Jitterbit-Agenten

Übersicht

Die Harmony-Agenten von Jitterbit verarbeiten die Operationen Ihrer Integrationsprojekte und senden sowie empfangen Endpunktdaten. Es gibt zwei Arten von Agenten: Cloud und privat:

• Cloud: Jitterbit verwaltet Cloud-Agenten auf ihrer eigenen Cloud-Infrastruktur. Sie müssen nichts einrichten oder konfigurieren.

• Privat: Sie müssen private Agenten auf Ihrer eigenen Cloud- oder physischen Infrastruktur einrichten, konfigurieren und verwalten.

Alle Agenten sind Mitglieder einer Gruppe. Agentengruppen sind Gruppen von Agenten desselben Typs (Sie können private und Cloud-Agenten nicht in einer Gruppe mischen). Agenten in einer Agentengruppe verarbeiten die Operationen Ihres Studio oder Design Studios Projekts. Gruppen bieten die folgenden Vorteile:

• Intelligente Weiterleitung: Um die Leistung und Zuverlässigkeit zu verbessern, werden die Operationen eines Projekts zur Verarbeitung an eine Agentengruppe gesendet, anstatt an einzelne Agenten. (Welche Agentengruppe ein Projekt verwendet, hängt von der Umgebung ab, in der ein Projekt bereitgestellt wird. Die Beziehung zwischen einer Umgebung und ihrer Agentengruppe wird als Assoziation bezeichnet.) Es sei denn, es gibt nur einen Agenten in einer Gruppe, haben Sie keine Kontrolle darüber, von welchem Agenten eine Operation verarbeitet wird—das intelligente Weiterleitungssystem entscheidet, welcher Agent verwendet wird.

  Dieser Weiterleitungsdienst analysiert die Anforderungen der Aufgaben und vergleicht sie mit den Fähigkeiten der einzelnen Agenten (dazu gehören ihre Connectoren, Versionen und Betriebssysteme). Aus dem Pool fähiger Agenten verteilt eine Lastenausgleichsstrategie die Arbeitslast, um Engpässe zu vermeiden. Wenn ein zugewiesener Agent beschäftigt oder offline ist, wird die Aufgabe nahtlos an einen anderen verfügbaren Agenten in der Gruppe weitergeleitet. Aufgaben werden nur an Agenten gesendet, die online sind und aktiv mit Harmony kommunizieren. Wenn keine geeigneten Agenten sofort verfügbar sind, werden Aufgaben automatisch in eine Warteschlange gestellt. Der Dienst sendet die Aufgabe dann, sobald ein geeigneter Agent verfügbar wird.

  Da diese Lastverteilungsmechanismen die Fähigkeiten und Kapazitäten der Hosts bei der Arbeitsverteilung berücksichtigen, können Sie Hosts bereitstellen, die besser zu den charakteristischen Lasten von Projekten oder Umgebungen passen, wodurch die Tendenz vermieden wird, übermäßig viele Ressourcen bereitzustellen und auszugeben.

• Hohe Verfügbarkeit: Wenn aus irgendeinem Grund der Status eines Agents auf Gestoppt wechselt, storniert das System alle ihm zugewiesenen geplanten Operationen und führt neue Betriebsinstanzen aus, wenn der Agent wieder aktiv ist. Wenn der Agent der einzige in einer Gruppe ist, laufen Integrationsoperationen, die diese Gruppe verwenden, schließlich ab und schlagen fehl. Bei mehreren Agents in einer Gruppe werden geplante Operationen, die auf einem Gestoppten Agenten laufen, storniert und sofort auf einem aktiven Agenten neu erstellt. Dies stellt sicher, dass Ihre Projekte auch dann weiterlaufen, wenn ein Agent ausfällt, sei es ein geplanter Vorfall (wie im Fall von Software-Updates) oder ein unvorhergesehener. Das Maß an Fehlertoleranz steigt proportional zur Anzahl der Agents in einer Gruppe.

• Skalierbarkeit: Wenn Sie Ihr Wissen über die dynamischen Eigenschaften Ihrer Projekte verbessern, können Sie Agents aus Gruppen hinzufügen oder entfernen oder neue Gruppen und Umgebungen schaffen, die bestimmten Betriebsmustern gewidmet sind.

Die folgende Tabelle vergleicht die beiden Arten von Agenten:

Cloud-Agenten

Cloud-Agenten sind Cloud-Dienste, die von Jitterbit verwaltet werden. Sie sind so konfiguriert, dass sie sich automatisch an Ihre Projektlasten anpassen. Sie müssen Cloud-Agenten nicht installieren, konfigurieren, aktualisieren, starten oder stoppen.

Cloud-Agenten-Gruppen

Cloud-Agenten-Gruppen sind Gruppen von Cloud-Agenten, die dieselbe Version ausführen. Sie sind in allen Harmony-Abonnements enthalten. Jitterbit bietet für jede Region zwei Cloud-Agenten-Gruppen an:

• Produktions-Cloud-Agenten-Gruppe: Eine Gruppe von Agenten auf der derzeit veröffentlichten Version, die vollständig getestet und bereit für die Produktion ist.

• Sandbox-Cloud-Agenten-Gruppe: Eine Gruppe von Agenten auf der derzeit vorgeschlagenen nächsten Version, die für Evaluierung und Tests geeignet ist.

Cloud-Agenten-Gruppen benötigen keine Konfiguration oder Verwaltung. Im Gegensatz zu privaten Agenten sind einzelne Cloud-Agenten nicht in der Management Console sichtbar.

Private Agenten

Im Gegensatz zu Cloud-Agenten, die von Jitterbit verwaltet werden, müssen Sie private Agenten (auf Windows, Linux, oder Docker Hosts, die die Systemanforderungen erfüllen) installieren und konfigurieren und sowohl Agenten als auch Gruppen über die Management Console > Agenten verwalten.

Sie können private Agenten mit Jitterbits nativem Beobachtungsmetriken und mit einer der unterstützten Drittanbieter-Beobachtungsplattformen überwachen.

Private agent groups

Bevor Sie einen privaten Agenten installieren und ausführen können, benötigen Sie mindestens eine private Agentengruppe. (Private Agentengruppen sind eine lizenzierbare Ergänzung zu Ihrem Harmony-Abonnement.) Standardmäßig sind keine privaten Agentengruppen vorhanden. Sie müssen diese erstellen und Umgebungen zuweisen. Eine private Agentengruppe muss mindestens einen privaten Agenten enthalten, und ein Agent kann sich nur in einer Gruppe gleichzeitig befinden.

Wenn sich zwei oder mehr Agenten in einer Gruppe befinden, wechseln die Agenten sich ab, um gesamte Operation Chains zu verarbeiten, einschließlich der Kinder. Dies hat folgende Konsequenzen:

• Es gibt keine Möglichkeit vorherzusagen, auf welchem Agenten eine Operation Chain ausgeführt wird. Projekte mit Endpunkten, die lokalen Datei Zugriff erfordern, sollten in einer Umgebung ausgeführt werden, in der alle Agenten in der Gruppe Zugriff auf ein gemeinsames Dateisystem oder ein freigegebenes Laufwerk haben.

• Die durchschnittliche Arbeitslast der einzelnen Agenten-Hosts kann erheblich variieren.

• Wenn ein Agent abstürzt, können Operationen hängen bleiben und Daten könnten verloren gehen.

Für unterstützte Connectoren und eine Mindestanzahl aktiver Agenten können Sie den Listening Service für Agenten in einer Gruppe aktivieren. Der Listening Service ermöglicht es unterstützten Studio-Connectors, auf API-Ereignisse zu hören. Er nominiert auch einen der Agenten als Leiter. Der Leiter-Agent verteilt Operationen an Agenten entsprechend ihrem Status und ihrer Last. Wenn ein Agent abstürzt, können Daten wiederhergestellt werden.

Release schedule and release notes

Der Release-Zeitplan für Agenten variiert je nach Agententyp:

• Cloud-Agentengruppen werden automatisch nach dem Upgrade des Sandbox Cloud Agent Group und dem Upgrade der Produktions-Cloud-Agentengruppe aktualisiert.

• Aktualisierte private Agenten-Installer sind nach dem Abschluss des Releases der Produktions-Cloud-Agentengruppe auf der Downloads Seite verfügbar.

• Das Docker-Image des privaten Agents ist nach dem Abschluss der Veröffentlichung der Produktions-Cloud-Agent-Gruppe für die Region Nordamerika (NA) auf Docker Hub verfügbar.

In den Harmony-Versionshinweisen ist jeder Agenttyp als separater Punkt in der Tabelle der Veröffentlichungsdaten am Anfang jeder Versionshinweis-Seite aufgeführt. Einzelne Versionshinweise sind unter der Überschrift Agents aufgeführt, wobei relevante Anwendbarkeit auf bestimmte Agenttypen in den Versionshinweisen enthalten ist.

Zusammenstellungen von Versionshinweisen für Produktions-Cloud-Agent-Gruppen, Sandbox-Cloud-Agent-Gruppen und private Agents sind ebenfalls verfügbar.

Bekannte Probleme

In diesem Abschnitt werden bekannte Probleme aufgeführt, die mit den neuesten Versionen der privaten Agents identifiziert wurden. Für bekannte Probleme, die mit anderen Jitterbit Harmony-Anwendungen identifiziert wurden, siehe Bekannte Probleme.

Mehrere Versionen von privaten Agents

Linux-private Agents 11.31.1 und alle früheren Versionen

• Geplante Operationen werden nach einem Neustart eines Linux-privaten Agents nicht ausgeführt

  • Zusammenfassung: Nach dem Neustart eines Linux-privaten Agents startet der Scheduler-Dienst des Agents nicht, was dazu führt, dass geplante Operationen nicht wie erwartet ausgeführt werden. Dieses Problem tritt bei Windows-privaten Agents nicht auf.

  • Zusätzliche Informationen: Der Scheduler-Dienst des Linux-Agents verwendet eine Bibliothek, die die neuesten Zeitzonendaten-Dateien herunterlädt. Ab dem 4. September 2024 hat der Anbieter dieser Bibliothek einen Syntaxfehler eingeführt, der dazu führt, dass der Scheduler-Dienst nicht startet.

  • Empfehlung: Dieses Problem wird mit der Version 11.31.2 behoben, die die Bibliothek, die das Problem verursacht, nicht mehr automatisch herunterlädt. Wir empfehlen, Linux-private Agents auf 11.31.2 oder höher zu aktualisieren, um zu verhindern, dass dieses Problem auftritt, und in Fällen, in denen es bereits auftritt, um sich davon zu erholen.

    Alternativ können Sie, wenn Sie eine frühere Agentenversion verwenden, die folgenden Workarounds oder Wiederherstellungsschritte für Nicht-Docker-Agenten anwenden:

    • Workaround: Wenn ein Linux-Privatagent noch nicht neu gestartet wurde, um zu verhindern, dass dieses Problem auftritt, bearbeiten Sie die Datei version unter /opt/jitterbit/TimeZoneDB/version und ändern Sie ihren Wert in 2024b. Dadurch wird verhindert, dass die fehlerhafte Version der Datumsbibliothek vom Agenten heruntergeladen wird.

    • Wiederherstellung: Wenn ein Linux-Privatagent bereits dieses Problem hat, bearbeiten Sie die Datei northamerica unter /opt/jitterbit/TimeZoneDB/northamerica, um den Wert April in allen Vorkommen durch Apr zu ersetzen. Starten Sie dann den Agenten neu.

Windows-Privatagenten 11.44 bis 11.58

• Upgrade-Fehler kann den PostgreSQL-Dienst entfernen

  • Zusammenfassung: Beim Upgrade eines Windows-Privatagenten von einer Version vor 11.44 auf eine Version zwischen 11.44 und 11.58 kann die Eingabe eines falschen Passworts für das PostgreSQL-Dienstkonto an der Eingabeaufforderung des Installationsprogramms dazu führen, dass das Upgrade fehlschlägt, ohne korrekt zurückgerollt zu werden, was zu Ausfallzeiten des Agenten führt.

  • Zusätzliche Informationen: Dieses Problem wird in den Privatagenten 11.59 / 12.3 und später behoben, wo ein falsches Passwort erkannt wird, bevor das Upgrade beginnt, ein Validierungsfehler im selben Dialog angezeigt wird und das Abbrechen des Installationsprogramms den bestehenden Agenten intakt lässt.

  • Workaround: Wenn Sie bereits auf dieses Problem gestoßen sind, siehe PostgreSQL-Dienst nach fehlgeschlagenem Upgrade unter Windows entfernt für Wiederherstellungsschritte. Um das Problem vor dem Upgrade zu vermeiden, stellen Sie sicher, dass Sie das Passwort für das PostgreSQL-Dienstkonto kennen. Wenn es unbekannt ist, siehe Setzen Sie das PostgreSQL-Admin-Passwort zurück vor dem Upgrade.

Alle aktuellen Versionen

Diese Probleme gelten für alle aktuellen Versionen:

• Installation des Windows-Privatagenten zeigt eine Microsoft Defender SmartScreen-Warnung

• Zusammenfassung: Bei der Installation eines privaten Agents der Version 10.69 oder höher (für 10.x Agents) oder 11.8 oder höher (für 11.x Agents) unter Windows 2019 oder Windows 10 kann eine Warnmeldung erscheinen.

  • Zusätzliche Informationen: Die Warnmeldung lautet "Windows hat Ihren PC geschützt" mit einem Hinweis, dass Microsoft Defender SmartScreen eine nicht erkannte App am Starten gehindert hat.

  • Umgehungslösung: Klicken Sie im Dialogfeld der Warnmeldung auf Weitere Informationen, um die Option Trotzdem ausführen anzuzeigen. Klicken Sie dann auf Trotzdem ausführen, um mit der Installation des Agents fortzufahren.

• Windows private Agents: Installation des 64-Bit-Agents mit Zwei-Faktor-Authentifizierung (TFA) nicht möglich

  • Zusammenfassung: Die Installation eines 64-Bit Windows privaten Agents schlägt fehl, wenn TFA aktiv ist.

  • Zusätzliche Informationen: Der Installer zeigt ein Fehlermeldungsdialogfeld an.

  • Umgehungslösung: Deaktivieren Sie vorübergehend TFA und installieren Sie den 64-Bit Windows privaten Agent. Aktivieren Sie TFA nach der Installation wieder.

• ODBC-Verbindungen verarbeiten erweiterte Zeichen nicht korrekt

  • Zusammenfassung: Bei der Verbindung zu einer Datenbank mit einem ODBC-Treiber werden einige erweiterte Zeichen, wie ein Gedankenstrich, von Operationen, die Daten upserten, nicht korrekt verarbeitet.

  • Zusätzliche Informationen: Upsert-Operationen können fehlschlagen oder mit unbeabsichtigten Folgen erfolgreich sein, indem sie die falschen Daten beeinflussen. Beachten Sie, dass Insert- und Update-Operationen von diesem Problem nicht betroffen sind.

  • Umgehungslösung: Verwenden Sie einen JDBC-Treiber für die Datenbankverbindung (siehe Anweisungen für Design Studio oder Studio).

• SFTP-Verzeichnisse werden manchmal nicht automatisch erstellt

  • Zusammenfassung: Beim Schreiben zu SFTP als Ziel mit Design Studio oder Studio funktioniert die automatische Erstellung von Verzeichnissen inkonsistent.

  • Zusätzliche Informationen: Je nach dem spezifischen beteiligten FTP-Server wird das Verzeichnis möglicherweise nicht erstellt.

  • Umgehungslösung: Bestätigen Sie, dass das Verzeichnis vor der Produktionsnutzung erstellt wurde.

• SetSalesforceSession Funktion funktioniert nicht

  • Zusammenfassung: Die Jitterbit-Skriptfunktion SetSalesforceSession funktioniert nicht korrekt und sollte im Design Studio oder Studio nicht verwendet werden.

  • Zusätzliche Informationen: Wenn sie verwendet wird, kann das Skript einen Fehler generieren oder auch nicht. Selbst wenn das Skript keinen Fehler generiert, wird die Funktion nicht korrekt arbeiten. Da die Funktion nicht funktioniert, wird die integrierte Sitzungsverwaltung des Salesforce-Connectors verwendet.

• Private Agenten haben spezifische Systemanforderungen und bekannte Probleme

  • Zusammenfassung: Die privaten Agenten haben unterschiedliche und spezifische Systemanforderungen sowie bekannte Probleme, abhängig vom verwendeten Betriebssystem.

  • Umgehungslösung: Siehe die Systemanforderungen für private Agenten für Details.

• Agenteninstallation schlägt fehl, wenn das PostgreSQL-Passwort ein Pluszeichen (+) enthält

  • Zusammenfassung: Die Installation des privaten Agenten schlägt fehl, wenn das PostgreSQL-Passwort ein Pluszeichen (+) enthält. Es wird keine Fehlermeldung angezeigt.

  • Zusätzliche Informationen: Dies ist ein Problem mit dem Installer des privaten Agenten, nicht mit PostgreSQL.

  • Umgehungslösung: Verwenden Sie ein Passwort ohne Pluszeichen (+). Nach Abschluss der Installation kann das Passwort auf ein beliebiges, für die Verwendung mit PostgreSQL akzeptables Passwort geändert werden.

11.26 private agents

• Der claims-Parameter der VerifyJwtClaims-Funktion hat keinen Standardwert, wenn er leer gelassen wird

  • Zusammenfassung: Bei Verwendung der Agentenversion 11.26 führt das Leerlassen des optionalen claims-Parameters mit der VerifyJwtClaims Jitterbit-Skriptfunktion zu einem Fehler.

  • Umgehungslösung: Aktualisieren Sie auf die Agentenversion 11.27 oder höher oder geben Sie "{}" für claims ein. Zum Beispiel: VerifyJwtClaims("AxE9qm4aTZiXvA2G8sblAxjeL...", "RS256", "Secret", "{}");.

10.87 / 11.25 und frühere private Agenten

• Übermäßige Protokolleinträge für den Microsoft Azure Service Bus-Connector

  • Zusammenfassung: Bei der Verwendung des Microsoft Azure Service Bus-Connectors mit der Agenten-Version 10.87 / 11.25 oder früher werden in kurzer Zeit übermäßig viele INFO-Protokolle generiert, was zu Speicherplatzproblemen aufgrund der Größe der Datei catalina.out führt.

  • Umgehungslösung: Ein Upgrade auf die Agenten-Version 11.26 oder höher wird empfohlen. Alternativ kann dieses Problem in der Agenten-Version 10.87 / 11.25 oder früher behoben werden, indem die folgenden Einstellungen in die Datei logback.xml eingefügt werden, die sich in C:\Program Files\Jitterbit Agent\tomcat\shared\lib (Windows) oder /opt/jitterbit/tomcat/shared/lib (Linux) befindet:

    <logger name="com.azure.core.amqp" level="ERROR"/>
    <logger name="com.azure.messaging.servicebus" level="ERROR"/>
    <logger name="com.azure.core.implementation" level="ERROR"/>
    

10.84 / 11.22 und frühere private Agenten

• Einmal täglich geplante Aufgaben werden während des Wechsels zur Sommerzeit übersprungen

  • Zusammenfassung: Bei der Verwendung der Agenten-Version 10.84 / 11.22 oder früher und wenn der Agent eine Zeitzone verwendet, die die Sommerzeit berücksichtigt, treten während eines Wechsels zur Sommerzeit folgende bekannte Probleme auf:

    • Wenn eine einmal täglich geplante Aufgabe zwischen 1 und 2 Uhr morgens festgelegt ist, schlägt die geplante Operation am ersten Sonntag im November aufgrund der Sommerzeit fehl.

    • Wenn eine einmal täglich geplante Aufgabe zwischen 2 und 3 Uhr morgens festgelegt ist, schlägt die geplante Operation am zweiten Sonntag im März aufgrund der Sommerzeit fehl.

  • Umgehungslösung: Upgrade auf die Agenten-Version 10.85 / 11.23 oder höher oder die Zeitzone des Agenten auf UTC setzen, indem die Zeitzone des Agenten überschreiben Organisationsrichtlinie verwendet und Etc/UTC ausgewählt wird.

10.45 und frühere private Agenten

• Apache Log4j2 JNDI-Sicherheitsanfälligkeiten betreffen private Agenten

  • Zusammenfassung: Die Sicherheitsanfälligkeiten von Apache Log4j2 CVE-2021-44228 und CVE-2021-45046 betreffen private Agenten, die Studio-Connectoren verwenden, die mit dem Studio Connector SDK erstellt wurden.

  • Minderung: Eine Notfallwartung hat die Sicherheitsanfälligkeiten behoben. Nach der Wartung mussten die privaten Agenten neu gestartet und eine Operation für jeden betroffenen Connector ausgeführt werden, damit das Update wirksam wird. Für detaillierte Informationen und Anweisungen siehe Minderung der Apache Log4j2 JNDI-Sicherheitsanfälligkeit.

10.38 Linux private Agenten

• Die PostgreSQL-Datenbank wird bei einem Upgrade von Version 10.37 auf 10.38 neu initialisiert

  • Hintergrund: Bei einem Upgrade eines Linux privaten Agenten von einer Version vor 10.37 auf eine Version, die 10.37 oder später ist, wird die PostgreSQL-Datenbank neu initialisiert, während sie auf Version 9.6 aktualisiert wird. Dieses Upgrade wird die Datenbank auf Ihrem privaten Agenten neu erstellen und Ihre Daten werden während dieses Upgrade-Prozesses wiederhergestellt. Nach dem Upgrade sind alle Sicherungen, die mit einer früheren PostgreSQL-Version erstellt wurden, nicht mehr kompatibel. Der Upgrade-Prozess kann je nach Anzahl der Projekte und der Größe der Umgebungen, die mit Ihrer Gruppe privater Agenten verbunden sind, mehr als 30 Minuten in Anspruch nehmen. Alle ausstehenden Jobs werden in eine Warteschlange gestellt, um nach Abschluss des Upgrades ausgeführt zu werden. Dieses Upgrade betrifft nicht den Windows privaten Agenten.

  • Bekanntes Problem: Es ist ein bekanntes Problem, dass bei einem Upgrade eines Linux privaten Agenten von Version 10.37 auf 10.38 die PostgreSQL-Datenbank neu initialisiert wird.

  • Umgehungslösung: Upgrade auf einen Linux privaten Agenten, der Version 10.39 oder später ist.

10.0 private agents

• Der Studio Cherwell-Connector funktioniert nicht

  • Zusammenfassung: Ab der 10.1 Harmony-Version ist eine Änderung am Cherwell-Connector im Studio vorgenommen worden, die ihn nicht mehr mit 10.0-Agenten kompatibel macht.

  • Umgehungslösung: Wenn der Cherwell-Connector verwendet wird, bitte auf 10.1-Agenten oder höher aktualisieren.