19    Landscape Setup Considerations

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
                                                                                —Antoine de Saint Exupéry

Similar to when you build a new house, there must be a strong foundation to have a sustainable and reliable system landscape. As with many other systems, the usage, availability, and performance requirements of your SAP Process Orchestration (SAP PO) system will change as time goes by. As the organization evolves, new businesses are acquired, and new systems are added; it’s important to set up the SAP PO system in such a way that it can be easily adjusted to new business requirements and needs without causing too many negative effects for the business. Of course, it’s not always possible to avoid such effects, but they should be taken into account when setting up the system for the first time.

In this chapter, we’ll explore different topics that can help you make sure that the foundation of your SAP PO system is well maintained and keeps running smoothly.

19.1    Java System Configuration

An SAP PO system can be installed from scratch, or an existing Java-only installation can be turned into an SAP PO installation by enabling additional usage types for Advanced Adapter Engine Extended (AEX), SAP Business Process Management (SAP BPM), and SAP Business Rules Management (SAP BRM).

If you have an SAP BPM system already running, then you can easily install the additional AEX usage type to obtain an SAP PO installation. When you have AEX running, you can do the same with the additional SAP BPM usage type.

Note

SAP PO always runs in an integrated solution, which means that deployment in more than one system isn’t supported. All three components SAP PO are deployed and activated into one single Java stack.

In the following sections, we’ll look at different aspects of an SAP PO system. These aspects include topics such as hardware sizing, the internal architecture of a Java-only system, the different Java central services, and various parameters to consider when tuning your Java-only system.

19.1.1    Java Sizing and Setup Considerations

The sizing and setup of the Java system architecture depends on several factors. To size the SAP PO system in a proper way, two different sizing methods need to be used. The combined results of these two methods will define the number of required SAP Application Performance Standards (SAPS).

The AEX part of the SAP PO instance can be sized via the SAP Quick Sizer tool, which can be found at http://service.sap.com/quicksizer. The SAP BPM part of the SAP PO instance can be sized using the document found at http://service.sap.com/~sapidb/011000358700000454652010E.

You can opt to implement the Java system as a full redundant and high availability setup. However, such a choice brings high additional costs. It’s important to consider whether there is a good business justification for these costs and which components should be set up in a high availability or redundant manner.

The most important questions to ask when setting up your technical architecture are as follows:

In an SAP landscape, there can be several single points of failure (SPOFs). The following SPOFs are of concern for an SAP PO instance:

Note

Only the SPOFs that directly concern the SAP instance are described in this section. There are of course more SPOFs that can be identified in your entire landscape and architecture. Network, storage, equipment, and even a complete datacenter are just a few other examples that fall outside of your SAP instance.

Single Points of Failure

Figure 19.1    Single Points of Failure

In Figure 19.1, the SPOFs are depicted with a dashed line. To remediate these SPOFs, the following setup measures can be used:

These setups will be explored in the next sections.

High Availability Web Dispatcher Setup

Figure 19.2 shows two web dispatchers. The primary web dispatcher will take care of all the incoming requests. In the case of a system failure, the high availability software will bring up the secondary web dispatcher, which will continue processing the request load.

High Availability Web Dispatcher Setup

Figure 19.2    High Availability Web Dispatcher Setup

Parallel Web Dispatcher Setup

You can set up two web dispatchers in parallel and place a separate load balancer in front of them, as shown in Figure 19.3. Alternatively, you can make use of Domain Name Service (DNS) round-robin load balancing, which means that the DNS will send an equal number of incoming requests to the web dispatchers that run on both hosts so that the load is equally spread across both web dispatcher instances.

Parallel Web Dispatcher Setup

Figure 19.3    Parallel Web Dispatcher Setup

Incoming requests will be processed round-robin style based on one of the web dispatchers. If one of the web dispatchers crashes, then the remaining one takes over. This setup is also convenient when performing maintenance on productive instances. By simply putting one of the web dispatchers out of the load balancing, changes can be executed without interrupting the business. In this case, risk time should be taken into account instead of downtime. Risk time means that for this period of time, the redundancy is lost. The system is completely up and running for the business but without redundancy.

High Availability with Standalone Enqueue

As Figure 19.4 demonstrates, the high availability enqueue server consists of a standalone enqueue server and an enqueue replication server. The enqueue server is a critical component in the SAP landscape because it holds the lock table. Without the possibility to set locks, the system can’t function. The replication of the enqueue runs on another host and contains a replica of the lock table.

High Availability with Standalone Enqueue

Figure 19.4    High Availability with Standalone Enqueue

If the standalone enqueue server fails, then it will be started by the high availability software on the secondary node. The replicated lock table stored on the replication server will be transferred to the newly started enqueue process, and a new lock table will be created from it.

Load Balancing

Load balancing should also be given special attention. As its name suggests, load balancing ensures that the load is equally distributed across the different instances in the landscape. An SAP Java instance can only retrieve HTTP(S) requests that have been sent to its own hostname and port number combination. In a setup in which multiple application servers are being installed (very common in mid-size and large systems), a load balancer therefore should be installed in front of the Java instances. This approach has the following advantages:

When it comes to choosing a type of web dispatcher to use, you can choose between hardware and software load balancers. However, in most cases, it’s sufficient to use the SAP Web Dispatcher.

As Figure 19.5 shows, the SAP Web Dispatcher can also be used as a reverse proxy to be placed in the demilitarized zone (DMZ) in business-to-business (B2B) scenarios. By placing a web dispatcher in the DMZ of your network, you can provide access from your SAP PO system to the outside world in a safe and secure way.

Web Dispatcher Placed in DMZ

Figure 19.5    Web Dispatcher Placed in DMZ

Database High Availability

There are different ways to make the database highly available. A common method involves making use of a standby database or database clustering. Log shipping makes sure that all the changes made in the primary database will be replicated to the standby database. The log shipping process basically applies all database changes to the target standby database. If the primary database fails, then the standby database takes over. Figure 19.6 shows an example of a high availability database.

Note

SAP supports the use of several database platforms. Each database flavor has its own high availability options. Make sure you consult the available SAP and database vendor documentation in relation to the supported high availability options.

High Availability Database

Figure 19.6    High Availability Database

19.1.2    Java System Architecture

Within an SAP Java instance, it’s recommended to have at least two server processes configured. These server processes are most commonly known as nodes. If you have two or more server processes, then SAP provides a built-in redundancy within the Java instance. If a node crashes, then only the processes and active connections running on that particular server node will be terminated. The remaining server node will take over all new requests and activities. Usually, the crashed server node will be automatically restarted by the startup and control framework.

If you only have one server process configured, then all connected sessions and connections will be terminated, and the system won’t be accessible until the node has been restarted. This is obviously an undesirable situation that results in a full system outage.

As Figure 19.7 shows, each server node has its own Java virtual memory. This memory allocation is dedicated for a particular server node and not shared across multiple server nodes.

Java System Architecture

Figure 19.7    Java System Architecture

When sizing the Java instance, make sure that the sum of the memory allocated for the server nodes plus the memory required for the operating system (and optionally also for other running applications or databases) fits with the physical memory of the server. Allocating swap space on the operating system level should be avoided at all costs!

19.1.3    Java Central Services

The Java Central Services are depicted in Figure 19.8, in which the Central Services Server (SCS) contains the message server and the enqueue server process of the Java instance. The message server process is used for load balancing and internal communication. The enqueue server process, on the other hand, takes care of the logical lock table, which is stored in memory. Both processes are vital for the functioning of the Java instance.

Position of the Java Central Services Instance

Figure 19.8    Position of the Java Central Services Instance

19.1.4    Java Parameter Tuning

Depending on the expected scenarios and the number of requests that will be running on the SAP PO system, the system will need to be tuned accordingly to cope with load. There are no golden rules for how to tune a system for that, but there are some parameters within the Java stack that need to be taken into account in the context of sizing and tuning. Some of these parameters will be explored in the next sections.

FCAServerThreadCount

For systems that need to process high volumes of synchronous Simple Object Access Protocol (SOAP) messages or that have a large number of concurrent users, this parameter should be increased. The default value for FCAServerThreadCount is 30, but in high-volume systems, it should be doubled. If this isn’t enough, then the parameter should be further increased. However, it’s wise to use small incremental steps each time.

The FCAServerThreadCount parameter is part of the HTTP provider service of the Java stack and can be changed via configtool. Bear in mind that when changing FCAServerThreadCount, the number of server threads will be affected, so make sure that the number of Java server threads is changed accordingly.

Internet Communication Manager Timeout Values

The first entry point for client requests to the Java instance is the Internet Communication Manager (ICM). The ICM forwards the request to an available Java server node, where the processing takes place. If the request processing takes longer than defined by the timeout parameter, then the request is automatically terminated. It’s therefore important to configure a reasonable timeout value for the ICM parameters.

As its name suggests, the timeout value defines how long it takes before a session times out and the connection is reset. The proctimeout parameter defines the allowed processing time for an HTTP(S) request. This value should not be set very high because it’s preferable that the processing of requests takes place in a reasonable amount of time.

Furthermore, the session timeout should not be set too high because sessions are kept open for the duration of the timeout value and therefore hold resources for this same duration. These resources are no longer usable for other processes. If you require a high timeout value, then it might be better to increase the number of sessions or threads on the ICM.

The ICM parameters can be set in the following way:

icm/server_port_0 = PROT=HTTPS, PORT=443, TIMEOUT=60, PROCTIMEOUT=600

The parameters are as follows:

The ICM parameters need to be set in the instance profile of the Java instance, which can be found in /sapmnt/<SID>/profile.

After changing the values of these parameters, a restart of the Java system is required to activate them.

Garbage Collection Configuration

In most cases, the default garbage collection (preconfigured with the SAP Java installation) is sufficient to match the workload of the Java server tasks. In special cases, the garbage collection algorithm can be adjusted, but only after consulting SAP.

Database Connection Pool Configuration

A Java server process makes use of threads to process requests. For each request (user request or a system request) that enters the system, the server creates a thread. If data needs to be fetched from or written to the database, then a database connection is established. This database connection is taken from the connection pool. When the activity is finished, the database connection is freed and cleared after the expiration time, and the thread becomes available again for new processes.

You need to make sure that the database connection pool is large enough to cope with the demand. If you need to increase the number of threads while tuning your system, then remember to also accordingly adjust the database connection pool.

The database connection pool can be modified by opening the Configtool and navigating to Cluster Data • Template • Instance • Services • DBpool (see Figure 19.9).

Database Connection Pool Settings

Figure 19.9    Database Connection Pool Settings