Press "Enter" to skip to content

Scaling SAP Process Orchestration


In case you need some options how to define and scale your PO landscape…

High-Available (HA) Setup: 

  • It is recommended to run the SCS (Central Message Server, Enqueue Server, Gateway) and Database components in a cluster (e.g. Oracle RAC).
  • In addition, 2 (or more) Application Servers should be used with at least 2 Server Nodes.
  • Also a Web Dispatcher is needed for load-balancing between the two Application Servers.
  • In total, you must not exceed 10 server nodes in total per system across all application servers

Simple  Setup:

  • Combined Central Services Instance (SCS), Database (DB) and one Application Server (PAS) with at least 2 Server Nodes.
  • No Web Dispatcher Necessary

There are also installation options available in between those two extremes: A Standard System with several (local or separate) Application Servers or even a Distributed System (each component can be installed on a separate host).

Usage of Decentral Adapter Engines:

  • Full SAP NetWeaver Java Server as a separate SID with its own database
  • Same scaling options

For detailed installation recommendations (Standard vs. Distributed vs. High-Available System) please check the appropriate installation guides for your environment (OS/DB) using the SAP NetWeaver Guide Finder.

To decide which approach is the best, you have consider the following two areas:

Maximize Transparency through Centralization regarding

  • Design Governance (ESR)
  • Configuration (DIR)
  • Monitoring (PIMON)

Maximize Independency through Decentralization regarding

  • Runtime
  • Downtime Management

I end up recommending a “powerful” (high-available) central PO installation (as all BPM processes and tasks run exclusively here) with at least one decentral adapter engine to separate runtime dependencies and the option to switch all (Non-BPM) channels to one or the other when a downtime is planned.

To allow this Adapter Engine Switch, I recommend using an additional Web Dispatcher which exclusively points to one adapter engine, so the sender does not have to change the URL.

As you can see, only the Runtime (Adapter Engine) is running on the Decentral AE.

  • All developments and configurations are managed centrally from PO and will be replicated to the local mapping runtime and CPA caches.
  • All Security-related elements (certificates) are managed locally in each NWA (Keystore)
  • All Destinations are managed locally in each NWA
  • Users are ideally managed centrally (from Active Directory/LDAP or from an ABAP System such as a dedicated SolMan client)
Print Friendly, PDF & Email