Skip to Content

Planning the SAP Fiori Front-end Server (FES) – Architecture Questions

Kindly notice that the blog further below is now outdated and will not be further maintained. In particular, for S/4H scenarios, the information is not correct any more. Related up-to-date information can be found here here:



This is a specific view on the possible deployment options for Fiori on an ABAP based SAP Fiori Front-end server (also referred to as “FES” in this document). For a more holistic view that also considers non-ABAP deployment options, please refer to:

In the context of Fiori, the FES provides the following key capabilities:

  • WebServer: serving the static UI5 resources to the requesting device.
  • Gateway for oData calls: routing of oData service calls to the backend that implements the service.
  • Fiori Launchpad Provider: providing the services required to run the Fiori Launchpad and keeping the related data model.

For more details, please refer to:

When performing the landscape planning for the FES, there are general “patterns” of architectural questions that I have observed with myself and others. I am herewith trying to consolidate these questions and try to give some guidance – by putting down some decision-relevant criteria.


Basics: Installation Requirements

Minimum release  / deployment requirements: to run the FES SPS04, you need at least Netweaver 7.31 SP5 (plus GW and UI Addon), Netweaver 7.40 SP8 or Netweaver 7.5 SP1 . A higher level is recommended. Please refer to SAP Help for more information: Installation Requirements (Transactional Apps) – SAP Fiori for SAP Business Suite – SAP Library.


Important: Some Fiori apps running on the FES define higher requirements! Most importantly, S/4HANA apps require the FES to run on an SAP Database (such as MaxDB, ASE or HANA). Please refer to the UI Technology Guide for SAP S/4HANA, on-premise edition 1511 for further information.


Basics: Sizing

For the sizing the FES, please refer to:


Basics: Unicode / Non-unicode backend

It is not recommend to use Fiori with non-unicode backends. For further information, please refer to the following notes:


Basics: Are there any DB restrictions for the FES

For the Fiori Front End Server 2.0, there are no per-se restrictions for the DB. The restriction depends on the content. For S/4 Fiori content, the supported databases on the FES are restrictured to any of the following DBs:

  • SAP MaxDB
  • Sybase ASE/SAP ASE


Official reference:



2-tier FES for 3-tier Backend – DON’T

To reduce your FES landscape, you might want to think that reducing your FES landscape to a two-staged approach is possible in where the DEV FES connects to a DEV and Q Backend system.


In the past customer reportedly had this working, with some drawbacks, but now that with S/4H also WebDynpro and WebGUI tiles are connected, this results in an unsupported state.

(Just for historical reasons, here the statement from the past, which is no more strong enough

Customers who have followed this approach have provided feedback that this is generally working. Nonetheless, this approach cannot be considered best practice. A few aspects coming to my mind:

  • Increases manual effort during testing (are you using the right system alias?)
  • Possible intereference between development and test activities
  • Possibility of invalid test results (if wrong system alias was set selected)
  • In case of upgrades required on IW_BEP in the backend system: need to upgrade both DEV and Q Backend.
  • Generally an asymetrical transport in the Backend.)
You must be Logged on to comment or reply to a post.
    • Hi Steven,

      thanks - interesting question. On the PI, that's something where I would be hesitant:

      • Typically, PI performs business-critical B2B-type communication, mostly asynchronous. I have seen a lot of PI systems that have been sized and stabilized over time to fit these requirements.
      • Gateway on the other hand is synchronous, typically end-user related and not B2B. The sizing / SLAs / etc. might be entirely different.
      • Also, you may have very different upgrade cycles. I'd see PI as mostly stable over a longer period, whereas Fiori is still more on the innovative edge. You might de-stabilize your PI operations by appliying Fiori-related patches etc. in a high frequency.

      So my gut feel tells me: rather keeep them seperated.

      Makes sense?



      • Hi Jochen,

        Thanks for your insights & feedback 🙂

        It is indeed an interesting question ... I agree that a PI system is typically sized for asynchronous processing and by nature has a different profile in terms of usage ... on the other hand for this particular system there are already alot of synchronous PI message flows and we already have an operational SAP Gateway hub and a couple of UI5 applications ( with limited usage though ) running ... so the system is already having a 'dual alike' role ... nevertheless you make good points in upgrade paths & patching & stability... I will take your points into consideration for our SAP basis guys to decide on where to take it next ...

        • Hi Steven, I know this post is rather old, but I’d like to know what the outcome was with your issue: Did you re-use same server for both fuctionalities or did you keep the functionalities apart on different servers?

          • Hi,


            If I recall well we didn't install the FES on PI as we were not interested in using Fiori Launchpad ... but we did run several UI5 apps for several years on the PI server ...

            Later on a separate FES server was installed though.



  • Hi Jochem

    You raise an interesting point about splitting FES into 2 systems.

    <My Opinion>

    Up until recently I actually thought the Central Hub FES/BEP model was being wrongly promoted as the default solution for Fiori, a single point of entry is one thing, but security has many layers, I see this as just one layer which is subjective and not consistently promoted (see OSI Model for example).

    I thought it was really targeting customers who could / didn't want to put gateway on "legacy" SAP systems. I often see customers take this option because they are reluctant to upgrade CRM or SRM systems for example, just wanting to keep the lights on until its no longer needed. Most customers I see have a long term plan for HANA and see this a place where they will start rationalizing. I point out that in HANA by default the FES/BEP is combine to one and independent of the Gateway pattern adopted there is still work to do on those legacy systems regardless.

    When you go into customers its always an interesting discussion to have AMS, has not changed since the MySAP WorkPlace days, they want to reduce the operation costs and your basically telling them they need 5+ (D,T,Q,PP,P) new instances to deploy a PO approval app and then you say wait there is also a Mobile Platform and an IdP and ... given everything is virtual nowadays, spinning up a new instance should take seconds not weeks and managing should be automated (Puppet, Docker whatever)

    </My Opinion>

    When i heard SAP had partnered with Apigee to create an API Management Solution I had very similar thoughts about splitting the Gateway instance into Data vs UI for load, availability and governance etc.

    The OData API that Netweaver Gateway provides is your App, there should be no business logic in your UI and therefore splitting this FES into 2 makes perfect sense.

    The UI content is really just static resources (akin to the WGATE of old) and shouldn't be tied to a SAP system for various reason like CI, Cloud and patching etc. (SAPUI5 dependencies like patches should be discoverable from Git or Bower for example) would love to see the ability for example of configurable deployment of NGINX containers which could easily deploy the static content close to the users.

    I think as customer start deploying more and more Gateway services, these services really need to be properly managed, consistency, re usability, SLA's and metrics etc.

    I guess my point is, with HANA customers are moving to a monolithic architecture which scales up, however to get where the users are you need to scale out as well, splitting out the front end definitely opens up the options for adopting best practices.

    hope some of this makes sense


  • I agree with John on splitting the FES system into two separate systems. In fact, I think "Frontend Server" is an ill-named term for a system role in a system architecture for SAPUI5 / Fiori applications. The role for Gateway is to expose SAP backends as an OData REST Web Service API. This is one step towards SOA, in which all systems communicate in a service-oriented way. Imagine all SAP backends can communicate using only OData API.

    The role for a Web Server is to serve static and dynamic web contents. In modern Web application design, the presentation layer goes completely to the client side (runs in a browser). So other than loading static contents (HTML/CSS/JS files and images etc.) from Web server, the client only sends REST requests for data to the Web Server and got JSON response. These REST requests are screen-based, i.e., it asks for data to populate its screen.  The requests are not domain-based, i.e., it need not have an understanding of underlying business objects and their complex APIs.

    To separate the screen-based API with the Gateway-provided domain-based API, there needs to be a separate layer in the architecture above Gateway to provide the data service for the UI screens. Typically this can be implemented with NodeJS (along with a DB to cache results for performance)

    For static Web content, Nginx would suffice.

    • To separate the screen-based API with the Gateway-provided domain-based API, there needs to be a separate layer in the architecture above Gateway to provide the data service for the UI screens. Typically this can be implemented with NodeJS (along with a DB to cache results for performance)

      Not sure I understand where NodeJS or a DB fits in maybe you could elaborate.

      One of the opportunities you get using API Management solutions like Apigee would be transformation, you could take generic services like for example content and document management and make them a better fit for the client app, not sure it fits in with current Fiori patterns though. A question i get asked a lot is around SAPUI5 consuming AIF data, maybe a good use case.


      • In "SAP Fiori Architecture Topics", which is a doc #U59 in the Fiori Design RDS, one of the best practices is to minimize the # of calls from the browser client to FES. Ideally there is one call per screen. This call is very specific to retrieve data that's only necessary to populate the UI. That's why we need a JSON API at the server side just to serve this need for screens. This does not need to be OData API, just a plain old REST API.

        This data API layer de-couples with the Gateway API layer, because they serve different purposes. Ideally the Gateway API for a particular SAP backend, e.g. SAP CRM, will provide a open standard web services and full-function interface with which SAP CRM is willing to interact with other systems.

        Check out LinkedIn's mobile architecture, for screen-based REST API.

        • wrt minimize the # calls

          - use Component and Library pre-load files, this condenses and concatenates all your UI5 code (controllers,views, i18n, css, images etc) into single file and massively reducing round trips

          - design your OData services to use $Expand so new views will load faster, idea is to  inline multiple Entities into the initial payload, reducing round trips

          - take advantage of cache headers in your Gateway service

          - take advantage of app cache on the UI5 side

          is a good start

    • Hi Srdjan,

      The only non ABAP deployment options that are supported are:

      • SAP Enterprise Portal
      • SAP HANA Cloud Platform

      Please see my additions above in the blog, or refer to:…

      Other 3rd party WebServers could theoretically also serve static UI resources. However you need to have a runtime for your launchpad meta model (roles, catalogs, etc) - and the launchpad related services. And 3rd party options are not covered through support. Therefore, I would strongly advise against this.

      Kind regards


      • Hi Jochen,

        thank you very much for the link to excellent document, exactly what I was looking for.

        On a page 4, in Supported UI Technologies row, the "URL" is listed together with technologies like SAPUI5, WebDynpro, Personas etc. Why the term "URL" is put here, at the same level with UI technologies - the only thing I could not figure out ?

        Comment on this highly appreciated.

        Kind regards,


        • Hi Srdjan,

          the term "URL" describes the ability to access generic Web Resources via Launchpad. (resources that can be called via URL and run inside the browser).



  • As always you provide excellent content 🙂

    I have another question that deserves clarification. Note 2217489 - Maintenance and Update Strategy for SAPUI5, NW AS ABAP UI Technology and UI Add-On and 2219596 - SAP Fiori front-end server 2.0 - General Information introduces a new term "Fiori Froentend Server 2.0". I think this would be a good topic for a new blog entry.

    I have a question in this context. If those note right an AS ABAP NW 7.40 with SAP_UI 750 and SAP_GWFND 750 if an FES 2.0 and so can serve as a FES for a NW 7.5 backend. Is that true?

    Best Regards,


    • Hi Tobias,

      AS ABAP 7.40 always has an Gateway Foundation 7.40.
      AS ABAP 7.50 always has an Gateway Foundation 7.50.
      No matter if with or without FES 2.0 on top.
      FES 2.0 always has an SAP_UI 7.50 build in - thats the idea of FES 2.0.
      it can be deployed on AS ABAP 7.40  with Gateway 7.40 or on a  AS ABAP 7.50 with GW 7.50
      (or on AS ABAP 7.31, which i do not recommend)

  • Thanks for the useful post. It helped on clarifying some aspects, however I still have one doubt I have been unable to answer.

    We are planning to install a front-end server to run Approve Requisitions and Approve Purchase Orders fiori apps from product FIORI ERP APPLICATIONS X1 (SAP Fiori Principal Apps 1.0 for SAP ERP) which according to note 2200415 it has been released for SAP_UI 750. Backend release is ERP 6.0 SPS15

    You mention in your post that there are no per-se restrictions on the DB layer from FES 2.0, however, whan planning an Installation of SAP front-end server 2.0 on Netweaver 7.50 and FIORI ERP APPLICATIONS X1, only SAP ASE, HANA or MaxDB OS/DB files are shown to be selected./wp-content/uploads/2016/08/fes20_1013889.png


    If we try to launch Maintenance Planner from fiori app reference library, we get no choice for Netweaver 7.50

    2016-08-11 16_31_20-WKI_MaintenancePlanner_FioriAppReferenceLibrary.docx - Word.png

    Also, from the fiori apps reference library, only Netweaver 7.31 / 7.40 is shown as option for the given product.

    I would appreciate if someone could throw some light on this, stating if it's possible or not to use FES2.0 on NW750 to run mentioned fiori apps on a backend ERP6.0 SPS15.



    • Hi,
      in general all Fiori apps should run with its newest product version with FES 3.0.  (However, some Fiori apps might not be already released for FES 3.0 or there might be some/few Fiori apps or versions, which will not support FES 3.0 for technical reasons. Please check in Fiori reference library)

      In case of FIORI ERP APPLICATIONS X1 you choosed the instance "Central App ui 2.0". In my system I see, that it is released for FES 2.0 and FES 3.0 - so should work. If not, please open a support ticket.

  • One question I have about the deployment of FES. What is the best approach for architecting  FES when we have a mix of S4HANA systems + Business Suites 7.40. Should we look for a Hub installation of FES with HA to serve all? Should we go with a FES for S4HANA(s) and one for Business Suites 7.40?
    Also, I was told recently (I need to get more context) that SAP recommendation is to have one FES per S4HANA instance is this true?

    • Hi Hernan,
      One FES per S/4 in general is not true. this is the embedded scenario which can make sense if you want to run the system separated e.g. for lifecycle reasons.
      General setup is hub deployment - one for all. Means one FES 3.0  (wit dev, test and prod) for S/4 HANA 1610 and BS with NW 7.40.
      S/4 HANA 1511 however isnt released for FES 3.0, so needs to be upgraded to 1610.
      However FES 3.0 has a new default theme "Belize", which would be then the theme for all Fiori apps. If you dont wnat this, you have to split the FES again, and you loose the FES-Fiori Launchpad as central integrator.
      For more infos see e.g.:

      BR, OLiver

  • A very good blog, covers the many 'creative' alternative architecture deployment possibilities (as well as why they are not best practice) which are usually not covered in the SAP Landscape Deployment Recommendations.

  • Thanks Jochen for such an informative blog. I have a quick question: Do we have any way to login to FrontEnd using the backend login credentials without using SSO?

    Scenario: We have different ECC systems (EC1 / EC2) where users might have different passwords. And we are planning to get a front end (Hub-implementation) for Fiori. But users will have to use separate password to login to this system until we have SSO. Is there any SAP standard way we can use so that our end users will be able to use same password as they use in ECC to login to Fiori Front End.


    • Hi, I am not a security expert, but due to my knowledge, this what the CUA - Central User Adminstration does:

  • Hi Jochen.

    We are implementing the Central Hub Deployment option as concerns the Fiori Front End Server. I am curious about the proposed database and the size to service the FES. We have 2 x HANA appliances spec'd with the following specs: 256GB RAM / 1TB HDD / 16 vCPUs

    From my perspective I am unsure how the appropriate sizing of the db for FES is obtained - can you help by pointing me in the right direction?

    With appreciation.

  • Hi Jochen

    Thanks for this. Just noting that the direct link to the Sizing Guide doesn't work... best to just leave the menu to it perhaps



  • I have upgraded my SAP NW 740 to 750 ( I got SAP_UI 750, SAP UI, SAP_GWFND etc) and when we see the Product Versions I could see any FIORI 2.0 Front-End add on  in the list , my question is " Does NW 750 ABAP stack automatically bring FIORI 2.0 part of SAP_UI or does we need to plan separately ? while I am trying to run maintenance planner to install FIORI Front end 2.0 there is no option to chose NW 750 only I have NW 740 ?  it sounds during my NW 750 upgrade all required components for FIORI 2.0 included in SAP_UI 750 component?


    • Hi Sankara

      Please note that Fiori Frontend Server 2.0 does not give you Fiori 2.0  - it's still Fiori 1.0 look and feel.

      Actually Fiori 2.0 requires Fiori Frontend Server 3.0, i.e. module SAP_UI 7.51

      You need to be on at least NetWeaver 7.40 and at the relevant support pack level to add module SAP_UI 7.51

      You can find more information here...

      If you have further questions please do NOT add it as a comment to this blog. Instead raise it as a separate question tagged with SAP Fiori.