Betriebsoptionen im Jitterbit Integration Studio

Einführung

Konfigurieren Sie die Betriebsoptionen, um Zeitüberschreitungen, Protokollierung und Datenverarbeitung zu steuern. Die meisten Operationen funktionieren gut mit den Standardeinstellungen, aber Sie können diese an spezifische Bedürfnisse anpassen.

Zugriff auf Betriebsoptionen

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

• Der Workflows-Tab im Projektbereich (siehe Komponentenaktionsmenü im Projektbereich Workflows-Tab).
• Der Komponenten-Tab im Projektbereich (siehe Komponentenaktionsmenü im Projektbereich Komponenten-Tab).
• Die Entwurfskanvas (siehe Komponentenaktionsmenü in Entwurfskanvas).
• Die Entwurfskanvas durch Doppelklicken auf die Operation (dies öffnet Einstellungen direkt).

Nachdem der Bildschirm für die Betriebseinstellungen geöffnet ist, wählen Sie den Tab Optionen:

Konfigurieren von Betriebsoptionen

Die folgenden Abschnitte beschreiben jede Betriebsoption:

• Betriebszeitüberschreitung
• Was protokolliert werden soll
• Debug-Protokollierungsmodus aktivieren bis
• Erfolgreiche Operation ausführen, auch wenn keine passenden Quelldateien vorhanden sind
• Chunking aktivieren
• Salesforce-Bulk-Betriebsoptionen

Betriebszeitüberschreitung

Legen Sie fest, wie lange die Operation läuft, bevor sie abgebrochen wird. Der Standardwert beträgt 2 Stunden, was für die meisten Operationen funktioniert.

Sie möchten diese Einstellung aus folgenden Gründen anpassen:

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

• Verringern Sie das Timeout für zeitkritische Vorgänge, die schnell abgeschlossen werden müssen.

Geben Sie eine Zahl ein und wählen Sie Sekunden, Minuten oder Stunden aus dem Dropdown-Menü.

Was zu protokollieren ist

Wählen Sie aus, welche Informationen in den Betriebsprotokollen angezeigt werden:

• Alles: Protokolliert alle Betriebsaktivitäten (empfohlen).
• Nur Fehler: Protokolliert nur Vorgänge mit einem Fehlerstatus (wie Fehler, SOAP-Fehler oder Erfolg mit Kindfehler). Verwenden Sie diese Einstellung, wenn Sie Leistungsprobleme haben und keine detaillierten Protokolle benötigen. Erfolgreiche Kindvorgänge werden nicht protokolliert. Übergeordnete (Root-Level) Vorgänge werden immer protokolliert, da sie zur ordnungsgemäßen Funktion protokolliert werden müssen.

Debug-Modus aktivieren bis

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

Wenn Sie den Debug-Modus für Vorgänge mit Kindvorgängen aktivieren, können Sie dieselbe Einstellung für alle Kindvorgänge mit dem Kontrollkästchen Auch auf Kindvorgänge anwenden anwenden.

Die Debug-Protokollierung erzeugt je nach Agententyp unterschiedliche Protokollarten:

Erfolgreiche Ausführung der Operation auch wenn keine passenden Quelldateien vorhanden sind

Diese Option zwingt eine Operation dazu, erfolgreich zu sein, selbst wenn ihr Trigger fehlschlägt. Dadurch können andere Operationen, die Bei Erfolg dieser Operation ausgelöst werden, unabhängig vom Ergebnis der ursprünglichen Operation ausgeführt werden. Sie gilt nur, wenn die ursprüngliche Operation eine Quellaktivität für einen dieser Connectoren enthält:

• API
• Dateifreigabe
• FTP
• HTTP
• Lokaler Speicher
• SOAP
• Temporärer Speicher
• Variablenaktivität

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

Chunking aktivieren

Chunking zerlegt große Datensätze in kleinere Teile (Batches). Dies beschleunigt die Verarbeitung und hilft, die API-Datensatzlimits einzuhalten. Um Chunking zu aktivieren, muss Ihre Operation eine Transformation oder eine Aktivität von einem dieser Connectoren enthalten:

• Datenbank
• 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 Webdienste mit Datensatzlimits. Zum Beispiel 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 ist, wird Chunking automatisch aktiviert.

Wenn diese Einstellung aktiviert ist, konfigurieren Sie diese Felder:

• Chunk-Größe: Die Anzahl der Datensätze in jedem Chunk. Standard ist 1 für die meisten Operationen und 200 für Salesforce-Operationen.

  Hinweis

  Wenn Sie eine (Salesforce, Salesforce Service Cloud oder ServiceMax) Bulk-Aktivität verwenden, ändern Sie diesen Standard auf eine viel größere Zahl, wie z.B. 10.000.

• Anzahl der Datensätze pro Datei: Die Anzahl der Datensätze, die in jede Ziel-Datei (Batch) geschrieben werden sollen. Standard ist 0, was kein Limit bedeutet.

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

Optionen für Salesforce-Bulk-Operationen

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

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

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

  Wichtig

  Wenn Sie Variable-Aktivitä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.

• Fehlerhafte 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 in mehrere Chunks (Batches) basierend auf der konfigurierten Chunk-Größe zu unterteilen. 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 Quell-Chunk einen Ziel-Chunk produziert. Die resultierenden Ziel-Chunks 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 so große Chunk-Größe wie möglich zu verwenden, wobei sichergestellt werden muss, dass die Daten für einen Chunk in den verfügbaren Speicher passen. Für zusätzliche Methoden zur Begrenzung des Speicherverbrauchs einer Transformation siehe Transformation Verarbeitung.

API-Beschränkungen

Viele Webservice-APIs (SOAP/REST) haben Größenbeschränkungen. Zum Beispiel akzeptiert ein Salesforce-basiertes Upsert nur 200 Datensätze pro Aufruf. Bei ausreichendem Speicher könnten Sie eine Operation so konfigurieren, dass sie eine Chunk-Größe von 200 verwendet. Die Quelle würde in Chunks von jeweils 200 Datensätzen unterteilt, und jede Transformation würde den Webservice einmal mit einem 200-Datensatz-Chunk aufrufen. Dies würde wiederholt, bis alle Datensätze verarbeitet sind. Die resultierenden Zieldateien würden dann kombiniert. (Beachten Sie, dass Sie auch Salesforce-basierte Bulk-Aktivitäten verwenden könnten, um die Verwendung von Chunking zu vermeiden.)

Parallelverarbeitung

Wenn Sie eine große Quelle und einen Multi-CPU-Computer haben, kann Chunking verwendet werden, um die Quelle für die Parallelverarbeitung zu unterteilen. Da jeder Chunk isoliert verarbeitet wird, können mehrere Chunks parallel verarbeitet werden. Dies gilt nur, wenn die Quelldatensätze auf der Ebene des Chunk-Knotens unabhängig voneinander sind. Webservices können parallel unter Verwendung von Chunking aufgerufen werden, was die Leistung verbessert.

Bei der Verwendung von Chunking in einer Operation, bei der das Ziel eine Datenbank ist, beachten Sie, dass die Zieldaten zunächst in zahlreiche temporäre Dateien (eine für jeden Chunk) geschrieben werden. Diese Dateien werden dann zu einer Zieldatei kombiniert, die an die Datenbank zum Einfügen/Aktualisieren 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 an die Datenbank übergeben, sobald er verfügbar ist. Dies kann die Leistung erheblich verbessern, da die Datenbankeinfügungen/Aktualisierungen parallel durchgeführt werden.

Verwenden Sie Variablen mit Chunking

Da Chunking Multi-Threading auslösen kann, kann dessen Verwendung das Verhalten von Variablen beeinflussen, die nicht zwischen den Threads geteilt werden.

Globale Variablen und Projektvariablen sind zwischen den Instanzen von Chunking segregiert, und obwohl die Daten kombiniert werden, sind Änderungen an diesen Variablen es nicht. Nur Änderungen, die im ursprünglichen Thread vorgenommen werden, werden am Ende der Transformation beibehalten.

Wenn beispielsweise eine Operation — mit Chunking und mehreren Threads — eine Transformation hat, die eine globale Variable ändert, ist der Wert der globalen Variable nach dem Ende der Operation der aus dem ersten Thread. Alle Änderungen an der Variablen in anderen Threads sind unabhängig und werden verworfen, wenn die Operation abgeschlossen ist.

Diese globalen Variablen werden den anderen Threads nach Wert und nicht nach Referenz übergeben, wodurch sichergestellt wird, dass Änderungen an den Variablen nicht in anderen Threads oder Operationen widergespiegelt werden. Dies ähnelt der Funktion RunOperation, wenn sie im asynchronen Modus ist.