From 168f3229a8a6d0b43af1a86f8dca10e758fc622c Mon Sep 17 00:00:00 2001 From: kaioken Date: Mon, 12 Jul 2021 15:36:29 -0400 Subject: [PATCH 01/11] feature: Action Engine RFC --- rfcs/001-action-engine.md | 43 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 rfcs/001-action-engine.md diff --git a/rfcs/001-action-engine.md b/rfcs/001-action-engine.md new file mode 100644 index 0000000..a678c7e --- /dev/null +++ b/rfcs/001-action-engine.md @@ -0,0 +1,43 @@ +- Start Date: (fill in today's date, YYYY-MM-DD) +- RFC PR: (leave this empty) + +# Summary + +Backend Implementation for SalesAssist Action Engine + +# Example + +If the proposal requires changes to the current API or the creation of new ones, add a basic code example. + +# Motivation + +Please make sure to explain the motivation for this proposal. +It means explaining the use case(s) and the functional feature(s) this proposal is trying to solve. + +Try to only talk about the intent not the proposed solution here. + +# Detailed design + +Describe the proposal in details: + +- Explaining the design so that someone who knows Kanvas can understand and someone who works on it can implement the proposal. +- Think about edge-cases and include examples. + +# Tradeoffs + +What potential tradeoffs are involved with this proposal. + +- Complexity +- Work load of implementation +- Can this be implemented outside of Kanvas's core packages +- How does this proposal integrate with the current features being implemented +- Cost of migrating existing Kanvas applications (is it a breaking change?) +- Does implementing this proposal mean reworking teaching resources (videos, tutorials, documentations)? + +# Alternatives + +What are the alternatives? + +# Unresolved questions + +Optional, but suggested for first draft proposals. What parts of the design are still TBD(To be defined)? From 614807da373bd091cba6c3aaa833bdc8a42ba379 Mon Sep 17 00:00:00 2001 From: kaioken Date: Sun, 8 Aug 2021 20:05:39 -0400 Subject: [PATCH 02/11] feature: action structure definition --- rfcs/001-action-engine.md | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/rfcs/001-action-engine.md b/rfcs/001-action-engine.md index a678c7e..e793574 100644 --- a/rfcs/001-action-engine.md +++ b/rfcs/001-action-engine.md @@ -3,7 +3,22 @@ # Summary -Backend Implementation for SalesAssist Action Engine +Backend Implementation for SalesAssist Action Engine . + +The focus of the action engine is the send a lead to a action page where they can execute one action and the result of this action is sent back to the system in order to execute a set of workflow to send this result to any # of third party, resulting in a historical feed of all the diff action this users has taken over time. + +The main db structure of the system is the following [Database Diagram](https://dbdiagram.io/d/60e7cf6b7e498c3bb3eecfee) + +**Entities** +- **Action**: structure that holds all action from the system +- **Action Type**: what type of action is this? product, document, forms, commerce, etc , just a reference to the diff type of actions in the system +- **Action Workflow**: what are the default workflows this action will execute upon its end. Why? if we want to make sure some action always run a specific workflow the system creators define +- **Action Systems**: each action page is powered by a specific subsystem , we can expect product action to function in the same way as form actions. So here we specify what system powers this action . Some initial system will be (forms, commerce, content) +- **Action date type** : specify the datatype this action will use. Example? product , content (as of now). cant this be used by the action system? to be discuss +- **Action Companies** : reference what action is this company use / has created +- **Action companies workflow** : Besides the default action workflow , specify custom workflow created by the user withing this company +- **Action companies systems modules** : Specify the list of entities from a specific action system tied to this action . Example: we would hold here the list of products, content, form referenced use in this action for the specific company in order to generate the action page. +- **Engagement** : Result of the current lead interaction with a action page. Main thing to point out is the changes of the action stage and the reference to the message id which is the json object of the result interaction # Example From e3db5c11f2f3d580cf50e496c419419dd0856a65 Mon Sep 17 00:00:00 2001 From: kaioken Date: Sun, 8 Aug 2021 20:52:31 -0400 Subject: [PATCH 03/11] feature: update project ddd folder structure --- rfcs/001-action-engine.md | 43 +++++++++++++++++++++++++++++++-------- 1 file changed, 35 insertions(+), 8 deletions(-) diff --git a/rfcs/001-action-engine.md b/rfcs/001-action-engine.md index e793574..fe20e3c 100644 --- a/rfcs/001-action-engine.md +++ b/rfcs/001-action-engine.md @@ -20,10 +20,43 @@ The main db structure of the system is the following [Database Diagram](https:// - **Action companies systems modules** : Specify the list of entities from a specific action system tied to this action . Example: we would hold here the list of products, content, form referenced use in this action for the specific company in order to generate the action page. - **Engagement** : Result of the current lead interaction with a action page. Main thing to point out is the changes of the action stage and the reference to the message id which is the json object of the result interaction -# Example +# Structure + +Since our action engine at the end of the day is based on 3 system, CRM, PIM and Actions but at this moment we dont want to have to manage 3 different API's lets follow the same DDD as we did in NZXT but update it based on a proper [DDD](https://stitcher.io/blog/laravel-beyond-crud-01-domain-oriented-laravel) + +- API (aka apps) + - crm + - config + - controller + - public + - routes + - test + - pmi + - config + - controller + - public + - routes + - test + - action_engine? + - config + - controller + - public + - routes + - test +- Domains + - Leads + - Products + - ActionsEngine +- Libraries +- Cli -If the proposal requires changes to the current API or the creation of new ones, add a basic code example. +# Detailed design + +Describe the proposal in details: +- Explaining the design so that someone who knows Kanvas can understand and someone who works on it can implement the proposal. +- Think about edge-cases and include examples. +- # Motivation Please make sure to explain the motivation for this proposal. @@ -31,12 +64,6 @@ It means explaining the use case(s) and the functional feature(s) this proposal Try to only talk about the intent not the proposed solution here. -# Detailed design - -Describe the proposal in details: - -- Explaining the design so that someone who knows Kanvas can understand and someone who works on it can implement the proposal. -- Think about edge-cases and include examples. # Tradeoffs From 9436c89982d9495c017f2fdaec14c60365dd0e31 Mon Sep 17 00:00:00 2001 From: kaioken Date: Sun, 8 Aug 2021 21:17:17 -0400 Subject: [PATCH 04/11] finish with v1 of action engine --- rfcs/001-action-engine.md | 41 +++++++++++++++++---------------------- 1 file changed, 18 insertions(+), 23 deletions(-) diff --git a/rfcs/001-action-engine.md b/rfcs/001-action-engine.md index fe20e3c..155e5ba 100644 --- a/rfcs/001-action-engine.md +++ b/rfcs/001-action-engine.md @@ -15,7 +15,8 @@ The main db structure of the system is the following [Database Diagram](https:// - **Action Workflow**: what are the default workflows this action will execute upon its end. Why? if we want to make sure some action always run a specific workflow the system creators define - **Action Systems**: each action page is powered by a specific subsystem , we can expect product action to function in the same way as form actions. So here we specify what system powers this action . Some initial system will be (forms, commerce, content) - **Action date type** : specify the datatype this action will use. Example? product , content (as of now). cant this be used by the action system? to be discuss -- **Action Companies** : reference what action is this company use / has created +- **Action companies** : reference what action is this company use / has created +- **Action companies recievers** : each action from a company needs to generate its own receiver - **Action companies workflow** : Besides the default action workflow , specify custom workflow created by the user withing this company - **Action companies systems modules** : Specify the list of entities from a specific action system tied to this action . Example: we would hold here the list of products, content, form referenced use in this action for the specific company in order to generate the action page. - **Engagement** : Result of the current lead interaction with a action page. Main thing to point out is the changes of the action stage and the reference to the message id which is the json object of the result interaction @@ -52,34 +53,28 @@ Since our action engine at the end of the day is based on 3 system, CRM, PIM and # Detailed design -Describe the proposal in details: +At a App level , we need to provide the different API's for the frontend to connect the necessary information to generate action pages and endpoints to send the end results in order to generate engagement messages. -- Explaining the design so that someone who knows Kanvas can understand and someone who works on it can implement the proposal. -- Think about edge-cases and include examples. -- -# Motivation +- Public routes will be always guided by a UUID, please avoid any int +- Internal CRUD calls can be guided by UUID or Int + +We will hae 3 different APi +- api.crm.domain.com +- api.products.domain.com +- api.action-engine.domain.com -Please make sure to explain the motivation for this proposal. -It means explaining the use case(s) and the functional feature(s) this proposal is trying to solve. +For public API calls from receiver or action pages , it will be important to always send +- lead uuid +- visitor uuid +- action uuid -Try to only talk about the intent not the proposed solution here. +# Motivation +We need to make the necessary changes to provide a clean structure for our action engine , allowing use a good structure for future growth # Tradeoffs What potential tradeoffs are involved with this proposal. -- Complexity -- Work load of implementation -- Can this be implemented outside of Kanvas's core packages -- How does this proposal integrate with the current features being implemented -- Cost of migrating existing Kanvas applications (is it a breaking change?) -- Does implementing this proposal mean reworking teaching resources (videos, tutorials, documentations)? - -# Alternatives - -What are the alternatives? - -# Unresolved questions - -Optional, but suggested for first draft proposals. What parts of the design are still TBD(To be defined)? +- Big changes to our folder structure +- Will need to update our Kubernetes app structure for the APi From 87df6e620488131a652c4ccb7a8e07162f5eb4f9 Mon Sep 17 00:00:00 2001 From: kaioken Date: Tue, 10 Aug 2021 14:08:46 -0400 Subject: [PATCH 05/11] fix : pim --- rfcs/001-action-engine.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/001-action-engine.md b/rfcs/001-action-engine.md index 155e5ba..339b2c2 100644 --- a/rfcs/001-action-engine.md +++ b/rfcs/001-action-engine.md @@ -32,7 +32,7 @@ Since our action engine at the end of the day is based on 3 system, CRM, PIM and - public - routes - test - - pmi + - pim (Product information management) - config - controller - public From 1f7108150f08ec4d627e58007dbf9556792ede05 Mon Sep 17 00:00:00 2001 From: kaioken Date: Wed, 11 Aug 2021 00:03:51 -0400 Subject: [PATCH 06/11] refactor: feedback white --- rfcs/001-action-engine.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/rfcs/001-action-engine.md b/rfcs/001-action-engine.md index 339b2c2..dc2e0a8 100644 --- a/rfcs/001-action-engine.md +++ b/rfcs/001-action-engine.md @@ -5,12 +5,12 @@ Backend Implementation for SalesAssist Action Engine . -The focus of the action engine is the send a lead to a action page where they can execute one action and the result of this action is sent back to the system in order to execute a set of workflow to send this result to any # of third party, resulting in a historical feed of all the diff action this users has taken over time. +The focus of the action engine is to send a lead to an action page where they trigger one action and the result of this is sent back to the system. This is turn executes a set of workflows that send the result to any # of third parties, resulting in a historical feed of all the different actions the user has made over time. The main db structure of the system is the following [Database Diagram](https://dbdiagram.io/d/60e7cf6b7e498c3bb3eecfee) **Entities** -- **Action**: structure that holds all action from the system +- **Action**: Structure that holds all actions of the system. - **Action Type**: what type of action is this? product, document, forms, commerce, etc , just a reference to the diff type of actions in the system - **Action Workflow**: what are the default workflows this action will execute upon its end. Why? if we want to make sure some action always run a specific workflow the system creators define - **Action Systems**: each action page is powered by a specific subsystem , we can expect product action to function in the same way as form actions. So here we specify what system powers this action . Some initial system will be (forms, commerce, content) @@ -50,10 +50,11 @@ Since our action engine at the end of the day is based on 3 system, CRM, PIM and - ActionsEngine - Libraries - Cli +- Storage # Detailed design -At a App level , we need to provide the different API's for the frontend to connect the necessary information to generate action pages and endpoints to send the end results in order to generate engagement messages. +At a App level , we need to provide different APIs for the frontend to connect the necessary information to generate action pages and endpoints to send the end results in order to generate engagement messages. - Public routes will be always guided by a UUID, please avoid any int - Internal CRUD calls can be guided by UUID or Int From 94c8dc0d73757782d4d9256f2a952ab39cc95fa5 Mon Sep 17 00:00:00 2001 From: kaioken Date: Mon, 16 Aug 2021 00:37:33 -0400 Subject: [PATCH 07/11] refactor : refactor text --- rfcs/001-action-engine.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/rfcs/001-action-engine.md b/rfcs/001-action-engine.md index dc2e0a8..a1a1ee1 100644 --- a/rfcs/001-action-engine.md +++ b/rfcs/001-action-engine.md @@ -10,13 +10,13 @@ The focus of the action engine is to send a lead to an action page where they tr The main db structure of the system is the following [Database Diagram](https://dbdiagram.io/d/60e7cf6b7e498c3bb3eecfee) **Entities** -- **Action**: Structure that holds all actions of the system. -- **Action Type**: what type of action is this? product, document, forms, commerce, etc , just a reference to the diff type of actions in the system -- **Action Workflow**: what are the default workflows this action will execute upon its end. Why? if we want to make sure some action always run a specific workflow the system creators define -- **Action Systems**: each action page is powered by a specific subsystem , we can expect product action to function in the same way as form actions. So here we specify what system powers this action . Some initial system will be (forms, commerce, content) -- **Action date type** : specify the datatype this action will use. Example? product , content (as of now). cant this be used by the action system? to be discuss -- **Action companies** : reference what action is this company use / has created -- **Action companies recievers** : each action from a company needs to generate its own receiver +- **Action**: Holds all actions of the system. +- **Action Type**: Types of action system will support product, document, forms, commerce, etc , +- **Action Workflow**: What are the default workflows system requires this action to execute once it ends. +- **Action Systems**: Each action type will be powered by its own system domain , thus allowing use to encapsulate system complexity . Example: Forms, Commerce and Content will each have its own set of features +- **Action date type** : Specify the datatype this action will use. We define here the json structure the action expect the frontend to send , if the frontend structure doesn't match all the required fields in the data type, backend will throw a exception +- **Action companies** : Reference what action is this company use / has created +- **Action companies receivers** : Each action has its own receiver uuid in order to know when the frontend send a message from each action taken on the action pages - **Action companies workflow** : Besides the default action workflow , specify custom workflow created by the user withing this company - **Action companies systems modules** : Specify the list of entities from a specific action system tied to this action . Example: we would hold here the list of products, content, form referenced use in this action for the specific company in order to generate the action page. - **Engagement** : Result of the current lead interaction with a action page. Main thing to point out is the changes of the action stage and the reference to the message id which is the json object of the result interaction From 34ed3c34cecb37394659f3298499a729c029aeb8 Mon Sep 17 00:00:00 2001 From: kaioken Date: Tue, 24 Aug 2021 12:20:44 -0400 Subject: [PATCH 08/11] refactor : initial draft --- rfcs/001-action-engine.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/rfcs/001-action-engine.md b/rfcs/001-action-engine.md index a1a1ee1..b7a1756 100644 --- a/rfcs/001-action-engine.md +++ b/rfcs/001-action-engine.md @@ -5,18 +5,18 @@ Backend Implementation for SalesAssist Action Engine . -The focus of the action engine is to send a lead to an action page where they trigger one action and the result of this is sent back to the system. This is turn executes a set of workflows that send the result to any # of third parties, resulting in a historical feed of all the different actions the user has made over time. +The purpose of the action engine is to generate an action page that collects information from leads and will trigger actions when this information is submitted back to our system, this will execute a set of workflows that send the result to any # of third parties, resulting in a historical feed of all the different actions the user has made over time. The main db structure of the system is the following [Database Diagram](https://dbdiagram.io/d/60e7cf6b7e498c3bb3eecfee) **Entities** - **Action**: Holds all actions of the system. - **Action Type**: Types of action system will support product, document, forms, commerce, etc , -- **Action Workflow**: What are the default workflows system requires this action to execute once it ends. -- **Action Systems**: Each action type will be powered by its own system domain , thus allowing use to encapsulate system complexity . Example: Forms, Commerce and Content will each have its own set of features -- **Action date type** : Specify the datatype this action will use. We define here the json structure the action expect the frontend to send , if the frontend structure doesn't match all the required fields in the data type, backend will throw a exception -- **Action companies** : Reference what action is this company use / has created -- **Action companies receivers** : Each action has its own receiver uuid in order to know when the frontend send a message from each action taken on the action pages +- **Action Workflow**: List of the default workflows system requires this action to execute once it ends. +- **Action Systems**: Each action type will be powered by its own system domain , in order to encapsulate system complexity . Example: Forms, Commerce and Content will each have its own set of features +- **Action data type** : Specify the datatype this action will use. We define here the json structure the action expect the frontend to send , if the frontend structure doesn't match all the required fields in the data type, backend will throw a exception +- **Action companies** : Reference what action is this company has +- **Action companies receivers** : UUID identifier to match external request from the frontend to a specific Action. - **Action companies workflow** : Besides the default action workflow , specify custom workflow created by the user withing this company - **Action companies systems modules** : Specify the list of entities from a specific action system tied to this action . Example: we would hold here the list of products, content, form referenced use in this action for the specific company in order to generate the action page. - **Engagement** : Result of the current lead interaction with a action page. Main thing to point out is the changes of the action stage and the reference to the message id which is the json object of the result interaction @@ -79,3 +79,8 @@ What potential tradeoffs are involved with this proposal. - Big changes to our folder structure - Will need to update our Kubernetes app structure for the APi + +# FAQ + +- What is a lead receiver? +- \ No newline at end of file From bc811f806f416b860fe2fcd8c2c4aa4f36c9a0d2 Mon Sep 17 00:00:00 2001 From: kaioken Date: Tue, 24 Aug 2021 15:00:54 -0400 Subject: [PATCH 09/11] feat : add db structure example --- rfcs/001-action-engine.md | 110 +++++++++++++++++++++++++++++++++++++- 1 file changed, 109 insertions(+), 1 deletion(-) diff --git a/rfcs/001-action-engine.md b/rfcs/001-action-engine.md index b7a1756..aa3b4b2 100644 --- a/rfcs/001-action-engine.md +++ b/rfcs/001-action-engine.md @@ -20,6 +20,7 @@ The main db structure of the system is the following [Database Diagram](https:// - **Action companies workflow** : Besides the default action workflow , specify custom workflow created by the user withing this company - **Action companies systems modules** : Specify the list of entities from a specific action system tied to this action . Example: we would hold here the list of products, content, form referenced use in this action for the specific company in order to generate the action page. - **Engagement** : Result of the current lead interaction with a action page. Main thing to point out is the changes of the action stage and the reference to the message id which is the json object of the result interaction +- **Business Verticals** : List of industries the system will have default actions # Structure @@ -83,4 +84,111 @@ What potential tradeoffs are involved with this proposal. # FAQ - What is a lead receiver? -- \ No newline at end of file + + +# DB Structure + +business_verticals + +| Syntax | Description | Test Text | +| :--- | :----: | ---: | +| id | integer | 1 | +| name | Text | automobile | + +
+action_data_types + +| Syntax | Description | Test Text | +| :--- | :----: | ---: | +| id | integer | 1 | +| uuid | varchar | 714d7361-9c3c-4223-8ccc-dabb5da47a36| +| name | Text | dealerContent | +| definition | Text | {json structure of reciever} | + +| Syntax | Description | Test Text | +| :--- | :----: | ---: | +| id | integer | 2 | +| uuid | varchar | 714d7361-9c3c-4223-8ccc-dabb5da47a36| +| name | Text | Finance Product | +| definition | Text | {json structure of reciever} | + +*json structure + +``` +{ + "leads_uuid": "a9f04a86-9aa5-44da-8c52-2289bd1c7dce", + "message": { + "lang": "EN", + "headers": {"User-Agent":"Mozilla\/5.0 (Macintosh; Intel Mac OS X 11_2_3)"}, + "status": "submitted", + "source": "web", + "hashtagVisited": "#hello", + "text": "hello", + "visitor_id": "62f3e6ee-39cf-4f26-837d-3515edd96b22" + }, + "verb": "trade-walk" +} +``` + +
+action_types + +| Syntax | Description | Test Text | +| :--- | :----: | ---: | +| id | integer | 1 | +| name | Text | document | + + +
+actions + +| Syntax | Description | Test Text | +| :--- | :----: | ---: | +| id | integer | 1 | +| uuid | Text | 614d7361-9c3c-4223-8ccc-dabb5da47a36|| +| apps_id | integer | 2|| +| actions_systems_id | integer | 1|| +| companies_id | integer | 0|| +| users_id | integer | 1|| +| pipelines_types_id | integer | 1|| +| name | varchar | Dealer Content|| +| parent_id | integer | 0|| +| description | text | This is a action fro dealer content|| +| business_Verticals_id | text | 1|| + + +
+action_systems + +| Syntax | Description | Test Text | +| :--- | :----: | ---: | +| id | integer | 1 | +| actions_id | integer | 1 | +| sub_system_id | integer | 1 | +| actions_data_type_id | integer | 1 | +| actions_type_id | integer | 1 | + +| Syntax | Description | Test Text | +| :--- | :----: | ---: | +| id | integer | 2 | +| actions_id | integer | 1 | +| sub_system_id | integer | 1 | +| actions_data_type_id | integer | 2 | +| actions_type_id | integer | 1 | + +
+actions_workflow + +| Syntax | Description | Test Text | +| :--- | :----: | ---: | +| id | integer | 1 | +| workflow_id | integer | 1 | + +
+systems + +| Syntax | Description | Test Text | +| :--- | :----: | ---: | +| id | integer | 1 | +| uuid | varchar | 788d7361-9c3c-4223-8ccc-dabb5da47a36| +| name | Text | Landing Page | From c0f452f248150129136793726bca6d993226758b Mon Sep 17 00:00:00 2001 From: kaioken Date: Tue, 24 Aug 2021 15:53:26 -0400 Subject: [PATCH 10/11] refactor: format --- rfcs/001-action-engine.md | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/rfcs/001-action-engine.md b/rfcs/001-action-engine.md index aa3b4b2..22097cf 100644 --- a/rfcs/001-action-engine.md +++ b/rfcs/001-action-engine.md @@ -83,8 +83,24 @@ What potential tradeoffs are involved with this proposal. # FAQ -- What is a lead receiver? +- What is a lead receiver?
+ Automated API designed to receive and process the information that is used to create a lead in the system. + + The following information is required: + - Name + - Email + - Phone + - UserCompany the lead belongs to + + Can receive the following information: + - Any additional field that belongs to the UserCompany's lead settings fields (eg: Credit Score, Interests, Type of Business, etc.) + + Can receive leads from: + - HTML forms + - API's via Json + - Webhooks +
# DB Structure From 4bc9aaea9cf57aaefd2b7a6ae89d530d7f333f8d Mon Sep 17 00:00:00 2001 From: kaioken Date: Tue, 24 Aug 2021 17:00:27 -0400 Subject: [PATCH 11/11] feat : ad action page diagram --- rfcs/001-action-engine.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/rfcs/001-action-engine.md b/rfcs/001-action-engine.md index 22097cf..2454e87 100644 --- a/rfcs/001-action-engine.md +++ b/rfcs/001-action-engine.md @@ -7,7 +7,8 @@ Backend Implementation for SalesAssist Action Engine . The purpose of the action engine is to generate an action page that collects information from leads and will trigger actions when this information is submitted back to our system, this will execute a set of workflows that send the result to any # of third parties, resulting in a historical feed of all the different actions the user has made over time. -The main db structure of the system is the following [Database Diagram](https://dbdiagram.io/d/60e7cf6b7e498c3bb3eecfee) +The main db structure of the system is the following [Database Diagram](https://dbdiagram.io/d/60e7cf6b7e498c3bb3eecfee)
+Action Page Flow [Diagram](https://viewer.diagrams.net/?highlight=0000ff&edit=_blank&layers=1&nav=1&title=actionengine.drawio#R5VjRcps6EP0aPyaDIeD4MbGdtNO0dZu6TftyR4Y1qBWICmGbfH1XQmAw2HN7M046tzNJRjparaSzZ1ciA2cSb28FSaO3PAA2sK1gO3CmA9sejcf4VwFFCQw91ymRUNDAYDvgnj6CAS2D5jSArGUoOWeSpm3Q50kCvmxhRAi%2BaZutOGuvmpIQOsC9T1gX%2FUIDGZXopWvt8FdAw6haeWiZkZhUxgbIIhLwTQNyZgNnIjiXZSveToAp8ipeynk3B0brjQlI5L%2BZ8Bj%2F82rEi29vis%2Brh2%2FwYZGv7TMTjEwW1YEhwPObLhcy4iFPCJvt0GvB8yQA5dXC3s7mjvMUwSGC30HKwgST5JIjFMmYmVHYUvmgpp%2B7pve11ZtujW%2FdKRqdOQgagwRRYYkURenKGg4roPTmeV4F7BzqXtHs7bvs0mqYzngufDjCZSVPIkKQR%2Bzs0k4R3VjABO0WOO5GFGgggBFJ120hEqPnsLbbhRwbJuq%2FoQDjd01YblZaZJhwtsfwDNdLga1QtdY0o1LhJMYoXyfLLNVs7dvdkSSgSYgu5yq19uWFWZCqZh6zK19yoTyDkBQz7o4sgc05LkN5giZLLiWPGwZXjIZqQCqdNQXFc8loApO6BhwNpHIH26PUm9GxSd2qeF2Y%2FmZXCRwDRY0i4FlPj9XPecpmN98vvqTv7Xx%2BefZmPb39o7L1aK72Kvy%2FZZXdzapebuxnSqLexS9eIjCnJbnXzn1Jkr1Opfr%2Fsd578Odi%2FdgmG6xPAV9HWO8trLdSHbpzB%2FRW%2Fjbzm4hKuE%2BJJmiDb8c%2Blp9UvDvV2%2BlW76F9ovJ9OHtaVN4ITWGgd4Wbsq13i4dP6tkLCQgi1UVssfpGTf9EXmu%2BnoPX3vzoPmEqSUbDSpJdkVYILtk1S%2BvnDCeBjkErBOpzoyl99JEedJGRc0hCnKfmnvv4pMHTjq4F%2BBSQ9gV%2B4QxGU%2FXj3OhXlnoVTXMF97rfiz%2BGTbaDnEnBf%2BBriGlHCU9U4VtRxvagDGWiTuVM3V3vk66DZ%2FYhMXHc8orpD5mIBgEknaJ6QFA9sjusMbetsZ7UdSz73O2KbHwqkXXr4IToWVfz1%2FqjVGetVM1IKYT4%2BhlbK4YmK2WyJBkoQemh0rIUAtUldbF4ja7xDMii9dmIoYKfnvhPC8rIbQXlzO1JfLcn8Uenikm3oF5VrH%2BELGeyCoyO0QvT51284H3US9%2FohHXzvrzV9nJBtKJSVcA6iTYRCGW%2FgcYVqObj70yX0FgXXWuls0JGVN2PWYp%2BVtRvLtRKM6qm%2BLkQ5eSUpqA%2BF%2F%2Fa6urZe0q87FHiuEeJtTx%2FQ4oD9cip%2Fselxxr%2FKXRmvwA%3D) **Entities** - **Action**: Holds all actions of the system.