Implementation of 'Should stop' in case of 'No queue'

Help
1

Hi all,
i need to implement ‘Should stop’. In my scenario, i am not getting my transaction data from Orchestrator queue. I am getting data from database.

In ‘Get transactional data’ i am getting a complete data table from database and passing it to ‘process transaction’ complete table one at a time. And process each row , one by one in ‘process transaction’. Can any one suggest us that how to implement ‘Should stop’ in this case ?

2

Hi @Ggaurav,

Welcome to uipath ccommunity.

There are two options should stop and kill process in Orchestrator. I am not sure as to how you want too leverage this but I am going to explain both.

SHOULD STOP : Let us say you after taking the data into the process transaction and processing them you use the ‘should stop activity’ then automatically (if you are using REF and modified it to not use queue items as your requirement states) the end process state is executed and it exists gracefully without going to any other state.

Basically for using Queue this is helpful because in a scenario where you know that you need to stop processing the next transaction but you don’t want to ‘kill process’ then and there, this activity will be of use to you as it will process the current transaction and then go to end process stage (where you can do clean up activities like closing applications etc…)

KILL PROCESS: Just force stops your bot/workflow that is running without processing any further from that point onward. Simple as that.

In my opinion should stop isn’t something that you need unless you are using the whole REF without much modification and you are using Queue.

Regards :slight_smile:

3

Simply put,
You need to place the Should Stop somewhere right before the next item will be processed. Typically, you will loop though some items in your process, so the Should Stop goes at the start inside the loop and it will finish the current item but not process the next item if the “Stop” is triggered in Orchestrator.

If your Process is using a Flowchart, then you can just check the boolean from the ShouldStop in a Decision and exit easily. If you are using a Sequence, then you will need an If activity with a Throw activity to exit the ForEach.

EDIT: If you are using States, then set a condition transition to End, so it doesn’t go to Process state for next item

I disagree with this. ShouldStop is important regardless of your project design. For example, Kill (like you mentioned) will halt the process and not continue. This can leave applications and files open. The main purpose of ShouldStop is that you can perform other actions before it stops, so you can complete the current item being processed and clean up the environment. Additionally, for scheduled jobs, you can set a timeout so a job can end after so many hours (you can use Stop or Kill for this, preferably Stop). Another thing to consider to code along with this, is to Log that it was manually stopped and Throw the last received exception that hit max retries so it doesn’t show Green successful, which is something that the REF does poorly in my opinion.

Regards

4 Likes
4

@Ggaurav

Completely agree with @ClaytonM. Should Stop activity is must and should always be incorporated in your workflow as a best coding/Framework practice. Even if you don’t use it today, A day might come when u really require it . so its better to design your workflow taking into consideration should stop activity.

5

Well,

@ClaytonM I totally agree with your points - especially this -

Also, I will go a step ahead and it should be made best practice. Auditing, safe way to finish a transaction before it exits etc all are fine.

But, the explanation of the OP suggested a scenario of Attended bot which prompted my response of maybe it wasn’t required as a typical assisted/attended bot will not require any should stop (maybe I should have clarified it more) and such a bot will not run un-attended (basically trigger events and dialogue).

@Ggaurav I guess what I really want to say is as far as it is unattended it is always a good practice/safe bet no matter what. But, it will always depend on the type of automation that you are planning - attended or unattended.

Unattended also can leverage this feature though, like I said case by case basis. :slight_smile:

Regards

PS ; Reference for Attended Bot Framework where it is transaction based model so should stop is used : https://go.uipath.com/component/personal-interactive-framework

1 Like