Technical Articles
How to transport Fiori like applications using SAP Solution Managers Quality Gate Management
Authors
Updates
- 22.03.2016 Added information how to make objects that reside in $TMP transportable.
Introduction
In this document we want to describe how to handle the software changes of a project that encompasses the development of
- an OData service in SAP Gateway and
- the development of a Fiori like SAPUI5 based consumer application
that is deployed on the SAP Gateway server using the Quality Gate Management (QGM) which is part of SAP Solution Manager.
The scenario described is also applicable to projects where SAP Fiori applications and the underlying SAP Gateway service are extended and where the changes need to be transported through a typical 3-system landscape.
A big plus for both scenarios is that the complete life cycle management of a SAP Gateway service and the corresponding consuming SAP Fiori like application can be managed using the well known SAP Change and Transport System of an ABAP system.
The only problem however is that service development and consumer application development are usually carried out by different developers. In addition complexity is added by the fact that during the development process of an OData service repository objects and customizing data are created in the SAP Gateway Backend and SAP Gateway Server whereas the development artefacts of the SAP Fiori like application are only created on the SAP Gateway Server.
As a result 1 customizing request and 3 workbench requests in 2 system landscapes have to transported in synch between the SAP Gateway server and backend systems as shown in the following picture.
This is where the Quality Gate Management (QGM) comes to the rescue. QGM allows for the creation of so called changes which can contain one or more workbench and customizing requests in different systems. With the help of QGM the workbench and customizing requests that have been assigned to those changes can be transported in synch and the process can be controlled and monitored centrally from SAP Solution Manager.
Please note:
If the objects that you want to transport cannot be transported since you might have created them in the development class $TMP, please have a look at the following post. How to change dev class $TMP for the repository objects of an OData service?.
Demo Flow
Step 1 – Create a change
Step 2 – Create workbench requests and customizing request
Step 3 – Gateway Service Builder – OData Service Creation
Step 4 – Gateway Service Builder – OData Service Implementation
Step 5 – Gateway Backend – Service Registration
Step 6 – Maintain Service – Service Activation on SAP Gateway Server
Step 7 – Maintain Service – System Alias Customizing
Step 8 – SAPUI5 Application Development
Step 9 – Transport changes via QGM
Step 1 – Create a change
The QGM supports the creation of transport request in different systems that are organized through a change request that spans different systems (e.g Gateway Server and Gateway Backend).
Step 2 – Create workbench requests and customizing request
In a second step three workbench requests for
- the repository objects of the Gateway service
- the service implementation and
- the Fiori application
will be created.
In addition a customizing request is created for the customizing settings of the Gateway service as shown in the following screen shot.
Step 3 – Gateway Service Builder – OData Service Creation
When the OData service developer starts to create a new project in the Service Builder in the SAP Gateway backend system and assigns it to a development class the developer will be prompted to assign these changes to the transportable Workbench request (here: EH1K900309) that has been created using QGM before.
Step 4 – Gateway Service Builder – OData Service Implementation
The steps shown in the video are described in detail in the how-to-guide How to Develop a Gateway Service using Code based Implementation.
Step 5 – Gateway Backend – Service Registration
The service implementation ends with the generation of the runtime objects. In this step the repository objects such as ABAP classes are generated and the Gateway service and model are registered in the SAP backend system.
As a result the developer is prompted to provide a transportable workbench request. Here the same workbench request (here: EH1K900309) will be used that already contains the Service Builder project.
Step 6 – Maintain Service – Service Activation on SAP Gateway Server
In this step the developer activates the Gateway service on the Gateway Server (Hub). Here the developer is prompted to provide a workbench request (here: GW1K900063). Please note that this happens on the Gateway Server development system (here: GW1).
Step 7 – Maintain Service – System Alias Customizing
You now want to transport the customizing settings for the system alias(es) that are assigned to the Gateway Service. This can be done from within the customizing table maintance view.
The developer will be prompted now to provide a customizing request (here: GW1K900065) that has been created earlier.
Step 8 – SAPUI5 Application Development
The developer of the SAPUI5 app can now develop the app and publish it finally on the Gateway server which is also called the frontend server for Fiori like applications. The SAPUI5 developer can submit the app so that it is published in the SAPUI5 ABAP repository from within his Eclipse development environement. Here the developer will be prompted to provide a workbench request (here: GW1K900067).
Step 9 – Transport changes via QGM
Now QGM will be used to transport the three workbench requests and the customizing request in synch to the quality assurance system and finally to production.
The status of the transports can be monitored. If for example a request is missing this can be easily be monitored in QGM
Finally all requests have been transported to the production system.
Result – SAPUI5 App runs
Finally the SAPUI5 app runs and displays a list of products .
Appendix – List of repository objects being transported
SAP Gateway Server
The following objects have to be transported between the SAP Gateway server systems:
| Object | Transport Type | PGMID | OBJECT |
|---|---|---|---|
| Service | Repository Object | R3TR | IWSG |
| Model | Repository Object | R3TR | IWOM |
| ICF Node | Repository Object | R3TR | SICF |
| System Alias | Customizing | R3TR | TABU |
| Serivice Registation on the Hub | Customizing | R3TR | TABU |
SAP Gateway Backend
Objects to be transported between the SAP Gateway backend systems
| Object | Transport Type | PGMID | OBJECT |
|---|---|---|---|
| Service Builder Project | Repository Object | R3TR | IWPR |
| Model Provider Class | Repository Object | R3TR | CLAS |
| Model Provider Extension Class | Repository Object | R3TR | CLAS |
| Data Provider Class | Repository Object | R3TR | CLAS |
| Data Provider Extension Class | Repository Object | R3TR | CLAS |
| Model object | Repository Object | R3TR | IWMO |
| Service object | Repository Object | R3TR | IWSV |
Fiori like application
The repository objects of an Fiori like application are deployed on the so called Frontend Server which is the same as the SAP Gateway server
| Object | Transport Type |
|---|---|
| ICF Service | Repository Object |
| Info Object from MIME Repository | Repository Object |
| BSP page | Repository Object |
Thanks Andreas. Very usefull. I have a question.
I have read your document on creating System Aliases in Production.
This document mentions transporting system aliases. I do not see any value in transporting system alias from Dev to Quality (since Dev system alias will point to Dev backend). Am I missing anything?
Hi Krishna,
you are right that any system alias in a DEV system should point to a DEV backend.
But the system alias is just a wrapper for the underlying RFC destination.
So for testing purposes you should use the same name for a system alias (e.g. CRM_BACKEND) in your DEV system as in your QAS and PRD system. This system alias should however point to the DEV CRM backend.
This is especially true if you want to test scenarios where several backends are used with a multi origin.
The assignment of a system alias to a service using transaction /IWFND/MAINT_SERVICE is customizing which is not allowed in a productive system.
Therefore I described in my document http://scn.sap.com/docs/DOC-42241 how it is possible to maintain the system alias itself in a productive system since this can be done as a so called direct setting whereas this is not possible for the assignment of the system alias to a service itself.
This way you can change the RFC destination which will be different in DEV, QAS and PRD.
Best Regards,
Andre
Perfect. Got it now.
I was used to naming the system alias same as RFC destination. So I need to be careful in naming the system alias so that it does not convey wrong meaning.
Hi Krishna,
from several customers we know that they have naming conventions for RFC destinations. RFC destinations may for example contain the SID and client of the target system. By using system aliases we are able to abstract from such naming conventions.
Best Regards,
Andre
Hi Andre,
Under Activate and Maintain Services ERP_UTILITIES_UMC, I was able to transported to QA, but the changes does reflected in QA. Do you know why?
Thanks
David
Hi David,
i am not sure whether I understood your question correctly.
Can you please give some more details what worked and what did not work?
ERP_UTILITIES_UMC is the OData service delivered mit the solution multichannel for utilities. So this is usually imported into your backend via an add on.
the only thing you transport is the service activation.
so if you only have transported the service activation you might be missing the service implementation part?
Best Regards,
Andre
Hi Andre,
thank you for your post. Please i have a question, after transporting my Fiori App to Q, how can i simply delete it without deleting one by one.
BR,
Kevin
Hi Kevin,
your question is not 100% clear to me since do not get what you mean by "without deleting one by one."
Are you planning to delete one or more SAP Fiori applications (apps and odata service implementations) in your Q-system?
Are you planning to delete apps and odata services in the dev system and are wondering whether the deletion can be transported as well?
Best Regards,
Andre
Thanks for your answer, i want to transport one Fiori Application form Dev in Q ( with one or more transport request). After transporting in Q i need to transport again in P-System. and also want to find a solution to delete it (apps, odata service, role and catalog) in P without delete in Dev
BR,
Kevin
Hi Kevin,
Deleting all items in the DEV system and then transport the deletions through Q and P.
See also the comment of my colleague Jorge Baltazar in another blog.
https://blogs.sap.com/2016/10/12/fiori-s4hana-basic-configuration-help-task-lists/comment-page-1/#comment-409896
If you have objects created that are local objects and can thus not be transported my following blog might help:
https://blogs.sap.com/2016/03/21/how-to-change-dev-class-tmp-for-the-repository-objects-of-an-odata-service/
Best Regards,
Andre
Many thanks.
But can i delete all items in Q System and then transport the deletions through P? Is it possible?
BR,
Kevin
Hi Kevin,
deleting objects in a Q-system when they still exist in your development system is tricky. See the following blog post about "deletion transports" and especially the comments that discuss other options using SE80.
BR
Andre