Let’s OptaPlan your jBPM tasks (part 1) - Integrating the two worlds

In the last months we’ve been working on integrating OptaPlanner and jBPM with that purpose.

The concept is very simple: "let each tool do the piece of work it is good at, integrate the results, and provide a better user experience".

The following image shows a simplified view of the integration:

The following image shows how the tasks are assigned when integration is enabled:

The tasks marked in blue are assigned to the user katy while the tasks marked in red are assigned to the user maciek.

As part of the integration, OptaPlanner was able to:

Yes, now they can focus on executing their assigned work. But most importantly, it also means that the responsibility and decision making was transferred from humans to optimization algorithms.

Usually, a running BPMS creates many process instances and many human tasks. At the same time, users are working and completing these human tasks. This cycle is repeated over and over.

OptaPlanner addresses this situation by recalculating the optimized plan when new human tasks are created or completed and produces new assignments to reflect the new optimized plan. This is often achieved by combining different "Repeated Planning and Real Time Planning" techniques.

Additionally, it might be the case that a plan that was optimal at time N is no longer optimal at time N+1. For example, a higher priority task has arrived and must be performed as soon as possible. The direct impact of this situation is that the programmed assignments at time N might change at time N+1, which means that tasks are routinely reassigned many times when the new optimized plans are calculated. One of OptaPlanner’s strengths is the ability to react to a changing context.

If not controlled, continuous task reassignment might negatively impact the user’s experience because they might feel that tasks come in and out of their workload randomly. This situation is present in other types of optimization problems as well and is usually managed by combining different repeated and continuous planning techniques. For detailed information see the "Repeated Planning" section of the OptaPlanner’s User’s Guide.

A simple strategy is to introduce the concept of a planning window which is a defined subset of the available work that will not be changed or reassigned even when new plans are calculated. Only this subset is available to users. The tasks in the planning window are called published tasks. The previous example contains a planning window with a size of two.

Users concentrate on completing these tasks and OptaPlanner concentrates on keeping the optimized plan updated and assigning more work to them as soon they start completing the published tasks.

The following constraints were used for the plan calculation:

At the beginning of this post we showed how the human tasks are configured and how the group information is set. Then, we showed how this group is used for calculating the plan and making the assignments. But let’s take a deeper look at these tasks.

The image shows how both tasks are configured with an input parameter skills that are assigned with some of the process variable values. At runtime these assignments connect the process business data with the tasks information and OptaPlanner can include it for the plan calculation.

The following example shows how the credit card type and language selection is entered when the process starts. (Note that this information could have been collected by the process by using any other mechanism.)

Finally, this information will be used to establish which of the available CreditAnalyst and ClientRelations users are best suited for each task instance.

The following users configuration was used to execute the preceding processes:

Let’s now see the information for task #70:

We can see that "Task #70 requires a CreditAnalyst user with skills in the MASTER credit card". This is why it was assigned to katy.

As soon as this task is completed, a new instance of the Notify Customer task is created.

The following image shows the new instance information:

We can see that the Spanish language was selected as the "Preferred language for communications", which establishes that:

"Task #76 requires a NotifyCustomer user with skills in the Spanish language", and this is why this new task is assigned to john.

Note that the example above is quite linear, only four users are defined, and the possible assignments are direct. This was done intentionally to show how the assignment decisions are made accordingly with the configured groups and the tasks business data. However, in production environments usually both the set of available tasks and users are huge, and for example at a certain point in time there might be many candidates for a task, and so forth. Here is when OptaPlanner’s work becomes crucial, because the optimized plan is calculated by taking into account all the constraints described above.

No, the integration is provided as a set of Kie Server capabilities and can be easily used and integrated in other projects and scenarios. See KIE Server Task Assigning

Usually, a running BPMS creates many process instances and many human tasks. Standard BPMS products assign these tasks following a bucket-model, making them available to a set of users named the "Potential Owners" for the tasks. None of these users are responsible for the tasks and before working with a particular task they must claim it.

This model transfers the responsibility of the tasks selection to the users that must execute a manual procedure. In many scenarios that selection is far from optimal.

By integrating OptaPlanner with jBPM, we can go one step further and produce direct assignments of tasks to the users according to an optimized plan. This plan is calculated by considering the process semantics, a set of constraints, and the business data.

Responsibility and decision making was transferred from humans to optimization algorithms.