Speicherüberlegungen zu Variablen, temporärem Speicher, Cloud-Caching und Cloud Datastore in Jitterbit Integration Studio

Einführung

Integration Studio bietet mehrere Ansätze zur Handhabung von Daten in Ihren Integrationen. Diese reichen von der Übergabe einfacher Werte zwischen Operationen bis hin zum Speichern und Abrufen von Daten. Jeder Ansatz ist für spezifische Anwendungsfälle und Leistungsanforderungen konzipiert. Diese Seite skizziert die empfohlenen Ansätze und ist keine umfassende Liste aller Ansätze.

Variablen zur Datenübergabe

Variablen sind dafür ausgelegt, Werte, Konfigurationseinstellungen und kleine Datenmengen zwischen verschiedenen Komponenten Ihrer Integration zu übergeben. Variablen sind nützlich, wenn Sie Informationen wie Sitzungs-IDs, Konfigurationsparameter oder berechnete Werte zwischen Skripten, Transformationen und Operationen teilen müssen. Diese Variablentypen stehen zur Verfügung:

Für Beispiele und detaillierte Informationen zu jedem Variablentyp siehe die jeweiligen Dokumentationsseiten.

Speicheranschlüsse für Datenpersistenz

Speicheranschlüsse kümmern sich um das Speichern und Abrufen von Dateien und persistenten Daten innerhalb Ihrer Integrationen. Diese Speicheranschlüsse sind nützlich, wenn Sie mit tatsächlichen Datendateien arbeiten, Verarbeitungsergebnisse vorübergehend speichern müssen oder Daten benötigen, die über eine einzelne Operationskette hinaus bestehen bleiben:

Variable

Variable-Endpunkte (Lesen und Schreibaktivitäten, die von oder zu globalen Variablen lesen oder schreiben), sind einfach zu programmieren und reduzieren die Komplexität. Sie haben jedoch bestimmte Einschränkungen.

Wir empfehlen die Verwendung eines Variable-Endpunkts für Szenarien, in denen eine Integration mit kleinen Datensätzen arbeitet, wie z. B. Webdienstanfragen und -antworten oder kleinen Dateien mit einigen hundert Datensätzen.

Wenn der Datensatz den Megabyte-Bereich erreicht, wird der Variable-Endpunkt langsamer, und es beginnt eine Verschlechterung, wenn die Daten 4 MB überschreiten.

Wenn der Datensatz im größeren Multi-Megabyte-Bereich liegt, besteht das Risiko einer Datenabschneidung. Wir empfehlen, die Verwendung von Variable-Endpunkten auf 50 MB zu beschränken, um konservativ zu sein und das Risiko einer Abschneidung zu vermeiden.

Die Verwendung von Variable-Endpunkten in asynchronen Operationen erfordert besondere Überlegungen. Es gibt eine Grenze von 7 KB für die Größe eines Datensatzes, der in einem Variable-Endpunkt verwendet wird, der in einer asynchronen Operation verwendet wird. In diesem Szenario kann das Überschreiten dieser Grenze zu einer Abschneidung führen. Siehe die RunOperation Funktion für eine Beschreibung des Aufrufs einer asynchronen Operation.

Variable-Endpunkte ermöglichen Wiederverwendung und reduzieren Komplexität

Die Verwendung eines Variable-Endpunkts für kleine Datensätze kann Wiederverwendung ermöglichen und die Komplexität reduzieren. Zum Beispiel, beim Erstellen von Operationsketten, kann jede Operation Aktivitäten haben, die als Quellen (Leseaktivitäten) und Ziele (Schreibaktivitäten) fungieren. Anstatt individuelle Quell- oder Zielkombinationen für jede Operation zu erstellen, können Sie einen gemeinsamen Variable-Ziel- und -Quellendpunkt verwenden.

Um die Wiederverwendbarkeit und Standardisierung zu erhöhen, können Sie ein wiederverwendbares Skript erstellen, das den Inhalt der Variablen protokolliert. Dieser Ansatz kann auch mit temporärem Speicher erreicht werden, erfordert jedoch zusätzliches Skripting, um den Pfad und den Dateinamen zu initialisieren.

Bei der Verwendung eines Variablenendpunkts ist dessen Gültigkeitsbereich die Operationenkette. Die Werte der Variablenendpunkte sind einzigartig für eine bestimmte Operationenkette und werden gelöscht, wenn die Operationenkette abgeschlossen ist. Dies ist nicht der Fall bei einem Temporären Speicherendpunkt (der im folgenden Abschnitt beschrieben wird).

Beim Durchführen von Unit-Tests für Operationen ist die Verwendung eines Variablenendpunkts nützlich, um Testdaten zu laden. Sie können am Anfang der Operationenkette ein Skript hinzufügen, um Testdaten zu schreiben:

  $memory = "a,b,c";

Im Gegensatz dazu sieht das Schreiben von Daten in einen Temporären Speicherendpunkt so aus:

  WriteFile("<TAG>activity:tempstorage/Temporary Storage/tempstorage_write/Write</TAG>", "a,b,c");

  FlushFile("<TAG>activity:tempstorage/Temporary Storage/tempstorage_write/Write</TAG>");

Ebenso ist das Lesen von Daten mit einem Variablenendpunkt einfacher:

  myLocalVar= $memory;

Im Gegensatz dazu lesen Sie Daten von einem Temporären Speicherendpunkt so:

  myLocalVar = ReadFile("<TAG>activity:tempstorage/Temporary Storage/tempstorage_read/Read</TAG>");

Temporärer Speicher

Temporäre Speicher Endpunkte werden häufig in Operationen sowohl auf Cloud- als auch auf privaten Agenten verwendet. Diese unterscheiden sich von Lokalen Speicher Endpunkten, die nur auf privaten Agenten verwendet werden können.

Bei der Verwendung eines Temporären Speicherendpunkts werden temporäre Dateien im Standard-Temp-Verzeichnis des Betriebssystems auf dem Agenten, der die Arbeit ausführt, geschrieben und gelesen:

• Im Fall eines einzelnen privaten Agenten ist das temporäre Speicherverzeichnis das Standard-Temp-Verzeichnis dieses privaten Agentenservers.
• Wenn Sie mehr als einen privaten Agenten in einer Gruppe privater Agenten verwenden, ist das temporäre Speicherverzeichnis das Standard-Temp-Verzeichnis des spezifischen privaten Agentenservers, der die Arbeit ausführt.
• Da Cloud-Agenten in einer Cloud-Agenten-Gruppe gruppiert sind, ist das temporäre Speicherverzeichnis das Standard-Temp-Verzeichnis des spezifischen Cloud-Agentenservers, der die Arbeit ausführt.

Wenn Sie entweder eine private Agentengruppe mit mehreren Agenten oder eine Cloud-Agentengruppe verwenden, bleiben temporäre Speicheroperationen auf demselben Server, solange sie Teil einer Operationenkette sind. Wenn Sie jedoch zwei separate Ketten haben, bei denen Kette A in die temporäre Speicherdatei myfile schreibt und Kette B später von myfile liest, könnte Kette B möglicherweise nicht auf denselben Agentenserver zugreifen, den Kette A zum Schreiben verwendet hat.

Beachten Sie bei der Verwendung von temporärem Speicher die folgenden Richtlinien:

• Wenn Sie private Agenten verwenden, um Ihr Projekt upgrade-sicher zu machen, verwenden Sie temporären Speicher so, dass der Wechsel von einem einzelnen privaten Agenten zu einer Agentengruppe mit mehreren Agenten keine Umstrukturierung erfordert.

• Um sicherzustellen, dass Lese- und Schreibvorgänge im temporären Speicher auf demselben Agentenserver stattfinden, halten Sie alle Lese- und Schreib-Aktivitäten, die auf denselben temporären Speicher verweisen, innerhalb einer einzigen Operationenkette. Dies gilt unabhängig davon, ob Sie eine private Agentengruppe mit mehreren Agenten oder eine Cloud-Agentengruppe verwenden.

• Temporäre Speicher auf privaten Agenten werden standardmäßig nach 24 Stunden vom Jitterbit-Dateireinigungsdienst gelöscht. Die Häufigkeit des Reinigungsdienstes kann über die Konfigurationsdatei für private Agenten im Abschnitt [FileCleanup] konfiguriert werden. Bei Cloud-Agenten können temporäre Dateien jedoch sofort gelöscht werden.

• Cloud-Agenten haben eine Größenbeschränkung für temporäre Speicherdateien von 50 GB pro Datei. Temporäre Dateien, die größer als 50 GB sind, sind nur bei Verwendung von privaten Agenten möglich.

• Beim Schreiben in den temporären Speicher ist das Standardverhalten, Dateien zu überschreiben. Dies kann mit dem Kontrollkästchen Datei anhängen in einer Aktivität zum Schreiben in den temporären Speicher geändert werden. In der Regel erfordert dies, dass die Datei nach dem Lesen der Quelle gelöscht oder archiviert wird. Eine einfache Möglichkeit, dies zu tun, besteht darin, die Nachbearbeitungsoptionen Datei löschen oder Datei umbenennen in einer Aktivität zum Lesen aus dem temporären Speicher zu verwenden.

• Dateinamen-Schlüsselwörter stehen zur Verfügung, die beim Erstellen eines Dateinamens verwendet werden können.

  Beispiel

  Sie können das [unique] Dateinamen-Schlüsselwort in einer Aktivität zum Schreiben in den temporären Speicher verwenden, um automatisch eindeutige Dateinamen zu generieren und Dateiüberschreibungen zu verhindern. Zum Beispiel erstellt die Benennung Ihrer Datei processing_[unique].csv Dateien wie processing_20240820143052123.csv.

• Eine Datei im temporären Speicher kann durch den Aufbau eines Skripts mit der ReadFile Funktion gelesen werden. Zum Beispiel: ReadFile("<TAG>activity:tempstorage/Temporary Storage/tempstorage_read/Read</TAG>"). Beachten Sie, dass dies nur zuverlässig funktioniert, wenn es einen einzelnen privaten Agenten gibt.

Cloud Datastore (Beta)

Cloud Datastore (Beta) bietet eine persistente Speicherlösung, bei der die Datenpersistenz je nach Speichertyp variiert, im Gegensatz zu temporären Speicherlösungen, die Daten nach Abschluss einer Operation löschen.

Cloud Datastore (Beta) adressiert zwei Hauptanwendungsfälle:

• Schlüssel-Wert-Paar-Lösungen: Speichern Sie Nachschlagdaten wie US > Vereinigte Staaten, die über mehrere Operationen und Projekte hinweg referenziert werden können.
• Datenverarbeitung basierend auf Status-Workflows: Verwalten Sie Daten, die durch verschiedene Verarbeitungszustände bewegt werden, mit automatischer Bereinigung für verarbeitete Datensätze.

Cloud Datastore (Beta) unterstützt zwei Speichertypen mit unterschiedlichen Persistenzeigenschaften:

• Nachschlagen nach Schlüssel: Daten bleiben bestehen, bis sie ausdrücklich gelöscht werden, ideal für Referenzdaten und Nachschlagetabellen.
• Nachschlagen nach Wert: Daten mit Status-Workflows, bei denen Datensätze maximal 90 Tage aufbewahrt werden. Sobald die Daten jedoch den Verarbeitet Status erreichen, werden sie automatisch nach 60 Tagen gelöscht.

Cloud-Caching-Funktionen

Neben den Kernvariablen und Speicheranschlüssen bietet das Integration Studio Cloud-Caching-Funktionen, um die Integrationsleistung und -funktionalität zu verbessern.

Die Cloud-Caching-Funktionen ReadCache und WriteCache werden verwendet, um Datenspeicher zuzuweisen, die projekt- und umgebungsübergreifend verfügbar sind. Ein zwischengespeicherter Wert ist für alle Operationen, die im gleichen Geltungsbereich ausgeführt werden, sichtbar, bis er abläuft, unabhängig davon, wie diese Operation gestartet wurde oder auf welchem Agenten sie ausgeführt wird. Durch das Caching von Daten in Harmony, anstatt sich auf lokale oder agentenspezifische Datenspeicher wie Temporary Storage oder Variable-Anschlüsse zu verlassen, können Daten zwischen separaten Operationen und über Projekte hinweg geteilt werden.

Dies sind zusätzliche Verwendungen des Cloud-Cachings:

• Daten können zwischen asynchronen Operationen innerhalb eines Projekts geteilt werden.
• Fehler, die in verschiedenen Operationen erzeugt werden, könnten in einem gemeinsamen Cache gespeichert werden. Durch das Ansammeln von Operationsergebnissen auf diese Weise können umfassendere Warnmeldungen erstellt werden.
• Anmelde-Token können zwischen Operationen geteilt werden.