Attributes and Variables | ||
---|---|---|
Previous | Next | |
SemQL Syntax | Using SemQL in Convergence for MDM |
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 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 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 calledUSER_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.
Variables are used with the following syntax:
:<variable_name>
, for example:
:USER_EMAIL
.
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
andCustomERName
do not represent the same attribute.
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 can be accessed using their Name.
Example:
FirstName
returns the value of the FirstName simple attribute of the current entity ( Employee).
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.
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 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 thePublisherID
(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.
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).
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.
Accessing child entities is possible
in conditions only using the SemQL
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' )
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' )
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
))
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
Previous | Top | Next |
SemQL Syntax | Using SemQL in Convergence for MDM |