03.09.2012 „Best of Breed“ statt „Ganz oder gar nicht“

WebAPI und RDP

Von: Heidi Schmidt

Passgenaue Legacy-Anwendungen sind die tragende Säule für die Kernprozesse vieler Unternehmen. Weil ihre Entwicklung lange Jahre in Anspruch genommen hat, steht die fachliche Reife dieser Anwendungen jedoch häufig im krassen Widerspruch zur veraltet wirkenden 5250-Bedienoberfläche.

Während erfahrene Anwender häufig noch zufrieden sind und aus alter Gewohnheit quasi blind in die Tastatur klopfen, tun sich neue Mitarbeiter aus der „Generation iPhone“ sehr schwer, mit der Anwendung vertraut zu werden; an eine intuitive Bedienung ist selten zu denken.

Doch nicht nur für die Mitarbeiter stellt der Generationswechsel eine Herausforderung dar. Die immer komplexeren Geschäftsprozesse in allen Branchen fordern heute einen durchgängigen Workflow für alle Beteiligten, seien es Kunden, Geschäftspartner oder Lieferanten. Und die Prozesskette macht schon längst nicht mehr am Firmentor halt.

Eine effiziente und kostengünstige Umsetzung der zeichenorientierten Oberflächen von Bestandsanwendungen in eine echte Web-2.0-Oberfläche, etwa mit der Produktreihe PKS WebAPI, ist daher zwar Pflicht, aber noch lange keine Erfolg versprechende Strategie für die Zukunft der Greenscreen-Anwendungen.

Die Pflicht
PKS WebAPI setzt die WebAPI direkt in der RPG- oder Cobol-Programmsource auf und greift dort alle relevanten Informationen ab, z.B. Indikatoren, Funktionstasten, Datenpuffer, OP-Codes, Formatnamen und vieles mehr. Ein Display-Handler verarbeitet diese Daten in Kombination mit den Programminformationen und generiert das User-Interface inklusive der Unterstützung von Unicode-Formaten. Anhand von Regeln und Styles wird das User-Frontend dann für die Bildschirmdarstellung der verschiedenen Endgeräte und Webbrowser umgesetzt („gerendert“) und dem Anwender bereitgestellt.

Die Kür
So weit das Pflichtprogramm, nun zur Kür: Die Architektur von WebAPI bietet viel mehr als nur die Modernisierung der vorhandenen Oberfläche. Konkret sind das drei Ansätze unterschiedlicher Tiefe zur Integration von bestehender und neuer Anwendungslandschaft:

1. Einbindung verfügbarer Widgets mit direkter Verlinkung zu einem oder mehreren DDS-Feldern: Eine beliebte Art, vorhandene Bildschirme nach der initialen Umsetzung mit Zusatzinformationen zu versehen, ist die Einbindung gängiger Widgets (wie z.B. Google Maps). Hierfür sind lediglich ein paar Zeilen XML-Code nötig – und schon wird abhängig vom Masken-Content (z.B. Stadt) die Landkarte angezeigt.
2. Javascript Library zur „Tiefenintegration“ durch die dynamische Verlinkung der dargestellten DDS-Maske und der neuen Web-2.0-Komponente: Diese etwas tiefere Art der Web-2.0-Integration gehört zum Lieferumfang von WebAPI und enthält alle notwendigen Funktionen, um Daten und Feldinhalte aus dem Screen auszulesen, an eine Web-2.0-Komponente zu übergeben, dort verarbeiten zu lassen und Rückgabewerte in Empfang zu nehmen sowie im Programmsource weiterzuverarbeiten. Wichtigster Unterschied zur Variante 1: Hier wird kein Parameter an die aufrufende URL mit übergeben. Die Web-2.0 Komponente kann sich per Javascript Library die Informationen per Funktionsaufrufe auslesen und auch Werte bzw. Steuerungen an der bestehenden Maske vornehmen.
3. Web-2.0-Bridging, also der Aufruf einer Web-2.0-Seite direkt aus einem CL-, RPG- oder Cobol-Programm, das zum Beispiel mit Rational Developer for Power Systems (RDP) weiterentwickelt wird: Weil die beiden zuvor genannten Integrationen keine dauerhaft zufriedenstellende Lösung für alle Anforderungen in der Zukunft bilden, bietet die WebAPI auch einen intelligenten und performanten Bridging-Mechanismus. Damit lassen sich aus der WebAPI-Oberfläche über eine Call-Schnittstelle aus dem Programm heraus neue Web-2.0-Anwendungen aufrufen. Dabei kann die neue Anwendung im Vollbild oder im Applikations-Frame erscheinen und sich so, je nach Wunsch, mehr oder weniger nahtlos in die Bestandsanwendung einfügen.

Hervorzuheben ist, dass der Call auf das System i wartet, bis die aufgerufene Webseite beendet oder gezielt zurückgesprungen wird. Diese Vorgehensweise ist bei „Crossdomain Skripting“ voll transparent und bietet damit die höchste Flexiblität. Bei der Web-2.0-Entwicklung ist der Programmierer völlig frei in seiner Wahl; Dojo, jQuery und ExtJS werden von der WebAPI-Kundschaft aber bevorzugt.

Mit dieser Technologie gibt es keinerlei Fixierung auf eine proprietäre Entwicklungsoberfläche. Der Kunde ist frei in seiner Entscheidung, mit welchen Technologien künftig entwickelt werden soll. Dadurch ist ein wichtiges Entscheidungskriterium, nämlich die Unabhängigkeit von Herstellern, auch für die IBM-i-Entwicklergemeinde endlich realisiert.

www.pks.de

Bildquelle: iStockphoto.com/mrPliskin