Page History
| Include Page | ||||
|---|---|---|---|---|
|
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.
| Issue | Background information | Severity |
|---|---|---|
| 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:
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
|
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 |
Overview
Content Tools