A few weeks ago, we discussed how an SAP system could be set up to be “externally-signed”, i.e. trusted so that the system is truly what someone may claim it to be.  This is the root of all SSL trust relationships.

Now that we have set up such a trusted system, how can we utilize it further for operational productivity in automation?  SAP already has Intelligent Robotic Process Automation entitlements available in its SCPI Cloud Foundry.  However, what if we want a Basis level process to just stop and start multiple SAP in any trusted environment?  How do we manage something so simple and yet so critical in its usage?  Stopping, starting and upgrading the SAP Host Agent, Kernel and other OS components are critical, complex but clearly documented steps that are done dozens of times by a Basis administrator in the course of a year.  Automating it so errors are avoided, and freeing up time for more useful work, just makes sense.

The trick to automating the processes is to go beyond SAP proper and leverage the corporate eco-system:  at the OS level, we consider a Linux/Unix environment and for the interface, a nodejs snippet to call the shell script.  In a future document, we shall consider a Windows environment as well.

Scenario:  At its simplest level, we consider a distributed SAP NetWeaver/HANA system with two application servers and a HANA DB server.  For automation purposes, we should have a separate, single, server from where all commands can be run.  SAP Solution Manager can be a good central server but in reality, any Linux server would suffice.

Manual Steps:  To stop the system, the steps are as follows.  (Recall that we have to typically use an ID like tstadm to execute the steps, where TST is the SID for the SAP system):

Stop Application Server 1 using command:

stopsap r3

(there may be other steps like cleanipc but we shall ignore those for the sake of simplicity)

Stop Application Server 2 using command:

stopsap r3

Stop Database Server 1 using command:

HDB stop

For the initial login, we shall assume a generic login ID “saprpa” which will have the rights to use the *UX sudo functionality switch to <sid>adm without a password.

For the setup, we will need root access to run the command:

visudo

Add the following line to the end:

saprpa    ALL=(tstadm) NOPASSWD: /bin/bash

Setting up the shell programs:  Once this file is saved, we can now switch from saprpa to tstadm without a password using the command:  “sudo su – tstadm”. This will be critical to run the stop/start commands in RPA automation.

To execute a command from a generic ID using a sidadm identity, we need to create shell scripts as follows under ID saprpa:

stopApp1.sh:

sudo su - tstadm -c "stopsap all"

stopApp2.sh:

sudo su - tstadm -c "stopsap all"

stopDB.sh:

sudo su - tstadm -c "stopsap all"

From the central server, we would connect to the remote application and database server as follows using another shell batch file:

stopAll.sh:

ssh -n -tt -o StrictHostKeyChecking=no saprpa@App1-IP './startApp1.sh'

ssh -n -tt -o StrictHostKeyChecking=no saprpa@App2-IP './startApp2.sh'

ssh -n -tt -o StrictHostKeyChecking=no saprpa@DB-IP './startDB.sh'

In the above case,

App1-IP is the IP address of the first application server,

App2-IP is the IP address of the second application server and

DB-IP is the IP address of the DB server.

If all the programs are run from a central server with an IP address Central-IP, then we need to do the following to create the SSH trust keys between them.

ssh -n -tt -o StrictHostKeyChecking=no saprpa@App1-IP "echo -e 'n' | ssh-keygen -b 2048 -t rsa -f /home/saprpa/.ssh/id_rsa -q -P '' "

(For the first time setup, we will be prompted for the password for saprpa and we have to enter it as required).  In each case, two files, id_rsa and id_rsa.pub will be created under the /home/saprpa/.ssh directory of each server.  The id_rsa key is the private key that must remain in place.  The id_rsa.pub is the public key that can be shared and copied as needed.

Next, we copy each of the files from the locally to the Central-IP server under the /home/saprpa/.ssh location:

scp -o StrictHostKeyChecking=no saprpa@App1-IP:/home/saprpa/.ssh/id_rsa.pub $App1.pub

On the Central-IP server also, we run the following command:

echo -e 'n' | ssh-keygen -b 2048 -t rsa -f /home/saprpa/.ssh/id_rsa -q -P ''

As a result, we will have files named as follows copied down to the Central-IP server:

id_rsa.pub (for the local public key for the Central-IP server)

App1-IP.pub

App2-IP.pub

DB-IP.pub

Now, we concatenate the files into one:

cat App1-IP.pub App1-IP.pub DB-IP.pub  rsa_id.pub  >> authorized_keys


This file authorized_keys contains all the public keys for the four servers involved.  This is the final step to ensure that these four servers (and only these servers) trust each other and allow the scripts written above to be executed:

scp -o StrictHostKeyChecking=no authorized_keys  saprpa@App1-IP:/home/saprpa/.ssh/.

. . . and similarly for the other servers App2-IP, DB-IP and Central-IP

Now, from the Central-IP server, we can execute the stop or start command we wrote earlier:  stopAll.sh.  This will use this single command to stop all the servers.

We can further automate this code by setting them up on open source nodejs and MySQL products like AutoAI from where they can be executed from a single Cloud source using a graphical interface.  However, the code we have used above is sufficient for small systems and can be implemented by any SAP Basis or OS administrator with the appropriate access.

Conclusion:  By using the basic automation, we can stop, start and run routine items like HA cluster failover, and enterprise patching on small (or possibly large) groups of SAP servers in one data center or around the world, as long as the necessary trust relationships are set up by following the methods above.  Happy #automating with #SAP #RPA!