Skip to Content
Author's profile photo Saumil Jyotishi

Fiorifying your ERP System – Ingredients of a successful Fiori Implementation – Part 2

In part 1 of this blog series (you can read it here –, I have tried to outline what all things you need to think about when planning your Fiori implementation. In this blog we will discuss the actual implementation itself. Scenario we are using as a topic of discussion here is Leave Management with some extensions.

Get, Set, Go! Starting the Implementation

Once you have a plan in place, you are ready to work on the pre-requisites for your implementation.

Step 1: Test core functions well in ERP!!

This is probably the most ignored step but the biggest time saver. Fiori uses same good old ERP core functionalities. So you need to make sure that you can perform these core functions in your backend sandbox/development system.

For Example, in Leave Management scenario, you may ask yourself following questions:

Are you able to create a leave from transaction PTARQ? Does it trigger the right workflow?

Are basic workflow configs in place for Leave Approval workflow? (Workflow customizing configs, Event Linkages, workflow definitions are active, human tasks are made as General Tasks, Org Structure and Agent Assignment as per Org Structure etc.)

Have you activated ESS Business Function? (Surprise! Yes you need it!)

Have you made your leave quotas available for use in ESS (Along with basic quota configuration)?

Are Team Calendar configs available in MSS for Leave Approval Apps?

And so on…

Take another example.

If you are interested in purchasing related apps (Like Order from Requisitions, Track Purchase Order or Approve Purchase Order), in the backend system, you should be able to create POs, Create PRs, have a release strategy setup, tested standard workflows and so on.

If you don’t know this bit, your partner or architect/functional consultant should be able to help you explaining which app uses what in the backend.

If your backend is not in place, you are destined to face horrible problems when you put Fiori in.

Step 2: Set up systems and perform the installation and initial configs

Once you have done your landscaping its time for basis team to step in and start the install.

Then, once right components are in and services have been activated, your architect can help basis team perform Gateway configuration (different Types of RFC Destinations, System Alias for various services and Task Gateway etc.) and do a connectivity check between systems.

Now you are ready to put the Fiori Components in. For each app, there is a relevant UI Component and a corresponding OData/Backend components. In case of Central Hub generally, UI components go on Gateway Hub and OData components go on your backend.

For Example: In case of Leave Creation App, UI Component is UIX01HCM 100 and Backend component is GBHCM002 600. 

UI Components can also be common across many apps. Once components are in place you need to activate and register the services on Gateway.

For a basis consultant reading this blog, you have to be careful as to which activities here are transportable and which ones are manual. It will help you prepare the right cutover plan before go-live. Also, apart from this you should have a close eye on what notes are available for the apps in your scenario. Keep an eye on what patches/notes are coming up in this area.

In short, this is a work of close coordination between your architect and your basis team. Having seen a few setups now, I can safely say that its very hard to do these things in isolation.

Step 3: Perform App specific configurations if needed

For Approval Apps, you will need a specific configuration telling Fiori what workflow tasks to use for which app. These configs are explained in the configuration section for approval apps in sap help.

The documentation also talks about relevant details about the Launchpad configuration for each app (Semantic Objects, Role for LPD_CUST etc.).  Personally, I prefer to do this as a separate activity later along with Launchpad Designer configurations.

Tip: If you get an unending spinning wheel when you open an approval app, you have missed this scenario configuration or you have done it wrong.

Step 4: Test the standard App via SICF transaction on your Gateway system

Now you can test your app via sicf transaction or may be wait for next step and configure Launchpad before testing. Full SICF service paths are available in the Fiori documentation.

Step 5: Launchpad config for your Apps

In order to enable tiles for your apps on Fiori Launchpad, you need to perform Launchpad Configurations.

For custom apps, majorly there are 4 steps involved for this set of configs.

    a) Creating/Enabling Roles in LPD_CUST transaction in your backend system

    b) Create Semantic Objects in a defined IMG for each app

    c) Launchpad Designer Configuration (Creating catalogues, adding them to group, creating tiles)

    d) Creating/Enabling Roles with appropriate Catalog for each app

Tip: Some of these configs have to be added manually to a Transport!

There are some good blogs/How-to guides on SCN for this. Below are a couple of links explaining how to add custom app to Launchpad.

For standard apps, you only need to to step d) above with right Catalogs and Groups.

This is a fairly quick activity even if you do not understand Launchpad Object Relationships but its recommended to understand it before you play around with Launchpad Designer.

Step 6: Perform Extensions

Once you have tested the standard app via Launchpad, you are ready to perform modifications.

This is where your UI5 and ABAP developers come into picture. The extensibility documentation of each app helps you identify all the views and associated enhancement points and dictionary objects to modify.

The approach, I personally prefer here is top-down approach. You determine what you want to see on UI, do some mock-ups and once you are happy, have a look at how can you support this new field or screen from the backend (Dictionary Enhancement->API Enhancement->OData Wrapper Enhancement).

Note: Approval Apps are always related to a workflow task. These apps pull data from the task containers.

So, even if you have a custom task, you should be fine unless you have done major changes like change the activity type from standard activity to user decision.

As for ABAP developers in particular, skills needed are Enhancement Framework, OO ABAP and Gateway development skills.

Step 7: Final Tests and Transport Planning

When you have tested the application in dev., its time now to transport the extended solution to QA where you can get multiple business users to test the apps with the help of your HCM consultant. Generally you would perform the installations and system specific Gateway/Fiori configs (like RFCs/Alias) on each landscape but things like Launchpad roles and your extensions can go via usual transports in both Gateway and Backend Systems.   

And finally, as usual, if business users are happy in QA, you can perform the cutover and request a downtime for a technical or full-fledged go-live.

To summarize, implementing and extending Fiori Apps is not difficult if done with right tools, technologies and people. Along with UX renewal these apps can provide a significant business value in a very short span of time. Happy learning and please share you feedbacks!

Next blog/blogs in the series would be for Analytical and Factsheet Apps.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Masayuki Sekihara
      Masayuki Sekihara

      Hi Saumil,

      Step 1: Test core functions well in ERP!! is the golden rule. I see some projects do it at very end of project.


      Masa / SAP Technology RIG

      Author's profile photo Saumil Jyotishi
      Saumil Jyotishi
      Blog Post Author

      Hi Masa,

      Yes, this is really step 1. A lot of times this is generally done near the end, while tracking down and fixing horrible problems.

      Author's profile photo Joao Sousa
      Joao Sousa

      You determine what you want to see on UI, do some mock-ups and once you are happy, have a look at how can you support this new field or screen from the backend (Dictionary Enhancement->API Enhancement->OData Wrapper Enhancement).

      Have you ever come to the conclusion that the effort to enhance is just too great and a custom app would be better?

      For example in the create sales order I miss the ability to change the shipping location to a different plant, and it's kind of structural.

      Author's profile photo Saumil Jyotishi
      Saumil Jyotishi
      Blog Post Author

      You have a point but it depends on your case as well. We have not seen any scenario yet where we had to drop the extension in favor of custom app creation. At the time of wave 1, situation was different as there were not enough extensibility options available but now its better.

      I think, sometimes extensions are more useful than building a whole custom app. Some customers just need simple things to start with. For example: You can easily add the capability to post a Goods Receipt (via Extensibility Options) in Track PO App and your posted GR will start appearing in follow-on documents page in standard app. Standard GR App in Wave 2 in just a Factsheet.

      Also, I would advise to register on SAP Jam to see what new feature are planned for next waves. This is to make sure you do not build anything which is already in SAP's Roadmap. We have made that mistake before. But in our case, customer knew it was coming but wouldn't wait.

      Before Wave 7, Team Calender was available as part of Approve Leave Request App. We built this for a customer (Reusing OData from Approve Leave Request) and after a month SAP released a similar app.

      Since both, apps and their documentation are rapidly evolving, knowing what exists and whats coming is of great help.

      But in the end, like you said, if the efforts are more for extension and changes are more fundamental, you can see if you can do modifications or implicit enhancements. It might save some effort? Though, it will be a pain at the time of upgrade.

      Or you can go with custom app development where you can always copy backend APIs and OData layer and do whatever you want with it 🙂


      Author's profile photo Bushair Thayyil
      Bushair Thayyil

      Dear Saumil,

      Thank you for the excellent blog. waiting for the next blog on Analytical and Factsheet Apps. We have EHp7 on DB2 BLU. and would like to see the performance of these apps in BLU in analytic workload mode. Do you have any experience?


      Author's profile photo Rahul Choudhary
      Rahul Choudhary

      Hi Saumil,

      Thanks for informative blog. Does all these steps also holds valid if we are build Fiori app on top of GRC instead of ECC? Also is there additional steps if we are building a custom app from scratch instead of extending an existing one?


      Author's profile photo Saumil Jyotishi
      Saumil Jyotishi
      Blog Post Author

      Hi Rahul,

      These steps are valid for all Non HANA Transactional apps.

      For GRC specific apps you can search app reference library by business area:

      Fiori Apps Library

      Apologies if that was not very helpful.

      Author's profile photo Former Member
      Former Member

      Hello Saumil Jyothishi,

      We have our ECC EHP7 SP7 system running on HANA.

      We would like to have is analytical app (Purchasing Spend Comparison). For that, we have installed Front end software "UISERP01 100" for this analytic app but we are not able to see anything in Fiori Launchpad.

      Can you please guide me how can I see Purchasing Spend Comparison App in Fiori Launch Pad. What configuration steps I need to execute after installing Front end app


      Bhupesh Pant