Chapter 12. Understanding the Scenario Service

[Note]

Note that:

  • DOC features can be extended further depending on the project requirements. For more details, refer to Chapter Extending the Application Features.

  • Access to this service requires authentication. For more details, refer to Chapter Managing Users.

  • Before each data modification, the Data Service calls the Scenario Service "canWrite" API in order to know if the current user can perform the modification.

DOC stores scenario information through two different services, each one using its own database:

  • The Data Service relies on a relational database to store the actual data associated with each scenario. For more details, refer to Section Understanding the Data Service.

  • The Scenario Service relies on a MongoDB database to store scenario specific metadata and properties, the workspaces and folders hierarchy and application configuration settings.

The Scenario Service is organized as a hierarchy of MongoDB documents that are used to represent scenarios, scenario links, folders, workspaces, views and dashboards. For more details, refer to Section Understanding the Scenario Service Document Properties.

Here is an example of an application hierarchy:

Application
 |- Workspace 1
   |- Folder 1
   | |- Scenario 1
   |- Folder 2
 |- View 1
 |- Dashboard 1
   -

The Scenario Service uses different MongoDB collections to store the data.

  • path stores the application elements, which can be of any type. For more details, refer to Section Understanding the Scenario Service Path Types.

  • path_event stores the events associated to an element of the application. For more details, refer to Section Understanding the Scenario Service Path Types.

  • gene_context stores the user contexts which may contain information about selected workspace, scenarios and filters.

  • gene_widget_state stores the widget states associated to a user and a dashboard.

  • gene_user_settings stores the users web client settings.

1. Understanding the Scenario Service Document Properties

The Scenario Service is organized as a hierarchy of MongoDB documents that are used to represent scenarios, scenario links, folders, workspaces, views and dashboards. They are defined as follows:

  • id - Internal MongoDB ID

  • pathType - the element type among ROOT, APPLICATION, WORKSPACE, FOLDER, SCENARIO, SCENARIO_LINK, CUSTOM_DASHBOARD, CUSTOM_VIEW. For more details, refer to Section Understanding the Scenario Service Path Types.

  • uuid - a unique identifier used by the application to refer to the path documents

  • parentUuid - the parent path document identifier

  • name - the element name

  • owner - the user owner of the element

  • creationDate - the element creation date

  • modificationDate - the last modification date

  • modificationUser - the user that made the latest modifications

  • deleted - set to true when the element is considered as deleted in the application

  • userLock (optional) - user lock information, when a user sets a lock on the element, as described in Section Understanding Scenario Locks (only applies to SCENARIO type elements)

  • systemLock (optional) - system lock information, when the system set a lock on the element, as described in Section Understanding Scenario Locks (only applies to SCENARIO type elements)

  • dataStatus- the scenario current data status (only applies to SCENARIO type elements)

  • dataStatusDate- the date when the latest data status check occurred (only applies to SCENARIO type elements)

  • properties - a list of custom properties used to store data associated to an element.

2. Understanding the Scenario Service Path Types

The application structure is defined in the MongoDB collection path and contains elements of the following types:

  • ROOT: this element is unique and represents the root element of the application hierarchical structure.

  • APPLICATION: the element that represents the application.

  • WORKSPACE: an organizational element in the hierarchical structure that may contain FOLDER, SCENARIO or SCENARIO_LINK child elements.

  • FOLDER: an organizational element in the hierarchical structure that may contain SCENARIO, SCENARIO_LINK or other FOLDER elements (subfolders).

  • SCENARIO: this element is associated through its uuid with data managed by the scenario data. For more details, refer to Chapter Understanding the Data Service.

  • SCENARIO_LINK: this element is referencing another existing scenario document through its referencedScenarioId field.

  • CUSTOM-DASHBOARD: a Custom Dashboard that aggregates multiple Widgets. For more details, refer to Sections Understanding the Custom Views and Dashboards and Understanding Widgets.

  • CUSTOM-VIEW: a Custom View contains a single Widget. For more details, refer to Sections Understanding the Custom Views and Dashboards and Understanding Widgets.

3. Understanding the Scenario Service Events

The events are stored in the MongoDB collection path_event and are defined using the following parameters:

  • id - Internal MongoDB ID

  • pathUuid - The attached path UUID (e.g. scenario Id)

  • taskId - Optional task identifier, if the event is linked to a task

  • author - The user who is the initiator of the event, can be "System" if automatically created by DOC

  • creationDate- The date of event creation, cannot be changed afterward

  • lastModificationDate - The last event modification date

  • type - The event type, customizable by the user

  • properties - Contains specific event data, depending on the type of event

4. Understanding the Scenario Service Context

The context defines the current web client state. For more details, refer to Section Understanding Widget Context.

The elements of context are stored in the MongoDB collection gene_context and are defined using the following parameters:

  • id - Internal MongoDB ID

  • author - The user who is the initiator of context

  • creationDate - The date of context creation

  • context - The web client serialized GeneContext