You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.
When publishing 9.8.5 documentation, this page should replace the page above. The diagrams still need to be updated.
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 four settings on three 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. |
| project | Ignores the project project name part of the applicationId. This can be used when multiple projects on the same branch share the same process model. | This setting was introduced in Blueriq 9.8.5. |
| 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. |
Components
| Component | Description |
|---|---|
| Process Engine | Controls which part of the application Id is ignored by the process engine when evaluating timer nodes and handling message events. |
| Process Lists | Controls which part of the application Id is ignored when displaying cases in Case Lists and tasks in Work Lists. For backward compatibility, when process list settings are not configured, the process engine settings apply. |
The settings are part of the aquima.properties for Java, or are part of .Net configuration.
Rules
When displaying cases and tasks in Case Lists and Work Lists, the Runtime uses the following rules to decide which part of the application Id should be ignored in an application A:
- check the process list setting for application A; if not configured then...
- check the global process list setting; if not configured then...
- check the process engine setting for application A; if not configured then...
- check the global process engine setting; if not configured then...
- use 'none' as default
When handling timers and message events, the Process Engine of an application A uses the following rules to determine which part of the application Id should be ignored:
- check the process engine setting for application A; if not configured then...
- check the global process engine setting; if not configured then...
- use 'none' as default
Aquima.properties
Java Runtime configuration is done in aquima properties:
#global setting for the process engine, accepted values = none, project, version, all processengine.appid_ignore=none #per-application setting for the process engine; format = processengine.appid_ignore.<application name> = none | project | version | all processengine.appid_ignore.studio-RepositoryName1-ProjectName1=project processengine.appid_ignore.studio-RepositoryName2-ProjectName2=version processengine.appid_ignore.studio-RepositoryName3-ProjectName3=all #global setting for process lists, accepted values = none, project, version, all processlist.appid_ignore=none #per-application setting for process lists; format = processlist.appid_ignore.<application name> = none | project | version | all processlist.appid_ignore.studio-RepositoryName1-ProjectName1=project processlist.appid_ignore.studio-RepositoryName2-ProjectName2=version processlist.appid_ignore.studio-RepositoryName3-ProjectName3=all
.NET configuration
To configure ignore process version globally, add the "processengine.appid_ignore" and "processlist.appid_ignore" parameters 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" /> <property name="processlist.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="project" processListIgnoreMode="project" /> <application name = "studio-RepositoryName2-ProjectName2" processEngineIgnoreMode="version" processListIgnoreMode="version" /> <application name = "studio-RepositoryName3-ProjectName3" processEngineIgnoreMode="all" processListIgnoreMode="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