Business Process

A Simple Demo that Illustrates Loads of BPMS Features

Introduction

This is a simple demo but it covers many BPMS features including:

  • Use of business rules in a task for input validation: siteName can’t be empty and siteProjectId must be one of: ‘NA’ followed by exactly 6 digits or ‘SN’ followed by exactly 5 digits
  • Use of business rules in the form of a decision table
  • Calling external application via a SOAP web service
  • Role-based access control
  • Escalation
  • Dynamic task assignment
  • Parallel tasks
  • Using signals (events that trigger actions in a business process)
  • Business Central UI to manage business process
  • Use of REST API to find out where process instances are at

The project is available on Github.

It is assumed that you are already familiar with BPMS’ Business Central UI to create/update/view assets. The demo will be described pictorially in the following sections.

The Business Process

The business process is shown in the diagram below:

Business Process
Business Process

A number of RED boxes have been added to the business process diagram to make it easy to understand each major function. First up is the INPUT VALIDATION section where the input is validated using business rules to ensure the Planning data object attributes: siteName is not empty and siteProjectId must be one of: ‘NA’ followed by exactly 6 digits or ‘SN’ followed by exactly 5 digits. If the input fails validation, a ValidationError fact is inserted in the working memory and a human task is used to update the attributes in a loop until valid input has been provided.

Next, the site score is calculated using a SOAP web service (Get Site Score WS).

The returned score is then adjusted using a decision table (updateScore) based on the returned score and the location.

The Setup Contractor script task uses a random number to assign Task1 to either Contractor1 or Contractor 2. Task 2 is always assigned to Contractor3.

The two tasks are then executed in parallel logically (PARALLEL TASKS rectangle).

The result is then assigned to a Reviewer to approve or reject a site (Make Decision in the ESCALATION AND SIGNAL rectangle). A boundary timer is used to escalate to his boss (Escalate to Manager) if the task has not been acted on in 30 seconds (for demo purposes). After the task has been escalated and not yet acted on by his boss, the Reviewer can re-claim the task by sending a “sendbackSignal”. Either the Reviewer or the Approver (Reviewer’s manager) can approve or reject the site.

This is a contrived business process to show off some of BPMS’ features. Think of it as a site development project where inspections have to be made by the contractors. Info collected is then used to approve or reject a site for certain types of development on the site. As such, you should not worry about its resemblance or lack of it to a real-life business process.

Input validation

Two simple data models are used for the business process and business rules. They are the Planning and ValidationError data objects.

Planning Data Object
Planning Data Object

 

ValidationError Data Object
ValidationError Data Object

 

The business rules are shown in the following screenshot.

The validation process will continue until the Planning data object contains valid values for the Planning attributes: siteName is not empty and siteProjectId must be one of: ‘NA’ followed by exactly 6 digits or ‘SN’ followed by exactly 5 digits

Validation Rules
Validation Rules

Calling a SOAP Web Service

The Get Site Score SOAP web service is invoked to get a score for the site based on a seed score which is generated by the Init Process Variables script task at the start of the process.

SOAP WS I/O Mapping
SOAP WS I/O Mapping

Use of Decision Table

The score returned by the SOAP web service is then adjusted using a decision table based on the returned score range and the location of the site.

Decision Table
Decision Table

Dynamic Task Assignment

The Setup Contractor script task uses a random number to pick either Contractor1 or Contractor2 as the “targetGroup” for handling Task1. Task1 uses a dynamic task assignment by using #{targetGroup}.

Setup Assignment
Setup Assignment

 

Setup Dynamic Assignment
Setup Dynamic Assignment

Role-base Security

Depending on whether contractor1 or contractor2 has been assigned to handle task 1, only users belonging to that group will be able to see and retrieve the task to action upon. For example, Task2 is always assigned to the contractor3 group meaning that only users belonging to the contractor3 group can see and act on the task. Contractor1 and contractor2 group users cannot see the task when logged in to Business central.

Parallel tasks

Contractor Task 1 and Contractor Tasks 2 in the business process are parallel tasks meaning they can be executed in parallel (logically by BPMS) and the business process does not proceed to the next task until both of these tasks have been completed. The screenshot below is from a login user who belongs to all the contractor groups. That is why he can see both tasks.

Parallel Tasks
Parallel Tasks

 

Escalation

The business process proceeds to the Make Decision human task after completion of the parallel tasks. If the Reviewer has not acted on the task in 30 seconds (for demo purpose so that we don’t have to wait too long to see this happen), it will be escalated to his/her manager. Note the use of a boundary timer to implement the escalation.

Escalation Properties

Signal Setup
Signal Setup
Escalated To Manager
Escalated To Manager

Using Signals

After the task has been escalated but before the manager acts on it, the Reviewer can re-claim the task by sending a “sendbackSignal”. He/she can issue such a signal from Business Central’s ‘Process Management → Process Instances’ menu.

Sending a Signal
Sending a Signal

Manage Business Process

For demo purposes, Business Central will be used to start a process instance, retrieve tasks to action, abort or signal a process instance, etc. using the menu items: ‘Process Management → Process Definitions’, ‘Process Management → Process Instances’, ‘Tasks’ respectively.

Starting an Instance
Starting an Instance
Retrieving a Task to Action
Retrieving a Task to Action

 

Using BPMS REST API

The REST API provides an easy way to search for process instances based on the content of simple process variables. We are making use of a simple process variable named ‘state’ to search for all process instances that are waiting on human tasks. However, for that to work, each human task’s On Entry Actions and On Exit Actions properties have to be populated with the code shown in the screenshots.

On Entry Action
On Entry Action
On Exit Action
On Exit Action

 

SoapUI can be used to look for all process instances waiting on human tasks. A couple of such searches are depicted below.

Search Screenshot #1
Search Screenshot #1

 

Search Screenshot #2
Search Screenshot #2

 

Although I am looking for all instances waiting for any human task using the simple variable ‘state’, you can change the query to use “var_state=Wait_Site_Plan_Correction” to look for instances that are waiting on a specific human task such as the Site Plan Correction human task.

Conclusion

The business process I described is a simple one. Despite of its simplicity, it illustrates many features of BPMS including, business rules for input validation, decision table to adjust site scores, dynamic task assignment, role-based security, parallel tasks, escalation, use of signals, and using RESP API to locate instances matching certain conditions. Owing to its simplicity, it is more likely that customers will understand what you are showing them. It is, in my opinion, a good demo if the customer is not asking to see how BPMS could be used to implement a specific use case he/she is interested in.