Data Type Mapping and Message Conversion

BEA 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 BEA 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 BEA SALT Message Conversion

BEA SALT message conversion is the message transformation process between SOAP XML data and Tuxedo typed buffer. BEA 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:

BEA SALT encloses Tuxedo buffer content with element <inbuf>, <outbuf> and/or <errbuf> in the SOAP message, the content encluded 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:

The following table compares inbound message conversion process and outbound message conversion process.

Table 2-1 Inbound Message Conversion vs. Outbound Message Conversion
Inbound Message Conversion	Outbound Message Conversion
SOAP message payload is encapsulated with <inbuf>, <outbuf> or <errbuf>	SOAP message payload is the entire <soap:body>
Transformation according to “Tuxedo-to-XML data type mapping rules”	Transformation according to “XML-to-Tuxedo data type mapping rules”
All Tuxedo buffer types are involved	Only Tuxedo FML32 buffer type is involved

Tuxedo-to-XML Data Type Mapping for Tuxedo Services

BEA SALT provides a set of rules for describing Tuxedo typed buffers in an XML document. 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.

Tuxedo Buffer Type

Description

XML Schema Mapping for SOAP Message

STRING

Tuxedo STRING typed buffers are used to store character strings that terminate with a NULL character. Tuxedo STRING typed buffers are self-describing.

xsd:string

In the SOAP message, the XML element that encapsulates the actual string data, must be defined using xsd:string directly.

Notes:

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.
If GWWS server receives a SOAP message other than “UTF-8”, the corresponding string value is in the same encoding.

CARRAY
(Mapping with SOAP Message plus Attachments)

Tuxedo CARRAY typed buffers store character arrays, any of which can be NULL. CARRAY buffers are used to handle data opaquely and are not self-describing.

The CARRAY buffer raw data is carried within a MIME multipart/related message, which is defined in the “SOAP Messages with Attachments’ specification.

The two data formats supported for MIME Content-Type attachments are:

application/octet-stream

For Apache Axis

text/xml

For BEA WebLogic Server

The format depends on which Web service client-side toolkit is used.

Note:

The SOAP with Attachment rule is only interoperable with BEA WebLogic Server and Apache Axis.

Note:

CARRAY data types can be specified with a max byte length. If defined in Tuxedo, the corresponding SOAP message is enforced with this limitation. The GWWS server validates the actual message byte length against the definition in the Tuxedo Service Metadata Repository.

CARRAY
(Mapping with base64Binary)

Tuxedo CARRAY typed buffers store character arrays, any of which can be NULL. CARRAY buffers are used to handle data opaquely and are not self-describing.

xsd:base64Binary

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.

In the SOAP message, the XML element that encapsulates the actual CARRAY data, must be defined with xsd:base64Binary directly.

Note:

CARRAY data type can be specified with a max byte length. If defined in Tuxedo, the corresponding SOAP message is enforced with this limitation. The GWWS server validates the actual message byte length against the definition in the Tuxedo Service Metadata Repository.

MBSTRING

Tuxedo MBSTRING typed buffers are used for multibyte character arrays. Tuxedo MBSTRING buffers consist of the following three elements:

Code-set character encoding
Data length
Character array of the encoding.

xsd:string

The XML Schema built-in type, xsd:string, represents the corresponding type for buffer data stored in a SOAP message.

The GWWS server only accepts “UTF-8” encoded XML documents. If the Web service client wants to access Tuxedo services with MBSTRING buffer, the mbstring payload must be represented as “UTF-8” encoding in the SOAP request message.

Note:

The GWWS server transparently passes the “UTF-8” character set string to the Tuxedo service using MBSTRING Typed buffer format.The actual Tuxedo services handles the UTF-8 string.

For any Tuxedo response MBSTRING typed buffer (with any encoding character set), The GWWS server automatically transforms the string into “UTF-8” encoding and sends it back to the Web service client.

MBSTRING (cont.)

Limitation:

Tuxedo MBSTRING data type can be specified with a max byte length in the Tuxedo Service Metadata Repository. The GWWS server checks the byte length of the converted MBSTRING buffer value.

Note:

Max byte length value is not used to enforce the character number contained in the SOAP message.

XML

Tuxedo XML typed buffers store XML documents.

xsd:anyType

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.

Limitation:

The GWWS server validates that the actual XML data is well-formed. It will not do any other enforcement validation, such as Schema validation.

Only a single root XML buffer is allowed to be stored in the SOAP body; the GWWS server checks for this.

The actual XML data must be encoded using the “UTF-8” character set. Any original XML document prolog information cannot be carried within the SOAP message.

XML data type can specify a max byte data length. If defined in Tuxedo, the corresponding SOAP message must also enforce this limitation.

Note: The BEA 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.

X_C_TYPE

X_C_TYPE buffer types are equivalent to VIEW buffer types.

See VIEW/VIEW32

X_COMMON

X_COMMON buffer types are equivalent to VIEW buffer types, but are used for compatibility between COBOL and C programs. Field types should be limited to short, long, and string

See VIEW/VIEW32

X_OCTET

X_OCTET buffer types are equivalent to CARRAY buffer types

See CARRAY xsd:base64Binary

VIEW/VIEW32

Tuxedo VIEW and VIEW32 typed buffers store C structures defined by Tuxedo applications.

VIEW structures are defined by using VIEW definition files. A VIEW buffer type can define multiple fields.

VIEW supports the following field types:

short
int
long
float
double
char
string
carray

VIEW32 supports all the VIEW field types and mbstring.

Each VIEW or VIEW32 data type is defined as an XML Schema complex type. Each VIEW field should be one or more sub-elements of the XML Schema complex type. The name of the sub-element is the VIEW field name. The occurrence of the sub-element depends on the count attribute of the VIEW field definition. The value of the sub-element should be in the VIEW field data type corresponding XML Schema type.

The the field types and the corresponding XML Schema type are listed as follows:

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

VIEW/VIEW32 (cont.)

For more information, see VIEW/VIEW32 Considerations.

FML/FML32

Tuxedo FML and FML32 type buffers are proprietary BEA Tuxedo system self-describing buffers. Each data field carries its own identifier, an occurrence number, and possibly a length indicator.

FML supports the following field types:

FLD_CHAR
FLD_SHORT
FLD_LONG
FLD_FLOAT
FLD_DOUBLE
FLD_STRING
FLD_CARRAY

FML32 supports all the FML field types and FLD_PTR, FLD_MBSTRING, FLD_FML32, and FLD_VIEW32.

FML/FML32 buffers can only have basic data-dictionary-like definitions for each basic field data. A particular FML/FML32 buffer definition should be applied for each FML/FML32 buffer with a different type name.

Each FML/FML32 field should be one or more sub-elements within the FML/FML32 buffer XML Schema type. The name of the sub-element is the FML field name. The occurrence of the sub-element depends on the count and required count attribute of the FML/FML32 field definition.

The e field types and the corresponding XML Schema type are listed below:

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

FML/FML32

(cont.)

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.

For limitations and considerations regarding mapping FML/FML32 buffers, refer to FML/FML32 Considerations.

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.

The following example depicts the TOUPPER Tuxedo service, which accepts a STRING typed buffer. The SOAP message is as follows:

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.

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.

Tuxedo MBSTRING Typed Buffers

Tuxedo MBSTRING typed buffers are used for multibyte character arrays. Tuxedo MBSTRING typed buffers consist of the following three elements:

Figure 2-1 shows the SOAP message for the MBSERVICE Tuxedo service, which accepts an MBSTRING typed buffer.

Tuxedo XML Typed Buffers

Listing 2-5 shows the SOAP message for the STOCKINQ Tuxedo service, which accepts an XML typed buffer.

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 SOAP message for the MYVIEW Tuxedo service, which accepts a VIEW typed buffer.

VIEW/VIEW32 Considerations

The following considerations apply when converting Tuxedo VIEW/VIEW32 buffers to and from XML.

Tuxedo FML/FML32 Typed Buffers

Tuxedo FML and FML32 typed buffer are proprietary BEA 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-11 shows the SOAP message for the TRANSFER Tuxedo service, which accepts an FML typed buffer.

FML32 Data Mapping Example

Listing 2-13 shows the SOAP message for the TRANSFER Tuxedo service, which accepts an FML32 typed buffer.

FML/FML32 Considerations

The following considerations apply to converting Tuxedo FML/FML32 buffers to and from XML.

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.

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

Custom Typed Buffers

BEA 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.

XML-to-Tuxedo Data Type Mapping for External Web Services

BEA SALT maps each wsdl:message as a Tuxedo FML32 buffer structure. BEA 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.

Table 2-3 Supported XML Schema Built-In Simple Data Type
XML Schema Built-In Simple Type	Tuxedo FML32 Field Data Type	C/C++ Primitive Type In Tuxedo Program	Note
`xsd:byte`	`FLD_CHAR`	`char`
`xsd:unsignedByte`	`FLD_CHAR`	`unsigned char`
`xsd:boolean`	`FLD_CHAR`	`char`	Value Pattern `[ ‘T’ \| ‘F’ ]`
`xsd:short`	`FLD_SHORT`	`short`
`xsd:unsignedShort`	`FLD_SHORT`	`unsigned short`
`xsd:int`	`FLD_LONG`	`long`
`xsd:unsignedInt`	`FLD_LONG`	`unsigned long`
`xsd:long`	`FLD_LONG`	`long`	In a 32-bit Tuxedo program, the C primitive type `long` cannot represent all `xsd:long` valid value.
`xsd:unsignedLong`	`FLD_LONG`	`unsigned long`	In a 32-bit Tuxedo program, the C primitive type `unsigned long` cannot represent all `xsd:long` valid value.
`xsd:float`	`FLD_FLOAT`	`float`
`xsd:double`	`FLD_DOUBLE`	`double`
`xsd:string` (and all `xsd:string` derived built-in type, such as `xsd:token`, `xsd:Name`, etc.)	`FLD_STRING` `FLD_MBSTRING`	`char [ ]` (Null-terminated string)	`xsd:string` can be optionally mapped as `FLD_STRING` or `FLD_MBSTRING` using wsdlcvt.
`xsd:base64Binary`	`FLD_CARRAY`	`char [ ]`
`xsd:hexBinary`	`FLD_CARRAY`	`char [ ]`
All other built-in data types (Data / Time related, decimal / Integer related, anyURI, QName, NOTATION)	`FLD_STRING`	`char [ ]`	You should comply with the value pattern of the corresponding XML built-in data type. Otherwise, server-side Web service will reject the request.

The following samples demonstrate how to prepare data in a Tuxedo program for XML Schema Built-In Simple Types.

XML Schema Built-In Type Sample - xsd:boolean
XML Schema Built-In Type Sample - xsd:unsignedInt
XML Schema Built-In Type Sample - xsd:string
XML Schema Built-In Type Sample - xsd:hexBinary
XML Schema Built-In Type Sample - xsd:date

Table 2-4 XML Schema Built-In Type Sample - xsd:boolean
XML Schema Definition
	<xsd:element name=”flag” type=”xsd:boolean” />
Corresponding FML32 Field Definition (FLD_CHAR)
	# Field_name Field_type Field_flag Field_comments flag char -
C Pseudo Code
	char c_flag; FBFR32 * request; ... c_flag = ‘T’; /* Set True for boolean data / Fadd32( request, `flag`, (char )&c_flag, 0);

Table 2-5 XML Schema Built-In Type Sample - xsd:unsignedInt
XML Schema Definition
	<xsd:element name=”account” type=”xsd:unsignedInt” />
Corresponding FML32 Field Definition (FLD_LONG)
	# Field_name Field_type Field_flag Field_comments account long -
C Pseudo Code
	unsigned long acc; FBFR32 * request; ... acc = 102377; /* Value should not exceed value scope of unsigned int/ Fadd32( request, `account`, (char )&acc, 0);

Table 2-6 XML Schema Built-In Type Sample - xsd:string
XML Schema Definition
	<xsd:element name=”message” type=”xsd:string” />
Corresponding FML32 Field Definition (FLD_MBSTRING)
	# Field_name Field_type Field_flag Field_comments message mbstring -
C Pseudo Code
	FBFR32 * request; FLDLEN32 len, mbsize = 1024; char * msg, * mbmsg; msg = calloc( ... ); mbmsg = malloc(mbsize); ... strncpy(msg, “...”, len); /* The string is UTF-8 encoding / Fmbpack32(“utf-8”, msg, len, mbmsg, &mbsize, 0); / prepare mbstring*/ Fadd32( request, `message`, mbmsg, mbsize);

Table 2-7 XML Schema Built-In Type Sample - xsd:hexBinary
XML Schema Definition
	<xsd:element name=”mem_snapshot” type=”xsd:hexBinary” />
Corresponding FML32 Field Definition (FLD_MBSTRING)
	# Field_name Field_type Field_flag Field_comments mem_snapshot carray -
C Pseudo Code
	FBFR32 * request; FLDLEN32 len; char * buf; buf = calloc( ... ); ... memcpy(buf, “...”, len); /* copy the original memory */ Fadd32( request, `mem_snapshot`, buf, len);

Table 2-8 XML Schema Built-In Type Sample - xsd:date
XML Schema Definition
	<xsd:element name=”IssueDate” type=”xsd:date” />
Corresponding FML32 Field Definition (FLD_STRING)
	# Field_name Field_type Field_flag Field_comments IssueDate string -
C Pseudo Code
	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.

Table 2-9 Supported XML Schema User Defined Data Type
XML Schema User Defined Data Type	Tuxedo FML32 Field Data Type	C/C++ Primitive Type In Tuxedo Program	Note
<xsd:anyType>	FLD_MBSTRING	char []	Tuxedo Programmer should prepare entire XML document enclosing with the element tag.
`<xsd:simpleType>` derived from built-in primitive simple data types	Equivalent FML32 Field Type of the primitive simple type (see Table 2-3)	Equivalent C Primitive Data Type of the primitive simple type (see Table 2-3)	Facets defined with `<xsd:restriction>` are not enforced at Tuxedo side.
`<xsd:simpleType>` defined with `<xsd:list>`	`FLD_MBSTRING`	`char []`	Same as `<xsd:anyType>`. The Schema compliancy is not enforced at Tuxedo side.
`<xsd:simpleType>` defined with `<xsd:union>`	`FLD_MBSTRING`	`char []`	Same as `<xsd:anyType>`. The Schema compliancy is not enforced at Tuxedo side.
`<xsd:complexType>` defined with `<xsd:simpleContent>`	`FLD_MBSTRING`	`char []`	Same as `<xsd:anyType>`. The Schema compliancy is not enforced at Tuxedo side.
`<xsd:complexType>` defined with `<xsd:complexContent>`	`FLD_MBSTRING`	`char []`	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`	`FLD_FML32`	`FBFR32 * embedded fml32 buffer`	Each sub-element of the complex type is defined as an embedded FML32 field.
`<xsd:complexType>` defined with shorthand `<xsd:complexContent>`, sub-elements composited with `choice`	`FML_FML32`	`FBFR32 * embedded fml32 buffer`	Each sub-element of the complex type is defined as an embedded FML32 field. Tuxedo programmer should only add one sub field into the fml32 buffer.

The following samples demonstrate how to prepare data in a Tuxedo program for XML Schema User Defined Data Types:

Table 2-10 XML Schema User Defined Type Sample - xsd:simpleType Derived from Primitive Simple Type
XML Schema Definition
	<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>
Corresponding FML32 Field Definition (FLD_STRING)
	# Field_name Field_type Field_flag Field_comments Grade string -
C Pseudo Code
	char grade[2]; FBFR32 * request; ... grade[0] = ‘A’; grade[1] = ‘\0’; Fadd32( request, `Grade`, (char *)grade, 0);

Table 2-11 XML Schema User Defined Type Sample - xsd:simpleType Defined with xsd:list
XML Schema Definition (Target Namespace “urn:sample.org”)
	<xsd:element name=”Users” type=”namelist” /> <xsd:simpleType name=”namelist”> <xsd:list itemType=”xsd:NMTOKEN”> </xsd:simpleType>
Corresponding FML32 Field Definition (FLD_MBSTRING)
	# Field_name Field_type Field_flag Field_comments Users mbstring -
C Pseudo Code
	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

Table 2-12 WSDL Message Mapping Rules
WSDL Message Definition	Tuxedo Buffer/Field Definition	Note
`<wsdl:input>` message	Tuxedo Request Buffer (Input buffer)
`<wsdl:output>` message	Tuxedo Response Buffer with TPSUCCESS (Output buffer)
`<wsdl:fault>` message	Tuxedo Response Buffer with TPFAIL (error buffer)
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: faultcode string - -	This mapping rule applies for SOAP 1.1 only.
`<faultstring>` in SOAP 1.1 fault message	Mapped as a fixed top level `FLD_STRING` field (faultstring) in the Tuxedo error buffer: faultstring string - -	This mapping rule applies for SOAP 1.1 only.
`<faultactor>` in SOAP 1.1 fault message	Mapped as a fixed top level `FLD_STRING` field (`faultactor`) in the Tuxedo error buffer: `faultactor string - -`	This mapping rule applies for SOAP 1.1 only.
`<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`): `Code fml32 - - Value string - - Subcode string - -`	This mapping rule applies for SOAP 1.2 only.
`<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`): `Reason fml32 - - Text string - -`	This mapping rule applies for SOAP 1.2 only.
`<Node>` in SOAP 1.2 fault message	Mapped as a fixed top level `FLD_STRING` field (`Node`) in the Tuxedo error buffer: `Node string - -`	This mapping rule applies for SOAP 1.2 only.
`<Role>` in SOAP 1.2 fault message	Mapped as a fixed top level `FLD_STRING` field (`Role`) in the Tuxedo error buffer: `Role string - -`	This mapping rule applies for SOAP 1.2 only.
`<detail>` in SOAP fault message	Mapped as a fixed top level `FLD_FML32` field in the Tuxedo error buffer: `detail fml32 - -`	This mapping rule applies for both SOAP 1.1 and SOAP 1.2.
Each message part defined in `<wsdl:fault>`	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)	This mapping rule applies for both SOAP 1.1 and SOAP 1.2.

Programming Web Services

Data Type Mapping and Message Conversion

Overview of Data Type Mapping and Message Conversion

Understanding BEA SALT Message Conversion

Inbound Message Conversion

Outbound Message Conversion

Tuxedo-to-XML Data Type Mapping for Tuxedo Services

Tuxedo STRING Typed Buffers

Tuxedo CARRAY Typed Buffers

Mapping Example Using base64Binary

Mapping Example Using MIME Attachment

Tuxedo MBSTRING Typed Buffers

Tuxedo XML Typed Buffers

Tuxedo VIEW/VIEW32 Typed Buffers

VIEW/VIEW32 Considerations

Tuxedo FML/FML32 Typed Buffers

FML Data Mapping Example

FML32 Data Mapping Example

FML/FML32 Considerations

Tuxedo X_C_TYPE Typed Buffers

Tuxedo X_COMMON Typed Buffers

Tuxedo X_OCTET Typed Buffers

Custom Typed Buffers

XML-to-Tuxedo Data Type Mapping for External Web Services

XML Schema Built-In Simple Data Type Mapping

XML Schema User Defined Data Type Mapping

WSDL Message Mapping