Zielgruppe BetriebVersion: GSB10.0Contentpatch
Der Export und Import unterstützt einen Ex- bzw. Import eines gesamten GSB-Mandanten. Häufig müssen aber gerade bei der Entwicklung bzw. Anpassung eines Mandanten nur einzelne Dokumente eines Mandanten geändert werden. Um diese Dokumente dann von einem GSB-System (bspw. dem Entwicklungssystem) auf ein anderes GSB-System (bspw. einem Staging- oder Produktivsystem) zu übertragen, kann ein sogenannter Contentpatch erstellt werden.
1 Einleitung
Ein Contentpatch beinhaltet nur eine Teilmenge eines GSB-Mandanten. Die in dem Patch enthaltenen GSB-Dokumente ersetzen bei Einspielung in das GSB-Contentrepository des Zielsystems die im Mandanten vorhandenen Stände der Dokumente. Dokumente, die im Patch neu enthalten sind, werden im Contentrepository erstmalig (in der Version eins) angelegt.
Hinweis: |
---|
Bei der Einspielung eines Contentpatches im Contentrepository wird die Linkkonsistenz natürlich geprüft und sichergestellt. D.h. wenn ein Dokument im Contentpatch Referenzen auf ein anderes Dokument enthält, welches weder im Repository noch im Contentpatch vorhanden ist, dann kann der Patch nicht eingespielt werden. Die Prüfung der Linkkonsistenz wird bei der Einspielung des Contentpatches als erstes durchgeführt. Werden hier Inkonsistenzen erkannt, dann wird der Import des Patches abgebrochen. So wird sichergestellt, dass die Linkkonsistenz im Content des Mandanten gewahrt bleibt. |
2 Erstellung Contentpatch
Bei einem Contentpatch handelt es sich, wie in der Einleitung skizziert, um eine Sammlung von GSB-Dokumenten. Die im Patch enthaltenen Dokumente werden in einem Dokument vom Typ Konfiguration-Linkliste
(technischer Name ConfigLinkList
) in der Property Wert
(technischer Name value
) zusammengestellt. Das Contentpatch-Dokument kann innerhalb des GSB-Mandanten in einem beliebigen Ordner und mit einem beliebigen Dokumentnamen angelegt werden.
Der folgende Screenshot skizziert dies anhand eines exemplarischen Cotentpatches (Dokumentname ContentPatch
mit drei Dokumenten (Bundesamt-Node, -Target und -Content).
Nachdem das oben beschriebene Contentpatch-Dokument erstellt worden ist, kann der Patch exportiert werden. Hierzu wird die Dokument-ID des Contentpatch-Dokumentes benötigt. Die ID kann am einfachsten über den GSB Editor "Informationen anzeigen" ermittelt werden. Der folgende Screenshot skizziert dies exemplarisch anhand des oben beschriebenen ContentPatch
-Dokumentes. Die für den Export benötigte Dokument-ID ist hierbei blau markiert.
Nachdem jetzt die Dokument-ID bekannt ist, kann der Patch mittels des folgenden REST
-Aufrufs gegen das Contentrepository des Redaktionssystems exportiert werden:
http://repository.preview.example.com:6001/repository/content/exporter/contentpatch/<DOCUMENT-ID>
Das Token <DOCUMENT-ID>
muss hierbei durch die Dokument-ID des Patches ersetzt werden. Der Servername und -port des Repositories müssen ggf. an die auf der jeweiligen Hostingplattform verwendeten Werte angepasst werden. Der skizzierte Beispielaufruf verwendet die Werte der im Release enthaltenen exemplarischen Beispielkonfiguration.
Der folgende Aufruf exportiert den Contentpatch mit dem Kommando curl
und legt diesen unter dem Namen ContentPatch.zip
im aktuellen Verzeichnis ab:
curl -o ContentPatch.zip http://repository.preview.example.com:6001/repository/content/exporter/contentpatch/be392da8-b747-49ac-b3b5-20b4acde6047
Der Export des Contentpatches besteht aus einer Zip-Datei in der alle im Patch enthaltenen Dokumente sind. Der oben skizzierte Beipspiel-Contentpatch enthält somit die folgenden Dateien:
# unzip -l ContentPatch.zipArchive: ContentPatch.zip Length Date Time Name--------- ---------- ----- ---- 6518 10-18-2018 17:17 standardlsg/DE/Bundesamt/bundesamt.xml 2726 10-18-2018 17:17 standardlsg/DE/Bundesamt/bundesamt_node.xml 776 10-18-2018 17:17 standardlsg/DE/Bundesamt/bundesamt_target.xml 1236 10-18-2018 17:17 standardlsg/SiteGlobals/ContentPatch.xml--------- ------- 11256 4 files
Der exportierte Contentpatch enthält neben den im Contentpatch enthaltenen Dokumente auch das Contentpatch-Dokument. Beim Import des Contentpatches wird dieses Dokument ebenfalls mit importiert, so dass auf dem Zielsystem der Patch ebenfalls vorhanden ist. Damit wird die weitere Bearbeitung (bspw. der anschließenden Freigabe und Publikation) der Dokumente des Contentpatches erleichtert.
Hinweis: |
---|
Wenn nur ein Dokument exportiert werden soll, muss kein Contentpatch-Dokument erstellt werden. Stattdessen kann das betreffende Dokument direkt mit dem oben skizzierten Aufruf unter Angabe der Dokument-ID des zu exportierenden Dokumentes exportiert werden. |
3 Einspielung Contentpatch
Auf dem Zielsystem wird der Contentpatch dann in das Contentrepository mit dem folgenden REST
-Aufruf eingespielt:
http://repository.preview.example.com:6001/repository/content/importer/zip/execute
Der REST
-Aufruf ist noch mit folgenden Form-Parameter zu parametrieren:
file
enthält den Namen des zu importierenden Contentpatch Zip-Filespublish
gibt an, ob die im Patch enthaltenen Dokumente nach dem Import direkt publiziert werden sollen (erlaubte Werte:true
oderfalse
)
Der Import kann bspw. mit dem folgenden Curl-Aufruf durchgeführt werden:
curl -F "file=@<CONTENTPATCH_ZIP>" -F "publish=<PUBLISH>" http://repository.preview.example.com:6001/repository/content/importer/zip/execute
Die beiden Tokens <CONTENTPATCH_ZIP>
und <PUBLISH>
müssen hier noch individuell angepasst werden.
Um den im Kapitel "Erstellung Contentpatch" exemplarisch skizzierten Patch zu importieren, ohne dass die importierten Dokumente publiziert werden, ist der folgenden Aufruf zu verwenden.
curl -F "file=@ContentPatch.zip" -F "publish=false" http://repository.preview.example.com:6001/repository/content/importer/zip/execute