In one of my blog series An example of End to End extension on CRM Fiori application – part1:

I introduce how to add some new fields in Fiori application with CRUD support. This time I will use the introduced tricks to resolve a real business case.

User story

In CRM WebUI, the sales area of a given opportunity consists of the following fields in assignment block “Organizational Data”.

Note the “Sales Office” and “Sales Group” marked with red:

However in Fiori these two fields are not available.

The series of this blog will introduce how to bring these two standard fields into Fiori and provide CRUD operations on them.

As the first step, we need to expose the read operation of these two fields via odata service, which means when we test the odata service read operation, we expect to see both in response stream. Below is the screenshot of response before extension – both fields are missing there.

1. When the data for Sales area tab in Fiori is read from backend, we make investigation and find out the data for both fields are already returned by one order API and available in the context of standard odata service implementation.

Since there is a MOVE-CORRESPONDING fields to move the opportunity data from one order API result to result structure of odata service, for the read operation, we just need to create two new fields in the structure of ls_entityset with exactly the same name, SALES_OFFICE and SALES_GROUP, then the MOVE-CORRESPONDING will take effect.

2. The DDIC structure of Opportunity header is enhanced as below:

Add these two fields in service builder as well, re-generate runtime objects and clear model cache in both gateway and backend system to ensure the new fields could be visible in the runtime.

3. retest the odata service read operation, the sales office and sales group are now available in the read response.

in next blog, I will introduce how to make these two fields display in Fiori UI.