SharePoint 2013: Workflow Debug/Diagnosis

In SharePoint 2013, new workflow model introduced. Now the workflow runs in different servers (or farms) and SharePoint communicates to the workflow server via REST endpoints. This is really scalable and decoupled architecture but it brings new challenges for workflow developers. Now debugging is not so easy as it was before with SharePoint 2010 workflows. Still you can develop/debug SharePoint 2010 workflows in SharePoint 2013 but it’s not recommended anymore. I’ll explain the techniques you can use to debug your workflow. If the workflow fails to run you will find the workflow error like HTTP 500 or Internal server error. You need to find out by yourself what went wrong. Till date, Workflow doesn’t have inherent functionality to trace the requests though as per this forum post, Workflow team is working on some tracing tools for next version.

Now let me describe few external tools/techniques you can use to diagnosis your workflow.

Event Viewer

Windows Server running workflow service can trace workflow manager and service bus activities. By default the Analytic and debug log for workflow manager is disabled. You can enable the event viewer and see what’s going on under the hood. You can find out details on how to enable the event viewer in the link: http://technet.microsoft.com/en-us/library/jj193526

 

HTTP Traffic Tracing

You can use some HTTP packet traffic tracing tools in SharePoint Server and trace the request back and forth between SharePoint and Workflow server. One such nice tool (though not free) that I’ve found is HTTP Debugger. However you can use any other tools that watch HTTP traffic at the network level (not browser level). So tools like Fiddler will not help as it just trace requests made from Browser whereas we need tools that trace HTTP traffic at network level.

 

Database Log

In the workflow Management database, there’s a table ‘DebugTraces’. I’ve noticed that sometimes Workflow Manager write down errors/debugs in this database tables. You can go and take a look if something is useful for your workflow debugging.

 

Conclusion

You can use all above tools in combination in finding out problem in different parts of the full workflow lifecycle. You can use HTTP Tracing tools to find out if the Workflow Service call from SharePoint goes to Workflow Manager or vice versa. Using event viewer or database log, you can find out if there’s any errors in your workflow during execution. Until some built-in tools are available for workflow tracing, you can use these tools to find out your problem relatively quickly.