A state machine is a bot that executes differently depending upon a set of conditions. Let’s assume that the long running task executes some steps and then waits for something to occur before it can continue. In this case you have three states: start, waiting, and continue. Start state is the state the bot is in when it runs the first time. When the bot hits the point in the tasks where it would stop and wait, you can introduce a condition, such as checking a file in the file system or reading data in a database. The key here is that the bot does not “block” – stop and wait—but it is dependent on coordination with the task it is waiting to complete to generate some signal.
There are a few ways this bot can be used, let’s look at both an unattended and attended example:
- Unattended mode example – we will schedule this bot to run every 10 minutes. Since the bot only uses minimal bot runner time if the other task is still running, it will free up time for the control room to schedule the next bot to run. If we use a device pool, the bot can be scheduled on different devices each time with no dependencies to previous runs. Moreover, many customers have bots that are dependent upon overnight batch jobs running successfully. When this doesn’t occur, it can sometimes result in a domino effect. Enabling the bot to wait for the signal from the batch process will minimize the potential for rework.
- Attended mode example– consider a call center or support agent that is assisting multiple people simultaneously. While the agent is assisting customer 1 they may require a bot to perform a lengthy task of collecting data or awaiting manager approval before continuing. This method would notify that the job was submitted and terminate the current instance of the bot allowing them to put the customer on hold, while they move to customer 2. When the job is complete and they execute the bot for customer 1, it will pick up where they left off.