Let’s Web Dynpro.

Part I
The title is inspired from the book “Let us C”. A very popular book on “C” at
our part of the world.
Web Dynpro: It is neither a tool with only drag and drop (those who have
actually not worked would say this) nor is it something only for the Geeks
(some who have worked might flaunt). So, neither under estimate it nor be
scared of it. It is like any other area of SAP ABAP, which helps the developer
to achieve the requirement and deliver some cool applications.
In this post and the series to follow, we are planning to provide the concepts
to understand the basics of ABAP Web Dynpro. This series would act as a
launching pad for our readers to develop their initial Web Dynpro applications.
We would hand hold you and provide you some actual project requirements
and how to achieve them.
This series would not give you detailed theories. There are tons of materials
already available for theories and practice.
This would be different than others and would just concentrate on the basics;
and some practical tweaks and tricks.
Let’s start..
We can make vague analogy between Web Dynpro terms and classical ABAP
terms for simplicity. Some of them are:
Context <=> Variable
Context node <=> Internal Table/Structures/Work Areas
Context attribute <=> Fields of variables (single field or fields of
structure / internal table)
Component Controller <=> TOP include program (declare global variables)
Custom/View Controller <=> Sub routine ( declare local variables )
Windows <=> Windows ( container )
Views <=> Views ( content )
WD Applications <=> Transaction codes
There are numerous UI elements in WD ABAP. But the most commonly used
ones are:
1. Tray
2. Group
3. Transparent Container
4. Label
5. Text Edit/View
6. Input Field
7. View Container
8. Button
9. Message Area
10. Checkbox
11. Radio Button
12. Drop down by Index
13. Drop down by Key
14. Link to Action
15. Tab Strip
16. Toggle Button
Assistance Class.. What exactly is it?
Assistance Class is the “M” of the famous “MVC”, Model View Controller. All the
extraction, massaging and modelling should be done in the assistance class.
What are the steps to start a Web Dynpro assignment?
Like any normal program, you should first define the Types and Data
(variables, internal tables, work areas), i.e.in WD, you should declare the
contexts.
Usually, normal program has selection screen parameters and select options.
In most cases, the selection screen data are global. Similarly in WD, the
contexts for the initial view(s) are usually defined at the Component Controller
Level (as they are global).
In normal programs, the global variables are automatically available in all
subroutines. In WD, the context of the global component controller are not
automatically available to other controllers. We need to map the context of
component controller to the respective custom/view controllers. By mapping,
it means, context with the same name is created in the custom/view
controllers (and they are linked). It is like passing parameters to the sub
routines in normal ABAP. If the parameters are changed in the sub routine,
the same is reflected in the calling program. Similarly if the context of the
component controller is changed in the custom/view controller, it is reflected
globally.
Let’s Web Dynpro. Part I
In Part I, we gave you a very basic overview of Web Dynpro. In this part we
will create one Web Dynpro Application.

Before we develop our first Web Dynpro application, let me ask, what steps
do you follow while writing a normal ABAP program/report in SE38/SE80,
which has a selection screen; an output screen and a custom transaction
code?

Let me note down that steps:

ABAP Editor or Object navigator
1. Go to SE38 or SE80 and create a program. Give the description and
attributes and save it in transport or as local object.
AT SELECTION SCREEN and SCREEN EVENTS
2. Declare the selection screen parameters and select options thereby
creating a selection screen.
3. Declare global data which would be used throughout the program.
START OF SELECTION
4. Fetch data from database tables.
5. Try to modularize (using subroutines) your data fetches if from numerous
tables.
6. Declare local data which would be used in subroutines.
END OF SELECTION
7. Massage the data and prepare the final data for output (modularize here
as well).
8. Display the output.
9. Activate your program.
Create Custom T-Code for the program using SE93.
10. Create transaction for your report.

Congratulations!!! You just created your first Web Dynpro Application. No

kidding. We will create a cool WD report in similar steps as mentioned above.
Let’s assume the requirement of your functional specification says: Create a
Portal screen which would display the SAP user’s first name and last name.
Use table view USER_ADDR to retrieve data.

Happy to get your first Web Dynpro Functional Specification. Let’s jump
into the system.

Please scroll up and walk through the steps.

Step 1: Go to SE80 Object Navigator. Select Web Dynpro Comp./Intf from
the dropdown. Give a name to the WD component which you want to create
and hit enter. You will get a message as shown in picture below.

Give a meaning description and name (as shown in next picture) for your
default/main Window and View. Name it as per your project standard.
Usually we have WI_ or W_ for windows and VI_ or V_ for views. Then save
it. Give appropriate package and transport number else save it as local
object if you do not want to move to next environment. Now you have
created your first WD component which is empty.
Step 2: Declare selection screen parameters. Since it would be used
globally, let us define the variable (context) in the component controller
(global/top). Double click on COMPONENTCONTROLLER in the left panel and
click the Context Tab in the right panel.
Right click the CONTEXT ->Create-> Node. This is the name of your
structure used in selection screen parameter. We generally use CN_ for
context node and CA_ for context attribute. Give a meaningful name and hit
enter.
You created a structure, but it is empty. You need fields in the structure to
make it complete. Right click on the context name CN_SELECTION_SCR -
>Create->Attribute; give a name and data-type of the field and save and
activate all the objects of the components. This is the global variable for the
selection screen.
Tip: Try to activate your component after every major change/development
so that if any error, you can find and resolve it easily. If you activate at the
end, after creating everything, then it might be little more tiresome to
resolve the issue.

As I mentioned in PART I, the global variable are not directly available to the
views. We need to make the view know that the global variable
(CN_SELECTION_SCR) would be used in that view. This can be done by
dragging the COMPONENT CONTROLLER Context attribute to View Context.
Expand the View in the left panel. Double click on the view name. Click the
Context Tab on the right Panel. On the right panel there is a split. Left for
View and Right side for COMPONENT CONTROLLER Context. Left click on the
CONTEXT CN_SELECTION_SCR hold and drag and put it on top of V_MAIN
CONTEXT on the left. This is like USING/CHANGE Parameters of SUB
ROUTINE (PERFORMS) in normal program.
Now we are good to design the screen. View->Layout. Right click on
ROOTUIELEMENTCONTAINER and insert one TRANSPARENT CONTAINER.
Transparent containers are just holder of UI elements. Usually, related UI
elements are collected in a TRANSPARENT CONTAINER.
Now let us define an input parameter for the screen (just like we do in
SE38). Right click on Transparent Container and create Input field.

This is just a variable, but what data would it hold? We will link this input
field to the USERID field defined in the context CN_SELECTION_SCR. Click on
the yellow icon on the right side of value property and bind it with USERID.
It is just like our PARAMETERS: P_INPUT TYPE XUBNAME. Any value entered
in this parameter in selection screen is passed to P_INPUT and it can be used
in the whole program.

Let us give a meaningful label to the selection screen parameter. Just like in
SE38, we create Selection Screen text, in the similar way, a LABEL UI
element tagged to Input Field would act as its text, which would be displayed
in the selection screen. Right click on Transparent Container and create the
Label. Populate the Label For field.
By default it would be on the right side of the field. Move it up so that it is on
the left side.
Let us look how the window looks. In the main window, the default main
view is assigned. So, whatever we have designed till now is available to be
displayed in the window.
Step 3: WD Application like our familier Transaction Code created in SE93:
At this juncture, you would be tempted to see how your selection screen
looks like. For that we need to create the application (like you need a
transaction code for a program). Right click on your Component and create
the application and save it.
Now you can execute it by F8 or by right clicking the application and Test.

Congrats!! Your screen look perfect..

Step 4: Interactive Buttons:

Screen is ready, but user would need something to interact. So, button is
needed. Let us create a button, which would let the system know that some
action is done and it has to perform some function.

Create another Transparent Container. Right click on transparent container

and create a Button UI element.
Link an action to the button. Click on the create icon on the right of onAction
Events property. Give a meaningful name and description to the action. A
method is created for this action in the background as shown.
Step 5: Preparation to display the output:
Now, we have the input field and button. But, still we do not have the place
holder for final output. So, let us create another CONTEXT
(CN_USER_DETAIL) which would be local to the view (assuming this context
would not be used in any other place). In the context define three attributes,
USERID, NAME_FIRST and NAME_LAST (referring to table
view USER_ADDR).
So output type is defined but it is not yet linked to any variable. Let us create
three input fields in a transparent container and link the values to
corresponding fields in the CONTEXT CN_USER_DETAIL. Below it is shown for
only USERID. We need to do for all three.
Since these three attributes would be used for display only, let us check the
displayOnly property for all three.

You would like to see the three attribute in one row, not in one column. For
this we need to change the layout type to Matrix Layout. We would speak
more about Flow, Matrix data and Matrix Head data layout in subsequent
sessions.
Let us see the screen again.
It has the input field and the execute button. But, what will the button do,
we have still not defined the data extraction and display logic.

Step 6: Start of Selection:

Read the value entered by user in the INPUT Field USERID in the portal
screen. This can be easily done by reading the CONTEXT which is linked to
USERID field. User the MAGIC WAND (highlighted with number 1) provide by
SAP. Most of your Web Dynpro code or at least the skeletal code snippet can
be generated by using this Magic Wand (wizzard). You need to go to the
Methods tab of the View or double click the Execute action of button
BT_EXECUTE.

Check the READ radio button and then hit the CONTEXT and choose the
CONTEXT field which is bound/linked to the INPUT field. Hit enter. All the
code is generated for you. Remove the commented code and some check
codes which are not needed for our scenario. Whatever user enters in
IP_USERID field in selection screen is available in variable lv_userid.

Now, whatever data you want to display in the three attribute of the output
context, we need to SET them, i.e. we can use the same magic wand to SET
the CN_USER_DETAIL context as shown.
The LS_CN_USER_DETAIL structure would display the user details. But, the
structure is still empty. We need to select the data and populate
the structure. We will write a simple select statement and populate the
structure as shown.

PS: This is the only piece of code we write for this application.. Isn’t it

awesome..
Uffff !!! We have done all steps. Fetched data based on input field and
populated the output structure. And linked all the UI elements to the
underlying context.

Let us test our first baby.. Let me enter an SAP user id present in our system

and hit the Get Data button. Abracadabra… Details are displayed..

This was one of the simple valid project requirements. Please do not smile,

this was one of the requirement in one of our project.. We would add on
the complexity and explore the different features of Web Dynpro in
subsequent parts. Till then, please play around this component and stay
tuned.

Let’s Web Dynpro. Part III

In Part II, we created one input field, a button and one line of output. In this
post, we would create more than one input fields, a button and a table with
multiple lines as output.

Lets assume your functional specification documents says; We need a portal

application which would report the number of orders created by particular
users in a given date frame. Document name, Document type, creation date

and user who created should be reported. Complex . In other words,

create one input field for User Id, one range for Date field and display VBAK-

VBELN, VBAK-AUART, VBAK-ERDAT and VBAK-ERNAM.. Easy ..

Lets plan our design as we did in Part II.

1) Create WD Component in SE80.

2) In this exercise, we will not create context in the component controller,
but we will create in View Controller and use it locally.
3) Define the input screen context (one line structure type) and output result
context (table type).
4) Design the layout and BIND your input fields and output fields.
5) In the execute button, create an Action and in the automatically created
method, generate the code to read input fields, select data and display
output fields.

Lets start..

Step 1: Create your component in SE80. Go to View Context and define the
selection screen context (CN_SEL_SCREEN). Three attributes/fields i.e.
userid, from date and to date are defined. Similarly define output table
context (CN_RESULT). As per requirement, four fields / attributes i.e. sales
order, created date, createdy by and document type are defined.
Step 2: Go to View Layout and create input fields. Group them in transparent
container. Do not forget to create Labels and align them. Remember to tag
one label with one input field in the LabelFor property of Label.
Your From Date and To Date might not be in one line.. .. Just change the

Layout type to Matrix Layout, both would be in one line.. happy..

Did you bind the input fields to the context? By now, you should know
that, context is your work area or variable or internal table. The UI element
with which you tag/bind it, that context would hold your data.. Freeze it..
Step 3: Anxious to see how your screen looks like. Create an application for
your component (right click and created), give a name and description and
save it. Now right click the application and test or hit F8 to test your screen.

Congrats!! it does show up.

Tip: Please keep your input fields in different transparent containers. Check,
we have different containers for different UI elements. You might not imagine
its importance in simple developments. But for complex one with lots of UI
elements, these transparent container would help in easy grouping and
manipulation.

Step 4: Create another transparent container and pur TABLE UI element in it.
This would be our final internal table. Bind it to the CN_RESULT context
which we have already defined.

Still your table shows: Table does not contain visible columns.. What
does it mean?
You have one more step to do for Tables. Although you have bound the
datasource with CN_RESULT, you still need to create a binding and define
how it should look like.
Right click on the Table UI element -> Create Binding and define the Cell
editior for the table columns. We have shown it as text field. You can show it
as button or input fields etc as per your requirement.
Magic.. your columns are visible now..

Step 5: Oops, we forgot to add the Execute button.

Create the button element and link onAction. Say your action name is
Execute, check ONACTIONEXECUTE method is created.
Step 6: The most important steps. We need to read screen input data, fetch
data from database and display back in the screen.
* 1 Read value in the USERID Context entered in the screen
* 2 Read value in the From Date and Two Date Context entered in the screen
* 3 Select from VBAK table with respect to the input screen fields
* 4 Bind the output to the CN_RESULT context to be displayed in the screen

Lets READ screen data first.

Put the cursor at the right place, hit the wizzard icon (we call it MAGIC
WAND), select READ Operation and then select the Selection Screen Context.
Code is in place to read the screen data and kept in workarea/structure
ls_cn_sel_screen. After deleting commented and unwanted auto-generated
code, we are left with these codes.
Please note, you could have used the wizard to read individual fields instead
of whole structure. In that case, you would have three variable, one each for
user id, from date and to date. Both the way would lead to your solution.
But, second option would generate more lines of codes.

Now, lets SET final output data.

Put the cursor at desired place, hit the MAGIC WAND, make sure to select
SET and As Table Operation (as the output would be displayed in multiple
lines). Auto code are generated and after deleting commented line and
unwanted code, below useful lines are left. LT_CN_RESULT is the final
internal table which should be populated to display the result.
So, we have code to read screen data and display to screen data. But, what
would we display!!!! We need to SELECT data from database and pass it to
output context.
Before LT_CN_RESULT is been bound to screen, we should select the data
and populate it. This is the only piece of code snippet a developer has to

write by him/herself for this application. Isn’t this cool. Less code…

Step 7: Lets test.

Execute your application, give a valid user id and some date range. Bingo..
The output is displayed in the table.

This is a simple post to show output in table. We should handle the errors,
also the output table skeleton should not be shown when we see the page
first. Columns should be displayed once user hits the Execute button. Also,
the date range should be handled so that, To date is not less than From date.

Let’s Web Dynpro. Part IV

In Part III, we displayed a simple output with multiple lines as output. If you
check the initial screen, it has the input fields, dates, execute button and the
output table structure. In acutal project, user would not like to see the blank
output table structure. Also, user would like to get an error message if the
mandatory fields are missing.

[adToAppearHere]

In this post, we would show, how to declare the UI elements as mandatory

and also how to show the output elements (in this case the output table)
only when it is needed, dynamically.

On your mark, get set, go….

A) Output table visibility to be dynamically controlled.

Check the blank output table with SO, Created no/by and SO Type. If you are
the user, you would NOT like to see these structure, when you are in the
initial screen.

Why is it displaying?
Because, we have hardcoded the UI element to be always visible (as shown
in screen shot).

Solution:
Instead of hard coding it to visible, we should point it to a variable, which
should be blank (false) when the user first enters the screen. Once the user
hits the execute button, that variable should be flagged (true) to indicate the
visibility.

How to do control the visibility?

Step 1: Define a context node (cardinality 1:1 should be enough) and define
an attribute (say set_table_visible). This attribute is our variable, which we
would bind with the output table visibility parameter.
Step 2: Bind the visibility property with set_table_visible attribute as shown
in figure. Done!! The output structure would not be visible now.

Step 3: But, it would not be visible even if you hit execute. Because, you
have not written the logic to set the attribute to true, when execute button is
hit. In the method which is called on execute button, set the attribute to
true, using the magical wand as shown in the screenshot.
After removing the commented lines, your code should look like below. You
just need to set the variable to ‘X’ or ABAP_TRUE. Only one line of code has
to be written as shown in line 43 of screenshot.

Step 4: Test it. Your output is visible only when you hit the Execute button.
B) Error message should be displayed if mandatory fields are not
entered

Step 1: Make the State property of the input field to “required”. This would
put a small red asterisk (*).

Begin a developer, we assume our work is done. Now Web Dynpro

framework should handle it automatically. But, we need to implement one

more step.

Step 2: In the event handler method which is triggered by your button

(ONACTIONEXECUTE for this example), we need to write the below piece of
code. Basically, it calls standard method check_mandatory_attr_on_view and
give the missing mandatory fields message.
Web Dynpro would show the message in default area. We can define our
message area and show the message in the place where we want in the
screen.

Check the output.

Link for code snippet for Part III and Part IV in the Execute button
method: OnActionExecute

Let’s Web Dynpro. Part V

In Part IV, we learnt how to make the elements visible as we need them and
also learnt how to make the mandatory fields throw error message. Till now
we dealt with the simple table output. In this part, we would see how we can
display the same tabular output in ALV. For ALV display in Web Dnypro
ABAP, we need to do “Component Usage“.

[adToAppearHere]

Another new term in Web Dynpro.. .. The Web Dynpro framework

provides us with a technique called ‘Component Usage’, with the help of
which we can reuse the events, methods and context of one WD component
into another WD component. In simple words, Component Usage means
reuse of already developed existing Web Dynpro Components (standard
and/or custom). Just like, we use standard “REUSE_ALV_GRID_DISPLAY”
function module to display our ALV in normal ABAP, similarly we can use
standard Web Dynpro Component “SALV_WD_TABLE“. Just like
“REUSE_ALV_GRID_DISPLAY” has table “T_OUTTAB” where we can assign
ANY type of internal table, similarly in WD “SALV_WD_TABLE” has a context
node called “DATA” where we can bind context of ANY type.

We need to use:
a) Interface View ‘TABLE’ of component SALV_WD_TABLE
b) Interface node ‘DATA’ of component SALV_WD_TABLE.

The other very oftenly used standard components are WDR_OVS (for Object
Value Selector OVS) and WDR_SELECT_OPTIONS (for select options).

Let us use the same example we did in Part III. This time we are declaring
global contexts in ComponentController (not necessary, just for
demonstration).
Drag these nodes in the main View and now they are available in the view
(just like we pass variables as parameters in the Subroutine/Performs to
make those variable available in the subroutines).

Hope, by now you know how to create button and link it to an actions
(screen shot below in case you forgot).
For displaying the ALV output, we can use View Container UI Element
(figure above). The View Container UI Element need NOT be bound to any
context here. We will show later how it is bound.
Hope you have bound all other screen elements.

On Execute button, we need to carry out three steps.

1. Read data entered in the screen (fig below).

2. Use the data entered in screen to extract data from database (in this
example VBAK).
3. Bind the extracted data to the output result context node (it would display
the final output) (fig below).
* Code Snippet

METHOD onactionexecute .

* Read data entered in screen

DATA lo_nd_cn_sel_screen TYPE REF TO if_wd_context_node.
DATA lo_el_cn_sel_screen TYPE REF TO if_wd_context_element.
DATA ls_cn_sel_screen TYPE wd_this->element_cn_sel_screen.
DATA lo_nd_cn_result TYPE REF TO if_wd_context_node.
DATA lt_cn_result TYPE wd_this->elements_cn_result.

lo_nd_cn_sel_screen = wd_context->get_child_node( name = wd_this-

>wdctx_cn_sel_screen ).
* get element via lead selection
lo_el_cn_sel_screen = lo_nd_cn_sel_screen->get_element( ).
* 1. Read data entered in the screen.
lo_el_cn_sel_screen->get_static_attributes(
IMPORTING
static_attributes = ls_cn_sel_screen ).

* 2. Use the data entered in screen to extract data from database

* Select from VBAK with the input screen fields
SELECT
vbeln ” Sales Document
erdat ” Date on Which Record Was Created
ernam ” Name of Person who Created the Object
auart ” Sales Document Type
FROM vbak
INTO TABLE lt_cn_result
WHERE ernam = ls_cn_sel_screen-userid
AND erdat GE ls_cn_sel_screen-from_date
AND erdat LE ls_cn_sel_screen-to_date.
IF lt_cn_result[] IS NOT INITIAL.
* Keep the extracted data in a context node (table) bound to ALV
lo_nd_cn_result = wd_context->get_child_node( name = wd_this-
>wdctx_cn_result ).

* 3. Bind the extracted data to the output result context node

lo_nd_cn_result->bind_table( new_items = lt_cn_result set_initial_elements
= abap_true ).
ENDIF.

ENDMETHOD.
The View Container UI Element is still not bound to any context. So the final
step is to link a context to the final output. For this we would leverage the
already existing standard WD Component, SALV_WD_TABLE.

Create a component usage. In this example the name is CU_DETAIL of

WD Component SALV_WD_TABLE. Naming convention CU_ for Component
Usage. Please note in the left side panel new Component Usages attributes
(CU_DETAIL) get created. Save/Activate the changes done till now.

Go to the Window W_MAIN. On the right side, right click on the W_MAIN
window and select EMBED View. Choose the view V_MAIN. View V_MAIN
along with the View Container UI element is embedded in the Window. Now
right click on the View Container VC_RESULT and chose EMBED View select
Component Usage View TABLE. Your window is linked to standard component
SALV_WD_TABLE’s TABLE view.
Now we need to bind the output data to the context of the SALV_WD_TABLE.
The context we would be binding to is “DATA”. Click on the
INTERFACECONTROLLER of the Component Usage CU_DETAIL. Check the
icon under “DATA” in context has single arrow underlined. Now we need to
let the SALV_WD_TABLE know, what data would be bound to the “DATA”
context. In our example, CN_RESULT context has the final data, so, we drag
CN_RESULT from right to the “DATA” context on the left.
Check, the arrow is two way now and also you should get the message
“External mapping for context element “DATA” was defined”.

Save and Activate your component. You are done.

Let us test out baby.

This is one of the simplest way to show ALV. In real project scenarios, you
rarely use one ALV output. In the next parts, we would explore multiple ALVs
and also different features of the ALV list; like onclick of a row/field, make
the ALV display/input only, activate/deactive standard features of ALV, put
custom buttons programatically etc.

Let’s Web Dynpro. Part VI

In Part V, we learnt how we can display the tabular output in ALV with
Component Usage. In this post we would see how to add custom buttons
programmatically to the ALV output tool bar/header.

[adToAppearHere]

It is a very common requirement as shown below (please note these buttons

are not standard UI elements).

In the above figure: SELECTALL, DESELECTALL and RETRIEVEINFO are

buttons which we have added at run time, programatically. They are not
standard UI buttons.

How to achieve this functionality?

Once you have determined the data for the output, you bind it to the context
node and call the method to SET the ALV Properties (for our example the
method is “ALV_SET_AVAIL_PLANT”. This is the place where you define the
button name and function code.

Let us check the important lines related to the custom buttons in this
method.

Create object, provide the image source (optional), Set the text of the button
(optional), provide the function code and add/set the button.

Please click the link for complete code snippet for the
ALV_SET_AVAIL_PLANT. You can use this as your template for all ALV
properties. Just change the field names of your table and you may or may
not need the button parts (shown in the above figure).

Give special emphasis to the function code. Make sure of the case of the
alphabets. You need to give the exact function code to the Event Handler
method as stated below.
Once the ALV Property is set, we need to declare another Event Handler
method to capture the clicks on the ALV; for our example it is
SELECT_DESELECT method.

In this method we need to identify the function code and call corresponding
method for action/activity you want to perform. Please see the function code
in the event handler method and the ALV property method. They are exactly
the same.

Say for action ‘DESELECTALL’ we want to call method deselectall( ) to

deselect all the check boxes. Similarly ‘RETRIEVEINFO’ action would fetch
you the plant details.
Please note, the method name can be different than the BUTTON or
FUNCTION code name. In our example we have the same name for all three
for simplicity.

Hope, with the above information, you would be able to add as many buttons
you want and make your ALV more interactive. Please let us know, if we
need to provide more information on this topic. We would be happy to add
them in this post.

Let’s Web Dynpro. Part VII

In this post I would like to show a very simple stuff, Personalization and
Customization in Web Dynpro, which has quite a big impact on the users.
Yesterday, someone happened to unwittingly hid an input UI element in
one of our Web Dynpro Application. And the first email I received in the
morning was like below (nothing confidential).

Look at the actual email I got from our Supply Chain.

——————————————————————
Hey Guys,

What happen to the PARTS Search???

There is no MFR. Part number field under the Manufacturer Search.

Have folks telling me that the field was there yesterday because they were
using the link yesterday. When they went in this morning it was gone.

I’m starting to get numerous call about this now

[adToAppearHere]

——————————————————————

I went to the user’s desk who complained about the issue. I knew exactly
what had happened and the solution was simple. I right clicked at this screen
and restored the hidden UI element as shown below.

Right Click –> User Setting –> Invisible Elements –> Restore Input
Field
That user was happy with the quick fix. But, it was not the complete solution
my friend!! Later in the day, I got another email (below) saying some other
user complained again.
——————————————————————
It appears IT has not fixed the parts search page. The Manufacturer part
number field is missing again

Can u guys check this again??

——————————————————————

This time, I did not go to anyone’s desk. I decided to fix it globally for all

users (once and for all). Let’s hit the last nail in the coffin.

Right Click –> User Setting –> More –> Reset User Settings for
Running Application
This time all changes done would be reset to original.. Happy Users!!

Let’s Web Dynpro. Part ZZ

The topic we would like to discuss today is definitely not Part III. Therefore
we have named it ZZ. We would have taken this later in our Web Dynpro
series, but on one day, two of our friends needed the same requirement.
And, we did not find much documentation in this internet world. Therefore

we decided to post this page before its due date..

Requirement: Export an EXCEL file with data in cell formatted excel

sheet with colors, borders, filters in Web Dynpro.

This is a very common requirement in Web Dynpro Reports. But, strangely,

not much is there in any forum.

There might be number of ways to achieve it, but the easiest way we figured
out is elaborated in this post.

Step 1. Create your Web Dynpro component and application, extract all your
data and prepare a final table(s) which you want to download in excel.

Step 2. For the ease of demonstration, we have created a simple WD

application with just one button (LinkToAction) UI element in main view. In
the action ‘DOWNLOAD’ we have added a small logic to fetch few columns
from MARA. Final table (i_mara) to be displayed in excel is ready.
Step 3. Create one Transformation program in SE80 or t-code XSLT_TOOL.
Simple Transformation is needed. When you save the Transformation
program, xml code would be generated.
Step 4. Replace the generated xml code with the code in the template xml
attached below. We have created this template for the ease of we
developers. Places are highlighted in the template where you need to
add/change your formats.
Link for xml template: Please look for SAPYard Tip in the template to find
the hints.

Word Doc: SAPYard Transformation Program Template

Text File: SAPYard Transformation Template

PS: This template can be used for any excel download/formatting. It should
be changed / enhanced for extra features. But this template can be used as
starting point.

Step 5. Prepare a sample excel page you want as output from Web
Dynpro, with all formatting, coloring, borders etc. Make sure you have all the
formatting done.
Step 6. Save that excel as .XML. Open that saved XML in notepad/wordpad.
You will see XML codes. Scan through the code to get the STYLES. Different
Styles will have different format for different rows, cells or columns.
Step 7. Go back to Transformation program XML which is the copy of the
XML template attached. Now copy all your STYLES from excel XML to
program XML.
Step 8. At the top of Transformation program, define the tables and variables
/ workareas which would be imported. TABLE is your internal table which
would be sent from Web Dynpro. Make sure to add your TABLE and
variables. And remove unwanted.

Step 9. Now, we need to differentiate between hard coding and

dynamic value.
For example: ‘Reported By’ is hard coding. This would be same every time
excel is downloaded. But the value of Reported By would be different
depending on who executed it. In this case Reported by value is in V_NAME
variable.
So, make a note of hard coding and values and replace the values with your
variable name.

Step 10. Similarly check the Header line of the table ( hard coding). For
example Material#, Created By, Material Type, Material Group. This would be
hard coded. The styles for this may or may not be same to that of the body
of table. We need to check the excel XML to figure out the style and copy the
same style to our Transformation Program.
Step 11. The TABLE body is to be populated in LOOP. The values would be
assigned from the field name (always UPPER CASE). The sequence in which
you call the fields, the structure of the Table is created in that way. See the
figure for the fields called and the structure created.
Make sure, your TABLE in transformation program and your Web Dynpro
internal table are same.

PS: LOOP has to be closed with </tt:loop>

Please check the link below for excel XML code and the final Transformation
program code after making change to the Template. Scan through it to see
how we enhanced the template.

Raw Excel XML code Final Transformation XML code

Step 12. Call the Transformation program in your WD method. It would

import the xml in STRING variable. Convert it to XSTRING. Call
WDR_TASK=>CLIENT_WINDOW->CLIENT-
>ATTACH_FILE_TO_RESPONSE as shown in figure (code in link below).

Link for the code snippets related to Transformation call: Sample code in
Method

Step 13. Lets test our development. Check, the color, border, text format
bold etc are there.
Hope we were able to guide you through. If you still have any
queries/suggestions / doubts, please leave your comment or contact us, we
would be happy to respond.

Is data element WDY_BOOLEAN

and Flag (Char1) same for Web
Dynpro ALV?
Both wdy_boolean and flag are data element of type char1. Does it mean
both are same?

Straight talk today. Let me show you two outputs of the same Web Dynpro
ALV which has three fields; to put my point. Three columns in an ALV
are: Plant, Plant Name and a one character Flag say ‘Set‘.

a) Let us first define the data element as Flag for the one character field
‘Set’ in the context definition. Look at the output ALV.

b) Now, let us define the data element as WDY_BOOLEAN for the same one
character field ‘Set’. Mark the output ALV again.
Do you see the difference?
The second output shows that the “Set” field is displayed as checkbox.

Did it light something?

So, whenever you need a checkbox in an interactive ALV, just set the field as
WDY_BOOLEAN and you are all set to get a checkbox as an output. Isn’t it
cool?

Taking one step back after EhP7.4,

does it make sense for Web Dynpro
UI?
Does your Web Dynpro UI Screen look different after EhP7.4
Upgrade?

Recently we had our upgrade to EhP740 and with it came the new look and
feel. NEW Operators, VALUE Operators, BOXes, beautiful Google like
suggestions while typing the words etc are really impressive. Even the UI
screens have soothing appearence with advanced features (SAP is really
getting ready for mobile devices, clouds). But our Business users who are so
used to the old UI screens were not so fascinated with the new UI features.

Someone rightly said, old habits die hard..

They demanded the same old look and all buttons. I wonder, did we really

upgrade or are we taking a step back after upgrade?

[adToAppearHere]

So, what all are missing in the UI screen after upgrade?

The most prominent absentee as per our users are:

i) The column separator vertical line seems to have disappeared.
ii) The custom button looked different and emphasis and color was a No No.
iii) The filter button is no longer visible.

You might be wondering, has SAP really removed the filter button. Answer is
‘No’. SAP has moved a step ahead. It has filter and sort functionality at
column level (as in Excel) which I believe is very useful. But, who can

convince our users..

One picture speaks more(better) than thousand words.

Look how one of our UI screen looked before Upgrade.

Now check the same screen after Upgrade.
Did you notice, the vertical line separators of columns and filter button are
missing. As, I mentioned above, filters and sorts are at column level. You can
click on any column and achieve the filter and sort functionality. Also have a
look at the custom buttons..

Personlly, I like the new feel. Is going back one step to old look, justifiable, is

a topic for discussion for some other time..

After little research one of our team member figured out that with Ehp7, we
can add some parameters in the Web Dynpro application to get what
our users wanted.

Let’s add the following parameter.

WDTHEMEROOT sap_standard STRING Stylesheet URI
Look how the screen looks now. The screen is close to the before upgrade
look. Still the vertical separator and filters are missing.

Add one more parameter.

WDUIGUIDELINE GL11 WDR_APP_PROP_UIGUIDELINE UI Guideline
Now we are completely one step back. Everything we had before upgrade is

availble here.. Happy Business Users..

What does GL11 mean?

F4 on the parameter value field reveals there are two versions of UI
Guideline. GL11 is 1.1 version and by default in EhP7 the UI version is 2.0
(GL20).
Setting GL11 is like going one step back. Do you agree?

Can we avoid Table Type

declaration for Attributes section in
Web Dynpro?
Do you create Table Types Data Dictionary object just to declare the internal
table variables in Web Dynpro Attributes section?

Most of our young guns do not hesitate to create as many table types as
needed without pondering if we have an alternative way to achieve the same

result without crowding the data dictionary repository.

One of the most commonly done activity is to declare a table type which is
used only once in the Attribute declaration. Say, you already have a data
dictionary structure but you want to define an internal table. You can use the
same structure. Just add TABLE OF or STANDARD TABLE OF <structure
name>. You will get a warning message “The type TABLE OF <structure>
doe not exist” or “The type STANDARD TABLE OF <structure> doe not exist”.
Just hit return/enter key one more time and you are good.
In the above screenshot ZEMAIL_ATT_TAB is a table type and ZEMAIL_ATT is
a structure. We could have avoided the ZEMAIL_ATT_TAB table type
declaration in SE11.