Anda di halaman 1dari 23

Getting Started Newsletters Store

Products Services & Support About SCN Downloads

Industries Training & Education Partnership Developer Center
Lines of Business University Alliances Events & Webinars Innovation
Login Regi ster Welcome, Guest Search the Community
Activity Communications Actions
Web Dynpro ABAP 116 Posts
1 2 3 4 5 6 8
Previous Next
While trying to use appropriate icons with buttons and fields, If you are looking for how to find out all
available icons, pictograms and graphics for use in your WebDynpro Application.

Check out the test application WDR_TEST_WEB_ICONS to see various available graphics / icons and
there path ( ~Icon/* ) to be used in your code.

Simply run the webdynpro application under the Webdynpro component WDR_TEST_WEB_ICONS to see the
list of all the icons, web icons & workset images and pictograms or Or just navigate to the URL :

This will execute a ready-to-run demo applications on how to use graphics element in your WebDynpro
Using Graphics in WebDynpro
Posted by Tarun Telang Jun 11, 2013
List of Work centers graphics.

This demo application is contained within package SWDP_DEMO which is delivered in your system. It contains
many other sample codes for demo or testing on different topics you may encounter while developing Web Dynpro for
ABAP components and applications.
609 Views 1 Comments
Tags: web_dynpro, web_dynpro_abap, webdynpro_abap, webdynproabap, webdynpro_f or_abap, abap_wd
Webdynpro Framework allow us to create our own webdynpro component and use that component to provide and
input help to the field. This type of providing search help is called freely programmed search help.

How to use the component as a search help component to an attribute?

One pre-requisite for the webdynpro component to be used as search help is that it should implement the webdynpro
component interface IWD_VALUE_HELP. By the time we are implementing the interface an window will be created in
our component with the name WD_VALUE_HELP. We need to embed the View of our component to window
WD_VALUE_HELP so that our view will be displayed as search help when the user triggers the F4. Later on this
Freely programmed search help
Posted by Arun Krishnamoorthy Jun 7, 2013
component created for providing search help can be added as a used component and its component usage can be
assigned to the attribute for which search help type is assigned as freely programmed search help.

Where to write the processing logic to display the list of possible values?

The view which is embedded to the window WD_VALUE_HELP will be displayed when the user triggers the F4 help.
Hence we can design the layout and the processing logic to display the data based on input can be implemented in
the view itself.

The list of possible values will be displayed in the view that is embedded to the window WD_VALUE_HELP. How
to transport the user selected value back to the place from where F4 help is called?

When the User selects a particular value and clicks on ok button the user selected value has to be written in the input
field from where the F4 help is called. The interface IWD_VALUE_HELP consist of two key attributes called
F4_CONTEXT_ELEMENT and F4_ATTRIBUTE_INFO. This attribute F4_ATTRIBUTE_INFO consist of information on
attribute from where the F4 help is triggered and the attribute F4_CONTEXT_ELEMENT consist element object
reference for the attribute from where the input help is triggered. Using these information in the attribute we can
transport the user selected value to the attribute from where the F4 help is called.

Will the values selected to an attribute using the freely programmed search help be captured in the Context
change log?

No, Just like in OVS Search help we need to write the record explicitly to the context change log table.

Refer to the SAP Link for More information on freely programmed search help:

Let us see an simple scenario that implements the freely programmed search help.

Scenario: Provide the freely programmed search help to the attribute CARRID. Design a webdynpro component that
provides the list of possible airline ID and use that component to provide search help for the attribute CARRID.

This tutorial is split into two parts.

1. Creating a freely programmed search help component
2. Using the component to provide the search help
415 Views 0 Comments Tags: web_dynpro
Generally when we work on F4 search help for web dynpro, we end up either with an OVS or a freely programmed
input help, for various reasons. The reasons being, setting of the initial search parameters, customization, a more
refined hit list or mapping of the result into multiple fields. These scenarios are easily achievable by OVS through the
different phases namely 0,1,2,3. But these requirements can be met by dictionary search help as well.
I personally prefer dictionary search help because of its flexibility and reusability factor.

In this blog I will describe the various steps to be followed in order to achieve an OVS like functionality through
dictionary search help.
I am not explaining everything from scratch but just giving the steps to achieve the required functionality.

For this you need to create a dictionary search help exit. You can refer to the following wiki doc in case you need
some info on search help exit.

1. The configuration ( Similar to OVS phase 0)
In case you want to change the title of the search help screen or the heading of the various search parameters you
can make the corresponding change in the changing parameter SHLP, it contains all the customization related to the
search help. A code snippet :

* Change Search help title.
shlp-intdescr-title = Supplier Name.

* Change Heading for Country.
READ TABLE shlp-fielddescr
ASSIGNING <fs_fielddescr>
WITH KEY fieldname = 'LANDX'.
IF sy-subrc = 0.
<fs_fielddescr>-reptext = Country.
<fs_fielddescr>-scrtext_s = Country.
<fs_fielddescr>-scrtext_m = Country.
<fs_fielddescr>-scrtext_l = Country.
Dictionary search help and Web dynpro
Posted by Swati Agarwal Jun 3, 2013

Here, I have changed the search help title and the heading of one of the parameter.

2. Initialization of search parameters ( Similar to OVS phase 1)
For this, you need to modify again the changing parameter SHLP-SELOPT.
It contains the search help parameters as select options.

In order to get the web dynpro values to be set as default values, you can use the class attribute

It contains the current web dynpro element from which the F4 has been called. And you need to do this piece of code
in the call control step 'PRESEL1'

* Get the context element from which the F4 has been called.
lo_el_supp_table = cl_wdr_value_help_handler=>m_context_element.

* get all declared attributes
static_attributes = ls_supp_table ).

IF ls_supp_table-supplier IS NOT INITIAL.
READ TABLE shlp-selopt
WITH KEY shlpfield = 'NAME1'.

IF sy-subrc <> 0.
* Add selection criteria in case not added earlier.
ls_sel_criteria-sign = 'I'.
TRANSLATE ls_supp_table-supplier TO UPPER CASE.
ls_sel_criteria-low = ls_supp_table-supplier.
ls_sel_criteria-shlpfield = 'NAME1'.

IF ls_supp_table-supplier CA '*'.
ls_sel_criteria-option = 'CP'.
ls_sel_criteria-option = 'EQ'.

APPEND ls_sel_criteria TO shlp-selopt.
CLEAR ls_sel_criteria.


3. Result set ( Similar to OVS phase 2)
You can get the result set on the basis of your search parameters, which you can assign to the changing parameter
You will write you code in the call control step 'SELECT'

4. Mapping of the result ( Similar to OVS phase 3)
Usually in Web dynpro, we use structures for node creation, you can map your search help exporting parameters to
the fields of the structure like the following in SE11. Due to this, as soon as the user makes the selection using
search help, the other mapped fields will get populated automatically.
Here, I have assigned a search help for the field Supplier, and mapped Supplier ID as well to the export parameters
of the search help.

Final Outcome :
Search help showing the customization and the initial search parameter value.
1116 Views 1 Comments Tags: web_dynpro, webdynpro, search_help, search_help_exit, abap_web_dynpro
During the course of a recent project for a customer, a fairly complex Web Dynpro for ABAP application was
developed. The WDA was a single screen application, with several popup screens, each implemented as a separate
WDA. The WDA displays the operations of an existing work order and lists a set of activities per work order operation.
For each activity, the user can create a number of different types of notifications. It was estimated that the application
would have about 1800 concurrent users when released to production. This raised some concerns about possible
performance issues with respect to the application in particular and the SAP Internet Communication Framework in
general. The customer had little previous experience with these types of custom Web Dynpro applications, and there
had been some experience with applications on other technologies failing under heavy load at go-live. When the
customer asked whether the application might break under load, it was not really possible for the project members to
deny this possibility with 100% certainty. Based on our experience with Web Dynpro and ICF we were fairy confident
that the application and infrastructure would hold, but to better support our gut feeling with facts, we decided to
undertake a load test of the application.

Performance testing versus load testing
The terms performance testing and load testing are often used interchangeably and the difference between the two is
not well defined. In this article, the following definition is suggested:

Web load testing is:

similar to, but not synonymous with performance testing
concerned with the volume of traffic your website (or application) can handle
not intended to break the system
viewing the system from the user perspective
associated with black box testing
Load testing of Web Dynpro applications using
Apache JMeter
Posted by Frank Stdle May 28, 2013

Web performance testing is:

a super-set of load testing
concerned with speed and efficiency of various components of the web application
useful with only one user and/or one transaction
viewing the system from the architecture perspective (behind the server side curtain)

In our case, our primary concern was ensuring that the application would not break under heavy load, that is, become
totally unresponsive. Within reasonable limits, we were less concerned with the user experienced performance of the
application. Thus, load testing was our primary objective, but our findings would also be useful for performance

A note on performance testing
When testing the performance of an application under heavy load, three components are actually being tested:

The application
The application framework - in our case, the SAP web dynpro framework and the SAP Internet Communication
Framework (ICF)
The network infrastructure

Of these three components, we have little influence over the framework and the network. Improving performance
would mainly be accomplished through fine tuning of the application. Possibly, some measures might have been
taken to improve network and framework performance as well, but this never turned out to be necessary.

Choosing a tool for the job
There are many tools available for load testing of web applications, both commercial and free. Several of the available
tools were considered for our task. The following is a list of other tools that were considered and/or tried:

Microsoft Visual Studio Ultimate - comprehensive, very expensive. No support for cookies without programming.
HP Load runner - expensive - has been used previously by customer, but was discouraged based on high cost
Selenium - not really a load testing tool, aimed at functional testing
Winshuttle - a data loading tool for SAP, but does not support Web Dynpro
Apache JMeter - open source, free, Java based, very configurable

JMeter was recommended to us at an early stage based on previous experience at customer site, and it soon
became apparent that JMeter was the best option in terms of functionality, even without considering price. Our main
requirement was being able to simulate the load of many simultaneous users, and JMeter met this requirement, at
no cost.

Getting JMeter
Apache JMeter is a free and open source tool for performance testing of web applications. It is available here

Other useful tools
In addition to JMeter some other tools are also necessary or useful for developing performance tests with JMeter. You
will need:

A text editor with support for regex searches - recommendation: Sublime Text
A tool for inspecting HTTP traffic - recommendation Fiddler
A modern browser - recommendation: Chrome

How JMeter works
JMeter differs from many other testing tools in that JMeter only works at the HTTP level, and not on the presentation
level where HTML pages are actually rendered. JMeter is not a browser. JMeter will act as a browser against the web
application server (such as the SAP ICF which serves web dynpro applications) in the sense that JMeter sends HTTP
requests and receives web pages in the form of HTTP responses from the server hosting the web application. JMeter
differs from a browser in the sense that JMeter does not execute the Javascript code in the received HTML pages and
JMeter also does not render the HTML of the web pages to screen.

When running JMeter, typically many "threads" are executed in parallel - each thread represents one user session.
Thus JMeter can simulate many users simultaneously accessing a web application. Spinning of thousands of
threads on the workstation JMeter is running on would possibly cause the workstation to run out of memory, therefore
JMeter also supports running test scenarios distributed across several workstations. In our testing, we ran JMeter
with 400 threads each on 2 workstations to simulate the load of 800 concurrent users.

How Web Dynpro applications work
A Web Dynpro application is a web application hosted on the SAP server. When the browser accesses the URL of a
web dynpro application, Javascript, HTML, CSS and resources such as images are downloaded to the browser and
rendered on screen. When the user interacts with the application by for instance clicking a button the following

1. A HTTP POST request is sent to the SAP server with information on what type of user action that occurred (what
type of action was performed on wich UI element)
2. The Web Dynpro framework communicates the user action to our Web Dynpro application code
3. Our Web Dynpro code typically enters a new state based on the user action (for instance, a radio button is set)
4. The Web Dynpro framework sends a HTTP response to the browser containing the new view in its updated
state, and the new application state is rendered on screen

It is important to note that with Web Dynpro applications, every user action results in a new HTTP POST request being
sent to the server which will than send an HTTP response with an updated application state to the browser. Many
modern web applications will react to user actions via Javascript code on the client (browser) and update the screen
without doing a round trip to the server. With Web Dynpro applications every user action results in a round trip to the
server and a redraw of the entire screen (disregarding any optimizing on the browser). This behavior is a good fit for
JMeter since JMeter only works on the HTTP layer, inspecting HTTP requests. JMeter is not able to execute or react to
Javascript code being executed on the client.

Setting up a test scenario
Start JMeter, and create a new "Thread group" by right clicking on "Test plan". A thread group is a collection of HTTP
request that are passed to the web server hosting the web application under test. After we have added a series of
request to the thread group, we can run the thread group with a large number of threads (users) to simulate multiple
users accessing an application simultaneously. For a thread group we can also add post- and preprocessors that
manipulate each request, monitoring and statistics, logical controllers and so on.

Recording as user session
JMeter can record HTTP traffic and store all the requests that are passed to the web server. The requests are stored
in a thread group and can then be replayed from JMeter to simulate a user accessing the web server. To be able to
record a user session JMeter must act as a proxy server - if a browser is used to create HTTP traffic, which is the
most common case, the browser must be configured to use JMeter as a proxy. Traffic from the browser is then routed
to JMeter, and JMeter passes the traffic along to the web server, receives traffic from the web server and passes it
back to the browser. By acting as an intermediary, JMeter can record all the traffic.

Setup a recording
1. Right click on the thread group and select "Add - Logic controller - Recording Controller". Our recording will be
stored in the new node "Recording controller"
2. Right click on "WorkBench", select "Add - Non-test elements - HTTP Proxy server"
3. Right click on the "HTTP Proxy Server" node and select "Add - Listener - View Results Tree". The listener will
store every information and response, and we need this information later on
4. Click on the resulting proxy server node and make a note of the Port number (typically "8080"). Also make sure to
choose "Use recording controller" as the value for "Target Controller"
5. In the settings for your browser, set JMeter as proxy by entering the values for the server address "" and
port "8080"

Your setup should look like this:

Start the recording by clicking "Start" on the HTTP Proxy screen. Traffic from your browser will now pass through
JMeter and be recorded. Recorded traffic will be stored in the "Recording controller" node. The result of recording a
brief web dynpro session will look like this:

As can be seen from the screen shot, most of the HTTP traffic comes from the browser downloading resources such
as images, CSS and Javascript. When we initially access the application, and whenever we access a new screen,
lots of these resources will be downloaded by the browser. The initial downloading of resources will contribute to the
load on the system, but as the resources are cached by the browser (and pn the server) they will have less impact on
the totel load. In my experience, the contribution of these resources on the overall load was negligible, so for the sake
of simplicity we can filter those files from being recorded by JMeter. We do this by adding a regular expression to
"URL Patterns to exclude" for each file we want to ignore:

Recording again, we now collect fewer and more interesting requests. We are only interested in the requests that are
highlighted - the requests that contain the Web Dynpro application name - the other request can be deleted:

Running the scenario
After having successfully recorded a user session with the WDA, you can run the test plan by clicking the green play
icon ("Run"). When the test plan is run JMeter will fire the HTTP requests in the recording controller to the server and
receive the HTTP responses. For a simple web application with no authentication this would work fine, but with a SAP
server it won't. The SAP server expects a user session to be authenticated and all HTTP requests to have two unique
IDs which identify this particular user session. The authentication scheme in your SAP landscape may differ, but for
our SAP system the following process is involved:

1. When a user first accesses the corporate intranet, a SAP single sign on cookie called MYSAOSSO2 is issued for
the same domain as the SAP WDAs are hosted ( This cookie is valid for one day
2. When a client (browser) accesses the URL of the WDA by sending a HTTP GET request, the MYSAOSSO2 cookie
is passed along by the browser
3. The SAP server responds to the GET request and sends two tokens in the HTTP response body, sap-
contextid and sap-wd-secure-id. The SAP server expects these tokens to be included in all subsequent
requests from the client to uniquely identify the user session

So for JMeter to successfully communicate with SAP the following is required:

A single sign on cookie must a included with all request
The query parameter sap-contextid must be passed with all request after the initial GET request
The parameter sap-wd-secure-id must be included in the body of each request after the initial GET request

Luckily, JMeter is capable of handling all this. The "HTTP Cookie Manager" will (unsurprisingly) handle cookies, and
we can use "Regular Expression Extractors" to extract the sap-contextid and sap-wd-secure-id tokens from the
first request, store them in variables and add them to subsequent request.

Working with the recording
Our new, cleaned up recording looks like this:

Adding Regular expression extractors
Note that the two first requests are HTTP GET requests that initially access the application on the server. The
subsequent requests are HTTP POST request, one for each user command. In the first of the GET request (the
second GET request can be deleted from JMeter as it is not needed for running the test scenario), two tokens are
passed to the client in the HTTP response. These tokens are used in all subsequent communication between the
client and the server to authenticate the user session. We can find the values of these tokens by inspecting the
request in the "View Results Tree":

The sap-contextid token is appended to every request as a query parameter (at the end of the URL) while the sap-
wd-secure-id token is passed in the body of the request. The value of these tokens will differ with every user
session, so to be able to playback our recording more than once we must dynamically extract the value of the tokens
and append them to our requests. JMeter makes it possible to extract data from HTTP responses using the "Regular
expression extractor".

Add the extractor by right clicking on the first request in the recording controller and selecting "Add - Post processors -
Regular expression extractor". We need to add one extractor for each parameter. We also will add a HTTP Cookie
Manager and a HTTP Header Manager - the purpose of which is explained below - giving us the following

The regular expression extractor is a post processing controller - it is triggered after a HTTP response has been
received by JMeter. The extractor will extract a value from the response that matches the regular expression and store
the value in a JMeter variable. The variable can then be used in subsequent requests and controllers. We must define
the following parameter for the extractor:

Reference name - name of the variable in which to store the retrieved value
Regular expression - the regular expression
Template - the number of the regular expression group to be stored in the variable
Match no. - if there are more than one match, the number of the match to store in the variable

In our case we will store the contextid and secure-id into two variables and add them as parameters to all
requests. For the secure-id extractor we will enter the following values:

Reference name - sap-wd-secure-id
Regular expression - name="sap-wd-secure-id" value="(.+?)"
Template - $1$
Match no. - 1

For the contextid extractor we will enter the following values:

Reference name - sap-contextid
Regular expression - (SID.+?NEW)
Template - $1$
Match no. - 1

You may have to tweak the regular expression to extract the values correctly - regular expressions are a pain in the
neck, but there are some online tools that help you test your expressions. For sap-contextid, note that I selected
"Body (unescaped)" to get the correct, unescaped value for the context id. When testing your expressions in JMeter,
add a "View results tree" node to the top node, run the scenario, and inspect the requests and responses in the

HTTP Cookie manager
The cookie manager allows JMeter to send and receive cookies to and from the server in the same way a browser
does. Cookies are generally used for authentication of the client against the server, and depending on the
authorization scheme on your SAP server a cookie will be used to authenticate the user sessions together with the
secure-id and contextid tokens. In our system landscape, a SAP single sign on cookie is obtained when the
browser accesses the corporate intranet the first time. This SSO cookie is then used as authentication when
accessing any SAP server. JMeter is unable to obtain this cookie in the same manner as Internet Explorer is. But
since the cookie is valid for an entire day, we can access the intranet using Internet Explorer, and then we can find the
value of the cookie and copy it into the JMeter cookie manager manually. Use Fidller or "Developer tools" in IE to find
the cookie; press "F12", select "Cache - View cookie information". In our system the cookie is called "MYSAPSSO2":

In the cookie manager in JMeter I will create a "User-Defined" cookie, called "MYSAPSSO2", and copy the domain of
the cookie and the value of the cookie from Internet Explorer:

HTTP Header Manager
The "HTTP Header Manager" is used to add headers to all HTTP request that are sent from JMeter to the server. We
need to add a header called "User-Agent" with the value Mozilla/5.0 (compatible; MSIE 9.0; Windows NT
6.1; WOW64; Trident/5.0) to the initial request to the server to trick the SAP server into believing that it is
communicating with a browser, otherwise the SAP server will send a message that our browser (JMeter) is not

Modifying requests to include contextid and secure-id
Having successfully extracted the contextid and secure-id into variables, we now must modify all our requests to
pass these tokens. A typical request will look like this:

${sap-contextid} and ${sap-wd-secure-id} are references to the variables.

You can determine whether your requests are successfully authenticated by adding a "View results tree" listener to
the test plan node, running the test plan, and inspecting the results in the listener. Select a request in the listener,
select the "Response data" tab, and select HTML from the drop-down menu at the bottom left. This will make JMeter
display a crude rendering of your web dynpro application screen. If unsuccessful, you will see some some kind of
SAP error message instead, because your request was not authenticated.

Looking at the request in more detail
The initial HTTP GET request establishes a connection to the SAP server and receives the user session tokens. After
this point, every user action on the client will generate a HTTP POST requests with information on the user action, and
the server responds with an updated screen in the HTTP response. Information on the user action is contained in the

To be able to manipulate the state of the web dynpro application this parameter must be passed. There are 2 ways
this can be done:

1. Either record a user session using JMeter HTTP proxy and update each request with the variables for
contextid and secure-id afterwards, or
2. Interact with the web dynpro application while a tool such as Fiddler is running. In JMeter, simply add request
manually to the test plan, and use values found in Fiddler for the SAPEVENTQUEUE parameter

Below is a typical recording from in Fiddler:

I preferred method number 2 as it gave more control over the development of the test script in JMeter. In JMeter, I can
create a new request (or more often, copy an exiting one) and copy value of the parameter SAPEVENTQUEUE from
Fiddler and paste it into JMeter.

Stable IDs
Every UI element in the web dynpro view is assigned an ID when the page is rendered in the browser.

For example, the <td> element above contains a radio button element, and the ID of this element is "WD66". This ID is
sent in in the SAPEVENTQUEUE parameter in a request to the browser when a user operates on the element. In our
test script in JMeter this ID is stored as part of the request. However, it turns out that the ID of the UI element can
change between each run of the application. This means that the JMeter test script can fail because it uses an
incorrect ID for the UI element. Luckily, SAP has provided a solution to this problem. Setting the URL parameter sap-
wd-stableids=X will cause every UI element to be rendered with a stable and more meaningful ID, as shown below
for the same radio button element:

So make sure to set this parameter for every request to ensure that the test script will not break.

Running the script
Below is a screenshot of my script after I have tidied it up and given each request a sensible name that describes to
the user action in the application:

In the log on the right side is the result from running my script -- the log shows no errors. Note that the log would also
show no error even if JMeter was unable to authenticate against the SAP server, because in that case the SAP server
would return a HTTP response with status code 200 containing an error message. JMeter will only show status
codes different from 200 as errors. So to determine if the script ran successfully, either the responses must be
investigated in JMeter or the effects of running the script should be checked in SAP.

Simulating many users
Still we have only run the script in a single thread, simulating just one user. The whole point of using JMeter is to
simulate many users. This can be accomplished by selecting the thread group "Main", and setting the value of
"Number of threads (users)":

Here I have set the number of users to 10. A ramp-up time of 1 means that the threads will be active within 1 second.
It is also possible to run the script in a loop to average measurement results.

Measuring performance
JMeter provides several types of listeners for collecting performance measurement data. The most useful one is the
"Summary report" which collects key data such as average, minimum, maximum and median response time for
requests. These numbers correspond to the time the user has to wait for an operation in the application to complete
and become visible on screen. Below are three different measurements from running the script 200 times with one
user, for a total of 1400 requests:

Every type of listener will incur a penalty on the performance, so fewer and less detailed listeners are recommended.
Graphing performance metrics in real time in JMeter is fun, but it's more useful to use the summary report and export
the data to Excel afterwards to analyze and graph the numbers.

The main objective of our load test was to prove that the application would not break under heavy load after going live.
It is not really possible to positively prove this, because the famous "unknown unknowns" can contribute to bring the
application down somehow. Load testing with JMeter did however give us great confidence that our application would
not break, and we were able build confidence with the customer as well based on the numbers and measurements
from JMeter. We also gained confidence the SAP ICF framework - we never got close to bringing ICF to its knees (as
far as we know), and ICF appears to be very robust, which also bodes well for its new role as the underlying platform
for UI5 applications.

Load testing should not be mandatory for all new Web Dynpro applications - but for critical applications with a great
number of concurent users it makes sense. Load testing with JMeter will also reveal information on performance
issues in an application that would otherwise be hard to detect. Even if that was of secondary importance in our
project, through visualizing the measurement from JMeter we we learned a lot about where there was room for
improving the user perceived performance of our application.

1830 Views 8 Comments Tags: web_dynpro, load_testing, jmeter, perf ormance_testing
Do not put all your data into the context.
Do not create a mega context for all data belonging to one application.
Put only the data required for the UI element binding into the context.
Use the assistance class or other ABAP OO classes for the data exchange.
Without any requirement(use in Multiple Controller) dont create Context in Component controller level, If
required create local contexts, for example, in views
Do not create deep-nested contexts.
Use singleton nodes if nestings (master detail) are necessary
Do not use dynamic attributes (IF_WD_CONTEXT_NODE_INFO->ADD_ATTRIBUTE)
Use data with context structure for BIND_TABLE
Update the context only if the data actually has to be updated
Do not create long context mapping chains.
Use the Context Change Log functions to detect user input. This has particular performance benefits while
a user of the application modifies only a small amount of data in a view while displaying a large amount of
mixed data.
Dos and Donts: Webdynpro Context.
Posted by Manigandan D May 21, 2013

Please feel free to add more points in this blog,

408 Views 2 Comments
Tags: web_dynpro, webdynpro, dynpro, web_dynpro_abap, webdynpro_abap, webdynproabap, webdynpro_f or_abap,
v Do not write your entire application source code in Web Dynpro components.
v Write your application source code in ABAP OO classes. For example, use the assistance class.
v As a rule, every ABAP class can serve as an assistance class. However, the services integrated in the
Web Dynpro framework are available only if the assistance class is derived from the class
CL_WD_COMPONENT_ASSISTANCE. Note that the assistance class must not have any required
parameters in the constructor.
v SAP no longer recommends creating special model components, since they do not offer any benefits over
model classes. One alternative is to use a shared assistance class to provide a model.
v Do not create single view in Web Dynpro component try to split it into many, so it can be reused.
v Always prevent different development groups from working on the same component.
v In a Web Dynpro component, group together as many views that belong to one application part as
possible. If, however, the ABAP workload is too large, split the component up.
v Whenever possible, restrict your components to a maximum of 15 views.
v Make sure that the number of controllers used by each controller does not exceed 8. Remember, at
runtime you create a load from your components. The size of this load depends to a great extent on the
number of views, UI elements, controllers, controller usages, and the size of the context nodes. If this
load is too big, the system produces a warning telling you that limited resources are available at runtime
for the WDA application. Performance drops.
v Generic components are more difficult to maintain than explicitly programmed components, which is why
we recommend that you make all your components only as generic as they absolutely need to be. This
requirement needs to be balanced with the demands of distributed application development groups. These
groups need to provide generic components that are then, for example, given a uniform layout at a later
time or by a different group. As a guideline, we recommend that you make your applications generic to
the extent that, when the resulting component is configured, around 80% of all applications are covered.
Do not try to make your component more generic just to cover the remaining 20% of the possibilities.
v Delete all Web Dynpro component instances as soon as they are no longer needed. To do that, use
v Use dynamic navigation or dynamic component usages only if it is absolutely necessary.
v Set the lifetime of a view to when visible, if the view is displayed only once in an application.
v As far as possible always set the lifetime to when visible. Note: Although memory consumption is
reduced by the lifespan of when visible, when visible can affect performance since in this case the view
has to be initialized every time it is displayed.

510 Views 2 Comments
Tags: beginner, web_dynpro, web_dynpro_abap, webdynpro_abap, webdynpro_f or_abap, abap_wd
Dos and Donts: Webdynpro Components.
Posted by Manigandan D May 20, 2013
Hi everybody,

There are four different ways to store text in a Web Dynpro and FPM application.
1. Data element
2. OTR (Online Text Repository)
3. Text elements of a class
4. In the configuration
Wich way should we prefer to store text in Web
Dynpro and FPM #WDA #FPM #Localization
Posted by Robin Vleeschhouwer May 17, 2013

You can read all about how to translate these texts in the following blog: ** TEAM FPM ** - All about Translation and
Texts of FPM applications

But what about the choice of which way we should use to store the text.
In this blog I will describe my preferred choice in different scenario's. This is not a guideline from SAP, but it is my
preferred way based on practical experience.

First of all you should always prefer to use a data element with the correct text.
Unfortunately this is not always possible.
There are four scenario's which I will describe below based on the difference that the text is static or dynamic and if
you use the text for a Web Dynpro (freestyle) or for FPM.

Scenario 1: The text is static and is bound to an UI element in Web Dynpro
Preferred choice: You should store the text in the OTR (Online Text Repository)
Why: You can easily translate the text with function module: SOTR_API_WB_TRANSLATE

Scenario 2: The text is static, but not bound to an UI element in Web Dynpro
Preferred choice: You should store the text in the text element of a class
Why: If a text in the OTR is not bound to an UI element, then you can't easily translate it. For example you won't see the
text in function module: SOTR_API_WB_TRANSLATE

Scenario 3: The text is static and used for FPM. This includes the FPM application (OIF, OVP, GAF) and also the
Preferred choice: You should store the text in the configuration.
Why: If you would use the OTR, then you don't see the text in administration or configuration mode, but you see the link
to the OTR. That is not very user friendly.

Tip for FPM feeder class. In the method GET_DEFINITION set "label_by_ddic = abap_false" for table
If you do this, then you will have the option to change the label in the configuration. Also if you leave the label empty in
the configuration, then FPM will use the label of the data element.

Scenario 4: The text is dynamic and used in Web Dynpro or FPM
Preferred choice: You should store the text in the text element of a class
Why: The text is not bound to an UI element. You can't easily translate it when you use the OTR. For example you won't
see the text in function module: SOTR_API_WB_TRANSLATE

Best regards,

Robin Vleeschhouwer

RV SAP Consultancy
588 Views 2 Comments
Tags: wda, abap, web_dynpro, webdynpro, f pm, web_dynpro_abap, localization, translate, webdynpro_f or_abap,
f loor_plan_manager_f pm, f loor_plan_manager
This blog brings all Webdynpro ABAP Select-Otions, OVS Help and Freely Programmed Input Help Related
Documents from scn at one place.

And also attached document for How to use new Select-Options WD_SELECT_OPTIONS_20.


SAP Help Documentation.

Select Options and Complex Select Options Usage.

New Select-Options WD_SELECT_OPTIONS_20.

OVS Help

SAP Help Documentation.
WebDynpro ABAP Select-Options and OVS Help.
Posted by Krishna Reddy B May 13, 2013

OVS Help for Multiple Input Fields.

OVS Help in Select-Options.

OVS Help with Multiple Input Fields in Select-Options.

Freely Programmed Input help

SAP Help Documentation.
855 Views 1 Comments Tags: web_dynpro
We did a survey last year to check with Web Dynpro ABAP developer if they really need eclipse based development
environment: Web Dynpro ABAP Tools in Eclipse Survey
The results of the survey were very positive and hence we start the project to create such environment.

Today, we released the first version and is available for you for real productive usage.

If you are in Web Dynpro ABAP application development arena and didn't participate in that survey, you must have the
question "Why should I use the new development environment to develop Web Dynpro ABAP applications ?".
Our answer is: In this new development environment, you do everything faster (lots of productivity gains) and many
things which were not possible earlier in old development environment, are available now. Apart from the list of
features below, please refer to the blog " How developing Web Dynpro ABAP Applications using ABAP
development tools (for Eclipse) is more fun !" will emphasize more on them.
Moreover in coming releases you will see more and more features made available for Web Dynpro ABAP
development using ABAP development tools for Eclipse.

For complete information please check this document : Developing Web Dynpro ABAP Applications using ABAP
development tools (for Eclipse)
Floor Plan Integration is also available now in ABAP in Eclipse: Develop UIs using Floor Plan Manager using ABAP
development tools (for Eclipse)

Have fun with the new development environment. Please keep us posted with your feedback and suggestions
for the new development environment.
583 Views 3 Comments
Tags: web_dynpro, web_dynpro_abap, f loorplan_manager_f or_webdynpro_abap;, f loor_plan_manager_f pm
Develop Web Dynpro ABAP faster !
Posted by Ashwani Kumar Sharma May 10, 2013

Please find the step to call the tcode pa60 from webdynpro ABAP .

Publish the three of the component below this is to refersh/activate the integration between R3 and internet gui in the
screen shot provided below .

Calling a TCODE PA60 from Web dynpro ABAP
Posted by Om Awasthi May 7, 2013

Create a link to URL UI element .
Pass the reference field as the combination of the server and the transaction which we want to execute example :
URL of Z application - http://soemthing.main.glb.corp.local:8003/sap/bc/webdynpro/sap/z_tcode
Tcode which you want to execute PA61
So create the url and assign to ur link to URL UI element as reference field

Out put after you click on the reference url which you created.

424 Views 0 Comments
Tags: web_dynpro, web_dynpro_abap, webdynpro_abap, ui_element, webdynpro_f or_abap, abap_wd
There are people who still want to know if it is really possible to Call a Transaction/T-code from a WebDynPro ABAP

I put together a quick set of steps to help answer that. We will call the HUPAST transaction in SAP.

1) Create a WD application ZTEST_CALL_HUPAST.

Calling SAP Transactions from WDA
Posted by Phani R Mullapudi May 2, 2013
2) In the main View, create a button "HUPAST".

3) Create an OnAction event handler method CALL_HUPAST & place the below code in it.

DATA lo_window_manager TYPE REF TO if_wd_window_manager.
DATA lo_api_component TYPE REF TO if_wd_component.
DATA lo_window TYPE REF TO if_wd_window.
lo_api_component = wd_comp_controller->wd_get_api( ).
lo_window_manager = lo_api_component->get_window_manager( ).
lo_window = lo_window_manager->create_external_window(
url = '*hupast'
lo_window->open( ).

4) Create a WD Application for this component, Activate component & run the URL.

RESULT: Once user hits the HUPAST button, It will create a new window with the HUPAST transaction. You can
replace the transaction with any of your choice.
2689 Views 2 Comments Tags: web, abap, web_dynpro, dynpro
Welcome to my first blog and here I am going to tell you a trick. Sometimes, there are multiple WD components
reusing each other and share a common assistance class. Each component requires a separate instance of
assistance class, however, some common data also we want to share between these WD components.
Now, there are few other ways using which we can achieve the same:
1. We can share the assistance class object in the used component, by sharing the same assistance class object
at runtime. For more detail, you can refer link
2. We can do external mapping between the using and used component using Component Interface Controller.
3. The third way that I am going to explain is a bit different and it is based on the OOPS ABAP concept and without
runtime code and external mapping.
Consider that we have two WD components, ZWD_MAIN and ZWD_USED.
Both the components are using the same assistance class ZCL_WD_ASSIST.
What we know is that each WD component will have its own instance of assistance class. Each object will be different
and have different instance of the ZCUSTOMERS. So how can we make sure that both the object points to same
attribute? I think you have guessed it
If not, here is the magic trick, if we want to share the ZCUSTOMERS list between two WD components, then just by
changing the attribute ZCUSTOMERS from Instance Attribute to Static Attribute, all the assistance class object can
share the ZCUSTOMERS data. Isnt it very simple .

Comments and suggestions are welcome.
490 Views 0 Comments Tags: web_dynpro, web_dynpro_abap, reusability, assistance_class
Data sharing between multiple WD component using
same assistance class
Posted by Abhinav S May 2, 2013
can any one plz explain how to raise a pop up window with out using CREATE_WINDOW method of interface
My requirement is i have to crate three buttons for ex button 1, button 2, button 3 in main view .when i click on the
button 1 a pop up window should be raised . similarly for the remaining but here i must use the window which is
how to raise a popup window with out using
create_window method
Posted by sivaramakrishna sayini Apr 22, 2013
Follow SCN
Site Index Contact Us SAP Help Portal
Privacy Terms of Use Legal Disclosure Copyright
created by default with webdynpro component.
263 Views 0 Comments Tags: web_dynpro, webdynpro_abap
HI All,

Here i have a requirement for Automation of 'All measuring point on object" in transaction IK22, through WDA....

I am executing the standard transaction through URL in webdynpro abap.. In transaction IK22 i am able to skip the
first screen but could not able to trigger button 'All measuring point on object" automatically in second screen.

Kindly let me know how to trigger the above button automatically.

Thanks in advance!
93 Views 0 Comments Tags: web_dynpro
Automation of "All measuring points on object" in
transaction IK22 through WDA
Posted by suresh gunnam Apr 19, 2013
Weird question isn't it ? The main purpose of this article is not to discuss about Web Dynpro ABAP but just to show
you how to use NOT pattern in your context binding

Let me show you with an example: when you use boolean attributes, often we want to have the opposite value
depending on how you think : isActivated or isDisable ?

Static option
The easiest way to do this NOT operation is using the wizard when you bind context attribute to graphical element
property. On the bottom of the wizard you will appear an option called : INVERT. Select it and that's it !

Thus, each TRUE value will be FALSE for the property element, and each FALSE will be TRUE for that element.

Dynamic option
Now, how to do the same thing but in dynamic context, such as in ALV element?

The key of the problem is: ":NOT"

Here is an easy example in ALV context to add button and bind the enabled property to the context and invert the value.

It is easy to use the NOT operator in the context binding so do not hesitate to use it. I would like to thanks a friend of
my Guillaume G. who ask me the question and bring me the ALV example.

556 Views 0 Comments Tags: web_dynpro, dynamic, web_dynpro_abap, invert;not, operator;, abap;alv
NOT or NOT Web dynpro ABAP?
Posted by Joseph BERTHE Apr 11, 2013
01. CREATE OBJECT lo_button.
02. lo_button->set_enabled_fieldname( 'ALV_MD__SAVED_ACTION:NOT' ).
1 2 3 4 5 6 8
Previous Next