Table of Contents

Note
This feature is for DCM 1.0 only

Introduction

This page describes how to manage behavior of the application Id 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 ApplicationId application ID. This Id ID is an aggregation of the branch version and the project name and the branch version. For example:

Code Block

language	text

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 . 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.

Requirements

By controlling the application ID behavior we are able to fulfil the following requirements:

UI Text Box
type
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
type

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.

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

Loading an application

A case that has to be started triggers the application(s) that is/are needed to be able to run. 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.

Settings

No additional settings are set.

Example

Cases

Applications

Comments

a:1

→

d:1

case a:1 will trigger:

application a:1, because they match exactly both on name and on version.

b:1

c:1

a:1

Ignore Options

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 matching applications with an application ID.

Ignore setting

Ignore setting	Description	Match on

SettingDescription

	Comment
`none`	The default behavior. The full application

Id

ID is

still regarded

used by lists and messages.

This is default behavior like prior to Blueriq 9.6. So no migration is needed.

name and version
`project`	Ignores the

project

project name part of the

applicationId

application 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.

Example

In the following example we use all different kinds of settings to illustrate what their effect is.

Cases		Applications	Ignore	Comments
a:1	→	d:2	all	case a:1 will trigger: application d:2, because nothing has to be matched: all versions of d will be taken. application a:3, because with ignoring the version the name has to match. application e:1, because with ignoring the project name only the version has to match. 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

Applying the options

The options can be applied on different levels, as well as different components. They are specified in the

Include Page

	_PropertiesFileJava
	_PropertiesFileJava

for the Runtime.

Levels

Level	Description	Comment

Server

Global The settings apply

for the complete application.A general setting if all behavior for the application is the sameProjectA 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.

...

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

ID is ignored by the process engine when

evaluating timer nodes and

handling message events.


`Process list`	Controls which part of the application

Id

ID is ignored when displaying cases

in Case Lists

and tasks in

Work Lists

lists (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.

The settings are part of the aquima.properties for Java, or are part of the .Net configuration.

Rules

Rules for process engine

When handling 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

Rules for process list

...

When displaying cases and tasks in the the AQ_CaseList and and AQ_Worklist containersWorkList containers, the Runtime uses the following rules to decide which part of the application Id should be ignored in an application A:
check the the `process list` setting setting for application A; if not configured then...
check the global global `process list` setting setting; if not configured then...
check the the `process engine` setting setting for application A; if not configured then...
check the global global `process engine` setting setting; if not configured then...
use use `none` as 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:

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

	_PropertiesFileJava
	_PropertiesFileJava

:

Code Block

language	text

Code Block

#global setting for the process engine, accepted values = none, project, version, all
blueriq.processengine.appid_ignore=default-app-id-ignore-mode = none

#per-application setting for the process engine;  format = blueriq.processengine.appid_ignoreapp-id-ignore-modes.<application name> = none | project | version | all
blueriq.processengine.appid_ignoreapp-id-ignore-modes.studio-RepositoryName1-ProjectName1 = project
blueriq.processengine.appid_ignoreapp-id-ignore-modes.studio-RepositoryName2-ProjectName2 = version
blueriq.processengine.appid_ignoreapp-id-ignore-modes.studio-RepositoryName3-ProjectName3 = all

 
#global setting for process lists, accepted values = none, project, version, all
blueriq.processlist.appid_ignore=default-app-id-ignore-mode = none
 
#per-application setting for process lists; format = processlist.appid_ignoreapp-id-ignore-modes.<application name> = none | project | version | all
blueriq.processlist.appid_ignoreapp-id-ignore-modes.studio-RepositoryName1-ProjectName1 = project
blueriq.processlist.appid_ignoreapp-id-ignore-modes.studio-RepositoryName2-ProjectName2 = version
blueriq.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:

Code Block

<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:

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

...

app-id-ignore-modes.studio-RepositoryName3-ProjectName3 = all

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:

Image Removed

Java aquima.properties

Image Removed

.Net properties

Image Removed

Space shortcuts

Page tree

Versions Compared

Old Version 8

New Version Current

Key

Introduction

Requirements

Functional guideline

Loading an application

Without options

Settings

Ignore Options

Ignore setting

Applying the options

Levels

Components

Rules

Rules for process engine

Rules for process list

Aquima.properties

Warning

Configuration

Work list and case list

Example

Throw message event

Warning

Example

Space shortcuts

Page tree

Page History

Versions Compared

Old Version 8

New Version Current

Key

Introduction

Requirements

Functional guideline

Loading an application

Without options

Settings

Ignore Options

Ignore setting

Applying the options

Levels

Components

Rules

Rules for process engine

Rules for process list

Aquima.properties

Warning

Configuration

Work list and case list

Example

Throw message event

Warning

Example