Bedienungsmöglichkeiten im Jitterbit Integration Studio

Einführung

Jeder Operation kann mit Optionen konfiguriert werden, beispielsweise wann der Operation abläuft, was protokolliert werden soll und wie lange die debuggen des Operation dauern soll. 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:

• Die Tab Workflows im Projektbereich (siehe Aktionsmenü Komponentenaktionen im Projektbereich Tab Workflows).
• Die Tab Komponenten des Projektbereichs (siehe Aktionsmenü im Projektbereich Tab Komponenten).
• Die Design-Canvas (siehe Aktionsmenü „Komponentenaktionen“ in Entwurfsfläche).

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

Konfigurieren von Operation

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

• Zeitüberschreitung des Vorgangs: Geben Sie die maximale Zeit an, die der Operation ausgeführt wird, bevor er abgebrochen wird. Geben Sie im ersten Feld eine Zahl ein und wählen Sie im zweiten Feld über die Dropdown-Liste die Einheiten in Sekunden, Minuten oder Stunden aus. Der Standardwert ist 2 Stunden.

  Häufige Gründe für die Anpassung des Werts für das Operation Time Out sind:

  • 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 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 protokolliert werden soll, eines von Alles (Standard) oder Nur Fehler:

  • Alles: Operationen mit beliebigem Operation werden protokolliert.

  • Nur Fehler: Es werden nur Vorgänge mit einem Fehlerstatus (wie 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 für ihre ordnungsgemäße Funktion eine Protokollierung erforderlich ist.

    Ein häufiger Grund für die Beschränkung der Protokolle auf Nur Fehler ist, wenn Sie Probleme mit der Operation haben. Auf diese Weise können Sie die Generierung der anderen Nicht-Fehlermeldungen, die normalerweise in den Operation herausgefiltert werden, von vornherein verhindern, wenn Sie nicht vorhaben, sie zu verwenden.

• Debugmodus aktivieren bis: Wählen Sie diese Option aus, um die debuggen von Operation zu aktivieren, und geben Sie ein Datum an, an dem der debuggen automatisch deaktiviert wird (begrenzt auf zwei Wochen ab dem aktuellen Datum). Die debuggen von Vorgängen wird zu Beginn dieses Datums (also 0:00 Uhr) entsprechend der Zeitzone des Agenten deaktiviert.

  Wenn Sie Debugmodus aktivieren bis auswählen, wird in einem Dialogfeld das Kontrollkästchen Auch auf untergeordnete Vorgänge anwenden angezeigt, mit dem die Einstellungen auf alle untergeordneten Vorgänge angewendet werden. Diese Option wird auch beim Löschen der debuggen für Operation bereitgestellt.

  

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

  • Privater Agent: Debug-Protokolldateien für einen Operation. Diese Option wird hauptsächlich zum Debuggen von Problemen während des Tests verwendet und sollte in der Produktion nicht aktiviert werden, da sie sehr große Dateien erstellen kann. Die Debug-Protokollierung kann auch vom privaten Agenten selbst für das gesamte Projekt aktiviert werden (siehe Operation- debuggen-Protokollierung). Die debuggen-Logdateien 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: Daten, die in an Integration Studio Operation für einen Operation, der auf Agentversion 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 Custom 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. Komponenten-Ein- und-Ausgabedaten 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 vertrauliche Daten wie in einer Payload bereitgestellte Anmeldeinformationen in den Eingabe- und Ausgabedaten in den Harmony Cloud-Protokollen im Klartext sichtbar sind.

• Operation erfolgreich ausführen, auch wenn keine passenden Quelldateien vorhanden sind: Wählen Sie diese Option aus, um einen davorlegende Operation erfolgreich auszuführen. Auf diese Weise können Sie einen 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, das 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 sie eine passende Quelldatei zur Verarbeitung haben. 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:

  • Chunk-Größe: Geben Sie eine Anzahl von Quelldatensätzen (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 Standard-Chunk-Größe 1. Wenn eine Salesforce-basierte Aktivität zu einer Operation hinzugefügt wird, für die das chunking nicht aktiviert ist, wird das chunking automatisch mit einer Standard-Chunk-Größe von 200. Wenn Sie eine Salesforce-basierte Massenaktivität verwenden, sollten Sie diesen Standardwert auf eine viel größere Zahl ändern, z. B. 10.000.

  • Anzahl der Datensätze pro Datei: Geben Sie die gewünschte Anzahl von Datensätzen ein, die in der Zieldatei abgelegt 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 die chunking Funktion für Vorgänge aktiviert ist, die keine Salesforce-basierten Aktivitäten enthalten, beträgt die Standardanzahl von 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 wird verwendet, um Daten in Blöcken an das Zielsystem zu übermitteln. Dies ermöglicht eine schnellere Verarbeitung großer Datensätze und wird auch verwendet, um Datensatzbeschränkungen zu berücksichtigen, die von verschiedenen webdienstbasierten Systemen bei einer Anforderung auferlegt werden.

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

  • Wenn einer Operation, bei der 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, bei der die chunking 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, um die Einstellungen ohne Speichern zu schließen.

Chunking

Chunking wird verwendet, um die Quelldaten basierend auf der konfigurierten Chunk-Größe in mehrere Chunks aufzuteilen. Die Chunk-Größe ist die 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, eine möglichst große Chunk-Größe zu verwenden und sicherzustellen, dass die Daten für einen Chunk in den verfügbaren Speicher passen. Weitere Methoden zum Begrenzen der Speichermenge, die eine Transformation verwendet, finden Sie unter Transformation.

API Einschränkungen

Viele Webdienst-APIs (SOAP/REST) unterliegen Größenbeschränkungen. Beispielsweise akzeptiert ein Salesforce-basiertes Upsert nur 200 Datensätze pro Aufruf. Mit ausreichend Speicher können Sie einen Operation so konfigurieren, dass er eine Blockgröße von 200 verwendet. Die Quelle würde in Blöcke mit jeweils 200 Datensätzen aufgeteilt, und jede Transformation würde den Webdienst einmal mit einem Block mit 200 Datensätzen aufrufen. Dies würde wiederholt, bis alle Datensätze verarbeitet wurden. Die resultierenden Zieldateien würden dann kombiniert. (Beachten Sie, dass Sie auch Salesforce-basierte Massenaktivitäten verwenden könnten, um die Verwendung von chunking zu vermeiden.)

Parallele Verarbeitung

Wenn Sie eine große Quelle und einen Computer mit mehreren CPUs haben, kann die Quelle mithilfe von chunking für die parallele Verarbeitung aufgeteilt werden. Da jeder Chunk isoliert verarbeitet wird, können mehrere Chunks parallel verarbeitet werden. Dies gilt nur, wenn die Quelldatensätze auf der Chunk-Knotenebene voneinander unabhängig sind. Webdienste können mithilfe von chunking parallel aufgerufen werden, was die Leistung verbessert.

Wenn Sie chunking bei einem Operation verwenden, bei dem das Ziel eine Datenbank ist, beachten Sie, dass die Zieldaten zunächst in mehrere temporäre Dateien geschrieben werden (eine für jeden Chunk). Diese Dateien werden dann zu einer Zieldatei kombiniert, 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 die chunking aktiviert ist, wird jeder Chunk stattdessen in die Datenbank übertragen, sobald er verfügbar ist. Dies kann die Leistung erheblich verbessern, da die Einfügungen/Aktualisierungen der Datenbank parallel durchgefü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 geteilt 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 aufweist, 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 verworfen, wenn die Operation abgeschlossen ist.

Diese globalen Variablen werden an die anderen Threads als Wert und nicht als Referenz übergeben. Dadurch wird sichergestellt, dass Änderungen an den Variablen nicht in anderen Threads oder Operationen widergespiegelt werden. Dies ist ähnlich wie bei RunOperation Funktion im asynchronen Modus.