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 Browse 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 : 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 Using Graphics in WebDynpro Posted by Tarun Telang Jun 11, 2013 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. 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. 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. Dictionary search help and Web dynpro Posted by Swati Agarwal Jun 3, 2013 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. 1116 Views 1 Comments Tags: web_dynpro, webdynpro, search_help, search_help_exit, abap_web_dynpro 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 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 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.
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,
Thanks! Mani 408 Views 2 Comments Tags: web_dynpro, webdynpro, dynpro, web_dynpro_abap, webdynpro_abap, webdynproabap, webdynpro_f or_abap, abap_wd 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 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 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 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.
Select-Options
SAP Help Documentation. https://help.sap.com/saphelp_nw70ehp1/helpdata/en/47/a0c2fd687d0795e10000000a42189b/content.htm
New Select-Options WD_SELECT_OPTIONS_20. http://scn.sap.com/docs/DOC-41404
OVS Help
SAP Help Documentation. WebDynpro ABAP Select-Options and OVS Help. Posted by Krishna Reddy B May 13, 2013 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 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 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 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 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.
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 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.
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.
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. 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 IF_WD_WINDOW_MANAGER , 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.
Conclusion 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.
Enjoy 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