Wednesday, April 29

Known Issues of UI Theme Designer for SAP NetWeaver Portal

Symptom
Known issues of UI Theme Designer for SAP NetWeaver Portal

Other Terms
UI Theme Designer for SAP NetWeaver Portal, troubleshooting, error, UI Theme Designer, Portal Themes, Theming

Reason and Prerequisites
You have installed NW 7.30 SP10, NW 7.31 SP9 or NW 7.40 SP4 and you are using the new UI Theme Designer for SAP NetWeaver Portal and you are experiencing some issues.

Solution
This section lists the known issues of UI Theme Designer for SAP NetWeaver Portal along with their solutions or workarounds.
LANGUAGES
Right-to-Left Languages Currently not Supported
Symptom: Right-to-left languages are not supported.
Workaround: None
Starting 7.31\7.30 SP13 7.40 SP8 Right-to-left languages are supported, please see note number 1959708

Translation of Parameters Currently not Supported
Symptom: Portal parameter names and tags are not translated.
Workaround: None
APPLICATION INTEGRATION
Application Types not Supported
Symptom: Changes made to portal themes using the UI Theme Designer do not affect the following applications:
1) IAC and old ITS iViews (WebGui) that do not use UR-based style sheets
2) UI5 iViews - not currently supported
3) Mobile iViews - not currently supported
Workaround: None
4) NWBC for HTML and Desktop: not currently supported
ACTIVATION
Automatic Migration of Portal Themes Currently not Supported
Symptom: Manual migration of portal themes to the new structure is required.
Workaround: Existing themes must be manually exported and imported using the "Transport Themes" UI. See documentation for details.
OTHER
Quick Theming of Portal Parameters Currently not Supported
Symptom: Portal parameters cannot be edited using the Quick Theming tab.
Workaround: Edit portal parameters in the CSS tab.

Changes Through WRR Require Manual Compilation
Symptom: Changing LESS files through the Web Resource Repository (WRR) will not affect the theme at runtime.
Workaround: Manually compile the theme through: PortalAnywhere.Go -> com.sap.portal.themes.archive ->  download.

Custom Themes Based on SAP Themes Are Affected by SAP Changes
Symptom: Changes made to parameters of standard SAP themes using the UI Theme Designer do not inherit parameter changes that are part of a NW upgrade.
Workaround: None

Using a Transport Package for Existing Themes not Supported
Symptom: Importing a transport package with an existing theme into a Portal that has activated the UI Theme Designer will result in the theme being transported but not migrated.
Workaround: Import the theme using the "Transport Themes" UI.

Posted by Mohammed Bohra at 4:10 AM 0 comments

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 0 comments
Labels: SAP web Dynpro ABAP

Web Dynpro Java: Generation error for portal application URL

Symptom
WDPortalUtils.getPortalApplicationURL returns wrong result.

Example for wrong URL before the fix returned by WDPortalUtils.getPortalApplicationURL(pcd://mypath/x):
/pcd://mypath/x

Example for correct URL after the fix returned by WDPortalUtils.getPortalApplicationURL(myurl):
/irj/servlet/prt/portal/prtroot/pcd%3A%2F%2Fmypath%2Fx

Other Terms
WDPortalUtils getPortalApplicationURL

Reason and Prerequisites
Error in URL generation.

Solution
Update to newer version of Web Dynpro runtime.

Posted by Mohammed Bohra at 3:49 AM 0 comments
Labels: SAP Web Dynpro java

Reverse proxy supported by Web Dynpro

Symptom
Reverse proxy supported by Web Dynpro; generated URLs have changed

Other Terms
WDURLGenerator, reverse proxy, URL generation, absolute URL, relative URL, resource path, Web resource URL, SPS13, Web Dynpro URL generation

Reason and Prerequisites
Starting with NetWeaver04, SPS13, Web Dynpro will support reverse proxies. In prior service packs, reverse proxies were not supported (see also note 711093). The support of reverse proxies led to a change in the URLs generated by the WDURLGenerator: Methods like
WDURLGenerator.getWebResourceURL(...), WDURLGenerator.getApplicationURL(...),
WDURLGenerator.getSAPIconsWebResourcePath(...), etc.

previously generated absolute URLs like the the following:

/webdynpro/resource/sap.com/tc~wd~corecomp/Components/test.TestComp/icon.gif

These URLs couldn't be resolved when a reverse proxy was used. In order to support reverse proxy landscapes, the generated URLs had to be changed to be relative URLs like the following:

../../../resource/sap.com/tc~wd~corecomp/Components/test.TestComp/icon.gif

This change should be transparent for the application if the URL generator is used as supposed. However, there might be problems in an application that misused the URL generation, as shown in the example below:

1. If the application generates Web resource URLs and adds a prefix to     the generated URL:
String url = "~host" + WDURLGenerator.getWebResourceURL(...);
   Previous to the support of reverse proxies, this led to an URL like           ~host/webdynpro/resource/sap.com/tc~wd~corecomp/Components/
          test.TestComp/icon.gif

   Starting with SPS13, this will result in the following wrong URL:
~host../../../resource/sap.com/tc~wd~corecomp/Components/
          test.TestComp/icon.gif

   Solution:
   The prefix should be removed. Using the prefix is no good idea          at all. It makes the application coding dependent on small              changes of the URL generation. The WDURLGenerator is supposed to        contain all methods required to generate URLs on static resources of    Web Dynpro applications and is supposed to hide away any details of     the structure of the generated URL to the application.

Posted by Mohammed Bohra at 3:46 AM 0 comments
Labels: SAP web Dynpro ABAP

Web Dynpro error page, known error situations, error codes

Symptom
Web Dynpro error page is shown

Other Terms
Web Dynpro error page error code
LockException SessionExpiredLongJumpException ChunkLimitException SessionLimitExceededException RuntimeException Error

Reason and Prerequisites
Exception occurs in Web Dynpro and Web Dynpro error page is shown.

Solution
This note describes how a user should analyze the Web Dynpro error page that is shown in case an error occurs when procesing a Web Dynpro application. It also describes well-known error codes and error situations which are not related to funtional correctness of the UI runtime.

=======================================================================
Analyzing error page information:

In case an error occurs when processing a request to a Web Dynpro application, an error page is shown.

System runs in development mode:
If the system runs in development mode, the error page contains following details about the related error.
  • Exception text and error code
  • System information, like version of the used Web Dynpro runtime, Web AS version, etc.
  • Correction hints are shown if a well-known error situation has occured that is not related to a bug in the Web Dynpro runtime.
  • If the error page is shown due to a unexpected error situation, the stacktrace of the exception is shown in a short version and additional in a full version at the bottom of the error page. Often, causing exceptions are nested in such stacktraces. Nested Exceptions can be identified by 'Caused by' prefix. To find the root cause of the problem, the last nested exception of the stacktrace is relevant. This is the exception after the last 'Caused by'.

If the shown error page results in a CSN, the complete error page should be saved as HTML file and attached to the CSN message.

System runs in productive mode:
If the system runs in productive mode, the error page only shows a log ID which references to the detailed exception stacktrace in the trace or log file. The related defaultTrace.trc and log file should be checked for further analysis. This can be done by the system administrator. To disable the reduced error page, the administrator can connect to the Java EE telnet console and type in following command:
> setsp -p DetailedErrorResponse true http

If the shown error page results in a CSN, the related defaultTrace.trc, and log file should be attached to the CSN message. Additionally, the system information page should be saved as HTML file and attached to the message (-> Web AS start page -> System Information).

For more information on how to get the defaultTrace.trc and System Information please have a look to note 742674. For more information on how to switch between productive and development mode see note 962319.

=======================================================================
Description of well-known error situations, their reasons and solutions:

There are some well-known error situations which are not related to a bug or functional incorrectness of the Web Dynpro runtime. The following list shows such error situations, grouped by exceptions and error codes, and explains their causes and possible solutions.
SessionLimitExceededException:
  • Symptom:Error page is shown with either a com.sap.tc.webdynpro.services.exceptions.SessionLimitExceededException
  • Error code: 403 - Forbidden
  • Cause: There is a configurable maximum number of sessions which can be started by a single user in one user session. If this maximum limit is exceeded, the error page comes up. There is an extra user session per browser process (respectively per browser login). Web Dynpro counts following sessions within a user session:
  • Web Dynpro applications running without the portal
  • Portal pages containing embedded Web Dynpro applications are counted when running within the portal
           This counting guarantees that in the portal a portal page that contains Web Dynpro applications is either shown completely or not at all.
  • Solution:
  • User must close external browser windows or browser tabs to reduce the number of active sessions.
  • If the maximum number of allowed sessions per user session is to small in general, the administrator can configure it via the parameter "sap.max.session.limit" in the Web Dynpro default.properties (for details, see note 1012065).


LockException:
  • Symptom:Error page is shown with a com.sap.tc.webdynpro.services.session.LockException
  • Error code: 408 -Request Timeout
  • Cause: Web Dynpro provides a single-threaded programming model. As soon as a request for a user session is processed, the user session is blocked for the duration of the request, i.e. there is always at most one thread that has acquired the lock of a user session. Concurrent requests which refer to the same user session (i.e. triggered from the same browser process) are serialized and processed one after each other. If there is a request which blocks or hangs due to some waiting/blocking condition, then other concurrently incoming requests are waiting for a certain period of time that the user session lock is released. If they can't acquire the user session lock after this time interval, the waiting thread terminates with a LockException error page.
  • Solution:
  • The LockException error page shows a 408 error code and the stacktrace of the thread that holds the user session lock and that is responsible for the blocking/waiting condition. Forward the stacktrace to the development group or CSN component that can help to understand the shown stacktrace and explain the waiting/blocking condition.
  • If there are intended long running requests which hold the user session lock for a longer time, an administrator might want to configure the maximum time for which an incoming request will wait if the user session lock is already taken. This can be done via "sap.locking.maxWaitInterval" parameter in the Web Dynpro default.properties (for details, see note 1012065).


SessionExpiredLongJumpException:
  • Symptom:Error page is shown with a com.sap.tc.webdynpro.clientserver.session.SessionExpiredLongJumpException
  • Error code:400 - Session Timeout
  • Cause 1: A started application was untouched for a certain period of time and has expired in the meantime. The expiration happens as an asynchronous server event and the client is not notified about this event. The user is notified about it the next time when a request to the expired application is triggered and the error page with the SessionExpiredLongJumpException is coming up.
  • Cause 2:A application that is started on the client is stopped/removed/redeployed on the server. Such an action leads to a termination of the depending sessions on the server. The user gets a SessionExpiredLongJumpException when triggering the next request to the related application.
  • Solution:The user has to restart the application (browser refresh, or "Refresh" entry in the IView tray menu in the portal).

DispatcherException:
  • Symptom:Error page is shown with a com.sap.tc.webdynpro.services.sal.core.DispatcherException
  • Error code:500 - Internal Server Error
  • Cause: The requested application is not deployed on the server.
  • Cause: There is a typo in the application URL, i.e. the URL doesn't address an existing and deployed application.
  • Solution: The user should check the URL for typos; the user should contact the system administrator whether the requested application is deployed at all.


"Failed to process the request: Request refers to an unknown session":
  • Symptom: Error page is shown with message text: "Failed to process the request: Request refers to an unknown session".
  • Error code: 404 - Application Not Found
  • Cause: The server received a request which refers to an assumingly existing application session which is unknown to the server.
  • Solution: The problem occurs if for instance the client has sent an incorrect request to the server, or the request dispatching mechanism of a cluster incorrectly dispatched a postback/follow-up request to a wrong server node. For a concrete analysis, the http traffic should be recorded using a tool like HttpWatch and the recording should be attached to an OSS message. To check whether a wrong request dispatching is the problem, check if the loadbalancing cookie "sap_lb" contains the same value over the sequence of requests. If this is not the case, it is an indication that the request was dispatched to the wrong server node during the sequence of requests.

"Failed to process the request: The suspension of a non-suspendable application resulted in the destruction of the requested session.":
  • Symptom: Error page is shown with message text: "Failed to process the request: The suspension of a non-suspendable application resulted in the destruction of the requested session.".
  • Error code: 400 - Suspend Error
  • Cause: The server received a request which refers to an assumingly suspended application session which was destroyed because the application is marked as non-suspendable.
  • Solution: The problem occurs if a request is sent with previous session parameters. For a concrete analysis, the http traffic should be recorded using a tool like HttpWatch and the recording should be attached to an OSS message. Check whether the request contains the request parameters "sap-wd-norefresh" or "sap-wd-cltwndid".

Posted by Mohammed Bohra at 3:44 AM 0 comments
Labels: SAP Web Dynpro java
Subscribe to: Posts (Atom)