Page History
| Table of Contents |
|---|
| Note |
|---|
This feature is for DCM 1.0 only |
Introduction
This page describes the mechanism of loading the right case with the right application in Blueriq so that it is possible to:
...
Processes are made unique in Blueriq by a so called application ID (applicationId). This ID is an aggregation of the project name and the branch version and the project name. In reality an example would look like. For example:
| Code Block | ||
|---|---|---|
| ||
export-TestProject:1.0-Trunk |
where export-TestProject is the project name and 1.0-Trunk is the branch version.
In this article we will use the notation a:1 in the schema of <name>:<version> . 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 to message events.
So having an a unique identity is a good thing, but it also limits the way of deploying models and expanding an application using more than one projectsproject.
With this mechanism By controlling the application ID behavior we are able to fulfil the following requirements:
...
| Tip |
|---|
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 |
| Tip |
|---|
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. |
Behavior
Since R11 the mechanism is as follows:
...
Loading an application
A case that has to be started triggers the application(s) that is/are needed to be able to run.
...
This behavior has a few pros:
- The system doesn't have to poll every time, it can now push
But it also has some cons:
...
Note that this implies that if there are a large number of applications available, it can take some time to determine which application is relevant.
Without options
Without any options the name and version of a case will be matched against the list of all applications. When there is an exact match, that application will be picked.
...
| Cases | Applications | Comments | |
|---|---|---|---|
| a:1 | → | d:1 | case a:1 will trigger:
|
| b:1 | b:1 | ||
| c:1 | a:1 |
Ignore Options
It is possible for every application to configure what should be ignored. You would ignore this version when ... $TODO ...You can configure an application to ignore certain parts of the application ID. You do this to be able to show cases from different applications in one list, or to be able to deploy an application from different branches.
The following ignore options will influence the behavior of loading the matching applications with an application ID.
Ignore setting
| Ignore setting | Description | Match on | Comment | |
|---|---|---|---|---|
none | The default behavior. The full application Id ID is still regarded used by lists and messages. | name and version | This is default behavior like prior to Blueriq 9.6. So no migration is needed. | |
project | Ignores the project name part of the applicationIdapplication ID. This can be used when multiple projects on the same branch share the same process model. | only version | 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. | only name | 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. | nothing | Typically used in a dashboard for DCM applications. |
...
| Cases | Applications | Ignore | Comments | |
|---|---|---|---|---|
| a:1 | → | d:2 | all | case a:1 will trigger:
note that application b:1 will not be triggered, because they don't match on name and on version. |
| b:1 | b:1 | none | ||
| c:1 | a:3 | version | ||
| d:1 | e:1 | project |
Levels
...
Applying the options
The options can be applied on different levels, as well as different components. They are specified in the
| Include Page | ||||
|---|---|---|---|---|
|
Levels
| Level | Description | Comment |
|---|---|---|
ServerGlobal | 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 to 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
...
| to all applications | Default for all applications | |
Project | The settings apply to a specific project | These settings override the global setting |
It is possible to mix these settings, so a global setting and project settings. If for a project a project setting is defined, that one applies, otherwise the global applies.
Components
| Component | Description | Comment |
|---|---|---|
Process engine | Controls which part of the application ID is ignored by the process engine when evaluating timer nodes and handling message events. | |
Process list | Controls which part of the application ID is ignored when displaying cases in Case Lists and tasks in Work Listslists (AQ_CaseList, AQ_WorkList, AQ_Timeline). For backward compatibility, when process list settings are not configured, the process engine settings apply. | This component was introduced in Blueriq 9.8.5. |
...
Rules for process engine
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 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
Configuration
...
| title | Java configuration |
|---|
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.
Configuration
The configuration for the Runtime is applied to
| Include Page | ||||
|---|---|---|---|---|
|
| Code Block | ||
|---|---|---|
| ||
#global setting for the process engine, accepted values = none, project, version, all
blueriq.processengine.default-app-id-ignore-mode = none
#per-application setting for the process engine; format = blueriq.processengine.app-id-ignore-modes.<application name> = none | project | version | all
blueriq.processengine.app-id-ignore-modes.studio-RepositoryName1-ProjectName1 = project
blueriq.processengine.app-id-ignore-modes.studio-RepositoryName2-ProjectName2 = version
blueriq.processengine.app-id-ignore-modes.studio-RepositoryName3-ProjectName3 = all
#global setting for process lists, accepted values = none, project, version, all
blueriq.processlist.default-app-id-ignore-mode = none
#per-application setting for process lists; format = processlist.app-id-ignore-modes.<application name> = none | project | version | all
blueriq.processlist.app-id-ignore-modes.studio-RepositoryName1-ProjectName1 = project
blueriq.processlist.app-id-ignore-modes.studio-RepositoryName2-ProjectName2 = version
blueriq.processlist.app-id-ignore-modes.studio-RepositoryName3-ProjectName3 = all |
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.
Example
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:
...
| language | text |
|---|---|
| title | application.properties |
...
Overview
Content Tools