Skip to Content
Technical Articles

Transfer parameters of a custom operation or custom hook in SAP Landscape Management (LaMa)

This blog intends to demonstrate with examples (using scripts registered with host agent) on how to transfer parameters of a custom operation or custom hook to a subsequent custom operation or custom hook. In particular this is in reference to SAP Note 2601394.

Parameters can be transferred to direct successors (custom operations/hooks that are executed immediately afterwards). This is done by using the keyword “ResultConverter” with entry of “hook” in the script registered with host agent. This means that special handling of the output of your script will be done. If the output had a line starting with [RESULT] then LaMa will set a transfer parameter per the following format.

Parameter [RESULT]:Param:<PARAMETER_NAME>=<PARAMETER_VALUE>
Secure parameter [RESULT]:ParamSecure:<PARAMETER_NAME>=<PARAMETER_VALUE>

All direct custom successors can access this parameter with the TRANS- prefix.

TRANS-<PARAMETER_NAME>

If your need is not for transfer of parameters to direct successors but rather to be used by any subsequent custom operation/hook, then this can be done by updating or creating custom properties in the script.

Custom property [RESULT]:Property:<Property-Name>=<Property-Value>
Secure custom property [RESULT]:PropertySecure:<Property-Name>=<Property-Value>
System wide custom property [RESULT]:SystemProperty:<Property-Name>=<Property-Value>
Secure system wide custom property [RESULT]:SystemPropertySecure:<Property-Name>=<Property-Value>

In this scenario you access the custom property as below.

PROP-<PROPERTY_NAME>

You have to allow the update of custom properties when creating the provider definition in SAP Landscape Management (covered in example 2).

Test Environment:

  • SAP Landscape Management Enterprise Edition 3.0 SP13 (on Linux with SAP ASE database)
  • Managed host: SuSE Linux Enterprise 12 SP2

Example 1: Parameter transfer to direct successor

In this example we will have 2 very simple custom operations.

  • Custom operation 1 executes a script to determine number of CPUs on a host (entity on which you execute the operation) and assigns this to a parameter with name of HOST_CPUCOUNT.

 

  • Custom operation 2 executes a script that takes the value of HOST_CPUCOUNT from above operation and creates a temporary file /tmp/transfer_parameter with an entry of “HOST_CPUCOUNT was evaluated as xx”

Above will run back to back.

Create the configuration files in directory /usr/sap/hostctrl/exe/operations.d on the managed host that is going to run the custom operation.

Create file CO_trans_param1.conf

Username: root
Name:CO_trans_param1
Description: Determine CPU count and assign to transfer parameter HOST_CPUCOUNT
Command: /usr/sap/scripts/cpu_count_trans.sh
ResultConverter: hook
Platform: Unix

Important thing to note here is the “ResultConverter” keyword and setting it to “hook”.

 

Set permissions:

chown root:root <.conf file>
chmod 755 <.conf file>

 

Create the bash script in a directory of your choice (in my case it was in /usr/sap/scripts):

Script name: “cpu_count_trans.sh”.

#!/bin/bash
# First we determine the cpu count and assign to internal variable cpu_count
cpu_count=`grep processor /proc/cpuinfo|wc -l`
# Now we can output something in a format that LaMa will process
# Assign the value to the transfer parameter HOST_CPUCOUNT
echo "[RESULT]:Param:HOST_CPUCOUNT=$cpu_count"

In the above script the key thing to note is the last line which produces an output in the correct syntax for the parameter to be transferred. This will trigger the handling by LaMa.

 

Set permissions

chown root:root <file>

chmod 755 <file>

 

Now let’s create the custom operation that will use the transferred parameter.

Create file CO_trans_param2.conf

Username: root
Name:CO_trans_param2
Description: Access parameter transferred by previous operation
Command: /usr/sap/scripts/cpu_count_trans_file.sh $[TRANS-HOST_CPUCOUNT]
ResultConverter: flat
Platform: Unix

 

Important line here is where the command is executed. Note the use of TRANS-HOST_CPUCOUNT

We no longer need any special handling of output so we set ResultConverter in this case to flat.

Set permissions:

chown root:root <.conf file>
chmod 755 <.conf file>

 

Create the bash script in a directory of your choice (in my case it was in /usr/sap/scripts):

Script name: “cpu_count_trans_file.sh”.

#!/bin/bash
# First we retreive the value of the transfer parameter
cpu_count=$1
# Now we create the file
echo "HOST_CPUCOUNT was evaluated as $cpu_count" > /tmp/transfer_parameter

The value of TRANS-HOST_CPUCOUNT was passed as an argument to the above script so we reference it as $1

 

Set permissions

chown root:root <file>

chmod 755 <file>

 

First we create the provider definitions:

Automation Studio -> Provider Definition -> Create

No special settings are needed for the transfer.

Repeat for second provider definition – CO_trans_param2 with identical settings.

We create the custom operations:

Automation Studio -> Custom Operation -> Create

Repeat for the second custom operation “CO_trans_param2” (using the corresponding provider definition) with same settings.

Now to test the above custom operations running back to back, we create an Operation Template.

Automation Studio -> Operation Template -> Create

 

 

Execute the above Operation Template and you should see the file /tmp/transfer_parameter created demonstrating that the correct value transferred from CO_trans_param1 to CO_trans_param2 custom operation.

Verify:

nm-sles-12-1:~ # cat /tmp/transfer_parameter
HOST_CPUCOUNT was evaluated as 4

 

Example 2: Custom Property Set and Retrieve

In this example we will create a variation of example 1 and this time assign the cpu count value to a custom property.

  • Custom operation 1 — cpu count is determined and assigned to a custom property

 

  • Custom operation 2 — use the custom property set in custoom operation 1 and create a temporary file “/tmp/transfer_cust_property” with entry of “CUST_CPUCOUNT custom property value was retrieved as xx”

Create file CO_trans_cust_prop1.conf:

Username: root
Name:CO_trans_cust_prop1
Description: Determine CPU count and assign to custom property CUST_CPUCOUNT
Command: /usr/sap/scripts/cpu_count_trans_cust_prop1.sh
ResultConverter: hook
Platform: Unix

Important thing to note here is the “ResultConverter” keyword and setting it to “hook”

 

Set permissions:

chown root:root <.conf file>
chmod 755 <.conf file>

 

Create script: “cpu_count_trans_cust_prop1.sh”.

#!/bin/bash
# First we determine the cpu count and assign to internal variable cpu_count
cpu_count=`grep processor /proc/cpuinfo|wc -l`
# Now we can output something in a format that LaMa will process
# Assign the value to custom property CUST_CPUCOUNT
echo "[RESULT]:Property:CUST_CPUCOUNT=$cpu_count"

In the above script the key thing to note is the last line which produces an output in the correct syntax for the custom property to be set. This will trigger the handling by LaMa.

 

Set permissions

chown root:root <file>

chmod 755 <file>

 

Now let’s create the custom operation that will use the custom property.

Create file CO_trans_cust_prop2.conf

Username: root
Name:CO_trans_cust_prop2
Description: Access custom property CUST_CPUCOUNT set by previous operation
Command:/usr/sap/scripts/cpu_count_trans_cust_prop_file.sh $[PROP-CUST_CPUCOUNT]
ResultConverter: flat
Platform: Unix

 

Important line here is where the command is executed. Note the use of PROP-CUST_CPUCOUNT

We no longer need any special handling of output so we set ResultConverter in this case to flat.

 

Set permissions:

chown root:root <.conf file>
chmod 755 <.conf file>

 

Create script: “cpu_count_trans_cust_prop_file.sh”.

#!/bin/bash
# First we retreive the value of the custom property that was passed as argument
cpu_count=$1
# Now we create the file
echo "CUST_CPUCOUNT custom property value was retrieved as $cpu_count" > /tmp/transfer_cust_property

 

The value of PROP-CUST_CPUCOUNT was passed as an argument to the above script so we reference it as $1

 

Set permissions

chown root:root <file>

chmod 755 <file>

 

First we create the first provider definition:

Note the check mark for “Update Custom Properties”

Repeat for the second provider definition – CO_cust_prop2 (using CO_trans_cust_prop2.conf) but do not check mark “Update Custom Properties” as we are not updating or setting new properties.

 

We create the custom operations. Create the first one:

 

Create the second custom operation “CO_trans_cust_prop2” with similar settings as above.

Now we can test the 2 custom operations but this time we do not need to create an Operation Template. This is because custom properties are persistent and can be retrieved at any time.

Execute custom operation CO_cust_prop1 and you will see a pop-up letting you know that the custom property has been set.

 

 

Now execute custom operation CO_cust_prop2 which will use the previously set custom property and create the file using the value.

Verify:

nm-sles-12-1:~ # cat /tmp/transfer_cust_property
CUST_CPUCOUNT custom property value was retrieved as 4

 

References:

  1. https://blogs.sap.com/2020/02/28/sap-landscape-management-lama-automation-studio/
  2. SAP Landscape Management Enterprise 3.0 User Guide
  3. SAP Note 2601394
9 Comments
You must be Logged on to comment or reply to a post.
  • Hi Naeem Maqsud,

    Thanks for sharing. It is very helpful information. I have a question here. How do I transfer the output value. For example. The first command is to find out the current kernel version, the first command output like kernel make variant 722_EXT_REL

    So, how do I use the output value (which trigger from the first command) pass over to second command. ? So, the second command will be look like this \\sapserver\SAPLaMa\Kernel\Windows\722_EXT_REL D:\Temp

    Name: LaMa_Kernel_Version_Windows
    Description: To determine the current kernel version and copy the new kernel release
    Command: "D:\usr\sap\$[SAPSYSTEMNAME:#required]\SYS\exe\uc\NTAMD64\disp+work.exe -version | findstr variant"
    Command: xcopy /E /I /Y \\sapserver\SAPLaMa\Kernel\Windows\$[PARAM-KERNEL_RELEASE:#required] D:\Temp
    Platform: Windows
    ResultConverter: flat
    Platform: Windows

    Appreciate for your help. Hope to hear you soon

     

    • Hi Steve,

      I think that example 1 above should cover your scenario. Create 2 custom processes, with first one using ResultConverter: hook and generating output as [RESULT]:Param:KERNEL_RELEASE=<value>. How you ensure to get the right output is up to you. Either do it with Command: and CLI or Command: and a script file (e.g. BAT file or Powershell). The second custom process will have ResultConverter: flat and will access the output from first one as TRANS-KERNEL_RELEASE. Then create an operation template to run custom process 1 and custom process 2 back to back. This will ensure variable transfers from 1st to 2nd custom process.

      Example 2 should also work in your scenario where you create a custom property with the kernel_release info and this will be persistent. Then you can access the value from another custom process at any time.

      I hope this helps.

      Cheers,

      Naeem

  • Hi Naeem Maqsud,

    Appreciate and thanks for your input and advise. I'm not so familiar with the .BAT file or powershell scripting. Would you please advise me?

    Here is the 2 custom processes created

    First scenario, is to obtain the kernel release information and store the output which needs to pass over to Second scenario

    Name: LaMa_Kernel_Version_Windows
    Command: "D:\usr\sap\$[SAPSYSTEMNAME:#required]\SYS\exe\uc\NTAMD64\disp+work.exe -version | findstr variant"
    ResultConverter: hook
    Platform: Windows

    I tried to run this script, the output value is "kernel make variant 722_EXT_REL"

    Appreciate if you could advise me, how to store this value (722_EXT_REL) into [RESULT]:Param:KERNEL_RELEASE.

    For the second scenario, it will be getting the output value from first scenario, the value should be 722_EXT_REL.

    Name: LaMa_Kernel_Copy
    _Windows
    Command: xcopy /E /I /Y \\ust2ta01\SAPLaMa\Kernel\Windows\$[TRANS-KERNEL_RELEASE:#required] D:\Temp
    ResultConverter: flat
    Platform: Windows

    So, this second scenario, will copy the .SAR files from \\ust2ta01\SAPLaMa\Kernel\Windows\722_EXT_REL to D:\Temp folder in the destination host.

    If the first scenario able to capture the kernel release information and pass over to second scenario, then, i can automate the kernel update process.

    Thanks in advanced for your help. Appreciate that.

    Regards,
    Steve Chai

    • Hello Steve,

      I'm more of a unix/linux guy than windows ;-). However, give this one liner a try:

      Command: powershell -command "D:\usr\sap\$[SAPSYSTEMNAME:#required]\SYS\exe\uc\NTAMD64\disp+work.exe -version | findstr variant | %{ $kernel=$_.Split(' ')[3]; }; Write-Host [RESULT]:Param:KERNEL_RELEASE=$kernel"

      The above should produce an output of "[RESULT]:Param:KERNEL_RELEASE=722_EXT_REL" and this will be interpreted by LaMa and retrievable with $[TRANS-KERNEL_RELEASE] in the second custom process.

      Try the command outside of LaMa first to make sure you get the right output.

      Cheers

  • Hi Naeem Maqsud,

    Really appreciate for your input and advise. Thanks so much.

    I replaced the parameter $[SAPSYSTEMNAME:#required] = SKC, updated the command as below.
    powershell -command “D:\usr\sap\SKC\SYS\exe\uc\NTAMD64\disp+work.exe -version | findstr variant | %{ $kernel=$_.Split(‘ ‘)[3]; }; Write-Host [RESULT]:Param:KERNEL_RELEASE=$kernel”

    Trying to run the command directly in the server via Windows Powershell

    Here is the output.
    PS C:\Users\w45907s> powershell -command “D:\usr\sap\SKC\SYS\exe\uc\NTAMD64\disp+work.exe -version | findstr variant | % { $kernel=$_.Split(‘ ‘)[3]; }; Write-Host [RESULT]:Param:KERNEL_RELEASE=$kernel”
    D:\usr\sap\SKC\SYS\exe\uc\NTAMD64\disp+work.exe=>sapparam(1c): No Profile used.
    D:\usr\sap\SKC\SYS\exe\uc\NTAMD64\disp+work.exe=>sapparam: SAPSYSTEMNAME neither in Profile nor in Commandline
    =.Split : The term '=.Split' is not recognized as the name of a cmdlet, function, script file, or operable program.
    Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
    At line:1 char:81
    + ... NTAMD64\disp+work.exe -version | findstr variant | %{ =.Split(‘ ‘)[3] ...
    + ~~~~~~~
    + CategoryInfo : ObjectNotFound: (=.Split:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

    My fault here, i miss this information in previous message.
    When I execute this command: disp+work.exe -version | findstr variant

    Here is the output, the third line, showing the kernel make variant: 722_EXT_REL

    D:\usr\sap\SKC\SYS\exe\uc\NTAMD64>disp+work.exe -version | findstr variant
    disp+work.exe=>sapparam(1c): No Profile used.
    disp+work.exe=>sapparam: SAPSYSTEMNAME neither in Profile nor in Commandline
    kernel make variant 722_EXT_REL

    Regards,
    Steve Chai

    • Looks like you ran the command inside the Powershell judging from the "PS" in the prompt. "powershell -command" is normally applicable from the Windows (or MS-DOS) command prompt. If you want to execute directly from Powershell, then just omit "powershell -command".

      BTW: What you are trying to do can be achieved in a simpler and more efficient way.

      1. If you have LaMa Enterprise Edition SP17 then kernel update feature is built-in. Refer to this link
      2. If you need to stick with custom process, then you can do it more efficiently by moving all logic into a single powershell script and then there is no need to handle parameter transfers in automation studio. One custom process will do it.

       

      • Hi Naeem Maqsud,

        Much appreciate and thanks for your guidance. With your advise and help, I managed to setup the custom process for kernel update process. It work fine on both platform (Linux and Windows).

        Regarding the comment :

        If you have LaMa Enterprise Edition SP17 then kernel update feature is built-in. Refer to this link

        -> Yes, we had upgraded our LaMa application to SP17 version, also review the built in custom process (Kernel and Host Agent). I managed to use the built in process for Host agent update only, but for the built in kernel update process, it require to DB instance settings under Managed and operational mode. However, there is no host agent/SMD agent installed on DB server. Hence, I tried to enable the Managed and Operational settings for DB instance, from the Dashboard, it show RED status.

        If you need to stick with custom process, then you can do it more efficiently by moving all logic into a single powershell script and then there is no need to handle parameter transfers in automation studio. One custom process will do it.

        -> Yes, totally agree with you

  • Hello Naeem,

    I would like to use a script similar to example 2 for setting custom properties to instances.

    The properties should be set dynamically so I thought by using a custom validation the properties could be set without manually triggering the setting process.

    When trying this out LaMa logs that a new property was found:

    Got new property TEST_PROPERTY=Test
    
    Set a custom value to custom property TEST_PROPERTY hook successfully executed

     

    But when looking at the instance itself the propery wasn’t set.

    Is this something that doesn’t work or am I missing something?

     

    Greetings,

    Teresa