Encoding is processed within the WebSphere Business Integration environment at three levels:
The content data level processes the business object runtime instance data. The meta and configuration level processes the data used by connectors to establish and maintain communication between external applications and the WebSphere Business Integration environment. The log and trace data level processes informational messages logged into various logs and trace files. Some adapters are more flexible than others with encoding support. For example, an XML connector has the ability to process the encoding specification in the XML file headers that provides full encoding support. A connector for SAP, on the other hand, has limited encoding support provided by the SAP client API. For content level as well as the meta and configuration data level, if the connector does provide a configuration option, then the locale setting is overwritten by the encoding specification option. For the log and trace data level, the default DOS prompt code set is used for encoding flashed data.
There is no uniform approach for content data encoding support among connectors. There are three basic approaches that can be used to deal with the variety of ways connectors handle content data encoding support. These approaches are:
These three approaches provide a means of handling content data by the adapters (see your adapter guide to find out what approach is applicable for your specific adapter).
The encoding support for meta-configuration data often depends on the capabilities of the middleware adapter code used for setting up a connection to an external application.
The meta and configuration data encoded in ASCII in WebSphere Tools (as part of the adapter template or supported business object templates) is stored in the repository as Unicode. At runtime, this data is used as an argument for either native Java APIs or third party APIs to establish a communication link with an external source. The middleware used for establishing a communication link in the adapter code can range from native Java APIs or packages, (for example, Email or WebSphere MQ connectors), to third party APIs (for example, PeopleSoft). In addition, there can be several layers of middleware separating the adapter Java code from the external source as in the case of JText and the File System folder located on a non-Windows system. If the File System folder is accessed from the Windows process, the call issued from the Java API might be indirectly serviced by the software allowing the mounting of non-Windows partitions instead of the target Windows File System. Because neither native Java APIs, third party API, nor middleware is guaranteed to support explicit encoding specification, WebSphere Business Integration products only support Unicode encoding for meta and configuration bidirectional data.
By default, the encoding of the bidirectional data flashed out into the log and trace files is identical to the code page of the DOS prompt that invokes the process. Unfortunately, the default DOS prompt code page associated with the bidirectional locales for Arabic and Hebrew is not the same as the standard code page for those languages on the Windows operating system (1256 and 1255). Consequently, if the DOS prompt code page for the WebSphere Business Integration Java processes is not changed, the bidirectional data flashed out by those processes into the log trace files is not correctly displayed in most Windows viewers using standard code pages for bidirectional languages data display (see Changing your DOS prompt code page in the System Installation Guide for Windows for more information).