The process orchestration layer

The process orchestration layer

The process orchestration layer contains the key mechanisms that create the flexibility that ESA must deliver to succeed. Enterprise services are the reusable building blocks built on top of business objects. Process orchestration is the simpler way that these building blocks are combined to solve problems.

The word orchestration has many different meanings in many contexts. Some people prefer the word choreography, which is sometimes used to mean the same thing. Orchestration became associated with SOA in the past few years because of the idea of web services orchestration, which was an attempt to create a language that could be used to combine web services to automate processes. Eventually, different standards efforts championed by different vendors were combined into the Business Process Execution Language (BPEL) standard. When many people speak of orchestration, they are referring to using BPEL to orchestrate the behavior of web services. But this is only one form of process orchestration as we use the term in this book.

What is process orchestration?

Since programming began, applications have controlled process flow. That is not what we mean by orchestration. We use the term to mean a form of modeling in which a simple set of abstractions is combined repeatedly to help solve a problem. The job of orchestration is to replace coding in Java and ABAP with modeling so that process orchestration is easier and more flexible, and can be performed by more people. As modeling tools have improved, more people have begun modeling. Process orchestration is one form of modeling. Modeling is also used heavily to create UIs and to manage system landscapes among other applications.

For this book, we will expand the notion of orchestration to include not only the high-level orchestration of enterprise services, but also the orchestration of any process using a simplified method, whether it is a guided procedure that is controlling the flow of work through a UI, or a workflow modeling technique in SAP NetWeaver AS. By "simplified method," we mean a mechanism that is much easier to use than Java or ABAP coding but that still has the power to allow a process to be constructed out of building blocks. The building blocks for BPEL are web services; in ESA, they are enterprise services. For guided procedures, the building blocks are callable objects of various sorts, including enterprise services, Adobe Interactive forms, and UI elements such as iViews. For workflow mechanisms in SAP NetWeaver AS, they are Java or ABAP objects. For process components, the building blocks are collections of enterprise services and business objects working together to solve a problem.

No matter what the building blocks are, the orchestration layer has a similar job. It must carry out the following tasks:

  • Send and receive messages to and from the building blocks.

  • Manage a process's flow of control as it moves from one building block to another. This includes deciding how the flow of control should proceed based on information provided from the building blocks.

  • Keep track of any information needed in the context of the orchestration. For some orchestrations, this may mean maintaining the state of a long-running transaction, or it may mean keeping a collection of documents related to a guided procedure.

  • Report on the state of the orchestration to other interested parties or to programs that are monitoring the process.

These tasks take on different forms based on the orchestration being implemented.

Why is process orchestration important in ESA?

Without process orchestration, the logic that controls processes must be coded in Java or ABAP. This makes the orchestration process difficult and complex, which shrinks the pool of people who can design and implement processes. Orchestration mechanisms simplify the process of defining an orchestration, usually through some model-driven development technique, which not only allows orchestrations to be created quickly but also allows them to be changed quickly.

Process orchestration also serves as a bridge between IT and business and as a form of documentation. Instead of writing a lengthy requirements document, process orchestration mechanisms can allow business analysts to describe, in an executable form, the automation of processes. The processes described through orchestration mechanisms serve as a highly accurate form of documentation, especially when the orchestration mechanism allows annotations to describe services that may be missing and are needed to complete the automation of a process.

What forms of process orchestration will be used in ESA?

SAP and many other vendors have been pursuing orchestration and a model-driven definition of business processes for many years. When XML arose as a standard and Enterprise Application Integration (EAI) systems were created, Business Process Management systems allowed orchestration based on reusable XML messages. Workflow modeling has existed for years in both ABAP and Java. What has changed in ESA is that now the building blocks for all levels of orchestration have a common elemententerprise servicesand many different contexts for applying orchestration have been well understood through trial and error. The different forms of process orchestration in ESA include all of the following:

Frontend process orchestration

Frontend process orchestration is aimed at the UI and will play a big role in the development of composite applications. Frontend processes are conversational and user-centric. Certain types of processes appear repeatedly in UIs, and SAP has created orchestration mechanisms to allow them to be easily implemented. Probably the most important new mechanism is guided procedures, a general-purpose way of walking a user through a series of steps that may be occurring in many different applications. Guided procedures can easily start a user in a portal UI, invoke an interactive form to gather more information, and then use that information to use enterprise services to perform other work, and so on. Standard UI mechanisms show the user's progress through the process steps. Guided procedures can be built through tools that are part of the SAP CAF. SAP NetWeaver Visual Composer will eventually be able to construct guided procedures.

Backend process orchestration

Backend process orchestration is focused on high-volume flows of transactions that do not require a lot of manual processing. This sort of work includes long-running transactions. Backend process orchestration is frequently associated with EDAs and processes that are automated with a management-by-exception model. The CCBPM mechanism of SAP NetWeaver XI is SAP NetWeaver's primary backend process orchestration mechanism. CCBPM can route, map, and process messages sent at high volumes, keeping track of the state of many different transactions that may take place over weeks or months. Backend process orchestration is not focused on UIs primarily, although some UIs are always part of backend process orchestration to help monitor the process underway or to allow exceptions to be handled.

Service composition

Service composition has an element of process orchestration to it. Sometimes this sort of process orchestration takes place in Java and ABAP code, but SAP CAF has a service modeling environment that contains a simple mechanism to model the creation of a new service composed from other services.


Workflow automation generally refers to the automation of a set of steps that occur within one application. In the context of ESA, workflows will still be used in service implementations and business objects to help execute a process that moves through a well-defined series of steps. Configurable workflow mechanisms exist for both Java and ABAP, and these mechanisms are powerful enough to invoke functions and enterprise services outside of an application. Primarily, however, workflow mechanisms are focused on automating processes inside a single application.

Process component modeling

Process component modeling helps describe the high-level structure of business processes. In ESA, process components are large building blocks created out of orchestrated groups of enterprise services and business objects. If the other forms of process orchestration reduce the gap between business and IT by making processes easier to model, then process component modeling closes an even larger gap between how the processes are related to business and how enterprise software implements them.

What are the limits of process orchestration?

Like any other modeling-oriented technique, process orchestration provides simplicity, but in doing so, it sacrifices some flexibility. While most process orchestration mechanisms provide some flow control mechanism, frequently this is simpler and less powerful than what is possible in ABAP or Java code. Certain orchestration problems will always be too thorny to be represented in one orchestration mechanism or another. The goal of orchestration mechanisms is not to handle every case possible, but to handle most cases in a simpler manner that does the job and lets more people participate, ending development bottlenecks. In most cases when orchestration mechanisms fail, it is possible to create a service that can do the job that is outside the scope of the orchestration mechanism.

How does process component modeling work?

Process component modeling is the newest form of orchestration, and it plays such a fundamental role in closing the gap between business and IT that it deserves a longer explanation. The other process orchestration mechanisms are primarily intended to accelerate development, but process component modeling actually spans the space between the high-level abstract descriptions of businesses and processes that use business scenarios and solution maps, and the world of enterprise services, as shown in Figure.

Three levels in process component modeling help bridge this gap:

  • Integration scenario modeling, as shown in Figure, which shows how a group of process components work together

  • Process component modeling, which describes how enterprise services are built on top of business objects to perform the work of a process component

  • Process component interaction modeling, which describes in detail the interaction between two process components that are communicating with each other

The role of process component modeling

ESA integration scenario modeling

Figure shows process component modeling and process component interaction modeling.

Process component modeling is so important because it attacks at a fundamental level the lack of structure and abstraction that led to the monolithic enterprise applications of the past. Process component modeling provides a tool that allows much of the structure of business that was never formally defined, to be captured and to be made clear and explicit. This sort of transparency has many different benefits, such as making it easier to identify gaps in end-to-end processes, making existing patterns in processes visible, helping to establish standards for solving the same problems in the same way, allowing flexible design based on reusing existing parts, and supporting outside-in development of new functionality based on modeling. Perhaps the largest benefit of this sort of modeling is its role as a communications tool that makes existing functionality clear to all interested parties and provides a tool for managing the growing complexity of business by breaking it down into smaller, more easily understood pieces.

Through process component modeling, the development process becomes much more connected and integrated, and specifications and requirements are communicated through the formal mechanisms of the model rather than through language, which can be less efficient.

ESA process component modeling and process component interaction modeling

 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows