Skip to Content

Architecting an SAP Fiori deployment

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 O’Callaghan for contributing to this blog.

You must be Logged on to comment or reply to a post.
  • Excellent blog and very timely! Would just like to add the option of using the SAP Portal esp. The new mobile portal options as a way to help users discover the Fiori apps they seem like a good fit as portal can also manage SSO.

    Thanks Simon

    • Hi Simon,

      Thanks for your comment and I fully agree. Especially since - as you say - the access via the SAP NetWeaver Portal can sort out the authentication question as well. The only additional consideration would be that most SAP Portal installations today do not target smartphones and tablets. It's clearly possible with the Mobile Edition of SAP NetWeaver Portal now, it's just not widely deployed yet.


  • Steffen,

    Esspecially the external access is something that is often underestimated. A lot of companies have strict policies and tools for external access to corporate systems. They often use tools like Cisco VPN or Microsoft Unified Access tools as the only option, but with regards to user friendly missions and reducing the complexity for end users that's not my favorite.

    I personally like the Relay Server of the SMP, but just another reverse proxy based on Apache and an SAP Web Dispatcher are a safe option too, in my opinion. Users don't have to log on to an additional stack and they have a low entry level for accessing the needed functionality.



    • Another option for access without having to install a full mobile platform like SMP could be just to have a MDM like afaria taking care of it.

      • Jan,

        While many companies might be comfortable with exposing services like SAP Fiori to the internet via reverse proxies, the more security-conscious / regulated industries see this often as a no-go and will require an additional layer of security, e.g. via a native wrapper application or a secure browser. There are interesting developments in the MAM space now as well with app level VPNs and access via third party manged gateways that can make such a native wrapper effective without having to custom-build additional security layers.

        MDM / Afaria could be useful to deploy a native wrapper or secure browser. Is there anything else you had in mind when you mentioned MDM?



        • Hi Steffen, No I think you sum it up - and probably know more about MDMs than me. My point was just that there are lots of MDMs out there offering different security options. Choosing one of these instead of a full mobile platform could be enough for some and the investment would be smaller. Br Jan

          • Yes, I would agree that a full mobile platform is overkill to expose a set of mobile web apps however if its already in place why not make use of it? As it stands however there is no getting away from custom development to access SAP Fiori via SMP   but if we believe the Fiori roadmap then there is something packaged coming as well.

            The MDM / MAM approach is interesting but its only going to help if the vendor offers some sort of connectivity solution into the corporate network. Especially with the many SaaS offerings out there this isn't always the case. There does seem to be an opportunity here for SAP though in that they could provide a secure mobile intranet browser app which would nicely complement the recently released  Mobile Documents app and make a good addition to the SAP Fiori / UI5 story.



          • Hi Steffen,

            I recently came across a client who uses Good for Enterprise, this is touted as a "secure browser" to allow secure access to the corporate intranet. I think they want to use Fiori via the Good for Enterprise application. I will let you know how that goes!

            Interested to know if anyone else has experience using this Good for Enterprise app in an SAP context?


          • Hi Simon,

            I've heard about Good for Enterprise as well and do know that they have an API on the server side of the installation that would allow pushing an application into Good. Whether or not this works with SAP apps (standard or custom build with e.g. UI5) is something that I cannot say yet. I'll dig into this in the coming weeks and might be able to provide more information once I have access to the environment.



          • Hiya,

            Good for Enterprise implements the pattern I mentioned and is well respected in the IT security community. Performance seems to be a major problem for some clients with all the traffic being routed through their data center. Would also be interested in what you guys find re SAPUI5 compatibility. Looking at the SAP Fiori / SAPUI5 documentation, apps like this don't seem to be on SAP's radar although they clearly ought to be.



          • Hi Steffen,

            Concerned to hear that "All the traffic being routed through their data center" - that doesn't sit well with my "TNO - Trust No One" security guideline 😏 . Apart from that security concern I would worry if performance is a problem - nothing kills the usability (and therefore the success) or an app like poor performance! I hope they have data centers in lots of countries if that is the case.

            Interesting times! Thanks,

  • Thanks, this is a great blog, really useful information and well explained! I do like that Fiori isn't prescriptive with how it will be served to users, however this may be confusing for some for who the definition of "app" is that it can be downloaded from iTunes. Really glad that this blog exists to help with that understanding.

    As I got to this blog via a link from Robbo's blog, I'd like to do other the favour of linking back - the two blogs (and comments) do work well together.

    Fiori arrives - first impressions and thoughts



  • Very nice blog, thanks for summarizing some key points around Fiori.

    The option to serve the apps through the mobile portal is indeed very interesting and I will definitely look into this option.



  • Great blog. Thanks

    I read in the technical documentation of the app that SAP will provide the source code of the application and the customer can easily customize the app. Thereby we can satisfy the customers added requirements.

    - Midhun VP

    • Great blog and subsequent comments!

      Specifically to the source code comment, tt would be interesting to know how one could keep the App code base compatible to future releases of the app from SAP. Does "user exit" paradigm exist here?


  • Hi Nice Blog.

    As a customer looking at potentially deploying these applications, and installing them, the natural home of Both the UI component and the Gateway services would be the core ECC6 system, thinking about the potential of the Architecture. Or would a standalone ABAP Application server be more relevant ?


  • Good discussion and valuable information.

    I have some follow-on questions to the one from James. In case the customer already has a SUP installation with a NW Gateway between SUP and the ECC6 backend according to the GW central hub -scenario, how would you bring in Fiori (now when Fiori is not yet usable via SUP)? Is it still a good idea to set up (another) GW according to the embedded scenario on ECC6 backend system or can we utilise the existing central GW? And if we decide to utilise the central GW, what is then the natural home for the UI components (backend ECC6, GW, separate system)? Does it make any difference if we only need to allow access to Fiori from within the corporate network, not from public internet?



    • Hi Pekka

      There's no need for a second Gateway system in this scenario. And the natural home for the UI components is the existing Gateway system - it is here that the UI components of Fiori can be installed, and there is also a requirement for the UI addon for NetWeaver (UI2) to be installed - this can also be installed on the Gateway system.

      Access restrictions are separate and even then shouldn't require a second Gateway system.


      • Hi dj,

        Thanks for the reply. I was looking at the Master Guide for UI AddOn and the Fiori Installation Guide. Based on those two I understood that the Fiori UISRA* -components would be installed on top of the ERP backend. But what you say is that we would not need to install any new components on the backend (assuming IW_BEP is already there), but all the stuff (including the UI Add-On) can be put into the existing Gateway system? That actually sounds quite good, but then I start to wonder how we can connect the Fiori apps thru the central Gateway to different source systems (DEV/QA/PRD).


        • Hi Pekka

          That's what i'm struggling with. Especially if you have different UME setups and users on dev / qa / prod.

          Rather than a central gateway system, wouldn't you build three ones a dev one / qa one and prod one on each ERP system, otherwise User Administration becomes a headache ?

          • Pekka, James,

            I don't think you can easily share a central Gateway system across multiple landscapes for the Fiori apps. Either way it's best to keep dev / qa / prod landscapes separate to avoid compromising their integrity, i.e. either have an embedded Gateway instance on each business system instance or install one central Gateway instance per landscape.


          • Hi Steffen,

            We have now proceeded to the phase of making to installations to the central Gateway system. But there seems to be some issues that are not totally in line with what has been stated above. In particular, the installation of UI Add-on 1.0 requires the installation of IW_BEP into the central Gateway. As it is already installed into the backend ERP, it sounds to me like the home of the UI Add-on should be the backend instead of Gateway.



  • Hi Steffen

    I am bit confused on this

    The natural home for the “UI component” of the SAP Fiori apps is alongside the SAP NetWeaver Gateway Services...

    Are you telling that the UI Component(UI5 component) is associated with sap netweaver gateway incase of fiori applications ?

    I deavtivated my gateway service and run the fiori home page. I was able to see the application in the browser even after clearing my browser cache. I belive the UI component is not anyway realated to netweaver gateway. Please correct me if i am wrong.


    Sreehari V Pillai