Values retrieved by OVS not binded to the context node

[matteo_montalto]

Hi all gurus,

In SRM 7 I'm working on an ABAP web dynpro (/SAPSRM/WDC_DODC_CT) which is intended to show a document's header custom table. In the unique view of this web dynpro, the user can see the table (made up by custom fields) and can add or remove a line.

I created dinamically a pair of OVS search help for some of the fields of the table, in this way (method WDDOMODIFYVIEW):

* insert: Object Value Selector for ZZ_PROLE_R3 and ZZ_LIFNR_R3
      DATA: lo_tabnode        TYPE REF TO IF_WD_CONTEXT_NODE.
      DATA: lo_tabnode_info   TYPE REF TO IF_WD_CONTEXT_NODE_INFO.

      lo_tabnode = wd_context->GET_CHILD_NODE( name = 'THCUS' ). "the custom table node
      lo_tabnode_info = lo_tabnode->get_node_info( ).
      CALL METHOD lo_tabnode_info->set_attribute_value_help
        EXPORTING
          name = 'ZZ_PROLE_R3'
          value_help_mode = 131 "ovs mode
          value_help = 'OVS'
.
      CALL METHOD lo_tabnode_info->set_attribute_value_help
        EXPORTING
          name = 'ZZ_LIFNR_R3'
          value_help_mode = 131 "ovs mode
          value_help = 'OVS'
.

and these Object-value selectors seem to work properly: the user can trigger them and the selection populates correctly the related field, in the selected row, of the table.

So we could say that apparently, everything seems ok. BUT...

...if I then SAVE the document, or simply change to another view and come back, the new entries added via search help disappear.

It's like there's something missing (a binding?) on the "lower" level...But I don't understand what's the point.

Otherwise, if a value is entered directly by hand by the user, the new row remains persistently (that is to say, direct fill by the user populated correctly the table view AND related fields in the buffer table). Is there something I'm missing?

This is the third - and last - phase in my OVS method (ON_OVS_R3_ROLE):

WHEN if_wd_ovs=>co_phase_3.
*   apply result

        IF ovs_callback_object->selection IS NOT BOUND.
******** TODO exception handling
        ENDIF.

        ASSIGN ovs_callback_object->selection->* TO <ls_selection>.

        IF <ls_selection> IS ASSIGNED.
          ovs_callback_object->context_element->set_attribute(
                                 name  = `ZZ_PROLE_R3`
                                 value = <ls_selection>-zz_prole_r3 ).

        ENDIF.

Help and suggestions are highly appreciated.

M.

Edited by: Matteo Montalto on Nov 12, 2010 4:14 PM

[matteo_montalto]

Solved!

I added the following code line at the end of the OVS method (phase 3):

ovs_callback_object->context_element->SET_CHANGED_BY_CLIENT( flag = 'X' ).

This is sufficient to trigger the CHANGE BADI after the next user operation.

Thanks again!

[Former Member]

GREAT!!!!

Matteo, I've faced the same Problem, and now i've soved with you indication!!!

Thank You.

[Former Member]

Hi,

As you have writtent the code in WDDOMODIFYVIEW, everytime you naovigate to other view or any action, this method gets triggered. And the code also runs. Do you want it to show for first time then use firt time variable or if you want you OVS to run..everytime/needs refresh then no need to use the first time. Keep deubuging and check..I guess the values are getting refreshed here..

Regards,

Lekha.

[matteo_montalto]

Hi Lekha and thanks for your help,

I'd surely try to check whether the point is the first-time execution you explained me; what sounds strange is that on that part of code I simply associate a table field to an OVS help, so the method ON_OVS_R3_ROLE is not triggered at that point.

In fact... pre-existing lines (calculated elsewhere and filled by a BADI in the table) of the tables are ALWAYS visible (and for that field, ZZ_PROLE_R3, they have the associated OVS search help).

I'm gonna restrict that OVS-field binding just to the first time execution and see what happens. Thanks again.

EDIT: I checked it; the above posted sketch of code in WDDOMODIFYVIEW is already in the IF FIRST_TIME EQ 'X'. section.

Edited by: Matteo Montalto on Nov 12, 2010 5:21 PM

[matteo_montalto]

HI,

I found the clue, but basically I have no idea on why it happens

This is the point: when I select a possible value from a select list in the OVS help, then the corresponding value(s) on the tables are filled BUT no CHANGE BADI is in this case triggered. Odd thing is that even if I select the field populated by the search help and press ENTER, the BADI isn't triggered.

Standard behaviour, which happens anytime I enter a value "manually", triggers the CHANGE BADI automatically (I can see in debug that the stack of the calls contains a fire_event_update, that's probably the clue).

So I guess the point is how to make a selection from a select list in OVS be equivalent to a value enter manually, so that we could generally say that anytime an input is filled - no matter if by OVS or "by hand" - the underlying CHANGE BADI is triggered.

Any help or suggestion is really appreciated,

thanks.