Skip to Content

How to use SAP Landscape Management custom validations

Overview

In this blog post I will describe how to use custom validations in SAP Landscape Management to check if a certain SAP profile parameter is set to a given value over all SAP systems in your landscape. The whole process is documented in the SAP Landscape Management manual in chapter Configuring Custom Operations, but I want to give you a real-life example how you can leverage this feature in your SAP Landscape.

Example use-case

Let’s say you need to make sure that the profile parameter login/no_automatic_user_sapstar is enabled (= 1) for each SAP instance and you have hundreds of them in your SAP landscape. With a short script and a few configuration steps in SAP LaMa you can create a custom validation which checks this parameter on all of your systems on a regular base, so that you can take the necessary actions to disable it, if it should be enabled.

The steps to implement the validation are:

  1. Create the validation script which checks the profile parameter
  2. Introduce the script to the SAP host agent for each system you want to validate
  3. Introduce the script to SAP LaMa by creating a “Provider Implementation Definition”
  4. Create a LaMa “Custom Operation” and mark it as “Validation Operation”

Implementation

Create validation script

Let’s start at the beginning with creating the validation script which will be executed by LaMa. We create a small bash script which takes the path to the SAP instance profile as parameter. This parameter will be passed in by LaMa during the execution. The script basically calls the sappfpar command to check the current setting for the parameter login/no_automatic_user_sapstar:

#!/bin/bash

echo "=== Custom validation $0 called with parameters:"
echo "$*"

while getopts "p:" opt; do
 case $opt in
 p)
  PROFILE=$OPTARG
  ;;
 esac
done

if [[ ! -f $PROFILE ]]; then
 echo "[WARNING]:WARNING: Instance profile $PROFILE not found!"
 exit 0
fi

no_automatic_user_sapstar=$(sappfpar pf=$PROFILE login/no_automatic_user_sapstar)

if [[ $no_automatic_user_sapstar == 1 ]]; then
 echo "OK: login/no_automatic_user_sapstar is enabled."
else
 echo "[WARNING]:Possible security issue: Profile parameter login/no_automatic_user_sapstar is disabled!"
fi

In my environment I store such scripts in the /usr/local/bin/ directory. This directory is replicated to all SAP hosts in my landscape, so that I have it available on every SAP system. The script can now be executed manually by calling it as <sid>adm user:

/usr/local/bin/LamaValAutoSapstar.bash -p <PATH TO INSTANCE PROFILE>

But we don’t want to execute it manually on all systems. LaMa is supposed to do it for all of our systems. So the next step is to make it known to the SAP host agent.

Introduce validation script to SAP host agent

The configuration files for the scripts to be executed are stored in the operations.d subdirectory of the SAP host agent. On my systems I stored the config file as /usr/sap/hostctrl/exe/operations.d/LamaValAutoSapstar.conf. The configuration for our new validation script needs to look like that:

Name: LamaValAutoSapstar
Command: /usr/local/bin/LamaValAutoSapstar.bash -p $[SAPSTARTPROFILE:#required]
Description: LAMA validation for login/no_automatic_user_sapstar
Username: $[SAPSYSTEMNAME:#tolower]adm
ResultConverter: hook
Platform: UNIX

Name:

With the Name: keyword we just specify a name for our LaMa operation

Command:

Here we specify how the script needs to be called. We just put the complete path to our script in here and provide all necessary parameters. As -p parameter we need the path to the instance profile. This parameter is passed in by LaMa as $[SAPSTARTPROFILE]. #required marks this parameter as required for execution of the operation.

Description:

As the name says, this is just some descriptive sentence for this operation.

Username:

Here we specify the username under which the script is executed. As the script calls sappfpar, it needs to be run as <sid>adm user. With the given setting, LaMa passes in the SAP system SID as parameter $[SAPSYSTEMNAME]. With the modifier #tolower, the SID is translated to lowercase and afterwards the string “adm” is appended. That should give us the <sid>adm username.

ResultConverter:

ResultConverter hook means, that the output of our script is analyzed by LaMa. If LaMa sees an output line which is starting with “[WARNING]:”, the validation will raise a validation warning.

Platform:

With the platform we specify, that this operation is only valid for UNIX systems.

Note: Make sure that you distribute the .conf file to each SAP host were you want to use this operation.

For a complete documentation on what is possible here, please look into the LaMa manual chapter Configuring SAP Host Agent Registered Scripts.

Introduce validation script to LaMa (Provider Implementation Definition)

Now as the script is available and known to the SAP host agent on all of our systems, the rest is just some configuration in LaMa. To be able to use the script as custom validation, we need to create a Provider Implementation Definition first. This can be done via Automation Studio -> Design -> Provider Implementation Definitions:

As Name we can specify how LaMa should call the operation. I prefer to use the same name as defined in the .conf file of the SAP host agent. As type we use Script registered with host agent. As Registered Script we need to specify exactly the name we used in the .conf file. In my case this is the same as Name.

Make sure that you mark the required Provider Implementation Usage on the right side. As we want to validate a profile parameter setting for SAP instances, I marked Operation: Instance. With this setting we can use our script as an Instance Operation only. After saving it, we only need to finally set up the custom operation as validation.

Create custom operation for validation

To create the last bit of LaMa configuration, go to Automation Studio -> Design -> Custom Operations:

Here we add a new custom operation. As Name we can use the name from the SAP host agent .conf file again. As Definition Name we need to reference to the Provider Implementation Definition we created in the previous step. As Button Group we just keep the “default” button group, as this is not important if the operation is run as validation. To define it as validation operation, we need to place the checkmark on the right side of the screen (Validation Operation).

The button Add Default Constraints gives us some constraints which make sure that the validation is only run if the install is not in the initial state and the host is reachable. I manually added another constraint for the Instance Type. With this constraint the validation will only be run for SAP instances of type AS Instance. And that’s finally it! After saving, LaMa will run our validation script during each validation run of an application server instance. Normally this is every 24 hours or when you manually click the Validate All button on the validation tab of an instance.

Hint: For troubleshooting it might be helpful to remove the checkmark Validation Operation temporarily. When the checkmark is not set, the script can be called as normal custom operation. With this configuration it is shown under the selected button group in the Advanced Operations -> Instance Details view of your instance:

From this view you can trigger the script with the Execute button. Afterwards you will find the execution log of the script in the Log tab. This comes in very handy if your script should not work as expected. From the logs you can also see the parameter names which are used to pass information between LaMa and your custom scripts.

Viewing the results

Now that our new validation is active, we can view the validation results over our whole SAP Landscape. To get a good overview of the results, I prefer to go to the Advanced Operations view in LaMa:

With the Grouping & Filtering button, we can group by Validation – Name. Now this view can be filtered for our new validation. In the screenshot I filtered for Lama* for convenience. From this view I can read the following:

  1. I have one system were the validation ran and it raised a warning, which means that I still have to disable the login/no_automatic_user_sapstar parameter.
  2. I have several other systems, were the validation was not yet run. I need to schedule a validation run for them or just wait until the next automatic validation run.
  3. There is one system, for wich the validation was skipped because the constraints did not match.

Result

We now have defined a custom validation which is run by the daily LaMa validation schedule. By viewing the validation warnings we can find out which SAP instances are configured incorrectly regarding the login/no_automatic_user_sapstar parameter. 

With custom validations you can validate pretty much anything in your SAP Landscape. Basically you can do everything you are able to code in a shell script. You can also define custom notifications based on the result of your custom validations and let LaMa send you an E-Mail if a Warning is raised. Of course you can also let your script send out the E-Mail directly. 😉

I think this is a very strong tool to monitor your system configurations and keep things in the standard configuration. In this example you will quickly know when somebody tinkers with the login/no_automatic_user_sapstar SAP profile parameter! The possibilities are endless!

Feedback

Feel free to use this blog post to configure your own custom validations in LaMa. If you do, I would be curious to know what you validated with a LaMa custom validation. It would be great if you would leave a comment to share your ideas on useful custom validations.

10 Comments
You must be Logged on to comment or reply to a post.
  • Great example, I finaly managed to set it up!

    Remember to ‘check’ “synchronous execution”, to get the output in the LaMa log screen as stated in the documentation :

    The markers are not shown within SAP LaMa. If the custom operation is marked for synchronous execution, the results are shown within a dialog box.

    Best Regards

    Bent Kirkegaard Nielsen

  • Hi Benny,

     

    Thank you for the blog. I am getting Error occured when trying to Lamasapstartsrv.conf instance. (RemoteException: ‘Custom Hostagent Operation ‘Lamasapstartsrv.conf’ not known to host. Ensure that the .conf file is located in the operations.d subdirectory, and accessible by the SAPHostAgent’)

     

    Thanks,

    Ranjith

     

    • Hi Benny,

      I was able to fix the issue. the filename in lama UI should be  Lamasapstartsrv not Lamasapstartsrv.conf. This was causing the issue.

       

      Thanks,
      Ranjith

       

  • Hi Benny,

    Thank you for the detailed information on the Custom Validation Script,I tried to configuring this script in our  solution Manager system and below is the output I received

    It is looking for START Profile but we don’t have START profile anymore.

    === Custom validation /sapbasis/scripts/LamaValAutoSapstar.bash called with parameters: -p /usr/sap/SMD/SYS/profile/START_DVEBMGS00_sol3d WARNING: Instance profile /usr/sap/SMD/SYS/profile/START_DVEBMGS00_sol3d not found! Validated

    This parameter is passed in by LaMa as $[SAPSTARTPROFILE],

    Can you please suggest the variable to check for Instance Profile or Default

    Thank you so much

    Regards,

    Jay

    • Hi Jay,

      sounds like LaMa is passing a wrong value for $SAPSTARTPROFILE to the script. Have you checked if the start profile is configured correctly in LaMa? You can check in the instance configuration in section “Instance Agent Configuration”:

      Hope this points you into the right direction.

      Kind regards,

      Benny

  • Hi Benny,

    Thanks a lot for this blog!

    I have the following issue for some of our instances:

    The ABAP instance is configured with the old naming convention for defining the instance profile.(e.g. CRR_DVEBMGS30_crrci). Could this be the reason for the the error? How could we solve it?

    Nice regards,

    Guy.

     

     

     

     

    • Hi Guy,

      you need to check the constraints you have defined for your custom operation:

      You seem to have configured the validation to run only on “AS Instances”. Probably you need to change this to “Central Instance”. You can also add a second constraint, so that your validation runs on both instance types.

      Kind regards

      Benny

      • Hi Benny,

         

        Thanks for the quick answer. Would it be possible to have both constraints at the same time, as we have both instance types in our SAP Landscape?

        Nice regards,

        Guy.

         

        • Hi Guy,

          sure. Just add another constraint entry for the other instance type. If you define a constraint multiple times with the ‘=’ operator, they are related by ‘OR’. That way your validation will run on both instance types.

          Kind regards

          Benny