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 2022, 2021, 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


      Author's profile photo Lisa Schmidtchen
      Lisa Schmidtchen

      Thank you for your post.
      We are working on a S/4 HANA 1809 and were trying to activate business roles via rapid activation.

      In step 3 "Prepare CTS Set transport options for to be activated OData Services" we can only select Local Change Requests. Not transportable. Same with transaction /IWFND/MAINT_SERVICE.

      Do we have to change the target of the transport request afterwards to transport it to quality and production?

      Kind Regards


      Author's profile photo bharat bajaj
      bharat bajaj

      Hi Jorge Baltazar

      CC : Jocelyn Dart


      I am doing the rapid activation using SAP_FIORI_CONTENT_ACTIVATION in a brand new multi client S/4HANA 2022 development system (client 100, 200, 300 ...)

      I have concerns about the below 2 steps :

      1. Activate OData Services (/IWFND/MAINT_SERVICE)
      2. Publish Service Groups (/IWFND/V4_ADMIN)

      Activate OData Services (/IWFND/MAINT_SERVICE) 

      In this step, some of the OData V2 services are published with "co-Deployed only mode while some are publised with "Routing based" mode and a system alias is added. However, the system alias entry is not captured in the customizing transport request.
      Due to this, the same odata services does not work in other client (200, 300..) even after client copy SCC1 is done.

      2 questions here :

      1. How does the task list determines which processing mode to use for an OData service (Routing vs Co-deployed)?
      2. How to include the system alias entries in the customizing TR during the rapid activation


      Publish Service Groups (/IWFND/V4_ADMIN)

      The OData V4 Services are published in this step, but they are not captured in transport request.

      That makes it really challanging to publish them in each client and target system manually.


      2 question here :

      1. Why SAP designed this step like this, to not include them in the TR?
      2. Is there any other way to mass activate those OData V4 Service groups in the target system?


      Hope you can help to clarify.


      Bharat Bajaj