Page History
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.
Known issues
| Issue | Background information | Severity |
|---|
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.
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 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 |
Limitations or different behaviour
| Issue | Background information | What to do? |
|---|
medium
Unlocking a case is blocked when the reopen task is available. Fixed in Blueriq 15.6Multi-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 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 |
Overview
Content Tools