Develop a First Process Application 251013 -V1

8/9/2019 Develop a First Process Application 251013 -V1

http://slidepdf.com/reader/full/develop-a-first-process-application-251013-v1 1/52



1 | www.bonitasoft.com © 2013 Bonitasoft

DEVELOP A FIRST BUSINESS PROCESS APPLICATION

by Raphaël Allègre, Product Manager, Bonitasoft

TABLE OF CONTENTS

1. Introduction .............................................................................................................................................. 3 2. 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 employee’s remaining leave days ......... 33 5.3.6. Configuring the Bonita connector to publish events on a Google calendar .......................... 34



© 2013 Bonitasoft www.bonitasoft.com | 2


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





1. IntroductionWhether you are wondering how BPMN can significantly improve the efficiency of your dailyoperations or whether you are wondering how to turn an existing process into an optimizeddynamic application, this paper addresses these challenges through a concrete business example:the modeling and the automation of an employee leave management procedure. We have putourselves in the shoes of a project team engaged in the development of its first BPMNimplementation.

The example application is developed with Bonita BPM 6 Teamwork Subscription Edition . Thispaper 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 executablebusiness process model readily understandable by all business stakeholders.

The paper covers the entire application life cycle such as the requirements analysis, the processmodeling, 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. Themain development choices are explained and best practices in terms of design or performanceoptimization are suggested.

The resulting application is a live prototype that can be tested by all the stakeholders. You caninstall Bonita BPM and follow the example given, making modifications and customizations asnoted, to create your own first business process application with Bonita BPM. Suggestions forfurther action (next steps) are given at the end of the paper.

2. The BPM Suite

2.1. Bonita BPM Studio: the development environmentBonita BPM Studio is a graphical environment for creating a business process application. Itcontains two principle design tools: the whiteboard , for drawing the process flow diagram anddefining the detail of steps, transitions, decision points and other process elements; and the formbuilder , 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 processeswithout 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 indevelopment.





Figure 1. Bonita BPM Studio

Bonita BPM Studio is also the tool for preparing a completed process for deployment, and forconfiguring the organization information required for a process.

2.2. Bonita BPM Engine and Bonita BPM Portal: the production

environmentThe Bonita BPM Engine is the process execution engine of Bonita BPM. It is invisible to processusers.

The Bonita BPM Portal is the part of Bonita BPM that is visible to process users, who use it to viewtasks and take actions. The Portal is also the tool used by the process administrator to deploy andmanage a process.

When a process is ready for production, prepare the production environment by installing theBonita BPM software, pre-requisites and dependencies, and configuring the system. Then you candeploy a process that has been exported from Bonita BPM Studio.





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





2.3. Application development cycleApplication development is based on an iterative and collaborative approach.

We begin by analyzing the business requirements and defining the scope of the application, ormore 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 peoplewill collaborate as much as possible with the technical people to optimize the chances of a quickadoption of the developed application. The typical project stakeholders are the business analyst ,the developer , the end user and the teste rs. The role of the business analyst can often be played bythe 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





3. Phase I: Application Scope Definition (requirementsanalysis)

All organizations have to manage internal administrative tasks, such as the employee leaveprocedure, for example. In this paper, we will explain how to build an application with Bonita BPMto manage such a process.

Let’s look at some common problems with this process. If we analyze the details of differentpractices, we can see that in many cases the process is not well managed. The two mainconsequences of inefficiency or poor management are time wasted on non-strategic activities anddissatisfaction among the workforce . Here are some examples of common problems that impactthe organization.

Example Consequence Cause

The officer has to review paper-based requests and enter the datamanually in the system.

• Time consuming• Workforce

dissatisfaction• Error prone

• Multiple recapture ofinformation

The HR officer is giving incorrectinformation because his source isnot up to date.

• Workforcedissatisfaction

• Error correctionneeded

• Multiple unsynchronizedsystems

Employees don’t have access totheir up to date remaining paid-vacation days.


dissatisfaction

• Unavailability ofinformation

The approval status is waiting sinceseveral weeks because the managerhas still not processed the request.

• Time consuming• Employee

dissatisfaction

• Approval process notoptimized

The officer has to review paper-based requests and enter the datamanually in the system.


dissatisfaction• Error prone

• Multiple recapture of

information

Note that depending on the type of organization and what type of laws apply, different types ofleave exist such as sick time, paid and unpaid vacation time, personal time off, etc. The type ofleave is usually linked to the payroll system.





3.1. Business requirementsKeeping in mind the primary business objective of improving process efficiency and increasingemployee satisfaction, here are the requirements that the first iteration of our application shouldaddress:

1. Provide a centralized solution to manage employee leave request2. Provide a solution appropriate for the 3 distinct user profiles: requestor, manager and HR

officer3. Eliminate paper timesheets4. Eliminate error-prone manual processes5. Automate the existing process from request submission to request information

documentation/archival6. Share information across the company

7. Notify employees when key decisions are made

3.2. Application scope

Business Requirements Solution

Centralized solution to manageemployee leave request

Build an executable model to orchestrate the businessprocess; build a business process application, with a web-based interface, to interact with end users.

Adapt the solution to the 3 distinctuser profiles: requestor, managerand HR officer

Include the 3 personas during the design of the processmodel and address their requirements at an early stage.

Eliminate paper timesheets andother error-prone manual processes

Design web forms within the process model in order tomanage data entries. Implement automatic data validationrules to ensure data integrity. Use connectors to push datato external IT systems. In our example, the leave request aswell as all the approval steps will be managed through aweb form.

Automate the approval process

Use BPMN 2.0 graphical elements to model the approvalprocess relevant to your organization. In our example, theprocess model will automatically route an employee’sleave request to the employee’s manager first and then tothe HR officer.

Notify employees when decision aremade

Include the appropriate notification scheme in the processmodel. In this example, we will use connectors toautomatically generate notifications.





4. Phase II: Process model designThe purpose of this phase is to design the business process model. It usually starts by analyzing theexisting process within the organization. The business analyst or the person who drives the needsfor the process is usually the one creating and refining the model. The process needs to address thespecific business case and the previously listed business requirements.

4.1. Happy pathOne of the best practices of process modeling is to start with the design of the “happy path” 1. Theidea is to simplify the model of your process in order to visualize the activities and the flow from itsbeginning 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 leaverequest web form. Once the process is started, the flow is then automatically routed to the firsttask called “Manager checks request”. This human task means the employee’s manager will checkthe employee’s request through a web form and decide whether or not to approve it. If theemployee’s manager approves the request, the flow is then routed to the second task called “HRchecks request”. At this second level of approval, the HR officer has to verify whether the request islegitimate or not. If the HR officer approves the request, it is then routed to a third service taskcalled “Notify of approval”. Once the email notification has been automatically sent to theemployee, 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 thecalendar publication has been completed, the flow is routed to the terminate end event that stopsthe entire process.

4.2. Human vs Service taskA human task is an activity to be performed by a user as opposed to a service task to be executedby the system. In Bonita BPM, a human task is an activity that is exposed to the end user. The

1 Best practice #1: start p rocess modeling by representing the “happy path” in its simplest version. The purpose is to represent the mainactivities from the start event to the end event without including the alternative paths.





developer can design web forms and manipulate data interactively with the process. Human tasksand their associated web forms are displayed in the Bonita BPM Portal task list view.

4.3. Pool, lanes & actorsOnce we have designed the “happy path”, we can now illustrate the 3 different functionalresponsibilities we have in our business process. Figure 6 shows the pool, “Leave Process”, thatrepresents the process. The pool is sub-divided into 3 lanes, each representing a participant in theprocess. The first lane, “Employee” includes the element (start event) related to the employee’srequest. The second lane, “Employee manager”, corresponds to the employee’s manager role. Thethird lane, “HR officer”, refers to the human resource officer responsibilities. Thus, the lanesvisually 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 thetask 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 todetermine 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 thatthe leave process can only be started by a user who is mapped to the “Employee” actor.





Figure 7. Create actors and set process initiator

Note that we haven’t created an actor with the employee’s manager responsibility. The end user isdefined from derives from the employee actor through the use of an actor filter called “Initiatormanager” that returns the manager of the initiator of the process.

Figure 8. Assign actor actor filter for “employee’s manager”





4.4. Alternative endingsOnce we have defined the “happy path” with the appropriate lanes and actors, we can now designthe 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 subordinate’s leave request. Themanager can either approve or refuse the request. Each of these options represents a differentpath on the diagram. The exclusive gateway , “Approved by manager?,” routes the flow in the onlybranch 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 thenotification 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 employeelane because we considered that it was more readable this way since the notification is intended tothe employee. Nevertheless, a service task is not concerned by the actor concept since it is notperformed by a user but by the system, other options are also possible such as put it inside themanager lane or creating a new “system” lane for it.

4.4.2. If the request is refused by the HR officer

When an employee’s request has been approved by the manager, it is automatically routed to theHR officer for review. The HR officer can either reject or approve the request. To manage these 2cases, we added another exclusive gateway: “Approved by HR?” In case of refusal, the flow is







Figure 11. Process with 3 possible paths

4.5.1. Request approved by the manager & the HR officer

When the HR officer validates the employee’s request, the flow is routed to the service task“Google calendar update”. This task automatically creates a Google calendar event with all theemployee 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 ): oneto handle the email notification to the employee and the other to handle the update of the numberof leave days remaining after the approved request. Notice that the parallel gateway receiving theflows from the two service tasks will merge them again once the two are performed. This behaviorensures that process can’t end without having completed the “DB update” and the emailnotification to the employee.

4.6. User management & task assignationThe 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. Theassignment of an actual user to a task can be performed when actors are mapped with the usersfrom the active organization . Actor mapping is done via the process configuration. The processconfiguration can be changed after deployment of the application. This means that it is possible todynamically 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. Thismeans 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





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 officerchecks request”.

Figure 12. Actor mapping definition: actor “Employee” mapped to the role “member” andactor “HR officer” mapped to the group “HR”

To create users, create an organization via the submenu Manage… of the menu Organization . Forthis example, we have created an organization called “ BonitaSoft S.A. ” This organization iscomposed of different groups, roles and users. The membership is the assignation of a group and arole to a user.





Figure 13. Creation of the organization “BonitaSoft S.A.” from the menuOrganization>Manage …

To make your organization “active”, you need to publish it. Only one organization at a time can beactive during execution.





5. Phase III: Data ManagementThe purpose of this phase is to determine the data needed to build the business processapplication. First we need to distinguish business data and process data.

Figure 14. “business” and “process” data in Bonita BPM

5.1. Business dataBusiness 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 otherapplications within the organization. Business data are also very often useful for reportingpurposes. Best practice is to manage Business data in an external database. In our case, thebusiness data correspond to the employee information and the leave request.





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 Employee’s fist name

Last name* Text Employee’s last name

Email* Text Employee’s email

Manager* Text Employee’s manager

Available annual leaves Numeric Remaining days for annualleave types

Available sick leaves Numeric Remaining days for sickleave types

Bonita BPM 6.0 offers a simple directory called organization in order to manage the users. Theorganization 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 theEmployee ID.

5.1.2. Leave request object

The employee leave request gathers the information about the leave. The leave request will thenbe stored as a table in an external database. Here is the leave request table definition:


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 inthe company

Number of days Numeric Number of days off

Type of leave Text Type of leave available

according to





company/country: annualleave, sick leave, unpaid

leave, other

Status Text Status of the leave request:submitted, approved bymanager, refused bymanager, refused by HR

officer, validated

Manager refusal comment Text Manager refusalexplanation

HR officer refusal comment Text HR officer refusal

explanation

5.2. Process dataProcess data represent the information that the executable model needs to route the flow to theright tasks. In this example, it includes the approval or refusal of the employee's request by themanager and the HR officer.


Approval Boolean Boolean variable thatindicates the approval (true)or the refusal (false) of theemployee leave request,either by the manager orthe HR officer.





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. Inour application example, we have identified the 3 use cases below that require the use of suchconnectors:

• 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 ofpre-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 employee’s leave dates on a shared Google calendar





On the process diagram, connectors are identified by a “plug” icon on the upper right corner of atask. 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 useconnectors within forms (eg. to initialize a field, on the submit button, etc.).

In the next sections, we’ll explain how the connectors are configured.

Figure 16. Connectors on tasks

5.3.2. Configuring the Bonita email connector to send notifications

Objective

According to the process design, an email notification is sent to an employee when the managerhas refused the request, when the HR officer has refused the request, or when the request hasbeen approved by both the manager and the HR officer. The email notification will be sent to theemployee 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 leaverequest.

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 Bonitaconnectors plus any user defined connectors you may have added. The SMTP email connector isunder the category Messaging . Like the other connectors, its configuration is facilitated by a step-by-step configuration wizard. Here are the detailed configuration steps.

First stepIn the first step, define the name, the description, the triggering event and the error managementoption for your connector. For the Select event option, select Finish which means the connector willbe executed at the end of the service task. This gives us the opportunity to execute anotherconnector at the beginning of the task in order to retrieve the business data (eg. start date, leavetype, etc.) required for the email content definition.





Figure 17. First step to define the email connector

We selected the option, “Put in failed state.” This offers the Bonita BPM Portal administratorresponsible for the application case management the possibility to detect the error, correct it andreplay the task.

Second step

Define the SMTP server connection information. It isrecommended to use parameters for the technicalsettings of the connector configuration 2.

2 Best practice #2: use of parameters for technical settings. Indeed, parameters are part of the process configuration and they can bedirectly modified in production from Bonita Portal without having to redeploy the application.

In Community Edition ,as parameters are not available, you

can use process data with type‘Constant’.





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 useda parameter for the sender address (eg. [email protected] ). The recipient emailaddress needs to be dynamically evaluated and should correspond to the employee whorequested the leave. To do this, open the expression editor and select script . Here is theGroovy script used to return the required email address:

Figure 19. Third step to define the email connector





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 andthe content are dynamic.

Figure 20. Fourth step to define the email connector

Here is the script definition used for the object called “Title”:

Where managerFirstName and managerLastName are two transient variables defined at theservice task level (“Notification of manager refusal”). Indeed, the rich text editor provided with theemail connector allows inserting process variables but no Groovy script. This is why we used twotransient variables defined at the task level.

ReturnBonitaUsers.getUserProfessionalContactInfo( ,BonitaUsers.getProcessInstanceIapiAccessornitiator( , ).getId()).getEmail(); apiAccessor processInstanceId

return managerFirstName+ " " +managerLastName+ "has refused your leave requestsubmitted on:" +leave_request_creation_date;





Figure 21. Definition of transient variables

Here are the scripts used to initialize these two transient variables:

Here is the email content definition for our email connector:

return

BonitaUsers.getProcessInstanceInitiatorManager( , ).getFirstN apiAccessor processInstanceId ame();

return

BonitaUsers.getProcessInstanceInitiatorManager( , ).getLastNaapiAccessor processInstanceId me();





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 thebeginning of the task by a database connector set on Enter . All the business related information isstored in our external database, so we need to use a database connector to retrieve it.

Here is an example of the generated email:





Figure 23. Email message with variables

5.3.3. 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 thestart event (See section 36). This means that submitting a leave request will start a processinstance. The objective of the database connector in our case is to store all the information enteredin 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 onthe 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 buttonor the form itself and select the Connectors tab in order to add the connector.





In Community Edition ,as form connectors are not available,the connector at the pool level can be

used.

Figure 25. Add a connector to the form

Here are the detailed configuration steps.

First step

Set the name and the description of theconnector.

Figure 26. Create a database connector

Second step

Choose between 2 options to define the SQL query. The graphical builder offers a graphical modeto build the query. It requires you to first configure the access to your database. The other option isto 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.





Figure 27. Choose connector editor

Third step

Define the settings to access the external database. As a good practice, we use parameters so thatit can be changed later without having to redeploy the application if its configuration changes.

In Community Edition ,as parameters are not available, you can use process data

with type ‘Constant’.





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 wehave defined a Groovy script named insert leave . Here is an example of script we use to store theleave request in the database.

Figure 29. Configure database query





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 requestinformation required to for the human task “ Manager checks request. ” The best practice to managebusiness 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 formperformance with too many connectors in the forms. Also, using a transient data at the form levelwill 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 customdata type is defined, you can create it as a JAR. To create the transient data derived from thecustom Java object, click on the human task and select Application>Pageflow>Transient Data .

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;





Figure 31. Add new data type as transient data

In this example, we have created thetransient java object named“employeeRequest” and it is initialized bythe database connector named “get leave

request data.” Since most of theconfiguration steps are similar to thepreviously presented database connector,we are only presenting here the steps thatare different.

SQL query definition

Here is the script we defined to select the submitted leave request information:

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 leaverequest 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 transientvariable “employeeRequest”

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_requestWHERE bonita_id =" +BonitaUsers.getProcessInstanceInitiator( , ).getId()+ " ANDapiAccessor processInstanceId start_date= '" +mySimpleDateFormat.format(leave_request_start_date)+ "'" ;logger.severe(mySQL);return mySQL;

In Community Edition ,as Java Data Type creation is not available, you

can create the Java objects externally and importthe jar file into Bonita BPM Studio. Also, as

connectors to initialize form transient data arenot available, define a task transient datainstead and a task connector to initialize.





Figure 32. Connector output configuration

Here is the script we used to define the mapping.

5.3.5. Configuring the database connector to update the employee’s remaining leavedays

Objective

The objective is to use a connector to update the employee’s remaining leave days right after theapproval of the HR officer. As shown on the process diagram, this operation is managed by theservice task “database update.”

Figure 33. Leave request database update task

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;





SQL query definition

Here is the script used to update the employee’s remaining leave days:

Note that in this example, each employee has fixed number of annual leave and sick leave eachyear. 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 Googlecalendar.

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.

if (typeLeave == "Annual leave" ){return "UPDATE public.employee SET available_paid_leave = available_paid_leave -" +numberDays+ " WHERE bonita_id =" +BonitaUsers.getProcessInstanceInitiator( , ).getId();apiAccessor processInstanceId } else if (typeLeave == "Sick leave" ){return "UPDATE public.employee SET available_sick_leave = available_sick_leave -" +numberDays+ " WHERE bonita_id="+BonitaUsers.getProcessInstanceInitiator( , ).getId();apiAccessor processInstanceId }





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'" );





6. Phase IV: Web user interface designWith Bonita BPM Studio, you can create web forms which are displayed to the end users when theyperform their assigned tasks. These web forms can be created on human tasks. A form can also beadded at the pool level. The submission of a pool-level form triggers the creation of the processinstance. In our process model, we have designed 3 web forms:

• The “leave_request ” form to be used by all employees, and which gathers all the requiredinformation to submit a leave request.

• The “manager_validation” form to be used by the managers to view the leave requestssubmitted by their subordinates, and to approve or refuse them.

• The “hr_validation” form to be used by the HR officers to review the leave requestssubmitted by the employees and approved by their managers.

6.1. Leave request submission formThis 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 gridsystem composed of rows and columns. A palette of drag-and-drop widgets is available for thedesign of the form fields. In this case, the form should include a section with the employeeinformation and another section related to the leave request submission.





6.1.1. Employee information section

For this section the purpose is to display the employee’sfirst name, last name, email and manager. Since this

section will also be displayed in the manager validationform and the HR officer validation form, it isrecommended to use a group widget in order to be ableto reuse it. A group widget and its content can be savedas a template ( Forms>Save Widget as a template… ). It is also good practice 3 to use a group widget,because the data initialization can be done with only one Groovy script. This improves formperformance.

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 groupwidget level by clicking on it and going to the Data pane of the General tab. Here is the script weused 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 “ savewidget as a template… ” offers the capability of reusing the widget template in other forms. Using a group widget also allows global datainitialization at the group level using a java Map object.

In Community Edition ,as group widgets are not

available, the forms can bedesigned without them.





We also added a “message” type widget above the group widget to display the “employeeinformation” section. We tuned the appearance of the widgets using the Appearance taband then Field. Here is an example of customization ( text size, color and position ) we haveapplied 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.

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 loggedUserIdContactData UserContact =BonitaUsers.getUserProfessionalContactInfo( , );apiAccessor loggedUserId long managerId = user.getManagerUserId();User manager = BonitaUsers.getUser( , managerId);apiAccessor result.put( "firstname" , user.getFirstName());result.put( "lastname" , user.getLastName());result.put( "manager" , manager.getUserName());

result.put( "email" , UserContact.getEmail());return result;





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 ourexample, 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. Design request form

6.1.3. Data initialization and consistency

We initialized the “Type of leave” list with a Javalist variable defined with 4 values: annual leave ,sick leave, non-paid leave and other . By default,the selected value is set to “annual leave.” The textfield “Available days” informs the employee abouthis remaining paid leaves so that he can take it intoaccount as he is creating a new leave request. The information is pulled out from the businessdatabase using a connector 4. Since the remaining leaves value to be displayed depends on the typeof leave selected by the employee (annual or sick leave) we used the Contingency feature. Asshown 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 iseither “Unpaid leave” or “Other”.

4 Best practice #4: use of transient form data initialized by connectors to manage data required in a form.

In Community Edition ,as contingency is not available, you

can implement it with JavaScript andexternal APIs.





Figure 40. Example of a hidden contingent widget

Here is the condition we used:

When the type of leave is changed to sick leave for example, the update value expression returnsthe appropriate remaining leave days for the concerned employee. Here is the SQL query we usedfor the connector getting the remaining leave days:

To ensure data consistency regarding the date widgets, we used the Validators feature at the formlevel. For example, to ensure that the start date is prior to the end date and to the return date:

return ( "Annual leave" .equals(field_leave_Type) || "Sickleave" .equals(field_leave_Type));

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

}





Figure 41. Add a validator to the field

Here is the Groovy expression (date validation) used for the field Parameter.

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 businessdatabase at the submission of the form. We added a connector positioned on the Submit button.

Figure 42. Add a connector toexecute on the submit button

Please refer to the section ( 27 –

Fourth step ) for the leave requestdata insertion explanations.

return field_dayOfLeave.before(field_Date1)&&field_Date1.before(field_dayOfReturn);

In Community Edition ,as form connectors are not available, you can

implement this with either task or pool connector.





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. Inorder 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 tothrow an error when the database connector fails, and catch the error with a Catch Error boundaryevent 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 tothe managers includes an additional section called “manager validation,” composed of:

• a radio button to set the “Status” of the employee’s 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 therequest. To implement this, we used the Contingency feature with the following condition:

6.1.7. HR validation form

The form designed for the HR officers is almost identical to the one for the managers. When weadded this form, we used the option “Duplicate a form from the list below” in order to reuse theexisting manager validation form.

return field_Radio_buttons1.equalsIgnoreCase( "refuse" );





7. Phase V: application testingIn this chapter we present the final application to the end users, specifically these three identifiedpersonas:

• 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 theleave 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 employeeRaphael that he has 25 annual leave days remaining. The submission of this form will thenautomatically create a new task for the employee’s manager, Charles. In our example, Charles willget a new task in his inbox.

Figure 44. Leave request form

If the employee selects incorrect dates for leave, the designed form validator (see Datainitialization and consistency ) warns him and blocks the data submission. Here is the result of thevalidation.





Figure 45. Warning appears if leave dates are incorrectly entered

7.1.2. The manager reviews leave requests

After logging into the Bonita BPM Portal, the manager can check the task list and sees all leaverequests waiting for approval. In our example, Charles has a new item in his task list named “Leaverequest from Raphael.”

Figure 46. Manager’s task list

When the manager opens the task, the leave request submitted by a team member appears. In ourexample, Charles gets the leave request submitted by Raphael at the previous stage (start date:09/26/2013).





Figure 47. Manager approval form

7.1.3. HR officer reviews approved requests

After logging into the Bonita BPM Portal, the HR officer can check the task list and views all theleave 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.





Figure 48. HR Review Form

When a leave request has been approved, the process flow adds 2 additional service tasks. Onehandles the email notification of approval, and the other manages the Google calendar eventpublication.

7.1.4. The employee is notified

Since the HR officer approved the request, the process application then gets all the requiredinformation from the business database and uses it to automatically send an email notification tothe employee who has requested the leave. Here is the email notification received by Raphael.

Figure 49. Email notification send to employee





7.1.5. Google Calendar event publication

Based on the approved leave request information, the process automatically publishes thecorresponding Google agenda event to share the leave information with the rest of the team.

Figure 50. Update to Google calendar

7.1.6. Update of the remaining leave days

If the employee tries to request a second leave right after the approval of the one previouslyapproved, he will then see that his number of available days has been updated. In the screenshotbelow, the employee Raphael has now 23 available annual leave days compared to 25 when hesubmitted his first request.

Figure 51. Number of available leave days has been updated





7.2. Alternative path testing: the leave request is refused by themanager

The manager reviewing a leave request from his subordinate can decide to refuse it. If the managerselects “refuse”, the text box “Refusal comment” is automatically added and an explanation isrequested.

Figure 52. Manager refuses leave request

The refusal of the leave request automatically routes the flow to the service task in charge of theemail notification. The employee, Raphael, receives the email notification bellow including theexplanation of his manager Charles.





Figure 53. Employee notification in case of refusal

8. Next stepsFor 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 thathe/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 onleave during the same period, to avoid having everyone on the team on leave at the sametime.

• Show employee leave reporting at a team/function/business unit level for capacity andproject planning.

• Add the ability to export and import leave request information through connection to apayroll system.

• Support cancellation of leaves by employees.

For more information about leave management process applications, see the Process Library onwww.bonitasoft.com .





9. Further reading

Best Practicesfor Getting Started with BPM

Speaking to the C-Suiteabout BPM

UnderstandingBusiness Process Automation

More information available at www.bonitasoft.com .



HEADQUARTERSGRENOBLE, FRANCE32, rue Gustave Eiffel38000 Grenoble

EMEA, ASIA & LATIN AMERICAPARIS, FRANCE73-77, rue de Sèvres92100 Boulogne-Billancourt

NORTH AMERICASAN FRANCISCO, USA51 Federal St. Suite 305

San Francisco, CA 94107

Documents

Develop a First Process Application 251013 -V1