![]() ![]() ![]() ![]() ![]() ![]() ![]() |
This topic contains the following topics:
Oracle SALT allows you to import external Web Services into Tuxedo Domains. To import external Web services into Tuxedo application, a WSDL file must first be loaded and converted. The Oracle SALT WSDL conversion utility, wsdlcvt
, translates each wsdl:operation
into a Oracle SALT proxy service. The translated SALT proxy service can be invoked directly through standard Tuxedo ATMI functions.
Oracle SALT proxy service calls are sent to the GWWS server. The request is translated from Tuxedo typed buffers into the SOAP message, and then sent to the corresponding external Web Service. The response from an external Web Service is translated into Tuxedo typed buffers and returned to the Tuxedo application. The GWWS acts as the proxy intermediary.
If an error occurs during the service call, the GWWS server sets the error status using tperrno
, which can be retrieved by Tuxedo applications. This enables you to detect and handle the SALT proxy service call error status.
Oracle SALT provides a WSDL conversion utility, wsdlcvt, that converts external WSDL files into Tuxedo specific definition files so that you can develop Tuxedo ATMI programs to access services defined in the WSDL file.
Oracle SALT converts WSDL object models into Tuxedo models using the following rules:
Note: | If the operation name exceeds the Tuxedo service name length limitation (15 characters), you must manually set a unique short Tuxedo service name in the metadata respository and set the <Service> tuxedoRef attribute in the WSDF file. |
Note: | For more information, see Oracle SALT Web Service Definition File Reference in the Oracle SALT Reference Guide. |
wsdl:operation
object and its input/output message details are converted as a Tuxedo service definition conforms to Tuxedo Service Metadata Repository input syntax.Table 4-1 lists detailed mapping relationships between the WSDL file and Tuxedo definition files.
The following sections include information on how to invoke the converted SALT proxy service from a Tuxedo application:
Oracle SALT only supports the Tuxedo Request/Response communication patterns for outbound service calls. A Tuxedo application can request the SALT proxy service using the following communication Tuxedo ATMIs:
tpcall(1)
/ tpacall(1)
/ tpgetreply(1)
These basic ATMI functions can be called with a Tuxedo typed buffer as input parameter. The return of the call will also carry a Tuxedo typed buffer. All these buffers will conform to the converted outside Web service interface. tpacall
/tpgetreply
is not related to SOAP async communication.
tpforward(1)
Tuxedo server application can use this function to forward a Tuxedo request to a specified SALT proxy service. The response buffer is sent directly to client application’s response queue as if it’s a traditional native Tuxedo service.
TMQFORWARD
enabled queue-based communication. Tuxedo system server TMQFORWARD can accept queued requests and send them to Oracle SALT proxy services that have the same name as the queue.
Oracle SALT does not support the following Tuxedo communication patterns:
When the GWWS is booted and Oracle SALT proxy services are advertised, you can create a Tuxedo application to call them. To develop a program to access SALT proxy services, do the following:
Note: | The wsdlcvt generated FML32 field table files are always used by GWWS. you must make sure the field name is unique at the system level. If two or more fields are associated with the same field name, change the field name. Do not forget to change Tuxedo Service Metadata Repository definition accordingly. The base number of field index in the generated FML32 field table must be changed from the invalid default value to a correct number to ensure all field index in the table is unique at the entire system level. |
tpcall(1)
or tpacall(1)
for synchronous or asynchronous communication, depending on the requirement.
If the GWWS server encounters an error accessing external Web services, tperrno
is set accordingly so the Tuxedo application can diagnose the failure. Table 4-2 lists possible Oracle SALT proxy service tperrno
values.
All rules listed in used to map WSDL input/output message into Tuxedo Metadata inbuf/outbuf definition. WSDL file default message can also be mapped into Tuxedo Metadata errbuf, with some amendments to the rules:
There are two modes for mapping Metadata errbuf
into SOAP Fault messages: Tux Mode and XSD Mode.
<detail>
element.errbuf
in Metadata, with type=FML32.errbuf
is a FML32 buffer. It is a complete descriptionof the SOAP:Fault message that may appear in correspondence (which is different for SOAP 1.1 and 1.2). The errbuf
definition content is determined by the SOAP version and WSDL fault message both.wsdl:part
defined in a wsdl:fault
message (when wsdl:fault
is present). Each part is defined as a param(field)
in the FML32 field. The mapping rules are the same as for input/output buffer. The difference is that each param requiredcount
is 0, which means it may not appear in the SOAP fault message.soap:fault
message are always defined as a filed in errbuf
, with requiredcount
equal to 1 or 0 (depending on whether the element is required or optional).<detail>
element in the soap fault message into a field in the error buffer.Table 4-3 lists the outbound SOAP fault errbuf definitions.
![]() ![]() ![]() |