Q Overriding Non-Traditional Characters

This appendix discusses how you can override the default characters allowed by XEngine in an Oracle B2B instance.

The appendix includes the following sections:

• Introduction

• Using XEngine to Override Characters

• Overriding: An Example

Q.1 Introduction

XEngine helps Oracle B2B to translate EDI, X12, and HL7 documents from the Native to XML and XML to Native formats.

The system or default characters allowed by XEngine for a particular document standard is located at $ORACLE_HOME/soa/thirdparty/soa-infra/edifecs/XEngine/config/charsets. For example, for EDI X12, the filename is x12.cs, and for EDI EDIFACT, the filename is edifact.cs.

It is recommended that you should not edit any of these XEngine provided files, but use Oracle Document Editor instead to override the default characters used in the system.

Q.2 Using XEngine to Override Characters

To override the default characters used in the system, you need to use Oracle Document Editor to create a user.cs file.

If the user.cs file is not created, you will encounter the following error message:

Error Brief : A data element contains characters not listed in the allowed character set.

To create the user.cs file:

1. In Oracle Document Editor, under the Tools tab, access Character Set Registry.

2. Select the Standard/Version/DocType whose characters you want to override and click the Duplicate button to create a duplicate of the Standard/Version/DocType.

3. Edit the content of this new entry with additional characters (such as ÿ in EDI X12 V4010 850), and then export this new entry to a file called user.cs.

To edit the user.cs file:

1. Open the user.cs file by using Wordpad on Windows.

   A user.cs file for EDIFACT D98A ORDERS will have this section:

   Key="EDIFACT:*:*:*:UNOB" 
   

   You need to further edit this file so that it is specific to the DocType/Version where the non-traditional character needs to be supported.

2. Change the section Key="EDIFACT:*:*:*:UNOB" to Key="EDIFACT:*:98A:ORDERS:UNOB".

   Without this change, XEngine will not pick up the content in user.cs and override the default setting in edifact.cs.

   For an X12 example, Key="X12:*:*:*:*" needs to be changed to Key="X12:*:V4010*:850:*" (V4010* works for both V4010VICS and V4010) and Key="*:*:*:*:*" maps to "GuidelineType:Standard:Version:DocType:CharsetName".

   In most cases, you only need to change the Version or DocType section, or both the sections.

3. Save the user.cs file in the $ORACLE_HOME/soa/thirdparty/soa-infra/edifecs/Common directory for use in runtime.

Q.3 Overriding: An Example

This gives an example of how to override a non-traditional character.

As an example, insert the character ÿ into a 850.xml XDATA file. This character, by default, is not supported by the default x12.cs file. You need to follow the steps listed in Using XEngine to Override Characters to generate a user.cs and place it in $ORACLE_HOME/soa/thirdparty/soa-infra/edifecs/Common.

For the outbound case when using AQ, ensure that the encoding=ISO-8859-1 is used in the property file so that the proper encoding is used to preserve the ÿ character in the transmission to the database. You can find out if this is done correctly by viewing the Application Message payload in the Oracle B2B UI and checking whether the character ÿ is displayed properly, and not as some random character.

With validation turned on and user.cs file in place, the 850.xml will be processed correctly. Without the user.cs in place, you will encounter the following error message:

"Error Brief : A data element contains characters not listed in the allowed character set." 

Finally, if the b2b.encoding=ISO-8859-1 property is set in Fusion Middleware Enterprise Management Control console, you will see that the character ÿ when the emacs editor is used to view the output file. If b2b.encoding is not set, the default UTF-8 character set is used. In this case, you will see the two characters ÿ instead of ÿ using the emacs editor. The reason for this is that the character ÿ is encoded in two bytes in the UTF-8 code page.

You can also test for multi-byte character set inserted into the 850.xml (make sure the multi-byte character is encoded correctly.) In addition, the database should support multi-byte character set. You can check the database character set by issuing the following SQL query:

select value from NLS_DATABASE_PARAMETERS where parameter = 'NLS_CHARACTERSET';