YAWL User Group

(At the moment Windows only, bug under Linux will be fixed)

Attached files:

1. The Jar which contains the generic Codelet “SeleniumRPAForYAWLFinal.jar”
2. The GeckoConfig.xml which contains the path to the WebDriver and paths to RPA scripts packed within “.GeckoConfigYAWL”-directory
3. The YAWL-net “ThirdTutorialSearchItemInOnlineShop"
4. The two RPA scripts BuyItemRPA.jar and SearchForItemInShop.jar
5. The Codelets and RPAs source code
6. The YAWL organizational data "YAWLOrgDataExport"

1 Motivation

In today’s tutorial you will see an approach on how to automate business process with YAWL and Selenium with an interface, which offers the ability to transfer individual datatypes and manages exceptions. You will get an idea of the possibilities that lies in such an approach. For this tutorial I provide you a workflow net with two RPA scripts. You will be able to search for items in an online shop an decide whether you want to put them in a basket or not. The example itself isn’t the most complicated but it will show how to integrate Robotic Process Automation into YAWL and on what points you should keep attention. The main idea for this whole approach is to use a single Codelet to integrate multiple RPA scripts through the config file which was introduced in the first tutorial.

The workflow itself is like I said before rather simple. You insert some data to search for in the web shop, after you complete the search form an agent will be executed which searches automatically for an item with the given text. If it found some, the first will be chosen and the price as well as the name will be returned into the net and displayed. If no item was found, this will be displayed, too, and the workflow ends. In case of a returned item, you can decide whether to “buy” this item or cancel the process. For the buying task a new Robot will be executed, which puts the item into a basket. Mind that this is only a mocked web shop, so you don’t run danger into buying anything.

2 Difference in detail

At the first expression this approach doesn’t differ much from the one in the first tutorial except that two different Robots were used, but this impression is wrong. In the background are many steps for data transfer, validation and exception handling done.

But let’s get this done from bottom up. One of the main advantages of this approach is, that you can transfer your individual XML data types to an Robot.

In this example I defined two data types through the data type definition manager in YAWL. I defined an output datatype for returning the items attributes and an input data type for inserting a name to search for. This could be stretched far more out, like giving a max or min price or a color the item must have. A defined data type can be used as an net or task variable.

Like stated in the Codelets description there are some provide and some custom inputs and outputs. If you chose the Codelet to automate a task you must configurate the input Variables “RPAScriptName” and “GeckodriverPath” as well the output Variables “ExecutionFailed” and “Exception”. RPAScriptName is the Codelets input parameter to identify, which of all available Robots you want to execute at this task. GeckodriverPath was already described in the first Tutorial and is used if you don’t want to configure the path of your driver beforehand. Exception and ExecutionFailed are used to handle occurring errors in the net itself. They can be used to execute some compensating actions, so you get a controlled feedback why there was an abortion instead of just a runtime exception. But the exception management will be discussed in detail in an later tutorial.

CodeletInput and CodeletOutput are a bit tricky variables. They aren’t necessary if your wished Robot doesn’t need them. In fact, you are supposed to act carefully that you provide these two only if they are needed, because this will be validated in the Codelet and can led to an Exception if done wrong. The Codelet is able to recognize every valid data type and transfer it to or from the net to the robot as long as you set the variables type as the datatype and give the Robot a hint of the type (see below for more information). Very important here is that you give a default value, if you need an output. This default will be used in case of an exception because if you define an Output YAWL does always except one. In the second automated task, where the robot puts the item into a basket there is no output but an input.

The RPA script must extend the supertype AbstractSeleniumScript which is provided as a jar file. This forces you to implement some methods, to specify whether the robot needs input/output and which types. Please note that the whole validation inside the Codelet can’t be done if you don’t work accurate on this. The stated input/output type must be the same as in the net. If you work properly you can use the Information given in your Script. For this there is the class “XMLTransformer” provided, which transforms the transfered XML-String into a jdom Element, which can be read in runtime, or transforms a jdom Element back to a String for returning data.

The returning inside of a Robot is a bit tricky, therefore here a cutout of the searching Robot

        Element result = new Element("result");

        result.addContent(new Element("ItemNameResult").setText(itemName));

        result.addContent(new Element("ItemPriceResult").setText(itemPrice));

        result.addContent(new Element("ItemFoundResult").setText(("" + itemFound)));

        return XMLTransformer.XMLtoString(result);

There is  also provided a class for easy Webdriver creation which is called “WebDriverFactory”. With this you can just generate a new instance which is already configured with a profile and can handle waiting times, but feel free to try your own webdriver configurations here.

You’re asking yourself now how to integrate those RPA-Scripts into YAWL? Its pretty easy, you just have to compile a Jar-File with the RPA-Script file, Abstract-Selenium-Script file and if needed the XML-Transformer file and the WebDriverFactory. As soon as you compiled this Jar file you can write down the path in the config file, which was introduced in the first tutorial. This config file inherits the path of the Geckodriver for the WebDriverFactory as well. 

3 How to get this working

I showed you roughly how this approach works. If you are more strongly interested in the source code behind, you can explore the attached files. But more interesting then why this approach works is how this approach works. So, let me list down the steps you must do to get this example working. If you already did the first tutorial you can skip some steps.

1. Load and extract all attached files.
2. Set your environment up like presented in the first tutorial (Especially the config-XML-File, the Geckodriver and the organizational data).
3. Put the RPA-Jars (BuyItemRPA.jar & SearchForItemInShopRPA.jar) in a directory and put the paths into the Config-files <FilePath>-Elements.
4. Put the SeleniumRPAForYawlFinal-Jar (in which the Codelet lies) into your Codelet directory like described in the first tutorial. Like the Codelet of the first tutorial this Codelet should lie in a directory called Codelet, too. For example: "codeletRootDirectory”\codelet\SeleniumRPAForYAWLFinal.jar – where the “codeletRootDirectory” is the path which was set in you web.xml-file.
5. Check if the tasks “SearchItem” and “BuyItem” are automated (green arrow in task symbol)
6. Start a new case and execute it

If you set up everything right the workflow should run properly now.

 4 What did we get?

With this approach we got some nice advantages. First, we need only one Codelet and can now integrate and replace multiple Robotic Process Automation Agents in runtime without stopping the YAWL Engine which is a huge benefit. Further we have a way to transfer individual data types into and out of the Robots while we can validate the data. Last, we have a Way to manage Exceptions properly, which will be discussed in the next Tutorial.