Build the NATS route from the network map

[Justus-at-Tazama]

Story statement

As an Tazama platform operator,
I want the routing between the processors constructed according to the network map,
So that the routing is configurable via the network map and not via environment variables embedded into the processors

Acceptance criteria

1. Use information from the network map to define publisher and subscriber subjects.
2. For the Event Director:
   a. use the id attribute for each rule processor in the network map with a sub- prefix, e.g. sub-001@1.0.0. The Event Director can retrieve this information from the network map at runtime and does not need to establish the routing up-front.
   b. When the Event Director is deployed/started/restarted, it must set up its own subscription subject (ed) to which the TMS API publishes.
3. For the rule processors:
   a. Use the rule processor's id attribute from the network map with a sub- prefix for the subscriber subject and a pub- prefix for the publisher subject, e.g. sub-001@1.0.01 and pub-001@1.0.0.
   b. When the rule processor is deployed/started/restarted, it must set up its own subscription subjects to which the Event Director will publish and publishing subjects to which the typology processor will subscribe.
4. The typology processor is an aggregating processor and is not explicitly addressed in the routing from the rule processors (rule processor publish to their own subject).
   a. The typology processor must subscribe to the rule publisher subjects. The typology processor must read the current active network map to determine what all the rule subjects are (each unique rule id with a "pub-" prefix).
   b. The typology processor must also extend the pattern established by the rule processors: publishing to a single subject per typology. The publishing subject for each typology must be the typology identifier (the cfg attribute from the network map) with a "typology-" prefix, e.g. typology-001@1.0.0.
   c. When the typology processor is deployed/started/restarted, it must subscribe to all the rule subjects based on the current active network map to receive rule results and it must set up its own typology-specific publishing subjects to which the typology processor will publish and to which the TADProc will subscribe.
   d. Where interdiction is required, the typology processor must also publish typology results to the cms subject.
5. Typology results will be published to individual typology subjects and collected directly by the TADProc where the typology results will be organised as defined in the network map.
6. The TADProc is also an aggregating processor, but either the typology processor or the TADProc needs a related subject to handle the routing between the two. In our current design, that responsibility rests with the TADProc. Going forward, the typology processor will publish typology results to individual typology subjects and the TADProc must subscribe to each of the typology subjects as created by the Typology Processor based on the network map.
   a. From the TADProc's perspective, the subject for each typology must be the typology identifier (the cfg attribute from the network map) with a "typology-" prefix, e.g. typology-001@1.0.0.
   b. When the TADProc is deployed/started/restarted, it must subscribe to all the typology subjects based on the current active network map to receive typology results and it must set up the publishing subject for the Case Management Integration (cms) to which the TADProc will publish and to which the CMS will subscribe.

Side-note: in a production context it is expected that a processor will be deployed with a specific code version that is reflected as part of the processor id. By using the version as part of the routing, we can ensure that the network map appropriately addresses a new version of a processor and is also even able to address multiple different versions of the same processor deployed in parallel. In the long run, it would make sense to "name" the rule processor after the repository where the code is source-controlled, e.g. "id": "rule-001@1.2.0" or even with the specific commit hash: "id": "rule-001@8820d6c".

[Justus-at-Tazama]

Clarification: How should the platform behave when there are multiple transactions defined in the network map?

Let's say the Event Director gets a pain.001, and then sends that to all the rules defined in the network map using the subjects that the rule processors created, the rule processors will then send the transaction to all the rule subjects that the rule processors also created and then the typology processor will pick up the rule results from all the rule processors it is subscribed to, but it will have to subscribe to ALL the rule processors linked to that typology processor in the network map, even if the specific typology for that specific transaction does not actually need that rule result.

The typology processor would also need to subscribe to all the rule subjects regardless of the transaction in which they reside. The subscription muse be informed by the entire network map, and not just the part relating to a specific transaction.

The same thing must happen in the TADProc. The typology processor publishes to the typology subjects defined in the network map and the TADProc must subscribe to all of them, regardless of transaction.

Effectively, the transaction distinction has no influence on the typology and TADProc subscriptions.

[cshezi]

Startup Library changes blocked Typology Processor changes: Wait till 04/12/2023