Importing Enterprise JavaBean (EJB) Models
The EJB model importer is represented by a wizard in the Web Dynpro Perspective. The importer supports you during the call of the one or several EJBs to be used in your Web Dynpro application. You define the Enterprise JavaBeans within an EJB Development Component (DC), implement the entities, add the Enterprise Application DC - which contains the EJB DC - to the Web Dynpro DC, and finally import the model.
The importer uses the Java standards Enterprise JavaBeans 3.0 and Java Persistence API (JPA) 1.0. Providing an abstraction of the application business logic into the Web Dynpro components, it reduces the manual coding done by the Web Dynpro application developer thus allowing to concentrate on the user interface part of the application. The most significant simplification aspects are the automatic database table creation and EJB business methods execution: When the server handles these actions, they are absolutely transparent for the developer.
More information: Enterprise JavaBean (EJB) Model
Prerequisites
You have already defined the following application parts:
● Enterprise JavaBean (EJB) Development Component
● Entities
● Database tables and connection
● Session facade
● Public part of the Enterprise JavaBean (EJB) Development Component
● Enterprise Application unit containing the EJB Development Component
● Web Dynpro Development Component
Procedure
1. Define a New Development Component Project with the required parameters, for the Vendor entry choose an individual praefix. This Development Component (DC) is kept locally which means it won’t be added to the overall infrastructure until you define this explicitely lateron.
2. Prepare the EJB DC and the Enterprise Application DC already available which you would like to use in Web Dynpro with a few clicks before you start with the model importing step itself. For an existing EJB DC, goto the Development Infrastructure Perspective, choose Component Properties → Permissions, select Entity Forwarding Allowed.
3. For the Enterprise Application DC, you also do the steps in theComponent Properties of the Development Infrastructure Perspective: Choose Public Parts, and create a new public part with any name. Right-click on it, select Reference Entities from the context menu and add the client public part of the EJB DC.
4. Now you can add the archiving DC - which contains the EJB DC - to the Web Dynpro DCdependencies: Go to the context menu of the Web Dynpro project and choose Development Component → Show in Component Properties, then Dependencies → Add… . Expand your vendor component node, and select your Enterprise Application. By doing this, you explicitely add the business application functionality such as creating and/or listing entities (this depends on the EJB DC definition) to your application.
5. To import the EJB model into the Web Dynpro application, choose Models → Create Model → EnterpriseJavaBean Model. Make the required entries and selections; from the available Public Parts list, you only need your Enterprise Application DC with the EJB DC. The tc/ folders are not needed.
6. Both session facades are shown with their business interfaces and methods inside; select all the methods.
Each business method of the Enterprise JavaBean is represented by a so called Request model class. The Request model class contains all the business method input parameters either as properties (in case of simple types) or relations (in case of JavaBeans, collections or arrays). If the business method has a return type, then the corresponding Response model class is created as well and linked as a relation in the Request model class.
7. Explore the properties and relations for each model class, then change the model class names. If there are name clashes, you have to change the model class names; if not, keep the initial class names.
8. The following import log is for your information about the status of the model import. With Finish you start the generation process for the model classes which you will use for your Web Dynpro application.
9. Make a definition for the model reference as it is needed for all Web Dynpro applications for usage of the right model at runtime.
More information: Adding Model References
10. Define all other Web Dynpro application units such as the component with window and view for the user interface design; the component interface for dataflow definition purposes; the application unit which is the starting point for the whole application.
11. Also the next steps for the model class mapping between the main application controller and the newly generated model classes are standard for Web Dynpro. There are some EJB Model import specific steps to do which are described here. Open the Controller Editor for the component controller and start the model binding wizard (New → Node → Model Binding from the context menu of context), next choose the Request_<entity1>FacadeLocal_create class. Select only the attributes from the request class sub-tree.
You use this Request model class for creating a new object, an employee for example (object type depends on your application content). Since the ID is automatically generated by the JPA implementation and the project is chosen from a drop-down menu, the sub-tree attributes are sufficient.
12. Back in the context menu of context, again choose New → Node → Model Binding. Choose the Request_<Entity1>FacadeLocal_findAll model class, and rename Response into any other name for the method (MyResponse, for example) and return into another name, e.g. myreturn. We recommend that you use generic prefixes when renaming the method names, depending on your project name, for example.
This step is required because nodes with equal names are not allowed in Web Dynpro contexts: Response is the default name for the Request-Response relation while Return is the name of the only property/relation in the Response model class.
Again, only select the lowest attributes from the tree, and finalize the definition for the facade.
13. Do the model binding steps described above for all available facades.
14. Switch to the Properties view – open it if not already done – and change the Collection Cardinality for each Request model class to 1..1. This is a mandatory step and therefore a requirement for the automatic model object creation lateron.
15. Perform the context binding/mapping between the view controller and component controller. These steps are the same as for all other Web Dynpro models.
16. Register the model in the component controller by adding the following coding to the wdDoInit() method:
public void wdDoInit()
{
//@@begin wdDoInit()
<mymodel>.<MyModel>
<myModel> = new
<mymodel>.<MyModel>();
wdComponentAPI.getModelInstanceMap().putDefaultInstance(
"<mymodel>.<MyModel>", "<mymodel>);
//@@end
}
By this, you ensure that all mandatory root elements and their mandatory relations 1..1 and 1..N will automatically be created by Web Dynpro, along with their default instances. You won’t have to instantiate them manually then.
17. The onAction events needed for user interface elements such as buttons or drop down lists require that you make further context definitions for the used entities and model objects. These steps depend on your user interface design and the actions the user shall perform. Select the current model object for the corresponding entity; define the relation between the entities; execute the create method of the session façade; make object updates and trigger Web Dynpro to re-create the request. For these implementations, use wdContext. in the public void method.
18. In the view controller, initialize the user interface page and execute the Request model objects which represent the findAll methods from the facades. Add the coding for the wdDoInit()method in the Java Editor as following:
public void wdDoInit()
{
//@@begin wdDoInit()
try {
// populates entity1
wdContext.currentRequest_<entity1>FacadeLocal_
findAllElement().modelObject().execute();
// populates entity2
wdContext.currentRequest_<entity2>FacadeLocal_
findAllElement().modelObject().execute();
} catch (Exception e) {
e.printStackTrace();
}
//@@end
}
19. Finally, deploy and run the application.