Operationsoptionen in Jitterbit Studio

Einführung

Konfigurieren Sie Operationsoptionen, um Timeouts, Protokollierung und Datenverarbeitung zu steuern. Die meisten Operationen funktionieren gut mit Standardeinstellungen, aber Sie können diese für spezifische Anforderungen anpassen.

Operationsoptionen aufrufen

Sie können die Option Einstellungen für Operationen von diesen Orten aus aufrufen:

• Der Registerkarte Workflows im Projektbereich (siehe Komponentenaktionsmenü in Projektbereich – Registerkarte „Workflows").
• Der Registerkarte Komponenten im Projektbereich (siehe Komponentenaktionsmenü in Projektbereich – Registerkarte „Komponenten").
• Der Design-Canvas (siehe Komponentenaktionsmenü in Design-Canvas).
• Der Design-Canvas durch Doppelklick auf die Operation (dies öffnet Einstellungen direkt).

Nachdem der Bildschirm mit den Operationseinstellungen geöffnet ist, wählen Sie die Registerkarte Optionen:

Operationsoptionen konfigurieren

Die folgenden Abschnitte beschreiben jede Operationsoption:

• Operationstimeout
• Was protokolliert werden soll
• Auf dediziertem Agent ausführen
• Debug-Protokollierungsmodus aktivieren bis
• Erfolgreiche Operation ausführen, auch wenn keine passenden Quelldateien vorhanden sind
• Chunking aktivieren
• Salesforce-Bulk-Operationsoptionen

Operationstimeout

Legen Sie fest, wie lange die Operation ausgeführt wird, bevor sie abgebrochen wird. Der Standard beträgt 2 Stunden, was für die meisten Operationen ausreichend ist.

Sie können diese Einstellung aus folgenden Gründen anpassen:

• Erhöhen Sie das Timeout für große Datensätze, deren Verarbeitung länger dauert. Geplante Operationen, die große Datenmengen verarbeiten, benötigen möglicherweise längere Timeouts. Wenn Ihre Datensätze die Timeout-Limits überschreiten, siehe Chunking aktivieren für Optionen, die große Datensätze in kleinere Batches aufteilen und die Anzahl der pro Ausgabedatei geschriebenen Datensätze steuern.

• Reduzieren Sie das Timeout für zeitkritische Operationen, die schnell abgeschlossen sein müssen.

Geben Sie eine Zahl zwischen 1 und 10000 ein und wählen Sie Sekunden, Minuten oder Stunden aus der Dropdown-Liste.

Was protokolliert werden soll

Wählen Sie, welche Informationen in Operationsprotokollen angezeigt werden:

• Alles: Protokolliert alle Operationsaktivitäten (empfohlen).
• Nur Fehler: Protokolliert nur Operationen mit einem Fehler-Status (z. B. Fehler, SOAP-Fehler oder Erfolg mit untergeordnetem Fehler). Verwenden Sie diese Einstellung, wenn Sie Leistungsprobleme haben und keine detaillierten Protokolle benötigen. Erfolgreiche untergeordnete Operationen werden nicht protokolliert. Übergeordnete (Root-Level-)Operationen werden immer protokolliert, da sie zur ordnungsgemäßen Funktion eine Protokollierung benötigen.

Debugging

Der Abschnitt Debugging enthält Optionen zum Ausführen einer Operation auf einem dedizierten Agent und zum Aktivieren des Debug-Modus.

Auf dediziertem Agent ausführen

Leiten Sie diese Operation zur vorübergehenden Fehlerbehebung auf einen bestimmten Agent um. Diese Option gilt nur für private Agent-Gruppen, die mit einer High Availability (HA) Agent-Gruppenklasse konfiguriert sind. Verwenden Sie diese Option, um Fehler auf einem bestimmten Agent zu reproduzieren oder einen problematischen Agent zu umgehen, während der Rest der Gruppe betriebsbereit bleibt.

Um diese Option zu aktivieren, wählen Sie das Kontrollkästchen Auf dediziertem Agent ausführen aus und konfigurieren Sie dann Folgendes:

• Agent auswählen: Wählen Sie den spezifischen Agent innerhalb der HA-Gruppe aus, der für die Ausführung dieser Operation verwendet werden soll. Wenn der ausgewählte Agent gelöscht wird, während diese Option aktiv ist, wird die dedizierte Agent-Ausführung automatisch deaktiviert und die Operation kehrt zur standardmäßigen Agent-Gruppenausführung zurück.

• Bis: Wählen Sie ein Datum bis zu zwei Wochen ab heute aus. Die dedizierte Agent-Ausführung wird an diesem Datum automatisch deaktiviert und die Operation kehrt zum standardmäßigen Verhalten der Agent-Gruppenausführung zurück.

• Auf untergeordnete Operationen anwenden: Falls die Operation untergeordnete Operationen hat, wird dieses Kontrollkästchen angezeigt. Wählen Sie es aus, um alle untergeordneten Operationen auf demselben Agent wie die übergeordnete Operation auszuführen.

Wenn Auf dediziertem Agent ausführen aktiviert ist, wird eine Warnung angezeigt.

Debug-Modus aktivieren bis

Aktivieren Sie detaillierte Protokollierung zur Fehlerbehebung. Wählen Sie ein Datum bis zu zwei Wochen ab heute aus. Der Debug-Modus wird an diesem Datum automatisch deaktiviert.

Wenn Sie den Debug-Modus für Operationen mit untergeordneten Operationen aktivieren, können Sie die gleiche Einstellung auf alle untergeordneten Operationen anwenden, indem Sie das Kontrollkästchen Auch auf untergeordnete Operationen anwenden verwenden.

Die Debug-Protokollierung generiert je nach Agent-Typ verschiedene Arten von Protokollen:

Operation auch ohne übereinstimmende Quelldateien erfolgreich ausführen

Diese Option erzwingt, dass eine Operation erfolgreich ist, auch wenn ihr Trigger fehlschlägt. Dies ermöglicht es anderen Operationen, die zum Ausführen konfiguriert sind, Bei Erfolg dieser Operation unabhängig vom Ergebnis der ursprünglichen Operation auszuführen. Dies gilt nur, wenn die ursprüngliche Operation eine Quellaktivität für einen dieser Connectoren enthält:

• API
• File Share
• FTP
• HTTP
• Local Storage
• SOAP
• Temporary Storage
• Variable-Aktivität

Standardmäßig werden Bei Erfolg-Operationen nur ausgeführt, wenn sie eine übereinstimmende Quelldatei zum Verarbeiten haben. Diese Option kann nützlich sein, um spätere Teile eines Projekts einzurichten, ohne dass der Erfolg einer abhängigen Operation erforderlich ist.

Chunking aktivieren

Chunking unterteilt große Datensätze in kleinere Chunks (Batches). Dies beschleunigt die Verarbeitung und hilft, API-Datensatzlimits einzuhalten. Eine aufgabenorientierte Anleitung zur Auswahl der Chunk-Größe, parallelen Verarbeitung und Variablengültigkeitsbereich finden Sie unter Operation Chunking für große Datensätze konfigurieren.

Um Chunking zu aktivieren, muss Ihre Operation eine Transformation oder eine Aktivität von einem dieser Connectoren enthalten:

• Database
• NetSuite
• Salesforce
• Salesforce Service Cloud
• ServiceMax
• SOAP-Aktivität

Verwenden Sie Chunking in diesen Situationen:

• Sie verarbeiten große Datensätze mit Tausenden von Datensätzen.
• Sie verwenden Webservices mit Datensatzlimits. Beispielsweise erlaubt Salesforce nur 200 Datensätze pro Aufruf.
• Sie möchten mehrere CPU-Kerne für die parallele Verarbeitung nutzen.

Wenn eine Salesforce-, Salesforce Service Cloud- oder ServiceMax-Aktivität in der Operation vorhanden ist, wird Chunking automatisch aktiviert.

Wenn diese Einstellung aktiviert ist, konfigurieren Sie diese Felder:

• Chunk Size: Die Anzahl der Datensätze in jedem Chunk. Der Standardwert ist 1 für die meisten Operationen und 200 für Salesforce-Operationen.

  Hinweis

  Wenn Sie eine (Salesforce-, Salesforce Service Cloud- oder ServiceMax)-Massenaktivität verwenden, ändern Sie diesen Standardwert auf eine viel größere Zahl, z. B. 10,000.

• Anzahl der Datensätze pro Datei: Die Anzahl der Datensätze, die in jede Zieldatei geschrieben werden (Batch). Standard ist 0, was bedeutet, dass keine Begrenzung vorhanden ist.

• Maximale Anzahl von Threads: Die Anzahl der Verarbeitungs-Threads, die gleichzeitig ausgeführt werden. Standard ist 1 für die meisten Operationen und 2 für Salesforce-Operationen.

Salesforce-Bulk-Operation-Optionen

Die folgenden Optionen werden nur für Salesforce, Salesforce Service Cloud und ServiceMax Bulk-Operationen angezeigt (außer Bulk Query-Operationen):

• Erfolgreiche Datensätze schreiben in: Wählen Sie, wohin erfolgreiche Datensätze nach Abschluss der Bulk-Operation gesendet werden. Wählen Sie aus konfigurierten dateigestützten Aktivitäten: HTTP, API, FTP, Dateifreigabe, Lokaler Speicher, Temporärer Speicher oder Variable. Standard: Keine.

• Fehlgeschlagene Datensätze schreiben in: Wählen Sie, wohin fehlgeschlagene Datensätze nach Abschluss der Bulk-Operation gesendet werden. HTTP, API, FTP, Dateifreigabe, Lokaler Speicher, Temporärer Speicher oder Variable. Standard: Keine.

  Wichtig

  Wenn Sie Variablenaktivitäten verwenden, können nur Operationen in derselben Operationskette während der Laufzeit auf den Variablenwert zugreifen.

• Erfolgreiche Datensätze senden an: Wählen Sie eine E-Mail-Benachrichtigung, um erfolgreiche Datensätze zu erhalten. Wählen Sie aus konfigurierten E-Mail-Benachrichtigungen. Standard: Keine.

• Fehlgeschlagene Datensätze senden an: Wählen Sie eine E-Mail-Benachrichtigung, um fehlgeschlagene Datensätze zu erhalten. Wählen Sie aus konfigurierten E-Mail-Benachrichtigungen. Standard: Keine.

Detaillierte Chunking-Informationen

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

Chunking kann nur verwendet werden, wenn Datensätze unabhängig sind und aus einer Nicht-LDAP-Quelle stammen. Es wird empfohlen, 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 zur Begrenzung des Speicherverbrauchs einer Transformation finden Sie unter Transformationsverarbeitung.

API-Einschränkungen

Viele Web-Service-APIs (SOAP/REST) haben Größenbeschränkungen. Beispielsweise akzeptiert ein Salesforce-basiertes Upsert nur 200 Datensätze pro Aufruf. Mit ausreichend Speicher können Sie einen Vorgang so konfigurieren, dass eine Chunk-Größe von 200 verwendet wird. Die Quelle wird in Chunks mit je 200 Datensätzen aufgeteilt, und jede Transformation ruft den Web-Service einmal mit einem 200-Datensatz-Chunk auf. Dies wird wiederholt, bis alle Datensätze verarbeitet wurden. Die resultierenden Zieldateien werden dann kombiniert. (Beachten Sie, dass Sie auch Salesforce-basierte Bulk-Aktivitäten verwenden können, um die Verwendung von Chunking zu vermeiden.)

Parallele Verarbeitung

Wenn Sie eine große Quelle und einen Multi-CPU-Computer haben, 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 der Chunk-Knotenebene voneinander unabhängig sind. Web-Services können mit Chunking parallel aufgerufen werden, was die Leistung verbessert.

Wenn Sie Chunking bei einem Vorgang verwenden, bei dem das Ziel eine Datenbank ist, beachten Sie, dass die Zieldaten zunächst in zahlreiche temporäre Dateien geschrieben werden (eine für jeden Chunk). Diese Dateien werden dann zu einer Zieldatei kombiniert, die zur Einfügung/Aktualisierung an die Datenbank gesendet wird. Wenn Sie die Jitterbit-Variable jitterbit.target.db.commit_chunks auf 1 oder true setzen, wenn Chunking aktiviert ist, wird jeder Chunk stattdessen in die Datenbank committed, sobald er verfügbar ist. Dies kann die Leistung erheblich verbessern, da die Datenbankoperationen zum Einfügen/Aktualisieren parallel ausgeführt werden.

Variablen mit Chunking verwenden

Da Chunking Multi-Threading aufrufen kann, kann seine Verwendung das Verhalten von Variablen beeinflussen, die nicht zwischen den Threads gemeinsam genutzt werden.

Globale und Projektvariablen werden zwischen den Instanzen des Chunking getrennt, und obwohl die Daten kombiniert werden, werden Änderungen an diesen Variablen nicht kombiniert. Nur Änderungen, die im ursprünglichen Thread vorgenommen werden, bleiben am Ende der Transformation erhalten.

Wenn beispielsweise ein Vorgang – mit Chunking und mehreren Threads – eine Transformation hat, die eine globale Variable ändert, ist der Wert der globalen Variable nach Abschluss des Vorgangs der des ersten Threads. Alle Änderungen an der Variable in anderen Threads sind unabhängig und werden verworfen, wenn der Vorgang abgeschlossen ist.

Diese globalen Variablen werden an die anderen Threads nach Wert statt nach Referenz übergeben, um sicherzustellen, dass Änderungen an den Variablen nicht in anderen Threads oder Vorgängen widergespiegelt werden. Dies ähnelt der RunOperation-Funktion im asynchronen Modus.