Sometimes developers need to include attributes with a common behaviour in transactions. For example, the developer may wish to include attributes to log the user that created or modified a record, or the time when that happened.
When these attributes have to be included in several transactions, the developer must replicate the logic for those attributes in each transaction. Basically, the rules associated with each attribute must be copied and adapted to each transaction.
This process can be automated by defining “Automatic rule templates” in the Entity Services pattern configuration as a child of "Transaction" node. To define a rule the developer must specify the criteria that an attribute must meet for that rule to apply to it, and a template for the rule that should be generated.
|
Adding an Automatic Rule |
A rule is defined by these properties:
-
Name: This is the rules identifier. It can only contain letters, numbers, and underscores, and must begin with a letter.
-
Description: This is a developer-friendly description that should describe the rule’s logic.
-
Name Match Regex: This property allows the developer to define a regular expression. The regular expression defined in this property will be matched against the attribute name to determine if the attribute should be considered for the rule.
This property can be left empty.
-
Domain: If set, this property will be compared to the attribute’s “Based On” property to determine if the attribute should be considered for the rule.
This property can be left empty.
-
Rules template: This property contains a text template used to generate rules for matching attributes.
Automatic rules are processed after applying the Entity Services pattern. At this point, the automatic rule templates are loaded from the pattern’s settings.
The developer can use the “Ignored Rule Templates” property located in the Transaction node to disable rule templates for each transaction. The templates specified in this property are not processed.
|
Ignore Template Rules |
The remaining rule templates are processed, comparing the criteria defined with the attributes in the transaction. An attribute is considered a match for a rule if:
-
The attribute is not inferred.
-
The template’s “Domain” property is empty or equal to the attribute’s “Based On” property.
-
The template’s “Name Match Regex” property is empty or it matches the attribute’s name.
If the attribute is considered a match for the rule, the rules are generated using the Template replace rules logic.
To generate the final rules, some placeholders are replaced by the attribute’s and transaction’s properties. The available placeholders are:
-
<AttName>: Will be replaced by the attribute’s name.
-
<AttDescription>: Will be replaced by the attribute’s description.
-
<TrnName>: Will be replaced by the transaction’s name.
-
<TrnDescription>: Will be replaced by the transaction’s description.
Property
|
Value
|
Name
|
CreationUser
|
Description
|
This templates adds rules to store the creation user
|
Name Match Regex
|
(.*)CreationUserCode
|
Domain
|
(none)
|
Rules template
|
<AttName> = &Context.UserCode if insert;
|
Suppose that an “Invoice” transaction contains the “InvoiceCreationUserCode” attribute. In that case, the attribute would be considered a match for this rule (as the name matches the regular expression), leading to the generation of this rule:
InvoiceCreationUserCode = &Context.UserCode if insert;
Property
|
Value
|
Name
|
LastUpdateTime
|
Description
|
This templates adds rules to store the last update time
|
Name Match Regex
|
(.*)LastUpdatedAt
|
Domain
|
(none)
|
Rules template
|
<AttName> = servernow() if insert or update;
|
Suppose that an “Invoice” transaction contains the “InvoiceLastUpdatedAt” attribute. In that case, the attribute would be considered a match for this rule (as the name matches the regular expression), leading to the generation of this rule:
InvoiceLastUpdateTime = servernow() if insert or update;
|