Commit and wait in RFC adapter

[Former Member]

Hallo,

I have the following problem.

During the calling in synchronous way a BAPI (Create order) I have the nice option "commit handling" in RFC receiver adapter.

Perfect, but subsequently I need the document created in an another BAPI (create delivery). The call is too fast and the return is "The sales order 2455233132 is currently being processed by user XXXX".

So in another situation (external to XI) the calling of BAPI_TRANSACTION_COMMIT must be done with the parameter WAIT = 'X' to solve this issue.

What I have to do in the XI RFC receiver Channel?

Regards,

Sergio

[Former Member · Accepted solution]

Hello,

As variant of solution you can create ZBAPI (your BAPI wrapper) which differ from standard BAPI by calling BAPI_TRANSACTION_COMMIT with the parameter WAIT = 'X'. And use this ZBAPI in XI scenario.

BR,

Dzmitry

[MichalKrawczyk]

Hi,

the commit and wait will not solve the issue I believe

as someone else might also start blocking this sales order so this is not the best option

the best thing you can do is to combine then both in one Z RFC

in which you can create sales order and then delivery

and inside that RFC you can call delivery creatation and check the error

if it's the one with blocking you can call delivery creation once more

(with XI this will not be possible)

one other option is to use IDOC for delivery creation - once you post an IDOC

the delivery may not get created due to blocking but in afew minutes

when job that restarts IDOC will run it will be created

I'd go for option with IDOC but first option is also one you can choose

but I'd certainly woulndn't go for the option with two BAPIs

as the second one realy can get blocked for other reasons and then what?

will you restart it from a BPM?

Regards,

Michal KRawczyk

[former_member188972]

Hi Michal,

thank you for your response.

I think also me that a ZBAPI is the solution, but the call is to external system and the customer doesn't wont to use non standard methods (BAPI, Idoc).

Another solution is to wait the Idoc order response and then create the delivery.....but also here I have to ask customizations in the external system.

So you confirm to me that there isn't options or others to set the "wait" in the RFC adapter!

I don't think that is SOA compliant.

Sergio

[MichalKrawczyk]

Hi,

>>So you confirm to me that there isn't options or others to set the "wait" in the RFC adapter!

you need to tell the customer that either he will use standard BAPIs

and it will require strange and inefficient BPM inside XI (as you need to

check delivery errors anyway and restart if blocked)

or some customization and XI flow will be efficient

>>Another solution is to wait the Idoc order response and then create the delivery

you can call BAPI for sales order (sync) and the just do IDOC for delivery

it will require less effort on ERP - if this is the real problem

but the point is

that wait would not help you anyway and even if it would exist

you shouldn't use it in your case

Regards,

Michal Krawczyk

[Former Member]

I second that: the "wait" will not solve your problem. Even if you create an IDoc wrapper for both BAPI's, the problem would remain. The best option would be to merge the two BAPI's in a single zIDoc and handle the locking issue within the IDoc.