Here we will learn a bit about how to debug
Workflows using both the
Xyna Process Modeller and the
Xyna Process Monitor.
After we deployed our "Add New Car" Workflow and others could use it, someone reported that it was not returning a null "Car" data object when a required input variable was missing. We can use both the modeler and the monitor to debug the problem.
|
When a Workflow is executed by the Xyna server, each execution gets a unique number called an Order ID. The Process Monitor application allows you to check on running or completed factory "Orders" (processes, Workflows). There are different sections for various tasks like looking at the results of a Workflow, managing tasks which require manual intervention, etc.
More information about the Process Monitor can be found under Process Monitor.
To open the Process Monitor, you can click on "Process Monitor" at the top of the browser window. We can also jump into the monitor directly after running a test in the modeler using the Workflow Tester.
Let's see how to debug our Workflow.
|
|
Open the Process Modeller and then open our "Add New Car" Workflow. Open the Context Menu and choose "Test Workflow". Type a value in the "Make" variable, but leave the "Model" variable blank or undefined.
Click on the "Launch and wait" button. You can see in the results that the input "Car" values were returned, but it should have been a null "Car" Data Type.
|
thumb
|
|
In order to see what happened as our Workflow ran, we can click on the Order ID which takes us into the Process Monitor application with the Workflow we just ran open for inspection.
Here we see our Workflow similar to what we see in the modeler. The paths that the Workflow took for this execution are dark and where it did not go is greyed out. So we can see that the Workflow did indeed go through the step where we set "Car" to null.
|
thumb
|
|
So why wasn't our returned "Car" null? To find out what an output data object is taken from, we can click on it. This shows us the connection link for the output came directly from the input and not from the Mapping where we set a "Car" to null. Here's why...
Each Mapping, Service, or Sub-Workflow has input and output data objects. The output is not directly linked to any previous input. To allow our Workflow to return either the input "Car" or the null "Car", we need to change the "Store new car" output from Storable to "Car" so that both the true and the false branches of the Conditional Choice have a "Car" at the bottom. Then we can return this bottom "Car" - thus picking up the end result of whichever branch the execution took.
|
thumb
|
|
To do this return to the Process Modeller. Then simply drag a "Car" Data Type onto the input and output Storables. This is possible because Storable is the base type of "Car".
Notice that there is now a "Car" data object at the bottom of our main Conditional Choice. This means that no matter which path the Workflow takes, the end result will have a "Car" which we can return.
|
thumb
|
|
|
thumb
thumb
|
Note that our whole Workflow output "Car" is now yellow. This is because there are now two choices for where this output comes from: either direct from the input "Car" or from the "Car" at the bottom of the main Conditional Choice.
Also note that in the right sidebar, there is now a red dot at the issues  button. The number in the red dot tells us how many things in our Workflow need to be fixed or resolved before we can deploy the Workflow.
We already know that we need to link our output "Car" data object to the correct "Car" at the bottom of the main Conditional Choice. Click on it to link it there. Notice that the red dot is no longer there since there are no more problems.
Click on the save and then deploy buttons in the left sidebar.
Our Workflow is now fixed and ready for testing. Click on "Test Workflow" in the context menu, type in some values but leave one of Make, Model, or VIN blank or undefined. Click on "Launch and wait" to test execute the Workflow.
|
thumb
|
|
Looking at the results of our execution, we find no output. We can use the Process Monitor to try to figure out where or why.
Click on the Order ID to switch us into the Process Monitor application with this Workflow as it was just executed.
|
thumb
|
|
By looking at the Workflow, we see that the false branch was taken and the "Set Car to null" Mapping was executed.
If we click on the bottom of the whole Workflow, we can see that it has input values, but it's output values are missing. We can guess that trying to return a null "Car" is causing a problem. So we can not return a null "Car" as originally planned.
|
thumb
|
|
After talking to the front-end developer, we decided to return a null or blank "Car.Model" member variable instead. This will allow us to communicate this "missing data" error to the caller.
Our fixed mapping in the false branch should now look like this.
Don't forget to change the Workflow documentation at the top of the Workflow to document this minor design change.
Now we can test our Workflow with various input values to make sure all logic possibilities are tested. When all tests are successful, we can hand over the Workflow to the front-end for integration and further testing.
|
thumb
|
This marks the end of the First Steps set of tutorial pages.
First Steps
