Ein Artikel an einem Freitag statt Dienstag? Was ist da denn los? Keine Sorge, ich bin nicht krank und in Österreich ist nicht die Anarchie ausgebrochen. Es gibt eine ganz einfache Erklärung:
Ich bin gerade auf der Automic World in Orlando und während dieser Artikel veröffentlicht wird, halte ich gerade einen Vortrag zum gleichen Thema: Ich erkläre meinen Zuhörern, dass sich SQL-Abfragen auf die AE Datenbank lohnen – dass man dabei aber wissen sollte, was man tut.
Und hier gibt es jetzt für Sie die schriftliche Verion: 3 überzeugende Gründe dafür, Datenbankabfragen zu schreiben, aber auch die 3 größten Risiken, die Sie dabei eingehen.
Übrigens, die Folien aus meinem Vortrag können Sie sich am Ende des Artikels herunterladen. Darin finden Sie ausführlichere Informationen zu den Beispielen und den verwendeten Scripts.
Grund 1: Die Nadel im Heuhaufen
Ein Kunde kam mit folgendem Problem zu mir: Die meisten Jobs in seinem Workflow für die Rechnungsstellung hatten eine Post Condition. Aber leider nicht alle. Deshalb definierte er eine Default Post Condition für alle Tasks, die noch keine hatten.
Auf dem System des Kunden gab es hunderte Workflows und über 2.500 Jobs. Für ungefähr 10% davon war keine Post Condition definiert.
Ohne SQL ist diese Aufgabe beinahe ein Lebenswerk. Mit SQL dagegen sind es wenige Zeilen Code, um die Einträge der betroffenen Jobs in der Datenbank zu finden.
Ich werde hier nicht ins Detail gehen – die Folien zu meinem Vortrag bei der Automic World können Sie am Ende des Artikels herunterladen. Darin finden Sie mehr Informationen zu den technischen Details und das Skript, dass ich für die Aufgabe verwendet habe.
Mit SQL-Abfragen können Sie in Ihrer Datenbank schnell Elemente finden, die bestimmte Bedingungen erfüllen.
Grund 2: Daten schnell verbinden
Lassen Sie es mich vorsichtig ausdrücken: Die AE Datenbank ist groß. Abhängig von der Komplexität Ihres Systems gibt es verschiedene Bereiche, Clients und Level. Informationen daraus zusammenzutragen ist aufwendig und vor allem langsam – es sei denn, Sie benutzen SQL.
Schon kurze und einfache Abfragen können Ihnen viel Zeit und Ärger sparen. In meinem Vortrag stelle ich dazu ein ausführliches Beispiel vor: Während Downtime durch eine Anwendung, die von ONE Automation gesteuert wird, wurden geplante Tasks übersprungen.
Um im Nachhinein alle Tasks in aktiven Schedules zu finden, die übersprungen wurden, muss man Informationen aus diversen Tabellen verbinden.
Für diesen Artikel ist eine Beschreibung des Beispiels zu lang. Wenn Sie wissen wollen, wie es im Detail funktioniert, haben Sie zwei Möglichkeiten:
- In meinen Folien vom Vortrag bei der Automic World finden Sie Scripts und Grafiken zu meinem Vorgehen.
- In zwei Wochen präsentiere ich dieses Beispiel hier im Blog noch einmal ausführlicher.
Grund 3: Verstecktes und Fehlendes
Dinge sichtbar machen, die überhaupt nicht da sind – wie soll das denn funktionieren? Ich zeige es an zwei Beispielen:
Beim Transport von Dev auf Prod passieren leicht Fehler. Sie können zum Beispiel einen Workflow transportieren, aber einen Job vergessen, der zu diesem Workflow gehört. Dieser Job fehlt dann auf Prod und der Workflow endet mit einer Fehlernachricht.
Mit einer einfachen und schnellen Abfrage auf die Datenbank können Sie herausfinden, ob im System Elemente fehlen.
Das zweite Beispiel kennen Sie als regelmäßiger Leser dieses Blogs schon: Sie können in den Daten Informationen finden, die noch nicht vordefiniert sind. Zum Beispiel den kritischen Pfad eines Workflows.
Mehr dazu finden Sie im Artikel Analyse kritischer Pfade.
Die Risiken von SQL-Abfragen
Ich habe es zu Beginn des Artikels schon angekündigt: Man muss im Umgang mit der Datenbank vorsichtig sein. SQL bringt tolle Vorteile, aber man muss wissen, was man damit macht.
In meinen Augen gibt es drei Risiken, auf die Sie besonders achten müssen.
Risiko 1: Unerwünschte Nebeneffekte
Das erste Risiko ist gleich das gefährlichste: Wenn Sie Dinge direkt in der Datenbank ändern, gefährden Sie Ihr ganzes System. Kleine Änderungen können unvorhergesehene Auswirkungen haben.
Zum Glück gibt es für dieses Risiko eine einfache Lösung:
Ändern Sie niemals etwas direkt in der Datenbank!
Risiko 2: Beeinträchtigung der Leistung
Abfrasgen beanspruchen Ihre Datenbank. Wenn Sie dabei nicht aufpassen können sich die Abfragen auf die Leistung Ihrer ONE Automation auswirken.
Man hat verschiedene Möglichkeiten, das Risiko zu schmälern:
- Abfragen mit SQL Clients entwickeln
- Abfragen auf einem Dev-System entwickeln ehe man sie auf der Produktion ausführt
- Die Größe der Rückgabe von Abfragen kontrollieren
- Systemleistung und Runtime im Auge behalten
Aber obwohl die Leistung durch SQL-Abfragen beeinträchtigt wird, gilt natürlich: Wenn Sie an die Daten und Informationen Ihrer Automation Engine wollen, dann gibt es keinen schnelleren und ressourcenschonenderen Weg als über SQL!
Risiko 3: Mousse au Chocolat
Dieser Punkt ist am ungefährlichsten – aber auch am schwierigsten zu beheben.
Kennen Sie das hier abgebildete Emoji?
Bekannte von mir dachten, dass es sich dabei um Mousse au Chocolat handelt, und waren entsetzt, nachdem ich sie über die wahre Bedeutung aufgeklärt hatte. Manche Ihrer Textnachrichten bekamen plötzlich eine ganz andere Bedeutung…
Genauso kann es mit SQL-Abfragen passieren: Vielleicht hat Ihnen Ihre Abfrage etwas ganz Anderes geliefert, als Sie eigentlich geplant haben. Wenn Sie es gleich bemerken: kein Problem. Oft ist es aber nicht so offensichtlich.
So werden Sie zum SQL-Meister
Konnte ich Sie neugierig machen? Natürlich gibt es mehr als 3 gute Gründe, um sich selbst mit SQL und der Datenbank vertraut zu machen – leider gibt es aber auch noch mehr Risiken.
Um maximal von SQL und Datenbankabfragen zu profitieren, hilft nur eins: Sie müssen lernen, richtig damit umzugehen.
Für einen erfolgreichen Einstieg habe ich 3 Empfehlungen für Sie:
- Laden Sie sich hier die Folien von meiner Präsentation herunter und versuchen Sie die Beispiele nachzuvollziehen.
- Lesen Sie meine Artikelserie zum Einstieg ins SQL-Querying: Teil 1 und Teil 2
- Nehmen Sie am AE Database Knowledge Workshop teil und vertiefen Sie sich 3 Tage lang in die Details der Datenbank und SQL-Abfragen