Getting infrastructure ready for web and mobile access to SAP
Web access to SAP landscapes is a new, or dramatically expanded, requirement in many organisations with the rise of the new SAP Fiori user interface. In my experience of projects to roll out SAP Fiori and Neptune SAPUI5 applications, I’ve found that preparing the existing SAP landscape for web access is often forgotten until problems have arisen.
There is infrastructure configuration work to complete across an IT department before you can use SAP Fiori applications productively. Failing to prepare for it will at best delay the project, and at worst leave security problems or users unable to access their applications smoothly.
Get the Fiori App working in your SAP Landscape
This article is not about the configuration within SAP S/4HANA, SAP ERP or NetWeaver Gateway for making Fiori applications work. My focus is on the external infrastructure required to facilitate secure, authenticated, usable web access to an existing SAP landscape that currently only has SAP GUI users.
If you do need information on the configuration within SAP, some useful resources are:
- the automated configuration tools available from SAP for the NetWeaver Gateway
- my colleague’s article provides a brief overview of the core requirements for a standard Fiori application
- Bjorn’s recent series covers the design and development of a custom SAPUI5 web application for a specific business process
The location of the users affects network access and third-party requirements for proxies or firewalls, and often the user base for Fiori is more mobile than SAP GUI users may have been. The user needs a single URL that will get them into the Fiori application regardless of where they are and how they are connecting.
You need to consider how to authenticate the user. Single Sign-On (SSO) is often required for a good user experience in Fiori applications, and there are cost-free options for SSO available for Fiori so it is a common requirement.
A security device such as an HTTP reverse proxy may be required to provide secure external access with services like authentication and caching. SAP provide their SAP Web Dispatcher for this, and our customers also use a range of third-party solutions including F5 load balancers, Citrix NetScaler, and the open source apache2 mod_proxy.
Run an infrastructure workshop
I like to take our customers through a workshop to consider all of the relevant areas. A workshop is a successful approach because there is so much cooperation needed across the IT department to configure all the required parts and getting everybody together is the best way to establish what needs to be done.
Several meetings and some follow-up work or study is usually required, then the final outcome of the workshop is a technical design and a plan to implement it with all the required detail.
Workshop Agenda Item: Where are the users?
If your user group for your Fiori application is the same as your existing users, and in the same place, you may not have much work to do. If your users are now going to be able to access the applications from mobile browsers or the SAP Fiori Client for mobile, you need to consider how the network will be configured to achieve that securely.
If users will access the applications from outside of your corporate network, you can run SAP’s standard Web Dispatcher reverse proxy, or a range of third-party reverse proxies to provide secure access.
Workshop Agenda Item: How will the users authenticate?
Single Sign-On is often a requirement for Fiori applications, even if it isn’t in place for existing SAP GUI users. External application to the SAP applications can also necessitate a more robust authentication requirement, such as two-factor authentication (2FA).
Single Sign-On can be requirement for a good user experience, particularly on mobile devices where typing a password on a small screen could ruin an otherwise usable app. My recent article on the story of developing a Single Sign-On solution for mobile for one of our customers covers some of the challenges that can be faced in mobile deployments.
Finding the SSO technology available within your organisation and reviewing it for suitability crosses skillsets and is an area to cover off in a workshop. It’s usually possible, and easier, to integrate with that you’ve got already than bring in something specific for SAP.
Workshop Agenda Item: Which link (URL) will the users use?
A pleasant single URL is needed for your users to access the Fiori applications, such as http://sap-fiori.your-organisation.com/.
Connectivity to a typical Fiori application can be complex after the solution is designed to meet all the requirements. You may have some users who connect through proxies whilst some connect directly. You may have some connected through external IP addresses, some internal. Some users may be challenged for two-factor due to the functionality they are accessing, or where they are accessing from.
The URL should be the same in all scenarios for a good user experience. It’s also vital for integration to corporate portals, intranets or anywhere else that has the URL technically configured.
One of my customers described a single hostname resolving to different IPs depending on where the user is resolving it from as “split brain DNS” and I think that’s a good way to describe it. It’s also known as split-horizon DNS.
From the internet the URL might take you through the IP of an external security device with two-factor authentication and proxy to the SAP server, whilst the same URL inside your network might take you directly to the SAP server.
Workshop Agenda Item: Do we need encryption?
HTTPS is the technology that allows web applications like SAP Fiori to run with encryption and the familiar padlock icon in the user’s browser, which is a definite requirement for any remote use and becoming mandatory for all use of web applications.
HTTPS configuration is tied into the hostname, so you need to agree your single hostname and URL before you can start to design an HTTPS requirement.
If your design includes a chain of reverse proxies or devices that offer HTTPS off-loading, you need to create a diagram to cover where HTTPS will start and end, where certificates and keys will be configured, and which parts of the communication are secured by HTTPS.
Get out of your comfort zone to address web access from the start
It is very difficult for one person to cover all of the areas that need to be considered to get an ideal solution working. I normally find there is a lot of mutual learning as infrastructure teams have to work in partnership with the SAP team who may be new to rolling out web applications in SAP themselves.
It’s also very easy to focus all efforts on getting some SAP Fiori applications working functionally in the development system, and then get very close to go-live without giving sufficient attention to all the extra infrastructure requirements for production use.
The difficulty of learning something new, then working across an entire department to achieve it, can make working on complex web access unappealing. But failure to address the issue is a recipe for disaster, so it’s worth leaving your SAP comfort zone to hit it from the start.