Use of BAPIs for FS CD

[Former Member]

I am new to the world of BAPI and I need to ask a very basic question on the use of BAPIs with FS CD.

I need to call, from an external system via RFC, the following series of BAPIs on SAP FS CD

BAPI_BUPA_CREATE_FROM_DATA

BAPI_BUPA_TAX_ADD

BAPI_BUPA_BANKDETAIL_ADD

BAPI_BUPR_RELATIONSHIP_CREATE

BAPI_CD_INSOBJ_CREATE

BAPI_PPLAN_ITEM_CREATE (this BAPI could be called more than 1 time with different data)

Is it possible to insert the entire set of calls within the boundaries of a transaction so that, at the end a either a COMMIT or ROLLBACK can be issued to confirm or not the entire transaction?

Do I need to COMMIT/ROLLBACK for every object (BP, IO, etc.)?

Do I need to issue a COMMIT after every BAPI call in order to be able to issue the next BAPI?

Thanks

Enrico

[Former Member]

Hello Enrico,

I shall not waste toomany words trying to explain it to you when SAP has already done the job wonderfully!!

Please read the documentation for the Function Modules BAPI_TRANSACTION_COMMIT and BAPI_TRANSACTION_ROLLBACK.

If you happen to have furthr doubts, then please do get back with them and and we shall try to resolve them.

Regards,

Anand Mandalika.

P.S: Seems like you have just registered on SDN and that this is your first post here. I welcome you to SDN. Have a nice time.

[Former Member]

Anand,

thanks for your reply. I still need to do some more investigation and therefore I will add further details.

1) The sequence of BAPIs reported in my initial posting is what FS CD requires to complete a business operation (inserting a one or more movements related to the issuing of a new policy for a new customer).

2) These BAPIs are invoked using the IBM SAP Adapter for WBI (Web Sphere Business Integrator). The documentation of the adapter says that it supports the transactional mode (i.e. can issue a COMMIT/ROLLBACK at the end of the sequence of BAPIs and uses the same RFC connection for all the BAPIs in the same transaction).

3) Nonetheless, somebody at the customer claims they have tried to issue the first 2 BAPIs (..) and that, in order for the second one to work, the first one had to be committed. I do not have any further detail on the type of test performed, but what I have reported seems not to match with the transaction capabilities the the BAPIs and the IBM Adapter claim to have.

I can imagine 2 scenarios:

a) There is something specific in the sequence of BAPIs BAPI_BUPA_CREATE_FROM_DATA

BAPI_BUPA_TAX_ADD

that forces the COMMIT to be issued after the first one

b) The test was not performed correctly (e.g. 2 different RFC connections were used for the 2 different BAPIs)

Would it be possible for you to help me clarify a bit this problem?

Thanks

Enrico