Image Added	ATTENTION: This page has been migrated to the Tazama GitHub repository and is now located at: https://github.com/frmscoe/docs/blob/main/Product/07-Creating-And-Maintaining-Processors/00-Introduction.md This page will no longer be maintained in Confluence.

Introduction

The Actio evaluation pipeline is intended to be largely configuration driven via external and centralised configuration files, as described in the diagram below:

...

The user stories for the creation and maintenance of the processors can be summarised in the following table:

Spoiler: Only the rule processors are actually discrete processors where there are many different rule processors. The Channel Router and Setup Processor, Typology Processor, Channel Aggregation and Desicioning Processor and the Transaction Aggregation and Decisioning processors are all universal in singular components (Highlanders)

...

...

[
    {
        "transactions": [
            {
                "id": "001@1.0.0",
                "host": "http://openfaas:8080",
                "cfg": "1.0.0",
                "messageId": "pain.001.001.11",
                "channels": [
                    {
                        "id": "001@1.0.0",
                        "host": "http://openfaas:8080",
                        "cfg": "1.0.0",
                        "typologies": [
                            {
                                "id": "001@1.0.0",
                                "host": "http://openfaas:8080",
                                "cfg": "028@1.0.0",
                                "rules": [
                                    {
                                        "id": "003@1.0.0",
                                        "host": "http://openfaas:8080",
                                        "cfg": "1.0.0"
                                    }
                                ]
                            },
                            {
                                "id": "001@1.0.0",
                                "host": "http://openfaas:8080",
                                "cfg": "029@1.0.0",
                                "rules": [
                                    {
                                        "id": "003@1.0.0",
                                        "host": "http://openfaas:8080",
                                        "cfg": "1.1.0"
                                    }
                                ]
                            },
                            {
                                "id": "002@1.0.0",
                                "host": "http://openfaas2:8080",
                                "cfg": "030@1.0.0",
                                "rules": [
                                    {
                                        "id": "003@2.0.0",
                                        "host": "http://openfaas2:8080",
                                        "cfg": "1.0.0"
                                    }
                                ]
                            }
                        ]
                    }
                ]
            }
        ]
    }
]

General

1. In general, an object in the network map is a collection of objects and attributes that provide the following information:

   1. Which processor is going to do the work (id and version)

   2. Where will the processor be hosted (processors may be deployed to different servers or locations for operational reasons)

   3. Which configuration will be used to “drive” the processor (id and version, or just version)

   4. (Optional) additional routing attributes (e.g. the ISO messageId in the transaction object)

   5. An array of the nested objects within the overhead object

2. Naming is intended to be as compact as possible to minimise the size of the payload for transmission between processors.

Transactions

1. At the root of the Network Map is a “transactions” array of transaction objects (“transactions”)

2. The transaction object contains the information that will allow the Channel Router and Setup Processor to route a transaction for evaluation and also to ultimately aggregate the evaluation results at the transaction level (by the Transaction Aggregation and Decisioning Processor)

   1. [transaction].id: The Transaction Aggregation and Decisioning Processor name (e.g. “001”) and version (e.g. “1.0.0”) separated by an “@”, i.e. “001@1.0.0”

      1. For the MVP, we will only deploy a single TADProc, named “001”. The MVP release version of the TADProc is expected to be “1.0.0”, but may have incremental versions of the processor leading up to 1.0.0 during the MVP development process.

      2. Each of our current transaction types will map to a different major version number:

         1. pain.001: 1.0.0

         2. pain.013: 2.0.0

         3. pacs.008: 3.0.0

         4. pacs.002: 4.0.0

      3. The MVP will only focus on pacs.002 evaluations.

      4. The design is intended to be flexible to allow for multiple concurrent variants and versions of the TADProc to be deployed in Actio.

   2. [transaction].host: the HTTP destination address of the Transaction Aggregation and Decisioning Processor that will conclude the evaluation for the transaction.

   3. [transaction].cfg: the version of the configuration that would drive the behaviour of the Transaction Aggregation and Decisioning Processor for the transaction.

      1. The config is intended to provide a final checkpoint for typology and channel results and is generally optional. For the MVP, the TADProc will evaluation typologies against set thresholds (as defined in the transaction config) to trigger investigations through the Case Management Solution).

   4. [transaction].messageId: the ISO 20022 message definition ID for the message that will be evaluated in the channels and using the typologies and rules defined in the Network Map under that transaction object.

Channels

1. Nested within each transaction object is an array of channel objects (“channels”)

2. The channel object contains the information that will allow the Channel Router and Setup Processor to route a transaction and also to ultimately aggregate the evaluation results at the channel level (by the Channel Aggregation and Decisioning Processor)

   1. [channel].id: The Channel Aggregation and Decisioning Processor name (e.g. “001”) and version (e.g. “1.0.0”) separated by an “@”, i.e. “001@1.0.0”

      1. For the MVP, we will only deploy a single CADProc, named “001”. The MVP release version of the CADProc is expected to be “1.0.0”, but may have incremental versions of the processor leading up to 1.0.0 during the MVP development process.

      2. The design is intended to be flexible to allow for multiple concurrent variants and versions of the CADProc to be deployed in Actio.

   2. [channel].host: the HTTP destination address of the Channel Aggregation and Decisioning Processor that will conclude the evaluation of the transaction for the channel.

   3. [channel].cfg: the version of the configuration that would drive the behaviour of the Channel Aggregation and Decisioning Processor for the transaction.

      1. The primary function of the channel config is to define the groups of typologies that would trigger a “proceed” message to the client system. This is not in scope for the MVP and the channel config version could be left blank (i.e. “cfg”: ““)

Typologies

1. Nested within each channel object is an array of typology objects (“typologies”)

2. The transaction object contains the information that will allow the CRSP to route a transaction and also to ultimately aggregate the evaluation results at the typology level (by the Typology Processor)

   1. [typology].id: The Typology Processor name (e.g. “001”) and version (e.g. “1.0.0”) separated by an “@”, i.e. “001@1.0.0”

      1. For the MVP, we will only deploy a single Typology Processor, named “001”. The MVP release version of the Typology Processor is expected to be “1.0.0”, but may have incremental versions of the processor leading up to 1.0.0 during the MVP development process.

      2. The design is intended to be flexible to allow for multiple concurrent variants and versions of the Typology Processor to be deployed in Actio.

   2. [typology].host: the HTTP destination address of the Typology Processor that will conclude the evaluation of the transaction for the channel.

   3. [typology].cfg: the version of the configuration that would drive the behaviour of the Typology Processor for the transaction.

      1. In our MVP design, the Typology Processor is a universal processing engine and a typology configuration could be considered the actual unique typology.

Rules

1. Nested within each typology is an array of rule objects (“rules”)

2. The transaction object contains the information that will allow the CRSP to route a transaction

   1. [rule].id: The Rule Processor name (e.g. “001”) and version (e.g. “1.0.0”) separated by an “@”, i.e. “001@1.0.0”

      1. The MVP release version of a Rule Processor is expected to be “1.0.0”, but may have incremental versions of the processor leading up to 1.0.0 during the MVP development process.

      2. The design is intended to be flexible to allow for multiple concurrent variants and versions of a Rule Processor to be deployed in Actio.

   2. [rule].host: the HTTP destination address of the Rule Processor that will conclude the evaluation of the transaction for the channel.

   3. [rule].cfg: the version of the configuration that would drive the behaviour of the Rule Processor for the transaction.

      1. The primary function of the channel config is to define the groups of typologies that would trigger a “proceed” message to the client system. This is not in scope for the MVP and the channel config version could be left blank (i.e. “cfg”: ““)

      2. We are not providing for two separate Rule Processors (different name@version ID’s) using the same configuration. Every rule configuration will be linked to a single rule processor ID. In other words, when a rule processor is updated with a new version, the rule configuration will be updated as well.

      3. Conversely, a rule config can be updated to a new version without issuing a new rule processor or version.