Resources play an essential role in the execution of business processes as they perform the work of the business steps. Thus, resource management and allocation has a high impact on the efectiveness and eficiency of the business processes. In existing process execution systems, the capabilities of managing and allocating resources are limited. In this demo, we present a resource manager, Rembrandt, that supports to specify resources with the help of hierarchies and attributes, as well as resource allocation recipes. The allocation recipes can also be executed, whereby advanced allocation algorithms of any programming languages can be integrated. Rembrandt ofers a front-end and REST APIs that can be used by practitioners and researchers to apply its capabilities in process execution systems or simulators.
Resources are essential for the process execution (human and non-human) ensuring the process
progress by executing the tasks of a process case. Often resources are limited and expensive such
that companies strive to optimize their resource utilization whenever possible [
In this demo, we present an open-source resource manager, called Rembrandt2, enhancing
process execution engines or process simulators by advanced resource management and
allocation capabilities. Rembrandt enables users, on the one hand, to represent the organization’s
resources and resource hierarchies and specify their attributes. On the other hand, resource
allocation plans (i.e. allocation recipes) can be defined where the input, all available resources,
and the output, the allocated resources, can be specified. For running these plans, one or
several techniques or heuristics (e.g., the Munkres algorithm [
In the remainder, we present the main functionalities in more detail. To show the maturity of the approach, we demonstrate two integrations of the tool.
The resource manager Rembrandt can be used to create, store, and delete resources and is able to integrate optimization algorithms to use them for the advanced allocation of resources. The back-end consists of two components as shown in the architecture in Fig. 1, the resource organization and the resource optimization. The resource manager provides diferent interfaces to connect to, a user interface for human operators and a REST API for other systems, such as Camunda.
In this component, resource types and instances can be defined, either via the Rembrandt front-end or the provided REST API.
Rembrandt allows to define hierarchies between resource types. As shown in Fig. 2, Letter and Parcel can be modelled as sub-types of a Shipment type, and therefore share the attributes receiver, sender, and delivered, but the attributes dimensions and weight are exclusive to parcels.
In this component, resource recipes can be defined, that are executed during run-time via the provided REST API to receive an optimized resource allocation for a process activity. 1–5 Allocation recipes. Resource allocations ifrst need to define the resources required as well as additional constraints. This can be specified via so-called allocation recipes in Rembrandt. They contain step-by-step instructions executed by the resource optimiza- Figure 2: Example of a class hierarchy of shiption component as soon as the corresponding ment resources optimization is requested. Rembrandt ofers in its front-end a user interface for the creation of recipes as depicted in Fig. 3. It is a block based plug-in system with four diferent types of basic blocks, called ingredients: Ingredients are independent parts of the recipe that are self-contained, reusable components. Each recipe starts with at least one input ingredient, which is one of the predefined resource types. They are used to gather all resource instances of this specific resource type. In front and behind of optimization algorithms, transformer ingredients can be used. They ofer functionality to modify resources to fit the respective needs of the following building block. Transformers can change values of resource attributes, filter the list of resources, or even change the type of the object they are working on. The most important ingredient is the optimization ingredient. It symbolizes a concrete optimization algorithm created by the optimization expert and has an arbitrary number of input ports and output ports, depending on the number of defined inputs and outputs when registering the algorithm to the platform via a docker container. At the end of each recipe an output ingredient is placed which contains the result of the optimization. Each output ingredient saves its result in the resource manager as one resource instance of the respective type so that the platform can continue working with it. Furthermore, recipes can be reused within other recipes to build upon previous work and merge common steps into one block. This allows combining multiple smaller solutions to one complex optimization pipeline, without loss of structure and clarity.
Resource Allocation Resource allocation is responsible for taking resource allocation requests, e.g., from a process execution system, collecting them, and executing recipes inside the resource manager. A resource allocation requests describes the requested type of resource(s) and the needed allocation recipe. During execution, all resource instances of all input resource types for this recipe are gathered first. Secondly, transformers are applied to the collected resource instances and subsequently, their results are passed to the algorithm which is executed using the respective docker container. Lastly, the output of it is stored as a new or modified resource instance and returned to the requestor.
Working with the platform follows a clear sequence of steps. To execute a complete resource management cycle, a few steps have to be performed: First, the general structure of resources has to be modelled by creating a type hierarchy. As soon as this is done, concrete resource representations can be instantiated and later modified. In parallel to the instantiation, the resource allocation can be defined. This includes registering the available optimization algorithms, matching them to corresponding resources as inputs and outputs, and creating appropriate recipes. Lastly, resource allocations can be initiated by a process execution engine or a simulator. The concrete step-by-step guide can be found here: https://rembrandt.gitbook.io/docs/use-case-guide/set-up.
As mentioned before, our tool is stand-alone and thus runs separately from any process engine.
However, to fully leverage the benefits of our tool, an integration into an existing process
execution engine or simulator is necessary. The tool can be integrated into existing approaches
by using the documented application programming interface (API) based on REST/HTTP. For
demonstration purposes, we have integrated Rembrandt with the process engine Chimera4, the
process modeler Gryphon5 and the simulation tool Scylla6 as shown in the following.
Integration with a Process Execution Engine In the first use case, we integrated
Rembrandt with the process engine Chimera [
The research leading to these results has been partly funded by the BMWi under grant agreement 01MD18012C, Project SMile. http://smile-project.de