Beschreibung der Datei "export.yml"

Mit der export.yml-Datei können Sie verschiedene Einstellungen, Dateien und Konfigurationsprojekte aus agorum core exportieren. Beim Export entsteht eine ZIP-Datei, die Sie über das agorum core support tool in eine andere agorum core-Installation einlesen können.

Den Export ausführen

Öffnen Sie links in der Seitenleiste Explorer.

Öffnen Sie Ihr Konfigurationsprojekt und dort den Ordner yml:

Eigene Dateien/Administration/customers/<Konfigurationsprojekt>/yml

Klicken Sie die Datei export.yml mit der rechten Maustaste an.
Wählen Sie im Kontextmenü Administration > Export.

Hinweis: Die Aktion erscheint nur, wenn der Dateiname mit export beginnt und mit .yml endet.

Strukturierung

Damit der Export problemlos funktioniert, muss der Administrationsbereich folgende Struktur aufweisen:

/agorum/roi/customers/<Name der Konfiguration>

csv (csv-Dateien Projekts, etwa für Metadaten-Drop-Downs)
doc (Dokumentation des Projekts)
deploy (Skripte, Workflows, mitgelieferte Pakete …
- pre (optional, wird bei einem Export am Anfang ausgeführt)
- post (optional, wird bei einem Export am Ende ausgeführt)
js
yml
Optional: Eigene Ordner für ein Projekt, etwa Vorlagen
Optional: Test (optional, Testdateien für Tests)
Optional: Update
- pre (optional, wird für das Update am Anfang ausgeführt)
- post (optional, wird für das Update am Ende ausgeführt)
- update …

Hinweis: Werden Funktionen hinzugefügt, wird automatisch ein Eintrag in der export.yml erstellt. Dieser wird nicht chronologisch eingefügt, sondern ist abhängig von den Keywords. Besteht etwa bereits eine agorum core smart assistant-Konfiguration namens - Smart Assistant: Test1 und Sie führen die Aktion agorum core template manager > Smart Assistant AddOn hinzufügen aus(agorum core template manager - Projektabhängige Aktionen), wird diese neue Konfiguration automatisch unterhalb von Test1 eingefügt.

Besteht keine Konfiguration und damit auch noch kein Keyword in der export.yml, wird der Eintrag automatisch am Ende der Datei eingefügt.

Sie müssen die Reihenfolge Ihrer export.yml stets gründlich prüfen, bevor Sie diese ausführen.

Keywords des Exporters

Hinweis: Die Reihenfolge der Keywords ist wichtig. Das System liest von oben nach unten in die ZIP-Datei ein- und wieder aus, da bestimmte Skripte bestimmte Strukturen, etwa ACLs, voraussetzen. Diese müssen dementsprechend in der Reihenfolge vorher installiert werden.

Der Exporter wird durch Keywords in der export.yml gesteuert, die im Folgenden beschrieben werden.

Jedes Keyword kann beliebig oft verwendet werden.
Ein # an erster Stelle bedeutet, dass es sich um einen Kommentar handelt:
```
# Das ist ein Kommentar
```

Ein Keyword beginnt immer mit einem Bindestrich und endet mit einem Doppelpunkt. Danach folgen ein Leerzeichen und dann der Parameter für das Keyword.
Manche Keywords können als Parameter eine RegExp besitzen, diese sind in der Beschreibung entsprechend gekennzeichnet.
- Es gelten die allgemeinen Regeln von RegExp.
- Sonderzeichen der Elemente müssen bei RegExp maskiert werden (etwa () im Namen müssen mit \(\) maskiert werden):

- Active Folder: Test mit \(Klammer\)

Hinweis: Die Nutzung von RegExp im Exporter hat eine Besonderheit: Es werden vor Import auf dem Zielsystem alle Einträge, die auf die RegExp passen, durch den Installer gelöscht. Etwa werden bei der Definition - FileWorkflow: xyz.* alle FileWorkflows gelöscht, die mit xyz beginnen. Erst danach werden die im Paket enthaltenen Definitionen neu eingetragen, sodass keine veralteten Definitionen im System bleiben.

ac

Exportiert alle Dateien unterhalb des angegebenen Ordners aus agorum core.

Definiert Sie einen Ordner, exportiert das System automatisch alle darin enthaltenen Ordner und Dateien. Alternativ können Sie auch einzelne Dateien angeben.

Beispiel für einen kompletten Ordner

# Einen kompletten Ordner exportieren
- ac: /agorum/roi/customers/DocForm Template

Beispiel für eine einzelne Datei

# Eine einzelne Datei exportieren
- ac: /agorum/roi/customers/DocForm Template/js/demo.js

Hinweis: Das System exportiert keine Adressen oder Notizen.

sync

Gleicht alle Dateien und Verzeichnisse auf einem Zielsystem mit der Struktur, die in sync angegeben wurde, ab. D. h. Dateien / Ordner, die beim Export nicht dabei sind, werden auf dem Zielsystem entfernt. Das ist sinnvoll, wenn etwa Dateien / Ordner umbenannt / verschoben wurden. Ohne sync würden diese auf dem Zielsystem als „Leichen“ herumliegen.

Alles, was Kunden / Benutzer in der Struktur, die über sync angegeben wird, selbst angelegt haben, geht verloren.

Zuvor muss das jeweilige Verzeichnis über ac exportiert worden sein.

Beispiel für ein komplettes Verzeichnis

# Ein kompletter Ordner wird hier exportiert
- ac: /agorum/roi/customers/DocForm Template
- sync: /agorum/roi/customers/DocForm Template

Beispiel für einen Teil der Struktur

# Ein einzelnes File wird exportiert
- ac: /agorum/roi/customers/DocForm Template
- sync: /agorum/roi/customers/DocForm Template/Ein Unterverzeichnis

Package

Exportiert ein Paket (entweder selbst als ZIP-Datei oder nur mit der passenden Verzeichnisstruktur). In diesem muss alles so hinterlegt werden, wie es der ZIP-Installer für einen Import wieder benötigt. Es kann aus ac, fs, xml, js oder weiteren export.yml-Dateien bestehen.

Mit einem Package können Sie etwa Folgendes erreichen:

Strukturen per JavaScript anlegen.
ACLs und Benutzergruppen per JavaScript anlegen.
XML-Dateien ausführen.
Strukturen per ac und fs anlegen.
Weitere export.yml-Dateien in das ZIP-Archiv hinzufügen. (Pro Angabe Package wird eine ZIP erzeugt, die wiederum in der normalen ZIP-Datei liegt (ZIP in ZIP).)

Für Einzelheiten zur Struktur einer exportierten ZIP-Datei siehe Eine ZIP-Datei und ein Konfigurationsprojekt installieren.

Schreiben Sie das Package in das Verzeichnis deploy.

Beispiel 1

- Package: /agorum/roi/customers/DocForm Template/deploy/installed

Beispiel 2

- Package: /agorum/roi/customers/DocForm Template/deploy/pre

Beispiel für die Angabe weiterer yml-Dateien

- Package: /agorum/roi/customers/agorum.patent/yml/export.yml
- Package: /agorum/roi/customers/agorum.workflow.library/yml/export.yml

Smart assistant

Exportiert eine Konfiguration des agorum core smart assistants.

Beispiel

- Smart assistant: DocForm Template

Hinweis: Wenn die Konfiguration des agorum core smart assistants wieder importiert wird, werden alle Metadaten automatisch in der MetaDB angelegt, und zwar genauso, wie diese im agorum core smart assistant eingetragen sind.

Active Folder

Exportiert Aktive Ordner.

RegExp wird unterstützt.

Beispiel

- Active Folder: DocForm Template - .*

Beispiel mit maskiertem Sonderzeichen

- Active Folder: Test mit \(Klammer\)
- Active Folder: Test mit \( Klammer 2 \)

FileWorkflow

Exportiert Fileworkflows.

RegExp wird unterstützt.

Beispiel

- FileWorkflow: DOCFORM.*

MetaDb

Exportiert einen oder mehrere MetaDB-Einträge.

Beispiel mit mehreren Einträgen

# Beispiel alle Shares für smb
- MetaDb: MAIN_MODULE_MANAGEMENT/roiprotocols/smb/control/SharePoints/agorum DMS
- MetaDb: MAIN_MODULE_MANAGEMENT/roiprotocols/smb/control/SharePoints/agorum User
- MetaDb: MAIN_MODULE_MANAGEMENT/roiprotocols/smb/control/SharePoints/agorum Root

# Beispiel alle Shares für webdav
- MetaDb: MAIN_MODULE_MANAGEMENT/roiprotocols/webdav/control/SharePoints/agorum DMS
- MetaDb: MAIN_MODULE_MANAGEMENT/roiprotocols/webdav/control/SharePoints/agorum User
- MetaDb: MAIN_MODULE_MANAGEMENT/roiprotocols/webdav/control/SharePoints/agorum Root

# Dropfläche
- MetaDb: MAIN_MODULE_MANAGEMENT/client/AddOns/drop-area.js

# Cockpit - Freigabeworkflow
- MetaDb: MAIN_MODULE_MANAGEMENT/home/control/Apps/Freigabe-Dashboard (Cockpit)

# Cron-Job, um GRP_DOCFORM_World stündlich zu aktualisieren
- MetaDb: MAIN_MODULE_MANAGEMENT/cronjob/control/fillWorldGroup

# Dashboard unter Ansicht als Suche wenn man auf einem Ordner steht
- MetaDb: MAIN_MODULE_MANAGEMENT/home/control/Details/Views/500 Main/Views/900 FolderDashboard

# Service zur Passwortänderung
- MetaDb: MAIN_MODULE_MANAGEMENT/api/control/Services/Custom/Services/user

Verschlüsselte MetaDB-Keys exportieren und importieren

Achtung: Datenverlust beim Import von verschlüsselten MetaDB-Keys. Sollten Sie verschlüsselte MetaDB-Keys exportieren (diese werden im Feld <StringValue> als xxxxxxxx exportiert, siehe Beispiel) und anschließend importieren wollen und existieren diese Keys bereits im Zielsystem, überschreibt das System die dort existierenden Daten.

Beispiel

So exportieren Sie verschlüsselte Keys (im Feld <StringValue>):

<MetaDbPropertyEntryObject>
  <Name><![CDATA[jwt-secret]]></Name>
  <EntryDataType>8192</EntryDataType>
  <StringValue><![CDATA[xxxxxxxx]]></StringValue>
  <AddToFolder><![CDATA[/agorum/ngos/MetaDb/MAIN_MODULE_MANAGEMENT/customers/agorum Software GmbH/[ custom-services ]/custom-service]]></AddToFolder>
  <NoErrorIfExist/>
</MetaDbPropertyEntryObject>

Falls Sie diese Daten trotzdem übertragen und importieren möchten, gehen Sie folgendermaßen vor:

Importieren Sie bei der ersten Installation die Keys einmal verschlüsselt (Werte werden mit xxxxxxxx importiert).

Ergebnis: Die Keys werden im Zielsystem initial angelegt.
Tragen Sie danach im Zielsystem die korrekten Werte manuell in die importierten Keys ein.
Bei jeder weiteren Installation exportieren Sie die Keys nicht mehr, um die Daten im Zielsystem nicht zu überschreiben.

Metadata

Exportiert Metadaten.

Sind in diesen exportierten Metadaten UUIDs enthalten, werden diese UUIDs auf dem Zielsystem gemappt, sofern die entsprechenden Objekte auf dem Zielsystem vorhanden sind (gesucht wird nach dem Pfad der Objekte).
Der Parameter hinter dem Keyword Metadata definiert den Startordner, ab welchem die Metadaten auf den Objekten ausgelesen werden.

Für den Export der Metadaten von Objekten gelten folgende Regeln:

Die exportierten Metadaten müssen angelegt sein, etwa über die metadata.yml.
Das System exportiert nur Metadaten, die direkt auf ein Objekt gesetzt sind (siehe JavaScript-Bibliothek common-metadata).

Bei diesem Keyword kann per Parameter gesteuert werden, welche Metadaten exportiert werden sollen (Syntax siehe Filter).

Folgende Parameter sind verfügbar:

Parameter	Beschreibung	Beispiel
filter	Übergibt ein Array, in dem die Filter für die Metadaten vorgegeben werden. Wenn der Parameter nicht angegeben wird, wird der Default-Filter gesetzt: [ '~~', '~' ]. Alle vererbten ('~~') und alle nicht vererbten ('~') Metadaten werden exportiert.	[ 'area', 'identifier' ]

Beispiel 1 – ohne zusätzlichen Parameter

Exportiert alle vererbten und nicht vererbten Metadaten ab dem Ordner '/agorum/roi/Files/acso2':

- Metadata: /agorum/roi/Files/acso2

Beispiel 2 – mit Parameter „filter“

Exportiert alle Metadaten mit den vorgegebenen Namen ab dem Ordner '/agorum/roi/Files/acso2':

- Metadata: /agorum/roi/Files/acso2
  filter: [ 'area', 'identifier' ]

Beispiel 3 – mit Parameter „filter“ und RegExp-Ausdrücke

Die RegExp-Ausdrücke müssen auch als String übergeben werden.

Syntax

/<RegExp-Ausdruck>/[<Flags>]

<Flags> können optional eingegeben werden.
Wenn ein \ benötigt wird, geben Sie dieses im String mit \\ ein.

Beispiel
/\w+/ entspricht '/\\w+/ in der String-Schreibweise.

- Metadata: /agorum/roi/Files/acso2
  filter: [ '/(are|ident)/i' ]

MetaDbDefaults

Exportiert alle DataHandler, die sich in Ihrem Konfigurationsprojekt im Unterordner Data.defaults befinden.

Folgendes passiert beim Export:

Das System prüft, ob Data.defaults vorhanden ist. Wenn nicht, wird der Unterordner angelegt.
Alle DataHandler, die unter Data liegen und nicht in Data.defaults vorkommen, werden in Data.defaults verlinkt.
Danach wird ausschließlich Data.defaults exportiert.
Wenn verschiedene DataHandler mit demselben Data.defaults existieren, wird nur der DataHandler von Data.defaults exportiert.

Das Keyword wird automatisch in die export.yml gesetzt, sofern Sie den entsprechenden DataHandler über den DataHandler-Manager für Ihr Konfigurationsprojekt erstellen, es ist allerdings zu diesem Zeitpunkt noch deaktiviert, erkennbar an dem # vor der Zeile.

Für das Aktivieren siehe Keyword „MetaDbDefaults“ in export.yml aktivieren.

Wann Sie dieses Keyword einsetzen und was es dabei zu beachten gilt, siehe detaillierte Erklärung zum Verfahren anhand eines JDBC-DataHandlers.

Hinweis: Das Keyword und das unten beschriebene Vorgehen funktioniert nur bei neuen Konfigurationsprojekten, die ab agorum core 10.1.2 angelegt wurden. Für das Vorgehen bei alten Konfigurationsprojekten siehe Alte Konfigurationsprojekte anpassen / Keyword in vorhandenen Konfigurationsprojekten verwenden.

Der Eintrag des Keywords in der Datei sieht folgendermaßen aus:

- MetaDbDefaults: MAIN_MODULE_MANAGEMENT/customers/<Konfigurationsprojekt>/Data

Der Eintrag in der export.yml umfasst nur den Unterordner Data des Konfigurationsprojekts. Wird der Export dann ausgeführt, exportiert das System jedoch alle DataHandler, die sich im Unterordner Data.defaults befinden.

Beispielhaftes Verfahren bei einem JDBC-DataHandler

Das folgende Beispiel geht davon aus, dass Sie offene Bestellungen aus dem ERP-System des Kunden abrufen möchten. Für ein solches Projekt benötigen Sie einen DataHandler, der auf eine SQL-Datenbank zugreift, um diese offenen Bestellungen abzurufen. Diese Schnittstelle hat in der Regel jedoch nur Zugang zum Produktivsystem von agorum core. Das ist suboptimal für die Weiterentwicklung der Schnittstelle, da der Produktivgang nicht gestört werden darf.

Um die Schnittstelle dennoch in einem Testsystem testen und weiterentwickeln zu können, werden das Keyword MetaDbDefaults sowie ein JDBC-DataHandler benötigt. Aus dem JDBC-DataHandler erstellen Sie dann einen CSV-DataHandler mit den Originaldaten aus dem JDBC-DataHandler. Dieser CSV-DataHandler kann anstatt des realen JDBC-DataHandlers dann für die Weiterentwicklung der Schnittstelle verwendet werden.

Um das Keyword sowie den JDBC-DataHandler für diesen Zweck zu verwenden, gehen Sie folgendermaßen vor:

Installieren Sie agorum core bei Ihrem Kunden, sofern es nicht bereits installiert ist. Auf diesem System können Sie per JDBC-DataHandler auf die SQL-Datenbank des Kunden zugreifen.
Installieren Sie das Plugin agorum core template manager über den agorum core plugin manager. Dieses Plugin benötigen Sie für die nachfolgenden Schritte.
Importieren Sie das Konfigurationsprojekt in das agorum core-System des Kunden.
Legen Sie in Zusammenarbeit mit dem Kunden den JDBC-DataHandler an, der die Daten aus der SQL-Datenbank des Kunden ausliest, und legen Sie diesen im importierten Konfigurationsprojekt ab. Den JDBC-DataHandler legen Sie über den DataHandler-Manager an.

Hinweis: Entfernen Sie bei der Anlage des JDBC-DataHandlers den Haken bei Ist der DataHandler exportierbar?, damit der DataHandler in den Unterordner Data des Kundenprojekts beim Erstellen abgelegt wird.
Testen Sie den DataHandler und stellen Sie ihn so ein, wie Sie ihn benötigen, d. h. Sie stellen ein, welche Daten aus der SQL-Datenbank des Kunden abgerufen werden sollen.
Wenn der JDBC-DataHandler funktioniert und Sie Zugriff auf die SQL-Datenbank des Kunden haben, erzeugen Sie sich über den DataHandler-Manager aus dem JDBC-DataHandler einen CSV-DataHandler.

Ergebnis: Das System führt die folgenden Dinge durch:

• Es registriert einen CSV-DataHandler in der MetaDB im selben Konfigurationsprojekt im Unterordner Data.defaults. Der CSV-DataHandler hat denselben Namen wie der originale DataHandler, den Sie gewählt haben.
• Es legt eine CSV-Datei im selben Projekt im Unterordner csv.defaults/<Name des DataHandlers>.csv an.
• Es erzeugt den eingangs beschriebenen Keyword-Eintrag - MetaDbDefaults in der export.yml.
• Es erzeugt unter Eigene Dateien/Administration/workspace/<Konfigurationsprojekt>/ den Unterordner uninstall. Damit können Sie auf dem agorum core-server, auf dem das Projekt erstellt wird, die vorhergehenden Schritte wieder rückgängig machen. Bei einer Deinstallation auf MetaDbDefaults wird der Eintrag in der MetaDB mit Data.defaults gelöscht (mit allen angelegt DataHandler, die sich dort befinden). Es wird zudem der Ordner csv.defaults im Projekt und der Eintrag MetaDbDefaults aus der export.yml gelöscht.

Hinweis: Sie tragen die DataHandler im Unterordner Data nicht in die export.yml ein. Das bewirkt, dass die originalen DataHandler des Kunden nicht mitgenommen werden, sondern beim Kunden verbleiben.
Exportieren Sie das Konfigurationsprojekt über die export.yml.
Importieren Sie das Konfigurationsprojekt auf Ihrem Entwicklungssystem, auf dem Sie die Konfiguration für den Kunden erstellen.

Ergebnis: Das System importiert all Ihre DataHandler. Die CSV-DataHandler unter Data.defaults werden bei Ihrem System unter Data verlinkt. Bei einem späteren Import des Konfigurationsprojekts aufseiten des Kunden wird dann wieder der original JDBC-DataHandler verwendet.

Tipp: Zu Sicherungszwecken können Sie sich auf dem agorum core-Server des Kunden etwa eine Datei namens export-kunden-DataHandler.yml erstellen, die alle kundenspezifische DataHandler exportiert. Diese Datei führen Sie aus, um eine Sicherungsdatei mit den Einstellungen zu erstellen.

Import des Konfigurationsprojekts mit dem Keyword „MetaDbDefaults“

Folgendes passiert beim Import des Konfigurationsprojekts:

Das System prüft, welche DataHandler in Ihrem Konfigurationsprojekt im Unterordner Data.defaults existieren:
```
Eigene Dateien/Administration/customers/<Konfigurationsprojekt>/Data.defaults/<DataHandler>
```
Für jeden dieser DataHandler überprüft der Installationsprozess jetzt, ob dieser bereits in Data in der MetaDB auf dem Entwicklungssystem vorhanden ist.
```
MetaDB‎/MAIN_MODULE_MANAGEMENT‎/customers‎/<Konfigurationsprojekt>/Data
```
Existiert dieser DataHandler auf dem Zielsystem in Data nicht, verlinkt das System den DataHandler aus Data.defaults in Data. Das bedeutet, dass anstatt der Originalschnittstelle auf die CSV-Datei verwiesen wird.

Unterordner Data und Data.defaults in der MetaDB, die beim Import geprüft werden

Damit erreichen Sie Folgendes:

Auf dem System, auf dem verschiedene DataHandler mit demselben Namen in Data.defaults und Data vorhanden sind, wird immer der DataHandler aus Data verwendet, da Sie bei der Anlage des JDBC-DataHandlers den Haken bei Ist der DataHandler exportierbar? entfernt haben. Auf dem System des Kunden wird also in diesem Beispiel der JDBC-DataHandler verwendet, der auf Ihrer Entwicklungsumgebung nicht vorhanden ist. Stattdessen befindet sich dort der erstellte CSV-DataHandler, der dann in Data verlinkt ist.

Folgendes Diagramm veranschaulicht die Prozesse nochmals:

DataHandler-Diagramm

Alte Konfigurationsprojekte anpassen / Keyword in vorhandenen Konfigurationsprojekten verwenden

Wenn Sie das Keyword in vorhandenen Konfigurationsprojekten verwenden oder alte Konfigurationsprojekte anpassen möchten, die vor agorum core 10.0.11 angelegt wurden, gehen Sie folgendermaßen vor:

Verschieben Sie alle DataHandler, die Sie explizit per Keyword - MetaDb exportieren, in den Unterordner Data.defaults.
Verlinken Sie alle DataHandler im Unterordner Data.defaults händisch in den Unterordner Data.
Ändern Sie in der export.yml den Eintrag - MetaDb für diesen DataHandler in folgenden Eintrag um:
```
- MetaDbDefaults: MAIN_MODULE_MANAGEMENT/customers/<Name des Projektes>/Data
```
Ergebnis: Die Anpassung / Umstellung ist beendet.

DocForm Type

Exportiert DocForm-Typen.

RegExp wird unterstützt.

Beispiel

- DocForm Type: DOCFORM.*

DocForm Training

Exportiert DocForm Trainings-Definitionen.

RegExp wird unterstützt.

Beispiel

- DocForm Training: DOCFORM.*

QueryScript

Exportiert einen im Support-Tool definierten QueryScript-Worker.

Beispiel

- QueryScript: MyQueryScript

ScriptWorker

Exportiert einen im Support-Tool definierten ScriptWorker.

Beispiel

- ScriptWorker: MyScriptWorker

MapUUIDs

Verlinkungen innerhalb von HTML-Dateien auf andere Objekte oder Bilder werden intern über UUIDs geregelt. Würden Sie solche Dokumente exportieren und in einem anderen System wieder einspielen, würden die Verlinkungen ins Leere laufen, da die UUIDs der Zielobjekte andere wären.

Mit dem Keyword MapUUIDs definieren Sie, dass diese Verweise beim Import korrigiert werden.

Der Parameter hinter MapUUIDs definiert den Startordner, ab welchem das Ersetzen der UUIDs stattfinden soll, in diesem Beispiel unterhalb des Projektes im Verzeichnis docs.
MapUUIDs beachtet Verweise, die auch außerhalb des Pakets liegen. Dazu muss sichergestellt sein, dass die Objekte auch im Zielsystem bezogen auf die Ordner genau dort liegen, wo sie im Quellsystem waren.

Beispiel

- MapUUIDs: /agorum/roi/customers/DocForm Template/docs

Parameter „extensions“

Verarbeitet zusätzliche Textdateien.

Wenn Sie den Parameter nicht angeben, berücksichtigt d0as System nur die Dateiendungen htm oder html,

Beispiel

- MapUUIDs: /agorum/roi/customers/DocForm Template/templates
  extensions:
    - ad-hoc-template

Workflow

Deployt einen Workflow beim Import.

Geben Sie immer den vollen Pfad des Workflows an oder einen Ordner, der mehrere Workflows enthält.

Beispiel 1

- Workflow: /agorum/roi/customers/agorum.workflow.test/workflows/agorum.workflow.test.test1

Deployt nur den Workflow agorum.workflow.test.test1, weil nur dieser angegeben ist. Sie können auch alle Workflows unterhalb eines Pfads mit einem Keyword deployen.

Beispiel 2

- Workflow: /agorum/roi/customers/agorum.workflow.test/workflows

Deployt alle Workflows (rekursiv), die unterhalb des vorgegebenen Pfads liegen.

Den Export aktualisieren

Soll nur ein kleiner Teil exportiert werden, legen Sie eine eigene export_update.yml an. In dieser werden nur die notwendigen Inhalte exportiert, wodurch der Prozess deutlich schneller geht. Bei einem vollständigen Export müssen diese Inhalte dann aber ebenfalls inkludiert werden.

Benutzer, Benutzergruppen und ACLs per export.yml exportieren

Benutzer, Benutzergruppen und ACLs können Sie nicht per export.yml exportieren. Um diese von einem System auf ein anderes zu überführen, müssen Sie diese stattdessen per JavaScript angelegen. Dazu erstellen Sie ein JavaScript im Pfad des Super-Administrators roi:

Eigene Dateien/Administration/customers/<Ihr Projekt>/deploy/pre/js

Die Objekte (Benutzer, Benutzergruppen, ACLs) erstellen Sie durch die JavaScript-Bibliothek common-objects.

Bestimmte Skripte bei einer Installation ausführen

Möchten Sie, dass das Zielsystem ausschließlich bestimmte Skripte bei einer Installation der exportierten ZIP-Datei ausführt, etwa ein Skript, das auf dem Zielsystem die Ordnerstrukturen, Berechtigungen und Benutzergruppen löscht, gehen Sie folgendermaßen vor:

Erstellen Sie eine zweite export.yml mit den Keywords ac und Package:
```
- ac: /agorum/roi/customers/<Konigurationsprojekt>

- Package: /agorum/roi/customers/<Konigurationsprojekt>/deploy/secondExport
```
Das auszuführende Skript muss im Ordner deploy/secondExport/js liegen, wobei der Ordner secondExport als Beispiel dient und auch anders lauten kann. Bei Installation des ZIP-Pakets führt das Zielsystem ausschließlich die enthaltenen Skripte innerhalb des Ordners secondExport aus.

Beispiel eines kompletten Exports

Tipp: Schreiben Sie Kommentare mit #, damit sich andere schneller in das Projekt einarbeiten können.

# Wichtig: Die einzelnen Skripte müssen in der Reihenfolge exportiert werden, die für den Import benötigt wird

### ac - Files die in den ZIP-Installer eingebunden werden ###

- ac: /agorum/roi/customers/DocForm Template

### Package - Erstellt ZIP-Paket, dass bei Import installiert wird ###

- Package: /agorum/roi/customers/DocForm Template/deploy/installed

### Smart Assistant - Konfiguration exportieren ###

- Smart Assistant: DocForm Template

### Package - weitere Pakete werden in den Installer eingebunden ###

- Package: /agorum/roi/customers/DocForm Template/deploy/agorum core Mailarchiv.zip
- Package: /agorum/roi/customers/DocForm Template/deploy/pre

### Aktive Ordner werden angelegt ###

- Active Folder: xyz ablegen (verarbeiten)
- Active Folder: DocForm Template - .*
- Active Folder: Test mit \(Klammer\)
- Active Folder: Test mit \( Klammer 2 \)

### FileWorkflows - Exportiert die angegebenen Fileworkflows ###

- FileWorkflow: xyz.*
- FileWorkflow: Deckblatt
- FileWorkflow: Fahrzeugakte finalisieren
- FileWorkflow: Dynamisch ablegen Eingangsrechnungen
- FileWorkflow: DOCFORM.*

### MetaDb - gekürzt, s. obiges eigenes Beispiel zur MetaDb ###

- MetaDb: MAIN_MODULE_MANAGEMENT/roiprotocols/smb/control/SharePoints

- MetaDb: MAIN_MODULE_MANAGEMENT/client/AddOns/drop-area.js

- MetaDb: MAIN_MODULE_MANAGEMENT/home/control/Apps/Freigabe-Dashboard (Cockpit)

- MetaDb: MAIN_MODULE_MANAGEMENT/api/control/Services/Custom/Services/user

- MetaDbDefaults: MAIN_MODULE_MANAGEMENT/customers/MeinKonfigurationsprojekt/Data

### DocForm - Typen - Ein oder mehrere Typen werden ausgelesen und im Installer eingetragen ###

- DocForm Type: Deckblatt

# Gilt für alle DocForm Typen, die mit xyz_.* beginnen
- DocForm Type: yxz_.*

### DocForm - Training ###

- DocForm Training: xyz_Rechnung-abc Ag
- DocForm Training: DOCFORM.*

### Package ###
# aus dem folgenden Verzeichnis wird ein weiterer ZIP-Installer generiert und in den jetzigen Installer eingetragen

- Package: /agorum/roi/customers/DocForm Template/deploy/post