Table of Contents Previous Next PDF


Data Type Mapping and Message Conversion

Data Type Mapping and Message Conversion
This topic contains the following sections:
Overview of Data Type Mapping and Message Conversion
Oracle SALT supports bi-directional data type mapping between WSDL messages and Tuxedo typed buffers. For each service invocation, GWWS server converts each message between Tuxedo typed buffer and SOAP message payload. SOAP message payload is the XML effective data encapsulated within the <soap:body> element. For more information, see Understanding Oracle SALT Message Conversion.
For native Tuxedo services, each Tuxedo buffer type is described using an XML Schema in the SALT generated WSDL document. Tuxedo service request/response buffers are represented in regular XML format. For more information, see Tuxedo-to-XML Data Type Mapping for Tuxedo Services.
For external Web services, each WSDL message is mapped as a Tuxedo FML32 buffer structure. A Tuxedo application invokes SALT proxy service using FML32 buffers as input/output. For more information see, XML-to-Tuxedo Data Type Mapping for External Web Services.
Understanding Oracle SALT Message Conversion
Oracle SALT message conversion is the message transformation process between SOAP XML data and Tuxedo typed buffer. Oracle SALT introduces two types message conversion rules: Inbound Message Conversion and Outbound Message Conversion.
Inbound Message Conversion
Inbound message conversion process is the SOAP XML Payload and Tuxedo typed buffer conversion process conforms to the “Tuxedo-to-XML data type mapping rules”. Inbound message conversion process happens in the following two phases:
Oracle SALT encloses Tuxedo buffer content with element <inbuf>, <outbuf> and/or <errbuf> in the SOAP message, the content included within element <inbuf>, <outbuf> and/or <errbuf> is called “Inbound XML Payload”.
Outbound Message Conversion
Outbound message conversion process is the SOAP XML Payload and Tuxedo typed buffer conversion process conforms to the “Tuxedo-to-XML data type mapping rules”. Outbound message conferring process happens in the following two phases:
Table 2‑1 compares an inbound message conversion process and an outbound message conversion process.
 
Tuxedo-to-XML Data Type Mapping for Tuxedo Services
Oracle SALT provides a set of rules for describing Tuxedo typed buffers in an XML document as shown in Table 2‑2. These rules are exported as XML Schema definitions in SALT WSDL documents. This simplifies buffer conversion and does not require previous Tuxedo buffer type knowledge.
 
The STRING data type can be specified with a max data length in the Tuxedo Service Metadata Repository. If defined in Tuxedo, the corresponding SOAP message also enforces this maximum. The GWWS server validates the actual message byte length against the definition in Tuxedo Service Metadata Repository. A SOAP fault message is returned if the message byte length exceeds supported maximums.
The CARRAY data bytes must be encoded with base64Binary before it can be embedded in a SOAP message. Using base64Binary encoding with this opaque data stream saves the original data and makes the embedded data well-formed and readable.
The XML Schema built-in type, xsd:string, represents the corresponding type for buffer data stored in a SOAP message.
The XML Schema built-in type, xsd:anyType, is the corresponding type for XML documents stored in a SOAP message. It allows you to encapsulate any well-formed XML data within the SOAP message.
Note:
The Oracle SALT WSDL generator will not have xsd:maxLength restrictions in the generated WSDL document, but the GWWS server will validate the byte length according to the Tuxedo Service Metadata Repository definition.
See VIEW/VIEW32
See VIEW/VIEW32
See CARRAY xsd:base64Binary
short maps to xsd:short
int maps to xsd:int
long maps to xsd:long
float maps to xsd:float
double maps to xsd:double
char (defined as byte in Tuxedo Service Metadata Repository definition) maps to xsd:byte
char (defined as char in Tuxedo Service Metadata Repository definition) maps to xsd:string (with restrictions maxlength=1)
string maps to xsd:string
carray maps to xsd:base64Binary
mbstring maps to xsd:string
short maps to xsd:short
int maps to xsd:int
long maps to xsd:long
float maps to xsd:float
double maps to xsd:double
char (defined as byte in Tuxedo Service Metadata Repository definition) maps to xsd:byte
char (defined as char in Tuxedo Service Metadata Repository definition) maps to xsd:string
string maps to xsd:string
carray maps to xsd:base64Binary
mbstring maps to xsd:string
view32 maps to tuxtype:view <viewname>
fml32 maps to tuxtype:fml32 <svcname>_p<SeqNum>
To avoid multiple embedded FML32 buffers in an FML32 buffer, a unique sequence number (<SeqNum>) is used to distinguish the embedded FML32 buffers.
Note:
ptr is not supported.
Tuxedo STRING Typed Buffers
Tuxedo STRING typed buffers are used to store character strings that end with a NULL character. Tuxedo STRING typed buffers are self-describing.
Listing 2‑1 shows a SOAP message for a TOUPPER Tuxedo service example that accepts a STRING typed buffer.
Listing 2‑1 Soap Message for a String Typed Buffer in TOUPPER Service
<?xml … encoding=”UTF-8” ?>
   ……
   <SOAP:body>
      <m:TOUPPER xmlns:m=”urn:......”>
           <inbuf>abcdefg</inbuf>
      </m:TOUPPER>
   </SOAP:body>
 
The XML Schema for <inbuf> is:
<xsd:element name=”inbuf” type=”xsd:string” />
Tuxedo CARRAY Typed Buffers
Tuxedo CARRAY typed buffers are used to store character arrays, any of which can be NULL. They are used to handle data opaquely and are not self-describing. Tuxedo CARRAY typed buffers can map to xsd:base64Binary or MIME attachments. The default is xsd:base64Binary.
Mapping Example Using base64Binary
Listing 2‑2 shows the SOAP message for the TOUPPER Tuxedo service, which accepts a CARRAY typed buffer using base64Binary mapping.
Listing 2‑2 Soap Message for a CARRAY Typed Buffer Using base64Binary Mapping
<SOAP:body>
       <m:TOUPPER xmlns:m=”urn:......”>
              <inbuf>QWxhZGRpbjpvcGVuIHNlc2FtZQ==</inbuf>
       </m:TOUPPER>
</SOAP:body>
 
The XML Schema for <inbuf> is:
<xsd:element name=”inbuf” type=”xsd:base64Binary” />
Mapping Example Using MIME Attachment
Listing 2‑3 shows the SOAP message for the TOUPPER Tuxedo service, which accepts a CARRAY typed buffer as a MIME attachment.
Listing 2‑3 Soap Message for a CARRAY Typed Buffer Using MIME Attachment
MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
    start="<claim061400a.xml@example.com>"
Content-Description: This is the optional message description.

--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <claim061400a.xml@ example.com>

<?xml version='1.0' ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
..
<m:TOUPPER xmlns:m=”urn:…”>
<inbuf href="cid:claim061400a.carray@example.com"/>
</m:TOUPPER>
..
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

--MIME_boundary
Content-Type: text/xml
Content-Transfer-Encoding: binary
Content-ID: <claim061400a. carray @example.com>

...binary carray data…
--MIME_boundary--
The WSDL for carray typed buffer will look like the following:
<wsdl:definitions …>
<wsdl:types …>
<xsd:schema …>
<xsd:element name=”inbuf” type=”xsd:base64Binary” />
</xsd:schema>
</wsdl:types>

……

<wsdl:binding …>
    <wsdl:operation name=”TOUPPER”>
           <soap:operation …>
           <input>
                 <mime:multipartRelated>
                      <mime:part>
                           <soap:body parts=”…” use=”…”/>
                      </mime:part>
                      <mime:part>
                           <mime:content part=”…” type=”text/xml”/>
                      </mime:part>
                 </mime:multipartRelated>
           </input
           ……
    </wsdl:operation>
</wsdl:binding>

</wsdl:definitions>
 
Tuxedo MBSTRING Typed Buffers
Tuxedo MBSTRING typed buffers are used for multibyte character arrays. Tuxedo MBSTRING typed buffers consist of the following three elements:
Note:
Listing 2‑4 shows the SOAP message for the MBSERVICE Tuxedo service, which accepts an MBSTRING typed buffer.
 
Listing 2‑4 SOAP Message for an MBSIRING Buffer
<?xml encoding=”UFT-8”?>
  <SOAP:body>
     <m:MBSERVICE xmlns:m=”http://......”>
         <inbuf>こんにちは</infuf>
     </m:MBSERVICE>
 
The XML Schema for <inbuf> is:
<xsd:element name=”inbuf” type=”xsd:string” />
WARNING:
If you use another character set conversion engine, the EUC-JP or Shift-JIS multibyte output for this character may be different. For example, the Java il8n character conversion engine, converts this symbol to UTF-16 0x2014. The result is the also same when converting to UTF-8, which is the Oracle SALT default.
If you use another character conversion engine and Japanese "—" is included in MBSTRING, TUXEDO server-side MBSTRING auto-conversion cannot convert it back into Shift-JIS or EUC-JP.
Tuxedo XML Typed Buffers
Tuxedo XML typed buffers store XML documents.
Listing 2‑5 shows the Stock Quote XML document.
Listing 2‑6 shows the SOAP message for the STOCKINQ Tuxedo service, which accepts an XML typed buffer.
Listing 2‑5 Stock Quote XML Document
<?xml version="1.0" encoding="UTF-8"?>
<!-- "Stock Quotes". -->
<stockquotes>
  <stock_quote>
     <symbol>BEAS</symbol>
     <when>
       <date>01/27/2001</date>
       <time>3:40PM</time>
     </when>
     <change>+2.1875</change>
     <volume>7050200</volume>
  </stock_quote>
</stockquotes>
 
Then part of the SOAP message will look like the following:
Listing 2‑6 SOAP Message for an XML Buffer
<SOAP:body>
       <m: STOCKINQ xmlns:m=”urn:......”>
       <inbuf>
       <stockquotes>
              <stock_quote>
                     <symbol>BEAS</symbol>
                     <when>
                     <date>01/27/2001</date>
                     <time>3:40PM</time>
                     </when>
                     <change>+2.1875</change>
                     <volume>7050200</volume>
              </stock_quote>
       </stockquotes>
       </inbuf>
       </m: STOCKINQ >
</SOAP:body>
 
The XML Schema for <inbuf> is:
<xsd:element name=”inbuf” type=”xsd:anyType” />
Note:
For example, if a Tuxedo service returns a buffer having a default namespace to the GWWS server as shown in Listing 2‑7, the GWWS server converts the default namespace to a regular name as shown in Listing 2‑8.
Listing 2‑7 Default Namespace Before Sending to GWWS Server
<Configuration xmlns="http://www.bea.com/Tuxedo/Salt/200606">
       <Servicelist id="simpapp">
              <Service name="toupper"/>
       </Servicelist>
       <Policy/>
       <System/>
       <WSGateway>
          <GWInstance id="GWWS1">
              <HTTP address="//myhost:8080"/>
         </GWInstance>
       </WSGateway>
</Configuration>
 
Listing 2‑8 GWWS Server Converts Default Namespace to Regular Name
       <dom0:Configuration
       xmlns:dom0="http://www.bea.com/Tuxedo/Salt/200606">
              <dom0:Servicelist dom0:id="simpapp">
                     <dom0:Service dom0:name="toupper"/>
              </dom0:Servicelist>
              <dom0:Policy></<dom0:Policy>
              <dom0:System></<dom0:System>
              <dom0:WSGateway>
                <dom0:GWInstance dom0:id="GWWS1">
                     <dom0:HTTP dom0:address="//myhost:8080"/>
                </dom0:GWInstance>
              </dom0:WSGateway>
       </dom0:Configuration>
 
Tuxedo VIEW/VIEW32 Typed Buffers
Tuxedo VIEW and VIEW32 typed buffers are used to store C structures defined by Tuxedo applications. You must define the VIEW structure with the VIEW definition files. A VIEW buffer type can define multiple fields.
Listing 2‑9 shows the MYVIEW VIEW definition file.
Listing 2‑10 shows the SOAP message for the MYVIEW Tuxedo service, which accepts a VIEW typed buffer.
Listing 2‑9 VIEW Definition File for MYVIEW Service
VIEW MYVIEW
#type     cname       fbname       count       flag       size       null
float     float1       -            1           -          -          0.0
double    double1      -            1           -          -          0.0
long      long1        -            3           -          -          0
string    string1      -            2           -          20        '\0'
END
 
Listing 2‑10 SOAP Message for a VIEW Typed Buffer
<SOAP:body>
       <m: STOCKINQ xmlns:m=”http://......”>
              <inbuf>
                     <float1>12.5633</float1>
                     <double1>1.3522E+5</double1>
                     <long1>1000</long1>
                     <long1>2000</long1>
                     <long1>3000</long1>
                     <string1>abcd</string1>
                     <string1>ubook</string1>
              </inbuf>
       </m: STOCKINQ >
</SOAP:body>
 
The XML Schema for <inbuf> is shown in Listing 2‑11.
Listing 2‑11 XML Schema for a VIEW Typed Buffer
<xsd:complexType name=” view_MYVIEW”>
  <xsd:sequence>
       <xsd:element name=”float1” type=”xsd:float” />
       <xsd:xsd:element name=”double1” type=”xsd:double” />
       <xsd:element name=”long1” type=”xsd:long” minOccurs=”3” />
       <xsd:element name=”string1” type=”xsd:string minOccurs=”3” />
  </xsd:sequence>
</xsd: complexType >
<xsd:element name=”inbuf” type=”tuxtype:view_MYVIEW” />
 
VIEW/VIEW32 Considerations
The following considerations apply when converting Tuxedo VIEW/VIEW32 buffers to and from XML.
If an inconsistency is found, the GWWS server cannot start. Inconsistency messages are printed in the ULOG file.
tmwsdlgen also provides strong consistency checking between the Tuxedo Service Metadata Repository VIEW/VIEW32 parameter definition and the VIEW/VIEW32 definition file at start up. If an inconsistency is found, the GWWS server will not start. Inconsistency messages are printed in the ULOG file.
If the VIEW definition file cannot be loaded, tmwsdlgen attempts to use the Tuxedo Service Metadata Repository definitions to compose the WSDL document.
Because dec_t is not supported, if you define VIEW fields with type dec_t, the service cannot be exported as a Web service and an error message is generated when the Oracle SALT configuration file is loading.
If the GWWS server runs in 32-bit mode, and the Web service client sends xsd:long typed data that exceeds the 32-bit value range, you may get a SOAP fault.
Tuxedo FML/FML32 Typed Buffers
Tuxedo FML and FML32 typed buffer are proprietary Oracle Tuxedo system self-describing buffers. Each data field carries its own identifier, an occurrence number, and possibly a length indicator.
FML Data Mapping Example
Listing 2‑12 shows the SOAP message for the TRANSFER Tuxedo service, which accepts an FML typed buffer.
The request fields for service LOGIN are:
ACCOUNT_ID 1 long /* 2 occurrences, The withdrawal account is 1st, and the deposit account is 2nd */
AMOUNT 2 float /* The amount to transfer */
Part of the SOAP message is as follows:
Listing 2‑12 SOAP Message for an FML Typed Buffer
<SOAP:body>
       <m:TRANSFER xmlns:m=”urn:......”>
              <inbuf>
                     <ACCOUNT_ID>40069901</ACCOUNT_ID>
                     <ACCOUNT_ID>40069901</ACCOUNT_ID>
                     <AMOUNT>200.15</AMOUNT>
              </inbuf>
       </m:TRANSFER >
</SOAP:body>
 
The XML Schema for <inbuf> is shown in Listing 2‑13.
Listing 2‑13 XML Schema for an FML Typed Buffer
<xsd:complexType name=” fml_TRANSFER_In”>
  <xsd:sequence>
       <xsd:element name=”ACCOUNT_ID” type=”xsd:long” minOccurs=”2”/>
       <xsd:element name=” AMOUNT” type=”xsd:float” />
  </xsd:sequence>
</xsd: complexType >
<xsd:element name=”inbuf” type=”tuxtype: fml_TRANSFER_In” />
 
FML32 Data Mapping Example
Listing 2‑14 shows the SOAP message for the TRANSFER Tuxedo service, which accepts an FML32 typed buffer.
The request fields for service LOGIN are:
CUST_INFO 1 fml32 /* 2 occurrences, The withdrawal customer is 1st, and the deposit customer is 2nd */
ACCOUNT_INFO 2 fml32 /* 2 occurrences, The withdrawal account is 1st, and the deposit account is 2nd */
AMOUNT 3 float /* The amount to transfer */
Each embedded CUST_INFO includes the following fields:
CUST_NAME       10       string
CUST_ADDRESS    11       carray
CUST_PHONE      12       long
Each embedded ACCOUNT_INFO includes the following fields:
ACCOUNT_ID       20       long
ACCOUNT_PW       21       carray
Part of the SOAP message will look as follows:
Listing 2‑14 SOAP Message for Service with FML32 Buffer
<SOAP:body>
   <m:STOCKINQ xmlns:m=”urn:......”>
       <inbuf>
              <CUST_INFO>
                     <CUST_NAME>John</CUST_NAME>
                     <CUST_ADDRESS>Building 15</CUST_ADDRESS>
                     <CUST_PHONE>1321</CUST_PHONE>
              </CUST_INFO>
              <CUST_INFO>
                     <CUST_NAME>Tom</CUST_NAME>
                     <CUST_ADDRESS>Building 11</CUST_ADDRESS>
                     <CUST_PHONE>1521</CUST_PHONE>
              </CUST_INFO>
              <ACCOUNT_INFO>
                     <ACCOUNT_ID>40069901</ACCOUNT_ID>
                     <ACCOUNT_PW>abc</ACCOUNT_PW>
              </ACCOUNT_INFO>
              <ACCOUNT_INFO>
                     <ACCOUNT_ID>40069901</ACCOUNT_ID>
                     <ACCOUNT_PW>zyx</ACCOUNT_PW>
              </ACCOUNT_INFO>

              <AMOUNT>200.15</AMOUNT>
       </inbuf>
   </m: STOCKINQ >
</SOAP:body>
 
The XML Schema for <inbuf> is shown in Listing 2‑15.
Listing 2‑15 XML Schema for an FML32 Buffer
<xsd:complexType name=”fml32_TRANSFER_In”>
  <xsd:sequence>
     <xsd:element name=”CUST_INFO” type=”tuxtype:fml32_TRANSFER_p1” minOccurs=”2”/>
     <xsd:element name=”ACCOUNT_INFO” type=”tuxtype:fml32_TRANSFER_p2” minOccurs=”2”/>
     <xsd:element name=”AMOUNT” type=”xsd:float” />
  /xsd:sequence>
</xsd:complexType >

<xsd:complexType name=”fml32_TRANSFER_p1”>
     <xsd:element name=”CUST_NAME” type=”xsd:string” />
     <xsd:element name=”CUST_ADDRESS” type=”xsd:base64Binary” />
     <xsd:element name=”CUST_PHONE” type=”xsd:long” />
</xsd:complexType>

<xsd:complexType name=”fml32_TRANSFER_p2”>
     <xsd:element name=”ACCOUNT_ID” type=”xsd:long” />
     <xsd:element name=”ACCOUNT_PW” type=”xsd:base64Binary” />
</xsd:complexType>

<xsd:element name=”inbuf” type=”tuxtype: fml32_TRANSFER_In” />
 
FML/FML32 Considerations
The following considerations apply to converting Tuxedo FML/FML32 buffers to and from XML.
FML32 Field type FLD_PTR is not supported.
If an FML/32 field is found that is not in accordance with the environment setting, or the field table field data type definition is different from the parameter data type definition in the Tuxedo Service Metadata Repository, the GWWS cannot start. Inconsistency messages are printed in the ULOG file.
The tmwsdlgen command checks for consistency between the Tuxedo Service Metadata Repository FML/FML32 parameter definition and FML/FML32 definition file. If inconsistencies are found, it issue a warning and allow inconsistencies.
If an FML/32 field is found that is not in accordance with the environment setting, or the field table field data type definition is different from the parameter data type definition in the Tuxedo Service Metadata Repository, tmwsdlgen attempts to use Tuxedo Service Metadata Repository definitions to compose the WSDL document.
Tuxedo primary data type “long” is indefinite between 32-bit and 64-bit scope according to different platforms. But the corresponding xsd:long schema type is used to describe 64-bit numeric value. The following scenario generates a SOAP fault:
The GWWS runs in 32-bit mode, and a Web service client sends a xsd:long typed data which exceeds the 32-bit value range.
Tuxedo X_C_TYPE Typed Buffers
Tuxedo X_C_TYPE typed buffers are equivalent, and have a similar WSDL format to, Tuxedo VIEW typed buffers.They are transparent for SOAP clients. However, even though usage is similar to the Tuxedo VIEW buffer type, SALT administrators must configure the Tuxedo Service Metadata Repository for any particular Tuxedo service that uses this buffer type.
Note:
Tuxedo X_COMMON Typed Buffers
Tuxedo X_COMMON typed buffers are equivalent to Tuxedo VIEW typed buffers. However, they are used for compatibility between COBOL and C programs. Field types should be limited to short, long, and string.
Tuxedo X_OCTET Typed Buffers
Tuxedo X_OCTET typed buffers are equivalent to CARRAY.
Note:
Tuxedo X_OCTET typed buffers can only map to xsd:base64Binary type. SALT 1.1 does not support MIME attachment binding for Tuxedo X_OCTET typed buffers.
Custom Typed Buffers
Oracle SALT provides a plug-in mechanism that supports custom typed buffers. You can validate the SOAP message against your own XML Schema definition, allocate custom typed buffers, and parse data into the buffers and other operations.
XML Schema built-in type xsd:anyType is the corresponding type for XML documents stored in a SOAP message. While using custom typed buffers, you should define and represent the actual data into an XML format and transfer between the Web service client and Tuxedo Web service stack. As with XML typed buffers, only a single root XML buffer can be stored in the SOAP body. The GWWS checks this for consistency.
For more plug-in information, see Using Oracle SALT Plug-Ins on page 5‑1.
XML-to-Tuxedo Data Type Mapping for External Web Services
Oracle SALT maps each wsdl:message as a Tuxedo FML32 buffer structure. Oracle SALT defines a set of rules for representing the XML Schema definition using FML32. To invoke external Web Services, customers need to understand the exact FML32 structure that converted from the external Web Service XML Schema definition of the corresponding message.
The following sections describe detailed WSDL message to Tuxedo FML32 buffer mapping rules:
XML Schema Built-In Simple Data Type Mapping
Table 2‑3 shows the supported XML Schema Built-In Simple Data Type and the corresponding Tuxedo FML32 Field Data Type.
 
In a 32-bit Tuxedo program, the C primitive type long cannot represent all xsd:long valid value.
In a 32-bit Tuxedo program, the C primitive type unsigned long cannot represent all xsd:long valid value.
(and all xsd:string derived built-in type, such as xsd:token, xsd:Name, etc.)
xsd:string can be optionally mapped as FLD_STRING or FLD_MBSTRING using wsdlcvt.
The following samples demonstrate how to prepare data in a Tuxedo program for XML Schema Built-In Simple Types.
 
<xsd:element name=”flag” type=”xsd:boolean” />
char c_flag;
FBFR32 * request;
...
c_flag = ‘T’; /* Set True for boolean data */
Fadd32( request, flag, (char *)&c_flag, 0);
 
<xsd:element name=”account” type=”xsd:unsignedInt” />
unsigned long acc;
FBFR32 * request;
...
acc = 102377; /* Value should not exceed value scope of unsigned int*/
Fadd32( request, account, (char *)&acc, 0);
 
<xsd:element name=”message” type=”xsd:string” />
 
<xsd:element name=”mem_snapshot” type=”xsd:hexBinary” />
FBFR32 * request;
FLDLEN32 len;
char * buf;
buf = calloc( ... );
...
memcpy(buf, “...”, len); /* copy the original memory */
Fadd32( request, mem_snapshot, buf, len);
 
<xsd:element name=”IssueDate” type=”xsd:date” />
FBFR32 * request;
char date[32];
...
strcpy(date, “2007-06-04+8:00”); /* Set the date value correctly */
Fadd32( request, IssueDate, date, 0);
XML Schema User Defined Data Type Mapping
Table 2‑9 lists the supported XML Schema User Defined Simple Data Type and the corresponding Tuxedo FML32 Field Data Type.
 
<xsd:simpleType> derived from built-in primitive simple data types
Facets defined with <xsd:restriction> are not enforced at Tuxedo side.
<xsd:simpleType> defined with <xsd:list>
Same as <xsd:anyType>. The Schema compliancy is not enforced at Tuxedo side.
<xsd:simpleType> defined with <xsd:union>
Same as <xsd:anyType>. The Schema compliancy is not enforced at Tuxedo side.
<xsd:complexType> defined with <xsd:simpleContent>
Same as <xsd:anyType>. The Schema compliancy is not enforced at Tuxedo side.
<xsd:complexType> defined with <xsd:complexContent>
Same as <xsd:anyType>. The Schema compliancy is not enforced at Tuxedo side.
<xsd:complexType> defined with shorthand <xsd:complexContent>, sub-elements composited with sequence or all
<xsd:complexType> defined with shorthand <xsd:complexContent>, sub-elements composited with choice
The following samples demonstrate how to prepare data in a Tuxedo program for XML Schema User Defined Data Types:
 
<xsd:element name=”Grade” type=”Alphabet” />
<xsd:simpleType name=”Alphabet”>
<xsd:restriction base=”xsd:string”>
<xsd:maxLength value=”1” />
<xsd:pattern value=”[A-Z]” />
</xsd:restriction>
</xsd:simpleType>
char grade[2];
FBFR32 * request;
...
grade[0] = ‘A’; grade[1] = ‘\0’;
Fadd32( request, Grade, (char *)grade, 0);
 
<xsd:element name=”Users” type=”namelist” />
<xsd:simpleType name=”namelist”>
<xsd:list itemType=”xsd:NMTOKEN”>
</xsd:simpleType>
char * user[5];
char users[...];
char * mbpacked;
FLDLEN32 mbsize = 1024;
FBFR32 * request;
...
sprintf(users, “<n1:Users xmlns:n1=\”urn:sample.org\”>”);
for ( i = 0 ; i < 5 ; i++ ) {
strcat(users, user[i]);
strcat(users, “ “);
}
strcat(users, “</n1:Users>“);
...
mbpacked = malloc(mbsize);
/* prepare mbstring*/
Fmbpack32(“utf-8”, users, strlen(users), mbpacked, &mbsize, 0);
Fadd32( request, Users, mbpacked, mbsize);
WSDL Message Mapping
Tuxedo FML32 buffer type is always used in mapping WSDL messages.
Table 2‑12 lists the WSDL message mapping rules defined by Oracle SALT.
 
<wsdl:input> message
<wsdl:fault> message
Each message part defined in <wsdl:input> or <wsdl:output>
Mapped as top level field in the Tuxedo FML32 buffer. Field type is the equivalent FML32 field type of the message part XML data type. (See Table 2‑3 and Table 2‑9)
<faultcode> in SOAP 1.1 fault message
Mapped as a fixed top level FLD_STRING field (faultcode) in the Tuxedo error buffer:
<faultstring> in SOAP 1.1 fault message
Mapped as a fixed top level FLD_STRING field (faultstring) in the Tuxedo error buffer:
<faultactor> in SOAP 1.1 fault message
Mapped as a fixed top level FLD_STRING field (faultactor) in the Tuxedo error buffer:
<Code> in SOAP 1.2 fault message
Mapped as a fixed top level FLD_FML32 field (Code) in the Tuxedo error buffer, which containing two fixed sub FLD_STRING fields (Value and Subcode):
<Reason> in SOAP 1.2 fault message
Mapped as a fixed top level FLD_FML32 field (Reason) in the Tuxedo error buffer, which containing zero or more fixed sub FLD_STRING field (Text):
<Node> in SOAP 1.2 fault message
Mapped as a fixed top level FLD_STRING field (Node) in the Tuxedo error buffer:
<Role> in SOAP 1.2 fault message
Mapped as a fixed top level FLD_STRING field (Role) in the Tuxedo error buffer:
<detail> in SOAP fault message
Mapped as a fixed top level FLD_FML32 field in the Tuxedo error buffer:
Mapped as a sub field of “detail” field in the Tuxedo FML32 buffer. Field type is the equivalent FML32 field type of the message part XML data type. (See Table 2‑3 and Table 2‑9)
 

Copyright © 1994, 2017, Oracle and/or its affiliates. All rights reserved.