Skip to Content

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: http://scn.sap.com/docs/DOC-58340

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:

http://service.sap.com/sap/support/notes/1978213

http://service.sap.com/sap/support/notes/2016014

 

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 HANA
  • SAP MaxDB
  • Sybase ASE/SAP ASE

 

Official reference:

 

HUB Deployment vs. Embedded Deployment

Generally, Fiori can be deployed in the folllowing ways:

  • HUB deployment: A dedicated FES system is deployed “in front of” the ERP / business suite backend system.
  • Embedded deployment: the FES is deployed into the ERP / business suite backend system.

 

SAP generally recommends the HUB deployment option. Please also refer to: Deployment Options – SAP Fiori for SAP Business Suite – SAP Library

In addition, certain criteria motivate for a HUB deployment:

  • Minimum release requirements, as pointed out above. These requirements must be met
  • Exposing the system to client devices: depending on the client device and the access (e.g. unmanaged mobile device from an external network), multiple network boundary lines may be desired or required by company security guidelines. A HUB deployment is strongly recommended from a security viewpoint.
  • Load: in a HUB deployment, the workload related to WebServer / Gateway / Launchpad is kept in a dedicated system, thereby not affecting the backend ERP / business suite system. Please also refer to the sizing guidelines above.
  • SLA: Fiori Apps / UIs / Basis for FIori might be upgraded in a higher frequency than your regular backend system update / patching cycles. Having a dedicated system will decouple the update cycles.

 

Embedded Deployment for Development / HUB Deployment for Production

A specific approach for the FES deployment: embedded in Development (and Quality) – HUB in Production. To be more explicit, let is use an example: you have an existing backend system landscape on Netweaver 7.40 with a dedicated instance for development (SID: BED), quality (SID: BEQ), production (SID: BEP). To limit the additional TCO, you want to deploy the FES for development on BED and for quality onto BEQ. To have the advantage of an HUB deployment in production, you however want a dedicated system for FES production (SID: FEP), which then connects to BEP.

This deployment option is possible, but to this date I have never done this, so I cannot rule out any issues. A few things that need to be considered in any case:

  • Gateway aliases / RFC destinations for the ERP backend systems will point to a local system for development and quality – and to a remote system in production.
  • This means also that a trust relationship needs to be set up for production FES and production backend. This is different than for development and quality and there may be some teething problems for the first app to go live in production.
  • Transport paths will need to be defined seperately for FES-related objects (GW config and the UI part of the apps) – and for the existing ERP developments, including service implementations. Since both will end up in different servers in production.

 

Using an an existing SAP Netweaver Gateway System as FES

Technically any ABAP stack that fulfills the minimum release / deployment requirements lined out above can act as a FES. An existing GW system may be a natural candidate to take over the additional role of the FES. Please consider the additional load that you will encounter on your system – as per the sizing guidelines above.

 

Using an existing SAP PI System as FES

(Thanks to Steven for asking the question). Generally I would not recommend this. Even though I have never seen that in a project – and thereby cannot judge – it does not seem right. The following reasons come to my midn:

  • 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.

 

Splitting FES into two ABAP Systems: UI-centric vs. DATA-centric system

Background: you may already have established a GW system, which is defined as the OData Integration Layer – any OData related communication should go through this point. On the other hand, you don’t want your GW system to take on any other responsibility (e.g. for reasons of system load, availability / SLAs / architecture governance).

Answer: There is currently no architectural statement forbidding the “split” of the central ABAP FES system into two systems – one UI-centric and one data-centric system. This split is however clearly not “best practice”. On top of that, the following challenges need to be considered:

  • Splitting the system responsibilities requires a proxy (e.g. WebDispatcher) in front of both ABAP Stacks (as the client browser prevents OData calls to any other server than the original server from which it requested the static UI resources).
  • Change Management will be complex as UI and OData service changes (incl Cache Refreshes) need to be managed in sync over two ABAP systems.
  • Fiori has certain inherent OData Services (for Launchpad User / Role / Catalog management) – including an integrated Fiori data model. Where do these run?

Summary: splitting the Frontendserver into does not solve any currently known problem. It will impose however additional effort and risks. Therefore it is not recommended.

As a simpler alternative: split split by use case. One Fiori Frontend-Server that also handles the OData Requests for Fiori components – and one GW for other integration scenarios.

 

Using SAP Portal as FES

It is possible to integrate the SAP Portal into the Fiori Frontend-Server infrastructure. This may be a relevant feature when the portal has been defined as the central point of entry for the users / the central point where UI-centric roles have been defined. The portal integration provides the following features:

  • Run the Fiori Launchpad as a dedicated Framework Page on the SAP Portal.
  • Integrate Fiori Launchpad Content into the Portal role model.

The portal does however not replace the FES, e.g.:

  • Application UIs will remain on the FES
  • The underlying UI5 libs also need to be on the FES.
  • Gateway needs to run on the FES.

For more information, please refer to:

 

Using 3rd party WebServers as FES

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 strongly advise against this option.

 

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.

DON’T!

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.)
To report this post you need to login first.

30 Comments

You must be Logged on to comment or reply to a post.

    1. Jochen Saterdag Post author

      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?

      Cheers

      Jochen

      (0) 
      1. Steven De Saeger

        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 …

        (1) 
  1. John Patterson

    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

    JSP

    (0) 
  2. Yanming Cao

    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.

    (0) 
    1. John Patterson

      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.

      JSP

      (0) 
      1. Yanming Cao

        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.

        (0) 
        1. John Patterson

          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

          (0) 
    1. Jochen Saterdag Post author

      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: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/f0b8f7bc-244b-3210-3ea2-cf9a3c3bc908?QuickLink=index&&hellip;

      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

      Jochen

      (0) 
      1. Srdjan Boskovic

        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,

        srdjan

        (0) 
        1. Jochen Saterdag Post author

          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).

          Best

          Jochen

          (0) 
  3. Tobias Trapp

    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,

    Tobias

    (0) 
    1. Oliver Stiefbold

      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)

      (0) 
  4. Daniel Munoz

    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

    /wp-content/uploads/2016/08/fes201_1013903.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.

    Regards,

    Daniel

    (0) 
    1. Oliver Stiefbold

      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.

      (0) 
  5. Hernan Enriquez

    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?

    (0) 
    1. Oliver Stiefbold

      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.: https://experience.sap.com/news/sap-fiori-2-0-now-available-for-sap-s4hana/

      BR, OLiver

      (1) 
  6. Kevin Ooi Wen Chong

    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.

    (1) 
  7. Ravi Singh

    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.

     

    (1) 
  8. Bernard Le Tourneur

    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.

    (0) 
  9. Jocelyn Dart

    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

    Rgds,

    Jocelyn

    (0) 
  10. Sankara Bavirisetti

    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?

     

    (0) 
    1. Jocelyn Dart

      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.

      Rgds,

      Jocelyn

      (0) 

Leave a Reply