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
Issue
Background information
Found in version
Fix version
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
Issue
Background information
Found in version
Fix version
Multi-valued attributes cannot be mapped from the process profile to the Runtime session DCM_GetCaseInfo
The DCM_GetCaseInfo service can be used to retrieve Case information to a Runtime Session. One of the functionalities is to perform a data mapping from the process module scope to the Runtime session. This can only be done using single-valued attributes. Especially to support mapping back information from message-events (where some multi-valued attribute could be sent to the process module), this functionality could be usefull. In other situations, data is normally already a known in the dossier.
15.13 / 16.0
16.6
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
16.4
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:
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.0
16.3
DCM_CaseList metadata ignores valuelists
On the CaseMetadata definition you are able to use valuelists (custom metadata in the aggregate definition of the case metadata). The valuelist is being ignored in the list, only showing the technical values. Note that the Metadata definition is a shared definition, but the dossier metadata is not. Therefore valuelists in the dossier-metadata will always be ignored.
15.13 / 16.0
16.2
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
16.2.1 / 15.13.5
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.0
16.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.0
16.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.0
16.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.0
16.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.0
15.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.0
won't fix
Limitations or different behaviour
Issue
Background information
What 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.
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, they will be ignored for now.
Prevent using relations in the process module, since it should not be necessary in the first place.
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.