AKIP Process Automation Platform: A Framework for the Development

of Process-Aware Web Applications

Ulisses Telemaco Neto

1 a

, Toacy Oliveira

2 b

, Raquel Pillat

2 c

, Paulo Alencar

1

David R. Cheriton School of Computer Science, University of Waterloo, Waterloo, Canada

2

limitations related to the adoption of these solutions, which include: vendor lock-in, limited UI/UX, limited

integration, outdated technology stack, and lack of support for non-process features. The framework presented

in this paper addresses these problems and limitations by providing an open-source platform to facilitate

the development of process-aware information systems (PAISs) based on code generation techniques. The

platform is capable of generating a functional process-aware Web application from a business process model

defined in BPMN. To the best of our knowledge, there is no other software tool that generates fully functional

process-aware Web applications. The presented framework has been evaluated in the academy and industry

and used to develop dozens of non-profit and commercial process-aware applications.

1 INTRODUCTION

Despite the huge amount of capital and effort that

through email exchanges, phone calls, and manual in-

tegration between systems. This scenario may lead to

several problems, including: Vendor Lock-in: One of

the main risks of adopting a proprietary platform is

being forced to continue using its product or service,

regardless of quality, cost or any other reason, because

it is not practical to switch away from that product

or service. Limited UI/UX: Despite claiming that the

systems provide features for building dynamic forms,

the forms produced by the BPA platforms are still

https://orcid.org/0000-0002-5420-6966

d

https://orcid.org/0000-0002-5373-8522

e

https://orcid.org/0000-0003-0092-2171

plex components (such as auto-complete input fields

or elements whose validation rule is more sophisti-

cated) becomes challenging and often unfeasible on

some low-code platforms. Limited Integration: Many

solutions for BPA provide extension mechanisms de-

signed to integrate the platform with existing systems

Lack of support for non-process features: Another

limitation of BPA platforms is that they focus only

on process automation and often provide limited sup-

port for other features that are usually necessary for

process execution. For example, customized authenti-

cation mechanisms, CRUD

import/export data are typically features hard to de-

velop in BPA solutions. There is a need of solutions

that can support the automation of both process and

1

with many other issues such as process tracking, or-

ganizational agility, team communication and process

redundancy. Because of the critical relevance of each

of the items, it is difficult to identify the one that

Systems (PAISs), i.e., systems whose requirements

are described using process models such as BPMN,

helps to address natively most of the problems just

mentioned (Dumas et al., 2005).

There are several solutions for BPA, including

open-source and proprietary platforms. These solu-

tions will be briefly described in Section 3. The main

problems and limitations of these solutions are:

1. Vendor Lock-in: One of the main risks of adopting

a proprietary platform is being forced to continue

quite limited. In this way, the construction of

complex components (such as auto-complete in-

put fields or elements whose validation rule is

more sophisticated) becomes challenging and of-

ten not feasible on some low-code platforms.

3. Limited Integration: Many solutions for BPA pro-

vide extension mechanisms designed to integrate

the platform with existing systems or third-party

solutions. However, implementing such integra-

tions are still costly, not efficient, and sometimes

other limitation of current BPA platforms is that

they focus only on process automation and of-

ten provide limited support for other features that

are usually necessary for process execution. For

example, customized authentication mechanisms,

CRUD

data are typically features hard to develop in BPA

solutions. There is a need for solutions that can

2

Acronym for Create, Read, Update, and Delete

support the automation of both process and Web-

related features.

To mitigate these problems and limitations, one

gine is that this integration is not straightforward and

can be very challenging and costly (Samland and Tut-

ing, 2019) (Straube and Horn, 2021) (Shan, 2022).

In this context, our solution fills the gap by pro-

viding an open-source platform to facilitate the devel-

opment of process-aware information systems based

on code generation techniques. The platform is ca-

pable of generating a functional process-aware web

application from a business process model defined

in BPMN. To the best of our knowledge, there is

no other software tool that generates fully functional

Group

that focuses on Knowledge Intensive Pro-

3

2 BACKGROUND

their tasks and interact with the business processes

seamlessly. It is almost imperative that these appli-

cations provide rich user interfaces (light, fast, and

user-friendly) on top of a reliable and scalable soft-

ware architecture based on cutting-edge technologies,

Considerable research has been conducted in the do-

main of Business Process Management (BPM) and

many tools have been proposed for different aspects

related to Business Process Automation (BPA). Be-

cause of the wide range of solutions, it is a challenge

ever, we briefly describe a set of platforms for BPA

that can be either a source of evaluation and/or in-

spiration for our framework. We divided those solu-

tions into two groups: proprietary and open-source

Heflo

, Nintex

,

15

ness process engine written in Java. The platform sup-

ports the deployment of BPMN 2.0 and can be used

for creating process instances of those process defi-

nitions, running queries, accessing active or histori-

cal process instances and related data. jBPM (Java

Business Process Model) is an open-source work-

flow engine written in Java that can execute business

processes described in BPMN 2.0 (or in jPDL, its

own process definition language, in earlier versions).

jBPM is a toolkit for building business applications to

The limitations of these existing solutions were

described in Section 1, and, as a reminder, are

listed here as well: (1) Vendor Lock-in; (2) Limited

UI/UX; (3) Limited integration; (4) Outdated technol-

ogy stack; and (5) Lack of support for non-process

features.

4 PLATFORM OVERVIEW

AKIP Process Automation Platform is an open-source

project devoted to facilitate process automation initia-

tives based on code generation techniques. The plat-

Application Generator and a Reference Architecture.

In our solution, we call KIPApp (which stands for

Knowledge Intensive Process Applications) a mod-

ern process-aware web application (such as described

in Section 2.4) that executes on the top of an open-

source process engine. In short, a KIPApp provides

the following main features:

the management of users, configuration proper-

ties, health checks, logs, and application metrics.

The application generator is a tool to generate, de-

velop, and deploy KIPApps quickly. It generates code

for the base reference architecture of the AKIP plat-

form.

The generator is a key tool in our solution because

it accelerates the development process by scaffolding

a huge amount of code that, without the generator,

would have to be coded manually.

The reference architecture represents the backbone

process workflow from an executable BPMN model.

Next, we depict the remaining three elements of the

reference architecture:

provided by the reference architecture, meaning

there is no need to repeat the code of these fea-

tures in each KIPApp. Examples of native fea-

tures include Advanced Tasks List, Start-Process,

Process-Instances Dashboard, Management of

Deployed Processes, and User Management.

cation to integrate quickly with the external world.

Examples of connectors include an Email Con-

nector used to send email automatically through-

out the process execution, RestAPI Connector

to integrate with other systems through Rest

APIs, JMS Connector to carry out communica-

tion through messaging, and AWS Connectors that

allow integration with main AWS services. The

main idea behind these elements is to reuse the

most common integration components through a

Architecture.

2. Technical implementation of one or more business

processes.

3. Deployment of the business process(es) into the

KIPApp.

We briefly explain below how these general steps

can be performed. Details on how to install and use

the platform can be found in the Github project public

repository.

more details, check out the platform’s Github public

documentation.

In this section, we will focus on the development of

an illustrative process named Travel Plan Process. In

https://agilekip.github.io/pap-documentation

Figure 3: Travel Plan Process - a running example.

a nutshell, this process has steps that users execute

when planning a trip. Therefore, our goal is to de-

velop a process-aware web application that aids a user

planning a trip. For illustrative purposes, we will use

5.2.1 Defining the Business Process Model

The business process model should be specified in

BPMN

and contain only typical tasks (usually User,

Service, or Message Tasks) as illustrated by the pro-

cess model in Figure 3. Moreover, the process should

have an associated identifier (id) and be defined as ex-

created in order to help identify domain entities that

the business process (supported by the KIPApp) needs

to handle. To keep our running example simple, the

domain model is represented by a single entity named

TravelPlan that has a few properties as shown in Fig-

ure 4. This entity represents the data that are handled

by the process.

It will serve as a guide artifact for the next steps

(related to entity generation). However, the domain

model itself is not an input artifact for the AKIP plat-

17

tions, and services) and provide a CRUD front-end

for each generated entity. The CRUD support, how-

ever, will only be provided if the readOnly property

of the JSON entity specification is set to false. In the

TravelPlanProcess differs from the TravelPlan entity

only in relation to the properties presented in Figure

6. Specifically, we highlight the processBpmnId and

domainEntityName properties. The first one should

match the process Id defined in the BPMN process

model (as mentioned in Section 5.2.1). The second

one (domainEntityName) should match the domain

entity previously created (i.e., TravelPlan).

Concerning the start-form entity, Figure 7

presents its JSON specification for our running exam-

matches the process id defined in the BPMN model;

processEntityName matches the process-binding

entity previously created; and domainEntityName

matches the domain entity previously created. Fig-

ure 8 shows the KIPApp’s UI form generated from

the TravelPlanStartForm entity (Figure 7) by using

the “entity” sub-generator of the AKIP platform. This

UI form will be used to start a Travel Plan process in-

stance in the Web application.

not present here the JSON specifications for these en-

tities, but they can be found in the platform’s online

tutorial. However, they are very similar to the start-

form entity specification previously created (Figure

7), as both entity types (user-task and start-form) are

used to generate UI forms of the resulting KIPApp.

In a user-task entity, the entityType property should

be user-task-form and the fields element should

contain the fields from the domain entity that should

appear in the KIPApp’s UI form used to execute the

process’s user task. Additionally, it should contain

the taskBpmnId property matching the correspond-

ing task id defined in the BPMN model file.

All entities mentioned above (i.e., the domain and

generated, it usually still needs some customizations

performed by developers. The most common cus-

tomizations we have identified in practice are the ad-

dition of support for business rules and adjustments in

UI form fields.

Finally, the KIPApp is ready and all entities support-

ing the execution of the Travel Plan business process

were generated and customized. Next, we need to ex-

ing to the Travel Plan Process (detailed in Section

5.2.1). The bottom of Figure 9 shows the Travel Plan

process already deployed.

Figure 9: KIPApp screen showing a deployed business pro-

cess.

6 USING A KIPApp

This section briefly presents how to use a KIPApp to

execute a business process. Owing to space limita-

tions, we will not present other functions provided by

the application.

Once the Travel Plan process has been deployed, we

can start the process by clicking on the Init button

from the app screen shown in Figure 9. The start form

of this process (shown in Figure 8) contains the fields

we defined previously in the TravelPlanStartForm en-

tity metadata (Figure 7). The process description (in

this case, three enumerated steps) came from the doc-

umentation element of the BPMN process model. The

process instance will actually start when we click on

the Start button at the bottom of the form (Figure 8).

from the My Tasks app menu. In the case of the Travel

Plan process, its tasks are available for any authen-

ticated user. Figure 10 shows the user tasks screen

where one can note the Choose flight task has already

Figure 10: User tasks from a process instance.

been completed (owing to its status) and the Book a

hotel task is enabled for execution (the BPMN pro-

cess model in this screen shows in green the current

task waiting to be executed). To execute it, we only

need to click on the Play button on the right side of

cation generated by the AKIP platform, running on

top of a process engine. Our Application Generator is

an extension of the JHipster

generator (technically

it is a JHipster blueprint) that overrides many sub-

generators and provides its own templates and func-

tions. Our Reference Architecture is based on one of

the most modern tool stacks in the software indus-

try. Currently, we use VueJS

as a front-end frame-

process-aware web applications (KIPApps). This sec-

tion presents data on a case study conducted in the

context of this enterprise. The following subsections

present the goal of our study (8.1), data about the

company and the automated business processes (8.2),

20

the procedure that was followed (8.3), the results of

the case study (8.4) and, finally, some considerations

about the case study (8.5).

Our goal with this study was to assess the feasibility

and usability of the AKIP platform. In other words,

we intended to verify its effectiveness to generate

world business process models?

This case study was conducted in the context of a

lutions for the logistics and port sectors.

ing any details of the process model itself.

Table 1 shows the size of the BPMN process mod-

els automatically generated with the AKIP platform

First of all, the software architect generated the

KIPApp for the client company using the AKIP plat-

form. Afterwards, at each project’s development pro-

cess iteration (sprint), the team followed the sequence

analyst with the participation of the process ana-

lyst.

specified by the developers in JSON and used by

the AKIP platform that generated the code base

for the given process.

velopers (including support for business rules and

integrations) and UI forms (screens) were cus-