Case 1: Running Bots without a Device Pool and with a Queue.

In case Device Pool D2 is not available, you cannot run processes assigned to that specific device pool, but you can still run processes assigned to Device Pool D1 if it is available.

If you want to run Bots without a device pool, you need to ensure that the processes are defined to be executed independently of the device pool. Queues are generally tied to device pools, so if all devices in a pool are unavailable, the queue for the pool may not process any items. 

So, you cannot run Bots assigned to a down device pool (D2) if they depend on that pool.

Processes assigned to D1 can be run if D1 is operational.

Case 2: Assigning Bots to Two Device Pools

Yes, you can distribute Bots (like Process 1) between multiple device pools (D1 and D2). It is helpful if you expect high volumes of transactions since it has load balancing functionality across available runner machines.

By creating the process to run in both device pools, you can ensure that in case one pool is busy or not available, the other pool can complete the workload, thus enhancing your resilience and efficiency of automation.

So, you can automate and Bots to two device pools to complete more transactions effectively. 

Case 3: Workflow Processing Based on Database Status Updates

In your situation, you have two systems updating different statuses in a database. You must ensure that Step 2 is triggered only after Step 1 is executed successfully. Here is how you can do it:

Use of Queues and Work Items: Once Step 1 (Pending to Ordered) is finished, you may update the database and subsequently add a corresponding record to the WLM queue that this Step 1 is finished.

Trigger Mechanism:

Polling or Event-Driven: Use a mechanism in which either:

The bot continuously polls the database for changes (e.g., looking for records that show Step 1 is finished Or, design an event-driven system where a notification system initiates the next process after Step 1 is complete.

Conditional Logic: In the WLM processing bot:

After Step 1 processing, check the status in the database to see if it has progressed to "Ordered." 
If so, the bot can then proceed to run Step 2 (Ordered to Completed).

So, implement a combination of queues and a database status update trigger to trigger Step 2 after successfully processing Step 1. Employ conditional logic to check the status before proceeding.

By implementing these steps, you can effectively manage your Bots across various device pools and transition between workflow steps seamlessly on the basis of database updates.

Hi,

Thanks for detail reply.

For Case 2: It is little confusing, process 1 Queue 1. I have enquired about the same but as per the suggestion, Process 1 WLM 1 could not run on multiple Device pool. I will verify once again. 

Case 3: I understand. My concern is when you will push the data in the queue and system 1 process is successfully completed. In that case, queue status for the record is completed. So how could trigger a bot again ?

Thanks

Shatdal