ABAP to the future - my version of the BOPF chapters - Part 1 Addendum: Other associations

[former_member182889]

8.1.4 Other associations

You have probably guessed that there are other ways of nodes being associated with each other than compositions. Let’s have a look at them as they kind of define the static structure of a business object model.

Modeled intra-BO-Associations

Nodes of the same business object might have more than one relationship. Above I wrote about heads of a monster which have a certain function or a specific feature.

These dedicated heads would still be heads (and not a separate  node in the model), but could be represented by an own association from ROOT to HEAD. There could be an association “preferred head” (with a cardinality 1) or “heads with hats” (with cardinality 0..*). As long as this can be expressed as a static restriction (with a “where-clause”), BOPF supports to model this association. Select the source node of the association and use the context-menu to create a new one.

Figure 7 - Basic properties of each association

While “cardinality” and “associated node” are easy to understand, the “resolving node” migt need an explanation: This information defines at which of the two nodes the information resides (as some kind of foreign attribute) which can be used in order to resolve the association. For unbound cardinalities, this usually is the target node, for cardinalities 1 this may be the source node.

The mapping of attributes between the nodes can be done on the “association binding” tab. But before we do that, we have to select a pattern (don’t just go and enter the binding straight ahead, the pattern is an essential model information, although unluckily not shown).

The following patterns are most common:

·         Specialization: The association selects a set of instances from the composition matching a particular, mostly static criterion

·         Foreign key-relation: There is an equality of some node attributes between the source and the target node. The association shall find the ones which match (just like a FK-relation in DB-tables). Note that in order to do this, an alternative key needs to be modeled at the resolving node. We’ll look at alternative keys later, keep in mind that the cardinality of the association and the alternative key need to match.

Let’s have a look at modelling a specialization:

Figure 8 - Using binding patterns to define the resolution of an association

We’ll select all the specialized heads which wear hats. Thus, in addition to the criterion that this node instance is a subnode-instance (PARENT_KEY = KEY), we’ll add a static filter criterion.

Figure 9 - Adding a constant binding for a specialization association

The filter value has to be taken from a constant interface. This is in general a good idea, I recommend to create one for your BO anyway containing all the domain values of the node’s attributes. Unluckily, BOPF does not support structured constants for filter variables, thus my constant interface looks like this:

Figure 10 - Only unstructured constants can be used for a constant binding

Modeled cross-BO-associations

Associations may also associated nodes from other business objects. In order to do this, a so-called “representation node” needs to be created. You can imagine this node being the anchor of the other bridge to the other business object in the source BO. With the representation node, BOPF automatically creates a Cross-BO-association with the same name for which you just have to provide a binding.

Only attributes on the target node can be used for binding in cross-BO-associations which are part of an alternative key. Consequently, the modeled association cardinality has to match the foreign key's uniqueness:

0..1 has to match a unique alternative key, 0..n a non-unique one.

There is a limitation with respect to the attribute binding: Foreign keys used in cross-BO-associations may only consist of a single attribute. Usually, this is the GUID containing the source node’s KEY.

Note: At runtime, these associations must be resolved using a service manager, not via the read-interface. Just keep this in mind, although you might not understand this sentence yet.

Implemented associations

For each association (no matter whether intra- or cross-BO), you can also provide an implementation (/BOBF/IF_FRW_ASSOCIATION) which is used for resolving the links between the source and target node. This should only be used if there’s no other option for expressing the relationship (e. g. if you need to join additional data to the target node in order to get it resolved or if the association is based on transient data).

From a consumption point of view, all of these associations behave equally. The consumer will not know whether an association is a modeled or implemented association. They all return pairs of source- and target-key.

> Find more alternative versions of chapters in my blogs.