Info*Engine provides a SOAP Remote Procedure Call (RPC) servlet that receives SOAP requests from a SOAP client and sends responses back to the client. The servlet gathers the information sent from the client (consisting of the methods to execute and other request information) and processes the methods by executing tasks that people at your site have created explicitly for use with the SOAP client. These tasks are used to execute task webjects, and the servlet allows SOAP clients to invoke these specially-written Info*Engine business tasks. For more information about the required SOAP task format, see Info*Engine Task Invocation with SOAP.

The Info*Engine SOAP RPC servlet can be used to pass data to and from a SOAP client that has been developed using the Info*Engine Java EE connector or some other third-party SOAP client. For more information, see Info*Engine Java EE Connector.

The SOAP RPC servlet automatically generates Web Services Definition Language (WSDL) for a given SOAP service when it receives an HTTP GET request (for example, when using a standard web browser to access the servlet directly). When issuing a GET request to the RPC servlet, you must supply the CLASS query argument, and can optionally supply the VERSION and STYLE query arguments. The CLASS query argument specifies the CLASS of the given SOAP service for which you would like WSDL generated. The VERSION and STYLE parameters are used to decide what type of WSDL you would like to have generated. For more information about the STYLE and VERSION parameters, see the webject description in Generate-WSDL.

For example, if you generate the default WSDL for an Info*Engine SOAP service that you authored under the following type identifier:

You might request the WSDL as follows:

If you are attempting to integrate your SOAP service with a third-party Service Oriented Architecture (SOA) platform for the task of attempting to call your SOAP methods from within a Business Process Execution Language (BPEL) orchestration, you would want Info*Engine to behave in a WS-I compliant manner to ease integration. In such a situation you would likely request your WSDL as follows:

The Info*Engine Java Platform, Enterprise Edition (Java EE) connector uses WSDL to generate client-side source code to simplify interactions with Info*Engine.

The Microsoft SOAP Toolkit uses WSDL to define, validate, and constrain the remote classes and methods that clients can call, the parameters that are supported by each method, and the kinds of results that are returned. For more information, and to download the Microsoft SOAP Toolkit, use the following URL:

Other third-party clients can also use WSDL to generate source code or to drive interactions with Info*Engine.

The following diagram illustrates how a SOAP client interacts with Info*Engine:

When a SOAP request is made, the web server processes the HTTP request and directs it to the SOAP RPC servlet. The SOAP RPC servlet accesses the LDAP repository in your Windchill Directory Server to identify which task should be executed. In the LDAP directory, you have created task delegates that identify tasks that are to be executed for the methods the SOAP client can execute. The SOAP RPC servlet passes the name of the task and the other request information on to an Info*Engine server, which executes the task.

After the Info*Engine server executes the task, an appropriate response is sent to the SOAP client. The response sent to the SOAP client is based on the data returned by the Info*Engine task. A task authored for invocation by a SOAP client can return the following:

If an Info*Engine group is returned and the SOAP task does not explicitly state its return type, the group is returned to the SOAP client as a single string that contains the Info*Engine XML representation of that group, named using the input $(@FORM[]group_out[0]).

If an error is detected, a SOAP fault is returned to the client. This fault can then be processed by the SOAP client using its own implementation-specific mechanisms. For example, Info*Engine Java EE connector clients receive SOAP faults as Java exceptions; Visual Basic clients can make use of instance variables such as faultcode, faultstring, faultactor, and detail.