Tuesday, May 20

Start of UME Service Failed with error

Error:
Start of UME Service Failed with error: "Parameter ume.persistence.data_source_configuration
cannot be read from the properties file.
 
Symptom
  • The security service fails to start. In the std_server0.out trace file, you will see the following error
service com.sap.security.core.ume.service ================= ERROR=================
Core service com.sap.security.core.ume.service failed. J2EE Engine cannot be started. com.sap.engine.frame.ServiceException: Start of UME service failed.
Check help topic "Start of UME Service Failed". Technical details: Parameter ume.persistence.data_source_configuration cannot be read from the properties file
#at com.sap.security.core.server.ume.service.UMEServiceFrame.start (UMEServiceFrame.java:398)


Environment
  • SAP Netweaver Application Server 7.0x/7.1x/7.2x/7.3x/7.4
Reproducing the Issue
Try to start the AS Java
Cause
Incorrect configuration of UME data source. The wrong UME datasource xml file has been chosen for the current configuration of your User store which is one of ABAP, LDAP, or Local UME.
Resolution
You need to locate and edit the UME parameter ume.persistence.data_source_configuration. To do so, please do the following:
For 7.0x:
  1. Open the Config tool
  2. Navigate to Global server configuration -> services -> com.sap.security.core.ume.service.
  3. Locate the parameter "ume.persistence.data_source_configuration"
  4. Enter the correct data source.
  5. Press "Set"
  6. Save the changes and restart the AS Java
For 7.1x and above:
  1. Open the Config tool
  2. Switch to configuration mode
  3. In the display Configuration tab, navigate to cluster_config -> system -> custom_global -> cfg -> services -> com.sap.security.core.ume.service -> Propertysheet properties.
  4. Switch to edit mode
  5. click on the property "ume.persistence.data_source_configuration"
  6. Enter the correct data source
  7. Apply the changes and restart the AS Java


See Also
718383 - NetWeaver: Supported UME Data Sources and Change options
http://help.sap.com/saphelp_nw70/helpdata/en/0b/50ad3e1d1edc61e10000000a114084/content.htm
http://help.sap.com/saphelp_nw73/helpdata/en/a2/03aa3d5acd40f082db65ee59c360b7/content.htm?frameset=/en/a2/03aa3d5acd40f082db65ee59c360b7/Content.htm

Posted by Mohammed Bohra at 12:12 AM 0 comments

Monday, May 19

Multiple Language Support in Portal on Device (MFP)

Symptom
You are using the Portal on Device (MFP) and it is not translated to End User languages.
Reason and Prerequisites
Before this correction the translation scope of the strings of MFP was set to de-DE, en-US, fr-FR, ja-JP, pt-BR, ru-RU, zh-CN only.
The specific SPs and patches containing the fix are visible in the "Support Packages & Patches" section of this note.
Solution
This correction will translate the Portal on Device (MFP) to End User languages,
identically to the list of languages that supported by the SAP Enterprise Portal.
Please refer to Support Packages & Patches link to view the versions including the fix.

Posted by Mohammed Bohra at 1:03 AM 0 comments

Portal on device session issue on iOS devices

Symptom
You have saved a portal on device web page as a shortcut on the home screen of iOS devices.
Every time you open portal on device from the home screen shortcut, you need to enter your login credentials and the session is not maintained.
Reason and Prerequisites
Portal on device uses a the specific meta tag "apple-mobile-web-app-capable" which sets a web application to run in full-screen mode once it is saved as a home screen shortcut.
The mode closes the web application session with each context switch.
Solution
A new property has been introduced to the "MFP UI" iView - "com.sap.portal.navigation.mfp.webAppCapable"
To solve the described issue, open the relevant framework page, open the MFPUI iView, and set the "com.sap.portal.navigation.mfp.webAppCapable" property to "false".

Posted by Mohammed Bohra at 1:01 AM 0 comments

Thursday, May 15

SAP EP http to https redirect

Issue:
we have webdispatcher installed on host cpcwd1. The external url
https://abc.xyz.com is mapped to the internal webdispatcher
url cpcwd1.cpc.co.in through reverse proxy. Webdispatcher is connected
the AS Java system. Currently SSL certificate is imported in
webdispatcher and https port is only open.

Please let us know how we can convert the url automatically at the
webdispatcher level from https://abc.xyz.com to
https://abc.xyz.com.

The webdispatcher profile is attached with the message.
We have also tried the parameter -
icm/HTTP/redirect_0 = PREFIX=/, FROM=*, FROMPROT=http, PROT=https,
HOST=px155.sap.com
which is not working


Solution :
The paramater
icm/HTTP/redirect_0 = PREFIX=/, FROM=*, FROMPROT=http, PROT=https,
HOST=px155.sap.com
should work actually.
What i suspect is there is already paramater icm/HTTP/redirect_0 and
you are using same paramater again which will violate the earlier one.
(icm/HTTP/redirect_0 = PREFIX=/, TO=/irj/portal )
Hence could you please change it to icm/HTTP/redirect_1= PREFIX=/,
FROM=*, FROMPROT=http, PROT=https,
HOST=px155.sap.com.

Problem:
We have tried setting the below mentioned parameter in Webdispatcher
but still it is failing.

We have EP installed with 5 application with SCS and DB. Below is the
FQDN for all the component -

APP server 1 - tiEPP.tpc.co.in
APP Server 2 - cpceppapp01.cpc.co.in
APP Server 3 - cpceppapp02.cpc.co.in
APP Server 4 - cpceppapp03.cpc.co.in
APP Server 5 - cpceppapp04.cpc.co.in
SCS - tcs02EPP.cpc.co.in
DB - dbkEPP.cpc.co.in

On top of this webdispatcher is installed and the FQDN for
webdispatcher is -

Webdispatcher - cpcwd1.cpc.co.in

Through maintaining DNS entry the webdispathecr url
(https://cpcwd1.cpc.co.in) is getting converted to
https://abc.xyz.com. Also a third pary reverse proxy is
used for url diversion in internet the same also converting from
https://cpcwd1.cpc.co.in to https://abc.xyz.com in internet.
I have added the following two parameter separately and tested (added
1st parameter - did not work, then modified to 2nd parameter still did
not work) -
icm/HTTP/redirect_1= PREFIX=/, FROM=*, FROMPROT=http, PROT=https,
HOST=tpcwd1.tpc.co.in
and
icm/HTTP/redirect_1= PREFIX=/, FROM=*, FROMPROT=http, PROT=https,
HOST=sangamdev.tatapower.com

Please let us know how we can set the parameter in our scenario so that
while end user type - http://abc.xyz.com it gets
automatically converted to https://abc.xyz.com.

Solution:
please check the syntax with required spaces in the parameter
definition that you have maintained according to the following link
http://help.sap.com/saphelp_nw04s/helpdata/en/00/040f3a39ce8704e10000000a114084/content.htm
Problem :
Also I have tried all the possible combination (providing space) of
providing the parameter as discussed over phone. But still it is not
working.

Solution:
you need to open the port 8103 defined for http
port.
The incoming http request is not reaching webdispatcher so that it can
be redirected.
If you want to change the http port then you need to change ICM
paramaters in webdispatcher profile mainly this paramater
icm/server_port_0 =
PROT=HTTP,HOST=TPCWD1,PORT=8103,TIMEOUT=60,PROCTIMEOUT=600
and below this paramater you can see other parameters as well where
http port is used,you need to change that as well.
You can involve network team and check with them regarding the present
port.



 

Posted by Mohammed Bohra at 6:12 AM 0 comments

Tuesday, December 10

J2EE Engine hangs because of unsufficient system threads

Symptom
J2EE engine does not respond to any requests, the system is frozen and the cluster node (if allocated) should be restarted to solve the issue temporarily.
Other Terms
hang, freeze, not responding, thread, performance, j2ee
Reason and Prerequisites
Very often for SAP Net Weaver systems running J2EE Engine with Enterprise Portal there are recommendations , that a number of 20 or 40 for the Application Threads are sufficient. This is true for the application threads, but too often these recommendations are understood as concerning the number of the System Threads, even for dispatcher nodes.

Please note, that System Threads and Application Threads pools are two separate thread pools with absolutely different functionality and mixing them, i.e setting any not recommended by SAP J2EE Engine support value to the System Threads number, could be fatal. Please be very careful regarding exactly which number is changed.

Solution
When J2EE Engine stops responding, please do the following steps:

1. Make (at least one) thread dump of the cluster node that hangs (or of all the cluster nodes, including dispatcher ones if the node is not allocated).
procedure to create thread dump is explained below in the post.

2. If the thread dump(s) show that there are no free System Threads, i.e. if there are no threads with the stack trace:
"SAPEngine_System_Thread[impl:5]_#" prio=1 tid=0x09aa4cb0 nid=0x453f in Object.wait() [0x58a09000..0x58a09228]
at java.lang.Object.wait(Native Method)
- waiting on <0x6b4f0060> (a com.sap.engine.lib.util.WaitQueue)
at java.lang.Object.wait(Object.java:429)
at com.sap.engine.lib.util.WaitQueue.dequeue(WaitQueue.java:238)
- locked <0x6b4f0060> (a com.sap.engine.lib.util.WaitQueue)
at com.sap.engine.core.thread.impl5.SingleThread.run(SingleThread.java:127)

please proceed to step 3.

3. Check the values for the System Threads in the visual configtool:

- start the configtool script in /configtool;
- in the left GUI pane expand Cluster Data -> Global server configuration -> managers -> ThreadManager;
Check the values of the properties MinThreadCount, InitialThreadCount and MaxThreadCount.

4. Check the values of the same properties for the dispatcher nodes under Cluster Data -> Global dispatcher configuration -> managers -> ThreadManager.

The values of all the properties mentioned must be at least the default ones. Pressing the "Restore to default" button (after having in mind the current values) would give you the defaults.
In case the current values are lower than the default, please keep the default values (Select from the menu File -> Apply and confirm all popups and then restart the cluster in order for the changes to take effect).
In case the current values are higher than the default values, and still there are no free system threads, please report an SAP message in BC-JAS-COR component, attaching to it the thread dumps you have made in step 1. In this case do not apply the changes.
In case of lower than the default values, if resetting them to the defaults does not solve the issue, please report an SAP message in BC-JAS-COR component, attaching to it the thread dumps you have made in step 1. Please keep the System Thread pool configured with the default values meanwhile.
 
 

Create a thread dump from all Java threads running on a Java node

You are using the J2EE Engine and want to create a thread dump from all Java threads running on a Java node.
Reason and Prerequisites
For platforms using a JDK from SUN:
  • Please check that the Java node is not in "console" mode.
Open the /usr/sap// /j2ee/cluster/instance.properties file and check that the node does not have a "ID.Console=yes" attribute.
If the console mode is active, the output of the node is not redirected and you will not find a std_.out file.
You can deactivate the console mode by clearing the "Show Console" checkbox of the node in the ConfigTool.

Solution
Use the JCMon tool to initiate a thread dump.
1. Start the JCMon program with the profile of the instance.

The JCMon binary is located in the /usr/sap///j2ee/os_libs directory or in the /usr/sap//SYS/exe/run directory.
    2. Enter "20" to go to the "Local Administration Menue".
    3. Choose the "Dump stacktrace" menu item by entering its number.
    4. Select the Java node from the list of processes above and enter the value from the "Idx" column.
    5. Confirm the command with a "y" if the selected node is correct.
After completion, you will find the thread dump:
  • in the /usr/sap///work/std_.out file (for JDK's from SUN and HP, according to the patch level of jlaunch also for Classic VM on IBM i)
  • for JDK's from IBM: javacore..txt in directory
    • /usr/sap///j2ee/cluster/dispatcher
    • /usr/sap///j2ee/cluster/server#
    • /usr/sap///SDM/program
  • according to the patchlevel of jlaunch in a spoolfile QDMPJVM of the workprocess user (for Classic VM on IBM i)
Alternative procedure on Unix
    1. Start the JCMon program with the profile of the instance.
    2. Enter "20" to go to the "Local Administration Menue".
    3. Note the process ID (PID) from the Java node.
    4. Issue a "kill -3 " command from the shell.
Alternative procedure on Windows
This procedure is not applicable for double stack installations (R/3 and J2EE Engine running in the same instance).
    1. Open the SAP Management Console.
    2. Navigate to the Process table of the Java instance.
    3. Right-click on the Java node and choose "Dump Stack Trace" from the context menu.
Alternative procedure on iSeries
    1. Log on as OFR.
    2. To check the java processes in your subsystem, enter command
    WRKACTJOB SBS(R3_)

    Jobs labeled "PGM-JLAUNCH" in column "Function" are java processes. In earlier support packages, those processes had the job name "JLAUNCH", with higher SP levels, they have job names "SDM", "DISPATCHER", "SERVER0" etc. Please substitute in the following lines accordingly.
    3. Push on function key F11 two times to get the user and the process number of the JVMs (job name ). These values are needed to create a java thread dump.
    4. To create the java thread dump, do one of the following:
      a) Enter command
      DMPJVMSAP JOB() USER() NUMBER()

      DMPJVMSAP creates a spool file QDMPJVM. In this spool file not only all java threads dumps are to be found but also the heap stack and the class loader information. DMPJVM does not stop a running JVM. This means that you can create a java thread dump at any time without stopping a JVM.

      Note that DMPJVMSAP only works with Classic VM. If your system is configured to run with IT4J this method cannot be used. Choose the commonly described method using jcmon for IT4J. The one below is only applicable to systms using Classic VM.
      b) Go to menu R3PROBLEM and choose option 16 'Trigger Java VM Dump' also specifying the job data. Location of the dump depends on the JVM you are using and on the patch level of your system (see generic description above).
    5. To look at the spool file created by DMPJVMSAP, enter command WRKSPLF. Use the function key F11 to collect the following information: file number, job name and job number.
    6. Create a text file containg the needed java thread dump information to make the information accessable also to users of other operation systems.
    (Attention: Perform the next steps on your Windows PC.)
    For this you may use the batch file getJavaDumpFile.bat attached in this SAP Note. Unattach the file getJavaDumpFile.TXT into a temporary directory on your Windows PC and rename it to getJavaDumpFile.bat. Run the batch file and you will get a file called javadump.txt containing the java thread dumps:
    getJavaDumpFile.bat


    (for example: getJavaDumpFile.bat as0096 SIDOFR secret QDMPJVM 2
    QPADEV0004 SIDOFR 060594)

Posted by Mohammed Bohra at 1:09 AM 0 comments
Subscribe to: Posts (Atom)