Generic Retrieval of Object Type and Key When Embedding a Component

It is sometimes the case that one needs to get the notion of its ‘surroundings’ when coding reusable UI Components. A view that needs to be reused/embedded in other CRM applications is a perfect example. Such views can implement logic that depends on the context in which they are executed. For example, call one FM when being displayed in an Account and a different FM when rendered in BP Contact. This requires code that determines the “surroundings” dynamically at runtime.  Fortunately there is a fairly straightforward solution.

Each CRM application shall have an associated UI object type. The latter identifies the application semantically. Remember that the same UI components can represent different things. So the UI object types help to specify what does a UI component represent at a given point in time.

BSP_DLC_OBJ_TYPE screenshot

The database table BSP_DLC_OBJ_TYPE  contains the UI Object type definitions. If you take a look there you will see that an UI Object type is mapped to a BOL and BOR objects .

The customers can define their new UI Object types in BSPC_DLC_OBJ_TYP. To view the SAP entries you can use transaction BSP_DLC_SDESIGN (SAP). Customers can maintain their definitions via in IMG under  UI Framework –> UI Framework Definition –> Define UI Object Types .

 

Due to the many to many nature of the relationships in these tables one cannot rely solely on them to map UI object types to BOL and BOR objects. Therefore, there is a service that does the mapping during runtime by evaluating the attributes of the relevant BOL object. The ABAP class name of this service is CL_CRM_UI_OBJECT_MAPPING_SRV. Internally it relies on mapper classes that carry out the actual conversion. These mapper classes implement interface IF_CRM_UI_OBJ_MAPPER.

CRMS_UI_OBJ_MAP screenshot

 

What mapper class to use for which BOL object is specified in table CRMS_UI_OBJ_MAP . You can use transaction CRMC_UI_OBJ_MAPPING instead of browsing this table in the DDIC (will also show the associated Design Layer objects). For customer settings use transaction  CRMS_UI_OBJ_MAP (Customer) or IMG path  UI Framework –> Technical Role Definition -> Define Object Mapping (Customer)

 

 

 

 

 

But how to use all these in an embeddable UI component? It is actually quite simple.  First you need to get an instance of the mapping service and then execute one of its methods. You have methods for obtaining the UI object types based on a BOL entity, getting the BOR type or the other way around – get the UI object type from a BOR/BOL objects. Here is an example that retrieves the BOR object from a  BOL:

* Local data declarations

  DATA: lv_ui_type TYPE bsp_dlc_object_type,

                lh_map_srv TYPE REF TO cl_crm_ui_object_mapping_srv.

* Get BOR object data

  lh_map_srv = cl_crm_ui_object_mapping_srv=>get_instance( ).

  CHECK lh_map_srv IS BOUND.

  lv_ui_type = lh_map_srv->determine_ui_object_of_entity( bol_entity ).

  CHECK lv_ui_type IS NOT INITIAL.

  pes_borident = lh_map_srv->get_bor_from_entity( iv_ui_object_type = lv_ui_type  

                                                                                                             iv_entity         = bol_entity ).

What is important is to note that the BOL object used must be the one used in CRMS_UI_OBJ_MAP. These are root entities and are often referred to as “main” BOL entities.  This term is somewhat loosely used. In the context of UI components, this is the BOL entity returned by IF_BSP_WD_HISTORY_STATE_DESCR~GET_MAIN_ENTITY of the OVP or the Window controller classes.  That should be a straightforward task to get 🙂