An example of End to End extension on CRM Fiori application - part2

[JerryWang]

• Aim of this blog


• Solution


• Next step

In previous blog An example of End to End extension on CRM Fiori application - part1:

we have already enhanced the standard CRM OData Model, Opportunity, by adding a new field to store creator of a given opportunity and expose it via enhanced OData service implementation.

Aim of this blog

In this part we will consume this extension field "extCreatedBy" in Fiori UI.

It is only possible for you to put your extension fields to UI area where an ExtensionPoint exists, which is delivered by SAP.

Since I need to put the new field under the last field "Log of Changes", below screenshot is original UI before we extend:

The screenshot below is what we expect to achieve after this blog:? the enhanced UI with extension field:

Solution

Find out its ExtensionPoint in xml view:

The idea here is you need to create a new view fragment, and put your extension field into this fragment, which is embedded into the standard opportunity view via ExtensionPoint.

The complete source code of extCreatedBy.fragment.xml:

<core:FragmentDefinition xmlns="sap.m" xmlns:core="sap.ui.core" xmlns:ui="sap.ui.layout">

   <ui:form.SimpleForm id="opportunityExtension">

        <ui:content>

         <Label id="opportunityCreatedByLbael" text="Created By">

         </Label>

         <Text id="opportunityCreatedByValue" text="{json>/extCreatedBy}"></Text>

        </ui:content>

        </ui:form.SimpleForm>

</core:FragmentDefinition>

Finally, specify the OData service url to your own OData service implemented via the step mentioned in previous blog:

The complete source code of frontend part could be found in github: https://github.com/i042416/testOpportunityExtension

commit id:

Last but not least, since now we have consumed the extension field in Fiori UI, not simply via gateway client in previous blog, so we need to ensure that the extension field could successfully be read out in all scenarios.

It means the following two methods should be redefined now ( for the first method /IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_ENTITY, it is already redefined in previous blog ).

source code are listed below:

METHOD /iwbep/if_mgw_appl_srv_runtime~get_entity.

    CALL METHOD super->/iwbep/if_mgw_appl_srv_runtime~get_entity

      EXPORTING

        iv_entity_name          = iv_entity_name

        iv_entity_set_name      = iv_entity_set_name

        iv_source_name          = iv_source_name

        it_key_tab              = it_key_tab

        it_navigation_path      = it_navigation_path

        io_tech_request_context = io_tech_request_context

      IMPORTING

        er_entity               = er_entity

        es_response_context     = es_response_context.

*  Customer extension could be put here

    CASE iv_entity_name.

      WHEN 'Opportunity'.

*         Extension logic on Opportunity header

        CALL METHOD fill_created_by

          EXPORTING

            it_key_tab          = it_key_tab

            iv_called_by_expand = abap_false

          CHANGING

            cr_entity           = er_entity.

      WHEN OTHERS.

    ENDCASE.

  ENDMETHOD.

  METHOD /iwbep/if_mgw_appl_srv_runtime~get_expanded_entity.

    CALL METHOD super->/iwbep/if_mgw_appl_srv_runtime~get_expanded_entity

      EXPORTING

        iv_entity_name           = iv_entity_name

        iv_entity_set_name       = iv_entity_set_name

        iv_source_name           = iv_source_name

        it_key_tab               = it_key_tab

        it_navigation_path       = it_navigation_path

        io_expand                = io_expand

        io_tech_request_context  = io_tech_request_context

      IMPORTING

        er_entity                = er_entity

        es_response_context      = es_response_context

        et_expanded_clauses      = et_expanded_clauses

        et_expanded_tech_clauses = et_expanded_tech_clauses.

    CASE iv_entity_name.

      WHEN 'Opportunity'.

*         Extension logic on Opportunity header

        CALL METHOD fill_created_by

          EXPORTING

            it_key_tab          = it_key_tab

            iv_called_by_expand = abap_true

          CHANGING

            cr_entity           = er_entity.

      WHEN OTHERS.

    ENDCASE.

  ENDMETHOD.

  method FILL_CREATED_BY.

     FIELD-SYMBOLS: <s_guid> LIKE LINE OF it_key_tab,

                    <opp_header> TYPE cl_crm_opportunity_mpc=>ts_opportunity,

                    <opp_expand> TYPE CRMT_ODATA_OPPT_HDR_EXPANDED,

                    <created_by> TYPE sy-uname.

     DATA: lv_created_by TYPE crmd_orderadm_h-created_by.

     IF iv_called_by_expand = abap_false.

       ASSIGN cr_entity->* TO <opp_header>.

       ASSIGN COMPONENT 'EXT_CREATED_BY' of STRUCTURE <opp_header> TO <created_by>.

     ELSE.

       ASSIGN cr_entity->* TO <opp_expand>.

       ASSIGN COMPONENT 'EXT_CREATED_BY' of STRUCTURE <opp_expand> TO <created_by>.

     ENDIF.

     READ TABLE it_key_tab ASSIGNING <s_guid> WITH KEY name = 'Guid'.

     CHECK sy-subrc = 0.

     SELECT SINGLE created_by INTO lv_created_by FROM crmd_orderadm_h WHERE guid = <s_guid>-value.

     IF sy-subrc = 0.

        <created_by> = lv_created_by.

     ENDIF.

  endmethod.

Signature of private method FILL_CREATED_BY:

methods FILL_CREATED_BY

    importing

      !IT_KEY_TAB type /IWBEP/T_MGW_NAME_VALUE_PAIR

      !IV_CALLED_BY_EXPAND type ABAP_BOOL

    changing

      !CR_ENTITY type ref to DATA .

In order to make FILL_CREATED_BY used by both read redefined method, I add a new importing parameter iv_called_by_expand to differentiate its used scenario, since for read and read_expand scenario, the exporting parameter's structure are different. The fill_created_by should react accordingly.

Next step

In next blog I will introduce how to persist the extension field value maintained by end user in Fiori UI to backend database table, that is, to support the update operation on extension field.