Entdecken Sie neue Möglichkeiten, Ihre Anwendungen rasch und mühelos zu modernisieren

Die Leistung der Datenbank ausschöpfen

Wie bereits erwähnt, verfügen nur wenige IBM i Anwendungen über ein explizit defi niertes Datenmodell oder Datenbankschema. Viele Anwender mussten die Erfahrung machen, dass dies ein signifi kantes Hindernis für Entwicklungsinitiativen darstellt, die direkten Zugriff auf die Anwendungsdaten einsetzen. Nachfolgend beschreibe ich vier der Bereiche, die am offensichtlichsten von einem explizit defi nierten Datenmodell profi tieren.

Zum Thema Application Mapping auf IBM i sind erschienen: Robert Cancilla: Gegenwart und Zukunft

• Teil 1: Februar/März 2010
• Teil 2: April/Mai 2010
• Teil 3: Juni/Juli 2010

Robert Cancilla: Programme ändern Programme

• Teil 1: August/September 2010
• Teil 2: Oktober 2010

Robert Cancilla: Schätze in Legacy-Anwendungen fi nden

• Teil 1: Dezember 2010
• Teil 2: Januar 2011

Moderne Ein-/Ausgabemethoden in Programmen verwenden

Eines der Kernthemen von RPG ist der native Datenbankzugriff. Die prägnante und einfache Syntax dafür verschafft RPG-Entwicklungen signifi kante Produktivitätsvorteile gegenüber anderen Programmiersprachen. In modernen Programmiersprachen wie Java und C# werden Datenbankzugriffe allgemein mit eingebetteten SQL-Anweisungen abgewickelt. Für einfache Leseroutinen über eine einzelne Tabelle stellen solche SQL-Anweisungen die meisten Entwickler vor keine besonderen Probleme. Wenn Tabellen verknüpft werden müssen und Updates und Löschoperationen en, wird die Sache komplizierter. Der Entwickler muss das Datenmodell verstehen und Informationen über Foreigen-Key-Beziehungen haben, um die Join-Anweisungen in SQL richtig aufbauen zu können. Abbildung 10 zeigt das Entity-Relationship-Datenmodell einer RPG-Anwendung, was ein allgemein übliches Verfahren zum Visualisieren der Datenbankbeziehungen in einer Anwendung darstellt. Abbildung 11 zeigt ein Spreadsheet, das alle für die in Abbildung 10 dargestellten Beziehungen erforderlichen Foreign Keys aufl istet.

Ein explizit in DDL beschriebenes Anwendungs-Datenmodell kann direkt in Persistence Frameworks wie z.B. Hibernate (hibernate.org) oder NHibernate für .NET (hibernate.org/343.html) importiert werden. Mit diesen Open-Source-Tools für objekt-relationales Mapping (ORM) können Java- und C#-Entwickler auf Datenbankmodelle von DB2 for i zugreifen, ohne die Architektur der Datenbank oder JDBC- bzw. ODBCTechnologien genauer kennen zu müssen, was eine große Arbeitserleichterung bedeutet. DDL kann auch in alle populären Anwendungs-Modellier-Tools, wie z.B. Rational Software Modeler (www-01.ibm.com/software/awdtools/modeler/swmodeler/), Borland Together (borland.com/us/products/together/) oder Eclipse (eclipse.org) importiert werden. Auch Microsoft Visual Studio (microsoft.com/germany/visualstudio/products/default.mspx) ermöglicht den Import von DLL zum Erstellen eines Daten-Projekts.

Datenqualitäts-Analyse – Test der referentiellen Integrität

Es ist ganz selbstverständlich, dass über Jahre der Verwendung, Erweiterung, Anpassung und Fehlerkorrektur einer Anwendung ihre referentielle Integrität leidet. Das trifft vielleicht nicht auf Systeme zu, die RI in der Datenbank selbst implementieren, aber, wie bereits erwähnt, nutzen die wenigsten IBM i Anwendungen diese Möglichkeit. Mit dem explizit defi nierten Datenmodell der Datenbank für eine IBM i Anwendung können Datensätze programmgesteuert auf referentielle Integrität getestet werden, und man kann einen Bericht mit „verwaisten“ Datensätzen erstellen. Einfach ausgedrückt: Das Programm beginnt auf der untersten Ebene des hierarchischen Datenmodells – in anderen Worten: bei den Dateien, die keine Abhängigkeiten/“Children“ haben – und sucht nach korrespondierenden Sätzen in übergeordneten Dateien, indem es die Foreign Keys aus dem Datenmodell anwendet. Dieser Test wird nacheinander für alle Dateien der Anwendung durchgeführt.

Automatisierte Testdaten-Extraktion

Die Anforderung nach stimmigen und repräsentativen Testdaten ist so alt wie die Anwendungsentwicklung. Die meisten Unternehmen verwenden kopierte Produktionsdaten. Dieser Ansatz birgt einige Probleme: Die Testdaten müssen aktuell gehalten werden, und der Kopiervorgang beansprucht viel Zeit und Speicherplatz. Ein anderer Ansatz ist die Verwendung einfacher Kopieranweisungen auf Betriebssystem-Ebene. Dieser Ansatz kann gut funktionieren, ist aber immer noch arbeitsintensiv und fehlerträchtig. Ein anderer Ansatz, der immer populärer wird, besteht darin, bestimmte Master-Sätze aus den Produktivdaten auszuwählen und dann ein Programm zu erstellen, das mit Hilfe der Foreign Keys aus dem Datenmodell die abhängigen Daten kopiert. Dieses Verfahren stellt schnell kleine und aktuelle Testumgebungen mit garantierter RI zur Verfügung und wird häufi g von Software-Anbietern und Support- Dienstleistern eingesetzt, um mit realistischen Kundendaten Programmänderungen und -erweiterungen testen zu können.

Aufbauen von BI-Anwendungen und Data Warehouses

Der Anwendungsbereich „Business Intelligence“ (BI) hat in den letzten Jahren stetig an Bedeutung gewonnen. Durch immer effi zientere Auswertung der Anwendungsdaten hoffen viele Unternehmen, sich echte Wettbewerbsvorteile zu erarbeiten. Die dabei eingesetzte Technik ist zum größten Teil weder neu noch sehr kompliziert. Wichtigste Voraussetzung ist in jedem Fall, dass die Anwendungs-Datenbank genau definiert und detailliert beschrieben ist.

Diese Anforderung ist an sich kein großes Problem, aber wenn man bedenkt, dass so gut wie keine IBM i Anwendung über ein explizit definiertes Datenmodell verfügt, kann sie für IBM i Anwender eine echte Herausforderung darstellen. Wenn ein explizites und genaues Datenmodell der Legacy-Anwendungen zur Verfügung steht, können BI-Tools wesentlich produktiver eingesetzt werden und mehr und nachhaltigeren ROI bieten, auch wenn nur kleine Entwicklungs- und Support-Teams zur Verfügung stehen. Ein gutes Beispiel für diese Zusammenhänge ist IBM DB2 Web Query for i (www-03.ibm.com/systems/i/software/db2/webquery/). Als großartiges Tool und natürlicher Nachfolger von IBM Query/400 bietet es viele BI-Features.

Um die gebotene Funktionalität von DB2 Web Query voll ausnutzen zu können, muss das Metadaten-Repository mit der Beschreibung der Anwendungs- Datenbank versorgt werden. Ein vorhandenes, explizites Datenmodell bietet die benötigten Informationen und kann zum Erstellen eines Metadaten-Layers in DB2 Web Query genutzt werden. Abbildung 12 zeigt ein Beispiel für die Source- und Modell-Ansichten der Metadaten von IBM DB2 Web Query. Das Modell zeigt, wie eine Datei mit anderen Dateien in der Datenbank verknüpft wird. Die gezeigten Metadaten wurden automatisch aus dem expliziten Datenmodell einer IBM i DB2-Datenbank erstellt.

Risiken minimieren und ROI maximieren

Weltweit kämpfen IT-Abteilungen damit, den täglichen Support und neue User-Anforderungen zu bewältigen – oft unter strengen personellen und fi nanziellen Einschränkungen. Immer höhere Anforderungen an Compliance und andere Regulatorien haben im Lauf der letzten 10 Jahre dafür gesorgt, dass vielerorts „Schnellschüsse“ viel zu riskant wurden, um sie überhaupt in Erwägung zu ziehen. Um unter dieser ungünstigen Ausgangslage voranzukommen, ist es sinnvoll, bei Neuentwicklungen auf die bewährte Business-Logik vorhandener Anwendungen zurückzugreifen.

Wenn es Ihnen gelingt, Business- Logik und Datenmodell zu extrahieren, eröffnet sich eine Welt mit neuen Möglichkeiten. Viele Risiken und Unsicherheiten entfallen bei potentiellen Projekten, weil Sie wissen, was Ihr System wirklich tut, und nicht nur, was andere glauben, dass es tut, oder was eine veraltete Dokumentation beschreibt.

Wenn das Extrahieren der Business- Logik und des Datenmodells automatisiert werden kann, werden viele Projekte auch mit limitierten Ressourcen machbar. Das reicht von schnellen Lösungen, wie z.B. dem Zugriff auf eine Auftragsübersicht als Webservice, den Kunden in ihre eigenen Anwendungen integrieren können, bis zu umfangreichen, langfristigen Projekten, wie vollständigen ERP-Systemen oder anderen großen Anwendungen. Wiedergewonnene Business-Regeln können in Prozess- Management-Systemen wie JBoss Drools oder in Workfl ow-Systemen eingesetzt werden. Automatisch extrahierte Business-Logik und Datenmodelle sind aber auch bei kleineren Entwicklungen hilfreich, wie z.B. beim Verwenden der Regeln und Prozesse eines CRM-Systems in einer neuen Java-basierten Web-Anwendung – mit der beruhigenden Gewissheit, dass die in der Anwendung defi nierten Prozesse praxisgerecht und bewährt sind, und dass Risiko und Aufwand der Neuentwicklung entsprechend gering sind.

Genau dieselben Vorteile lassen sich aber auch in Großprojekten nutzen, weil man diese Schritt für Schritt in handhabbare Teilstücke aufteilen kann und aus der vorhandenen Business-Logik und dem Datenmodell schnell funktionierende Prototypen entwickeln kann: Es ist nicht nötig, Entwicklungsarbeit im luftleeren Raum, ohne User-Feedback, zu leisten.

Der nächste Artikel

in unserer Reihe geht genauer auf Anwendungsentwurf und erneuerung ein, wie sie auf der Grundlage der extrahierten Logik möglich werden. Schließlich soll es bei der Anwendungsmodernisierung mehr um den großen Entwurf und nicht so sehr um Code-Philosophie gehen.

Vergleichen Sie das Vertrauen in zwei IT-Manager aus der Compliance- oder Audit-Perspektive:

Einer hat ein System zur automatisierten Erstellung von Business- Regeln und Datenmodellen verwendet, um vorhandene Systeme wiederverwenden oder nachbilden zu können, während der andere einen konventionellen Ansatz zum manuellen Entwerfen und Erstellen von neuen Funktionalitäten einsetzt, die das vorhandene System ersetzen sollen, und dabei nur auf Benutzeranforderungen, Dokumentation und Source Code des existierenden Systems zurückgreift. Der erste IT-Manager hat einen überprüfbaren und wiederholbaren Prozess zum Erstellen von Regeln und neuen Systemen. Der andere IT-Manager ist ausschließlich auf das Können und die Erfahrung des Entwicklungsteams angewiesen, und darauf, wie dieses Team die Ausrichtung und die Besonderheiten des existierenden Systems interpretiert.

Autor Robert Cancilla

(rcancill (ät) mac.com) arbeitete die letzten vier Jahre als Market Manager für IBMs Rational Enterprise Modernization tools and compilers group for IBM i. Davor was Robert Cancilla 34 Jahre lang ITManager für drei große Versicherungsgesellschaften und für einen Anbieter von Versicherungs-Software. Er schrieb vier Bücher über E-Business für AS/400 und IBM i und gründete die User Group IGNITe/400. Robert Cancilla ist jetzt im Ruhestand und noch zeitweise als unabhängiger Berater tätig.

Übersetzt und für den deutschsprachigen Markt überarbeitet von Mathias Spateneder.