Configuration Model

[Former Member]

Web Dynpro IDE offers many options for creating models. One of them is "Create Configuration Model". Is there any documentation or tutorial on "configuration model" (purpose, uses , examples, etc..)?

Thanks, regards, peter

[Former Member · Accepted solution]

Hi Peter,

I've investigated the possibilities with the configuration model and I'd make the following points:

1. The Configuration Model <b>Interface</b> Classes can be quite useful as you can implement properties and methods and then implement the interface in a JAVA class that can be binded to a context of this interface during the wdInit of a controller. The limitiation of this is that you can not represent relatinships between interfaces. Hence mapping to table controls needs to be done programmatically.

These seem quite stable and allow you to make a wrapper around adaptive RFC's, EJB's, web services, etc; which I believe improves the design of your Web Dynpro application for future support.

2. The Configuration Model Classes are good for handling the relationships between other Config Model Classes, however they do not support methods yet so these are only really good to represent structures (and tables of structures if you consider the relationships). That said, the implementation leads me to believe they are still working out the logistics of how these will work and this is probably why they say this is not really supported yet. ie. They are still implemented as interfaces and you can't really instantiate an object without using a context (I haven't investigated this fully).

The alternative is to get a tool that creates XMI files that Dev Studio will accept. I tried a number of other UML tools out there other than Borland Together, but Borland Together was the only one that produced the right format. I think it's worth while buying this software, but at over $4000 USD for a single license, or around $6500 for a floating license, you need to have stakeholders that are aware of the benefits of proper UML integrated design as otherwise it is a hard sell.

So in summary, my recommendation is Borland TE if you can get it (this software will even cost SAP when '04 is released I believe). If you can't get it, the configuration model interfaces let you abstract from the other models quite well, but the fact that relationships are only supported in classes is a major limitiation and requires tables to be represented in a way that can't be directly mapped to table controls (ie. You need to programmatically do this to a value node in the View Controller).

Regards,

Matt

[Former Member · Accepted solution]

Oh my God!

Sure, WD team should publish corresponding documents ASAP!!! I can't imaging so terrific missuse of Configuration classes!

Briefly, WD Configuration classes are used for storing configuration data in WebDynpro Runtime Repository. There are a lot of co-related things, and this topic worth blog entry or even multi-part article. If you want to explore this functionality yourself here is starting points:

1. Study documentation for packages com.sap.tc.webdynpro.repository.api & com.sap.tc.webdynpro.services.sal.repository.api

2. Create sample configuration model and look inside generated classes -- you will see references to interfaces declared inside com.sap.tc.webdynpro.repository.api package, probably it gives you some hints how this classes intended to work with.

3. Deploy your DC with configuration model and try to play with WD Runtime Repository Editor http://<host>:50000/webdynpro/dispatcher/sap.com/tc_wdtools/Editor

Now several words to Matt:

1. There are more appropriate wizards for RFC models & web-services.

2. Do you really try to use Configuration Model to wrap EJBs? This is impossible, and you would know this if you ever try.

3. Configuration classes DO support relations without any custom methods. Relation-specific methods are generated by wizard.

Regards,

VS

[Former Member · Accepted solution]

Steady on Valery. Firstly, although they may be specifically created for configuration, they are the only way of abstracting from direct calls to Adaptive RFC's and Open SQL without the use of XMI file imports (if you want to map context elements directly to the object). The whole concept of the interface model fits in fine with this (Agreed it's not the original planned usage of it but we need to look for work arounds when Web Dynpro is not fully functional).

Just in response to what you stated:

1. I'm definitely recommending using the wizards for RFC models and web services, but my point is not to directly tie these into Web Dynpro Views directly. I feel this is a very bad practice unless you're designing your model within the SAP space entirely.

2. No I haven't actually used EJB's within the implementation of the interface, but this was a hypothetical example and I'm pretty sure I could do it within the JAVA class implementation regardless (note - I'm referring to a JAVA class that implements the interface and not the interface class itself.)

3. That's what I said. But the interfaces do not.

It sounds like you either;

1.Have Borland TE; or

2.You are combining data within the controllers directly into value nodes and attributes.

I found without Borland TE, you are very limited to how you can design a Web Dynpro application, but I would be interested to see how you model your data if you do not use this. Alternatively, if you know how to produce XMI files that import correctly from Posiedon or other tools, I'd really be interested in that.

Regards,

Matt

[Former Member · Accepted solution]

Matt,

All my complains was addressed to WD team, not you. Sorry if you take this personally. This functionality was available more then for year (!!!) and there are still no docs publicly released.

Next, if you are using Adaptive RFC you are already tied to SAP J2EE engine & co. Otherwise use SAP JCA adapter.

Moreover, WD Models intended to be used with WD UI part. They adopt (in certain sence and way) any object model to WD-Context-friendly-form. It is only my opinion, but believe me, it has strong background.

When you are generating Configuration Model Classes, take a look at result -- there is an implementation inside! That is what this generator was made for. Worth to mention, this implementation should never be accessed directly. Using them for anything else is possible. Like it is possible to hit a nail with microscope.

Regarding XMI import. Yes, I have Together Edition for SAP NW. Probably, I can help you as well. Type the following in NW help search: "Conditions for an XMI Model Import". This gives you 2 documents that completely describes UML tool requirements and developer responsibilities.

Briefly, the following required from tool:

1. Support for Unisys Extension 1.3

2. Ability to embed SAP-specific anotations (NW contains necessary configs for Together & Rational, location mentioned in documents above)

WBR,

VS

[Former Member · Accepted solution]

Definitely tied to SAP J2EE, and hence Adaptive RFC is a really good wizard to use so I feel it's the way to go there.

I'm very interested in your comment:

They adopt (in certain sence and way) any object model to WD-Context-friendly-form. It is only my opinion, but believe me, it has strong background.

I'm not sure if you're just talking about overwriting the implementation of a model, or if there's a way to implement a model that's not necessarily tied to the 4 options available in the dev studio.

For Config Model Classes, yep, that implementation looks pretty scary (and currently useless); however; there is no implementation behind the Config Model "Interface" classes, and this is what I am referring to as being useful.

ie. The interface code only contains the following:

//@@begin imports
import com.sap.tc.webdynpro.repository.api.IWDRepositoryModelClass;
//@@end

//@@begin documentation
/**
 * Interface of configuration model class "Interface1".
 * @author File created by Web Dynpro code generator
 */
//@@end
public interface Interface1 {

  /**
   * Getter for read only property Value1.
   * @return value of the Property
   */
  public java.lang.String getValue1();

  //@@begin javadoc:Method1()
  /** declared method */
  //@@end
  public java.lang.String Method1( );

}

Hence it is pretty clean to create a model that you can use in Views. Basically I implement this interface in a JAVA class, and then bind the JAVA class to the node of this type. It also makes all the methods available by the bounded object (for controller events).

Thanks for the info on the XMI tool. I'm thinking my next step is to identify how to build the XMI in the right format, as I really need a model that supports relationships and XMI is my only solution.

Regards,

Matt

[Former Member · Accepted solution]

Any ideas on the "Import Enterprise Services Model" option that's shown as available within the documentation for XMI import?

[Former Member · Accepted solution]

Hi Matt,

have a look here.

Best regards,

Christian

[Former Member]

Hi folks,

a new ModelImport Wizard has been made available with the current Stack level 9:

the JavaBean Model Import Wizard!

This should solve the problems you have attempted to solve with either the ConfigurationModel as stated above by Matt, or even the XMI Import (reverseEngineered Model).

This new Wizard allows you to import arbitrary Java classes conforming to Java Bean Naming Conventions (setter/getter Methods) and bind these directly to Web Dynpro contexts. You can achieve everything you were able to achieve with the XMI Import, but you don't need a $4000 license for Together and you aren't forced to model in UML in order to bind Java classes to Web Dynpro contexts. It is also possible to model relationships, although your Java classes must use proper methodnames to be identified as relations.

Please update to Stack9 if you want to use this new wizard.

Ciao, Markus

PS: although it is technically possible to use the ConfigurationModel to abstract model data, it brings in quite some overhead and should not be done. With the JavaBean Model, there should be no more reason to attempt such a workaround.

[Former Member]

Thanks for the info. I knew this was coming, but I expect this will not be released for at least 6 months for GA. Alternatively, do you know when it available as ramp-up?

Also, in anticipation of this, do you have documentation or advice on what the naming of relationships and methods should be in order to develop them and import them as a JavaBean Model in the future? Get and set methods are obvious, but what are the names and standards for demonstrating relationships? Is it the same as the interface defined when you import an XMI model with relationships?

Thanks,

Matt

[Former Member]

Markus,

Thanks for info. However, I demand more

What I need to know how WD-Context-friendly will be generated models. Could you elaborate further on questions below?

Would it be ICMIModel (I mean whether or not complete Java implementation will be generated)? Or better yet, will all clases implement ICMIGenericModelClass (I don't know how, probably via mix-in CMI specific interfaces on original classes).

Any chance to see 0..n relations represented via ICMIObservableList?

Does IWDModel will be implemented (cureently this is done for Dynamic RFC Model only)?

Thx in advance,

VS

[detlev_beutner]

Hi Peter,

no, not documented yet. See

For some explanation, see

Hope it helps

Detlev

[Former Member]

Detlev:

Thanks for your quick reply. Do you have an idea when the documentation will be available?

Thanks, best regards, peter

[detlev_beutner]

Hi Peter,

no, I have no idea when it will be published. But as a suggestion: Go into the first thread given and ask Karin.

Hope it helps

Detlev

PS: If you find my answer(s) helpful, please do not forget to award corresponding points (via the yellow stars). Thanks in advance!