Orchestrator Job Statuses

Our Business Teams are having hard times in tracking the real-time statuses of the bots as the orchestrator job statuses are showing as completed even when there are pending items in the queue without processing due to one of the below reasons:

  1. There is a stop after time set in the bot that force stops the bot after n hours even though the processing of the job is not completed.
  2. The bot has processed few transactions successfully but there are pending items in queue, but due to recurrent application issues, bot ends the processing and marks the job as completed.

While we are communicating the business teams about the transaction details via email, the reporting becomes cumbersome. So we would like to understand the right Job statuses (e.g. Faulted/Suspended etc) to represent the scenario, that we can forcefully set via the code.

Also we would like to understand if the status faulted is reserved for default behaviour such as infrastructure or technical issues, rather the the issues with source systems that the bot interacts with.

Is there an advantage in using the suspended state.

Hey @sharmili.priyadarsini

You can make the Job Faulted if it suits your need.

It’s like you need to just throw an exception at the end process or terminate the workflow which would make the job Faulted.

I’m actually not sure if you are using latest ReFramework in which we have that provision which will fulfill your need.

Thanks
#nK

We would like to understand in detail with regards to other job statuses considering “Faulted” is reserved for unhandled exceptions. Job States (uipath.com)

Forum URL Orchestrator Job Statuses - Help / Orchestrator - UiPath Community Forum

1 Like

Hey @sharmili.priyadarsini

You are still looking for some help here ?

Thanks
#nK

Yes, My question is not limited to the Faulted statuses, but if there is a way to leverage other job status types to classify between unhandled exceptions from the handled ones in the process transaction state.

Thanks and Regards,

Sharmili Priyadarsini

1 Like

Hey @sharmili.priyadarsini

If my understanding is correct, you want to make the job as Faulted if there is an unhandled exception & the job should be Successful if the exception is properly handled ?

Is that correct ?

Thanks
#nK

Hi Nithin,

Its more about trying to understand more on a standards perspective regarding the job statuses, which is the go to status “Faulted/Suspended/Terminated” that we should set through the code when there are pending items in the work queue considering we are handling the exceptions gracefully and we do not want to retry the transaction as a part of current schedule and transitioning to the end state.

Thanks and Regards,

Sharmili Priyadarsini

Hi @sharmili.priyadarsini

It might be useful if you could provide a small overview of the processing that is being done to better understand the use case and how to approach it.

When I read your second point:

It sounded to me like you should not mark those transactions as successful in the first place, but rather fail them.

As it is, I don’t think there is a way to mark a transaction as something other than Success/Fault, as the other statuses are used for other purposes by design.

Hi Maciej,

Consider there are 10 items in the work queue, and the bot has successfully processed 3 transactions and the status are marked as success for those 3 transactions. While we are trying the 4th transaction, the bot is running into an application exception due to which we will fail the transaction and Due to exception type, the bot wants to terminate the session rather picking up the next item from the work queue.

In this scenario, the job status is showing as Successful while there are still pending items in the work queue. We would like to understand what is the status we should use in this scenario.

As per the Job States (uipath.com) documentation, “Faulted” is meant when, “A job is in this state if it failed to start or the process threw an unhandled error during execution.”

1 Like

Hey @sharmili.priyadarsini

You are right and are you using ReFramework at the moment please ?

Thanks
#nK

@sharmili.priyadarsini
let’s try to answer technicals with non-technicals instead

Business Case: Shopping task
Details: you send someone with a shopping list to buy some goods:

  • A Bottle of milk
  • a package of earl grey tea
  • 1kg of potatoes (but only when good quality is in the stock)

Scenario 1

  • Person will go for the shopping and will come back
  • returned goods: 1 bottle of milk, peppermint tea, no potatoes
    Evaluation: milk: OK, tea: Failed, potatoes: OK, but not returned due good quality was not available
    Mission Completed: YES, Shopping was done, Person came back

Scenario 2

  • Person will go for the shopping and will come back
  • returned goods: 1 bottle of milk, peppermint tea, no potatoes
    Evaluation: milk: OK, tea: Failed, potatoes: OK, but not returned due good quality was not available
    Mission Completed: NO, as the definition of done is about coming back with all goods and also as defined by the shopping list

So coming back to the technicals

  • with the status of the work Queue Item we can reflect the result of buying a good and its result
  • with the status of the Job we can reflect on how was the Shopping tour resulted in all

So it is depending on the definition of done if we call the shopping tour was successful or not

Once we specified this, we do implement it and do calculate the result for the job

1 Like

yes, we are using RE Framework, and we would like to alter the job status to handle for specific application exceptions during process transaction state.

1 Like

Okay @sharmili.priyadarsini

You will use Faulted state if the Job is getting any consecutive application exceptions !

This is how the current ReFramework behaves.

Thanks
#nK

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.