Transporting Fiori Objects…Untangle the knots!!

Fiori, now the not so new user experience (UX) . We all know how cool it is. Initially, some of us were resistant and struggled to accept it , but as we learn more about it,more we started getting addicted to it and why not … who doesn’t like better :)…

The initial challenges were to understand the architecture, so many manual steps involved in setting it up and then activating so many service be it OData, UI5 , Search connectors, creating user roles and assignment and what not.. and  that’s why the feeling of why to change … but some efforts are worth the investment and believe me it is one of them…

But, at the same time SAP too understands the challenges and always comes up with better solution to make our life easy and that where i am talking about the Fiori activation tools. The latest being the Rapid Fiori Activation ( please check the details in this blog by Jocelyn Dart ). So, now our life is easy, we will just identify the required Fiori apps from Fiori library, download the business roles for the same and activate the same using Rapid Fiori Activation and we are ready to use apps.. wonderful… 

and If we need only specify apps from the catalog, quickly create a custom catalog with apps of choice using Launchpad content manager (check this blog by Sibylle Brehm )….

Life is all cool and easy isn’t it…. No, not really, that is what we realize when we reaches a stage when we want  the activated/Extended or custom Fiori apps in the next landscape system… oops..we didn’t even think about it so far….

So, how are the Fiori objects transported across systems? what all objects we need to move? do i need to activate apps in each system? how are my catalogs and groups going to be moved…. suddenly all these question start haunting us…

I search for the answers to all these, any documents around it and realized its all spread over the forums but in bits and pieces and takes lot of time to gather and understand..

That’s why, i thought of putting it together, so that it could help people, new to all this.

Lets start…

HUB Deployment Scenario

As we know,Standard Fiori activation involve multiple steps and each step requires a transport…

In case of custom app the, we need have below additional steps.

When we perform all the above activities the following are  objects and the transport type, they gets locked in…

Front End System :

Below Transports Carrying the respective objects will be transported to landscape Gateway Systems

Backend System :

Below Transports Carrying the respective objects will be transported to landscape Gateway Systems

Embedded Deployment Scenario

In case of embedded deployment scenario, all the activities will be performed in the same system, but the same objects in corresponding TRs will need to be moved across systems.

In this case , Rapid Fiori Activation can be used for activating apps and it generates the Workbench and Customizing TR’s with activation objects mentioned above ( OData activation , System alias, Z user roles )

The workbench request records data for the OData and ICF service while the customizing request records the system alias assignment to the OData service.

What need to be done in target system after Transport movement.

Is it enough to just transport the above mentioned transports to the next landscape system and we are good to use apps there??..and the answer is NO.

UI5 services need activation in target system

This ui5 notes will need activation in each system. So, does that mean we need to manually active the ui5 node in SICF? or Can we use Rapid Fiori Activation tool there to active ui5 apps?

Rapid Fiori Activation can’t be used just for ui5 activation part.We can activate them manually in SICF, if it is few.

In case we have many ICF nodes to be activated we can do the mass activation and deactivation  using the standard reports and that will do the trick for us.

• RS_ICF_SERV_ADMIN_TASKS  – Export the Active Nodes in the CSV file

• RS_ICF_SERV_MASS_PROCESSING – Import the CSV file in the target system

System Alias need to be aligned to the correct RFC destination.

As, system alias points to the respective back-end system RFC destination and that will be different in each system.

The approach could be to transport the system alias with generic name and configure it in target system to point it to the required RFC destination.

System alias can be directly maintained in target system under the maintenance view /IWFND/V_DFSYAL.

Please refer to this blog from  Andre Fischer for more details on SAP system alias maintenance in productive system.

With this we have come to an end. Hope this will help you to gather your thoughts together on Fiori objects transportation.

Keep Learning & Keep Sharing!!

Vijay