In this chapter, we will look at how developers implement the process. This chapter answers the question "How do you move from a model to a running process?", which automatically routes tasks, brings the right forms, applies rules, stores data, and so on.
The main tool to be used is BPM Studio, which you have used in Chapter 1, Process Modeling, while developing the model as a Process Analyst. You will focus on implementing the model. However, the same model that was developed as a Process Analyst will be used. You can switch gears as you are now a Process Developer and are going to implement a running process.
This chapter will focus on the implementation tasks and cover the following topics:
- Defining an Interactive task
- Generating a Task Form for an Interactive task
- Defining an Interactive task for the Finalize activity
- Creating a common Interactive task
- Generating a common Task Form
- Assigning the same Human Task to different Interactive tasks
- Creating Data associations
- Implementing service tasks
- Assigning the outcome of Interactive tasks to Data objects
- Configuring Data association for conditional flows
BPM is a strategy for managing and improving the performance of a business through continuous optimization of the business processes in a closed loop cycle of modeling, implementation, simulation, execution, and measurement. The typical life cycle for BPM is shown as follows:
The process model created in Chapter 1, Process Modeling, has to be implemented before it can be executed on the BPM runtime engine. The Process Developer/IT Developer role is responsible for the implementation. Implementation of the process model involves the creation of implementation artifacts, creation of data types and data mapping, handling of exception conditions, transactional conditions, and compensation logic.
For human interactions managed by the BPM engine, the Human Task implementation artifacts and their associated user interfaces have to be implemented. In addition, the roles have to be mapped to an LDAP user or group before deployment. Similarly, the business rules also have to be implemented. Furthermore, these business rules can be dynamically changed by the business user at runtime to meet the changing needs of the business. Finally, implementation of the process model involves creation of complex data types, variables, and transformation logic to convert data from one format to another.
After the Process Analyst models the process, developers need to implement the process. In this step, developers perform the following actions:
- Refine the model
- Bring technical configuration into the model
- Assign values to measurements and KPIs
- Make a deployable application.
For example, developers define technical components such as sending notifications to perform tasks, forms for participation, and integration of processes with backend systems and other systems.
We will go from a process model to a running process, which automatically routes tasks to assigned participants, brings the right forms, applies business rules that a developer defines, calls the services, stores data, and so on.
BPMN elements include activities (Task and subprocesses), events, and Gateways. BPMN has many types of tasks such as the following:
- User tasks: These are for human steps managed by the workflow component of BPMN runtime engine.
- Manual tasks: These are for human steps not managed by the workflow component of the BPMN runtime engine.
- Service tasks: These are for synchronous system interaction.
- Send and Receive tasks: These are for asynchronous interaction.
- Script tasks: These are for scripting needs
- Call tasks: These are for calling other BPMN processes.
Developers perform implementation tasks for each activity such as defining tasks, rules or services, binding components to their activities, or mapping data (input and output). For each Gateway, they include conditional transitions, define expressions that determine branching, and finally deploy and test.