A generic BPMS user portal for business processes execution interoperability
Andrea Delgado, Daniel Calegari Instituto de Computacion,´ Facultad de Ingenier´ıa Universidad de la Republica´ Montevideo, Uruguay, 11300 {adelgado, dcalegar}@fing.edu.uy
Abstract—A Business Process Management System (BPMS) REST/SOAP API that allows the portal and other applications integrates several software modules to support the business to invoke specific operations from the process engine. process (BP) lifecycle. A process modeler, process engine, a web There is a wide variety of BPMS, both open source and portal for interaction with users, and a REST/SOAP API which exposes operations from the engine are key ones. In previous proprietary, with different support levels for the BPs lifecycle. works we have evaluated several BPMS identifying similarities In previous works we have evaluated several BPMS [7], [8] in terms of the concepts they manage in their user portals and identifying similarities in terms of the concepts they manage the APIs they expose, and how the user portals became highly in their user portals and the APIs they expose. In such works coupled to the underlying process engine through the provided we have evidenced that user portals are usually tightly coupled API. We proposed a generic user portal that makes invocations to a generic API decoupling the portal from the specific process with the native process engine API. The independence between engine it invokes, which can be exchanged through the generic the front-end and the process engine provides means to migrate API invocation to different process engines. In this paper we from one process engine to another without affecting the user present an extension of this work by adding concepts to the experience, as well as offers a unified interaction layer for generic API and data model, a comparative analysis between external applications, similarly to the way applications already BPMS, as well as the implementation of adapters for three different engines to show its capabilities. work nowadays with many database management systems. Keywords: Business Process Management Systems (BPMS), Thus, in [9] we proposed a generic (process-independent) generic BPMS user portal, generic API and data model BPMS user portal which can be integrated (loosely coupled) with potentially any process engine for the execution of I.INTRODUCTION business processes. It is based on a unified data model and Business Processes (BPs) [1], [2], [3] describe how organi- a generic process engine API. zations carry out their business, identifying elements such as In this paper we present an extension of these works participants performing activities, the sequence order between by: improving the comparative analysis between BPMS and them, business rules, different paths of process execution, and expanding the concepts managed by unified data model and interactions with other participants, among others. Process- the generic process engine API. The contributions of this work Aware Information Systems (PAIS) [4] provide support for are threefold. In the first place, we extend the generic API and BPs driven execution as the core of the system. In this type data model to support the execution of BPs from the generic of systems, BPs drive the flow of the activities that are carried user portal we have defined, thus providing a complete and out within the organization, providing the basis for the analysis comprehensive definition of operations and concepts covering and continuous improvement of BPs. different BPMS approaches. In the second place, we present a Business Process Management Systems (BPMS) [1], [2], comparative analysis between six different BPMS, extending [5] are a specific type of PAIS supporting the BP lifecycle our previous analysis to include other attributes and elements based on an explicit representation of BPs. The business expanding the spectrum of process engines to which our process lifecycle [2] can be described as an iterative process solution can be integrated. Finally, we implement adapters involving the modeling and simulation of business processes, for three different engines and a runtime selection of process the software development for their support, their execution and engines without changing and/or implementing anything else its corresponding monitoring and evaluation. In this context, in the generic user portal, proving that it can be integrated any BPMS provides as key modules [1]: a process modeler with several and different process engines without changing usually based on a specific process modeling language, such the user experience and navigation between functionalities in as the Business Process Model and Notation (BPMN 2.0) [6]; a the portal. process engine which is able of executing such process model; The rest of this paper is organized as follows. In Section II a user portal, which is usually a web application, allowing we present and discuss related work. In Section III we present users to interact with the process engine in order to manage an extension of the BPMS evaluation, and in Section IV we processes, activities and other BPs execution elements; and a provide a description of the generic API and data model we 978-1-5386-3057-0/17/$31.00 c 2017 IEEE have extended to integrate with the generic user portal, along with the prototype implementation. In Section V we present A. BPMS portal evaluation revisited a case study regarding the implementation of the adapters for In this section we present the revision of new versions of three process engines: Camunda, Bonita and jBPM. Finally, the BPMS we have already evaluated, presenting new elements in Section VI we present some conclusions and future work. and key concepts. 1) Actitivi: II.RELATED WORK The new version of Activiti 6.0 was released on May 2017 In previous works [7], [8] we have evaluated several open with major changes at the application user interface including source and proprietary BPMS based on a defined list of key separated apps for different users, following the structure of functional and non-functional characteristics that this kind of the Alfresco Activiti commercial suite. After that Activiti tools must provide. We have identified some first level features 7.0 was released as a cloud application, being the 6.0 the that allow us to classify existing BPMS based on: category, last standalone release. Activiti also provides support for the type, process engine language and API type, which we used Decision Model and Notation (DMN) [13] standard [14]. to select a representative BPMS of each equivalence class. Web user portal: Activiti provides two new web applica- These representative BPMS were analyzed as a basis for our tions for users to interact with the Activiti process engine: definitions in [9]. In [9] we also provided a detailed descrip- TaskApp and IdentityApp. The TaskApp presents two menus: tion of other approaches that tried to unify BPM concepts. tasks and process, where it provides access to the working list Although we refer to such work for more information, it for a user to perform tasks, start processes and tasks, claim is worth mentioning some works that come from the initial and reassign tasks, query execution data, among others. The definition of Workflow Management Systems, as the Workflow IdentityApp is focus on admin users to create configurations Reference Model and the Workflow Management Facility and administer groups and users assign to them. In the Specification [10], [11] in which key functionalities for a commercial distribution also an AnalyticsApp is provided with workflow engine are defined. Also, in [12] some workflow dashboards for the execution of processes. systems functionalities are analyzed with focus on defining a Data Model: The concepts defined by Activiti remain the reference model for the management and monitoring interface. same as the ones we already evaluated. They correspond to Compared to these works, our proposal provides a unified view the following three categories: definition of processes (process, of concepts and relationships regarding the execution of BPs, task, variable, group, user), execution (process instance, task along with a highly decoupled view of the main components instance, variable instance, event, form data, etc.) and execu- of a BPMS for process execution. tion history (historic process instance, historic task instance, historic variable instance). It is also worth mentioning that our unified data model Generic API: Activiti provides a REST API to expose represents information related to process execution and user operations from the process engine, which also remains the worklist management, from the perspective of a user portal. It same as the one we already evaluated. Resources are managed means that it does not considers detailed information about grouped in sub APIs: Repository, Runtime, Identity, History, each process model and its corresponding configuration as Forms and Management. Access to any resource needs the any metamodel for classical process or workflow modeling user to be authenticated, for which Activiti uses the ”Basic languages, as BPEL or BPMN. As an example, within a authentication” as security method. user portal is enough to know if a user task is active and 2) Bizagi: its corresponding form, but not the events or sequence flows Version 11 of Bizagi was released on 2016 and subsequent related with it. sub versions were release under the 11 numbering being the 11.2 release the current. III.BPMS PORTAL EVALUATION Web user portal: Bizagi organizes the user portal in a In [9] we presented the analysis of three BPMS represent- single web application with six menus: home, inbox, new case, ing different combinations of the defined first level features: queries, reports and admin. In the home menu information of Activiti1, Bizagi2 and Bonita3, to compare the concepts and the user is organized and, in the inbox, menu access to the definitions they manage throughout their user portal and en- work list of the user is provided, to perform, manage and gine API. We extended this work by including the evaluation control activities and process instances in which the user is of other three BPMS: Camunda4, Flowable5 and jBPM6, and involved. The reports menu presents an analysis dashboard a revision of new versions of the first three we analyzed. In where data on the process execution can be visualized and the following we present the previous evaluation revisited and analyzed. The rest of the menus present complementary func- the extension of the evaluation. tionalities to the user. Data Model: The concepts defined by Bizagi remain the 1Activiti BPM: https://www.activiti.org/ same as the ones we already evaluated. As key ones it identifies 2 Bizagi BPMS: https://www.bizagi.com/ Process for definitions and Cases for process instances, Task 3Bonita BPM: https://www.bonitasoft.com/ 4Camunda BPM: https://camunda.com/ for definitions and Activity for task instance, groups, roles 5Flowable: https://www.flowable.org/ and users. It also adds the organization concept to support the 6jBPM: https://www.jbpm.org/ modeling of organization hierarchies. Generic API: Bizagi added a REST and OData services application provides functionalities related to process monitor- API to provide access to the underlying business information ing and execution statistics. in the data model and process engine. It uses the standard au- Data Model: Camunda follows some concepts definition as thentication mechanism OAuth version 2.0 to provide human Activiti, such as process, task and variable definition, process, and server interaction based on credentials. The resources are task and variable instance, event, form data, and execution grouped in: general use, my stuff (relative to a user), searches, history by historic process instance, task instance and variable relevant processes, processes, cases (as process instances), instance, but some names are different. It also defines group queries and entities. When the OData services API does not and users adding the concept of authorization (as role). cover the integration requirements the SOAP API can be used, Generic API: Camunda provides a REST API with op- using the WS-Security feature via web services invocations, erations to access the process engine. It it also organized in which remains the same as we already evaluated. sub APIs for: processes, tasks, users and variables definitions 3) Bonita: and instances, and also an API for accessing the execution Version 7.5 of Bonita was released on August 2016 and history. Authentication to invoke operations in the REST API subsequent sub versions were release under the 7 numbering is provided via Basic Authentication or via cookies. being the 7.8.4 release the current. 2) Flowable: Web user portal: Bonita user portal is provided in a Flowable is also based on Activiti but supported by the original single web application which organizes users actions in three Activiti developers, version 6.4 was released on 2018 and the menus: tasks, cases and processes, to access the work list current version is 6.4.1. Flowable also provides support for the and perform, manage and control tasks in which the user standards CMMN and DMN [14]. participate, view cases and initiate processes. The admin user Web user portal: as Activiti, it provides three web appli- can also manage processes definitions, groups, users among cations for user interaction: Flowable Task, IDM and Admin. others, with different menus that are listed only for that user, The task application provides access to the work list for users such as configuration, resources and data models management. to claim, perform and search tasks and processes instances Data Model: Bonita concepts also remain the same as the and start processes, among others. It is organized in three ones we already evaluated. As key ones a process defini- menus: tasks, processes and cases. The IDM application is for tion which is named Application, cases, tasks definition and managing groups and users. The Admin application allows ad- instances, variables definition and instances. It also defines ministrators to query the process engine to view deployments, profile, role, group and membership for managing users and instances, tasks, variables on real time. user’s rights. As Bizagi, it provides the organization concept Data Model: Flowable as Activiti fork provides mainly to support the modeling of organization hierarchies. the same concepts as Activiti, at least at the moment of the Generic API: Bonita provides a REST API which allows evaluation, so we refer to that model. to access processes, tasks, users and other execution elements, Generic API: Flowable also provides the same REST API organized in the following sub APIs: bdm (for business data), as Activiti, at least at the moment of the evaluation, so we bpm (for processes), customer info, identity (groups, roles, refer to that API. users), platform, portal (profiles, rights over pages), system 3) jBPM: (session, translation, tenant), application, tenant and form. It Version 7.7 of jBPM was released on 2018 and subsequent provides an authentication service which returns a cookie sub versions were release under the 7 numbering being the session that must be sent in every invocation. 7.20 release the current. It also provides support for DMN and partially to CMMN [14]. B. BPMS portal evaluation extended Web user portal: jBPM provides in the KIE Workbench In this section we present the extension of the evaluation we several applications for users to manage tasks, processes, rules, carried out by adding the evaluation of three different BPMS, deployments among others. It provides the tasks inbox to presenting their key concepts. claim and perform tasks, and other functions such as start 1) Camunda: processes and view process execution and reports. Also, the Camunda is based on Activiti, version 7.9 was released on administrator can create and assign groups and users. 2018 and the current version is 7.10. Camunda also provides Data Model: jBPM defines as main concepts process support for the standards Case Management Model and Nota- definition, UserTask definition and variable definition, process, tion (CMMN) [15] and DMN [14]. task and variable instance, users and roles, among other. Web user portal: Camunda as Activiti, provides three Generic API: jBPM provides both a REST and SOAP API. different web applications for users actions: Tasklist, Cockpit We focused on the REST API which provides a sub API for and Admin. The Tasklist application provides users with their the KIE server which corresponds to the KIE workbench as corresponding work list to perform tasks, claim and reassign the user portal. It defines several sub APIs: containers (to tasks, search and query tasks and processes, start processes, manage server containers), process (for process instances), among others. The Admin application provides support for process definition, task instances, query (for queries on process defining and managing users, groups and rights. The Cockpit definitions, instances and tasks), among others. Fig. 1: Generic BPMS portal Architecture
IV. GENERIC BPMS PORTAL EXTENDED B. Generic data model In what follows we introduce the general architecture of The generic data model definition is a generalization of the proposal, key concepts from the unified data model, and concepts from the BPMS we have evaluated, based on the the corresponding concept from each evaluated BPMS, and analysis and comparison of concepts defined by each one as an excerpt of the generic process engine API. Complete presented in Section III. For doing so, we defined a unified information can be found in [16]. data model in which for each concept we named it uniquely and we trace it to each concept defined by each BPMS for A. Generic BPMS portal Architecture traceability. The extended unified data model also respects The architecture, depicted in Fig. 1, is based on three layers: the unified concepts from the previous work, so we can also presentation, services and integration. The presentation layer maintain the definition of operations in the generic API and the comprises the definitions regarding the generic BPMS portal, basis implementation of the generic BPMS portal. In Table Ia providing functionalities for users and administrators. The we present some concepts from the generic unified data model services layer is defined based on the generic unified data and their corresponding concepts for each BPMS. model and the generic REST API of services (operations). The column ”Unified model” presents the unified concepts, Finally, the integration layer is in charge of the communication i.e. the ones the generic portal and API will use, and in with the specific process engines allowing the realization each of the other columns we reference the concepts from the of the generic operations in concrete ones. It translates the corresponding process engine. In the ”Unified model” column definitions in the generic operations and data model, to one some concepts are not integrated: context, membership, profile or several operations from the specific process engine. The and data. For example, in the case of membership, profile and generic BPMS portal invokes the generic API via the defined data they are only present in Bonita and are associated with concepts of the generic data model, and the generic API the user, these concepts can be translated in the corresponding invokes the concrete process engine APIs for each specific invocations to the concrete concepts and operations of the process engine, via the defined adapters between the generic Bonita process engine. operations and data, and the concrete ones. TABLE I: Unified data model and process engine API Unified model JBPM Activiti Flowable Bonita Camunda Bizagi Process Process definition Process definition Process definition Process Process Definition Process Task definition UserTask Task Definition - Task Definition Task Task Definition Deployment Container Deployment Deployment Application Deployment - Resource Image Resource Resource - Resource - Model - Model Model - - - Variable definition Variable definition Variable Definition Variable Variable Defini- - variable definition tion/Contract - - - - Context - - User - User User Actor/User User User Group - Group Group Group Group Domain Role - - - Role Authorization Role - - - - Membership ------Profile ------Data - - Form Form Form data Form data - Form - Query Query - - - filter Query Tenant - - - - Tenant - Variable instance Variable instance Variable Instance Variable Variable Instance. Variable instance Variable instance Execution Node Execution Execution - Execution - instance/workItem Event Event Event Event - Event Event Comment Task Comment Comment Comment Comment Comment Comment Attachment Task Attachment Attachment Attachment - Attachment - Case Process instance Process instance Process Instance Case Process Instance Case Task instance Task instance TaskInstance Task Task Instance Task Activity (a) Unified data model concepts (excerpt) Operation Activiti Bonita Bizagi Camunda JBPM Flowable startCase(int processId, POST POST /process- /cont id/pro- POST createCases IEnumerable
As an example, in Fig. 2 we show the unified data model The colors correspond to different phases or views: green for for the key process concept and related extended concepts. execution (two concepts on top) and orange for administration. Fig. 2: Generic unified data model (excerpt) extended elements
This model presents key execution concepts such as Job and such as Role, Group, User, Process, Task and Variable defini- Execution, where the latter is associated with a Deployment tion, Case, Task instance and Variable instance are shown. which corresponds with the definition of several elements of a process. Model, Process, Form, Query and Resources Fig. 3 presents the relationships between process, task and are defined elements which are executed by means of a variables definition in design time (orange for administration), deployment in the process engine. case, task instance and variable instance in runtime (green for execution). In this model we also present an example of For the sake of clarity, we also present in Fig. 3 an excerpt of the historic extension with the concept history of variables the original definitions from [9], where more familiar concepts instances (pink for historic). Fig. 3: Generic unified data model (excerpt) base elements from [9] and variables extension
C. Generic process engine API key operations it will allow the authentication of users based on the rights assigned, to carry out a set of actions such as: The generic process engine API is a REST API that provides operations which manage the unified data model, • view active and no active processes, filter by name, being invoked from the generic BPMS user portal to offer category and state, activate or deactivate processes, query the functionalities to be able to carry out the execution of BPs data, assign a category; from organizations, regardless the specific process engine. As • list all instances of a process, create a new instance, delete an instance, query information on an instance, add comments and obtain comments; • view tasks and obtain information about them, claim and re-assign tasks, update variables and complete tasks; • manage groups, roles and users, allowing the creation, update, listing and deletion, assign users to groups and roles as well as unassigning them. Table Ib shows an example of operations defined in the generic process engine API and the mapping to the corre- sponding operation defined by each evaluated BPMS API. It it is worth mentioning that to be able to satisfy an operation from the generic API it could be necessary to invoke more than one operation in the API of the specific process engine. For example, if when querying the process engine about a task the information of the associated process is needed, if the Fig. 4: Vacation leave request BP in BPMN 2.0 specific process engine does not return this information, other operations should be invoked in order to obtain it. Also, if the underlying process engine does not provide some functionality (i.e. reassign a task to another user) that functionality will not be available to the user from the Generic BPMS portal execution for that process engine. Regarding the management of groups, roles and users, what we provide is a minimal set of operations to deal with that information at runtime, which are needed by the Administrator user as described in [9] (see Table 3 on page 49 and Fig. 5 on page 52). Complex management of organizational models can be carried out in model editors and configuration tools as usual, and when impacted in the corresponding process engine, we will be able to manage them on the Generic BPMS portal by means of the defined operations. Fig. 5: Login into the generic BPMS user portal with engine selection D. Tool support The tool can be found in [16] and is an extension of the prototype implementation we developed in the previous work. services that must be implemented by each adapter and the As main improvements, the presentation and the backend are unified data model. It provides a map to the generic API which highly decoupled based on two war applications, a tenant includes all classes implementing the defined interface along approach is provided, and it is possible for users using different with the identifier of the corresponding process engine. These process engines to access them via a single instance of the classes are instantiated using Java Reflection. It stands out with generic BPMS user portal, by selecting it when login into this implementation, the low cost of adding a new process the application. The platform is able to redirect each user engine to the current solution. The component jar contains to the selected process engine at runtime. This is achieved everything necessary to connect with a new engine; the adapter by defining a properties file in which three properties are must implement the interface that is provided, defined each of included to declare a process engine: location of the adapter the three properties in the ”adapter.properties” file as presented implementing the process engine invocations, URL of the before, and add the implementation of the new adapter as a process engine and authentication URL, as shown in the jar in the Tomcat libs directory, without modifying anything following example. that is already implemented.
V. CASESTUDY ubicacionMotor1 = adapter.camunda.IBpmsEngineCamunda urlMotor1 = In this section we present a case study based on the http://localhost:8081/camunda/api/engine/engine/ implementation of the well-known process ”Vacation Leave default/ AuthenticationUrl1 = Request”, depicted in Fig. 4, for three different BPMS: Ca- http://localhost:8081/camunda/api/admin/auth/ munda, Bonita and jBPM. Besides is a very simple case study, user/default/login/welcome; it is enough as a proof of concepts from the perspective of the generic BPMS user portal functionalities. In the integration layer a specific component includes the The first step is to login into the generic BPMS user portal, definition of the interface for the API REST including the in which the process engine to interact with must be selected. (a) Bonita
(b) Camunda
(c) jBPM Fig. 6: Generic BPMS user portal processes menu with definitions
Based on this selection, the execution of the BP will continue for that user in the selected engine. In Fig. 5 a screenshot of the login page is presented. After the user is authenticated within the selected process engine, the generic BPMS user portal presents the menus for interact with: tasks, cases and processes, as defined in the Fig. 7: Operation of the generic API and corresponding unified data model. When selecting the menu for processes operations the list of existing processes is presented to the user. In Fig. 6 a screenshot with the result for each process engine is shown. To show these results the generic BPMS user portal is always invoking the same operation within the generic process engine API and managing the same concepts of the generic data model. The corresponding process engine adapter trans- lates the invoked operation into the corresponding operation/s Fig. 8: Operation of the generic API and corresponding for the specific engine and also translates the return of the operations operation/s into the generic concepts to be return to the generic user portal. Fig. 7 shows a screenshot of the generic API operation and the corresponding operations in each engine. and from the corresponding operations and data of the specific After viewing the process definition, a process instance can process engine. Fig. 8 shows a screenshot of the generic API be started by invoking the operation in the generic API to do operation and the corresponding operations in each engine, to so. As before, the adapters translate the operation and data to start a process instance. REFERENCES [1] M. Dumas, M. L. Rosa, J. Mendling, and H. Reijers, Fundamentals of Business Process Management. Springer, 2013. [2] M. Weske, Business Process Management - Concepts, Languages, Architectures, 2nd Edition. Springer, 2012. [3] W. M. P. van der Aalst, A. H. M. ter Hofstede, and M. Weske, “Business process management: a survey,” in Business Process Management, International Conference, BPM 2003, Proceedings, ser. LNCS, vol. 2678. Springer, 2003, pp. 1–12. [4] M. Dumas, W. M. van der Aalst, and A. H. ter Hofstede, Process-aware Information Systems: Bridging People and Software Through Process Technology. Wiley, 2005. [5] J. Chang, Business Process Management Systems: Strategy and Imple- mentation. CRC Press, 2016. [6] OMG, “Business process model and notation (BPMN) version 2.0,” OMG, Tech. Rep., 2011. [7] A. Delgado, D. Calegari, P. Milanese, R. Falcon, and E. Garcia, “A systematic approach for evaluating BPM systems: Case studies on open source and proprietary tools,” in Open Source Systems: Adoption and Impact - 11th IFIP WG 2.13 Intl.Conf., OSS 2015, Proceedings, ser. Fig. 9: Error of conversion in a variable type IFIP, vol. 451. Springer, 2015, pp. 81–90. [8] D. Calegari and A. Delgado, “Systematic evaluation of business process management systems: a comprehensive approach,” CLEI Electronic Journal, vol. 21, 08/2018 2018. As mentioned before, the adapters perform all translations [9] A. Delgado, D. Calegari, and A. Arrigoni, “Towards a generic bpms and conversions between operations and concepts, and also user portal definition for the execution of business processes,” Electronic between values for variables of type String to Integer or Notes in Theoretical Computer Science, vol. 329, pp. 39 – 59, 2016. [10] OMG, “Workflow management facility specification, v1.2,” OMG, Tech. Boolean, to be able to invoke the corresponding process engine Rep., 2000. with the correct type. For doing this the defined type for each [11] W. M. Coalition, The Workflow Reference Model. Workflow Handbook. variable must be considered. Fig. 9 depicts an error returned by Wiley, 1997. [12] M. zur Muehlen, Workflow-based Process Controlling: Foundation, the specific process engine when the value cannot be converted Design, and Implementation of Workflow-driven Process Information to the corresponding type. Systems. Advances in Information Systems and Management Science. Logos, 2004. VI.CONCLUSIONSAND FUTURE WORK [13] OMG, “Decision model and notation (DMN) v1.1,” OMG, Tech. Rep., 2016. In this paper, we have presented an extension of previous [14] A. Delgado and D. Calegari, “Towards integrating bpmn 2.0 with cmmn and dmn standards for exible business process modeling,” in Conferencia work regarding the definition of a generic BPMS user portal, Iberoamericana de Software Engineering (CIbSE) 22 - 26 Abril, La by evaluating other BPMS to enhanced the generic process Habana, Cuba, In press 2019. engine API and data model we have defined, with the aim of [15] OMG, “Case mgmt model and notation (CMMN) v1.1,” OMG, Tech. Rep., 2016. decoupling the user portal from the underlying process engine [16] D. Rodr´ıguez, B. Remedi, and A. Guggeri, “Generic BPMS executing the processes. we presented the evaluation of six user portal,” 2018. [Online]. Available: https://gitlab.fing.edu.uy/open- BPMS platforms, three as revision of a previous evaluation and coal/portalbpms new evaluations of three added BPMS, in order to compare concepts and operations from their process engine APIs. Our solution not only allows the underlying process engine to be changed (i.e. allowing interchanging process engines within the same portal) but also the implementation of the user portal in different technologies (i.e. decoupling the user interface from the process engine). This provides more flex- ibility to organizations that has special requirements for user interfaces or infrastructure to run the process engines, allowing them to use any combination. What is more, in our current im- plementation we provide support for multi-tenant applications and for users to execute processes in different process engines within a single generic BPMS user portal instance. We plan to continue extending both underlying concepts and operations and the current implementation.
ACKNOWLEDGMENT We would like to thank undergraduate students who worked in the BPMS portal prototype: Diego Rodr´ıguez, Belen´ Remedi, Alejandro Guggeri.