Home

Sequencing

Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors
page

Overview

The Sequencing feature prevents parallel send operations for the same object. By default, events are dispatched directly, asynchronously, and potentially in parallel, which requires consumers to handle out-of-sequence delivery — particularly during error recovery and reprocessing.

Sequencing eliminates this requirement by ensuring that all messages referring to the same object identifier (e.g., the same Sales Order number) are transmitted in strict order. The sequencing process comprises the following steps:

  1. Persisting the generated payload to the outbox table

  2. Acquiring an exclusive lock on the sequence key to prevent concurrent send operations

  3. Processing any pending payloads with an earlier timestamp for the same sequence key prior to the current payload

If any of these steps results in an error, the remaining payloads are retained and processed on the next retry or on the next event for the same object.

Note: Because payloads are transmitted in the order of their creation, intermediate status changes are preserved. This is relevant for use cases involving status transitions, where standard reprocessing might otherwise skip intermediate states.

Activate Sequencing

The Sequencing feature is configured in the Header Attributes of the Outbound Object.

  • Go to transaction: /ASADEV/ACI_SETTINGS

  • Select your Instance and Outbound Object

  • Go to Header Attributes

  • Add New Entry and specify:

    • Header Attribute: SEQUENCING

    • Header Attribute Value: X

Header Attribute

Header Attribute Value

Description

SEQUENCING

X

Activates sequencing for this outbound object

Use Outbox Pattern

Purpose: Achieves complete sequencing guarantees by persisting events to an outbox table as part of the same database transaction as the application data change.

If outbox entries are not saved together with the application data but only at the time of event consumption, parallel events on the same object may be processed out of sequence. Implementing the outbox pattern eliminates this risk.

Prerequisites: The application logic must be enhanced to create outbox entries before events are raised. This is typically implemented via a BAdI.

Implementation: Use class /ASADEV/CL_OUTBOX_COLLECTOR with methods PREPARE_ENTRY and SAVE_ENTRIES to create outbox entries.

The created entries can be configured using header attributes:

Configuration:

  • Go to transaction: /ASADEV/ACI_SETTINGS

  • Select your Instance and Outbound Object

  • Go to Header Attributes

  • Add New Entry and specify the attributes based on the table below

Header Attribute

Header Attribute Value

Description

SEQUENCE_OBJECT

<name for the sequence>

The object type to sequence on

SEQUENCE_KEY

<key for the sequence>

The key value to sequence on

Note: The SEQUENCE_OBJECT and SEQUENCE_KEY attributes allow the same sequence to be shared across different Outbound Objects (e.g., Sales Order header and Sales Order item events), ensuring a consistent ordering across related event types.

Use RAP Event Data

Purpose: Skips the data extraction step by using the payload included directly in the RAP event.

Certain RAP events include a complete data snapshot as part of the event itself. In these cases, re-extracting data from the application can be bypassed. Because the payload represents the state at the time of the event, Sequencing must be active to ensure that snapshots are not delivered out of order.

Prerequisites: The Sequencing feature must be activated (see Activate Sequencing).

Configuration:

  • Go to transaction: /ASADEV/ACI_SETTINGS

  • Select your Instance and Outbound Object

  • Go to Header Attributes

  • Add New Entry and specify:

    • Header Attribute: USE_EVENT_DATA

    • Header Attribute Value: X

Header Attribute

Header Attribute Value

Description

USE_EVENT_DATA

X

Skips data extraction and uses the RAP event payload instead

Combine RAP Data Events and the Outbox Pattern

Purpose: Correlates outbox entries created in the application logic with the corresponding RAP event data payload.

When both options are used together, each outbox entry must be linked to its corresponding RAP event. This is necessary because the outbox entry is created before the event is raised, and the event data must reference the correct outbox identifier to enable proper correlation during processing.

Example Use Case: The SAP Fioneer Transactional Banking component provides full data events that can be extended via BAdIs, making it a perfect candidate for this combined approach.

Prerequisites:

  • Sequencing must be activated (see Activate Sequencing)
  • The Outbox Pattern must be implemented (see Use Outbox Pattern)
  • RAP Event Data must be enabled (see Use RAP Event Data)

Implementation: Implement BAdI /ASARAP/EVENT_DATA_BADI to extract the key information from the event data that identifies the corresponding outbox entry.

This BAdI is invoked in the receiver class for locally consumed RAP events (/ASARAP/EVENT_DISTRIBUTOR) before change pointers are created.

The method ADJUST_EVENT_DATA returns the following:

Return Value Description
List of outbox IDs Identifies the outbox records for the processed event. Multiple IDs are returned for bulk events.
Reference to usable event data Provides the payload reference used during payload generation
Adapted change pointers In most cases, change pointers are adapted to reference the outbox entry rather than the original application object

Scroll to Top