Command Line Interface Documentation for SDM

1 .....................................................................................................................................2 IntroductionSyntax of the Parameters ...................................................................................................................2

Note for Windows Users ..................................................................................................................3 Globally Valid Parameters ................................................................................................................3

2 ...................................................................................................3 Installing and Updating the SDMInstalling the SDM..............................................................................................................................3

Prerequisites .....................................................................................................................................4 Interactive Installation ......................................................................................................................4 Non-Interactive Installation..............................................................................................................4 Installing SDM from a packed SDM Kit jar.....................................................................................5

Updating the SDM..............................................................................................................................5 Prerequisites .....................................................................................................................................5 Interactive Update ............................................................................................................................5 Non-Interactive Update ....................................................................................................................5 Ignoring the version of the currently installed SDM ........................................................................6 Follow-Up Actions ...........................................................................................................................6

3 ...........................................................................................................6 Registering the Secure Store4 .................................................................7 Updating the System State Management with the SDM5 ............................................................................................................8 Configuring Target Systems

Procedure ............................................................................................................................................8 DTD for targetconfigfile.....................................................................................................................8

6 ................................................................................................9 Configuring Substitution Variables7 ............................................................................................................12 Deploying SDAs and SCAs8 .......................................................................................13 Undeploying Development Components9 ..........................................................................14 Integration of SDM in the JStartup Framework10 .....................................................................................15 Starting and Stopping the SDM Server11 ...............................................................................................................15 Starting the SDM GUI12 ....................................................................................16 Changing the (remote) SDM Password13 .......................................................................................16 Changing the JDK Used by the SDM14 .........................................................................17 Changing the JVM Options Used by the SDM15 ...................................17 Starting and Stopping the J2EE Engine Automatically with the SDM16 ..............................................................................17 Starting and Stopping the SDM http server17 ...........................................................................................18 Checking for running SDM server18 ...........................................................................18 Getting information about the deployed DCs19 ...........................................................................20 Packing an SDM installation into a JAR file20 ............................................................21 Getting a list of overwritten Support Package Patches21 .........................................................................21 Creating Software Components archive file(s)22 .......................................................................................................................22 Other Commands23 ..............................................................................................................................23 Return Codes

1/24

1 Introduction The Software Deployment Manager (SDM) offers several different external interfaces:

GUI: You can use the GUI to view the SDM Repository, and create and configure new target systems. You can also define substitution variables and deploy archives. The GUIs own documentation describes how to use it.

Java API: The SDM group provides the archive SDMClient.sda. This archive contains a client library that uses a Java API (Application Programming Interface) to access the SDM. The client library functions are described in a Java document in SDMClient.sda.

Command Line Interface: You can use commands (in a command prompt window, for example) to access almost all SDM functions.

This document describes the syntax and semantics of all available commands in the Command Line Interface. The state of the software discussed here corresponds to SAP Web Application Server 6.30. Before you can use the Command Line Interface, you must make a complete installation of the SDM and a JDK (Java Development Kit) with version 1.3 or higher. Since we have encountered problems with Windows 2000 SP2, we recommend strongly that you use Windows 2000 SP3. The main SDM class is SDM.class. This class is already flagged as the main class in SDM.jar, and does not need to be specified again by the caller. This is also not recommended. To use the SDM Command Line Interface, you must start the Java Virtual Machine as follows: java -jar /bin/SDM.jar where : Installation directory of the SDM : Name of the SDM command : Valid parameters of the SDM command After the successful installation of the SDM, you can simplify the way you call an SDM command with the following scripts: \sdm.bat (Windows) /sdm.sh (Unix) From now on, the call options described here for the SDM will be shortened to sdm for simplicity. Syntax of the Parameters A parameter is always specified in the form =. The number of valid parameters varies according to the SDM command. Some parameters must be specified; others are optional. This document indicates optional parameters by placing them in square brackets: []. Do not enter the square brackets in the command line. If, in principle, the valid values of a parameter can be used without restrictions (for example, when specifying a file name or directory name), then the document indicates this as follows: =. However, if there are restrictions on the values permitted for a

2/24

parameter, then the values are placed in a list, and divided by pipes. For example, a parameter whose permitted values are a, b and c is shown as =a|b|c. If command parameters are mutually exclusive, then these parameters are placed in a list and divided by pipes: sdm | If groups of parameters for a command are mutually exclusive, then the parameters of each group are placed in braces and the groups are divided by pipes: sdm { }|{ }

Note for Windows Users On Windows, each parameter must be included in quotation marks in the command line: sdm = = Globally Valid Parameters Some parameters can be added to every SDM command. The meaning of these parameters is explained in this section. They are not explained again when the individual SDM commands are discussed, as long as their meaning does not change. The following parameters are globally valid:

sdmhome: Specifies the installation directory of the SDM. This parameter is mandatory for some SDM commands. The explanation of these commands indicates this by including this parameter in the command syntax. If the parameter is optional for a command, and the caller does not give it a value explicitly, then the SDM takes the current working directory as the value of the parameter. The scripts sdm.bat and sdm.sh already contain this parameter, with the name of the installation directory as its value. If you use these scripts, then you cannot specify sdmhome.

logfile: Specifies the name of a file to which the SDM writes a log for the executed command. Caution: This file is constantly being overwritten. For a complete log of all SDM activities, see the subdirectory log of the sdm_home directory.

logtoconsole: Controls whether the SDM adds the log of the executed command to the other log files as part of the standard output. This happens when logtoconsole=true.

syntaxcheck (since 6.30 SP7): A means to check whether a given SDM command (including its parameters) is syntactically correct without actually executing it. When adding syntaxcheck=true to any SDM command, the command either returns 0 if the syntax is correct or returns 12 if it is not. In most cases this parameter helps to find out whether a given SDM version supports some command or parameter. The usage of this syntax check has some limitations, however: It does not recognize if exactly one of several optional parameters is specified, as requested for example by the deploy command syntax. Further, for a parameter that allows only a set of fixed values the syntax check does not recognize if the assigned value is valid.

2 Installing and Updating the SDM Installing the SDM The installation of the SDM includes creating the sdm_home directory, copying and modifying all required files, and preparing various start scripts that make it easier to use the SDM.

3/24

Prerequisites You must unpack the SDM installation package (SDMKit.jar) in the temporary directory . You can install the SDM in one of two ways. For simplicity, SDMKit.jar contains two scripts, install.csh and install.bat, which support the interactive installation, and which give the parameter popdir described below the value ..

Interactive Installation Use the command autoinstall to start the interactive installation of the SDM:

1. Use the following call to start the interactive installation mode: java -jar /bin/SDM.jar autoinstall

2. You then see several questions about the installation of the SDM (for an explanation, see below). Each question has a default answer. Choose Enter to confirm this answer. To overwrite a default, enter your preferred value, and then choose Enter.

Note: You can also use the autoinstall command for a partly interactive installation mode by specifying some values as parameters when you call the command. The user then only enters those values that are not specified as parameters when the installation is started. The parameters are identical to the parameters of the non-interactive installation.

Non-Interactive Installation Use the command autoinstall to start the non-interactive installation of the SDM: You must specify all data required for the installation and configuration of the SDM when you call the autoinstall command: java -jar /bin/SDM.jar autoinstall sdmhome= sdmroot= sdmguiport= sdmhttpport= sdmadminport= javahome= popdir= memory= 64bitswitch= [hostname=] where

sdmhome: Target directory of the installation. This directory is created if it does not already exist. If this directory already exists, then it must be empty.

sdmroot: Usually a subdirectory of sdmhome. The versions of the SDAs and SCAs deployed with the SDM are installed in this directory.

sdmguiport: The SDM can be used with a remote GUI. This port is used for the communication between the SDM server and the remote GUI. You must make sure that this port is not used elsewhere on the host.

sdmhttpport: When you start the SDM as a server, you are also offered a http server. You can use this port to address the http server. You must make sure that this port is not used elsewhere on the host.

sdmadminport: This port is used for internal SDM purposes only. You must make sure that this port is not used elsewhere on the host.

javahome: Directory in which a JDK with Version 1.3 or higher is installed. popdir: Directory into which the installation package (SDMKit.jar) of the SDM

has been unpacked. (PoP: Point of Presence) memory: Set the amount of memory in Mega Bytes the SDM Java process shall use. 64bitswitch: Boolean parameter that specifies whether or not a 64-bit-runtime

switch shall be used with the JDK. hostname: Specify the host name where SDM is being installed. It needs for HA

systems where Local host name is different from Virtual host name and SDM should work with the Virtual host name. If you dont specify SDM will give the Local host name.

4/24

Result of the installation: The SDM has been installed and you can start to use it. After the installation, you can execute other SDM commands with the scripts sdm.bat and sdm.sh described in the introduction.

Installing SDM from a packed SDM Kit jar This paragraph describes the re-install part of copying an existing SDM installation to a new location (supported since 6.30 SP7 - see the documentation of the createsdmkitjar command). To do this, you first need to extract the SDM Kit jar file containing the existing SDM installation to a temporary directory. From here, you can go on in the same way as you install an initial SDM installation as described above, choosing either the interactive or the non-interactive mode. As an addition, specify the optional parameter extractpackedinst=true for the autoinstall command. If development components have been excluded or if SDA files were not accessible when the SDM Kit jar has been packed, then the autoinstall command returns with return code 2 (warning.) After re-installing SDM, make sure to deploy those SDAs again whose development components have been excluded when the SDM Kit jar has been packed. Finally, deploy all filesystem SDAs again by executing the SDM command deploy softwaretype=FS. Updating the SDM Periodically, you can update the SDM installation with a new version.

Prerequisites You already have a complete SDM installation on your host. You must unpack the SDM installation package (SDMKit.jar) in the temporary directory . Before you can start the update, you must stop the SDM Server, if it is running: /StopServer(.sh) Also make sure that the jstartup mode has been set to standalone: sdm jstartup mode=standalone As with the installation, you can update the SDM in one of two ways. For simplicity, SDMKit.jar contains two scripts, update.csh and update.bat, which support the interactive update, and which give the parameter popdir the value ..

Interactive Update Use the following syntax to start the interactive update mode: java -jar /bin/SDM.jar autoupdate

In this mode, the SDM asks you to enter some values so that it can be updated successfully.

Non-Interactive Update Use the following syntax to start the non-interactive update mode: java -jar /bin/SDM.jar autoupdate sdmhome= popdir= The parameters are explained in the description of the installation.

5/24

Ignoring the version of the currently installed SDM Usually, you only want to update an SDM installation with a higher version than the one currently installed. In order to not accidentally downgrade an SDM installation to a lower version, the SDM update routine has a built-in version check that compares the versions of both the currently installed SDM and the new SDM. Thus, an accidental downgrade will be prevented. There may be, however, situations that actually require a downgrade of an SDM installation to a lower version. Then, the SDM autoupdate command offers a parameter ignoreversion=true such that the update will not be prevented because of a version conflict between the currently installed and the new SDM. This parameter is new with 6.30 SP7 and applies to both the interactive and the non-interactive update mode. In the interactive mode, you are not asked to enter a value for this parameter even if you did not specify it on the command line. Note that this parameter does not have any impact on the comparison between the SDM repository versions of the new and the installed SDM. The SDM repository is the SDM internal database whose structure evolves over time and therefore gets assigned new versions from time to time. There is no way to downgrade an SDM installation to another version that effectively has a lower SDM repository version.

Follow-Up Actions If you set the jstartup mode from integrated to standalone before the update, reset it to integrated now: sdm jstartup mode=integrated If you stopped the SDM Server before the update, restart it now: /StartServer(.sh)

3 Registering the Secure Store SAP offers a storage option for security-sensitive data. The SDM can use this feature to get the configuration data of the target systems. The Secure Store itself and the data stored with it are created and maintained with the Config Tool of the SAP J2EE Engine. You can find the documentation for the Config Tool in the SAP Library of the SAP Web Application Server under SAP NetWeaver Application Platform (SAP Web Application Server) J2EE Technology in SAP Web Application Server Administration Manual Server Administration SAP J2EE Engine Administration Tools Config Tool. Usually, SAPinst creates the Secure Store and provides the software needed to access it. SAPinst also uses the registersecurestore command to register the secure store for the SDM. sdm registersecurestore sdmhome= libdir= datafile= keyfile= systemname= where

libdir: Directory where the software has been installed that needs to be used by SDM to access the Secure Store.

datafile: Secure Store data file. keyfile : File that contains the key that enables the SDM to use the Secure Store. systemname: Name of the system

6/24

The command unregistersecurestore discontinues the usage of the Secure Store by the SDM. sdm unregistersecurestore sdmhome= [execmode=true|false] where

execmode: Defines whether the usage of the Secure Store by the SDM is really discontinued. This only happens if its value is true. The default value false just displays the current configuration data for the Secure Store.

Caution: The commands registersecurestore and unregistersecurestore delete the configuration of the target systems. Only execute these commands if you have good reason. The target systems and the deployed software are not deleted by the commands. The command getsecustoreconfig makes the SDM write the Secure Store configuration data to a file in XML format. sdm getsecustoreconfig sdmhome= secustoreconfigfile= where

secustoreconfigfile contains the name of the file to which the configuration is written in XML format. Caution: This overwrites an existing file.

Note: All Secure store commands can be executed only if SDM server is stopped (see stop/start SDM Server) and it is in standalone mode (see jstartup). It would be better to return SDM in the same state as it was before the execution.

4 Updating the System State Management with the SDM

After a deployment or undeployment, the SDM gives you the option of updating the management of the system state with regard to all deployed development components and software components (Cvers). During the installation of SAP Web AS 6.30, an appropriate function is created in the J2EE Engine, which allows other applications to query this system state information. The management of this system state is not the same as the SDM Repository. Use the following command to activate and deactivate this option: sdm systemcomponentstate mode=activate|deactivate|sync where

mode determines which action needs to be performed. The value activate activates the automatic update of the system state management, the value deactivate deactivates this update. The value sync copies the current content of the SDM Repository to the system state management function. This is usually done by SAPinst directly after setting up the system state management.

Note: systemcomponentstate command can be executed only if SDM server is stopped (see stop/start SDM Server). It would be better to return SDM in the same state as it was before the execution.

7/24

5 Configuring Target Systems Before you can deploy SDAs and SCAs with the SDM, you must first register target systems in the SDM. You might also need to provide configuration data, such as logon information, for these target systems. Note: You only need to enter the required security-relevant access data, such as the and , in the configuration of the target systems if you operate the SDM without Secure Store. In the standard Secure Store configuration, you use a link to the data in the Secure Store to configure the target systems. This link is defined by the parameter of the target system. Prerequisites To register a new target system (a target system with a server type that does not yet exist in the SDM Repository), you must provide the following data:

1. Name of the target system 2. Server type of the target system that you want to create. You can choose from three

server types: SAP J2EE Engine Java FS DATABASE

Procedure You can use the registertarget command to register new target systems in the SDM Repository: sdm registertarget targetname= servertype= where

targetname: Your choice of name for the target system in the SDM Repository. You can use this name to identify the target system later. The name must be different from the names of all the other target systems in the SDM Repository.

servertype: Type of the new target system. Possible values: SAP J2EE Engine, Java-FS, DATABASE.

Note: You can register only one target system for each server type. If you try to register a second target system for a server type, you cause an error, and the SDM terminates with the return code 4. After you have registered all the necessary target systems in the SDM Repository, you can configure them with the following command: sdm gettargetconfig targetconfigfile= where

targetconfigfile: File generated by the SDM. This file contains the configuration data for all target systems registered in the SDM Repository in the XML format described below. Note: This file is overwritten if it already exists.

The configuration file generated by the SDM meets the following DTD (Document Type Definition). If a configuration file is sent to the other commands for configuring target systems, then it must also meet this DTD: DTD for targetconfigfile

8/24

(content of element is value of parameter) Now the user can change or complete the configuration data file generated by the SDM. You can use the command savetargetconfig to copy the complete configuration data into the SDM Repository: sdm savetargetconfig targetconfigfile= where

targetconfigfile: File read by the SDM. This file must contain the configuration data for all target systems registered in the SDM Repository in the XML format specified above.

Result of the configuration: Once you have specified all necessary configuration data for a target system, the value of the XML attribute isComplete of the XML element TargetSystem in the file specified by targetconfigfile is true when gettargetconfig is called. This value indicates that you can now deploy archives in this target system. Note: All target system commands can be executed only if SDM server is stopped (see stop/start SDM Server) and it is in standalone mode (see jstartup). It would be better to return SDM in the same state as it was before the execution.

6 Configuring Substitution Variables Substitution variables enable you to deploy archives without interaction. Instead of entering values for deployment parameters during the deployment, substitution variables are included as placeholders for the actual values in the deployment descriptors. You can include substitution variables and their current values in the SDM Repository. During deployment, the SDM cooperates with the SAP J2EE Engine to make sure that the variables in the descriptors are replaced with the current values. The following four commands handle substitution variables in the SDM Command Line Interface: sdm getsubstvars substvarfile= where

substvarfile: File generated by the SDM. This file contains the configuration data for all substitution variables registered in the SDM Repository in the XML format described below. Note: This file is overwritten if it already exists.

If no file can be written (because, for example, an authorization is missing), an error occurs. The DTD of the resulting XML file is as follows:

9/24

(content of element is parameter value)

sdm addsubstvars substvarfile= [addmode=strict|replace_existing] where

substvarfile: File read by the SDM. For details, see below. addmode: Describes two variants of this command, strict and

replace_existing. If you do not specify addmode when you execute the command, then the default is strict.

You can use this command to add new substitution variables to the SDM Repository, or modify the definition of existing substitution variables. The parameter addmode is optional and describes two variants of this command, strict and replace_existing. If you do not specify addmode when you execute the command, then the default is strict. If addmode=strict, then all definitions are read from the XML file specified by substvarfile. The SDM then uses the name to check whether all of these substitution variables do not yet exist in the SDM Repository. If at least one substitution variable has already been registered in the SDM Repository, then an error occurs, and the repository is not changed. Otherwise, the specified substitution variable types (type attribute), are checked against the specified substitution variable values (content of the Param element). To do this, the string representation of the value is converted to the specified type. If this conversion fails for a least one of the substitution variables, then an error occurs, and the SDM Repository is not changed. The new substitution variable definitions are added to the SDM Repository only if none of the substitution variables are already registered in the SDM Repository, and all values can be converted to the specified types. If the content of the XML element Param (which represents the value of the substitution variable) is empty, then the value of the substitution variable in the SDM Repository is set to the special value not set (similar to the null value in databases). Substitution variables whose value is not set cause a deployment error if needed for a deployment. If addmode=replace_existing, then all substitution variable definitions are read from the XML file specified by substvarfile. The specified substitution variable types (type attribute) are then checked against the specified substitution variable values (content of the Param element). To do this, the string representation of the value is converted to the specified type. If this conversion fails for a least one of the substitution variables, then an error occurs, and the SDM Repository is not changed. Otherwise, the new definitions are copied directly to the SDM Repository, where they overwrite any existing substitution variables. If a substitution variable does not yet exist in the SDM Repository, then it is added to the definition. If a substitution variable has already been registered in the SDM Repository, then it is overwritten by the new attribute values. This is one way of changing the displayName, type, and the hide attribute. If the content of the XML element Param (which represents the value of the substitution variable) is empty, then the value of the substitution variable in the SDM Repository is set to the special value not set (similar to the null value in databases). Substitution variables whose

10/24

value is not set cause a deployment error if needed for a deployment. For this command, the DTD of the required XML file is the same as the DTD of the getsubstvars command specified above. A tolerant check is made on the DTD when the XML file specified by substvarfile is read. The required attributes of the element Param must exist, but any other attributes are ignored. Even Param elements whose name attribute have the same value are ignored. The Param element that is read first wins. sdm modifysubstvars substvarfile= where

substvarfile: File read by the SDM. For details, see below. This command is used to modify substitution variables already registered in the SDM Repository. First, all substitution variable definitions are read from the XML file specified by substvarfile. The SDM then uses the name to check whether all of these substitution variables already exist in the SDM Repository. If at least one substitution variable does not yet already exist in the SDM Repository, then an error occurs, and the repository is not changed. Otherwise, all specified substitution variables are checked to see whether the specified values (content of the Param element) can be set (whether the specified string representation can be converted to the type of the substitution variables). If at least one value cannot be converted successfully, an error occurs and the SDM Repository cannot be changed. Otherwise, the specified attributes and values are used to change the substitution variables in the SDM Repository. If the attribute displayName (see DTD below) is not specified, then the displayName of the substitution variables is not changed. If the content of the XML element Param (which represents the value of the substitution variable) is empty, then the value of the substitution variable in the SDM Repository is set to the special value not set (similar to the null value in databases). Substitution variables whose value is not set cause a deployment error if needed for a deployment. The following describes the DTD of the XML file that you need to specify with this command any other specified attributes (type, hide) of the XML element Param are ignored. Also, any other Param elements with the same attribute value for name (as with addsubstvars and removesubstvars) are ignored: (content of element is parameter value)

sdm removesubstvars substvarfile= [removemode=strict|ignore_nonexisting] where

substvarfile: File read by the SDM. For details, see below. removemode: Describes two variants of this command, strict and

ignore_nonexisting. If you do not specify removemode when you execute the command, then the default is strict.

11/24

You can use this command to delete substitution variables from the SDM Repository. If removemode=strict, then the names of all substitution variables are read from the XML file specified by substvarfile. The SDM then uses the name to check whether the specified substitution variables do not yet exist in the SDM Repository. Only when all specified substitution variables are registered in the SDM Repository are the substitution variable definitions removed from the SDM Repository. Otherwise, an error occurs and the SDM Repository is not changed. If removemode=ignore_nonexisting, then the names of all substitution variables are read from the XML file specified by substvarfile. Then all substitution variable definitions are removed from the SDM Repository. Any specified substitution variables that are not registered in the SDM Repository are ignored (an entry is made in the log file). The following describes the DTD of the XML file that you need to specify any other specified attributes (displayName, type, hide) of the element Param are ignored. Also, any other Param elements with the same attribute value for name (as with addsubstvars and modifysubstvars) are ignored: (actual identification)

Note: All Substitution Variables commands can be executed only if SDM server is stopped (see stop/start SDM Server) and it is in standalone mode (see jstartup). It would be better to return SDM in the same state as it was before the execution.

7 Deploying SDAs and SCAs Unlike SDM 6.20, the deployment of SDAs or SCAs with the SDM Command Line Interface is now a one-step process. You can deploy archives with a single command: sdm deploy file=|list=|softwaretype= [updateversions=lower|samelower|lowerchanged|all] [onerror=stop|skipdepending|ignore] where

file: Name of an SDA/SCA that you want to deploy with the SDM. You cannot specify the list or softwaretype parameter if you use the file parameter. This means that the execution of the deploy command with this parameter can be used to deploy precisely one SDA/SCA.

list: Name of a text file that contains the names of the SDAs/SCAs that you want to deploy. You cannot use the file or softwaretype parameter if you specify this parameter. This means that the execution of the deploy command with this parameter can be used to deploy multiple SDA/SCAs simultaneously.

softwaretype (since 6.30 SP7): Name of a software type. All SDAs currently deployed for the specified software type will be deployed again. If some of the SDAs that are currently deployed cannot be accessed in the SDM root directory, deployment aborts with an error message. You cannot specify the file or list parameters if you use the softwaretype parameter.

updateversions: Determines the comparison of versions between a deployed SDA/SCA and the new SDA/SCA. lower indicates that a deployed SDA/SCA can be updated only if its version is lower than the SDA/SCA specified in the command.

12/24

lower is the default value of this parameter, which means it is used automatically if the parameter is not specified with the deploy command. samelower lets you deploy a version that has already been deployed with same or lower version. lowerchanged update only lower versions of a deployed SCA and top level SDA and only changed versions of a deployed SDA contained in an enclosing SCA. all permits an update regardless of the version of the deployed SDA/SCA.

onerror: Optional parameter that controls the responses to an error. stop (default) stops the deployment after the first deployment error. Any missing SDAs/SCAs are not deployed. skipdepending continues the deployment after a deployment error, but only for any missing SDAs/SCAs that do not have dependencies on the deployment with the error. ignore continues the deployment with any SDAs/SCAs that are still missing. Only experts should select the last option, since this can cause inconsistencies in the target systems. Currently, the parameter onerror is only used for errors in the actual deployment. For example, if a specified SDA/SCA cannot be found or read, or if dependencies between SDAs cannot be resolved, then the deployment always stops with an error message.

If, for some reason, you cannot deploy the SDAs/SCAs (missing target system, incompletely configured target system, unknown substitution variable, missing value for a substitution variable, SDA/SCA version cannot be deployed) an error occurs you can find details on the cause of the error in logfile. Note: deploy command can be executed only if SDM server is stopped (see stop/start SDM Server) and it is in standalone mode (see jstartup). It would be better to return SDM in the same state as it was before the execution.

8 Undeploying Development Components You can undo the deployment of SDAs with the command undeploy. To do this, the caller must specify the name and vendor of the development component of the SDAs. The syntax is as follows: sdm undeploy list= | { compname= compvendor= } [undeploydb=yes|no] where

list: Specifies the name of a file. This file contains a list of name attributes and vendor attributes of the development components that you want to undeploy. The list must conform to the XML format shown below.

compname, compvendor: Specify the name attribute and vendor attribute of a development component that you want to undeploy. You can only undeploy one SDA in each call with this variant.

undeploydb: Optional parameter that controls whether archives deployed on DB target(table schemas and table contents) will be undeployed. If the parameter is not specified, then the behaviour is the same as undeploydb=no(default behaviour).

The DTD that must be conformed to by the file specified in the parameter list is as follows: Notes:

The SDM refuses to undeploy development components if other deployed development components have dependencies on them. You must undeploy the dependent development components first.

13/24

Currently, you also cannot undeploy complete software components. If you want to undeploy a complete software component, then you must do this by undeploying its development components.

undeploy command can be executed only if SDM server is stopped (see stop/start SDM Server) and it is in standalone mode (see jstartup). It would be better to return SDM in the same state as it was before the execution.

9 Integration of SDM in the JStartup Framework The JStartup Framework is the central monitoring and administration tool for controlling the services and processes that comprise a complete J2EE Server installation. These include the following:

Database instance J2EE instances

o J2EE Dispatcher o J2EE Server node(s) o SDM Server

The SDM itself is an update and installation tool. For this reason, the SDM must also support situations in which the JStartup Framework is not available. In addition, SAPinst uses the command line interface of the SDM, which is not compatible with a running SDM Server. Therefore, you must integrate the SDM into the JStartup Framework in such a way that it continues to run in the following situations:

JStartup is not available You want to use the SDM command line interface, which unlinks the SDM from the

JStartup Framework. You can handle these situations with the commands registerjstartup, unregisterjstartup, and jstartup. When the JStartup Framework is registered, the SDM learns where the software is located, and how it can access the message server. The message server is the communication back end of the JStartup Framework. sdm registerjstartup sdmhome= jstartupdir= mshost= msport= where

jstartupdir: Directory in which the JStartup Framework software is installed mshost: Host name of the message server msport: Port through which the message server waits for requests

sdm jstartup sdmhome= [mode=integrated|standalone] where

mode: Defines whether the SDM is linked to or unlinked from the JStartup Framework

When mode parameter is not specified, then the current state of SDM regarding its linkage to JStartup Framework is displayed(integrated/standalone). sdm unregisterjstartup sdmhome= [execmode=true|false] where

execmode: Defines whether the usage of JStartup by the SDM is really canceled. This only happens if its value is true. The default value false just displays the current configuration data for JStartup .

14/24

Note: registerjstartup and unregisterjstartup commands can be executed only if SDM server is stopped (see stop/start SDM Server) and it is in standalone mode (see jstartup). jstartup command can be executed only if SDM server is stopped (see stop/start SDM Server). It would be better to return SDM in the same state as it was before the execution.

10 Starting and Stopping the SDM Server The SDM usually runs as a server. In this mode, the CMS or an IDE installation can use the Java API to address the SDM. You can also use the server with the remote GUI described below. To start the SDM as a server, use the command server: sdm server sdmhome= Note: If the SDM is linked to the JStartup Framework, the SDM Server is not started directly with this command. Instead, the JStartup Framework is told to start the SDM Server. The JStartup Framework then starts the SDM Server. The shutdown command stops a running SDM Server: sdm shutdown sdmhome= sdmguiport= [sdmhostname=] [password=] [shutdownmode=] where

sdmguiport: Port that the remote GUI and the SDM Server use to communicate with each other. The CMS or IDE also uses this port to address the SDM Server through the Java API.

sdmhostname: Specifies the host on which the SDM Server is running. password: Specifies the password for authentication on the SDM server. Since 6.30

SP5, this parameter will be ignored by the SDM server so that the SDM server can be shut down without authentication.

shutdownmode: Controls the response of the server if another client is also logged on. If this is the case, the server only shuts down if this parameter has the value abort.

During the SDM installation, several scripts are generated in the sdm_home directory. These scripts can be used to start and stop the SDM Server. These scripts also define the appropriate values for sdmhome and sdmguiport:

StartServer.bat, StopServer.bat (Windows) StartServer.sh, StopServer.sh (Unix)

11 Starting the SDM GUI If you have started the SDM as a server (see Starting and Stopping the SDM Server above), then you can call a remote GUI with which you can operate the server. The SDM Server and the remote GUI can run on different hosts, however they must be connected by a network connection. Use the command remotegui to start the remote GUI: sdm remotegui Since there is no current separate installation for the GUI, you must perform a complete SDM installation even if you only want to start the remote GUI on the host.

15/24

Besides the remote GUI there is also a second SDM GUI variant. In this variant, the GUI and the SDM Server run in the same process. This process must run on the host where the SDM Repository is located. Use the command gui to start this GUI: sdm gui sdmhome= During the SDM installation, several scripts are generated in the sdm_home directory. These scripts can be used to call the GUI and the remote GUI.

startSDM.bat (for GUI), RemoteGui.bat (for remote GUI) (Windows) startSDM.sh (for GUI), RemoteGui.sh (for remote GUI) (Unix)

Note: We intend to separate the SDM Server functions from the GUI functions, which is why we recommend that you use the remote GUI variant. In the long term, the second GUI variant will become obsolete.

12 Changing the (remote) SDM Password Since the SDM Server offers you functions that you can use remotely, they must be protected from unauthorized use. For this reason, the SDM requires remote users to authenticate themselves with a password. The default shipped password is sdm. You can change this password in the following ways:

Pushbutton in the remote GUI changepassword command

sdm changepassword sdmhome= newpassword= [password=] where

newpassword: New password password: Old password. Since 6.30 SP5, this parameter has been set optional so

that the password can be changed without reference to its current value. If this parameter is specified, its value will be ignored.

Note: changepassword command can be executed only if SDM server is stopped (see stop/start SDM Server) and it is in standalone mode (see jstartup). It would be better to return SDM in the same state as it was before the execution.

13 Changing the JDK Used by the SDM The scripts and property files generated during the installation of the SDM refer to a specific installation of the JDK. This installation is specified during the installation of the SDM. If required, you can change this setting with the command newjdk (from 630, SP3). You can also set a 64-bit-switch and the memory setting can be adjusted. sdm newjdk sdmhome= [javahome=] [memory=] [64bitswitch=] [sdmjavaparameters=] where

javahome: Installation directory of the JDK (for example, /jdk1.3.1_07) memory: Set the amount of memory in Mega Bytes the SDM Java process shall use. 64bitswitch: Boolean parameter that specifies whether or not a 64-bit-runtime

switch shall be used with the JDK. sdmjavaparameters: The value of the property must start with + for adding or -

for removing java parameters. The command supports configuration of a list of JVM

16/24

parameters. Each of the parameters must be a valid JVM option and they must be space separated. Example: sdm.sh newjdk "sdmjavaparameters=+ -verbose:gc -Xms96M

Note: newjdk command can be executed only if SDM server is stopped (see stop/start SDM Server). It would be better to return SDM in the same state as it was before the execution.

14 Changing the JVM Options Used by the SDM The scripts and property files generated during the installation of the SDM set specific JVM options, which guarantee the successful operation of the SDM server. If specific tuning is required or SDM is not working correctly on the concrete system, it is possible to change the initial settings with the command jvmparams (from 7.0, SP20). When the command is used without add or remove parameters it lists the current JVM settings. sdm jvmparams sdmhome= [javahome=] [add=] [remove=] where

javahome: Installation directory of the JDK (for example, /jdk1.3.1_07) add: Adds the specified JVM option to the list of JVM parameters used at SDM

startup. remove: Removes a JVM option from the list of JVM parameters used at SDM

startup. Note: jvmparams command can be executed only if SDM server is stopped (see stop/start SDM Server). It would be better to return SDM in the same state as it was before the execution.

15 Starting and Stopping the J2EE Engine Automatically with the SDM

The SAP J2EE Engine must be stopped before you can deploy certain types of software (offline deployment). Since 630 SP4, SDM gives you the option of letting the J2EE Engine be stopped and started automatically. You can configure this function: sdm j2eeenginestartstop [mode=automatic|manual] [timeoutmillisec=] Where:

mode: Specifies whether SDM stops the J2EE Engine (automatic) or whether the J2EE Engine is stopped manually (manual).

timeoutmillisec: Specifies the time interval (in milliseconds) after which SDM displays a timeout error message when the J2EE Engine is being started or stopped.

When mode and timeoutmillisec parameters are not specified, then the current state of SDM regarding automatic starting and stopping of the J2EE Engine is displayed (automatic/manual). Note: j2eeenginestartstop command can be executed only if SDM server is stopped (see stop/start SDM Server) and it is in standalone mode (see jstartup). It would be better to return SDM in the same state as it was before the execution.

16 Starting and Stopping the SDM http server SDM http server gives an opportunity to browse in SDM log files using the HTTP protocol. Since 630 SP14, SDM gives you the option to start or stop the HTTP server with function:

17/24

sdm httpserver [sdmhttpport=] [httpsrvmode=active|inactive] where:

sdmhttpport: Specifies the http server port. httpsrvmode: Specifies whether HTTP server is started (active) or stopped

(inactive). When sdmhttpport and httpsrvmode parameters are not specified, then the current state of HTTP server is displayed (active/inactive) and its port. Note: httpserver command can be executed only if SDM server is stopped (see stop/start SDM Server) and it is in standalone mode (see jstartup). It would be better to return SDM in the same state as it was before the execution.

17 Checking for running SDM server Before performing operation concerning SDM you can check whether the SDM server is running and whether your SDM password is a correct one. In order to do this use the command: sdm ping dmhome= sdmguiport= [password=] [logfile=] [sdmhostname=] [logtoconsole=] Where:

sdmguiport: This port is used for the communication between the SDM server and the remote GUI

password: The SDM password sdmhostname: The host on which will be check whether there is SDM server

running

18 Getting information about the deployed DCs The command delivers possibility to get information for all the deployed DCs or for set of them. The result is in XML format. sdm sduinfo sdmhome= [compname=] [compvendor=] [version=] [tofile=] [logtoconsole=] [logfile=] Where:

compname: optional argument specifying the component name, for which information will be get.

compvendor: optional argument specifying the vendor of the SDU which information, has to be get. If there is no "compname" specified but only "compvendor" all the SDUs which belong to the specified vendor will be get.

version: optional argument specifying the version of the result DTD of the returned XML containing the SDU information.

tofile: optional argument (since 6.30 SP6). If provided, the information will be written to the specified file. If this parameter is not provided, the information will be written to the standard output.

If there are no "compname" and "compvendor" specified information for all the SDUs will be get. If both of the arguments are specified an information for the component with name and vendor like the specified will be get. The DTD corresponding to version 1(default version) of the result is:

18/24

]> The DTD corresponding to version 2 of the result is: ]> The DTD corresponding to version 3 of the result is:

SoftwareType, Dependencies, DebugInfo, PathName, ComponentType)>

ScaFileCount, SPNumber, ComponentType)>

19/24

Note: sduinfo command can be executed only if SDM server is stopped (see stop/start SDM Server). It would be better to return SDM in the same state as it was before the execution.

19 Packing an SDM installation into a JAR file In the context of copying a complete J2EE instance of an SAP system, it is necessary to copy the corresponding SDM installation, too. This is supported in SDM since 6.30 SP7. Copying an SDM installation consists of two steps: First, the SDM installation is packed into a JAR file (called the SDM Kit jar). Second, this SDM installation will be installed from the SDM Kit jar to the new location. To create the SDM Kit jar, use this command: sdm createsdmkitjar [excludedcomplist=] [tofile=] [tmpdir=] where

excludedcomplist: Specifies the name of an XML file which defines a set of development components whose SDAs will not be packed into the SDM Kit jar. The excluded components will still be marked as deployed in the new SDM installation.

tofile: Specifies the file name of the SDM Kit jar. If not specified, the command creates a file SDMKit.jar in the current working directory.

tmpdir: Specify a temporal directory where SDM collects the JAR content before packs it. If not specified, the command uses SDM installation directory ().

If not all SDAs could be packed into the SDM Kit jar, the command returns with return code 2 (warning.) For installing the packed SDM Kit jar to a new location, see the documentation of the SDM command autoinstall. The DTD that must be conformed to by the file specified in the parameter excludedcomplist is as follows: Note: createsdmkitjar command can be executed only if SDM server is stopped (see stop/start SDM Server) and it is in standalone mode (see jstartup). It would be better to return SDM in the same state as it was before the execution.

20/24

20 Getting a list of overwritten Support Package Patches

By definition Support Package Patch is collection of all corrections which have been made for a software component in the official correction codeline for a Support Package since shipment of that Support Package. A Support Package Patch is generally shipped as a full Software Component Archive. When you deploy batch of SCAs, it could happen that some of these SCAs will overwrite already deployed Support Package Patches. To get a list of the Support Package patches that would be overwritten, use this command: sdm getoverwrittenfullpatches list= [tofile=] where

list: Name of a text file that contains the names of the SCAs that you want to deploy.

tofile: optional argument. If provided, the information will be written to the specified file. If this parameter is not provided, the information will be written to the standard output.

The DTD corresponding to the result is:

name CDATA #REQUIRED vendor CDATA #REQUIRED version CDATA #REQUIRED>

Note: getoverwrittenfullpatches command can be executed only if SDM server is stopped (see stop/start SDM Server). It would be better to return SDM in the same state as it was before the execution.

21 Creating Software Components archive file(s)

As of SAP Netweaver 04s SP8 SDM does not keep anymore the Software Component archive files under \usr\sap\\\SDM\root\origin_sc directory. The following command give the user the ability to create Software Component archive file: sdm createsca list= | {compname= compvendor=} todir= where

list: Specifies name of a file. This file contains a list of name attributes and vendor attributes of the software components which archive files you want to create. The list must conform to the XML format shown below.

compname, compvendor: Specify the name attribute and vendor attribute of a software component which archive files you want to create. You can create only one software component archive in each call with this variant.

todir: the directory where SDM will put the generated Software Component archive file(s). The exact directory where the archives will be stored is \\\\\

If both the component list and compname plus compvendor are not specified as parameter(s), then all possible Software Component archive files will be created. The DTD that must be conformed to by the file specified in the parameter list is as follows:

21/24

22 Other Commands Four other commands also exist: help, version, listinstalledcomponents and gc: sdm help Displays a list of available SDM commands with a short description of their syntax and meaning. sdm version Displays the version of the SDM software, in the format of the development component of the SDM, for example: Name: tc/SL/SDM/SDM Vendor: sap.com Location: SAP AG Counter: 6.30.20030212181233.0000 API Version: 4 GUI Version: 1.40 Repository Version: 23 Web Server Version: 1.0 Command API Version: 1.0 sdm listinstalledcomponents sdmhome= componentname= [componentlistfile=] where

componentname: Name of a component (DC or SC) whose deployed version you want to display. If you want to display this information for all deployed components, then enter the value all for the componentname parameter.

componentlistfile: Name of a file to which the information on the deployed component(s) is written. If you do not specify this parameter, then the standard output is used.

Note: listinstalledcomponents command can be executed only if SDM server is stopped (see stop/start SDM Server). It would be better to return SDM in the same state as it was before the execution. sdm gc sdmhome= [enabled=true|false] where

enabled: Boolean parameter which enables / disables the garbage collection operations on the SDM repository. The set mode for GC operations is persistent even after engine restart until the next change.

When used without the enabled parameter, the command executes garbage collecting on a SDM Repository if the operation has not been disabled before that. In particular, all information (including physical storage) about SDUs that are not deployed will be removed from the Repository. If the enabled parameter is included, only the GC mode is switched, no actual GC operations are carried out.

22/24

23/24

Note: gc command can be executed only if SDM server is stopped (see stop/start SDM Server). It would be better to return SDM in the same state as it was before the execution. Note 2: The enabled parameter is not replicated with the SDMKIT.jar. By default, the GC is enabled on new installation. sdm filetransferdir sdmhome= [dir=] where

dir: specify the name of the new file transfer directory. It is optional and if it is missed the command will show the currently set directory.

The command changes the directory used by SDM to store deployed archives temporally. It is helpful when there is no enough disk space and you can use other drive for this storage. Note: filetransferdir command can be executed only if SDM server is stopped (see stop/start SDM Server) and it is in standalone mode (see jstartup). It would be better to return SDM in the same state as it was before the execution. sdm repobackups sdmhome= [unlimited=true|false] where

unlimited: Boolean parameter which enables / disables unlimited count of backups of the SDM repository. When the unlimited count is switched off, the SDM repository backups count is automatically reduced to the maximum backup count set in the repository by keeping the most recent files. When switched on, the maximum backup count in the repository is no longer taken into account on creation of new backups.

If executed without parameters, the command shows if the count of the repository backups created is set to unlimited and if not, what the current maximum count is. With the unlimited parameter, the command switches the mode for creating unlimited number of backups. Note: repobackups command can be executed only if SDM server is stopped (see stop/start SDM Server). It would be better to return SDM in the same state as it was before the execution. Note 2: The unlimited parameter is not replicated with the SDMKIT.jar. By default, the repository backups count is limited to 10 on new installation.

23 Return Codes Any of these return codes can apply to any of the commands in the SDM Command Line Interface. The last two numbers in the return code identify the type of the event. The following types exist: Event Type (Last Two Numbers in Return Code)

Meaning

00 Command completed successfully 02 Command completed, but with warnings 04 Command not completed successfully an error occurred 08 Command not completed successfully, since at least one

prerequisite not met 12 Command not completed successfully, since command

syntax incorrect 16 Command not completed successfully critical internal SDM

24/24

error The command deploy can have the following return codes:

RC=0 Deployment successful (at least one archive deployed successfully). Some of the specified archives might not have been deployed since their versions had already been deployed.

RC=4 Deployment not successful for at least one archive.

RC=102 Deployment triggered a warning for at least one archive, all other archives deployed successfully. A warning indicates that the archive is flagged as deployed in the SDM Repository, however, some extra actions are required.

RC=104 All specified archives already deployed in this version. The SDM has not deployed them again.

The command undeploy can have the following return codes:

RC=0 Undeployment successful (at least one SDA undeployed successfully). Some of the specified components might not have been undeployed since they had not been deployed before.

RC=2 Undeployment triggered a warning for at least one SDA, all other SDAs undeployed successfully.

RC=4 Undeployment not successful for at least one SDA.

RC=104 None of the specified components has been undeployed since they had not been deployed before.

The command shutdown can have the following return codes:

RC=0 Request to stop server sent successfully. The server will stop very soon.

RC=4 Request to stop server failed.

RC=104 No connection to server. Server probably not running.

RC=204 Server currently being used (by Java API or remote GUI). Server cannot currently be stopped.

1 IntroductionSyntax of the ParametersNote for Windows Users

Globally Valid Parameters

2 Installing and Updating the SDMInstalling the SDMPrerequisitesInteractive InstallationNon-Interactive InstallationInstalling SDM from a packed SDM Kit jar

Updating the SDMPrerequisitesInteractive UpdateNon-Interactive UpdateIgnoring the version of the currently installed SDMFollow-Up Actions

3 Registering the Secure Store 4 Updating the System State Management with the SDM5 Configuring Target SystemsProcedureDTD for targetconfigfile

6 Configuring Substitution Variables7 Deploying SDAs and SCAs8 Undeploying Development Components9 Integration of SDM in the JStartup Framework10 Starting and Stopping the SDM Server11 Starting the SDM GUI12 Changing the (remote) SDM Password13 Changing the JDK Used by the SDM14 Changing the JVM Options Used by the SDM15 Starting and Stopping the J2EE Engine Automatically with the SDM16 Starting and Stopping the SDM http server17 Checking for running SDM server18 Getting information about the deployed DCs19 Packing an SDM installation into a JAR file20 Getting a list of overwritten Support Package Patches21 Creating Software Components archive file(s)22 Other Commands23 Return Codes