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

tiny-tool.de

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"

Werbung/Advertising

<
>

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

Werbung/Advertising

<
>

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