Importing Adaptive Web Service Models (SAP Library - SAP NetWeaver Composition Environment Library)

Importing Adaptive Web Service Models

Using the Web Dynpro model import wizard, you address a Web Service definition which is available locally or from a UDDI for your Web Dynpro application.

Prerequisites

● Adaptive Web Service Model type is activated for the current Developer Studio version. Enablement of the Web Service model type is done within the .options file in the Developer Studio plugin

com.sap.ide.webdynpro.modeleditor/modeltypes/adaptivewebservice=true

● Web Service provider supports the Web Service Inspection Language WSIL. SAPsystems are suitable to provide these services, this is true for ABAP as well as Java backends.

● A Web Dynpro project as well as a component have been defined and are displayed within Web Dynpro Explorer view.

● Model import wizard has been started.

● Good working knowledge of Java Web Dynpro technology and of Web Service standards defined from the World Wide Web Consortium (W3C), for example the architecture of Web Services in general, or Web Service semantics.

Limitations

To successfully import an Adaptive Web Service Model for a given WSDL description, the WSDL must be compliant with the existing XML schema support limitations. Note that the limitations of the Adaptive WS Model apply in addition to those of the Web Service runtime.

● Group definitions

○ A definition with maxOccurs > 1 within other group definition

● Wildcards

○ XML Schema wildcard any

● Simple Types

○ XML schema list types on simple type supported: Simple type atomic

○ All simple types that are built-in, or are restrictions of built in simple types

● Complex Types

○ There are no explicit limitations regarding usage of complex types. The following limitations are derived from the limitations from Web Service runtime side:

■ Complex type restriction and redefine complex type extension "complex type extends complex type" only conditionally supported

■ Support depends on model groups used in the two complex types.

■ Not supported: Parent is choice, son is choice, all or sequence; Parent is sequence, son is choice; Parent is all, son is choice

■ Supported: Parent is sequence, son is sequence. The extended type contains all fields inherited from the parent.

■ Parent is all, son is all. The extended type contains all fields inherited from the parent.

■ Supported: complex type extension "complex type extends simple type"

■ Supported by using the SIMPLE content structure and DSimpleContent attribute.

Regarding the WSDL support limitations consider that the dynamic Web service client proxy only support rpc/document literal SOAP Bindings.

Procedure

1. In the model import wizard, choose the Adaptive Web Service Model option and follow the instructions in the wizard. For the WSDL URL, type the address into the entry field, or find it by browsing your local file system. The URL address is as following:

http://<hostname>:port/inspection.wsil

Example:

http://localhost:53000/inspection.wsil

To get a certain URL address which is available with the Java Engine of SAP NetWeaver Application Server, you can go to the WSDL page in the Web Service Navigator (Window →Show View → Others → Web Services → Web Service Navigator). Simply copy the URL from the WSDL link which is displayed there.

2. The next wizard screen shows the default logical destinations which you can change in the administration tool lateron. There is one destination suggested for the metadata itself and one destination for the execution. An alternative during this step could be that you don’t want to work with logical destinations; then you would use the WSDL URL itself for the metadata retrieval as well as for the Web Service execution. If you would like to work without explicitely defined destinations, select the non-default radio button.

This graphic is explained in the accompanying text

Web Service model metadata can be loaded using one of the following modes and differentiating between the so called “non-empty metadata destinations” and the “empty metadata destinations”:

If the metadata destination is non-empty, you maintain the metadata destination name in the administration tool. Additionally, the qualified name for Web Service interface (namespace and localpart) has to be defined. The WSDL URL is optional then.

If the metadata destination and other fields are empty, only the WSDL URL is required. This option is true for Web Service provider systems not offering Web Service lookup via WSIL. For the resolution of an external Web Service, the Internet proxy settings have to be provided for the Web Services Container via administration.

Restriction:

This mode is currently not working for external Web Services such as Google since the Internet proxy settings which have to be maintained for the Web Service Runtime within the administration tool for resolving the host in the WSDL URL are not working correctly. This behaviour will be changed with one of the following releases.

3. If you have made adoptions on the default settings you will get the information on the next wizard screen where you optionally can make changes on namespaces and entity names. Make changes in column Editable Model Class Name, additionally you can enter an Alias. After you have entered a new model class name, the Final Model Class Name also will automatically be changed. If you additionally define an alias, you will get modified class names, the alias name is automatically added to the final model class names.

4. Read the import log messages and finish the import. Save all metadata for the Web Dynpro project.

5. Make an update on the the usually used Development Component (DC) references with those that are needed by the Web Service Model. As the required DCs are not synced automatically from the Component Build Server (CBS), you trigger this manually: Log on to the SAP NetWeaver Development Infrastructure (NWDI), select the corresponding DC folder in the Web Dynpro Explorer, and select Development Component → Sync Used DCs from the context menu.

6. Execute the known Design Time Repository (DTR) check-in processes in the DC Perspective for the generated Web Dynpro units: Open the corresponding DC, expand the package folder in which the model has been created. All model entities must have an icon with a blue cross which indicates that the corresponding entity will be checked into the DTR.

Result

In the Web Dynpro Explorer view, the generated Web Service model represented by its model classes becomes visible after the import. The Adaptive Web Service model has a model class for each of the request and response class as a complex type. As a general rule the model creates classes named Request_<operationName> andResponse_<operationName> which act as containers for the input and output parameters of the corresponding Web Service operation. These classes have no direct correspondence to the complex types defined in the WSDL file. The relations of the request and response model class are created for all model classes corresponding to complex types of Web Service operation parameters. In addition, there is a relation from the request to the response model class for assigning the response model object to the request model object after invocation of the Web Service. On the right-hand side, the model class information is displayed in tab Relations.