Java – Call BAPI RFCs transactionally via JCo

Call BAPI RFCs transactionally via JCo… here is a solution to the problem.

Call BAPI RFCs transactionally via JCo

First of all, I’m not a SAP/BAPI developer.
We have a java application that uses the JCo library to call some BAPIs via RFC.
The question is whether there is any method that can call more than one of these in a single transaction.

I think the right thing to do is

  • Start JCoContext
  • Perform some RFCs
  • Call BAPI_TRANSACTION_COMMIT
  • End JCoContext

For example, we want to call these systems bapis:
BAPI_CATIMESHEETMGR_INSERT
BAPI_CATIMESHEETMGR_CHANGE

But for some reason, whatever we do, everything is committed.
I would like to know exactly what submitted this data. Is the commit part of those BAPIs or some kind of JCo “feature”?

Solution

A good place to start learning about the RFC transaction model is this piece of help , where you can read a guide on creating custom BAPIs:

BAPIs must not execute ‘COMMIT WORK’ commands.
Reason: The caller should have control of the transaction. Several BAPIs should be able to be combined within one LUW. For more information see Transaction Model for Developing BAPIs.
The following commands must not be used:

  • CALL TRANSACTION
  • SUBMIT REPORT
  • SUBMIT REPORT AND RETURN
    Database changes can only be made through updates.
    Reason: The RFC executes an implicit database commit.

So yes, usually your assumption is correct that implicit commits happen in RFCs.

In addition, the “Transaction Model for Developing BAPIs” help section contains important notes about your scenario:

The following restrictions apply to combining several BAPIs in one LUW:

  • If an instance was created, modified or deleted by a write BAPI, a read BAPI can only access the most recent data if a COMMIT WORK has taken place.
  • It is not possible to make two write accesses on the same instance within one LUW. For example, you cannot first create and then change the object within the same LUW.
  • You can, however, create several instances of the same object type within an LUW.

So you won’t be able to achieve what you want: create (BAPI_CATIMESHEETMGR_INSERT) and change (BAPI_CATIMESHEETMGR_CHANGE) schedules in one LUW (Logical Unit of Work).

It must be done in two LUWs (two RFC calls).

Related Problems and Solutions