Commit handling for single BAPI calls

[Former Member]

Hi everyone,

I hope someone can help me! I am trying to call a bapi (BAPI_SLSTRANSACT_CREATEMULTI) from XI to CRM to create sales orders. Of course, I want the data to commit if the call is successful, so I have selected:

Advanced Mode

Send 'Confirm Transaction'

Commit Handling for Single BAPI Calls

in the RFC receiver. However, despite the fact a GUID and sales order number are returned to me from the bapi call, the data is not committed - when I look for the sales order number, it does not exist.

Have I set everything up correctly?

Thanks in advance

z

[Former Member · Accepted solution]

Hi Zadie,

-What do you see in the audit log in the RWB for the entry that represents the RFC BAPI message processing : In the audit log you should either see that the BAPI_COMMIT was triggered or that the BAPI_ROLLBACK was triggered.

-Do you see any dumps on the target system ( ST22 )

-Do you see anything unusual in the system log in the target system ( SM21 )

regards

Dirk

[Former Member · Accepted solution]

Hi Dirk,

Thank you for your response.

I have checked the Audit log and it shows that BAPI_ROLLBACK was called as the BAPI executed with errors - is there any way to find out what these errors were?

Thanks

z

[Former Member · Accepted solution]

Hi Zadie,

As your flow shows succesfull in XI, it means that the BAPI has issued an application error. Normally these errors are returned also in the log ( e.g. customer does not exist or something like that ) .

If not , you could try to

-execute the BAPI on target system ( if not to complicated ) via SE37 / Test option

-raise your logging and trace level e.g. via SXMB_ADM / Error Analysis / e.g Add a new entry for the user that runs the interface and put logging on and trace level to 3 ( synchronous success messages are by default not made persistent )

regards

Dirk

[Former Member · Accepted solution]

Hi Zadie

You might also want to check the update processes ( SM13 ) in the target system as you say that you get a sales order number back so it might be an error in the V1 update processes themselves,

regards

Dirk