In this Document
Purpose
Last Review Date
Instructions for the Reader
Troubleshooting Details
1. The Planning Interface
2. The Relational Database Server
3. The Essbase Server
4. The Planning Refresh
Information in this document applies to any platform.
Not every release of Planning is fully localized. However, the web interface to Planning can be customized to use a language other than English even in non-localized releases, although the logs, utilities, and error messages in non-localized releases will be in English. All versions of Planning support "Level 0 internationalization", meaning that Planning will run on a non-English version of an operating system (e.g. the French version of Windows 2003 Server) .
Fully localized Planning releases:
• 9.2.0.2
• 9.2.1
• 11.1.1.2
• 11.1.1.3
All later versions, beginning with version 11.1.2.0, are fully localized. There will be no further non-localized or partially localized releases.
Languages supported in fully localized releases:
• English
• French
• German
• Spanish
• Turkish
• Russian
• Japanese
• Korean
• Simplified Chinese
• Traditional Chinese
• Brazilian Portuguese
• Polish (version 11.1.2.1 and later only)
• Norwegian (version 11.1.2.1 and later only)
Most user interaction with Planning occurs in the web browser, and the language displayed depends on the language settings of that web browser. This is true for both fully localized and non-localized releases.
To change the language used in the Planning interface, change the preferred language used by your web browser. For example, in Microsoft Internet Explorer 7:
It is easy to tell if there is problem with the current relational database settings, as unsupported characters will appear as question marks, or small squares, in the Planning web interface. Generally, the characters displayed in the Planning web interface reflect the characters as they are stored in the relational database. If you do see a question mark in a member name instead of the expected accented character, for example, you can verify how that character is stored in the relational database by connecting to it with a database client and viewing the contents of the tables.
Note that if a character is not stored correctly in the database, this does not always mean that the current database settings are incorrect. It is possible for characters to be "lost" when restoring a database exported from an environment that used a different characterset to the destination environment. Again, this is a complex area best dealt with by your Database Administrator but bear in mind that both the existing settings of the database and any migration procedure (if you are migrating or upgrading existing applications) can cause characters to be displayed incorrectly.
Since the Essbase databases are based on the application outline as defined in Planning, Essbase must support the characters used in Member names, Aliases, Member Formulas, and so on.
To this end, Essbase supports a large number of charactersets. The characterset used by Essbase is defined by a system variable on the Essbase server called ESSLANG. See the Essbase Database Administrator's Guide for a list of available ESSLANG values.
The ESSLANG setting is by its nature a server-wide setting. You cannot use different ESSLANG settings for different Essbase databases on a single Essbase server. When you initially install and configure Essbase you are given the option of choosing an ESSLANG setting. By default, the ESSLANG is English_UnitedStates.Latin1@Binary, which supports most Western European languages.
You can change the ESSLANG by simply changing the value of the ESSLANG system variable on the Essbase server and restarting the Essbase service. However, any existing applications, whether these are Planning or native Essbase applications, will no longer work if they were created with a different ESSLANG. The ESSLANG value is embedded into an application's outline when it is first created, and changing it is not a trivial task. The ESSLANG is also embedded into objects such as calc scripts when they are first created. It is therefore important to give some thought to selecting the right ESSLANG setting before you start creating applications.
Not all languages have their own ESSLANG. For example, there is no Polish ESSLANG. However, it is often possible to use a different ESSLANG which supports the same characters. For example, Polish can be supported by using a Czech ESSLANG settings.
Most languages have several possible ESSLANG settings. For example:
You would usually select the ESSLANG appropriate to your operating system. "MS" ESSLANG's are Microsoft standards and should be used for Essbase servers running on Windows, whereas Unix and Linux based servers normally use the ISO ESSLANG's, (an example exception to this would be moving an outline from a Windows server to a Unix server or vice-versa as the ESSLANG is embedded as mentioned above). Note that this is not an exact science, so if you are having problems getting special characters to display correctly in the Essbase outline consider trying a different ESSLANG setting, or using a Unicode application instead (see below).
Planning version 11.1.1.0 and later supports Essbase unicode databases. This allows for greater flexibility because a unicode database will support any characters supported by UTF8, regardless of the server ESSLANG setting. Since this is a per-database setting, it is also possible to support non-unicode Essbase applications that require a particular ESSLANG alongside unicode Essbase applications that would have required a different ESSLANG.
However, unicode support comes at a cost, requiring more resources on the Essbase server. See the Essbase Database Administrator's Guide for your version. Search for the section called "When to Use Unicode-Mode Applications". Despite this drawback, unicode applications do offer a way to sidestep problems selecting the correct ESSLANG, and offer better support for charactersets used by Asian languages.
To create a unicode application in Essbase, check the "Unicode" checkbox when creating the application's datasource in Planning. When the Planning application is created using this datasource, the Essbase database will be set to support Unicode (and consequently will ignore the Essbase server's ESSLANG setting).
This refresh is accomplished using an Essbase run time client, which is installed on the Planning server as part of the Planning installation. It is this run time client that makes the connection to the Essbase server. This is true even if Essbase is on the same physical machine as Planning.
For the refresh to work properly, the Essbase run time client on the Planning server must be able to communicate with the Essbase server using a compatible characterset. The run time client picks up the language and regional settings of the Planning server on which it is installed, and uses those settings when communicating with the Essbase server. This means that the language and regional settings of the Planning server must match the ESSLANG used on the Essbase server. If Essbase and Planning are on separate servers then the client ESSLANG must be set accordingly.
For example, if the Essbase server is using the ESSLANG "Slovenian_Slovenia.ISO-8859-2@Slovenian", then the Planning server's regional settings must be set to the Slovenian language and Slovenia locale. In Windows these settings can be changed from the Control Panel, and require a reboot to take effect.
On Windows, the locale and language are chosen from a list of territories and languages, and Windows automatically decides which codepage corresponds to these choices. On Unix and Linux systems, the codepage may be an explicit choice, e.g. "es_es.UTF8" for a Spanish/Spain system. So long as the language and locale portion (the "es_es" part) matches the ESSLANG (which for Spanish on a Unix or Linux Essbase server would be Spanish_Spain.ISO-8859-15@Spanish) the refresh should work.
Strictly speaking, the language and regional settings used by the Essbase run time client on the Planning server are those of the user account that is used to run the Planning service, not the server itself. Make sure that you are changing the regional settings for the correct user, especially on Unix and Linux systems, where the server-wide language settings may not be the same as the language settings in use by the particular user account used to run Planning.
Purpose
Last Review Date
Instructions for the Reader
Troubleshooting Details
1. The Planning Interface
2. The Relational Database Server
3. The Essbase Server
4. The Planning Refresh
Applies to:
Hyperion Planning - Version: 4.1.0.0.00 to 11.1.1.3.00 - Release: 4.1 to 11.1Information in this document applies to any platform.
Purpose
Hyperion Planning supports many languages and charactersets, including non-Latin charactersets. However, Planning and the third party software on which Planning depends must be configured appropriately for all characters to be displayed correctly in Planning and in Essbase.Last Review Date
January 14, 2010Instructions for the Reader
A Troubleshooting Guide is provided to assist in debugging a specific issue. When possible, diagnostic tools are included in the document to assist in troubleshooting.
Troubleshooting Details
There are four areas to consider: the Planning interface itself, the relational database Planning uses to store metadata, the Essbase OLAP database Planning uses to store data, and the regional and language settings of the Planning server itself.Not every release of Planning is fully localized. However, the web interface to Planning can be customized to use a language other than English even in non-localized releases, although the logs, utilities, and error messages in non-localized releases will be in English. All versions of Planning support "Level 0 internationalization", meaning that Planning will run on a non-English version of an operating system (e.g. the French version of Windows 2003 Server) .
Fully localized Planning releases:
• 9.2.0.2
• 9.2.1
• 11.1.1.2
• 11.1.1.3
All later versions, beginning with version 11.1.2.0, are fully localized. There will be no further non-localized or partially localized releases.
Languages supported in fully localized releases:
• English
• French
• German
• Spanish
• Turkish
• Russian
• Japanese
• Korean
• Simplified Chinese
• Traditional Chinese
• Brazilian Portuguese
• Polish (version 11.1.2.1 and later only)
• Norwegian (version 11.1.2.1 and later only)
1. The Planning Interface
When installing a fully localized release you are given the option of selecting your preferred language. This will affect the non web-based parts of Planning - the utilities, logs, and the Windows client (in versions 9.2.x).Most user interaction with Planning occurs in the web browser, and the language displayed depends on the language settings of that web browser. This is true for both fully localized and non-localized releases.
To change the language used in the Planning interface, change the preferred language used by your web browser. For example, in Microsoft Internet Explorer 7:
- Tools > Internet Options > "Languages" button
- Use the "Move Up" button to move your preferred language to the top of the list
- If your preferred language is not present use the "Add..." button to add it to the list and then move it to the top.
- Restart Internet Explorer
NOTE: in non-localized releases a few menu entries may continue to appear in English even after the Planning interface has been configured to display in a different language.
Customization:
It is possible to customize process management statuses, some error messages, and email notifications by editing the appropriate configuration files. This allows for the partial localization of non-localized releases. For more information about customization, see the Planning Administrator's Guide for your version, which contains a chapter on customization. Please note that all Planning customization is at the customer's discretion, and that Oracle Support will not assist with customization efforts. If assistance is required, Oracle Consultancy is available as a paid service.
It is possible to customize process management statuses, some error messages, and email notifications by editing the appropriate configuration files. This allows for the partial localization of non-localized releases. For more information about customization, see the Planning Administrator's Guide for your version, which contains a chapter on customization. Please note that all Planning customization is at the customer's discretion, and that Oracle Support will not assist with customization efforts. If assistance is required, Oracle Consultancy is available as a paid service.
2. The Relational Database Server
The language settings and characterset used by the database instance that Planning uses to store metadata must support the characters used in Member names, Aliases, Data Form names, and so on. As the selection of relational database charactersets is a complex area, you should consult your database administrator about which settings to use, and review the recommendations in the Installation Guide. For most situations a UTF8 configuration is the easiest way to provide support for your chosen language.It is easy to tell if there is problem with the current relational database settings, as unsupported characters will appear as question marks, or small squares, in the Planning web interface. Generally, the characters displayed in the Planning web interface reflect the characters as they are stored in the relational database. If you do see a question mark in a member name instead of the expected accented character, for example, you can verify how that character is stored in the relational database by connecting to it with a database client and viewing the contents of the tables.
Note that if a character is not stored correctly in the database, this does not always mean that the current database settings are incorrect. It is possible for characters to be "lost" when restoring a database exported from an environment that used a different characterset to the destination environment. Again, this is a complex area best dealt with by your Database Administrator but bear in mind that both the existing settings of the database and any migration procedure (if you are migrating or upgrading existing applications) can cause characters to be displayed incorrectly.
3. The Essbase Server
Planning applications store the bulk of their data in Essbase OLAP databases. These Essbase databases (or "cubes") are structured according to the application outline that is first defined in Planning. The Planning relational database contains this application outline, which is then "pushed" to Essbase during the Planning Refresh. This is a one-way refresh, from Planning to Essbase, not a two-way synchronization.Since the Essbase databases are based on the application outline as defined in Planning, Essbase must support the characters used in Member names, Aliases, Member Formulas, and so on.
To this end, Essbase supports a large number of charactersets. The characterset used by Essbase is defined by a system variable on the Essbase server called ESSLANG. See the Essbase Database Administrator's Guide for a list of available ESSLANG values.
The ESSLANG setting is by its nature a server-wide setting. You cannot use different ESSLANG settings for different Essbase databases on a single Essbase server. When you initially install and configure Essbase you are given the option of choosing an ESSLANG setting. By default, the ESSLANG is English_UnitedStates.Latin1@Binary, which supports most Western European languages.
You can change the ESSLANG by simply changing the value of the ESSLANG system variable on the Essbase server and restarting the Essbase service. However, any existing applications, whether these are Planning or native Essbase applications, will no longer work if they were created with a different ESSLANG. The ESSLANG value is embedded into an application's outline when it is first created, and changing it is not a trivial task. The ESSLANG is also embedded into objects such as calc scripts when they are first created. It is therefore important to give some thought to selecting the right ESSLANG setting before you start creating applications.
Not all languages have their own ESSLANG. For example, there is no Polish ESSLANG. However, it is often possible to use a different ESSLANG which supports the same characters. For example, Polish can be supported by using a Czech ESSLANG settings.
Most languages have several possible ESSLANG settings. For example:
Swedish_Sweden.IBM500@Swedish
Swedish_Sweden.ISO-8859-15@Swedish
Swedish_Sweden.Latin1@Swedish
Swedish_Sweden.MS1252@SwedishYou would usually select the ESSLANG appropriate to your operating system. "MS" ESSLANG's are Microsoft standards and should be used for Essbase servers running on Windows, whereas Unix and Linux based servers normally use the ISO ESSLANG's, (an example exception to this would be moving an outline from a Windows server to a Unix server or vice-versa as the ESSLANG is embedded as mentioned above). Note that this is not an exact science, so if you are having problems getting special characters to display correctly in the Essbase outline consider trying a different ESSLANG setting, or using a Unicode application instead (see below).
Planning version 11.1.1.0 and later supports Essbase unicode databases. This allows for greater flexibility because a unicode database will support any characters supported by UTF8, regardless of the server ESSLANG setting. Since this is a per-database setting, it is also possible to support non-unicode Essbase applications that require a particular ESSLANG alongside unicode Essbase applications that would have required a different ESSLANG.
However, unicode support comes at a cost, requiring more resources on the Essbase server. See the Essbase Database Administrator's Guide for your version. Search for the section called "When to Use Unicode-Mode Applications". Despite this drawback, unicode applications do offer a way to sidestep problems selecting the correct ESSLANG, and offer better support for charactersets used by Asian languages.
To create a unicode application in Essbase, check the "Unicode" checkbox when creating the application's datasource in Planning. When the Planning application is created using this datasource, the Essbase database will be set to support Unicode (and consequently will ignore the Essbase server's ESSLANG setting).
4. The Planning Refresh
The final thing to consider are the language and regional settings on the Planning server. When a Planning Refresh is launched, the application outline is refreshed from Planning to Essbase. Any new members or changes to the outline structure are pushed to Essbase.This refresh is accomplished using an Essbase run time client, which is installed on the Planning server as part of the Planning installation. It is this run time client that makes the connection to the Essbase server. This is true even if Essbase is on the same physical machine as Planning.
For the refresh to work properly, the Essbase run time client on the Planning server must be able to communicate with the Essbase server using a compatible characterset. The run time client picks up the language and regional settings of the Planning server on which it is installed, and uses those settings when communicating with the Essbase server. This means that the language and regional settings of the Planning server must match the ESSLANG used on the Essbase server. If Essbase and Planning are on separate servers then the client ESSLANG must be set accordingly.
For example, if the Essbase server is using the ESSLANG "Slovenian_Slovenia.ISO-8859-2@Slovenian", then the Planning server's regional settings must be set to the Slovenian language and Slovenia locale. In Windows these settings can be changed from the Control Panel, and require a reboot to take effect.
On Windows, the locale and language are chosen from a list of territories and languages, and Windows automatically decides which codepage corresponds to these choices. On Unix and Linux systems, the codepage may be an explicit choice, e.g. "es_es.UTF8" for a Spanish/Spain system. So long as the language and locale portion (the "es_es" part) matches the ESSLANG (which for Spanish on a Unix or Linux Essbase server would be Spanish_Spain.ISO-8859-15@Spanish) the refresh should work.
Strictly speaking, the language and regional settings used by the Essbase run time client on the Planning server are those of the user account that is used to run the Planning service, not the server itself. Make sure that you are changing the regional settings for the correct user, especially on Unix and Linux systems, where the server-wide language settings may not be the same as the language settings in use by the particular user account used to run Planning.
Thanks! Very Helpful!
ReplyDeleteNice info provided here keep updating
ReplyDeleteHyperion essbase Online Training
DRm Online Training
Hyperion Online Training
Hyperion Training