The proper way would be to set up a workflow for the successfully processed IDoc and send back an IDoc (recommended type: ALEAUD01, message type, outbound function AUDIT_IDOC_CREATE). Some applications, like the SD sales order, fire explicit workflow events, when the document has been created via ALE, i.e. through an IDoc). These events can then be used to send the workflow back.
Main menu for workflow is SWLD
The workflow events are coupled and enabled via transaction SWETYPEV (rel 4.6++; earlier releases edit table SWETYPECOU with SM30).
A workflow handler must comply with a rigid interface. To create an own handler for an event, you can copy PUR_ORDER_CREATE_VIA_SD_EVENT as a template.
To check out what events are fired by your application, you can check the event trace (transactions SWEL and SWELS).
For sales orders there is an event predefined: ALECREATED. In the event coupling SWETYPEV the processing by PUR_ORDER_CREATE_VIA_SD_EVENT is already defined but not activated. You can use this scenario as example for your works.
If the IDoc is updated by a transaction that does not fire events, you can indirectly trigger an arbitrary workflow via the change documents which fire their own events from within the function CHANGEDOCUMENT_CLOSE.
More details can be found in "The R/3 Guide to EDI and Interfaces" or at http://logosworld.com.
Dig Deeper on SAP Basis administration and NetWeaver administration
Related Q&A from Axel Angeli
An SAP user wants to know how to upload data into SAP R/3 when SAP Scripting is not enabled. Continue Reading
An SAP user is receiving an error message while integrating SAP iDoc PORDCR1 for a purchase order. Continue Reading
An SAP user is having difficulty with PERNR iDoc while transporting data from SAP to an external system. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.