Faced with an issue? Not sure where to start looking? Never fear, the following article will outline the basics of troubleshooting any K2.net 2003 related problem.
K2.net 2003 consists of a number of modules. Each module has it’s own unique function, but the core modules are used in all deployments. They are:
- K2.net 2003 Server: The actual workflow engine;
- K2.net 2003 Service Manager: The tool that manages the server (think of Enterprise Manager for SQL 2000);
- K2.net 2003 Studio: The application used to build (and troubleshoot) the K2 processes;
- K2.net 2003 Workspace: The web based application used for tracking, reporting and worklist interaction.
Note: The basics of support as a whole will not be covered, for example, don’t start troubleshooting the problem if you do not have steps to test, correct user accounts etc etc.
K2 Error Profiles
The very first thing that needs to be completed when troubleshooting any K2 related problem is to evaluate the error profiles in the K2.net Server 2003 Service Manager. This can be done by completing the following steps:
- Open K2.net 2003 Service Manager;
- Expand the relevant K2 server;
- Click on “Error Profiles”.
You should have an error profile per process, but if you simply have an error profile for all it’s not the end of the world. It just makes it more difficult to troubleshoot if you have many processes. For specific troubleshooting, it’s also a good idea to create an error profile for the particular process based on the specific date testing is taking place, this way you filter out all the old errors.
The error profiles report general exceptions and K2 even gives you the option to automatically fix it. I do not recommend this approach, but it is great to read what action K2 wants to complete. This helps point you in the right direction and in many cases, helps you to solve the problem.
If you have checked the error profiles and still can’t resolve the problem, it’s time to see what the K2 server is doing. To get to the heart of it all you need to start the server in console mode. This is completed by completing the following steps:
- Navigate to service manager of the server (services.msc from the run dialog);
- Stop the service. Note: This obviously causes downtime so ensure that this is completed outside of business hours if troubleshooting in a production environment;
- Locate the K2.net 2003 Server shortcut, right click on it and select “Run-as”.
- Enter the K2 service account details and start the server.
K2 Console Mode
A blue dialog will appear with step for step tracing information on what is happening on the server. As the server has just started, there will more than likely not be much information, but this is expected.
Now that the server is started in console mode every activity performed on the server is visible and the steps to reproduce the error should be completed. At this point, you will clearly see where the process fails and more than likely get a big fat exception to go along with it. Note: When developing processes, developers have the ability to write debug type information to the console. The syntax is simple for example “Console.Write(“**Start of Leave Process**” + Variable1.ToString())“. Text can be written to the console to make the console more readable and variables can be included for more advanced error reporting. More on this operation later in the post.
When you no longer need the console window, simply close it, but remember to start the service again as closing the “blue dialog” effectively stops the K2 service.
The K2.net 2003 Workspace is the workbench for the users and administrators alike. It allows users to interact with their worklists and, say for managers, view the efficiency of individuals per process. Administrators can use the workspace to visually track the progress of any process and also interrogate the datafields if required.
To allow users (or administrators) to view the progress of a process, you need to set the “View” and “View Participants” permission for the particular process. To enable these permissions, complete the following steps:
- Open the K2.net 2003 Service Manager;
- Expand the relevant K2 server;
- Expand “Processes”;
- Click on the relevant process that you want to troubleshoot;
- In the right hand pane, click on “Users”;
- Select “View” and “View Participants” for the relevant user(s).
- Click on “OK”
Now that you have updated the viewing permission for the appropriate process, you will have the ability to interrogate the process as described above.
The workspace is pretty much a visual representation of what has already happened. Not a lot of intervention can happen through this interface and as described above, it is mainly used for users to view reports and interact with their worklists. The workspace is also security sensitive therefore the administrator can for example not act on behalf of another user. In order to complete this, we need to go back to the K2.net 2003 Service Manager.
In some cases a K2 task is routed to a user that no longer exists or a particular activity is simply stuck, the following steps will guide you as the administrator through the process of routing a worklist item to another user and, if required, updating a process to jump to another activity:
- Open the K2.net 2003 Service Manager
- Expand the relevant K2 server
- Click on “Processes”
- Expand the relevant process
- In the right hand pane, click on “Worklist”
A dialog will be shown allowing you to search for a worklist item. If you know some filtering criteria, fill it in and find the worklist item. Once you have found a worklist item that you want to reroute, click on the icon on the left above the listed worklist items, select the new user, and click on “OK”.
Rerouting a task will allow you to act on behalf of any user at any stage of the workflow. This is obviously pretty useful.
The K2.net 2003 Studio is the application used to develop processes. It is not the place to troubleshoot active processes, but updates to existing processes can be made to report or handle errors better. Earlier in the article I mentioned that tracing information can be written into a process that will allow for better bug tracking, the following steps will take you through an example of this:
- Open K2.net 2003 Studio;
- Open the relevant .KSN (K2.net 2003 solution file) that contains the processes you want to update;
- Double click on the actual process of interest;
- You will be presented with the actual flow of the process. Here you can click on a line rule or activity depending on what you wish to edit;
- To edit the code of a process, right click on any activity and select “Properties”;
- At the bottom right of the properties dialogue, click on “Use Code”. Note: This only applies if the activity actually uses the code, in some instances the activitiy will use the GUI;
- Update the code to include for example boiler plates to show when a process starts or finishes, the state of variables as they pass through the process or even what arguments are being passed into the activity for this instance of the process;
- Save the process;
- Export the process to the relevant development server.
The process now has more debugging information in it, so start the server in console mode and watch the window for the added bits and pieces, but please note that I mentioned to export to a development server for a reason; changes like the update of processes mentioned above should not simply be made and added to a production environment unless there is a total failure of the production system and rollbacks are unavailable.
Updating the process with debugging information is in some instances one of the most effective ways of getting to the bottom of your problem, but this approach is not always feasible due to environmental constraints. A good practise for creating processes is however to include this kind of debugging at development time. Just please don’t write out username’s and passwords to the console, I doubt that your system administrator will be too pleased about that.
K2.net 2003 is a wonderful product, it is robust and each component really serves its purpose well. This post, although simply dealing with the basics, highlights what a rich framework for troubleshooting is available to the developer or consultant. Once you have mastered the above mentioned items, try looking into the error logs in the */bin/ folder or play with the elaborate logging possibilities.
Other resources that might help in your quest to solve your K2.net 2003 problem include:
- http://portal.k2workflow.com/ (Login required)
- http://www.k2underground.com/
- http://kb.k2workflow.com/rss/kbrss/kbrss.aspx
Here’s a 
An irritating problem that our team ran into this morning is the fact that 
