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.
Here is the flow of the Get operation. This is where it starts to get fun.
When the user clicks the button, the BTN_GET_CLICK event is fired. This event creates an instance of the W_GET_VARIANT window and also assigns the [OK] button to the GET_OK action before opening the window.
As you can see – I toyed with trying to allow the row selection to cause GET_OK event to fire. Unfortunately – I didn’t have enough time to make it function properly. I’m open to suggestions. I’d like to include it next time around.
The W_GET_VARIANT window utilizes the V_GET_VARIANT view. The view itself contains only one element: a ViewContainerUIElement named VIEW_LIST. This is one of our WD ALV grids, so within W_GET_VARIANT we need to embed ALV1 into the VIEW_LIST container.
Now inside the view, there’s a lot of work to be done to set up the list. I created a method INIT_ALV to help with this. It’s job is to create the usage of the ALV1 component and then configure the ALV for a minimalist view of the variants retrieved by the Component Controller during initialization.
INIT_ALV is called from the WDDOINIT of V_GET_VARIANT. WDDOINIT also uses a public variable set at the Component Controller level to determine whether to clear messages. This was useful in that if the source selection screen contains required input values, any error messages displayed during validation would not get replicated in this pop-up window. Using m_clear_msgs variable, though, allows flexibility to display any error messages that you might want to display (example: during the Save operation if the user fails to enter a variant name).
After we’ve configured the variant list, we’re finished with the V_GET_VARIANT view. The rest happens outside this view after the user clicks [OK]. Remember that the [OK] button is mapped to the GET_OK action. So when ONACTIONGET_OK is called, there are three things to do:
- Get the selected variant
- Load the variant into the WD selection screen
- (Optionally) fire an ‘after get’ event
To get the selected variant, we need to retrieve the variant name from the first selected entry in the variant list. I then load them into my ‘IN’ node for downstream processing.
The LOAD_VARIANT method exists at the Component Controller level. It’s job is to retrieve the variant details and set these values into the WD selection screen.
We’re about to get into the nuts and bolts of this whole thing. Retrieving the details is as easy as the IMPORT FROM DATABASE statement above. In order to set the details into the WD selection screen is a little more involved – the SET_FIELDS method is here for that. For each selection screen assigned, I get the parameter fields and assign those values, and then work with the selection fields. The work in both cases is very similar:
- Check if anything is assigned for this field in the variant.
- If so, then change the assignment in the field.
- If not, then make sure the field is set to INITIAL.
There is one additional helper routine SET_FIELD_PARAMS that provides support for dynamic dates. We’ll get to that in a later post.
The REFRESH_VARIANT_FIELDS routine could more properly be thought of as part of the Save Variant process, but it happens during Get Variant only because the data is currently in memory. It collects meta data about the fields and prepares the field list that is to be displayed in the V_SAVE_VARIANT view. More on that later.
The last thing that happens in the Get Variant [OK] button event is to fire the Component Controller’s public AFTER_GET event. This allows other applications to perform additional processing after the variant details have been set into the selection screen.
That finishes out retrieving the variant. Next I’ll discuss the routines involved in saving.