Skip to Content
Technical Articles
Author's profile photo Jorge Baltazar

SAP Fiori for SAP S/4HANA – SAP Fiori Rapid Activation: Transport from Development to Production systems

Relevant for SAP S/4HANA 2020, 1909, 1809, 1709

With the release of SAP Fiori Rapid Activation back in 2018, SAP provided a procedure to mass activate SAP Fiori Apps. The focus of the early release of Rapid Activation was to be used mainly in Sandbox systems for the discovery and explore phases of a project based on the Activate methodology.

Based on the positive feedback from multiple customers SAP now provides transport options for the task lists in Rapid Activation meaning you can use this procedure in your Development system and transport content to your after-Development systems like QA, Pre-PRD and PRD. By doing this you will save time and effort when activating SAP Fiori in your landscape.

SAP has provided a central note with information on how OData services activated through task lists in Development system can be activated again in the Production System: SAP Note 2886433 – Fiori Setup: Activation of OData Services in Prod Systems with task lists. However, we are aware that you may need additional guidance depending on your project status, hence, the SAP S/4HANA Regional Implementation Group (RIG) has created a brief document explaining the procedure to move content from your Development system to after-Development systems based on the following procedure:

  • Run Rapid Activation in Your Development system with transport options active.
  • Move Transports to subsequent system
  • Run Rapid Activation with only a defined subset of tasks

By doing this, you will ensure your complete SAP Fiori landscape is active and configured with the same parametrization and the exact same content is available across your landscape.

You will find a detailed guide here: SAP S/4HANA Fiori Rapid Activation Transport Move To Production Strategy

Please note that for the described scenario we recommend defining a transportable development package and using this package while running Rapid Activation. Package reallocation is currently not covered by the task list but can be done manually through transaction SE03.

I’d like to thank my friend and colleague Van Vi  for his dedication to create this document.


Becoming an SAP Fiori for SAP S/4HANA guru

You’ll find much more on our SAP Fiori for SAP S/4HANA wiki

Let us know your questions in the comments section.



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Luiz Felipe Ramos Machado
      Luiz Felipe Ramos Machado

      Hi Jorge,

      Great reading. I found the document really clean and straightforward. I had this very question in my mind on what would be the best practices to avoid re-work or overwriting configs.

      I have to say, SAP is making the Fiori activation easy and fast which helps in the customer adoption.

      Thanks for sharing!

      Author's profile photo Surajit Pramanick
      Surajit Pramanick

      Excellent blog, Javier and Van! Just the right amount of information with clear guidance. Thank you!!

      Author's profile photo Pablo Marichal
      Pablo Marichal

      Thanks for this post, It's a good path to follow for the implementation of the Fiori Rapid Activation in the whole landscape. Until recently I've had several doubts if I needed to implement these tasklist over and over again in every system, but with these approach it's very clear and faster than ever to do the whole process.

      Author's profile photo Deep Agrawal
      Deep Agrawal

      Hi Jorge,
      your Blog & Document suggests Activation steps on After-Development systems.

      Does that mean cut out Activation steps have to be done on Production system - what if the Prod is not open?

      Author's profile photo Jorge Baltazar
      Jorge Baltazar
      Blog Post Author

      Hi Deep,

      Yes, you need to run the steps in PRD. Overall this would be creating RFC's and scheduling jobs, for this the system does not need to be open.

      When you run the task lists in PRD, if you select the tasks listed in the document, you do not need to have the system open as these tasks do not update/modify configuration in the system. All client dependent config is moved via transports.


      Author's profile photo Achim Vornberger
      Achim Vornberger

      Currently I try to activate Fiori using the mentioned guide. But I have to say that the guide is not up to date at the moment. Some points, for example UCON, are not mentioned.

      But the main problem is that the guide is not working as promised. Maybe it is also a problem with the current versions of the task lists. But for example the guide says active "Set SAP System Alias" in SAP_GW_FIORI_ERP_ONE_CLNT_SETUP. But the mandatory predecessor is to create the transports. So you cannot use the task list in QAS or PRD without creating transports again.

      And I'm also struggling with the aliases in "SAP_FIORI_FOUNDATION_S4" because the entries "S4.." in the view /UI2/V_ALIASMAP  are recorded in DEV but the view is still empty after the import in QAS. And I have no idea why. The objects are in the transport, and the import ends with RC=0.

      And some of the "Add Alias" tasks also create an RFC. So you cannot skip these tasks and so as consequence you have transports in DEV, QAS and PRD. I don't think that this is the expected behavior

      Author's profile photo Jorge Baltazar
      Jorge Baltazar
      Blog Post Author

      Hi Achim,

      Thanks for your comments, I'll try to help solve some of your issues.

      On the UCON topic, not all customers require whitelisting HTTP connections, if needed, it would be required by a customer specific use case that would not make sense to add on a generic document. If you believe this setting does need to be added, please elaborate your needs and we can decide if this is to be updated in the document.

      On task list SAP_GW_FIORI_ERP_ONE_CLNT_SETUP, yes, there were some updates to the task list but that does not mean the document is not useful or misleading. This task runs two activities:

      1. Create RFC FIORI_FLP_HTTPS - Please note that RFC's are not transportable objects and would require you to create them manually on each system in transaction SM59, this RFC is thereby not added to any TR in any version of the notes.
      2. Create custom system alias FIORI and map to target alias FIORI_FLP - Both these aliases are added to tables /UI2/VC_SYSALIAS and /UI2/V_ALIASMAP and these objects should be added to the TR you've defined and successfully transported to your upcoming system.

      Understanding what the task list does, would then allow you to safely uncheck the task "Set SAP System Alias" in your configuration process in QAS/PRD and move the transport to your upcoming system while we update the document.

      On the transport from SAP_FIORI_FOUNDATION_S4 kindly create an incident to SAP specifying the note version implemented in your system as this issue had been identified and solved in version 15 of note 2712785, there is a possibility for this bug to reappear hence the proposal to create an incident and better analyze your situation. Consider that implementing the latest version of the required notes is mentioned in page 8 of the document and even if you are on the latest and greatest version of S/4HANA and the ABAP stack you still need to update the notes.

      Hope this helps,


      Author's profile photo Achim Vornberger
      Achim Vornberger

      Hi Jorge,


      regarding the UCON, from my perspective “Virus Scan Profile Configuration” is also optional, because many customers do not use the virus scan interface. But it is mentioned and UCON not. And both are preselected when you start the task list. I do not think this is straightforward 😉


      “Set SAP System Alias”: In this step transportable and not transportable steps are combined in one step. Why? Why not one task for the RFC and one task for the aliases.


      “Understanding what the task list does”: First of all I like the idea behind the task lists. But some steps are not very well documented and so it is hard and sometimes impossible to know what the step is exactly doing. And in many cases the error messages when a task is failing are also very short and imprecise.


      My impression is that many customers and also consultants do not use the transports and instead they prefer the local configuration. But I would prefer transports like in any other parts of ABAP coding and configuration.


      Kind Regards