💡 Schluss mit Copy-Paste-RPG: Automatisierung per Workflow statt neuer Programme

tiny-tool.de

In vielen IBM i-Projekten sieht man immer wieder das gleiche Muster: Daten aus der Datenbank holen, irgendwie in eine strukturierte Form bringen, in eine Mail packen und verschicken. Immer wieder. Nur jedes Mal ein bisschen anders – und dafür wird dann oft ein neues RPG-Programm gebaut.

Doch dieses Prinzip ist keineswegs auf RPG beschränkt. Auch in Java-, .NET- oder Python-Projekten finden sich ähnliche Strukturen – meist als schnell zusammengeschriebene Utility-Skripte oder Batchprozesse, die irgendwann schwer wartbar werden.

Aber warum eigentlich?

Geht das nicht auch generischer, konfigurierbarer und wiederverwendbar?

Hinweis

Alle auf dieser Website genannten Produktnamen, Logos und Marken sind Eigentum ihrer jeweiligen Inhaber. Alle Firmen-, Produkt- und Dienstleistungsnamen, die auf diesem Blog verwendet werden, dienen ausschließlich Identifikationszwecken und implizieren keine Verbindung oder Unterstützung durch die jeweiligen Inhaber. Werbung ist entsprechend gekennzeichnet.

🔁 Immer gleiche Aufgaben – immer neue Programme?

Nehmen wir mal diesen typischen Ablauf:

Hole SMTP-Server aus einer Konfigurationstabelle
Hole die Empfänger für einen bestimmten Prozess
Hole die eigentlichen Nutzdaten (z. B. aus einer View oder einer Abfrage)
Erzeuge daraus eine CSV
Wende ein E-Mail-Template an
Sende die Mail über SMTP

In RPG sieht das oft nach viel Code aus. Und wenn sich etwas ändert – ein neuer Prozess, ein anderes Template, eine andere Tabelle – wird wieder ein neues RPG gebaut. In anderen Plattformen ist es dann vielleicht ein neues Java-Job-File, ein Python-Script oder ein PowerShell-Task. Gleiches Muster, gleiches Problem.

Dabei könnte man diesen Ablauf wunderbar als Workflow definieren – zum Beispiel so:

steps:

  - step: executeSql

    name: fetchMailserver

    query: "SELECT smtp_server FROM config WHERE id = 1"

  - step: executeSql

    name: fetchRecipients

    query: "SELECT email FROM recipients WHERE active = 1"

  - step: executeSql

    name: fetchContent

    query: "SELECT name, value FROM report_data"

  - step: transform

    name: transformData

    type: csv

  - step: applyTemplate

    name: applyEmailTemplates

    subjectTemplate: "emailSubject.ftl"

    bodyTemplate: "emailBody.ftl"

  - step: sendEmail

    name: sendNotification

    smtp: "context:fetchMailserver"

🧠 Die Lösung: Workflows statt „Coding-Orgie“

Um genau solche wiederkehrenden Aufgaben einfacher zu handhaben, habe ich ein kleines Workflow-Framework gebaut: hermes-workflow – ein modularer Ansatz auf Basis von Java und Spring Boot, bei dem Prozesse deklarativ per YAML beschrieben werden. Kein neues RPG-Programm mehr, kein wildes Copy-Paste.

Aktuell wird ein Hotfolder überwacht, in den z. B. Job-Files gelegt werden können. Weitere Auslöser sind denkbar (und technisch leicht erweiterbar), etwa:

interaktive Aufrufe
Zeitsteuerung (z. B. via Quartz oder cronähnlich)
Queues (z. B. MQ, Datenbank-Queues oder IBM i Data Queues)
oder WebSocket-basierte Trigger

Und das Beste: Spring Boot macht’s plattformunabhängig. Das Ganze läuft nicht nur auf der IBM i, sondern überall – lokal, in der Cloud oder im Docker-Container. Datenbankseitig reicht alles, was per JDBC erreichbar ist.

☝️ Hinweis: Das Projekt ist öffentlich verfügbar – in erster Linie als Lern- und Übungsidee gedacht. Wenn du Java- und Spring Boot-Kenntnisse mitbringst (oder gerade einsteigst), kannst du hier gut experimentieren – und nebenbei moderne Integrationsideen aufgreifen, die weit über IBM i hinausgehen.

🤔 Aber kann man nicht einfach SQL verwenden, um JSON direkt zu erzeugen?

Klingt verlockend. Und ja – Db2 for i bietet seit V7R3 tatsächlich eingebaute JSON-Funktionen wie:

JSON_OBJECT – erzeugt ein JSON-Objekt aus Spaltenwerten
JSON_ARRAY – erzeugt Arrays von Werten oder Zeilen
JSON_TABLE – bringt JSON-Daten wieder in relationale Tabellenform

Diese Funktionen sind sehr nützlich, wenn man:

einfache Objekte direkt aus SQL erzeugen möchte,
schnell ein flaches JSON für eine Web-API liefern will,
kleine JSON-Strukturen für externe Tools oder Services braucht,
eingehende JSON-Daten parsen und relational weiterverarbeiten will.

👉 Kurz gesagt: Für klar strukturierte, flache Daten ist das eine schnelle Lösung – besonders wenn man direkt aus Views oder Tabellen arbeitet.

🧱 …aber für alles andere?

Sobald die Anforderungen wachsen – z. B.:

verschachtelte Objekte mit mehreren Ebenen,
dynamische Inhalte (z. B. abhängig vom Prozesskontext),
unterschiedliche Strukturen je nach Datensatz,
Fehlerbehandlung, Transformation, Logging, ReUse –

…wird’s in reinem SQL sehr schnell komplex und schwer wartbar. Vor allem wenn man später auch noch andere Ausgabeformate benötigt – oder die Struktur regelmäßig anpassen muss.

Und genau hier kommt der Workflow-Ansatz ins Spiel:
SQL liefert die Rohdaten – danach übernehmen gezielte, konfigurierbare Verarbeitungsschritte.

🛠️ Formatvielfalt durch XSLT: JSON, HTML, Markdown und mehr

Ein Highlight des Systems: Wir nutzen XSLT, um die Daten nach der Abfrage in verschiedenste Formate zu bringen – flexibel, nachvollziehbar und konfigurierbar.

Mitgeliefert sind bereits Transformationen in:

CSV – z. B. für Excel-Importe oder Anhänge
HTML – für direkt lesbare Report-Mails oder Webausgaben
JSON & JSONL – für moderne API-Formate oder Streaming-Verarbeitung
Markdown (MD) – für lesbare Log-Dateien, E-Mail-Reports oder technische Doku

Und das Beste: Alles definierbar per YAML und XSLT – ganz ohne ständiges Nachprogrammieren im Backend.

✨ Fazit:
SQL + JSON-Funktionen? Super für klar umrissene Aufgaben.
Aber wenn du flexibel bleiben willst – in Struktur, Format und Verarbeitung – dann ist ein Workflow-System wie dieses die deutlich robustere und wartungsfreundlichere Lösung.

🚀 Und was kommt als Nächstes?

Das Workflow-System ist bewusst so aufgebaut, dass es mitwachsen kann – und du es Stück für Stück an deine Anforderungen anpassen kannst. Die bisherigen Funktionen decken schon viele typische Automatisierungs-Szenarien ab, aber das Potenzial ist noch lange nicht ausgeschöpft.

Folgende Erweiterungen stehen auf der Roadmap – oder lassen sich mit wenig Aufwand ergänzen:

Zeitgesteuerte Ausführung von Workflows (z. B. täglich um 6:00 Uhr morgens)
Trigger durch Queues, z. B. IBM MQ, Datenbank-Queues – oder sogar IBM i Data Queues
REST-basierte Ausführung, z. B. um Prozesse über eine API anzustoßen
JSON als Eingabequelle: Derzeit liegt der Fokus auf SQL als Input, aber technisch ist es problemlos möglich, auch JSON-Daten aus Dateien, Webservices oder REST-POST-Aufrufen zu verarbeiten. Damit wäre z. B. auch die Umsetzung klassischer API-basierten Eingänge (Webhook → Workflow) ein Kinderspiel.
Weitere Transformationen: Du möchtest aus JSON direkt eine HTML-Tabelle erzeugen oder Markdown-Reports per Slack schicken? Dank XSLT und dem offenen Template-System geht das – heute schon oder bald ganz leicht.

📌 Fazit: Was heute eine flexible Lösung für „SQL rein, CSV raus“ ist, kann morgen zur zentralen Integrations- und Automatisierungsplattform in deiner IBM i-Umgebung werden – oder darüber hinaus.

🧩 Noch Fragen? Lust auf mehr?

Wenn du dich in deinem Projekt regelmäßig dabei ertappst, wie du „mal eben schnell“ ein neues RPG-Programm schreibst, nur um Daten zu holen, zu formatieren oder zu verschicken – dann ist es vielleicht Zeit für einen neuen Ansatz.

Workflows statt Copy-Paste. Konfiguration statt Boilerplate. Wiederverwendbare Steps statt Programmfragmenten.

Mit dem hermes-workflow möchte ich zeigen, wie man mit einfachen Mitteln wiederkehrende Aufgaben strukturieren und automatisieren kann – und dabei ganz nebenbei moderne Technologien wie Spring Boot, XSLT und YAML nutzt.

📘 Und wenn du neugierig geworden bist: In einem Folgeartikel zeige ich dir, wie du eigene Workflows definierst, mit Templates arbeitest und sogar dynamische Entscheidungen in deine Abläufe einbauen kannst.

✨ Außerdem werde ich regelmäßig Einblicke in die Implementierung geben und den Funktionsumfang Stück für Stück erweitern – ganz praxisnah, mit Fokus auf Wiederverwendbarkeit, Transparenz und ein bisschen Spaß an moderner IBM i-Entwicklung.

🚀 Neugierig geworden?

Der Quellcode zum Workflow-System ist öffentlich auf GitHub verfügbar:

👉 Zum Source-Code auf GitHub

🔗 Weitere Artikel auf meinem Blog zum Thema:

🌐 Weitere lesenswerte Ressourcen: