Web(abap introduction)
0 likes976 views
This document provides an overview of Web Dynpro, which is SAP's technology for developing web-based user interfaces. It discusses the key concepts behind Web Dynpro such as its model-view-controller architecture, use of declarative programming and code generation. The document also describes the main components of a Web Dynpro application including windows, views, controllers and contexts, and how they work together through mechanisms like context mapping, data binding, and navigation plugs.
More Related Content
What's hot (20)
Viewers also liked (20)
Similar to Web(abap introduction) (20)
More from Kranthi Kumar (15)
Web(abap introduction)
- 2. 2 © SAP AG 2005, ABAP Web Dynpro Introduction to the Web Dynpro architecture Contents: Web Dynpro Introduction
- 3. 3 © SAP AG 2005, ABAP Web Dynpro After completing this lesson, you will understand: The basic concepts behind Web Dynpro The basic architecture of a Web Dynpro Component Web Dynpro Introduction: Objectives
- 4. 4 What is Web Dynpro? From a technological point of view, SAP’s Web Dynpro for Java and ABAP is a revolutionary step in the development of web-based user interfaces. It is completely unlike any design paradigm ever used by SAP before and represents a quantum leap in the development of web-based, ERP applications. What is the Design Philosophy Behind Web Dynpro? Web Dynpro applications are built using declarative programming techniques based on the Model View Controller (MVC) design paradigm. That is, you specify which user interface elements you wish to have on the client, and where those elements will get their data from. All the code to create the user interface is then generated automatically within a standard runtime framework. This relieves you from the repetitive coding tasks involved in writing HTML and then making it interactive with JavaScript. © SAP AG 2005, ABAP Web Dynpro What is Web Dynpro ? A Programming Model for User Interfaces Defines a standard structure for user interface applications Derived from the MVC (“model-view-controller”) design pattern A Set of Tools for User Interface Design Focus on graphical modelling Code is generated from meta-model declarations Integrated in SAP NetWeaver Developer Studio and the ABAP Workbench A Runtime Environment for Applications Framework running on SAP Web AS server offers common services A Technology for Software Modularization Components help structure applications and support pattern- based UIs
- 5. 5 Web Dynpro Main Benefits Web Dynpro’s main goal is to enable application developers to create powerful Web applications with a minimum of effort using descriptive tools in a structured design process. One guiding principle in the Web Dynpro philosophy is: the fewer lines of hand- written code there are in the UI, the better. Web Dynpro pursues this goal in two ways. Web Dynpro uses a declarative, language-neutral meta model for defining an user interface. From this abstract definition, The development environment generates the required Java/ABAP code. Hand-written code still has its place, but is confined to that required to manipulate the business data, not the user interface. Web Dynpro provides technical features such as support for internationalization, flicker-free interaction and a clean separation of the business logic and the user interface. This separation is achieved through a modified implementation of the Model-View-Controller (MVC) design paradigm. MVC was invented by Trygve Reenskaug in the late seventies and first implemented in the Smalltalk-80 language. Since the repetitive tasks of UI coding have been all but eliminated, the developer can focus their attention on the flow of business data through the application. Web Dynpro applications can run on a range of devices and on various types of network – an important feature for collaboration scenarios. © SAP AG 2005, ABAP Web Dynpro Web Dynpro Main Benefits Deliver an Enterprise Quality Web Development Environment minimize coding, maximize design separate layout and logic support arbitrary backend systems support reuse of components configuration of UI patterns support web services and data-binding Achieve Independence run on multiple platforms Improve User Experience through a "High Fidelity Web UI" browser based, zero footprint screen updates w/o page reloads client-side dynamics performance through caching 508 accessibility support Web Dynpro Metadata Web Dynpro Tools Web Dynpro Runtime JAVA ABAP Multi Channel Access
- 6. 6 Meta model Concept and Declarative Programming A Web Dynpro application is developed using a declarative programming approach. Within the ABAP Workbench there are special tools that allow you to build and abstract representation of your application in the form of a Web Dynpro meta model. The necessary source code is then generated automatically and conforms to a standard architecture known as the Web Dynpro Framework (WDF). The WDF allows each controller within a component to have a set of standard hook methods. It is within these hook methods that any required custom coding can be placed. In addition to the events provided by the WDF, you can also define your own events for a Web Dynpro application. All Web Dynpro applications are constructed from the same basic units. However, through the use of custom coding in the standard hook methods, the standard framework can be extended to supply any required business functionality. Not all implementation decisions need to be made at design time. It is perfectly possible to implement a Web Dynpro application in which the appearance of the user interface is decided at runtime. This allows a highly flexible application to be written without requiring the need to directly write any HTML or JavaScript. © SAP AG 2005, ABAP Web Dynpro Meta-model Declarations vs. Custom Coding Meta-model Declarations Guarantees common app. design Good for graphical tool support Screen Layout and Nesting Navigation and Error Handling Data Flow Componentization ... Custom Coding Guarantees universality Good for data-driven, dynamic apps Implementation of business rules Dynamic screen modifications Access to services (files etc.) Portal eventing ... Web Dynpro Tools Generated Code Generator Meta-data Compiler RunableApp Custom Code
- 7. 7 Application Scenarios with Web Dynpro A Web Dynpro Model Object can be supplied with information from the following types of backend systems: RFC Modules such as BAPI’s in an SAP ABAP backend system. This interface is provided by the Adaptive RFC Layer (aRFC). Enterprise JavaBeans (EJBs) which encapsulate application logic. Web Services © SAP AG 2005, ABAP Web Dynpro Application Scenarios with Web Dynpro JAVA Web Dynpro Runtime JAVA Web Dynpro Runtime Deployed Web Dynpro App Deployed Web Dynpro AppDeployed Web Dynpro App Deployed Web Dynpro App SAP Enterprise PortalSAP Enterprise Portal Web Dynpro Application Web Dynpro Application HTTP SAP NetWeaver Developer Studio SAP NetWeaver Developer Studio ABAP Web Dynpro Runtime ABAP Web Dynpro Runtime Web Dynpro App Web Dynpro AppWeb Dynpro App Web Dynpro App ABAP WorkbenchABAP Workbench Conversion of existing Dynpros Conversion of existing Dynpros J2EE Backend Server J2EE Backend Server Backend ApplicationBackend Application ABAP Backend Server ABAP Backend Server Web Service Provider Web Service Provider Web Service Web Service RMI SOAP RFC Business Data Business Data Business Data RFC enabled Function Modules EJB (e.a.)EJB (e.a.)
- 8. 8 © SAP AG 2005, ABAP Web Dynpro W e b D y n p r o C o m p o n e n t Window View Controller View Web Dynpro Component Main Web Dynpro Component parts Windows Views UI elements Layout Controller Context … Component Controllers Context … Label Component Controller View Controller View Context Context Context
- 9. 9 © SAP AG 2005, ABAP Web Dynpro W e b D y n p r o C o m p o n e n t Window View ControllerView Context and Data Transport Label Component Controller View ControllerView Context Node 1 Root Node Context Root Node Node 1 Node 3 Node 2 Context Node 3 Root Node Context Like a data container which holds the data The data transport between the controller can be established with mapping definition
- 10. 10 Context Mapping Context mapping allows a context node in one controller to be supplied automatically with data from a corresponding context node in another controller. This is the primary mechanism for sharing data between controllers. Mapping Terminology When two controllers within the same component share data through a mapping relationship, this is known as “Internal Mapping”. The context node that acts as the data source is known as the “Mapping Origin Node”, and the context node that is mapped is known as the “Mapped Node”. There is also a type of mapping known as “External Mapping”, but this will not be dealt with in this chapter. Prerequisites In order for a mapping relationship to be established, the following steps must first be performed: A node must exist in the context of the controller acting as the mapping origin. This node need not have any declared child nodes or attributes. The mapping origin controller must be a custom controller. The controller containing the mapped node must declare the use of the mapping origin controller as a required controller. © SAP AG 2005, ABAP Web Dynpro Context Mapping W e b D y n p r o C o m p o n e n t View Controller Component Controller Mapping Relationship Mapped node collection Node collection of mapping origin Controller Usage Declaration Context Root FLIGHTS BOOKINGS BOOKID CUSTID CLASS PASSN PRICE CARRID CONNID FLDATE Context Root FLIGHTS BOOKINGS BOOKID CUSTID CLASS PASSN PRICE CARRID CONNID FLDATE
- 11. 11 Data Binding Data binding is the means by which data is automatically transported from a view controller’s context to a UI element in its layout. You may not bind UI elements to context nodes or attributes that occur in some other controller. UI elements are private to the view controller within which they are declared. The data binding process decouples the UI element object from the application code within the view controller. Therefore, in order to manipulate UI element properties, the application code in the view controller needs only manipulate the values of context nodes and attributes to which the UI elements are bound. The Web Dynpro Framework then manages the following two tasks: The transport of data from the context to the UI element during the screen rendering process. Repopulating the context from the UI element after data is entered by the user. © SAP AG 2005, ABAP Web Dynpro W e b D y n p r o C o m p o n e n t View Putting data on the screen: Data Binding Component controller context View controller context Context mappingData Binding View layout Root Node FLIGHTS BOOKINGS BOOKID CUSTID CLASS PASSN PRICE CARRID CONNID FLDATE Root Node FLIGHTS BOOKINGS BOOKID CUSTID CLASS PASSN PRICE CARRID CONNID FLDATE
- 12. 12 Outbound Plugs Calling an outbound plug method causes a navigation event to be raised. Navigation events are special, asynchronous events that are placed into a navigation queue. Only when all the outbound plugs have been called by all the views in the current view assembly, will the Web Dynpro Framework enter its navigation processing phase. Outbound plugs should be named according to the action that caused navigation away from the current view. Inbound Plugs Inbound plugs are special event handler methods that subscribe to navigation events raised when outbound plugs are fired. Inbound plug methods are called only when the navigation queue is processed. This will only take place once all the views in the current view assembly have fired their outbound plugs and no validation errors have occurred that would cause navigation to be cancelled. Inbound plugs should be named according to the reason for which the view being displayed. Links Outbound and inbound plugs are joined together using navigation links. © SAP AG 2005, ABAP Web Dynpro Window Navigation between views To define the navigation between two views, you need to create exit and entry points for each view using outbound and inbound plugs. Only then you can specify the navigation flow using navigation links Outbound plug Navigation link Inbound plug Customer List Customer Search Out In
- 13. 13 Windows, View Sets and View Areas When you create a Window, you define three things: All the possible views that could exist in the component’s visual interface. The layout and position of those views within view sets and view areas The navigation links that exist between different views You can embed either a single view, or one or more view sets into a window. Each view set in turn is divided into view areas, each of which can have one or more views or view sets embedded within it. A view area can only display one view at a time. Navigation links must be defined between views in order for the contents of a view area to be replaced. View areas can be blanked out by creating an empty view whose inbound plug responds to an appropriate navigation event. © SAP AG 2005, ABAP Web Dynpro Window Windows, View Sets and View Areas View Set “Identify Customer“ View Set “Case Detail“ Empty EmptyCustomer List Product List Customer Search Customer Details Product Details Interaction Record Interaction History A window is the set of all possible views that can make up a visible screen A window can have zero or more view sets embedded within it. A view set is subdivided into several view areas each of which can possibly display one or more views. A view area can only display one view at a time.
- 14. 14 View Assembly Special asynchronous navigation events are the triggers that cause a view area to contain a particular view. For a given window definition in which multiple views are embedded into view areas, there could be many permutations of views visible. The permutation that is visible depends on which navigation links the user follows. The subset of views visible at anyone time is known as a “View Assembly”. © SAP AG 2005, ABAP Web Dynpro Window View Assembly View Set “Identify Customer“ Empty Customer Search The subset of views visible at any one time is known as a “View Assembly”. Navigation causes either specific views within a view area to be replaced, or can cause entire view sets within the window to be replaced. Empty
- 15. 15 View Assembly Special asynchronous navigation events are the triggers that cause a view area to contain a particular view. For a given window definition in which multiple views are embedded into view areas, there could be many permutations of views visible. The permutation that is visible depends on which navigation links the user follows. The subset of views visible at anyone time is known as a “View Assembly”. © SAP AG 2005, ABAP Web Dynpro Window View Assembly View Set “Identify Customer“ Empty Customer Search The subset of views visible at any one time is known as a “View Assembly”. Navigation causes either specific views within a view area to be replaced, or can cause entire view sets within the window to be replaced. EmptyCustomer List
- 16. 16 The architecture of a Web Dynpro Component can be divided into two parts – externally and internally visibility: The horizontal dotted line separates the entities that are visible from outside the component, from those that are only visible from within the component. A view consists of a view layout and the corresponding view controller. A view can contain navigation plugs, methods and a context. A window embeds one or more views and has a corresponding window controller. A window can contain navigation plugs, methods and a context. © SAP AG 2005, ABAP Web Dynpro Web Dynpro Component Architecture I Contains Externally Visible Internally Visible W e b D y n p r o C o m p o n e n t Contains Usage declarations Window Window Controller View Layout View Controller M M M Plugs Methods Context
- 17. 17 The component controller acts as a component wide controller. Notice that Web Dynpro Models stand outside the Component. Models are reusable across multiple components. © SAP AG 2005, ABAP Web Dynpro Web Dynpro Component Architecture II Business Logic (Models) Component Controller Model 1 Contains Externally Visible Internally Visible Usage declarations Usagedeclarations W e b D y n p r o C o m p o n e n t Contains Usage declarations Window Window Controller View Layout View Controller M M M M Plugs Methods Context
- 18. 18 Custom controller can act as a local controller for some views. This allows to reduce the content of the component controller by copulating sub functions. © SAP AG 2005, ABAP Web Dynpro Web Dynpro Component Architecture III Business Logic (Models) Component Controller Model 1 Model 2 Contains Externally Visible Internally Visible Usage declarations Usagedeclarations W e b D y n p r o C o m p o n e n t Custom Controller Contains Usage declarations Window Window Controller View Layout View Controller M M M M M Plugs Methods Context
- 19. 19 A Web Dynpro Component can declare the use of another Web Dynpro Component. A specific component usage is then created and the parent component accesses the functionality of the child component via its component interface controller. The only parts of a Web Dynpro Component that are visible to the outside world, are the interface controller and the interface view(s). All Web Dynpro components have only one Interface Controller. There is a one to one relationship between a Window and an Interface View. If the component has no views, then it will have no Windows, which in turn, means that it will not implement an interface view. Such components have no visual interface and are known as “faceless” components. © SAP AG 2005, ABAP Web Dynpro Web Dynpro Component Architecture IV Business Logic (Models) Component Controller Model 1 Model 2 Contains Externally Visible Internally Visible Usage declarations Usagedeclarations W e b D y n p r o C o m p o n e n t Components Custom Controller Contains Usage declarations Component Interface Interface Controller Interface view Window Window Controller View Layout View Controller M M M M M M Plugs Methods Context Interface view
- 20. 20 Web Dynpro Application A Web Dynpro Application is an entry point into a Web Dynpro Component and is the only Web Dynpro entity that can be addressed via a URL. There is often (but not always) a one to one relationship between an interface view and an application. In the same way that the functionality in an ABAP module pool can be accessed by defining multiple transaction codes, so the functionality of a single Web Dynpro component can be accessed by defining multiple applications. Application definition In order to define a Web Dynpro application, you must specify The component to be invoked. This component is then known as the “root” component, Which interface view of the root component will be used as the initial view assembly, Which inbound plug will act as the entry point for the nominated interface view (this inbound plug must have the Startup check box selected) © SAP AG 2005, ABAP Web Dynpro Web Dynpro Application An application is an entry point into a Web Dynpro component An application can be addressed via a URL Component Controller Externally Visible Internally Visible Components Component Interface Interface Controller Interface view Window Window Controller M M M Interface view Automatically created with an inbound plug of type startup called default. An application is a URL associated with this special inbound plug in the interface view.
- 21. 21 © SAP AG 2005, ABAP Web Dynpro You should now be able to understand: The basic concept behind Web Dynpro The basic architecture of a Web Dynpro Component Web Dynpro Introduction: Summary