Skip to Content
Author's profile photo Jerry Wang

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

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:

/wp-content/uploads/2015/06/clipboard1_728565.png

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

/wp-content/uploads/2015/06/clipboard2_728566.png

Solution

Find out its ExtensionPoint in xml view:

/wp-content/uploads/2015/06/clipboard3_728567.png

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.

/wp-content/uploads/2015/06/clipboard4_728568.png

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:

/wp-content/uploads/2015/06/clipboard5_728569.png

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

commit id:

/wp-content/uploads/2015/06/clipboard6_728570.png

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 ).

/wp-content/uploads/2015/06/clipboard7_728571.png

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.

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.