Q
Problem solve Get help with specific problems with your technologies, process and projects.

BAPIs in a global 4.5B implementation

We are currently implementing ESS/MSS in a global environment on 4.5B. We have created custom BAPIs as we have...

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!

This was last published in June 2001

Dig Deeper on SAP ABAP

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchManufacturingERP

SearchOracle

SearchDataManagement

SearchAWS

SearchBusinessAnalytics

SearchCRM

SearchContentManagement

SearchFinancialApplications

Close