Debugging K2 SmartActions

If for some reasons K2 SmartActions doesn’t work, what should we do? It’s a black box feature, and we can’t access its source code to debug with Visual Studio. But, there are some non-code debugging approaches that we can perform when it happens. In this post, we will mention some of those methods that we already tried based on our experience doing real projects.

Examine K2 Host Server Log Files

This should be the first step to perform when something doesn’t go quite right. We can find a lot of messages to aid our effort to resolve the issue. There are a lot of log files in C:\Program Files (x86)\K2 blackpearl\Host Server\Bin directory. We can sort it by date to find the newest one.

There are a lot of entries in the log files, especially if we turn on the verbose logging mode in K2. Unlike SharePoint log, K2 log doesn’t have correlation token to make it easier to find specific log entries. We have to read carefully or search based on certain keyword to debug problems related to K2 SmartActions.

Decrypt K2HostServer.exe.Config Content

Connection strings data are encrypted inside K2HostServer.exe.Config file. When debugging, it is important to know these connection strings data, especially the EWS URL which plays a vital role in SmartActions. To decrypt the content of this config file, first copy K2HostServer.exe.Config to temporary location, for example C:\Temp, and rename it to web.config. Then open a Command Prompt windows as Administrator, change directory to C:\Windows\Microsoft.NET\Framework\v2.0.50727, and type the following command:

aspnet_regiis.exe -pdf "connectionStrings" C:\Temp

Open C:\Temp\web.config, and we’ll find the connectionStrings section has been decrypted.

Decypted ConnectionStrings

We can examine the connectionStrings section to find out about the EWS URL and whether the auto discovery setting is turned on or off. Sometimes Exchange auto discovery is not configured in our environment. On the other side we already provide the EWS URL explicitly in the configuration file. So it’s better to set Autodiscover value to false to avoid flooding our log files with exception messages related to auto discovery error.

If we change values in connectionStrings section we have to encrypt it back before we commit the change to K2HostServer.Config file, using the following command:

aspnet_regiis.exe -pef "connectionStrings" C:\Temp

Use Fiddler to Debug Network Communication

Sometimes the culprit of the error doesn’t lie within our application, but our network. For example blocking firewall can prevent K2 server from reaching Exchange server, especially if we use external (cloud-based) Exchange server. To make sure all communication with external parties are not blocked, we can use fiddler to debug communication messages, and to examine request and response messages between K2 Server and Exchange Server.

Debugging Network Messages with Fiddler

Source: Debugging K2 SmartActions

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s