Remote BAPI_TRANSACTION_COMMIT from APO to ECC

[Former Member]

We have an APO application at this site that has to call the function SWE_EVENT_CREATE on a remote ECC instance.

To actually create the event, we follow this function call with a remote BAPI_TRANSACTION_COMMIT call to the same ECC partner.

So a question naturally occurs that has probably occurred to some of you already.

Since ECC knows the APO application as "ALEREMOTE", what if anotherr APO application happens to do some remote commitable work on the same ECC partner in the split-second between the time we call the event create function and the time we call the commit BAPI.

Won't the commit BAPI commit that stuff as well as our stuff?

And if not, why not ????

[Sougata]

Hello David,

The good news is that you can make the system work like the way you want it to. As you have not mentioned the details of how you calling the function SWE_EVENT_CREATE (i.e. the parameters and options of the function call), I cannot confirm if the BAPI will commit your stuff and other stuff together or in a separate LUW but I can confirm that you can program it in a way to commit all or commit one at a time. To implement this you need to look at various options when calling the RFC by using Transactional RFC (tRFC) or Asynchronous RFC (aRFC) and another technique that SAP calls Queued RFC (qRFC) With Send Queue

I'll now copy/paste some relevant info for you from SAP Documentation about tRFC and qRFC which I think is what you need to analyse in order to implement this commit as a separate unit (of work).

What Does tRFC Perform Right Now?
1. tRFC guarantees that a called function module is executed in the target system exactly once. 
2. All tRFC calls terminated with the statement COMMIT WORK belong to one LUW (Logical Unit of Work). Each LUW automatically receives a transaction ID. 
3. Within an LUW, all function modules are executed in the target system in the sequence in which they are called in the send system. 
4. tRFC calls with the addition AS SEPARATE UNIT map a separate LUW each in the target system. Such a sub LUW contains exactly one tRFC call and is processed independent of the actual (superior) LUW. This sub LUW receives its own transaction ID. 
5. If within an LUW several destinations are used, all tRFC calls that belong to one destination also form a sub LUW. However, since this bundling happens only internally, there is no separate transaction ID assigned to the sub LUW.
Use and Availability
The typical applications for which the serialization of tRFC was implemented use distributed environments:
ALE (Application Link Enabling) 
APO (Advanced Planner and Optimizer) 
SFA (Sales Force Automation)
As a special feature for APO, the serialization is provided as a special release for APO systems of Release 3.1H or 4.5A, respectively .

You can read more on this in the section named RFC Programming in ABAP - you won't believe how flexible it is till you see it!

Hope this helps,

Cheers,

Sougata.

[Former Member]

Hi Sougata -

I'm not sure you've answered the question, but you've certainly provided a good perspective and good leads to further reading.

Thanks very much

djh