Oracle WebLogic Tuxedo Connector provides a property that provides an alternate method to compile FML tables. You may need to use the DynRdHdr utility if:

• You are using very large FML tables and the .java method created by the mkfldclass32 class exceeds the internal Java Virtual Machine limit on the total complexity of a single class or interface.

• You are using very large FML tables and are unable to load the class created when compiling the .java method.

Use the following steps to use the DynRdHdr property when compiling your FML tables:

1. Convert the field table definition into Java source files.

   java -DDynRdHdr=Path_to_Your_FML_Table weblogic.wtc.jatmi.mkfldclass32 userTable
   

   The arguments for this command are defined as follows:

   Table 7-1 Argument

   Attribute	Description
   -DDynRdHdr	Oracle WebLogic Tuxedo Connector property used to compile an FML table.
   Path_to_Your_FML_Table	Path name of your FML table. This may be either a fully qualified path or a relative path that can be found as a resource file using the server's CLASSPATH.
   weblogic.wtc.jatmi.mkfldclass32	This class is a utility function that reads an FML32 Field Table and produces a Java file which implements the FldTbl interface.
   userTable	Name of the .java method created by the mkfldclass32 class.

2. Compile the userTable file using the following command:

   javac userTable.java

3. Add the userTable.class file to your application CLASSPATH.

4. Update the WTCResources MBean to reflect the fully qualified location of the userTable.class file.

5. Target your WTC server. The userTable.class is loaded when the WTCServer service starts.

Once you have created the userTable.class file, you can modify the FML table and deploy the changes without having to manually create an updated userTable.class. When the WTC server is started, Oracle WebLogic Tuxedo Connector will load the updated FML table using the location specified in the Resources tab of your WTC server configuration. If the Path_to_Your_FML_Table attribute changes, you will need to use the preceding procedure to update your userTable.java and userTable.class files.

To gain TypedFML32 performance improvements, you can choose to give size hints to TypedFML32 constructors. There are two parameters that are available to those constructor:

• A parameter that hints for maximum number of fields. This includes all the occurrences.

• A parameter for the total number of field IDs used in the buffer.

For instance, a field table used by the buffer contains 20 field IDs, and each field can occur 20 times. In this case, the first parameter should be 400 for the maximum number of fields. The second parameter should be 20 for the total number of field IDs.

TypeFML32 mybuffer = new TypeFML32(400, 20); 

If you have an extremely small buffer, use those constructor without hints. An example of an extremely small buffer is a buffer with less than 16 total occurrences. If the buffer is extremely large, for example contains more than 250000 total field occurrences, then the application should consider splitting it into several buffers smaller than 250000 total field occurrences.

The message payload is translated using the Oracle WebLogic Tuxedo Connector internal FML32/XML translator. Fields are converted field-by-field values without knowledge of the message structure (hierarchy) and repeated grouping.

In order to convert an FML32 buffer to XML, the tBridge pulls each instance of each field in the FML32 buffer, converts it to a string, and places it within a tag consisting of the field name. All of these fields are placed within a tag consisting of the service name. For example, an FML32 buffer consisting of the following fields:

NAME          JOE
ADDRESS       CENTRAL CITY
PRODUCTNAME   BOLT
PRICE         1.95
PRODUCTNAME   SCREW
PRICE         2.50

The resulting XML buffer would be:

<FML32>
  <NAME>JOE</NAME>
  <ADDRESS>CENTRAL CITY</ADDRESS>
  <PRODUCTNAME>BOLT</PRODUCTNAME>
  <PRODUCTNAME>SCREW</PRODUCTNAME>
  <PRICE>1.95</PRICE>
  <PRICE>2.50</PRICE>
</FML32>

Remember to consider the following information when working with FML32:

• For XML input, the root element is required but ignored.

• For XML output, the root element is always <FML32>.

• The field table names must be loaded as described in FML Field Table Administration.

• The tBridge translator is capable of only "flat" or linear grouping. This means that information describing FML32 ordering is not maintained, therefore buffers that contain a series of repeating data could be presented in an unexpected fashion. For example, consider a FML32 buffer that contains a list of parts and their associated price. The expectation would be PART A, PRICE A, PART B, PRICE B, etc. however since there is no structural group information contained within the tBridge, the resulting XML could be PART A, PART B, etc., PRICE A, PRICE B, etc.

• When translating XML into FML32, the translator ignores STRING values. For example, <STRING></STRING> is skipped in the resulting FML32 buffer. All other types cause WTC to log an error resulting in translation failure.

• Embedded FML is not supported in this release.

• Embedded VIEW fields within FML32 buffers are supported in this release.

• TypedCArray is supported for FML/FML32 to XML conversion. Select from the following list of supported field types:

  • SHORT

  • LONG

  • CHAR

  • FLOAT

  • DOUBLE

  • STRING

  • CARRAY

  • INT (FML32)

  • DECIMAL (FML32)

• If you need to pass binary data, encode to a field type of your choice and decode the XML on the receiving side.

• If you need to use CARRAY fields in an XML input buffer, you must first encode the content using base64. You must decode the base64 data after it is received and before it is processed by an application.

The FLD_MBSTRING field in FML32 is not supported by the XmlFmlCnv.FML32toXML method in this release.

When an Oracle Tuxedo message that contains an MBSTRING data is sent to another Oracle Tuxedo domain, TypedMBString uses the conversion function of java.lang.String class to convert between Unicode and an external encoding. The TypedMBString has a codeset encoding name associated to the string data.

When a TypedMBString object is created by a WTC application code, the encoding name is set to null. The null value of the encoding name means that the default encoding name is used for Unicode string to byte array conversion while sending the MBSTRING data to a remote domain. By default, the Java's default encoding name for byte array string is used for the default encoding name.You can specify encoding or accept the default encoding. The following order defines the order of precedence for TypedMBString.

1. Specify the encoding name by setMBEncoding() method.

2. Specify the encoding name through the setDefaultMBEncoding() method of weblogic.wtc.jatmi.MBEncoding class.

3. Specify the encoding name through the RemoteMBEncoding attribute of the WTCResourcesMBean.

4. MBENCODINGPROPERTY system property value.

5. Accept the Java default encoding name.

When an Oracle Tuxedo message that contains an MBSTRING data is received from a remote domain, the following actions take place.

1. WTC determines the encoding of the MBSTRING data by the codeset tcm in the received message.

2. WTC creates a TypedMBString object.

   A TypedMBString object can be used almost identically as a TyepdString object in WTC application code. However, the TypedMBString has a codeset encoding name associated to the string data.

3. WTC passes the TypedMBString object to the WTC application code. The application code knows the encoding of the received MBSTRING data by the instance method getMBEncoding().

1. Specify the encoding name by setMBEncoding() method of the TypedMBString object for the field.
2. Specify the encoding name by setMBEncoding() method of the TypedFML32 object.
3. Specify the encoding name through the setDefaultMBEncoding() method of weblogic.wtc.jatmi.MBEncoding class.
4. Specify the encoding name through the RemoteMBEncoding attribute of the WTCResourcesMBean.
5. MBENCODINGPROPERTY system property value.
6. Accept the Java default encoding name.

   Note:

   The following methods must be updated when using FLD_MBSTRING: Fldtype(), Fchg(), Fadd(), Fget(), and Fdel().

   The on-demand encoding methods and auto-conversion methods needed in Oracle Tuxedo, such as Fmbpack32() and Fmbunpack32() are not needed by Oracle WebLogic Tuxedo Connector.