Event processing for an IDoc packet

An inbound event may contain multiple IDocs, with each IDoc corresponding to a single business object. The multiple IDocs are pushed out by the SAP system to the adapter in the form of an IDoc packet.

Note: The enterprise service discovery wizard allows you to create an ALE wrapper object. The wrapper object will contain a business object, of multiple cardinality, that represents an IDoc. All instances of this business object will be passed into the ALE interface in one RFC-enabled function call.
The following steps describe how the adapter processes an inbound event for an IDoc packet that contains multiple individual IDocs.
  1. When the SAP system pushes the Transaction ID (TID) to the adapter, the adapter checks the status of the event.
    • If this a new event, the adapter stores the TID along with a status of CREATED in the event recovery table.
    • If the event status is ROLLBACK, the adapter updates the status to CREATED.
    • If the event status is EXECUTED, the adapter returns a return code of SUCCESS to the SAP system.
  2. The SAP system pushes the IDoc packet to the adapter, which parses and converts the IDoc into multiple business objects and stores them in memory.
  3. The adapter also updates the NumIDocs column (or table field) in the EventRecovery table to the number of IDocs in the packet. This number is used for audit and recovery purposes. If the adapter encounters an error while processing the IDoc packet, it can behave in one of two different ways, depending on the IgnoreIDocPacketErrors configuration property:
    • If the IgnoreIDocPacketErrors property is set to false, the adapter stops processing any further IDocs in the packet and reports errors to the SAP system.
    • If the IgnoreIDocPacketErrors property is set to true, the adapter log an error and continues processing the rest of the IDocs in the packet. The status of the transaction is marked as PARTIAL. In this case, the adapter log shows the IDoc numbers that failed and you must resubmit those individual IDocs separately. You must then manually maintain these records
  4. The adapter sends the business objects to the message endpoint, one after the other, and updates the CurrIDoc 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.
  5. When the endpoint receives the event and the transaction is committed, the adapter increments the number in the CurrIDoc property. The message endpoint must be configured to support XA transactions.
  6. After the adapter delivers all the business objects in the IDoc packet to the message endpoint, it updates the event status to EXECUTED.
  7. The SAP system sends a COMMIT call to the adapter.
  8. 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 CurrIDoc property, even if IgnoreIDocPacketErrors is set to true. This is required in case the user terminates the adapter manually while processing an IDoc packet.
  9. The adapter logs a common event infrastructure (CEI) event that can be used for tracking and auditing purposes.
  10. If an exception occurs either while the adapter processes the event or when the endpoint raises an exception, the event status is updated to ROLLBACK.
  11. The SAP system sends a CONFIRM call to the adapter. If the status is EXECUTED, the adapter deletes the records from the event recovery table.

Terms of use |

Last updated: Sun Mar 12 11:15:17 2006

(c) Copyright IBM Corporation 2005.
This information center is powered by Eclipse technology (http://www.eclipse.org)