Adapter JSON¶

Die Integration Studio Benutzeroberfläche für einen mit dem Jitterbit Connector SDK erstellten Connector wird durch ein JSON definiert Datei, die in der JAR-Datei enthalten ist, die den Connector verpackt. Konventionell und standardmäßig heißt diese Datei adapter.json.

Der Name dieser Datei kann unterschiedlich sein, da der verwendete Name der ist, der in der Jitterbit-Connector-UI Eintrag des MANIFEST-MF Datei:

Jitterbit-Connector-UI: adapter.json

Siehe Connector-Registrierung: Connector-Manifest für Einzelheiten zu den MANIFEST.MF Datei.

JSON-Datei des Adapters¶

Der Entwickler eines Connectors definiert alle UI-Komponenten im adapter.json Datei. Diese Komponenten werden angezeigt, wenn der Benutzer den Connector und seine Aktivitäten konfiguriert, und die eingegebenen Werte können über den Connector-Code abgerufen werden.

JSON-Dateistruktur des Adapters¶

Hier ist ein Gesamtschema der JSON-Datei, die eine Connector-Benutzeroberfläche definiert, mit Platzhalterwerten, die wie folgt angezeigt werden: "<name>". Die verwendeten Begriffe und ihre Bedeutung werden nach diesem Beispiel erläutert:

{
  "name": "<name>",
  "version": "1.0.0",
  "sandbox": true,
  "defaultActivityIcon": "<path-to-SVG-file>",
  "endpoint": {
    "displayName": "<display-name>",
    "icon": "<path-to-SVG-file>",
    "properties": ["<properties>" ]
  },
  "activities": {
    "activity-1": {
      "displayName": "<display-name-1>",
      "icon": "<path-to-SVG-file>",
      "properties": ["<properties>" ]
    },
    "activity-2": {
      "displayName": "<display-name-2>",
      "properties": ["<properties>" ]
    },
    . . .
  }
}

In diesem Schema wurde ein Konnektor mit Eigenschaften für den Endpoint und seine ersten beiden Aktivitäten definiert. Bei Bedarf können weitere Aktivitäten hinzugefügt werden.

Für die Verbindung (die angezeigt wird, wenn ein Endbenutzer den Connector zum ersten Mal im Integration Studio konfiguriert) UI) kann eine Reihe von Eigenschaften definiert werden, die verwendet werden, um einen oder mehrere Schritte zu generieren, die der Endbenutzer ausführt um die Verbindung zum Endpoint zu konfigurieren.

Beachten Sie, dass die name Und version verwendet werden, müssen derselbe Name und dieselbe Version sein, unter der der Connector registriert ist (siehe Connector-Registrierung).

Der sandbox Die Eigenschaft kann wie folgt eingestellt werden: true oder false. Eingestellt auf true bedeutet, dass der Connector in der Entwicklung ist, und wird von Harmony nicht zwischengespeichert. Stattdessen wird bei jedem Aufruf der Connector aus dem Jitterbit neu geladen. privater Agent. Sobald Sie eine Produktionsversion haben, können Sie diese auf false damit Caching genutzt werden kann um die Nutzung zu beschleunigen.

Für jede Aktivität wird ein Satz von Eigenschaften definiert, der Schritte zur Konfiguration der Aktivität nach dem Hinzufügen zu eine Operation im Integration Studio.

Endpoint¶

Wie im obigen Schema zu sehen ist, können Sie Symbole für die Verbindung und jede der Aktivitäten definieren (zusammen wird als Endpoint bezeichnet). Symbole werden mithilfe von SVG definiert und als Pfad zu einer SVG-Datei bereitgestellt.

Diese Schlüssel können bereitgestellt werden im adapter.json:

Im obigen schematischen Beispiel wurde ein Standardsymbol definiert, wobei die Verbindung und die erste Aktivität andere - möglicherweise unterschiedliche - Symbole verwenden. Für die zweite Aktivität ist kein Symbol definiert, stattdessen wird das Standardsymbol verwendet.

Dieser Screenshot des Dropbox-Connectors zeigt, wie unterschiedliche Symbole verwendet werden können:

Ein Symbol (ein Ordner) wird für die Verbindung verwendet, ein anderes Symbol für die Aktivitäten. Es ist möglich, ein anderes Symbol für jede Aktivität, obwohl ein einheitliches Farb- und Formthema für einen Endpoint empfohlen wird. Beachten Sie, dass Text, der die Aktivität beschreibt, wird über das Symbol gelegt. Am besten belässt man die untere Hälfte des Symbols in einer Volltonfarbe. damit der weiße Text einen Hintergrund hat, vor dem er erscheinen kann.

Einzelheiten zum Erstellen der SVG-Dateien, einschließlich Vorlagen und einer Schritt-für-Schritt-Anleitung, finden Sie unter Connector SDK UI- Endpoint.

Aktivitäts- und Symbolreihenfolge¶

-Connector. Wir empfehlen, beim Erstellen eines Connectors diese Richtlinien zu befolgen.

Die Reihenfolge der Symbole in der Benutzeroberfläche sollte der Reihenfolge der Aktivitäten im JSON entsprechen. Wenn die Anzahl der Wenn die Anzahl der Aktivitäten drei überschreitet, werden in der Benutzeroberfläche unterhalb der ursprünglichen Zeile zusätzliche Zeilen mit Aktivitäten hinzugefügt.

Wir empfehlen, die Reihenfolge der Aktivitäten diesen gängigen Mustern zu folgen:

• Lesen, Schreiben
• Abfragen (oder Suchen), Erstellen, Aktualisieren, Upsert, Löschen
• Abrufen, Posten, Ablegen, Löschen
• Anfrage, Antwort
• Herunterladen, Hochladen

Wenn es benutzerdefinierte, spezielle oder entitätsspezifische Aktivitäten außerhalb der oben genannten Beispiele gibt (z. B. Get List), ordnen Sie sie an den Anfang der Reihenfolge, wenn sie als Datenquelle für eine Operation dienen sollen, und gegen Ende, wenn sie als Ziel einer Operation Daten empfangen sollen.

Seitennummerierung¶

Für die Verbindung und jede Aktivität werden Eigenschaften in einer JSON-Struktur definiert. Diese erstellen die Konfigurationsschritte (Seiten), die ein Endbenutzer durchläuft, um die Verbindung und jede der bestimmten Aktivitäten zu konfigurieren, die er verwenden möchte.

Standardpaginierung¶

Verbindungen haben standardmäßig keine Paginierung. Für Verbindungen gibt es oft nur einen Schritt, der Entwickler kann jedoch beliebig viele hinzufügen.

Für Aktivitäten gibt es mindestens zwei Schritte: eine Startseite mit einem Namensfeld und eine Endseite mit den Datenschemata zur Überprüfung. Beide Seiten werden automatisch von der Infrastruktur erstellt und sind nicht in der JSON-Datei enthalten oder definiert.

In diesem Beispiel sind die Schritte Start (Seite 1) und Ende (Seite 2):

Einzelne Seite¶

Wenn die Verbindung oder Aktivität auf einer einzigen Seite konfiguriert werden kann und keine Paginierung erforderlich ist, kann eine einfache Struktur verwendet werden:

. . .
"properties": [
  {
    "name": "<name-1>",
    "displayName": "<display-name-1>",
    "type": "string",
    "validators": [
      {
        "name": "required"
      }
    ]
  },
  {
    "name": "<name-2>",
    "displayName": "<display-name-2>",
    "type": "string",
    "validators": [
      {
        "name": "required"
      }
    ]
  }
]
. . .

Mehrere Seiten¶

Wenn die Konfiguration jedoch länger ist und mehrere Werte festgelegt oder überprüft werden müssen, empfiehlt sich eine Paginierung, um die Ansichten in der Tiefe kleiner zu halten:

. . .
"properties": [
  {
    "name": "page1",
    "displayName": "<display-name-page-1>",
    "type": "pagination",
    "children": [
      {
        "name": "<name-1-1>",
        "displayName": "<display-name-1-1>",
        . . .
      },
      . . .
    ]
  },
  {
    "name": "page2",
    "displayName": "<display-name-page-2>",
    "type": "pagination",
    "children": [
      {
        "name": "<name-2-1>",
        "displayName": "<display-name-2-1>",
        . . .
      },
      . . .
    ]
  }
]
. . .