Start of Content Area

Background documentation Conditions for an XMI Model Import  Locate the document in its SAP Library structure

To be able to import an XMI model into the Web Dynpro development environment, you must use an external modeling tool that can produce XMI files. XMI is an XML format for storing and transporting metadata. To import to Web Dynpro you require Version 1.1 with Unisys Extension 1.3.

SAP has tested the modeling environments of the companies Rational Rose and TogetherSoft. The XMI models are released for import to Web Dynpro.

TogetherSoft

For an XMI export from a TogetherSoft model you require Patch Version 6.0.1 Build 1968v9. You must also carry out the following steps:

...

       1.      In the TogetherSoft tool, the SAP Importer tab must be active.

       2.      In your SAP NetWeaver installation, copy the file

<installDir>\eclipse\plugins\com.sap.ide.webdynpro.service.modeleditor\resources\uml\sapimporter.config

to the directory

/Together6.0.1/config

...

Rational Rose

For an XMI export from Rational Rose you require a Unisys add-in (Version 1.3.2). This can be found on the Rational Rose support homepage.

The following steps are necessary for a model import from Rational Rose:

       1.      Start the Rational Rose modeling tool.

       2.      In the Rational Rose tool, the SAP Importer tab must be active.

       3.      Choose Tools Model Properties Add... and add the following SAP NetWeaver installation file to your model:

<installDir>\eclipse\plugins\com.sap.ide.webdynpro.service.modeleditor\resources\uml\sapimporter.pty

For an XMI model import you must also adhere to some naming conventions: You must use fully qualified Java classes /interfaces, and note the conventions described in the next section.

Modeling Environment-Independent Procedure

1. Importing a Model into the Web Dynpro Development Environment

Prerequisites

Check the following import conditions:

...

       1.      The classes of the model require a specific package (=> default package).

       2.      Properties, methods, and relations relevant to Web Dynpro must be public.

       3.      Data types that you use for properties are restricted to primitive types and primitive wrapper classes (with the exception of byte and java.lang.Byte). java.lang.Object, java.math.BigDecimal, java.sql.Date, and java.sql.Time are supported. java.util.Date is not supported; use java.sql.Date instead.

       4.      Relations can be modeled as associations and aggregates, plus they can have any cardinality. Bidirectional associations are also supported, plus you can model any direction as an association or aggregation.

When using the TogetherSoft model, note that bidirectional associations are not supported, in accordance with the UML 1.3 standard. However, you can explicitly convert an existing association to a bidirectional association using the TogetherSoft pattern Convert to Bidirectional.

To do this, proceed as follows:

                            a.      Select the association

                            b.      In the context menu, choose Choose Pattern

                            c.      Select the Link node

                            d.      Choose Convert To Bidirectional

                            e.      Choose Finish to confirm.

Additionally, note the following Java interface specifications for properties and relations:

Property Access

For every property that is to be bound to a Web Dynpro context, the model must provide appropriate access methods according to JavaBean conventions.

Get Methods for Properties

ScalarType getX()

Note that property get methods can only return scalar types.

Mutator Methods for Properties

Void setX (ScalarType value)

Mutator methods (or set methods, in this case) are only needed for those properties that the client can change. Otherwise, the property can be set read-only in the model declaration. No mutator method should be provided. Note that the context can also be set to read-only with regards to client changes if the model property writeable is set.

Relation Access

Use the ModelClass class as a placeholder for the special parameters or return types of the relation access.

Get Methods for Relations

The Web Dynpro framework distinguishes between four cardinalities for relation roles:

x:0..1;

x:1;

x:0..n;

x:1..n.

 

Example

Example:

Let us assume there is a relation between model class C1 and model class C2 with the target role name X:

Cardinality

Method

Note

x:0..1

ModelClass getX()

Returns zero or the relevant object of the type ModelClass, according to the relation roll X between C1 and C2.

x:1

ModelClass getX()

Returns the relevant object of the type ModelClass, according to the relation roll X between C1 and C2.

If no such object exists, the behavior of the method is not defined.

x:0..n

Collection getX()

Returns the relevant object collection of the type ModelClass, according to the relation roll X between C1 and C2 (can be empty, but not zero).

x:1..n

Collection getX()

Returns the relevant non-empty object collection of the type ModelClass, according to the relation roll X between C1 and C2.

The returned collections can be variable or non-variable. The Web Dynpro Framework ignores the changeability of a collection and does not make use of special collection types such as List or Set.

Mutator Methods for Relations

Collection mutator methods are not called by the Web Dynpro framework. Instead, create the model instances and model relations and adapt the relevant context nodes later.

2. Preparatory Measures in the External Modeling Tool

In the external modeling tool, you specify which parts of the model you wish to use in the Web Dynpro application. Declare these model parts for export. In UML, the standard for customer enhancements is Tagged Values. To be able to edit these tagged values, you must install the required configuration files specific to the manufacturer, as described in the sections TogetherSoft and Rational Rose above. This provides an additional tab SAP Importer in the Properties view, which displays classes, methods, properties, and relations.

Set the Web Dynpro Import property to true for all classes and interfaces that are to be visible to the Web Dynpro application. Also, set the flag No Web Dynpro Import for methods, properties, and relations.

For every property, you must model a get method for read-only properties and a set method for read/write properties.

Example

Example:

For the read/write property String firstName, you model the two methods:

public String getFirstName();

public void setFirstName String value();

For relations you must model at least one get method for each navigatable roll of the relation. Depending on the cardinality of the relation roll, the accessors/mutators are as follows:

·        Single relation roles (0..1 or 1..1):

public <TargetRoleClass> get<TargetRoleName>();

public void set<TargetRoleName>(<TargetRoleClass> value);

·        Multiple relation roles (0..* or 1..*):

public java.util.Collection get<TargetRoleName>();

The return type must implement the collection.

When modeling relations, note that only navigatable roles are imported.

Export the UML model to XMI 1.1 (Together: File Export Model to XMI, XMI V1.1, Unisys 1.3, encoding: UTF-8) with any name for the XMI file, whose extension must be .xmi or .xml.

 

End of Content Area