Best-Practices For Optimizing Web Dynpro Java Application Performance

COMP204 Best-Practices for Optimizing Web Dynpro Java Application Performance
Bertram Ganz, SAP NW UI Foundation OPS
Disclaimer
This presentation outlines our general product direction and should not be relied on in making a purchase decision. This presentation is not subject to your license agreement or any other agreement with SAP. SAP has no obligation to pursue any course of business outlined in this presentation or to develop or release any functionality mentioned in this presentation. This presentation and SAP's strategy and possible future developments are subject to change and may be changed by SAP at any time for any reason without notice. This document is provided without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP assumes no responsibility for errors or omissions in this document, except if such damages were caused by SAP intentionally or grossly negligent.
SAP 2008 / SAP TechEd 08 / COMP204 / Page 2
Session Abstract COMP204

Best-Practices for Optimizing Web Dynpro Java Application Performance Release NetWeaver 7.0 and CE 7.1 Description Type Audience Developers or architects with intermediate knowledge in Web Dynpro Java business application development
In this lecture you learn the most effective best1-hour practices to optimize the performance of your Web Lecture Dynpro Java application regarding an enhanced UI responsiveness on client side and minimized memory consumption on server side. The given recommendations and best-practice rules focus on different aspects related to user interface design, component granularity, component and controller lifecycle management, controller contexts, on-demand resources, table paging or models like the Adaptive RFC model. This session is based on Web Dynpro Java in SAP NetWeaver CE 7.1 so that performance rules related to the newest Web Dynpro Java Ajax features like the different flavors of suggestion, asynchronous input validation or the new UI element event onChange are also considered.
Agenda
1. Overview of Web Dynpro Java Performance Aspects 2. Web Dynpro Java Performance Guidelines
2.1. 2.2. 2.3. 2.4. 2.5. 2.6 Focus: User Interface Focus: Programming Model Focus: Controller Contexts Focus: Componentization Focus: Models Focus: New Ajax Functions
3. Special: Web Dynpro Table Paging 4. Performance Tools Overview 5. Summary
End-to-End Time: Who eats my TIME?
Backend Data Retrieval
Web Dynpro Runtime:

Component Creation Controller Creation UI Element Creation Context Creation
Application:

wdDoInit() wdDoModifyView() Action handlers
Network Latency
YOUR CODE!
Server-Side Rendering
(for each user interaction)
Browser Rendering
(for each user interaction)
On Server Side: Who eats my MEMORY?
Web Dynpro Runtime: Context Metadata UI Elements

Server Rendering Components Controllers
Application:

Context Data Controller Data (class member objects)
YOUR CODE and DECLARATIONs affect this!

Another Performance Flavor: TCD* Development Efficiency

*TCD = Total Cost of Development
YOUR ARCHITECTURE and DEVLOPMENT STYLE affect this!
Development Process

Build Process Understandability Maintainability
Main Objective: Know to Tackle Web Dynpro Java Performance Gremlins as a Developer
Components User Interface Contexts
Models
Programming Model
Where Gremlins live
Who Gremlins are
Ajax Functions
How Gremlins are tackled

Agenda

User Interface
Apply Container Layouting Rules and Avoid Deep Container Nesting

Dont add extra TransparentContainer UI elements inside container UI elements such as Groups these UI elements already contain a TransparentContainer.
Instead, control the layout using the layout property of the container UI element.
Prefer the Row layout to the Grid or Matrix layout if you dont need horizontal alignment (one column layouts). Prefer the Matrix layout to the Grid layout.
No need to specify column count. Helps to achieve consistent layouts via predefined paddings (property cellDesign).
Avoid complex and nested layouts wherever possible.

Nesting has a big impact on browser or client rendering performance! E.G. nesting transparent containers with matrix or grid layout inside other transparent containers also using these container layout types. Instead, try to use a single large grid or matrix layout with column spans.
User Interface
Client Time
Exchange Transparent Root Container UI Element with other Container Types in CE 7.1
New in NetWeaver CE 7.1 Exchange default root view element (TransparentContainerUIElement) with other container UI element (like TabStrip, Table, Group) to minimize container nesting levels
CE 7.1 CE 7.1
Question: Can I see the nesting of containers in the browser
Answer: Use the key combination CTRL+ALT+SHIFT+O visualize the nesting in the browser in Web Dynpro screens. Focus a UI element first.
User Interface
CE 7.1
Client Time
Load Large Trees on Demand Use New Table Selection Change Behavior
Use load-on-demand (onLoadChildren event) to populate large trees.
Use the table selection change behavior by setting the table-property compatibilityMode == nw04Plus in NW 04 and NW 7.0 explicitly to enhance table performance.
Avoids a second implicit lead-selection roundtrip when triggering a single action Implement a parameter mapping relation for the UI element event parameter nodeElement Note: New table selection change behavior is default in NetWeaver CE 7.1 See SDN WebLog 2343 Enhancing Web Dynpro Java Table Performance CE 7.1 CE 7.1
Apply table paging techniques to populate large tables with hundreds of records
See special section on Web Dynpro Table Paging .
User Interface
CE 7.1
Memory
Server Time
Client Time
Make UI Containers Invisible Instead of UI Els.
Web Dynpro does not render UI elements whose visibility property is set to WDVisibility.NONE
Instead of making multiple single UI elements invisible better set the embedding UI element containers visibility to WDVisibility.NONE Renderer does not have to loop all container elements on server side
User Interface
Server Time
Client Time
Adobe Interactive Forms Dos and Donts (1)
Adobe Interactive Forms are always a performance penalty for the following reasons ...
Remote call from the SAP NetWeaver AS Java to the ADS server to build the PDF file Additional roundtrips between the Acrobat Reader and the SAP NetWeaver AS Java to exchange the PDF file and the input data SOAP call to remote ADS server to create binary PDF resources PDF stream read/write with every request (almost!) PDF transfer from browser to the server and vice versa Additional application specific BAPI calls might take additional time
Performance recommendations on Web Dynpro Java application side
Usage of Zero Client Installation (ZCI) is strongly recommended Always use the latest ZCI script from Adobe inside the form.
User Interface
Server Time
Client Time
Adobe Interactive Forms Dos and Donts (2)
Performance recommendations on Web Dynpro Java application side Do not bind the pdfSource property until and unless the application needs the latest binary PDF available on the server. Use pdfResource property instead of pdfSource to leverage resource based optimizations (only send XML instead of binary PDF data).. Have a pre-created PDF and then use the same throughout the application session using usePdf mode.
UsePdf mode is disconnected from ADS for simple data transfer cases. It only gets connected to the ADS when it is absolutely required.
User Interface
CE 7.1
Server Time
Client Time
Agenda

Programming Model
Implement wdDoModify() Hook Judiciously Use Context for Fine Grain UI Manipulations
Implement fine grain UI manipulations on context but not on UI element level to maximize the rendering performance:
Do not call the setter-methods of UI element objects inside wdDoModifyView() directly: Not: wdDoModifyView(){ theField.setEnabled(true) } Bind the related properties to the context and call the corresponding setter methods outside wdDoModifyView(): But: wdDoInit(){ wdContext.currentFieldNode.setEnabled(true) }. Especially bind UI element properties like readOnly, visibility, enabled, TreeNodeType.expanded, TabStrip.selectedTab or TableColumn.sortState to properly typed context attributes. The UI adapts automatically. Otherwise Web Dynpros caching mechanisms cannot speed up the rendering of view layouts!
Avoid repeated modification of view layouts when not necessary

If possible only modify views once during initialization (firstTime == true). If not, repeat modification of view layouts (firstTime == false) only when necessary (UI state change) In case you cannot adapt a view layout to your need with data binding you should consider to create a separate, more specialized view layout instead and to switch between them via navigation link.
Programming Model
Server Time
s Client Time
Optimize Controller Lifespans How to Determine a View Controllers Lifespan

Optimize the view controllers lifespan
Use lifespan == framework_controlled by default
Set view controller lifespan == when_visible to improve memory performance.

Example: Views that both require a lot of memory (for data and layout) and that are (usually) used once and then not needed anymore.
Given Drawbacks of shorter lifespan: View will be destroyed by the framework (calls wdDoExit() befor) when it is no longer visible Re-creation of view controller instance takes additional time because wdDoInit() must run again. View state", e.g. the first visible row of a table or the currently selected tab of a tab-strip etc. are lost when view instance gets destroyed (can be kept in mapped component or custom controller context).
Programming Model
Memory
Server Time
Correctly Initialize Component Controllers Use Additional Custom Controllers

Dont implement monolithic component controllers
Component controllers are automatically launched on component creation time (normally on application startup). Therefore, component controllers containing extensive coding and declarations in their wdDoInit() methods will require a longer creation time. Only add coding to a controllers wdDoinit() method if the results of its execution are actually required at the start of the controllers lifecycle.
Use additional custom controllers to keep the component controller as efficient as possible
Custom controllers are created on-demand. Therefore, moving functionality into a custom controller will delay its initialization from the start of the component controllers lifecycle to the point in time when it is actually needed. This can reduce the time taken for a component to start. Custom controllers should be used when you have identified a specific reuse case or when a distinct unit of functionality can be identified and separated from the main component controller.
Programming Model
Memory
Server Time
Create Static URLs for Static MIMEs
Create static URLs for static MIME resources via WDURLGenerator service which generates static URLs for MIMEs
(= deployable object parts) being stored and deployed in separate Web Dynpro DCs Configuration to create static MIME resource URLs at runtime (being stored in context) Common client implementations (like browsers) use caching mechanisms handling the lifetime of requested MIME objects.
MIME servers should therefore

generate static URLs to their MIME objects. This implies also request parameters appended to the URL. not limit the lifetime of a MIME object (e.g. single request).
Do not redundantly store session independent MIME resources per session in Web Dynpro Binary Cache or controller contexts:
WDWebResource.getWebResource(file, type) WDResourceFactory.createCachedResource() Instead, create static URLs for static MIMEs (see above)
Programming Model
Memory
Server Time
Client Time
Agenda

Controller Contexts
Minimize Generation of Typed Context APIs Avoid Context Mapping if not Needed
When declaring context nodes set property typedAccessRequired == false in case
a typed context access is not required within the controller coding. This is often the case when defining mapped view context elements. a context node contains many attributes but only a few attributes are accessed inside the controller coding. Access these attributes with the generic context APIs IWDNode and IWDNodeElement instead.
Dont mirror full controller context hierarchies in mapped controller contexts

Instead, do only map the required sub-set of (inner) context (data) nodes and attributes to keep the mapped controller context as slim as possible.
Controller Contexts
Memory
Dont Declare Context Model Nodes and Attributes NOT used for Data Binding Purposes
When model data retrieved via backend connections (Adaptive RFC, Web Service, EJB) has NOT to be transferred to the user interface via data binding:
There is no need to declare context model nodes and attributes bound to model classes and attributes for storing business data in the context. Just programmatically operate on model objects directly to access model data in your controller classes
By omitting the definition of a context-to-model binding relation in a controller context, the generated context interfaces are kept as slim as possible, and this reduces the permanent memory space* on server side.
Controller Contexts
Memory
Apply Alternative Techniques to Share Data Across Controller and Component Borders Consider other techniques than context mapping to share data NOT used for data binding across controller and component borders: server-side eventing (component interface) controller method Invocation navigation plugs (inbound and outbound plugs) Use private non-satic member variables instead of context attributes to store and access Java objects NOT used for data binding inside controller classes.
Controller Contexts
Memory
Prefer Singleton to Non-Singleton Context Nodes

Prefer defining singleton child nodes to non-singleton child-nodes wherever possible unless a given requirement cannot be fulfilled (see next slide )
Define singleton nodes to minimize the memory footprint of a controller context at runtime:
Populate singleton nodes with supply functions
Controller Contexts
Memory
When to Define Non-Singleton Context Nodes
Define non-singleton context nodes under the following circumstances

Tables: If the content of a child context node (table columns) must be simultaneously available for all node elements (table lines) of its parent node, the child node must be of type non-singleton. Trees: To populate a Tree UI element an inner context node, which is defined on the same level like the used recursive node, must be of type non-singleton. Extending structure nodes at design time: Declare a non-singleton child node (cardinality x..1) to extend structure nodes with additional attributes at design time. Validate-By-Rendering: Performance can be enhanced by declaring nonsingleton child nodes of cardinality 1..1 to reduce the number of BAPI calls (see next slide )
Controller Contexts
Memory
Server Time
When to Use the Validate-By-Rendering Technique (1)

Whats Validate-By-Rendering? The Web Dynpro Runtime only validates those context nodes which contain UI relevant data. This means, that the rendered user interface elements are bound to them (data binding). Context node validation implies supply function invocation as well as getter/setter method calls for the defined calculated context of this context node.
Retrieval of detail model objects associated with master model objects is too expensive for all node elements:
Bind a non-singleton [1..1] or [1..n] child node to the detail model class and declare a supply function for it. The supply function is only called for the rendered (validated) child nodes (visible table rows) referencing the detail model objects. Explicitly invalidate these inner child nodes when detail model object retrieval is required again. Binding a new list of node elements or model objects to a context will invalidate all child nodes. Controller Contexts
Memory
Server Time
When to Use the Validate-By-Rendering Technique (2)

tables data node with cardinality 0..n non-singleton child node with cardinality 1..1 calculated context attribute
Singleton property is set to false
supply function is called for every validated (rendered/visible) nonsingleton child node instance Controller Contexts
Memory
Server Time
Create Resources on-Demand to Download Large or Many MIME Files

Create resources on-demand when they are actually being requested for file download on client side
Do not prefetch or store MIME resouces in controller contexts on server side before being requested for file download on client side to reduce memory consumption NetWeaver 7.0: Lazily initialize context attributes with 0-byte resource objects of type IWDResource (see factory methods below) to be streamed to the client on-demand (based on calculated context attribute getter invocation) NetWeaver CE 7.1: Lazily initialize context attributes with resource objects associated with an object implementing the IWDResourceContentProvider API.
Release SAP NetWeaver 04 and 7.0 Return Type IWDResource
WDResourceFactory API Method

createResource(IWDAttributePointer attributePointer, String resourceName, WDWebResourceType type) Method creates an instance of IWDResource, which is bindable to FileDownload-UIElement. Resource is created on-demand in the referenced calculated context attributes getter method.
SAP NetWeaver CE 7.1
IWDResource
createResource(IWDResourceContentProvider provider, String resourceName, WDWebResourceType type) Method creates an instance of IWDResource, which is bindable to FileDownload-UIElement. Resource is created on-demand by the resource content provider implementation.
Controller Contexts
Memory
Server Time
Agenda

Componentization
Finding the Best Web Dynpro (Development) Component Granularity

Optimize the development performance with the best deployment granularity
Keep your Web Dynpro development components (Web Dynpro DCs) as slim as possible to accelerate build/deploy/run turnaround cycles
Optimize the application architecture with the best Web Dynpro component granularity
Rule of Thumb: implement 1 Business Task in 1 Web Dynpro component Dont make Web Dynpro components too large distributing work between several developers is harder reusability is very poor But: Dont make Web Dynpro components too small the application might not perform well the resulting sea of components might reduce maintainability reuse level too small higher system overheads
Componentization
TCD
Accelerate Single Development Cycles
Minimize the duration of a single development cycle by

only rebuilding DCs as soon as its Public Part definition has changed, otherwise only rebuild project only doing a Deploy New archive and Run step for changed DCs adhering to the rule of splitting up models, dictionaries, Web Dynpro components and component interface definitions into separate Web Dynpro DCs Project Build
Development Component Build
Componentization
TCD
Apply Inverse Search Function to Resolve Usage Dependencies

Apply inverse search function for individual Web Dynpro entities, such as components, controllers, context nodes, context attributes, or model classes, to resolve usage dependencies:
List all users (other components and controllers) of a Web Dynpro entity inside and outside of a Web Dynpro development component. Select Web Dynpro entity and open context menu item References Workspace and References Project. CE 7.1 CE 7.1
Componentization
TCD
CE 7.1
Split your Web Dynpro Application into separate Web Dynpro DCs
Apply Web Dynpro Component Separation Principles
Create a single root component which embeds and layouts separate UI components. Separate the UI in visual Web Dynpro components Centralize model access in a faceless model component and use this singleton model component in other components by applying the component usage referencing mode.
Web Dynpro DC
Apply Web Dynpro Development Component Separation Principles

Place Web Dynpro models, components, component interface definitions and Local Dictionaries in separate Web Dynpro DCs Distribute work between developers by assigning one DC to one developer.
Web Dynpro DC
Web Dynpro DC Web Dynpro DC
Web Dynpro DC
Componentization
TCD
Apply Component Interface Definitions For Loose Component Coupling (Strategy Pattern)
Separate the component interface definition from the component interface implementation (strategy design pattern):
FIRST: Define Web Dynpro components on an abstract level: component interface: context structure, public methods, events component interface view: inbound plugs, outbound plugs used models THEN: Implement the given component interface definition in one or more concrete Web Dynpro component(s)
Advantages:
Loose Coupling: Component user can program against separately defined component interfaces (implementation is hidden) without declaring hard component usage(s) to one (or many) component implementations. Component implementation can be provided (or selected) later on at run time. Larger Web Dynpro applications can be effectively developed by many developers
Componentization
TCD
Optimize Component Lifecycle Management
Consider manual lifecycle management of Web Dynpro component instances

Component Usage Lifecycle = createOnDemand: createOnDemand Web Dynpro Runtime automatically creates component instance on component interface view navigation, context mapping access or interface method invocation BUT: A used component gets only destroyed automatically with its parent component Apply manual component usage lifecycle to create and DESTROY component instances more precisely in time via controller code (invoking the IWDComponentUsage API). Example: explicitly delete a displayed component when its disappears from the UI
Componentization
Memory
Server Time
Favor Java Utility Classes over Faceless Web Dynpro Components

Do not implement a faceless (without UI) Web Dynpro component for a single helper method, .
Defining a Web Dynpro Component + usages from all components might be too much overhead (during development). To keep memory usage low at runtime, you have to apply the component usage referencing mode for the new utility component (implies additional coding and declaration efforts)
, instead implement a simple, pure Java utility class:

Expose such a Java class in a Web Dynpro or Java DC via DC public parts and reference it from all your Web Dynpro DCs.
To implement other Web Dynpro Java dependant code that requires a Web Dynpro component (like shared contex nodes etc.), then a component makes sense and then you could incorporate the new method there as well.
Componentization
Memory
Server Time
Read SPJ Article Series on Component-Based Architecture in Web Dynpro Java

Go to the WIS/SAP Insert booth and drop off Your business card. They will send You the PDF of the first article in the series for free.
Get fi art i r st cl f or f e re at S e Tec AP hE d

Componentization
Agenda

Focus: Models
Adaptive RFC Model Dos and Donts
Apply Adaptive RFC Models for accessing RFC modules in SAP systems
Do not circumvent the Adaptive RFC layer by implementing your own, JCo-based, access to RFC modules which are exposed in a SAP system
Dont transfer table values as export or import parameters Dont embed tables within RFC import, export or table parameters Dont implement data intensive operations on the UI layer, for example, sorting and filtering of context model node elements
Instead, data intensive operations should already take place in the backend implementation (RFCs) itself. In this case the required unmarshalling is minimized
Models
TCD
Memory
Server Time
Adaptive RFC Model Dos and Donts
Put as many RFCs in a single Adaptive RFC model as possible Put RFCs into separate models only in case of
different RFCs in different backend systems have to be jointly accessed in one Web Dynpro application. This requires different connections. different lifecycles of the RFCs. These RFCs can then be kept and updated independent of each other. componentization across different DCs. In this case RFCs should also be separated.
Place Web Dynpro Models into separate model DCs. Therefore, model DCs will only be rebuilt when they change. TCD TCD
This greatly speeds up the development process.
Only re-import an Adaptive RFC Model when a table, which was defined as an import or export parameter before, is defined as a table parameter afterwards TCD TCD
Models
TCD
Memory
Server Time
Agenda

New Ajax Functions
New Suggestion Support in CE 7.1 EhP1 Potentially Increases Number of Roundtrips!

Beware the increased number of server roundtrips for suggestionenabled (suggestValues = true) Input Fields in the following case:
The InputField suggestion is based on the OVS valuehelp: see IWDOVSSuggester, IWDSuggestionList In this case the client repeatedly calls the server to query and send back a list of matching suggestions on-demand.
There is also an increased number of server roundtrips when the InputField suggestion is based on on-demand valuesets or static valuesets defined in dictionary simple types with MORE than 200 values:
A matching chunk valueset with 200 values is retrieved in a first roundtrip. In additional roundtrips new valuesets matching the user input are retrieved from the server successively. see WDSimpleValueSupplier
New Ajax Functions

CE 7.1
Asynchronous Input Validation in CE 7.1 EhP1 Increases Number of Server Roundtrips!

The new asynchronous input validation for numeric values is enabled by default! This implies an increased number of server roundtrips to process the generic validation logic on server side
Input validation logic cannot be processed independently on client side
To disable the asynchronous input validation service on ...

Application level: start Web Dynpro application by adding the URL-parameter sap-wd-disableAsyncInputValidation = X. X User level: configure this URL parameter sap-wd-disableAsyncInputValidation=X for specific users, who for example run a Web Dynpro application in a WAN with lower bandwidth. Web Dynpro Java Runtime level: configure Web Dynpro runtime configuration property sap.wd.disableAsyncInputValidation = true in NetWeaver Administrator. By this the generic, asynchronous input validation service is disabled for all Web Dynpro applications without passing a URL-parameter.
New Ajax Functions

CE 7.1
Server Time
Client Time
New onChange Event in CE 7.1 EhP1 Increases Number of Server Roundtrips!

New onChange UI element event for InputField, FormattedTextEdit, TextEdit, ToolBarInputField implies an increased number of server roundtrips to handle action events on server side.
The action (the onChange event is bound to) is performed when a UI element loses focus AND its value has been changed.
Therefore use the new onChange UI element event judiciously when server-side logic is inevitably required. Note: With the new onChange event it is first possible that two action events are handled in the same server roundtrip.
Example: The user has changed an input field value and then directly presses a form button afterwards (without intermediately editing another field). The client then triggers two action events (onChange and onAction) in the same roundtrip to be processed on server side. The Web Dynpro Runtime first handles the action to which the onChange event is bound.
New Ajax Functions

CE 7.1
Server Time
Client Time
Agenda
3. Special: Web Dynpro Java Table Paging 4. Performance Tools Overview 5. Summary
Apply Table Paging Techniques to Reduce Memory and to Enhance Client Performance
Optimize performance with server-side table paging techniques to display a large number of table rows
highly reduced memory consumption by retrieving displayed table records on demand and caching them on Web Dynpro server side rapid initial table display based on minimized number of records initially retrieved from the backend exact table page navigation based on reading scrolltips in vertical table scrollbar
Technical Solution
Implement ICMIObservableList-API extending generic abstract base implementation class CMIAbstractObservableList. No supply function needed to populate the tables data node based on binding an ICMIObservableList object instance to it. Read fixed page size (= number of records per backend call) in one backend call. Only read displayed table records from backend on-demand after rendering phase.
CE 7.1 CE 7.1
For further details see SDN Wiki Page on How to Implement Table Paging Server Time Client Time
Table Paging
Table Paging Solution Architecture Digram
For further details see SDN Wiki Pages on Web Dynpro Java Table Paging and How to Implement Table Paging
Table Paging
Server Time
Client Time
DEMO
See Table Paging Demo Application Running on SAP NetWeaver CE 7.1
Agenda
3. 4. 5. 6.
Special: Web Dynpro Table Paging Performance Tools Overview Outlook Summary
Show Stacked Performance Infos for ALL Roundtrips in Running Client Session
Analyzing Web Dynpro Java Application Performance with a Simple URL-Parameter

Question: Answer: Use URL parameter sap-wd-showInfo=true (or =X) to =X display the performance breakdown between the client and the server in the browser status line (times in [ms]):
How to get a rough idea where time is spend in an application?

See SDN WebLog 5003
Part
Note: while running in the portal most URLs are calculated during the navigation. You can grep the URLs, run the app in separate browser window and then add the URL parameter there.
Parameter Parsing JSBefore Html JSAfter Description, times in [ms] Time for parsing HTML Time for processing JavaScript code before HTML rendering Time for rendering HTML Time for processing JavaScript code after HTML rendering Time to process and dispatch an incoming request to the Web Dynpro Runtime Time needed by the Web Dynpro Runtime to process the complete phase model Time for accessing the backend (executing ARFC, ESF, AWS model classes) Not measured (0) when other models are used (JavaBean, EJB Model) Estimated response size in kilobytes.
Browser
J2EE Back-End Size
Server side processing time
Agenda
Main Objective: Know to Tackle Web Dynpro Java Performance Gremlins as a Developer
Models
Programming Model
Where Gremlins live
Who Gremlins are
Ajax Functions
How Gremlins are tackled

Now You know How to tackle the Web Dynpro Java Performance Gremlins
Models
Apply ALL Web Dynpro Java Performance Rules

Programming Model
Know How Your Declarations and Code Affect Memory, Client and Server Time Apply Performance Tools
Ajax Functions
Building Your Business with SDN Subscriptions

SDN Subscriptions offers developers and consultants like you, an annual license to the complete SAP NetWeaver platform software, related services, and educational content, to keep you at the top of your profession.
SDN Software Subscriptions: (currently available in U.S. and Germany)
A one year low cost, development, test, and commercialization license to the complete SAP NetWeaver software platform Automatic notification for patches and updates Continuous learning presentations and demos to build expertise in each of the SAP NetWeaver platform components A personal SAP namespace
SAP NetWeaver Content Subscription: (available globally)

An online library of continuous learning content to help build skills.
Starter Kit
To learn more or to get your own SDN Subscription, visit us at the Community Clubhouse or at www.sdn.sap.com/irj/sdn/subscriptions
Further Information
SAP Public Web:
SAP Developer Network (SDN): www.sdn.sap.com SAP NetWeaver UI https://www.sdn.sap.com/irj/sdn/nw-ui Web Dynpro Java https://www.sdn.sap.com/irj/sdn/nw-wdjava
Related SAP Education and Certification Opportunities

http://www.sap.com/education/
Related Workshops/Lectures at SAP TechEd 2008

COMP165, Web Dynpro Java Goals, Concepts, Benefits, 2 hour hands-on COMP167, Web Dynpro Java for Beginners, 4 hour hands-on COMP200, Web Dynpro Java: Whats New With SAP NetWeaver CE 7.1, lecture COMP266, Best-Practices for Building State-of-the-Art Web Dynpro Java User Interfaces, 2 hour hands-on, Intermediate UP360 Enhancing Performance of Web Applications Using Accelerated Application Delivery , 4 hour hands-on, Advanced UP108 Accelerated Application Delivery: Enhancing the Performance of Web Applications , 1 hour lecture, Beginner
Thank you!
Feedback Please complete your session evaluation.

Be courteous deposit your trash, and do not take the handouts for the following session.
Thank You !

Best-Practices For Optimizing Web Dynpro Java Application Performance

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Best-Practices For Optimizing Web Dynpro Java Application Performance

Загружено:

Авторское право:

Доступные форматы

COMP204 Best-Practices for Optimizing Web Dynpro Java Application Performance

Bertram Ganz, SAP NW UI Foundation OPS

SAP 2008 / SAP TechEd 08 / COMP204 / Page 2

Session Abstract COMP204

SAP 2008 / SAP TechEd 08 / COMP204 / Page 3

3. Special: Web Dynpro Table Paging 4. Performance Tools Overview 5. Summary

SAP 2008 / SAP TechEd 08 / COMP204 / Page 4

End-to-End Time: Who eats my TIME?

Backend Data Retrieval

Web Dynpro Runtime:

Component Creation Controller Creation UI Element Creation Context Creation

wdDoInit() wdDoModifyView() Action handlers

On Server Side: Who eats my MEMORY?

Web Dynpro Runtime: Context Metadata UI Elements

Server Rendering Components Controllers

Context Data Controller Data (class member objects)

YOUR CODE and DECLARATIONs affect this!

Another Performance Flavor: TCD* Development Efficiency

YOUR ARCHITECTURE and DEVLOPMENT STYLE affect this!

Build Process Understandability Maintainability

SAP 2008 / SAP TechEd 08 / COMP204 / Page 7

Where Gremlins live

Who Gremlins are

How Gremlins are tackled

3. Special: Web Dynpro Table Paging 4. Performance Tools Overview 5. Summary

Apply Container Layouting Rules and Avoid Deep Container Nesting

Avoid complex and nested layouts wherever possible.

Question: Can I see the nesting of containers in the browser

Make UI Containers Invisible Instead of UI Els.

Adobe Interactive Forms Dos and Donts (1)

Performance recommendations on Web Dynpro Java application side

Adobe Interactive Forms Dos and Donts (2)

3. Special: Web Dynpro Table Paging 4. Performance Tools Overview 5. Summary

Avoid repeated modification of view layouts when not necessary

Optimize Controller Lifespans How to Determine a View Controllers Lifespan

Set view controller lifespan == when_visible to improve memory performance.

Correctly Initialize Component Controllers Use Additional Custom Controllers

Create Static URLs for Static MIMEs

MIME servers should therefore

3. Special: Web Dynpro Table Paging 4. Performance Tools Overview 5. Summary

Dont mirror full controller context hierarchies in mapped controller contexts

Prefer Singleton to Non-Singleton Context Nodes

Populate singleton nodes with supply functions

When to Define Non-Singleton Context Nodes

Define non-singleton context nodes under the following circumstances

When to Use the Validate-By-Rendering Technique (1)

When to Use the Validate-By-Rendering Technique (2)

Singleton property is set to false

Create Resources on-Demand to Download Large or Many MIME Files

WDResourceFactory API Method

SAP NetWeaver CE 7.1

3. Special: Web Dynpro Table Paging 4. Performance Tools Overview 5. Summary

Finding the Best Web Dynpro (Development) Component Granularity

Accelerate Single Development Cycles

Minimize the duration of a single development cycle by

Development Component Build

Apply Inverse Search Function to Resolve Usage Dependencies

Apply Web Dynpro Development Component Separation Principles

Web Dynpro DC Web Dynpro DC

Optimize Component Lifecycle Management

Consider manual lifecycle management of Web Dynpro component instances

Favor Java Utility Classes over Faceless Web Dynpro Components