@loginerror I believe you are referring to transaction processing, where @x.Rei.Ai.x is asking about Job (processing) State.
2 Likes
@loginerror I appreciate the response! But yes, as @sagacity mentioned, this is with regard to setting the Job State in Orchestrator to âFaultedâ.
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.
1 Like
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?
@loginerror
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.
2 Likes
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.
1 Like
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.
2 Likes
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.
1 Like
Is any update on this idea?
Hi All,
Let me know if this has any risks,
What if In REFrameworkâs end process, I put throw inside an if condition saying
âSystemException isNot Nothingâ and rethrow in catch and hence it will update it in orchestrator as faulted.
Thanks in advance.
I need this functionality when implementing the CI/CD pipeline.
When running a Jenkins job with the UiPath plugin âRun Jobâ, the resulting output json file, states the run as success, evne though there were fatal errors during the executions. It only looks at the âJobâ result.
How else would I mark a run as failed in jenkins, when all results show success even though they were not?
If I recieve a system exception I still wont to close the process gracefully, this meaning closing all application and killing all processes. But the process is still failed, thus it should have the failed status. I think this feature would be great to have.
Today we have to check logs or wait for the business to call!
An additional Job Status would be helpful, which could be set manually if the error was caught and, to some extent, handled, but the result of the Job cannot be treated as âSuccessfulâ. It would make those items visible in the Jobs list and also allow to populate the Output Values in the Job Details with some additional info about the error (currently if flow is terminated by Rethrow, Output Values are null).
ashokkarale
Anil_G
Yoichi
yangyq10
postwick
chandreshsinh.jadeja
aravindbalineni123
Parvathy
aya
PRASHANT_GABHANE