Das Deployment der Arbeitsblätter, Verbindungen und Verzeichnisse erfolgt nicht aus der GUI heraus, sondern per Shell Script oder Webservice Aufruf. Dises ermöglicht das Deployment zu automatisieren und in bestehende Deployprozesse aufzunehmen.
Die kleinste Deploymenteinheit bei Transformation ist ein Arbeitsblatt.
Während des Deployments wird die Gültigkeit eines Arbeitsblattes gepüft und es wird im Fehlerfall abgewiesen.
Der Linux datasqill user bietet in seinem bin Verzeichnis mit deploySheet.sh die Funktionalität für das Deployment von Repository Daten.
Diese Script hat folgende Aufrufsyntax:
deploySheet.sh --url URL --test --verbose --option OPTIONS --file FILE
--url URL: Angabe der URL zum Service vom datasqill server. Per default
wird die Verbindung datasqill_server per getkey verwendet.
Dort ist in der Regel http://localhost:17491/datasqill-server/service hinterlegt
--test: Teste nur das Deployment. Gleiche Wirkung wie --option {"dryRun" : "true"}
--verbose: zeigt an welche Parameter effektiv verwendet werden
--file FILE: Angabe des Dateinamens vom zu deployenden Objektes. Per default wird stdin verwendet.
--option OPTIONS: Angabe eines JSON mit den Optionen
OPTIONS ist ein JSON mit umschließenden geschweiften Klammern welches die folgenden Attributpaare enthalten kann:
{
"validate" : "true",
"dryRun" : "false",
"intoFolder" : null
}
Die angegebenen Werte bei den Optionen stellen den Defaultwert der Option dar.
Wird validate auf "false" gesetzt, dann wird die Datei ohne Prüfung deployed.
Achtung: Nicht validierte Arbeitsblätter können dazu führen, dass fehlende Angaben von Quelltabellen zur falschen Ausführungsreihenfolge führen.
Bei dryRun auf "true" wird die Datei nur geprüft (und wenn angegeben validiert), aber nicht effektiv in das Repository aufgenommen.
Gibt man bei intoFolder eine existierende ID eines Transformationsverzeichnisses an, dann wird das Arbeitsblatt als neues Arbeitsblatt in das angegebene Verzeichnis kopiert. Alle vorhandenen IDs der Objekte, Transformationen, Arbeitsblatt, usw. werden neu vergeben.
Achtung: Diese Option ist nur auf dem Repository der Entwicklungsumgebung möglich.
Als Quelldateien können alle Objekte im dsr (datasqill repository) Format verwendet werden. Diese Dateien basieren auf HJSON.
Somit können mit dem gleichen Befehl Arbeitsblätter, Verbindungen und Verzeichnisse deployed werden.
Ein Beispielaufruf könnte so aussehen
$ deploySheet.sh --option '{"validate":true,"dryRun":false,"intoFolder":20791}' --file Sheet.dsr
Deployment without errors
Analog kann das Deployment per Webservice erfolgen.
Der payload vom Service hat folgendes Format:
{
"command" : "DeployRepository",
"payload" : {
"content" : "{\nversion: 1\n transformationData:\n {\n sheets:\n [\n {\n id: 2851\n attributes:\n {\n documentation: Sonderzeichen \" : { } []\n name: Deployment via Service\n order: DEPLOYMENT VIA SERVICE\n folder_id: 1158\n folder: /Manual\n }\n nodes:\n [\n {\n id: 2853\n type: 0\n layout:\n {\n x: 340\n y: 230\n width: 160\n height: 30\n }\n attributes:\n {\n module: Virtual\n documentation: null\n name: Übertrage\n action: null\n }\n }\n {\n id: 2852\n type: 1\n layout:\n {\n x: 340\n y: 180\n width: 160\n height: 30\n }\n attributes:\n {\n field1: Quelle\n field2: null\n field3: null\n objectTypeId: 3\n connectionId: 0\n dependency: Y\n }\n }\n {\n id: 2854\n type: 1\n layout:\n {\n x: 340\n y: 280\n width: 160\n height: 30\n }\n attributes:\n {\n field1: Ziel\n field2: null\n field3: null\n objectTypeId: 3\n connectionId: 0\n dependency: Y\n }\n }\n ]\n edges:\n [\n {\n id: 2855\n from: 2852\n to: 2853\n }\n {\n id: 2856\n from: 2853\n to: 2854\n }\n ]\n }\n ]\n }\n}",
"deployOptions" : {
"validate" : "true",
"dryRun" : "false",
"intoFolder" : null
}
}
}
Die Optionen in deployOptions sind genauso zu verwenden, wie bereits im vorherigen Abschnitt beschrieben.
Im Feld content steht das gesamte zu deployende (HSON) Objekt (z.B. ein Arbeitsblatt) als JSON String.
Ein einfaches Arbeitsblatt sieht im HJSON folgendermaßen aus:
{
version: 1
transformationData:
{
sheets:
[
{
id: 2857
attributes:
{
documentation: null
name: Small Sheet
order: SMALL SHEET
folder_id: 1158
folder: /Manual
}
nodes:
[
{
id: 2859
type: 0
layout:
{
x: 320
y: 120
width: 160
height: 30
}
attributes:
{
module: Virtual
documentation: null
name: dummy
action: dummy
}
}
]
}
]
}
}
Um es zu deployen, muss es in einen JSON String umgewandelt werden.
Dieses erfolgt im Java z.B. mit der Klasse JsonStringEncoder aus der Jackson Bibliothek und der Methode quoteAsString:
static String sheetToString(String sheetFileName) throws Exception {
JsonStringEncoder e = JsonStringEncoder.getInstance();
try (FileInputStream fis = new FileInputStream(sheetFileName)) {
String unquoted = streamToString(fis);
return new String(e.quoteAsString(unquoted));
}
}
Um es unter Linux z.B. mit curl zu veschicken, muss das dsr-Objekt vorher konvertiert werden.
Hier ein Script, um die Datei zu konvertieren und via curl zu deployen:
#!/bin/bash
head='{"command" : "DeployRepository","payload" : {"content" : "'
tail='","deployOptions" : {"validate" : "true","dryRun" : "false","intoFolder" : null}}}'
content=$(cat "$1" | sed 's,\r,,g;s,\\,\\\\,g;s,",\\",g' | awk -v ORS='\\n' '1')
echo "$head $content $tail" | curl -v --request POST --header "Content-Type: application/json" --data-binary @- $(getkey datasqill_server)
Im content werden Windows CR entfernt, doppelte Anführungszeichen und backslashes escaped. Weiter werden Zeilenumrüche mit dem backslash escaped.
Es wird hier getkey verwendet um an die Webadresse des datasqill Services zu kommen. Man kann ihn auch direkt angeben.
Datenstrukturen und statische Inhalte im datasqill Repository werden mit dem Shell Script deploySchema.sh deployed. Diese Funktionalität wird bei der Installation oder Update von datasqill verwendet.
Mit jedem Update von datasqill wird eine Datei mitgeliefert, die mit deploySchema.sh das datasqill Repository von einer beliebigen vorherigen Version auf die aktuelle Version aktualisiert.