Einführung
Informatica ist der Marktführer unter den Anbietern von Datenintegrationssoftware und viele Unternehmen vertrauen beim Extrahieren, Transferieren und Laden von Daten der Werkzeugpalette, die Informatica bietet. Im entsprechenden Gartner-Quadranten haben Sie seit vielen Jahren die Spitzenposition inne.
Die Möglichkeiten der Versionskontrolle, die Informatica PowerCenter [1] zum Nachverfolgen/Rückabwickeln von Entwicklungsschritten innerhalb eines Repositories oder zum Deployen von Änderungen in z.B. Test- oder Produktionsumgebungen bietet, sind jedoch etwas unhandlich. Wenn man in Informatica PowerCenter die Versionierung nutzt, dann führt dies dazu, dass von jedem Objekt (mappings, targets, sources etc.) jede Version gespeichert wird und sich lediglich der object status ändert. Dargestellt wird nur das jeweils aktive Objekt und wenn man ein nicht aktives Objekt wieder aktivieren möchte, dann muss man seinen Status wieder auf Active setzen. Dies führt dann aber zu Namenskonflikten, wenn die zuvor aktive Version des Objekts nicht zuerst auf Delete gesetzt oder umbenannt wurde. Dieses Vorgehen bedeutet auch, dass jede eingecheckte Version komplett gespeichert wird. Diese Art der Versionierung bedarf natürlich ungleich mehr Speicherplatz und Wartungsaufwand, da nicht mehr benötigte Versionen gelöscht werden müssen. Dauerhaftes Löschen wird von Informatica als Purge bezeichnet, in Abgrenzung zum Delete, wodurch eine Version nur inaktiviert wird. Eine einmal gelöschte Version eines Objektes ist dann aber auch dauerhaft verloren.
Die Versionierungslösung von Informatica PowerCenter erlaubt grundsätzlich auch das Verteilen von Entwicklungsschritten auf z.B. eine Integrations-/Test-/Produktionsumgebung über sogenannte Deployment Groups. Die Nutzung von dynamischen Deployment Groups ermöglicht es dem Nutzer auf Grundlage einer Query die Objekte zusammenzustellen, die von der Deployment Group erfasst werden sollen. Dynamisch bedeutet hierbei, dass die Query zum Zeitpunkt des Deployments ausgeführt wird und die Grundlage für das Deployment bildet. Allerdings gilt es hierbei genau auf die Abhängigkeiten von Child und Parent Objekten zu achten. Für die Extraktion von versionierten Objekten müssen zusätzlich Labels verwendet werden, um die korrekte Version zu identifizieren. Dies kann zu Problemen führen, da die Label, die zur Identifizierung von versionierten Parent und Child Objekten verwendet werden, ihre Synchronizität verlieren können. [2] Im Idealfall kann jedoch auf diese Weise vom Entwicklungsrepository per Query eine Deployment Group erstellt und extrahiert werden, die sich dann auf einer anderen Umgebung wieder einbinden lässt.
Zusammenfassend lässt sich sagen, dass die Versionierung von Informatica auf jeden Fall ressourcenintensiv ist und zudem ein hohes Maß an Disziplin beim Verwalten der Abhängigkeiten und Namensgebungen bzw. der Labels erfordert.
Informatica bietet zwar die Möglichkeit über einen weiteren Service, das sogenannte Model Repository, Git anzubinden, bzw. die Objekte des Model Repositories zusätzlich in einem lokalen oder auch globalen Git Repository abzulegen, jedoch ist hierbei nicht vorgesehen, eigene Entwicklungszweige zu erstellen und serverübergreifend Änderungen an Objekten zu verwalten und zu verteilen. Zudem benötigt jedes Repository sein eigenes Model Repository, welches wiederum jeweils ein eigenes Git Repository anbindet. Git dient hier eher zur Verwaltung einer zusätzlichen Sicherungskopie und zum Sperren von Objekten des Model Repositories, da verhindert werden kann, dass mehrere Entwickler gleichzeitig an einem Objekt arbeiten.[3]
Die Alternative
Eine alternative Möglichkeit der Versionierung von Informatica-Repository-Objekten soll im Folgenden vorgestellt und erläutert werden.
Grundlegend lässt sich jedes Objekt in einem Informatica Repository als XML-Datei exportieren. Es ist also naheliegend, eine Versionierung der XML-Dateien vorzunehmen, die zuvor aus einem Repository exportiert wurden.
Die benötigten Programme sind alle in Python entwickelt und nutzen im Wesentlichen das Informatica Befehlszeilenprogramm pmrep [4], welches grundlegende Funktionalitäten im Umgang mit den Repositories bereitstellt. So lassen sich z.B. Objekte auflisten, als XML-Datei exportieren, Ordner erstellen oder löschen, Verbindungen zu Repositories herstellen, etc.
Die eigentliche Herausforderung für die Entwicklung einer sinnvollen Versionierungslösung ist der Umgang mit den XML-Dateien, die exportiert werden. Dazu muss man sich zunächst die Struktur der exportierten XML-Dateien vergegenwärtigen und verstehen, welche Informationen auf welche Weise in den XML-Exporten steckt.
Gehen wir von einem Repository „Beispiel_Repository“ aus. Nehmen wir nun an, dass an einem Mapping gearbeitet wurde, welches in einem Workflow zur Anwendung kommt. Wenn ein Export dieses Workflows durchgeführt wird, dann werden, je nach Exporteinstellungen, die unterschiedlichsten Transformationen, Sources, Targets, Mappings, Mapplets, etc. im XML zusammengefasst. Unter der Annahme, dass die betroffenen Objekte in den Repository-Ordnern „SPAM“, „EGGS“und „BACON“ gespeichert sind, könnte ein XML-Export eine Struktur wie in Abbildung 1 dargestellt aufzeigen. Der Export besteht aus Elementen, die zur allgemeinen Beschreibung des Repositories dienen und aus Elementen, die die betroffenen Repository-Ordner und deren Inhalt darstellen.
Es wird sofort ersichtlich, dass es nicht sinnvoll wäre, diesen XML-Export zu versionieren, da die Information zum einen repositoryspezifisch ist und zum anderen die Elemente des XMLs diverse Objektinformationen aus unterschiedlichsten Repository-Ordnern erfassen und deren Reihenfolge von dem exportierten Workflow selbst abhängt. Das bedeutet, dass in einem anderen Export die gleiche Source Definition, die in dem Beispiel-Export im Folder „BACON“ enthalten ist, erfasst sein kann. Somit wäre die Information über ein und dieselbe Source in zwei verschiedenen XML-Exporten vorhanden. Diese XML-Exporte wären dann auf jeden Fall unterschiedlich und damit auch für ein Versionierungstool, wie z.B. git. Das die Source Definition in beiden Exporten exakt gleich sein kann und sich somit zwischen den beiden Exporten die Source Definition nicht geändert hat, wäre damit nicht erfassbar.
+-------------------------------------------------------------------------------+
| Exemplarischer und gekürzter Auszug eines XML-Exports. Bis auf die Namen der |
| Folder sind alle Attribute der einzelnen Elemente entfernt worden, um die |
| Struktur des XML-Exports zu veranschaulichen |
+-------------------------------------------------------------------------------+
<?xml version="1.0" encoding="UTF-8"?>
<DOCTYPE POWERMART SYSTEM "powrmart.dtd">
<POWERMART CREATION_DATE="12/10/2020 14:44:29" REPOSITORY_VERION="123.456">
<REPOSITORY NAME="Beispiel_Repository" VERSION="123" CODEPAGE="UTF-8" DATATYPE="Oracle">
<FOLDER NAME="SPAM">
<TARGET>
<TARGETFIELD/>
</TARGET>
<TRANSFORMATION>
<TRANSFORMFIELD/>
...
<TABLEATTRIBUTE/>
...
</TRANSFORMATION>
<MAPPING>
<TRANSFORMATION>
<TRANSFORMFIELD/>
...
<TABLEATTRIBUTE/>
...
</TRANSFORMATION>
<INSTANCE/>
<CONNECTOR/>
<TARGETLOADORDER/>
<MAPPINGVARIABLE/>
</MAPPING>
<SHORTCUT/>
</FOLDER>
<FOLDER NAME="EGGS">
<TARGET>
<TARGETFIELD/>
</TARGET>
<TRANSFORMATION>
<TRANSFORMFIELD/>
...
<TABLEATTRIBUTE/>
...
</TRANSFORMATION>
<MAPPLET>
<TRANSFORMATION>
<TRANSFORMFIELD/>
...
<TABLEATTRIBUTE/>
...
</TRANSFORMATION>
<INSTANCE/>
<CONNECTOR/>
<TARGETLOADORDER/>
<MAPPINGVARIABLE/>
</MAPPLET>
</FOLDER>
<FOLDER NAME="BACON">
<SOURCE>
<SOURCEFIELD/>
</SOURCE>
</FOLDER>
</REPOSITORY>
</POWERMART>Sequenzieren und Sortieren
Im Kern ist also das Problem der XML-Exporte, dass ein Export diverse Informationen des Repositorys zusammengefasst darstellt. An dieser Stelle kann jedoch eingegriffen werden und Hilfsprogramme können entwickelt werden, die die Exporte sequenzieren, sortieren und in geeigneter Weise als XML-Bausteine abspeichern.
Eine sinnvolle Ordnerstruktur, in der die sequenzierten und sortierten XML-Dateien abgelegt werden und die dann auch mit git versioniert werden kann, orientiert sich an der Ordnerstruktur des Repositorys. Das heißt, man benötigt, wenn in unserem Beispiel das Repository zusätzlich zu den Ordnern „SPAM“, „EGGS“ und „BACON“, die Ordner „SAUSAGE“und „BEANS“ enthält, ein zu versionierendes Verzeichnis – nennen wir es „ETL_Repo“, mit den Unterordnern „SPAM“, „EGGS“, „BACON, „SAUSAGE“ und „BEANS“. Jeder Ordner beinhaltet wiederum die Strukturen des Informatica Repositorys, also jeweils einen Ordner für z.B. Workflows, Transformations, Targets, Sources, Shortcuts, Mapplets, Mappings usw.
Wenn nun mit den Hilfsprogrammen ein XML-Export eines Workflows, des ganzen Ordners, oder des gesamten Repositorys angestoßen wird, so wird der eigentliche Export direkt sequenziert und sortiert auf die einzelnen Ordner aufgeteilt. In Abbildung 2 ist dies grafisch für das Beispiel aus Abbildung 1 verdeutlicht.
Dieses Vorgehen sorgt dafür, dass bei einem Export unterschiedlichster Elemente immer nur dann im versionierten Ordner (ETL_Repo) eine Änderung erfasst wird, wenn sich auch tatsächlich inhaltlich etwas an den exportierten Elementen geändert hat. Eine Besonderheit stellen die Attribute der „Folder“- und „Repository“-Elemente, die in Abbildung 2 magentafarben markiert sind, dar. Diese Informationen gehören in der versionierten Ordnerstruktur in den jeweiligen Ordner und können z.B. sehr gut als JSON-Datei erfasst werden.
Ein weiterer Vorteil dieser Art der Versionierung und Aufbereitung der XMLs ist die Flexibilität, die sich ergibt, wenn Änderungen auf andere Repositories auf anderen Servern übertragen werden sollen. In Ergänzung zu einem Export-Programm, welches direkt sequenziert und sortiert, benötigt man natürlich auch ein Import-Programm, welches die Informationen in dem git Repository „ETL_Repo“ wieder in das eigentliche Informatica Repository lädt. Hier spielt die JSON-Datei „repository_info.json“ eine wichtige Rolle. In diesem JSON ist der Name des exportierten Repositorys enthalten. Wenn man an dieser Stelle mit Platzhaltern arbeitet, ermöglicht dies, den Repository-Namen, der bei einem Import genutzt werden soll, in einer config Datei auf dem jeweiligen Server abzulegen und dynamisch bei einem Import in die XML-Datei einzubauen. Auf diese Weise lassen sich Änderungen an einem Repository, die auf einer Entwicklungsumgebung gemacht wurden, sehr komfortabel in eine Test- oder Produktionsumgebung einspielen. Ebenso erhöht dieses Vorgehen die Flexibilität der Entwickler, da man z.B. auf zwei verschiedenen Entwicklungsservern und Repositories arbeiten kann und seine jeweiligen Änderungen in einem eigenen Zweig des git-Repositorys verwalten kann.
Fazit
Informatica Repositories können auf sinnvolle Weise versioniert werden. Um dies zu realisieren, muss einmalig ein erhöhten Programmieraufwand betrieben werden, da geeignete Hilfsprogramme erstellt werden müssen. Die Vorteile liegen jedoch auf der Hand. Zum einen kann so auf die unter Umständen immense Vergrößerung der Repository-Datenbank verzichtet werden, da nicht jede Änderung gespeichert wird, sondern mit git die tatsächlichen Änderungen nachverfolgt und rückabgewickelt werden können und das volle Potenzial von der Entwicklung auf eigenen Zweigen genutzt werden kann. Zum anderen erhöht das Vorgehen die Flexibilität bei der Entwicklung, da man Änderungen auf unterschiedlichste Repositories auf verschiedenen Servern verteilen kann.
1. Die Aussagen beziehen sich auf die Informatica PowerCenter Versionen 10.2.0 bis 10.4.1
