When you clicked on this blog I’m sure you heard already a lot about Software as a Service (SaaS) and SAP’s On Demand Solutions so I won’t give you a long introduction into those terms. I’m generally interested in infrastructure topics, with infrastructure loosely defined as the technology layers below SAP platforms and typically provided by SAP’s technology partners. Therefore, I’d like to describe in this blog what SaaS adoption means to the Infrastructure of SAP customers.
At first sight this might appear odd: The whole idea of SaaS is that a customer does not need to worry about any sort of hardware and software because it is all bundled together as a SaaS solution. I’d say this is mostly true at the first stage of SaaS adoption by a customer when each SaaS application provides enough value to be adopted as an island solution in itself. Island means that such a solution is not integrated with any other solution. There are just end-users connecting via the Internet to a SaaS island application. The only infrastructure needed on the customer side is technical Internet connectivity, which by now pretty much any company has already built-up long time ago. The only infrastructure concern a customer might have is to add additional Internet connectivity capacity to support increased SaaS usage by their employees.
For SAP customers the second stage of SaaS adoption is to integrate the SAP On Demand (OD) solution islands with their On Premise (OP) SAP Business Suite solutions to gain even more value out of both, the OD and the OP side. There are an increasing number of use cases for building out “hybrid” On Demand – On Premise applications. The blog “What is a cloud and on-premise hybrid solution by SAP?”gives a good introduction into the business drivers for such solutions and the technologies provided by SAP to build such solutions. If you are visiting TechEd 2012 conferences TEC102 SAP Cloud Strategy & Road Map, by Sven Denecken gives you a great overview, too.
The implementation of hybrid solutions might follow three basic steps:
- Determine business drivers for an OD/OP integration and make an implementation decision.
- Design and build the “application connectivity”.
- Design and build the “technical connectivity”.
Application connectivity and technical connectivity are 2 distinct tasks for OD/OP solution integration. The application connectivity is concerned with application APIs and in some cases solution specific content for SAP integration components like SAP PI and SAP Data Services (DS). A customer would need to decide whether to leverage maybe pre-existing On Premise integration components or to use their respective SAP On Demand integration solutions. Both are possible in principle. Typical for the integration components is that they are general use “containers” for integration “content” which is specific for each particular hybrid business process running across your OD/OP solutions. Content refers to the particular transformation and message handling rules for a usage scenario, which have to be performed by the integration components. Setting up application connectivity at the OP side is a task for SAP application IT departments of SAP customers.
Technical connectivity is about building and configuring the infrastructure, in particular the network, for providing qualities such as reliability, security and good performance over the wide area network (WAN) Internet between the OD and OP datacenters. This task is typically performed by the network IT group at the On Premise datacenter of an SAP customer. On the On Demand side technical connectivity is provided by SAP and is part of the On Demand solution offering.
Fig.1 : Application connectivity can be provided by SAP PI OD and SAP DS OD in conjunction with an SAP On-Premise agent. The technical network connectivity consists out of network infrastructure components in the DMZ of OD and OP datacenter sites.
Here a few network connectivity guidelines I’d like to recommend:
- NC-1: No direct network connection from public networks to OP SAP applications shall be allowed.
- NC-2: All business application network traffic transmitted via Wide Area Networks shall be encrypted.
The background of the 1stguidelines is that a customer wants to keep control over who can access or post what information in their On Premise backend systems. Therefore, it is out of question to just connect an application server network port to the Internet, a control needs to be put in between the backend application and the Internet. In the simplest case this would be a so called proxy instance sandwiched in between additional firewalls as shown in Fig. 2. The firewalls control lower level network protocol access and guard and define the borders of different network security zones. The network zones between the Internet facing firewall and the other most inner application network security zone is commonly called De-Militarized Zone or DMZ. The proxy inside the DMZ further restricts communications to only one Internet URL which is then mapped to an internal application server port. Thereby, internal application server IP and port addresses are hidden from the outside world. Proxies should be used for either case:
- The On Premise application making a call to the On Demand application. For such outbound requests from the On Premise side so called forward proxies are used.
- If the On demand application has to send a request to the customer’s On Premise system the customer would need to provide a public URL for accessing the backend application by the On Demand application and would link traffic to such URL to a so called reverse proxy in their DMZ. The reverse proxy would then forward traffic to the backend application server and maybe perform a number of other network operations for security and other qualities.
Fig. 2: A proxy instance in the DMZ allows controlled and save guarded access from the Internet to customers On Premise backend systems.
The simple traffic routing function of proxies is just the minimum service required for technical OP/OD connectivity and is part of a set of wider functions provided by so called application delivery controllers or ADCs. ADCs provide proxy functions but might also include encryption/decryption, load balancing, bandwidth capacity managing and other network services. A collection of reference information about some network technologies can be found at http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/7447
The 2ndnetwork connectivity rule takes into account that your business data is confidential and therefore needs to be encrypted when sent over the Internet. Encryption/decryption can be provided by the SAP application server or be off-loaded to most proxies or better ADCs, which provide that capability themselves. Application groups should consult with their network and security colleagues to decide if encryption/decryption should be done in the application server or by an ADC in the DMZ or by even both.
As for choosing a proxy or ADC check out SAP’s listing of technology partners with SAP certified products at
http://www.sap.com/partners/directories/searchsolution.epx. With the search terms ESOA-AW-PO, ESOA-AW-RA and ESOA-AW-SEC you can find DMZ network products and many of those include the needed proxy features and more. A second option is to consider the SAP NetWeaver WebDispatcher product.
To narrow down these choices even more you might try the following approach:
- When you need to design your technical connectivity implementation contact your network group and ask what type of proxy solution they might have already implemented in the On Premise datacenter DMZ.
- Check if that product is certified by SAP. If so, go ahead and use it.
- If no suitable proxy solution is deployed already, consider SAP WebDispatcher as easily available solution already included in customer’s SAP NetWeaver license.
Re-using existing proxy technologies of your network group is usually the easiest and most cost effective way to go. It saves you a lot of time for discussing the introduction of new technologies into your DMZ. Special purpose build network hardware appliance can usually handle dozens or even hundreds of proxy instances so new hardware for added capacity is usually not required. Adding one more proxy would be a simple configuration task of existing equipment. However, in case that no such solution is available you’d need either to implement it or do a software installation and configuration of SAP NetWeaver WebDispatcher on a small server in the DMZ.
For the configuration of the proxy you’d need to give your network group some information about internal application server IP addresses, SAP’s OnDemand solution URLs and they’d need to understand how to handle security certificates for the traffic encryption/decryption configuration. SAP can’t possibly describe such configuration procedures for all proxy technologies available to customers. Rather we decided to describe the process using SAP WebDispatcher, which is the SAP proxy reference implementation. If you use other proxy technologies your network group simply needs to do the equivalent configuration steps on the proxy products they prefer. The SAP WebDispatcher reference implementation is described in detail in https://service.sap.com/~sapidb/011000358700000894852012E/SAP_OD_TCG_FINAL_V12.pdf
(A customer or partner SAP Service Marketplace user account is required to retrieve this document.)
I’ll be visiting SAP TechEd 2012 in Las Vegas and you could meet me during my expert session “Connecting SAP Applications” on Tuesday 10/16th/2012 at 2pm in Lounge 7 Hall C to discuss network technology for SAP solutions further.
8 Comments