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.
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.
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.
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.
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.
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.
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:
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.
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:
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.
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.
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.
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.