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

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.

Disclaimer


Session Abstract COMP204

Release Description Type Audience

NetWeaver 7.0 and CE 7.1

In this lecture you learn the most effective best- practices to optimize the performance of your Web 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.

1-hour Lecture

Developers or architects with intermediate knowledge in Web Dynpro Java business application development

Best-Practices for Optimizing Web Dynpro Java Application Performance


1. Overview of Web Dynpro Java Performance Aspects2. Web Dynpro Java Performance Guidelines

2.1. Focus: User Interface2.2. Focus: Programming Model2.3. Focus: Controller Contexts2.4. Focus: Componentization2.5. Focus: Models2.6 Focus: New Ajax Functions

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

Agenda


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

Backend DataRetrieval

Web Dynpro Runtime:• Component Creation• Controller Creation• UI Element Creation• Context Creation

Browser Rendering(for each user interaction)

Server-SideRendering(for each user interaction)

NetworkLatency

Application:• wdDoInit()• wdDoModifyView()• Action handlers

YOURYOURCODE!CODE!

Presenter

Presentation Notes

Network / Latency: See other TechEd Sessions 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


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 YOUR CODE and DECLARATIONsDECLARATIONs affect this!affect this!


Another Performance Flavor: TCD* Development Efficiency

*TCD = Total Cost of Development

YOUR YOUR ARCHITECTURE ARCHITECTURE and DEVLOPMENT and DEVLOPMENT STYLE affect this!STYLE affect this!

DevelopmentProcess• Build Process• Understandability• Maintainability

Presenter

Presentation Notes

Maintainability : the ease with which a software system or component can be modified to correct faults, improve performance, or other attributes, or adapt to a changed environment (IEEE 90)


Main Objective: „Know to Tackle Web Dynpro Java Performance Gremlins as a Developer“

User Interface

Components

AjaxFunctionsProgramming

Model

Models

Contexts

WhereGremlins live …

WhoGremlins

are …

How Gremlins are tackled …



2.1.2.1. Focus: User InterfaceFocus: User Interface2.2. Focus: Programming Model2.3. Focus: Controller Contexts2.4. Focus: Componentization2.5. Focus: Models2.6 Focus: New Ajax Functions


Agenda

User Interface


Apply Container Layouting Rules and Avoid Deep Container Nesting

Don’t 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 don’t 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

Presenter

Presentation Notes

Prefer the Row Layout to the Grid or Matrix Layout if you don’t need horizontal alignment! The row layout allows you to put an arbitrary number of elements in each row (it automatically uses a flow layout for each row). If you need a new row you simple set the property layoutData of the first element of the new row to RowHeadData. It is also a good idea to use the row layout if you have only one element per row as it is often used to arrange a screen vertically. Prefer the Matrix Layout to the Grid Layout! This won’t enhance the performance, but we think it is easier for the application developer to work with it: You don’t have to specify a column count and you can put as many controls into one row as you like. If you need a new row you simple set the property layoutData of the first element of the new row to MatrixHeadData. Additionally, the matrix layout helps to achieve consistent layouting: Other than the grid layout, the matrix layout only allows some predefined values for the cell padding. Instead of the properties paddingTop, paddingButtom, paddingLeft and paddingRight it only offers the property cellDesign with the following predefined values:


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

User Interface

CE 7.1CE 7.1

Answer:Use the key combination CTRL+ALT+SHIFT+O visualize the nesting in the browser in Web Dynpro screens.Focus a UI element first.

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

Client TimeCE 7.1


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 compatibilityModecompatibilityMode == nw04Plus == nw04Plus in NW 04 and NW 7.0 explicitly to enhance table performance.

Avoids a second implicit lead-selection roundtrip when triggering a single actionImplement a parameter mapping relation for the UI element event parameter nodeElementNote: New table selection change behavior is default in NetWeaver CE 7.1See SDN WebLog 2343 Enhancing Web Dynpro Java Table Performance

Apply table paging techniques to populate large tables with hundreds of recordsSee special section on Web Dynpro Table Paging ….

User Interface

CE 7.1CE 7.1

Client TimeCE 7.1 Memory Server Time

Presenter

Presentation Notes

Use load-on-demand (onLoadChildren event) to populate large trees: Assign an event handler to the onLoadChildren() event of the TreeNode Type. Apply parameter mapping for event property path so that the event handler knows about the context path corresponding to the clicked tree element. Implement the event handler for populating the given context node with node elements.

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2343


Make UI Containers Invisible Instead of UI Els.

Web Dynpro does not render UI elements whose visibility property is set to WDVisibility.NONEWDVisibility.NONE

Instead of making multiple single UI elements invisible better set the embedding UI element container’s visibility to WDVisibility.NONEWDVisibility.NONE

Renderer does not have to loop all container elements on server side

User Interface Client TimeServer Time


Adobe Interactive Forms Dos and Don’ts (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 dataSOAP call to remote ADS server to create binary PDF resourcesPDF stream read/write with every request (almost!)PDF transfer from browser to the server and vice versaAdditional application specific BAPI calls might take additional time

Performance recommendations on Web Performance recommendations on Web DynproDynpro Java application sideJava application side

Usage of Zero Client Installation (ZCI) is strongly recommended

Always use the latest ZCI script from Adobe inside the form.

User Interface Client TimeServer Time

Presenter

Presentation Notes

Usage of Zero Client Installation (ZCI) is strongly recommended: ZCI is the future of Interactive Form. ACF will become obsolete in future. Performance/flexibility is of course better with ZCI Always use the latest ZCI script from Adobe inside the form: From EhP1 onwards Automatic Script Injection is ON by default on the ADS. For older releases, application should do it manually with the migration tool provided. Adobe also recommends the same.


Adobe Interactive Forms Dos and Don’ts (2)

Performance recommendations on Web Performance recommendations on Web DynproDynpro Java application sideJava 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 Client TimeServer TimeCE 7.1

Presenter

Presentation Notes

Do not bind the pdfSource property until and unless the application needs the latest binary PDF available on the server. If the pdfSource property is not bound, XML is interchanged between the server and the client, always, which is much less expensive than binary PDF data transfer. Have a pre-created PDF and then use the same throughout the application session using usePdf mode. Alternative application logic: create PDF form for the first time and then use the same PDF form throughout the session.



2.1. Focus: User Interface2.2.2.2. Focus: Programming ModelFocus: Programming Model2.3. Focus: Controller Contexts2.4. Focus: Componentization2.5. Focus: Models2.6 Focus: New Ajax Functions


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 Dynpro’s caching mechanisms cannot speed up the rendering of view layouts!

Avoid repeated modification of view layouts when not necessaryIf 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 sClient TimeServer Time

Presenter

Presentation Notes

The wdDoModifyView() hook is designed for the creation of a UI tree or UI sub-tree at runtime in case it is not possible to declare the UI at design time. The method is neither intended for fine grain UI manipulations nor for context manipulations. Fine grained UI manipulations are achieve via means of data binding. Context manipulations are done in wdDoInit(), action event handlers or server side event handlers. Changing only one single attribute of a single UI element within wdDoModifyView() flags the complete view containing the control as dirty and the complete view must be completely re-rendered again – depending on the size and complexity of the view this can result in significant performance hits The hook method wdDoModifyView() should not be used for the following types of code: Altering UI property values – use context binding instead Changing the context in any way! Creating or changing modifiable simple types Storing UI element object references that you then attempt to access outside this method The properties of dynamically created UI elements should be controlled through context binding. Don’t store static references to UI elements in the View Controller Don’t attempt to refer to static UI element references in any event handler or supply function


Optimize Controller Lifespans How to Determine a View Controller‘s Lifespan

Optimize the view controller’s lifespanUse 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

Presenter

Presentation Notes

Web Dynpro's programming model brings views automatically into life when needed, e.g. when a navigation makes a certain view "visible" for the first time. It is important to understand that the visibility of views and the visibility of UI elements are defined slightly different. A view is called visible when it is part of the current view assembly, i.e. when it is either the current content of a visible (according to its own definition) window, or is the current content of a view container which in turn belongs to a currently visible view. The hierarchy of view inside view containers or windows that you define in the NetWeaver Developer Studio is a hierarchy of possibilities, so to speak. It defines possible and initial (default) embeddings. At runtime, every window and view container contains at most one current view. This is the hierarchy of facts, so to speak, that defines visibility in the above mentioned sense From the definition above, we know pretty good when a view is created. At that time, wdDoInit() is called and later wdDoModifyView() is called with firstTime == true. This allows an application programmer to bring the view into the desired initial state with respect to data and layout. The interesting question now is when will the view be destroyed? And the answer is, as usual, it depends. In this case it depends on the view's lifespan as defined at design time ("Properties" tab of the view). The possible values today are "framework controlled" and "when visible". It is the goal of this item to help you decide which of these values fits best your needs. A lifespan of "when visible" means that a view is destroyed as soon as it becomes invisible. Now what would be the consequences if a view, that has just become invisible temporarily, is destroyed and then created again? First of all, it takes additional time because wdDoInit() must run again. Given a well-written application, this should bring back the view into almost the correct state, because data should reside in component or custom controllers and programmatic layout modifications should be based an such data. But what is nearly inevitably lost is "view state", e.g. the first visible row of a table, the currently selected tab of a tab-strip etc. This can make a big difference to the end user, of course.


Correctly Initialize Component Controllers Use Additional Custom Controllers

Don’t 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 controller’s wdDoinit() method if the results of its execution are actually required at the start of the controller’s 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 controller’s 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

Presenter

Presentation Notes

Previous Slide Notes continued … Thus the default lifespan is "framework controlled" and means that the Web Dynpro runtime decides when a view should be destroyed. I.e. our framework reserves the right to do so at its own discretion. Of course, a view that is currently visible will not be destroyed. In practice, such a view currently lives as long as its component does. This allows views to become temporarily invisible without view state being lost and without additional overhead for initializing the view again. This should be the usual lifespan for ordinary views. Only if you want to improve memory performance, i.e. reduce the current memory usage of your component, and have already identified suitable views should you consider to declare those views' lifespans as "when visible". Good candidates are views that both require a lot of memory (for data and layout) and are (usually) used once and then not needed anymore. If you have e.g. an application that requires the user to create the header of a document before creating its items, you might have two views, one for the header and one for the items, that are shown one after the other. If the header view is sufficiently complex, it may be a good idea to make it live only when visible. In this way, memory is saved during the prolonged time that the user is creating items. In the rare case that she must return to the header (and your application supports that), the header view would be recreated.


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



2.1. Focus: User Interface2.2. Focus: Programming Model2.3.2.3. Focus: Controller ContextsFocus: Controller Contexts2.4. Focus: Componentization2.5. Focus: Models2.6 Focus: New Ajax Functions


Agenda

Controller Contexts


Minimize Generation of Typed Context APIs Avoid Context Mapping if not Needed

When declaring context nodes set property typedAccessRequiredtypedAccessRequired == false == 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.

Don’t “mirror” full controller context hierarchies in mapped controller contextsInstead, 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

Presenter

Presentation Notes

Whar are Typed Context Interfaces? Typed context APIs are context interfaces that are generated for the declared context nodes and attributes. For every declared context node <node name> a corresponding pair of typed context APIs, I<node name>Element and I<node name>Node, gets generated. Return types and parameter types of typed context API methods are not the generic Web Dynpro context APIs (IWDNode and IWDNodeElement), but the typed context APIs themselves. By setting the typedAccessRequired property to false, the Web Dynpro Java Generation Framework does not generate typed context interfaces for declared nodes and their elements. NOTE You do not have to declare mapped context elements when the target context belongs to the same Web Dynpro component and when it is used for other purposes than data binding, filtering or having an un-mapped lead selection. Instead, you can also access the typed context APIs of the used controller directly with wdThis.wdGet<used controller name>Controller().wdGetContext() method.


Don‘t Declare Context Model Nodes and Attri- butes 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.


Presenter

Presentation Notes

Q: What is the content of "Perm Space"?�A: Permanent Space is not apart of the Java heap. It contains metadata and byte compiled code for the classes already loaded, as well as JIT compiled code. In short: Perm Space = class information + hotspot compiled code. �Perm space is part of the consumed memory and in some VMs can not easily distinguished from heap memory. In some VMs like the SAP JVM the perm size can be configured and monitored separately.


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.


Presenter

Presentation Notes

Web Dynpro knows different techniques to share data (objects, values) across controller and component borders: context mapping between controller contexts of the same Web Dynpro component (External) Interface context mapping between controller contexts of different Web Dynpro components server-side eventing with event parameters inside a component or across component borders IPublic API method invocation between non-view controllers of the same component IExternal API method invocation between a controller of another component and the interface controller of the used component Navigation inbound and outbound plugs with defined plug parameters NOTE: When context attributes MUST be defined You must use the context to share objects between non-static event handlers and the static wdDoModifyView() hook method, even if these objects (context elements) are not used for data-binding. Do not declare static member variables for this purpose, as static members never store session-dependent objects on controller instance level but session-independent objects on controller class level.


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


Presenter

Presentation Notes

The singleton representation minimizes the resources needed as content is only maintained for the current lead selection of the parent and it allows for static binding as no node instance must be named, but only the "class" of the node. To model master-detail relationships within a controller context singleton child nodes (containing the detail node elements for a selected master node element) are mostly sufficient.


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 besimultaneously 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 non-singleton 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)

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


Presenter

Presentation Notes

Example Assume you are displaying a list of flights in a table and have a BAPI to retrieve flight details. Based on the validate-by-rendering technique, the BAPI is called only for those flights that are currently visible in the table by … Creating a non-singleton child node (with cardinality 1..1) of the tree's data source to hold the details for each flight. Using a supply function to retrieve the details for one flight via that BAPI.


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


calculated context attribute

non-singleton child node with cardinality 1..11..1

table‘s data node with cardinality 0..n

supply function is called for every validated (rendered/visible) non- singleton child node instance

Singleton property is set to falsefalse


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 consumptionNetWeaver 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 Return Type WDResourceFactory API Method

SAP NetWeaver 04 and 7.0

IWDResource 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 attribute’s 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.

Presenter

Presentation Notes

For more details see See WebLog “Uploading and Downloading Files in SAP NetWeaver 7.0” (https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/6603):� Tutorial: Uploading and Downloading Files in Web Dynpro Java - SAP NetWeaver 7.0 Article: Uploading and Downloading Files in Web Dynpro Tables - SAP NetWeaver 7.0 SDN Wiki Code Tutorial: Exporting Table Data Using On-Demand Streams - SAP NetWeaver 7.0 - https://wiki.sdn.sap.com/wiki/x/0mQ�



2.1. Focus: User Interface2.2. Focus: Programming Model2.3. Focus: Controller Contexts2.4.2.4. Focus: ComponentizationFocus: Componentization2.5. Focus: Models2.6 Focus: New Ajax Functions


Agenda

Componentization


Finding the Best Web Dynpro (Development) Component Granularity

Optimize the development performance with the best deployment granularityKeep 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 componentDon’t make Web Dynpro components too large

distributing work between several developers is harderreusability is very poor

But: Don’t make Web Dynpro components too smallthe application might not perform wellthe resulting „sea“ of components might reduce maintainabilityreuse level too smallhigher 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 projectonly doing a Deploy New archive and Run step for changed DCsadhering to the rule of splitting up models, dictionaries, Web Dynpro components and component interface definitions into separate Web Dynpro DCs


Development Development Component BuildComponent Build

Project BuildProject Build


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.1CE 7.1

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 componentsCentralize model access in a faceless model component and use this singleton model component in other components by applying the component usage referencing mode.

Apply Web Dynpro Development Component Separation Principles

Place Web Dynpro models, components, component interface definitions and Local Dictionaries in separate Web Dynpro DCsDistribute work between developers by assigning one DC to one developer.


Web Web DynproDynproDCDC

Web Web DynproDynproDCDC

Web Web DynproDynpro DCDC

Web Web DynproDynpro

DCDC

Web Web DynproDynpro DCDC


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, eventscomponent interface view: inbound plugs, outbound plugsused 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


Presenter

Presentation Notes

For more details on this topic, see the “Web Dynpro Component Interface Definitions in Practice” on SDN.


Optimize Component Lifecycle Management

Consider manual lifecycle management of Web Dynpro component instancesComponent Usage Lifecycle = Lifecycle = createOnDemandcreateOnDemand:

Web Dynpro Runtime automatically creates component instance on component interface view navigation, context mapping access or interface method invocationBUT: A used component gets only destroyed automatically with its parent component

Apply manualmanual 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

Presenter

Presentation Notes

Also Consider to Enter Component Usages in Referencing Mode In case you want to share a reusable Web Dynpro Helper Component across component borders you should not declare component usages with lifecycle „createOnDemand“ to this helper component in all „client“ components. With lifecycle „createOnDemand“ every client component would create its own instance of the helper component which might not be necessary in most cases and which causes an unnessecary memory overhead. Instead all client components should enter the same helper component usage instance in referencing mode at runtime. For this, they must first declare an own helper component usage of lifecyle type „manual“ at design time. The helper component usage (also lifecycle = manual) and the lifecycle of its associated helper comonent instance can be defined and managed by the root component. At runtime, the root component passes its helper component usage to all client components via component interface controller method invocation, so that these client components can enter the helper component usage in referencing mode. In this way, all client components use the same helper component instance at runtime.


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

Get first article for freeat SAP TechEd

Get first article for freeat SAP TechEd

Componentization

Go to the WIS/SAP Insert booth and drop off Your Go to the WIS/SAP Insert booth and drop off Your business card. They will send You the PDF of business card. They will send You the PDF of

the first article in the series the first article in the series for freefor free..

Presenter

Presentation Notes

SAP Professional Journal 2008 – Article Series “Leveraging component-based architecture in Web Dynpro for Java business applications” by Bertram Ganz (Senior Product Specialist, SAP AG) �and Richard Tucker (Principal Web Development Architect, Atos Origin UK) Part 1 — Design methodology, concepts, and case study (SPJ, May/June 2008) Part 2 — Component models (SPJ, July/August 2008) Part 3 — Componentization patterns in practice (SPJ, September/October 2008)



2.1. Focus: User Interface2.2. Focus: Programming Model2.3. Focus: Controller Contexts2.4. Focus: Componentization2.5.2.5. Focus: ModelsFocus: Models2.6 Focus: New Ajax Functions


Agenda

Focus: Models


Adaptive RFC Model Dos and Dont‘s

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

Don’t transfer table values as export or import parameters

Don’t embed tables within RFC import, export or table parameters

Don’t 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 Memory Server TimeTCD

Presenter

Presentation Notes

Don’t transfer table values as export or import parameters Design your RFCs so that all table values are transferred as table parameters and not within export-, import- or changing-parameters (the last ones should never be used at all). If possible use a length-limited datatype like char[10] instead of Xstring Don’t embed tables within RFC import, export or table parameters When doing this a performance critical overhead of XML metadata has to be �transferred. For avoiding this disadvantage complex structures in given RFCs parameters have to be flattened.


Adaptive RFC Model Dos and Dont‘s

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

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

Models Memory Server TimeTCD

TCDTCD

TCDTCD

Presenter

Presentation Notes

Put as many RFCs in a single Adaptive RFC model as possible A model represents a namespace, therefore, any commonly used datatypes or �structures can be shared only within a single model. Allows connection sharing between several RFCs in one model. With the reimport functionality existing models can be updated and further RFCs can be added.



2.1. Focus: User Interface2.2. Focus: Programming Model2.3. Focus: Controller Contexts2.4. Focus: Componentization2.5. Focus: Models2.62.6 Focus: New Ajax FunctionsFocus: New Ajax Functions


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 suggestion- enabled (suggestValues = true) Input Fields in the following case:

The InputField suggestion is based on the OVS valuehelp: see IWDOVSSuggester, IWDSuggestionListIn 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

Presenter

Presentation Notes

Suggestion and the 200 Values Size Limit There is NO increased number of server roundtrips when the InputField suggestion is based on … On-demand valuesets with less than200 values: see WDSimpleValueSupplier. �The valueset is retrieved once in a first roundtrip. The client then filters this valueset and suggest values without additional server roundtrips. Static valuesets defined in dictionary simple types with less than 200 values: �the client initially retrieves the complete valueset and then filters suggest values purely on client side.


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-parametersapsap--wdwd--disableAsyncInputValidationdisableAsyncInputValidation = X= X.

User level: configure this URL parameter sapsap--wdwd--disableAsyncInputValidationdisableAsyncInputValidation=X=Xfor 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.disableAsyncInputValidationsap.wd.disableAsyncInputValidation = true = 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 Client TimeCE 7.1 Server 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 Client TimeCE 7.1 Server Time




3. Special: Web Dynpro Java Table Paging 4. Performance Tools Overview5. Summary

Agenda


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 siderapid initial table display based on minimized number of records initially retrieved from the backendexact table page navigation based on reading scrolltipsin vertical table scrollbar

Technical SolutionImplement ICMIObservableList-API extending generic abstract base implementation class CMIAbstractObservableList.No supply function needed to populate the table’s 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.

For further details see SDN Wiki Page on

How to Implement Table Paging …

Table Paging Client TimeServer Time

CE 7.1CE 7.1

https://wiki.wdf.sap.corp/x/AAOtCw



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 Client TimeServer Time

https://wiki.wdf.sap.corp/x/hAOtCw



DEMOSee Table Paging Demo Application

Running on SAP NetWeaver CE 7.1 …




3. Special: Web Dynpro Table Paging 4. Performance Tools Overview5. Outlook 6. Summary

Agenda


Show „Stacked“ Performance Infos for ALL Roundtrips in Running Client Session

http://wdportal3:57200/webdynpro/dispatcher/sap.com/chess/Chess?sap-wd-lightspeed=no


Analyzing Web Dynpro Java Application Performance with a Simple URL-Parameter

Answer:Use URL parameter sapsap--wdwd--showInfoshowInfo=true =true (or =X=X) to display the performance breakdown between the client and the server in the browser status line (times in [ms]):

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.

Question:How to get a rough idea where time is spend in an application?

Part Parameter Description, times in [ms]

Browser Parsing Time for parsing HTML

JSBefore Time for processing JavaScript code before HTML rendering

Html Time for rendering HTML

JSAfter Time for processing JavaScript code after HTML rendering

J2EE Server side processing time

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

Back-End Time for accessing the backend (executing ARFC, ESF, AWS model classes)Not measured (0) when other models are used (JavaBean, EJB Model)

Size Estimated response size in kilobytes.

See SDN WebLog 5003

See SDN WebLog 5003

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/5003





Agenda


Main Objective: „Know to Tackle Web Dynpro Java Performance Gremlins as a Developer“

User Interface

Components

AjaxFunctionsProgramming

Model

Models

Contexts

WhereGremlins live …

WhoGremlins

are …

How Gremlins are tackled …


Now You know „How to tackle the Web Dynpro Java Performance Gremlins“

User Interface

AjaxFunctions

Components

ProgrammingModel

Models

Contexts

Apply ALL Web Dynpro Java Performance Rules

Apply ALL Web Dynpro Java Performance Rules

Know How Your Declarations

and Code Affect Memory, Client and Server Time

Know How Your Declarations

and Code Affect Memory, Client and Server Time

Apply Performance ToolsApply Performance Tools


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 updatesContinuous learning presentations and demos to build expertise in each of the SAP NetWeaver platform componentsA personal SAP namespace

SAP NetWeaver Content Subscription: (available globally)An online library of continuous learning content to help build skills.

Starter Kit

Building Your Business with SDN Subscriptions

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

Presenter

Presentation Notes

Unlike trial versions which expire after 90 days, requiring you to uninstall, reinstall, and re-configure. SDN Subscriptions provides developers uninterrupted access to an environment that they can personalize and completely control, saving them valuable time and increasing productivity through reduced downtime. Specific subscriptions include: SAP NetWeaver Development Subscription. Hands-on access and ownership to the complete SAP NetWeaver software platform. (available in Germany and U.S.) Low cost, access to the SAP NetWeaver platform with a one year, development and commercialization license Choice of development method with SAP NetWeaver ABAP, Java, and/or composite applications Continuous learning presentations and demos to build skills in each of the SAP NetWeaver platform components SAP NetWeaver Content Subscription. An online library of continuous learning content to help build skills. (available globally) SAP NetWeaver Composition Subscription. Uninterrupted, total control for creating, testing, and selling Java-based solutions that integrate with SAP applications. (available in Germany and U.S.) To learn more or to get your own SDN Subscription, visit SAP NetWeaver, Development Subscription, www.sdn.sap.com/irj/sdn/devsub SAP NetWeaver, Content Subscription, www.sdn.sap.com/irj/sdn/subscriptions/content SAP NetWeaver, Composition Subscription, www.sdn.sap.com/irj/sdn/subscriptions/composition Key Benefits include: Complete control Uninterrupted, hands-on access Latest NetWeaver software Continuous learning And Supporting services

http://www.sdn.sap.com/irj/sdn/subscriptions


Further Information

Related Workshops/Lectures at SAP TechEd 2008COMP165, Web Dynpro Java – Goals, Concepts, Benefits, 2 hour hands-onCOMP167, Web Dynpro Java for Beginners, 4 hour hands-onCOMP200, Web Dynpro Java: What’s 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, IntermediateUP360 Enhancing Performance of Web Applications Using Accelerated Application Delivery , 4 hour hands-on, AdvancedUP108 Accelerated Application Delivery: Enhancing the Performance of Web Applications , 1 hour lecture, Beginner

Related SAP Education and Certification Opportunitieshttp://www.sap.com/education/

SAP Public Web:SAP Developer Network (SDN): www.sdn.sap.comSAP NetWeaver UI https://www.sdn.sap.com/irj/sdn/nw-uiWeb Dynpro Java https://www.sdn.sap.com/irj/sdn/nw-wdjava

http://www.sap.com/education/

http://www.sdn.sap.com/

https://www.sdn.sap.com/irj/sdn/nw-ui

https://www.sdn.sap.com/irj/sdn/nw-wdjava


Thank you!


Please complete your session evaluation.Be courteous — deposit your trash,

and do not take the handouts for the following session.

Thank You !

Feedback

Best-Practices for Optimizing Web Dynpro Java Application Performance

Documents

asynchronous

detail model

web dynpro

component

processing

web dynpro

container

adaptive rfc