1.2 Speaking the BPM language （谈谈BPM语言）
We already spoke about business processes and the BPM life-cycle, but there is a lot of other terminology used in the BPM space. Therefore we will look at the most important parts of the BPM language in this chapter to get up to speed for the rest of this book.
1.2.1 Getting the big picture （获取大图）
First, let’s look at the big picture of the BPM terminology by looking at a typical BPM architecture. Such an architecture is implemented by a business process management system or suite if you like (BPMS). There are a lot of software vendors who provide BPMS software (such as IBM, Oracle, Tibco, Intalio and of course Alfresco with Activiti), but all their suites contain similar tools. Figure 1.3 provides an overview of a typical BPM architecture.
Figure 1.3 An overview of a typical BPMS architecture, with a process engine in its core and surrounded by process modeling, monitoring and life-cycle management tools.
There are quite a lot of components mentioned in figure 1.3, but the core of a BPMS is without doubt the process engine. In most chapters of this book we’ll therefore discuss this part of a BPMS in detail. The process engine is responsible for handling the process state for example. Because processes can run for days, weeks or even months it’s vital that the process state is persisted in a database. In case of hardware or software failure, the process
state can always be recovered based on the process state retrieved from the database.
In the rest of this section we will look at each of the four core components of a BPMS architecture, first the process engine, then the process modeling tools, third the process monitoring tools and eventually the process life-cycle management tools.
1.2.2 Exploring the core process engine （探索核心的流程引擎）
A process engine is the foundation for a business process management suite. The process engine is capable of executing the business process model with quality aspects such as availability, performance and robustness in mind. In the next subsections we discuss the core parts of the process engine, the process state manager and the human task manager. The business rule engine integration will be discussed in chapter 9 and we’ll be talking about
the process history service in chapter 12 and 13.
PROCESS STATE MANAGEMENT（流程状态管理）
One of the common requirements of a business process is that it must be able to run over a longer period such as a day or a week. In that period the business process must be capable of accepting requests and handling events and progress a step further in the business process definition. A simple implementation of a process engine supporting this requirement would keep the running business processes in memory until it eventually reaches its end state. This would however lead to a very high consumption of memory when a lot of business processes are running.
Therefore a core capability of a process engine is to have good process state management. A common solution for managing the process state is to have the current state of a process stored in a database at certain points in a process execution. When we talk about the process state you can think of the following parts of a process:
- Process variables
- The current activity in the process execution, often named the process execution token.
- Assigned users / groups in a user task
- The start and end time of executed process activities
Because the process state is stored in a database, the process engine can also recover running processes after a server shutdown, due to hardware failure or regular maintenance. So the process state manager is a vital component of the process engine.
HUMAN TASK MANAGER（人工任务管理）
Another important component of a process engine is a human task manager to support workflow functionality. With workflow functionality, we mean the creation of user or group assigned tasks during process execution. In BPMN 2.0 this can be implemented with the user task construct.
The human task manager should be capable of assigning tasks to specific users or groups of users. This also means that an API must be available to query the human task manager for tasks available to a specific user. A task can have at least three different states.
1. The task is unassigned, which means that the task is available to every user that is part of the user or group criteria specified in the task configuration.
2. The task is assigned, which means the task is assigned to one and only one user. This user has claimed the task, so the task will not appear on other user’s task lists. Of course administrators and managers still can perform commands on this tasks in exceptional cases.
3. The task is completed, which means the task is completed by the user who has claimed the task in the first place.
User or group criteria define the users who can claim a user task. Often, there is support
for LDAP queries to fill-in this criteria.
1.2.3 Modeling and design tools （建模和设计工具）
It’s great to have a process engine to run your business processes, but a BPMS also need modeling and design tools to create the business processes. Before BPMN 2.0 it was easier to differentiate between modeling and design tools, because modeling tools used a modeling notation like BPMN 1.x and design tools used a process execution language like WS-BPEL or jPDL for jBPM.
尽管拥有流程引擎来运行你的业务流程，但是BPMS也需要建模和设计工具来建立业务流程。在BPMN 2.0之前，区分建模工具和设计工具是比较容易的，这是因为建模工具使用像BPMN 1.想的建模符号，设计工具使用WS-BPEL或者就BPM的jPDL的流程执行语言。
With BPMN 2.0 we now have a standard that provides a modeling notation as well as a process execution language. This means that it’s not necessary any more to convert and transform a BPMN 1.x business process model to WS-BPEL. But as we will see in section 1.3.3, there’s still a difference between the level of detail used in modeling and design phases. A modeling tool has to support features to do high-level modeling and a design tool must be able to create a process execution model that can be directly deployed to a process engine. There may be tools which support modeling as well as design functionality, but we’ll discuss the functionality separately here.
BPMN 2.0既提供了建模符号的标志，也提供了流程执行语言的标准。这意味着，将BPMN 1.x业务建模语言转为WS-BPEL不再有必要。但是，正如我们将在1.3.3所见，建模和设计阶段所使用的细节层次仍有差别。建模工具不得不支持高层次的建模特性；而设计工具必须能建立能够直接部署到流程引擎的的流程执行模型。尽管也许存在既支持建模，也支持设计功能的工具，但是，我们在此分开讨论这些功能。
MODELING A BPMN BUSINESS PROCESS（对BPMN业务流程建模）
A BPMN modeling tool should support the definition of business processes by business and information analysts. This means that in a modeling tool we don’t want to be restricted too much by the formal BPMN 2.0 specification, but the focus should be to support the user in the definition of the business process model in a user-friendly way.
In addition, it would be nice to see simulation functionality in the modeler to be able to see if the modeled business process executes as expected. There are pretty advanced simulation tools available that can calculate maximum throughput and can identify possible bottlenecks in a business process and this is vital functionality to do successful BPM.
DESIGNING A BPMN BUSINESS PROCESS （对BPMN业务流程进行）
The designer tool takes a BPMN business process defined in the modeler as starting point or you can decide to design a business process from scratch if you want to. A designer tool is often dedicated to support a specific implementation of a process engine. Where a modeler tool can and should be vendor independent, a designer can contain vendor specific details and have support for vendor specific functionality inside a process engine.
Important functionality for a designer is to be able to add for example error handling to a process, to couple service tasks to web services via WSDL and Java classes, and to couple user tasks to LDAP related queries. Furthermore, it must be possible to run a process engine from within the designer tool and deploy processes on it for testing purposes. Finally it must support unit testing, so a developer is able to perform some basic unit tests before a process is deployed to a central process engine.
1.2.4 Managing and monitoring the process engine （管理和监视流程引擎）
Management functionality for a process engine means that an administrator must be able to query the process engine for deployed process definitions and look into version information. In addition, running process instances can be queried to look into specific states of processes when end users have questions about it. Also for user tasks it must be possible to claim and complete certain user tasks when there is a need for this.
In general, the state of a process definition, process instance and user task must be available for an administrator. This also includes the process engine databases, which are a core part of the process engine. So the database model and its tables should be easily accessible for administration purposes.
Monitoring functionality is more targeted at specific events that occur in a process instance. For example, when a large order enters an order process, it may be interesting for specific managers to receive a signal. Another more technical example is that a process instance is inactive for more than a week, it may need attention to see if the process is still running normally. It’s obvious that management and monitoring is a very important part in the business success of process engines and BPM in general.
1.2.5 Collaborating on business processes （业务流程协作）
Collaboration tools are a central part of a lot of IT projects in general. Collaboration tools include for example source code repositories, code review tools and wiki pages. But in BPM projects it’s even more important due to the complexity and the large amount of different roles and persons in such a project.
BPMN provides a good foundation for collaboration because it supports high level business modeling understood by managers, it also supports detailed business modeling understood by business analysts, architects and designers and with BPMN 2.0 it also support process execution understood by architects, developers and administrators.
A BPM collaboration tool must provide a view on the different process model repositories of a BPM project. There are modeler, designer and even code repositories which must be bundled in one or more views depending on the end user. It’s also very important that everybody working on a business process is identifiable with his role and work in this collaboration tool. It must be clear which person must be contacted for specific questions.
We rushed through the major components of the typical BPM architecture we showed in figure 1.3. But we’ll take a closer look at every part in the rest of this book. For example we’ll look at the process engine in chapter 3, discuss the human task manager in chapter 7 and look at the modeler, designer and collaboration tools in chapter 2. For now it’s good to have heard about the vocabulary, as we will be using it a lot in this book.
With a foundation of BPM knowledge and vocabulary in our minds it’s time to get introduced into BPMN 2.0 and its history.