Processing BAPIs
Procedure
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.
Converting the IDoc to a BAPI Call
When the BAPI call is generated, all the data from the IDoc segments is written to the corresponding parameters of the BAPI function module. If interface reduction has been defined for the BAPI, the suppressed fields are not filled with IDoc data.
Calling the BAPI Function Module
The BAPI function module is then executed synchronously with the filled parameters. Because the BAPI does not trigger a COMMIT WORK command, any application data that it creates, modifies, or deletes is not yet updated in the database.
Determining the IDoc Status
Once the execution of the function module is complete, the inbound function module determines the IDoc status, which depends on 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 a package, however, then the following situations are feasible:
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.
Package processing is only possible when no serialization is involved.
Error Handling
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 responsible person receives the task in their workflow inbox.
- Processing the task displays the error message.
- Once the error has been corrected in a separate window, the IDoc can be resubmitted for processing.
- If the error cannot be corrected, the IDoc can be flagged for deletion.
- Once the BAPI/IDoc has been successfully updated, an event is triggered that ends the error task. The task then disappears from the workflow inbox.