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

Case-Modelling has been in beta stage in the Blueriq 15 major. At the latest minor, all Blueriq 16.0 changes have been merged back to Blueriq 15.13. From this point on Case-Modelling is out of beta and can be used.

Please make sure to upgrade to at least Blueriq 15.13 when using Case-Modelling, possibly in a production environment. Earlier minor versions are not supported.

The beta version will be a first version which can be used by everyone on a development or test environment. Some items will need attention before the new architecture can be used in a production environment. A list of issues or points of improvements is kept up-to-date below. Some issues will be blocking for any production environment, some will be improvements which might be added later in time.

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

A service will be added in Blueriq 16, so migrating to this major might be the best solution in the future.


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.

low (won't fix)

Maintenance-App restore endpoints could lead to cases getting stuck

The maintenance user has several endpoints to restore errors on a case. However, endpoints sometimes work only when the case is in a specific state. For example, the "reopen task" endpoint only works when the case is still locked, so when the lock has been deleted by another restore endpoint, the case cannot be restored ever. We need to make sure restore endpoints can only be applied when they could fix the case, instead of breaking the case.

Examples:

  • unlock case endpoint is only applicable when there is no started task, or failed message event for this case
  • reopen task is only applicable when there are no failed messages in the queue (a completed task event could never be processed after the task has been canceled)

A different approach would be to include all actions, so the "unlock case" endpoint would cancel any started tasks, making it a bit less evident what the endpoint is really doing.

medium

(tick) Unlocking a case is blocked when the reopen task is available. Fixed in Blueriq 15.6

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

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

low
Priority Algorithms don't 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.

low