Technical Articles
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.
Thanks,
SAP S/4HANA RIG
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!
Excellent blog, Javier and Van! Just the right amount of information with clear guidance. Thank you!!
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.
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?
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.
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
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:
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,
JB
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
Achim
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
Lisa
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 :
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 :
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 :
Hope you can help to clarify.
Thanks,
Bharat Bajaj