You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »


Introduction

This page describes the mechanism of loading the right case with the right application in Blueriq so that it is possible to:

  1. Deploy from different branches without breaking the runtime application.
  2. Have lists that show cases and tasks from different projects.

Processes are made unique in Blueriq by a so called application ID (applicationId). This ID is an aggregation of the branch version and the project name. In reality an example would look like:

export-TestProject-1.0-Trunk

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

With this mechanism we are able to fulfill the following 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.

Behavior

This behavior is different to how it previously worked! Before R11 clicking an application determined what case could be run. The drawback of this approach was that it needs a polling mechanism.


Since R11 the mechanism is as follows:

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

  • Determining which application is relevant for a specific case might take longer.

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
ApplicationsComments
a:1


→

d:1

case a:1 will trigger:

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

Ignore Options

It is possible for every application to configure what should be ignored. You would ignore this version when ... $TODO ...

The following ignore options will influence the behavior of loading the application ID.

Ignore setting

Ignore settingDescriptionMatch onComment
noneThe default behavior. The application Id is still regarded by lists and messages.name and versionThis is default behavior like prior to Blueriq 9.6. So no migration is needed.
projectIgnores the project name part of the applicationId. This can be used when multiple projects on the same branch share the same process model.only versionThis setting was introduced in Blueriq 9.8.5.
versionIgnores the version part of the application Id. This can be used when models are deployed from different branches.only nameTypically for deploying from hot fix branches and different deployment strategies.
allIgnores version and project name from the application Id. This can be used when there are pages that wants to collect information from different projects.nothingTypically 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
ApplicationsIgnoreComments
a:1



→

d:2all

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:1b:1none
c:1a:3version
d:1e:1project


Levels

It is also possible to determine on a higher level how the mechanism should work in general, so this is then for applications overall.

LevelDescriptionComment
ServerThe settings apply for the complete application.A general setting if all behavior for the application is the same
ProjectA 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

On top of all properties we have the following:

ComponentDescriptionComment
Process engineControls which part of the application ID is ignored by the process engine when evaluating timer nodes and handling message events.
Process listControls 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.This component was introduced in Blueriq 9.8.5.

The settings are part of the application.properties for Java. 

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:

  1. check the process engine setting for application A; if not configured then...
  2. check the global process engine setting; if not configured then...
  3. use none as default

Rules for process list

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:
  1. check the process list setting for application A; if not configured then...
  2. check the global process list setting; if not configured then...
  3. check the process engine setting for application A; if not configured then...
  4. check the global process engine setting; if not configured then...
  5. use none as default


Configuration

The configuration for the Java Runtime is done in application.properties:


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

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

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

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:

application.properties
# global setting, accepted values = none, project, version, all
blueriq.processengine.default-app-id-ignore-mode = none

# per-applicaton setting; format = blueriq.processengine.app-id-ignore.<application name> = none | project | version | all
blueriq.processengine.app-id-ignore-modes.studio-ACO-First = all
blueriq.processengine.app-id-ignore-modes.studio-ACO-Second = all





  • No labels

Didn't find the answer you were looking for? Try the advanced search!