A Guest Post by Oliver Frese


Regular backups can be extremely tiring. Especially when the bosses keep coming around with new backup strategies: New number of versions, new number of backups per week and similar demands.

After participating in Philipps Automation Engine Database Knowledge Workshop, I had an idea how I could simplify this in my company: with a VaraXML.

VaraXML and 3 JOBs

So I created ONE VaraXML to control all SAP backups centrally: my VARA.SYSTEMINFOS. There is one entry per SID. In addition to the backups, I now use this Vara for a lot of other processes.

It contains all the information necessary to carry out the backups. Important key data such as name, agent, OS, SAP system, database, paths. But also control parameters for important jobs and log entries of the backups.

 
<?xml version="1.0" encoding="ISO-8859-15" standalone="no"?>
<sid>
   <name><em>SID</em></name>
   <agent><em>Agentname</em></agent>
   <host><em>Hostname</em></host>
   <os><em>AIX</em></os>
   <rolle><em>E</em></rolle>
   <db><em>ORACLE</em></db>
   <db_home<em>>/oracle/SID/122</em></db_home>
   <db_port><em>PORT</em></db_port>
   <db_schema><em>Schemaname</em></db_schema>
   <stack><em>abap</em></stack>
   <utl_home<em>>/oracle/SID/122/dbs</em></utl_home>
   <backup_versions><em>{VARA.ALL@BACKUP$VERSIONEN,Entwicklung,1}</em></backup_versions>
   <backup_sessions><em>4</em></backup_sessions>
   <last>13122019</last>
   <start>01:00:19</start>
   <end> 01:23:16</end>
   <length>22 min 55 sec.</length>
   <size>946120.797 MB</size>
   <logfile>bfcrevsz.anf</logfile>
   <tss><em>BACKUP Location</em></tss>
   <backup><em>AKTIV</em></backup>
...

The backup is then carried out with a simple workflow consisting of 3 jobs.

The plan first collects the contents of the Vara in the script and checks whether the backup should run (<backup>ACTIVE</backup>) and whether the last backup location is filled (<tss>BACKUP Location</tss>). If not, error handling is performed and mails are sent. The generation of the plan is also canceled.

  • The first job, during runtime, creates the UTL file for backup at runtime
  • The second is the backup itself
  • The third one runs a br-archive in the case of ORACLE. In other words, the plan applies to both Oracle and DB2

JOB 1 is largely responsible for the simplification of the backup process. If I am presented with new requirements or strategies, I no longer have to log in to 70 operating systems and manually adjust the UTL files. Instead, JOB 1 gets the values from VaraXML and dynamically writes the UTL file.

Depending on the DB type, JOB 2 then calls the respective command line command for the backup, taking care to ensure a flip-flop process. To do this, the last backup location is read from the Vara and then the other location is passed to the command.

The entire process is now centralized in the UC4.

Use Cases for VARA.SYSTEMINFOS

VARA.SYSTEMINFOS is not only useful when performing backups. In many other regards, too, it simplifies my work.

The first use case is quite simple: I have built a Job that creates an XLS with the information of the VARA. At the push of a button, we get an overview of all information about our SAP systems. For this, I additionally use an SQL query to get the days the respective backups are scheduled for and visualize the information in the table.

The second use case, once more, shows that laziness is an important driver for human innovation. Within short time, I had to twice change the amount of backup versions. I would have had to adjust 70 entries in my VARA.SYSTEMINFOS. Twice.

That was too much for me.

That’s why I introduced a static VARA and refer to it within the VARA.SYSTEMINFOS with curly bracket notation:

<backup_versions>{VARA.ALL@BACKUP$VERSIONEN,Entwicklung,1}</backup_versions>

This VARA contains the information, how many versions are intended for which role of the system.

And to make it even more automated, I always have the backup job plan created automatically when we get a new SAP system. For this I use a PromptSet, a backup plan template and the following script:

...
:  PSET &VORLAGE#    = 'JOBP.HOST@ONLINE_SICHERUNG_FF$SID'
:  PSET &JOBNAME#    = 'JOBP.&AGENT#@ONLINE_SICHERUNG_FF$&SID#'
...
! XML laden & ändern & zurückschreiben 
!Bei Jobplänen nur den Jobplannamen anpassen 
:  SET &HND# = PREP_PROCESS_FILE(UC4SERVER, &FILE_EXP#) 
:  SET &XML_PROCESS# = XML_PROCESS_TO_DOM(&HND#) 
:  SET &XML_NODE#    = XML_SELECT_NODE(&XML_PROCESS#, '/uc-export/JOBP') 
:  SET &XML_ATT#     = XML_SET_ATTRIBUTE(&XML_NODE#,"@name","&JOBNAME#") 
:  SET &XML_RET#     = XML_PRINTINTOFILE('&FILE_EXP#', &XML_PROCESS#) 
:  XML_CLOSE 

After importing the created XML file, I only have to schedule the backup.

In addition, the CONN.OBJs are created for the DB, the connection parameters and login data are entered, the login objects are expanded and an entry is made in my VARA.SYSTEMINFOS.

Even More Use Cases?

Many of the ideas I presented in this article came after I attended the Automation Engine Database Knowledge Workshop. I had never worked with a VaraXML before, now I can hardly imagine how I could manage without it.

I’m also sure that there are many more ways to use these VARAs.

Do you also use XML Varas for similar applications? Let us know in the comments.

Oliver Frese

Automic/SAP/DMS Administrator
Oliver is a trained IT clerk. Since 2010 he has been working at Count + Care GmbH & Co KG as an Automic Admin / Operator / Programmer, SAP System Administrator and as a DMS Administrator.

Get concentrated knowledge from 5 years of AutomicBlog

Download an archive with all old articles:

  • Features, SQL-Tricks, and handy Scripts.
  • 63 extensive articles (+ comments).
  • Used by Automic experts around the world.

Subscribe to the newsletter and immediately get all articles!

[caldera_form id="CF572741b60f87f"]