Two Transactions in One BDC session

[satyapriyanka_vana]

Hello Friends,

I have a requirement of creation of an asset(AS01) and after the asset is created, process one more operation in tcode ABNAN. The user wants it as a BDC session method. Until the user process the session I cannot retrieve the asset number which is mandatory field for ABNAN transaction. So I decided to use BAPI to create asset and for the second transaction I will use the BDC session (at that time asset number will be available). But in this case, before user process the session, the asset will be created, which is wrong. Is there anyway to use the two tcodes sequentially in a session ?

Thanks & Regards,

Priyanka.

[Jelena]

Use 'ABAP Development' tag for ABAP questions.

The users want to be BDC session to be created and they will process it separately? Then, naturally, you can't combine BAPI call and session on the same LUW. It's not possible.

If you use a BAPI and don't COMMIT but call BDC afterwards it has at least a chance of working together (although it seems like a poor design choice) but session is a separate update.

I believe you can combine two transaction calls in one session but then you can't use BAPI (unless you put it in a transaction and then call it using BDC, which would be rather ridiculous).

[raymond_giuseppi]

Why don't you use only BAPIs: First creation BAPI BAPI_FIXEDASSET_CREATE1 and then a posting BAPI like BAPI_ASSET_ACQUISITION_POST (BUS6029) or BAPI_ASSET_POSTCAP_CHECK (BUS6027) ?
Regards,
Raymond

[former_member182550]

The only problem being that you need to issue a commit work and wait between the first and second bapi's so that the asset that you are posting against is created.

The same goes for Jelena's answer above - if you have two BDC sessions you get implied commits. However, using BAPI in the first transaction requires a commit.

[raymond_giuseppi]

With the BAPI you can use the WAIT option, with BDC the standard transactions don't usually use the WAIT option. You can move the WAIT from COMMIT to a LOCK request before second call. What behavior do your users want when the second call fail?