Share This:

Of course services are supposed to work correctly. After all, you designed them yourself, put a lot of thought into them. You did your homework and it shows: they look the way you want them to and they create work orders to set up new PCs, for example, or alert teams on infrastructure changes, initiate onboarding processes, even book your holidays requests.  You might even have the questions translated into various languages, from Welsh to Chinese. But something has gone amiss. The work order records are created, but they always show up with the wrong status. You check again, it’s definitely not you, everything looks right. What could it be? The whole service is down, and fixing it is time-critical. Tick tock.


Luckily for you, Catalog is pretty good at telling you what’s happening to those services your users are creating. I would maybe even go as far as to say that it’s really good at it. If your tool-of-choice is SRM you know that logs are difficult to avoid. The wrong status shows up in your request? Start with the combined SQL, API and Filter logs. Requests get stuck? Give me the combined SQL, API and Filter logs. The value for the Summary field not populated correctly? SQL, API and Filter logs will tell us why.


Is this any better in Catalog? As a matter of fact, it is. Logs have their place but it's not the place you start in Catalog. Not convinced? Let’s have a look. The core of your service is the workflow, this tells you how the questions provided by the end users are handled and, more importantly, how the backend process is fulfilled. This is where the work order records and incidents are created. Here’s my workflow:


myit-sb_Phaser bank alignment request (3).png


Looks pretty good, right? If my phaser banks are not aligned properly, my service will make sure the right team gets engaged straight away. Let’s create a request for the phaser relay on deck 47A:



dwpc blog 2 s 2.PNG


According to my workflow a few things should happen: a work order record should be created if the priority is deemed low or medium. If it’s high or critical a record should be submitted to the external senior command system for further evaluation. But there’s something going wrong here, when the work order is cancelled, the Catalog request does not reflect this and is still stuck in In Progress.


dwpc blog 2 s 3.PNG


How can you work out what’s happening? You need to look at the flow and understand how the service requests are handled. But the first step doesn’t have to be logs, it’s handled differently in Catalog. First things first, let’s have a look at the report with all the recent requests:


dwpc blog 2 s 4.PNG


Now go to the Actions menu and click on View Process. This will show you the workflow it’s currently processing. Here’s mine:







The activities with a dark grey border have been processed successfully, the activity with the green border is where we currently are. We can easily see that it informed the security maintenance team, then navigated the gateway to create the work order. This also was successful, but it’s still stuck at Wait for Completion.

This now allows me to see what values are passed between the activities. If I click on Create Work Order I can see the output:


  "instanceId": "AGGAA5V0FLH5PAP9WE46P8ZAJTDPZ3",
  "requestId": "000000000000611",
  "workOrderId": "WO0000000001016"


It’s creating the work order record correctly and looking at it I can see it’s already cancelled, so I need to look at the workflow in more detail. The Wait for Completion construction is basically a loop which pauses the workflow until it meets the condition. So let’s have a look at the variable that’s used for this. I can do this via the tab with the gear icon:


dwpc blog 2 s 6.PNG


That should match my condition. Let’s go back to the original workflow and double check this:


dwpc blog 2 s 7.PNG


So there’s our problem, my condition used the American spelling (one L) whereas ITSM favours British spelling (two Ls). It never meets this condition so we’re stuck in the loop.


I realise this is a fairly straightforward root cause but I hope you appreciate it didn’t take us long to find it. Using the graphical overview of the workflow process we quickly established the flow and the point where it got stuck. From there onwards we were able to work out what the various variable values were which allowed us to concentrate on the reason why it’s not progressing.


But what if looking at the workflow isn’t enough? What if this doesn’t explain why it’s not processing? What if you need to go deeper? There’s always the option to go through the logs. Catalog’s main log file is bundle.log which is generated in the db folder. This will record the service requests from DWP with all the values but it won’t track the workflow process. So you can find the JSON code generated by the DWP request with all the values and the ID of the request but not what’s happening afterwards. It will however record any exception that might occur. We are planning to introduce some dedicated process logs in a future release which will allow us to track the workflow processes via logs. As soon as this is available I’ll dedicate another blog article to debugging your workflow processes via logs, so stay tuned!


But at least I hope this gives you some idea how to get started when there’s a problem with the workflow processes. The visual approach allows you to quickly assess the point where its stuck before you drill down into more details. So the next time your services don’t quite behave the way you expect them to, you know where to look. And if you’re stuck? Well, you just have to give us a shout.


Best wishes,