Troubleshooting workflow process issues

One thing that regularly comes up when responding to Workflow-related issues is that there seems to be some confusion about where to find the information for troubleshooting the problem. ADAM Workflow Studio relies on AgilePoint Server as a BPMS and this product has its own separate logging and error reporting. In this blog post I'm going to explain how you can get to those log files and how to scan them for error messages and other trouble indicators, as well as give you tips on how to add logging to your own custom building blocks.

I'm assuming a basic knowledge of the ADAM Workflow Studio and a working installation of the ADAM Workflow Server (AgilePoint Server).

How to troubleshoot failing workflow processes

When something goes wrong in a workflow process (or a task in that process, for that matter), the process will get the special "Failed" status in the process management section of Workflow Studio. In order to display the failed processes, you'll need to modify the filter, which hides them by default:

You can then use the "View" link to show details of the process and in the process visualization you should see an error icon above the task that caused the problem:

In the other two tabs, you can review the state of the workflow process variables at the point of failure. You can check whether this information corresponds to what you would've expected for the process.

Also, there should be a special process variable containing the exact exception message that caused the process to fail. This information can be particularly handy when debugging problems in custom-code building blocks.

Where are the Workflow Server logs?

When a process is failing and the information in the process variables does not help you any further to identify the problem, you can move on to check the AgilePoint Server log files.

The AgilePoint Server log files can be found in the "log" directory under the web application directory for AgilePoint Server. The default location for this is C:\Inetpub\wwwroot\WorkflowServer. The log is split over multiple files which file names contain a time stamp. Most of the time, you'll want to check the most recent file.

When an exception has occurred in the workflow engine, you will find the error message and stack trace in these files:

Apart from exception information, this log file also contains valuable information for debugging workflow performance issues, building block problems (most building blocks will log their parameter values here), and other things that might come up.

Any problem with the AgilePoint Server installation (license expired, assemblies missing, ...) would be visible in these log files.

Also remember that workflow building blocks performing ADAM tasks might add information to the ADAM log as well, so it might be beneficial to check the application log and Windows Event Log as well, especially when the AgilePoint Server logs don't seem to get you any further.

Adding logging to custom building blocks

When developing custom building blocks, always remember to add logging to make troubleshooting easier. You can use the AgilePoint API Ascentn.Workflow.Base.Logger class to add entries to the log files described earlier:

C#
1
Logger.WriteLine("Data received: {0}", additionalInfo);

Especially when performing ADAM tasks like manipulating orders, records, and such; it might be more appropriate to log in the ADAM logging system. You can use the Adam LogManager class to add entries to the ADAM Application log (and all registered log listeners):

C#
1
2
3
LogManager.Write(LogSeverity.Normal, "Updating user information.");
// Or...
App.Log(LogSeverity.Normal, "Updating user information.");

To avoid adding clutter, it is advisable to only log information that is actually useful when troubleshooting issues and be verbose enough on this; for instance: instead of logging "Reading input parameters.", you could log the actual values of the input parameters, along with their names. This will help you further when things go wrong.

Wrapping it up

At this point, you should have a clearer view on where to find the right info for troubleshooting workflow processes, as well as know how you can add logging to your own custom building blocks. Feel free to comment or ask questions when something is still bothering you. Happy coding.

Comments

Leave a comment
You must be logged in to post comments.
Sign in now
 
 
CATEGORIES
AnnouncementsDocMaker StudioEngineSharePoint ConnectorWeb DevelopmentWebinarsWorkflow Studio
rss feed