Java mit IBM i verbinden: JDBC, JTOpen und flexible Exporte mit XML, XSLT, JSON, CSV & Markdown

Ein Praxisblick auf ein kleines historisches Beispielprojekt: Was zeus-access-400 gut zeigt, was man heute anders bauen würde – und warum IBM i für Java-Integration spannender ist, als viele denken.

1. Kurzfassung

zeus-access-400 ist ein kleines Java-CLI-Beispiel, das Daten über JDBC aus einer IBM-i-Datenbank liest und in mehrere Formate exportiert. Der technische Kern ist bewusst einfach:

2. Einordnung: Ein historisches Projekt mit aktuellem Lernwert

zeus-access-400 ist kein aktiv gepflegtes Produktivwerkzeug mehr. Das Projekt bleibt aber interessant, weil es eine klare und bis heute brauchbare Architekturidee zeigt: Daten werden per Java und JDBC aus IBM i gelesen, in eine neutrale Zwischenstruktur gebracht und anschließend flexibel in verschiedene Zielformate transformiert.

Gerade kleine Projekte haben einen Vorteil: Man sieht die Idee ohne viel Framework-Nebel. In diesem Fall geht es um drei praktische Punkte:

• Java kann über JDBC sauber mit Db2 for i auf IBM i kommunizieren.
• SQL-Ergebnisse lassen sich neutralisieren, bevor sie in konkrete Zielformate geschrieben werden.
• XSLT kann eine schlanke Transformationsschicht sein, wenn XML ohnehin als Zwischenformat verwendet wird.

3. Die Grundidee: einmal selektieren, mehrfach ausgeben

Viele Datenexporte entstehen aus einer einfachen Anforderung: „Ich brauche diese Daten mal eben als CSV.“ Kurz danach kommt: „Kann ich das auch als JSON bekommen?“ Danach: „Für die Doku bitte als Markdown.“ Und irgendwann: „Eine kleine HTML-Ansicht wäre auch praktisch.“

Die naive Lösung wäre, für jedes Format eigenen Java-Code zu schreiben. Das funktioniert, wird aber schnell unübersichtlich. zeus-access-400 geht einen anderen Weg:

Das ist nicht für jeden Anwendungsfall perfekt, aber als Muster sehr lehrreich:

• Die Datenbeschaffung bleibt von der Darstellung getrennt.
• Neue Zielformate können über zusätzliche XSLT-Dateien ergänzt werden.
• Das XML-Zwischenformat ist prüfbar, versionierbar und gut nachvollziehbar.
• Das Konzept funktioniert lokal, auf Servern und grundsätzlich auch in IBM-i-nahen Umgebungen.

4. Architektur des Beispielprojekts

Das Projekt ist klein und dadurch gut lesbar. Es folgt keinem modernen Framework-Ansatz, sondern einer klassischen Java-CLI-Struktur.

5. Datenfluss: SQL → ResultSet → XML → Zielformat

Der eigentliche Datenfluss ist simpel und genau deshalb gut erklärbar.

application.properties
        │
        ▼
JDBC-Verbindung zu Db2 for i
        │
        ▼
SQL SELECT ausführen
        │
        ▼
JDBC ResultSet
        │
        ▼
XML-Zwischenformat
        │
        ├── XSLT → HTML
        ├── XSLT → JSON
        ├── XSLT → JSONL
        ├── XSLT → CSV
        └── XSLT → Markdown

Der spannende Punkt ist das XML-Zwischenformat. Es enthält nicht nur Werte, sondern kann auch Metainformationen tragen, etwa Spaltennamen und JDBC-Typen. Dadurch wird das Ergebnis nicht nur „Textausgabe“, sondern eine strukturierte Zwischenrepräsentation.

<export>
  <data>
    <property path="CUSTOMER_NO" type="CHAR">
      <value>0004711001</value>
    </property>
    <property path="ORDER_TOTAL" type="DECIMAL">
      <value>1234.56</value>
    </property>
  </data>
</export>

6. Unterstützte Ausgabeformate

Das alte Projekt zeigt mehrere Zielformate. Genau das macht es als Beispiel interessant.

7. Konfiguration und Start

Das historische Projekt arbeitet mit einer einfachen Properties-Datei. Das ist für ein Beispiel angenehm greifbar.

driver=com.ibm.as400.access.AS400JDBCDriver
databaseUrl=jdbc:as400://YOUR_SYSTEM;translate binary=true
username=YOUR_USER
password=YOUR_PASSWORD

xsltpath=./xslt
exportpath=./export

query=SELECT * FROM YOUR_LIB.YOUR_TABLE
exportFormats=html,json,jsonl,csv,md

Der Build erfolgt klassisch mit Maven:

mvn clean package

Start unter Windows:

java -cp "zeus-access-400-1.0-SNAPSHOT.jar;jt400.jar" de.zeus.hermes.AppInitializer application.properties

Start unter Linux, Unix oder IBM i PASE:

java -cp "zeus-access-400-1.0-SNAPSHOT.jar:jt400.jar" de.zeus.hermes.AppInitializer application.properties

8. Warum das gerade auf IBM i interessant ist

IBM i ist nicht nur ein „altes System mit grüner Oberfläche“. Auf vielen Systemen liegen hochrelevante Geschäftsdaten direkt in Db2 for i. Gleichzeitig gibt es oft Bedarf, diese Daten für moderne Zwecke verfügbar zu machen:

• technische Dokumentation bestehender Tabellen und Views,
• regelmäßige Datenexporte für Fachbereiche,
• Vergleichsdaten für Modernisierungsprojekte,
• JSON- oder CSV-Dateien für externe Systeme,
• Markdown-Reports für Git-Repositories,
• HTML-Auswertungen für schnelle Sichtprüfungen.

Wichtig ist aber: Ein Export ist keine Modernisierung. Er kann eine Modernisierung vorbereiten, dokumentieren oder begleiten. Die eigentliche Architekturfrage bleibt: Welche Daten dürfen gelesen werden? Wer darf sie sehen? Wie werden sensible Felder behandelt? Wie wird die SQL-Selektion geprüft? Und wie wird sichergestellt, dass Ausgabeformate fachlich korrekt sind?

9. Grenzen des alten Ansatzes

Das Projekt ist bewusst klein und direkt gehalten. Genau das macht es als Lernbeispiel angenehm. Für produktionsnahe Nutzung fehlen aber einige Dinge, die man heute von einem sicheren IBM-i-Datenexport erwarten würde.

10. Wie man es heute robuster bauen würde

Würde man das Konzept heute neu bauen, wäre die Richtung klar: CLI-first, sicherer Standardmodus, nachvollziehbare Ausführung, deterministische Exporte und möglichst wenig Magie.

• Dry-run standardmäßig aktiv: Ohne explizites --execute wird keine Query ausgeführt.
• Read-only Guard: Nur lesende SQL-Statements erlauben.
• Secrets schützen: Keine Passwörter in Logs, Manifesten oder Shell-Historien.
• Konfigurationsreihenfolge dokumentieren: CLI vor Environment vor Config vor Defaults.
• Query-Quelle nachvollziehbar machen: CLI-Query, Query-Datei oder Properties-Wert eindeutig markieren.
• Run Manifest schreiben: Was wurde wann mit welchen Formaten erzeugt?
• Formate deterministisch ausgeben: Gleiche Eingabe, gleiche Ausgabe – wichtig für Tests und Diffs.
• Tests für IBM-i-Spezialitäten: CCSID, Dezimalwerte, Datum/Zeit, führende Nullen, Nullwerte.

11. Nachfolger: zeus-ibmi-extract-transform

Der moderne Nachfolger heißt zeus-ibmi-extract-transform. Dort wird die ursprüngliche Idee in eine robustere Richtung weitergeführt: read-only SQL-Extraktion aus Db2 for i, CLI-first, mehrere Ausgabeformate, Dry-run als Standard und ein vollständigeres Sicherheitsmodell.

Das Legacy-Projekt bleibt hier verlinkt, weil es die ursprüngliche Idee gut zeigt:
zeus-access-400 auf GitHub.
Für neue Entwicklung ist der Nachfolger die bessere Adresse:
zeus-ibmi-extract-transform auf GitHub.

12. Fazit

Der eigentliche Wert liegt nicht darin, den alten Code unverändert weiterzuverwenden. Spannend ist das Muster dahinter: Datenbeschaffung und Ausgabeformat werden voneinander getrennt. Dadurch kann eine SQL-Abfrage Grundlage für HTML, JSON, JSONL, CSV oder Markdown werden.

Für heutige IBM-i-Projekte würde man Sicherheit, Konfiguration, Secrets, Read-only-Guards, Logging und große Datenmengen deutlich strenger behandeln. Die Architekturidee bleibt trotzdem stark: Erst sauber extrahieren, dann kontrolliert transformieren.

Quellen