Online SAP Webdynpro for ABAP Training | SAP Modules at Acutsoft
India:+91 (0)9848346149, USA: +1 973-619-0109, UK: +44 207-993-2319 Santosh@acutesoft.com
Select Page

SAP WEBDYNPRO

SAP WEBDYNPRO ABAP ONLINE TRAINING

SAP WEBDYNPRO ABAP ONLINE TRAINING IN INDIA, USA & UK

SAP WEBDYNPRO ABAP ONLINE TRAINING IN CANADA

SAP WEBDYNPRO ABAP ONLINE TRAINING IN AUSTRALIA

SAP WEBDYNPRO ABAP TRAINING

WebDynpro Framework / Architecture

Download [PDF]

  • WebDynpro Introduction

      WD4J Vs WD4A
      Component Architecture
      Component Entities
      Views / Windows / Interface Views / Component Controller / Application
      Relation b/w Component Entities
      Data Binding
      Plugs at View level and Plugs at Window Level
      Inbound Plugs / Outbound Plugs
      Navigation Link
      View Assembly / Nested Views / Navigation b/w views
      Default View in a Component
      Multiple windows
      Context Mapping
      Internal Context Mapping / External Context Mapping
      WebDynpro Application / Creation of Multiple Applications
  • Application Execution Cycle
  • URL Parameters
  • FQDN Settings
  • Faceless Components
  • Service maintenance
  • WebDynpro Controllers
      View controller
      Window Controller
      Component Controller
      Interface Controller
      Custom Controller
  • Services of each Controller Hook Methods and Attributes of each Controller
  • WebDynpro ABAP Tools
      Webdynpro Code Wizard and its different options
      Layout Editor
      Working with Layouts
  • Different layouts
      Flow Layout / Grid Layout / Matrix Layout / Row Layout
  • UI Elements
      Caption / Page Header / Input Fields / Text Views / Text Edit / Check box / Radio Buttons / Buttons / Button Rows / Image / Table / Message Area / Group / Transparent Container / Tray / View Container UI Element / List Box
      Drop down by Index / Drop down by key / Radio Button By Index / Radio ButtonByKey
  • Design Time Context
      Understanding the Meaning of Node and Element
      Working with multiple Nodes and/or Attributes
      Working with properties of Nodes and/or Attributes
  • Role of Data Binding
      Binding the UI elements to Nodes and/or Attributes
  • Kind of methods in Controllers
      Normal Methods
      Event Handler Methods
      Supply Functions
  • Working the Multiple Views
      Nested views ( View with in a View )
      Navigation b/w Views
      Creation of Plugs – Inbound and Outbound Plugs
      Creation of Navigation Link
      Firing the Outbound Plugs
      Significance of the Inbound Plug EventHandlerMethod
  • Managing View Lifetime
      When Visible
      Framework Controlled
  • Creation of MIME objects
  • Role and Significance of Properties of the Node
      Cardinality
      Selection
  • Table Control
      Multiple of creating a Table
      Working with different table column cells
      Single row Selection
      Multi row Selection
  • Dynamic Programming
      Managing the UI element properties in runtime
      Binding the internal table to the Node
      Creation of elements under a Node in runtime
      Removing the elements under a Node in runtime
  • Data Transfer Techniques b/w the Views Component Controller
      Significance of Component Controller
      Hook Methods and Attributes of Component Controller
      Context Mapping
      Used Controllers
  • Message Manager
      Generation of Messages
      Report Messages – Success / Warning / Error Messages
      Defining own Message Area
      Changing the message options in the WD application level
  • Implementing Service Call (BAPI / RFC Calls)
  • Calling the smart forms in a Applicatio
  • Implementing the Supply Function
  • Advanced Concepts in WebDynpro ABAP
      Window Controller
      Window Plugs
      Significance of DEFAULT Plug
      Inbound Plugs of Window Controller
      Start Up Plug / Standard Plug / Resume Plug
      Outbound Plugs of Window Controller
      Exit Plug / Standard Plug / Suspend
  • Custom Controller
      Creation of Custom Controller
      Working with Custom Controller
  • Popup Windows
      Popup Messages
      Data Sharing b/w views and popup windows
  • Internationalization
  • OTR – Online Text Repository
  • Concept of iViews and Integration into Portal (Theory
  • Portal Integration
  • WebDynpro Application Configuration
  • WebDynpro Application Personalization
  • WebDynpro Component Configuration
  • Tree Structure – Tree UI Element
  • Implementing RoadMap UI element with 3 to 4 steps
  • Role of Component Interface
  • Cross Component Programming
      Component Usage
      Sharing the Context across the components
      Sharing the Views or Visibility across the components
  • Implementing ALVs
      Implementing ALV without configuration Model In the ALV View In the Separate View
      Implementing ALV with Configuration Model In the ALV View In the Separate View
  • Editable ALVs
      Totals / Subtotals in ALVs

        ALV with different Cell Editors (Link to Action, Buttons, etc.., )
        ALV with different Events (Hotspot, OnClick, etc.)
        Working with Select Options
        Enhancements in WebDynpro Components — View / Context / Methods


SAP WEBDYNPRO ABAP

Web Dynpro is a client-independent programming model of the SAP NetWeaver technology platform for developing user interfaces for professional business applications. It is based on the model view controller paradim which ensures that the business logic is separated from the presentation logic. This architecture is visible in the Web Dynpro perspective of the SAP NetWeaver Developer Studio (NWDS).

Web Dynpro helps you with the development of Web applications by:

  • Ensuring platform-independence with the meta model approach
  • Minimizing the implementation effort through declarative programming
  • Supporting a structured design process by applying the model view controller paradigm
  • Providing reuse and better maintainability by using components
  • Providing graphical support with tools in the Web Dynpro perspective
  • Providing the SAP NetWeaver Java Development Infrastructure (NWDI) which supports team work with different services such as source code versioning and the Central Build Service.

Web Dynpro is the SAP development toolset for creating professional Web user interfaces (UI) for business applications. Web Dynpro Java applications are developed within the SAP NetWeaver Developer Studio using a model-driven approach that minimizes manual UI coding and uses visual tools to design and reuse components.

Web Dynpro is based on the powerful and flexible Model-View-Controller architecture that helps implement a clear separation of user interfaces from backend services.

webDynpro uses SAP’s own interpretation of the MVC concept. In order to achieve the best results from Web Dynpro, it is most important that understand the key concepts in Web Dynpro architecture.

If these concepts are not understood, then you may well be able to write a functional Web Dynpro application, but it will suffer from:

  • poor performance under heavy workload
  • increased time required to perform maintenance
  • unnecessarily complex business logic
  • if your application connects to a backend SAP system, then it is likely that more connections will be opened than are necessary, which in turn will create extra work load on your backend system.

A Programming Model for User Interfaces defines a standard structure for user interface applications and derived from the MVC (“model-view-controller”) design pattern

A Set of Tools for User Interface Design Focus on graphical modeling where Code is generated from meta-model declarations.

A Technology for Software Modularization with Components helps structure applications and support pattern based UIs.

Web Dynpro Advantages:

  • Deliver an Enterprise Quality Web Development Environment
  • Minimize coding, maximize design
  • Separate UI logic and business logic
  • Declarative UI development
  • Independent of client Technology
  • Browser, smart client, Mobile devices
  • Client technology independent meta data

DEMO VIDEOS

UPCOMING DEMOS

calls

WEBDYNPRO INTERVIEW QUESTIONS

  • Web Dynpro Applications are built on Which Programming Technique and What Pattern are followed?

      Web Dynpro framework uses declarative programming techniques to create a meta-model of the application which is free from back-end and front-end programming languages. Rather the metadata is programming language-neutral and has information stored in XML format. It’s only during run-time that the rendering engine generates the code in html and java script from this meta model of the application. So the design part – which defines the UI and data flow between UI elements – is completely abstracted minimizing the coding (which is required only for implementing business logic).
      The model-driven approach helps developer to focus less on coding and technology part and more on the design part of the application – “minimizing coding and maximizing design”. Naturally, the primary focus of business application developer should be the business logic and the technological implementation should not distract him.
      MVC pattern is followed in Webdynpro abap.
  • What is View Assembly?
      A window defines the superset of all possible views that a Web Dynpro application could require whilst running a particular component. The number of views visible at any one time however, will typically be only a subset of the number of views embedded within the window.
      The subset of views rendered at any one time is known as the View Assembly. User interaction followed by subsequent navigation processing will frequently cause this subset of views to change with every server round-trip. The view assembly represents those views seen by the user on their client device after the completion of a particular server round trip.
  • What is Face Less component?
      it is a component with zero views and zero windows. Such a component is known as a “faceless” component and is useful when a complex unit of functionality requiring no direct user interaction needs to be encapsulated. A good example of a faceless component is the creation of something called a model component. This is not actually a specific Web Dynpro component type; rather it is a standard Web Dynpro component that has been written specifically for the task of interacting with a model object.
  • What are the types of Controller? Describe?
      In broad terms, SAP has defined two categories of Web Dynpro controller. The difference between them is simply this: A controller either
      Has a visual interface, or
      Does not have a visual interface.
      SAP has introduced this difference in order to maintain a strict separation between those parts of the business application that display data (typically data consumers), and those parts of the business application that process data (typically data generators).
  • What are Recursion Nodes?
      The recursion node is a special type of node used when a node hierarchy with a recursive structure needs to be created. This is needed when, for instance, the depth of the node hierarchy is not known until runtime. Using a recursion node, you can declare that a particular node structure be replicated as a child of itself. A good example here is if your context needs to hold information in the same structure as a file system, containing directories and sub directories.
  • What is an Empty View?
      There is a special type of view known as the empty view. This view requires no manual implementation, neither is it possible to interact with it in any way other than invoking its default inbound plug – showEmptyView. If you require one particular area of a view set to be empty, then you should embed the empty view into the view area. You can then treat this view just like any other view you have written, except that calling its inbound plug will cause the corresponding view area to be blanked out. If a view set has had no views manually embedded into one of its view areas, then the empty view will be substituted automatically.
  • How does the Web Dynpro framework decide which particular views make up the current view assembly?
      When an application is executed for the first time, only those views which have their default flag set to true will belong to the first view assembly.
      Thereafter, user navigation will occur and the view assembly will be composed of those views that have been newly instantiated (on account of their inbound plugs being fired), and those views that persist from the previous view assembly (because no outbound navigation took place from them).
  • Define WebDynpro Controller.
      Controllers are the active parts of a Web Dynpro component. In the design of Web Dynpro controllers, SAP has made a significant modification to the original MVC concept of a controller.
  • Main advantages of the original MVC design?
      One of the main advantages of the original MVC design was its focus on the reusability of models, views, and controllers as individual coding units. However, Web Dynpro is focused on more than just the technical reuse of coding entities. Instead, Web Dynpro has been designed to be the foundation for implementing business solutions. Therefore, one of the key elements in its design was the need to provide a reusable unit of code that corresponded to an atomic step within a business process, rather than trying to build business solutions from reusable units of low level code that, in themselves, were not directly related to the business process.
      In other words, the Web Dynpro component is a reusable unit of code at the business process level, rather than the technical coding level. The resulting change in the nature of code reuse produces a shift in the developer’s focus of attention during coding. No longer are they concerned so much with the reuse of technical coding units; instead, the design of a Web Dynpro component focuses on the reuse of atomic units of business processing. A component can be thought of as a set of controllers, views, and model usage declarationsthat have been aggregated for the specific purpose of reuse.
  • If the view set concept is not implemented in Web Dynpro for ABAP, what options are there for reusing views?
      In both Web Dynpro for ABAP and Java, there is a specific UI Element called the ViewContainer. This UI element, when added to a view layout, acts as a container for any other view. ViewContainers can be arranged in large variety of ways in order to achieve the desired layout on the screen.
      The views that can be embedded into a ViewContainer UI element are the following:
      Any view from the current component
      Any visual interface from a child Web Dynpro component
      An empty view (supplied automatically by the Web Dynpro runtime)
  • What is a View Set?
      A view set is a visual framework that subdivides the window into predefined areas. Each subdivision of a view set is known as a view area, and multiple views can be embedded into a single View Area.
      The following preconfigured view sets are available:
      T layout T layout 90o T layout 180o T layout 270o Grid layout Tab strip
      Each subdivision within the view set layout is known as a view area.
  • How is model-driven architecture implemented in Web Dynpro framework?
      Web dynpro framework uses declarative programming techniques to create a meta-model of the application which is free from back-end and front-end programming languages. Rather the metadata is programming language-neutral and has information stored in XML format. It’s only during run-time that the rendering engine generates the code in html and java script from this meta model of the application. So the design part – which defines the UI and data flow between UI elements – is completely abstracted minimizing the coding (which is required only for implementing business logic).
      The model-driven approach helps developer to focus less on coding and technology part and more on the design part of the application – “minimizing coding and maximizing design”. Naturally, the primary focus of business application developer should be the business logic and the technological implementation should not distract him.
  • What is Meta Model Concept?
      Since SAP uses both ABAP and Java as languages for the delivery of its application software, any development framework used by SAP must be able to accommodate both the requirements and the idiosyncrasies of these languages. It made little sense to have one design methodology for ABAP based applications and another for Java; therefore, a common structural concept was developed to lie at the heart of all Web Dynpro development. This common structural foundation is known as the “Web Dynpro Metamodel”, and acts a language neutral specification for both the visual appearance and development structure of a Web Dynpro program.
      Since SAP uses both ABAP and Java as languages for the delivery of its application software, any development framework used by SAP must be able to accommodate both the requirements and the idiosyncrasies of these languages. It made little sense to have one design methodology for ABAP based applications and another for Java; therefore, a common structural concept was developed to lie at the heart of all Web Dynpro development. This common structural foundation is known as the “Web Dynpro Metamodel”, and acts a language neutral specification for both the visual appearance and development structure of aWeb Dynpro program.
  • What do you mean by Lifespan of a Web Dynpro Application?
      The lifespan of a Web Dynpro application is determined by, and equal to, the lifespan of the application’s root component.
      Lifespan of the application’s root component
      The component chosen to act as the application’s entry point is known as the root component. When a user invokes the associated URL, the WebDynpro framework creates an instance of the application’s root component. This component instance will persist until such time as the user formally terminates the application, or closes their client (e.g. the browser), enters a new URL, or remains inactive for the configured time out period.
      Lifespan of a child component
      Any Web Dynpro component may act as the child of any other Web Dynpro component. In such cases, the lifespan of the child component may either be controlled automatically by the Web Dynpro framework, or it may be controlled by coding written by the application developer in the parent component.
  • How can you determine Lifespan of custom controllers?
      The lifespan of a custom controller is determined by a parameter setting made during the design time declaration. It can be either “Framework Controlled” or “On demand”. If you choose “Framework Controlled”, then the Web Dynpro framework will instantiate the custom controller when the component is instantiated. If however, you choose “On demand”, then the Web Dynpro developer must write the coding necessary to instantiate the custom controller.
      Each child component usage is instantiated with a unique name that must be defined at design time. During the lifespan of the parent component, a child component may only ever be instantiated once under a given name; however, should it be necessary, you may declare multiple usages of the same child component as long as you specify different usage names.
  • Why would a component need multiple windows?
      A good example of where a Web Dynpro component would need multiple windows is where a single business application needs to be accessible on variety of client devices. For example, a particular application needs to be written that can be executed from both desktop based browsers and handheld devices.
      In order to avoid having to write the same business logic twice, you can write a single Web Dynpro component but within it, you define two sets of views. The first set of views has been laid out with a desktop browser in mind (I.E. there will be a lower number of views because a larger quantity of data can be presented on each view).
      The second set of views however, is laid out with a handheld device in mind (I.E. the restricted space on the handheld device will mean that more views will be needed in order to present the same quantity of information).
      The two sets of views are then grouped together into different windows; one for the desktop based browser, and the other for the handheld device. Couple this design together with the principle that view controllers are not responsible for generating the data they display, and you should quickly be able to see that all the business logic need only be written once and placed within the component controller and custom controllers. The view controllers then simply display (consume) the data supplied to them by the non-visual controllers.
      The last step is to define two different Web Dynpro applications. Both applications will use the same Web Dynpro component, but since two windows have been defined, there will be two Interface view controllers – one for each window. These interface view controllers are then used to define the visual interface of each application.
      A second example for a component with more than one window is the use of popup windows. A popup window will always be implemented by a separate window which may be defined in the same component, but processed as an independent window.
  • Explain the Concept of Lazy Data Access.
      The Web Dynpro framework has been built to follow the principle of Lazy Data Access. This means that the processing required to generate data will not be invoked until the data is actually needed. When this principle is applied to the architecture of the context, it means that unless there is an attempt to access the data in a singleton child node, then even though the lead selection in the parent node has changed, the child node’s supply function will not be called.
  • Before a mapping relationship can be established, what criteria must be met?
      There must be a suitable node available to act as a mapping origin