Develop A First Process Application 251013 - V1

DEVELOP A FIRST BUSINESS PROCESS APPLICATION
by Raphal Allgre, Product Manager, Bonitasoft

TABLE OF CONTENTS
1.
2.
Introduction .............................................................................................................................................. 3
The BPM Suite ......................................................................................................................................... 3
2.1.
Bonita BPM Studio: the development environment ......................................................................... 3
2.2.
Bonita BPM Engine and Bonita BPM Portal: the production environment....................................... 4
2.3.
Application development cycle ........................................................................................................ 6
3. Phase I: Application Scope Definition (requirements analysis) ............................................................... 7
3.1.
Business requirements .................................................................................................................... 8
3.2.
Application scope ............................................................................................................................ 8
4. Phase II: Process model design............................................................................................................... 9
4.1.
Happy path ...................................................................................................................................... 9
4.2.
Human vs Service task.................................................................................................................... 9
4.3.
Pool, lanes & actors ...................................................................................................................... 10
4.4.
Alternative endings ........................................................................................................................ 12
4.4.1.
If the request is refused by the manager .............................................................................. 12
4.4.2.
If the request is refused by the HR officer ............................................................................ 12
4.5.
Extended process model ............................................................................................................... 13
4.5.1.
Request approved by the manager & the HR officer ............................................................ 14
4.6.
User management & task assignation ........................................................................................... 14
5. Phase III: Data Management ................................................................................................................. 17
5.1.
Business data ................................................................................................................................ 17
5.1.1.
Employee object ................................................................................................................... 18
5.1.2.
Leave request object ............................................................................................................ 18
5.2.
Process data ................................................................................................................................. 19
5.3.
Connection to other Information Systems ..................................................................................... 20
5.3.1.
Concept of connectors in Bonita BPM 6.0 ............................................................................ 20
5.3.2.
Configuring the Bonita email connector to send notifications ............................................... 21
5.3.3.
Configuring the database connector to store the submitted leave request ........................... 27
5.3.4.
Configuring the database connector to get the leave request information............................ 31
5.3.5.
Configuring the database connector to update the employees remaining leave days ......... 33
5.3.6.
Configuring the Bonita connector to publish events on a Google calendar .......................... 34
1 | www.bonitasoft.com
2013 Bonitasoft
6.
Phase IV: Web user interface design ..................................................................................................... 36

6.1.
Leave request submission form .................................................................................................... 36
6.1.1.
Employee information section............................................................................................... 37
6.1.2.
Leave request submission section........................................................................................ 39
6.1.3.
Data initialization and consistency ........................................................................................ 39
6.1.4.
Data insertion into the external database ............................................................................. 41
6.1.5.
Leave request unicity constraint ........................................................................................... 42
6.1.6.
Manager validation form ....................................................................................................... 42
6.1.7.
HR validation form ................................................................................................................ 42
7. Phase V: application testing ................................................................................................................... 43
7.1.
Happy path testing: the leave request is approved ....................................................................... 43
7.1.1.
The employee requests a leave............................................................................................ 43
7.1.2.
The manager reviews leave requests ................................................................................... 44
7.1.3.
HR officer reviews approved requests .................................................................................. 45
7.1.4.
The employee is notified....................................................................................................... 46
7.1.5.
Google Calendar event publication....................................................................................... 47
7.1.6.
Update of the remaining leave days ..................................................................................... 47
7.2.
Alternative path testing: the leave request is refused by the manager .......................................... 48
8. Next steps .............................................................................................................................................. 49
9. Further reading ...................................................................................................................................... 50
2013 Bonitasoft
www.bonitasoft.com | 2
1. Introduction
Whether you are wondering how BPMN can significantly improve the efficiency of your daily
operations or whether you are wondering how to turn an existing process into an optimized
dynamic application, this paper addresses these challenges through a concrete business example:
the modeling and the automation of an employee leave management procedure. We have put
ourselves in the shoes of a project team engaged in the development of its first BPMN
implementation.
The example application is developed with Bonita BPM 6 Teamwork Subscription Edition. This
paper also gives some pointers to develop it with Bonita BPM 6 Community Edition.
Through the use of BPMN 2.0 graphical elements, we will explain how to design an executable
business process model readily understandable by all business stakeholders.
The paper covers the entire application life cycle such as the requirements analysis, the process
modeling, the design of the web user interfaces and finally the acceptance testing and deployment.
For each phase, the reader is guided with illustrations or scripts extracted from the solution. The
main development choices are explained and best practices in terms of design or performance
optimization are suggested.
The resulting application is a live prototype that can be tested by all the stakeholders. You can
install Bonita BPM and follow the example given, making modifications and customizations as
noted, to create your own first business process application with Bonita BPM. Suggestions for
further action (next steps) are given at the end of the paper.
2. The BPM Suite

2.1.
Bonita BPM Studio: the development environment
Bonita BPM Studio is a graphical environment for creating a business process application. It
contains two principle design tools: the whiteboard, for drawing the process flow diagram and
defining the detail of steps, transitions, decision points and other process elements; and the form
builder, which is used to create forms used in process web applications. Bonita BPM Studio is the
process development environment for both the business analyst and the application developer.
You can install Bonita BPM Studio on a development system, then create and test processes
without needing to deploy a production environment. Bonita BPM Studio contains an embedded,
locally deployed version of the Bonita BPM Engine, suitable for testing a process that is in
development.
2013 Bonitasoft
Figure 1.
Bonita BPM Studio
Bonita BPM Studio is also the tool for preparing a completed process for deployment, and for
configuring the organization information required for a process.
2.2.
Bonita BPM Engine and Bonita BPM Portal: the production

environment
The Bonita BPM Engine is the process execution engine of Bonita BPM. It is invisible to process
users.
The Bonita BPM Portal is the part of Bonita BPM that is visible to process users, who use it to view
tasks and take actions. The Portal is also the tool used by the process administrator to deploy and
manage a process.
When a process is ready for production, prepare the production environment by installing the
Bonita BPM software, pre-requisites and dependencies, and configuring the system. Then you can
deploy a process that has been exported from Bonita BPM Studio.
2013 Bonitasoft
Figure 2.
Bonita BPM Portal, displayed on a web browser and on a mobile device
Figure 3.
Schematic of service-based, extensible Bonita BPM Engine
2013 Bonitasoft
2.3.
Application development cycle
Application development is based on an iterative and collaborative approach.

We begin by analyzing the business requirements and defining the scope of the application, or
more specifically, the deliverables of the first iteration.
Figure 4.
The 5 phases of application development project life cycle
In each of the 5 phases of the project lifecycle, the business-oriented or end-user oriented people
will collaborate as much as possible with the technical people to optimize the chances of a quick
adoption of the developed application. The typical project stakeholders are the business analyst,
the developer, the end user and the testers. The role of the business analyst can often be played by
the business user (SMEs), the person who drives the needs for the process.
This paper will now follow the phases of the development lifecycle:
Application scope definition (requirements analysis)

Process model design
Data management (and connection to other Information Systems)
Web user interface (UI) design
Testing / Live demo
2013 Bonitasoft
3. Phase I: Application Scope Definition (requirements

analysis)
All organizations have to manage internal administrative tasks, such as the employee leave
procedure, for example. In this paper, we will explain how to build an application with Bonita BPM
to manage such a process.
Lets look at some common problems with this process. If we analyze the details of different
practices, we can see that in many cases the process is not well managed. The two main
consequences of inefficiency or poor management are time wasted on non-strategic activities and
dissatisfaction among the workforce. Here are some examples of common problems that impact
the organization.
Example
The officer has to review paperbased requests and enter the data
manually in the system.
The HR officer is giving incorrect
information because his source is
not up to date.
Consequence
Time consuming
Workforce
dissatisfaction
Error prone
Workforce
dissatisfaction
Error correction
needed
Cause
Multiple recapture of
information
Multiple unsynchronized
systems
Employees dont have access to

their up to date remaining paidvacation days.
Time consuming
Workforce
dissatisfaction
Unavailability of
information
The approval status is waiting since

several weeks because the manager
has still not processed the request.
Time consuming
Employee
dissatisfaction
Approval process not

optimized
Time consuming
Workforce
dissatisfaction
Error prone
Multiple recapture of
information
The officer has to review paperbased requests and enter the data
manually in the system.
Note that depending on the type of organization and what type of laws apply, different types of
leave exist such as sick time, paid and unpaid vacation time, personal time off, etc. The type of
leave is usually linked to the payroll system.
2013 Bonitasoft
3.1.
Business requirements
Keeping in mind the primary business objective of improving process efficiency and increasing
employee satisfaction, here are the requirements that the first iteration of our application should
address:
1. Provide a centralized solution to manage employee leave request
2. Provide a solution appropriate for the 3 distinct user profiles: requestor, manager and HR
officer
3. Eliminate paper timesheets
4. Eliminate error-prone manual processes
5. Automate the existing process from request submission to request information
documentation/archival
6. Share information across the company
7. Notify employees when key decisions are made
3.2.
Application scope
Business Requirements
Solution
Centralized solution to manage

employee leave request
Build an executable model to orchestrate the business

process; build a business process application, with a webbased interface, to interact with end users.
Adapt the solution to the 3 distinct

user profiles: requestor, manager
and HR officer
Include the 3 personas during the design of the process

model and address their requirements at an early stage.
Eliminate paper timesheets and

other error-prone manual processes
Design web forms within the process model in order to

manage data entries. Implement automatic data validation
rules to ensure data integrity. Use connectors to push data
to external IT systems. In our example, the leave request as
well as all the approval steps will be managed through a
web form.
Automate the approval process
Use BPMN 2.0 graphical elements to model the approval

process relevant to your organization. In our example, the
process model will automatically route an employees
leave request to the employees manager first and then to
the HR officer.
Notify employees when decision are

made
Include the appropriate notification scheme in the process

model. In this example, we will use connectors to
automatically generate notifications.
2013 Bonitasoft
4. Phase II: Process model design

The purpose of this phase is to design the business process model. It usually starts by analyzing the
existing process within the organization. The business analyst or the person who drives the needs
for the process is usually the one creating and refining the model. The process needs to address the
specific business case and the previously listed business requirements.
4.1.
Happy path
One of the best practices of process modeling is to start with the design of the happy path1. The
idea is to simplify the model of your process in order to visualize the activities and the flow from its
beginning to its end.
Figure 5.
Happy path modeling
Figure 5 corresponds to the happy path for the leave process. The first graphical element is the
start event Submit request. The process will be actually started at the submission of a leave
request web form. Once the process is started, the flow is then automatically routed to the first
task called Manager checks request. This human task means the employees manager will check
the employees request through a web form and decide whether or not to approve it. If the
employees manager approves the request, the flow is then routed to the second task called HR
checks request. At this second level of approval, the HR officer has to verify whether the request is
legitimate or not. If the HR officer approves the request, it is then routed to a third service task
called Notify of approval. Once the email notification has been automatically sent to the
employee, the flow is automatically routed to last task of the process: Google calendar update.
This service task will publish the approved leave dates to a shared Google calendar. Once the
calendar publication has been completed, the flow is routed to the terminate end event that stops
the entire process.
4.2.
Human vs Service task
A human task is an activity to be performed by a user as opposed to a service task to be executed

by the system. In Bonita BPM, a human task is an activity that is exposed to the end user. The
Best practice #1: start process modeling by representing the happy path in its simplest version. The purpose is to represent the main
activities from the start event to the end event without including the alternative paths.
2013 Bonitasoft

developer can design web forms and manipulate data interactively with the process. Human tasks
and their associated web forms are displayed in the Bonita BPM Portal task list view.
4.3.
Pool, lanes & actors
Once we have designed the happy path, we can now illustrate the 3 different functional
responsibilities we have in our business process. Figure 6 shows the pool, Leave Process, that
represents the process. The pool is sub-divided into 3 lanes, each representing a participant in the
process. The first lane, Employee includes the element (start event) related to the employees
request. The second lane, Employee manager, corresponds to the employees manager role. The
third lane, HR officer, refers to the human resource officer responsibilities. Thus, the lanes
visually represent roles or organizational units that perform activities.
Figure 6.
Leave process with three lanes representing groups with process responsibilities
In Bonita BPM, to assign a human task to a particular group of users means defining an actor for the
task and associating this actor to the desired group of users.
An actor defines the potential pool of performers for an activity. Actors are resolved at runtime to
determine who is eligible to perform a task. In our case, we have created 2 actors, Employee and
HR officer (see Figure 6). The employee actor is set as the initiator of the process. This means that
the leave process can only be started by a user who is mapped to the Employee actor.
2013 Bonitasoft
Figure 7.
Create actors and set process initiator
Note that we havent created an actor with the employees manager responsibility. The end user is
defined from derives from the employee actor through the use of an actor filter called Initiator
manager that returns the manager of the initiator of the process.
Figure 8.
Assign actor actor filter for employees manager
2013 Bonitasoft
4.4.
Alternative endings
Once we have defined the happy path with the appropriate lanes and actors, we can now design
the alternative branches of our process.
4.4.1.
If the request is refused by the manager
The first task intended to the manager is the review of the subordinates leave request. The
manager can either approve or refuse the request. Each of these options represents a different
path on the diagram. The exclusive gateway, Approved by manager?, routes the flow in the only
branch that matches the condition. In case of request refusal, the flow is routed to the service task
Notification of manager refusal, that will handle the email notification. The process ends once the
notification of refusal has been transmitted.
Figure 9.
Alternative path if request is refused by manager
Note that we positioned the service task Notification of manager refusal within the employee
lane because we considered that it was more readable this way since the notification is intended to
the employee. Nevertheless, a service task is not concerned by the actor concept since it is not
performed by a user but by the system, other options are also possible such as put it inside the
manager lane or creating a new system lane for it.
4.4.2.
If the request is refused by the HR officer
When an employees request has been approved by the manager, it is automatically routed to the
HR officer for review. The HR officer can either reject or approve the request. To manage these 2
cases, we added another exclusive gateway: Approved by HR? In case of refusal, the flow is
2013 Bonitasoft

routed to the service task Notification of HR refusal that will automatically handle the email
notification. The process ends when the notification of refusal has been transmitted.
Figure 10.
4.5.
Alternative path if request is refused by HR officer
Extended process model
The figure below now illustrates the comprehensive process model from the leave request
submission (start event) to the 3 potential endings (terminate end event): refused by manager,
refused by HR and request approved.
2013 Bonitasoft
Figure 11.
4.5.1.
Process with 3 possible paths
Request approved by the manager & the HR officer
When the HR officer validates the employees request, the flow is routed to the service task
Google calendar update. This task automatically creates a Google calendar event with all the
employee leave details. This calendar is shared with all the employees within the company. When
this step has been completed, the flow is split into two branches (through a parallel gateway): one
to handle the email notification to the employee and the other to handle the update of the number
of leave days remaining after the approved request. Notice that the parallel gateway receiving the
flows from the two service tasks will merge them again once the two are performed. This behavior
ensures that process cant end without having completed the DB update and the email
notification to the employee.
4.6.
User management & task assignation
The end users of the business process application are managed through an internal directory called
organization. An organization is composed of groups, roles, memberships and users.
The term actor is strictly a name that generally corresponds to functional responsibilities. The
assignment of an actual user to a task can be performed when actors are mapped with the users
from the active organization. Actor mapping is done via the process configuration. The process
configuration can be changed after deployment of the application. This means that it is possible to
dynamically modify the task assignment rules independently from the process design.
In our example, we mapped the actor, Employee, to the role member of the organization. This
means that all users with the role member will be able to start an instance of the application
Leave Process. Since the role member is the default role in our organization, it means each user
2013 Bonitasoft

will be able to submit a leave request. The second actor, HR officer is mapped to the group HR.
All users belonging to the group HR will be eligible to perform the human task called HR officer
checks request.
Figure 12. Actor mapping definition: actor Employee mapped to the role member and
actor HR officer mapped to the group HR
To create users, create an organization via the submenu Manage of the menu Organization. For
this example, we have created an organization called BonitaSoft S.A. This organization is
composed of different groups, roles and users. The membership is the assignation of a group and a
role to a user.
2013 Bonitasoft
Figure 13. Creation of the organization BonitaSoft S.A. from the menu
Organization>Manage
To make your organization active, you need to publish it. Only one organization at a time can be
active during execution.
2013 Bonitasoft
5. Phase III: Data Management

The purpose of this phase is to determine the data needed to build the business process
application. First we need to distinguish business data and process data.
Figure 14.
5.1.
business and process data in Bonita BPM
Business data
Business data represent the information that the process application interacts with (read, write and
update) and which may exist outside of the process. Business data may be shared or used by other
applications within the organization. Business data are also very often useful for reporting
purposes. Best practice is to manage Business data in an external database. In our case, the
business data correspond to the employee information and the leave request.
2013 Bonitasoft
5.1.1.
Employee object
The employee information will be summarized by the following attributes.

Variable
Type
Description
Employee ID*
Integer
Unique employee identifier
First name*
Text
Employees fist name
Last name*
Text
Employees last name
Email*
Text
Employees email
Manager*
Text
Employees manager
Available annual leaves
Numeric
Remaining days for annual

leave types
Available sick leaves
Numeric
Remaining days for sick

leave types
Bonita BPM 6.0 offers a simple directory called organization in order to manage the users. The
organization is composed of groups, roles, memberships and users (see. part User management &
task assignation). All the fields marked with a star already exist in the Bonita organization (Bonita
BPM Engine). We will then only store in the external DB, data not marked with a star plus the
Employee ID.
5.1.2.
Leave request object
The employee leave request gathers the information about the leave. The leave request will then
be stored as a table in an external database. Here is the leave request table definition:
Variable
Type
Description
Employee ID
Integer
Unique employee identifier
Start date
Date
Date of the first day of leave
End date
Date
Date of the last day of leave
Return date
Date
Date of the return day in

the company
Number of days
Numeric
Number of days off
Type of leave
Text
Type of leave available

according to
2013 Bonitasoft

company/country: annual
leave, sick leave, unpaid
leave, other
Status
Text
Status of the leave request:

submitted, approved by
manager, refused by
manager, refused by HR
officer, validated
Manager refusal comment
Text
Manager refusal
explanation
HR officer refusal comment
Text
HR officer refusal
explanation
5.2.
Process data
Process data represent the information that the executable model needs to route the flow to the
right tasks. In this example, it includes the approval or refusal of the employee's request by the
manager and the HR officer.
Variable
Type
Description
Approval
Boolean
Boolean variable that

indicates the approval (true)
or the refusal (false) of the
employee leave request,
either by the manager or
the HR officer.
2013 Bonitasoft
5.3.
Connection to other Information Systems
5.3.1.
Concept of connectors in Bonita BPM 6.0
In Bonita BPM, connectors are used to make your process interact with an external IT system. In
our application example, we have identified the 3 use cases below that require the use of such
connectors:
Retrieving or storing data from an external database (employee information, leave request)
Sending email notifications whenever decisions are made
Creating a Google Calendar event to share information with other employees
Connectors can be triggered at the process level or at the task level. Bonita BPM 6.0 offers a list of
pre-built connectors as illustrated by the figure below.
Figure 15.
Connectors in Bonita BPM
In our example, we will use:
Email connectors to notify the requestor about the status of the leave request
Database connectors to display or update employee information
Database connectors to store or update the leave request details
Google Calendar connector to post an employees leave dates on a shared Google calendar
2013 Bonitasoft

On the process diagram, connectors are identified by a plug icon on the upper right corner of a
task. The example below illustrates the use of the email connectors on the two service tasks
Notification of manager refusal and Notification of HR refusal. Note that we can also use
connectors within forms (eg. to initialize a field, on the submit button, etc.).
In the next sections, well explain how the connectors are configured.
Figure 16.
5.3.2.
Connectors on tasks
Configuring the Bonita email connector to send notifications
Objective
According to the process design, an email notification is sent to an employee when the manager
has refused the request, when the HR officer has refused the request, or when the request has
been approved by both the manager and the HR officer. The email notification will be sent to the
employee who has submitted the request. Its subject and content should include the status of the
request (refused or approved), the comment of the manager, and the details about the leave
request.
Implementation
To add a connector on a task, click on the task and select the Connectors pane of the General tab.
The list of connectors displayed after clicking on Add corresponds to all the pre-built Bonita
connectors plus any user defined connectors you may have added. The SMTP email connector is
under the category Messaging. Like the other connectors, its configuration is facilitated by a stepby-step configuration wizard. Here are the detailed configuration steps.
First step
In the first step, define the name, the description, the triggering event and the error management
option for your connector. For the Select event option, select Finish which means the connector will
be executed at the end of the service task. This gives us the opportunity to execute another
connector at the beginning of the task in order to retrieve the business data (eg. start date, leave
type, etc.) required for the email content definition.
2013 Bonitasoft
Figure 17.
First step to define the email connector
We selected the option, Put in failed state. This offers the Bonita BPM Portal administrator
responsible for the application case management the possibility to detect the error, correct it and
replay the task.
Second step
Define the SMTP server connection information. It is
recommended to use parameters for the technical
settings of the connector configuration2.
In Community Edition,
as parameters are not available, you
can use process data with type
Constant.
2
Best practice #2: use of parameters for technical settings. Indeed, parameters are part of the process configuration and they can be
directly modified in production from Bonita Portal without having to redeploy the application.
2013 Bonitasoft
Figure 18.
Second step to define the email connector
Third step
In this third step, define the sender and recipient email addresses. In this example, we used
a parameter for the sender address (eg. no-reply@system.com). The recipient email
address needs to be dynamically evaluated and should correspond to the employee who
requested the leave. To do this, open the expression editor and select script. Here is the
Groovy script used to return the required email address:
Figure 19.
Third step to define the email connector
2013 Bonitasoft

Return
BonitaUsers.getUserProfessionalContactInfo(apiAccessor,BonitaUsers.getProcessInstanceI
nitiator(apiAccessor,processInstanceId).getId()).getEmail();
Note that this script uses a provided Groovy function from the Bonita category.
Fourth step
Define the object, the content and the attachment(s) if applicable. In our case, both the object and
the content are dynamic.
Figure 20.
Fourth step to define the email connector
Here is the script definition used for the object called Title:
return managerFirstName+" "+managerLastName+"has refused your leave request
submitted on:"+leave_request_creation_date;
Where managerFirstName and managerLastName are two transient variables defined at the
service task level (Notification of manager refusal). Indeed, the rich text editor provided with the
email connector allows inserting process variables but no Groovy script. This is why we used two
transient variables defined at the task level.
2013 Bonitasoft
Figure 21.
Definition of transient variables
Here are the scripts used to initialize these two transient variables:
return
BonitaUsers.getProcessInstanceInitiatorManager(apiAccessor,processInstanceId).getFirstN
ame();
return
BonitaUsers.getProcessInstanceInitiatorManager(apiAccessor,processInstanceId).getLastNa
me();
Here is the email content definition for our email connector:
2013 Bonitasoft
Figure 22.
Definition of email content
The rich text editor offered to define the email content supports the insertion of process variables
(F1 or Ctrl space). In our example, the process variables used (requestorFirstName,
managerRefusalComment, dayOfLeave, etc) are transient variables that have been initialized at the
beginning of the task by a database connector set on Enter. All the business related information is
stored in our external database, so we need to use a database connector to retrieve it.
Here is an example of the generated email:
2013 Bonitasoft
Figure 23.
5.3.3.
Email message with variables
Configuring the database connector to store the submitted leave request
Objective
Although it is not visible in the process design, the employee leave request form will be part of the
start event (See section 36). This means that submitting a leave request will start a process
instance. The objective of the database connector in our case is to store all the information entered
in the form while the leave request submission.
Implementation
To add a connector on the form displayed at the start of the process, open the form by clicking on
the pool and selecting the Application tab.
Figure 24.
Add a form to start the process
You can then open the form (Leave_request). When the form is opened, click on the Submit button
or the form itself and select the Connectors tab in order to add the connector.
2013 Bonitasoft
Figure 25.
Add a connector to the form
Here are the detailed configuration steps.
First step
Set the name and the description of the
connector.
Figure 26.
as form connectors are not available,
the connector at the pool level can be
used.
Create a database connector
Second step
Choose between 2 options to define the SQL query. The graphical builder offers a graphical mode
to build the query. It requires you to first configure the access to your database. The other option is
to use the text editor to write the query. The Groovy script editor is also part of this second option.
In this case, we use the text editor in order to have access to the Groovy editor.
2013 Bonitasoft
Figure 27.
Choose connector editor
Third step
Define the settings to access the external database. As a good practice, we use parameters so that
it can be changed later without having to redeploy the application if its configuration changes.
as parameters are not available, you can use process data
with type Constant.
2013 Bonitasoft
Figure 28.
Configure database access
Fourth step
Define the SQL query either with a basic text editor or with the Groovy script editor. In this case we
have defined a Groovy script named insert leave. Here is an example of script we use to store the
leave request in the database.
Figure 29.
Configure database query
2013 Bonitasoft
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.logging.Logger;
Date request_date = new Date();
String status = "submitted";
DateFormat mySimpleDateFormat = new SimpleDateFormat("YYYY-MM-dd HH:mm:ss");
Logger logger=Logger.getLogger("org.bonitasoft");
String mySQL="INSERT INTO leave_request (start_date, end_date, return_date,
number_days, type_of_leave, bonita_id, submission_date, status) VALUES
('"+mySimpleDateFormat.format(field_dayOfLeave)+"',
'"+mySimpleDateFormat.format(field_Date1)+"',
'"+mySimpleDateFormat.format(field_dayOfReturn)+"', "+field_numberOfDays+",
'"+field_leave_Type+"',"+loggedUserId+",
'"+mySimpleDateFormat.format(request_date)+"', '"+status+"')";
logger.severe(mySQL);
return mySQL;
Note that we added some entries in the Bonita BPM Studio logs to display the SQL query.
5.3.4.
Configuring the database connector to get the leave request information
Objective
The objective here is to use a database connector to retrieve the employee leave request
information required to for the human task Manager checks request. The best practice to manage
business data required for a form is to create a custom transient data type (Java object) and
initialize it with a single database connector. This way, you will avoid impacting the form
performance with too many connectors in the forms. Also, using a transient data at the form level
will avoid storing business data in the Bonita BPM Engine database.
Figure 30.
Manager checks request task
To create a new data type, go to Development>Data types>New data type When your custom
data type is defined, you can create it as a JAR. To create the transient data derived from the
custom Java object, click on the human task and select Application>Pageflow>Transient Data.
2013 Bonitasoft
Figure 31.
Add new data type as transient data
In this example, we have created the

transient
java
object
named
employeeRequest and it is initialized by
the database connector named get leave
request data. Since most of the
configuration steps are similar to the
previously presented database connector,
we are only presenting here the steps that
are different.
as Java Data Type creation is not available, you
can create the Java objects externally and import
the jar file into Bonita BPM Studio. Also, as
connectors to initialize form transient data are
not available, define a task transient data
instead and a task connector to initialize.
SQL query definition

Here is the script we defined to select the submitted leave request information:
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.logging.Logger;
Logger logger=Logger.getLogger("org.bonitasoft");
DateFormat mySimpleDateFormat = new SimpleDateFormat("YYYY-MM-dd HH:mm:ss");
String mySQL="SELECT end_date, return_date, number_days, type_of_leave FROM leave_request
WHERE bonita_id =
"+BonitaUsers.getProcessInstanceInitiator(apiAccessor,processInstanceId).getId()+ " AND
start_date= '"+mySimpleDateFormat.format(leave_request_start_date)+"'";
logger.severe(mySQL);
return mySQL;
Note that the primary key (unicity constraint) is defined by the two columns bonita_id and
start_date. Our assumption is that the same employee cannot submit more than one leave
request with the same start date.
Connector output operations

In this last step, we need to use the connector output (resultset) and map it to the transient
variable employeeRequest
2013 Bonitasoft
Figure 32.
Connector output configuration
Here is the script we used to define the mapping.

import org.bonitasoft.employeeleaverequest.LeaveRequest;
import java.util.Date;
resultset.next();
LeaveRequest employeeRequest = new LeaveRequest();
Date endDate = new Date(resultset.getDate("end_date").getTime());
Date returnEnd = new Date(resultset.getDate("return_date").getTime());
employeeRequest.setEndDate(endDate);
employeeRequest.setReturnDate(returnEnd);
employeeRequest.setLeaveType(resultset.getString("type_of_leave"));
employeeRequest.setNumberDays(resultset.getInt("number_days"));
return employeeRequest;
5.3.5.
Configuring the database connector to update the employees remaining leave

days
Objective
The objective is to use a connector to update the employees remaining leave days right after the
approval of the HR officer. As shown on the process diagram, this operation is managed by the
service task database update.
Figure 33.
Leave request database update task
2013 Bonitasoft

SQL query definition
Here is the script used to update the employees remaining leave days:
if(typeLeave == "Annual leave"){
return "UPDATE public.employee SET available_paid_leave = available_paid_leave "+numberDays+" WHERE bonita_id =
"+BonitaUsers.getProcessInstanceInitiator(apiAccessor,processInstanceId).getId();
}
else if(typeLeave == "Sick leave"){
return "UPDATE public.employee SET available_sick_leave = available_sick_leave "+numberDays+" WHERE bonita_id
="+BonitaUsers.getProcessInstanceInitiator(apiAccessor,processInstanceId).getId();
}
Note that in this example, each employee has fixed number of annual leave and sick leave each
year. Each approved annual leave or sick request is then subtracted from the number of leave days
available.
5.3.6.
Configuring the Bonita connector to publish events on a Google calendar
Objective
The purpose of this connector is to publish the leave request dates (start & end) on a shared Google
calendar.
Google calendar connector configuration

Set the email account, the password, and the URL to the target calendar.
Figure 34.
Google calendar connector configuration wizard: step I
Then define the event: title, content, start time and end time.
2013 Bonitasoft
Figure 35.
Google calendar connector configuration wizard: step II
Here are the scripts used for the event start and end:
leave_request_start_date.format("yyyy-MM-dd'T'HH:mm:ss'+02:00'");
endDate.format("yyyy-MM-dd'T'HH:mm:ss'+02:00'");
2013 Bonitasoft
6. Phase IV: Web user interface design

With Bonita BPM Studio, you can create web forms which are displayed to the end users when they
perform their assigned tasks. These web forms can be created on human tasks. A form can also be
added at the pool level. The submission of a pool-level form triggers the creation of the process
instance. In our process model, we have designed 3 web forms:
6.1.
The leave_request form to be used by all employees, and which gathers all the required
information to submit a leave request.
The manager_validation form to be used by the managers to view the leave requests
submitted by their subordinates, and to approve or refuse them.
The hr_validation form to be used by the HR officers to review the leave requests
submitted by the employees and approved by their managers.
Leave request submission form
This form is created at the pool level. As you can see on the image below, the form leave_request
has been added to the pool by selecting it and clicking on Application tab and then Pageflow.
Figure 36.
Add an instantiation form to the process pool
The design of the form is done using the form builder. The form area is structured with a grid
system composed of rows and columns. A palette of drag-and-drop widgets is available for the
design of the form fields. In this case, the form should include a section with the employee
information and another section related to the leave request submission.
2013 Bonitasoft
6.1.1.
Employee information section
For this section the purpose is to display the employees

first name, last name, email and manager. Since this
as group widgets are not
section will also be displayed in the manager validation
available, the forms can be
form and the HR officer validation form, it is
designed without them.
recommended to use a group widget in order to be able
to reuse it. A group widget and its content can be saved
as a template (Forms>Save Widget as a template). It is also good practice3 to use a group widget,
because the data initialization can be done with only one Groovy script. This improves form
performance.
Figure 37.
Using the form builder to create a form
As you can see in the figure above, we positioned the four required widgets (first name, last name,
email and manager) in a group widget. The initialization of these 4 widgets is done at the group
widget level by clicking on it and going to the Data pane of the General tab. Here is the script we
used for the initialization:
3
Best practice #3: it is recommended to use the Group widget to group several widgets that share the same theme. The feature save
widget as a template offers the capability of reusing the widget template in other forms. Using a group widget also allows global data
initialization at the group level using a java Map object.
2013 Bonitasoft
import org.bonitasoft.engine.identity.User;
import org.bonitasoft.engine.identity.ContactData;
Map<String, Object> result = new HashMap<String, Object>();
User user = BonitaUsers.getUser(apiAccessor, loggedUserId);
ContactData UserContact =
BonitaUsers.getUserProfessionalContactInfo(apiAccessor,loggedUserId);
long managerId = user.getManagerUserId();
User manager = BonitaUsers.getUser(apiAccessor, managerId);
result.put("firstname", user.getFirstName());
result.put("lastname", user.getLastName());
result.put("manager", manager.getUserName());
result.put("email", UserContact.getEmail());
return result;
We also added a message type widget above the group widget to display the employee
information section. We tuned the appearance of the widgets using the Appearance tab
and then Field. Here is an example of customization (text size, color and position) we have
applied for the message widget.
Figure 38.
Define the appearance of a field
For each widget, configure how its data is handled by clicking on the widget and going to the Data
pane of the General tab.
2013 Bonitasoft
6.1.2.
Leave request submission section
In this section of the form, we want to display the fields required to submit a leave request. In our
example, we used:
a dropdown list widget for Type of leave

a text field widget to display Available days
three date widgets for Start date, End date and Return date
a text field widget to enter Number of days
a text area widget to enter a Comment
a Submit button to submit the request
Figure 39.
6.1.3.
Design request form
Data initialization and consistency
We initialized the Type of leave list with a Java

list variable defined with 4 values: annual leave,
sick leave, non-paid leave and other. By default,
as contingency is not available, you
the selected value is set to annual leave. The text
can implement it with JavaScript and
field Available days informs the employee about
external APIs.
his remaining paid leaves so that he can take it into
account as he is creating a new leave request. The information is pulled out from the business
database using a connector4. Since the remaining leaves value to be displayed depends on the type
of leave selected by the employee (annual or sick leave) we used the Contingency feature. As
shown on the image here, the text field Available days is contingent on the field Type of leave.
The Groovy script expression not display hides the widget when the type of leave selected is
either Unpaid leave or Other.
4
Best practice #4: use of transient form data initialized by connectors to manage data required in a form.
2013 Bonitasoft
Figure 40.
Example of a hidden contingent widget
Here is the condition we used:

return ("Annual leave".equals(field_leave_Type) || "Sick
leave".equals(field_leave_Type));
When the type of leave is changed to sick leave for example, the update value expression returns
the appropriate remaining leave days for the concerned employee. Here is the SQL query we used
for the connector getting the remaining leave days:
if (field_leave_Type.equalsIgnoreCase("annual leave")) {
return "SELECT available_paid_leave FROM employee WHERE bonita_id
="+loggedUserId;
}
else {
return "SELECT available_sick_leave FROM employee WHERE bonita_id
="+loggedUserId;
}
To ensure data consistency regarding the date widgets, we used the Validators feature at the form
level. For example, to ensure that the start date is prior to the end date and to the return date:
2013 Bonitasoft
Figure 41.
Add a validator to the field
Here is the Groovy expression (date validation) used for the field Parameter.
return field_dayOfLeave.before(field_Date1)&&field_Date1.before(field_dayOfReturn);
6.1.4.
Data insertion into the external database
The data related to the leave request section of the form are inserted in our external business
database at the submission of the form. We added a connector positioned on the Submit button.
Figure 42. Add a connector to

execute on the submit button
Please refer to the section (27
Fourth step) for the leave request
data insertion explanations.
as form connectors are not available, you can
implement this with either task or pool connector.
2013 Bonitasoft
6.1.5.
Leave request unicity constraint
For the leave request table, we defined a primary key based on the start date and employee ID. In
order to ensure that this constraint is not violated, we can use a form validator that will prevent an
employee from submitting an invalid leave request. Another possible option would have been to
throw an error when the database connector fails, and catch the error with a Catch Error boundary
event in order to route the flow another task.
6.1.6.
Manager validation form
In addition to the fields already used for the leave request submission form, the form displayed to
the managers includes an additional section called manager validation, composed of:
a radio button to set the Status of the employees request

a text area field to set the Refusal comment in case of refusal
Figure 43.
Text area widget refusal comment configuration
The text area widget Refusal comment is displayed only when the manager decide to refuse the
request. To implement this, we used the Contingency feature with the following condition:
return field_Radio_buttons1.equalsIgnoreCase("refuse");
6.1.7.
HR validation form
The form designed for the HR officers is almost identical to the one for the managers. When we
added this form, we used the option Duplicate a form from the list below in order to reuse the
existing manager validation form.
2013 Bonitasoft
7. Phase V: application testing

In this chapter we present the final application to the end users, specifically these three identified
personas:
the employee requesting a leave (Raphael)
the manager reviewing the request (Charles)
the HR officer reviewing approved requests (Stephanie)
7.1.
Happy path testing: the leave request is approved
7.1.1.
The employee requests a leave
After logging into the Bonita BPM Portal, the employee can submit a leave request by starting the
leave management application from the Apps menu. This will open the leave request submission
form as presented in the previous chapter. The field Available days informs the employee
Raphael that he has 25 annual leave days remaining. The submission of this form will then
automatically create a new task for the employees manager, Charles. In our example, Charles will
get a new task in his inbox.
Figure 44.
Leave request form
If the employee selects incorrect dates for leave, the designed form validator (see Data
initialization and consistency) warns him and blocks the data submission. Here is the result of the
validation.
2013 Bonitasoft
Figure 45.
7.1.2.
Warning appears if leave dates are incorrectly entered
The manager reviews leave requests
After logging into the Bonita BPM Portal, the manager can check the task list and sees all leave
requests waiting for approval. In our example, Charles has a new item in his task list named Leave
request from Raphael.
Figure 46.
Managers task list
When the manager opens the task, the leave request submitted by a team member appears. In our
example, Charles gets the leave request submitted by Raphael at the previous stage (start date:
09/26/2013).
2013 Bonitasoft
Figure 47.
7.1.3.
Manager approval form
HR officer reviews approved requests
After logging into the Bonita BPM Portal, the HR officer can check the task list and views all the
leave requests that have been approved by managers and waiting for HR approval. In our example,
Stephanie, the HR officer, has a new item in her task list named Leave request from Raphael
which has been approved by his manager. The HR officer can open the task, review the request and
approve or refuse it.
2013 Bonitasoft
Figure 48.
HR Review Form
When a leave request has been approved, the process flow adds 2 additional service tasks. One
handles the email notification of approval, and the other manages the Google calendar event
publication.
7.1.4.
The employee is notified
Since the HR officer approved the request, the process application then gets all the required
information from the business database and uses it to automatically send an email notification to
the employee who has requested the leave. Here is the email notification received by Raphael.
Figure 49.
Email notification send to employee
2013 Bonitasoft
7.1.5.
Google Calendar event publication
Based on the approved leave request information, the process automatically publishes the
corresponding Google agenda event to share the leave information with the rest of the team.
Figure 50.
7.1.6.
Update to Google calendar
Update of the remaining leave days
If the employee tries to request a second leave right after the approval of the one previously
approved, he will then see that his number of available days has been updated. In the screenshot
below, the employee Raphael has now 23 available annual leave days compared to 25 when he
submitted his first request.
Figure 51.
Number of available leave days has been updated
2013 Bonitasoft
7.2.
Alternative path testing: the leave request is refused by the

manager
The manager reviewing a leave request from his subordinate can decide to refuse it. If the manager
selects refuse, the text box Refusal comment is automatically added and an explanation is
requested.
Figure 52.
Manager refuses leave request
The refusal of the leave request automatically routes the flow to the service task in charge of the
email notification. The employee, Raphael, receives the email notification bellow including the
explanation of his manager Charles.
2013 Bonitasoft
Figure 53.
Employee notification in case of refusal
8. Next steps
For the next project iteration, we can envisage the following extension points:
When the employee applies for a leave, show the details of all upcoming leaves so that
he/she is better informed on how many leaves he has already requested.
When the manager approves leave, show him/her details of who else on the team is on
leave during the same period, to avoid having everyone on the team on leave at the same
time.
Show employee leave reporting at a team/function/business unit level for capacity and
project planning.
Add the ability to export and import leave request information through connection to a
payroll system.
Support cancellation of leaves by employees.
For more information about leave management process applications, see the Process Library on
www.bonitasoft.com.
2013 Bonitasoft
9. Further reading
Best Practices
for Getting Started with BPM
Speaking to the C-Suite

about BPM
Understanding
Business Process Automation
More information available at www.bonitasoft.com.
2013 Bonitasoft
HEADQUARTERS
GRENOBLE, FRANCE
32, rue Gustave Eiffel
38000 Grenoble
EMEA, ASIA & LATIN AMERICA

PARIS, FRANCE
73-77, rue de Svres
92100 Boulogne-Billancourt
NORTH AMERICA
SAN FRANCISCO, USA
51 Federal St. Suite 305
San Francisco, CA94107
2013 Bonitasoft

Develop A First Process Application 251013 - V1

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Develop A First Process Application 251013 - V1

Загружено:

Авторское право:

Доступные форматы

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

by Raphal Allgre, Product Manager, Bonitasoft

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

Phase IV: Web user interface design ..................................................................................................... 36

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

2. The BPM Suite

Bonita BPM Studio: the development environment

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

Bonita BPM Studio

Bonita BPM Engine and Bonita BPM Portal: the production

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

Bonita BPM Portal, displayed on a web browser and on a mobile device

Schematic of service-based, extensible Bonita BPM Engine

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

Application development cycle

Application development is based on an iterative and collaborative approach.

The 5 phases of application development project life cycle

Application scope definition (requirements analysis)

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

3. Phase I: Application Scope Definition (requirements

Employees dont have access to

The approval status is waiting since

Approval process not

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

Centralized solution to manage

Build an executable model to orchestrate the business

Adapt the solution to the 3 distinct

Include the 3 personas during the design of the process

Eliminate paper timesheets and

Design web forms within the process model in order to

Automate the approval process

Use BPMN 2.0 graphical elements to model the approval

Notify employees when decision are

Include the appropriate notification scheme in the process

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

4. Phase II: Process model design

Happy path modeling

Human vs Service task

A human task is an activity to be performed by a user as opposed to a service task to be executed

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

Pool, lanes & actors

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

Create actors and set process initiator

Assign actor actor filter for employees manager

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

If the request is refused by the manager

Alternative path if request is refused by manager

If the request is refused by the HR officer

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

Alternative path if request is refused by HR officer

Extended process model

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

Process with 3 possible paths

Request approved by the manager & the HR officer

User management & task assignation

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

5. Phase III: Data Management

business and process data in Bonita BPM

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

The employee information will be summarized by the following attributes.

Unique employee identifier