Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata


For suite7i11 it may be desired that editable overview pages offer a central edit button located in the super ordinate tool bar. A click on it switches all assignment blocks of the overview page into edit mode.  


The following how-to guide indicates what basic steps are required for an implementation. It depends on the specific application if and which additional coding is needed for a particular use case.

As an implementation sample you may look into the sales order component BT115H_SLSO. The central edit button is visible in case you operate the application as an Interaction Center Agent.

How to Use

The user of an WebClient UI based application finds a central Edit button overview page. A click on it brings all assignment blocks into edit mode and it is not necessary any more to switch each section into edit mode separately. It is furthermore intended, that the button configuration may be used to display or hide the button as desired for a business role. This topic is not described here, since the button configuration is not yet available. 

How to Implement

The overview page has to offer a central Edit-Button on top. So far the overview page offers Edit-Buttons on various assignment blocks. The following instructions point out how an additional button is inserted in the central tool bar of the overview page and how to implement the corresponding event handler. Implementation and testing in a typical straight forward case should be done within 2 hours.

(1) Add central edit button by an implementation of the tool bar callback interface in the overview page controller

The coding might look as sketched out below ...

method <class representing the controller of your overview page>->if_bsp_wd_toolbar_callback~get_buttons.
* Get current entity
  data: entity type ref to cl_crm_bol_entity.
  entity ?= me->typed_context-><node containing root entity to edit>->collection_wrapper->get_current( ).
  if entity is initial. ... exit. endif.
* Determine buttons to display
  data: button TYPE crmt_thtmlb_button_ext.
* Central edit button
  clear ls_button.
  button-type     = cl_thtmlb_util=>gc_icon_edit.
  button-text     = cl_wd_utilities=>get_otr_text_by_alias( 'CRM_UIU_BT/EDIT' ). "#EC NOTEXT
  button-on_click = 'EDIT'.                                                      "#EC NOTEXT
  button-page_id  = me->component_id.
  if entity is bound
     and view_group_context->is_all_views_editable_set( ) = abap_false
     and entity->is_change_allowed( ) = abap_true.
     button-enabled  = abap_true.
  append button TO rt_buttons.


You may access this method easily from the component workbench: 


(2) Create and implement an event handler in your overview page to process a click on the central edit button

It might look as sketched out below ... 


method <class representing the controller of your overview page>->eh_onedit
* Get and lock current entity
  data: entity type ref to cl_crm_bol_entity.
  check me->typed_context-><node containing root entity to edit> is bound.
  entity ?= me->typed_context-><node containing root entity to edit>->collection_wrapper->get_current( ).
  check entity is bound.
  check entity->is_change_allowed( ) = abap_true.
  entity->lock( ).
* ... Reset view group context if lock was not successful
  if entity->is_locked( ) = abap_false.
     me->view_group_context->reset( ).
* Set view group context to signal whether all assignment blocks are to be indicated as editable
  me->view_group_context->set_all_editable( ).
* Create dependent view contexts if needed
* ... and set them as editable as well
  data: dependent_view_group_context type ref to if_bsp_wd_view_group_context.
  dependent_view_group_context ?= view_group_context->get_dependant_vg_context( ).
  dependent_view_group_context->set_all_editable( ).


When you use the component workbench to create the event handler, the necessary entry in the DO_HANDLE_EVENT method in the controller class is generated automatically as usual. 


The specific implementation may vary for each application case.


As an example, already existing in CRM 7.0, have a look into the sales order overview page using the IC WebClient profile. Here a central edit button becomes visible. The underlying component is BT115H_SLSO.

Find below some code snippets taken from the implementation of the sales order suite7 application. The UI component is BT115H_SLSO. The implementation is build into a hierarchy of base classes ...

  * Edit button (depending on BT channel interface)
    DATA: ls_button TYPE crmt_thtmlb_button_ext.
    lr_access = cl_crm_uiu_bt_channel_asp_fac=>get_instance( ).
    lv_edit_all_active = lr_access->if_crm_uiu_channel_aspects~is_edit_all_button_active( ).
    IF lv_edit_all_active = abap_true.
      CLEAR ls_button.
      ls_button-type     = cl_thtmlb_util=>gc_separator.
      ls_button-enabled  = abap_true.
      APPEND ls_button TO rt_buttons.
      CLEAR ls_button.
      ls_button-type     = cl_thtmlb_util=>gc_icon_edit.
      ls_button-text     = cl_wd_utilities=>get_otr_text_by_alias( 'CRM_UIU_BT/EDIT' ). "#EC NOTEXT
      ls_button-on_click = 'EDIT'.                          "#EC NOTEXT
      ls_button-page_id  = me->component_id.
      IF lr_entity IS BOUND AND view_group_context->is_all_views_editable_set( ) = abap_false.
        ls_button-enabled  = abap_true.
      APPEND ls_button TO rt_buttons.
  DATA: lr_cn  TYPE REF TO cl_bsp_wd_context_node,
        lr_ent TYPE REF TO cl_crm_bol_entity,
        lr_vgc type ref to if_bsp_wd_view_group_context.
* Get current AdminH-Entity
  lr_cn = me->get_context_node( gc_cn_btadminh ).
  check lr_cn is bound.
  lr_ent ?= lr_cn->collection_wrapper->get_current( ).
  CHECK lr_ent IS BOUND.
  IF lr_ent->is_locked( ) = abap_true.
    me->view_group_context->set_all_editable( ).
    lr_vgc ?= view_group_context->get_dependant_vg_context( ).
    lr_vgc->set_all_editable( ).
    lr_ent->lock( ).
    IF lr_ent->is_locked( ) = abap_true.
      me->view_group_context->set_all_editable( ).
      lr_vgc ?= view_group_context->get_dependant_vg_context( ).
      lr_vgc->set_all_editable( ).


In order to explorer the view group context and tool bar creation in this example you may want to use those conditional breakpoints  

Some words about the view group context

Whenever you put a dependent BOL entity into edit mode, not only its children, but all relatives up to the root entity are editable as well. So if the lock state of an entity would have been used to indicate the possibility to edit all assignment blocks of an overview page, a view group context object would not have been necessary.

The UI guideline however request the general possibility that usually each assignment block is put into edit mode separately. In order to support this situation, the view group context object has been created. It is exposed with the interface IF_BSP_WD_VIEW_GROUP_CONTEXT, is implemented by class CL_BSP_WD_VIEW_GROUP_CONTEXT and belongs to the UI framework package BSP_WD. The view group context is used in overview pages to register each view which is in edit mode.

Therefore the view group context is typically used in the html for an assignment block, which leads to a different appearance of assignment blocks in display and edit mode.

<%@page language="abap" %>
<%@extension name="chtmlb" prefix="chtmlb" %>
<%@extension name="thtmlb" prefix="thtmlb" %>
<chtmlb:config displayMode = "<%= controller->view_group_context->is_view_in_display_mode( controller ). %>"
               mode        = "RUNTIME" />


Once the view group context has been created in the view hierarchy - e.g. in the Window of an overview page -

METHOD CL_CRM_BT_H_WINDOW->set_view_group_context.
  IF iv_first_time EQ abap_true AND
     me->view_group_context IS NOT BOUND.
    IF iv_parent_context IS INITIAL.
      CREATE OBJECT me->view_group_context
        TYPE cl_bsp_wd_view_group_context.
      me->view_group_context = iv_parent_context.
  me->set_tx_for_grp_ctxt( ).


it is inherited automatically to all subordinate views by the UI Framework.



They reuse it, provided that they do not create their own dependent contexts, etc. .

A view group context (IF_BSP_WD_VIEW_GROUP_CONTEXT) allows registration of editable views (SET_VIEW_EDITABLE), indicate general possibility to edit (SET_ALL_EDITABLE), the creation and access of dependent contexts (GET_DEPENDANT_VG_CONTEXT), access to the parent context (GET_PARENT_VG_CONTEXT), assignment of a transaction context (SET_ASSOCIATED_TX_CONTEXT) and finally a reset of the edit mode (ON_TX_FINISHED, RESET) among others.


Question: Are there sample implementations available? Answer: Find a simple use case in the sample flight application (UIF_FLIGHT_O). For a real life implementation have a look into the sales order overview page using the interaction center business role. The component is BT115H_SLSO, starting in release suite7.

Question: Would it be possible to provide an application customizing, which allows to specify whether the assignments blocks of an overview page get switched into edit mode automatically when entered? Answer: Yes, application development may use this guideline to implement such a customizing.