Error During Deployment

JSPM cannot deploy all components. The deployment of at least one of the components that you selected has finished either with status DEPLOYED WITH ERROR or with status NOT DEPLOYED.

Possible Reasons

Check if the /usr/sap/<SID>/<Central instance name>/j2ee/cluster/<Server process>/log/defaultTrace.<xx>.trc file contains an OutOfMemory exception. Such an exception occurs if not enough J2EE Engine memory is available.

Solution

On all operating systems - using the Config Tool, set the heap size and permanent space Java parameters as described in SAP Note 723909.

On Microsoft Windows - get the SAP Address Space Viewer and rebase the DLLs as described in SAP Note 129813 and SAP Note 736462.

For more information about troubleshooting the J2EE Engine, see SAP Note 764417.

For more information about setting the Java parameters, see Configuring Instance Properties .

Check if the last JSPM_MAIN<_x_xx>.log file contains the following message:

Error during deployment. See <path>\sdmcl<yyyymmddhhmmss>.log for details.

The SDM log file contains the following message:

Aborted: development component 'com.sap.ip.bi.ra.j2ee'/'sap.com'/'SAP'/'7.00.20050728182148.0000': SDM could not start the J2EE cluster on the host <host>. The online deployment is terminated. A timeout has occurred while ensuring that process server <name> is in final state.

Possible Reasons

• After an upgrade from SAP NetWeaver release 2004 to SAP NetWeaver release 7.0, according to the new SAP security policy, the J2EE Engine administrator user may be prompted to change his or her password. The password is changed in the User Management Engine (UME).
• According to SAP security policy, the J2EE Engine administrator password must be changed every 90 days. The password is changed in the UME.

However, SDM reads the J2EE Engine administrator password not from the UME, but from the secure storage instead. The J2EE Engine administrator password is not changed in the secure storage. For more information, see SAP Note 870445.

Solution

Change the J2EE Engine administrator password in the secure storage. For more information, see Modifying the Default Administrator User .

JSPM hangs on during deployment. If your database is MaxDB, the deployment may continue longer than expected (the maximum expected deployment time is about 3 hours).

Possible Reasons 1

If your database is MaxDB, the logs may be full.

Solution 1

If your database is MaxDB, we recommend that you set the overwrite mode for the log area. For more information, see Changing Log Settings .

Possible Reason 2

If your database is MaxDB, the parameter M AXUSERTASKS may have insufficient value.

Solution 2

If your database is MaxDB, we recommend that you set the parameter MAXUSERTASKS to at least 50.

For more information about MAXUSERTASKS see General Database Parameters .

For more information about changing database parameters see Displaying and Changing Database Parameters .

JSPM cannot deploy all components. Check if the last JSPM_MAIN<_x_xx>.log file contains the following message:

Error during deployment. See <path>\sdmcl<yyyymmddhhmmss>.log for details.

The SDM log file contains one of the following messages:

SDM could not start the J2EE cluster on the host <hostname>! The online deployment is terminated. A timeout occurred during the cluster running verification!

Or

SDM could not stop the J2EE cluster! The offline deployment is terminated. A timeout has occurredwhile ensuring that process <process ID> is in final state!

Possible Reasons

The preset time interval during which SDM waits for the J2EE Engine to completely start or stop is too small.

Solution

You have to increase the wait time interval of SDM to a value that is large enough. You can do this by changing the:

• JSPM configuration
• SDM configuration

Changing the JSPM Configuration

1. Stop JSPM.
2. Open usr/sap/<SID>/JC<instance number>/j2ee/JSPM/param/jspm_config.txt.
3. Add property /jspm/sdmTimeout . Its default value is 21600 seconds. If there is no such property in the file, JSPM does not change the SDM timeout.
4. You can set a different value for the sdmTimeout property. The value must be a positive whole number. To do this, in the configuration file enter:

/jspm/sdmTimeout = <some value>

1. Start JSPM.

Changing SDM Configuration

You can find detailed instructions in SAP Note 739190.

SDM update fails. Following error message can be found in the JSPM log file:

Cannot update SDM. Could not stop SDM server. Cannot execute Java
process for stopSDM with parameters XXXXX. Return code condition
success evaluated to false for process java for action ACTION_STOP

Following error can be found in the SDM shutdown log file OPERATESDM_X.ERR:

Shutdown failed: Error disabling SDM Process with JStartup Framework
(Could not create JStartupClusterController: A remote host refused an
attempted connect operation.)/
Could not shutdown server: Could not shutdown Server(4)
Details: Shutdown failed: Error disabling SDM Process with JStartup
Framework (Could not create JStartupClusterController: A remote host
refused an attempted connect operation.)/
Processing error. Return code: 4

Possible Reasons

The JSPM tool is trying to stop the SDM server via a "shutdown" request but the system message server port and host stored in SDM repository 

/usr/sap/<SID>/<Central instance name>/SDM/program/config/sdmrepository.sdc are wrong.

Solution

Register proper system message server port and host in SDM with command sdm registerjstartup as per the Note 780670:

1. Stop SDM server with SAP MMC or JCMON depending on the OS.
   Caution

   stopserver script does not work correctly.

2. Go to the /usr/sap/<SID>/<Central instance name>/SDM/program directory.
3. In the command line, execute the following commands:

   On a Microsoft Windows system execute:

sdm jstartup "mode=standalone"

sdm registerjstartup sdmhome=<...> jstartupdir=<...> mshost=<...> msport=<...>

where:

• jstartupdir - the directory in which the JStartup Framework software is installed
• mshost - the host name of the message server
• msport - the port on which the message server waits for requests

sdm jstartup "mode=integrated"

On a UNIX system execute:

./sdm.sh jstartup "mode=standalone"

./sdm.sh registerjstartup sdmhome=<...> jstartupdir=<...> mshost=<...> msport=<...>

where

• jstartupdir - the directory in which the JStartup Framework software is installed
• mshost - the host name of the message server
• msport - the port on which the message server waits for requests

./sdm.sh jstartup "mode=integrated"

On an IBM eServer iSeries system execute:

QSH

cd /usr/sap/<SID>/<Central instance name>/SDM/program

./sdm.sh jstartup "mode=standalone"

./sdm.sh registerjstartup sdmhome=<...> jstartupdir=<...> mshost=<...> msport=<...>

where:

• jstartupdir - the directory in which the JStartup Framework software is installed 
• mshost - the host name of the message server
• msport - the port on which the message server waits for requests

./sdm.sh jstartup "mode=integrated"

1. Run the StartServer script file.
2. Restart JSPM.

For more information, see the SDM command line documentation in the /usr/sap/<SID>/<Central instance name>/SDM/program/docdirectory.

Deployment of some Web Dynpro applications ends with the following error in the SDM log file:

Warning: Finished with warnings: development component XXXXXX:
Caught exception during application startup from SAP J2EE Engine's deploy service:
      java.rmi.RemoteException: Error occurred while starting application XXXXXX and wait.
      Reason: Clusterwide exception: server ID YYYYYY:com.sap.engine.services.deploy.exceptions.ServerDeploymentException:
      Application XXXXXX cannot be started. Reason: it has hard reference to resource Web Dynpro with type service, which is not active on the server.

Possible Reasons

The problem appears only after OutOfMemoryError (OOM) is thrown when deploying certain libraries, such as the aii-library. Typically, this happens on 64-bit hosts with only 1G heap size. OOMs appear in the logs before this deployment, which is an indicator that the J2EE Engine is in an unstable state, which can lead to an unpredictable behavior.

As a result, one or more of these libraries become invisible after the deployment. This in turn breaks the entire deployment sequence, stops the Web Dynpro service and leads to the error described.

Solution

The error can be avoided completely by adjusting the memory settings as specified in note 723909 before applying the patch.

If the error occurs, the deployment can continue by first adjusting the memory settings, and then applying the workaround as per note 723909:

1. Stop the JSPM tool.
2. Apply note 723909.
3. Start the SDM tool from the RemoteGui.bat or RemoteGui.sh script.
4. Redeploy the following SDAs with the SDM tool as you get them from the /usr/sap/<SID>/<Central instance name>/SDM/root/origin/sap.com directory:
   • com.sap.aii.proxy.framework/SAP AG/0/7.00XX…/aii_proxy_rt.sda
   • com.sap.aii.util.xml/SAP AG/0/7.00XX…/aii_util_xml.sda
   • com.sap.util.monitor.grmg/SAP AG/0/7.00XX…/grmg.sda

1. Check whether Web Dynpro service is up and running.
2. Restart the normal deployment process with the JSPM tool.

After the end of the deployment the system is left in SAFE mode. This can be observed in SAP MMC or in the file /usr/sap/<SID>/<Central instance name>/j2ee/cluster/instance.properties, property instance.runMode .

Possible Reasons

JSPM sets the system in SAFE mode during most of the updates, particularly deployment of new support package stack, update of portal applications and so on. Deployment in SAFE mode is more stable and overall execution time is lower than deployment while system is in NORMALmode. After the end of the deployment, JSPM tries to set the system back to NORMAL mode. This switch may fail because of various reasons - misconfigured system, executable permissions and so on. The system in such case is updated but is left in SAFE mode.

Solution

Set system in NORMAL mode manually. Use the procedure as per the Note 780670:

1. Stop manually the JSPM process.
2. Start the Config Tool script file from the /usr/sap/<SID>/<Central instance name>/j2ee/configtool/directory.
3. From the menu choose File → Safe Mode. A dialog box appears.
4. Choose Nofrom the Safe Mode Enabled drop-down list.
5. Choose OK.
6. Save the settings and confirm all the messages that are displayed.
7. Restart the J2EE Engine.