Allocators & Workers

The cornerstone in this pattern is that we can create a better automation with more flexibility for the users, by using multiple Anymate Processes to model a single business process.

Allocator -> Worker

In it's simplest form, you model a Business Process with two Anymate processes - an Allocator and a Worker - with each their own schedule and rules.

An Allocator is a Trigger Process, which typically gets a dataset from either a database, a core system, a csv file on a sftp drive or similar. Based on this dataset, it will create a number of tasks in the Worker process.

A Worker is a Process with tasks enabled. It is now possible both for the allocator to create tasks and for users to create tasks how they normally would - the worker does not know the difference, and will solve them all the same.

We often see an implementation where the allocator runs once a day, but the worker checks the queue every 20 minutes. This gives the users a lot of flexibility if they wish to use the worker for ad-hoc tasks aswell.

Where to put business rules?

Depending on the Business Process, sometimes it makes sense to have the Worker process set up taking only a Key and maybe a few fields. Here the Allocator will mainly identify where work needs to be done but the real logic is in the Worker process. This can be good if you have a very defined Business Process where you always want a task to be solved in the same way using the same algorithm. Maybe it has multiple steps spanning across multiple systems.

Other times, it makes sense to have the Worker taking a Key and multiple fields, where it will simply input data in to a system directly. Here, the Allocator will have the responsibility of gathering the required data and ensuring all business rules are followed with the Worker doing a simple data entry blindly trusting the input it is given. It makes sense if you have some rules, but you still want to keep the Worker as a flexible tool for the business users who sometimes have to create tasks where they best know what is the right data.

Multiple Allocators

The Allocator -> Worker pattern can easily be extended with several Allocators. One scenario could be where you have one Allocator daily checking for new items in a database, and to ensure transparancy the Worker is required to have a Task for each of them. Another Allocator could run maybe once a month and check all existing items, but only create the ones where it can see some data being wrong according to a set of rules. With a simple data entry Worker, it would not be a problem to have two Allocators work seperatly feeding the same Worker.

Multiple Workers

Extending with multiple Workers can be a really great idea if the Business Process consists of many seperate steps. For example if the Process requires data entry in multiple systems, or require multiple independant updates in the same system. This way, it becomes very transparant what has been done for each Key, and if a problem arises in one place then the rest of the Business Process can be completed with the Agents only having minimal work left.

Having an Allocator create multiple tasks in multiple processes at once allows for parallelising work, which is really great if the work can be done independant. It also leaves the different Worker processes as flexible tools for the business users to create ad-hoc tasks in as needed.

Another idea is to serialize work, if you have a Business Process where a job has to be performed step-by-step. This could be done by first having an Allocator start the work by creating a Task in the first Worker, and then when the first Worker solves a Task a new one is created in a second Worker and so forth.

You could ofcourse achieve the same results with one big automation script that uses a single Process however by splitting the Business Process up in smaller sub-processes it becomes easier to maintain and extend later on for the automation team, and more transparant what have been done.