Page History
...
At the task mapping, the task from the process is connected to the flow implementation, there is no need to map events back to the process, since we have not defined any "flowing" events in the process. The last thing Then we should add is select the right datamapping. This datamapping serves for the Case-Engine to update the process state with any new information after finishing the task. Usually there is one datamapping definition that is used to perform a datamapping after a task.
The last step is to update the datamapping we've just selected in the task mapping. Since a precondition has been added, the process should know the value of this precondition after each finished task. Open the mapping, and map the precondition attribute from implementation to the process module.
Modelling an automatic-task
1. Determine (sub)goals
Similar to the user-task, the task you want to add probably serves a purpose in getting closer to the goal. So it can make sense to start with modelling what you want to achieve with the task. Does the data I add to the case make a milestone true? Does it add to one of the subgoals of making a milestone true? This can be added in the Process domain module (in the implementation). For example to complete the milestone that the decision has been communicated, the system should notify the applicant. The fact that the notification (email) has been sent could be one of the subgoals, and can be added on the rule to check whether this milestone is true.
2. Add task precondition
Similar to the user-task, we should determine when our new task is relevant for a user to execute. Since we only want to bother users with necessary actions when it is needed to reaching the case goals, we should determine when it is relevant. This can also be added to the Process domain module (for example in a "Preconditie.<TaskName>" attribute). The actual rule for this added boolean can be modelled in the Process domain derivation module, since this module can access the case-dossier. In our example, the task of notifying the applicant could be relevant when the decision has been made (and confirmed), and the notification has not yet been sent.
One important difference to the user-task, is that the system-task is being executed by the system with almost no delay. So be careful at determining the precondition, since a loop is easy to make. When, for example, the result of the task is not used in the logic of the precondition well, it could be that the precondition remains true after the first try, or second try, or third try, etc. It is customary to check whether the service (like sending the email) went ok, but is also tried once. Some pattern like, adding an attribute in the dossier: "applicantNotified" which is unknown by default, but is set to FALSE when something went wrong. In this situation when it is unknown, the automatic task is relevant, when it is TRUE the (sub)goal has been met, and when it is FALSE, you should recover from some form of error.
| Info |
|---|
Note that the Case-Engine determines in each step which precondition is true and which is false. Make sure the same task is not repeating itself when you don't want to, by setting up your derivation well. Also keep in mind error situations. When the service responded, but did not lead to the goal of the task, you could choose to derive the precondition to be false, and add a second (manual) task to recover. |
When a technical exception occurs, the precondition will not be predetermined. The message will enter the retry mechanism, so tried for example 3 more times, afterwards, it will be sent to the DCM-Maintenance-APP for manual recovery.
3. Add task implementation
In the task implementation module, a flow can be added where the actual work is done by the system. The complete dossier is retrieved at starting a task. When the task is completed, the new case-dossier state is sent to the Case-Engine to be processed. The dossier is retrieved and sent using the aggregate model of the case-dossier, so make sure this definition holds all information.
| Info |
|---|
case-dossier is shared between Case-Engine and Runtime by its aggregate definition. Make sure the models loaded in the Case-Engine and Runtime share exactly the same aggregate definition. |
The task implementation should not contain any user-interaction, so no pages. The task is performed by a Blueriq Runtime (read from the queue)
After the user-interaction, the flow can end with a "Commit".
Most likely is the commit, where the altered dossier is sent back to the Case-Engine, where the Case-Engine stores it, and determines what to do next.
When no exit is reached (due to a technical exception for example), the task exits with an exception. The lock remains (since the task should processed before anything else), and no data is stored. The task is retried using the DCM-Maintenance-APP, after a few retries it will be added to the failed events list in the DCM-Maintenance-APP for a maintainer to be fixed.
The Rollback exit aborts the task for you, which is strange in the context of an automatic task, since it will not be retried until some other action has taken place. So the Rollback should be avoided using automatic tasks.
4. Add task definition in the process
Since the implementation side is finished, we can now turn to the process module. A task definition should be created using a sensible name (this is for example seen in the timeline later on). The task should be modeled on a process line, so make sure the "ok" event is modelled in the task definition.
The created task should be added to a sub process, with one starting point, the task, and one exit. The sub process should be added to the right phase as an ad-hoc process, with the precondition of the task added as a precondition. This means, when the sub process becomes relevant, the automatic task is triggered, finished, and determined what is relevant afterwards.
5. Connect implementation and process using the configuration module
Now that the implementation has been created, and the process has been modified, we should connect the two models. In a configuration module we should extend the task mapping with our new task. By doing this, the Case-Engine knows which flow to start when the user tries to start the task.
At the task mapping, the task from the process is connected to the flow implementation. Map the taskflow exit event to the "ok" event in the task definition, so the process knows what to do after task execution. Then we should select the right datamapping. This datamapping serves for the Case-Engine to update the process state with any new information after finishing the task. Usually there is one datamapping definition that is used to perform a datamapping after a task.
The last step is to update the datamapping we've just selected in the task mapping. Since a precondition has been added, the process should know the value of this precondition after each finished task. Open the mapping, and map the precondition attribute from implementation to the process module.
What is happening?
The models have been changed correctly, but the task is not visible in the list for the right user.
...
| Info |
|---|
Process state is derived and set after each task execution. Make sure when the model is changed, to run some task on a case you want to see the changes on. This can be achieved by throwing a message event and performing an automatic task afterwards (with either a dossier migration, or an empty flow to just make sure the new dossier + rules are sent to the Case-Engine). When developing without any production cases, it is probably easier to just create new cases after reloading the models. |
The models have been changed, process elements are deleted, the cases that were already created are not working anymore!
The process state of any case in progress is stored in the database. This can be reviewed in the DCM-Maintenance-APP:
The Case-Engine looks for ALL tasks with the status open or started when evaluating what to do next. So make sure you only delete elements when there are no cases left in your production environment with this task/listening event/timer with the status open or started. When you do, the Case-Engine cannot determine a next state and does not process your action. When you want to delete an ad-hoc task, make sure you set the precondition to false first, and migrate all cases. When there is no case left in production with an open task-status, you can delete the task from your process definition.
Overview
Content Tools