Instruction manuals

1 WebDynpro Overview

WebDynpro Overview
of 6
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  Abstract SAP Web Dynpro is a framework for developing user interfaces for use with the SAP NetWeaver platform. It comes with design tools that are part of the NetWeaver developer studio, enabling developers to do most of the  programming in a graphical or declarative manner. Web Dynpro applications can run on different  platforms, including Java, ABAP, and .NET. Component-orientation supports reusability of user interfaces. The concepts covered in this article allow a separation of layout and logics, and ease the integration of different backends. Using contexts and models, data may be synchronized automatically between the user interface and the backend. Besides discussion of basic concepts and a glance at the development process, this article briefly illustrates the client-driven execution of a Web Dynpro application. Keywords:  Web Dynpro, NetWeaver, User Interfaces 1.   Introduction 1.1.    What is Web Dynpro? Web Dynpro is a framework for development of user interfaces (UIs) for use with SAP NetWeaver. It supports programming for different platforms, including Java, ABAP, and .NET. For Java programming, Web Dynpro comes with extensive design tools, which are based upon the Eclipse framework and part of SAP’s NetWeaver Developer Studio. The product name has a historical background: SAP’s legacy product lines, starting from the R/2 system, include a technology for interactive UIs called Dynpro, an abbreviation for “dynamic program”. Dynpro UIs are described in the ABAP programming language and rendered in a proprietary frontend application called SAP GUI. In contrast, Web Dynpro UIs can be rendered in non-proprietary, ubiquitous frontends, particularly web browsers, employing dynamic web technology like JavaScript. Thus, Web Dynpro is aimed to combine “high interactivity” (i.e. a dynamic UI) with “zero installation” (i.e. an ubiquitous UI). [2] 1.2.   Objectives and approaches The Web Dynpro framework has been developed to achieve some characteristic design goals, so there is a bunch of technical approaches that directly address those design goals. [2] First of all, developers should be able to build as much as possible without procedural programming, according to the slogan “minimize coding, maximize design” . The NetWeaver Developer Studio offers facilities for graphical and declarative programming here, where much of the code is generated. Another objective affecting the development process is separation of layout and logics . This is achieved through the “view” and “controller” concepts: views can be equipped with controls and navigation plugs independently of actual data bindings and event handlers, which are put into a view controller. In order to support arbitrary backends , Web Dynpro uses so-called models as an interface to the functionality of backends. Currently, models for JavaBeans, ABAP, and Web Services are supported. Applications should  run on multiple platforms , in terms of the program processor at the presentation server side. Java, ABAP, and .NET are suitable runtime environments at present. Web Dynpro is aimed to be a “high fidelity web UI” , which comprises flexible client-side solutions as well as accessibility features and internationalization. Basically, there are three SAP Web Dynpro Overview Andreas Fahle Seminar System Modeling 2005 Hasso-Plattner-Institute for Software Systems Engineering  types of client platforms: ã    JavaScript-capable web browsers (up from Internet Explorer 5.5 or Mozilla 1.7), ã   mobile devices (PocketPC, Blackberry), ã   the Web Dynpro Client for Windows, which can be regarded as the successor of the SAP GUI application. [4] In addition to client-side rendering using  JavaScript, other rendering modes are under consideration, such as static HTML assembled by the server. [2] The remainder of this article will focus upon  Java development and rendering using  JavaScript-capable web browsers. However, the basic concepts discussed in section 2 hold true for other use cases as well. Diagrams use FMC notation (see [8]). 2.   Basic concepts 2.1.   An example The basic concepts of Web Dynpro are now explained using the example in Figure 1. A form for editing employee base data (like name, date of birth and so on) should be realized as a Web Dynpro application. Note that is a simple example: it comes with only one view and no further controllers beyond the view controller and the component controller. Furthermore, it uses no complex data types, i.e. only strings are mapped between contexts. 2.1.1.   View A view  describes a visible screen area, which contains and lays out controls  (also called UI elements or widgets). In the example, a view called “EmployeeForm” contains controls of type text field for displaying and entering information such as the “name” of an employee.  Actions  are defined for designated user input (i.e. entering text, or pressing a button), they may trigger event handling. Views can be arranged to complex screen layouts using view areas , view sets  and windows , and navigation plugs  may be added to a view for switching between views. Both is beyond the scope of this article. 2.1.2.   Controller For realization of dynamics, controllers  are required. Every view has a dedicated view controller  , and every component has a component controller  . Custom controllers  may be added for further structuring of the system. A view controller performs event handling based of the actions invoked in the view. For example, the view controller of “EmployeeForm” may react on pressing a button by updating data (see section 2.1.6) or switching to another view. Besides event handling (which is described in event handler methods), controllers may perform other activity described in methods. 2.1.3.   Model A model  describes data in the backend, for example using JavaBeans. Those data are componentEmployeeBaseDataEditor modelHuman Ressourcesmodel classEmployeeview controller of EmployeeFormcontextcomponentcontroller viewEmployeeFormcontrol name text fieldcontrol propertytextcontrol propertycontrolcontext elementemployee/namecontextcontext elementemployee/namecontext elementcontext elementmodel property name attributemodel propertyto thebackend model manager Figure 1 Simple example    provided through model classes which comprise model properties. In the example, the Web Dynpro component uses a model called “Human Ressources”. Inside this model, the “Employee” model class contains an employee’s data, in particular the “name” attribute as a model property. Models may also contain “executable” model classes, which can be “called”. These are not covered in this article. It should be noted that the classic  Model-View-Controller   pattern (MVC) is not  apparent in Web Dynpro—although the same wording is used and although this is claimed in various publications. In classic MVC, a view gets updates directly from the model ([7], i.e. without indirection via a controller), which is not true for Web Dynpro. 2.1.4.   Component A reusable, encapsulated part of the system (and the describing software package) is called a component . In most cases, a component contains several views and controllers (in fact, a component controller is always present), and uses one or more models. In the example, the component is called “EmployeeBaseDataEditor”. Components are able to communicate with other components via component interfaces . 2.1.5.   Application An application , which is not embodied in Figure 1, serves as the entry point for users in terms of “something runnable” from the frontend. It is identified by a uniform resource locator (URL). Running an application means 1.   starting a designated component, and 2.   navigating to an initial view, which in turn is displayed in an initial window. 2.1.6.   Context All data processing in a Web Dynpro application is done via contexts . Each controller has a context, which represents a hierarchical data “model” 1  as depicted in Figure 2, where leaf nodes are typed using Java native types (e.g. String as in the example) or Java dictionary types. Typically, a view controller’s context keeps the 1  “Model” means a structure of metadata (i.e. types and their relationships) here. The quotation marks are used to distinguish this term from a “WebDynpro model” as introduced in section 2.1.3. “model” of the data to be presented in controls of the view, and a binding exists between these context elements and control properties. Then, a component controller’s context keeps the “model” of all data required in the component, and these context elements are bound to a model. Moreover, context elements may be mapped across contexts. According to context mappings, data changes are synchronized between controls and models, so one may have the idea of only one location for the data. In Figure 1, this is illustrated by the long rounded node for the employee’s name, which comprises the corresponding control property, context elements, and model property. 2.2.   Meta-model In Figure 3, all the concepts introduced so far are put together to form a meta-model. The entity types and relationships concerning screen layout and navigation are grayed out since they are not covered in this article. As Figure 3 depicts, a component consists of views and controllers, may use models, and is started by an application. Controllers are partitioned into view controllers, component controllers, and custom controllers, whereas there is exactly one component controller, and one view controller per view. A view consists of controls, which have control properties. As well, a model consists of model classes, which have model properties. A context is part of each controller and consists of context elements. To simplify matters, context elements are not partitioned into non-leaf and leaf elements in Figure 3, so it is true that context elements may be bound to both model classes and model properties. On the other hand, context elements may be bound to control properties, and can be mapped to context elements in other contexts. Figure 2 A context    3.   Development process As mentioned before, the NetWeaver Developer Studio provides tools to create Web Dynpro applications in a graphical or declarative manner. Usually, this includes all the layout and navigation, as well as context data and model binding. These pieces of system description are known as Web Dynpro metadata, for which the corresponding Java code is generated automatically. In addition, programmers may alter the generated code in order to add event handlers or additional methods (see Figure 4). [5] The Web Dynpro tools require custom code to be restricted to designated regions, which are marked with special comments. In the following code, only the blocks between the //@@begin  and //@@end  markers may be edited and would be preserved during code re-generation: //@@begin javadoc:onActionBack(ServerEvent) /** Declared validating event handler. */ //@@end  public void   onActionBack( <...> IWDCustomEvent wdEvent ) { //@@begin onActionBack(ServerEvent) wdThis.wdFirePlugToStartView(); //@@end } Writing a Web Dynpro application typically includes some common steps as listed in Table 1. For each step, the table states if graphical, declarative, or procedural programming is appropriate. navigationlinkviewpluginbound plugoutbound plugcontrolcontroller view controller component controller custom controller contextcomponentcontextelementmapmodelclassmodelapplicationstartuseconsist of consist of bindbindwindownavigationscreen layouthavehavemodelpropertycontrolproperty havehave Figure 3 Meta-model   Web Dynpro Toolsdeveloper Editor Generator Web DynproMetadataJava Code R Figure 4 Development process  
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks