Zum Inhalt springen

Betriebsoptionen im Jitterbit Integration Studio

Einführung

Jeder Operation kann mit Optionen konfiguriert werden, z. B. dem Zeitlimit, den zu protokollierenden Operation und dem Zeitrahmen für die debuggen. Das Vorhandensein bestimmter Komponenten als Operation macht zusätzliche Optionen sichtbar, die festlegen, ob ein nachfolgender Operation ausgeführt wird und ob chunking verwendet werden soll.

Operation

Auf die Option Einstellungen für Vorgänge kann von diesen Orten aus zugegriffen werden:

Sobald der Bildschirm mit den Operation geöffnet ist, wählen Sie die Tab Optionen:

Optionen-Tab

Konfigurieren von Operation

Jede auf der Tab Optionen der Operation verfügbare Option wird unten beschrieben.

Optionsdialog

  • Operation Timeout: Geben Sie die maximale Dauer der Operation an, bevor sie abgebrochen wird. Geben Sie im ersten Feld eine Zahl ein und wählen Sie im zweiten Feld über die Dropdown-Liste die Einheiten Sekunden, Minuten oder Stunden aus. Der Standardwert ist 2 Stunden.

    Zu den häufigsten Gründen für die Anpassung des Operation Time Out-Werts gehören:

    • Erhöhen Sie den Timeout-Wert, wenn der Operation große Datensätze umfasst, deren Ausführung lange dauert.

    • Verringern Sie den Timeout-Wert, wenn der Operation zeitkritisch ist. Das heißt, Sie möchten nicht, dass der Operation erfolgreich ist, wenn er nicht innerhalb eines bestimmten Zeitrahmens abgeschlossen werden kann.

    Notiz

    Operationen, die durch API-Manager APIs ausgelöst werden unterliegen bei der Verwendung von Cloud-Agenten nicht der Einstellung Operation Time Out. Verwenden Sie bei privaten Agenten die EnableAPITimeout Einstellung in der privaten Agent-Konfigurationsdatei, damit die Einstellung Operation Time Out auf von APIs ausgelöste Operationen angewendet wird.

  • Was soll protokolliert werden: Verwenden Sie die Dropdown-Liste, um auszuwählen, was in den Operation, entweder Alles (Standard) oder Nur Fehler:

    • Alles: Operationen mit beliebigem Operation werden protokolliert.

    • Nur Fehler: Es werden nur Vorgänge mit einem Fehlerstatus (wie z. B. Fehler, SOAP Fehler oder Erfolg mit untergeordnetem Fehler) protokolliert. Erfolgreiche untergeordnete Vorgänge werden nicht protokolliert. Übergeordnete Vorgänge (auf Stammebene) werden immer protokolliert, da sie für eine ordnungsgemäße Funktion eine Protokollierung benötigen.

      Ein häufiger Grund für die Beschränkung der Protokolle auf Nur Fehler sind Probleme mit der Operation. Auf diese Weise können Sie die Generierung der anderen, nicht auf Fehlermeldungen bezogenen Meldungen, die normalerweise in den Operation herausgefiltert werden, von vornherein verhindern, falls Sie diese nicht verwenden möchten.

  • Debug-Modus aktivieren bis: Aktivieren Sie die debuggen Operation und geben Sie ein Datum an, ab dem der debuggen-Modus automatisch deaktiviert wird. Das Datum liegt bei maximal zwei Wochen ab dem aktuellen Datum. Die debuggen Protokollierung wird zu Beginn dieses Datums (d. h. um 0:00 Uhr) entsprechend der Agenten-Zeitzone deaktiviert.

    Wenn Sie Debug-Modus aktivieren bis für eine Operation mit untergeordneten Operationen auswählen, wird in einem Dialogfeld das Kontrollkästchen Auch auf untergeordnete Operationen anwenden angezeigt, mit dem die Einstellungen auf alle untergeordneten Operationen angewendet werden. Diese Option ist auch verfügbar, wenn Sie die Einstellung für den debuggen-Modus der Operation löschen.

    Wenn die Protokollierung des debuggen aktiviert ist, werden je nach Agententyp folgende Protokolltypen generiert:

    • Privater Agent: Debug-Protokolldateien für einen Operation. Diese Option dient hauptsächlich der Fehlersuche während des Tests und sollte in der Produktion nicht aktiviert werden, da sie sehr große Dateien erzeugen kann. Die Debug-Protokollierung kann auch für das gesamte Projekt über den privaten Agenten selbst aktiviert werden (siehe Operation debuggen logging. Die debuggen-Protokolldateien sind direkt auf privaten Agenten zugänglich und können über die Management Console Agenten heruntergeladen werden. und Runtime Operations Seiten.

    • Privater Agent oder Cloud-Agent: Es können zwei Arten von Protokollen generiert werden:

      • Eingabe- und Ausgabedaten der Komponente: In das Operation geschriebene Daten für einen Operation, der auf Agentenversion 10.48 oder höher ausgeführt wird. Die Daten werden von Harmony 30 Tage lang gespeichert.

      • API -Operationsprotokolle: Operationsprotokolle für erfolgreiche API Operationen (konfiguriert für benutzerdefinierte APIs oder OData-Dienste). Standardmäßig werden nur API Operationen mit Fehlern in den Operation protokolliert.

    Weitere Einzelheiten finden Sie unter Operation debuggen Logging für Cloud-Agenten oder Operation debuggen-Protokollierung für private Agenten.

    Achtung

    Die Generierung von Komponenten-Ein- und Ausgabedaten wird von der Agentengruppeneinstellung Cloud-Logging aktiviert nicht beeinflusst. Die Eingabe- und Ausgabedaten der Komponenten werden in der Harmony-Cloud protokolliert, auch wenn die Cloud-Protokollierung deaktiviert ist.

    Um die Generierung von Komponenten-Eingabe- und Ausgabedaten in einer privaten Agentengruppe zu deaktivieren, in der privaten Agentenkonfigurationsdatei unter dem [VerboseLogging] Abschnitt, Satz verbose.logging.enable=false.

    Warnung

    Wenn Komponenteneingabe- und -ausgabedaten generiert werden, werden alle Anforderungs- und Antwortdaten für diesen Operation in der Harmony Cloud protokolliert und verbleiben dort 30 Tage lang. Beachten Sie, dass personenbezogene Daten (PII) und sensible Daten wie Anmeldeinformationen in einer Payload in den Eingabe- und Ausgabedaten der Harmony Cloud-Protokolle im Klartext sichtbar sind.

  • Operation erfolgreich ausführen, auch wenn keine passenden Quelldateien vorhanden sind: Wählen Sie diese Option, um den Erfolg einer davorlegende Operation zu erzwingen. Dadurch können Sie eine Operation effektiv mit einer Bei Erfolg-Bedingung starten (konfiguriert mit einer Operation), auch wenn der Auslöser fehlgeschlagen ist.

    Diese Option ist nur anwendbar, wenn die Operation eine API enthält, Dateifreigabe, FTP, HTTP, Lokaler Speicher, SOAP, Temporärer Speicher oder Variable Aktivität, die als Quelle in der Operation verwendet wird und nur gilt, wenn für die Operation eine Bei Erfolg-Bedingung konfiguriert ist. Standardmäßig werden alle Bei Erfolg-Operationen nur ausgeführt, wenn eine entsprechende Quelldatei zur Verarbeitung vorliegt. Diese Option kann nützlich sein, um spätere Teile eines Projekts einzurichten, ohne dass der Erfolg einer abhängigen Operation erforderlich ist.

    Hinweis

    Die Einstellung AlwaysRunSuccessOperation im [OperationEngine] Abschnitt der privaten Agentenkonfigurationsdatei überschreibt die Einstellung Vorgang erfolgreich ausführen, auch wenn keine passenden Quelldateien vorhanden sind.

  • Chunking aktivieren: Wählen Sie diese Option aus, um chunking mit den angegebenen Parametern zu aktivieren:

    • Blockgröße: Geben Sie die Anzahl der Quelldatensätze (Knoten) ein, die für jeden Thread verarbeitet werden sollen. Wenn die chunking für Vorgänge aktiviert ist, die keine Salesforce-basierten Aktivitäten enthalten, beträgt die Standardblockgröße 1 Wenn eine Salesforce-basierte Aktivität zu einer Operation hinzugefügt wird, für die chunking nicht aktiviert ist, wird chunking automatisch mit einer Standard-Chunk-Größe von 200 Bei Verwendung einer Salesforce-basierten Massenaktivität sollten Sie diesen Standardwert auf einen deutlich höheren Wert ändern, z. B. 10.000.

    • Anzahl Datensätze pro Datei: Geben Sie die gewünschte Anzahl Datensätze ein, die in die Zieldatei eingefügt werden sollen. Der Standardwert ist 0, d. h. es gibt keine Begrenzung für die Anzahl der Datensätze pro Datei.

    • Maximale Anzahl von Threads: Geben Sie die Anzahl der gleichzeitig zu verarbeitenden Threads ein. Wenn chunking für Vorgänge aktiviert ist, die keine Salesforce-basierten Aktivitäten enthalten, beträgt die Standardanzahl der Threads 1. Wenn eine Salesforce-basierte Aktivität zu einer Operation hinzugefügt wird, für die chunking nicht aktiviert ist, wird chunking automatisch mit einer Standardanzahl von Threads aktiviert: 2.

    Diese Option ist nur vorhanden, wenn die Operation eine Transformation enthält oder eine Datenbank, NetSuite, Salesforce, Salesforce Service Cloud, ServiceMax oder SOAP -Aktivität und dient der stückweisen Verarbeitung von Daten an das Zielsystem. Dies ermöglicht eine schnellere Verarbeitung großer Datensätze und dient auch dazu, Datensatzbeschränkungen zu berücksichtigen, die von verschiedenen webdienstbasierten Systemen bei Anfragen auferlegt werden.

    Hinweis, wenn Sie einen Salesforce-basierten Endpoint (Salesforce, Salesforce Service Cloud oder ServiceMax) verwenden:

    • Wenn einer Operation, für die chunking nicht aktiviert ist, eine Salesforce-basierte Aktivität hinzugefügt wird, wird chunking mit den Standardeinstellungen speziell für Salesforce-basierte Aktivitäten aktiviert, wie oben beschrieben.

    • Wenn einer Operation, für die die chunking-Funktion bereits aktiviert ist, eine Salesforce-basierte Aktivität hinzugefügt wird, werden die chunking Einstellungen nicht geändert. Ebenso werden die chunking Einstellungen nicht geändert, wenn eine Salesforce-basierte Aktivität aus einer Operation entfernt wird.

    Weitere Informationen und Best Practices zum chunking finden Sie im nächsten Abschnitt Chunking.

  • Änderungen speichern: Klicken Sie hier, um die Operation zu speichern und zu schließen.

  • Änderungen verwerfen: Nachdem Sie Änderungen an den Operation vorgenommen haben, klicken Sie auf, um die Einstellungen ohne Speichern zu schließen.

Chunking

Mithilfe von Chunking werden die Quelldaten basierend auf der konfigurierten Chunk-Größe in mehrere Chunks aufgeteilt. Die Chunk-Größe entspricht der Anzahl der Quelldatensätze (Knoten) für jeden Chunk. Die Transformation wird dann für jeden Chunk separat durchgeführt, wobei jeder Quellchunk einen Zielchunk erzeugt. Die resultierenden Zielchunks werden kombiniert, um das endgültige Ziel zu erzeugen.

Chunking kann nur verwendet werden, wenn die Datensätze unabhängig sind und aus einer Nicht-LDAP Quelle stammen. Wir empfehlen, möglichst große Chunks zu verwenden und sicherzustellen, dass die Daten für einen Chunk in den verfügbaren Speicher passen. Weitere Methoden zur Begrenzung des von einer Transformation genutzten Speichers finden Sie unter Transformation.

Warnung

Die Verwendung von chunking beeinflusst das Verhalten von globalen und Projektvariablen. Siehe Variablen mit chunking verwenden unten.

API Einschränkungen

Viele Webdienst-APIs (SOAP/REST) unterliegen Größenbeschränkungen. Beispielsweise akzeptiert ein Salesforce-basierter Upsert nur 200 Datensätze pro Aufruf. Bei ausreichendem Speicher könnten Sie eine Operation mit einer Blockgröße von 200 konfigurieren. Die Quelle würde in Blöcke zu je 200 Datensätzen aufgeteilt, und jede Transformation würde den Webdienst einmal mit einem Block von 200 Datensätzen aufrufen. Dieser Vorgang würde wiederholt, bis alle Datensätze verarbeitet sind. Die resultierenden Zieldateien würden anschließend kombiniert. (Beachten Sie, dass Sie auch Salesforce-basierte Massenaktivitäten verwenden könnten, um die Verwendung von chunking zu vermeiden.)

Parallele Verarbeitung

Bei einer großen Quelle und einem Computer mit mehreren CPUs kann chunking verwendet werden, um die Quelle für die parallele Verarbeitung aufzuteilen. Da jeder Chunk isoliert verarbeitet wird, können mehrere Chunks parallel verarbeitet werden. Dies gilt nur, wenn die Quelldatensätze auf Chunk-Knotenebene unabhängig voneinander sind. Webdienste können mithilfe von chunking parallel aufgerufen werden, was die Leistung verbessert.

Beachten Sie beim chunking bei Operation mit einer Datenbank als Ziel, dass die Zieldaten zunächst in mehrere temporäre Dateien geschrieben werden (eine für jeden Chunk). Diese Dateien werden dann zu einer Zieldatei zusammengefasst, die zum Einfügen/Aktualisieren an die Datenbank gesendet wird. Wenn Sie die Variable Jitterbit festlegen jitterbit.target.db.commit_chunks Zu 1 oder true Wenn chunking aktiviert ist, wird jeder Chunk in die Datenbank übernommen, sobald er verfügbar ist. Dies kann die Leistung erheblich verbessern, da die Einfügungen/Aktualisierungen der Datenbank parallel ausgeführt werden.

Verwenden von Variablen mit chunking

Da chunking Multithreading auslösen kann, kann seine Verwendung das Verhalten von Variablen beeinflussen, die nicht zwischen den Threads gemeinsam genutzt werden.

Global und Projektvariablen werden zwischen den chunking-Instanzen getrennt, und obwohl die Daten kombiniert werden, werden Änderungen an diesen Variablen nicht kombiniert. Nur Änderungen am ursprünglichen Thread bleiben am Ende der Transformation erhalten.

Wenn beispielsweise eine Operation (mit chunking und mehreren Threads) eine Transformation enthält, die eine globale Variable ändert, ist der Wert der globalen Variable nach Abschluss der Operation der des ersten Threads. Alle Änderungen an der Variable in anderen Threads sind unabhängig und werden nach Abschluss der Operation verworfen.

Diese globalen Variablen werden als Wert und nicht als Referenz an die anderen Threads übergeben. Dadurch wird sichergestellt, dass Änderungen an den Variablen nicht in anderen Threads oder Operationen berücksichtigt werden. Dies ähnelt dem RunOperation Funktion im asynchronen Modus.