WD Screen Variants – Main View

overview

<< previous | next >>

The concept of a selection screen variant is something that most SAP users have come to expect, yet this feature is unavailable in standard Web Dynpro. Below is the next in a series of posts detailing how to bring this necessary feature back to Web Dynpro. Start here to see the full requirements.

The MAIN view has a very simple layout.  Drop three Web Dynpro buttons on the view, named as shown below.

All of the real work in the MAIN view happens in the Methods.

The flow is essentially the same for each button on the Layout, with some minor differences between them.

1. Each button is assigned an action: ONACTIONBTN_GET_CLICK, ONACTIONBTN_SAVE_CLICK, and ONACTIONBTN_DELETE_CLICK.
2. The button click event then creates an instance of a window: W_GET_VARIANT (for Get and Delete) or W_SAVE_VARIANT (for Save).  The [OK] button of the window is assigned to another event: ONACTIONGET_OK, ONACTIONSAVE_OK, and ONACTIONDELETE_OK.
3. In the case of the Save and Delete operations, a confirmation window may be displayed in which a second [OK] button is tied to an event: ONACTIONSAVE_CONFIRM and ONACTIONDELETE_CONFIRM.
4. Following all the user interaction and validation the requested operation is executed at the Component Controller level.

In the next post, I’ll detail my implementation of the Get Variant process flow.

overview

<< previous | next >>

WD Screen Variants – WD Component

overview

<< previous | next >>

The concept of a selection screen variant is something that most SAP users have come to expect, yet this feature is unavailable in standard Web Dynpro. Below is the next in a series of posts detailing how to bring this necessary feature back to Web Dynpro. Start here to see the full requirements.

Start your development by creating a new Web Dynpro component named ZES_SELOPT_VARIANT. This WD component will have a public interface with a few methods used to initialize the report name and selection screens. It will have one main window that contains three buttons (by default): Get Variant, Save Variant, and Delete Variant. 
In the Web Dynpro component, we’ll need to use two instances of the Web Dynpro ALV component:

Comp. Use	Component	Description
ALV1	SALV_WD_TABLE	List of existing selection screen variants for this Web Dynpro application)
ALV2	SALV_WD_TABLE	List of fields assigned to this set of selection screens.

This is also where you identify the assistance class created earlier.
In the Component Controller, add the following context nodes:
Node: TEXT stores the values of various labels used through the component.

Node: IN stores values that are bound to various screen elements throughout.  This elements in this node could have used a little more structure – maybe split out by view - given the time.

Node: VARIANT_LIST is a table of variants associated with the REPORT_NAME assigned when the component is initialized.

Node: VARIANT_FIELDS holds a table of fields associated with the currently selected (or newly created) variant.

Node: FIELD_PARAMS is a single-line structure that holds the values selected by the user from view V_ASK_PARAMETERS that are used to help determine dynamic dates (more later).

One additional attribute is required on the Component Controller: M_CLEAR_MSGS.  This value will be set at each *first* display of the W_GET_VARIANT and W_SAVE_VARIANT windows in order to prevent ‘required field’ warnings from being shown to the user.  The MO_GET_WINDOW is not used.  It was added as part of an attempt to get the W_GET_VARIANT window to auto-close when a row is selected.

I added the following events to the Component Controller:

The following methods were added as part of the Web Dynpro Component interface in order of importance:
SET_REPORT_NAME:  Here we’re simply setting the the context node element to remember the value.

   1: METHOD set_report_name .                                    " PLM8034

   2:  

   3:   DATA: lo_nd_in                      TYPE REF TO if_wd_context_node.

   4:   DATA: lo_ni_in                      TYPE REF TO if_wd_context_node_info.

   5:   lo_nd_in = wd_context->get_child_node( name = wd_this->wdctx_in ).

   6:   lo_ni_in = lo_nd_in->get_node_info( ).

   7:  

   8:   lo_nd_in->set_attribute( EXPORTING: name = 'REPID'

   9:                                       value = i_report_name ).

  10:   me->refresh_variant_list( ).

  11:  

  12: ENDMETHOD.

It’s also important to know what the REFRESH_VARIANT_LIST routine is doing. It’s called when the report name is set in addition to a couple of other important times. This retrieves a list of variants from the transparent table created for storing the variants for the report name indicated above.  It binds this list to the VARIANT_LIST context node.

 

   1: METHOD refresh_variant_list .                               " PLM8034

   2:  

   3:   DATA: lo_nd_in                      TYPE REF TO if_wd_context_node.

   4:   DATA: lo_ni_in                      TYPE REF TO if_wd_context_node_info.

   5:   lo_nd_in = wd_context->get_child_node( name = wd_this->wdctx_in ).

   6:   lo_ni_in = lo_nd_in->get_node_info( ).

   7:  

   8:   DATA: l_repid                       TYPE repid.

   9:   lo_nd_in->get_attribute( EXPORTING: name = 'REPID'

  10:                            IMPORTING: value = l_repid ).

  11:  

  12:   DATA: lt_variants                   TYPE TABLE OF zes_wdvari,

  13:         ls_variant                    LIKE LINE OF lt_variants.

  14:   SELECT prog_name vari_name vtext protected

  15:          ename edat etime aename aedat aetime

  16:     INTO CORRESPONDING FIELDS OF TABLE lt_variants

  17:     FROM zes_wdvari

  18:    WHERE relid = 'WD'

  19:      AND prog_name = l_repid.

  20:  

  21:   DATA: lo_nd_list                    TYPE REF TO if_wd_context_node.

  22:   DATA: lo_ni_list                    TYPE REF TO if_wd_context_node_info.

  23:   lo_nd_list = wd_context->get_child_node( name = wd_this->wdctx_variant_list ).

  24:   lo_ni_list = lo_nd_list->get_node_info( ).

  25:  

  26:   lo_nd_list->bind_table( lt_variants ).

  27:  

  28: ENDMETHOD.

APPEND_SELOPT_SCREEN: Add the value supplied to the list of selection screens to process later when getting/saving the variant.

 

   1: METHOD append_selopt_screen .                               " PLM8034

   2:   APPEND i_selopt_screen TO wd_assist->selopt_screens[].

   3: ENDMETHOD.

SHOW_BUTTONS: Show/hide Get/Save/Delete buttons (untested)

 

   1: METHOD show_buttons .                                       " PLM8034

   2:  

   3:   DATA: lo_nd_in                      TYPE REF TO if_wd_context_node.

   4:   lo_nd_in = wd_context->get_child_node( name = wd_this->wdctx_in ).

   5:  

   6:   lo_nd_in->set_attribute( EXPORTING: name = 'VISIBLE_BTN_GET'

   7:                                       value = i_btn_get ).

   8:   lo_nd_in->set_attribute( EXPORTING: name = 'VISIBLE_BTN_SAVE'

   9:                                       value = i_btn_save ).

  10:   lo_nd_in->set_attribute( EXPORTING: name = 'VISIBLE_BTN_DELETE'

  11:                                       value = i_btn_delete ).

  12:  

  13: ENDMETHOD.

GET_VARIANT_NAME: Get variant name chosen by user (untested)

 

   1: METHOD get_variant_name .                                   " PLM8034

   2:  

   3:   DATA: lo_nd_in                      TYPE REF TO if_wd_context_node.

   4:   lo_nd_in = wd_context->get_child_node( name = wd_this->wdctx_in ).

   5:  

   6:   lo_nd_in->get_attribute( EXPORTING: name = 'VARIANT_NAME'

   7:                            IMPORTING: value = r_result ).

   8:  

   9:  

  10: ENDMETHOD.

The WDDOINIT method is called immediately at initialization.  First, I’m initializing the list of ‘dynamic date’ routines used later for DATS fields.  Then I’m setting the labels for various controls used through the views based on logon language.  Finally, I indicate that the MAIN view should show all three buttons by default.

 

   1: METHOD wddoinit .                                           " PLM8034

   2:  

   3:   wd_assist->init_varivar_table( ).

   4:  

   5:   DATA: lo_nd_text                    TYPE REF TO if_wd_context_node.

   6:   lo_nd_text = wd_context->get_child_node( name = wd_this->wdctx_text ).

   7:  

   8:   DATA: l_text                        TYPE string.

   9:  

  10:   l_text = wd_assist->get_text( '001' ).

  11:   lo_nd_text->set_attribute( EXPORTING: name = 'GET'

  12:                                         value = l_text ).

  13:  

  14:   l_text = wd_assist->get_text( '002' ).

  15:   lo_nd_text->set_attribute( EXPORTING: name = 'SAVE'

  16:                                         value = l_text ).

  17:  

  18:   l_text = wd_assist->get_text( '003' ).

  19:   lo_nd_text->set_attribute( EXPORTING: name = 'OK'

  20:                                         value = l_text ).

  21:  

  22:   l_text = wd_assist->get_text( '004' ).

  23:   lo_nd_text->set_attribute( EXPORTING: name = 'CANCEL'

  24:                                         value = l_text ).

  25:  

  26:   l_text = wd_assist->get_text( '005' ).

  27:   lo_nd_text->set_attribute( EXPORTING: name = 'PROTECTED'

  28:                                         value = l_text ).

  29:  

  30:   l_text = wd_assist->get_text( '006' ).

  31:   lo_nd_text->set_attribute( EXPORTING: name = 'PARAM1'

  32:                                         value = l_text ).

  33:  

  34:   l_text = wd_assist->get_text( '007' ).

  35:   lo_nd_text->set_attribute( EXPORTING: name = 'PARAM2'

  36:                                         value = l_text ).

  37:  

  38:   me->show_buttons( ).

  39:  

  40: ENDMETHOD.

Okay that gets a real good start on the Component Controller.  In truth there are quite a few more methods on this object that we’ll get into a little later.  These methods are called by user-events, but were placed at the Component Controller level, because it already had access to the shared Context nodes we created above.

overview

<< previous | next >>

WD Screen Variants – Assistance Class

overview

<< previous | next >>

The concept of a selection screen variant is something that most SAP users have come to expect, yet this feature is unavailable in standard Web Dynpro. Below is the next in a series of posts detailing how to bring this necessary feature back to Web Dynpro. Start here to see the full requirements.

Start a new ABAP class ZCL_WDR_SELOPT_VARIANT.  It should inherit from CL_WD_COMPONENT_ASSISTANCE in order to be a true Web Dynpro assistance class (however, this isn’t a requirement).  An Assistance Class is assigned to a Web Dynpro component for two reasons: text elements and class-based coding.

Text Elements

I use this class to hold a list of language-dependent label captions that can be translated as needed.

Classic ABAP Class-based Code

I’ve made the assistance class very important to this project by placing the list of assigned select options in this class.  It also stores a list of dynamic-date functions from RS_VARI_V_INIT.

You’ll see later where these methods are called.  The GET_TEXT method is simply a call to Web Dynpro assistance class GET_TEXT.  This makes for a more simple method call inside my Web Dynpro component.  The INIT_VARIVAR_TABLE is called at initialization to populate the MT_VARIVAR variant variables function list.

This method gets a list of the various dynamic date possibilities:

   1: METHOD init_varivar_table.

   2:  

   3:   CALL FUNCTION 'RS_VARI_V_INIT'

   4:     TABLES

   5:       p_varivar = me->mt_varivar[].

   6:  

   7: **********************************************************************

   8: * Hide these dynamic date possibilities.

   9: * We don't have factory calendars configured in D15.

  10: **********************************************************************

  11:  

  12:   DATA: ls_varivar                    TYPE rsvarivar.

  13:   LOOP AT me->mt_varivar[] INTO ls_varivar.

  14:     CASE ls_varivar-runt_fb.

  15:       WHEN 'RS_VARI_V_TODAY_XWD' OR

  16:            'RS_VARI_V_WDAYS_UP_TO_NOW' OR

  17:            'RS_VARI_V_XWD_ACTUAL_MONTH'.

  18:  

  19:         DELETE TABLE me->mt_varivar[] FROM ls_varivar.

  20:  

  21:       WHEN OTHERS.

  22:     ENDCASE.

  23:   ENDLOOP.

  24:  

  25: ENDMETHOD.

Next, let’s dive into the Web Dynpro component itself.

overview

<< previous | next >>

WD Screen Variants – DDIC Changes

overview

<< previous | next >>

The concept of a selection screen variant is something that most SAP users have come to expect, yet this feature is unavailable in standard Web Dynpro.  Below is the next in a series of posts detailing how to bring this necessary feature back to Web Dynpro.  Start here to see the full requirements.

Data Dictionary Changes
First we need a data store. In SE11, create a new table ZES_WDVARI. This table conforms to the specifications of the IMPORT/EXPORT database ABAP command.


We’ll also need a few additional data dictionary objects:
This structure will be used to hold the content of the data stored into ZES_WDVARI-CLUSTD (raw data) field). 
 
This structure includes some additional fields used to display data to the user in the Web Dynpro ALV. 
 
Table type used for class method parameters.
 
Table of Web Dynpro Select Options will contain a list to all select option screens being considered as part of this variant.

Now that we have the dictionary objects in place, let’s take a look at the development.

overview

<< previous | next >>