Mit der d.3 Version 8.0 gibt es nicht nur optische Veränderungen in d.3 admin (siehe Kapitel Starten von d.3 admin ), sondern auch neue Menüpunkte und Begriffe, deren Bedeutung hier näher erklärt wird.

Projekt

Ein Projekt ist eine Sammlung von Meilensteinen und dient der Aufzeichnung von Änderungen von Repository-Stammdaten wie Dokumentarten oder erweiterte Eigenschaftsfelder sowie von Änderungen an Konfigurationsschaltern. Ein Projekt hat einen Namen und einen optionalen Beschreibungstext. Jedes Projekt hat einen Status: Entweder "offen", was bedeutet, dass man Änderungen innerhalb dieses Projektes aufzeichnen kann oder "geschlossen", was jegliche Aufzeichnung von Änderungen verhindert. Ein einmal geschlossenes Projekt kann nicht mehr geöffnet werden und wird per Standard nicht in d.3 admin angezeigt werden.

Meilenstein

In einem Meilenstein werden Änderungen an den Repository-Stammdaten bzw. an Konfigurationsschaltern aufgezeichnet und können auf ein anderes d.3-Repository übertragen werden. Meilensteine werden, von 1 beginnend, aufsteigend durchnummeriert und tragen den Namen "Meilenstein <Nummer>". Jeder Meilenstein hat einen Status. Entweder "offen", was bedeutet, dass Änderungen in diesem Meilensteinen aufgezeichnet werden können oder "geschlossen", was jegliche Aufzeichnung von Änderungen in diesem Meilenstein verhindert. Ein einmal geschlossener Meilenstein kann nicht mehr geöffnet werden.

Import

Mit der Import-Funktion können aufgezeichnete Änderungen von Projekten oder Meilensteinen aber auch aus Backups bzw. Snapshots in das d.3-Repository eingespielt werden. Vor jedem Import wird eine Sicherung gemacht, wodurch ein Meilenstein im Snapshot-Projekt entsteht.

Export

Über die Export-Funktion können ausgewählte Projekte oder Meilensteine in Form von ZIP-Dateien aus dem d.3-Repository exportiert werden. Diese Dateien können dann über die Import-Funktion in ein anderes d.3-Repository übertragen werden.

Backup

Ein Backup enthält die kompletten Stammdaten und Konfigurationsparameter des d.3-Repositorys und kann zum Rollback eines bestehenden oder zum Neuaufbau eines neuen d.3-Repositorys verwendet werden. Ein Backup kann entweder automatisiert oder aber explizit erstellt werden. Die so erzeugte Datei trägt die Dateierweiterung ".d3backup".

Snapshot

Ein Snapshot enthält die gleichen Daten wie ein Backup und wird automatisch durch einen Import-Vorgang erzeugt. Snapshots werden in einem eigenen Projekt mit dem Namen "Snapshot" verwaltet, wobei das Projekt den Status "geschlossen" hat. Jeder Snapshot ist dabei ein Meilenstein innerhalb des Snapshot-Projektes.

Transport

Ein Transport ist eine Datei, die durch die Export-Funktion erzeugt wird und die Dateierweiterung .d3trans trägt. Ein Transport kann durch die Import-Funktion in ein anderes d.3-Repository eingespielt werden. Der Transport ist für stetigen Austausch zwischen Test- und Produktivsystem gedacht, das Backup dient eher zur eigentlichen Datensicherung.

Bearbeitungsmodus

In diesem Modus können Änderungen an Stammdaten und Konfigurationsparameter in d.3 admin durchgeführt und aufgezeichnet werden. Pro Projekt kann nur ein Administrator in den Bearbeitungsmodus wechseln.

Ansichtsmodus

In diesem Modus können keine Änderungen vorgenommen werden. Alle Module innerhalb d.3 admin werden in einem Readonly-Modus gestartet.

Sitzungen

Wenn ein Administrator zu einem Projekt in den Bearbeitungsmodus wechselt, wird eine Sitzung auf dieses Projekt eröffnet. Pro Projekt kann es nur eine Sitzung geben und ein Administrator kann immer nur eine Sitzung geöffnet haben. Nach einer Stunde Inaktivität kann die Sitzung durch einen anderen Administrator geschlossen werden.

Objekttyp

Objekttypen werden im Protokoll zu einem Meilenstein in d.3 admin angezeigt und kennzeichnen den Typ eines Stammdatenobjektes, z.B. eine Dokumentart oder ein Eigenschaftsfeld.

Aktion

Aktionen werden im Protokoll zu einem Meilenstein in d.3 admin angezeigt und kennzeichnen, ob ein Objekt hinzugefügt (INSERT), aktualisiert (UPDATE) oder gelöscht (DELETE) wurde.

Synchronisations-ID

Jedes Stammdatenobjekt bekommt beim ersten Start von d.3 admin nach dem Update auf die d.3-Version 8 eine Synchronisations-ID zugewiesen, die als Referenz für die Übertragung von Transportdaten in andere d.3-Repositorys verwendet wird. Damit kann die Synchronität der Stammdaten zwischen den d.3-Repositorys gewährleistet werden.

Aufzeichnung der Änderungen

Änderungen, die ein Administrator im Bearbeitungsmodus vornimmt, werden innerhalb eines Meilensteines gespeichert und somit für den Transport in ein anderes d.3-Repository aufgezeichnet. Nicht alle Änderungen können aufgezeichnet, im Protokoll angezeigt und transportiert werden.

Wie arbeite ich mit Projekten und Meilensteine, wie starte ich damit nach einem Update?

Die allgemeine Arbeit mit Projekten und Meilensteinen wird in den vorherigen Kapiteln erklärt.

Wenn nur ein Repository betrieben wird, legt man nach dem Update Projekte an und kann dann Änderungen über den Bearbeitungsmodus vornehmen.

Wenn man 2 Repositorys betreibt, die den gleichen Aufbau haben und bisher immer synchron gehalten wurden, hat man 2 Möglichkeiten:

Wenn man mehrere Repositorys betreibt, die einen unterschiedlichen Aufbau haben, bleibt nur der Weg, ein neues Repository auf Basis einer Datensicherung aufzubauen.

Welche Voraussetzungen müssen gegeben sein damit das Transportsystem genutzt werden kann?

Was wird vom Transportsystem abgedeckt?

Folgende Stammdatenobjekte werden vom Transportsystem berücksichtigt:

Folgendes muss somit noch nachträglich angepasst werden:

Initialer Transport vs. Folgetransport

Was ist zu beachten, bei dem initialen Import? / Was ist bei dem Export für den initialen Import zu beachten?

Der initiale Import, also der Import in ein leeres Repository, kann entweder über eine Backup-Datei (Datensicherung) oder über einen Projekt- bzw. Meilenstein-Import erfolgen. Beim Export für einen initialen Import muss nur dann etwas bedacht werden, wenn das Quellsystem schon vor Version 8 aufgesetzt wurde und somit schon administrative Änderungen vor dem Update stattgefunden haben, und zwar folgendes: Der Meilenstein-Export enthält nur die Änderungen an den Stammdaten, die explizit durchgeführt werden. Dabei werden auch die Abhängigkeiten zu anderen Objekten berücksichtigt. Allerdings werden andere Objekte, die nicht in die Abhängigkeiten fallen, unberücksichtigt gelassen. Möchte man diese Objekte ebenfalls in den Export aufnehmen, muss man entweder "Schein-Änderungen" (mittels Durchklicken der Objekte) ausführen oder aber mittels des "d.3 project manager"-Plugins die Objekte gezielt einem Projekt und damit dem aktuellen Meilenstein zuordnen.

Wie gehe ich mit parallelen Projekten um?

Benutzung der gleichen Eigenschaftsfelder (z.B. Datum oder Name)/Benutzung von gleichen Wertemengen (z.B. Ja/Nein)? / Was ist zu beachten, wenn Projekt 1 z.B. die Eigenschaft angelegt hat, aber Projekt 2 zuerst produktiv gesetzt wird?

Beim Export wird immer der aktuelle Stand der Daten berücksichtigt und zusätzlich der Zeitpunkt der letzten Änderung am Objekt festgehalten. Dies wird beim Import dann berücksichtigt, so dass eine ältere Änderung keine neuere überschreibt.

Was ist beim Entfernen von Dokumentarten, Eigenschaften, etc. zu beachten?

Prinzipiell nichts.

Wenn man in Projekt 1 eine Dokumentart löscht, die in Projekt 2 vorher geändert wurde, würde beim Import folgendes ablaufen:

Wird Projekt 2 vor Projekt 1 importiert, würde die Dokumentart zunächst einmal erstellt bzw. geändert. Wenn dann Projekt 1 importiert wird, wird die Dokumentart gelöscht.

Wird Projekt 1 vor Projekt 2 importiert, würde die Dokumentart gelöscht bzw. nicht berücksichtigt. Wenn dann Projekt 2 importiert wird, wird die Dokumentart nicht angelegt.

Wie funktioniert der Transport rein technisch? Was wird wie exportiert und importiert?

Export

Beim Schließen eines Meilensteines wird der aktuelle Stand der Stammdatenobjekte (z.B. einer Dokumentart), die im Bearbeitungsmodus des Meilensteines geändert wurden erfasst und in eine XML-Datei geschrieben. Dabei werden alle Abhängigkeiten (z.B. die erweiterten Eigenschaften zur Dokumentart) berücksichtigt und vorweg in die XML-Datei geschrieben. Zudem wird der Zeitstempel der letzten Änderung (dabei ist es egal, ob das Objekt innerhalb des Meilensteines, der gerade geschlossen wird, ober in einem anderen geändert wurde) in die XML-Datei aufgenommen. Dieser Zeitstempel dient dann beim Import dazu, dass ältere Änderungen neuere nicht überschreiben. Die so erstellte XML-Datei wird vom Master-Async in die Dokumentart "Audit-Log" importiert.

Wird nun ein Meilenstein exportiert, wird die XML-Datei heruntergeladen und in eine ZIP-Datei aufgenommen. Diese ZIP-Datei enthält noch weitere Steuerdateien.

Man kann auch mehrere Meilensteine auf einmal exportieren (Achtung: Die Liste der Meilensteine kann nur von einem Projekt sein und muss durchgängig, also lückenlos sein). Auch ein ganzes Projekt kann exportiert werden, wobei hier nur die geschlossenen Meilensteine berücksichtigt werden.

Import

Vor dem Import findet zunächst eine Konsistenzprüfung der Daten aus der ZIP-Datei statt. Dabei wird zu jeder Datei ein Hash-Wert berechnet und mit den Hash-Werten aus der .hash-Datei abgeglichen. Eine Änderung der Dateien ist somit nicht gestattet um sicherstellen zu können, dass der Import nach den Regeln des Transportsystems stattfindet. Wenn die .hash-Datei nicht existiert, kann kein Import durchgeführt werden.

Beim Import werden die Objekte nach ihrem Vorkommen in den XML-Dateien verarbeitet. Wenn Stammdatenobjekte schon existieren, wird der Zeitpunkt der letzten Änderung im Zielsystem mit dem in der XML-Datei abgelegten Zeitpunkt der letzten Änderung aus dem Quellsystem verglichen. Wenn der Zeitpunkt aus der XML-Datei jünger ist als der im Zielsystem, wird das Objekt mit den Daten aus der XML-Datei aktualisiert.

Wenn beim Import irgendein Fehler auftritt, wird der komplette Import-Vorgang abgebrochen und alle Änderungen verworfen.

Wie ist die empfohlene Vorgehensweise wenn mehrere Umgebungen im Einsatz sind (Testsystem, Abnahmesystem, Produktivsystem)?

Ausgangspunkt sollte immer ein System (also hier das "Testsystem") sein. Hier werden die Änderungen an den Stammdatenobjekten vorgenommen. Anhand eines Exports aus dem Testsystem werden die Daten dann in das Abnahmesystem übertragen. Änderungen sollten dann wieder im Testsystem vorgenommen werden. Passt alles für einen Import in das Produktivsystem, wird das über das Testsystem heraus gemacht, wobei aber auch ein Export aus dem Abnahmesystem möglich wäre.

Installation der Basis-Workflows

Die Installation der Basis-Workflows kann folgendermaßen durchgeführt werden:

Möchte man nun nach der Installation des Basis-Workflows in einem Testsystem diesen auch im Produktivsystem einrichten, nimmt man den Export des Meilensteines, in dem man die Einrichtung der Stammdatenobjekte im Testsystem vorgenommen hat und transportiert diese in das Produktivsystem. Der Installationsbenutzer wird dabei aber nicht berücksichtigt und muss im Produktivsystem "per Hand" angelegt werden. Danach kann man dann für das Produktivsystem das Setup des Basis-Workflows ausführen.

Änderungen im Zielsystem

Es ist auch weiterhin in einem "Produktivsystem", also dem Zielsystem von Transportdateien möglich, Änderungen vorzunehmen. Allerdings muss man darauf verzichten, Änderungen an Stammdaten vorzunehmen, die über das Transportsystem angelegt wurden. Allerdings fallen im Produktivsystem auch Änderungen an Benutzern oder an d.3-Parametern an. Um solche Änderungen durchführen zu können, kann man sich ein "Notfall-Projekt" anlegen und die Änderungen innerhalb dieses Projektes durchführen. Im Regelfall wird man in der Protokollansicht keine Einträge finden, da z.B. Benutzer oder bestimmte d.3-Parameter nicht transportabel sind und somit nicht aufgezeichnet werden.