Make your FIORI Go Live easy

[sreehari_vpillai]

Introduction

In this short blog, I am describing the activities to be performed to make a successful SAP FIORI transactional application implementation go live on my experiences. Unlike normal ABAP level go lives, some special activities are to be performed as part of FIORI implementations. We consider a hub architecture for reference landscape of implementation

Netweaver gateway system has 3 servers, development, quality and production instance.

Development Objects

The types of development objects and configuration objects are listed below along with the respective activities.

Gateway system –

1. Development Class(package) –

     The Development package in Gateway system(Transportable via a workbench request)

2. BSP Applications –

     Whenever we create an enhancement of a standard UI5 application, a BSP application will be created in the ABAP repository where we are deploying the application. In our case, the BSP applications will be created in Gateway 200 system. Same is applicable for FIORI like applications which we develop in the system as well. These are transportable through a workbench request. When we deploy the application from Eclipse IDE or Web IDE, a workbench TR number will be asked for transport.

3. Initial configuration –

     Initial configuration involves the following activities in general

1. A) Activation of SICF services – We need to do this activity in all the gateway systems
2. B) Assigning LOCAL alias for Launchpad services – This activity is tracked in a workbench request and we can transport this to the target systems
3. C) Configuration of Login page – To configure a login class, please follow the document http://scn.sap.com/docs/DOC-59371 . There is a standard class /UI2/CL_SRA_LOGIN which we need to use for configuring the Login and logoff page. In my suggestion, instead of using the standard class, extend the class to a custom class (Z object – Yes the base class is not Final) and redefine the required methods to change the logo, branding texts and CSS properties if required. You need to upload your icons, css file etc in MIME repository and track these objects in a workbench request.

4. OData Registration –

For standard applications, SAP delivers standard OData projects in the back end system (Here ECC 200). We will need to register the Odata services in the corresponding gateway system (Gateway 200). When an Odata service is registered in gateway system, it will create the following objects in gateway system and track it in a workbench request.

1. A) Service Model Metadata
2. B) Service Group Metadata
3. C) ICF Service
4. D) Model identified and data provider implementation definition

In addition to this, it assign an Alias name to the Odata. This activity is not tracked in a TR normally, and they are not transportable.

Why? – The alias name we assign to the Odata service in Dev landscape is not same as QA and production. In our case, in GW Dev 200, the alias name is ECC_DEV where as in GW QA 300, alias name is ECC_QA. Even if we manually assign the alias assignments manually in a Customizing TR, in the target system, it is going to throw error.

How to bypass – We have two options with us.

1. A) Use the same alias name throughout the landscape( a generic name like GW_ECC) so that the transport will be smoother
2. B) Open the target client to do customizations(which means, we need to manually run the /iwfnd/maint_service tcode and assign alias manually for each service as part of live activities)

5. Coming to the Launchpad configurations –

All the configurations we do in Admin page will be tracked in a customizing request. By default, it will not be stored anywhere. We need to manually assign a Customizing request and transport it to target systems. Below objects are included in this

1. A) Catalogs
2. B) Groups
3. C) Tiles

6. Semantic Objects –

Semantic objects are to be created and transported in the below cases. These are tracked in a customizing requests

1. A) When you have created custom FIORI Like applications and configured in Launchpad
2. B) When you have enhanced an application and configured in Launchpad (Normally, in this case, you can use the standard semantic object itself. But, consider the My Inbox application, scenario specific tiles. Multiple enhanced version of UI will be configured in the launch pad and you cannot use the same semantic object. So , we will need to create separate Semantic objects )

7. Launchpad instance ( LPD_CUST – Launchpad Customizing)

Launchpad instances are not automatically tracked in any transport request. We need to manually perform this activity by clicking the transport button. This activity will prompt for a customizing request

Below are the cases you need to create Launchpad instances

1. A) When you create enhanced UI projects
2. B) When you create Custom FIORI Like applications

8. Gateway Roles

You can start creating gateway roles once you complete the step 3. Once the service are activated, it will create hash values for the services and which will be used inthese roles.

We can either transport the roles or we can manually create them in target clients. It depends on the customer policy. I used to transport the Fiori end user role and application specific roles. For each application configured in the Launchpad will be having one role associated.

9. Caching of application

To enable caching of resources, we need to implement the BADI /UI5/BADI_CONFIG_HTTP_HANDLER in the gateway system. It will be a good idea to keep the cache expiry time as 1 day before we move the applications to production system. If any changes or corrections are required in the application after the go live, we can correct them and the changes will be reflected for the user from the very next day itself.  It is not a good idea to let the users clear their browser cache after implementing the changes especially when the number of users are huge. Once the applications are stable, you can set the cache expiry time to a week or a month. This will increase the performance of applications.

10. OSS Notes –

     OSS notes applied for the applications/Launchpad will be tracked in Workbench requests and to be transported. This activity should be done with care :oops:

11. Custom themes –

All the custom themes created for Launchpad and applications to be transported.

Back end / ECC activities –

1. OSS notes transport –

All the OSS notes implementation will be tracked in Workbench requests and these are to be transported to the target systems

2. OData Project enhancements –

OData projects might be redefined or created custom OData services based on the requirement. These will be tracked in Workbench requests and to be transported.

3. Enhancement implementations –

All the enhancement implementations to be transported (Which may include Customizing requests and Workbench requests)

4. Roles creation and Transportation of roles if required.

Enjoy

Sreehari -