Zum Inhalt springen

Betriebsoptionen im Jitterbit Design Studio

Diese Seite beschreibt die Optionen, die für jede Operation konfigurierbar sind. Um auf diese Optionen zuzugreifen, klicken Sie mit der rechten Maustaste auf den Hintergrund eines beliebigen Operationsdiagramms und wählen Sie Optionen im Menü. Das Fenster Operationsoptionen wird angezeigt:

attachment

Diese Abschnitte beschreiben die verfügbaren Betriebsoptionen:

Operationstimeout

  • Das Operationstimeout ist die maximale Zeitspanne, die die Operation laufen kann, bevor sie abgebrochen wird. Wenn Ihre Operation große Datensätze oder eine komplexe Struktur hat, kann dies dazu führen, dass die Operation länger dauert.

  • Standardmäßig ist das Operationstimeout auf 2 Stunden eingestellt. Wenn die Operation länger als 2 Stunden läuft, ohne abzuschließen oder zu fehlschlagen, wird sie automatisch abgebrochen.

  • Möglicherweise möchten Sie diesen Wert erhöhen, wenn die Operation große Datensätze hat, die lange zum Ausführen benötigen. Oder verringern, wenn die Operationen zeitkritisch sind; d.h., Sie möchten nicht, dass die Operation abgeschlossen wird, wenn sie nicht innerhalb eines bestimmten Zeitrahmens abgeschlossen werden kann.

Hinweis

Das Aktivieren der Einstellung EnableAPITimeout in der Konfigurationsdatei des privaten Agents ermöglicht es Operationen, die durch die APIs des API-Managers ausgelöst werden, diese Timeout-Einstellungen zu verwenden.

Was zu protokollieren

  • Die Option Was zu protokollieren ermöglicht es Ihnen, zwischen "Alles" oder "Nur Fehler" zu wählen. Dies sind die Protokolle, die Sie sehen können, wenn Sie mit der rechten Maustaste auf den Hintergrund einer Operation klicken und Operationsprotokoll auswählen. Beachten Sie, dass Sie im Operationsprotokoll auch die Möglichkeit haben, nur nach Fehlern zu filtern.
  • Standardmäßig wird alles protokolliert. Dazu gehören Erfolge, Abbrüche, ausstehende, laufende und Fehlerstatus.
  • Ein Grund, warum Sie möglicherweise "Nur Fehler" auswählen möchten, bevor das Protokoll erstellt wird, ist, dass dies die Latenzprobleme der Operation verbessern kann, falls Sie solche haben. Auf diese Weise können Sie verhindern, dass die anderen nicht fehlerhaften Nachrichten, die normalerweise im Operationsprotokoll herausgefiltert werden, überhaupt generiert werden.

Debug-Modus aktivieren

Im Fenster Betriebsoptionen wählen Sie Debug-Modus aktivieren bis und setzen Sie ein Datum, an dem die Einstellung deaktiviert werden soll. Dieses Datum ist auf 2 Wochen ab dem aktuellen Datum begrenzt. Das Logging wird zu Beginn dieses Datums (12:00 Uhr) unter Verwendung der Zeitzone des Agents deaktiviert. Das Aktivieren des Debug-Modus für einen bestimmten Vorgang kann hilfreich sein, wenn Sie Probleme mit einem bestimmten Vorgang haben und das Debug-Logging nicht für Ihr gesamtes Projekt aktivieren möchten, da dies sehr große Dateien im Verzeichnis erstellen kann.

Warnung

Bei Cloud-Agent-Gruppen ist die Dauer dieser Einstellung unzuverlässig. Protokolle können vor dem Ende des ausgewählten Zeitraums nicht mehr erstellt werden.

Wenn das Debug-Logging für Vorgänge aktiviert ist, werden je nach Art des Agents folgende Protokolle generiert:

  • Privater Agent: Debug-Protokolldateien für einen Vorgang. Diese Option wird hauptsächlich zur Fehlersuche bei Problemen während der Tests verwendet und sollte in der Produktion nicht aktiviert werden, da sie sehr große Dateien erstellen kann. Das Debug-Logging kann auch für das gesamte Projekt direkt vom privaten Agenten selbst aktiviert werden (siehe Debug-Logging für Vorgänge). Die Debug-Protokolldateien sind direkt auf privaten Agenten zugänglich und können über die Management-Konsole auf den Seiten Agenten und Laufzeit heruntergeladen werden.

  • Privater Agent oder Cloud-Agent: Betriebsprotokolle für erfolgreiche API-Vorgänge (konfiguriert für benutzerdefinierte APIs oder OData-APIs). Standardmäßig werden nur API-Vorgänge mit Fehlern in den Betriebsprotokollen protokolliert.

Erfolgreichen Vorgang ausführen

  • Die Option Erfolgreichen Vorgang ausführen, auch wenn keine passenden Quelldateien vorhanden sind gilt für Vorgänge, die "OnSuccess"-Trigger konfiguriert haben.
  • Standardmäßig werden Ihre OnSuccess-Vorgänge nur ausgeführt, wenn sie eine passende Quelldatei zum Verarbeiten haben.
  • Sie haben die Möglichkeit, den vorherigen Vorgang "zwingen" erfolgreich zu sein, was es Ihnen effektiv ermöglicht, den "OnSuccess"-Vorgang zu starten, auch wenn der Trigger fehlgeschlagen ist. Dies kann nützlich sein, um spätere Teile des Projekts einzurichten, ohne von dem Erfolg eines abhängigen Vorgangs abhängig zu sein.

Hinweis

Der Parameter AlwaysRunSuccessOperation im Abschnitt [OperationEngine] der Datei jitterbit.conf überschreibt die Einstellung Erfolgsoperation auch ausführen, wenn keine passenden Quelldateien vorhanden sind.

Chunking aktivieren

  • Chunking ermöglicht es Jitterbit, Daten in Blöcken an das Zielsystem zu verarbeiten.
    • Die Chunk-Größe gibt Jitterbit an, wie viele Quelldatensätze pro Thread verarbeitet werden sollen.
    • Die Anzahl der Datensätze pro Datei weist Jitterbit an, nur die angeforderte Anzahl von Datensätzen in die Zieldatei zu platzieren.
    • Die Maximale Anzahl von Threads gibt Jitterbit an, wie viele gleichzeitige Threads verarbeitet werden sollen.
    • Der Quell-Chunk-Knoten und der Ziel-Chunk-Knoten ermöglichen es dem Benutzer, zu definieren, was einen Datensatz ausmacht, und sollten für hierarchische Datenstrukturen und XML festgelegt werden.
  • Standardmäßig ist Chunking nicht aktiviert.
  • Dies ermöglicht eine schnellere Verarbeitung großer Datensätze und wird auch verwendet, um die von verschiedenen webdienstbasierten Systemen auferlegten Datensatzlimits bei einer Anfrage zu umgehen.