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 to be exclusively available to the requesting session at this moment. The enqueueing and dequeuing as well as interpreting the lock-result is implicitly done by the framework at runtime. 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.
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.
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.
BOPF supports two different types of authority-checks out-of-the-box: Static and dynamic checks. 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 have the creator of a monster as an attribute relevant for authorizations. In our factory, multiple departments 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. 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 we said earlier, we could model that heads are validated with the same auth-object of the root with an wuthority-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.
<-- Back to the post covering the basic consumption of a BO using CRUD services