1.3    Architectural Overview and Positioning

This section explains how the different components of SAP PO fit together. We’ll also take a look at the use of each of the components and justify why each component’s positioning represents a good approach and a robust architecture. Finally, we’ll discuss some of the advantages and disadvantages of using such an architectural approach.

1.3.1    SAP Process Orchestration Positioning

As depicted in Figure 1.8, SAP PO, which includes AEX, SAP BPM, and SAP BRM, is placed between the service-enabled applications (backend applications), the UI (presentation layer), and the external (cloud, business-to-business [B2B] Electronic Data Interchange [EDI], etc.) applications.

The backend applications can be any on-premise SAP or legacy applications that provide a particular business content and functionality to an organization. Most SAP backend applications come equipped with standard enterprise services provided by SAP. Whether delivered with standard services or not, the applications can be connected to via a diverse range of connectivity adapters provided by SAP PI.

The AEX layer links all of the message traffic and exchange of data between applications. It plays the role of ESB and exposes the backend application’s functionalities as services or interfaces. It can also leverage enterprise services provided by SAP in the backend applications. The exposed services are presented in a format that suits widely accepted standards and protocols, such as Simple Object Access Protocol (SOAP), JMS, and many others.

The developed services can be maintained, discovered, and managed in the Enterprise Services Repository. The services can be published, searched, and discovered by using the equivalent of the yellow pages for services: the Service Registry.

Figure 1.8    Positioning of SAP PO (SAP Composition Environment and SAP PI)

After all required services have been made available via the SAP PI layer, you can position the SAP Composition Environment layer on top. The composition layer encapsulates products such as SAP CAF, SAP BRM, and SAP BPM. It’s now possible to build different composite services and applications based on individual services exposed by the process integration layer (supported by SAP PI or AEX). This approach lets the composition layer leverage and reuse the services already provided by SAP PI and therefore saves on costs. This approach also lets the composition layer focus on the composition and bundling of services together to provide new functionalities and leaves integration-related work to SAP PI.

SAP PO also supports B2B integration scenarios, whether that involves traditional EDI, Secure File Transfer Protocol (SFTP), or modern cloud-based integration, multiple B2B protocols are supported. However, be aware that some specific platform prerequisites might apply to enable the B2B add-on functionality in SAP PO.

Furthermore, since SAP NetWeaver 7.5, you can also reuse SAP Cloud Platform Integration (formerly known as SAP HANA Cloud Integration) content in SAP PO. This so-called hybrid scenario, that is, on premise to cloud and vice versa, support different types of business processes as part of SAP cloud products such as SAP S/4HANA Cloud, SAP Hybris Cloud for Customer, SAP SuccessFactors, and many more. For a complete overview of which prepackaged content SAP is currently offering, you can go the SAP Marketplace and look for the hybrid scenarios overview page via this link: http://service.sap.com/hybrid.

The presentation layer, which includes all technologies the end user directly interacts with, is placed above the composition environment. Technologies such as SAP Enterprise Portal, mobile apps, and desktop applications have the flexibility to directly interact with a business process via the composition environment or alternatively to communicate with the integration layer if no processes or composite services are involved in the scenario.

1.3.2    SAP NetWeaver Application Server for Java: System Architecture

SAP PO is fully built on top of the SAP NetWeaver Application Server for Java (SAP NetWeaver AS Java), so it’s essential to have a high-level understanding of the SAP NetWeaver AS Java architecture to better understand SAP PO’s foundation and capabilities.

SAP NetWeaver AS Java is at the core of the SAP NetWeaver technology. It facilitates functionalities spanning from deployment to running Java applications. Depending on your system requirements, you might consider using an SAP NetWeaver AS Java cluster to enable more scalability and reliability.

As depicted in Figure 1.9, a simple SAP NetWeaver AS Java installation is made up of three main components:

• A Java instance
• An SAP Central Services (SCS) instance
• A database

You can also extend the cluster by adding more Java instances.

Figure 1.9    Composition of a Simple SAP NetWeaver AS Java Cluster Installation

In the next sections, we explain the roles of each component.

Java Instance

The Java instance is made up of two main components. First, the Internet Communication Manager (ICM) is used to regulate the communication between SAP NetWeaver AS Java and any outside application request. Most common requests from outside are made using HTTP, HTTPS, and Simple Mail Transfer Protocol (SMTP). The ICM listens to a specific URL and port number combination through which the requests are made. After receiving the requests, the ICM transfers or forwards them to the relevant internal applications and server processes. The ICM plays the roles of load dispatcher and balancer. It’s important to mention that the ICM is responsible for receiving requests and for sending them to the outside world.

Second, the server processes receive all the requests that are forwarded by the ICM and are responsible for the actual execution of these requests with the Java EE applications. Depending on your landscape requirements and the expected load, more server processes can be added. The server processes are multithreaded (i.e., have multiple threads) and are therefore capable of handling a huge number of requests concurrently.

SAP Central Services Instance

The SAP Central Services (SCS) instance plays a critical role and forms the basis and foundation for all synchronizations and communications that take place in your SAP NetWeaver AS Java clustered installation.

The SCS instance is made up of the following components:

• Message server
  The message server maintains availability information about all the server processes of the entire cluster and then provides this availability information to the ICM to help it dispatch the incoming request to the correct (available) server process. As shown in Figure 1.10, another responsibility of the message server is to facilitate the exchange of messages and communication between the different server processes in your SAP NetWeaver AS Java cluster.

• Enqueue server
  This component is responsible for regulating and managing the lock table. All requests to lock resources are forwarded to the enqueue server, which determines whether or not there is already a lock of the resource. If the resource isn’t locked, then a lock is placed, and a new record is inserted in the lock table. If the resource has an existing lock (called lock collision), then the lock request is rejected.
  

  Figure 1.10    Message Server Enabling the Communication and Exchange of Messages between the Different Java Server Processes in the Cluster

Database

The central database is responsible for storing and persisting all the application data and the data related to the configuration of the system.

Now that you’re familiar with the architecture of SAP NetWeaver AS Java, let’s look at the layers that are included in such a system.

1.3.3    SAP NetWeaver AS Java System Logical Layers

The SAP NetWeaver AS Java engine is made up of three main components and layers (see Figure 1.11):

• Java enterprise runtime
• SAP NetWeaver AS Java system components or services
• Applications

Figure 1.11    Main Layers and Components of the SAP NetWeaver AS Java System

These three components depend on each other. They have a dependency hierarchy from the bottom component to the next higher one; the lower components need to be available before the higher ones can be used. This implies that when your SAP NetWeaver AS Java server s starting up, the Java enterprise runtime is started first. Next, the SAP NetWeaver AS Java system components and services are started. Finally, all applications deployed on the server can be started as well.

In the next sections, we’ll explore the functionalities and roles of each of the three components.

Java Enterprise Runtime

The runtime provides the core functionalities for the running of all applications. It contains components that have the main task of managing the internal resources of the server. The following are some of the components and their roles:

• Session Manager
  Manages the sessions on the server and ensures sessions fail over. This component ensures that the data saved in a session isn’t lost if the application server becomes unreachable.
• Application Thread Manager
  Manages all threads used on the server to process requests on deployed and running applications. This component balances resource allocation for all incoming application requests and prevents a system overload.
• Cache Manager
  Manages all caching functionalities used by the different components in SAP NetWeaver AS Java.
• Locking Manager
  Manages all locking and unlocking of resources based on the enqueue server.
• Log Manager
  Manages the foundation of the logging mechanism in the server. This component is responsible for all logging activities in the application server.
• Cluster Manager
  Manages the communication and exchange of messages between the different cluster nodes or elements.
• Database Manager
  Manages the connections to the database.
• Pool Manager
  Used to manage the pool of existing connections. This component explicitly creates and manages connection pools. All unused connections are cleaned up.
• Class Loader Manager
  Can be accessed in the SAP NetWeaver Administrator. This component enables the management of loading references between the different Java classes or applications.
• Configuration Manager
  All configuration performed in any components or applications of the application server needs to be persisted and saved in the database. This component provides the required support to save and retrieve this configuration data.
• Licensing Manager
  Provides features to manage all SAP license- and certificate-related data in a uniform and central manner.

SAP NetWeaver AS Java: System Components

These components can be seen as services running on the server. Each of these components or services performs a specific task, and together they facilitate the communication and collaboration between the SAP NetWeaver foundation and all of the applications running on top of it. These components can be categorized as follows:

• Facades
  Provide a means by which an external application can directly communicate to the application server using a Java API.
• Interfaces
  Provide ways for the different components to communicate with each other.
• Libraries
  Provide a set of loadable libraries that Java applications can call during runtime.
• Services
  Access and expose the runtime functionality with the use of the framework API.

Applications

This layer comprises different types of Java-based applications—from standard Java applications delivered by SAP to custom Java applications written by you as an SAP NetWeaver developer.

Applications residing in this layer can leverage the different functionalities provided by the SAP NetWeaver AS Java system components layer via APIs.

Applications can be generally categorized into the following different groups:

• A standalone web module (WAR files)
• A standalone Enterprise Java Bean (EJB) module (JAR files)
• A standalone resource adapter module (RAR files)
• SAP NetWeaver AS Java system components (services, libraries, and interfaces)