Transport von Profilen

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

Automatisierter Transport von Profilen mit dem Transport Manager.
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 ü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).

Manueller Export und Import von Profilen

Man kann ein Profil zusammen mit den zugehörigen Konfigurationsdateien, Makros (können ignoriert werden, siehe dort) und Testdaten als Package (.pak) exportieren und importieren. Die Konfigurationsdateien werden nur berücksichtigt, wenn ihr Dateipfad mit ./conf beginnt und als Fixwert eingetragen wurde. Verwendet der Pfad von Konfigurationsdateien Variablen, werden die Dateien nicht berücksichtigt. Wenn Funktions-Ersatzwerte definiert wurden, werden sie im Package ebenfalls exportiert.

Export

Siehe auch Abschnitt Kontextmenü Profile. Beim Exportieren kann man zwischen folgenden Optionen wählen.

(Standard, importierbar) Profil und alle Konfigurationsdateien als Package (.pak). Hinweis: Konfigurationsdateien in einem beliebigen Unterordner mit Namen _exclude_ werden nicht in .pak-Dateien aufgenommen. Damit kann gesteuert werden, dass z. B. wichtige Ersetzungsdateien nicht vom Test- zum Produktiv-System "wandern" bzw. überschrieben werden. Beispiel:./conf/sub1/_exclude_/test.txt

(veraltet, importierbar) Nur das Profil ohne Konfigurationsdateien (.obj).
(importierbar) XML-Datei (.xml). Kann auch für einen Profilvergleich (diff) verwendet werden.
(nicht importierbar) Gefeg.FX-Datei (.xml). Erzeugt nur eine Baumstruktur.
(nicht importierbar) RESTful API Modeling Language (RAML). Erzeugt nur eine Baumstruktur. Hinweis: Funktioniert nur bei Profilen mit eventgesteuertem Eingangsagent HTTP mit gesetzter Checkbox HTTP-Schnittstelle oder REST-WebService. Zudem muss das Profil eine Quellstruktur mit einem Root-Knoten haben.

Import

Siehe auch Abschnitt Kontextmenü Profile. Beim Import öffnet sich ein weiterer Dialog. Hier können Sie die Formate .pak und .obj importieren, Verwenden Sie bitte immer Format .pak.

Folgend die Einstellungsmöglichkeiten:

(1) Datei hochladen: Sie können die Export-Datei entweder direkt ins Feld ziehen oder über den Button in der Verzeichnisstruktur suchen.

(2) Als neues Profil importieren: Es wird ein neues Profil angelegt und alle Einstellungen der Export-Datei werden übernommen.

(3) Selektiertes Profil überschreiben, Name, Gruppe & ID bleiben erhalten: Das in der Profil-Übersicht markierte Profil wird mit dem Inhalt der Export-Datei überschrieben.

(4) Neues Profil anlegen und nur Strukturinformationen (Mapping) übernehmen: Es wird ein neues Profil angelegt. Es werden nur die Quellstruktur, Zielstruktur und die Variablen importiert. Die Einstellungen für den Eingangsagenten und die Antwortwege bleiben unverändert.

(5) Selektiertes Profil klonen und nur Strukturinformationen (Mapping) überschreiben: Das selektierte Profil wird geklont. Es werden nur die Quellstruktur, Zielstruktur und die Variablen importiert. Die Einstellungen für den Eingangsagenten und die Antwortwege bleiben unverändert.

Hinweis: Wenn Sie ein Package importieren, können Sie entscheiden, welche der enthaltenen Dateien Sie tatsächlich importieren möchten.

Hinweis: Erst wenn ein neues Profil nach dem Import gespeichert wird, ist es dauerhaft vorhanden. Selbes gilt auch für sonstige importierte Daten.