1.2    SAP Process Orchestration Components

To get a better understanding of why SAP PO can be useful, let’s explore SAP PI, SAP BPM, and SAP BRM individually and get into the details of how they can support your organization. This section of the book also presents the positioning of these three components within an SAP landscape.

1.2.1    SAP Process Integration

It’s far too common in our daily lives to encounter situations in which two or more systems need to be connected to exchange data. In the digital world that we live in, a typical organization will require multiple systems to perform its daily business tasks. The organization’s human resource or employee data will be stored in an HR application, whereas financial data will be stored in a financial application. The choices of which software packages, applications, and vendors fit best for the task at hand will vary from organization to organization. However, the different systems in an organization usually need to exchange data and work together to support a particular business process or need.

The systems or applications involved in the exchange of data don’t necessarily need to belong to the same organization or be part of the same network. Two companies doing business together might need to exchange information through their respective applications, which come in all sizes, shapes, and flavors. They also generally don’t speak the same language, and they cover business processes that belong to different industries. They are located in different time zones and continents and don’t have the same security requirements. The list of differences goes on and on. All of these factors increase the complexity and challenge of achieving a seamless integration between all concerned systems.

The next section illustrates two approaches that organizations use to solve these integration challenges. For that purpose, we’ll explore point-to-point integration. We’ll also look at an integration approach using an ESB, such as SAP PI or AEX, and address why such an approach is a better way to tackle your integration challenges.

Point-to-Point Integration

Some organizations take the easy way and choose point-to-point communication, as shown in Figure 1.4. In a point-to-point communication, each communication involves two systems: the source system sends information to or requests information from the target system. There is a dedicated connection line between the two systems involved in the communication, and the systems can therefore be seen as tightly coupled applications.

Point-to-Point Integration: Systems Directly Connected to Each Other

Figure 1.4    Point-to-Point Integration: Systems Directly Connected to Each Other

At first glance, this approach looks simple and fast to implement, especially with fewer applications to connect. However, its disadvantages become visible very quickly as the organization’s integration landscape becomes more complex and larger. The point-to-point approach forms a spider web of application connections, which keeps growing exponentially as more systems are introduced into the landscape.

Each system is aware of the connection and message details of the system on the other side of the exchange. Every time a particular system changes or needs to be replaced, the impact will be felt by all other systems communicating with it. If a vulnerable security connection is discovered in one of the systems, all applications currently connecting with it will need to be changed, adapted, and potentially be unavailable for a long time, all of which results in higher costs of development and maintenance in the long run.

Integration Using an Enterprise Service Bus

To avoid some of the issues resulting from a point-to-point strategy, you can opt instead for a service-oriented architecture (SOA) strategy. SOA is a design pattern that focuses on exposing the functionalities of a business application as services.

These services can be seen as self-contained components that provide a specific functionality, which can be remotely called or invoked. The services are published, and potential consumers of the services can discover them. This approach encourages loose coupling of functionality and therefore enables reusability and cost savings. SOA has been around for a while and is widely used. There is plenty of information published about SOA, so we’ll spare you from the theoretical details in this book. For more information on SOA, refer to www.opengroup.org/standards/soa.

An ESB can enable you to support an SOA in your organization’s ecosystem. This is where SAP PI or AEX enters to save the day (see Figure 1.5).

Note

The terms SAP PI and Advanced Adapter Engine Extended (AEX) are sometimes interchangeably used. These terms are pretty much referring to the same product. The only exception is that SAP PI might include a dual stack (Java and ABAP), whereas AEX is always a single stack (Java only).

Integration Using an ESB: AEX at the Center of All Message Exchanges

Figure 1.5    Integration Using an ESB: AEX at the Center of All Message Exchanges

AEX plays the roles of middleman, courier, and translator. AEX is an ESB, and it takes care of implementing the communication and interaction between the software applications that are interacting and exchanging data. It’s at the heart of your SOA implementation strategy. Figure 1.5 shows how the AEX can intervene and simplify the communications between the different systems. Some of its duties include the following:

The ESB eliminates the need for a point-to-point connection. By having smaller units of functionality exposed as services, you can build composite services; in other words, you can combine or bundle many smaller services into a new bigger service or composite application.

For the purposes of this book, whenever we refer to SAP PI, we mean the Java-only stack (or AEX), unless specifically stated otherwise, because only the Java stack (also called AEX) is used in SAP PO.

1.2.2    Business Process Management

To run a streamlined business, a typical organization has a clearly defined business process that describes the actions and steps to be performed to complete a particular task. You probably encounter these business processes every day. For example, when a new employee comes into an organization, he needs to send his details to the HR department to complete the hiring business process. Or when an employee needs to order a new computer, the employee’s manager might need to approve the ordering of the computer as part of the process that has been defined within the organization. An organization could decide to automate and support such a process by using a business process engine (BPE). Figure 1.6 shows how a business process can be managed in the BPE.

The SAP BPM toolset provides multiple benefits in this arena, including the following:

1.2.3    Business Rules Management

The business world is constantly changing. These changes can be internally influenced by an organization or externally influenced (e.g., a new employment law to a change in consumer behavior).

A typical organization wants to quickly adapt to those changes in the business environment to keep its competitive advantage. This adaptation might result in a change of existing business rules. Businesses can design and define their decisions and business rules in a business rules management (BRM) system. Given that these rules are subject to constant changes, it makes sense to maintain and keep them separate from the actual business applications. This externalization of business rules creates the flexibility to change such rules without having to change the business applications.

As an example, consider an HR application. This application is used to maintain all employees’ details, including their position in the organizational structure. Let’s consider a hypothetical business rule within the organization which stipulates that if an employee has a minimum of 10 colleagues reporting to him, then he needs to be promoted to manager. Such a requirement is best maintained in a business rule, rather than being hard-coded in the HR application itself. Having the rule outside of the HR application will enable other applications to reuse the application. In addition, the rule can be adapted quickly without needing to change the actual HR application. See Figure 1.7 for an example of this rule’s possible implementation in SAP BRM.

Business Rule Flow Based on the Rules Modeling Tool of SAP BRM

Figure 1.7    Business Rule Flow Based on the Rules Modeling Tool of SAP BRM

Here, SAP BRM brings added value. Some of the benefits SAP BRM offers include the following: