There is sometimes some confusion when changing the code in Service Manager when repairing errors. This article gives more detail regarding process definitions and process instances.

When a process is designed in K2.net Studio and that process is exported to the K2.net Server for the first time, Version 1 of that process exists on the server. Any instances of this process created will then use this Version 1 "blue print". This blue print includes the entire process (including any code generated or custom written by developers). When an instance of the process is then created, that blue print is recalled from the database and used to run the process.

Whenever an error occurs at any point in the process, this process instance is halted and subsequently listed in the K2.net Service Manager error profiles. The faulting code can be viewed from here and changed. Remember that only one blue print exists for all instances of the process, and when the code is repaired from the Service Manager, this blue print is updated on the K2.net Server. It is safe to assume that if the blue print is found to be faulty, a repair action will only be carried out to repair the blue print so that future process instances will not fail. The Repair action will then save the updated blue print and continue the instance of the process. If the Repair window is now opened for any other faulting process instances, the recently updated blue print code will be shown, as there is only one blue print.

When the Repair action is carried out, the updated blue print for Version 1 of the process is saved and only the process instance that was opened in Service Manager is run again. If the Repair All Instances checkbox is selected, the updated blue print is still saved, but now all process instances in the error profile with the same error type will be run again. All process instances will now be run against the newly updated blue print.

It is recommended that process data fields be used to store variable data that is specific to process instances. If values are hard coded in the blue print, these values will exist for all process instances. Remember that process data cannot be changed from Service Manager.

In the event that a user might mistakenly capture incorrect data, the user interface should be used to validate such data fields before these values are sent to K2 (or any back end system). If validation is not being employed, an approval step should be built into the process so that another human can review the data before it is being submitted. Once the data is then submitted, it cannot be changed from Service Manager, as the data is not part of the blue print. If user interface validation and approval steps do not catch a specific instance of user error, these data fields can only be changed by directly accessing the SQL Server database (_ProcInstData table). This is not recommended.

You have the freedom to store many values in process data fields and use them anywhere in the process, e.g. if I complete a leave application, the number of days I requested will be stored in a process data field, as it applies only to my instance of the process. My mail server name could be hard coded in the blue print, as this will be the same for any mail sent to leave applicants.

So if your process involves the sending of mail using an email address that is coded in the blue print, this email address should be stored in process data (or activity data, if applicable), unless Active Directory can be leveraged to eliminate this.

If the blue print has to be changed, e.g. a new step is added to the business process, this change will be made using K2.net Studio and the process will be exported to the server again. This is now stored as Version 2 in the database and any new process instances will run against this Version 2 of the blue print, unless I explicitly request Version 1 to be run (this is done using the code that will be written to start the process).

If you need to change process data for some reason (and you know you shouldn't hard code it), then you have some alternatives.

K2.net Studio allows you to add exception handler code in events to catch any errors that may occur. By default K2 will catch any unhandled exceptions, but you can roll your own exception handler that can be used to automatically correct errors (that can be corrected in this manner).

If this is not the case, a new Activity can be added to the process, called e.g. Data Admin and the flow can be redirected to this Activity when something goes wrong. This activity will have a client side event linked to a web page that will display the process data fields. The flow will now be interrupted while a new entry will appear on the admin's worklist. The admin can correct any process data errors here and continue the process. This will then only happen in cases where validation and compensation failed, so that the admin will not have to check every process instance.

By employing this mechanism, Service Manager should no longer be needed to check for data errors.