MIGRATION ITND TRANSFORMATION VON DATENSTRUKTUREN
Die Erfindung betrifft eine Funktionseinheit, ein System, einen Beschreibungsrahmen, ein Verfahren zur Transformation einer Datenstruktur, ein Computerprogramm und ein Computerprogrammprodukt .
Zur Migration oder Transformation von Gestaltungen von IT- bzw. Datenbanksystemen zwischen verschiedenen Plattformen sind unterschiedliche übersetzende Verfahren bekannt. Bei derartigen Migrationen werden jedoch lediglich Daten transformiert. Anwendungen, die die Daten enthalten, respektive deren Struktur und Gestaltung werden hierbei nicht berücksichtigt. Deshalb ist eine Umstellung von existierenden Infrastrukturen bislang zu aufwendig.
Vor diesem Hintergrund wird eine Funktionseinheit mit den Merkmalen des Patentanspruchs 1, ein System mit den Merkmalen des Patentanspruchs 8, ein Beschreibungsrahmen mit den Merkmalen des Patentanspruchs 9, ein Verfahren mit den Merkmalen des Patentanspruchs 10, ein Computerprogramm mit den Merkmalen des Patentanspruchs 20 und ein Computerprogrammprodukt mit den Merkmalen des Patentanspruchs 21 vorgeschlagen .
Die erfindungsgemäße Funktionseinheit ist zur Migration und Transformation von Datenstrukturen mindestens eines Quellsystems in Datenstrukturen mindestens eines Zielsystems ge-
eignet und weist mindestens einen Import-Filter und mindestens einen Export-Filter auf. Die Funktionseinheit ist zur Kopplung zwischen mindestens einem Quellsystem und mindestens einem Zielsystem ausgebildet. Dabei ist der mindestens eine Import-Filter dazu ausgebildet, eine in einem quell- systemabhängigen Format vorliegende Datenstruktur in ein übergreifendes Beschreibungsformat zu transformieren. Der mindestens eine Export-Filter ist dabei dazu ausgebildet, die in dem übergreifenden Beschreibungsformat vorliegende Datenstruktur in ein zielsystemabhängiges Format zu transformieren.
Allgemein bieten IT-Systeme eine Möglichkeit Daten in Datenbanksystemen zu speichern. Der Aufbau dieser Speicherungssysteme, d.h. bspw. der Name der Tabellen sowie die Namen und Spezifikation dieser Felder, wie etwa Typ Zahl, Typ Datum, usw. wird allgemein als "Datenstruktur" bezeichnet .
Im Rahmen der vorliegenden Erfindung bezieht sich der Begriff "Datenstruktur" jedoch auf die Struktur eines betrachteten IT-Systems, d.h. auf das Quell- bzw. das Zielsystem, respektive deren jeweiligen Gestaltung. Demnach umfasst der Begriff "Datenstruktur" nicht nur eine Definition verwendeter Speichermedien sondern auch eine entsprechend eingesetzte verarbeitende Programmlogik sowie zur Verfügung stehende Eingabe- und Anzeigeoberflächen, ein sog. Benutzer- frontend und administrative Gestaltungselemente.
Der Kern der vorliegenden Erfindung ist die Migration und Transformation der Gestaltung von IT-Systemen, d.h. der Gestaltung des Quellsystems und der Gestaltung des Zielsystems, zwischen verschiedenen Plattformen und nicht ledig-
lieh die Migration der in den jeweiligen Systemen enthaltenen Daten.
"Datenstruktur" im Kontext der vorliegenden Erfindung setzt den Fokus auf die Struktur der Gestaltung, welche auch Daten im eigentlichen Sinne enthalten kann, dies aber nicht muss .
Die erfindungsgemäße Funktionseinheit kann für jeweils ein Quellsystem einen Import-Filter und für jeweils ein Zielsystem einen Export-Filter aufweisen. Bei einer Analyse der im quellsystemabhängigen Format vorliegenden Datenstruktur wird diese in Strukturelemente zerlegt. Diese Strukturelemente werden überprüft und/oder identifiziert und dann mit in einer Konfigurationstabelle hinterlegten Strukturelementen verglichen. Man spricht dabei von "Parsen" (engl, für analysieren) der Datenstruktur. Ein sog. DOM-Parser (Docu- ment Object Model) kann dazu verwendet werden, eine Datenstruktur in Strukturelemente zu zerlegen und in einem sog. Syntaxbaum zur weiteren Verarbeitung bereitzustellen. Neue Strukturelemente können in die Konfigurationstabelle aufgenommen werden. Somit kann sich die Funktionseinheit fortlaufend erweitern.
Strukturelemente, die als nicht identifizierbar eingestuft sind, aber in der Datenstruktur vorhanden sind, können in ein für derartige Strukturelemente vorgesehenes Protokoll aufgenommen und in einem zusätzlichen Schritt ggf. durch eine Administratoreinheit analysiert und transformiert werden. Ein quellsystemabhängiges oder quellsystemkonformes Strukturelement kann über den Import-Filter in ein Strukturelement des übergreifenden Beschreibungsformats und ausgehend hiervon über den Export-Filter in ein zielsystemab-
hängiges oder zielsystemkonformes Strukturelement übersetzt werden.
Das übergreifende Beschreibungsformat kann auch als ein zwischen zwei Systemen, also zwischen dem mindestens einen Quellsystem und dem mindestens einen Zielsystem stehendes, intersystemisches Beschreibungsformat bezeichnet werden. Das übergreifende Beschreibungsformat ist als Hilfsformat zu verstehen, über das eine Transformation und Migration zwischen dem quellsystemabhängigen Format und dem zielsys- temabhängigen Format ermöglicht wird. Das übergreifende Beschreibungsformat kann demnach als ein allgemeingültiges bzw. übergeordnetes Format unter quellsystemabhängigen und zielsystemabhängigen Formaten angesehen werden.
Weitere Ausgestaltungen der vorliegenden Funktionseinheit ergeben sich aus den abhängigen Patentansprüchen 2 bis 7. Hierbei ist die Funktionseinheit insbesondere dazu ausgebildet, mindestens einen Schritt des nachfolgend vorgestellten erfindungsgemäßen Verfahrens durchzuführen.
Ferner betrifft die vorliegende Erfindung ein Transformationssystem mit den Merkmalen des Patentanspruchs 8. Dieses Transformationssystem ist zur Migration und Transformation von Datenstrukturen mindestens eines Quellsystems in Datenstrukturen mindestens eines Zielsystems vorgesehen. Das Transformationssystem weist mindestens ein Quellsystem, mindestens ein Zielsystem und eine zwischen dem mindestens einen Quellsystem und dem mindestens einen Zielsystem gekoppelte Funktionseinheit auf, wobei die Funktionseinheit mindestens einen Import-Filter und mindestens einen Export- Filter aufweist. Dabei ist der mindestens eine Import- Filter dazu ausgebildet, eine von dem Quellsystem bereitge-
stellte, in einem quellsystemabhängigen Format vorliegende Datenstruktur in ein übergreifendes Beschreibungsformat zu transformieren, und der mindestens eine Export-Filter ist dazu ausgebildet, die in dem übergreifenden Beschreibungsformat vorliegende Datenstruktur in ein zielsystemabhängi- ges Format zu transformieren und dem Zielsystem bereitzustellen.
Die vorliegende Erfindung umfasst auch einen Beschreibungsrahmen, ein sog. Framework, mit den Merkmalen des Patentanspruchs 9. Der erfindungsgemäße Beschreibungsrahmen ist zur Transformation und Migration einer Datenstruktur von mindestens einem Quellsystem in mindestens ein Zielsystem geeignet und dazu ausgebildet, eine von dem mindestens einen Quellsystem bereitgestellte, in einem quellsystemabhängigen Format vorliegende und über mindestens einen Import-Filter transformierte Datenstruktur in einem übergreifenden Beschreibungsformat darzustellen, und die in dem übergreifenden Beschreibungsformat dargestellte Datenstruktur über mindestens einen Export-Filter in ein zielsystemabhängiges Format zu transformieren.
Das von der Erfindung ferner bereitgestellte erfindungsgemäße Verfahren ist zur Migration und Transformation einer Datenstruktur von mindestens einem Quellsystem in mindestens ein Zielsystem vorgesehen. Bei dem Verfahren wird die von dem mindestens einen Quellsystem bereitgestellte, in einem quellsystemabhängigen Format vorliegende Datenstruktur über mindestens einen Import-Filter in eine in einem übergreifenden Beschreibungsformat vorliegende Datenstruktur transformiert. Die in dem übergreifenden Beschreibungsformat vorliegende Datenstruktur wird über mindestens einen Export-Filter in eine in einem zielsystemabhängigen Format
vorliegende Datenstruktur transformiert und dem mindestens einen Zielsystem bereitgestellt.
Weitere Vorteile des erfindungsgemäßen Verfahrens ergeben sich aus den abhängigen Patentansprüchen 11 bis 19. Es ist vorgesehen, dass das Verfahren insbesondere durch die erfindungsgemäße Funktionseinheit durchgeführt werden kann.
In einer bevorzugten Ausführungsform kann vorgesehen sein, dass der mindestens eine Import-Filter und der mindestens eine Export-Filter jeweils durch den erfindungsgemäßen Bearbeitungsrahmen aus einem Quellcode abzuleiten sind. Dieser Quellcode kann aus Strukturinformationen, die in einer Konfigurationstabelle bzw. einer Konfigurationsdatei hinterlegt sind, generiert werden.
Das erfindungsgemäße Computerprogramm mit Programmcodemitteln ist dazu geeignet, alle Schritte des erfindungsgemäßen Verfahrens durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in der erfindungsgemäßen Funktionseinheit, ausgeführt wird.
Das erfindungsgemäße Computerprogrammprodukt mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind, ist dazu ausgebildet, alle Schritte des erfindungsgemäßen Verfahrens durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in der erfindungsgemäßen Funktionseinheit, durchgeführt wird.
Die vorliegende Erfindung stellt eine vorzugsweise softwaregestützte Lösung zur wechselseitigen Migration und
Transformation von Datenstrukturen, beispielsweise verschiedener Datenbank-Systeme oder verschiedener EDV-Anwendungen über verschiedene Entwicklungs-Plattformen bereit. Die Datenstrukturen basieren dabei bspw. auf dem XML-Format (Extensible Markup Language) . Eine Migration und Transformation von Datenbank-Systemen und EDV-Anwendungen über verschiedene Entwicklungs-Plattformen hinweg auf Basis von XML wird mittels der vorliegenden Erfindung ermöglicht. Jedes andere geeignete Format neben dem XML-Format ist jedoch auch denkbar.
Zahlreiche Datenbank- und IT-Systeme ermöglichen eine Darstellung einer zu verarbeitenden Logik und von Gestaltungselementen in einem XML-Format. Die erfindungsgemäße Funktionseinheit, wobei diese Funktionseinheit sowie deren Komponenten im Folgenden die Bezeichnung D2 (D-Quadrat) tragen können, transformiert diese in der Regel in hersteiler- und systemabhängigen XML-Formaten oder -Darstellungen vorliegenden Datenstrukturen ausgehend von dem mindestens einen Quellsystem über den mindestens einen Import-Filter in ein übergreifendes Beschreibungsformat. Die in dem übergreifenden Beschreibungsformat dargestellten Datenstrukturen werden im Folgenden als D2-Objekte bezeichnet. Durch reversen Einsatz der erfindungsgemäßen Funktionseinheit lässt sich in einem zweiten Schritt diese Datenstruktur wieder über mindestens einen vorzugsweise dedizierten Export-Filter in ein für das mindestens eine Zielsystem valides und konformes hersteller- und systemabhängiges XML-Format transformieren, so dass die Darstellung der verarbeitenden Logik und die Gestaltungselemente nunmehr in einem zielsystemspe- zifischen XML-Format vorliegt.
Dabei können alle EDV-Systeme unterstützt werden, die eine Darstellung ihrer Gestaltung in XML oder XML-Dialekten, wie Lotus Domino, MS Office 2003, .Net, etc., ermöglichen.
Der erfindungsgemäße Beschreibungsrahmen, im Folgenden als D2-Framework bezeichnet, der in die Funktionseinheit eingebunden ist, basiert auf einer programmiersprachenunabhängigen und selbstlernenden Vorgehensweise für die Interpretation und Migration von Datenstrukturen. Bei den Datenstrukturen kann es sich, wie bereits erwähnt, um Anwendungen handeln.
Mögliche Einsatzmöglichkeiten der erfindungsgemäße Funktionseinheit und/oder des erfindungsgemäßen Verfahrens finden sich bspw. in den folgenden Teilbereichen: Analyse von Umstellungsaufwänden, Migration von IT-Systemen und/oder Modifikation von IT-Systemen.
Durch den Import von bestehenden Anwendungen in den Beschreibungsrahmen der Funktionseinheit wird ein den Anwendungen zugrundeliegender Code geprüft und identifiziert. Somit ist eine Analyse von Umstellungsaufwänden einer Datenstruktur von einem Quellsystem in ein Zielsystem möglich.
Übersetzbare Strukturelemente der quellsystemabhängigen Datenstruktur bzw. entsprechende Gestaltungselemente wie Pro- grammecodeelemente werden hierbei als "positiv" identifiziert und stellen im Rahmen einer geplanten Umstellung keine Probleme dar. Nicht übersetzbare Strukturelemente werden bei der Analyse der quellsystemabhängigen Datenstrukturen als "negativ" identifiziert und in ein für derartige negative Strukturelemente vorgesehenes Protokoll geschrieben.
Dieses Protokoll kann durch zusatzliche Maßnahmen entsprechend bearbeitet werden, so dass für negativ identifizierte Strukturelemente eine geeignete Übersetzung bereitgestellt und diese Übersetzung für die Zukunft in die Konfigurationstabelle aufgenommen wird. Bewertet man dieses Protokoll mit Aufwanden zeitlicher und/oder materieller Art, können über deren Aggregationen realitatsnahe Abschatzungen für die geplanten Umstellungen getätigt werden.
Bei einer Migration für IT-Systeme werden bestehende Strukturelemente bzw. eine bestehende Gestaltung des Quellsystems ausgelesen und in eine analoge Gestaltung bzgl. Formularaufbau, Darstellung der Daten, verarbeitende Logik, usw., in dem gewählten Zielsystem überfuhrt. Da das Quellsystem hierbei nicht modifiziert wird, wird dessen Daten- und Funktionsintegritat gewahrleistet.
Nach erfolgter Migration kann die neugeschaffene Datenstruktur bzw. Anwendung hinsichtlich ihrer Funktionalität getestet und evaluiert werden. Sind im Verlaufe der Migration keine Probleme aufgetreten, kann die quellsystemabhan- gige Datenstruktur abgelost werden. Sind im Verlaufe der Migration bisher unbekannte Codeelemente in dem Quellsystem identifiziert worden, werden diese in dem Protokoll (D2- Log) der Funktionseinheit protokolliert. Diese unbekannten Codeelemente oder als "negativ" identifizierte Strukturelemente, können bei einer Auswertung des Protokolls überarbeitet und/oder auskommentiert werden, so dass diesen Co- deelemten bzw. Strukturelementen im Rahmen des übergreifenden Beschreibungsformats eine geeignete Übersetzung zugewiesen werden kann.
Nun besteht die Möglichkeit, die bestehenden Import- und Export-Filter zu erweitern und in einem weiteren Migrationsdurchgang ein vollständigeres und somit besseres Ergebnis zu erzielen. Auf diese Weise können komplexe Migrationsprojekte modular und anwendungsbezogen abgearbeitet und zu einem Stichtag automatisch abgeschlossen werden.
Zahlreiche in einem Unternehmen oder einer Organisation befindliche IT-Systeme weisen ein beträchtliches Alter auf und sind nach den zum Zeitpunkt der Entwicklung gegebenen technischen Möglichkeiten erstellt worden, weshalb eine Modifikation derartiger IT-Systeme in Erwägung zu ziehen wäre. Ein manuelles Upgrade auf den aktuellen Stand (Status Quo) des technischen Fortschritts birgt ein hohes Kosten- und Zeitrisiko. Im Regelfall sind an dieser Stelle zahlreiche einfache Einzelschritte manuell abzuarbeiten, wie Anpassung des Datenmodells, Änderung von Feldnamen und Bezeichnungen usw.
Mittels der erfindungsgemäßen Funktionseinheit können diese Schritte automatisiert werden. Das bedeutet, dass für den Export der Datenstruktur der entsprechende inverse Import- Filter verwendet wird. Wird bspw. ein Import-Filter für die Transformation einer Datenstruktur von MS Word nach D2 verwendet, so dient der entsprechende inverse Import-Filter umgekehrt für die Transformation von D2 nach MS Word als Export-Filter. Dazu müssen der Import- und der Export- Filter entsprechend invers zueinander konfiguriert sein. Demnach kann in bevorzugter Ausgestaltung mit einem Import- Filter und einem dazu korrespondierenden Export-Filter eine bidirektionale Transformation einer Datenstruktur, die in einem bestimmten, von einem ersten System abhängigen Format vorliegt, in das übergreifende oder allgemeingültige Be-
schreibungsformat und umgekehrt ermöglicht werden. Dieses bestimmte erste System kann dabei sowohl als Quellsystem von dem Import-Filter als auch als Zielsystem von dem dazu korrespondierenden Export-Filter bedient werden.
Die Transformation der Datenstruktur erfolgt in zwei Schritten. In einem ersten Schritt wird die Datenstruktur, die in dem quellsystemabhängigen Format vorliegt, durch den Import-Filter durch Analyse, Identifizierung und Zuordnung von Strukturelementen in das übergreifende Beschreibungsformat transformiert. Dieser Import-Filter kann sich aus der übergebenen Datenstruktur und den in einem Konfigurationssystem hinterlegten bspw. vorgebbaren Informationen durch Bearbeitung, Modifikation und Ergänzung von Strukturelementen selbst generieren. Bei diesem Import-Filter handelt es sich somit um einen sogenannten selbstlernenden Code. Die Informationen zu der in dem nunmehr übergreifenden Beschreibungsformat vorliegenden Datenstruktur werden in dem übergreifenden Beschreibungsrahmen der Funktionseinheit temporär gespeichert. Eine Speicherung kann hierbei in einem hierarchischen Klassenmodell oder Klassensystem erfol- genr wobei dieses Klassenmodell auf Basis der bei der Transformation oder Migration aus dem mindestens einen Quellsystem eingelesener Strukturelemente oder einer entsprechenden Datenstruktur überführt wird.
Die in dem allgemeinen Beschreibungsformat vorliegende Datenstruktur kann in einem zweiten Schritt durch Analyse, Identifizierung und Zuordnung von Strukturelementen in ein beliebiges Zielsystem oder eine entsprechende Plattform überführt werden, für die der Export-Filter hinterlegt ist. Der Export-Filter identifiziert die in dem Beschreibungsrahmen gespeicherten Strukturelemente, beispielsweise Ent-
wurf- oder Designelemente oder Code-Bausteine, und überführt diese in jenes zielsystemabhängige Format, das von dem Zielsystem interpretiert werden kann. Nicht bekannte oder nicht existierende Strukturelemente innerhalb des Zielsystems werden bei diesem Vorgang zu Dokumentationszwecken protokolliert und mitgeführt, diese Strukturelemente können nachträglich auskommentiert und durch eine Administratoreinheit bearbeitet und insbesondere manuell übersetzt werden. Auf diese Weise können EDV-Systeme über einen Zwischenschritt des übergreifenden Beschreibungsrahmens unter Speicherung in dem übergreifenden Beschreibungsformat von einer ersten Plattform bzw. dem Quellsystem auf eine beliebige andere unterstützte zweite Plattform bzw. das Zielsystem überführt werden.
Unterstützt werden hierbei insbesondere alle Plattformen oder Systeme, die auf XML-Dateien oder deren Derivaten zur Definition von Strukturelementen wie deren Layout und Code zurückgreifen können, beispielsweise "Lotus Domino", "MS Office 2003", ".Net" usw. Es ist vorgesehen, dass ein Zugriff auf den übergreifenden Beschreibungsrahmen während dieser Transformation über jede Programmiersprache erfolgen kann, die das Einbinden von externen Code-Ressourcen, in diesem Fall in einer Programmierschnittstelle (D2-API (Application Programming Interface) ) der Funktionseinheit erlaubt, z.B. "Lotus Script", "Java", "VB" usw.
Neben der eigentlichen Migration von Anwendungen ist mit der Funktionseinheit beispielsweise eine Schätzung zu erwartender Aufwände bei einer IT-System-Umstellung oder ein Überblick über eine Code-Qualität von betrachteten Anwendungen möglich.
Mit der erfindungsgemäßen Funktionseinheit bzw. dem übergreifenden Beschreibungsrahmen ist es somit möglich, eine IT-Infrastruktur zu analysieren und eine Abschätzung zu gewinnen, wie viel Prozent der mit dieser IT-Infrastruktur verbundenen Datenstrukturen bzw. Anwendungen einfach, schwierig oder vielleicht gar nicht zu migrieren sind. Werden die hierbei gewonnenen Ergebnisse, die aus dem Protokoll hervorgehen, in eine sog. Normalform gebracht, bei der jedes unbekannte Element nur noch einmal enthalten ist, so dass die Ergebnisse übersichtlich aufbereitet sind, kann eine einfache Aufwandsschätzung darüber abgeleitet werden, was eine Umstellung an Ressourcen und Kosten verschlingen wird. Sofern einem Nutzer diese Abschätzung als angemessen und akzeptabel erscheint, kann über den übergreifenden Beschreibungsrahmen oder die Funktionseinheit die Umstellung des ursprünglichen Systems, also des Quellsystems, bspw. durch Ablösen von Word-Formularen oder Excel-Spreadsheets automatisiert erfolgen.
Im Regelfall werden Migrationen zwischen Plattformen bzw. Systemen entweder manuell durchgeführt oder es wird ein individueller Code verfasst, durch den eine Umstellung von einem ersten System zu einem zweiten System möglich ist. Durch den Einsatz eines globalen Filters oder eines Transformationsfilters der erfindungsgemäßen Funktionseinheit, der den Import-Filter und den Export-Filter umfasst, ist es möglich, eine neue Plattform bzw. das Zielsystem in zwei Schritten zu erschließen. In einem ersten Schritt kann ein Import-Filter aus der quellsystemabhängigen Datenstruktur bzw. Anwendung im übergreifenden Beschreibungsformat erstellt werden. In einem zweiten Schritt kann ein entsprechender Export-Filter für die zielsystemabhängige Datenstruktur erzeugt werden. Hierzu kann in einer Ausgestaltung
vorgesehen sein, dass der Bearbeitungsrahmen aus Strukturinformationen, die in Konfigurationstabellen für die jeweiligen Datenstrukturen hinterlegt sind, jeweils einen Quellcode erzeugt, aus derartigen Quellcodes können dann die Import- und Export-Filter abgeleitet werden. Liegen beide Filter vor, ist dieses Quellsystem in den übergreifenden Beschreibungsrahmen eingebunden und kann jederzeit eingesetzt werden. Somit können erhebliche Einsparungspotentiale erzielt werden. Es ergibt sich im Vergleich zu bisherigen Vorgehensweisen eine erhebliche Kostenreduktion und eine schnellere Umsetzbarkeit, da die eigentliche Arbeit der Transformation nunmehr von der erfindungsgemäßen Funktionseinheit übernommen wird. Mit der erfindungsgemäßen Funktionseinheit ist man in der Lage, bestehende Anwendungen auf eine neue Plattform zu heben bzw. in das Zielsystem zu transformieren, wodurch ein wesentlich einfacherer und schnellerer Umstellungsprozess bereitgestellt ist.
Die erfindungsgemäße Funktionseinheit kann ein wesentlich weitläufigeres Spektrum an Plattformen bzw. Systemen, also Quell- und Zielsystemen abdecken, da dieses auf dynamischen Import-Filtern und Export-Filtern aufbaut. Während einer Laufzeit analysiert die Funktionseinheit einen eingespielten Code und erweitert gegebenenfalls die hinterlegte Konfigurationstabelle. Diese Konfigurationstabelle kann von einem Administrator überprüft und modifiziert werden, so dass der Nutzer die Funktionseinheit individuell an seine Bedürfnisse anpassen kann, womit dieser Nutzer entscheidet, welche Optionen ihm mit der Funktionseinheit geboten sind. Möglicherweise bei der Transformation bzw. einer Übersetzung des Codes oder einer Gestaltung auftretende Fehler sind lediglich Konfigurationsprobleme und können nachträglich angepasst werden, ohne ein Update der softwaregestütz-
ten Funktionseinheit zwingend erforderlich zu machen. Der Nutzer ist somit in der Lage, seine bestehende Infrastruktur zu analysieren und hieraus eine Aufwandsabschatzung für die Transformation abzuleiten und einen Fokus auf eine Identifikation von Hindernissen zu setzen. Somit wird dem Nutzer ein breiteres Spektrum an Funktionalitaten zur Verfugung gestellt .
Die erfindungsgemaße Funktionseinheit sowie der erfindungs- gemaße übergreifende Beschreibungsrahmen als Teil der Funktionseinheit bieten die Möglichkeit einer Entwicklung einer globalen Speicherungsmoglichkeit von Datenstrukturen, die in beliebigen Formaten, insbesondere XML-Formaten, vorliegen. Zur Speicherung der Datenstrukturen kann hierbei vorzugsweise das hierarchische und ggf. generalisierte Klassenmodell vorgesehen sein.
Mit der Funktionseinheit oder dem übergreifenden Beschreibungsrahmen kann zudem eine Anzahl der zur Transformation notwendigen Übersetzungsfilter erheblich reduziert werden. Geht man beispielsweise von sechs verschiedenen Plattformen bzw. Systemen aus, benotigt man für diese sechs Plattformen insgesamt 30 Transformationsfilter, da jedes System in jeweils fünf andere Systeme zu übersetzen ist. Durch den Einsatz der erfindungsgemaßen Funktionseinheit als globaler Container, der die Import- und Export-Filter umfasst und unter Nutzung des übergreifenden Beschreibungsformats ist eine Anzahl der benotigten Transformationsfilter auf zwei pro eingesetztem System oder eingesetzter Plattform reduziert. Demnach benotigt man pro System nur einen Import- Filter und einen Export-Filter. Geht man insgesamt von sechs Plattformen oder Systemen aus, so sind bei der vorliegenden Funktionseinheit lediglich 12 Transformationsfil-
ter, also sechs Import-Filter und sechs Export-Filter nötig.
Zusätzlich zu einer Reduktion benötigter Filter und damit benötigter Codes ist die Funktionseinheit selbstlernend, indem die Funktionseinheit neue Strukturelemente in eine Konfigurationstabelle aufnimmt und zugrundeliegende Programmierschnittstellen (D2-API) eigenständig erweitert und neuen Gegebenheiten anpasst. Die Funktionseinheit kann demnach bei neuen Versionen von Quell- oder Zieldaten aus entsprechenden Quell- oder Zielsystemen den sich dabei ergebenden Änderungen selbsttätig anpassen.
Die Funktionseinheit erlaubt ein Öffnen der in einem quell- systemabhängigen Format, bspw. in einem XML-Format, vorliegenden Datenstruktur, also einer Datei oder Anwendung, und überführt die darin enthaltenen Strukturelemente in eine zielsystemabhängige Datenstruktur und importiert diese automatisch. Strukturelemente, die nicht fehlerfrei übersetzt werden können, werden entsprechend markiert und in dem Protokoll angezeigt. Der Nutzer der Funktionseinheit kann aus diesem Protokoll ableiten, was und in welchem Umfang noch Korrekturen vorgenommen werden müssen, bevor dieser Teil oder diese Anwendung genau jenen Anforderungen genügt, die die ursprüngliche Datei oder Anwendung hatte. Sämtliche Aktivitäten der Funktionseinheit können nach Applikation, Anwender, Datum oder Art einzelner durchgeführter Schritte in einem Bericht sortiert, angezeigt und ausgewertet werden. Ein Benutzer-Frontend bzw. Programmier-Frontend, das zur interaktiven Anforderung, Eingabe sowie Anzeige von Daten verwendet wird und auch als Benutzeroberfläche bezeichnet werden kann, basiert auf Vorgaben einer Designstudie für
eine Erstellung eines intuitiven Frontends und setzt diese soweit technisch möglich um.
Die erfindungsgemäße Funktionseinheit ist insbesondere für Nutzer oder Unternehmen geeignet, die eine Ausrichtung in einem Bereich der computergestützten Zusammenarbeit ("CSCW" (Computer Supported Collaborative Work) oder Groupware) überdenken. Eine auf diesem Markt herrschende Konkurrenzsituation, bietet sich zur Anwendung der Funktionseinheit sowie des Verfahrens an. Die Funktionseinheit ist für Unternehmen geeignet, die einen hohen Bedarf an Unterstützung durch weitgehend automatisierte Tools im IT-Bereich haben. Mit der Funktionseinheit wird diesen Unternehmen die Möglichkeit geboten, ihre IT-Strategie vor dem Hintergrund aktuell genutzter Systeme, in diesem Fall von Quellsystemen, zu überdenken und gegebenenfalls durch Umstellung oder Transformation auf modernere, leistungsstärkere Systeme, also Zielsysteme, zu verbessern.
Der erfindungsgemäße Beschreibungsrahmen der Funktionseinheit kann derart ausgebildet sein, dass im Bereich einer Gestaltung des Benutzer-Frontends Anforderungen der Norm "DIN EN ISO 9241 Teil 10" berücksichtigt und soweit wie möglich umgesetzt werden können. Hierbei kann aufgrund technischer Gegebenheiten auf folgende Aspekte Wert gelegt werden:
- Aufgabenangemessenheit durch Nutzung von Standard- Werten und Auswahlfeldern zur Fehlerreduktion,
Selbstbeschreibungsfähigkeit durch Verwendung von Statuszeilen, kostenextensiven Hilfen oder Anmerkungen,
Steuerbarkeit, indem Eingabemöglichkeiten über einen sogenannten Wizard für Anfänger oder komplexere Masken für Experten möglich ist,
Erwartungskonformitat durch konsistente Gestaltung aller Interaktionsmoglichkeiten durch Anordnung von Aktionen.
Mit der Funktionseinheit kann insbesondere das XML-Format in innovativer Weise genutzt werden. Ursprünglich war XML als Datenaustauschformat zwischen IT-Systeinen, z.B. WebSer- vices gedacht. Mit der durch das Verfahren oder der Funktionseinheit durchfuhrbaren Transformation von Datenstrukturen, also Anwendungen, Daten oder auch Gestaltungen, kann unter Nutzung von XML-Import- und Exportmöglichkeiten zur Ablösung oder Einrichtung von Systemen das XML-Format innovativ genutzt werden.
Bei Durchfuhrung des erfindungsgemaßen Verfahrens bzw. bei Nutzung der erfindungsgemaßen Funktionseinheit werden nicht nur einfach Buchstaben oder Worte, sondern komplette Strukturelemente inklusive deren technischer Sinngehalt hinsichtlich einer Anwendung transformiert oder ausgetauscht.
Für einen Praxiseinsatz erscheinen insbesondere drei verschiedene Szenarien denkbar und lukrativ:
1) Abschätzung von Aufwanden im Vorfeld einer Migration: Wahrend einer Überführung der Datenstruktur aus dem Quellsystem, also einer Quellapplikation m das übergreifende Beschreibungsformat fuhrt die Funktionseinheit eine Analyse der Strukturelemente und somit eines Codes dieser Datenstruktur durch. Im Rahmen dieser Analyse werden nicht bekannte oder nicht übersetzbare Struktur-, Code- und/oder Designelemente protokolliert. Der Inhalt des dabei bereitgestellten Protokolls ist die Summe aller nicht automatisch übersetzbaren Strukturelemente oder Fragmente. Erfahrungsgemäß sind es bei verschiedenen Datenstrukturen oder Anwen-
düngen identische Strukturelemente, die nicht übersetzt werden können, so dass nur eines von mehreren gleichartigen Strukturelementen für eine Aufwandsschätzung relevant ist und in die Normalform gebracht wird. Bewertet man von jedem Objekttyp ein Strukturelement mit einer pekuniären oder zeitlichen Größe, erhält man einen Überblick über einen im Rahmen der tatsächlichen Umstellung anfallenden Aufwand zur Anpassung.
2) Durchführung einer Migration:
Steht eine Migration bevor, ergeben sich für den IT-Bereich oder betroffene Fachbereiche zwei Möglichkeiten zu deren Durchführung: Entweder a) eine manuelle Migration, die in der Regel sehr aufwendig sein wird, oder b) eine toolgesteuerte Migration mit anschließender manueller Prüfung und Korrektur. Da der Aspekt der Qualitätssicherung in beiden Fällen auftritt, kann dieser bei einer Bewertung vernachlässigt werden. Sind im Rahmen der IT-Umstellung mehr als ca. 20 Datenstrukturen zu transformieren, empfiehlt sich aus finanzmathematischer Sicht der Einsatz der erfindungsgemäßen Funktionseinheit bzw. des erfindungsgemäßen Verfahrens .
3) Upgrade von bestehenden Datenstrukturen oder Anwendungen :
Besteht das Interesse, bestehende Datenstrukturen auf ein einheitliches Format anzuheben und die ihnen zugrundeliegende Codelogik zu vereinfachen, kann dies mit dem durch die Funktionseinheit zur Verfügung gestellten Beschreibungsrahmen (Framework) und den darin enthaltenen Programmierschnittstellen (API) durchgeführt werden. Mit Hilfe der Funktionseinheit kann sichergestellt werden, dass auch tatsächlich alle Feldbezeichnungen innerhalb eines zu trans-
formierenden Systems, insbesondere Quellsystems oder einer zu transformierenden Datenbank umgesetzt werden. Auch in diesem Szenario macht der Einsatz der Funktionseinheit aus finanzieller Sicht Sinn, sobald es sich um mehr als 20 Datenstrukturen handelt.
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
Es versteht sich, dass die voranstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
Die Erfindung ist anhand eines Ausführungsbeispiels in der Zeichnung schematisch dargestellt und wird im folgenden unter Bezugnahme auf die Zeichnung ausführlich beschrieben.
Figur 1 zeigt in schematischer Darstellung eine bevorzugte Ausführungsform eines erfindungsgemäßen Transformationssystems .
Figur 2 zeigt in schematischer Darstellung eine bevorzugte Ausführungsform eines Ebenenmodells einer erfindungsgemäßen Funktionseinheit .
Figur 3 zeigt ein Phasenmodell zur Durchführung einzelner Schritte einer bevorzugten Ausführungsform eines erfindungsgemäßen Verfahrens.
Figur 4 zeigt in schematischer Darstellung eine bevorzugte Ausführungsform eines erfindungsgemäßen Beschreibungsrahmens .
Das in Figur 1 in bevorzugter Ausführungsform schematisch dargestellte Transformationssystem 1 umfasst eine Funktionseinheit 3, die mindestens einen Import-Filter 5, mindestens einen Export-Filter 7 sowie mindestens eine Programmierschnittstelle 9 (API) aufweist. Die Funktionseinheit 3 bzw. der mindestens eine Export-Filter 7 sowie der mindestens eine Import-Filter 5 haben Zugriff auf diverse Objekte 11, wie bspw. auf zur Transformation benötigte Tabellen, insbesondere auf Konfigurationstabellen oder Definitionstabellen sowie auf Protokolle.
Ist vorgesehen, eine Datenstruktur, die in einem quellsys- temabhängigen Format 17 vorliegt, von einem Quellsystem 13 in eine in einem zielsystemabhängigen Format 19 vorliegende Datenstruktur in ein Zielsystem 15 zu transformieren und/oder zu migrieren, so ist eine derartige Transformation und/oder Migration mit der Funktionseinheit 3 sowie mit dem durch die Funktionseinheit 3 ausführbaren Verfahren durchführbar. Hierbei ist vorgesehen, dass die in dem quellsys- temabhängigen Format 17 vorliegende und von dem Quellsystem 13 bereitgestellte Datenstruktur über den Import-Filter 5 in eine, in einem übergreifenden Beschreibungsformat 18 vorliegende Datenstruktur transformiert und in der Funktionseinheit 3 abgespeichert wird. Danach wird die in dem übergreifenden Beschreibungsformat 18 vorliegende Datenstruktur über den Export-Filter 7 in die im zielsystemabhängigen Format 19 vorliegende Datenstruktur transformiert und somit dem Zielsystem 15 bereitgestellt. In den Konfigurationstabellen unter den Objekten 11 sind Informationen
hinterlegt. Diese Informationen dienen bei der Transformationen zur Interpretation und Übersetzung oder Übertragung von Strukturelementen, in die die im quellsystemabhängigen Format 17 vorliegende Datenstruktur zu zerlegen ist. In den Protokollen unter den Objekten 11 werden nicht übersetzbare Strukturelemente protokolliert.
Bei der Funktionseinheit 3 handelt es sich demnach um eine Plattform und bei dem Verfahren um eine Vorgehensweise für eine automatisierte Transformation bzw. Migration von EDV- Systemen über bzw. zwischen verschiedenen Plattformen.
Figur 2 verdeutlicht in schematischer Darstellung die Vorgehensweise für eine Interpretation und Migration von Datenstrukturen bzw. Anwendungen. Grundlage eines Beschreibungsrahmens der Funktionseinheit aus Figur 1 ist hierbei das in Figur 2 in bevorzugter Ausführungsform dargestellte Ebenen-Modell, das zur Durchführung der Transformation 21 von Datenstrukturen ausgebildet ist, und das eine in einer Darstellungsebene 23 eingebettete EDV-Anwendung, eine Verarbeitungsebene 25 mit mindestens einem globalen Filter oder einem entsprechenden Transformationsfilter, der mindestens einen Import-Filter 24 und mindestens einen Export- Filter 26 aufweist, und eine Datenebene 27, die das übergreifende Beschreibungsformat 28 umfasst, aufweist.
Über den mindestens einen Import-Filter 24 wird die quell- systemabhängige XML-Darstellung der entsprechenden Datenstruktur bzw. eine Quellanwendung aus dem Quellsystem in das übergreifende Beschreibungsformat 28 (D2-Format) überführt. Ist die Gestaltung in diesem Beschreibungsformat 28 zwischengespeichert, kann die Datenstruktur ausgehend von dieser Darstellung über den Export-Filter 26 in eine für
das Zielsystem bzw. eine Zielplattform verständliche ziel- systemabhängige XML-Darstellung überführt werden. Die Funktionseinheit ist durch ständige Aktualisierung an eine hohe Dynamik im IT-Umfeld angepasst, somit können neue Versionen einer Software oder neue Design-Elemente und somit auch neue XML-Strukturen transformiert werden.
Figur 3 zeigt ein Phasenmodell entsprechend einem Prozess der Transformation bei einer bevorzugten Ausführungsform des Verfahrens. Das Verfahren umfasst im wesentlichen vier Phasen oder Schritte, nämlich eine Analyse 29, eine Erweiterung 31 bzw. ein Upgrade, einen Entwurf 33 bzw. ein Design und eine Transformation 35.
Bei Durchführung des Verfahrens wird in der Phase der Analyse 29 eine bereitgestellte quellsystemabhängige XML-Datei bspw. mittels eines Standard-XML-Parsers (DOM-Parser) in ihre Strukturelemente oder Elemente zerlegt. Jedes identifizierte Strukturelement oder Attribut, beispielsweise ein XML-Knoten, sowie jedes XML-Attribut wird gegen eine Konfigurationstabelle verglichen. Das Ergebnis dieser Überprüfung kann eine der folgenden Ausprägungen haben: a) Das Strukturelement ist noch nicht in der Konfigurationstabelle der Funktionseinheit enthalten. b) Das Strukturelement ist bereits in der Konfigurationstabelle enthalten und in dieser weder als positiv, d.h. bekannt und übersetzbar, noch negativ, d.h. bekannt und nicht übersetzbar, markiert oder identifiziert. c) Das Strukturelement ist bereits in der Konfigurationstabelle enthalten und als bekannt und interpretierbar markiert, dies entspricht einer positiven Definition dieses Strukturelements.
d) Das Strukturelement ist bereits in der Konfigurationstabelle enthalten und als nicht interpretierbar markiert, dies entspricht einer negativen Definition dieses Strukturelements.
Handelt es sich um ein neues Strukturelement (Fall a) , wird dieses in die Konfigurationstabelle aufgenommen und als unbekannt markiert. Durch eine manuelle Überprüfung kann dieses dann entweder als übersetzbar, d.h. positiv, oder nicht übersetzbar, d.h. negativ, markiert werden. Ist das Strukturelement zwar in der Konfigurations- oder Definitionstabelle enthalten (Fall b) , aber noch nicht beurteilt worden, protokolliert der Import-Filter, dass es sich um ein Undefiniertes Strukturelement handelt, dieses Strukturelement wird dabei in ein dafür vorgesehenes Protokoll aufgenommen, so dass es individuell bearbeitet werden kann. Ist das Strukturelement in der Konfigurations- oder Definitionstabelle enthalten und als bekannt und interpretierbar markiert (Fall c) , so wird dieses Strukturelement in den Beschreibungsrahmen bzw. eine D2-Struktur des Import-Filters aufgenommen. Ist das Strukturelement als bekannt aber nicht übersetzbar identifiziert worden (Fall d) , eliminiert der Import-Filter einen damit verbundenen Knoten, insbesondere einen XML-Knoten.
Bei einem positiv definierten Strukturelement wird dieses iinn ddeenn BBeesscchhrreeiibbuunnggssrraahhmm«en bzw. eine D2-Struktur des Im- port-Filters aufgenommen.
Durch die automatische Aufnahme neuer Strukturelemente in die Konfigurations- oder eine entsprechende Definitionstabelle stellt sich der Import-Filter als selbstlernendes
System dar. Neue Situationen erweitern den zugrundeliegenden Beschreibungsrahinen (D2-Struktur) automatisch.
Positiv- und Negativdefinitionen für Strukturelemente garantieren, dass nur den Import- und Export-Filtern bekannte Strukturelemente importiert und in das Zielsystem exportiert werden können. Neben der eigenständigen Erweiterung der Funktionseinheit handelt es sich hierbei um die zweite entscheidende Eigenschaft zur Durchführung von fehlerresis- tenten Transformationen und/ oder Migrationen von Datenstrukturen. Negativen Strukturelementen, die in dem hierfür vorgesehenen Protokoll abgelegt sind, kann durch einen Administrator eine geeignete Übersetzung zugeordnet werden.
Bei dem Verfahren ist in der nächsten Phase die Erweiterung 31 vorgesehen. Stößt der Import-Filter auf ihm noch nicht bekannte Strukturen oder Strukturelemente werden diese, wie voranstehend beschrieben, in die Konfigurationstabellen aufgenommen. Auf Basis der nun veränderten Konfigurationstabelle erweitert sich ein Objektmodell des Beschreibungsrahmens oder der Funktionseinheit um die hinzugekommenen Strukturelemente und merkt sich diese für die Zukunft. Hierbei werden automatisiert neue Objektklassen generiert und in bereits eingebundene Struktur- oder Codeelemente integriert .
Ist die zu importierende Datenstruktur analysiert worden und das Objektmodell im Rahmen der Erweiterung 31 aktualisiert, wird in dem als Entwurf 33 vorgesehenen Prozessschritt die quellsystemabhängige Datenstruktur bzw. eine Quell-Datei in ein hierarchisches Klassenmodell auf Basis der bei der Transformation oder Migration aus dem mindestens einen Quellsystem eingelesenen Strukturelemente oder
Datenstruktur überführt und einer Bearbeitungsplattform (D2-Plattform) des Bearbeitungsrahmens zur Verfügung gestellt. Nach dem Abschluss dieser Phase ist somit ein Import-Vorgang abgeschlossen und der eingelesene Code bzw. die eingelesenen Strukturelemente der Datenstruktur liegt bzw. liegen zur Weiterbearbeitung vor.
Analog zu dem Programmablauf beim Import werden im Rahmen der Transformation 35 die in dem übergreifenden Beschreibungsformat vorliegenden bzw. in einer D2-Struktur gespeicherten Informationen gegen den Export-Filter validiert und protokolliert. Unbekannte Struktur- bzw. Codeelemente werden hierbei aus Gründen der Dokumentation nicht gelöscht, sondern in das Protokoll aufgenommen und später auskommentiert. Der Export-Filter überführt die im übergreifenden Beschreibungsformat bzw. D2-Format gespeicherten Informationen in eine für das Zielsystem konforme Datenstruktur, insbesondere XML-Datei auf Basis der in den Import- und Export-Filtern hinterlegten Neuzuweisungen und/oder Übersetzungsregeln. Durch eine Erweiterung der Konfigurationstabelle werden der Import-Filter und Export-Filter im Laufe der Zeit verbessert. Der Import-Filter erweitert bei Bedarf eigenständig das allgemeine Beschreibungsformat, um dieses auf neue Situationen dynamisch anzupassen. Werden neue Strukturvorschläge durch einen Administrator akzeptiert, stehen sie für die Zukunft dauerhaft zur Verfügung.
Figur 4 zeigt in schematischer Darstellung den Beschreibungsrahmen 37 der Funktionseinheit mit einem Programmieroder Benutzer-Frontend 39, dem Import-Filter 41, dem Export-Filter 43, einer Klassenbibliothek 45, einer Basisbibliothek 47 und einer Konfigurationstabelle 49, die, durch
die Pfeile angezeigt, durch Austausch von Daten, Informationen und Strukturelementen miteinander wechselwirken.
Der Bearbeitungsrahmen 37 (D2-Framework) folgt einem objektorientierten Programmier-Paradigma und nutzt über den Einsatz von Klassen die Eigenschaften der Vererbung in gängigen Programmiersprachen. Der Beschreibungsrahmen 37 ist - soweit eine Einbindung von Code-Ressourcen in der gewählten Programmiersprache möglich ist - sprachunabhängig. In einer Basisklasse "DD_Base" können globale Objekte definiert und globale Funktionen zur Verfügung gestellt werden. Diese stehen in den aus der Basisklasse abgeleiteten systemabhängigen Klassen zur Verfügung und verwenden diese für Standardfunktionen. Aus den in der Konfigurationstabelle 49 hinterlegten Strukturinformationen generiert der Bearbeitungsrahmen 37 automatisch einen Quellcode für die hersteiler- und/oder systemabhängige Datenstruktur.
Aus diesem Quellcode werden dann Import-Filter 41 und Export-Filter 43 abgeleitet, die über die in den Klassenbibliotheken 45 hinterlegte API-Schnittstelle eine entsprechende Transformation von Datenstrukturen zwischen verschiedenen Formaten durchführen. Über das entsprechende Be- nutzer-Frontend 39 in einer gewählten Plattform, wie beispielsweise "Domino. Designer" bei "Lotus Domino" oder "Visual Studio" bei ".Net-Anwendungen", können diese Import- Filter 41 und Export-Filter 43 über die entsprechend hinterlegte Programmierschnittstelle (API) angesprochen und angepasst werden. Hierbei werden alle Programmiersprachen unterstützt, welche das Einbinden von externen Code-Ressourcen zulassen.
Die Basisbibliothek 47 (DD_Base-Bibliothek) repräsentiert eine Basisklasse, auf der alle anderen Klassen aufbauen. Sie stellt Grundfunktionen zum Interpretieren von XML- Dateien und die Überführung in ein Klassenmodell dar. Darüber hinaus enthält die Funktionseinheit die für die weitere Bearbeitung notwendigen klassenübergreifenden Objekte, beispielsweise einen Strukturbaum oder Basis-XML-Knoten. Die in einer Basisbibliothek 47 identifizierten XML- Elemente werden - solange noch nicht vorhanden - in die Konfigurationstabelle 49, die einer Definition der Strukturelemente dient, aufgenommen. Auf diese Weise entsteht dynamisch für jedes analysierte System oder jede analysierte Plattform je nach Format, beispielsweise "Lotus Domino", "MS Word" usw., ein eigener Strukturbaum. Über die Klassenbibliotheken 47 der Funktionseinheit werden aus den in der Konfigurationstabelle 49 hinterlegten Informationen die Funktionseinheit und die Programmierschnittstelle (API) dynamisch generiert, durch die die in der D2-Struktur hinterlegten Informationen darstellbar sind. Ein derart dynamisch erzeugter Code wird automatisch dokumentiert und versio- niert, und kann im weiteren Verlaufe von Transformationen angesprochen werden.
Für alle Attribute eins XML-Knotens (XML-node) werden bspw. die folgenden Eigenschaften und Methoden zur Verfügung gestellt:
- "get<AttributName>" (liest den Wert des Attributes aus)
- "set<AttributName>" (verändert den aktuellen Wert des Attributes)
- "append<ElementName>" (fügt ein neues Objekt dieses Typs in die Struktur ein)
"remove<ElementName>" (löscht ein bestehendes Objekt dieses Typs)
- "New(MyNode as XMLNode) " (initialisiert eine neue Klasse für dieses XML-Element)
- "getXMLAsStream(stream_out as Stream) " (überführt das aktuelle Klassemodell in einen Stream)
- "getXMLAsString(str_DDOut as String) " (überführt das aktuelle Klassenmodell in einen Text-String) .
Auf diese Weise entsteht eine einheitliche und konsistente Schnittstelle (API) , die von einem beliebigen anderen Code angesprochen werden kann.
Um einen System- oder plattformunabhängigen Einsatz der Funktionseinheit zu gewährleisten, werden diese Klassenbibliotheken 45 in unterschiedlichen Programmiersprachen generiert und als Ressourcen in eine definierte Ablage (Reposi- tory) geschrieben.
Die in bei dem Verfahren durch die Funktionseinheit verwendeten Import-Filter 41 und Export-Filter 43 greifen auf die Klassenbibliotheken 45 zu und erben von diesen Eigenschaften und Methoden. Über diese Funktionalitäten werden für den Fall eines Imports die Informationen aus der XML-Datei in die Funktionseinheit geschrieben. Im Falle des Exports werden die in der Funktionseinheit gespeicherten Informationen in die entsprechende Klassenbibliothek 45 geführt und in einem validen XML-Format wiedergegeben. Nicht bekannte oder bekannte, jedoch nicht übersetzbare Strukturelemente und/oder Codeelemente werden hierbei in Protokollen festgehalten und somit auskommentiert mitübergeben. Derartige Strukturelemente müssen und/oder können dann bei Bedarf in dem Zielsystem manuell nachbearbeitet werden.
Besteht der Bedarf in den Transformationsprozess via Programmcode einzugreifen, was beispielsweise ein Setzen von Update-Informationen oder Erstellen einer technischen Dokumentation umfasst, erfolgt dies in der gewählten Sprache über die eingebundene Programmierschnittstelle (API). Hierbei können, wie voranstehend gezeigt, alle Eigenschaften der Funktionseinheit sowie der Import-Filter 41 und Export- Filter 43 manipuliert werden.