Page History
| Table of Contents |
|---|
| Warning |
|---|
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:
...
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
| UI Text Box | ||
|---|---|---|
| ||
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. |
| UI Text Box | ||
|---|---|---|
| ||
| 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.
...
| 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 (from 9.8.5)
| 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 the .Net configuration.
Rules
When displaying cases and tasks in the AQ_CaseList and AQ_Worklist containers, the Runtime uses the following rules to decide which part of the application Id should be ignored in an application A:
- check the
process listsetting for application A; if not configured then... - check the global
process listsetting; if not configured then... - check the
process enginesetting for application A; if not configured then... - check the global
process enginesetting; if not configured then... - use
noneas 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 enginesetting for application A; if not configured then... - check the global
process enginesetting; if not configured then... - use
noneas default
Aquima.properties
Java Runtime configuration is done in aquima properties:
...
| Code Block |
|---|
<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:
...
Overview
Content Tools