The capabilities defined in this section provide integration at the business processing level.
The Orchestration capability coordinates the execution of the different activities that make up a business process. Although a business process model is a static representation of the set of activities involved, the Orchestration capability brings the model to life and executes each step within the model. Activities undertaken by the people, systems, or organizations are invoked, coordinated, managed, and measured by the Orchestration capability, according to its process models.
The Orchestration capability triggers the processes corresponding to a business event, passes inputs and outputs across processes, receives communication of status information by different activities, and requests human intervention as necessary.
Generally, business processes begin either with the arrival of a message from the application integration environment communications capabilities, or they begin with the occurrence of a user action (for example, a user typing a customer's last name and then clicking the Search button in a Web interface). Both are considered events in the context of the application integration environment.
The Event Processing capability recognizes when business events have occurred, logs those events, and determines which business processing capability will receive the event. In most cases, this target is the Rules Processing capability.
The majority of events are expected occurrences, taking place as part of the normal business processing carried out by the environment. However, the Event Processing capability must also handle unexpected events, or exceptions. These exceptions are often the result of system-level events on the computers in the environment. For example, the system-level failure of a database that stores inventory may generate events at the business process level, because the business process of checking and updating inventory is no longer possible. In this case, the application could take tentative orders and warn the user that it is not possible to verify the availability of the product at that time. The same database failure might generate events at other levels as well. At the data level, the orders might be stored in a secondary location until the database could come back online, and at the operations level, actions would be taken to restore the database functionality.
System-level events are not handled by the Event Processing capability; instead, they are handled by the Event Handling operational management capability.
In your application integration environment, you are likely to have a number of multistep processes, involving multiple applications that are interdependent. This situation can quickly become unmanageable, with a significant number of applications remaining active and simply waiting for responses from other applications that may not come for hours, days, or even months or years. These applications can consume significant processor resources. The State Management capability reduces the impact on your systems by maintaining the following types of state information across different components:
Applications that use asynchronous messaging typically run until a message is sent asynchronously to a target application. At that point, the state of the multistep process is normally handed over to the State Management capability, and the application releases its resources and shuts down. When Event Processing recognizes the arrival of the response from the target application, it invokes the State Management capability, which in turn identifies the application that initiated the exchange and restarts that application so that it can receive the response to the original message.
To maintain the state of each of the pending applications, the State Management capability maintains a database with an entry for each pending process. For every pending process, the State Management capability has to store the data that must persist between process steps. Hence, State Management maintains a map of the various process steps with a pointer to the next step in the process (for example, the step that must be executed upon the arrival of the response to the last message sent).
Messages exchanged between applications are in various states of processing. Upon arrival, messages are in an active state waiting to be picked up and processed by the receiving application. After they are processed, they are in a journaled state. Messages can also enter the journaled state if they are in the active state for a duration longer than the predefined expiration period. This change of state usually occurs when none of the receiving applications picks up the active message. Journaled messages move on to an archived state when they are archived into a persistent store.
To run properly in its target environment, services require multiple pieces of information including user ID, time, date, contents, and any other information the service might need to access. A service that has all the required information is in a state where it is ready to run. Although most of the information is specified as input by the consumer, services may need to collect the remaining information by accessing other systems and data stores. While it is in the process of collecting this information, the service is in a state where it is preparing for execution. After execution, the service is in a dormant state waiting to be invoked by interested consumers.
Not all pending processes simply wait for a response to a message. In some cases, a process is placed in the pending state until a specified time or date, or until a specified amount of time has elapsed. When this time has elapsed (or when the specified date or time is reached), the Schedule capability generates an event for the Event Processing capability just as any other event.
The Schedule capability also acts as a timekeeper, tracking processes where an external event should occur within a specified time frame or by a specified date or time. If this event has not occurred by the specified deadline, an alert or exception is generated and the Event Processing capability passes this alert to the process that was waiting fruitlessly for the expected event.
Business applications are frequently required to coordinate multiple pieces of work as part of a single business transaction. As an example, think of when you order goods online. Your credit card must be verified, you must be charged, the goods must be selected, boxed, and shipped, and inventory must be managed. All of these steps are interrelated, and if one step fails then generally all of the corresponding steps must be cancelled. The Transaction Management capability coordinates these steps. In some cases, it is not possible to directly cancel out transactions that have already been issued. Instead, you may have to issue additional transactions to compensate for the original transaction. This technique is known as transaction compensation.
Several types of rules may be applied in processing data — both to transform the data through the application of an algorithm (for example, a pricing model) and to route the data through application of a set of business rules (for example, orders for widgets are sent to the widget factory that is closest to the Ship To address on the order).
Some of the rules can be asserted at the time of development and require little access to outside systems or data. For example, all of the data needed to process the rule is contained in the message that is passed to the business capability. In other cases, the data needed to process a rule must be pulled from local and remote databases, and from local or remote applications.
The Rules Processing capability enables a developer or a business analyst to specify business rules without writing a lot of procedural code. The rules may be specified in a declarative programming language (for example, one that is not sensitive to arcane punctuation and does not rely on elaborate language constructs). Alternatively, the rules may be specified by answering questions in a graphical environment such as a programming wizard or a sequence of dialog boxes.
Your organization can define a wide range of rules within business processing capabilities, including:
Data validation rules. For example, is this a valid customer number? Is the postal code valid for the city?
Processing algorithms. For example, what is the total price of this order, considering the customer's contract discount and any additional discounts for the size of this order or the number of orders placed this month, and including the costs associated with the custom configuration?
Processing rules. For example, was the customer's insurance policy in effect at the time of the accident? Or is the value of the order large enough to earn free shipping?
Sequencing rules. For example, before the system can approve a second mortgage application, does it need to send a message to a scheduling application to have the house appraised?
Exception handling rules. For example, if you don't have enough widgets in the warehouse, can you order stock from the supplier and have the the supplier ship the order directly to the customer?
Non-delivery rules. For example, if the order isn't acknowledged by the primary supplier within four hours, do you resend the order, call the supplier's expediter, or send the order to a secondary supplier?
Prioritization rules. For example, given the size of the requested insurance policy, do you escalate the request to a senior underwriter, or can a junior underwriter approve the policy?
Data reconciliation rules. For example, since the last batch update of the customer database, the primary contact name for this account has been changed by both the customer service representative and the account executive — to different names. Which update takes precedence (or do you need to call the account executive for clarification)?
This list is not meant to be comprehensive, nor are the rules listed mutually exclusive. However, it is indicative of the range of rules processing requirements that must be supported in an integration solution.
Often, business processing capabilities manage only the interaction between applications, because in many integration scenarios, user interaction is managed only indirectly. That is, the users interact with applications, and the applications in turn interact with the business processing capabilities.
For those processes that do interact directly with users, an additional business processing capability is needed: the Workflow capability. The Workflow capability uses the rules and state management engines to control the interaction between people and the process management environment.
For example, if an "application for fire insurance" event arrives at the process management environment, the Workflow capability may immediately forward the event to an underwriter, who decides whether the applicant should be insured and at what rate.
To ensure that the application is handled by an appropriate underwriter, a set of assignment and escalation rules may be defined and implemented with the help of the rules engine. Perhaps applications that pose no particular problems or risks can be assigned to the Junior Underwriters queue, whereas the riskiest applicants are assigned to the Senior Underwriters queue. In this example, the rest of the applications go in the Underwriters queue.
If the Junior Underwriters queue becomes too long, escalation rules can move up excess applications to the Underwriters queue. Similarly, if the Underwriters queue becomes too long, escalation rules can move up excess applications to the Senior Underwriters queue. However, rules do not permit the reverse to occur; for example, applications cannot be moved down from the Senior Underwriters queue to the Underwriters queue.
In addition to these escalation rules, the Workflow capability may implement prioritization rules. For example, if an application for fire insurance has been sitting in the Underwriters queue for two days, it can be escalated to the beginning of the Senior Underwriters queue so that it can be addressed before some of the new applications in the queue.
The Contract Management capability monitors and processes contractual obligations at run time. A business contract is an agreement between two or more parties expressing their mutual obligations and permissions for carrying out certain economic exchanges. These exchanges are related to the execution of actions that form multistep business processes.
In the context of business process management, a contract can be treated as a conversation between one party and other parties. The contract can be modeled as one or more workflows where the actions or tasks relevant to the contract (internal to organizations) are described as steps in the parties' business processes. The interactions between parties at various stages of the business process will often take the form of message exchanges.
In a service-oriented architecture, Web services can represent the parties involved in the contract. Specifications such as BPEL4WS can be used to address Web services orchestration and coordination issues. WS-Policy is the emerging standard that is used to implement contract agreements.