!--a11y-->
Modeling Web Dynpro Projects 
A Web Dynpro project combines all Web Dynpro development objects. The Web Dynpro project consists of Web Dynpro components, Web Dynpro component interfaces, models, is used to organize files and packages and to maintain Java Dictionary entries, settings and properties for Web Dynpro applications. In the documentation on the J2EE Technologies in the SAP Web Application Server, the Developer’s Guide introduces Web Dynpro projects under Developing Web Applications in the Introduction to the Web Dynpro Programming Model.
A Web Dynpro component is a reusable entity consisting of views and controllers. Web Dynpro components can be reused as a whole or simply be used to structure a Web Dynpro application. The definitions for development components and Web Dynpro components imply that a development component may contain, besides other development components, also Web Dynpro project development components, which again can contain any number of Web Dynpro components. However, a Web Dynpro component cannot contain a development component. A Web Dynpro component cannot contain other Web Dynpro components either; it can only use other Web Dynpro components for different purposes (for example, for method calls, for embedding interface views, or for mapping context elements). In the modeling of Web Dynpro projects introduced below, the different usage dependencies are consequently modeled differently. A Web Dynpro component can only be included in a development component. To prevent duplicate data und to support the reuse of Web Dynpro components, you should develop generic Web Dynpro components, which can then be tailored to the respective needs.
In this phase, you identify the interaction of all required Web Dynpro components, all models used, the Web Dynpro component interfaces and their dependencies. In addition, you determine the cross-component data and control flow in this step. The data flow is modeled by a labeled edge between the Web Dynpro components; the edge identifies the context to be mapped. The control flow, too, is modeled by a labeled edge between the Web Dynpro components; the edge identifies either method calls or the events used between the Web Dynpro components. You can use the Web Dynpro project diagram to visualize this; for our example, it looks like this:

You use Web Dynpro components to structure Web Dynpro applications. They can also be reused if specific data and services are suitable for a specific task on an abstract level. Within the Web Dynpro component to be developed, you should therefore search for subaspects that can be moved to other Web Dynpro components and be reused there. When creating Web Dynpro components, make sure that the package is structured logically, for example:
· com.company.toplevelcomponent.subcomponent1
· com.company.toplevelcomponent.subcomponent2
· ...
In the Web Dynpro project diagram, a Web Dynpro component is symbolized by a rectangle containing the name of the Web Dynpro component.
The Web Dynpro component Book2FlyComp integrates different travel services. FlightsComp is responsible for flight booking. ItemSearchComp performs the flight search and ItemAvailabilityComp is used for selecting the seat in a graphic: it displays the cross-section of a plane. CustomerDetailsComp manages the customer data. PurchaseOrderComp performs the flight booking and ContractConfirmationComp is used to confirm a booking.
In our example, you can use the Web Dynpro component CustomerDetailsComp not only for the flight booking system FlightsComp, but also for other applications that need to manage customer data. However, the Web Dynpro component ItemAvailabilityComp is such a specialized component with its graphical seat selection in a plane that it is used only for structuring.
A Web Dynpro component can have an interface view that another Web Dynpro component can use for its own visualization.
In the Web Dynpro project diagram, such a usage dependency between two Web Dynpro components is symbolized by an ”embeds” edge giving a direction. The edge points to the Web Dynpro component whose interface view is embedded.
The Web Dynpro component Book2FlyComp uses the interface views of the Web Dynpro components FlightsComp, GuidesComp and RoutesComp. FlightsComp itself uses the interface views of the Web Dynpro components ItemSearchComp, ItemAvailabilityComp, CustomerDetailsComp, PurchaseOrderComp and ContractConfirmationComp in order to enable flight bookings.
A Web Dynpro application is usually an SAP system. Check whether or not appropriate RFC calls are available for the data to be processed. If this is the case, you can create a model using Import Adaptive RFC Model.
If the data is retrieved from a Java backend, you should develop or, if existing, use Enterprise Java Beans (EJBs) to access the business data. In this case, you can use an external modeling tool to perform an XMI export based on the underlying UML model of the EJB. You can use Import Model from UML definition (XMI-format) to create a Web Dynpro model with the exported XMI file, which allows you to access the Java backend.
In addition, you can generate a Web Dynpro model for a published Web service using Import Web Service Model.
In the Web Dynpro project diagram, a model is symbolized by a database symbol carrying the model name.
The FlightModelis used to access the flight data stored in an SAP system. The dustomer data come from a Java backend managed by the CustomerModel. To send a confirmation message, the EmailModel is used, which feeds a Web service.
Using a model, you can supply a Web Dynpro component with business data or use services in another system.
In the Web Dynpro project diagram, such a usage dependency between a Web Dynpro component and a model is symbolized by an ”uses” edge giving a direction. The edge points to the model used.
The Web Dynpro component ItemSearchComp uses the FlightModel to determine the flight data. CustomerDetailsComp uses the CustomerModel to manage the customer data. To send a confirmation message, the Web Dynpro component PurchaseOrderComp uses the EmailModel.
A Web Dynpro component interface separates the description of properties of a Web Dynpro component from its implementation. A Web Dynpro interface can be implemented by more than one Web Dynpro component and a Web Dynpro component can implement more than one Web Dynpro component interface.
A Web Dynpro component interface describes a component interface controller and any number of component interface views. The component interface controller contains both methods and events with their parameters and context elements. The component interface views define inbound and outbound plugs with their parameters. Web Dynpro component interfaces enable the operator of a Web Dynpro application to tailor the Web Dynpro application to individual needs. To do this, the Web Dynpro application uses Web Dynpro component interfaces to integrate one or more Web Dynpro components. The operator can then exchange these Web Dynpro components with others that implement the same interfaces.
In the Web Dynpro project diagram, a Web Dynpro component interface is symbolized by a dashed rectangle containing the name of the Web Dynpro component interface.
¡ In our example, there is a Web Dynpro component interface named CompanyAdaptorCompI, which is adapted to company requirements in the example.
Because a Web Dynpro component interface only describes the properties of a Web Dynpro component without actually implementing them, you need Web Dynpro components that implement the defined Web Dynpro component interfaces.
In the Web Dynpro project diagram, such an implementation dependency between a Web Dynpro component and a Web Dynpro component interface is symbolized by an ”implements” edge giving a direction. The edge points to the Web Dynpro component interface to be implemented.
Our example contains the Web Dynpro component SapAdaptorComp, which implements the Web Dynpro component interface CompanyAdaptorCompI. This ensures that the application is adapted to SAP requirements.
Web Dynpro components can not only use other Web Dynpro components but also Web Dynpro component interfaces. The Web Dynpro component can use the following properties of the Web Dynpro component interface:
1. Context (for mappings)
2. Methods (for calls)
3. Events (for communication)
4. Interface views (for embedding)
Consequently, these different usage dependencies between a Web Dynpro component and a Web Dynpro component interface are modeled differently in the Web Dynpro project diagram:
...
1. By a dotted edge giving a direction; the edge is labeled with the context to be mapped. The edge determines the data flow direction.
2. By a dashed edge giving a direction; the edge is labeled with the calling method and, optionally, with the method called in the calling method. The edge determines the call direction.
3. By a dashed edge giving a direction; the edge is labeled with the event and, optionally, with the method in which the event is triggered. The edge determines the trigger direction.
4. By an ”embeds” edge giving a direction. The edge points to the Web Dynpro component whose interface view is embedded.
The cross-component data flow is represented by dotted edges and the cross-component control flow by dashed edges.
The Web Dynpro component Book2FlyComp uses the Web Dynpro component interface CompanyAdatorCompI to adapt our example to company requirements.
Communication between Web Dynpro components happens using method calls and events.
In the Web Dynpro project diagram, a method call between two Web Dynpro components is symbolized by an edge giving a direction; it is labeled with the name of the calling method and, optionally, with the method called in the calling method. The edge determines the call direction.
In the Web Dynpro project diagram, an event used and the relevant event handler between two Web Dynpro components are symbolized by an edge giving a direction; it is labeled with the name of the event and, optionally, with the method in which the event is triggered. The edge determines the trigger direction.
To identify these edges as part of the control flow, they are shown as dashed lines.
In method wdDoInit, the Web Dynpro component Book2FlyComp calls the Web Dynpro component interface method getTitleImage from the Web Dynpro component SapAdaptorComp, which implements the Web Dynpro component interface CompanyAdatorCompI, to adapt the title screen to the company requirements.
The context mapping between Web Dynpro components enables the participating Web Dynpro components to exchange data.
In the Web Dynpro project diagram, context mapping between two Web Dynpro components is symbolized by an edge giving a direction; the edge is labeled with the context to be mapped. The edge points to the node to which the data is mapped.
To identify these edges as part of the data flow, they are shown as dotted lines.
For our example, we can describe the cross-component data flow as follows:
Because the Web Dynpro component PurchaseOrderComp gives an overview of the selected flight, the selected seat, and the entered customer data, labeled edges exist from ItemSearchComp, from ItemAvailabilityComp and also from CustomerDetailsComp to PurchaseOrderComp.
