Support for proper units of work

[Former Member]

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

[reiner_hille-doering]

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.

Regards,

Reiner.

[Former Member]

With respect Reiner, I think you missed the point.

The problem is entirely that the SAP-enforced requirement for BAPI's to implement asynchronous updates prevents easy use of these API's and adds to the cost of associated development in an era when SAP is touting NetWeaver as a way to reduce the total cost of ownership.

As an example, suppose a custom development, either from ABAP or Java or other, needs to:

a) create a customer

b) create an account

c) create a contract for the customer/account

For the purpose of this discussion it matters not what these things mean functionally, just that they follow one another such that the output of step A (a customer) is a required input of step B and the output of step B is a required input of step C.

As an SAP customer, I am meant to use the available BAPI's to perform these application tasks. However if I do so I will not be able to perform this as a single unit of work for the reasons stated in my initial posting.

What does this mean for my integration? It means additional complexity and thus cost because what should be a simple unit of work is now multiple and I need to consider how to handle failures in mid-point. Is it acceptable to leave the committed data there? Will the interface need to be designed to be able to restart at the point of failure?

The root cause of all this is the implicit commit issued by the RFC protocol at the end of each call.

With regards,

Scott

[reiner_hille-doering]

Hello Scott,

I'm really sorry, but I can't continue a general architectural discussion here because I'm not expert of SAP's overall transaction concepts.

I just wanted to note that there is no big difference between the technologies used to call a function: Yes, DB-transactions are commited after each RFC, but they are also commited at each screen-change from local ABAP. And Update-process LUWs are not automatically commited after RFC calls as long as the connections stays open and you don't call CommitWork; just the same situation as from local ABAP.

Regards,

Reiner.

[Former Member]

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.

Regards,

Scott