Hello guys!
I propose an activity to set the status of a process as failed in jobs list. This is necessary because if you do try-catch, your workflow will complete succesfully (green checkmark), and that is correct from the technical perspective, however from the business and support perspective it should appear as failed.
If the developer has this mechanism it can mark it as failed in the orchestrator web interface so support can track the problem.
Alex
Why not…
?
You can invoke cleanup in every catch and afterwards throw the error, agreed, but it would be much easier if you had an activity to set the status to failed.
Would it be much easier?
It is
almost the same or i’m missing something.
One difference I’ve noticed is if execution ends with an exception robot doesnt log out even if he started a new session. This can make follow up runs work incorrectly.
I’d still prefer a jobstart flag for that, but that’s a different topic.
Hmm…haven’t thought about it. However you can still do the cleanup and only after re-throw the exception.
I’m thinking that using exception is better for consistency reasons. Using an activity will let you set the job status to failed by mistake. Using exception will guarantee that after throwing the exception nothing gets executed.
Yes, but that will still leave the session as Disconnected, instead of logging out.
Something to think about.
Yes, but some customers complained that login/logout is time consuming 
.
If you’re not changing the win-logon should not be a problem…though, indeed, logoff is safer especially in an unhandled robot crash case…so it’s something to think about…and will avoid the trouble of doing clean-up.
Currently, if you have graceful exception handling in your process, even if your process has errors and technically “Failed” its intended goal and if your Try/Catches succeed in catching all the errors, the Job State is still listed in Orchestrator as “Successful” despite having failed the intended goal because the process technically completed from start to finish without unresolved errors.
We need an activity that we can include in a Catch where we know the Job State has faulted so we can override the Job State in Orchestrator as “Faulted”, despite having caught the error because we want to avoid an error popup for the end-user.
Specifically, from an Orchestrator-monitoring point of view and analytics, we should not be seeing “Successful” jobs if they were in fact Faulted.
@x.Rei.Ai.x
Per my understanding this can be done currently.
After handling your exception simply use a Rethrow activity to rethrow the exception. Assuming you don’t wrap this in an additional try/catch this will not be caught and will display as Faulted in Orchestrator. This allows you to gracefully recover but also to properly update the Job status.
Does this cover your need?
This Rethrow would occur at the end?
@sagacity
Yes. Let’s say that to handle the exception we wanted to close the application and send an email to the business subject matter expert. We might do something like this:
The application would be closed and the email would be sent. Then, the Rethrow would cause the job to appear faulted.
What if I want to do additional processing AFTER the exception was caught and the email was sent, but still show the job as “Faulted” in the State when looking at Jobs in Orchestrator?
@sagacity
Any uncaught exception will cause the job to be “Faulted”. As long as you do all of your processing BEFORE throwing or rethrowing an exception you will be fine.
@DanielMitchell Yes, this is the crux of it. So in your example, if I continue with more activities, more processing, etc., and finally get to a place where the job is going to end, if I put a Rethrow there, it will cause the exception and mark the job as faulted, right? Even if processing did another 20 activities after, right? If that’s the case, great. However, if it is, what happens if there were no exceptions, and you call a Rethrow?
Thank you, I appreciate the response.
However, this really would not work if you are also using a Global Exception Handler. The Rethrow triggers the Global Exception Handler, and it will retry the activity (Rethrow) and Try Catch (default 3x) until it goes to result = errorAction.abort. This would result in an error popup (which I want to avoid for the end-user) - or even in unattended automation, the popup onscreen might hinder other scheduled unattended automation.
@x.Rei.Ai.x You seem familiar. I think we spoke on this before where you wanted this and I didn’t think it was possible. Seems like I was wrong! 
I just didn’t know about this method. If not you, then sorry!
I wonder if you could have one final Rethrow in the Global Exception Handler (by this you mean wrapping the entire code in a Try Catch, right?) Could you put that as the last thing in there? Maybe in the Finally? Can’t remember if you can place it in Finally.
I am excited about this prospect as well, b/c like you, I too wanted this functionality, but resolved to it not being possible…until this post…
haha, yes I think we bumped into each other in a previous post. I don’t remember if it was regarding this specific issue - I think it was something to do with the wait attribute?
But yes, I could put a “Throw” activity into the Global Handler with the errorInfo argument for the details, but, again, this would show an error popup for the user. Maybe there’s just no way around the error popup if we want the job to be Faulted.
I don’t use popups when communicating with the attended user (unless for user inputs). I have a reusable workflow that creates a “Robot Desktop Icon” that shows a callout box and text-to-speech voice to communicate to the user. This is the main reason I want to avoid having an error popup (not to mention unattended automation not needing a workflow to check if there is an error popup before starting its process), and the need to be able to override the Job State in Orchestrator to “Faulted” when the workflow really has failed despite finishing the process.
Ah. Yes. This has been my experience as well. I never could find a way around it.
Hi @x.Rei.Ai.x
This seems like a scenario for Business Rule Exceptions, which are tracked separately in Orchestrator.
In short:
Please let me know if this is not what you are asking about
