...
In this document, we will discuss how the various configuration documents are expected to be updated to influence evaluation behavior.
2.
...
Configuration Management
Configuration documents are essentially files that contain a processor-specific configuration object in JSON format. The recommended way to upload the configuration file to the appropriate configuration database and collection is via Arango DB’s HTTP API that is deployed as standard during platform deployment.
2.1. Rule Processor Configuration
2.1.2. Introduction
A rule processor is a custom-built module that evaluates an incoming message according to its code. When a new rule processor is developed, the rule designer will specify both the input parameters for the rule, as well as the output results. Changes to these attributes can alter a rule processor’s behavior and it is expected that these attributes are hosted in the rule configuration so that the rule processor behavior can be altered by updating the configuration instead of changing the rule processor code.
A rule processor configuration document typically contains the following information:
Rule metadata, for example:
| Code Block |
|---|
{
"id": "003@1.0.0",
"cfg": "1.0.0",
"desc": "Account dormancy - creditor"
} |
A config object, that may contain parameters, for example:
| Code Block |
|---|
"config": {
"parameters": {
"maxQueryRange": 86400000,
"tolerance": 0.1
}
} |
The config object may contain a number of exit conditions, for example:
| Code Block |
|---|
"config": {
"exitConditions": [
{
"subRuleRef": ".x00",
"outcome": false,
"reason": "Incoming transaction is unsuccessful"
},
{
"subRuleRef": ".x01",
"outcome": false,
"reason": "Insufficient transaction history"
}
]
} |
The config object will also contains either result bands, for example:
| Code Block |
|---|
"config": {
"bands": [
{
"subRuleRef": ".01",
"lowerLimit": 0,
"upperLimit": 18,
"outcome": true,
"reason": "The debtor is younger than 18 years old"
},
{
"subRuleRef": ".02",
"lowerLimit": 18,
"upperLimit": 30,
"outcome": true,
"reason": "The debtor is 18 years or older and younger than 55 years of age"
},
{
"subRuleRef": ".04",
"lowerLimit": 50,
"outcome": true,
"reason": "The debtor is 55 years or older"
}
]
} |
or alternatively result cases, for example:
| Code Block |
|---|
"config": {
"parameters": {},
"exitConditions": [],
"cases": [
{
"subRuleRef": ".00",
"outcome": false,
"reason": "The transaction type is not defined in this rule configuration"
},
{
"subRuleRef": ".01",
"value": "MP2B",
"outcome": true,
"reason": "The transaction is identified as a Mobile P2B Payment"
},
{
"subRuleRef": ".02",
"value": "MP2P",
"outcome": true,
"reason": "The transaction is identified as a Mobile P2P Payment"
},
{
"subRuleRef": ".03",
"value": "CASH",
"outcome": true,
"reason": "The transaction is identified as a general cash management instruction"
}
]
} |
3. Version Management
3.1. Introduction and Basics
Each configuration document in the platform can be assigned a unique semantic version that will identify one instance of a configuration document as distinctly separate from another instance of the same configuration document.
...
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes
...
3.2. Configuration version management of processors
Every rule processor, typology processor and transaction aggregation and decisioning processor (TADProc) is guided by its own configuration document. The specific version of a configuration document that is required to operate a processor is defined in the network map when the evaluation routing is specified. When a processor receives an instruction from its predecessor in the evaluation flow, the processor checks the network map to determine which configuration document and version to use to perform its tasks.
...
Once a configuration document has been created or updated and uploaded to the configuration database, the configuration is ready to be used, but not in use yet. To activate a new configuration (or version), the configuration must be linked to the processor in the network map.
...
3.3. The Network Map
The network map defines the routing of an incoming transaction to all rules and typologies that are required to evaluate the transaction7. By default, the platform is configured to evaluate a pacs.002 transaction that concludes a transaction initiated from a pain.001 or pacs.008 message with a status response.
...