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. Isn’t it very simple.

Comments and suggestions are welcome.

There are people who still want to know if it is really possible to Call a Transaction/T-code from a WebDynPro ABAP application.

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.

2) In the main View, create a button "HUPAST".

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

method ONACTIONCALL_HUPAST .

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 = 'http://ersbxdb0.gene.com:8040/sap/bc/gui/sap/its/webgui?~transaction=*hupast'
                   ).
lo_window->open( ).

endmethod.

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.

Hi,

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 .

1.       SYSTEM

2.       SHUFFLER

3.       WEBGUI

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

http://something.main.glb.corp.local:8003/sap/bc/gui/sap/its/webgui?~transaction=PA61

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

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.

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.

Select-Options 

SAP Help Documentation.

https://help.sap.com/saphelp_nw70ehp1/helpdata/en/47/a0c2fd687d0795e10000000a42189b/content.htm

Select Options and Complex Select Options Usage.

http://scn.sap.com/community/web-dynpro-abap/blog/2005/12/20/using-select-options-in-a-web-dynproabap-application

http://wiki.sdn.sap.com/wiki/display/Snippets/Web+Dynpro+ABAP+-+Complex+select-options+component+usages

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/c09fec07-0dab-2a10-dbbe-c9a26bdff03e?QuickLink=index&overridelayout=true&24215025625919

New Select-Options WD_SELECT_OPTIONS_20.

http://scn.sap.com/docs/DOC-41404

OVS Help

SAP Help Documentation.

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/47/9ef8c99b5e3c5ce10000000a421937/content.htm

OVS Help for Multiple Input Fields.

http://scn.sap.com/docs/DOC-41319

OVS Help in Select-Options.

http://scn.sap.com/docs/DOC-2359

OVS Help with Multiple Input Fields in Select-Options.

http://scn.sap.com/docs/DOC-41402

Freely Programmed Input help

SAP Help Documentation.

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/47/9ef8cc9b5e3c5ce10000000a421937/content.htm

http://scn.sap.com/docs/DOC-2355

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/80ae749c-87c9-2d10-87bd-821b5e92ee69?overridelayout=true&49478023320206

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

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 GUIBBs

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 ET_FIELD_DESCRIPTION.

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

@RVSAP

RV SAP Consultancy

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 IF_WD_COMPONENT_USAGE=>DELETE_COMPONENT.

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.

Regards,

Mani

• 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.

Please feel free to add more points in this blog,

Thanks!

Mani

Introduction

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

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 considerations.

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 happens:

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 "127.0.0.1" and port "8080"

Your setup should look like this:

Recording

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 (companyname.com). 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 configuration:

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 listener.

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 supported:

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 parameter SAPEVENTQUEUE:

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.

Conclusion

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.

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.

http://wiki.sdn.sap.com/wiki/display/Snippets/Implementing+Search+Help+Exits

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’.

    ENDIF.

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 cl_wdr_value_help_handler=>m_context_element

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

    lo_el_supp_table->get_static_attributes(

      IMPORTING

        static_attributes = ls_supp_table ).

    IF ls_supp_table-supplier IS NOT INITIAL.

      READ TABLE shlp-selopt

           TRANSPORTING NO FIELDS

           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'.

        ELSE.

          ls_sel_criteria-option = 'EQ'.

        ENDIF.

        APPEND ls_sel_criteria TO shlp-selopt.

        CLEAR ls_sel_criteria.

      ENDIF.

    ENDIF.

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 RECORD_TAB.

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.

1. When you bind the property filtervalue of the column to a context attribute whose type does not have a fixed domain values then the input field UI element will be provided. However an attribute without fixed domain values can be made displayed as a drop down instead of input box by adding valueset to the attribute which will be covered in the following post.
2. When the attribute with fixed domain values is binded to the filtervalue property then drop down UI element will be provided as a selection option.

1. Create a context attribute to be binded to the filter value property of the company code column.
2. Create a context attribute to switch on and switch off the filter.
3. Create a toolbar in the table UI element and button with an event handler method to switch on and switch off the filter.
4. Create an action to be triggered when the filter is selected.

  

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 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:

http://help.sap.com/saphelp_nw70/helpdata/en/47/9ef8cc9b5e3c5ce10000000a421937/frameset.htm

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

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 : http://<hostname:Port>/sap/bc/webdynpro/sap/wdr_test_web_icons?sap-language=EN

This will execute a ready-to-run demo applications on how to use graphics element in your WebDynpro development.

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.

1.  In SE80, select the required Web Dynpro ABAP application and display it (by double-clicking or by choosing Display).

2.      Choose Goto→ HTTP Service Maintenance. 

         You go to the service node in the SICF for your application.

3.     Select the service node that belongs to your Web Dynpro application.

4.     Choose Edit→ Runtime Analysis → Activate.

5.     Make the required settings and choose Activate.

      6. Start your Web Dynpro application, make your user entries and execute the operations for which you would like to make a runtime analysis. 

      7. To display the results of the runtime analysis, in transaction SE30 or SAT under Performance Data File choose Other File…

.        

          Once we click on Other File , popup will appear .Choose file and then click on Analyze button

Best regards,

Rao.

Hi Experts,

I am sharing my knowledge on Webdynpro Component Interface.

By using the component Interface, We can call multiple components dynamically based on action triggered.

In this document , I am calling 4 components dynamically based on action .

Steps to follow.

1.   Create a table named ZCOUNTRY_COMP.

  Create the entries as below

1.  Create a Webdynpro Component Interface with name 'ZRAO_INTERFACE_TEST' with interface view 'INTERFACE_VIEW'.

2. Create the 4 compoents with the names 'ZRAO_INTERFACE_COMP1,ZRAO_INTERFACE_COMP2,ZRAO_INTERFACE_COMP3

    and ZRAO_INTERFACE_COMP4'.

      Creating component 'ZRAO_INTERFACE_COMP1' as follows.

       i.  Delete the default window in ZRAO_INTERFACE_COMP1 and Implement the interface in the component ZRAO_INTERFACE_COMP1'.

           This interface will provide common window named 'INTERFACE_VIEW'.

     ii.  Create a view with UI element caption as below.

   Follow the above two steps for the another 3 components.( ZRAO_INTERFACE_COMP2, ZRAO_INTERFACE_COMP3, ZRAO_INTERFACE_COMP4 ).

&

After creating all the 4 components , Create a Main component ZRAO_INTERFACE_MAIN with re-use component

ZRAO_INTERFACE_TEST interface as follows.

3. Create the view with dropdownbyindex with action 'DROPDOWN' and one ViewContainerElement as below.

4.  Write the code in Action DROPDOWN .

     METHOD onactiondropdown .

   DATA lo_nd_country_comp TYPE REF TO if_wd_context_node.
   DATA lo_el_country_comp TYPE REF TO if_wd_context_element.
   DATA lv_wda_component TYPE string .

* navigate from <CONTEXT> to <COUNTRY_COMP> via lead selection
   lo_nd_country_comp = wd_context->get_child_node( name = wd_this->wdctx_country_comp ).
* get element via lead selection
   lo_el_country_comp = lo_nd_country_comp->get_element( ).

   IF lo_el_country_comp IS NOT INITIAL.
* get single attribute
     lo_el_country_comp->get_attribute(
       EXPORTING
         name =  'WDA_COMPONENT'
       IMPORTING
         value = lv_wda_component ).

       DATA lo_cmp_usage TYPE REF TO if_wd_component_usage.
       lo_cmp_usage =   wd_this->wd_cpuse_dynamic_comp1( ).
       IF lo_cmp_usage->has_active_component( ) IS INITIAL.
         lo_cmp_usage->create_component( lv_wda_component ). "Dynamic wda component name.
       ELSE.
         lo_cmp_usage->delete_component( ).
         lo_cmp_usage->create_component( lv_wda_component ). "Dynamic wda component name.
       ENDIF.

       wd_this->wd_get_api( )->do_dynamic_navigation(
         source_window_name = 'ZRAO_INTERFACE_MAIN' "{this is my window name }
         source_vusage_name = 'MAIN_USAGE_0' "{this one is MAIN--"}
         source_plug_name = 'OUT_PLUG1' "{this plug name can be generated dynamically }
         target_component_name = 'ZRAO_INTERFACE_TEST'
         target_component_usage = 'DYNAMIC_COMP1'
         target_view_name = 'INTERFACE_VIEW' "{the view i want to embed}
         target_plug_name = 'DEFAULT'
         target_embedding_position = 'MAIN/VCE' ).

   ENDIF.

ENDMETHOD.

Finally run the application.

If we select COMP2 , second component view will trigger.

Hope it will helpful.

Best regards,

Rao.

If you are running NW ABAP 7.31 SPS05, upgraing to SPS 07 means a lot of new feature for WebDynpro ABAP and Floor Plan Manager.

Below are the details of many new useful features delivered for ABAP WebDynpro & Floorplan Manager as part SPS07,

Web Dynpro Changes in 7.31 SPS07 -

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/eb/a6d6a041b04fa8afdeb49c1fa032e1/content.htm?frameset=/en/a3/721c134fdb4f1fbe774cfbfa9be66d/frameset.htm

Floor Plan Manager Changes in 7.31 SPS07-

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/41/801f67890d444ab5ae5efbbcca900a/content.htm?frameset=/en/a3/721c134fdb4f1fbe774cfbfa9be66d/frameset.htm

Hi,

I want to create a Search input field on my wd screen which can search an index based on the search text I feed in. The challenge is that search query in the background should execute as soon as I start writing the key rather than on hitting any button. Did any of you do this in past or have any insights on this. Basically I need to know if there is a wd function which gets called on entering text in the input field.

If there is nothing like this available as of now in SAP, any suggestion on how to approach designing this functionality. Thank you so much.

The objective of this article is to summarize the main differences of UI technologies like Business Server Pages and Webdynpro, in order to check the pros and cons when deciding on which technology to use be used by developers for the required project. The table at the end of the article summarizes the advantages and disadvantages of both UI technologies.

Web Dynpro is the follow up of the classical Dynpro technology. It is not a direct competitor of BSP or SAP ITS.

Web Dynpro is a programming model, which allows to design standard UIs very quick. Everything that can be designed without coding is designed without coding. On the other side, the freedom in designing the UI is restricted. E.g. it is not possible to include client side JavaScript in the generated pages. The generated code is not restricted to HTML.

BSP programming model offers to include all browser supported techniques in the generated HTML pages. However, the construction of a BSP UI

takes a lot more time than the development of a WD UI, since there is no declarative approach. Thus, BSP can be used for “free-style” programming.

Web Dynpro is implemented in Java and ABAP. It is suited to generate standardized user interfaces (UIs) using a declarative approach, resulting in a minimum time effort to realize Web applications.

In the ABAP area, there exist two other programming models, SAP ITS and BSPs, which are still supported. The developer should be prepared for questions, related to the pros and cons of these three technologies.

SAP ITS will be used in to future to map existing Dynpro-based transactions to HTML pages. This will be necessary, since it is impossible to convert

all Dynpro-based transactions to Web Dynpro in an acceptable time frame. SAP ITS is the only Web enabling technology. For all other technologies, the

application has to be rewritten completely! Cons: Long response times, since an additional time frame is necessary for the mapping between HTML pages and

Dynpros (in both directions).

Web Dynpro is the technology SAP uses for developing all future applications. Existing Dynpro-based transactions will be converted. Web Dynpro will replace

the old Dynpro step by step. Cons: Web Dynpro does allow to develop of standardized UI very quick, but it is not the right choice for the development

of fancy Internet-like UIs. This is because the UI is rendered from meta data, so the developer can not place his/her own JavaScript code in the rendered

HTML page! Web Dynpro has to be embedded in the portal environment to be able to change the application design.

BSP is the ABAP technology for “free-style” programming. Everything is possible in terms of RIA (Rich Internet Applications). BSP can be compared to JSP on the Java side. Cons: Standardized UIs are not supported and everything has to be coded (Navigation, UI...). The development of a BSP-based UI is much slower than the Web Dynpro development. Because SAP develops standard applications with the need to have a standardized and consistent UI, BSP will not be used by SAP. However, BSP is the only of these three technologies, that allows to design sophisticated Internet applications based on ABAP. Thus this technology will be very interesting for the customer also in the future.

http://wiki.sdn.sap.com/wiki/display/Snippets/ABAP+Web+Dynpro+ALV+-+Change+Cell+Colour+based+on+Content

Analyzing Web Dynpro Adaptations

Motivation

Analyzing an adapted component

Before having a look at various tools first we need an adapted component to play around.

Customizing a Web Dynpro Component

• Runtime
  Customizing is switched on in runtime mode when you run your application with the additional url-parameter sap-config-mode=X.
  Customizing at runtime shall be used for Build-In adaptations.

• Design time
  Design time customizing takes place in the customizing editor – application (customize_component).
  Customizing at design time shall be used for Component-Defined adaptations.

Customizing a Web Dynpro Component at runtime

• Start the application (wdr_test_pers_imp_exp) with url-parameter sap-config-mode=x.
• Hide one plane icon. Click the right mouse button on this field and choose “Settings for current configuration” in the context menu.

• Set the image to invisible input. And press button “Save and Close”.
• In the transport request popup box choose “No Transport Request”.
  
• Press Settings and change the treshold settings. And press button “Save”.
• In the transport request popup box choose “No Transport Request”.

• Changes are applied instantly:
  

Personalization of a Web Dynpro Component at runtime 

• Start the application (wdr_test_pers_imp_exp).
• Adjust the flight table. click the right mouse button and choose "More...".
  
• Remove the Date column and press OK..

• Changes are applied instantly and saved automatically:
   

Analyzing all Adaptations at runtime with Runtime Analysis Tool (RAT)

• Press Button “Activate for this user”.
• Select WD Component Configuration
• OK

• Start the application.
• Customized and personalized adaptations are active.

• Analyze the adaptation by clicking right mouse button on any position of this screen and select “Technical Help” from context menu.
  

• Choose tab “Adaptations”
• The following levels of adaptation may exist:
  • ENH – enhancement
  • CON – configuration
  • CUS – customizing
  • PRS – personalization

• For each level of available adaptation you can select the entry in the adaptation list.
• Selecting an adaptation level will show the details for Build-In and Component Defined adaptations up to this level.
• Comparing the changes it is easy to find out on which level which adaptation is applied.
  In our case you see that the value of attribute "CONFIG_LOW" has been changed  in customizing to value “30”.

• The Built-In adaptations are also available for each level:

• Keep in mind that showing up in the adaptation details doesn’t mean that this entity has been adapted at the selected level.
  It means that there is an adaption changing this entity on this level. The adaption may exist on a level below or on the selected level.
• The adaptations details always show the actual adaptation that influences the entity on the selected level. It will not show the delta from the underlying level.

Analyzing Configurations with WD_ANALYZE_CONFIG_COMP

• In SE80 search for Web Dynpro application “WD_ANALYZE_CONFIG_COMP” and start it.
• Enter your configuration to be analyzed.
• From a list of available configurations you can select your desired configuration for inspection of adaptation details.
  It is also possible to delete or transport a configuration.
  
  
• Selecting a configuration will show the details of Build-In and Component Defined adaptations.

Analyzing Customizing and Personalization with WD_ANALYZE_CONFIG_USER