BOPF and shared locks

[Former Member]

Hi everybody,

we are facing with a lock issue. Due to some requirements we need to set a shared lock on a BOPF instance.

In /BOBF/IF_CONF_C are the following edit modes defined:

• SC_EDIT_CHECK_OPTIMISTIC
• SC_EDIT_EXCLUSIVE
• SC_EDIT_OPTIMISTIC
• SC_EDIT_PROMOTE
• SC_EDIT_READ_ONLY
• SC_EDIT_SHARED

So far, so good. But in /BOBF/CL_TRA_SERVICE_MGR->/BOBF/IF_TRA_SERVICE_MANAGER~RETRIEVE we see the following restriction:

IF iv_edit_mode <> /bobf/if_conf_c=>sc_edit_read_only
 AND iv_edit_mode <> /bobf/if_conf_c=>sc_edit_optimistic
 AND iv_edit_mode <> /bobf/if_conf_c=>sc_edit_exclusive.
 set_application_error( ).
ENDIF.

Is it a bug or currently not supported?
... We are on NetWeaver 7.40 SP11 / SAP_BS_FND 747 0009

Cheers, Daniel

[former_member190794]

Hello Daniel,

shared locks are currently not supported. However, what is you use case? There should be also a different solution than using shared locks.

Best regards

Tilmann

[Former Member]

Hi Tilman,

thank you for your quick response. Our use case :

A fraud detection application checks invoices and – if a difference between the requested and the self-calculated amount is found – the invoice is assigned to a “clawback bundle”. From time to time this bundle is transmitted, i.e. it changes its state from “open” to “sent”. Afterwards no new assignments are allowed and a new open bundle must be created. During the assignment, transmitting is forbidden. Because there are thousands of invoices the checks and assignments are done in several parallel running processes. As long as at least one process is running no state change is allowed. So the solution was that each process set a shared lock on the bundle.

[former_member190794]

Hello Daniel,

there are different solutions possible, here is one.

I assume that the parallel processes do not modify the BO instances itself while executing the assignment:

Use an action validation on SAVE or a consistency validation contained in a save preventing consistency group. In this validation, you can implement a check, if the instance is assigned to a "sent" bundle and if a parallel process is transmitting the bundle at the moment (you could use an own separat enqueue object for that task that is locked/unlocked by the batch processes). In that case you prevent the save of the transaction by putting the IT_KEY into ET_FAILED_KEY of the validation implementation and raise an error message (e.g. "Modifications are not allowed due to assignment phase").

However to avoid that the user loses the already maintained data when he saves the transaction and gets angry, a property determination allows to inform him upfront by disabling all actions and modifications (so that all fields are displayed readonly). Thereto you can reuse the checking logic you have implementend in the validation. That validation is still required as some consumers might not care about properties at all (e.g. a different background job).

A further solution would be to redefine BOPF's locking behavior, however the solution above is more "standard" compliant.

Best regards
Tilmann