locking issue when using BAPI_PRODORD_CHANGE and then BAPI_PRODORD_RELEASE

[prashant_kumar30]

Hello Experts,

I am using the BAPI_PRODORD_CHANGE and then BAPI_PRODORD_RELEASE in a sequence to change the prod ord and then release in a LOOP.

when running in fdebuggin it works fine but when i am running in background/forground ,orders are getting locked .

Can anyone have idea, what could be the reason.

below is my code for reference.

 LOOP AT gt_out ASSIGNING <lfs_output>.<br>CALL FUNCTION 'BAPI_PRODORD_SCHEDULE'<br> EXPORTING<br> sched_type = 2 " Scheduling type<br> bck_dlv_origin = 1<br> bck_dlv_date = end_dat<br> fwd_beg_date = start_dat<br> work_process_group = 'COWORK_BAPI'<br> work_process_max = 99<br> IMPORTING<br> return = ls_return<br> TABLES<br> orders = lt_orders.<br> IF ls_return-type <> lc_e AND ls_return-type <> lc_a.<br> lv_number = <lfs_output>-aufnr.<br> ls_orderdata-basic_end_date = ls_output_tsd-prop_mad.<br> ls_orderdatax-basic_end_date = abap_true.<br>* * Update Production Order<br> CALL FUNCTION 'BAPI_PRODORD_CHANGE'<br> EXPORTING<br> number = lv_number<br> orderdata = ls_orderdata<br> orderdatax = ls_orderdatax<br> IMPORTING<br> return = ls_return.<br> IF ls_return-type <> lc_e AND ls_return-type <> lc_a.<br> <lfs_output>-upd_flag = abap_true.<br> READ TABLE it_prod_order INTO DATA(wa_prod_order) WITH KEY aufnr = <lfs_output>-aufnr BINARY SEARCH.<br> IF sy-subrc EQ 0.<br> CLEAR : lt_rel_ord[], lt_rel_ret[], ls_rel_ord, ls_rel_ret , wa_output.<br> READ TABLE gt_out INTO DATA(ls_pout) WITH KEY aufnr = wa_prod_order-aufnr BINARY SEARCH.<br> IF sy-subrc EQ 0 AND ls_pout-upd_flag NE abap_true.<br> wa_output-icon = c_red .<br> wa_output-aufnr = ls_pout-aufnr .<br> wa_output-text = ls_pout-message_txt.<br> APPEND wa_output TO gt_output .<br> continue<br> ENDIF.<br> CLEAR : ls_pout.<br> ENDIF.<br> ls_rel_ord-order_number = wa_prod_order-aufnr.<br> APPEND ls_rel_ord TO lt_rel_ord.<br> IF lt_rel_ord[] IS NOT INITIAL.<br> CALL FUNCTION 'BAPI_PRODORD_RELEASE'<br> EXPORTING<br> release_control = '1'<br> work_process_group = 'COWORK_BAPI'<br> work_process_max = 99<br> TABLES<br> orders = lt_rel_ord<br> detail_return = lt_rel_ret.<br> IF lt_rel_ret[] IS NOT INITIAL .<br> READ TABLE lt_rel_ret INTO ls_rel_ret WITH KEY type = 'E'.<br> IF sy-subrc EQ 0.<br> CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK' .<br> ELSE.<br> CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'<br> EXPORTING<br> wait = abap_true.<br> ENDIF.<br>endloop

when i schedule the job ,spool output is generating like as shown below.But in debugging it is releasing each order successfully

[Marissa]

Hi prashant.kumar30,

Could you please confirm if you're working with SAP S/4HANA Cloud 2302?

Best regards,
Marissa

[prashant_kumar30]

Hi Marissa,

No, its 1709 NW 7.52

[Sandra_Rossi]

Please edit your question (Actions>Edit), select your code and press the button [CODE], which makes the code appear colored/indented, it'll be easier for people to look at it. Thanks!

[Marissa]

Hi,

I removed tag SAP S/4HANA Cloud ABAP Environment because it's for public cloud.

Best regards,
Marissa

[Jochen]

Quote:

BAPI_PRODORD_CHANGE and SCHEDULE

Initialization

When it is called, this method initializes the document tables for order processing and the document tables for status management. For this reason, a COMMIT WORK should be entered before the method is called if other BAPIs have already been called or there are other entries in the document tables for order processing or status management as a result of other actions.

As it's done in a loop I would recommend doing so - commit work and wait before these calls.

@SAP it's not good practice to do commits explicitly in BAPI's - what about RAP/FIORI apps and "commits are not allowed"? Or am I wrong at this place?

[Sandra_Rossi]

NB: I guess there's a switch to modern API, OData services. I guess it will take time to migrate all BAPIs though.

[prashant_kumar30]

Hi haasejoc

Do u suggest me to use commit work and wait after BAPI_PRODORD_SCHEDULE and before BAPI_PRODORD_CHANGE?

Thanks

Prashant

[Jochen]

before both - BAPI documentation gives a hint about that

[prashant_kumar30]

haasejoc

sorry i tried but that does not made any difference on locking of records.

Thanks

Prashant

[prashant_kumar30]

Closing this thread as i dint get any solution.

[Sandra_Rossi]

As you can see in the documentation of all these three BAPI_PRODORD_* function modules, they run a COMMIT WORK themselves (NB: I looked at ECC 6, not sure about S/4HANA).

I just looked at ECC code, and it seems that they run a COMMIT WORK, not a COMMIT WORK AND WAIT, so the locks are retained till the asynchronous updates are done, hence the next BAPI called runs possibly before the locks are released.

Consequently, I suggest that you run SET UPDATE TASK LOCAL before running each function module, which will have the same effect as running the next COMMIT WORK the same way as COMMIT WORK AND WAIT. If one BAPI runs more than one SAP LUW (COMMIT WORK running several times), the solution may not work because SET UPDATE TASK LOCAL is active only for one SAP LUW (NB: it's why I ask you to run it before each BAPI call).

PS: pay attention to other instructions in the BAPI_PRODORD_* documentations about COMMIT WORK before calling the BAPI.

[prashant_kumar30]

Hi Sandra Rossi,

Thanks for your input/suggestion.

Actually i had already tried to put SET UPDATE TASK LOCAL before posting my query. But that also dint helped me as well.

Thanks

Prashant

[Sandra_Rossi]

Unfortunately, you posted ABAP code which is not using SET UPDATE TASK LOCAL, so we can't tell you if possibly it's wrong or not.

To know what the problem is exactly, you should use an SQL trace to see where the implicit COMMIT WORK.

If you can't diagnose yourself, there is still the option of using the WAIT UP TO number SECONDS.