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

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.

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.