Exception condition "OS_COMMIT_WORK_FORBIDDEN" triggered

[former_member210804]

Hello Experts,

I need your help/suggestion. I m working on CO60 transaction where we are entering data below information.

Material

Enter Material

Resv Batch Enter Batch HU Number Scale ID# Weigh Mat Zero Wt UOM Zero Wt Scale Wt UOM MW Indicator Read Wt Man Wt P Status Signature

in the signature column, once click on enter button, our custom function module (Z_HU_PACK) triggers, which performs packing HU . For packing HU, we are using the standard FM BAPI_HU_PACK and followed BAPI_TRANSACTION_COMMIT to commit the record in DB . But during this bapi_transaction_commit, it is going to dump. (Exception condition "OS_COMMIT_WORK_FORBIDDEN" triggered)

If I run the the custom FM from se37, no dump occurs. Please suggest me to overcome this strange issue.

Thanks,

Narasimha

[nabheetscn]

This will happen as you can not do commit in existing LUW of standard it will lead to inconsistencies. If you still want to perform the commit on enter and do not wait for user to save then better wrap the call of both BAPI and commit in an FM and use starting new task options to get the work done in new LUW.

BTW normally we want packing to be done on save and let standard commit handles the rest of the things.

Nabheet

[former_member210804]

Thank you Nabheet. Can you provide me syntax how to use 'starting new task options'. After starting new task , what parameter I should pass?

Thanks,

Narasimha.

[former_member182550]

Are you sure you want to do this ? SAP is telling you that your code is doing something wrong..... badly so and yet you still want to carry on down this path and continue corrupting your data ????

The thing to do is to go back to your process design and redesign it so that you do not do a commit. Also, somewhere in the mists of time I seem to remember that BAPI's and enhancements should not do commits.......

[loyd_enochs3]

Richard,

COMMIT should not occur within an enhancement because the standard SAP transaction is doing a commit somewhere along the line, and a commit in the enhancement would violate the LUW of the original transaction.

BAPI should not contain a commit work because they are 'generic' operations that can legitimately be called from within an enhancement - and thus a commit in the BAPI would run afoul of the original LUW as well. That 'generic' ability is supposedly why BAPI_TRANSACTION_COMMIT exists at all.

In addition, a BAPI can be remote enabled and behave as an RFC, and we definitely don't want an external process updating the SAP database without proper controls (permissions, LUW, locking, etc, etc).

Just my .02

Loyd Enochs

[former_member210804]

Thank you Nabheet, Richard and Loyd..

As Nabheet stated, created new FM by wrapping the standard bapi with bapi_transaction_commit ,in addition used option 'DESTINATION 'NONE' ..it is not going for dump now even after several executions..This option provided by SAP to overcome this dump. Please look at the screenshot below.

Please suggest is that the right approach to process .

Thanks,
Narasimha.

[former_member182550]

Read my comment above.

Do you really want to increase the chances of corrupting your clients data ?

What happens when your commit is successful, but the commit in the transaction calling your function fails and rolls back ? Your changes will not be undone - they have been committed, however, the changes in the calling program have not been committed and will be rolled back leaving any records you have created as orphans. Then what do you do ????