3

First of all I'm not a SAP/BAPI developer. We have a java application that is calling some BAPIs over RFCs using JCo library. The question is whether there is any way to call several of those in a single transaction.

I believe the correct way to do it would be to

  • begin JCoContext
  • execute some RFCs
  • call BAPI_TRANSACTION_COMMIT
  • end JCoContext

E.g. we'd like to call those system bapis this way: BAPI_CATIMESHEETMGR_INSERT BAPI_CATIMESHEETMGR_CHANGE

But for some reason all the stuff gets commited regardless of what we do. I would like to understand what exactly is commiting this data. Are commits part of those BAPIs or is it some kind of JCo "feature"?

Suncatcher
  • 10,355
  • 10
  • 52
  • 90
archie_by
  • 1,623
  • 2
  • 11
  • 10
  • 3
    Your assumptions are correct. A BAPI should not commit data, but there are a few exceptions. Only `BAPI_TRANSACTION_COMMIT` should do that. But if you want to revert the updates, you should call `BAPI_TRANSACTION_ROLLBACK` otherwise that would do an implicit commit at the end of context. Opening and closing a context should open an independent transaction. If you can run a trace from SAP, with transaction code `ST05` and with the "call stack" logging option, you could see the ABAP origin of the commit. – Sandra Rossi Aug 17 '21 at 11:00

1 Answers1

3

A good place to start learning the RFC transaction model is this piece of help, where you can read the guidelines about 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, generally your assumption is correct, the implicit commit happens in RFC.

Moreover, "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 will not be able to achieve what you want: create (BAPI_CATIMESHEETMGR_INSERT) and change (BAPI_CATIMESHEETMGR_CHANGE) timesheet in one LUW (Logical Unit of Work).

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

Suncatcher
  • 10,355
  • 10
  • 52
  • 90