Best Practice Guide
Preparation
General overview of configuration procedure
Creation of objects and configuration of processes
Usage of created processes
Configuration Examples and Detailed Definitions
SAP Landscape Management 3.0 (LaMa) must be installed according to SAP Documentation[1]. To be able to control each SAP system, all instances must be configured[2]. SAP Host Agent is used by LaMa to perform all actions. If non-SAP applications should be controlled, also a SAP Host Agent must be installed [3]on these hosts and configured in SAP LaMa[4]. On each Host Agent, SAP Adaptive Extensions (SAPACEXT Package) [5]must be placed in the ‘exe’ directory as described in SAP Note 1759181. How to configure a system in LaMa is described in SAP Help Documentation and not in scope of this document.
To be able to use all functions mentioned in this document these system requirements are recommended. If possible, newest available versions at SAP Marketplace should be used.
Remarks:
Scope of this document are SAP systems running on HANA and SLES4SAP 12 SP1. Controlling of scripts also possible on other operating systems or any other database.
In mentioned use cases following versions had been used:
Important:
All mentioned scripts had been already used to patch and update systems. This guide describes how to implement his own framework into SAP LaMa. Configuration of script-calls and parameters have to be adapted for each system environment!
With SAP LaMa not only standard mass operations like starting, stopping, takeover handling, etc. are possible, also controlling of custom scripts is configurable. On each client where SAP Host Agent is installed, each script can be started. Start of these scripts can be configured in process chains with different constraints.
One special use case which can be dealt is automation of patching SAP Systems. Normally in bigger landscapes this is handled by running scripts for update the kernel, update the operating system, set profile parameters, and so on.
Next picture shows an overview of a patch process with manual starting of scripts on each host. As recommended, HANA database and SAP instance are installed on different hosts.
Main idea was to handle all these tasks automatically with SAP LaMa, with possibilities to schedule them at night and select an update of whole system by groups, e.g. all development systems.
How to configure a script in LaMa and how to implement a custom process will be described on next pages.
Remark: Update of a HANA system will not be handled here. An automatic update of an HANA database is very complex and consists manual steps. In one of next versions of LaMa this functionality will be shipped by SAP as an integrated process. So it will be possible to configure it also very easily in the custom processes which are used here.
To be able to start and schedule own scripts in LaMa, serveral tasks must be done in sequence. In next chapter each task will be described step by step. A general overview what to do is shown in Figure 2.
On operating system side, first a config file must be created. Here, the link between LaMa and the script is defined. Also parameters can be used to start the script. These <name of action>.conf should exist on each system which have to be controlled. If possible a configuration management system should be used to distribute these files.
On LaMa side, first the script-call must be configured. This is done in the provider definition. Then a single custom operation have to be defined. This one can be used in custom processes to design a sequence of operations.
For custom processes and operations it’s possible to configure constraints in many different manifestations. So each operation can be bind to a special host, a group, a system or a system type. Groups can be eg. all development systems, a several pool, all HANA databases,…
Every custom operation or custom process can be integrated in an operation template. So several systems can be selected for this task(s). So a scheduling for one time or a period is possible.
First step is to create a <action_name>.conf file on operating system level. For easier handling there should be a similar preprocessor for all custom scripts / actions.
Naming example: CUSTOM_NameOfAction.conf
This file must be stored on each host, where the script will be executed. Normally there should be one file per script. Path on each host must be a special folder in the sap Host Agent structure.
Location: /usr/sap/hostctrl/exe/operations.d
In this file, location of the real script is configured. If possible there should be only one location for all scripts on an nfs-share. Configuration file must contain following lines and should look like:
A detailed description of all possible entries can be found at SAP Help Portal:
https://help.sap.com/viewer/e7dead4286c545808b3bd24feee7448c/3.0.7.0/en-US/250dfc5eef4047a38bab466c2...
Example of a .conf file, name in this case 'CUSTOM_KernelInstaller.conf’:
To start own scripts using parameters hand over from LaMa, these have to be defined also in the .conf file.
Syntax of a Parameter:
The Parameter configuration is splittet in two parts, PARAMTER definition itself and a modifier. Possible value for the modifier are: #required, #sapparam, #env, #input, #tolower, #toupper. In our case only ‘#required’ is used. Detailed description of each modifier can be found at SAP Help Portal (link above).
Some possible parameters are:
SAPSYSTEMNAME, PHYSICAL_HOSTNAME,…
To use custom parameters for a script, following syntax must be used: PARAM-<custom-name>
The ‘<custom-name>’ will be configured in next steps in LaMa, so each parameter needed by own scripts can be hand over.
Attention: Naming of parameters is case sensitive!
Example 1: Value with a specific Instance Number should be hand over to script named myownscript.sh. Definition of this Parameter will be done in LaMa in next steps.
Example 2: Script needs hostname as parameter.
All available Parameters are listed in SAP Help Portal:
https://help.sap.com/viewer/e7dead4286c545808b3bd24feee7448c/3.0.7.0/en-US/0148e495174943de8c1c3ee1b...
First step on LaMa side is to create a ‘provider definition’. This configuration step defines the interconnection between script and SAP LaMa respectively the SAP Host Agent.
Now, a Provide Definition is configured. To change the configuration use the edit button. To edit further options, click on the highlighted name.
If the script we are using needs to be started with some parameters, the definition of them in LaMa also must be done.
Important: This parameter definition must be done already in the .conf file, otherwise script call will not work.
After saving this definition, it can be used in next steps to create custom operations and processes.
3. Create Custom Operation
Now, next step is the creation of a custom operation. In next screenshots, the creation of a custom process for the script Kernel Update will be described. Which options and constraints should be used for other use cases and other scripts is described in chapter ‘Configuration Examples’
First start creation of custom operation witch Automation Studio → Custom Operation → Create (Button located at top right).
Description of fields, which must be filled
After creation of the custom operation, next step is to define the constraints. Go to details of the new custom operation (click on the highlighted name, in this case ‘SAP Update Kernel Files’. The go to Constraints and create them as listed in screenshot below.
Meaning of defined constraints:
If a provider definition was created with parameters also these parameters have to be defined in the operation template. The name of the parameter is inherited. Edit the existing parameter and select the needed value. If type String is used, also in this section dynamic values can be used, e.g. $[SAPSYSTEM].
In this case, the parameter –kernel had been selected. Now, this custom operation can start the kernel script with option –kernel on a SAP System instance.
To handle a whole process for patching a system including SAP, Operating System and HANA there are quiet more Custom Operations needed. Next screen shows an overview of these. The only one missing is the actual HANA Update to complete the patch process. Thisis planned to be shipped by SAP in one of the next versions of LaMa.
A detailed description of the configuration of each Custom Operation is listed in chapter ‘Configuration Examples’.
4. Create Custom Process
With all the created Custom Operations, now it is possible to design a Custom Process to patch a whole system automatically, including starting and stopping of each instance. Also, a Custom Process can be configured for each Operation, do be able to run even a kernel update or a profile change for one or more systems, if needed also scheduled at a defined time.
Next, this guide describes exemplary the configuration of one operation and afterwards of the whole patch process. How to configure all other operations is described in chapter ‘Configuration Examples’.
In this case, SAP Kernel will be update including Host Agent and update of security file configuration. To create a new Custom Process use the ‘+’ button at the Custom Process menu entry.
On first screen name and an optional description of the process must be configured. Important in this case is the option Entity Type, this defines the level where the process can be executed.
The main configuration is done in the part Steps. Each step can be added by selecting the already created custom operation. Also on the right side the definition is done, if an operation should run only a specific instance (e.g. central instance) or only on the SAP instances. Next screenshots show the defined process for a kernel installation including starting and stopping.
The table below shows which constraints and operation chains had been used for the several operations.
Detailed configuration of the other processes is described in chapter ‘Configuration Examples’. To be able to perform other actions as well as a separate task, following custom processes had been also created by using the existing Custom operations:
With all created Operations now it’s possible to create a Custom Process for all activities to patch a system completely. Process for kernel update is described above. All configuration tasks are same as described already. In next two screenshots the general sequence is described. Detailed definition of each object can be find in table, which is following.
All these steps can be combined in many other Custom Process with other actions as needed in his own infrastructure.
To start the created processes on one or more systems, now there is an entry in the menu per each system. This is also available for mass operations.
On system level → Operations → Custom Processes
Now the functionality to schedule a custom process for one or more systems is available. Therefore, two tasks have to be performed.
Create Operation Template
Go to Automation Studio à Operation Template → ‘+’.
On step configuration side select the created custom process. On right side, select the systems on which the process should start.
To finalize, save this Operation Template.
On Operation Template view, every created template can be executed directly. Also, there is the possibility to schedule an Operation Template.
On this screen all details for a Scheduling Template can be configured. After saving, this action will be started at the configured date and time.
Important: The right operation template must be selected to avoid unplanned actions or downtimes.
[1] https://help.sap.com/viewer/c337eb50b9084db6a5207afda95efc19/3.0.7.0/en-US
[2] https://help.sap.com/viewer/e7dead4286c545808b3bd24feee7448c/3.0.7.0/en-US/4e01ba23c4e400aae10000000...
[3] https://help.sap.com/viewer/141cbf7f183242b0ad0964a5195b24e7/106/en-US/48c6f9627a004da5e10000000a421...
[4] https://help.sap.com/viewer/e7dead4286c545808b3bd24feee7448c/3.0.7.0/en-US/1626fef0aec740b58232fd9a6...
[5] https://help.sap.com/viewer/e7dead4286c545808b3bd24feee7448c/3.0.7.0/en-US/de3826afa9534da9b79617d40...
Automatic Patch Management for complete SIDs
Quick Acces
Preparation
General overview of configuration procedure
Creation of objects and configuration of processes
Creation of a configuration file
Create Provider Definition
Create Custom Operation
Create Custom Process
Usage of created processes
Create Operation Template
Scheduling
Configuration Examples and Detailed Definitions
HANA Profile Change
SAP Profile Change
SAP Kernel Update (including several components)
Operating System Update
Preparation
General prerequisites
SAP Landscape Management 3.0 (LaMa) must be installed according to SAP Documentation[1]. To be able to control each SAP system, all instances must be configured[2]. SAP Host Agent is used by LaMa to perform all actions. If non-SAP applications should be controlled, also a SAP Host Agent must be installed [3]on these hosts and configured in SAP LaMa[4]. On each Host Agent, SAP Adaptive Extensions (SAPACEXT Package) [5]must be placed in the ‘exe’ directory as described in SAP Note 1759181. How to configure a system in LaMa is described in SAP Help Documentation and not in scope of this document.
Technical prerequisites
To be able to use all functions mentioned in this document these system requirements are recommended. If possible, newest available versions at SAP Marketplace should be used.
| Product | Minimum version |
| SAP NetWeaver (SAP LaMa installation) | 7.50 SPS11 |
| SAP Landscape Management Enterprise Edition 3.0 | SP07 PL0 |
| SAP Host Agent | 7.21 PL36 |
| SAP ACEXT Package | PL41 |
Remarks:
Scope of this document are SAP systems running on HANA and SLES4SAP 12 SP1. Controlling of scripts also possible on other operating systems or any other database.
In mentioned use cases following versions had been used:
- SAP Netweaver systems ABAP and JAVA with kernel versions 749 and 753.
- HANA Database with version 2.023
- SLES 12 SP1 for SAP
- SLES 12 SP2
- Host Agent, ACEXT Packages und SAP LaMa as described in previous table
Important:
All mentioned scripts had been already used to patch and update systems. This guide describes how to implement his own framework into SAP LaMa. Configuration of script-calls and parameters have to be adapted for each system environment!
Use Case - Patchmanagement
With SAP LaMa not only standard mass operations like starting, stopping, takeover handling, etc. are possible, also controlling of custom scripts is configurable. On each client where SAP Host Agent is installed, each script can be started. Start of these scripts can be configured in process chains with different constraints.
One special use case which can be dealt is automation of patching SAP Systems. Normally in bigger landscapes this is handled by running scripts for update the kernel, update the operating system, set profile parameters, and so on.
Next picture shows an overview of a patch process with manual starting of scripts on each host. As recommended, HANA database and SAP instance are installed on different hosts.
Fig. 1 System update - all steps in sequence
Main idea was to handle all these tasks automatically with SAP LaMa, with possibilities to schedule them at night and select an update of whole system by groups, e.g. all development systems.
How to configure a script in LaMa and how to implement a custom process will be described on next pages.
Remark: Update of a HANA system will not be handled here. An automatic update of an HANA database is very complex and consists manual steps. In one of next versions of LaMa this functionality will be shipped by SAP as an integrated process. So it will be possible to configure it also very easily in the custom processes which are used here.
General Overview of Configuration Procedure
To be able to start and schedule own scripts in LaMa, serveral tasks must be done in sequence. In next chapter each task will be described step by step. A general overview what to do is shown in Figure 2.
Fig. 2 Configuration Steps
On operating system side, first a config file must be created. Here, the link between LaMa and the script is defined. Also parameters can be used to start the script. These <name of action>.conf should exist on each system which have to be controlled. If possible a configuration management system should be used to distribute these files.
On LaMa side, first the script-call must be configured. This is done in the provider definition. Then a single custom operation have to be defined. This one can be used in custom processes to design a sequence of operations.
For custom processes and operations it’s possible to configure constraints in many different manifestations. So each operation can be bind to a special host, a group, a system or a system type. Groups can be eg. all development systems, a several pool, all HANA databases,…
Every custom operation or custom process can be integrated in an operation template. So several systems can be selected for this task(s). So a scheduling for one time or a period is possible.
Creation of Objects and Configuration of Processes
1. Creation of a configuration file
First step is to create a <action_name>.conf file on operating system level. For easier handling there should be a similar preprocessor for all custom scripts / actions.
Naming example: CUSTOM_NameOfAction.conf
This file must be stored on each host, where the script will be executed. Normally there should be one file per script. Path on each host must be a special folder in the sap Host Agent structure.
Location: /usr/sap/hostctrl/exe/operations.d
In this file, location of the real script is configured. If possible there should be only one location for all scripts on an nfs-share. Configuration file must contain following lines and should look like:
| Entry | Value | Description |
| Name: | CUSTOM_action_name | For easier access in LaMa it is recommended to use same name as script is named |
| Username: | username with appropriate authorizations | Script will run with configured username |
| Command: | /share/script.sh <PARAMETER> | Path to script. <PARAMETER> is optional, only if script is usable with parameters. Syntax and usage is described below. |
| ResultConverter: | flat | Handling of script output |
| Platform: | Unix / Windows | Platform where script is running on |
A detailed description of all possible entries can be found at SAP Help Portal:
https://help.sap.com/viewer/e7dead4286c545808b3bd24feee7448c/3.0.7.0/en-US/250dfc5eef4047a38bab466c2...
Example of a .conf file, name in this case 'CUSTOM_KernelInstaller.conf’:
Name: CUSTOM_KernelInstaller
Username: <username with appropriate authorizations>
Command: /myglobalshare/kernelinstaller.sh $[PARAM-FUNCTION:#required]
ResultConverter: flat
Platform: Unix
Special Use Case: Parameter Handling
To start own scripts using parameters hand over from LaMa, these have to be defined also in the .conf file.
Syntax of a Parameter:
$[PARAMETER;#modifier]
The Parameter configuration is splittet in two parts, PARAMTER definition itself and a modifier. Possible value for the modifier are: #required, #sapparam, #env, #input, #tolower, #toupper. In our case only ‘#required’ is used. Detailed description of each modifier can be found at SAP Help Portal (link above).
Some possible parameters are:
SAPSYSTEMNAME, PHYSICAL_HOSTNAME,…
To use custom parameters for a script, following syntax must be used: PARAM-<custom-name>
The ‘<custom-name>’ will be configured in next steps in LaMa, so each parameter needed by own scripts can be hand over.
Attention: Naming of parameters is case sensitive!
Example 1: Value with a specific Instance Number should be hand over to script named myownscript.sh. Definition of this Parameter will be done in LaMa in next steps.
Command: /myglobalshare/myownscript.sh $[PARAM-INSTNR:#required]Example 2: Script needs hostname as parameter.
Command: /myglobalshare/myownscript.sh $[PYHSICAL_HOSTNAME:#required]All available Parameters are listed in SAP Help Portal:
https://help.sap.com/viewer/e7dead4286c545808b3bd24feee7448c/3.0.7.0/en-US/0148e495174943de8c1c3ee1b...
2. Create Provider Definition
First step on LaMa side is to create a ‘provider definition’. This configuration step defines the interconnection between script and SAP LaMa respectively the SAP Host Agent.
a.
On left side in SAP LaMaUI5 select Automation Studio → Provider Definitions. Then use button Create → Script Registered with Host Agent on the top right of the screen.
b.
On Create Provider screen, first the registered script has to be selected. So first define a name for the Provider Definition, then select the hostname, where the <action_name>.conf file is located. In this case the Provider Definition for kernel update script will be created.
c.
Select hostname where script is located. If necessary use the filter option for an easier way of searching.
d.
Select button Retrieve Scripts to upload all available scripts. Then choose the file name of the already created .conf file
e.
Select on which entities this provider should be available. In this case for further uses Instance and Host must be selected. Hint: This can be changed afterwards by editing the provider definition. To finish the action, select Create Provider.
Now, a Provide Definition is configured. To change the configuration use the edit button. To edit further options, click on the highlighted name.
Special Use Case: Parameter Handling
If the script we are using needs to be started with some parameters, the definition of them in LaMa also must be done.
Important: This parameter definition must be done already in the .conf file, otherwise script call will not work.
a.
Open the options of the provider definition. Select Name of Provider Definition → Parameters → Add Parameter
b.
In this screen, all parameters should be added, which are accepted by the own script. The Name of the parameter definition must be the same as defined in the .conf file. In this case it’s named FUNCTION, the script call in the .conf file should look like: Command: /nfs/sles_data/support_tools/kernelinst.sh $[PARAM-FUNCTION:#required].
After saving this definition, it can be used in next steps to create custom operations and processes.
3. Create Custom Operation
Now, next step is the creation of a custom operation. In next screenshots, the creation of a custom process for the script Kernel Update will be described. Which options and constraints should be used for other use cases and other scripts is described in chapter ‘Configuration Examples’
First start creation of custom operation witch Automation Studio → Custom Operation → Create (Button located at top right).
Description of fields, which must be filled
- Name: Define a name
- Provider Definition: Choose the already created provider definition (script which will be started)
- Entity Type: Define if operation can run on an instance or on a host (Remark: On one host there can be many instances. In next steps it can be defined where the script can start, e.g. on a specific instance like ASCS or generally on a SAP instance)
- Button Group: Type or choose a name, where you can find the operations in menus later on.
After creation of the custom operation, next step is to define the constraints. Go to details of the new custom operation (click on the highlighted name, in this case ‘SAP Update Kernel Files’. The go to Constraints and create them as listed in screenshot below.
Meaning of defined constraints:
Instance status (Dynamic) = Not Running
Operation only starts, if instance is stopped
Host status (assigned host) (Dynamic) <> Unreachable
Only if host is reachable, operation can start (and also can be selected)
Important configuration: Instance class (Static) = Instance
Operation only selectable on a SAP instance (not a HANA instance). For this case important, because kernel should only be updated on a SAP instance.
Special Use Case: Parameter Handling
If a provider definition was created with parameters also these parameters have to be defined in the operation template. The name of the parameter is inherited. Edit the existing parameter and select the needed value. If type String is used, also in this section dynamic values can be used, e.g. $[SAPSYSTEM].
In this case, the parameter –kernel had been selected. Now, this custom operation can start the kernel script with option –kernel on a SAP System instance.
To handle a whole process for patching a system including SAP, Operating System and HANA there are quiet more Custom Operations needed. Next screen shows an overview of these. The only one missing is the actual HANA Update to complete the patch process. Thisis planned to be shipped by SAP in one of the next versions of LaMa.
A detailed description of the configuration of each Custom Operation is listed in chapter ‘Configuration Examples’.
4. Create Custom Process
With all the created Custom Operations, now it is possible to design a Custom Process to patch a whole system automatically, including starting and stopping of each instance. Also, a Custom Process can be configured for each Operation, do be able to run even a kernel update or a profile change for one or more systems, if needed also scheduled at a defined time.
Next, this guide describes exemplary the configuration of one operation and afterwards of the whole patch process. How to configure all other operations is described in chapter ‘Configuration Examples’.
Custom Process: SAP Kernel Update
In this case, SAP Kernel will be update including Host Agent and update of security file configuration. To create a new Custom Process use the ‘+’ button at the Custom Process menu entry.
On first screen name and an optional description of the process must be configured. Important in this case is the option Entity Type, this defines the level where the process can be executed.
The main configuration is done in the part Steps. Each step can be added by selecting the already created custom operation. Also on the right side the definition is done, if an operation should run only a specific instance (e.g. central instance) or only on the SAP instances. Next screenshots show the defined process for a kernel installation including starting and stopping.
The table below shows which constraints and operation chains had been used for the several operations.
| Operation | Defined Constraints / Relation Chains | Remark |
| Stop | Operation Constraint Instance class (Static) = Instance | Stop is only performed on SAP instances, not on the database |
| SAP Update Kernel Files | Operation Constraint Instance class (Static) = InstanceRelation ChainGlobal InstanceTarget (Instance) | Kernel Update Script will only be started on the central instance. |
| SAP Update Security Files | no changes / nothing selected | |
| Start | no changes / nothing selected | |
| SAP Update Host Agent | no changes / nothing selected |
Detailed configuration of the other processes is described in chapter ‘Configuration Examples’. To be able to perform other actions as well as a separate task, following custom processes had been also created by using the existing Custom operations:
- HANA Profile Change
- SAP Profile Change
- Update Operating System
Custom Process: Update System (whole update process for a system)
With all created Operations now it’s possible to create a Custom Process for all activities to patch a system completely. Process for kernel update is described above. All configuration tasks are same as described already. In next two screenshots the general sequence is described. Detailed definition of each object can be find in table, which is following.
| Operation | Defined Constraints / Relation Chains | Remark |
| Stop | no changes / nothing selected | Stop is performed on all SAP and database instances. |
| SAP Profile Change | Operation Constraint Instance class (Static) = Instance | Script will be started only on SAP instances |
| HANA Profile Change | Operation Constraint Database Type (Static) = SAP HANA | Script will be started only on HANA instances |
| SAP Profile Change Host Agent | no changes / nothing selected | |
| SAP Update Kernel Files | Operation Constraint Instance class (Static) = InstanceRelation ChainGlobal InstanceTarget (Instance) | Kernel Update Script will only be started on the central instance or PAS. |
| SAP Update Security Files | no changes / nothing selected | |
| SAP Update Host Agent | no changes / nothing selected | |
| Update OS | no changes / nothing selected | Script for updating the operation system will be started on one central configuration host. This is defined in the configuration of the Custom Operation |
| Start | no changes / nothing selected | All instances will be started |
All these steps can be combined in many other Custom Process with other actions as needed in his own infrastructure.
Usage of created processes
To start the created processes on one or more systems, now there is an entry in the menu per each system. This is also available for mass operations.
On system level → Operations → Custom Processes
Now the functionality to schedule a custom process for one or more systems is available. Therefore, two tasks have to be performed.
Create Operation Template
Go to Automation Studio à Operation Template → ‘+’.
On step configuration side select the created custom process. On right side, select the systems on which the process should start.
To finalize, save this Operation Template.
Scheduling
On Operation Template view, every created template can be executed directly. Also, there is the possibility to schedule an Operation Template.
On this screen all details for a Scheduling Template can be configured. After saving, this action will be started at the configured date and time.
Important: The right operation template must be selected to avoid unplanned actions or downtimes.
Configuration Examples and Detailed Definitions
HANA Profile Change
| Provider Definition - HANA Profile Change Name in .conf file: CUSTOM_ModifyHANAProfile Command in .conf file: /myshare/modifyhanaprofile.sh | ||
| Configuration | Options | Script - Description |
| Name HANA Profile Change | nothing configured / no changes | Script must be started on HANA instances without any parameters. Definition how and where the HANA values have to be changed are defined in the script. |
Registered Script CUSTOM_ModifyHANAProfile | ||
Operation Uses Instance | ||
| Custom Operations based on HANA Profile Change | |||
| Name | Configuration | Options | Description |
| HANA Profile Change | Entity Type Instance | Operation Constraints Database Type (Static) = SAP HANA | Operation is only visible on HANA database instances. |
Required Permission Normal | |||
| Button Group Patch Automation | |||
| Other selected Entries Valid for Mass Operations Locks Instance or Host Synchronous Execution | |||
| Definition in Custom Process | ||
| Name | Options | Description |
| HANA Profile Change | Operation Constraints Database Type (Static) = SAP HANA | During the process operation only on entities with Database Type = SAP HANA will be executed. |
SAP Profile Change
| Provider Definition - SAP Profile Change Name in .conf file: CUSTOM_ModifySAPProfile Command in .conf file: /myshare/modifysapprofile.sh -i $[PARAM-INSTNR:#required] | ||
| Configuration | Options | Script - Description |
| Name SAP Profile Change | Parameters Name/Label: INSTNR Type: Hard-Coded String Mandatory: true | To execute the script for editing and changing SAP profiles, the instance number must be given as a parameter following the identificator ‘-i’. This must be defined in the parameters section of the provider definition. Which parameters have to be changed in which is handled by the script itself. |
Registered Script CUSTOM_ModifySAPProfile | ||
Operation Uses Instance Host | ||
| Custom Operations based on SAP Profile Change | |||
| Name | Configuration | Options | Description |
| SAP Profile Change | Entity Type Instance | Parameters Name/Label: INSTNR Type: String Value: $[SAPSYSTEM] Mandatory: trueConstraints Instance status (Dynamic) <> Initial Host status (assigned host) (Dynamic) <> Unreachable Instance class (Static) = Instance | The LaMa standard parameter $[SAPSYSTEM] includes the instance number of the actual started operation, e.g. if operation is started on ASCS01, script will be called with parameter ‘-i 01’. |
| Required Permission Normal | |||
| Button Group Patch Automation | |||
| Other selected Entries Valid for Mass Operations Locks Instance or Host Synchronous Execution | |||
| SAP Profile Change Hostagent | Entity Type Host | Parameters Name/Label: INSTNR Type: String Value: 99 Mandatory: trueConstraints Host status (assigned host) (Dynamic) <> Unreachable | SAP Host Agent is installed on each system with standard port 99. For this case update for it is started every time with ‘-i 99’. |
| Required Permission Normal | |||
| Button Group Patch Automation | |||
| Other selected Entries Valid for Mass Operations Locks Instance or Host Synchronous Execution | |||
| Definition in Custom Process | ||
| Name | Options | Description |
| SAP Profile Change | Operation Constraints Instance class (Static) = Instance | Operation will be started only on SAP instances, as defined with parameter instance number. |
| SAP Profile Change Hostagent | nothing configured /no changes | Operation will be started on each host, as defined with parameter 99 for SAP Host Agent. |
SAP Kernel Update (including several components)
| Provider Definition - SAP Kernel Update Name in .conf file: CUSTOM_KernelInstaller Command in .conf file: /myshare/kernelinstaller.sh $[PARAM-FUNCTION:#required] | ||
| Configuration | Options | Description |
| Name SAP Kernel Update | Parameters Name/Label: FUNCTION Type: Hard-Coded String Array Value: --kernel; --hostagent; --security | Script for kernel update is much more complex than the other ones. Start of script is possible with following parameters: --kernel: Update of kernel files --hostagent: Update of SAP Host Agent ACEXT package --security: adapt all ACL files according to templates |
| Registered Script CUSTOM_Kernelinstaller | ||
| Operation Uses Instance Host | ||
| Custom Operations based on SAP Kernel Update | |||
| Name | Configuration | Options | Description |
| SAP Update Kernel Files | Entity Type Instance | Parameters Name/Label: FUNCTION Type: String Value: --kernelConstraints Instance status (Dynamic) = Not running Host status (assigned host) (Dynamic) <> Unreachable Instance class (Static) = Instance | Script will be executed with parameter –kernel. It is only possible to start the script, if instance is down, host is reachable and the entity type is a SAP instance |
| Required Permission Normal | |||
| Button Group Patch Automation | |||
| Other selected Entries Valid for Mass Operations Locks Instance or Host Synchronous Execution | |||
| SAP Update Hostagent | Entity Type Host | Parameters Name/Label: FUNCTION Type: String Value: --hostagentConstraints Host status (assigned host) (Dynamic) <> Unreachable | Update of SAP Host Agent must be done on each host, so the only constraint is configured to start the script only on hosts which are reachable. |
| Required Permission Normal | |||
| Button Group Patch Automation | |||
| Other selected Entries Valid for Mass Operations Locks Instance or Host Synchronous Execution | |||
| SAP Update Security Files | Entity Type Host | Parameters Name/Label: FUNCTION Type: String Value: --securityConstraints Host status (assigned host) (Dynamic) <> Unreachable | Security files should also be adapted on each host, because SAP services and host agent itself also is configured with ACL files. Script handles itself, whose files have to be adapted according to templates. |
| Required Permission Normal | |||
| Button Group Patch Automation | |||
| Other selected Entries Valid for Mass Operations Locks Instance or Host Synchronous Execution | |||
| Definition in Custom Process | ||
| Name | Options | Description |
| SAP Update Kernel Files | Operation Constraints Instance class (Static) = Instance | Kernel file update must only run on the central instance or the PAS. This is configured in the relations chain options. |
| Relations Chain Global Instance, Target (Instance) | ||
| SAP Update Hostagent | nothing configured/ no changes | Can run on each host. No further configurations needed. |
| SAP Update Security Files | nothing configured/ no changes | Can run on each host. No further configurations needed. |
Operating System Update
| Provider Definition – OS Update Name in .conf file: CUSTOM_HostUpdate Command in .conf file: /myshare/hostupdate.sh -hn $[PHYSICAL_HOSTNAME:#required] | ||
| Configuration | Options | Description |
| Name OS Update | nothing configured/ no changes | To update an operating system of a host in this infrastructure, it’s a requirement to start the update on one central host with the hostname of the target system as a parameter. The option to start the script every time on this special host is done with the value Central hostname during the configuration of the provider definition. The embedded parameter PHYSICAL_HOSTNAME includes the hostname, which belongs to the system where the update is started.Example: If in LaMa on system level the OS update is started, the script will start on central update host for each hostname which belongs to the SAP system. |
| Registered Script CUSTOM_HostUpdate | ||
| Execute on Central Host Only true | ||
| Central Execution Type Host | ||
| Central Hostname <hostname of central host for updates> | ||
| Operation Uses Host | ||
| Custom Operations based on OS Update | |||
| Name | Configuration | Options | Description |
| Update Operating System | Entity Type Host | nothing configured /no changes | All necessary configurations are done in the provider definition. |
| Required Permission Normal | |||
| Button Group Patch Automation | |||
| Other selected Entries Valid for Mass Operations Locks Instance or Host Synchronous Execution | |||
| Definition in Custom Process | ||
| Name | Options | Description |
| Update Operating System | nothing configured /no changes | No changes needed here at this point. |
[1] https://help.sap.com/viewer/c337eb50b9084db6a5207afda95efc19/3.0.7.0/en-US
[2] https://help.sap.com/viewer/e7dead4286c545808b3bd24feee7448c/3.0.7.0/en-US/4e01ba23c4e400aae10000000...
[3] https://help.sap.com/viewer/141cbf7f183242b0ad0964a5195b24e7/106/en-US/48c6f9627a004da5e10000000a421...
[4] https://help.sap.com/viewer/e7dead4286c545808b3bd24feee7448c/3.0.7.0/en-US/1626fef0aec740b58232fd9a6...
[5] https://help.sap.com/viewer/e7dead4286c545808b3bd24feee7448c/3.0.7.0/en-US/de3826afa9534da9b79617d40...
- SAP Managed Tags:
4 Comments
