Applies to:

SAP CRM 7.0, EHP1 and EHP2

Summary

Handler classes methodology is very helpful in SAP CRM WEBUI framework where we have a scenario to enhance standard BOL object in order to include customize functionality. To be more precise by using handler classes we are trying to achieve what we do in AET or EEWB. But then the question is why we should use handler classes in first hand when we have powerful tool like AET with us. Well there are two answers to this which I have experienced while working in umpteen implementation projects. First one AET is not always reliable; many instances are there where we have added the custom fields/table to the existing standard field and when we try to activate it suddenly takes more time and meantime AET dumps out. Due to this inconsistency many times the whole Web UI dumps. The second answer it gives more flexibility as well as the power to each technical developer to design the custom functionality. The other purpose is it gives good insight to the user especially to the technical people as to how the CRM BOL architecture works.

 

Author(s): Rajwin Singh Sood

Company: Atos

Created on: 15^th July 2014

Author Bio

Rajwin Singh Sood is currently working as Team lead/Solution Architect at Atos. He has got experience of more than 9 years in SAP ABAP and SAP CRM web UI. He is also a SAP CRM EHP2 Certified associate consultant. Prior to working with Atos he had worked with SAP India(SAP Global Delivery), Capgemini , Accenture and Infosys. He worked in SAP CRM Web UI areas like BSP enhancements, transaction launchers, BOL Programming, BRFPlus .

Scenario for using handler classes

We’ll be using a simple scenario wherein we are planning to have some dealers associated with the opportunity id. You can use your Customize table and then accordingly use it. So we have a Z table ZZBT_DEALERS created as per below screenshot:-

 

 

The GUID will be the key which will link this table to the BT objects(in our case its opportunity). To make it more simple we have already made an entry in this table as :-

 

 

The GUID DE17AD967C89D5F19C570019B9F5A712 is for the quotation number 100:-

 

 

 

 

Also define the structure for the table which we’ll be using in our later steps:-

 

 

This mean after we incorporate the handler class enhancement and when we open the opportunity on webui screen we’ll have this data for Dealer shown as per the entry made in the dealer database table.

 

Steps for creating the handler classes

1.     As a first step type transaction SPRO click on SAP Reference IMG and got user area MENU Customer Relationship Management->CRM Cross-Application Components->Generic Interaction layer/Object Layer->Component specific settings->business transactions->Extend Model for business transactions with new nodes:-

 

 

when we click on extend model for business transactions with new nodes we’ll be defining the new ZBOL model with respect to the Dealer table which we had created above. When we enter the screen after clicking on the button we need to click on the new entries button:-

and we need to make the following entries:-

and then click on save.

2.     Now in step 1 after defining the new node. We need to come back on the User area menu screen click on the button Extend Model for Business transaction with new relations. This particualr section deals with the kind of realtionship/cardinality which we are looking out for the dealer table with respect to the BT order transctions. Over here I have user 1 to many as 1 particular opportunity could have multiple dealers:-

 

 

3.     In the third step which is Define Custom Handler Classes For Business Transaction Model Nodes. In this step we’ll be defining the handler class which will be executed whenever the Dealer data is to be dealt with:-

click on save.

 

4.Now the customizing settings for handler classes is done now we need to create the handler class. To do that go to transaction and create class ZCL_BR_DEALERS_RUN_BTIL with the super class CL_CRM_RUNTIME_BTIL it should look like the one as per below screenshot:-

 

 

 

there might be very much as query creeping into your mind as to why class name is different in customizing and the actual class name. This is actually a very intriguing part of handler classes terminilogy. Once you define the class in customizing at run time which means we try to retrieve the Dealer data with respect to the opportunity there could be upmteen numbers of instances of handler classes. Which means there could be umpteen number of handler classes instances depending upon as to how the developer wants the handler classes to run. To less complicate I am using the single class.

 

 

5. Now comes the part where we need to redefine the method IF_CRM_RUNTIME_BTIL~READ_ATTRIBUTES. This is the method which gets called when we try to retrieve the dealer data with respect to the opportunity. So redefine it and then add the code as per the below code snippet:- METHOD if_crm_runtime_btil~read_attributes.

CALL METHOD super->if_crm_runtime_btil~read_attributes

EXPORTING

ir_cont_obj = ir_cont_obj

ir_api_data = ir_api_data

iv_ref_guid = iv_ref_guid

iv_ref_kind = iv_ref_kind.

DATA: ls_guid TYPE crmst_guid_btil.

DATA: lr_cont_obj TYPE REF TO if_genil_container_object.

DATA: lt_dealer TYPE STANDARD TABLE OF zzbt_dealers_struct,

lr_attr_props TYPE REF TO if_genil_obj_attr_properties,

ls_dealer TYPE zzbt_dealers_struct.

DATA: lr_children    TYPE REF TO if_genil_container_objectlist,

lr_child       TYPE REF TO if_genil_container_object,

lr_bt          TYPE REF TO if_crm_runtime_btil,

lv_relation  TYPE crmt_relation_name,

lv_size        TYPE sy-tabix,

lv_count       TYPE i,

lv_totalsize   TYPE i.

***now we’ll fetch the data from th dealer database table

SELECT * FROM zzbt_dealers INTO TABLE lt_dealer WHERE guid EQ iv_ref_guid.

*****reading the GUID from the ORDER then setting the attributes.

LOOP AT lt_dealer INTO ls_dealer.

TRY.

ir_cont_obj->set_key( iv_ref_guid ).

CATCH cx_crm_cic_duplicate_entry.

ENDTRY.

IF ir_cont_obj->check_attr_requested( ) EQ true.

*****now set the attributes of the parameter on the basis of the data fetched

me->set_attributes( ir_cont_obj   = ir_cont_obj

is_attributes = ls_dealer

iv_ref_kind   = iv_ref_kind

iv_log_key    = iv_ref_guid ).

****this is to make the fields editable allowing the user to make the changes

lr_attr_props = ir_cont_obj->get_attr_props_obj( ).

lr_attr_props->set_all_properties( if_genil_obj_attr_properties=>changeable ).

***but we don’t need to make the field GUID and CLIENT as changeable so we’ll make them read only.

CALL METHOD lr_attr_props->set_property_by_name

EXPORTING

iv_name  = ‘CLIENT’

iv_value = if_genil_obj_attr_properties=>read_only.

CALL METHOD lr_attr_props->set_property_by_name

EXPORTING

iv_name  = ‘GUID’

iv_value = if_genil_obj_attr_properties=>read_only.

ENDIF.

ENDLOOP.

1. ENDMETHOD.

The code snippet is self explanatory as in I have added the proper comments expalining the same. But to understand it better I would recommend to you to please put a external breakpoint and then try to debug it while testing it in GENIL_BOL_BROWSER transaction, which is our next section.

 

 

Testing the handler class in GENIL_BOL_BROWSER

1. Goto transaction GENIL_BOL_BROWSER and in the component field enter BT and execute.
2. When we come to screen try to search for the search object BTQOpp and double click on the same:-

3.Now in the dynamic query parameters add the parameter OBJECT_ID whose value is 100 and click on find button:-

 

4. Now click on the children button as highlighted in red. Once you click on that you’ll get 1 entry BTADVOPP on the left hand side of the screen double click on that:-

 

5. After double clicking on that again click on the children button and then you’ll again get two entries which are BTOrderCustHist and BTOrderHeader respectively on the left hand side of the screen. Double click on BTOrderHeader entry:-

 

 

 

6.After doubleclicking on it again click on children. You’ll get multiple BOL nodes which are nothing but related entities with respect to BT. Over here search for the ZBT_DEALER entry which we created in SPRO customizing. After you find it double click on that:-

7.After double clicking on that you’ll get the entries as is save in the dealer database table. You can debug the handler class but following the steps specified above in order to understand the flow of handler classes:-

 

 

Steps to use handler classes in BSP workbench

Now as we have tested it successfully our handler class using transaction GENIL_BOL_BROWSER we can proceed further and have it implemented in BSP workbench so that we can make this functionality useable for the end user at the browser. Over here I have directly added a view to the BSP component BT111H_OPPT and then shown it in the overview page. But you can create a different component and create a view in that and then using component usage you can display it in the component BT111H_OPPT.

Steps are given below:-

1. Add the table type view dealer using the normal wizard way by right mouse click on the view

 

please note that in the view while adding the model node please select the BOL relation ZZBT_DEALER which we created in SPRO settings in the above section and make this view as table type view configurable.

2.Go to the configuration tab and add the fields Dealer ID and Dealer Name:-

3.Redefine the DO_PREPARE_OUTPUT and add the following code:-

METHOD do_prepare_output.

  CALL METHOD super->do_prepare_output

    EXPORTING

      iv_first_time = iv_first_time.

  DATA: lr_coco TYPE REF TO cl_bt111h_o_bspwdcomponen_impl,

        lr_collection TYPE REF TO if_bol_entity_col,

        lr_btadmin_h TYPE REF TO cl_crm_bol_entity.

  lr_coco ?= me->comp_controller.

  IF lr_coco IS BOUND.

    lr_btadmin_h ?= lr_coco->typed_context->btadminh->collection_wrapper->get_current( ).

  ENDIF.

  IF lr_btadmin_h IS BOUND.

    TRY.

        CALL METHOD lr_btadmin_h->get_related_entities

          EXPORTING

            iv_relation_name = ‘ZZDEALER_REL’

          RECEIVING

            rv_result        = lr_collection.

      CATCH cx_crm_genil_model_error .

    ENDTRY.

    IF lr_collection IS BOUND.

me->typed_context->dealer->collection_wrapper->set_collection( lr_collection ).

    ENDIF.

  ENDIF.

  ENDMETHOD.

 

 

 

4. We need to add this view as an assignment block to the over view page. To achieve this first go to the Runtime repository editor and add this view to the over view page as per below screenshot:-

 

 

 

 

 

5.Now go to the configuration tab of the overview page BT111H_OPPT/OpportunityOVViewSet and add the assignement block for dealer as per below screenshot:-

 

 

So we are done with the handler classes tutorial now the final step testing in browser.

 

Testing the working model in browser

Use transaction to WUI/ CRM_UI to open webui screen and in that open the sales professional business role and in that go to the sales cycle and search for opportunity with id as 100 and then check for the  assignment block Dealers:-

 

 

 

 

 

This particular document gave a simple illustration about handler classes. My next document I’ll covering the advance topics where we’ll be editing as well as saving the data using handler classes.