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?

Cheers,

Scott Barden