+1
I am working on a system that works with time sensitive processes. Sometimes a process times out and goes into error state. this can be fixed by a simple retry of the process. but as the processes work 24 hours a day and errors can occur 24 hours a day. with processes outside of support hours manual retry cannot always be done.
I wanted to know in the Exception Rule of the process is there a way to Retry the Event/Activity after an allotted amount of time.
+6
why do you think the workflow instance will continue if you retry after an allotted time? Rather than simply retrying, is it not necessary to fix the issue that has caused the workflow to error out?
You can configure notifications to send an email when a workflow instance goes into error state.
+1
Well I know that 95% of the time when it goes into error state it is a time-out problem and retrying the item again it works again.
to create a custom exception handling system on every event is impractical. so can't fix the issue if it is network time-out error or such.
I want the system to retry 5 times before sending out an email to the support Team after which it should no longer retry.
This will mean that only serious issues are sent to the support team.
and time out errors and simple errors that can be fixed by a retry does not stop the process from continuing and causing concerns.
+6
you have to build custom windows service that monitors the "error profiles" section using API and use the conditions as you described based on the ProcInstID.
+4
No need for custom windows services or code of any sort here.
Create a workflow and a dd a "ForEach" event. Inside that select all the Id's from the SmartObject "Error Log" (located under System - Management - Workflows)
This will enable you to loop through all the errors.
Now using that Id you can obtain "ProcInstId", "ProcId", "ObjectId", "TypeId" etc.
Then check to see if that error has disappeared from the Error Log, by using the SmartObject "GetError". If it's gone then end the WF, otherwise send an email/notification and maybe log it to a database or SharePoint for further inspection by other teams/users.
Use the other SmartObject "RetryError" in the same location to then retry the error.
That's the Workflow at it's most basic, you then simply set that up as Schedule in the Management console to run every *personal details removed* mins.
+7
I tried this and it works very well. Will work best if you create an error profile for just your process or you can use the process name. Do a for each loop using "get errorLogs" do a retry with the data from the reference item.
I hope this helps as well.
+1
Sorry to bump an old thread, but I'm doing some troubleshooting surrounding the RetryError method of the Error Log SMO and stumbled onto this post.
I'm trying to build a workflow that does exactly the same thing, and am trying to execute the SMO Method through the Management Console to validate that it's working as expected. There's a 5th parameter that I feel like is causing me issues: UserName. I've tried all sorts of entries for this, and still cannot get the method to successfully retry the error in question. My suspicion is that it should be in the ‘K2:domainuser’ format, but this doesn't seem to be working for me (and I've confirmed that I do have both Admin and Server Event rights on the test process).
Does anyone have any ideas? Thanks in advance
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.