Skip to Content

ABAP to the future – my version of the BOPF chapters – Part 3: Locking and authorization management

8.2.3 Locking

The manipulating services we’ve been talking about in the previous chapter of course require the business object which we’re accessing to be locked – precisely it’s the BO node instance which requires being exclusively available to the requesting session at this moment. The enqueue and de-queue as well as interpreting the lock-result is implicitly done by the framework at runtime. Unfortunately, changing the locking options is not supported by SAP, so it’s not possible to model the options in BOBX, but we can see the default-option in the Conf-UI (which is not supported for custom development). Anyway: You as a developer don’t really need to worry about it, but it is of good use to know how it works in general. Each node is – theoretically – separately lockable. This means that multiple sessions can manipulate different subnode node instances of the same root instance. You can imagine a monster factory where one department attaches the heads and another one was responsible for the extremity-design while the management is responsible to define which monsters (root node instances) exist. If this was your business, you could simply model the head and the extremity node separately lockable and – if the UI permits a local edit – multiple persons could edit heads and extremities of the same monster. All the subnodes which are not separately lockable are being logically locked along with the next-level lockable parent. Assuming that FINGER is a subnode of EXTREMITY, but FINGER is not separately lockable, a consumer adding a finger to an extremity would require a lock on the extremity-instance.

By default, only the root-node is separately lockable.


Figure 24 – A BO node in the Conf-UI: BOPF supports multiple lock-shadows, but changing the setting is not supported.

You have to use the defaults: Subnodes are not seperately lockable.

For the curious ones: You can enable visibility of the technical entities responsible for locking in the display-options of the Conf-UI (Utilities -> Settings):


Figure 25 – The model entities responsible for locking made visible on the Conf-UI


Figure 26 – Technical entities used by the framework for locking – visible only on the Conf-UI.

8.2.4 Authorizations

Another technical thing which happens implicitly when interacting with a BO is authorization handling. This latest BOPF feature allows to model which authority object guards the interactions with a BO node. It is similar to locking with respect to the hierarchical interpretation of the modeled auth-objects: If a parent node has an authority object attached but the subnode does not, the authorizations of accessing the parent node are validated.


Figure 27 – The business object itself needs to be flagged as authorization relevant


Figure 28 – Each node with an own auth. object needs to be flagged to have own checks

As soon as you defined that a BO shall have authority checks, you may define one or multiple auth-objects at a BO node. The auth-object kind of defines a set of nodes with the same target usergroup. If multiple objects are modeled, all authority-checks need to pass in order to grant the desired access.

The authority field ACTVT has to be part of the auth-object definition and BOPF will determine the necessary value at runtime. In addition, BOPF will pass the action name on executing an action as well as the query name in the case of executing a query to the field BO_SERVICE in order to allow fine-grained roles (obviously, your security guy has much more to do maintaining the roles than the developer “implementing” the auth-validations). ACTVT and BO_SERVICE are compulsory for each auth-object-definition which is used within BOPF.


Figure 29 – Definition of an authority object guarding access to a BOPF instance with static and instance-based authority fields.

BOPF supports two different types of authority-checks out-of-the-box: Static and dynamic checks. Static checks validate the access-mode on a particular node.


Figure 30 – Assigning an auth.-object to a node for static authorization checks (ACTVT, BO_SERVICE)

When executing dynamic checks, additional authority fields which are checked based on the value of an attribute of a node instance exist. For example we could imagine the creator of a monster as an attribute relevant for authorization: In our factory, multiple departments could exist, each handling the monsters of a dedicated creator. Thus, at runtime, the value of creator needs to be read and the authority-check has to compare the instances value with the allowed value from the role-definition.


Figure 31 – Mapping a node attribute to the auth. field for instance based checks.

BOPF does all this data-retrieval for you after you modeled the auth-attribute-mapping. It even supports the relevant attribute being located at an associated node: Assuming that heads were separately lockable as I wrote earlier, we could model that heads are validated with the same auth.-object of the root with an authority-field-mapping based on the CREATOR which can be retrieved via the association TO_PARENT.

Funky, isn’t it? And the best part of it: You don’t need to write a single line of code in order to make this work, independent of which consumer you’ve got. And if your authorization logic is even more “sophisticated”, you are always free to define an own authorization class which implements your very custom authorization concept.

> Find more alternative versions of chapters in my blogs.

You must be Logged on to comment or reply to a post.
  • Hi Oliver,

    Thanks for your post.

    Is it possible to control specific columns of a node by this. For example, only users with authority object ZZZZ are allowed to change column A, B, C. Users without this object would not allowed to change the values of columns A, B,C.

    Thanks very much!

    • Dear Chris,

      as per BOPF's designtime-environment, there is no possibility to model field-based properties.

      However, the actual AUTHORITY-CHECK-statement is performed inside the library which you can seen in figure 27. You are free to inherit from this class and implement field-based properties based on the result of authorizations there.

      If you do this in your project, I recommend to have a common superclass for nodes which shall have this feature which has a hook-method.

      This way, you could easily implement a generic property-determination (or even validation) without messing your application code up with AUTHORITY-CHECK-statements:

      Custom auth class

      2015-11-19 11_36_20-ABAP - Global Class ZCL_PRI_LIB_AUTHORITY_CHECK [A05] - Aktiv, Gesperrt - A05_00.png

      Property determination

      2015-11-19 11_54_39-ABAP - A05_001_db1695e_en - Eclipse Platform.png

      2015-11-19 11_56_57-ABAP - A05_001_db1695e_en - Eclipse Platform.png

      2015-11-19 12_08_09-ABAP - Global Class ZCL_PRI_AUTH_DEPENDENT_PROP [A05] - Aktiv, Gesperrt - A05_00.png2015-11-19 12_09_41-ABAP - Global Class ZCL_PRI_AUTH_DEPENDENT_PROP [A05] - Aktiv, Gesperrt - A05_00.png

      Understandable? Helpful?



      • Hi Oliver,

        Thanks for your quick response.

        I just finished a simple demo by following your steps, it works perfectly.

        Thanks you so much for your fabulous solution. You are so altruistic.

        Thanks and Regards,

        Chris Xu

        • Hi Chris,

          most welcome! Just one note on the solution provided: The part which is visible on the screenshots is only responsible for setting properties. As you know (if you read my series of blog-posts), properties are only optional for the consumer to interpret, they don't prevent the change (if the consumer does not respect them). If you want to be on the safe side, you should implement an additional action validation on create and update. The validation's class could inherit from the authorization class and use common code which resides in a protected method of the superclass.



          P.s.: There is no altruism - only a community.

          • Hi Oliver,

            Thank you for your reminder.

            Just made several lines of code to test this, you are right absolutely. Consumer can ignore the property setting without any error or warning. I will try to implement your additional steps of action validation.

            Thank you again for your solution. 🙂

            Thanks and Regards,

            Chris Xu

  • Hi Oliver,

    Thank you very much for providing this blog.

    I have a query regarding locking concept in Business Objects(BO). Lets consider I have two BOs (say BO1 & BO2). Is there any possibility to lock one BO(here BO2) while editing the other BO (BO1)? Can you please provide us some information on this.



  • Dear Siva,

    there is no in-built mechanism for cross-object-locking.

    However, you can define your custom locking-class: For each lockable node, there is a technical action LOCK_<node>. Inheriting from the provided lock-class, you can lock a different business object by retrieving a second business object with edit mode exclusive. Triggering the other node’s lock action will not work, as this is an (internal) framework-action.

    However, I just noticed that the lock-action is not visible neither in transaction BOBX nor in Eclipse, but only in BOBF. Thus, this feature is currently not officially supported for customers.

    I attached some screenshots from BOBF for illustration purposes, please don't modify your BO via BOBFas you're losing support if you do.



    You might create a support message requesting this feature or hope that someone of the BOPF-team reads this post ?

    In the meantime, I'd recommend to make the consumer lock both objects, if you can mange it.

    Cheers, Oliver