Datenformat und Datenquellen

Die Konfigurationsdateien werden im JSON-Format bereitgestellt. Diese Daten können entweder in Dateiform oder in der internen Verwaltungsdatenbank gespeichert werden.

Für den Programmstart wird immer eine Datei benötigt (siehe Programmausführung). Diese Datei muss mindestens die Konfigurationseigenschaften für die Datenbankverbindung enthalten, aus der die übrigen Daten geladen werden.

Wenn in den Konfigurationsdaten Referenzen auf weitere Konfigurationen enthalten sind, gelten abhängig von deren Quelle diese Syntaxen (URI-Schemata). Das URI-Schema für Dateien folgt einem allgemeinen Standard. Das URI-Schema für datenbankbasierte Konfigurationen ist eine proprietäre Erweiterung.

Syntax	Beschreibung
`file:///{Dateipfad}` oder `file://{Server}/{Dateipfad}`	Die erste Variante (`file:///{Dateipfad}`) wird für lokale Dateien genutzt. Die Syntax enthält einen absoluten oder relativen Dateipfad oder nur den Dateinamen. Beispiele: `file:///c:/data/myConfig.json` `file:///data/myConfig.json` `file:///myConfig.json` Als Basis zur Auflösung eines relativen Pfades wird der Ordnerpfad der übergeordneten Konfiguration genutzt. Auf oberster Ebene ist das der Ordnerpfad der Startkonfigurationsdatei. Die zweite Variante (`file://{Server}/{Dateipfad}`) ist für Netzwerkfreigaben auf einen anderen Server vorgesehen und mit einem UNC-Pfad vergleichbar. Der Dateipfad-Teil setzt sich zusammen aus `{Freigabename}/{Dateipfad}`. Alte Konfigurationen unterstützen nur die Dateiform und keine URI-Syntax. Für die Kompatibilität mit diesen alten Konfigurationen, ist die Angabe des reinen Dateipfades ohne URI-Präfix zulässig. Die Angabe der Dateiendung `.json` ist optional.
`db://{Name}[/{Stadium}[/{Version}]]`	Konfigurationen, die in der Datenbank gespeichert sind, unterliegen einer Versionierung. Außerdem wird zwischen den Stadien "Entwicklung", "Test" und "Produktion" unterschieden. Hinweis Weitere Informationen zur Nutzung der Versionierungslogik finden Sie unter Konfigurator. Bei der Angabe einer Referenz ist der eindeutige technische Name der Konfiguration zwingend erforderlich. Das Stadium und die Version sind optionale Komponenten. Diese beiden Komponenten sind voneinander abhängig, d.h. die Angabe eines Stadiums ohne Version ist möglich, aber die Angabe einer Version ohne Stadium ist nicht zulässig. Die technischen Kennzeichner für die Stadien sind `Dev`, `Test` und `Prod`. Eine Versionsnummer setzt sich aus 3 Zählern zusammen, die per Punkt getrennt sind. Die Zähler beginnen bei Null und können unabhängig voneinander inkrementiert werden, z. B. `2.17.0`. Wenn die Version in der Referenz nicht angegeben ist, wird implizit die neueste Version des betreffenden Stadiums geladen. Wenn auch das Stadium nicht angegeben ist, gilt der global konfigurierte Standardwert `Config.DefaultStage`. Beispiel: vollständige Referenz: `db://myConfig/Prod/2.17.0` Minimalform der Referenz: `db://myConfig` Hinweis Nutzen Sie möglichst die Minimalform. Auf diese Weise müssen Sie nicht bei jedem Wechsel von Stadium und Version alle Referenzen manuell anpassen.

Syntax

Beschreibung

file:///{Dateipfad}

oder

file://{Server}/{Dateipfad}

Die erste Variante (file:///{Dateipfad}) wird für lokale Dateien genutzt. Die Syntax enthält einen absoluten oder relativen Dateipfad oder nur den Dateinamen.

Beispiele:

file:///c:/data/myConfig.json
file:///data/myConfig.json
file:///myConfig.json

Als Basis zur Auflösung eines relativen Pfades wird der Ordnerpfad der übergeordneten Konfiguration genutzt. Auf oberster Ebene ist das der Ordnerpfad der Startkonfigurationsdatei.

Die zweite Variante (file://{Server}/{Dateipfad}) ist für Netzwerkfreigaben auf einen anderen Server vorgesehen und mit einem UNC-Pfad vergleichbar.

Der Dateipfad-Teil setzt sich zusammen aus {Freigabename}/{Dateipfad}. Alte Konfigurationen unterstützen nur die Dateiform und keine URI-Syntax. Für die Kompatibilität mit diesen alten Konfigurationen, ist die Angabe des reinen Dateipfades ohne URI-Präfix zulässig. Die Angabe der Dateiendung .json ist optional.

db://{Name}[/{Stadium}[/{Version}]]

Konfigurationen, die in der Datenbank gespeichert sind, unterliegen einer Versionierung. Außerdem wird zwischen den Stadien "Entwicklung", "Test" und "Produktion" unterschieden.

Hinweis

Weitere Informationen zur Nutzung der Versionierungslogik finden Sie unter Konfigurator.

Bei der Angabe einer Referenz ist der eindeutige technische Name der Konfiguration zwingend erforderlich. Das Stadium und die Version sind optionale Komponenten. Diese beiden Komponenten sind voneinander abhängig, d.h. die Angabe eines Stadiums ohne Version ist möglich, aber die Angabe einer Version ohne Stadium ist nicht zulässig.

Die technischen Kennzeichner für die Stadien sind Dev, Test und Prod. Eine Versionsnummer setzt sich aus 3 Zählern zusammen, die per Punkt getrennt sind. Die Zähler beginnen bei Null und können unabhängig voneinander inkrementiert werden, z. B. 2.17.0. Wenn die Version in der Referenz nicht angegeben ist, wird implizit die neueste Version des betreffenden Stadiums geladen. Wenn auch das Stadium nicht angegeben ist, gilt der global konfigurierte Standardwert Config.DefaultStage.

Beispiel:

vollständige Referenz: db://myConfig/Prod/2.17.0
Minimalform der Referenz: db://myConfig
Hinweis
Nutzen Sie möglichst die Minimalform. Auf diese Weise müssen Sie nicht bei jedem Wechsel von Stadium und Version alle Referenzen manuell anpassen.

Die Konfigurationsdateien sind wie folgt unterteilt:

Globale Konfiguration: Konfigurationsdatei, die die grundlegenden Einstellungen für die Ausführung des Programms umfasst. Jeder Programminstanz von xSuite Interface wird eine individuelle globale Konfiguration zugeordnet. Die globale Konfiguration darf nicht identisch zu der globalen Konfiguration einer anderen parallelläufigen Instanz auf derselben Maschine sein.
Szenariokonfiguration: Konfigurationsdatei, die ein spezifisches Verarbeitungsszenario beschreibt. Die Anzahl der Szenariokonfigurationen ist abhängig davon, welche Szenarien eine einzelne Instanz verarbeitet.

Die verschiedenen Konfigurationen werden jeweils als separate Ressource bereitgestellt, d.h. für jede globale und jede Szenariokonfiguration existieren eigenständige Dateien oder Datensätze in der Konfigurationstabelle in der Verwaltungsdatenbank. Die globale Konfiguration wird direkt der Programminstanz zugeordnet. Die Zuordnung der Szenariokonfigurationen erfolgt hingegen innerhalb der globalen Konfiguration durch Referenzen auf die zu verarbeitenden Szenarien. Für die parallele Verarbeitung desselben Szenarios durch mehrere Instanzen kann dieselbe Szenariokonfiguration in mehreren globalen Konfigurationen referenziert werden.

Beispiel

Das folgende Beispiel zeigt den grundsätzlichen Aufbau der Konfigurationsdaten:

Hinweis

Im JSON-Format muss auf die korrekte Groß-/Kleinschreibung der Eigenschaftsnamen und der Werte geachtet werden.

{
   "General": {
      "ExitOnInitError": true
   },
   "Logging": {
      "Database": {
         "Type": "MsSqlServer",
         "Host": "localhost",
         "Port": 1433
      }
   },
   "WebService": {
      "Url": [
        "http://localhost:8000"     
        "http://testserver:8000"
      ] 
   },
   "Worker": [
      {
         "Type": "Input"
      },{
         "Type":"Output"
      }
   ]
}

Die JSON-Eigenschaften der obersten Ebene (z. B. General) dienen nur der Gliederung und enthalten als Wert immer ein Objekt mit untergeordneten Eigenschaften. Diese Eigenschaften beschreiben entweder direkt einen elementaren Wert (z. B. .ExitOnInitError) oder stellen bei einer mehrstufiger Gliederung wiederum ein Objekt dar (z. B. .Database unterhalb von Logging).

JSON-Syntax

Konfigurationseigenschaften und Eigenschaftswerte werden in der vorliegenden Dokumentation wie folgt dargestellt:

Art der Angabe	Beispiel	Beschreibung
Pfad zu einer Eigenschaft	`Logging.Database.Type`	In der vorliegenden Dokumentation wird oftmals der vollständige Pfad zu der untersten Eigenschaft, d.h. dem elementaren Wert, angegeben. Die einzelnen Eigenschaften werden durch einen Punkt separiert.
Wert einer Eigenschaft	`Logging.Database.Type: "MsSqlServer"`	Der Wert einer Eigenschaft ist durch einen Doppelpunkt von der Pfadangabe getrennt. Bei dem Pfad werden die Anführungszeichen zur besseren Lesbarkeit weggelassen. Bei dem Wert werden Anführungszeichen verwendet, um den korrekten Datentyp hervorzuheben. String-Werte werden daher mit Anführungszeichen geschrieben.
Numerische Werte und Wahrheitswerte	`Logging.Database.Port: 1433` `General.ExitOnInitError: true`	Numerische Werte und Wahrheitswerte werden ohne Anführungszeichen geschrieben. Gemäß JSON-Syntax muss für numerische Werte mit Nachkommastellen ein Punkt als Dezimaltrennzeichen verwendet werden.
String-Werte	`"Test(\"Hello\")"`	Bei der Angabe von String-Werten müssen eingebettete Anführungszeichen als `\"` maskiert werden. Ein in seiner Gesamtheit als String zu kennzeichnender Makroausdruck wie `Test("Hello")`, der wiederum einen String-Parameter enthält, muss im JSON-Format somit als `"Test(\"Hello\")"` geschrieben werden. Um das Maskierungszeichen `\` als normales Zeichen zu erhalten, muss dieses Zeichen doppelt angegeben werden (`\\`).
Arrays	`WebService.Url[]`	Um in der Pfadangabe zu kennzeichnen, dass eine Eigenschaft ein Array ist, werden dieser Eigenschaft eckige Klammern angefügt.
Arrays	`Worker[].Type`	Wenn die Array-Werte nicht elementar sind, sondern wiederum Objekte mit Untereigenschaften darstellen, kann nach den eckigen Klammern eine weitere Eigenschaft folgen.

In diesem Abschnitt:

xSuite Interface Windows Prism 5.x – Online-Hilfe