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 28 Next »

This is a list of known issues in the current setup. It will be kept up-to-date with the coming releases, until the first customers use the new setup, or migrated to the new setup in a working environment,

Known issues

IssueBackground informationFound in versionFix version

DCM_CaseList and DCM_WorkList

always filter on application-id

Filtering on application-id might not make sense to do when the containers are being used in a dashboard model. Therefore the dependency will be removed in a future version. In a mean time, the property to filter on application id can be ignored by adding this to the application.properties of the Runtime:

blueriq.processlist.default-app-id-ignore-mode=all
15.13 / 16.0

DCM_ReadCase service does not throw right exceptions

When the read-case fails, it sometimes does not flow through the right exit nodes (CaseNotFound, CaseCouldNotBeLoaded). Workaround is to make sure after loading the case that is has successfully done so, by checking on some property to be loaded correctly, and failing in the flow when it has not.

15.13 / 16.0

Development Toolbar is not available on the execute task widget.

When using DCM-Dashboarding, the development tools are not available for the global session and Blueriq sub-sessions. Separate DCM-Widgets can be started using the development dashboard, the developement tools are available there. However, the execute task is a special type of widget, that cannot be started separately.

15.13 / 16.0

Searching cases is not possible

Searching cases is not possible yet. In the old situation, the "AQ_Aggregate_Search" service could be used to search for cases. However, this returns aggregateId's. A new service will be added to search for cases, returning caseId's.

15.13 / 16.016.3

Unexpected model valiation errors at the Case-Engine

Since the Case-Engine runs the same models as the Runtime, it tries to load all services and containers. However, it does not have these definitions in scope, since it is a Case-Engine. At the development dashboard, it will show validation errors. These can be ignored. When the Runtime component shows no errors at the development dashboard, the model can be considered valid.

15.13 / 16.0
IssueBackground informationFound in versionFix version

DCM_CaseList sorting (user and model) does not work

Adding a sorting at the column in the container, or clicking on one of the columns as a user, does not work.

15.13 / 16.016.2

DCM_CaseList and DCM_WorkList

Dossier Metadata does not work

In the new container, a new feature is implemented, the "Dossier Metadata". This is case-type specific data which can be used in lists. However, in this version, the Runtime behaviour is not yet implemented.

15.13 / 16.016.2

DCM_CaseList and DCM_WorkList and DCM_ReadCase

always need a process module in the project scope

The containers always need a process module to work. Also when used in a (main) dashboard application. This does not always make sense. You can use the process module to filter/show columns, but in many cases, you could also use the metadata for that. Therefore the dependency will be removed in the future (it's only needed when process profile is selected in columns). Workaround is to model a process module in each project using this containers (it may be an empty "dummy" module).

15.13 / 16.016.1

AQ_File_Upload and AQ_Generate_Document

do not store the case-id

The uploaded or generated documents should contain the case-id in scope when used. In the Case-Modelling setup, the attribute system.caseid will be used when documents are uploaded during task execution. In the first release this does not work properly, and will be fixed in a future release

15.13 / 16.016.1

All Runtime models should also be available in the Case-Engine

The case-engine relies on Runtime models to work. Since it will load the model when requests are sent to the Case-Engine, you have to make sure that all Runtime models, are also available in the Case-Engine. In a future state, only a subset of the models might be relevant (or even subset of the modules), but for now, the models should be kept the same for both components (either by using exports or the publisher).

Fix: Only the case-type model has to be shared between Runtime and Case-Engine (containing necessary modules for both components). Other projects, like MainDashboard is no longer needed in the Case-Engine.

15.13 / 16.015.13.2 / 16.1

DCM_Lists containers imported/migrated from pre 15.13 versions do not work properly.

In Blueriq 15.13 and higher, changes have been made in the way the lists containers work. ProcessId/CaseId has been changes in CaseId of type Text. New column types have been added for searching the metadata.

It seems that containers that the migrated DCM_ containers from previous versions sometimes do not work in Studio/Encore. This can be fixed to reinitiate the container (change types and back, or create a new one). Since most containers will be build from scratch anyway (aggregate list needs to be changed to caselist), the impact is minimal.

15.13 / 16.0won't fix


Limitations or different behaviour

IssueBackground informationWhat to do?

Multi-valued attributes in the process profile can lead to dead-locks in MSSQL

Using multi-valued attributes lead to complex queries in the database during case evaluation. When depending heavily on multi-valued attributes, it can lead to deadlock issues in combination with MSSQL database during high load.

Avoid using multi-valued attributes in the process profile. Use case-metadata or dossier-metadata instead for filtering/showing cases and tasks in lists. When you use multi-valued attributes in the process-profile, make sure you test the specific solution well, especially when high loads are expected.

Multi-valued attributes and relations cannot be used in the DCM_GetCaseInfo.

In the new set-up, the service call is actually a REST call from the Runtime to the Case engine. Therefore, an interface (in JSON) is needed. Since we cannot just add complex graphs and all kinds of (multi-valued) attributes, they will be ignored for now

Use metadata of the case instead. This data will be loaded during task execution, or can be loaded using the DCM_ReadCase service. This service supports multi-valued elements.
Testpaths do not work on timed events or automatic tasks

Testpaths are session bound, and will be lost when a new session is started. In the new setup, all automatic tasks and timers will be evaluated and executed in their own session (asynchronous), therefore the testpath will not be available.

Testing a DCM application will be a new business case to do further research on what is needed, and how this can be achieved.

The application ID (model version + branch) is stored as item in the process. When the case-model and feature-branch model of any task implementation is similar, then it will use this application-id to proceed. However, it is not possible for now to send the testpath parameter at any other services during an automatic task, since it is lost at the new session.
Priority Algorithms do not work

Priority algorithms are based on the addition of custom code to evaluate priorities at certain moments in time. The Case Engine does not allow custom code. The task field Priority will remain unknown.

A new business case will be added to the product management backlog to investigate the requirements for case and task prioritization.

As an alternative, priority can be modeled and managed as a custom field for a task.


  • No labels

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