You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.
Introduction
This page describes how to manage behavior of the application Id in Blueriq so that it is possible to:
- Deploy from different branches without breaking the runtime application.
- Have lists that show cases and tasks from different projects.
Processes are made unique in Blueriq by a so called ApplicationId. This Id is an aggregation of the branch version and the project name. This Id is used to make sure to always address the correct case from a case list or work list. The same behavior applies using message events. So having an unique identity is a good thing, but it also limits the way of deploying models and expanding an application using more than one projects.
Requirements
As business I want to be able to deploy from different branches without breaking the process, so that it is easier to manage my deployment strategy.
As business I want to be able to have a single dashboard over projects so that all cases and tasks are shown in one list.
Functional guideline
New properties are added to influence the behavior of models that normally make use of the application Id. Blueriq run time responds to three settings on two levels.
Settings
| Setting | Description | Comment |
|---|---|---|
| none | The default behavior. The application Id is still regarded by lists and messages. | This is default behavior like prior to Blueriq 9.6. So no migration is needed. |
| version | Ignores the version part of the application Id. This can be used when models are deployed from different branches. | Typically for deploying from hot fix branches and different deployment strategies. |
| all | Ignores version and project name from the application Id. This can be used when there are pages that wants to collect information from different projects. | Typically used in a dashboard for DCM applications. |
Levels
| Level | Description | Comment |
|---|---|---|
| Server | The settings apply for the complete application. | A general setting if all behavior for the application is the same |
| Project | A setting per project if settings only apply for a single project. | These settings overrule the server setting. It is possible to have a mix. So if no project setting is available, then the server setting applies. |
The settings are part of the aquima.properties for Java, or are part of .Net configuration.
Aquima.properties
Java Runtime configuration is done in aquima properties:
#global setting, accepted values = none, version, all processengine.appid_ignore=none #per-application setting; format = processengine.appid_ignore.<application name> = none | version | all processengine.appid_ignore.studio.RepositoryName-ProjectName1=version processengine.appid_ignore.studio.RepositoryName2-ProjectName2=all
If no configuration exists for an application, the global setting applies. If global setting is not configured, it defaults to none (backwards compatible behaviour)
.NET configuration
To configure ignore process version globally, add the "processengine.appid_ignore" parameter to the aquima section as below:
<aquima> <properties> <!-- Optional property to override the default value for ignoring the process version --> <property name="processengine_appid_ignore" value="none" /> </properties> </aquima>
To configure ignore process version per application, specify the application name and ignore mode as below in the webapplication section:
<applicationSettings> <application name = "studio-RepositoryName1-ProjectName1" processEngineIgnoreMode="version"/> <application name = "studio-RepositoryName2-ProjectName2" processEngineIgnoreMode="all"/> </applicationSettings>
Work list and case list
The default behavior for building a work list or a case list is a query on the database which uses an application Id. If the version Id and the project name of the current model definition do not match the stored version Id and project name, no tasks and cases will be shown in the corresponding lists. With the new settings it is possible to get the required behavior.
Below an overview is given of the interaction between the different components.
Throw message event
The default behavior for throwing a message event is that it is thrown to the version and project of the corresponding application Id. So if we have a solution which consists of multiple projects, a broadcasted message should be broadcasted within the solution. It is possible that model wise the process is modeled in one module which is a library and imported in multiple projects. With the new settings it is possible to get the required behavior.
Warning
If there is a deployment from a different version which is missing models compared to the current application, there is a possibility functionality won't work anymore. So ignoring versions can complicate things. For example a work list shows all tasks within a case ignoring version. But a task definition has been deleted and is not deployed from a new version. The task is still part of the process database, so it will show up in the work list because the version is ignored. Starting the task from the list will result in an error, because it cannot find its model definition.
Example
Below an example is given to get a good understanding on how to address the properties:
Java aquima.properties
.Net properties
Overview
Content Tools