4.4.6 Using the MBSTRING Buffer Type

Starting with Tuxedo 9.0, Jolt supports the MBSTRING buffer type which is already supported by Tuxedo ATMI as of Tuxedo 8.1.

Since Java uses Unicode as the standard for multi byte character encoding and provides String class for handling Unicode string data, Jolt MBSTRING support will use the String class as the MBSTRING container on the Java client side. Jolt automatically converts the Unicode MBSTRING data in a String object between byte array MBSTRING data, which is the ATMI’s MBSTRING representation, when the data is transferred between a Jolt client and a Tuxedo server.

The following methods are added to bea.jolt.Message interface and to bea.jolt.JoltMessage and bea.jolt.JoltRemoteService classes.

addMBString
setMBString
setMBStringItem
getMBStringDef
getMBStringItemDef

The usage of the MBSTRING buffer type is very similar to the STRING buffer type except that the buffer type specified in the Metadata Repository Editor is “MBSTRING” and the Java methods used for setting and getting the MBSTRING data are listed above.

In addition, the following Java system properties are used to specify the character encoding name for MBSTRING data sent to Tuxedo servers.

bea.jolt.mbencoding
The Tuxedo encoding name used for converting Unicode MBSTRING data to the corresponding byte array MBSTRING data while sending MBSTRING data to a Tuxedo server. If this property is not specified, the Java default character encoding name is used and mapped to the corresponding Tuxedo encoding name. For example, the default Japanese Windows encoding name “MS932” should be mapped to the corresponding Tuxedo encoding name “CP932” and specified in this property.
bea.jolt.mbencodingmap
The full path name for the file which specifies character encoding name mapping between Jolt clients and Tuxedo servers. This mapping is necessary because the character encoding name for the same character encoding is sometimes different between Java and Tuxedo. For example, the default Japanese Windows encoding name is MS932 in Java, but in Tuxedo it is CP932. If this property is not specified, mapping is not done.
This means that the Java character encoding name is directly set in the MBSTRING data sent to the Tuxedo server, and the encoding name which is set in the received MBSTRING data from the Tuxedo server is used as the Java encoding name. This may cause a conversion error if the encoding name is not supported by Java or Tuxedo.
To specify the bea.jolt.mbencoding or bea.jolt.mbencodingmap, jolti18n.jar must be included in the CLASSPATH. If jolti18n.jar is not included in the CLASSPATH, the encoding name is set to “ISO-8859-1” and no encoding name is done between Java and Tuxedo even if these properties are specified in the Java command line.