Siebel Global Deployment Guide > Overview of Global Deployments > Global Deployment Terminology >

Platform

This topic is part of Global Deployment Terminology.

The platform determines what data can be processed in a Siebel Business Applications deployment. The character set encoding and operating system language of a platform will determine what data can be handled correctly and what data will not be handled correctly by the platform.

This guide uses the term platform in several places to discuss deployment options as well as specific functionality available in Siebel Business Applications.

Siebel Business Applications generally do not support mixed character encoding environments. The reason is that it is not technically possible to manage an environment that uses multiple character set encodings on databases and servers without a genuine risk of losing data in the process.

For example, suppose a database is set up with a Western European character set encoding and a user tries to insert Japanese data through a Siebel Server set up for Japanese. Depending on the actual database, the effect could be that the user's data would be rejected and not stored in the database, or the data could get converted by the database and stored incorrectly as unreadable characters (substitution characters), resulting in loss of the original Japanese data.

Field Size Issues

In some cases, a user might try to enter data into the application and receive an error message saying that the language of the text entered "is not compatible with the database language" or that the length of the text entered "is bigger than the corresponding length allocated in the database."

Such an error might occur when the character set of the data does not match the character set of the database and cannot be converted without data loss. Or, the error might occur when the data string is too long to fit into the database column.

If you have an existing Siebel deployment and upgrade the database default character set to Unicode (any encoding), then all links to other information technology systems must be examined for compatibility. In many cases, data previously encoded in a traditional codepage will now be larger in terms of bytes, and could overflow the fields that are used for transfers. In such cases, Siebel Unicode data values will be truncated, especially if the data value is large enough to approach the maximum defined size of the field.

You must examine the field sizes in tables used by Siebel EAI or Siebel EIM, in any linking or replication software, and in any extension columns that have been added.

Depending on your existing code page, the languages and specific characters representing your data, and the Unicode encoding that you are migrating to, field sizes might need to be enlarged. In some scenarios, field sizes must be doubled.

Customers can set byte limits on columns in the database. At the user interface level, the input size can be controlled to make sure that this column width is not exceeded. In most cases, there is a 1:1 mapping between bytes and characters.

Field Sizes by Database Platforms

When specifying new field sizes, be careful as to whether they must be given in bytes or in characters. Field size units will vary by the RDBMS vendor:

• Oracle Database. Specify field sizes in characters (using character semantics).
• IBM DB2. Specify field sizes in bytes.
• IBM DB2 for z/OS. Specify field sizes in bytes.
• Microsoft SQL Server. Specify field sizes in bytes.

NOTE:  For more information about using IBM DB2 for z/OS, see Implementing Siebel Business Applications on DB2 for z/OS and Siebel Database Upgrade Guide for DB2 for z/OS.

Considerations for Deployments Using Code Page 932 (Shift-JIS)

The following are special considerations for Japanese-language deployments using Shift-JIS, which is also known as Code Page 932 (or 936 on IBM DB2, or JA16SJIS on Oracle Database). It is assumed that the client computer uses the same code page as the database.

• Some Japanese characters require two bytes per character. However, note that user input can include both single-byte and double-byte chars, in combination. Because there is no direct correlation between length limit and byte limit in the case of double-byte languages, it is impossible to provide direct validation of byte limits. For validation purposes, the assumption should be that all characters typed are double-byte. This may leave unused fields when only single-byte characters are used. Custom validation based on analysis of the input string might be able to solve this problem, if a customer chooses to implement this.
• If your deployment is migrating from Code Page 932 (Shift-JIS) to Unicode, then you must be careful with characters entered on a system where the data is stored in Code Page 932.

  Over 300 characters present in Code Page 932 have only one representation in Unicode, so when these characters are moved to a Unicode system, they are converted permanently to the new value used in Unicode. Because of this conversion, users will see that the character they originally entered has been slightly changed, but the meaning should be the same as before.

  An example is the replacement of the WAVE DASH character by the FULL WIDTH TILDE character, often used in expressing appointment times. There is no correction for this situation, because it is a result of the design of both Code Page 932 and Unicode character sets, which are industry standards.

Limitation for Arabic and Numeric Fields

Although the Arabic language is supported, Arabic digits cannot be used in numeric fields in the Siebel Business Applications.