CRM Web UI - Use of object and subobject for configuration determination

In this blog, we are going to explore the use of OBJECT_TYPE and SUBOBJECT in configuration determination (As method DO_CONFIG_DETERMINATION also plays key role to change screen layout determination).

Although, use of the object_type and subobject_type is not recommended, because it apparently is hard coded. This is true for some objects, not for all. So let's take a look at what it does and how we can use it.

Basic concept how web UI Screen Customizing works: The CRM webclient UI is very flexible when it comes to moving and renaming fields in the user interface. This is due to the platform. At runtime, an XML containing the screen definition is retrieved from the database, and is used to build up the HTML.

When retrieving the screen definition XML, the system uses a few parameters to determine the right XML. One of the parameters of course is the name of the view itself, so, for instance, BP_HEAD/AccountDetails is the view for the account details screen.

Now depending on the view, some other parameters are added to the XML retrieval process, which are:

• Role key
• Component Usage
• Object Type
• Subobject Type

1. Role key : The role key is automatically added by the system, and represents the business role. This enables you to differentiate the configurations for different business roles.
2. Component Usage : The component usage is a constraint-free field. You can use this to for instance differentiate based on the context (as described here).
3. Object Type : The Object Type should describe the object from the object model (so should be available in BSP_DLC_OBJ_TYP or BSPC_DLC_OBJ_TYP), customizable in: SPRO --> SAP Customizing Implementation Guide--> Customer Relationship Management --> UI Framework --> UI Framework Definition --> Define UI Object Types
4. Subobject Type: The subobject type is a further differentiated type of the object type. Standard SAP uses this for instance to differentiate configurations per customer type (CORPORATE, INDIVIDUAL, GROUP) or per transaction type.
   
   As much as you might want this, it is not recommended to actually influence the screen layout itself using coding. It is allowed to influence the retrieval though, using the do_config_determination method of the controller class of the view.
   
   As a screen (or view actually) usually is created to show one particular object type (so either business partners, transactions, campaigns etc), the object type would usually be the same for every instance shown in the screen.
   
   The subobject type is where we can make the split. In order to set different subobject types, there are a few constraints though:
   • The object type must be set.
   • The value for the subobject type must be selectable in the config screen.

Both are not standard in some cases. We need three steps:

•   To Set the object_type and sub object_type in do_config_determination : We need to redefine the do_config_determination in our view, and implement calling the super class.
  

  *Call logic in super class(Standard)

  CALL METHOD super->do_config_determination

     EXPORTING

       iv_first_time = iv_first_time.

  
  Then we set the object_type and subobject_type:

  DATA: lr_config_desc TYPE REF TO cl_bsp_dlc_configuration2.

   

  TRY.

      lr_config_desc ?= me->configuration_descr.

      lr_config_desc->if_bsp_dlc_config_appl~set_object_type( <your object> ).

      lr_config_desc->if_bsp_dlc_config_appl~set_object_sub_type( <your subobject> ).

    CATCH cx_sy_ref_is_initial.

  ENDTRY.

Note: You will need to add values to the parameters <your object> and <your subobject> in above mentioned code

The <your object> parameter can usually be hardcoded, because we are coding in the particular view anyway.

However the <your subobject> parameter should come from  the context nodes, so you will also need something like:

lr_access = me->typed_context->paonline->collection_wrapper->get_current( ).

 

• Allow the subobject_type in the config screen: Sometimes when trying to add a new configuration for a newly created subobject, you might have come across error's like this: "Subobject type CUSTOMER is not valid for object type BP_ACCOUNT"

In such case, you need to do configuration change and in the customizing of BSP_DLC_OBJ_TYP table, there is a field called Callback Class.

This class is primarily used to determine the subobject types. For BP_ACCOUNT for instance, this is dealt in class CL_BP_HEAD_SUBTYPE_CALLBACK. If we want to adjust this, we can either implement a subclass of the standard class, or implement a new class with an interface to IF_BSP_DLC_OBJ_TYPE_CALLBACK and implement the method GET_OBJECT_SUB_TYPES. Access via  as SPRO --> SAP Customizing Implementation Guide--> Customer Relationship Management --> UI Framework --> UI Framework Definition --> Define UI Object Types (SM30 View : BSPDLCVC_OBJ_TYP).

Note : - Here we either select data from a domain, from a table or hardcode the possible subobject types. Make sure you enter your custom callback class in the customizing.

• Create specific screen customizing : Now that this has been done, you will notice that the new subobject types are selectable, so you can create your new configurations using them. You will also notice that they will be correctly determined if you have done the do_config_determination correctly.