Inspect Process Data with Attended Tasks

Debugging executable processes can be a challenge because, unlike DMN models, you cannot test them in the Modeler. You need to compile and deploy them first, and problems are often reported as runtime errors.

Until fairly recently, to zero in on the problem you needed to isolate it in a small fragment of the process by saving various fragments as test processes, compiling and deploying them, and running them with reconstructed input values. But earlier this year, Trisotech made it a lot easier with a new feature called Attended tasks. Attended tasks are a Trisotech extension, not part of the BPMN spec, but very useful in practice. This post shows how they work.

An automated task, such as a Decision task or Service task, that is marked as Attended allows its input and/or output data to be inspected and possibly modified by a user, either before or after the task runs. Attended tasks originally were introduced not for debugging but to support customers in Healthcare. While highly interested in technology and automation, Healthcare providers often want to confirm the values provided as inputs to automated tasks in order to correct them for the latest values observed, as some of the data fetched may come from an earlier encounter or may need to be adjusted based on the latest live observations. On the output side, providers want to be able to overwrite an automated decision for various reasons. Based on their own experience, they may disagree with the automated results, or may believe that certain details about the case were not properly considered in the automated result. Trisotech was seeking a way to ensure that a clinical pathway could remain the same for review, whether or not pre and/or post validations were required. By using Attended tasks, the same clinical model can introduce or remove data validation without having to modify the model for all possibilities of the Healthcare context.

My own experience with Attended tasks is not in Healthcare is focused more generally on the debugging problem. Marking an automated task as Attended acts as a “breakpoint” in the automation where the user – typically the process designer in this case, not the end user – can inspect process data at design time to better understand unexpected results. To illustrate, let’s look at a variant of the Vacation Request process in the Trisotech EU-Rent repository.

Employee Vacation Days is a table from the HR system, listing each employee with their accrued vacation days. Data input Vacation Request specifies the requesting employee’s name, id, and proposed vacation start and return dates. Script task Fetch Vacation Information extracts the employee’s record from Employee Vacation Days and passes it to the Decision task Approve Vacation Request, which could either approve the request, refuse it, or refer it for human decision. That’s pretty simple. Nothing much could go wrong here, right? But when we test it from the Service Library, we see a problem. The Decision task Approve Vacation Request failed with a runtime error.

We can mark that Decision task as Attended to take a look at what is going on. When we do that, we see this dialog:

This dialog lets us specify where we want to put the breakpoint: before or after the input data mapping, and/or before or after the output data mapping. Since this task is failing, we want to inspect the data before the input data mapping, which is the output of our Script task. If we want, we can enter the name of a process user as a Resource, who will receive the data in an email and can return corrected values. You would use that when the Attended task is a permanent feature of the process, as in the Healthcare context. But when using Attended tasks simply for debugging, we can leave this Resources field blank, as the user will see the data in the Service Library test interface. So our configured Attended task dialog looks like this:

Now in the process diagram, the task is marked as Attended with a little checkbox.

When we Save, Cloud Publish, and test, we see this:

The process has paused at the Decision task input mapping. We can inspect the data input and then click the link Verify data inputs.

Now we see the cause of the problem. The data object Current Vacation Status – the output of our Script task – is null. Even though this example is simpler than most you will encounter, the root cause of the problem – some data object is null – is far and away the most common cause of BPMN runtime errors. In real-world process models, it usually boils down to pinpointing which data object has the problem, and Attended tasks let you do that.

The Script task is just a simple filter of the Employee Vacation Days table. If no entry in that table matches the employeeid value of the Vacation Request, Current Vacation Status will be null, and that’s exactly what happened. Most likely the employee entered the wrong value for his employeeid. That certainly could happen, even though our original model did not consider the possibility. But we still need to fix our process so that we don’t get a runtime error in that case. To do that, we can just test for null in a gateway and exit to the end state “Employee not found”.

Now the process runs with no runtime errors even when Vacation Request.employeeid is not found in the HR system. Thorough testing of executable BPMN models is a must, as you cannot assume that only “good” input data will be provided. If you haven’t considered some possibility, no matter how unlikely it seems, sooner or later it will occur. When that happens, Attended tasks make it a lot easier to track down and fix the problem.