Expose SAP legacy middleware securely with Azure PaaS
Enabling internal systems and external partners to interact with SAP back ends is a common requirement. Existing SAP landscapes often rely on the legacy middleware SAP Process Orchestration (PO) or Process Integration (PI) for their integration and transformation needs. For simplicity, this article uses the term SAP Process Orchestration to refer to both offerings.
This article describes configuration options on Azure, with emphasis on internet-facing implementations.
Note
SAP mentions SAP Integration Suite--specifically, SAP Cloud Integration--running on Business Technology Platform (BTP) as the successor for SAP PO and PI. Both the BTP platform and the services are available on Azure. For more information, see SAP Discovery Center. For more info about the maintenance support timeline for the legacy components, see SAP OSS note 1648480.
Overview
Existing implementations based on SAP middleware have often relied on SAP's proprietary dispatching technology called SAP Web Dispatcher. This technology operates on layer 7 of the OSI model. It acts as a reverse proxy and addresses load-balancing needs for downstream SAP application workloads like SAP Enterprise Resource Planning (ERP), SAP Gateway, or SAP Process Orchestration.
Dispatching approaches include traditional reverse proxies like Apache, platform as a service (PaaS) options like Azure Load Balancer, and the opinionated SAP Web Dispatcher. The overall concepts described in this article apply to the options mentioned. For guidance on using non-SAP load balancers, see SAP's wiki.
Note
All described setups in this article assume a hub-and-spoke network topology, where shared services are deployed into the hub. Based on the criticality of SAP, you might need even more isolation. For more information, see the SAP design guide for perimeter networks.
Primary Azure services
Azure Application Gateway handles public internet-based and internal private HTTP routing, along with encrypted tunneling across Azure subscriptions. Examples include security and autoscaling.
Azure Application Gateway is focused on exposing web applications, so it offers a web application firewall (WAF). Workloads in other virtual networks that will communicate with SAP through Azure Application Gateway can be connected via private links, even across tenants.
Azure Firewall handles public internet-based and internal private routing for traffic types on layers 4 to 7 of the OSI model. It offers filtering and threat intelligence that feed directly from Microsoft Security.
Azure API Management handles public internet-based and internal private routing specifically for APIs. It offers request throttling, usage quota and limits, governance features like policies, and API keys to break down services per client.
Azure VPN Gateway and Azure ExpressRoute serve as entry points to on-premises networks. They're abbreviated in the diagrams as VPN and XR.
Setup considerations
Integration architecture needs differ, depending on the interface that an organization uses. SAP-proprietary technologies like Intermediate Document (IDoc) framework, Business Application Programming Interface (BAPI), transactional Remote Function Calls (tRFCs), or plain RFCs require a specific runtime environment. They operate on layers 4 to 7 of the OSI model, unlike modern APIs that typically rely on HTP-based communication (layer 7 of the OSI model). Because of that, the interfaces can't be treated the same way.
This article focuses on modern APIs and HTTP, including integration scenarios like Applicability Statement 2 (AS2). File Transfer Protocol (FTP) serves as an example to handle non-HTTP integration needs. For more information about Microsoft load-balancing solutions, see Load-balancing options.
Note
SAP publishes dedicated connectors for its proprietary interfaces. Check SAP's documentation for Java and .NET, for example. They're supported by Microsoft gateways too. Be aware that IDocs can also be posted via HTTP.
Security concerns require the usage of firewalls for lower-level protocols and WAFs to address HTTP-based traffic with Transport Layer Security (TLS). To be effective, TLS sessions need to be terminated at the WAF level. To support zero-trust approaches, we recommend that you re-encrypt again afterward to provide end-to-encryption.
Integration protocols such as AS2 can raise alerts by using standard WAF rules. We recommend using the Application Gateway WAF triage workbook to identify and better understand why the rule is triggered, so you can remediate effectively and securely. Open Web Application Security Project (OWASP) provides the standard rules. For a detailed video session on this topic with emphasis on SAP Fiori exposure, see the SAP on Azure webcast.
You can further enhance security by using mutual TLS (mTLS), which is also called mutual authentication. Unlike normal TLS, it verifies the client identity.
Note
Virtual machine (VM) pools require a load balancer. For better readability, the diagrams in this article don't show a load balancer.
Note
If you don't need SAP-specific balancing features that SAP Web Dispatcher provides, you can replace them with Azure Load Balancer. This replacement gives the benefit of a managed PaaS offering instead of an infrastructure as a service (IaaS) setup.
Scenario: Inbound HTTP connectivity focused
SAP Web Dispatcher doesn't offer a WAF. Because of that, we recommend Azure Application Gateway for a more secure setup. SAP Web Dispatcher and Process Orchestration remain in charge to help protect the SAP back end from request overload with sizing guidance and concurrent request limits. No throttling capability is available in the SAP workloads.
You can avoid unintentional access through access control lists on SAP Web Dispatcher.
One of the scenarios for SAP Process Orchestration communication is inbound flow. Traffic might originate from on-premises, external apps or users, or an internal system. The following example focuses on HTTPS.
Scenario: Outbound HTTP/FTP connectivity focused
For the reverse communication direction, SAP Process Orchestration can use virtual network routing to reach on-premises workloads or internet-based targets via the internet breakout. Azure Application Gateway acts as a reverse proxy in such scenarios. For non-HTTP communication, consider adding Azure Firewall. For more information, see Scenario: File based and Comparison of Gateway components later in this article.
The following outbound scenario shows two possible methods. One uses HTTPS via Azure Application Gateway calling a web service (for example, SOAP adapter). The other uses FTP over SSH (SFTP) via Azure Firewall transferring files to a business partner's SFTP server.
Scenario: API Management focused
Compared to the scenarios for inbound and outbound connectivity, the introduction of Azure API Management in internal mode (private IP only and virtual network integration) adds built-in capabilities like:
- Throttling.
- API governance.
- Additional security options like modern authentication flows.
- Microsoft Entra ID integration.
- The opportunity to add SAP APIs to a central API solution across the company.
When you don't need a WAF, you can deploy Azure API Management in external mode by using a public IP address. That deployment simplifies the setup while keeping the throttling and API governance capabilities. Basic protection is implemented for all Azure PaaS offerings.
Scenario: Global reach
Azure Application Gateway is a region-bound service. Compared to the preceding scenarios, Azure Front Door ensures cross-region global routing, including a web application firewall. For details about the differences, see this comparison.
The following diagram condenses SAP Web Dispatcher, SAP Process Orchestration, and the back end into single image for better readability.
Scenario: File-based
Non-HTTP protocols like FTP can't be addressed with Azure API Management, Application Gateway, or Azure Front Door as shown in the preceding scenarios. Instead, the managed Azure Firewall instance or the equivalent network virtual appliance (NVA) takes over the role of securing inbound requests.
Files need to be stored before SAP can process them. We recommend that you use SFTP. Azure Blob Storage supports SFTP natively.
Alternative SFTP options are available in Azure Marketplace if necessary.
The following diagram shows a variation of this scenario with integration targets externally and on-premises. Different types of secure FTP illustrate the communication path.
For insights into Network File System (NFS) file shares as an alternative to Blob Storage, see NFS file shares in Azure Files.
Scenario: SAP RISE specific
SAP RISE deployments are technically identical to the scenarios described earlier, with the exception that SAP itself manages the target SAP workload. The described concepts can be applied here.
The following diagrams show two setups as examples. For more information, see the SAP RISE reference guide.
Important
Contact SAP to ensure that communication ports for your scenario are allowed and opened in NSGs.
HTTP inbound
In the first setup, the customer governs the integration layer, including SAP Process Orchestration and the complete inbound path. Only the final SAP target runs on the RISE subscription. Communication to the RISE-hosted workload is configured through virtual network peering, typically over the hub. A potential integration could be IDocs posted to the SAP ERP web service /sap/bc/idoc_xml by an external party.
This second example shows a setup where SAP RISE runs the whole integration chain, except for the API Management layer.
File outbound
In this scenario, the SAP-managed Process Orchestration instance writes files to the customer-managed file share on Azure or to a workload sitting on-premises. The customer handles the breakout.
Comparison of gateway setups
Note
Performance and cost metrics assume production-grade tiers. For more information, see the Azure pricing calculator. Also see the following articles: Azure Firewall performance, Application Gateway high-traffic support, and Capacity of an Azure API Management instance.
Depending on the integration protocols you're using, you might need multiple components. For more information about the benefits of the various combinations of chaining Azure Application Gateway with Azure Firewall, see Azure Firewall and Application Gateway for virtual networks.
Integration rule of thumb
To determine which integration scenarios described in this article best fit your requirements, evaluate them on a case-by-case basis. Consider enabling the following capabilities:
Request throttling by using API Management
Concurrent request limits on SAP Web Dispatcher
Mutual TLS to verify the client and the receiver
Azure Firewall for non-HTTP integrations
High availability and disaster recovery for VM-based SAP integration workloads
Modern authentication mechanisms like OAuth2, where applicable
A managed key store like Azure Key Vault for all involved credentials, certificates, and keys
Alternatives to SAP Process Orchestration with Azure Integration Services
With the Azure Integration Services portfolio, you can natively address the integration scenarios that SAP Process Orchestration covers. For insights on how to design SAP IFlow patterns through cloud-native means, see this blog series. The connector guide contains more details about AS2 and EDIFACT.
For more information, view the Azure Logic Apps connectors for your desired SAP interfaces.
Next steps
Protect APIs with Application Gateway and API Management
Integrate API Management in an internal virtual network with Application Gateway
Deploy the Application Gateway WAF triage workbook to better understand SAP-related WAF alerts
Understand the Application Gateway WAF for SAP
Understand implications of combining Azure Firewall and Azure Application Gateway