Entering content frame

Component documentation Command Line Proxy Generator Locate the document in its SAP Library structure

Purpose

The command line proxy generator is intended to generate standalone Web services clients or clients for deployment on SAP J2EE Engine without using SAP NetWeaver Developer Studio tools.

Features

The command line proxy generator is located in the following class: com.sap.engine.services.webservices.jaxrpc.wsdl2java.ProxyGenerator

When you call this class you must have a classpath to the following JAR files from server installation:

·        webservices.jarsapxmltoolkit.jar

·        activation.jar

·        jaxrpc-api.jar

·        mail.jar

·        w3c_http.jar

·        jaxm.jar

Also the following JARs from JDK 1.3 must be added:

·        <JDK_install_dir>\jre\lib\rt.jar

·        <JDK_install_dir>\lib\tools.jar

A brief example of its use is as follows:

ProxyGenerator <wsdlLocation> <targetDir> [options]

Here is a brief list of the proxy generator options. Run the generator with no options to see the help screen:

[-p package] - package name
[-c] – compile
[-j jarname] - create jar
[-i] - generates interfaces only
[-d] - generates rpc style method where possible
[-x] - generate JAX-RPC style getXXX methods in service interface
[-h proxyHost proxyPort] – use http proxy

More detailed description of the proxy generator options follows:

·        [-p] – the option is used to set the base output package for the generated proxy files. Note that if this option is not set, the generator will try to deliver the default package name from the WSDL target namespace. If this cannot be done, then an empty package is set.

·        [-c] – tells the generator to compile the output directory with the generated files.

·        [-j jarname] – creates a JAR file and adds the generated compiled files in it. This option turns on the compile option, as it makes no sense to add Java files to the JAR file.

·        [-i] – generates Web service interfaces only. It is required if you intend to deploy a Web service client on the SAP J2EE Engine. When you need to use this Web service without testing it standalone, the server is responsible for generating interface implementations at deploy time.

·        [-d] – for all document style Web services, it is possible to create RPC-like methods instead of  methods with one structure as a parameter. The generator checks and adds additional methods where possible. This is performed for the convenience of users.

·        [-x] – by default, there are some differences in the generated service interfaces. This option forces the generator to add JAX-RPC compatible methods to the service interfaces for getting the port instances.

·        [-h proxyHost proxyPort] – when using a WSDL location across the Internet through a firewall proxy server, some adjustments are required.

Example

java.exe –classpath activation.jar; jax-qname.jar; jaxrpc-api.jar; mail.jar; w3c_http.jar; sapxmltoolkit.jar; jaxm.jar; C:\jdk1.4.2\jre\lib\rt.jar; C:\jdk1.4.2\lib\tools.jar; webservices.jar com.sap.engine.services.webservices.jaxrpc.wsdl2java.ProxyGenerator groupb.wsdl -c -p myproxy

SAP WSDL Proxy Generator 6.40

* Generating Proxy from:C:\Documents and Settings\Chavdar-B\My Documents\groupb.wsdl

* To directory:E:\Version\AppServer\dev\src\server

* Output root package set to : tutorial.myproxy

Compiling... last = 4

Compiling... last = 1

Compiling... last = 4

* Done

Results of proxy generation

In this example, option –c is used, which tells the generator to compile the generated output files. Here is a screenshot of what is produced in the output directory:

This graphic is explained in the accompanying text

The main proxy classes and configuration files are generated in the root directory, and delivered helper classes are also generated in the types sub-package schema. The file lports.xml is responsible for describing the service ports. The SAP Web services clients use configuration files to store the proxy state. This makes it possible to configure and change the proxy without having to regenerate it every time. lports.xml stores information about the logical ports. The logical port is a unit that represents a Web service port abstraction, but also contains extended Web service information and an endpoint configuration. For example, endpoint-specific extensions such as HTTP proxy and security are stored for each separate logical port, and can be passed to the server environment when a Web service client application is deployed. The file types.xml keeps the mapping of XML schema types to Java serializers. If there are no custom defined types used by this Web service, the types.xml file will be missing.

The protocols.txt is a property file that describes mapping from abstract framework extensions to actual implementation files. This file is needed for a standalone environment only, to gain information that typically is only known to the server for deployed clients. For example, when you deploy a client that uses a session feature (extension) on the SAP J2EE Engine, you do not need to know the actual implementation class of this feature, but the implementation class must be listed to make this work standalone in protocols.txt.

 

 

Leaving content frame