Transport (Export und Import) von Profilen

Lobster_data-Profile werden üblicherweise in der Test- oder Entwicklungsumgebung entwickelt und nach gründlichen Tests in die Produktionsumgebung transportiert. Lobster_data bietet die folgenden Möglichkeiten, um Profile zu transportieren.

  • Automatisierter Transport von Profilen mit dem Transport Manager. Die Versionen beider Systeme müssen dabei aber innerhalb des selben Major Releases sein, also z. B. 4.0.0 und 4.1.0. Nicht funktionieren würde z. B. 3.5.4 und 4.0.0.

  • Manueller Transport (Export und Import) von Profilen. Die jeweiligen Systeme sollten dieselbe Version haben. Der Import von Profilen einer früheren Version ist möglich, dabei gehen aber alle Einstellungen, die nicht in beiden Versionen existieren, verloren. Eine anschließende Prüfung ist dann dringend empfohlen.

  • Automatisierter Export von Profilen mit der Klasse ExportProfiles.

Für das explizite Backup von Profilen gibt es eigene Mechanismen.

Richtlinien zur Erstellung von Profilen im Test-System für den Transport ins Produktiv-System

Die Idee eines Test-Systems ist, dass man dort (abgesehen von allgemeinen Tests und Spielereien aller Art) Profile in einer "harmlosen" Umgebung erstellt und testet und diese dann, wenn man sie letztendlich perfektioniert hat, auf das Produktiv-System transportiert. Die Harmlosigkeit liegt darin begründet, dass man meist nicht mit produktiven Partnersystemen und Datenbanken testen wird und somit nicht in Gefahr ist, wichtige Daten zu korrumpieren durch die notwendigen Tests. Aber gerade die Verwendung von nicht-produktiven Systemen erzeugt (bei aller Notwendigkeit) Fallstricke bei einer Übertragung von Profilen. Deshalb sollen hier im Folgenden ein paar Hinweise gegeben werden, wie man diese vermeiden kann. Wichtiger Hinweis: Wir empfehlen prinzipiell nur den Transport vom Test-System ins Produktiv-System und nicht anders herum. Das soll verhindern, dass Test-Daten im Produktiv-System landen. Sollten Produktiv-Daten im Test-System landen, ist das zwar auch nicht schön, aber weniger dramatisch.

Die problemlose Verwendung von Profilen aus einem anderen System setzt voraus, dass in diesen Profilen keine Server-Adressen, Namen, Passworte, usw. fest konfiguriert sind. Stattdessen sollten die konkreten Partner-Zugangsinformationen z. B. in Partner-Kanälen definiert werden. Weiterhin gibt es die sogenannten System-Konstanten, die in der Systemumgebung definiert werden. Mit diesen Methoden kann erreicht werden, dass sich ein (unverändertes) Profil z. B. auf dem Test-System mit dem Test-System eines Partners verbindet, aber nach dem Transport auf das Produktiv-System mit dem Produktiv-System des Partners. Bei der Profil-Entwicklung können System-Konstanten an den entsprechenden stellen meistens einfach ausgewählt werden, wenn sie vorher definiert wurden.

Partner-Kanäle auf Ziel-System

Wenn Sie in Profilen Partner-Kanäle verwenden, dann müssen Sie diese gesondert übertragen. Entweder "manuell" oder mit der entsprechenden Funktion im Transport Manager. Zudem müssen Sie in beiden Fällen deren Werte nach der Übertragung anpassen (produktive Zugangsdaten). Hinweis: Sollten Sie einen gleichnamigen Kanal für Ihr Profil auf dem Ziel-System neu anlegen (anstatt ihn zu übertragen), dann ist das nicht ausreichend. Kanäle sind über ihre ID mit Profilen verknüpft und ein neuer Kanal bekommt eine neue ID. Sie müssten im Profil also den Kanal danach nochmal manuell zuordnen. Hinweis: Die Werte für Zusatzkennungen in den Partner-Kanälen beziehen sich auf die zentralen Zusatzkennungen (siehe Details dort). Wenn eine solche zentrale Zusatzkennung im Zielsystem nicht definiert ist, kann eine entsprechende Zusatzkennung im Kanal auch nicht erfolgreich angelegt werden (beim manuellen Export/Import eines Partner und seiner Kanäle). Sie finden dann zwar eine Zusatzkennung im Kanal, aber ohne Namen. Legt man auf dem Zielsystem manuell eine zentrale Zusatzkennung mit der selben ID an (nicht selben Namen!), wird auch in der Zusatzkennung im Kanal der Name wieder aktualisiert. Alternativ, um dieses Problem zu umgehen, können Sie den Transport Manager verwenden.

System-Konstanten auf Ziel-System

Beim Transport von Profilen werden System-Konstanten nicht ins Zielsystem übertragen. Sie müssen daher dort nochmal angelegt werden oder "manuell" oder mit dem Transport Manager übertragen werden. Zudem müssen Sie in beiden Fällen deren Werte nach der Übertragung anpassen (produktive Zugangsdaten).

Beispiel: Wie Sie vermutlich wissen, werden Datenbanken in Lobster_data über Aliase gehandhabt, hinter denen sich die eigentlichen Zugangsdaten verbergen. Nun könnten Sie auf dem Test-System den Alias so einrichten, dass er zur Test-Datenbank führt und auf dem Produktiv-System so, dass er auf die Produktiv-Datenbank zeigt. Das ist aber nicht die sauberste Lösung, weil es hier auch Verwechselungen geben kann, da die Datenbanken nicht mehr am Alias-Namen unterschieden werden können. Besser ist es, wenn Sie in Ihren Profilen nicht mehr direkt mit Aliases arbeiten, sondern mit System-Konstanten. Verwenden Sie also statt eines Aliases die System-Konstante XYZ_DB, deren Wert (der Alias) dann auf dem Test-System z. B. xyz_t ist (Alias zeigt auf die Test-Datenbank) und auf dem Produktiv-System xyz_p (Alias zeigt auf die Produktiv-Datenbank).