Skip to Content
avatar image
Former Member

BOPF and shared locks

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

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Best Answer
    Oct 27, 2015 at 04:32 AM

    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

    Add comment
    10|10000 characters needed characters exceeded

    • 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