We are currently implementing ESS/MSS in a global environment on 4.5B. We have created custom BAPIs as we have...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
a lot custom fields and infotypes. We are using BEA System products (Weblogic, TUXEDO and eLink Adapter) to connect to R/3. The eLink experts tell us that we have to use 'wrapper' BAPIs to minimize the calls to R/3 and to ensure data integrity. We would need to make sure that all of our write BAPIs have the COMMIT WORK implemented in the write BAPI and therefore executed in the BAPI. According to SAP documentation this was the case with 3.1x but has been changed from 4.0x. What was the reason for that and why would you recommend to have the COMMIT separated from the actual write BAPI.
For now we have created the BAPIs in a standardized way with separate DELETE and CREATE BAPIs but the eLink team tells us that in order to have load balancing on their side we would need a 'wrapper' BAPI to combine those calls - with the COMMIT or ROLLBACK at the end of the processing - otherwise it could happen that the CREATE is executed before the DELETE or that a ROLLBACK BAPI is executed for a BAPI which is actually OK !
Can anyone explain the sequence when having several write BAPIs and why you have implemented it that way.
Please let me know your comments on this.
* Limiting the number of calls to SAP is a good idea for performance reasons, but is not required for the sake of data integrity. * BAPIs that do not use their own COMMIT WORK allow you (within certain limits, see below) to combine multiple update activities into one Logical Unit of Work (LUW) which is required for certain scenarios (stateful programming). If you do not need this capability then each BAPI can contain its own COMMIT WORK, although that limits the flexibility of a BAPI. * Remember that BAPIs using an external COMMIT WORK approach must use the update task to perform their changes! * Since the external COMMIT WORK requires stateful programming, you need to hold on to a connection for the whole duration of the LUW. This does not preclude the use of session pooling, but increases the time a connection is in use. Stateless programming, while "ugly" from an object-oriented perspective, gives you better overall performance. Both approaches can be used, provided that the middleware, in your case BEA, supports both. * I do not know the BEA products intimately, so I cannot comment on what exactly their SAP connectivity component does, but the following is true in general: Assuming that all BAPI calls that need to take place in the same LUW are executed in the same session (and hence thread, if multi-threading is used), there are no serialization issues, where one BAPI overtakes another one. The sequence of calls would be this: - Open the session (i. e. get a connection from the pool). - Call all the BAPIs you need to call within the same LUW (provided they all follow the rule and do not include their own COMMIT WORK). - Call the TransactionCommit BAPI if all previous BAPI calls returned OK. - Call the TransactionRollback BAPI if there are any problems. - Return the connection to the pool. * What cannot be achieved using the approach detailed above is this: 1. Add a new object (e. g. a customer). 2. Create an new object depending on the previous call (e. g. create a sales order for the new customer). 3. Commit both activities. Step two would fail, because the update task has not really created the customer yet (that happens after the COMMIT WORK). Here you need to insert a COMMIT WORK AND WAIT call after the first step (i. e. you now have two LUWs, not one). COMMIT WORK AND WAIT makes sure that the update task has completed before control returns to the client program. For details about this topic, refer to my article "Transaction Handling in SAP R/3 - What Every Programmer Needs to Know" in the July/August 2000 issue of the SAP Professional Journal (www.sappro.com). Another general tip: Make sure that any middleware you use to connect to SAP through Java uses the SAP Java Connector (JCo), not the obsolete SAP JRFC software!
Dig Deeper on SAP ABAP
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.