Setting Advanced Initialization

At the very first Scenario Service startup, when the MongoDB database is empty, a check is made on the existence of a configuration file which name is defined by the scenario-management.app-config.file property (default value is app-config.json).

If this file is found, the application configuration elements it contains are loaded in the application.

This behavior reflects the default values scenario-service-base that the Spring Boot application uses by default.

                     scenario-management:
                     app-config:
                     file: /app-config.json         # Configuration file to use for reset
    # Following parameters configure the application reset on startup.
    # If a scenario-management.app-config.file is defined and exists it will be
    # used to reset the application, otherwise reset will erase existing elements
    # and reinitialize through the application initializers.
    #
    reset:
                     mode: always                  # init (default) | always | never
      views-dashboards: true      # reset views and dashboard (default true)
      workspaces: true            # reset workspaces (default true)
      permissions: true           # reset permissions (default true)
      app-preferences: true       # reset Application Preferences (default true)

It is possible to override scenario-management properties by adding them in application.yml of the scenario-service-extension module.

The possible values for the scenario-management.app-config.reset.mode property are :

  • init: if present, the file is loaded at the first startup of Scenario Service, when application database is empty.

  • always: if present, the file is reloaded at every Scenario Service startup.

  • never: the is never loaded.

Note:

Note that,when a user calls the interactive "Reset Default Configuration" feature, all the elements of the scenario-management.app-config.file are loaded, if present, regardless of the scenario-management.app-config.reset.mode and the individual reset flags.

In addition, an initialization bean is looked for and invoked if found. This gives you the opportunity to define some global initialization of the application, such as creating global workspaces or installing general permission rules. You can consider the code in this bean to be responsible for creating workspaces, and permissions always needed in your application.

To do so, define a class that implements WorkspaceAndPermissionRulesInitializer (Javadoc) in the scenario-service-extension, and annotate it with @Component to make it a bean class. In this class, you will override three methods:

  • initWorkspaces(String applicationId, InitWorkspaceApi initWorkspaceApi)

  • initPermissionRules(String applicationId, PermissionRulesApi permissionRulesApi)

  • initUser(String applicationId, GeneUser user, InitUserApi initUserApi)

The first two methods are called when the application starts or after a reset from a configuration file. The first one receives an InitWorkspaceApi (Javadoc) instance as argument, which contains the necessary API to create a workspace, etc. The second one receives a PermissionRulesApi (Javadoc) instance as argument, which contains the necessary API to add permission rules. For more details, please refer to Section Defining Permissions.

Finally, the third method is called when a user cannot access any workspace, typically when they log in for the first time. This is where a private workspace for the user can be created, for example.

Note that a freshly generated application contains an implementation of this bean, provided as an example, that duplicates the default behavior. You are free to modify it at will, or even remove it if you want to keep the default behavior and save some code.

The user initialization attaches a gene_user_initialized flag to each Keycloak user once the initialization is completed. The user initialization can be disabled by setting the property scenario-management.users.initialize to false in the default.yml configuration file of the scenario-service-extention module. This can be useful, for example, if your keycloak is configured with users in read-only mode.