Prerequisites: Section 1 of Recovering SAP BAPI Transactions with Custom Pipelines, which presents BAPI Operations and envelope schemas. It is like reintroducing the "COMMIT WORK" to the BAPI Transaction Model (Without Commit).Īll implementation artifacts and code are provided in the attached archive. Thanks to the new property BAPIContextId though, there is a simpler way to add recoverability to batches of BAPI transactions, by splitting them into independent "auto-commit" transactions. As demonstrated in Handling Errors in SAP BAPI Transactions, it is complicated to achieve. For instance, when a batch contains hundreds of transactions, if the BAPI transactions are unrelated and can be processed independently, it should be possible to keep the processing going rather than letting all messages/orchestration instances be suspended for some invalid field in one out of many transactions. In this first of two posts on the topic, we pick up where Recovering SAP BAPI Transactions with Custom Pipelines left off and look at how to support Recoverable Interchange Processing (RIP) with BAPI transactions when the "one-fails/all-fail" behavior could be cost-prohibitive. Previously, the grouping of BAPI transactions in the same context was always based on the message interchange id (which is still the default behavior).Ĭustom grouping can greatly simplify the implementation of some complex scenarios. It means that BAPI transaction messages can be now mapped arbitrarily to the same Logical Unit of Work (LUW) on the SAP server based on the value of the new property, .BAPIContextId. This post has been republished via RSS it originally appeared at: New blog articles in Microsoft Tech Community.Ī long-awaited improvement to the WCF-SAP adapter was recently introduced in BizTalk Server 2020 CU3: Support for custom grouping of BAPI transactions in the WCF-SAP adapter.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |