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 previous blog, the two fields Sales Office and Sales Group have already been exposed via OData service read operation. In this part I will make the two fields visible in Fiori UI. The final UI would look like below:
Step1: find the available extension point in UI to hold the two fields
There is existing extension point in opportunity detail view:
As the first step, our aim is just to display the two fields in Fiori UI without considering format requirement. So we just directly bind the two fields to SalesOfficeCode and SalesGroupCode exposed by blog part1.
This step is quite easy to do. The UI after this step looks like below. We can notice that for the other three standard fields, always the format + ( + + ) is displayed in UI.
The format is defined in xml view as below:
and the simple format function:
In next step, we will enable the same format function for the two new fields.
Step2: create another two new fields SalesGroupText and SalesOfficeText to hold the description
The steps are also exactly the same as how we create the two fields SalesGroupCode and SalesOfficeCode in blog1: add the fields in DDIC structure and related Odata Model node:
After we have these two fields to store description, we can write the logic to get description by code.
All READ-related methods need to be enhanced with this logic.
a. redefine method OPPORTUNITIES_GET_ENTITYSET and paste the following source code:
b. create a new private method FILL_SALES_TEXT with the following signature:
source code:
Once this step is done, you could test your enhanced Odata service read operation and ensure you could see both code and description of SalesGroup and SalesOffice in response.
Step3: change the binding of extension fields
Just change the binding path from code to the converted value formatted by the formatter.
The complete UI code could be found in github:https://github.com/i042416/testOpportunityExtension/ with commit id: 7489bd487cc40fff1a9dd3b9d3683036961a1061
The complete backend source code could be found from attachment.
