8.5pt;font-family:Tahoma'>The WebDynpro Model 8.5pt;font-family:Tahoma'>
8.5pt;font-family:Tahoma'>Very early when I saw first versions of WebDynpro I was very intrigued by it and I especially liked the idea of the models very much. But I also noticed that it was a very high emphasis on a RFC connection to R/3 systems. What I thought was missing and many customers find that also that there was a model missing for EJB or any other Java Object model.
8.5pt;font-family:Tahoma'>The XMI model 8.5pt;font-family:Tahoma'> was first meant to fill the gap. The idea is to have a case tool like rational rose or together where you can design your object model with your classes and relations and then export this to an XMI file. (XMI is an xml format to exchange UML diagrams between different case tool). This XMI file then again can be imported into WebDynpro as a model. This works but never got so popular as as there were not so many people around having a Rational Rose or a Together installation. It is a quite complex setup also because you need to install a small plugin for together or rational rose so you can tag the different classes with a special WebDynpro Tag that mark an object as ready for a WebDynpro import. I think I got it to run once but it was just too tedious and I never really became a friend of it.
8.5pt;font-family:Tahoma'>That is why I started to experiment with writing my own Java Bean importer and came up with a very simple prototype that I already use successfully in my customer projects. (Luckily I had some experience with writing a model importer for webdynpro through the webservice importer). I am also very glad that SAP will now put out the official Java Bean importer with a lot of enhancement to mine in the next release. Thanks to the Indian collegues Padma and Raman for that.
8.5pt;font-family:Tahoma'>The Java Bean Importer 8.5pt;font-family: Tahoma'>
8.5pt;font-family:Tahoma'>I think the Java Bean importer finally will become the most often used model next to the RFC model because it is very natural for a java developer and can be used for almost any purpose. You can write a very simple access layer with Java Beans that encapsulate the access to any backend system. Though the access layer has to be coded manually it gives you the advantage that if the backend changes your implementation of the access layer changes too but not necessarily its interface to the ui. This can be a recommended practice especially when the backend interfaces are not stable which they are not most of the time when you are still developing them.
8.5pt;font-family:Tahoma'>Your Java Beans (we are not talking about EJBs but plain old java objects) can be imported as a model and then be bound to a Context in WebDynpro. Against this Context you can bind you ui elements which makes the data transport between the ui and the Java Bean model just a matter of configuration. Because EJBs are also java classes you could theoretically import them with the Java Bean importer also. Probably some people could get the idea to import some Entity bean with the Java Bean importer and then connect its properties directly to the ui. This is not recommended though because of the tight coupling of your ui and the scalability and ... whatever, its just not good practice to use Entity Beans directly.
8.5pt;font-family:Tahoma'>Therefore for Entity Beans or databases access in general usually a Session Bean facade is used. But how would you use this Session Bean as a webdynpro model?
8.5pt;font-family:Tahoma'>Writing an access layer for Session Beans 8.5pt;font-family:Tahoma'>
8.5pt;font-family:Tahoma'>For this you must understand what makes sense in a model and what not. In a webdynpro model only objects and their attributes make sense. You could technically import a Session Bean with the Java Bean importer but what would you see?
8.5pt;font-family:Tahoma'>A model class without any properties.
8.5pt;font-family:Tahoma'>The problem is: a modelclass is also the backup for a Context. A Context in WebDynpro has nodes which are the equivalent to model objects and nodes have attributes the equivalent to properties in a Java Bean. The Context does not have methods or at least you cannot bind methods to ui elements but you can only bind Context Attributes(java bean properties) to ui elements. Therefore a solution would be to encapsulate every method in the Session Bean as its own object and treat the method parameters as Java Bean properties. This can be achieved through the command pattern.
8.5pt;font-family:Tahoma'>So if the Session Bean looked like this:
public class MySessionBean implements SessionBean{ public float add(float f1,float f1){ return f1+f2; } }
8.5pt;font-family:Tahoma'>You could create a command object like this:
public class MySessionBean_AddCommand { private float f1; private float f2; private float result; public MySession Bean_AddCommand() throws Exception { //do lookup here, create from HomeInterface } public void execute() { setResult( getMySessionBean().add(getF1(),getF2()) ); } public float getF1() { return f1;} public float getF2() { return f2;} public float getResult() { return result;} // setter .... }
8.5pt;font-family:Tahoma'>This command bean makes perfect sense to connect to the ui. When you map a Context Node (of type Model) to this bean and then you have the three properties "f1","f2" and "result" in your Context which you can bind to the ui. You bind two input fields to the Context attributes "f1" and "f2" and a textview to display the result to the Context Attribute "result". To trigger the calculation you can call the execute() method of the bean in the button action.
8.5pt;font-family:Tahoma'>Here is how you would have to bind the model object to the Context.
public void wdDoInit(){ //@@begin try { wdContext.nodeMySessionBean_AddCommandElement().bind(new MySessionBean_AddCommand()); }catch(Exception ex) { } ... //@@end }
8.5pt;font-family:Tahoma'>Here is how you woud code the action for the button
public void onActionCallSessionBean(){ //@@begin wdContext.currentMySessionBean_AddCommandElement().modelObject().execute(); ... //@@end }
8.5pt;font-family:Tahoma'>
8.5pt;font-family:Tahoma'>Limitations 8.5pt;font-family:Tahoma'>
8.5pt;font-family:Tahoma'>Of course this is a very simplistic example. If the objects start to have relations, for example the result of a method is not a simple type but a collection of customer objects the webdynpro ui cannot detect that the relation "result" has to be updated after the execute() was called.
8.5pt;font-family:Tahoma'>In cases like this you have to call
... //@@begin wdContext.nodeResult().invalidate() ; ... //@@end
8.5pt;font-family:Tahoma'>to trigger some type of a refresh. If you remember the old RFC model, there you had to do the same thing. Of course the Java Bean model is still inferior to the RFC model as it has no extra services like pageable resultsets, valuehelp etc.
8.5pt;font-family:Tahoma'>Outlook 8.5pt;font-family:Tahoma'>
8.5pt;font-family:Tahoma'> An approach to have similar functionality like the RFC model could be to create some utility classes that enrich the Context meta data. Another approach which one of the WebDynpro Architects (Markus) pointed me to was to implement the ICMIGenericModel classes in some Baseclasses from which your javabeans can inherit. These baseclasses can take care of the changetracking etc. This is not done yet but would be an interesting task. Maybe some people want to volunteer. (Do not worry if you did not understand a word I was talking about the "ICMIGeneric" stuff, I just wanted to get some interested people to help with this).
8.5pt;font-family:Tahoma'>
8.5pt;font-family:Tahoma'>Summary: 8.5pt;font-family:Tahoma'>
8.5pt;font-family:Tahoma'>I am very excited about the upcoming Java Bean importer. I think it is quite an universal tool and can even support you to produce more maintainable WebDynpro applications. As you may have noticed it can be quite tricky to read a webdynpro program from another person as there are so many code snippets distributed. My personal recommendation is: Encapsulate as much as you can in Java Beans and then import them into webdynpro. This makes your application easier to maintain and quicker to develop. Another advantage of the approach is that you can test your Java Bean middlelayer if you put most of the business and validation logic in there. The Webdynpro then is mainly ui logic. If you cannot wait maybe the SAP guys tell you how to get a beta version of the importer. Or you write me an email and I can send you my very simple version of the Java Bean importer.
>
