K2.net 2003 have the great feature of fixing errors on the fly. When any code component in K2 (line rule, start or preceding rule, event, etc.) generates an unhandled exception, the process instance goes into an Error state. These process instances in Error state can be viewed form the K2.net Service Manager by creating a Error Profile and then viewing the errors in that profile.
From here the Service Manager allows you to open the details of the error and various details of the error can be viewed including:
- Process Name
- Error Type
- Error Location
- Error Details
The really nice feature is being able to see the code that generated the error. From this view you can edit the code and repair the error on the fly.
But... what is the effect of doing this? The K2 server stores only ONE copy of this code. Its stored in the _Code table in the transaction DB (normally called K2). By modifying the code in this error details window and hitting the Repair button, the Service Manager updates the code in the _Code table and re-executes the object (in my example an error was created in an Server Event, so the event is re-executed with the new code).
Because there is only one copy of the code, the change made is reflected for ALL process instances and all new process instances. So be careful what you do in your code change as its going to affect way more than just the current process instance! As a matter of fact, even previous version of the process having the same code is updated.
Something else to note is that the original process definition will still contain the un-edited bad code and will also need to be looked at before you re-export the process.
I must apologise to my ex students as I've probably not been explaining the behaviour correctly in the past. We burn and learn. Comments (including possible moans at me) welcome!
