When an event throws an exception while executing, I use the K2.net Service Manager to correct the source code and repair the error, from the error list in "Error Profiles".
I recently realized that when I do this, the Service Manager:
- copies this modified code to all other similar existing errors, so that they can be corrected just by clicking the Repair button
- automatically repairs any similar errors that occur in the future, by using my modified code
This is really bad for me, because sometimes when correcting the code to repair an error, I will hardcode values specific to the process instance for which the error occured. So this source code is invalid when the same error occurs for other process instances.
Is there any way I can prevent this behaviour so that, when I repair an error, the source-code modifications I make apply only to that particular instance of the error and not when the same error is encountered again in the future?
Thank you.
+11
Hi,
When an event throws an exception while executing, I use the K2.net Service Manager to correct the source code and repair the error, from the error list in "Error Profiles".
I recently realized that when I do this, the Service Manager:
- copies this modified code to all other similar existing errors, so that they can be corrected just by clicking the Repair button
- automatically repairs any similar errors that occur in the future, by using my modified code
You're right, what actually happens is that the code pertaining to this specific event is changed in the database and ALL other process instances running on this specific version of the workflow process, will encounter this new code if/when the event is executed.This is really bad for me, because sometimes when correcting the code to repair an error, I will hardcode values specific to the process instance for which the error occured. So this source code is invalid when the same error occurs for other process instances.
What happens in this Event? Can you give me an example of your hard-coded values? Can't you rather use process level datafields to store the values applicable to each process instance and then use these datafields in the code?Is there any way I can prevent this behaviour so that, when I repair an error, the source-code modifications I make apply only to that particular instance of the error and not when the same error is encountered again in the future?Unfortunately not. This is by design.
Regards,
Ockert
+1
Thanks. I can see that this feature has a different purpose than what I thought. It is intended to fix bugs without having to export a new version.
What I did with it was, when there was a bug in the code, I would sometimes apply a quick and dirty fix (often hardcoding values) just so that the process instance could become active again as soon as possible; and when I had the time I would fix the bug in Studio and export a new version.
Anyway, now that I know how it works, I suppose I can still apply such fixes, by appending code that only works for a particular process instance, e.g. something like: If Folio="145" Then MissingValue=10
Thanks.
What I did with it was, when there was a bug in the code, I would sometimes apply a quick and dirty fix (often hardcoding values) just so that the process instance could become active again as soon as possible; and when I had the time I would fix the bug in Studio and export a new version.
Anyway, now that I know how it works, I suppose I can still apply such fixes, by appending code that only works for a particular process instance, e.g. something like: If Folio="145" Then MissingValue=10
Thanks.
+8
The error log's 'Process ID' property is the Process Instance ID of the process instance that has failed, so if you want to do a quick-and-dirty fix in the code for the specific process instance, you can do a test in the 'repair error' code like so:
Where the Process Instance ID is displayed in K2.net Service Manager:
http://img.photobucket.com/albums/v705/neiljohn/ErrorInstanceID.jpg
)
{
//do something that fixes the error
}
Where the Process Instance ID is displayed in K2.net Service Manager:
http://img.photobucket.com/albums/v705/neiljohn/ErrorInstanceID.jpg
+3
We ran into this unexpected behavior the hard way... Basically, we have a process that has an email event that emails a client using a value supplied by the user in an Infopath field. What we ran into was that activity instances were erroring because the user was inputting a badly formatted e-mail address. At first glance, it seemed easy to repair; we basically (in error manager), removed the XML field reference and hard coded the intended customer e-mail address. Well, to our great horror, every single other active activity now e-mailed that same hard coded recipient.. The "fix" caused more problems than the error...
I really think this behavior should change. Repairing an error should not modify code for all active instances, it should just modify the code for that particular instance. If I want to change code globally, I'll fix my process in K2 studio and re-export. If I want my fix in error manager to apply to all active instances, that's what the "repair all instances" checkbox *should* do.
The current behavior makes it *very* difficult to fix certain errors, *especially* ones that reference xml data in our Infopath forms. Using the K2rom, we've developed a way to fix active processes where the fix is contained in a k2 data field, but so far now way to fix errors in the xml data supplied by users in our Infopath forms.
Any suggestions on fixing *single* active processes that reference an error in an xml field provided via Infopath?
I really think this behavior should change. Repairing an error should not modify code for all active instances, it should just modify the code for that particular instance. If I want to change code globally, I'll fix my process in K2 studio and re-export. If I want my fix in error manager to apply to all active instances, that's what the "repair all instances" checkbox *should* do.
The current behavior makes it *very* difficult to fix certain errors, *especially* ones that reference xml data in our Infopath forms. Using the K2rom, we've developed a way to fix active processes where the fix is contained in a k2 data field, but so far now way to fix errors in the xml data supplied by users in our Infopath forms.
Any suggestions on fixing *single* active processes that reference an error in an xml field provided via Infopath?
+4
Hi All,
How about another perspective on this problem. If the code you have generates an exception you can catch this using the exception catching code at the event, activity or process level. Once you have caught the exception you can pass it on to a correction process or similar.
The algorthm for reposting the "fixed" instance is the only tricky bit.
My understanding of the error manager is that if no exception catching mechanism is provided, this is where the instance failures end up.
Hope this helps, hope the perspective is also correct. :?
Graham
How about another perspective on this problem. If the code you have generates an exception you can catch this using the exception catching code at the event, activity or process level. Once you have caught the exception you can pass it on to a correction process or similar.
The algorthm for reposting the "fixed" instance is the only tricky bit.
My understanding of the error manager is that if no exception catching mechanism is provided, this is where the instance failures end up.
Hope this helps, hope the perspective is also correct. :?
Graham
+2
So what is the different between check or uncheck the "Repair all instances"?
+11
The difference is in the execution of ALL errorred-out instances (of the same event) against the modified code or just the execution of the current instance against the modified code.
Regards,
Ockert
Regards,
Ockert
With the "Repair all instances" checked, will all process intstances with the same error event resume excecution regardless of the process intstance state(Error, Active, Completed...)?
Let's say that one instance is repaired seperately, and then "Repair all instances" is run. What happens to the singly repaired instance?
+13
Assuming after you repair one and it's successful, the next time you modify the code and click repair all instances --- the new code will be applied but the repaired one will not need to re-run with the new code. However if you use GotoActivity on the repaired one to the activity prior to the error code, then I believe you'll force it to execute with the latest code that you applied by using "Repair all instances".
From what I understand "repair all instances" is just a way that you don't need to manually repair one by one...
Thank you for quick the response!
I'd like to have confirmed the following statements (on "Repair all instances):
1. Repairs only processes in Error-State.
2. Repairs only prosesses that hasn't been repaired previously.
I want to make sure that I only repair processes that are in Error-State and that the Error-Event is still applicable. By applicable I mean that the process is still in the step that spawned the Error-Event (& Error-State).
+11
Hi,
Yes, when you use 'Repair All', you will only repair process instances that are currently in Error State on the specific Event - experiencing the specific error.
The important thing to note is that any code changes you make will apply to all these instances currently in error state AS WELL AS all future instances reaching the specific event.
HTH,
Ockert
+8
I know this is an old thread, but a very simple solution exists.
I get a fair number of errors that occur when a dest user has been assigned at process instantiation, but by the time the activity is assigned the dest user is no longer in Active Directory. The Infopath Client event goes into an error state because the value of 'strEmail' is nothing. So I hard code the email address of the new user, but put it inside an If End If block so it only executes for that particular process instance ... like this:
If K2.ProcessInstance.ID = 1234 then
strEmail = "newperson@mycompany.com"
End If
The Process Instance ID is on the 'Error Log' tab tab of the Repair Error window. Then I reassign the worklist item to the new person.
An additional line of code helps me to identify the workflow instance. With over 3000 active instances it is handy to know which one it is and who the originator is so that I can email them to ask who to assign the step to. Add this as the first line of the block, then just comment it out when you need to repair it.
Throw New System.Exception ("Folio=" & K2.ProcessInstance.Folio & "; Originator=" & K2.ProcessInstance.Originator)
After 3 years of doing this almost every infopath client event has this piece of code in it ... all I do is change the process instance ID.
+1
I also just realized that "Repair All" must be used with caution. I didn't realize "repair all" applies changes to all future instance. However, now I need to revert or overwrite those changes. Can anyone help? Or have any idea how remove the changes I made?
So what I did, when the error arrive the realized one of the datafields wasn't able to draw the email address from the ProcInsData field so I hard coded the value in and press "repair all" not realizing it effect everything. Now i'm screwed and need some advice on how to revert this change.
+13
Any repair (not limited to repair all) will alter all future versions as it changes the underlying code base that process runs.
In the future you need to add conditional clause:
If k2.processinstance.id = id_having_issue then
specific data fix
end if
You would have to carefully update the code you changed in k2._code table to permanently revert back.
You can narrow down the procid from k2._Procset.
+1
Thanks for the info!!
I'm also curious, if I were to export a new version of the project to the server, would all the existing processes inherit the new changes from the export, or would the existing processes go unchanged and only new process (created after the export) take affect?
Reply
View our Community Site Map
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.