Web Dynpro - Terminology
Web Dynpro for ABAP
This is a short Glossary about Web Dynpro Terms. This is useful for people who are new to Web Dynpro Technology,the successor to Dynpro Technology.
Author: Fahad Javed
Created on : 22nd December 2011
Table of Contents
Web Dynpro Component
Central ,Re-usable and flexible code building blocks for developing complex web applications.
Naming Convention = ZWDC_<component_name>
Used For Interacting with External webdynpro components as well as internal components like methods,plugs and events,provided they have been flagged as "Interface". This applies to "Inbound Plugs" and "Outbound Plugs" of Window Controllers,"Events" and "Methods" of Component Controllers. In this way all of these could be accessed via the Interface Controller. These are used for Interacting with External components,like calling a shared method or attribute[provided they have been set as public].
Naming Convention = ZIWCI_<component_name>
(Automatically created by the Web Dynpro Framework)
Web Dynpro Application
This is the executable part of a web dynpro that points to the given Component in the form of a URI(Uniform Resource Identifier). It also allows you to pass certain application parameters that change the look and behavior of a Web Dynpro Application,accessed via the "Parameters" Tab.
Naming Convention = ZDWC_<component_name>_[ANW|APP]
It is the Visual Interface of a Web Dynpro Component. There is one-to-one relationship between a Window and an Interface View. Infact when a Window is created,the system automatically creates an Interface View in the Component Interface,allowing it to be accessible from external components. It exposes the Inbound and Outbound Plugs for which you have flagged the "Interface" Property. Methods and context Data of the Window are not accessible using the Interface View. Their is an Inbound Plug named "DEFAULT" of plug type "startup" already created. This plug is used for Launching a Web Dynpro Application.
Context is the Heirarchical Storage of Data at run time. Usually Nodes and Attributes defined here are data binded to different UI elements. All data that needs to be shown in the UI is catered through this using contextual Programming. Context can be found in Component,Interface,Custom,Configuration, View and Window Controllers. Root context attributes can be accessed via a standard attribute 'wd_context'[of type 'if_wd_context_node'] which refers to the context root node,a node that always appears before any custom context nodes or attributes are created,its fixed and it cannot be deleted,as it is part of the framework.
Nodes are the Parent containers that contain child elements like another Node or Attributes. Think of them as Branches of a Tree or a Table Like container.
Attributes are sub elements of a Context. They can be created either at the root node or within other Nodes. Data is held in attributes during run time. While creating an attribute,you need to assign them data types. These could be Data Elements,Standard ABAP Type or Webdynpro specific Data Types such as "WDY_BOOLEAN" which has a value of True or False. Attributes could be bound to the Properties of a UI Element,this way any changes made in the attribute will be reflected in the UI for example the "Visibility" property for showing or hiding a UI element. Please don't confuse Context based attributes with attributes,as they are just like properties that are held by a Class.
Views are the Displayable part of a Web Dynpro Component. They contain UI elements through which the User Interacts. They control the placement of UI elements,settings up properties of UI elements and for triggering events called 'Actions' .These must be embedded in a Window,to be displayed in a Web Browser via the relevant Web Dynpro Application.
Naming Convention = V_<View_Name>
UI Elements or Widgets
These are the Controls through which the user interacts within a Web Dynpro Application. Web Dynpro Framework contains a rich library of UI elements in different categories like Label and Text View UI elements in "text" category, Buttons and TimedTrigger UI elements in "action" category,Group and Tray UI Elements in the "layout" category and so on. Most of the UI elements have DATA bindable Properties like the "text" property of a Text View,Visual changes like the "visibility" property and Layout changes like the "cellDesign" property. Each UI Element also has events where you can plug in you code in the respective event handler methods. For Example the "onAction" event used in the Button control to invoke the click event.
All source code in the form of methods is stored in Controllers. Basically you control the flow logic of a web Dynpro component which involves Event Handling, Implementation and dispatchment of client side events in the form inbound plug method implementation and so on.
Types of Controllers:
01 - Component Controller
Represents the Global Point of Access within each Webdynpro Component.Each component contains exactly one Component Controller.They contain Constructor and Deconstructor methods that are created during the creation and deletion of a component.They are useful for cross communication and model binding.They can also be used together with contexts to act as a global data exchange interface between the windows and views of a component.The lifetime of the component controller equals the lifetime of the web dynpro component.Some of the Hook Methods associated with Component Controllers are:
> WDDOAPPLICATIONSTATECHANGE( )
> WDDOBEFORENAVIGATION( )
> WDDOPOSTPROCESSING( )
To access component controller methods and attributes directly within any controller,a standard attributed named 'wd_comp_controller' is available. This attribute is only available to controllers who have declared its usage.
02 - View Controller
They are only visible within their respective view and each view has its own controller.The Main task includes responding to actions triggered by the user,checking user entries for accuracy regarding firmly defined rules within the controller.Controlling the properties of UI elements contained in the View. You cannot assign a View Controller as a used controller. Some of the Hook methods associated with a View Controller are:
> WDDOBEFOREACTION( )
> WDDOAFTERACTION( )
> WDDOMODIFYVIEW( )
03 - Window Controller
They are visible within their respective Windows as well as in the views contained there in.Each Window has exactly one Window controller.When you start a Webdynpro application,the respective Window controller is addressed by inbound plugs defined within the window.Each Instance of a component can only use one window at a time.To enable views to access a Windows controller,the respective window must be explicitly made known to the views.It cannot be deleted explicitly.Some of the Hook methods associated with a Window Controller are:
> WDDOONOPEN( )
> WDDOONCLOSE( )
04 - Interface Controller
It publishes methods and actions of the component controller in the component interface. Therefore the methods of this controller must always be defined via the component controller because the interface controller is actually an interface rather than a controller.The respective methods becomes visible across different components if you set the “INTERFACE” flag in the component controller.
05 - Custom Controller
They provide the same features as the component controllers and thus specifically useful for exchanging data across views and windows, as well as for binding models.They are designed at design time and can encapsulate a subset of functionality for the Component controller.Many custom controllers can be defined in a webdynpro component. Since Custom Controllers are instantiated at run time ,and therefore it cannot be derived from any custom controller.Its instantiation is delayed until the first method of this controller is called. Its instance cannot be deleted explicitly.
06 - Configuration Controller
This is a special type of custom controller that is created when Personalization or special configuration is is required.Only one configuration controller may be created per webdynpro Component.Any controller can access the configuration controller but the configuration controller cannot access any other controller.This controller is instantiated as the first controller of the component. Its life span is as long as that of the component.
These are used for Managing Navigation between views by embedding them within itself. More than one window can be created for each Web Dynpro Component. You cannot navigate between Windows but you can pop open a window with an embedded view.
Naming Convention = W_<window_name>
It is a link used for Navigating from one view to another. This works by embedding both views in question in a Window. Then creating the Navigation Link from the Outbound Plug of one view to the Inbound Plug of another.
Triggers the Navigation Event. Also known as the exit point for the given view.
Naming Convention = TO_<Target_View>
Registers to the event dispatched by the Outbound Plug in the relevant Event Handler Method via the Navigation Link. Also known as the entry point for the given view.
Naming Convention = FROM_<Source_View>
Types of Plugs:
Each Inbound and Outbound plug is divided into the following types of plugs:
Types of Outbound Plugs:
They are used for View Navigation. Invokes the Inbound event handler method registered with the outbound Plug.
This a counter part of a Startup plug. Exit Plugs are used for exiting a webdynpro application or for exiting an application and launching another application by providing its URL.
This is a counter part of the Resume Plug. Suspend plugs are just like exit plugs,but their is one difference,they suspend the current application and launch a another application.They are used for complex,multicomponent scenarios.
Types of Inbound Plugs:
They are used for View Navigation. Invokes a Navigation Event,to be processed further by an Inbound Plug.
Startup Plugs are used for instancing a Component. By default an Inbound plug of type 'startup' is associated with window.
Once an application has been suspended and another application is launched and exited,resumption of the application which was suspended takes place using this plug. They are used for complex,multicomponent scenarios.
The mapping of a UI element's attribute to the view context attribute is known as data binding. Once binded it allows automated data transport between the context and the UI element and does not require any page refresh as changes are made in real time.
User enters in Data in the Input field whose "value" property is binded to a context attribute. any changes made in the Input field is also reflected in the context attribute.
Mapping of context from the mapping Origin node(origin of data context) to the mapped node(target node,usually a copy of the mapping origin node). This process only references the Original Context instead of creating a copy of that. This allows sharing of context data within the given component.
Mapping Origin Node
This is the Original(Source)Context Node from where the context node is to be shared via context mapping.
The node which is mapped from the Mapping Origin Node or which is referenced from the Mapping Origin Node.
Mapping done between contexts of a single component is called Internal Mapping.
Mapping done between 1 or more components via the Interface controller usually by first creating a Component Interface.
Context Root Node
Root node that is part of the Context and created by default automatically. It is the top most Node after which you create your own custom Nodes. This node cannot be deleted as it is part of the Web dynpro framework.
Standard Attribute = wd_Context[of Type IF_WD_CONTEXT_NODE][This Standard attribute is used for Accessing the Nodes and Attributes of the given context root node]
All the child entities of a node are aggregated into a unit called element. Think of it as a record in an internal table.
One set of a Node and its corresponding children[attributes] collectively form a collection.Each Context Root Node can have more than one Node collections. Think of a node collection as contents of an entire internal table.
Singleton Property[Needs Revision]
Controls the Parent child relationship between a Node and its elements. Each parent can create one instance of a child element. This is especially true in nested Context Nodes. If it is set to 'false',the root context node[parent context Node] in a nested scenario will always create a new subnode context node element for each parent context node,provided the cardinality for each of these has been set to either '1..n' or '0..n'. For example:
It is a method attached to a context node and is executed each time it is accessed. It is useful for populating it with initial data when no node attributes are populated at runtime. This is especially useful if you have added and then removed all Context elements at runtime,this could lead to a runtime error for an initial context node,but could be avoided using a supply function to provide an initial element.when the context node is at the initial state it,It re-calculates any changes to the data of child nodes. This is especially useful for single ton nodes,where the each time there is a change in the lead selection,the node's children get updated.
Lazy Data Instantiation
It is the Creation of data when it is needed. In case of context nodes, dependent collections are not automatically created for all elements of the parent node. Thus the creation of the collection of the dependent node is delayed to the point when the related element of the parent collection gets the lead selection.
Root UI Element
It is automatically created for each view and represent the root UI Element. It is a Transparent container. You cannot delete this UI element,as it is created by the Web Dynpro framework. All UI elements are added right after that.
These are standard methods which are part of the Web Dynpro framework.They enable you to interfere with the program flow at a particular point in time by adding in your custom code. Some hook methods include : WDDOINIT, WDDOEXIT, WDDOMODIFYVIEW, just to name a few. These are very similar in vein to ABAP Reporting events like START-OF-SELECTION, END-OF-SELECTION,INITIALIZATION.
Actions represent UI element events,that trigger UI Interactions. For example,"onAction" event for the button click or "onEnter" event for the Input field,when the user presses the "Enter" key in the field. An event handler method is created,which is executed when ever that action is performed. These Actions can be created for any of the UI elements that are part of the web dynpro framework,Just look out for the "Events" section in the Properties tab of the respective UI. Secondly,these can also be created from the "Actions" tab of the view controller. An event handler method for each action is automatically created that follows the following naming convention "onaction<actionname>". For example if the action name is "Dispatch_popup_message" then the event handler method for such an action would be "onactionDispatch_popup_message( )".
They can be created in any of the controllers. Once triggered,they can be invoked by firing them. You must register an event handler method with the event,so that it is executed each time the given event is triggered.
It is the sequence in which Hook Methods are executed as provided by the Web Dynpro framework.
For Further Reading: Phase Model
Previously it was a practice to create a special component which would work as a Model,but this approach was not useful as it had a bearing on the Performance of the Application. The best approach is to a create a Model as an Assistance Class. This improves performance and is best to create all you business logic there in the form of attributes and methods. It is recommended to base this class as a super class of "CL_WD_COMPONENT_ASSISTANCE",as it adds extra functionality of creating and accessing Text Symbols within the class.
Standard Attribute = wd_assist[Type <Assistance_class_name>][This Standard attribute is used for Accessing the Methods and Attributes of the given Assistance Class]
Cardinality is a Node specific feature and it dictates how many instances of child elements of a node be instantiated. Every context node has property called “cardinality”,it defines the minimum and maximum number of elements a node collection may hold.
For Example:"1..1" cardinality is used for a single Input field and "0..n" cardinality is used for multiple entries in a Table.
Selection property can be maintained for each context node. Here you can choose the same options that you can for cardinality.It indicates how many elements of a context node can be selected at runtime. This property is thus important for displaying tables.
Within each node,a single element can contain the LEAD SELECTION.For Example: The lead selection determines from which of the existing context elements the UI Element properties bound to node attributes will be read.
> The “DropDownByIndex” UI element represents a useful representation of this concept.
Allows you to update certain portions of a Web Dynpro application,in case of any modification in that portion. For Example:change in visibility of a button UI Element.Leads to better performance on server runtime,rendering time and Network Load.It is based on Views. The rendering engine of the server analyzes dirty flags[See Dirty Flag] of all visible views and generates a delta file for the browser from the smallest common set of UI's of dirty views,provided that Delta Rendering has been switched on.
Each view has what is called a Dirty flag. If during a server round trip,a visual change is made to a view,for example : a Button UI element is hidden,the system flags the entire view as dirty
Light Speed Rendering
This is a tool available while creating a Web Dynpro Component from where you can create and change Context Nodes and Attributes.
This is done by developers by creating configuration data sets,which contain values for view element properties,context attributes or both,after that you need to create an Application Configuration and assigning that to a Web Dynpro Application.These enable developers to override the values Of UI element properties via data binding,allowing you to change the appearance of the UI without modifying the implementation. This type of configuration is called "Implicit Configuration". Apart from this there is another approach for configuration based on a Configuration Controller called "Explicit Configuration".
These are settings for a specific user group in a particular client.It is controlled and regulated by Authorizations. Customizing settings can also be transported.
Individual Users can make Individual settings by right clicking on any of the UI elements. Some Personalization settings include for example : "Hide Button" for the Button UI element and "Use Current Value as Default" for the Input Field UI element.
Introduced in SAP Netweaver 7.0.This new kind of Extension concept is a technology for modifying,extending, and reusing development objects. These Enhancements are carried out via the Enhancement Builder. Such enhancements are called "Implicit Enhancements". "Explicit Enhancements" are not yet available for Web Dynpro,but they are carried out in other development Objects via BADI's. Enhancement concept was brought about by SAP to save costs on Upgrading an entire SAP system for example from 4.6 to ECC 6.0 and since it runs on its own layer,it does not interfere with the existing SAP software . These are encapsulated in what are called "Enhancement Packages" and are released after every year with newly added functionality.
Web Dynpro Framework
It is a framework that consists of classes and interfaces. Each UI control in Web Dynpro is available as a Class in the framework. Apart from the availability of ABAP and Dictionary Data types,there are certain datatypes that are only available in Web Dynpro's for example : "WDY_BOOLEAN" which a boolean data type with possible values of "true" and "false". Web Dynpro frame thus provides a complete framework in the form of tools and API for developing complex Web Dynpro Applications.
Development Objects modified in Enhancement Builder can be managed in Switch Framework.This framework enables you to group together your changes to individual development Objects in switches and in what are known as “business function sets”. The switches and the enhancements they contain can then be activated and de-activated in any way you like in the Switch Framework.
A Switch is an entity which controls whether to make an enhancement(be it visibility of maintenance view fields,Screen fields) assigned to it is in active or in-active state. A switch usually has three states "ON","OFF" and "STANDBY".
It is a building block of Business Function set,which represents a self contained function that can be switched on. Only reversible business functions can be switched off. There are three types of business functions:
01 - Industry Business Function
02 - Enterprise Business Function
03 - Enterprise Add-Ons
Business Function Sets
Used for bundling multiple Business Functions from different Industrial Solutions to provide an Industrial Solution. Multiple Business Sets can be nested together. You can thus switch on and off a business functions in a Business Function set.
Can be made at any point in the development Object using the Enhancement Builder. Such enhancements could include the creation of new UI elements in an existing view,creation of new attributes and nodes or overwriting an existing method e.t.c..Switch framework can be utilized for Implicit Enhancements.
You can write in you own code before a method of an existing standard web dynpro component method.
You can write in you own code after a method of an existing standard web dynpro component method.
You can completely overwrite the existing method,by plugging in your own code here. This disables the existing code in the entire method and calls in your code.
These can be carried out via a BADI's(Business ADd Ins). These can be made at points defined in advance by the application developer only. These are not yet available for Web Dynpros.
These are Object Oriented Development Objects used for Enhancing existing Standard SAP Applications.SAP allows you to predefine these points in your software.
Components that have no Graphical Presence i.e. they don't have views and windows for navigation between views are called Faceless Components. In the early days of Web Dynpro,such components were used for sharing context data between multiple components. This activity is carried out more gracefully using Assistant Classes.
This is the first component that is called in a Web Dynpro Application.
You can embed multiple views in a Window. A set of views visible at one time within a window is called a 'View Assembly'. These multiple views can be displayed within the root view,by making use of the 'ViewContainer' UI element that allows you to use multiple views within the same view.
Firing an Oubound Plug triggers a Navigation Event. These events are special asynchronous events that are placed in a Navigation Que. The Navigation Que is processed at a certain point in time within the Phase Model[See Phase Model] of the Webdynpro Applications at runtime. The event handler methods triggered by Inbound Plugs are processed when the Navigation Que is processed.
Fahad Javed's Copyrights
All Screen Shots taken,Fahad Javed's Logo are copyrights © 2010-2013 Fahad Javed. All rights reserved.
All the material written is a labour of hardwork carried out by the author. Kindly don't copy this material for commercial purposes. If a link is provided do provide the accredition to the author as follows:'All Screen Shots taken,Fahad Javed's Logo are copyrights © 2010-2013 Fahad Javed. All rights reserved.'.
All the terms used are copyrights of SAP AG © 2012 SAP AG. All rights reserved. See the section 'SAP - Copyrights and Trademarks' for further details.
SAP - Copyrights and Trademarks
© 2013 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Excel, Outlook, PowerPoint, Silverlight, and Visual Studio are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, z10, z/VM, z/OS, OS/390, zEnterprise, PowerVM, Power Architecture, Power Systems, POWER7, POWER6+, POWER6, POWER, PowerHA, pureScale, PowerPC, BladeCenter, System Storage, Storwize, XIV, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, AIX, Intelligent Miner, WebSphere, Tivoli, Informix, and Smarter Planet are trademarks or registered trademarks of IBM Corporation.
Linux is the registered trademark of Linus Torvalds in the United States and other countries.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are trademarks or registered trademarks of Adobe Systems Incorporated in the United States and other countries.
Oracle and Java are registered trademarks of Oracle and its affiliates.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems Inc.
HTML, XML, XHTML, and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.
Apple, App Store, iBooks, iPad, iPhone, iPhoto, iPod, iTunes, Multi-Touch, Objective-C, Retina, Safari, Siri, and Xcode are trademarks or registered trademarks of Apple Inc.
IOS is a registered trademark of Cisco Systems Inc.
RIM, BlackBerry, BBM, BlackBerry Curve, BlackBerry Bold, BlackBerry Pearl, BlackBerry Torch, BlackBerry Storm, BlackBerry Storm2, BlackBerry PlayBook, and BlackBerry App World are trademarks or registered trademarks of Research in Motion Limited.
Google App Engine, Google Apps, Google Checkout, Google Data API, Google Maps, Google Mobile Ads, Google Mobile Updater, Google Mobile, Google Store, Google Sync, Google Updater, Google Voice, Google Mail, Gmail, YouTube, Dalvik and Android are trademarks or registered trademarks of Google Inc.
INTERMEC is a registered trademark of Intermec Technologies Corporation.
Wi-Fi is a registered trademark of Wi-Fi Alliance.
Bluetooth is a registered trademark of Bluetooth SIG Inc.
Motorola is a registered trademark of Motorola Trademark Holdings LLC.
Computop is a registered trademark of Computop Wirtschaftsinformatik GmbH.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.
Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects Software Ltd. Business Objects is an SAP company.
Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other Sybase products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Sybase Inc. Sybase is an SAP company.
Crossgate, m@gic EDDY, B2B 360°, and B2B 360° Services are registered trademarks of Crossgate AG in Germany and other countries. Crossgate is an SAP company.
All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.