Integrating Services
The Java Web Dynpro developer always will – in addition to the user interface definition itself – either define new persistent application logic for the application, or reuse application parts, where possible. The Web Dynpro model which is a mandatory logical application unit which receives the application data from a back-end system where the data for the Web Dynpro application can originate from various sources: Either Java or ABAP application coding can be chosen to be the backend at design time, developers usually would come to the decision about the addressed back-end platform at the beginning of the project setup. In some cases, it also might be useful to first create the user interface units and then choose the back-end form, but in most cases it will be vice versa. Even defining more than one model entity for a Web Dynpro DC is possible, at any time developers then simply create a component reference for the runtime-relevant model where the Web Dynpro component is the application container unit which provides the interfaces for the data flow between the backend and the front end.
Procedure
1. Make a decision for an available backend type.
2. Start the model importer in Developer Studio.
3. Select the corresponding model type in the wizard screen.
You can use business objects from a SAP backend system, or from Visual Composer, for your Java Web Dynpro application. From the Enterprise Services Repository (ESR) in an SAP system, you retrieve the business object nodes and compound service interfaces.
If you have been using the ABAP platform in the past and want to provide a Java Web Dynpro user interface, then the Adaptive Remote Function Call (RFC) Model will be the right choice to start with Web Dynpro since the reuse factor is high, and development time is shortened. The Web Dynpro model importer generates Java classes out of the Business API(BAPI) or function module application data. This encapsulated data can be SAP data, or an application part which customers have developed themselves.
For profiting from application data which the Java standards such as WSDL provide, the Web Dynpro developer can use Web Services which are, for example, locally available, or services out of a Universal Description, Discovery and Integration (UDDI) registry. The Web Services used for the Web Dynpro application can also be services that were defined in the Web Service perspective as custom development. The Adaptive Web Service Model type provides enhanced features such as destination mapping or cookie-based authentication, and it supports the Web Services Inspection Language (WSIL) standard.
The JavaBean Model is the right choice for Java developers who want to combine the advantages of Web Dynpro with those of JavaBeans. As soon as the encapsulated application parts are available at design time, they can be addressed using the Web Dynpro component importer interface. The model interface supports interfaces, abstract JavaBean classes, and provides enhanced support for multiple JavaBean sources.
In addition to the JavaBean Model, you can use the Enterprise JavaBean (EJB) Model for the transactional beans. Transparent business methods support you at designtime, and you for example don’t have the need to instantiate instances manually but only have to register the model once within wdDoInit().
4. Finish import to generate the model classes which can then be reused for model binding purposes.