As we have discussed in the previous chapter, itineraries are the conceptual definition of the different services and processes that a message should go through to complete a business process within an ESB. Itinerary services are one of the main peculiarities that define how an ESB works. They are the glue that keep many of rest of the features of an ESB together.
In this chapter, we will have a deeper insight into the following:
- What is an itinerary
- What are the itinerary services and their different types
- How to create our own custom itinerary services
- How we stick together our itinerary services within an itinerary
- Deploy and use your itineraries within BizTalk
In many aspects of life, complex problems are better solved by breaking down the problem into well-defined smaller problems and solving those smaller problems in a given order. And, even the solution to complex problems that we solved following that decomposition process in the past, might not remain immutable over time.
This is the basic rationale that stands behind the concept of an itinerary.
Any business process can usually be broken down into a set of clearly defined subprocesses. Those subprocesses are usually mapped to specific services or capabilities within an organization (for example, the approval of a specific offer within a purchase order is undertaken by some specific customer care team, the arrangement of the goods shipment is scheduled by the automated delivery system, and so on). All those services have clearly defined duties, and they can carry out their processing in a more or less autonomous/decoupled way. Doesn't it start smelling like SOA?
An ESB itinerary is just the logical representation of how those subprocesses are composed to fulfill the overall business process. The itinerary doesn´t define how each of those processes should implement their duty, but just how the information moves from one subprocess to the other.
Each of those subprocesses will be carried out by what we will call itinerary services. An itinerary service is an autonomous and clearly defined piece of functionality that receives some information or message, does some processing over that information, and in most cases, produces an outcome of that processing.
The autonomous nature of the itinerary services makes it easy to compose different services into an itinerary, and allows them to evolve without having a significant impact on any other services that might be part of that composition.
In the following figure, we can see what could be the three examples of an itinerary that define the overall purchase order management process within an organization, where each of the squares below represent an itinerary service that carries out part of the process:
Our initial business process is rather simple, where we have three subprocesses or itinerary services in charge of doing some processing over the specific purchase order.
Over time, as our organization evolves, this business process could evolve and include further subprocesses within the overall process:
- After detecting that some orders where later withdrawn because the client was not able to pay for them, we introduce Check Client Credit History in our process.
- As we want to give a better service to our clients, a new customer care process is defined. So after each purchase order, the client is automatically contacted to provide some feedback about our organization.
- Even an existing subprocess might just change instead of being added or removed from the itinerary. We could just engage a new courier services company to deliver our orders.
Thanks to the itinerary-based design of these processes, our business processes can evolve with minimal impact on the rest of the subprocesses involved.
Before we can jump in and start creating itineraries, we must first learn what they are composed of, and how to create them using the tools provided by the BizTalk ESB Toolkit. The following section will provide us with this knowledge.