Business processes

A business process is any system or procedure that an organization uses to achieve a larger business goal. When you break it down, you see that a business process is actually a series of individual tasks, and each task is executed in a specific order.

As an integral part of the WebSphere® Integration Developer tools, business processes provide the primary means through which enterprise services are integrated. The WebSphere Integration Developer tools have been designed so that users can easily compose integrated business solutions without programming skills. To this end, you can easily create and develop a business process in an intuitive graphical programming environment called the process editor, and deploy it to a separate runtime environment for execution.

Before you start to use the process editor, you need to understand these key concepts about business processes:
Note: Business processes can only be deployed to the WebSphere Process Server.

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
A graphical representation of a simple 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 WebSphere Integration Developer:
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. In this example, the partner is the customer, who has indicated an interest in something in the vendor's store. The customer asks how much it costs, and expects to get a response in return.
Partners are the parties that interact with the business process. In this conceptual example, the customer is the partner, and the vendor is the business process.
The relationship between the partners and the activities in a process.
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 are used by a business process.
Imagine that in this example, all communication takes place on pieces of paper. The messages represent the writing, and the paper represents the variable. The messages move from the partner to the process, and as a result they might get appended to, changed, or copied to, other pieces of paper.
The variable is the means through which a message is carried

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 will show you how business processes can match real-life behavior.

Transactional business processes

The first concept that you have to understand when you start modelling business processes using the process editor is that of 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 a 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
Graphical representation of a basic 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 prior to commitment, the whole process could be cancelled 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 represent at least one transaction, but this alone does not make a process transactional. To be transactional, there must be one transaction for each individual activity in your process, and each activity must commit its operation before execution continues.

Here are some more terms related to transactional processes, as well as the sections that follow:
Microflow
A microflow is a process that is contained within a single transaction. This is ideal for situations where the user is expecting an immediate response.
Long running processes
A long running process executes over an extended period of time, and is much more flexible and resilient than a microflow. Interruptible business processes and asynchronous business processes are examples of long running processes.

Interruptible business processes

Processes can be interruptible in that they are designed to pause periodically, or noninterruptible where they execute without stopping at all.

When a business process is interruptible, it is long running, and execution will stop at specific activities 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 to receiving a message in response to a request. When this response does not come from the place where the request was sent, it is called an asynchronous business process.

Consider the following example:

Figure 3. An asynchronous business process
A graphical example of 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 typically 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


A graphical example of the use of correlations

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 that is 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.

Aliases
An alias associates comparable message parts within a process that are stored in separate variables. Aliases allow two messages to have the same value but be called something different by different partners. In other words, aliases recognize that partners may be using the same data in the process but label it differently.

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 instance, 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 instance, 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
A graphical example of business compensation.

Abstract business processes

An abstract business process is one in which the appropriate business logic to make decisions is defined, but the sensitive information needed to choose a course of action is hidden from the process partners. An abstract process is basically a description of a business process, and cannot be run on the server.

For example, consider the following variation on the earlier transaction. The customer makes a purchase request using a credit card, and the vendor must make a decision that is based on two criteria:
  • the good-standing of the customer's credit
  • the availability of the goods

In this transaction, the vendor makes a call out to two external services in order to make a decision. The first is the vendor's credit card company to see if there is sufficient credit to make the purchase, and the second is to the storage facility to see if the item is actually in stock. The decision logic to enable the decision is clearly defined in the transaction, even though properties of it remain hidden from one partner or the other. For instance, the vendor does not know the details about the customer's credit card (such as credit limit, current balance, or purchase history), only whether it can handle this purchase. Similarly, the customer does not know the full details of the vendor's inventory, only whether or not this item is available.

Feedback
(C) Copyright IBM Corporation 2005, 2006. All Rights Reserved.