Home > References
Inheritance and Value Resolution
Overview
The main idea behind inheritance is to mutualize resources that are shared by multiple contexts or entities. EBX.Platform offers several mechanisms for defining, factorizing and resolving Master Data values: standard inheritance , inherited attributes and functions .
Note that inheritance mechanisms that we describe in this chapter only concern instances (values and records). It should not be confused with "structural inheritance" that usually applies to models and that is proposed for example in UML class diagrams.
Standard Inheritance
Standard inheritance is particularly useful when Master Data has to be adapted to various global enterprise contexts, like subsidiaries or business partners.
Based on a hierarchy of adaptation instances , it allows to factorize common data on the root adaptation (or on intermediate ones) and to specialize (or adapt ) specific data to specific contexts.
Standard Inheritance mechanisms are detailed in the section below .
Specific Inheritance: Inherited Attributes
As opposed to standard inheritance (which exploits a global built-in relationship between adaptation instances), inherited attributes are able to exploit finer-grained dependencies that are specific to the Master Data structure. It hence allows to factorize and adapt Master Data at business entities level.
For example, if the model specifies that a Product is associated with a FamilyOfProducts, it is possible that some attributes of Product inherit their value from attributes defined in its associated family.
Formally speaking, the specific inheritance must be specified on terminal nodes at schema level. The lookup mechanism for such nodes is as follows:
-
If the value is locally defined, returns it (it can explicitly be
null). -
Otherwise, looks up the source record and value to inherit from, according to the
osd:inheritanceproperties that are defined on the schema. -
The process is recursive, if the source node does not locally define a value, it is further looked up, according to the inheritance behavior of the source node.
In order to define a specific inheritance directly on the schema, see the section below .
Computed Values (functions)
It is also possible to specify at schema-level that a node holds a computed value . In this case, the specified JavaBean function will be executed each time the value is requested.
The function is able to take into account the current context, for example values of the current record or computation from another table, and to request third-party systems.
For more information on functions, see section Computed Values .
Standard Inheritance
As described above, standard inheritance is based on a hierarchy of adaptation instances, the adaptations tree . This section's purpose is to precisely define standard inheritance mechanisms.
Basic standard mechanism for values
Formally speaking, the standard inheritance lookup mechanism for values is as follows:
-
if the value is locally defined, returns it (it can explicitly be
null); -
otherwise, looks up the first locally defined value according to the built-in child-to-parent relationship of adaptation instances in the hierarchy tree;
-
if no locally defined value is found, the schema default value is returned;
nullis returned if the schema does not define a default value.
Standard mechanism for records
Like values, table records can also be inherited as a whole by multiple contexts, but they can also be partially redefined ( overwritten ), be specific to a context ( root mode ) or even be occulted. More formally speaking, a table record has one of four distinct definition modes:
-
A root record is locally defined in the table and has no parent. This means that no record with the same primary key exists in the parent table, or that this parent is an occulting record.
-
An overwriting record is locally defined in the table and has a parent record. This means that a record with the same primary key exists in the parent table, and that this parent is not an occulting record. The overwriting record inherits its values from its parent, except for the values that it explicitly redefines.
-
An inherited record has a parent record but is not locally defined in the current table. All values are inherited (except functions which are always resolved in the current record context).
-
An occulting record specifies that if a parent with same primary key is defined, this parent will not be seen in table descendants.
Inherited Attributes [beta]
The specific inheritance mechanism allows to fetch the value of a node according to its relationship to other tables.
It is declared as follows:
<xs:annotation>
<xs:appinfo>
<osd:inheritance>
<sourceRecord>
/root/table1/fkTable2, /root/table2/fkTable3
</sourceRecord>
<sourceNode>color</sourceNode>
</osd:inheritance>
</xs:appinfo>
</xs:annotation>
</xs:element>
The element sourceRecord is an expression describing how to look up the record from which the value is inherited. It is a foreign key, or a sequence of foreign keys, that starts from the current element, up to the source table.
This expression is obtained through the hierarchy selector assistant (this assistant can be accessed from a table, menu "Perspectives...", item "Automatic hierarchies"), by clicking on the spanner on the right side:
If this element is not defined in the schema, the attribute to inherit from is fetched into the same record.
The element sourceNode is the path of the node to inherit from in the source record.
The following conditions must be verified for this kind of inheritance:
-
Element sourceNode is mandatory.
-
The expression to the source record must be a consistent path of foreign key(s), from the current element up to the source record. This expression must only involve 1-1 relations or 0-1 relations.
-
The source node must belong to the source table.
-
The source node must be terminal.
-
The source node must be writeable.
-
The source node type must be compatible with the current node type
-
The source node cardinalities must be compatible with the current node.
Home > References