Merge pull request #91 from frmscoe/dev

Release team demo

Author: scott45

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,8 +1,12 @@
+# SPDX-License-Identifier: Apache-2.0
+
 ## What did we change?
 
 ## Why are we doing this?
 
 ## How was it tested?
 - [ ] Locally
 - [ ] Development Environment
-- [ ] Not needed, changes very basic
+- [ ] Not needed, changes very basic
+- [ ] Husky successfully run
+- [ ] Unit tests passing and Documentation done

Community/Tazama-Contribution-Guide.md

@@ -160,7 +160,7 @@ From a DevOps perspective, we make use of the following tools:
  - [Mermaid.js](http://mermaid.js.org/#/) for markdown-embedded diagrams in GitHub
  - [Atlassian Confluence](https://www.atlassian.com/software/confluence) is (currently) hosting our project documentation at <https://frmscoe.atlassian.net/wiki/spaces/FRMS/overview>
  - [PlantUML](https://plantuml.com/) for embedded diagrams in Confluence
- - [Drawio](https://www.drawio.com/) for embedded diagrams in GitHub
+ - [Drawio](https://www.drawio.com/) for embedded diagrams in GitHub. See [guide for draw.io](/guides/drawio-guide.md)
 
 [Top](#contribution-guide)
 
@@ -384,7 +384,7 @@ Follow the steps below to get the `Rule Executer` on your operating table:
 
 8. Sending messages to the microservice processor via the NATS REST Proxy
 
-    Let's try to send a test message to our locally running CRSP via the NATS REST Proxy using a pre-fabricated Postman test. If you previously cloned the Postman repository, the `Rule-901-Quick-Check.postman_collection.json` test will be located in the Postman repository folder.
+    Let's try to send a test message to our locally running Event Director via the NATS REST Proxy using a pre-fabricated Postman test. If you previously cloned the Postman repository, the `Rule-901-Quick-Check.postman_collection.json` test will be located in the Postman repository folder.
     
     Because the application is running in our previous Windows Command Prompt, we'll need to open a new one and then, using the following Newman command in the new Command Prompt, we can execute the test on our running processor:
 
@@ -428,7 +428,7 @@ Read the [Product Overview](/README.md) for a detailed overview of the system.
 The Project organization on GitHub contains both PUBLIC and PRIVATE repositories. Core components of the system are in public repositories that are accessible to anyone:
 
  - The Transaction Monitoring Service (TMS) API
- - The Channel Router and Setup Processor (CRSP)
+ - The Event Director (ED)
  - The Rule Executor (the rule processor wrapper function)
  - Rule 901, a sample rule
  - The Typology Processor
@@ -454,14 +454,12 @@ flowchart TB
   F -->|Push| G[5. Create Pull Request]
   G -->|Review| H[6. Code Review]
   H -->|Approve| I{7. Merge PR}
-  I -->|Merge to Main| J[8. Close Issue]
+  I -->|Merge to Dev| J[8. Close Issue]
   J --> K[9. Deploy to Production]
   K --> L[10. Monitor & Feedback]
   H -->|Request Changes| D
 ```
 
-1. Fork the repository you want to work on
-
 [Top](#contribution-guide)
 
 ## 5. Making and Submitting Contributions
@@ -487,6 +485,8 @@ Best practices for making changes.
 
 **Code Documentation** – Electronic documentation has been auto-generated (where available) and has been checked for correctness. Also have sufficient code comments. [Developer] + [PR Approver]
 
+**Licensing comment** Add the following string as a comment ("SPDX-License-Identifier: Apache-2.0") at the top of every file in the organisation in GitHub that is capable of including a comment i.e. extensions="ts" "js" "env" "template" "eslintignore" "yaml" "properties" "npmrc" "editorconfig" "dockerignore" "gitignore" "prettierignore" "md" "helmignore" "Makefile" "sh" "npmignore" "plantuml" "yml" 
+
 **\*Release Notes / Version Control** - TODO Aaron - figure out what greater ML does - check this
 
 **Code Refactoring** - Source code has been refactored to make it comprehensive, maintainable and amenable to change (*unless agreed otherwise as part of refactoring existing legacy code). [Developer]

Guides/drawio-guide.md

@@ -0,0 +1,51 @@
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+- [Introduction](#introduction)
+- [Tazama Template](#tazama-template)
+- [Create and Update diagrams in draw.io](#create-and-update-diagrams-in-drawio)
+- [Embed diagrams in markdown files](#embed-diagrams-in-markdown-files)
+
+## Introduction
+
+This guide will take you through the steps to embed a Draw.io diagram into a markdown file.
+
+For the purposes of this guide, I am using a folder \\\GitHub\docs which you can copy by cloning the `docs` repository to a GitHub folder in your local environment
+
+![draw.io clone docs repo](../images/draw.io-clone-docs-repo.png). 
+
+In the example in this guide, the location images for this repository were saved here
+
+![draw.io start](../images/draw.io-folder.png). 
+
+## Tazama Template
+
+The Tazama template with the color palette and font can be found the location \\\GitHub\docs\files\templates\Tazama-template.drawio.png 
+Copy the file from your local location where you cloned the docs repository to your preferred working file location.  ![Tazama-template.drawio.png](../files/templates/Tazama-template.drawio.png).   
+
+**1. Access the website https://www.drawio.com/ and click on `Start` button.**
+
+![draw.io start](../images/draw.io-start-button.png).  
+
+**2. Select `Open Existing Diagram` and find the Tazama template file you just saved**
+
+![draw.io create new diagram](../images/draw.io-create-new-diagram.png)
+
+[Top](#introduction)
+
+## Create and Update diagrams in draw.io
+
+**3. Save the file and export to svg format**
+
+![draw.io export svg](../images/draw.io-export-svg.png)
+
+**4. click Export**
+
+![draw.io svg export button](../images/draw.io-svg-export-button.png)
+
+**5. click Save**
+
+![draw.io save as svg ](../images/draw.io-save-as-svg.png)
+
+## Embed diagrams in markdown files
+
+![draw.io embed diagram in markdown](../images/draw.io-embed-diagram.png)

Product/configuration-management.md

@@ -36,11 +36,6 @@
   - [3.1. Introduction and Basics](#31-introduction-and-basics)
   - [3.2. Configuration version management of processors](#32-configuration-version-management-of-processors)
   - [3.3. The Network Map](#33-the-network-map)
-- [References](#references)
-- [Ref 1](#ref-1)
-- [Ref 2](#ref-2)
-- [Ref 3](#ref-3)
-- [Ref 4](#ref-4)
 
 # TL;DR
 
@@ -60,7 +55,7 @@ Configuration documents can be uploaded to the system using the ArangoDB API dep
 
 [Top](#configuration-management)
 
-# 1\. Overview of the detection methodology
+# 1. Overview of the detection methodology
 
 The core detection capability within the system is distributed across three distinct steps in the end-to-end evaluation flow.
 
@@ -105,7 +100,7 @@ In this document, we will discuss how the various configuration documents are ex
 
 [Top](#configuration-management)
 
-# 2\. Configuration Management
+# 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 (`networkMap` or `configuration`) and collection is via ArangoDB’s HTTP API that is deployed as standard during system deployment.
 
@@ -235,7 +230,9 @@ Each exit condition contains the same attributes:
 | **Attribute** | **Description** |
 | --- | --- |
 | `subRuleRef` | Every rule processor is capable of reporting a number of different outcomes, but only a single outcome from the complete set is ultimately delivered to the typology processor. Each outcome is defined by a unique sub-rule reference identifier to differentiate the delivered outcome from the others and also to allow the typology processor to apply a unique weighting to that specific outcome.<br><br> By convention, the exit condition sub-rule references are prefaced with an 'x'. |
-| `reason` | The reason provides a human-readable description of the result that accompanies the rule result to the eventual over-all evaluation result. [Reason descriptions will be refined during future enhancements](#Ref 1) |
+| `reason` | The reason provides a human-readable description of the result that accompanies the rule result to the eventual over-all evaluation result. Reason descriptions will be refined during future enhancements[^1] |
+
+
 
 #### The `.err` exit condition
 
@@ -303,7 +300,7 @@ Each rule result band contains the same information:
 | `subRuleRef` | Every rule processor is capable of reporting a number of different outcomes, but only a single outcome from the complete set is ultimately delivered to the typology processor. Each outcome is defined by a unique sub-rule reference identifier to differentiate the delivered outcome from the others and also to allow the typology processor to apply a unique weighting to that specific outcome.<br><br> We have elected to assign a numeric sequence to the sub-rule references for result bands, prefaced with a dot (“.”) separator, but this format is not mandatory for the sub-rule reference string. Any descriptive and unique string would be an acceptable sub-rule reference. |
 | `lowerLimit` | This attribute defines the lower limit of the band range and is evaluated inclusively (`>=`).<br><br> Where a lower limit is not provided, the rule processor will assume the intended target lower limit is -∞. Unless the very first result band in a configuration has a clear and unambiguous lower limit, it is often omitted. |
 | `upperLimit` | This attribute defines the upper limit of the band range and is evaluated exclusively (`<`).<br><br>Where an upper limit is not provided, the rule processor will assume the intended target upper limit is +∞. Unless the very last result band in a configuration has a clear and unambiguous upper limit, it is often omitted. |
-| `reason`| The reason provides a human-readable description of the result that accompanies the rule result to the eventual over-all evaluation result. [Reason descriptions will be refined during future enhancements](#Ref 1)|
+| `reason`| The reason provides a human-readable description of the result that accompanies the rule result to the eventual over-all evaluation result. Reason descriptions will be refined during future enhancements[^1]|
 
 One of the most frequent limit values in use in the system is based on time-frames. In the system, all time-frames and associated limits are represented in milliseconds. The following table reflects the conventional milliseconds for different time terms in our configurations:
 
@@ -356,7 +353,7 @@ Each rule result case contains the same information:
 | --- | --- |
 | `value` | This attribute defines the specific value that will be matched in the rule processor (`=`).<br><br>Every case contains a value, with the exception of the default “else” case.<br><br>Values can be either strings, encapsulated in quotes, or numbers, without quotes. |
 | `subRuleRef` | Every rule processor is capable of reporting a number of different outcomes, but only a single outcome from the complete set is ultimately delivered to the typology processor. Each outcome is defined by a unique sub-rule reference identifier to differentiate the delivered outcome from the others and also to allow the typology processor to apply a unique weighting to that specific outcome.<br><br>We have elected to assign a numeric sequence to the sub-rule references for result cases, prefaced with a dot (“.”) separator, but this format is not mandatory for the sub-rule reference string. Any descriptive and unique string would be an acceptable sub-rule reference.<br><br>By convention, the default “else” outcome has a sub-rule reference of `.00`. |
-| `reason`| The reason provides a human-readable description of the result that accompanies the rule result to the eventual over-all evaluation result. [Reason descriptions will be refined during future enhancements](#Ref 1) |
+| `reason`| The reason provides a human-readable description of the result that accompanies the rule result to the eventual over-all evaluation result. Reason descriptions will be refined during future enhancements[^1] |
 
 ### Complete example of a rule processor configuration
 
@@ -670,9 +667,9 @@ The network map “header” contains metadata that describes the network map. T
 
 ### The messages object
 
-The `messages` object is an array that contains information about the transactions that the system is expected to evaluate. Each element in the `messages` object contains the following attributes [Ref 4](#ref-4):
+The `messages` object is an array that contains information about the transactions that the system is expected to evaluate. Each element in the `messages` object contains the following attributes[^4]:
 
-*   `id` is the unique identifier for the Transaction Aggregation and Decisioning Processor (TADProc) that will be used to ultimately conclude the evaluation of a specific transaction. It is possible for a transaction to be routed to a unique TADProc that contains specialized functionality related to summarizing the transaction’s results [Ref 3](#ref-3).
+*   `id` is the unique identifier for the Transaction Aggregation and Decisioning Processor (TADProc) that will be used to ultimately conclude the evaluation of a specific transaction. It is possible for a transaction to be routed to a unique TADProc that contains specialized functionality related to summarizing the transaction’s results[^3]
 
 *   `cfg` is the unique version of the deployed TADProc that will be used to conclude the evaluation of the transaction.
 
@@ -696,7 +693,7 @@ The `typologies` object is a nested array object inside the transaction element
 
 The typology object array contains the following attributes:
 
-*   `id` is the unique identifier for the typology processor that will be invoked to aggregate the specified rule results into a typology. It is possible for a transaction to be routed to a unique typology processor[Ref 3](#ref-3) that contains specialized functionality related to calculating the specific typology.
+*   `id` is the unique identifier for the typology processor that will be invoked to aggregate the specified rule results into a typology. It is possible for a transaction to be routed to a unique typology processor[^3] that contains specialized functionality related to calculating the specific typology.
 
 *   `cfg` defines the unique typology and the version of its configuration. The typology processor is effectively just a generic engine that processes the typology’s configuration to combine rules into a typology in a specific way. From a certain perspective, the typology configuration *is* the typology.
 
@@ -794,7 +791,7 @@ Once a configuration document has been created or updated and uploaded to the co
 
 The network map defines the routing of an incoming transaction to all rules and typologies that are required to evaluate the transaction. By default, the system 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.
 
-Unlike the processor configuration documents, the network map does not contain an explicit configuration version [Ref 2](#ref-2). Instead, the network map contains an attribute to identify the current active network map being used to perform evaluations:
+Unlike the processor configuration documents, the network map does not contain an explicit configuration version[^2]. Instead, the network map contains an attribute to identify the current active network map being used to perform evaluations:
 
 ```
 "active": true
@@ -814,19 +811,13 @@ The active network map ultimately defines the scope of a particular evaluation,
 
 [Top](#configuration-management)
 
-# References
-
-# Ref 1
-We have found during our performance testing that the text-based descriptions in our processor results undermines the performance gains we achieved with our ProtoBuff implementation. We will be removing the unabridged reason and processor descriptions from the configuration documents in favor of shorter look-up codes that will then also be used to introduce regionalized/language-specific descriptions.
+[^1]: We have found during our performance testing that the text-based descriptions in our processor results undermines the performance gains we achieved with our ProtoBuff implementation. We will be removing the unabridged reason and processor descriptions from the configuration documents in favor of shorter look-up codes that will then also be used to introduce regionalized/language-specific descriptions.
 
 
-# Ref 2 
-An explicit version reference has been planned for development to make it easier for an operator to link an evaluation result to the specific originating network map.
+[^2]: An explicit version reference has been planned for development to make it easier for an operator to link an evaluation result to the specific originating network map.
 
 
 
-# Ref 3
-In its default deployment, the system contains a single version of the “core” system processors (the typology processor and TADProc) at a time. Though it is possible to deploy and maintain multiple parallel versions of these processors and manage routing to these processors through the network map, this guide will only focus on singular core processors for now.
+[^3]: In its default deployment, the system contains a single version of the “core” system processors (the typology processor and TADProc) at a time. Though it is possible to deploy and maintain multiple parallel versions of these processors and manage routing to these processors through the network map, this guide will only focus on singular core processors for now.
 
-# Ref 4
-Before our implementation of NATS, Tazama processors were implemented as RESTful microservices. The `host` attributes in the network map contained the URL where the processors could be addressed. With our initial implementation of NATS, the routing information was moved into environment variables that were read into the processors when they were deployed, or restarted in the event of a processor failure. We have now removed the need to specify the host property for a processor - the routing is automatically determined from the network map at processor startup - see [https://github.com/frmscoe/General-Issues/issues/310](https://github.com/frmscoe/General-Issues/issues/310) for details.
+[^4]: Before our implementation of NATS, Tazama processors were implemented as RESTful microservices. The `host` attributes in the network map contained the URL where the processors could be addressed. With our initial implementation of NATS, the routing information was moved into environment variables that were read into the processors when they were deployed, or restarted in the event of a processor failure. We have now removed the need to specify the host property for a processor - the routing is automatically determined from the network map at processor startup - see [https://github.com/frmscoe/General-Issues/issues/310](https://github.com/frmscoe/General-Issues/issues/310) for details.

Product/event-director.md

@@ -119,3 +119,4 @@ Using the list of unique rules from step 2.4, the Event Director invokes all the
  - Network sub-map (the portion of the network map that defines the in-scope rules and typologies)
 
 See the page on [processor results propagation](https://github.com/frmscoe/docs/blob/main/Product/processor-results-propagation.md) for more information on the payload composition and propagation from one processor to the next.
+