Evolution statt Revolution: Von ADABAS C auf Oracle

KONFERENZ
Mittwoch, 10. November 2004
13h00, Variohalle 2
Evolution statt Revolution:
Von ADABAS C auf Oracle migrieren
Mathias Jacobi
PKS Software GmbH, Ravensburg
Schlüsselworte:
Adabas, Oracle, Migration, Re-Engineering, Datenbanken, Gateway, Testkonzept
Zusammenfassung
Der Konsolidierungs- und Modernisierungsdruck in der IT wächst. Betroffen
sind auch bewährte und unternehmenskritische Anwendungen die auf
ADABAS C basieren. Mit einem "Transparency-Gateway" lässt sich der "noninvasive Migrationsansatz" verwirklichen: Ohne Änderungen am Source-Code
können ADABAS C basierende Anwendungen auf Oracle betrieben werden. Auf
Datenebene können Anwendungen im Unternehmen damit interagieren, Wartungs- und Produktionskosten werden gesenkt, der Lebenszyklus von LegacyAnwendungen wird nachhaltig verlängert wie auch die parallele Neuentwicklung von einzelnen Funktionsbausteinen auf der Basis bestehender Daten risikoärmer wird. Bereits mehrere Unternehmen sind diesen Weg gegangen.
Anhand einzelner Projektschritte wird gezeigt, wie Anwendungen von ADABAS
C auf Oracle migriert werden können, welche Analyse-Schritte vorab notwendig sind, welche Überlegungen im Hinblick auf die Normalisierung anzustellen
sind, wie eine gleichbleibende Performance sicher gestellt wird und wie vor
allem die Testaufwände gering gehalten werden können.
Einleitung
Über Jahre hinweg haben Unternehmen und Organisationen ihre unternehmenskritischen Anwendungen erfolgreich mit ADABAS C, mit Natural und
Cobol, mit PL/I und Assembler implementiert und mit hoher Performance
betrieben. Sie abzulösen oder zu modernisieren ist ein komplexes Unterfangen
und will gut überlegt sein. Doch der Konsolidierungs- und Modernisierungsdruck in der IT-Branche steigt. Damit die über Jahre gewachsenen, fortwährend
getesteten und stabilen, auf ADABAS C basierenden Anwendungen den neuen
internen wie externen Anforderungen besser begegnen können, ist vor allem
der Weg der Migration ein äußerst attraktiver Weg. Er verspricht, zwei Fliegen
mit einer Klappe zu schlagen: Bewährtes und Bestehendes zu schützen und
dennoch auf veränderte Rahmenbedingungen anzupassen.
17. Deutsche ORACLE-Anwenderkonferenz
Migrations-Treiber
In den meisten Fällen lassen sich drei – zum Teil sich überlappende – Erwartungshaltungen ausmachen die letztlich zu der Entscheidung für eine Migration führen:
• Reduktion von Komplexität,
• Senkung von Betriebskosten und
• Anwendungsmodernisierung und Zukunftssicherung.
Technische Komplexität reduzieren
Betriebskosten senken
Auch hohe Wartungs- und Betriebskosten spielen häufig eine Rolle. Zwei unterschiedliche Datenbanken im Unternehmen belasten doppelt – auch finanziell.
Es fallen zweifach Wartungsgebühren an – im Mainframe-Umfeld sind dabei
besonders Upgrades auf eine höhere Hardwareklasse finanziell besonders
schmerzlich – und es muss zweifach ganz unterschiedlich qualifiziertes Systempersonal vorgehalten werden.
Anwendungen modernisieren und Zukunft sichern
Zu einer Migration kommt es typischerweise auch dann, wenn etwa die technische Plattform (Hardware, Systemsoftware, Entwicklungswerkzeuge) nicht
mehr unterstützt wird oder auf lange Sicht als unsicher betrachtet werden
muss. Bei Wechseln auf kostengünstigere Plattformen – etwa vom Mainframe
zu Open-Systems Plattformen – werden ggf. auch nicht mehr alle bislang eingesetzten Systemkomponenten unterstützt (z.B. ADABAS SQL, Predict CASE).
Doch auch der schrittweise Umstieg von einer Legacy-Anwendung auf eine neu
zu entwickelnde Applikation lässt sich durch eine vorherige Migration auf die
Zielumgebung wirkungsvoll absichern. Die bestehende Anwendung kann auf
der Basis einer neuen Technologie weiter betrieben und die neue Anwendung
parallel dazu entwickelt werden. Teilen sich beide Anwendungen die Daten,
lassen sich einzelne Geschäftsprozesse ohne Risiko und zeitlichen Druck auf
evolutionärem Wege von der Anwendung A auf die Anwendung B überführen.
Das Schreckgespenst der "Big-Bang-Ablösung" wird den so geschaffenen Burggraben nicht überschreiten können.
IT Experience
Die Integration von Anwendungen leistet für den Erfolg von Unternehmen
einen entscheidenden Beitrag – unabhängig davon, ob Anwendungen innerhalb des Unternehmens verbunden, Daten über das Internet für die Kunden
bereitgestellt oder Informationen mit Geschäftspartnern ausgetauscht werden
sollen. Gerade in Unternehmen mit heterogenen Anwendungslandschaften
werden enorme Anstrengungen für die mühevolle, zeitträchtige und fehleranfällige Integration von im Unternehmen verstreuten Datenbeständen aufgewendet. Mit einer einheitlichen Datenbank im Unternehmen lässt sich die
Integration auf Datenebene einfach und schnell umsetzen.
KONFERENZ
In der Kombination dieser Motivationen wird der Änderungsdruck in vielen
Fällen so groß, dass die Überlegungen für die Ablösung, den Austausch oder der
Migration einer Anwendung nunmehr konkreter und dichter werden. Für eine
erste Entscheidung sind der Softwaretyp (Individual- oder Standard-Software)
sowie die Qualität und Komplexität der Software (Niedrig oder Hoch) zu
berücksichtigen.
Abb. 1: Entscheidungsmatrix Migration
Für Individualanwendungen von hoher Komplexität und Güte sind auf alle
Fälle Wert erhaltende Maßnahmen zu prüfen. In diesen Applikationen stecke
immense Investitionen, nicht selten mehrere hundert Entwicklungsjahre. Die
Nutzungsdauer solcher Anwendungen kann mit einer Migration auf eine standardisierte, zukunftsfähige und preisgünstige Plattform erheblich verlängert
und damit betriebswirtschaftlicher Vorteil erzielt werden. Unter diesen
Umständen ist die Migration der Königsweg. Ganz nebenbei bleibt auch die
Akzeptanz und Effizienz beim Anwender unverändert hoch und wird nicht
gefährdet.
Technische Migrationswege
Im Rahmen von technischen Migrationen – also Änderungen der Systemumgebung – sind grundsätzlich zwei Vorgehensweisen zu unterscheiden:
• Migrationen mit Änderung des Source-Codes und
• Migrationen ohne Änderung am Source-Code.
Im Falle einer Migration von ADABAS C Anwendungen auf Oracle würde bei
einer Migration auf der Basis von Manipulationen im Source-Code jedes
Zugriffsstatement durch generierte SQL-Statements ersetzt. Dieses Vorgehen
zieht erhebliche Nachteile nach sich. Gerade große, stetig gewachsene Applikationen sind nach einer Migration dieser Art nicht mehr überschaubar und
nicht mehr wartbar. Im Source-Code der Anwendung finden sich im Anschluß
Hunderte bis Tausende von hoch komplexen SQL-Statements. Alle Update,
Read, Find, Histogram, Store, Delete und Transaktions-Anweisungen werden
17. Deutsche ORACLE-Anwenderkonferenz
Im Gegensatz dazu steht der Ansatz der sog. "Transparency-Gateways". Dieser
Migrationsansatz wird von dem Grundgedanken getragen, dass der SourceCode als "heilige Kuh" anzusehen ist, er darf in keinem Fall verändert werden.
Ausgehend von dem Quell- und dem Zielsystem wird ein "Abstraction-Layer"
unterhalb der Anwendung bzw. der Anwendungen aufgebaut der jedwede
Kommunikation mit der Quelldatenbank abfängt und auf das Zielsystem leitet.
Etwaig notwendige Umsetzungsregeln – das Mapping – werden in einem internen Repository abgelegt und zur Laufzeit interpretiert. Die Vorteile eines solchen Vorgehens liegen auf der Hand:
• Keine Änderung am Source-Code
Für die Anwendung bleibt die neue Datenhaltung völlig transparent
• Vollständig Sprachneutral
Für Anwendungen, die in mehreren Sprachen codiert wurden, sind keine
unterschiedlichen Parser, Generatoren oder Vorgehenskonzepte notwendig.
Gerade im ADABAS Umfeld trifft man häufig auf Anwendungen deren Dialogteile vollständig in Natural implementiert sind, die Batch-Teile hingegen
sich der Technik der ADABAS Direct-Calls z.B. aus COBOL oder PL/I bedienen
• Geringe(re) Testaufwände
Da der Source-Code unverändert bleibt und lediglich eine Zugrifsschicht auf
Systemebene neu implementiert und konfiguriert wurde, ist ausschliesslich
der Nachweis der Kongruenz der Ergebnisse von Abfragen und Transaktionen
nachzuweisen, die Geschäftsprozess-Logik muss nicht getestet werden.
IT Experience
durch z.T. seitenlange SQL-Statements ersetzt. Im Falle eines Fehlers gleicht die
Suche nach der Ursache der Suche nach der viel zitierten "Nadel im Heuhaufen". Ein darüber hinaus etwaig notwendiges Performance-Tuning der Applikation wird direkt im Source-Code und meist auch an beliebig vielen Stellen der
Anwendungssourcen – zum Teil redundant – durchgeführt. Dies gilt umso
mehr, als viele Anwendungen die heute übliche Kapselung der Datenzugriffe
und ihrer Trennung von der Geschäftslogik nicht implementiert haben. Damit
wird dann auch das gewichtigste Argument gegen die Entscheidung für eine
Migration mit Änderung des Source-Codes aufgeworfen: Die solcherart generierten Testaufwände sind immens. Es werden durch die mannigfachen Eingriffe in das Coding umfangreiche Tests notwendig, die neben den Datenzugriffen die abgebildeten Geschäftsprozesse vollständig auf Logik, Funktionalität
und Integrität überprüfen müssen. Im Bereich der unternehmenskritischen
Anwendungen sind die so generierten Testaufwände nicht mehr tragbar, sie
würden in Einzelfällen nahezu 50 % der Erst-Entwicklung des Legacy-Systems
ausmachen. Von den Kosten und Risiken kaum noch beherrschbar wird die
Migration von ADABAS C Anwendungen, die neben Natural-Code noch weitere Programmiersprachen wie COBOL, PL/I oder Assembler umfassen.
KONFERENZ
• Problemsuche wie auch Performance-Tuning ausschliesslich in der Middleware
Statt in Hunderten oder gar Tausenden von Modulen nach eventuellen Auffälligkeiten zu suchen kann dies auf die Middleware beschränkt werden.
Abb. 2: Umstellungskosten für unterschiedliche Migrationsansätze differenziert nach Anwendungsgröße
Bei einer Umstellung der Datenbank ist ein Verfahren, welches den Quellcode
unberührt lässt (non-invasive Strategie), also um Potenzen sicherer und günstiger als ein Verfahren, das die Applikation modifiziert.
SmartDCI – das Transparency-Gateway für ADABAS und Oracle
Eine ADABAS C basierende Anwendung kommuniziert mit der Datenbank ausnahmslos über das Direct-Call-Interface, den sog. ADALNK. Das gilt für alle
Anwendungen mit Zugriff auf ADABAS C – unabhängig von der verwendeten
Programmiersprache. Auch Natural verwendet dieses Linkmodul. Alle in Natural verwendeten Zugriffs- und Transaktions-Statements kommen auf der Datenbank-Schnittstelle als Direct-Calls an und werden von ADABAS abgearbeitet.
Aus dem Coding des Natural werden automatisch die entsprechenden Buffer
(Control-Block, Format-Buffer, Record-Buffer, Search-Buffer, Value-Buffer und
ISN-Buffer) für die Kommunikation mit der Datenbank aufgebaut und an den
ADALNK weiter geleitet. Auf dieser Ebene kommt das ursprünglich codierte
READ-Statement beispielsweise als Command-Code "L3" (Byte 3 und 4 des
80 Byte großen ADABAS Control-Blocks) daher, der DELETE erscheint als "E1",
das Update-Statement wird durch den "A1" identifiziert. In anderen Programmiersprachen muß die Datenbank-Schnittstelle des ADABAS direkt (d.h.:
manuell) bedient werden. Dann sind die Buffer und der Control-Block vom
Entwickler aufzubauen und in einem Call an ADABAS zu richten. Die Datenbank arbeitet basierend auf dem Control-Block und der zugehörigen Buffer den
Request ab, füllt die Ergebnisse im Control-Block (z.B. Return-Code, ISN Quantity etc.) und den Buffern und sendet sie an die Applikation zurück.
17. Deutsche ORACLE-Anwenderkonferenz
Da jede Anwendung ausschliesslich auf diesem Wege mit ADABAS C kommuniziert, kann ein Transparency-Gateway risikolos eingesetzt werden, es wird
lediglich die Schnittstelle zum ADABAS durch ein anderes Datenbank-Kommunikations-Modul ersetzt. Die neue Schnittstelle zu Datenbank, SmartDCI®,
übernimmt dann alle Datenbankzugriffe und übersetzt sie zur Laufzeit in korrespondierende SQL-Befehle. Die ADABAS-Spezifika (Multiple Felder, Periodengruppen, Nullwertunterdrückung, Super- und Subdeskriptoren etc.) werden
dabei berücksichtigt und auf die relationale Welt übertragen. Das DatenbakGateway besitzt also "nach oben" die gleiche Schnittstelle wie die Anwendungen sie erwarten, "nach unten" aber arbeitet es mit der Oracle-Datenbank
zusammen.
Abb. 4: Anwendungs-Kommunikation mit Oracle via SmartDCI
Für den Migrationsprozess selbst und eine eventuelle Parallebetrieb-Phase in
Produktion können beide Datenbanken auch im Dual-Modus betrieben werden: Anhand der Kombination aus Datenbank-ID und File-Nummer werden
die Requests der Anwendung entweder auf die eine oder die andere Datenbank
oder gegen beide Datenbanken gesendet.
IT Experience
Abb. 3: Anwendungs-Kommunikation mit Adabas am Beispiel COBOL und Natural
KONFERENZ
Abb. 5: Parallelbetrieb gegen ADABAS und Oracle
Die interne Architektur
Die an ADABAS gerichteten Requests der Applikationen werden zunächst auf
ihre Anforderung überprüft und in die entsprechende Aktionskategorie eingeordnet (modifizierend, lesend oder transaktionssteuernd). Das passende und
optimierte SQL-Statement wird generiert, geparsed, gebunden und an die
Oracle-Datenbank übergeben. Gegebenenfalls werden auch entsprechende
Optimizier-Hints (meist vom Typ Index) verwendet. Sollte das Statement während der aktiven Datenbank-Session bereits verwendet worden sein wird es
ohne Parsing und Binding direkt an die Datenbank weiter geleitet: Das selbe
Statement wird nie zweimal generiert. Durch die Nutzung des Oracle-CallInterfaces kann im Vergleich zu einer ODBC-Implementierung ein optimiertes
und hoch-performantes Statement aufgebaut und ausgeführt werden. Die
Übersetzung der Daten und ihrer Formate zur Laufzeit wird über das interne
Repository gesteuert.
Das Repository
Das Repository wird zum Start geladen und ständig im Speicher gehalten. Hier
sind die Definition der Umsetzungsregeln ("Mapping") abgelegt: Das Repository beschreibt die Abbildung des ADABAS-Datenbank-Modells auf das relationale Modell von Oracle und sorgt so für die entsprechenden Grundlagen.
Jedem einzelnen Feld aus dem physischen ADABAS-Modell (FDT) wird eine
Spalte in der korrespondierenden Tabelle zugeordnet. Dabei werden üblicherweise alphanumerische ADABAS-Felder auf VARCHAR2 gemapped, PACKED
und UNPACKED-Felder auf NUMBER. Auch die ADABAS interne Satznummer
– die ISN – wird in den resultierenden relationalen Tabellen mitgeführt.
Deskriptoren der ADABAS-File werden als Index angelegt, Superdeskriptoren
üblicherweise als Function Based Index. Der Repository-Generator erledigt den
Großteil dieser Aufgaben automatisch. Zunächst werden die FDTs der betroffenen ADABAS-Files – um Angaben aus den korrespondierenden DDMs ergänzt –
17. Deutsche ORACLE-Anwenderkonferenz
Abb.6: Mapping zwischen FDT und Oracle im Überblick
Ein typisches Migrationsprojekt
Analyse
Jedes Migrations-Projekt hat seine eigenen Tücken und Besonderheiten, so wie
jede Applikation ihre eigenen Spezifika aufweist. Daher steht am Anfang eines
jeden Migrationsprojektes eine genaue Analyse. Vor der eigentlichen Umstellung sind Architektur und Muster der Anwendung detailliert zu betrachten, das
zugrunde liegende Datenbank-Modell zu untersuchen und die implementierten Zugriffswege exakt zu analysieren. Für eine ADABAS/Natural-Applikation
stehen dafür drei unterschiedliche Quellen zur Verfügung.
FDT-Analyse
Die Analyse der FDTs der ADABAS-Datenbank gibt bereits erste Hinweise auf
die Komplexität der Migration. Besonders betrachtet werden die aus Performance-Gründen relevanten Multiplen Felder und Periodengruppen. Aber auch
die Anzahl, Verwendung und der Aufbau von Deskriptoren und Superdeskriptoren läßt Rückschhlüsse auf die Applikation, die wichtigsten Files und ihre
überwiegende Verwendung zu.
IT Experience
eingelesen, woraufhin dann das Standard-Mapping für alle Felder generiert
wird. Multiple Felder und Periodengruppen werden dabei besonders behandelt,
für sie werden als Default-Regel eigene Tabellen aufgebaut die mit der MasterTabelle über die ISNs verknüpft sind.
KONFERENZ
Abb. 7: Übersicht FDT-Analyseergebnis
In der Analyse des ADABAS Datenbankschemas ist unschwer zu erkennen, dass
die Files 4 und 17 mit ihrer überaus hohen Anzahl an Multiplen Feldern und
Periodengruppen wie auch Multipler Felder in Periodengruppen besonders
betrachtet werden müssen. Auf beiden Files liegt überdies ein phonetischer
Deskriptor. Es handelt sich jedoch in beiden Fällen um Predict-Systemfiles die
in dem Projekt nicht mit migriert werden mussten.
Die hier betrachtete Applikation umfasste 214 Files, für die insgesamt 2.422
Deskriptoren angelegt worden waren. Die meisten Periodengruppen fanden
sich in der File 245 (13 Stück). Für den weiteren Projektverlauf stand fest, dass
die File 245 im Projektverlauf immer wieder auf Performance und Zugriffe überprüft werden musste. Aber auch die Verteilung der Datensätze auf einzelne Files
lässt Rückschlüsse auf ihre (Schreib-)Bedeutung zu und ist ein wichtiger
Anhaltspunkt für etwaig notwendige Performance-Maßnahmen.
Source-Code-Analyse
Mit der Source-Code-Analyse wird die vollständige Applikation – in diesem Fall
Natural – auf ihre Datenbank-Statements untersucht. Alle relevanten CodingStellen werden identifiziert und nach unterschiedlichen Kriterien zusammen
gestellt.
17. Deutsche ORACLE-Anwenderkonferenz
Über die Ergebnisse der Natural-Analyse lassen sich performance-kritische
Code-Strecken identifizieren; dabei interessiert besonders, auf welche Files
diese ggf. weniger performanten Statements abgesetzt werden. Aber auch
"Sünden" in der Entwicklung von ADABAS-Anwendungen werden dabei sehr
schnell aufgedeckt, hier: die relativ häufige Verwendung von FIND … SORTED
BY – Statements und die Verwendung des Ungleichheits-Operators bei Leseanfragen.
CLOG-Analyse
Der wichtigste Analyseteil mit dem höchsten Informationsgehalt ist die Analyse der Command-Logs. ADABAS bietet die Möglichkeit, alle an die Datenbank
abgesetzten Anfragen und Rückgaben zu protokollieren, das sog. CLOG. Als
Analysequelle ist das CLOG von unschätzbarem Wert: Jeder Zugriff jeder Applikationsquelle wird aufgezeichnet. Mit einem Werkzeug zur Aufbereitung der so
gewonnen Daten lassen sich schnell die am häufigsten benutzten Files, die
häufigsten Befehle auf Datenbank-Ebene und ihre Verteilung aufdecken. Das
CLOG bietet damit gleichsam die Datenbank-Sicht auf die Anwendung. Wenn
der zu protokollierende Zeitraum gut und repräsentativ gewählt ist lassen sich
damit alle für den Start eines Migrationsprojektes erforderlichen Informationen generieren. Häufig ist es daher notwendig, mit unterschiedlichen CLOGs
aus mehreren Phasen der Produktion (oder der der Testumgebung) zu arbeiten;
nicht immer kann z.B. ein Monats- oder gar ein Jahresabschluss laufen. Doch
natürlich sind gerade diese verarbeitungsintensiven Anwendungsteile für eine
detaillierte und valide Analyse unverzichtbar.
IT Experience
Abb. 8: Übersicht Natural-Analyse – lesende Zugriffe
KONFERENZ
Abb. 9: Übersicht CLOG-Analyse – CommandView
Neben der Betrachtung der Calls, ihrer Verteilung und die Schreib-/LeseHäufigkeit auf einzelne Files sind auch Betrachtungen von Lese-Sequenzen,
Deskriptoren-Verwendung, ISN-Verarbeitung, Format-Buffern für modifizierende und lesende Zugriffe etc. von Bedeutung. All diese Informationen geben
wertvolle Hinweise auf das anzustrebende Daten-Design und auf die anwendungsspezifischen Anforderungen an das Gateway. Weit in die Produktion hinein reichende Design-Entscheidungen für ein konkretes Datenmodell können
nur auf der Basis einer solchen umfangreichen Analyse getroffen werden.
Design
In der Design-Phase steht das Mapping der Daten im Vordergrund. Ausgehend
vom ADABAS Datenmodell wird gemeinsam nach dem besten Datenmodell
auf relationaler Basis gesucht. Dabei spielen neben der reinen Funktionalität
auch Performance-Erwägungen eine erhebliche Rolle. In der Design-Phase
werden grundlegende Entscheidungen nicht nur über die Datentypen und ihr
Mapping getroffen sondern auch Normalisierungsstrategien für die ADABAS
Periodengruppen und Multiplen Felder gewählt.
In Periodengruppen und Multiplen Feldern werden in ADABAS-Files Wiederholstrukturen aufgebaut, für die Inhalte in jedem einzelnen Datensatz gespeichert werden. Periodengruppen und Multiple Felder führen zu einer zweiten
Dimension innerhalb eines Satzes, mit Multiplen Feldern in Periodengruppen
wird gar die dritte Dimension eröffnet. Für die Abbildung dieser ADABAS-Spezialfelder auf einer relationalen Datenbank sind spezielle Maßnahmen erforderlich – auch und insbesondere im Hinblick auf die angestrebte Performance.
Dazu stehen für Oracle drei unterschiedliche Modelle zur Verfügung:
• Schematyp "Normalisiert"
• Schematyp "Verdichtet" und
• Schematyp "Objekt".
17. Deutsche ORACLE-Anwenderkonferenz
Die grundsätzlich favorisierte Normalisierungsstrategie mündet in die VollNormalisierung mit dem Schematyp "Normalisiert". MU/PE-Felder werden als
Detail-Tabelle in einer Master-Detail Beziehung abgebildet. Für jede Ausprägung einer Periodengruppe wird ein eigener Record in einer Detail-Tabelle
angelegt der mit der Master-Tabelle über die ISN verknüpft wird. Bei drei Ausprägungen innerhalb einer Periodengruppe oder eines Multiplen Feldes ergeben sich also drei Datensätze in der abhängigen Tabelle. Anders verhält es sich
mit dem Schematyp "Verdichtet". Die Inhalte von Periodengruppen und
Multiplen Feldern werden in der Stammtabelle in einer Containerspalte abgelegt. Auf den ersten Blick mag dies widersinnig erscheinen und ist es dennoch
nicht. Gerade in Multiplen Feldern werden häufig Programmm- oder Datenflags gesetzt, die unkritisch auch verdichtet in einer Containerspalte gespeichert werden können. Als dritter Objekttyp steht für Oracle auch die 1:1 Abbildung von Periodengruppen und Multiplen Feldern zur Verfügung. Doch wenngleich diese Möglichkeit technisch besteht wurde sie bislang noch in keinem
Projekt umgesetzt. Gerade die Normalisierung der Datenstrukturen wurde in
allen Projekten bislang als echter Mehrwert betrachtet.
Implementierung
Nachdem das Repository vollständig aufgebaut wurde und die Mapping-Rules
angepasst worden sind, werden – aus den Abbildungsregeln abgeleitet – die
Oracle-Datenbankobjekte (Tabellen, Indizes etc.) generiert. Die Testdaten werden von der ADABAS Datenbank entladen, dekomprimiert und mit dem Data
Loader anhand der im Repository definierten Abbildungsregeln in die neue
Datenbank übernommen. Die applikationsspezifische Implementierung kann
beginnen. Sie umfasst ggf. notwendige Erweiterungen der Funktionalität und
zielt darüber hinaus auf Performance steigernde Maßnahmen ab. Dazu wird
insbesondere die Statement-Generierungs-Engine auf die spezifischen Anforderungen der zu migrierenden Applikation angepasst.
IT Experience
Abb. 10: Normalisierungsmöglichkeiten einer Periodengruppe für Oracle
KONFERENZ
Test
Für die vorigen Projektphasen wie in besonderem Maße auch für die Testphase
gilt: Je höher jeder Prozess-Schritt automatisiert ist desto besser. Nur ein hoher
Automatisierungsgrad gewährleistet kurze Projektlaufzeiten, überschaubare
Tests sowie gleich bleibende und vergleichbare Qualität. Ein hoher manueller
Anteil der einzelnen Schritte hingegen treibt Aufwände und Kosten in die
Höhe und potenziert zudem etwaige Risiken. Ein großer Vorteil des non-invasiven Migrationsansatzes ist das Versprechen, die Testaufwände in einem
Migrationsprojekt signifikant zu reduzieren. Dieses Versprechen begründet sich
auf der Tatsache, dass in die Sourcen der Anwendung nicht eingegriffen wird.
Im Zusammenhang mit der Analyse einer Anwendung und "ihrer" Datenbank
wurden die ADABAS Command-Logs bereits als wichtige Quelle benannt. Sie
sind darüber hinaus auch für die Tests in besonderem Maße hilfreich und
äußerst nützlich. Da jeder Call und sein individuelles Ergebnis protokolliert
wird, kann das Command-Log auch als Eingabequelle für einen automatisierten Test der neuen Schnittstelle verwendet werden. Dazu werden zunächst die
involvierten Datenbestände gesichert und das Command-Log aktiviert. Die
relevanten Testfälle aus dem Dialog wie auch umfangreiche Batchläufe werden
durchgespielt bzw. angestoßen und das resultierende Protokoll wie auch die
End-Datenbestände werden wieder gesichert. Später kann die Aufzeichnung
aller Calls und aller Buffer über eine Art "Macro-Reader" gegen das neue Datenbank-Gateway laufen und muss das selbe Verhalten und die selben Ergebnisse
(Rückgabedaten und Returncodes) zeigen wie der Originallauf in ADABAS. Mit
diesem Testverfahren werden Regressionstests ebenso wie Performance-Tests
unkompliziert, schnell und automatisiert durchgeführt, die Beteiligung der
Fachbenutzer auf ein absolutes Minimum reduziert.
Abb. 11: Testkonzept
17. Deutsche ORACLE-Anwenderkonferenz
Produktion
Sind alle Tests erfolgreich durchgeführt und die Performance der migrierten
Applikation auf dem gleichen Niveau wie zuvor kann die Applikation dem
Abnahmetest zugeführt werden und in Produktion gehen. Für die Produktion
werden die Produktivdaten aus ADABAS entladen, dekomprimiert und mit
dem Data Loader anhand der Abbildungsregeln aus dem Repository in die
Oracle-Datenbank geladen. Der ADALNK wird durch SmartDCI® ausgetauscht.
Aus Sicherheitsgründen empfiehlt es sich, die Produktivumstellung vorher in
der Originalumgebung einmal zu "üben" und zu dokumentieren. Gegebenenfalls wird die Anwendung nach der Produktivschaltung für eine definierte Zeitspanne im Parallelmodus gegen beide Datenbanken betrieben. Zum Ende der
Parallel-Phase verleiht dann ein automatischer Vergleich der Datenbestände
die letzte Sicherheit, die richtige Entscheidung für den evolutionären Weg, die
Migration auf der Basis eines Transparency-Gateways, gewählt zu haben.
Mathias Jacobi
Georgstraße 15
D-88214 Ravensburg
Telefon:
Fax:
E-Mail:
Internet:
+49(0)751-56140 - 236
+49(0)751-56140 - 500
[email protected]
www.pks.de
IT Experience
Kontaktadresse: