Event processing for parsed IDoc packets

An inbound event can contain a single IDoc or multiple IDocs, with each IDoc corresponding to a single business object. The multiple IDocs are sent by the SAP server to the adapter in the form of an IDoc packet. You can specify, during adapter configuration, whether the packet can be split into individual IDocs or whether it must be sent as one object (non-split).

Event processing begins when the SAP server sends a transaction ID to the adapter. The following sequence occurs.
  1. The adapter checks the status of the event and takes one of the following actions:
    • If this is a new event, the adapter stores an EVNTID (which corresponds to the transaction ID) along with a status of 0 (Created) in the event recovery table.
    • If the event status is -1 (Rollback), the adapter updates the status to 0 (Created).
    • If the event status is 1 (Executed), the adapter returns an indication of success to the SAP system.
  2. The SAP system sends the IDoc to the adapter.
  3. The adapter converts the IDoc to a business object and sends it to the endpoint.
    For single IDocs and non-split IDoc packets, the adapter can deliver objects to endpoints that support transactions as well as to endpoints that do not support transactions.
    • For endpoints that support transactions, the adapter delivers the object as part of a unique XA transaction. When the endpoint processes the event and the transaction is committed, the status of the event is updated to 1 (Executed).

      The endpoint must be configured to support XA transactions.

    • For endpoints that do not support transactions, the adapter delivers the object to the endpoint and updates the status of the event to 1 (Executed). The adapter delivers the business object without the quality of service (QOS) that guarantees once-only delivery.
  4. For split packets only, the adapter performs the following tasks:
    1. The adapter updates the BQTOTAL column (or table field) in the event recovery table to the number of IDocs in the packet. This number is used for audit and recovery purposes.
    2. The adapter sends the business objects to the message endpoint, one after the other, and updates the BQPROC property to the sequence number of the IDoc it is working on. The adapter delivers the objects to the appropriate endpoint as part of a unique XA transaction (a two-phase commit transaction) controlled by the application server.
    3. When the endpoint receives the event and the transaction is committed, the adapter increments the number in the BQPROC property.

      The message endpoint must be configured to support XA transactions.

      If the adapter encounters an error while processing a split IDoc packet, it can behave in one of two ways, depending on the IgnoreIDocPacketErrors configuration property:
      • If the IgnoreIDocPacketErrors property is set to false, the adapter stops processing any additional IDocs in the packet and reports errors to the SAP system.
      • If the IgnoreIDocPacketErrors property is set to true, the adapter logs an error and continues processing the rest of the IDocs in the packet. The status of the transaction is marked 3 (InProgress). In this case, the adapter log shows the IDoc numbers that failed, and you must resubmit those individual IDocs separately. You must also manually maintain these records in the event recovery table.

      This property is not used for single IDocs and for non-split IDoc packets.

    4. The SAP system sends a COMMIT call to the adapter.
    5. After the adapter delivers all the business objects in the IDoc packet to the message endpoint, it updates the event status to 1 (Executed).
    6. In case of abrupt interruptions during IDoc packet processing, the adapter resumes processing the IDocs from the current sequence number. The adapter continues updating the BQPROC property, even if IgnoreIDocPacketErrors is set to true. The adapter continues the processing in case you terminate the adapter manually while the adapter is processing an IDoc packet.
  5. If an exception occurs either while the adapter is processing the event or if the endpoint generates an exception, the event status is updated to -1 (Rollback).
  6. If no exception occurs, the SAP server sends a CONFIRM call to the adapter.
  7. The adapter deletes the records with a 1 (Executed) status and logs a common event infrastructure (CEI) event that can be used for tracking and auditing purposes.