I would like to share my experience in extending Fiori Apps and at the same time will show some of the significant steps which need to be performed when extending a Fiori App. As I got access to a CRM system, I will demonstrate with a simple use case as to what effort is required to add a field to one of the apps – “My Appointments”. “My Appointment” app typically displays the appointment records which can be displayed via CRMD_ORDER SAP GUI transaction.

Fiori Appointment Overview screen

Fiori Appointment Detail

screen

The counterpart SAP GUI transaction looks like below.

Let’s take an example where the requirement is to add few additional fields at the bottom of the Fiori Detail screen. The Category field is available in SAP GUI but not on Fiori screen.

To enhance this, there are three pieces of activities which need to be performed

1. Extend the Standard Appointment OData service and put in the logic to retrieve the additional fields
2. Extend the SAPUI5 Fiori Appointment application
3. Display the new enhanced application to the user via the new Launchpad

I will cover the first topic in this article and the remaining as separate articles shortly

Extend the Standard Appointment OData service

It’s always good to start with SAP Help documentation to identify the components of each Fiori App.

http://help.sap.com/fiori_bs2013/helpdata/en/f4/394452aeeeb710e10000000a44176d/content.htm

Open the project in SEGW to explore the components.The Standard service which needs to be extended is “CRM_APPOINTMENT” and the entity is “Appointment”.

Before enhancing the service, please read the documentation on “Use cases for redefining OData Services” – http://help.sap.com/saphelp_gateway20sp08/helpdata/en/34/4e3d5269a2b610e10000000a44176d/content.htm?frameset=/en/3d/500cb8468d4534ae4130aecf680dbb/frameset.htm

Each entity is bound to an ABAP structure. From the help document, you should be able to find if there is an Include within the structure for extension. The Appointment entity is bound to the structure “CRMS_APPOINTMENT_ODATA” and it has an include “CRM_APPOINT_ODATA_INCL”. Add the new fields like Category within this structure.

With this, the DDIC part is enhanced. Next, create a new project as shown below in SEGW

Redefine it by using the below option

Provide the standard OData service as shown below

Select all the objects in the pop-up and you should see the below screen

Open the properties for the Appointment entity and add new entries for additional fields like Category.

Generate the project and provide values for the DPC/MPC classes

Add the Service via /IWFND_SERVICE_MAINT

After the service is added, you should be able to test by clicking on “Gateway Client”

In the gateway Client (/IWFND/GW_CLIENT) , retrieve the metadata of the service to confirm if the new fields have been added to the entity.

Next, we need to put some logic to populate the field values. Always look for enhancement spots to see if they meet the requirements. If not, open the  DPC_EXT Class (ZCL_MYAPPOINTMENT_DPC_EXT) class which was generated and redefine the APPOINTMENTSET_GET_ENTITY. If we were to add some fields to the Fiori overview screen, we would have to redefine the APPOINTMENTSET_GET_ENTITYSET (which returns a collection of Appointments for the list screen).

After analysing the code, You can have either of the below approaches within the methods which are to be redefined:

1. Call the corresponding SUPER method to ensure that standard SAP code is executed. After invoking the SUPER method, you can add the custom code to perform operations for additional fields.
2. Copy the standard code from the corresponding SUPER method and amend it with logic to perform operations for additional fields.

Keep in mind that SAP might be enhancing the standard structure by adding or removing fields in higher versions. Hence, we need to accordingly redefine the methods to minimize any impact during an upgrade.

Since there is a BADI – CRM_APPT_ODATA_BD within an Enhancement spot, we could use that BADI to put in our logic in the GET_APPOINTMENT method.

Once the data for additional fields are retrieved use the Gateway client to run the service and check if the collection of Appointments has the category details too.

It is very important to understand that before any OData service enhancements occur, it is best for the developer to debug the calls which come into the system from the Fiori App. Very often we make assumptions only to find at a later stage that the way in which the Fiori App makes a call to the backend is different to what we thought. For example a PATCH_ENTITY method could be invoked rather than an UPDATE_ENTITY. The way in which one Fiori App is developed may differ from another. It’s best to set a break point and explore how the calls come into the backend system.

The remaining parts of this article can be found in the below links.

Extending a Fiori App – Simple Use case – Part 2 (UI Extension)

Extending a Fiori App – Simple Use case – Part 3 (Launchpad Setup)