Exception Management
The Codelet which was presented in the last Tutorial is designed to be able to manage occurring exceptions and execute validation strategies. The main goal is that the workflow doesn’t need to be aborted just because of a failed execution. The workflow designer as well as the user should have the power to configure exeption following activities. There are three main categories in which exception can occur:
1.
The user or the designer refer to a not available RPA script
2.
The user or the designer transfer wrong or invalid datatypes
3.
The RPA script itself throws an exception while runtime
These 3 exceptions occur at different stages of the execution and because of this each one needs an own validation strategy and exception management
Real business cases and abstract models often includes some differences from each other. Because of this there is a possibility of raising exceptions in each scenario. YAWL offers the workflow designer the ability to face these exceptions with so-called exlets. With an exlet you can define rules how to identify an exception and what steps must be done to mange the following workflow. An exlet consists of three main parts – first you have do define what type of exlet you want to configure, second you must configure the kind of exception validation and last you must define the compensation activities. For the first step, there are different types, but the most important one in this approach is the so-called post item constraint violation type. With this you can define constraints which will be validated after the execution of before specified tasks. The activities are used to either lead the workflow to a controlled end or to execute some compensation tasks.
Following I will shortly describe in what cases exceptions are expected
1.1 Chose a nonexistent RPA script
The Codelet itself loads all given paths from the configuration file. Each of these files will be scanned for all classes in them. For every class there is a check wheter this class ist he searched one. If there is no positive validation after scanning all given files there will be an exception thrown. This exception will be catched later.
1.2 Wrong or missing data
Another exception can occur if the stated and given datatype aren’t the same. Before the execution of a RPA script there will be a validation of the data transferred by the YAWL net. This validation relies upon the stated dataypes in the RPA script. A RPA script designer hast to specify wheter there is a need for an input and output and if there is, what datatypes they need. If a validation fails, an later catched exception will be thrown.
1.3 How to handle exceptions at output tasks
It’s a bit tricky to create a correct default output file if there is no information about the datatype because of the generic approach. Because of this it is very important to insert a valid default value for output data types. Fortunately YAWL offers a quick solution for generating such default data.
With this default data it can be guaranteed that even in the case of an exception there will be a controlled response of the Codelet.
2. Exception handling in this example
One of the main benefits of the exception handling offered by YAWL is the decreasing in complexity. You don’t need to configure multiple paths in your workflow for every possible exception. You just must configure how to identify and manage occurring exceptions.
The exception handling in this example is rather easy.
We want to check whether an exception occurred at 2 checkpoints and execute some compensating actions if needed. For this we need 2 steps. First, we need a YAWL worklet, which is a YAWL net, too. This will be executed as a compensation. Second, we need the rule of identifying a exception. For this we use the Worklet Management plugin and add a new rule.
For the creation of the rule a short explanation:
If an Exception occurs while runtime, the Codelet will catch this exception and fill the output parameters for returning valid values. The Codelet fills the both parameters “ExecutionFailed” and “Exception”. ExecutionFailed is a boolean which describes whether the execution failed or not. Exception is a string and shows the reason of the Exception in style of the thrown exception message, so that an user or a designer can reconstruct the failures reason.
With this in mind we can construct the exception management for the first automated task. We choose the Workitem post-constraint-violation as rule type, the SearchItem task as task and the ExecutionFailed parameter as Condition, with which we can check the constraint violation. Last, we need to implement an action strategy. In this case, we suspend the whole case, then we execute a worklet as compensation, which simply shows all present data and the execption message and end the process by removing the case. Different ways of managing the exception are possible here. We could implement a mechanism for starting a new attempt of execution. But at least there should be any kind of information for the user and/or the administrator of the yawl net. There is a similar exception management for the second automated task.
Step-by-step:
1.
Download and extract all attached files.
2.
Start YAWL and the net “CompensatingWorklet”
3.
Load the CompensatingWorklet as a Worklet into the engine “Plugins -> Worklet Management -> Save”
4.
Close the Compensating Worklet and open ForthTutorialSearchItemInOnlineShop
5.
Load the Ruleset “ForthTutorialSearchItemInOnlineShop.xrs” into the net.