Attributes and Variables

Variables

Variables store values that are integration job-specific or user session-specific. Variable are either Built-in Platform Variables, or Model Variables.

Built-in Platform Variables

Built-in Platform Variables are built-in the platform. They are described below:

Variable Name Definition
V_DATABRANCH For the certification process, the data branch number where the integration runs. For a user data session, the data branch number to which this user connects to.
V_DATAEDITION For the certification process, the data edition (version) number where the integration job runs. For a user data session, the data edition number to which this user connects to.
V_USERNAME For the certification process, name of the user who has submitted the integration job. For a user data session, the name of the connected user.

Model Variables

Model Variables are available in user sessions, for example when the user accesses a data location via an application. They are derived from built-in platform variables.

Model variables are typically retrieved from remote servers (which are declared as Variable Value Providers). Variable values are local to each user session, and are refreshed when the user accesses Semarchy Convergence for MDM. Model variables can be used in SemQL filters and expressions created at design and run-time to adapt the experience to the connected user.

Example: Using the built-in platform variables V_USERNAME, it is possible to query (via a Variable Value Provider definition) the corporate LDAP directory and retrieve the email of the connected user, and then store this value in a model variable called USER_EMAIL.

Note: For more information about Model Variables, see the Model Variables section in the Logical Modeling chapter of the Semarchy Convergence for MDM Developer’s Guide. For more information about Variable Value Providers, see the Configuring Variable Value Providers in the Semarchy Convergence for MDM Administration Guide.

Using Variables

Variables are used with the following syntax: :<variable_name>, for example: :USER_EMAIL.

Attribute Qualified Names

A Attribute Qualified Name is the “path” to an attribute from the current entity being processed.
This path not only allows accessing the attributes of the entity, but also allows access to the attributes of the entities related to the current entity.

Note: In this section, Name always refers to the (internal) Name of an attribute, and not to the Label. The label may be translated in various languages, but the name is invariant.

Important: Attribute names are case sensitive . For example customerName and CustomERName do not represent the same attribute.

Using Current Entity’s Attributes

A given SemQL clause is expressed for a given entity. For example, an enricher, a validation or a filter is performed on a pre-defined entity. Such a clause always has access to the attributes of this entity. These attributes may be simple of complex attributes.

Simple Attributes

Simple attributes can be accessed using their Name.

Example: FirstName returns the value of the FirstName simple attribute of the current entity ( Employee).

Complex Attributes

Display Name

Complex attributes can be accessed using their Attribute Name. This returns the value of the complex attribute in the format of the corresponding complex type’s Display Name.

Example: The SimpleAddressType complex type is defined with a display type that shows the Address, City and Country definition attributes separated by a space. This type is used for the InputAddress attribute of the Custome entity. The InputAddress qualified name therefore returns a string containing <Address> <City> <Country> value for each Customer.

Definition Attribute

It is also possible to retrieve the value of each definition attribute of a complex type by prefixing this definition attribute name by the name of the complex attribute.

Example: The SimpleAddressType complex type includes the Country definition attribute. This type is used for the InputAddress attribute of the Custome entity. The InputAddress.Country qualified name therefore returns the Country stored in the InputAddress complex type value for each Customer.

Built-in Attributes

Built-in attributes are provided by Convergence for MDM to support the certification process. They appear in addition to the attributes designed in the data model. The available attributes depending on the location of the SemQL expression.

Example: For example, a clause that involves source data (for example, an enricher) will support built-in attributes such as the SourceID (ID of the source record) or the PublisherID (Code of the application that published the source record). On Golden Records – which are not directly related to one source – these built-in attributes no longer make sense.

Note: For more information about the built-in attributes, refer to the Integration Job chapter of the Semarchy Convergence for MDM Integration Guide.

Using Related Entities' Attributes

Related entities may be either parent entities (for a given relation, the current entity has zero or one parent), or child entities (for a given relation, the current entity has zero or more children).

Parent Entities

It is possible to access attributes of a parent entity by prefixing this attribute by the Role of this parent in the relation.

Example: The current Customer entity references the Employee entity in a relation. In this relation, the Role of this second entity is AccountManager. The AccountManager.FirstName attribute refers to the FirstName of the Employee that is the parent – in this relation, the AccountManager - of the current Customer.

Referring to parent entities can follow a chain of relations.

Example: AccountManager.CostCenter.CostCenterName follows two relations to return the CostCenterName of the CostCenter to which the AcountManager of the current Customer reports to.

Child Entities

Accessing child entities is possible in conditions only using the SemQL any and all syntax.

Any and All Syntax

The any syntax is a condition that returns true if any of child records meet the given condition.

any <child_entity_role> have (	<condition_on_child_entity> )

Example: To filter Customers having at least one Contact named “John”: any Contacts have ( FirstName = 'John' )

The any syntax is a condition that returns true if all the child records meet the given condition.

all <child_entity_role> have (	<condition_on_child_entity> )

Example: To filter Customers having all their Contacts with the IsInfluencer flag set to ‘0’ : all Contacts have ( isInfluencer = '0' )

Cascading References

It is possible to cascade through several relations' roles.

Example: To filter Employees managing Customers having one contact with the IsInfluencer flag set to ‘1’: any Customers.Contacts have ( IsInfluencer = '1' )

ParentRecord

In the Any and All syntax, it is possible to access the direct parent’s record from the condition on the child entity, through the ParentRecord reserved keyword or through the parent’s role name in the relation.

Example: The following condition returns all the customers having two contacts with a different ContactID but the same FirstName.

any Contacts have (
any ParentRecord.Contacts have (
ParentRecord.ContactID != ContactID
and ParentRecord.FirstName = FirstName
))

Attributes of Duplicates

Certain SemQL expressions manipulate two records simultaneously:

For these expressions, the two records are identified by the RECORD1 and RECORD2 prefixes.

Example: The following condition returns the duplicates with the same InputAddress.Address (complex type) but a different CustomerName Record1.CustomerName <> Record2.CustomerName AND Record1.InputAddress.Address = Record2.InputAddress.Address