When you’re building workflows in VertiGIS Studio Workflow, it’s important to understand how to debug them. Understanding how to debug and troubleshoot issues can enhance your development experience!
This VertiGIS Studio Tech Tip provides an overview of how to test workflows in the VertiGIS Studio Sandbox environment and explains how to use the Network and Console tabs in the Sandbox to spot and troubleshoot errors. It also gives an in-depth overview of the different features available in the Network and Console tabs and explains how they relate back to the workflows you are building.
Video Transcription:
Hey everybody, Patrick here. In this Tech Tip video, we’re going to take a look at how to debug your workflows to improve your overall development experience. Let’s dive in!
We’re going to look at how to properly debug your workflows to make it easier for you to develop them and troubleshoot them when things go wrong or your logic needs to be altered. I’ll highlight some tips and tricks to help you with your journey learning how to build sophisticated workflows.
This is a workflow that I had previously demonstrated in a video. So, if you haven’t seen the Query Layers Tech Tip, I would recommend taking a look at that before you watch this one.
Basically, we have a very basic workflow where we’re getting a hold of a layer within our workflow by referencing the layer name from a layer within our web map – in this scenario, we’re getting a “Water Lines” layer. Then we’re getting the current map extent, doing a query and passing that layer as input. We’re running this query on our Water Lines layer. Here we have a “where” clause which is where we’re going to find all the Water Lines that are of “MATERIAL” type “Cast Iron” and have a diameter “<= 150”. Here we’re restricting it based on the “mapExtent”, we’re returning “Geometry” and we’re returning all of the “Output Fields”. And this last bit here we’re just getting the number of features returned.
You can quickly test these workflows by using the Sandbox environment which I’ve used in a few videos. If we run this workflow, you can see that I can return the number of features. We’ve already started using the “Network” tab to kind of debug the workflow. So, here if we go to the “Network” tab we can look at our header and see all this information there. All you really need to be concerned with is this “Payload” which is the input parameter.
This is our “geometry” which is coming from our map extent. This is the “outFields” and our “where” clause that are being passed to the query. If we look at the “Preview” you can see that this is our response that is being returned. Currently we have “7” features that are being returned as an index of zero. And here you can see these are the “attributes” and the individual “geometry” of each feature.
There is actually an easier way though to digest this information and that’s by using the “Console”. If we jump over to the “Console” tab here you can see that it’s logging all of the individual activities that get fired within our workflow. So, here we can see we have a “GetLayer” activity, here we “GetViewExtent”, here we “Query” our layer, and then here we’re presenting an “Alert”. This basically mimics the back end of the workflow. It’s showing each of the activities, what the inputs are, and what the outputs are. If we jump back to the Sandbox, we can take a closer look at this.
To get this logging, there’s a couple of things you need to do. What you need to do depends on the browser that you’re using. Here I’m using Chrome. If I go to the “Console” tab, there’s this “All Levels” section. You’re going to want to ensure that you enable “Verbose” logging. Once you have verbose logging enabled, then you should be able to retrieve more fine-grained activities within your workflow as you run it.
Each activity is also going to be run twice or will get logged twice. That’s because the first time it’s run it’s going to show you what the “inputs” are. For example, with the “GetLayer” activity there’s this “layerID” input parameter. If we jump over here, we can see it’s called “Layer ID” and here I’ve supplied “Water Lines”. The second time you see this log, you’ll get both the “inputs” and the “outputs” of everything that’s available.
Here we can see it’s been successful because we’re getting an “output” “layer” and within this layer there’s all of these other properties that you can pull from within Workflow.
In our scenario, for our Query Layer activity, we just passed this entire “layer” object as input. But we could also drill down and reference, for example, the “id” of the layer or the “name” of the layer. Or potentially even the “url” which is pointing to the rest endpoint of that that layer. So, there’s a whole number of different elements in here that you can pull from using Workflow.
I’m just going to minimize this because it’s a little overwhelming when you first see it. If we continue to scroll through, we can see that this is our “GetViewExtent” activity. This one doesn’t have any inputs; it will just give you the map extent or the center point or current scale. And these are the properties that are available.
I always like to look at the second listing of each activity because it’s designed to include both the inputs and the outputs. If we look at our inputs here, we can see that this is our input “geometry”, which is coming from the map extent and being passed as our input geometry parameter.
This is our input “layer”, our “outFields” are set to “*”, our “returnGeometry” is set to “true” and the “where” clause is being included.
If we look at our “outputs”, this is the output response of that query. This is where we can drill into each individual feature and see the individual attributes and the geometry. So, rather than having to use the Network tab, everything that you need is included in the Console. This makes it really easy to debug and troubleshoot your workflows.
It’s also worth mentioning that within “features” there’s this “length” property. If we hover over it you can see it says “outputs.features.length” and it’s equal to “7”. When we run the workflow, we’re also getting “7”. So, you can also use the console to determine what properties are available and then retrieve those.
If we jump to the Workflow tab here, you can see and expand this “Alert”. You can see here that we’re going “query1.features.length”. It’s also worth mentioning that we don’t always display every single property available. In this scenario, we’re displaying the length, but, for example, if I go into the “layer” object and add a period, we’re only displaying four different properties like the “id”, the “opacity”, and whether it’s “visible”. But if you jump over to the console and expand our “layer” object you can see that there’s a whole ton of other properties available.
So, for example, if I wanted the URL I could go ahead and do “layer.url”. If I click “OK” and rerun this, you can see that here we’re getting the URL for the feature service. You’d also have to add an ID onto the end of it. Here you can see we’re going into the “layer” list, and if we scroll over that URL property, it’s going to be “outputs.layer.url”.
Hopefully that gives you an overview of how you can use the console as well as the network tab to troubleshoot and debug your workflows.
What happens if you accidently make a mistake? Let’s change this to “Water Line” and rerun it. You’re going to see that it’s giving us an “undefined” warning. If we look at our “inputs” tab we can see that the layer input is undefined. If we look at our “GetLayer” activity, we’ll see that our “inputs” are here but there’s no “output” layer being returned. This allows you to rework and rethink your workflow to then go investigate and see that you accidently set it as “Water Line” when it should be “Water Lines”.
We’ll go back and update that, clear our console and rerun it, and now we can see now our “Water Lines” “input” is returning a “layer” and our “QueryTask” input has that layer.
Hopefully that gives you a quick overview of how to use the console to better troubleshoot and debug your workflows. Thanks for watching!
Want to learn more about the capabilities of VertiGIS Studio Workflow? Click the button below for more information on what is possible with VertiGIS Studio Workflow.
Contributors