Architecting an SAP Fiori deployment

[Former Member]

There’s been a great buzz this week following the SAP Fiori announcement. Do check out this site to find out what it’s all about if you haven’t seen it yet but in a nutshell Fiori is a collection of consumer-grade productivity apps for common enterprise scenarios that work seamlessly across smartphones, tablets and PCs.

From a technical perspective, each SAP Fiori app consist of a “UI component” and an “integration component”. The UI component is an SAPUI5 application and the integration component provides the underlying SAP NetWeaver Gateway OData service.

I’ve been lucky enough to be involved in two projects recently that are based on a very similar architecture so here are initial thoughts on how to architect a Fiori app deployment. Please do add your comments and experiences below, especially if you’ve participated in the Fiori ramp-up programme.

Key functions

To start with, I'll list the key functions that an SAP Fiori architecture needs to provide. This is in addition to the relevant SAP ERP processes that I assume to be in place and fully configured:

• Serve the SAP NetWeaver Gateway OData Services
• Serve the SAPUI5 application
• Authenticate the user
• Provide internal and external access
• Help users to discover the Fiori apps

In its simplest form all these functions can be provided by a single SAP NetWeaver ABAP application server that is accessed from the internal network or over an existing VPN connection. In real life most deployments will end up being  more complex though.

In the next step, let’s look at the options for these five functions in more detail - starting with the NetWeaver Gateway services.

Serve the SAP NetWeaver Gateway OData Services

With SAP NetWeaver Gateway there are basically two deployment options. SAP NetWeaver Gateway can either be installed as an ABAP Add-On “embedded” into your SAP ERP system or it can be deployed as a “standalone” instance. An embedded installation is only an option if your ERP system meets the SAP NetWeaver Gateway prerequisites. Running SAP NetWeaver Gateway as a standalone instance adds additional overhead but comes with the advantage that it can be upgraded independently from your core systems and it can form a single access point for multiple backend systems.

What can be  confusing initially is that in the standalone scenario the SAP Fiori integration components need to be deployed into the backend system. The reason is that although the OData service is served by SAP NetWeaver Gateway, the service logic itself is executed  by the “Backend Event Publisher” (IW_BEP) on the backend system.

Serve the SAPUI5 application

The natural home for the “UI component” of the SAP Fiori apps is alongside the SAP NetWeaver Gateway Services, but it could also go into any other SAP NetWeaver ABAP Application server that has the “SAPUI5 for NetWeaver Add-On” installed. Such a split installation then would need to be fronted by a shared reverse proxy server to avoid same origin policy issues.

Authenticate the user

Fundamentally SAP Fiori users need to authenticate against the UI component. Once that is accomplished the user’s identity can be propagated (e.g. via SSO2 tokens) to the Gateway service which then uses a trusted connection to connect to the ERP system. For this to work as intended, the user name needs to be consistent across all three components. If the UI component, the integration component and the ERP system are all on the same instance than that will naturally be the case. In distributed scenarios however user details will need to be replicated – either via SAP Central User Administration (CUA) or from your central identity store.

Where the variations come in is how the initial authentication takes place and there is a whole raft of different options:

• User name and password
• X.509 client certificates
• SAML tokens generated by SAP IdP or another SAML Identity Provider
• SSO2 tokens generated by an SAP NetWeaver Portal instance
• Other single-sign on providers

In my book this degree of openness is a real strength of the SAP Fiori architecture, but needs some thought in advance to get it right. If authentication is by user name and password it tends to be a wise move to link into a central identity store to make sure your users can actually use the new apps and to keep your support cost down.

Provide internal and external access

Remember the lady in the Fiori promotion video checking a purchase order from her smartphone in the fitness club? To make that happen any Fiori UI components, integration components and potentially your identity provider need to be accessible from the internet. I bet that whoever is responsible for the security of your corporate network and data wants to have a say how this is going to be achieved so make sure to discuss this topic as early as possible. Again the SAP Fiori architecture isn’t prescriptive of how to do this which will help to fit in with existing policies and infrastructure at the network edge.

For mobile device the SAP Mobile Platform (SMP) can also be a viable access path if you wrap the Fiori apps into small hybrid apps. In that case SMP can add an additional layer of security with its device registration features, but all of that is purely optional.

Helping users to discover the Fiori apps

Now that the apps are up and running think about how your users will be able to discover the Fiori apps. Being creative with how to promote the apps is well worth the effort to drive user adoption. Adding the Fiori home page to your intranet could be a good starting point. Direct links to each app could also be promoted via your enterprise app catalogue or they could be pushed down automatically to any corporate managed mobile device via a mobile device management solution. For the many approvals scenarios in the Fiori app portfolio, why not add the links directly into the respective reminder emails that are being sent out by the underlying workflow?

Sizing implications

The final point to consider is sizing the required infrastructure. I won’t go into details in this blog, but a good starting point would be to get to the bottom of the intended target audience. How large is the target audience? How many of them are already using the functions offered by the Fiori apps via a different channel? What is the expectation of usage within the corporate network vs access from external? There is also tons of good advice on SCN now regarding sizing SAP NetWeaver Gateway.

If you want to dive deeper, check out this SAP Help page which holds the product documentation for SAP Fiori.

Many thanks go to my colleagues dj.adams and brenton.ocallaghan for contributing to this blog.