You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.
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 | Found in version | Severity |
|---|---|---|---|
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. | 16.0 | Low |
DCM_CaseList and DCM_WorkList 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). | 16.0 | Low |
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 | 16.0 | Low |
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). | 16.0 | Low |
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 | 16.0 |
Limitations or different behaviour
| Issue | Background information | What to do? |
|---|---|---|
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 info, of 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 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. |
Overview
Content Tools