Morning to all Fioriers,

I am not actively blogging these days. Last time I blogged on SCN; one and half year back. As Fiori is gaining more and more momentum,I feel there is a need to present a big picture/approach towards tackling Fiori projects and get it up and running quickly. So, after some encouragement from my colleagues Owen Pettiford and Paul Abrahamson I decided to jot down my experiences, from the Fiori projects we completed successfully last year, in the form of this blog series.

Part 1 is about planning your Fiori setup and Part 2 (I have supplied the link in the end) is about the implementation itself.

(Next parts in this series will be on implementing Analytical and Factsheet apps in Fiori)


Fiori UX talk is all around these days. From its humble beginnings i.e. simplifying/rethinking 30 most used SAP transactions to a mammoth collection of 511 apps in Wave 7 (at the time of writing this blog) coming from almost all major functions of SAP Business Suite, its still growing.

There are mainly 3 categories of Fiori Apps: Transactional, Analytical and Factsheet Apps.

You need HANA for Analytical and Factsheet Apps. Transactional Apps, on the other hand, for a familiar business function, could be a good start towards UX renewal in your company.This blog is meant for those SAP customers and consultants who are already working with SAP Business Suite and wondering what it takes to get their feet in the door and implement a successful Fiori project.


Conception and Scenario

So you are a classic ERP customer using the traditional SAP Business Suite system and you are impressed with the demos you see all the time by SAP and various partners for new Fiori UX paradigm. You want to play around with these standard apps, asses their suitability and see how much you need to customize before you can think about going live with them.

Let’s say your area of interest is Leave Management and you want to have a look at My Leave Requests and Leave Approval Apps. Also, you want to perform some customization in the Leave Approval App.

Building the know-how or engage with a partner who has done this before

Now you need to figure out technicalities of the product, skills needed, current state of your systems for Fiori (versions etc.) and how best you can have Fiori with minimum or no upgrade to your backend systems.

To figure all this out there are two options:

a) If you already have an SAP competence in your company and want to maintain this kind of solutions yourselves going forward, you need to get your architects have a look at above mentioned things and draw up a learning and implementation plan.


b) There are a few specialist partners in this space whom you can contact for a consulting advice as well as implementation itself. For a first time customer, with no experience in these technologies, engaging with a partner could be very beneficial. One advantage here is that generally these partners have the apps running in their landscape so you can get them to demo these to your business users even before starting the project.

Also, they may have already wrestled with the real world problems hidden behind the marketing slides of a new product 😉


Planning your implementation – Food for thought

Below are some pointers regarding technologies, skills and the kind of landscape needed to kick start a Fiori project for the scenario we have chosen:

a) Technologies involved and architecture

To implement and use Fiori Leave Management apps you need following technological pieces:

  • A Backend SAP ERP with HR business functions ESS/MSS enabled
  • SAP Gateway (Embedded or Hub Deployments)
  • SAPUI5 Libraries (As Fiori is currently implemented in SAPUI5)

b) Putting together the right Fiori team

You might have heard that Fiori and Gateway are freely available for the customers who already have the license for relevant business function with underlying NetWeaver layer. But, as you know, for all non-plug & play products, there are implementation costs involved. Fiori is no exception. You need people who can play following roles.

  • Involvement of business users for discussions since the beginning of project to understand the actual pain points in their day to day work. This is extremely important for obvious reasons.
  • An Architect who knows how things fit together technically – Prerequisites, right Gateway/Fiori deployment options for your landscape, which apps use which ERP functions/workflows in the backend ,needed reverse proxies setup, System Aliases for services and Task Gateway, OData-UI5 app architecture know-how, Launchpad concepts etc. Most importantly, someone who can coordinate between various teams to get things done in time.
  • A Functional Consultant who can assess the apps functionally, determine enhancement needs, help technical teams during implementation, write test cases and work with business users with UAT.
  • A Basis Consultant who can install and configure Fiori apps with the help of your Architect and ABAP Team members.
  • Member/Members from the Network team in your company to address issues in Reverse Proxies, Cross Domain Access, Firewalls/Ports for external access etc.
  • An ABAP Consultant who knows SAP NetWeaver Workflow, Enhancement Framework, OData and Gateway
  • An SAPUI5 Consultant who can do UI extensions and theming etc.

These roles can be played by any number of people depending on the competence in your or your Partners’ Team. Last two roles are need-basis and required at the time of app extension.

c) Landscaping: Are you on the right version? Whats the right deployment choice for you?

This is a very important discussion you need to have with your architects and it varies from case to case and customer to customer.  You may setup an Embedded Gateway Deployment (ERP, Gateway, and UI5 on 1 box) for your Sandbox/Dev but a Central Hub (Gateway and UI5 on a separate box connected with your ERP) for your QA and Prod. Or it could also be a Central Hub for all 3 landscapes.

If you are doing a Central Hub, you will get Gateway core components available as part of NW 7.4. You just need to install Backend-Enablement component (IW_BEP) on your backend system. This component is quite compatible to old versions of ERP/NW. On the other hand, if you are doing an Embedded Gateway, you need to find out if you on the right version for Gateway Framework components (scope of GW_CORE/IW_FND) .

Also will the Launchpad be a part of your existing portal or a new entry point altogether?

Generally your architect can work with the basis team for this. Poor decisions in this space could lead to a bad start and unnecessary overhead costs. So doing your landscaping right is a great start in Fiori projects.

d) Authentication and Authorization

This is where Network and Basis teams can collaborate with you and your Architect to determine how users will access these apps internally and externally. Firewalls and Ports to be opened, reverse proxy you use currently, redirecting or renaming URLs and most importantly the current situation of SSO in your company. This is often the most challenging piece in such projects. Do you really need an SSO? What combination of OAuth/SAML/X.509 can serve the purpose? What about security and SSL? Do you need to secure your RFCs as well with SNC? Have you thought about using User-Mappings feature of SAP Gateway? (Yes! There are more features in Gateway then SEGW stuff).

Story doesn’t end here, what about security? Are the role templates provided by SAP for Fiori sufficient to create custom roles and use straightaway? No they are not 😉

This is a huge topic in itself. In fact, achieving SSO via User Mappings in Gateway (via X.509 or SAML 2.0) is a topic of a separate blog in itself.

This is also a space where your experienced partner can help you a lot.

e) Documentation

SAP, in past (2013-Early 2014) have confused everyone by releasing many documentations frequently (PDFs initially). But now as the apps themselves are relatively more stable, as of today, there are three main documentations available:

  • Fiori App Reference Library

http://www.sap.com/fiori-apps-library.

I especially like this one. This documentation explains the pre-requisites/components/notes not only for every app but for each release of every app. Thank you SAP for this and I hope you will maintain this going forward!

  • SAP Help Documentation

http://help.sap.com/fiori_bs2013/helpdata/en/1a/ebc553bd51eb1ae10000000a441470/content.htm?current_toc=/en/59/69c553c9519638e10000000a44176d/plain.htm&show_children=true

  • And lastly “All Things Fiori” Page

       http://scn.sap.com/docs/DOC-41598


Also, new Fiori space is live on SCN now!

http://scn.sap.com/community/fiori

I think, once you have thought about all of this, you are on the right track and ready to evaluate the pre-requisites and start the implementation.

In 2nd Part of this series, I will talk about the actual implementation itself.

Here is the link to Part 2:

http://scn.sap.com/community/mobile/blog/2015/02/06/fiorifying-your-erp-system-ingredients-of-a-successful-fiori-implementation-part-2

To report this post you need to login first.

34 Comments

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

    1. Saumil Jyotishi Post author

      Hi Mike,

      Thanks for reminding about Fiori Landing Page. We have been using it since quite a while now. I will include it in the documents list.

      I haven’t used Web IDE much till now but for the upcoming assignments we have plans to use it for UI extensions.

      (0) 
  1. Masayuki Sekihara

    Hi Saumil,

    Thank you for sharing your experiences. I like the section b) Putting together the right Fiori team. Yes. Setting up a project team is very important like any other projects. Fiori is free but project is not free.

    Regards,

    Masa / SAP Technology RIG

    (0) 
    1. Saumil Jyotishi Post author

      Thanks Masa!

      Absolutely. Right team is important and equally important: co-ordination between people in the team. Specially during installation and configuration.

      (0) 
  2. Trevor Naidoo

    Just wanted to add some points below. If you have the right SAP Technical capabilities in-house it should be adequate for this exercise. Having just gone through this exercise, the one thing that stood out for me was this comment you made:

    Also, they may have already wrestled with the real world problems hidden behind the marketing slides of a new product 😉

    There were many SAP notes that needed to be applied – paints a picture of a very immature product. And support from SAP on Gateway related issues leaves much to be desired. I would have thought that SAP support would have been beefed up to get as much traction for Fiori and Gateway as possible. The SAP documentation on the subject is also at it’s usual “cryptic” best. Depending on how far you want to go with this – also consider getting some Workflow expertise if you don’t already have this.

    The issue that stood out the most for me was the lack of clean LDAP integration. Considering that almost every SAP customer would have LDAP/Active Directory in their landscape and this type of solution lends itself to this type of SSO requirements.

    Last comment (advise) would probably be to not invest too heavily on an ABAP Gateway Hub – for me it doesn’t make sense and doesn’t factor into account any diversification further down the line, e.g. if you want to OData enable not just SAP Backends but other sources as well. Get your Architecture team doing some medium term planning for a solution like Integration Gateway for Java. Especially if you also have SAP PO deployed in your landscape. Otherwise your hardware costs start escalating.

    (0) 
    1. Saumil Jyotishi Post author

      Thanks for your comments Trevor.


      About your first comment: Yes, if you do have people who can play the roles mentioned, you can do it in house. Absolutely agree on Workflow skills. Its very much needed if your working with any approval app.


      About Notes: I agree. It was a nightmare for us as well in the initial projects. Its very easy in Fiori projects to go over budget because of the unpredictability. Also, a lot of customers try this first in a sandbox system where nothing is configured functionally which makes it difficult to run a scenario. Its important to remember, Fiori is a new face but heart and soul of the system are same.

      Now the situation is improving as the apps are becoming more stable (I will let you know in our next project 🙂 )


      About Gateway support: Agree. SAP needs to improve this. I remember a couple of Gateway issues in OSS taking 3 months and still under investigation. In one instance, they got our system upgraded for an issue when it was not needed.


      About LDAP Integration: Agree. They have done it once with Duet Enterprise(an SAP SharePoint integration product) where they built an OData extension provider on SharePoint. On SAP side it was integrated via new External ID for SharePoint and User Mapping facilities of Gateway. I liked it but it was a licensed product.

      If you have seen SAP NetWeaver SSO 2.0, they have this option of integrating via SP Nego but again its a licensed product. It would be interesting to see how this will work with Fiori.

      Capture SP Nego.JPG


      Now on your last comment: There is no definitive answer here. It totally depends on landscape to landscape. You can also expose your OData services from PO stack to your Fiori launchpad residing on ABAP Front End/Gateway Hub (as PO stack now has OData exposure capabilities too). As you would know, Integration Gateway is not a standalone product. It only comes with SMP and PO stack. And, to communicate with ABAP stack it needs NetWeaver Gateway.

      I am not sure where your Frontend Fiori components, launchpad and UI5 libraries will go out of ABAP Frontend.

      Also, as a customer, do you want an Embedded Gateway running on your production? What about your upgrade cycles? Gateway hub could act like an App Firewall for your ERP,CRM systems. Security in Javascript based apps is a concern.

      This again is a topic of a great debate and I have not seen huge amount of Gateway landscapes yet to comment on any one definitive strategy.



        



      (0) 
      1. Trevor Naidoo

        Thanks for the fantastic feedback Saumil – really enjoyed this one. Just some added info on my thought pattern regarding Integration Gateway 😀 …We’re considering establishing an “Integration” CoE of which PI/O, Gateway (ABAP Hub or Integration Gateway) fall under this banner. So one team to manage all “Integration” related topics (PO, Gateway, ALE etc.)

        You need to help me understand your comment below:

        Saumil Jyotishi wrote:

        And, to communicate with ABAP stack it needs NetWeaver Gateway

        Bear in mind I haven’t explored Integration Gateway in-depth but I see Integration Gateway (running on SAP PO for argument sake) work the same way as a SAP NW Gateway Hub on ABAP would. Once you have Integration Gateway (serving as your hub) This would then just require the additional components to be deployed on the backend/s as is currently done for an ABAP Gateway Hub. Are you saying you would need more? I’m not thinking of embedding gateway anywhere :-). That wouldn’t be ideal.

        I’m thinking more along the lines of having a single Integration domain. So a PO install with Integration Gateway bolted on. SMP is a distant memory for us as it doesn’t make sense having (and licensing) similar integration capabilities across multiple SAP solutions (i.e. PO and SMP). SMP didn’t make sense also because we were heading HTML5/SAPUI5/Fiori as the preferred App deployment methodology.

        If you’re saying that if you head towards the Integration Gateway route, you will the need the following (that is if you don’t choose to embed gateway into your backend):

        – Integration Gateway bolted on to a PO Java stack

        – Gateway Hub on ABAP

        – And then your Gateway related components deployed in your respective backends

        Then I think SAP need to go back to the drawing board – because it then sounds like awful design! 😥

        (0) 
        1. Saumil Jyotishi Post author

          You are welcome Trevor.

          Integration Gateway can consume all Non-SAP content like SOAP, JDBC etc and produce OData Services but to consume content from ABAP stack: It can’t just take the RFCs and produce OData content. It needs OData Services provisioned via SAP Gateway.

          Have a look at this blog:

          http://scn.sap.com/community/gateway/blog/2014/03/20/there-is-a-gateway-for-that

          Capture Integration GW 1.JPG

          So, you will need both Gateway Hub and PO with Integration Gateway.

          Now, coming back to your question about Integration COE, if you have to do it this way, I think there are some challenges. I am also trying to understand some of these things:


          This architecture is fine for custom apps where you can expose ABAP content via NW Gateway and use Integration Gateway to consume services and integrate with Non SAP sources. In this case, you can keep your UI5 libraries on PO stack as well and deploy UI5 projects on PO Server.


          But, how will you architect your Fiori then? Where will you place your Fiori Frontend components which are ABAP based and utilize UI5 libraries on gateway hub? 😀

          Now add HANA DB, XSOData services and some Analytics in the landscape. How do we architect this?

          (0) 
          1. Trevor Naidoo

            Thanks Saumil. Yes I see now. I thought it would have been an either or concept. You either choose to go with Integration Gateway or you choose SAP NW Gateway.

            There’s a Gateway for this and a Gateway for that – probably a license for this and a license for that as well :-). Just kiddin’, I know additional licensing costs don’t apply for SAP NW Gateway but now you still need the additional hardware. I just need one Gateway for this and that, that’s all 🙂

            So Integration Gateway provides the tools to design and provision OData services for just about anything – except SAP! – so for SAP as a data source use case it will just serve as an OData adapter & for all other data sources it will act as a real Gateway.

            And SAP NW Gateway provides tools to design and provision OData Services for SAP only.

            Now, if we continue looking at Integration Gateway as a possible option – you can imagine the Support overhead.  You will have OData services provisioned on PO/Java, you will OData services provisioned in ABAP (SAP NW Gateway) – I’m getting a headache just thinking about this 🙂

            I don’t understand why the Fiori (UI5) front end components need to be tightly coupled with ABAP and what would the limitation be to deploy on on a Java stack? I know it’s maybe a question for SAP instead of you 🙂

            Regards, Trevor

            (0) 
            1. Saumil Jyotishi Post author

              I like your writing style Trevor. Could not stop myself from smiling 🙂

              May be Masayuki Sekihara can enlighten us.

              One reason, for this type of architecture, could be because of the fact that they have already invested a lot in Gateway & service provisioning/consumption is relatively easier when you are closer (native in this case) to ABAP systems?

              Regards,

              Saumil Jyotishi

              (0) 
        2. Saumil Jyotishi Post author

          Hi Trevor,

          I got to know that architecturally you could also use PI (REST Adapter) to expose content from ERP and consume in Integration Gateway in PO.One good use case for this could be exposing workitems from ABAP stack (using Task Gateway) and consume in PO.

          – Saumil

          (0) 
  3. saee sai

    Dear Saumil,

    with 500 ready made apps & more standard apps to come,

    what would be the role of custom firori development needs for HANA on cloud

    S4 HANA on cloud

    S4 HANA on premise

    thanks

    (0) 
    1. Saumil Jyotishi Post author

      Hi Saee,

      I do not know how current Fiori apps will be packaged into S/4 HANA, but as far as we know today, the primary extension platform for S/4 will be Hana Cloud Platform.

      ABAP changes/extensions are simply not allowed in public cloud deployments of S/4.On the other hand, they are allowed in Private cloud and On Premise versions.


      I personally think, in Future SAP landscapes, extensions will be performed on some/all of the following layers depending on the depth of your extension:

      a) HANA Layer – Extensions for views/procedures/xsodata

      b) S/4 Suite Layer (Business Logic) – HANA Cloud Platform, ABAP Extensions for On Premise and Private/Managed Cloud and who knows, in future, may be ABAP in HCP!

      c) UI Layer – UI5 Extensions with Web IDE

      d) Extensions on SAP NetWeaver Enterprise Search – Any extra field to search on

      May be more…

      I am also waiting for Sapphire 2015 for S/4 HANA deep dive and roadmap.

      (0) 
  4. Joao Sousa

    What is your experience with productive support for Fiori Apps? You said support for Gateway was very poor.

    I’m asking this because most Fiori apps are actually quite simple (they should be since the business logic should remain on the backend) so I have to wonder if depending on SAP support for this is the right call. It should be, that’s why you pay licensing, but is there a real advantage not going the internal UI development route where you can really optimize your own processes?

    I avoid SAP support as much as I can. SAP keeps saying that it must go cloud to survive, but from my experience customers leave SAP because of a) price and b) lack of adequate support (for the price) – not because of the cloud.

    As a side node, I don’t understand why SAP says it will lose margin because the cloud is more competitive, and fail to address the fact that their on-premise software also competes with that cloud. If they accept losing margin in the cloud because of the competition…. why not accept losing margin in on-premise which has the same competitors?

    (0) 
  5. Ryan Fleischmann

    Great post.

    I’d add that clients should become familiar with SAPUI5, and to know SAPUI5 is know jQuery and advanced JavaScript/HTML5.

    Given that there’s such an abundance of great learning material specifically geared towards HTML5, jQuery, and JavaScript — that’s the best place to start learning/working in before getting into SAPUI5 Fiori. Once you gain mastery in those areas, SAPUI5 and Fiori should a breeze.

    I would contend that Odata/Gateway doesn’t *need* to be used, so long as you have some kind of web service that provides XML/JSON. Odata is just an extension of JSON with features you may or may not use.

    (0) 
    1. saee sai

      Dear Ryan,

      great reply, can you elorate on, how or scenarios, where at UI5 developer, would have continuous work / enough load to be dedicated SAP UI5 resource.

      standard ERP comes with almost all pre-built UI and why does a company need a dedicated UI5 guys to work on, if they need, what will he be doing ? 

      (0) 
    2. Saumil Jyotishi Post author

      Thanks.

      Agree with your point that UI5/Javascript skill is a must for every Fiori discussion. That’s why I mentioned UI5 as a skill in my skill map BUT its a misconception that if you have expert skills in just those areas “Fiori should be a breeze”.

      It will not be.

      I see a lot of experts talk only about UI5 when they talk about Fiori Apps.

      I understand the point if you think of Fiori as a “UX Paradigm”. But, if you talk about “Fiori as a set of apps for a business function”, going to a customer & configure their landscape for Fiori, configure Fiori Apps and assess the depth of customization, “Expert in UI5/JS” is just one of many skills you will need.

      Equally important is the need for someone who understands OData/Gateway/Launchpad Object relationships, someone who has Functional knowledge of the ERP configs, HANA Developers for Analytics/KPIs/OpInt/XS, ABAP Developer who understands Enterprise Search  for Factsheets and Enhancement Framework, someone who can understand the Connections/SSO……and so on..

      So in short, if a customer asks you to put a Fiori Purchase Requisition Approval app on top of their heavily customized PR workflow, you need to get your MM and Fiori/Workflow expert to talk to them first 😉

      (0) 
    3. Saumil Jyotishi Post author

      Also, on the point that “You do not “have” to use OData/Gateway”

      Fine for custom apps on a non ERP backend but for a ERP backend, using standard apps, there is no other way.

      For custom apps you can hand crank the REST services in ERP without Gateway but whats the point of not using it when you have it for free.

      (0) 
      1. saee sai

        so it does mean that,

        either ABAPers pick up SAP UI5 and have a blast

        or

        HTML/CSS guys pickup SAP UI5 + ABAP  (including OData/GW) and have blast too

        until them, implementations need both UI5 guys and ABAPers right?

        what if the all customers go ahead with cloud and very few on-premise, in that case too we need ABAPers ?

        (0) 
        1. Saumil Jyotishi Post author

          I guess ABAP is fully allowed in Managed/Private Cloud. Who knows if SAP is working on a cloud version of ABAP in HCP as well.

          I think the stack is becoming too vast for one to become “God of all things”.

          There will always be a separation of skills with a few UI5 developers crossing over to ABAP/ HCP and vice versa(not very sure about that).

          (0) 
      2. Ryan Fleischmann

        I agree that Gateway/Odata is the preferred option – but the alternatives I put forward do have a valid context.


        ‘Hand-cranking’ your own REST service is useful to keep in mind when you have a scenario in which you:

        -Are not yet on an enhancement pack that allows you to use gateway/it hasn’t been fully configured

        -Have a separate web application deeply integrated into SAP ERP, but may be stuck in some issues trying to use Gateway (ex: cross-client, authentication, etc)


        When you’re in such a situation, you’re really in a ‘chicken-and-egg’ type dilemma. You want show the benefits adopting a few new technology and UX paradigms, but you seemingly have no tools available to you to really lead the way. What I’m driving at here is that you really do.


        Having functional experts for new applications, be they Fiori or not, is always considered a given.


        They key here is to really get your coworkers and clients to see Fiori (and the HTML5, modern UX paradigm behind it) not as some monolithic thing that will incur loads of huge new costs, many hours of difficult training, and not work for several months/years (because frankly — that’s the expectation some users have of SAP). Instead, show that it is possible to do some smaller web application projects to which we can identify a clear ROI and complete in several weeks.

        (0) 
        1. Saumil Jyotishi Post author

          Hi Ryan,

          Interesting points.

          I will not hand crank the REST service unless there is absolutely no other way. It would not be ideal for a longer run and standard Fiori apps needs Gateway.

          – If you are on a lower version, I would rather suggest to put IW_BEP in your backend and setup Gateway as a central hub. IW_BEP supports lower versions of your ERP

          – If thats not possible and you do not have an upgrade planned for a long duration (not an ideal case), you can go with fully Central Hub Gateway installation for a custom app.

          – If you have cross client issue in productive or sandbox, I would prefer fixing those rather than creating your own REST services without OData.

          – If you are on a PO stack, you can create OData signatures using Olingo and odata4j.

          Such decisions should always be taken keeping in mind your landscape and upgrade strategy.

          Now about the messaging, I agree that simplicity, responsive screens, reduction in training, new UX paradigm should be THE messaging. All I am saying is, it should not be the ONLY messaging.

          Right now, due to this messaging Customers and Functional consultants who are not updated or aware of new things (Ideally, they should have this know-how and Fiori is not very new) think that this is something completely new. As far as the transactional apps are concerned, they should know that “Face” is new but “Heart and Soul” is same.

          So like any other project, for Fiori, they will need a well balanced team too.

          cheers!

          (0) 
  6. Lino Magpantay

    Hi,

    How did you control which app can be displayed internally or externally in fiori launchpad? Is there a configuration in SPRO to know if the access is coming from In-Network or Outside Network?

    (0) 

Leave a Reply