Understanding the Scenario Service
Note that:
-
Platform features can be extended further depending on the project requirements. For more details, please refer to Chapter Extending the Application Features.
-
Access to this service requires authentication. For more details, please 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.
The Platform 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, please 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, please 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.
-
pathstores the application elements, which can be of any type. For more details, please refer to Section Understanding the Scenario Service Path Types. -
path_eventstores the events associated to an element of the application. For more details, please refer to Section Understanding the Scenario Service Path Types. -
gene_contextstores the user contexts which may contain information about selected workspace, scenarios and filters. -
gene_widget_statestores the widget states associated to a user and a dashboard. -
gene_user_settingsstores the users web client settings.