Using object and subobject in configuration determination

In some of my previous blogs I mentioned using the DO_CONFIG_DETERMINATION to change screen layout determination. In the blog here, I even mention that using the object_type and subobject_type is not recommended, because it apparently is hardcoded. This is true for some objects.
But not for all.

So let’s take a look at what it does and how we can use it.

Screen customizing

Let’s go back to what screen customizing is about. The CRM webclient 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

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.

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

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

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:

Set the object_type and subobject_type in do_config_determination

So, first we redefine the do_config_determination in our view, and implement calling the super class.

  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.

Of course, you will need to add values to the parameters <your object> and <your subobject>. The <your object> parameter can usually be hardcoded, because we are coding in the particular view anyway, but 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

You will notice that when trying to add a new configuration for a newly created subobject (based on the context), you will run into errros like this:

Now there is a good trick for this. In the customizing of BSPC_DLC_OBJ_TYP, there is a field called Callback Class.

SPRO –> SAP Customizing Implementation Guide–> Customer Relationship Management –> UI Framework –> UI Framework Definition –> Define UI Object Types

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.

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.