Tracking subnode data changes using CL_WD_CONTEXT_SERVICES

[Former Member]

Hi Experts,

Am trying to track the context node changes within my web dynpro component. So I first tried using the Context change log mechanism {i.e, method GET_CONTEXT_CHANGE_LOG method of interface IF_WD_CONTEXT} However despite repeated attempts the log always used to come up as empty.

So I tried using the method GET_CHANGE_LIST of CL_WD_CONTEXT_SERVICES instead & this does help me a bit further. I have 2 context nodes which i would like to track: DEV_NEEDS & DEV_ACTIVITIES. The node DEV_ACTIVITIES is defined as a sub node of DEV_NEEDS. The problem is that GET_CHANGE_LIST of CL_WD_CONTEXT_SERVICES is tracking the changes done in DEV_NEEDS but not its child node DEV_ACTIVITIES. Is there anything that am missing out while trying to capture the data of sub nodes using this approach? And also the logic for CL_WD_CONTEXT_SERVICES seems to be based on context change log mechanism itself. So I am confused as to why the context change log mechanism would not work by itself on a standalone basis. Any inputs would be greatly appreciated.

Regards,

Uday

Code for subscribing within WDDOINIT :

DATA: lt_subscription TYPE cl_wd_context_services=>subscription_list,
        ls_subscription TYPE cl_wd_context_services=>subscription_element.


  IF wd_this->mo_context_services IS NOT BOUND.
    CREATE OBJECT wd_this->mo_context_services.
  ENDIF.

  ls_subscription-controller = wd_this->wd_get_api( ).
  ls_subscription-node_name = 'DEV_ACTIVITIES'.
  APPEND ls_subscription TO lt_subscription.

  ls_subscription-controller = wd_this->wd_get_api( ).
  ls_subscription-node_name = 'DEV_NEEDS'.
  APPEND ls_subscription TO lt_subscription.

  wd_this->mo_context_services->subscribe_to_node_changes( subscriptions = lt_subscription ).
  wd_this->mo_context_services->activate_subscriptions( ).

Code for retrieving the changes in method WDDOAFTERACTION:

METHOD wddoafteraction .
  TYPES:
    BEGIN OF changed_item,
      controller     TYPE REF TO if_wd_controller,
      node_name      TYPE string,
      node           TYPE REF TO if_wd_context_node,
      node_path      TYPE string,
      change_kind    TYPE char1,
      element_index  TYPE i,
      attribute_name TYPE string,
    END OF changed_item .

  data:
    changed_list TYPE SORTED TABLE OF changed_item WITH NON-UNIQUE KEY controller node_name .

  CALL METHOD wd_this->mo_context_services->get_change_list
*  EXPORTING
*    reset_list    = ABAP_TRUE
    RECEIVING
      changed_items = changed_list.

[uday_gubbala2]

Thanks a ton to Mohammed Anzy S & Thomas Szuecs. I (Rather they) have now managed to overcome the problem. The issue was that my context nodes were created at COMPONENTCONTROLLER level while the code snippet for subscribing to the nodes was within the WDDOINIT of my local view. The lesson learnt is that the change log needs to be enabled for the controller where the original node resides. So am now able to harness the power of CL_WD_CONTEXT_SERVICES whilst the other method continues to lend me a deaf ear...

Regards,

Uday

[Former Member]

>

> Hi Experts,
> 
> Am trying to track the context node changes within my web dynpro component. So I first tried using the Context change log mechanism {i.e, method GET_CONTEXT_CHANGE_LOG method of interface IF_WD_CONTEXT} However despite repeated attempts the log always used to come up as empty. 

Hi, i assume that you have enabled the context change log before you attempt to get the change log.

DATA: lr_context TYPE REF TO if_wd_context.

lr_context = wd_context->get_context( ).
lr_context->enable_context_change_log( ).

Find out why it is not having any changes recorded. My advice is to stick with GET_CONTEXT_CHANGE_LOG approach rather than CL_WD_CONTEXT_SERVICES.

[uday_gubbala2]

Hi Baskaran,

I was very much using the same context change log mechanism earlier & my code was working all perfectly. It did then somehow stop working all of the sudden one day. i searched around but couldnt find any possible reasons behind it over SDN/OSS. So I did finally give up & got for a complete manual ABAP coding upon the clients persistence. Now they have came up with a functional change that's rendering my ABAP code meaningless so this is when I got to discover the CL_WD_CONTEXT_SERVICES. I just gave it a try & its at least capturing the changes partially while the context log mechanism does still come up as blank. You can find the details of my go at the context change log mechanism in this [thread|; that i had rose at around that time.

Regards,

Uday