String handling in user-defined nodes

Consider issues that relate to string handling when you develop user-defined extensions in the C programming language.

If you are developing user-defined extensions using the Java™ programming language, you can use standard Java string handling methods.

To enable an integration node to handle messages in all languages at the same time, text processing within the integration node is done in UCS-2 Unicode. UCS-2 Unicode character strings are also used across the Java and C language user-defined extension APIs to pass and return character data. Attributes are received in XML configuration messages as character strings, regardless of data type. If the true data type of an attribute is not a string, the cniSetAttribute function must perform the necessary verification and conversion before storing the attribute value. Similarly, when an attribute value is retrieved using cniGetAttribute2, conversion must be performed to a UCS-2 Unicode character string before returning the result.

CciChar defines a 16-bit character with UCS-2 Unicode representation. A CciChar* is a string of such characters terminated with a CciChar of 0. By default, a CciChar is represented by type wchar_t. However, some platforms do not have a convenient way of representing UCS-2 constants in source code, typically because of 4-byte wchar_t or EBCDIC representation. For example, a source-code constant such as L"ABC" expands to 12 bytes on Solaris.

For this reason, WebSphere® IBM® Integration provides the utility functions cciMbsToUcs and cciUcsToMbs. Use these functions, where appropriate, to ensure portability of your user-defined nodes.