Skip to Content

In SRM, most of the business objects creation/display is handled in ABAP WD FPM and the screen is composed of several different webdynpro components in turn. If you are familiar with how a webdynpro application is built, then you know what context is and how it is bound to the UI elements on screen. If not, please do not proceed further rather go and watch a movie. Don’t waste time here 🙂

In general, if we are building a webdynpro application involving a single component, then it makes sense to fill the context in WDDOINIT/WDDOMODIFY methods. But in SRM as I mentioned earlier, the total screen is combination of several individual webdynpro components. Let’s take shopping cart as an example. It has header section, item overview, item detail, source of supply etc and each of this tabs/sections refer to separate WD components.  If we were to write code to fill each WD component context in their own controller methods, we have to access the SC details multiple times. In order to avoid this SAP has followed, façade design pattern of ABAP OOPs and written an abstract layer which will act as a common interface for filling up context of any WD component involved in the application.

Let’s take SC header data component. It refers to WD component /SAPSRM/WDC_UI_SC_DOFC_HD and view V_SC_BOFC_HD_FT. All the fields that you see on SC header are linked to context node HEADER which refers to structure /SAPSRM/S_CLL_WD_SC_HEADER

In a normal sunny day, if we want to set this context node with values we would write below code

   lo_nd_header = wd_context->get_child_node( name = wd_this->wdctx_header ).
    lo_el_header = lo_nd_header->get_element( ).
    lo_el_header->set_static_attributes( static_attributes = ls_header ).

Or as below, which is much better

lo_nd_header ->bind_structre( new_item = ls_header ).

Refer to the below help link for more info on how to set/read context

https://help.sap.com/saphelp_erp60_sp/helpdata/en/46/1d7d1cd66f4250e10000000a1553f6/content.htm

But we don’t see any of this code in any of the controller methods of view V_SC_BOFC_HD_FT. So question is where is SAP filling the nodes??

Let’s start our mission impossible (just watched MI: rouge nation 🙂 on TV)

Let’s look at the code written in WDDOINIT and WDDOMODIFYVIEW methods of this view

WDODINIT

I am mentioning here the code that is relevant for our purpose here

 

  • Get the reference of the node that we want to fill in

lon_header = wd_context->get_child_node( name = if_v_sc_bofc_hd_ft=>wdctx_header ).

  wd_this->mo_dodm_sc_h_bd = wd_comp_controller->mo_bom_sc->get_dodm_sc_h_bd(
                              ion_wd_set                  = lon_header
                              io_wd_view_controller       = lo_wd_view_controller
                              io_wd_component_controller  = lo_wd_component_controller
                              io_meta_init                = wd_this->mo_meta_init
                              ion_wd_set_header_text      = lon_header_text_note ).

 

WDDOMODIFYVIEW

Call refresh method of Dependent object mapper class

wd_this->mo_dodm_sc_h_bd->/sapsrm/if_cll_mapper~refresh( ).

Almost all the WD components involved in SC, follow the same pattern of code as mentioned above.

Let’s look at what happens inside the creation of DODM instance, i.e. code in WDDOINIT method

Class Method
In WDDOINIT method

wd_comp_controller->mo_bom_sc->get_dodm_sc_h_bd

 

return parameter of this method is wd_this->mo_dodm_sc_h_bd

-/SAPSRM/CL_CH_WD_MAP_FACTORY /SAPSRM/IF_CH_WD_MAP_FACTORY~CREATE_DODM_SC_H_BD
– > /SAPSRM/CL_CH_WD_MAP_FACTORY

/sapsrm/if_ch_wd_map_factory~create_set_facade

 

Return parameter of this method is lon_cll_set_facade

 — ->    /SAPSRM/CL_CH_WD_MAP_FACTORY

/sapsrm/if_ch_wd_map_factory~create_set_facade_by_xo_mapper

 

In this method instance of the class /sapsrm/cl_ch_wd_set_facade is created and reference is passed as return parameter ro_set_facade

  —–  ->         /SAPSRM/CL_CH_WD_SET_FACADE CONSTRUCTOR
  ———->          /SAPSRM/CL_CH_WD_SET_FACADE

INIT

Several things happened in this method. Attributes of the context along with their value binding paths are retrieved. Set type (for header it is ‘05’) are retrieved. All this information is stored in attributes of class /sapsrm/cl_ch_wd_set_facade

Once the set_facade process  ( call to method /sapsrm/if_ch_wd_map_factory~create_set_facade

)as mentioned above is over below calls happen

/SAPSRM/CL_CH_WD_DODM_SC_H_BD

CONSTRUCTOR

Variable lon_cll_set_facade is passed to import parameter ion_cll_set_facade

à/SAPSRM/CL_CH_WD_DO_MAPPER

CONSTRUCTOR

Here attribute mon_cll_set_facade is assigned value of import parameter ion_cll_set_facade

 

 

Please note the context is still not filled with the values yet. It happens in WDDOMODIFYVIEW method in below call

                 wd_this->mo_dodm_sc_h_bd->/sapsrm/if_cll_mapper~refresh( ).

In this call

  • All the required data that is needed to fill in the HEADER context are extracted and massaged using BO PDO class. In this case it is /SAPSRM/CL_PDO_BO_SC.
  • Once we have the required data fill in variable ls_context_header. This variable refers to structure /sapsrm/s_cll_wd_sc_header, same structure as the HEADER node refers to ( makes sense isn’t it?)
  • Fill in context using bind_data_strucutre method of class /SAPSRM/CL_CH_WD_SET_FACADE. mon_cll_set_facade is filled in the constructor of DODM class ( see above call stack table)

mon_cll_set_facade->bind_data_structure( new_item = ls_context_header ).

  • Inside the above method there is a call to BIND_STRUCTURE method of class /SAPSRM/CL_CH_WD_CTX_DLGT_STD
  • Inside this method we have call to actual BIND_STRUCTURE method of interface IF_WD_CONTEXT_NDOE implemented by class CL_WDR_CONTEXT_NODE_MAP
  • We have accomplished our mission impossible by finding where call to BIND_STRUCTURE method happens J J

 

Have a nice day and keep blogging 🙂

 

 

 

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply