COMMIT WORK - performance problem

[Former Member]

Dear Fellow SDNers,

I seek your help on the following problem:

Scenario : Inbound idoc which updates an Outbound delivery with Picked quantity, posts the goods issue and then creates billing document

Approach : I am using the function module SD_DELIVERY_UPDATE_PICKING to update the delivery from the idoc data and to post goods issue. Thereafter, i use BAPI_BILLINGDOC_CREATEMULTIPLE to create the billing document. Before calling this BAPI, I use a COMMIT WORK statement to update the relevant tables so as to enable invoice creation properly.

Problem: The COMMIT WORK statement takes a lot of time to execute (I have no update tasks that could lead to this), so much that the idoc (probably) has a timeout and ends up in status 64. As a result, the succeeding part of the code (after COMMIT WORK) is not executed and the billing document is not created.

When I debug this, the COMMIT WORK statement leads to a strange screen (which looks like a blank report output screen, with its title as "UPDATE CONTROL". However (of course), there is no timeout while debugging and the billing document is successfully created.

Could anyone provide some pointers to solve this problem?

regards,

Priyank

[anup_deshmukh4]

Hello have you tried calling bapi with UPDATE TASK addition

[mvoros]

Hi,

I would suggest to create a new RFC enabled function module which will be wrapper for SD_DELIVERY_UPDATE_PICKING and BAPI_BILLINGDOC_CREATEMULTIPLE. So you will call this wrapper from your IDoc code with option STARTING NEW TASK. So IDoc code would not have to wait for this code. It will be processed asynchronously in separate task.

Cheers

[Former Member]

hi Martin,

Thanks for your reply.

I could try the approach you suggest but i actually want the idoc to wait for the billing document creation to finish...and then i want to give it a status message accordingly. Therefore, my main problem is that the statement : COMMIT WORK AND WAIT takes so long that there seems to be a timeout and the subsequent part is not executed. Also, it shows up the "UPDATE CONTROL" screen when i process using standard inbound processing through WE19.

Any further hints?

regards,

Priyank

[mvoros]

Hi,

that's weird. Are you sure that your code times out? Maybe there is something else. You can try to check system log SM21 or check ABAP dumps ST22. Are you sure that you can call COMMIT WORK in your code? You can't call COMMIT WORK when you are already in UPDATE TASK.

Cheers

[Former Member]

hi Martin,

As i said, i am not calling the function in update task...after i call the first FM, a commit work is required and without it, the relevant tables are not updated to facilitate billing doc creation by the second BAPI.

The idoc ends up in status 64 but the updates for the preceding part of the code (updating of pick quantity for the delivery and goods issue) is being done perfectly. The table VBUK is pending to be updated which happens only after the COMMIT WORK AND WAIT Statement.

I know it sounds really wierd...but unfortunately this is what is happening.

regards,

Priyank

[mvoros]

But where do you call those FMs from?

[Former Member]

i have a custom function module Y_IDOC_INPUT_WMSPICK001 which is responsible for idoc inbound processing. SAP PI sends the inbound data to ECC and once this is done, this function module is executed.

This FM has the following code sequence inside it...

1) Call the FM SD_DELIVERY_UPDATE_PICKING

2) COMMIT WORK AND WAIT.

3) Call the BAPI_BILLINGDOC_CREATEMULTIPLE

Step1 is successfully executed, the step 2 takes a long time, and after that, the step 3 is not executed at all and the idoc ends up with a yellow light (status 64).

hope it clarifies what I am doing

regards,

Priyank

[mvoros]

I checked the FM SD_DELIVERY_UPDATE_PICKING and it has the parameter SYNCHRON. I guess that this parameter switches FM to synchronous mode. I also guess that the parameter NICHT_SPERREN has to be blank. In this case the FM will call COMMIT. So probably you can skip the second step.

Cheers