Skip to Content
author's profile photo Former Member
Former Member

Support for proper units of work

This posting is very similar to one I posted in the Web AS forum. I am reposting here as although this is not an RFC forum as such, it is probably the closest thing given the topics are mostly about the .NET connector.

One of the problems I've always found with the SAP BAPI and RFC concept is the way in which database updates must be coded to execute asynchronously to the function call. That is, the function queues database updates via PERFORM ... ON COMMIT, later started by a call to a function that issues a COMMIT WORK (like BAPI_TRANSACTION_COMMIT).

I understand that the reason for this is because there is a database commit done at the end of each function call and so if updates were done directly in the function logic then they would be committed at the end of the call, preventing the caller from rolling back or from creating a logical unit of work across multiple function calls.

However, this introduces problems too:

1) It complicates the function logic and it is not always clear whether a function supports multiple calls to itself within the same unit of work.

2) It is often not possible to perform unit of work updates anyway, because the subsequent calls fail if the updates of the former have not been made to the database.

For example, in the Utilities industry a company might receive market notification that they are to establish a service connection for a new customer. Ideally an external interface (such as a J2EE app) should be able to do this as a single unit of work, by calling the relevant functions to create the new customer and then the service connection. If the latter function call fails, then the former should be backed out.

Currently this would not be possible because the latter function call would attempt to validate the existence of the customer record in the database, but of course it is not there yet due to the asynchronous DB update logic.

I'm surprised this hasn't come up more given the tight RFC-based integration between Java and ABAP (ie. JCO).

Are there any plans to address this deficiency?


Scott Barden

Add a comment
10|10000 characters needed characters exceeded

Related questions

1 Answer

  • Posted on Mar 08, 2004 at 10:33 AM

    Hello Scott,

    I think the question if and when to call CommitWork is not dependent on the technology you use to make the call or even if you use RFC or call the stuff directly from ABAP. It's the the matter of how the functions work - if it uses the update process or stored data directly to DB - and if it is dependent on data already commited to DB.

    I think this information is available in the documentation of the functions.



    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member Reiner Hille-Doering

      Thanks Reiner - any chance you know who the expert is? 😊

      I take your point about asynchronous update LUW's in ABAP being the same. It just that it seems specifically because of this RFC limitation that the BAPI standard for asynchronous was chosen in 4.x (I seem to recall in 3.1x that many had synchronous updates).

      For this reason when dealing with the SAP Utilities solution, we generally avoid BAPI's using instead the lower level IS-U functions. We are quite fortunate because the developers of IS-U (and FI-CA) have in general done an excellent job and employed a standardised approach across the solution, allowing us to take this path.



Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.