VaraXML für Backups und die RESOLVE_VAR Skript-Anweisung

Ein Gastartikel von Oliver Frese


Regelmäßige Backups können extrem anstrengend sein. Vor allem, wenn immer wieder die Chefs mit einer neuen Backupstrategie um die Ecke kommen: neue Anzahl an Versionen, neue Anzahl an Backups pro Woche und ähnliche Forderungen.

Nach meiner Teilnahme an Philipps Automation Engine Database Knowledge Workshop kam mir eine Idee, wie ich das bei mir im Betrieb vereinfachen kann: Mit einer VaraXML.

Die VaraXML und 3 JOBs

Ich habe also EINE VaraXML angelegt, um alle SAP Backups zentral zu steuern: Meine Vara.Systeminfos. Pro SID gibt es einen Eintrag. Neben den Backups benutze ich diese Vara mittlerweile auch für viele andere Verarbeitungen.

Sie enthält alle Infos, die zur Durchführung der Backups nötig sind. Wichtige Eckdaten wie Name, Agent, OS, SAP System, Datenbank, Pfade. Aber auch Steuerungsparameter für wichtige Jobs sowie Logeinträge der 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>
...

Das Backup wird dann mit einem einfachen Workflow aus 3 Jobs durchgeführt.

Der Plan zieht sich im Script zuerst den Inhalt der Vara und prüft, ob das Backup laufen soll (<backup>AKTIV</backup>) und ob die letzte Backup-Location gefüllt ist (<tss>BACKUP Location</tss>). Falls nicht gibt es ein Fehlerhandling und Mails werden verschickt. Außerdem wird die Generierung des Plans abgebrochen.

  • Der erste Job erstellt zur Laufzeit das UTL File für das Backup
  • Der zweite ist das Backup selbst
  • Der dritte lässt im Falle ORACLE noch einen br-archive laufen. Sprich der Plan gilt sowohl für Oracle als auch DB2

JOB 1 ist maßgeblich für die Vereinfachung des Backup-Prozesses verantwortlich. Wenn ich neue Anforderungen oder Strategien vorgelegt bekomme, muss ich mich nicht mehr wie früher in 70 Betriebssystemen anmelden und manuell die UTL-Files anpassen. Stattdessen holt sich JOB 1 die Werte aus der VaraXML und schreibt dynamisch die UTL-Datei.

JOB 2 ruft dann je nach DB-Typ den jeweiligen Commandline-Befehl für das Backup auf und achtet dabei darauf, ein Flip-Flop-Verfahren zu gewährleisten. Hierfür wird der letzte Sicherungsstandort aus der Vara geholt und dann der andere Standort an den Befehl übergeben.

Der gesamte Prozess läuft jetzt zentralisiert im UC4 ab.

Anwendungsbeispiele für die VARA.SYSTEMINFOS

Die VARA.SYSTEMINFOS ist nicht nur beim Durchführen der Backups nützlich. Sie erleichtert mir auch ansonsten sehr oft die Arbeit.

Ganz simpel ist das erste Anwendungsbeispiel: Ich habe mir einen Job gebaut, der mir eine XLS aus den Informationen der VARA schreibt. Per Knopfdruck bekommen wir damit eine Übersicht über alle Infos zu unseren SAP Systemen. Ich frage dafür zusätzlich per SQL ab, an welchen Tagen die jeweiligen Backups im Schedule eingeplant sind und visualisiere die Infos in der Tabelle.

Beim zweiten Anwendungsfall zeigt sich mal wieder, dass Faulheit ein wichtiger Antrieb für menschliche Innovation ist. Innerhalb kurzer Zeit musste ich zweimal die Anzahl Versionen der Backups ändern. Ich hätte also zweimal 70 Einträge in meiner VARA.SYSTEMINFOS anpassen müssen. Das war mir zu viel.

Deshalb habe ich eine statische VARA eingeführt und verweise innerhalb der VARA.SYSTEMINFOS mit einer geschweiften Klammer auf die statische VARA:

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

In ihr steht wie viele Versionen bei welcher Rolle des Systems vorgesehen sind.

Und um alles noch ein wenig automatischer zu machen, lasse ich auch immer, wenn wir ein neues SAP System bekommen, automatisch den Sicherungsjobplan erstellen. Dafür benutze ich ein PromptSet, eine Sicherungsplanvorlage und das folgende Skript:

...
:  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 

Nach dem Import der erstellten XML-Datei muss ich die Sicherung nur noch einplanen.
Nebenbei werden auch direkt die CONN.OBJs für die DB angelegt, dort die Verbindungsparameter und Anmeldedaten eingetragen, die Loginobjekte erweitert und ein Eintrag in meiner VARA.SYSTEMINFOS erstellt.

Noch mehr Anwendungsfälle?

Viele der Ideen, die ich in diesem Artikel vorgestellt habe, kamen mir, nachdem ich am Automation Engine Database Knowledge Workshop teilgenommen hatte. Vorher hatte ich noch nie mit einer VaraXML gearbeitet, jetzt kann ich mir kaum mehr vorstellen, wie ich ohne sie zurechtkommen sollte.

Ich bin mir auch sicher, dass es noch viel mehr Möglichkeiten gibt, diese VARAs zu benutzen.

Benutzt du auch XML Varas für ähnliche Anwendungsfälle? Erzähle uns davon in den Kommentaren.

Oliver Frese

Automic/SAP/DMS Administrator
Oliver ist gelernter IT-Kaufmann. Seit 2010 ist er bei Count+Care GmbH & Co KG tätig als Automic Admin/Operator/Programmierer, SAP Systemadministrator und als DMS Administrator.

Von |2022-06-22T11:40:10+02:0023. Januar 2020|Kategorien: AutomicBlog|Kommentare deaktiviert für VaraXML für Backups und die RESOLVE_VAR Skript-Anweisung

Share This Story!

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.

Von |2022-06-30T13:05:03+02:0023. Januar 2020|Kategorien: AutomicBlog|Kommentare deaktiviert für VaraXML für Backups und die RESOLVE_VAR Skript-Anweisung

Share This Story!

Titel

Nach oben