RPG-Programme für alle Plattformen: RPG wird plattformunabhängig

Software-Häuser suchen nach Möglichkeiten, ihre bestehenden Anwendungen auf andere Plattformen zu portieren, da sie vom Markt unter Druck geraten. iSeries-Anwender wünschen sich eine bessere Integration ihrer Programme auf Windows und direkten Zugriff auf Datenbanken wie SQL-Server, Access und Oracle. Wie sich das alles in ASNA VisualRPG.NET umsetzen lässt, zeigt dieser Artikel.

Die Evolution geht weiter

Totgesagte leben bekanntlich länger. Auch für RPG trifft diese Regel zu. Obwohl es sich bei VisualRPG.NET nicht um eine Weiterentwicklung von IBM, sondern von ASNA handelt, wird VisualRPG.NET von IBM auf der iSeries-Roadmap als Produkt empfohlen. Mit diesem RPG-Compiler und dem Migrations-Tool MONARCH können iSeries-Programme auf DotNet arbeiten. Dieses Thema hat viele interessante Aspekte, wir widmen uns in diesem Artikel der Plattformunabhänigkeit. In unserem kleinen Beispielprogramm geht es um eine Adresstabelle, die auf vier Datenbanken liegt, auf die wir aus unserem RPG-Programm zugreifen. Es geht um die Datenbanken:

1. DB2/iSeries
2. Microsoft SQL-Server
3. Acceler8DB von ASNA
4. Microsoft ACCESS

Dem Datenzugriff unter DotNet liegt das Konzept der ManagedProvider zu Grunde. Es handelt sich dabei um Datenbank-Driver, die in DotNet eingebettet sind und die die Datenbank optimal betreiben, da sie speziell für eine Datenbank geschrieben wurden. In DotNet kann man beliebig viele ManagedProvider integrieren, daher ist man für alle Plattformen offen und hochperformant, da sich um jede Datenbank sozusagen ein „Spezialist“ kümmert. Auch für den für RPG-typischen Zugriff auf Satzebene kümmert sich ein Spezialist – nämlich: DataGate. DataGate gibt es für die iSeries, den SQL-Server und die Acceler8-DB von ASNA.

Abbildung 1: Funktionsweise von ASNA VisualRPG.Net in Verbindung mit DataGate für IBM iSeries

Also kann aus einem RPG-Programm auf Satzebene auf diese drei Datenbanken zugegriffen werden, ohne dafür eigens Code zu schreiben. Auf die Access-Datenbank greifen wir über den ManagedProvider zu. Dazu schreiben wir eine Routine mit Embedded-SQL. Um das Thema spannend zu machen, greifen wir alternativ auf Access so zu, dass die Logik des Programms gar nicht mitbekommt, dass es sich nicht um eine iSeries-Datenbank handelt, auf der die Daten liegen.

So sieht das Programm aus: Es hat 5 Buttons, von denen jeder einen Datenzugriff auf „seine“ Datenbank ausführt.

Der Name „SQL-Chain-Access“ schreit regelrecht nach Verbesserungsvorschlägen, diese bitte senden an: c.neissl@niceware.at

Tabelle der Buttons und Funktionen

Der Sinn, einen Zugriff auf die Datenbank zu implementieren, liegt darin, dass es für die übergeordnete Logik keinen Unterschied macht, welche Datenbank darunterliegt. Da wird schon deutlicher, wo die Reise hingeht. Wir wollen Software auf den Markt bringen, aber heute akzeptiert kaum mehr ein Unternehmen, dass die Software von der Hardware abhängig ist. Größere Unternehmen sind da offener, aber wir wollen unsere Software auch kleineren Unternehmen verkaufen, die bereits Server-Systeme einsetzen und nicht bereit sind, dafür extra Hardware anzuschaffen und zu betreuen.

Und so funktioniert es mit RPG

Chain wird in einer einzigen Routine ausgeführt. Diese Routine wird an die Datenbank-Verbindung übergeben, eröffnet dann die Datei und liest mit CHAIN die Daten ein:

Chain Customer_num Key( kyCMCustNo ) Err(*extended)if %found()// Anzeigefelder aus Datenfelder füllenExSR FillFromFields stb.Text = „Chain auf “ + DBName.DBName.ToString() + „…“
Endif

Diese Funktion wird aus den obersten 3 Buttons aufgerufen, jeweils mit der eigenen Datenbank-Verbindung die im Programm deklariert wird:

DclDB iSeriesDB DBName( „ATNICE“ )
DclDB ProdDB DBName( „DG NET Local“ )
DclDB SQLDB DBName( „ASNA SQL DB“ )

Und so sehen die Aufrufe für CHAIN aus:

// aus iSeries lesen
ChainiSeries(txtCMCustNo.text, iSeriesDB)
…
// aus lokaler DB lesen
ChainiSeries(txtCMCustNo.text, ProdDB)
…
// aus SQL-Server lesen
ChainiSeries(txtCMCustNo.text, SQLDB)

Der Zugriff auf Access erfolgt über Embedded-SQL, das heißt in DotNet – ADO-DotNet.

daConn = *new OleDbDataAdapter( + „SELECT * FROM CustMastNew WHERE CMCustNo = “ + %trim(KundenNR) + „;“, dbConn ) daConn.Fill(dsRead, „CustMastNew“)
Und nun werden einfach die Datenfelder der iSeries mit dem Rückgabewert des SQL befüllt.

Simpel und doch einmalig

Was sollte man sonst mit den Datenfeldern machen, was ist da so ‚großartig’? Bei genauerem Hinsehen wird man feststellen, dass dieses RPG-Programm auch unabhängig von der iSeries laufen kann. Wie kommt es dann zu iSeries-Datenfeldern; wieso sind die in einem Programm, das auf der Datenbank Access, MySQL, ORACLE etc. läuft, vorhanden? Der Clou ist, dass der Compiler zur Umwandlungszeit die Datenfelder im Programm bereitstellt. Wie damit zur Laufzeit umgegangen wird und woher sie befüllt werden, ist eine andere Geschichte. Diese Funktion kann dazu benutzt werden, RPG-Programme mit der iSeries zu entwickeln und auch ohne iSeries und DataGate mit einer alternativen Datenbank zu betreiben.

Alle die das probieren möchten, können unter meiner e-Mail-Adresse c.neissl@niceware.at ein komplettes Paket mit VisualStudio, VisualRPG.NET und 200 Seiten Leitfaden in deutscher Sprache gratis bestellen. Ich freue mich auf die Diskussionen.

Fachautor: Christian Neißl