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 seiner 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 derselben Art (Sie können private und Cloud-Agenten nicht in einer Gruppe mischen). Agenten in einer Agentengruppe verarbeiten die Operationen Ihres Studio- oder Design Studio-Projekts. Gruppen bieten die folgenden Vorteile:
-
Intelligentes Routing: Um 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 Zuordnung bezeichnet.) Wenn eine Gruppe nur einen Agenten enthält, haben Sie keine Kontrolle darüber, welcher Agent eine Operation verarbeitet—das intelligente Routingsystem entscheidet, welcher Agent verwendet wird.
Dieser Routing-Service analysiert Jobanforderungen und gleicht sie mit den Funktionen einzelner Agenten ab (einschließlich deren Connectoren, Versionen und Betriebssysteme). Aus dem Pool der leistungsfähigen Agenten verteilt eine Lastwechsel-Strategie die Arbeitslast und verhindert Engpässe. Wenn ein vorgesehener Agent beschäftigt oder offline ist, wird der Job nahtlos an einen anderen verfügbaren Agenten in der Gruppe weitergeleitet. Jobs werden nur an Agenten gesendet, die online sind und aktiv mit Harmony kommunizieren. Wenn keine geeigneten Agenten sofort verfügbar sind, werden Jobs automatisch in eine Warteschlange eingereiht. Der Service sendet den Job dann weiter, sobald ein geeigneter Agent verfügbar wird.
Da diese Lastwechsel-Mechanismen die Fähigkeiten und Kapazitäten von Hosts bei der Arbeitsverteilung berücksichtigen, können Sie Hosts bereitstellen, um die typischen Lasten von Projekten oder Umgebungen besser zu entsprechen, und vermeiden die Tendenz zur Überversorgung und Übertragung von Ressourcen.
-
Hohe Verfügbarkeit: Wenn der Status eines Agenten aus irgendeinem Grund Beendet wird, bricht das System alle geplanten Operationen ab, die diesem zugewiesen sind, und führt neue Operationsinstanzen aus, wenn der Agent wieder aktiv ist. Wenn der Agent der einzige in einer Gruppe ist, werden Integrationsoperationen, die diese Gruppe verwenden, schließlich unterbrochen und schlagen fehl. Mit mehreren Agenten in einer Gruppe werden geplante Operationen, die auf einem Beendeten Agenten ausgeführt werden, abgebrochen und sofort auf einem aktiven Agenten neu erstellt. Dies stellt sicher, dass Ihre Projekte weiterhin ausgeführt werden, auch wenn ein Agent ausfällt, sei es ein geplantes Ereignis (wie im Fall von Softwareupgrades) oder ein unvorhergesehenes. Die Ausfallsicherheit nimmt proportional mit der Anzahl der Agenten in einer Gruppe zu.
-
Skalierbarkeit: Wenn Sie Ihr Wissen über die dynamischen Merkmale Ihrer Projekte verbessern, können Sie Agenten aus Gruppen hinzufügen oder entfernen, oder neue Gruppen und Umgebungen erstellen, die bestimmten Betriebsmustern gewidmet sind.
Die folgende Tabelle vergleicht die beiden Agentenarten:
| Funktion | Cloud-Agent | Privater Agent |
|---|---|---|
| Konfiguration | Keine | Manuell |
| Verantwortung | Jitterbit | Sie (der Kunde oder Partner) |
| Connector-Unterstützung | Einige | Alle |
| Custom Connector-Unterstützung | Einige | Alle |
| Unterstützung für Listening-Aktivitäten | Nein | Ja |
| Zusätzliches Logging | Einige | Alle |
| Benutzerdefinierte Netzwerkkonfiguration | Nein | Ja |
| Standard-Zeitzone1 | UTC | Betriebssystem-basiert |
| JDBC-Treiberunterstützung | Ja | Ja |
| ODBC-Treiberunterstützung | Nein | Ja |
| Unterstützung für zusätzliche/benutzerdefinierte Datenbanktreiber | Nein | Ja |
| SSH-Anmeldung mit Schlüssel | Nein | Ja |
| Lokale Datei-Quelle/Ziel | Nein | Konfigurierbar |
| Aufbewahrung von Operationsprotokollen | 30 Tage | Konfigurierbar |
| Operationszeitüberschreitung | Bis zu 6 Stunden | Konfigurierbar bis zu 24 Stunden |
| Gleichzeitige Operationen pro Agent | Automatisch (8) | Automatisch (2 x CPU-Kerne) |
| Bereinigungsintervall für temporäre Dateien | Kurz | Konfigurierbar |
| Limit für temporäre Speicherung | 50GB/Datei | Abhängig von Host-Ressourcen und Dateisystemtyp |
| Windows-Betriebssystem-Authentifizierung | Nein | Ja |
Cloud-Agenten
Cloud-Agenten sind Cloud-Services, die von Jitterbit verwaltet werden. Sie sind so konfiguriert, dass sie sich automatisch an Ihre Projekt-Workloads anpassen. Man muss Cloud-Agenten nicht installieren, konfigurieren, aktualisieren, starten oder stoppen.
Wichtig
Nicht alle Connectors werden von Cloud-Agenten unterstützt. Bevor man eine Umgebung für sein Integrationsprojekt auswählt, muss man sicherstellen, dass die gewünschten Connectors in der Umgebung laufen.
Cloud-Agent-Gruppen
Cloud-Agent-Gruppen sind Gruppen von Cloud-Agenten, die die gleiche Version ausführen. Sie sind in allen Harmony-Abos enthalten. Jitterbit stellt zwei Cloud-Agent-Gruppen pro Region bereit:
-
Production Cloud Agent Group: Eine Gruppe von Agenten in der aktuellen freigegebenen Version, vollständig getestet und produktionsreif.
-
Sandbox Cloud Agent Group: Eine Gruppe von Agenten in der aktuellen vorgeschlagenen nächsten Version, geeignet für Evaluierung und Tests.
Cloud-Agent-Gruppen erfordern keine Konfiguration oder Verwaltung. Im Gegensatz zu privaten Agenten sind einzelne Cloud-Agenten in der Management Console nicht sichtbar.
Private Agenten
Im Gegensatz zu Cloud-Agenten, die von Jitterbit verwaltet werden, muss man private Agenten installieren und konfigurieren (auf Windows, Linux oder Docker-Hosts, die die Systemanforderungen erfüllen) und sowohl Agenten als auch Gruppen über die Seite Management Console > Agenten verwalten.
Man kann private Agenten mit Jitterbit's nativen Observability-Metriken und mit einer der unterstützten Observability-Plattformen von Drittanbietern überwachen.
Private Agent-Gruppen
Bevor man einen privaten Agenten installieren und ausführen kann, benötigt man mindestens eine private Agent-Gruppe. (Private Agent-Gruppen sind ein lizenzierter Zusatz zu einem Harmony-Abo.) Standardmäßig werden keine privaten Agent-Gruppen bereitgestellt. Man muss diese erstellen und Umgebungen zuweisen. Eine private Agent-Gruppe muss mindestens einen privaten Agenten enthalten, und ein Agent kann sich jeweils nur in einer Gruppe befinden.
Wenn sich zwei oder mehr Agenten in einer Gruppe befinden, verarbeiten die Agenten abwechselnd ganze Operation-Chains, einschließlich untergeordneter Elemente. Dies hat die folgenden Folgen:
-
Es gibt keine Möglichkeit vorherzusagen, auf welchem Agenten eine Operation-Chain ausgeführt wird. Projekte mit Endpunkten, die lokalen Dateizugriff erfordern, sollten in einer Umgebung laufen, in der alle Agenten in der Gruppe Zugriff auf ein gemeinsames Dateisystem oder ein freigegebenes Laufwerk haben.
-
Die durchschnittliche Workload einzelner Agent-Hosts kann erheblich variieren.
-
Wenn ein Agent abstürzt, können Operationen hängen bleiben und Daten können verloren gehen.
Bei unterstützten Connectors und einer Mindestanzahl aktiver Agenten kann man den Listening-Service für Agenten in einer Gruppe aktivieren. Der Listening-Service ermöglicht es unterstützten Studio-Connectors, auf API-Ereignisse zu warten. Er nominiert auch einen der Agenten als Leader. Der Leader-Agent verteilt Operationsaufgaben gemäß Status und Last an Agenten. Wenn ein Agent abstürzt, können Daten wiederhergestellt werden.
Release-Plan und Versionshinweise
Der Release-Plan für Agenten variiert je nach Agenttyp:
-
Cloud-Agent-Gruppen werden automatisch nach dem Plan Sandbox Cloud Agent Group-Upgrade und Production Cloud Agent Group-Upgrade aktualisiert.
-
Aktualisierte Installer für private Agenten stehen auf der Seite Downloads nach Abschluss des Production Cloud Agent Group-Release zur Verfügung.
-
Das Private-Agent-Docker-Image wird bei Docker Hub nach Abschluss der Veröffentlichung der Production Cloud Agent Group in der Region Nordamerika (NA) verfügbar.
In den Harmony-Versionshinweisen ist jeder Agent-Typ als separate Zeile in der Versionstabelle oben auf jeder Seite mit Versionshinweisen aufgeführt. Einzelne Versionshinweise sind unter der Überschrift Agents aufgelistet, mit relevanten Hinweisen zur Anwendbarkeit auf bestimmte Agent-Typen in den Versionshinweisen.
Zusammenstellungen von Versionshinweisen für Production Cloud Agent Groups, Sandbox Cloud Agent Groups und Private Agents sind ebenfalls verfügbar.
Bekannte Probleme
In diesem Abschnitt werden bekannte Probleme aufgelistet, die in neueren Versionen von Private Agents identifiziert wurden. Bekannte Probleme mit anderen Jitterbit Harmony-Anwendungen finden Sie unter Bekannte Probleme.
Mehrere Versionen von Private Agents
Windows Private Agents 12.3
-
Windows Private Agent 12.3 Installer wegen bekanntem Problem entfernt
-
Zusammenfassung: Ein bekanntes Problem mit dem Windows Private Agent Version 12.3 führte dazu, dass der Installer kurz nach der Veröffentlichung entfernt wurde.
-
Workaround: Wenn Sie bereits Agent Version 12.3 unter Windows installiert haben, führen Sie ein Upgrade auf Agent Version 12.4 oder höher durch.
-
Linux Private Agents 11.31.1 und alle früheren Versionen
-
Geplante Operationen werden nach dem Neustart eines Linux Private Agents nicht ausgeführt
-
Zusammenfassung: Nach dem Neustart eines Linux Private Agents startet der
Scheduler-Service des Agents nicht, was dazu führt, dass geplante Operationen nicht wie erwartet ausgeführt werden. Dieses Problem tritt bei Windows Private Agents nicht auf. -
Zusätzliche Informationen: Der
Scheduler-Service des Linux Agents nutzt eine Bibliothek, die die neuesten Zeitzonen-Datendateien herunterlädt. Ab dem 4. September 2024 führte der Anbieter dieser Bibliothek einen Syntaxfehler ein, der dazu führt, dass derScheduler-Service nicht startet. -
Empfehlung: Dieses Problem wurde mit Version 11.31.2 behoben, die die problematische Bibliothek nicht mehr automatisch herunterlädt. Es wird empfohlen, Linux Private Agents auf Version 11.31.2 oder höher zu aktualisieren, um dieses Problem zu vermeiden und sich im Falle eines bereits aufgetretenen Problems davon zu erholen.
Alternativ können Sie, wenn Sie eine frühere Agent-Version nutzen, die folgenden Workaround- oder Wiederherstellungsschritte auf Nicht-Docker-Agents anwenden:
-
Workaround: Wenn ein Linux Private Agent noch nicht neu gestartet wurde, ändern Sie die
version-Datei unter/opt/jitterbit/TimeZoneDB/versionund setzen Sie den Wert auf2024b, um zu verhindern, dass die problematische Version der Datumsbibliothek vom Agent heruntergeladen wird. -
Wiederherstellung: Wenn ein Linux Private Agent bereits dieses Problem hat, ändern Sie die
northamerica-Datei unter/opt/jitterbit/TimeZoneDB/northamerica, um in allen VorkommenAprildurchAprzu ersetzen, um das Problem zu beheben. Starten Sie den Agent dann neu.
-
-
Windows Private Agents 11.44 bis 11.58
-
Upgrade-Fehler kann den PostgreSQL-Service entfernen
-
Zusammenfassung: Wenn Sie einen Windows Private Agent von einer Version vor 11.44 auf eine Version zwischen 11.44 und 11.58 aktualisieren und beim Installer-Prompt ein falsches PostgreSQL-Service-Konto-Passwort eingeben, kann das Upgrade fehlschlagen, ohne korrekt zurückzusetzen, was zu Agent-Ausfallzeiten führt.
-
Zusätzliche Informationen: Dieses Problem wurde in Private Agent 11.59 / 12.3 und höher behoben, wo ein falsches Passwort erfasst wird, bevor das Upgrade beginnt, ein Validierungsfehler im selben Dialog angezeigt wird, und das Abbrechen des Installers den bestehenden Agent intakt lässt.
-
Workaround: Wenn Sie dieses Problem bereits aufgetreten ist, lesen Sie PostgreSQL-Service nach fehlgeschlagenem Upgrade unter Windows entfernt für Wiederherstellungsschritte. Um das Problem vor dem Upgrade zu vermeiden, stellen Sie sicher, dass Sie das PostgreSQL-Service-Konto-Passwort kennen. Falls es unbekannt ist, lesen Sie Setzen Sie das PostgreSQL-Admin-Passwort zurück vor dem Upgrade.
-
Alle aktuellen Versionen
Diese Probleme gelten für alle aktuellen Versionen:
-
RHEL 9.7 und später: Fehler bei der Installation von nicht-root-Private Agents mit OpenSSL
-
Zusammenfassung: Red Hat Enterprise Linux (RHEL) 9.7 und später können nicht-root-Private Agents aufgrund von OpenSSL Version 3.5 nicht starten.
-
Zusätzliche Informationen: Der Fehler
ImportError: /opt/jitterbit/lib/libcrypto.so.3: version 'OPENSSL_3.4.0' not found (required by /usr/lib64/python3.9/lib-dynload/_hashlib.cpython-39-x86_64-linux-gnu.so)wird angezeigt. Dieses Problem tritt bei RHEL 9.6 und früher nicht auf, wo OpenSSL Version 3.0.14 verwendet wird. -
Abhilfe für 12.x Private Agents: Benennen Sie die gebündelten OpenSSL-Bibliotheken um, damit die von RHEL bereitgestellten OpenSSL-3.5-Bibliotheken verwendet werden:
cd /opt/jitterbit/lib sudo mv libcrypto.so.3 libcrypto.so.3.bak sudo mv libssl.so.3 libssl.so.3.bak -
Abhilfe für 11.x Private Agents: Deaktivieren Sie
LD_LIBRARY_PATHund starten Sie den Agent mit explizit gesetztemJITTERBIT_HOMEneu:unset LD_LIBRARY_PATH export JITTERBIT_HOME=/opt/jitterbit sudo JITTERBIT_HOME=/opt/jitterbit env -u LD_LIBRARY_PATH jitterbit restart
-
-
Windows Private Agent-Installation zeigt eine Microsoft Defender SmartScreen-Warnung an
-
Zusammenfassung: Bei der Installation eines Private Agents 10.69 oder später (für 10.x Agents) oder 11.8 oder später (für 11.x Agents) unter Windows 2019 oder Windows 10 kann eine Warnmeldung angezeigt werden.
-
Zusätzliche Informationen: Die Warnmeldung lautet „Windows hat Ihren PC geschützt" mit dem Hinweis, dass Microsoft Defender SmartScreen das Starten einer unbekannten App verhindert hat.
-
Abhilfe: Klicken Sie im Warnmeldungsdialog auf Weitere Informationen, um die Option Trotzdem ausführen anzuzeigen. Klicken Sie dann auf Trotzdem ausführen, um die Installation des Agents fortzusetzen.
-
-
Windows Private Agents: 64-Bit-Agent mit Zwei-Faktor-Authentifizierung (2FA) kann nicht installiert werden
-
Zusammenfassung: Die Installation eines 64-Bit-Windows-Private Agents schlägt fehl, wenn 2FA aktiv ist.
-
Zusätzliche Informationen: Das Installationsprogramm zeigt einen Fehlerdialog an.
-
Abhilfe: Deaktivieren Sie 2FA vorübergehend und installieren Sie den 64-Bit-Windows-Private Agent. Aktivieren Sie 2FA nach der Installation erneut.
-
-
ODBC-Verbindungen handhaben erweiterte Zeichen nicht korrekt
-
Zusammenfassung: Bei der Verbindung mit einer Datenbank über einen ODBC-Treiber werden einige erweiterte Zeichen, wie z. B. ein Gedankenstrich, von Operationen, die Daten upserten, nicht ordnungsgemäß verarbeitet.
-
Zusätzliche Informationen: Upsert-Operationen können fehlschlagen oder mit unbeabsichtigten Folgen erfolgreich sein, indem die falschen Daten beeinflusst werden. Beachten Sie, dass Insert- und Update-Operationen von diesem Problem nicht betroffen sind.
-
Abhilfe: 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 auf SFTP als Ziel in Design Studio oder Studio funktioniert die automatische Erstellung von Verzeichnissen inkonsistent.
-
Zusätzliche Informationen: Je nach FTP-Server können Verzeichnisse möglicherweise nicht erstellt werden.
-
Abhilfe: Stellen Sie sicher, dass das Verzeichnis vor der Verwendung in der Produktion erstellt wurde.
-
-
Funktion
SetSalesforceSessionfunktioniert nicht-
Zusammenfassung: Die Jitterbit Script-Funktion
SetSalesforceSessionfunktioniert nicht korrekt und sollte nicht in Design Studio oder Studio verwendet werden. -
Zusätzliche Informationen: Bei Verwendung kann das Script einen Fehler generieren oder auch nicht. Auch wenn das Script keinen Fehler generiert, funktioniert die Funktion nicht korrekt. Da die Funktion nicht funktioniert, wird die eingebaute Sitzungsverwaltung des Salesforce-Connectors verwendet.
-
-
Private Agents haben spezifische Systemanforderungen und bekannte Probleme
-
Zusammenfassung: Die Private Agents haben je nach verwendetem Betriebssystem unterschiedliche und spezifische Systemanforderungen sowie bekannte Probleme.
- Workaround: Siehe Systemanforderungen für Private Agents für Details.
-
Agent-Installation schlägt fehl, wenn das PostgreSQL-Passwort ein Pluszeichen (
+) enthält-
Zusammenfassung: Die Installation des Private Agent 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 Private Agent Installer und nicht mit PostgreSQL.
-
Workaround: Verwenden Sie ein Passwort ohne Pluszeichen (
+). Nach Abschluss der Installation kann das Passwort in ein beliebiges Passwort geändert werden, das für PostgreSQL akzeptabel ist.
-
11.26 Private Agents
-
Der Parameter
claimsder FunktionVerifyJwtClaimserhält nicht den korrekten Standardwert, wenn er leer gelassen wird-
Zusammenfassung: Bei Verwendung der Agent-Version 11.26 führt das Leerenlassen des optionalen Parameters
claimsmit der Jitterbit Script-FunktionVerifyJwtClaimszu einem Fehler. -
Workaround: Führen Sie ein Upgrade auf Agent-Version 11.27 oder später durch oder geben Sie
"{}"fürclaimsein. Beispiel:VerifyJwtClaims("AxE9qm4aTZiXvA2G8sblAxjeL...", "RS256", "Secret", "{}");.
-
10.87 / 11.25 und frühere Private Agents
-
Übermäßige Log-Einträge für den Microsoft Azure Service Bus Connector
-
Zusammenfassung: Bei Verwendung des Microsoft Azure Service Bus Connectors mit Agent-Version 10.87 / 11.25 oder früher werden in kurzer Zeit übermäßig viele
INFO-Logs generiert, was zu Speicherplatzproblemen aufgrund der Größe der Dateicatalina.outführt. -
Workaround: Ein Upgrade auf Agent-Version 11.26 oder später wird empfohlen. Alternativ kann dieses Problem in Agent-Version 10.87 / 11.25 oder früher behoben werden, indem die folgenden Einstellungen zur Datei
logback.xmlinC:\Program Files\Jitterbit Agent\tomcat\shared\lib(Windows) oder/opt/jitterbit/tomcat/shared/lib(Linux) hinzugefügt werden:<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 Agents
-
Täglicher Zeitplan wird während des Wechsels zur Sommerzeit übersprungen
-
Zusammenfassung: Bei Verwendung der Agent-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 die folgenden bekannten Probleme auf:
-
Wenn ein täglicher Zeitplan zwischen 1 und 2 Uhr morgens festgelegt ist, wird der geplante Vorgang am ersten Sonntag im November aufgrund des Sommerzeitwechsels nicht ausgeführt.
-
Wenn ein täglicher Zeitplan zwischen 2 und 3 Uhr morgens festgelegt ist, wird der geplante Vorgang am zweiten Sonntag im März aufgrund des Sommerzeitwechsels nicht ausgeführt.
-
-
Workaround: Führen Sie ein Upgrade auf Agent-Version 10.85 / 11.23 oder später durch oder legen Sie die Agent-Zeitzone auf UTC fest, indem Sie die Organisationsrichtlinie Override Schedule Agent Time Zone verwenden und Etc/UTC auswählen.
-
10.45 und frühere Private Agents
-
Apache Log4j2 JNDI-Sicherheitslücken beeinflussen Private Agents
- Zusammenfassung: Apache Log4j2-Sicherheitslücken CVE-2021-44228 und CVE-2021-45046 beeinflussen Private Agents, die Studio Connectors verwenden, die mit dem Studio Connector SDK erstellt wurden.
-
Abhilfe: Eine Notfallwartung hat die Sicherheitslücken behoben. Nach der Wartung mussten private Agenten neu gestartet und eine Operation für jeden betroffenen Connector ausgeführt werden, damit das Update wirksam wird. Detaillierte Informationen und Anweisungen finden Sie unter Apache Log4j2 JNDI-Sicherheitslücke beheben.
10.38 Linux private agents
-
Die PostgreSQL-Datenbank wird beim Upgrade von Version 10.37 auf 10.38 neu initialisiert
-
Hintergrund: Beim Upgrade eines Linux private agent von einer Version vor 10.37 auf Version 10.37 oder später wird die PostgreSQL-Datenbank neu initialisiert, da sie auf Version 9.6 aktualisiert wird. Dieses Upgrade erstellt die Datenbank auf dem private agent neu und die Daten werden während dieses Upgradevorgangs wiederhergestellt. Nach dem Upgrade sind alle mit einer früheren PostgreSQL-Version erstellten Sicherungen nicht kompatibel. Der Upgradeprozess kann je nach Anzahl der Projekte und Größe der mit der private agent-Gruppe verknüpften Umgebungen mehr als 30 Minuten dauern. Alle ausstehenden Jobs werden in eine Warteschlange eingereiht, um nach Abschluss des Upgrades ausgeführt zu werden. Dieses Upgrade betrifft nicht den Windows private agent.
-
Bekanntes Problem: Es ist ein bekanntes Problem, dass die PostgreSQL-Datenbank beim Upgrade eines Linux private agent von Version 10.37 auf 10.38 neu initialisiert wird.
-
Problemumgehung: Upgrade auf einen Linux private agent der Version 10.39 oder höher.
-
10.0 private agents
-
Der Studio Cherwell-Connector funktioniert nicht
-
Zusammenfassung: Seit dem Harmony Release 10.1 ist eine Änderung am Cherwell-Connector in Studio nicht mehr mit 10.0-Agenten kompatibel.
-
Problemumgehung: Wenn Sie den Cherwell-Connector verwenden, führen Sie bitte ein Upgrade auf Version 10.1 oder höher durch.
-
-
Sofern die Option Zeitzone des Planungsagenten überschreiben in der Management Console auf der Seite Organisationen nicht aktiviert ist. ↩