This is for situations where your process caught errors, and the errors were handled gracefully, and still completed the Job, but ultimately logging the Transaction Item as “Failed”, and ending the process with no further prompts or error messages (as is typical with a Global Handler displaying a final popup of the error - forcing the job to fail in this manner or “Terminate Workflow” or some other abort method would cause the Job State to record as “Faulted”, but with the drawback of there being a final Exception popup left afterwards).
In the event you do not force an abortion of the process, the Job State is recorded as “Successful”, despite it being a Transaction failure (or all items in the queue failing).
As suggested, a “Rethrow” or “Throw” at the end of the whole process to log a Job State of “Faulted” will still display a final error popup for the user, which I’d like to avoid. Also, the Global Handler would be triggered by these methods. I could customize the Global Handler to recognize that the “Throw” is meant to set the Job State to faulted, but, again, I want to avoid the final Exception popup that this would cause.
Interesting take on transaction processing.
To summarize, you would want both Success scenario and Business Rule Exception to return Failed as Job status instead of current behaviour of Success?
Correct, but it should default to a Job State of “Success” (assuming there weren’t any unhandled Exceptions) unless overridden by the bot (i.e., the bot sends a “Job State Failed” parameter back to Orchestrator, which will tell it to set the Job State to “Faulted” no matter the outcome of the Process when the process finishes). I think this would allow more flexibility in reporting and monitoring, as we are able to force a Job to record a “Faulted” Job State (or some other “Failed” state), no matter the outcome of the Job or Transaction Item statuses. That is, there are some situations where every item in your Orchestrator Queue failed, but the Job was able to finish from end-to-end, so it would still record that the Job State was a success - this wouldn’t make sense, correct? If you were to display a printout of the monitoring to stakeholders, showing all successful jobs, but failed queues?
@x.Rei.Ai.x Wouldn’t you just show the stakeholders the Queue report instead? That would show the actual success/failure of the transactions - it even shows Success, App Exceptions and Biz Exceptions.
So, even though the Job is successful, this report would show
Success - These transactions were processed successfully
Biz Exceptions - These transactions couldn’t be processed, but not because of an error, but because they didn’t meet certain criteria (maybe amount is too low, or, a zip code is missing, etc.)
App Exceptions - These transactions didn’t get processed because of a handled exception during processing.
Unhandled exceptions would show a Job Failure.
So, in your case, yes, the job would be a Sucess (the job ran properly and all exceptions were handled) but when you look at the transaction (queue) report, you would see that all the transactions failed and why. The transactions can even be reviewed and (I believe) reprocessed.
Look into more detail transaction processing - it might already do exactly what you’re looking for.
Under your main, add a string out argument called “ExitMsg”. Then for each of your “grace exit”, pass a value to it (most time would equal to exception.message). You will then be able to detect any gracefully exited successful jobs.
I know this method is a bit cumbersome right now as you have to click on the job detail button to see, but I would imaging eventually UiPath would provide ways for customized table view options (show/hide additional columns). If not, it would be a must easier ask to update the Orchestrator “JOBS” page UI than make additional fault state that may impact current logic.
For now we have the queues to handle exceptions. There is a workaround (rethrow).
We need to gather more feedback to see if it is worth duplicating queue functionality on jobs.
Of course, you could also add a dummy transaction item for each started job.
I’ve merged the two topics about the same suggestion.
@All - I am facing same issue, Is it right way to Rethrow exception again.
The queues can be used to handle exceptions in transactional processes.
But in case of non-transactional business processes which does not require the use of queues, then this method would not be suitable to handle the exception.
For instance if there is a business process which exports a file from a system, in case of a failure I could send a email to the user notifying that a certain file export failed at that time.
I can send the email and then rethrow the exception which would set the job status to faulted in Orchestrator.
But, if any exception occurs while sending the email, this would mean that the job status is set as faulted but the email was not sent.
Currently, in case of any System/Business exception the job status is set to faulted and if the error is not rethrown the status is set to successful.The errors can be only viewed in the logs.
If there would be a activity which could set the job status in orchestrator after error handling to “Job Needs Attention/Review”, “Warn”, etc, then the job can be assigned a reviewer to check if further actions are required or not.
Please suggest if there are any alternative methods currently to handle this type of scenarios.
Is any update on this idea?