When the inbound function module is executed on the application side, the BAPI call is generated from the IDoc, the BAPI function module is called, and the IDoc status is determined. When processing of the BAPI (or the entire package) is complete, the status records of all the IDocs and all application data generated by the successfully completed BAPIs are written together to the database.
Conversion of IDoc into BAPI Call
When the BAPI is called, the entire data from the IDoc segments is written to the associated parameters of the BAPI function module. If an interface reduction has been defined for the BAPI, the hidden fields are not filled with the IDoc data.
BAPI Function Module Call
Next the BAPI function module with the filled parameters is executed synchronously. As the BAPI does not execute a COMMIT WORK command, the application data that it has created, modified ot deleted is not yet saved in the database.
Determination of IDoc status
If the function module has been executed, the IDoc status is determined in the inbound function module from the result of the call.
If the TYPE field is filled with A (abort) or E (error) in at least one of the entries of the return parameter, this means:
Type A: All status records of the corresponding IDoc are assigned status 51 (error, application document not posted), and a ROLLBACK WORK is executed.
Type E: All status records of the corresponding IDoc are assigned status 51 (error, application document not posted), and a COMMIT WORK is executed. During package processing, the COMMIT WORK is performed after the entire package has been processed (assuming no other BAPI returns an A message). The results of the invalid BAPIs are not saved, however; only their error status is recorded.
In all other cases, status 53 (application document posted) is written and a COMMIT WORK is executed. During package processing, the COMMIT WORK is performed after the entire package has been processed (assuming no other BAPI returns an A message).
Posting Application Data and IDoc Status
When every IDoc/BAPI is processed individually, the data is immediately written to the database. If several IDocs are processed within one packet, the following may happen:
If no BAPI within the package aborted with an A message, the COMMIT WORK command is executed after the entire package has been processed. This saves the application data of all successfully completed BAPIs to the database together with the status records of all the IDocs.
As soon as a BAPI in the package aborts with an A message, however, the status of the corresponding IDoc is set to 51, and a ROLLBACK WORK is performed immediately. Inbound processing is then started again for all BAPIs that were completed successfully before (that is, the ones that did not return an E or A message). If no other A message occurs during this run, a COMMIT WORK is performed; the application data of the valid BAPIs is written to the database together with the status records of the IDocs. If further A messages occur, the above procedure is repeated.
Packet processing is only carried out if there is no serialization.
If errors occur, the standard ALE error handling can be used. This has the following effects:
The update of the IDoc and/or BAPI that caused the error is cancelled.
An event is triggered. This event starts an error task (work item):
The employees responsible receive a task in their workflow inbox.
An error message is displayed when the task is processed.
The error is corrected in another window and the IDoc can then be resubmitted for processing.
If the error cannot be corrected, the IDoc can be marked for deletion.
Once the IDoc has been successfully posted, an event is triggered that terminates the error task. The task then disappears from the inbox.