Wednesday, April 29

Locales, languages, date and time formats in Web Dynpro

Symptom
A wrong language or locale is used after you logged on to the system ?
Calendar dates are formatted in an unintended way ?
Language change in the portal (through portal personalization) does not get immediately reflected in the Web Dynpro iViews ?

Other Terms
Web Dynpro Java, Enterprise Portal, locale, date format, time format

Reason and Prerequisites
You are using applications that have a SAP Web Dynpro Java user interface, running standalone or in the SAP Enterprise Portal.

Solution

Determination of languages and locales

Languages and locales are found stepping through several hierarchies based on the server layers involved. If you want to find out where this algorithm fails in your case, e.g. due to misconfiguration, you have to carefully check each step.
As there might be differences from release to release we recommend to double check with the NetWeaver Developer Workplace documentation, to visit sdn.sap.com or to consult a book like "Web Dynpro for Java" (SAP PRESS).
    1. Determination of the locale in SAP Portal
              When the Web Dynpro application is running within the SAP Portal you have to start your investigation here.
              If the Portal succeeds to determine a locale and successfully hands it over in the URL to Web Dynpro, this locale might become effective. The first locale determined by the following sequence will be forwarded to Web Dynpro.
    a) Component locale: The locale of the component is specified by the following two properties and enables you to force a component to use one specific locale. This could be used for administration components.
                       ForcedRequestLanguage
                       ForcedRequestCountry
    b) Portal mandatory locale: This is defined in the prtDefault.properties and forces a portal installation to use one and only one locale. Administrators setting up a portal environment use this locale.
                       request.mandatorylanguage
                       request.mandatorycountry
    c) User locale: This is the locale attached to the profile of the user who logged in to the system. This is the most popular way to set language and locale.
    d) Request locale: The request locale is defined by the browser. This is used, for example, for anonymous user or users that do not have locales defined in their profiles.
    e) Portal default locale: This locale is defined in the prtDefault.properties by the following two properties.
                       request.defaultlanguage
                       request.defaultcountry
    f) System default locale: The Java default locale defined by the system, either by the operating system or by the JVM on the server.
    2. Determination of the locale in SAP Web Dynpro Java
              Web Dynpro starts with the determination of a locale by looking for a locale delivered by SAP Portal. If this fails or if the Web Dynpro application is running standalone, successive steps are taken until the first one succeeds.
    a) SAP Portal hands over a locale to Web Dynpro via an URL parameter sap-locale .
    b) The user locale is checked. This is the locale attached to the profile of the user who logged in to the system.
    c) The Accept-language in the HTTP header of the request, defined in the browser, is checked.
    d) The default sap.Locale in the application properties of the Web Dynpro application is investigated.
    e) The sap.systemLocale in the Propertysheet default of the Web Dynpro runtime is evaluated.
    f) The system default locale, either defined by the operating system or by the JVM on the server, is evaluated.
    3. Determination of language resources
              Dependent on the resource bundles available on the server the effective language in which static texts on the screen are shown can change again at this point of time. The first of the following steps succeeding finally determines the language of the static texts.
    a) The system searches for property resource bundles for the language defined in the SAP Web Dynpro Java session locale in a file like _.properties . If the file is available this language becomes effective.
    b) The default locale of the JVM on the server is evaluated and the related resource file _.properties is searched for. If the file is available this language becomes effective.
    c) Last the system tries to use the default resource bundle named .properties .
    d) If this fails too, e.g. because the default resource bundle is not available, a java.util.MissingResourceException is thrown.

Troubleshooting
    4. Check the current session locale
              The current session locale of the SAP Web Dynpro Java session is quite important. It is evaluated once at application startup and effects both static texts on the screen, headlines of table columns, formatting of application data e.g. calendar dates, and so on.
It can be checked in the Web Dynpro Content Administrator:
    a) Enter the Web Dynpro Content Administrator, e.g. via the start page of the SAP J2EE Engine -> Web Dynpro -> WD Content Administrator.
    b) Display the attributes for any application.
    c) Choose the tab "Language Resources" in the content area on the right.
    d) Watch for the session locale displayed in the content area in the upper part ("Current locale"):
    If it is something like "en_AU" it contains both language and country information, if it is e.g. "en" only, the country information is missing and the default formatting related to this language for e.g. calendar dates is used. For "en" this is USA English MM/DD/YYYY.
    5. Check the available language resource bundles
              The language resource bundles available define and contain the static language dependent texts on the screen for Web Dynpro Java applications.
They can be checked in the Web Dynpro Content Administrator:
    a) Enter the Web Dynpro Content Administrator.
    b) Display the attributes for the application you want to check.
    c) Choose the tab "Language Resources" in the content area on the right.
    d) Select the desired language in the drop down menu "Select Language".
    e) Watch for error messages like "No resource bundles found " at the bottom of the content area.
    If the language resource bundle for the language chosen is available, the texts contained are shown in the table next to the drop down menu.
    Mind that the resource bundles are stored on the appliocation servers locally and that they have to be checked for all application servers.
    6. Different languages on different application servers
              If you see Web Dynpro Java applications in different languages for the same user accessing different application servers, this might be due to inconsistencies on the different application servers regarding the JVM locales, the availability of language dependent resource bundles or different contents in the default resource bundle.
Please check these prerequisites on all apllication servers.
    7. Enable session trace
    a) NW 04s & later versions
                       To enable the trace for locale determination in Web Dynpro, configure the log location "com.sap.tc.webdynpro.i18n" to Severity.INFO
    b) NW 04 versions
                       To enable the trace for locale determination in Web Dynpro, configure the log location "com.sap.tc.webdynpro.clientserver.cal.ClientSession" to Severity level: INFO.
    8. Users from R/3 & Date Formatting
              If you use an R/3 based store (UME User Management Engine) in the backend system to keep your user data please ensure that you have not only maintained the language setting but also the country setting. Both in combination determine the NetWeaver Web Dynpro locale and in consequence the calendar date format that is used, e.g. DD/MM/YYYY for Australian English and MM/DD/YYYY for USA English.
              The settings in the user management in R/3 are:
    a) call transaction SU01 in R/3 ABAP system
    b) press tab "Address"
    c) look at box "Person"
    d) maintain "Language" field (technical "LANGUP_ISO")
    e) press small button "+ more fields" on right
    f) maintain "Format country" field (technical "NAMCOUNTRY")
              To check the current session locale that is used in your NetWeaver Web Dynpro session see the paragraph above on this issue.
              For further reference on localization of Java applications see ISO 639 Language Codes, ISO 3166 Region Codes and SUN SDN "Internationalization: Understanding Locale in the Java Platform".
    9. Change of locale in Web Dynpro iView
              There is one locale assigned per login (user) session. This is done for the first Web Dynpro Java application or Web Dynpro Java iView started in the login session.
After detecting the locale, this locale is assigned to the login session and all Web Dynpro applications and all Web Dynpro iViews started in the same login session. The reason why it has to be this way is that Web Dynpro uses backend connection caches which are associated to the login session and they are locale sensitve.
              If the locale for the Web Dynpro iView is changed in the portal (through portal personalization), this is not reflected in the running login session. The user needs to logoff and login again, in order to see the locale change in the Web Dynpro iView.
              As Web Dynpro uses one locale per login session, it is not possible to run multiple iViews with different locale settings.

Known Limitations
    10. Calendar date formatting for Singapore
              The calendar date formatting for the locale "en_SG" Singapore is MM/DD/YYYY similar to the US American date format.
This is a feature of the SUN Java JVM. It is not possible, by means of SAP NetWeaver, to change this behaviour.

Posted by Mohammed Bohra at 3:51 AM
Labels: SAP web Dynpro ABAP

No comments:

Post a Comment

You are welcome to express your views here...

Subscribe to: Post Comments (Atom)