IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Developing business processes > Building BPEL processes

Business processes

A business process is any course of action or procedure that an organization follows to achieve a larger business goal. When you break it down, a business process is actually a series of individual tasks or activities that are performed in a specific order.

Authoring of business processes is an integral aspect of IBM Integration Designer. Business processes provide the primary means through which enterprise services are integrated. Even users who do not have programming skills can use IBM Integration Designer to compose integrated business solutions. You can easily create and develop a business process in an intuitive graphical programming environment called the BPEL process editor, and deploy it to a separate runtime environment.

Before you start to use the BPEL process editor, you need to understand these key concepts about business processes:

Microflows

A microflow is a process that is contained within a single transaction. Because it runs automatically from start to finish, it is ideal for situations in which the user expects an immediate response that does not require a human task. An example of a microflow would be a database query.

Long running processes

A long running process executes over an extended period of time, and is much more flexible and resilient than a microflow. It is used most commonly with services that may not respond immediately, in particular human tasks.

See the subsequent sections for more details on other important concepts.


An example of a simple business process

Let us begin with an example of a simple business process. This figure illustrates the steps involved when a vendor sells an item to a customer.

Figure 1. A simple real-world business process

Before continuing, here are some terms that will help you bridge your knowledge of business processes in the real world, and those in IBM Integration Designer:

Partners

These are the external users or services that interact with the process.

A process starts and ends somewhere, and involves the interaction of at least one other outside force: partners. Partners are the parties that interact with the business process. In this example, the partner is the vendor who is interacting with process by supplying inventories, quotes, and fulfilling purchase requests.

Activities

Activities are the individual business tasks within the process that compose the larger business goal.

In this example, activities represent each step the vendor takes while interacting with the customer and completing the business between them.

Variables

Variables store the data that is used by a business process.

Imagine that in this example, all communication takes place as messages on paper. The messages represent the data, and the paper represents the variable. The messages move from the partner to the process, and as a result they can get appended to, changed, or copied to, other pieces of paper.

In this simple example, you have all the basic concepts of a business process. Not every business process is this simple. In the next few sections, the processes become more complicated, the examples go into greater detail, and show you how business processes can match real-life behavior.


Transactional business processes

A concept that you have to understand when you developing business processes is transactions.

In the real world, a transaction is the activity that takes place between the parties involved in a business process that work toward the larger business goal. Sometimes, the entire business process is considered to be just one transaction. Other times, it is the smaller series of transactions that, when added together, create the whole.

In fact, you have already been exposed to a transaction. Take a look at the simple business process example again, as shown here with a few minor additions.

Figure 2. A simple business transaction

There are a few new terms added to the figure, the most important of which is the term committed. This is a key concept in understanding what a transaction is. Simply put, a transaction is not complete until it has fully completed and the results locked in place. Take a look at the figure again, and you'll note that at any time before commitment, the whole process could be canceled easily without complication. However, once it has been committed it can no longer be undone so simply, and the actions that took place must instead be compensated. This term will be discussed in more detail later in this topic.

Essentially, all business processes consists of at least one transaction, but this alone does not make a process transactional. To be transactional, the process must be composed of a number of individual transactions, and these transactions can be composed either of one single activity, or a group of activities. Each activity in your process must belong to exactly one transaction, and each activity must commit its operation before the processing continues. The importance of transactions relate to the concept of compensation (see below) as they are predefined points where the business process can be stopped either to record all accumulated activities, or to roll it back to a previous point.


Interruptible business processes

Processes can be interruptible in that they consist of more than one transaction, and so are designed to pause periodically, or non-interruptible where they run without stopping at all.

When a business process is interruptible, it is long running, and the process will stop at specific activities (where an end of a transaction boundary has been set) and will not continue until an appropriate action has taken place.

When a process is paused, it is waiting. You decide what it waits for.

For example, you may decide that it needs instruction from a human before continuing, or you may decide that it cannot proceed until it has specific input from a partner.

The next two examples are interruptible business processes.


Asynchronous business processes

As we discussed earlier, a partner interacts with a business process with the purpose of receiving a message in response to a request. When this response does not come back immediately, it is called an asynchronous business process.

Consider the following example:

Figure 3. An asynchronous business process

In this figure, our customer is still interested in the same object as before, but it is not physically in the vendor's store. An order is placed for the object and rather than receiving it directly from the vendor, the customer receives it in the mail at a later time. In this business process, the customer sends a request to the vendor, and the response comes from somewhere else.

For another example, think of a synchronous process as a telephone, and an asynchronous process as the postal system. When you are having a conversation on the phone, you send and receive messages instantaneously using the same connection. If you were to send the same message in a letter using the postal service, it would be delivered in one manner, and its response returned in another.


Correlations

Thus far, the examples in this topic have been fairly simple, at least as far as the vendor is concerned. In a typical business however, a vendor will usually be using the same business process with more than one customer, and will often have to work with multiple customers at the same time. With so much going on, it is easy to lose track of the status of these interactions, so the vendor uses correlations to distinguish the customer in their initial interaction so that they can recognize each other in the future. A correlation is the record that the vendor uses to keep track of multiple partners in the same business process.

Consider the following example:

Figure 4. A business process that uses correlations to identify customers

In this example, a customer goes to the vendor's store looking for a specific item that is ultimately sold out. Accordingly, the vendor issues a rain-check to the customer so that when there is sufficient stock, the customer can return and the vendor will be able to pick up the business process where it left off. The vendor is essentially assigning a token to the customer used to identify the customer when the transaction resumes.

It is important to note that the vendor is able to manage multiple tasks, and does not hang in a single business process waiting for it to conclude at the expense of all other activity. Instead, while they are waiting for the object to arrive, the vendor conducts similar business, using the same business process, with other customers.


Compensation

Compensation is an action that is executed when a state is reached in your process that you have deemed to be undesirable. The goal is not always to return to a previous condition, but instead it is to maintain a balanced and consistent state and to deal with any committed operations that conflict with this state.

Business compensation is used in a transactional process where an operation has already been committed, and cannot be reversed.

For example, if anything goes wrong during the simple business transaction example, it is a simple matter of replacing the object on the vendor's shelf, and halting all communication between the purchaser and the vendor. If, however, the transaction has been committed, then cancelling it is not possible and you cannot simply return the object to the shelf and walk away.

Let us assume for example, that the vendor was offering a time-limited guarantee, and the customer returned the defective object within that period of time. In such a case, the original business process is still actually in effect, and it resumes the moment the customer returns with the object. The customer wants something in return for the broken object, and if you recall, the transaction was fully committed in that money was exchanged for goods. A completely different procedure (a refund) must take place to return the conditions to a balanced state. It is not necessarily exactly the same state that existed before (for example, the customer paid in cash but receives a store credit in return), but nonetheless it is one that is balanced and consistent. If either the customer or the vendor are unhappy, then business compensation has not been successful.

Figure 5. Business compensation of a simple business process

Building BPEL processes


Related concepts:
Work with BPEL extensions
Choose between long-running processes and microflows
Best Practice: When to not use the BPEL extensions


Related tasks:
Compensating activities in a long-running process
Compensating a microflow


Related reference:
Server tab: BPEL process editor