Fehlerbehebung bei Operationen in Jitterbit Studio

Diese Anleitung behandelt Fehler und unerwartetes Verhalten beim Erstellen, Bereitstellen und Ausführen von Operationen in Jitterbit Studio, einschließlich Operationen, Transformationen, Skripts und Funktionen sowie Design-Zeit-Validierung. Wenn man Probleme mit einem bestimmten Connector behebt, siehe Connector-Fehlerbehebung.

Für eine einheitliche Referenz, die Integrations-, Automatisierungs-, API-Management-, EDI- und App-Entwicklungsprobleme an einer Stelle abdeckt, siehe Harmony-Fehlerbehebungsanleitung.

• HTTP- und API-Fehler

  • 504 Gateway Timeout
  • 507 Insufficient Storage
  • 502 Bad Gateway

• Fehler zur Entwurfszeit

  • Häufige Validierungsfehler bei Operationen
  • HTTP-Validierungsregelfehler
  • Komponentennamen müssen nach dem Projektimport eindeutig sein
  • Private Agent-exklusive Connector-Blöcke können nicht in eine Cloud-Agent-Umgebung importiert werden
  • Das Hochladen einer Schemadatei ersetzt diese projektübergreifend
  • Die Bereitstellung der Marketplace-Prozessvorlage schlägt aufgrund von Schemainkompatibilität fehl
  • Studio wird bei sehr großen Projekten langsam oder reagiert nicht

• System- und Ressourcenfehler

  • Chunking erfordert einen nativen Connector als Quelle
  • Variablenupdates gehen bei mehrgethreaded Chunking-Operationen verloren
  • Fehler beim Erstellen des temporären Verzeichnisses
  • Operationsprotokollmeldungen werden bei etwa 100 KB gekürzt
  • Das Debug-Logging von Operationen offenbart PII und Anmeldedaten im Klartext

Diagnoseschritte

Diese Schritte gelten für nahezu alle Operationsfehler und sind der empfohlene Ausgangspunkt, bevor man einen bestimmten Fehler untersucht.

Verbindung testen

Für alle Operationen, die Connectors verwenden, klickt man in der Verbindung auf die Schaltfläche Test, um sicherzustellen, dass die Verbindung erfolgreich ist.

Für Connectors, die in Operationen bereitgestellt sind, die auf privaten Agents ausgeführt werden, stellt das Klicken auf Test auch sicher, dass die neueste Version des Connectors auf den Agent heruntergeladen wird (es sei denn, die Organisationsrichtlinie Automatisches Connector-Update deaktivieren ist aktiviert).

Operationsprotokolle prüfen

Man prüft die Operationsprotokolle auf alle Informationen, die während der Ausführung geschrieben wurden.

Abhängig vom Agent-Typ stehen zusätzliche Protokolldaten zur Verfügung:

• Debug-Logging für Operationen aktivieren (für Cloud-Agents oder für private Agents).
• Verbose-Logging für Connectors aktivieren (nur private Agents).
• Agent-Protokolle prüfen (nur private Agents).

Agent-spezifische Fehler isolieren

Wenn eine Operation auf einigen Agents fehlschlägt, aber auf anderen innerhalb derselben privaten Agent-Gruppe erfolgreich ist, verwendet man die Option Auf dedizierten Agent ausführen, um die Operation auf einen bestimmten Agent zu lenken. Dies ermöglicht es, den Fehler auf dem problematischen Agent zu reproduzieren und zu untersuchen, ohne den Rest der Gruppe offline zu nehmen.

Um diese Option zu konfigurieren, öffnet man die Operationseinstellungen, wählt die Registerkarte Optionen und konfiguriert Auf dedizierten Agent ausführen.

Operationsausführung und Planung

Operationen, die im Status „Submitted" oder „Running" stecken

• Symptom: Eine Operation wird nicht wie erwartet abgeschlossen. Sie bleibt im Status Submitted oder Running stecken und macht keinen Fortschritt, oder wird mit der Meldung abgebrochen:

  Long running operation canceled by System
  

  Der Abbruch kann erfolgen, nachdem die Operation eine Zeit lang ausgeführt wurde, oder kurz nach ihrem Start, und spiegelt nicht unbedingt wider, wie lange die Operation tatsächlich ausgeführt wurde.

• Mögliche Ursachen:

  • Ein privater Agent hat die Verbindung zur Harmony-Plattform verloren und konnte den Operationsstatus nicht melden. Die Plattform zeigt die Operation weiterhin als Running an und bricht sie möglicherweise ab, als ob sie hängend wäre, auch wenn die Operation auf dem Agent abgeschlossen wurde. Dies kann Operationen betreffen, die normalerweise in Sekunden abgeschlossen sind.
  • Die Operation wurde abgeschlossen, aber der endgültige Status wurde nicht an Harmony zurückgemeldet, daher wird sie weiterhin als Running angezeigt, bis sie ausläuft.
  • Die Agent-Gruppe ist stark ausgelastet und verzögert sich beim Abholen oder Aktualisieren von Operationen in der Warteschlange.
  • Die Operation steckt speziell im Status Submitted fest: Die Ausführungsmitteilung wurde in die Warteschlange eingereiht, aber kein Agent in der Gruppe hat sie akzeptiert, da die Agents offline, fehlerhaft oder keine freie Kapazität haben, um neue Operationen zu akzeptieren (z. B. ist jeder Worker-Thread beschäftigt).

• Lösung:

  • Bei privaten Agenten müssen Sie bestätigen, dass der Agent den Status Running auf der Seite Agents in der Management Console hat. Überprüfen Sie die Protokolle des privaten Agenten auf Verbindungsprobleme und stellen Sie sicher, dass die Netzwerkverbindung zwischen dem Agent und der Harmony-Plattform stabil ist.
  • Überprüfen Sie die Vorgangsprotokolle, um zu bestätigen, was während der Ausführung passiert ist. Die Abbruchmeldung kann auch bei Vorgängen angezeigt werden, die nur kurz ausgeführt wurden. Dies deutet daher nicht unbedingt auf einen tatsächlich lange laufenden Vorgang hin. Die Protokolle können auch einen spezifischen Fehler offenbaren, z. B. 401 Unauthorized (Anmeldedaten überprüfen) oder 429 Too Many Requests. Ein 429 von einem Zielendpunkt kann durch Reduzierung der Anfragerate oder durch Hinzufügen von Wiederholungslogik verringert werden. Ein 429 vom von Jitterbit verwalteten Cloud-API-Gateway ist das Plattformlimit von 200 Anfragen pro Minute. Verteilen Sie daher die Aufrufe zeitlich oder führen Sie die betroffenen APIs auf privaten Agenten aus.
  • Halten Sie private Agenten auf einer aktuellen Version. Neuere Agent-Versionen verbessern die Agent-Stabilität und reduzieren vorzeitige Abbrüche von Vorgängen.
  • Versuchen Sie, die betroffenen Vorgänge abzubrechen. Der Abbruch ist für Vorgänge mit dem Status Submitted, Received, Pending oder Running verfügbar. Dies können Sie von der Seite Runtime in der Management Console, aus der Vorgangsprotokolltabelle oder vom Runtime-Status eines Vorgangs auf der Design-Canvas aus durchführen.
  • Falls der betroffene Vorgang nach einem Zeitplan ausgeführt wird und nie startet, lesen Sie Geplante Vorgänge werden nicht ausgeführt.
  • Falls die Vorgänge nicht abgebrochen werden können, falls das Problem erneut auftritt oder falls viele Vorgänge gleichzeitig betroffen sind, wenden Sie sich an den Jitterbit-Support. Diese Fälle erfordern möglicherweise eine Lösung auf Serverseite.

Geplante Vorgänge werden nicht ausgeführt

• Symptom: Ein Vorgang mit einem Operationszeitplan wird zur geplanten Zeit nicht ausgeführt oder wird versendet, bleibt aber in einem Status Pending oder Received stehen.
• Mögliche Ursachen:
  • Der Zeitplan wurde dem Vorgang in Studio zugewiesen, aber das Projekt wurde nicht bereitgestellt. In Studio zugewiesene Zeitpläne werden erst nach der Bereitstellung des Projekts wirksam.
  • Der Zeitplan ist deaktiviert.
  • Es liegt eine Fehlkonfiguration der Zeitzone in den Zeitplaneinstellungen vor.
  • Bei privaten Agenten wird der Planungsdienst nicht ausgeführt.
  • Der der Umgebung zugeordnete Agent ist offline oder fehlerhaft.
  • Änderungen, die für ein Projekt bereitgestellt wurden, haben sich noch nicht vollständig mit dem Agent synchronisiert.
  • Die Agent-Gruppe ist ressourcengesättigt. Ein Rückstau von lang laufenden Vorgängen oder eine anhaltend hohe CPU- oder Speichernutzung kann verhindern, dass eine Agent-Gruppe geplante Vorgänge rechtzeitig aufnimmt.
• Lösung:
  • Bestätigen Sie, dass das Projekt bereitgestellt wurde, seit der Zeitplan dem Vorgang zugewiesen wurde.
  • Bestätigen Sie, dass der Zeitplan aktiviert ist. Zeitpläne können nur auf der Seite Projects in der Management Console aktiviert oder deaktiviert werden, und zwar auf den Registerkarten Operations und Schedules.
  • Überprüfen Sie die Zeitplankonfiguration und achten Sie besonders auf die Zeitzoneneinstellung. Details finden Sie unter Operation time zones.
  • Bei privaten Agenten überprüfen Sie, ob der Agent auf der Seite Agents in der Management Console online und fehlerfrei ist, und bestätigen Sie, dass der Planungsdienst auf dem Agent-Computer ausgeführt wird. Unter Windows überprüfen Sie im Task Manager, ob Jitterbit Scheduler und Jitterbit Scheduler Service ausgeführt werden. Unter Linux und Docker verwenden Sie den Befehl jitterbit status.
  • Stellen Sie das Projekt erneut bereit, um die Neusynchronisierung des Zeitplans mit dem Agent zu erzwingen.
  • Falls Vorgänge im Status Pending steckenbleiben, brechen Sie diese über die Seite Runtime in der Management Console ab und starten Sie den Agent-Dienst neu.
  • Falls Zeitplanverluste mit der Last korrelieren, reduzieren Sie die Anzahl der gleichzeitigen lang laufenden Vorgänge. Überprüfen Sie auf privaten Agenten auch die CPU- und Speichernutzung und gleichen Sie geplante Vorgänge an die Kapazität des Agenten an (ein privater Agent kann bis zum Doppelten seiner CPU-Kernanzahl gleichzeitige Vorgänge ausführen).
  • Falls ein geplanter Vorgang versendet wird, dann aber steckenbleibt, anstatt nie zu starten, lesen Sie Operations stuck in Submitted or Running state.

Wörterbuch oder globale Variable ist nach asynchroner Operation leer

• Symptom: Ein Wörterbuch oder eine globale Variable, die in einer untergeordneten Operation gefüllt wurde, ist leer oder behält ihren früheren Wert, wenn die übergeordnete Operation sie nach dem asynchronen Aufrufen liest.
• Mögliche Ursache: Wenn eine Operation asynchron aufgerufen wird (das Run type des Invoke Operation-Tools auf Asynchronously gesetzt oder RunOperation mit runSynchronously auf false aufgerufen), wird die untergeordnete Operation in einem separaten Thread ausgeführt und die übergeordnete Operation wird fortgesetzt, ohne zu warten. Globale Variablen und Wörterbücher werden an die untergeordnete Operation nach Wert statt nach Referenz übergeben und sind nicht thread-sicher. Daher werden Änderungen in der untergeordneten Operation nicht in der übergeordneten Operation berücksichtigt. Die übergeordnete Operation kann den Wert auch lesen, bevor die untergeordnete Operation abgeschlossen ist. Für das entsprechende Verhalten in aufgeteilten Multi-Thread-Operationen siehe Variablenupdates verloren in aufgeteilten Multi-Thread-Operationen.
• Lösung:
  • Wenn die übergeordnete Operation von Werten abhängt, die die untergeordnete Operation erzeugt, rufen Sie die untergeordnete Operation synchron auf (das Run type des Invoke Operation-Tools auf Synchronously gesetzt oder RunOperation synchron ausgeführt, was die Standardeinstellung ist), damit die untergeordnete Operation abgeschlossen wird und ihre globalen Variablenänderungen von der übergeordneten Operation geerbt werden.
  • Um Daten zwischen Operationen gemeinsam zu nutzen, die unabhängig ausgeführt werden müssen, speichern Sie diese mit Cache-Funktionen (WriteCache und ReadCache) statt sich auf ein Wörterbuch oder eine globale Variable über Threads hinweg zu verlassen. Cache-Funktionen sind standardmäßig auf 100 kombinierte Aufrufe pro Minute pro Organisation begrenzt.
  • Eine feste Verzögerung einfügen (z. B. mit der Sleep-Funktion) erhöht die Latenz und garantiert nicht, dass die untergeordnete Operation abgeschlossen ist. Führen Sie die Operation stattdessen synchron aus.

Verbindungs- und Authentifizierungsfehler

Salesforce-Zertifikat: Fehler bei Subject Alternative Name (SAN)

• Symptom: A Salesforce connection to a sandbox or an org with Enhanced Domains enabled fails with:

  Certificate for <url> doesn't match any of the subject alternative names
  

• Possible causes:

  • The certificate does not include the Salesforce MyDomain or sandbox URL in its Subject Alternative Names.
  • The Sandbox checkbox in the Salesforce connection settings is not correctly toggled.

• Resolution:

  • Inspect the certificate's SAN entries using OpenSSL: openssl x509 -in cert.crt -text -noout. Confirm the Subject Alternative Name section includes your Salesforce MyDomain URL.
  • In the Salesforce connection settings in Studio, verify the Sandbox checkbox is correctly set for your target org.
  • If the Salesforce URL is absent from the SANs, regenerate the certificate to include the specific domain.
  • If the same connection succeeds on a cloud agent group but fails on a private agent, the cause may instead be a missing SNI extension in the agent's TLS handshake. See Salesforce sandbox connection fails with certificate mismatch.

Fehler bei Datenbankverbindung des privaten Agenten (TranDb)

• Symptom: Operationen schlagen mit Fehlern fehl, die auf die interne PostgreSQL-Datenbank des privaten Agenten (TranDb) verweisen, z. B. Failed to connect to back-end database 'TranDb' oder FATAL: query_wait_timeout.
• Ursache und Lösung: Dies ist ein Problem auf Agent-Ebene mit den Datenbankverbindungen der internen Datenbank des privaten Agenten. Siehe TranDb-Verbindungsfehler im Troubleshooting-Handbuch des Agenten für die Ursachen und Lösungen.

Client-Zertifikat wird auf Linux-Privatagenten nicht geladen

• Symptom: Eine Operation, die einen ausgehenden gegenseitigen TLS-Webservice-Aufruf (Client-Zertifikat) tätigt, schlägt bei der Ausführung auf einem Linux-Privatagenten fehl, mit einem Fehler wie:

  Problem with the local SSL certificate. Unable to set private key file: '<path>.key' type PEM.
  

  Das Zertifikat wird erfolgreich in Studio hochgeladen, aber die Operation schlägt bei der Ausführung fehl. Dieselbe Konfiguration hat möglicherweise zuvor auf einem Windows-Privatagenten funktioniert.

• Mögliche Ursachen:

  • Der Betriebssystembenutzer, der den Jitterbit-Agenten ausführt, hat keine Leseberechtigung für die Datei mit privatem Schlüssel oder deren übergeordnete Verzeichnisse.
  • Ein Linux-Sicherheitsmodul wie SELinux oder AppArmor blockiert den Zugriff des Agenten auf die Datei mit privatem Schlüssel.

• Lösung:

  • Stellen Sie sicher, dass das Konto, das den Jitterbit-Agent ausführt, Lesezugriff auf die private Schlüsseldatei und alle übergeordneten Verzeichnisse hat.
  • Prüfen Sie, ob SELinux oder AppArmor den Zugriff auf die Schlüsseldatei einschränkt, und passen Sie die Richtlinie oder den Dateikontexte entsprechend an.

Transformations- und Datenfehler

Nicht unterstützte XML-Elemente (CDATA) in JSON eingebettet

• Symptom: Character-Data-Abschnitte (CDATA) werden in XML, das in JSON eingebettet ist und durch eine Transformation verarbeitet wird, nicht unterstützt. Falls vorhanden, wird der folgende Fehler im Operationsprotokoll angezeigt:

  Transformation failed. Error: The operation "Operation" failed.
  Error: Failed to convert XML file to JSON.
  org.jitterbit.integration.server.engine.EngineSessionException: org.xml.sax.SAXParseException ...
  

• Lösung: Verwenden Sie ein Jitterbit-Skript, um die Zeichen &, <, >, ' und " im CDATA-Abschnitt, einschließlich der CDATA-Trennzeichen (<![CDATA[ ... ]]>), durch ihre Escaped-Entsprechungen (&, <, >, ', ") zu Replace. Wenn eine Beschränkung auf nur den CDATA-Abschnitt nicht möglich ist, kann die gesamte XML-Zeichenfolge, die ihn enthält, ersetzt werden.

  Das folgende Beispiel wird ohne diese Replacements als ungültig betrachtet:

  {
    "name": "Jitterbit",
    "data": "<xml><content><![CDATA[<greeting>Hello, world!</greeting>]]></content></xml>"
  }
  

Transformation schlägt fehl, wenn ein JSON-Zeichenfolgenwert die maximale Länge überschreitet

• Symptom: Eine Transformation, die einen großen JSON-Zeichenfolgenwert verarbeitet, schlägt mit einem Fehler fehl, der meldet, dass die Zeichenfolge die maximal zulässige Länge überschreitet, z. B.:

  Transformation failed. Error: Error Code: String value length (20054016) exceeds the maximum allowed (20000000, from StreamReadConstraints.getMaxStringLength())
  

  Die Stack Trace verweist auf StreamConstraintsException und den JSON-Parser des Agents. Ein häufiger Auslöser ist eine HTTP v2-Antwort mit aktivierter Option Get response content in base64 string: Die Base64-Codierung vergrößert Binärinhalte (z. B. Audio- oder Mediendateien), daher kann die codierte Zeichenfolge die Grenze überschreiten, auch wenn die Originaldatei kleiner ist.

• Ursache: Der JSON-Parser des Agents begrenzt einen einzelnen JSON-Zeichenfolgenwert standardmäßig auf 20 MB (20000000 Zeichen). Ein Wert, der größer als dieser ist, schlägt beim Parsen durch den Agent fehl, bevor nachgelagerte Aktivitäten (z. B. ein Upload) ausgeführt werden.

• Lösung: Erhöhen Sie auf einem privaten Agent mit Version 12.5 oder später die Grenze mit dem Schlüssel MaxStringLength im Abschnitt [JsonParser] der Konfigurationsdatei jitterbit.conf (setzen Sie ihn beispielsweise auf 50000000 für eine 50-MB-Grenze), und starten Sie den Agent neu. Dieser Schlüssel ist in Agent-Version 12.5 und später verfügbar. Führen Sie daher zunächst ein Upgrade durch, falls der Agent eine frühere Version hat.

Sonderzeichen in Connector-bereitgestellten JSON-Schemas

• Symptom: Wenn eine Transformation ein von einer angrenzenden Connector-Aktivität geerbtes JSON-Schema verwendet, werden alle Sonderzeichen in einem Schemafeld- oder Knotennamen durch Unterstriche (_) ersetzt. Wenn Sie die Legacy-JSON-Verarbeitung verwenden (Standard für Projekte, die vor dem 11.48 Harmony Release erstellt wurden), kann dies dazu führen, dass der Endpunkt Fehler zurückgibt, da die tatsächlichen Feldnamen nicht mehr dem entsprechen, was er erwartet.

  Wenn beispielsweise die Aktivität ein Feld mit dem Namen location_ids[] bereitstellt, wird dieses in location_ids__ konvertiert. Falls der Endpunkt immer noch den ursprünglichen Namen erwartet, kann er einen Fehler wie den folgenden zurückgeben:

"error_message": "{location_ids:expected String to be a Array}"

• Lösung:

  1. Bestätigen Sie, dass in der betroffenen Aktivität ein JSON-Schema verwendet wird. Solche Schemas haben einen Stammknoten mit dem Namen json:

     

  2. Aktivieren Sie die JSON-Namen beibehalten Projekteinstellung (erfordert Agent-Version 11.48 oder später).

  3. Konfigurieren Sie den Vorgang neu, stellen Sie ihn bereit und führen Sie ihn aus.

  Wichtig

  Wenn JSON-Namen beibehalten in einem Projekt aktiviert wird, in dem diese Option zuvor deaktiviert war, gilt die neue Verarbeitungsmethode nur für Vorgänge und Schemas, die nach Aktivierung der Einstellung konfiguriert werden. Vorhandene Vorgänge und Schemas verwenden weiterhin die Legacy-JSON-Verarbeitung. Um Inkonsistenzen innerhalb eines Projekts zu vermeiden, konfigurieren Sie alle vorhandenen Vorgänge und Schemas erneut, nachdem Sie diese Einstellung aktiviert haben.

  Überprüfen Sie zur Überprüfung des an den Endpunkt gesendeten Feldnamens den Wert jsonPropertyName in den Ein- oder Ausgabedaten der Aktivität mit Debug-Protokollierung aktiviert:

  

Multibyte-Zeichen werden bei einer großen Connector-Antwort beschädigt

• Symptom: Ein Multibyte-Zeichen in einer JSON-Connector-Antwort wird beschädigt. Der beschädigte Text zeigt das klassische Muster von UTF-8-Bytes, die als Latin-1 dekodiert werden (z. B. São Luís wird zu São LuÃs). In der Regel ist nur ein Multibyte-Zeichen betroffen, das nach ungefähr den ersten 8 KB der Antwort erscheint; dasselbe Zeichen, das früher in der Antwort erscheint, ist nicht betroffen.
• Mögliche Ursache: Bei Agent-Versionen 12.8 und 12.9 werden bei der automatischen Zeichencodierungserkennung nur der Anfang der Antwort verwendet, um ihre Codierung zu bestimmen. Wenn dieses Beispiel nur ASCII-Zeichen enthält, wird die Antwort als Latin-1 (ISO-8859-1) statt als UTF-8 erkannt, was alle Multibyte-Zeichen beschädigt, die über den abgetasteten Bereich hinausgehen.
• Lösung: Aktualisieren Sie auf Agent-Version 12.10 oder später, die die Kodierungserkennung korrigiert.

Gespiegelte Schemas mit Substitutionsgruppen

• Symptom: Gespiegelte Schemas, die XML-Substitutionsgruppen verwenden, werden nicht unterstützt. Die Verwendung führt zu einem Laufzeitfehler:

  Failed to initialize transformation "<transformation name>". Failed to expand the (source|target) tree for the path: <path to substitution head node>.
  

  Dieser Fehler kann auch aus anderen Gründen auftreten, z. B. beim Importieren einer Transformationszuordnung mit doppelten Knoten, und deutet nicht unbedingt auf ein Problem mit einer Substitutionsgruppe hin.

• Lösung: Falls Substitutionsgruppen die bestätigte Ursache sind, löschen Sie das gespiegelte Schema und erstellen Sie es mit einer anderen Methode neu (Hochladen, Erstellen eines benutzerdefinierten Schemas usw.).

Importieren einer Transformationszuordnung mit doppelten Knoten schlägt mit „Knoten kann nicht erstellt werden" fehl

• Symptom: Eine Transformation, deren Zuordnung aus einer Datei importiert wurde, die doppelte Knoten referenziert, schlägt zur Laufzeit mit einem Fehler wie dem folgenden fehl:

  Failed to initialize transformation "<transformation name>". Failed to expand the target tree for the path: <path to node>. The node: <node name> cannot be created.
  

Die Zuordnung kann im Transformations-Designer korrekt aussehen, obwohl der Vorgang bei der Ausführung fehlschlägt.

• Mögliche Ursache: Beim Importieren einer Zuordnungsdatei, die doppelte Knoten zum Zielschema hinzugefügt hat, wurde die entsprechende Änderung nicht auf die Schemadefinition angewendet, die bei der Ausführung des Vorgangs verwendet wird, wodurch die beiden nicht synchronisiert wurden. Dies wurde behoben, aber eine Transformation, deren Zuordnung vor der Behebung importiert wurde, kann weiterhin betroffen sein.

• Lösung: Verwenden Sie in der betroffenen Transformation die Funktion Alle Zuordnungen unter diesem Knoten entfernen auf dem Stammknoten, um alle Zuordnungen zu entfernen, und importieren Sie die Zuordnungsdatei erneut. Durch das erneute Importieren wird die bei der Laufzeit verwendete Schemadefinition mit der Zuordnung neu synchronisiert. Falls der Fehler weiterhin besteht, konfigurieren Sie die Aktivität neu, die das Schema bereitstellt, und aktualisieren Sie das Schema in der Transformation.

Erneute Verarbeitung von gespiegelten XML-Schemas in Projekten, die vor Version 10.25 erstellt wurden

• Symptom: Aufgrund von Änderungen in den Harmony-Versionen 10.25 und 10.27 können sich Projekte, die vor 10.25 erstellt wurden und gespiegelte XML-Schemas verwenden, unerwartet verhalten. Zuordnungen, die XML-Funktionen mit Namespaces (wie SelectNodes) verwendet haben, können jetzt ungültig sein.

  Der Unterschied liegt in der Behandlung von Namespace-Präfixen:

  • Vor 10.25: Gespiegelte XML-Schemas verwendeten das Standard-Namespace-Präfix xsi.
  • 10.25 und später: Gespiegelte XML-Schemas verwenden das qualifizierte Namespace-Präfix ns. Nicht zugeordnete Felder werden im Schema nicht angezeigt.

• Lösung: Ab Version 10.27 behält der Import eines Projekts, dessen gespiegelte XML-Schemas vor 10.25 erstellt wurden, das ursprüngliche Namespace-Präfix bei, sodass das Schema identisch mit dem Zeitpunkt seiner Erstellung ist. Um ein Update auf das aktuelle Namespace-Präfix zu erzwingen, generieren Sie das Schema neu, indem Sie es aktualisieren oder die Aktivität, die es bereitstellt, neu konfigurieren. Überprüfen Sie nach der erneuten Generierung alle betroffenen XML-Namespace-Funktionsaufrufe und aktualisieren Sie die Präfixverweise entsprechend.

  Siehe den kommentierten XML-Schema-Vergleich für eine Illustration des Unterschieds zwischen den beiden Formaten.

Warnung für zusätzliche Subelemente in Operationsprotokollen

• Symptom: Eine extra subelement-Meldung in den Operationsprotokollen ist eine Warnung, keine Fehler, und kann in der Regel ignoriert werden. Sie zeigt an, dass die API-Nutzlast eines Connectors mehr Knoten oder Felder zurückgegeben hat, als im Antwortdatenschema definiert sind.
• Lösung: Falls Sie die zusätzlichen Daten erfassen möchten, aktualisieren Sie das Schema, um die zusätzlichen Felder einzubeziehen.

Transformationsausgabe auf 0 für Zielfelder mit dem Datentyp double konvertiert

• Symptom: Ein Zielfeld mit dem Datentyp double im Schema erhält einen Wert von 0, obwohl das Zuordnungsskript einen nicht leeren Zeichenfolgenwert zurückgibt.
• Mögliche Ursache: Wenn die Transformation eine Skriptausgabe verarbeitet, wird das Ergebnis in den Datentyp des Zielfelds konvertiert. Falls der Zeichenfolgenwert mit einem Nicht-Ziffern-Zeichen beginnt (z. B. "string1"), kann kein numerischer Teil extrahiert werden und das Feld erhält den Standardnumernwert von 0. Ein Wert wie "1string" würde hingegen 1 ergeben, da die führende Ziffer übernommen wird.
• Lösung:
  1. Überprüfen Sie die Schemadefinition für das betroffene Zielfeld und bestätigen Sie, ob sein Datentyp double oder ein anderer numerischer Datentyp ist.
  2. Falls das Zuordnungsskript eine nicht numerische Zeichenfolge zurückgeben kann, fügen Sie eine explizite Validierung hinzu, um sicherzustellen, dass nur numerische Werte zu numerischen Zielfeldern zugeordnet werden, oder ändern Sie den Datentyp des Felds im Schema.

Leere zugeordnete Felder mit flachen Quellschemas

• Symptom: Zielfelder erscheinen in der Operationsausgabe leer, obwohl die Quelldaten Werte enthalten. Dieses Problem tritt speziell bei Verwendung eines flachen Quellschemas auf. Es tritt nicht bei gespiegelten Schemas oder JSON-Schemas auf.
• Mögliche Ursache: Der Standard-Streaming-Transformationsmodus verarbeitet Datensätze inkrementell, was dazu führen kann, dass zugeordnete Felder bei Verwendung mit flachen Quellschemas keine Werte erhalten.

• Lösung:

  1. Fügen Sie am Anfang der Operation einen Skriptschritt hinzu, der Streaming-Transformationen deaktiviert, indem Sie jitterbit.transformation.auto_streaming auf false setzen:

     $jitterbit.transformation.auto_streaming = false;
     

  2. Stellen Sie die Operation bereit und führen Sie sie erneut aus. Weitere Informationen zu Streaming und Transformationsverarbeitung finden Sie unter Transformationsverarbeitung.

Zielschleifenknoten, der mehreren Quellschleifenknoten zugeordnet ist

• Symptom: Eine Transformation ist ungültig oder kann nicht bereitgestellt werden mit:

  Mappings of a target loop node depend on more than one source loop node.
  

• Mögliche Ursache: Ein Zielschleifenknoten verfügt über Feldzuordnungen, die auf zwei oder mehr verschiedene Quellschleifenknoten verweisen. Jeder Zielschleifenknoten kann nur über einen einzelnen Quellschleifenknoten iterieren.

• Lösung:
  1. Öffnen Sie die Transformation und identifizieren Sie den in der Fehlermeldung angegebenen Zielschleifenknoten.
  2. Überprüfen Sie die Zuordnungen unter diesem Knoten, um zu bestätigen, dass alle zugeordneten Felder aus demselben Quellschleifenknoten stammen.
  3. Wenn Daten aus mehreren Quellknoten erforderlich sind, verarbeiten oder zusammenführen Sie die zusätzlichen Quelldaten vor der Transformation in einem Skriptschritt vor, sodass ein einzelner einheitlicher Quellknoten den Zielschleifenknoten speist.
  4. Weitere Informationen zu gültigen Zuordnungsmustern finden Sie unter Transformationszuordnungsgültigkeit.

Transformation löscht doppelte Datensätze, wenn die Ausgabe hierarchisch ist

• Symptom: Eine Transformation, die eine CSV-Quelle liest und einer hierarchischen Ausgabe (z. B. JSON) zuordnet, löscht stillschweigend doppelte Datensätze. Datensätze mit identischen Feldwerten werden in der Ausgabe nur einmal angezeigt, unabhängig davon, wie oft sie in der Quelle vorkommen. Die Operation wird erfolgreich abgeschlossen, meldet aber weniger Zieldatensätze als Quelldatensätze.
• Mögliche Ursachen:
  • Bei der Umwandlung flacher Quelldaten in ein hierarchisches Ausgabeformat entfernt die Transformations-Engine während der Normalisierung doppelte Datensätze. Datensätze mit identischen Werten nach dem Parsing werden als Duplikate behandelt und nur eine Kopie wird beibehalten.
  • Dieses Verhalten ist spezifisch für hierarchische Ausgabe. Wenn das Ausgabeschema flach ist, wird die Normalisierung nicht ausgeführt und alle Datensätze werden geschrieben.
  • Die Transformations-Engine schneidet standardmäßig auch führende und nachfolgende Leerzeichen aus CSV-Feldwerten ab. Datensätze, die sich nur durch führende oder nachfolgende Leerzeichen unterscheiden, werden nach dem Trimmen identisch und unterliegen derselben Deduplizierung.
• Lösung:
  • Aktivieren Sie Chunking in den Operationsoptionen. Chunking verarbeitet Datensätze in Batches, was die Normalisierung umgeht und alle Datensätze einschließlich Duplikate beibehält.
  • Verwenden Sie ein flaches Ausgabeschema in der Transformation statt eines hierarchischen. Die Normalisierung gilt nicht für flache Ausgabe, daher werden alle Datensätze beibehalten.
  • Deaktivieren Sie die Normalisierung, indem Sie in einem Skriptschritt vor der Transformation eine Jitterbit-Variable setzen. Setzen Sie bei Flat-to-Flat-Transformationen jitterbit.transformation.disable_normalization auf true. Setzen Sie bei Flat-to-XML-Transformationen jitterbit.transformation.flat_to_xml.disable_normalization auf true (erfordert Agent 11.58 oder später). Beide Variablen können andere Transformationen in der gleichen Operation beeinflussen, daher testen Sie die Änderung sorgfältig.
  • Wenn die Duplikate speziell durch Leerzeichenunterschiede verursacht werden, setzen Sie jitterbit.source.preserve_char_whitespace in einem Skriptschritt vor der Transformation auf true. Dies erhält die Leerzeichen beim Parsing, sodass betroffene Datensätze unterschiedlich bleiben.

Lange numerische IDs werden in der Transformationsausgabe beschädigt

• Symptom: Ein langer numerischer Wert (z. B. eine Tracking-Nummer, Kontonummer oder externe ID) wird mit einem falschen Wert an das Ziel gesendet. Die Zahl ist zu groß, um in den impliziten numerischen Typ zu passen, der während der Zuordnung verwendet wird. Dies führt zu einem Überlauf und erzeugt einen falschen Wert am Ziel.
• Mögliche Ursache: Das Quell- oder Zielfeld ist implizit als numerischer Datentyp typisiert, dessen Bereich den vollständigen Wert nicht aufnehmen kann. Dies verursacht einen Überlauf während der Konvertierung.
• Lösung:
  • Legen Sie in der Transformation den Datentyp des betroffenen Zielfelds auf String fest, anstatt einen numerischen Typ zu verwenden. Lange IDs, die nicht in Berechnungen verwendet werden, sollten als Strings behandelt werden.

  • Wenn das Quellfeld ebenfalls numerisch typisiert ist, casten Sie den Wert explizit mit String, bevor Sie ihn zuordnen:

    String($source.numericId)
    

JSON-Transformationsausgabe lässt null- und Leerstring-Felder aus

• Symptom: Eine JSON-Transformation entfernt Felder, deren Wert null oder ein Leerstring ("") ist, aus der Ausgabe-Payload, obwohl diese Felder explizit zugeordnet sind. Das Zielsystem erhält eine Payload, die die ausgelassenen Felder nicht enthält. Dies kann zu Downstream-Validierungsfehlern führen, wenn das Ziel die Felder als vorhanden erfordert.
• Mögliche Ursache: Der JSON-Ausgabe-Prozessor lässt Felder mit null- oder Leerstring-Werten standardmäßig aus.
• Lösung:
  • Legen Sie in einem Skriptschritt vor der Transformation jitterbit.target.xml.include_nil_attribute auf true fest. Ab Agent-Version 11.37 werden dadurch null-Werte und Leerstrings in der JSON-Ausgabe einbezogen, was der Eingabe entspricht. (Trotz xml im Namen gilt diese Variable für JSON-Ziele.)
  • Wenn Sie vollständige Kontrolle darüber benötigen, welche Felder in der Payload enthalten sind, erstellen Sie den JSON-Body in einem Skriptschritt mit String-Verkettung und senden Sie ihn über einen HTTP v2-Connector mit einem Request-Body ohne Schema.

Leere zugeordnete Felder werden zu xsi:nil="true" und invalidieren eine XML- oder SOAP-Anfrage

• Symptom: In einer XML- oder SOAP-Transformation wird ein zugeordnetes Feld mit einem leeren Wert als nil-Element ausgegeben, und der Ziel-Endpunkt lehnt die Anfrage ab. Beispielsweise erzeugt eine leere Telefonnummern-Zuordnung Folgendes:

  <ns1:Phone_Number xsi:nil="true"/>
  

  Einige Endpunkte (z. B. Workday-SOAP-Services) behandeln dies als ungültig und geben einen Fehler zurück.

• Ursache: Standardmäßig enthält die Transformation, wenn eine Zuordnung zu einem Zielknoten einen null- oder leeren Wert ergibt, den Knoten, kennzeichnet ihn aber als nil (xsi:nil="true"). Dies wird durch jitterbit.target.xml.include_null_xml gesteuert, deren Standard true ist.

• Lösung: Legen Sie in einem Skriptschritt vor der Transformation $jitterbit.target.xml.include_null_xml = false fest, um Knoten mit null- oder leeren Werten vollständig aus der Ausgabe zu entfernen. Falls der Knoten stattdessen als leeres Element vorhanden sein muss, verwenden Sie die entsprechenden Ziel-Jitterbit-Variablen jitterbit.target.xml.include_empty_xml und jitterbit.target.xml.include_nil_attribute, die steuern, ob leere und null-Werte in der Ausgabe enthalten sind.

Byte-Order-Mark (BOM) in einer Quelldatei wird an den Wert des ersten Datensatzes weitergegeben

• Symptom: Wenn eine Quelldatei (z. B. eine CSV-Datei) mit einer UTF-8-Byte-Order-Mark (BOM) beginnt, enthält das erste Feld des ersten Datensatzes in der Transformationsausgabe ein zusätzliches oder unerwartetes Zeichen, das nicht Teil der Quelldaten ist, anstelle des erwarteten Werts. Aus Microsoft Excel als UTF-8 CSV exportierte Dateien enthalten häufig diese BOM.
• Mögliche Ursache: Studio liest den Inhalt einer Quelldatei unverändert und erkennt oder entfernt eine führende BOM nicht. Die rohen Bytes des BOM werden Teil des Werts des ersten Felds, nachdem die Datei in Datensätze analysiert wurde.
• Lösung: Überprüfen Sie den Wert des betroffenen Felds, um die genauen Zeichen zu identifizieren, die von der BOM erzeugt werden, und ordnen Sie das Feld dann mit Replace zu, um diese zu entfernen. Bei Agent-Versionen 12.6 oder früher, bei denen UTF-8 nicht die Standardeinstellung ist, können Sie auch vor dem Ausführen der Quellaktivität explizit die Zeichencodierung auf UTF-8 setzen, z. B. $jitterbit.source.text.character_encoding = "utf-8";. Agent-Versionen 12.7 und später verwenden standardmäßig UTF-8.

Skript- und Funktionsfehler

Dateifunktionen: Vorgang wird nach ArchiveFile- oder ReadFile-Fehler fortgesetzt

• Symptom: Ein Vorgang wird mit erfolgreichem Status abgeschlossen, aber Dateien wurden nicht archiviert oder Daten wurden nicht wie erwartet gelesen. Im Vorgangsergebnis wird kein Fehler angezeigt, nur eine Warnung im Vorgangsbericht.
• Mögliche Ursache: ArchiveFile und ReadFile haben ein Soft-Failure-Verhalten: Wenn eine dieser Funktionen fehlschlägt, wird das aktuelle Skript abgebrochen und eine Warnung zum Vorgangsbericht hinzugefügt, aber der Vorgang selbst schlägt nicht fehl und die folgenden Schritte werden fortgesetzt. Ab Agent-Version 12.5 gibt es eine Ausnahme: ArchiveFile wirft bei Aufruf mit deleteSource auf true einen auffangbaren Fehler, wenn die Quelldatei nicht gelöscht werden kann, anstatt schweigend fehlzuschlagen.
• Lösung:
  • Überprüfen Sie die Vorgangsprotokolle auf Warnmeldungen, wenn ein Vorgang erfolgreich ist, aber die erwartete Dateiausgabe fehlt.
  • Wenn das Skript bei einem Dateifunktionsfehler beendet werden muss, wickeln Sie den Aufruf in eine Eval-Funktion ein und rufen Sie RaiseError explizit auf, um die Warnung zu einem Vorgangsfehler zu befördern.

ReadFile: Teillesenachrichten mit Binärdateiinhalt

• Symptom: Ein Skript, das ReadFile verwendet, um eine Binärdatei (z. B. eine ZIP- oder PDF-Datei) zu lesen, gibt unvollständige oder beschädigte Daten zurück.
• Mögliche Ursache: ReadFile funktioniert nicht zuverlässig mit Binärdateiinhalten und liest normalerweise nur einen Teil solcher Dateien.
• Lösung: Verwenden Sie Base64EncodeFile anstelle von ReadFile, um den vollständigen Inhalt einer Binärdatei als Base64-codierte Zeichenfolge zu lesen.

ReadFile-Inhalt mit nicht-UTF-8-Bytes schlägt fehl, wenn er in eine UTF-8-XML- oder JSON-Nutzlast zugeordnet wird

• Symptom: Eine Transformation, die Rohzieldateiinhalte mit ReadFile (z. B. eine unformatierte EDI-Datei) in ein UTF-8 XML- oder JSON-Zielfeld abbildet, schlägt während der XML- oder JSON-Konvertierung fehl. Das Ersetzen des abgebildeten Werts durch eine hartcodierte Zeichenfolge ermöglicht den Abschluss des Vorgangs, was bestätigt, dass der Rohinhalt der Auslöser ist. Versuche, das problematische Zeichen anhand seines Unicode-Codepunkts zu entfernen (z. B. Replace($readFile, HexToString("2026"), "~") für die Auslassungspunkte U+2026), stimmen nicht überein, und der Aufruf von StringToHex für den Inhalt mit aktivierter Unicode-Unterstützung wirft:

  not a UTF-8 string, byte not in range: 13
  

• Ursache: Der Dateiinhalt enthält ein Byte, das nicht in UTF-8 codiert ist (z. B. das einzelne Byte 0x85, das einige EDI-Dateien als Segmenttrennzeichen verwenden). Dieses Rohbyte unterscheidet sich von der Multi-Byte-UTF-8-Codierung eines ähnlich aussehenden Unicode-Zeichens (die Auslassungspunkte U+2026 werden als drei Bytes codiert), weshalb ein Austausch, der auf den Unicode-Codepunkt abzielt, nie übereinstimmt. Wenn jitterbit.scripting.hex.enable_unicode_support auf true gesetzt ist, interpretieren die Hex-Funktionen den Inhalt als UTF-8 und schlagen beim ungültigen Byte fehl.

• Lösung: Entsprechen und ersetzen Sie das Rohbyte mit deaktivierter Unicode-Hex-Unterstützung, sodass HexToString auf Rohbytes und nicht auf UTF-8-Zeichen arbeitet:

  $jitterbit.scripting.hex.enable_unicode_support = false;
  $badByte = HexToString("85");
  $readFile = Replace($readFile, $badByte, "~");
  

  Passen Sie den Hexwert (85) an das von StringToHex($readFile) gemeldete Byte an, und passen Sie die Ersatzzeichenfolge (~) nach Bedarf an, dann bilden Sie den bereinigten Wert ab.

FlushFile / FlushAllFiles: Fehler, wenn die Zieldatei bereits vorhanden ist

• Symptom: Ein Skript schlägt fehl, wenn versucht wird, eine Datei in ein Ziel zu schreiben, das bereits eine Datei mit demselben Namen enthält.
• Mögliche Ursache: FlushFile und FlushAllFiles (und damit auch ArchiveFile) werfen einen Fehler, wenn eine Datei mit dem Zielnamen bereits am Zielort vorhanden ist.
• Lösung:
  • Fügen Sie einen DeleteFile oder DeleteFiles Aufruf vor dem Schreibvorgang hinzu, um die vorhandene Datei zu löschen.
  • Verwenden Sie alternativ einen dynamischen Dateinamen, der einen Zeitstempel oder eine eindeutige Kennung enthält, um Konflikte zu vermeiden.

DeleteFiles: Fehler, wenn der Quellpfad nicht gefunden wird

• Symptom: Ein Skript mit DeleteFiles schlägt mit einem Fehler fehl, wenn der angegebene Quellpfad oder das Verzeichnis nicht gefunden werden kann. (Ein Filter, der keine Dateien entspricht, gibt 0 statt eines Fehlers zurück.)
• Mögliche Ursache: Wenn der Quellpfad nicht gefunden werden kann, wirft DeleteFiles einen Fehler, statt stillschweigend zurückzukehren. Dies kann zu unerwarteten Ausfällen während des Vorgangs führen, wenn die zu löschende Datei nicht vorhanden ist.
• Lösung: Schließen Sie den DeleteFiles-Aufruf in eine Eval-Funktion ein, um den Fehler zu erfassen und zu handhaben, ohne dass der Vorgang fehlschlägt.

GetJSONString: Ausführung unterbrochen bei ungültigem Pfad

• Symptom: Ein Skript, das GetJSONString aufruft, schlägt fehl, wenn der angegebene Pfad nicht im JSON aufgelöst wird (z. B. weil der Knoten fehlt oder ein Array leer ist). Die Fehlermeldung ist generisch und identifiziert den Pfad nicht als Ursache. Bei Aufrufen über eine API kann dies als irreführender Proxy Error [502] beim API-Aufrufer angezeigt werden.
• Mögliche Ursache: Wenn das an GetJSONString übergebene path-Argument ungültig ist oder keine Daten entspricht, unterbricht die Funktion sofort die Ausführung und gibt einen Fehler zurück, was dazu führen kann, dass das gesamte Skript abbricht.
• Lösung:
  • Den JSON-Pfad vor der Übergabe an GetJSONString validieren, oder (ab Agent-Version 11.59 / 12.3) GetJSONStringEx verwenden, das einen anpassbaren Wert zurückgibt, anstatt die Ausführung zu unterbrechen, wenn der Pfad ungültig oder nicht vorhanden ist.
  • Die JSON-Payload unmittelbar vor dem GetJSONString-Aufruf protokollieren, um die aktuelle Struktur zu überprüfen und den Pfad zu bestätigen.

Schleifeniterationslimit überschritten

• Symptom: Ein Skript schlägt mit einem Fehler fehl, der angibt, dass die maximale Anzahl von Schleifeniterationen erreicht wurde. Das Standardlimit beträgt 50.000 Iterationen.
• Mögliche Ursachen:
  • Eine Schleife in einem Jitterbit-Skript überschreitet das Iterationslimit der Plattform.
  • Ein JavaScript-Skript enthält mehrere Schleifen, deren kombinierte Iterationszahlen 50.000 überschreiten. In JavaScript gilt das Limit pro Skript (über alle Schleifen hinweg), nicht pro einzelner Schleife.
• Lösung:
  • Die Skriptlogik überprüfen, um festzustellen, ob die Schleife optimiert werden kann, um die Anzahl der Iterationen zu verringern.
  • Für JavaScript-Skripte auf privaten Agenten kann das Pro-Skript-Limit erhöht werden, indem JavaScriptMaxIterations=X (wobei X größer als 50000 ist) zum [Settings]-Bereich der Konfigurationsdatei des privaten Agenten hinzugefügt wird.
  • Für Jitterbit Script auf privaten Agenten kann das Limit erhöht werden, indem jitterbit.scripting.while.max_iterations auf einen Wert größer als 50000 gesetzt wird.

RunOperation stoppt nach 50 synchronen Aufrufen in einer While-Schleife

• Symptom: Nach einem Upgrade eines privaten Agenten auf Version 12.11 oder später verarbeitet ein Skript, das RunOperation, RunOperationFromProject oder ReRunOperation synchron innerhalb einer While-Schleife aufruft, weniger Datensätze als erwartet. Es tritt kein Fehler auf Operationsebene auf, es sei denn, das Skript selbst überprüft den Rückgabewert der Funktion oder ruft GetLastError auf. Das Operationsprotokoll zeigt einen Eintrag, der die aufgerufene Operation anhand ihres Namens identifiziert (und auf ihre GUID zurückgreift, wenn der Name nicht aufgelöst werden kann), wenn das Limit erreicht wurde, und GetLastError gibt diese gleichen Informationen zurück.

• Mögliche Ursache: Ab Agent-Version 12.11 begrenzt ein Limit auf Agent-Ebene (MaxSynchronousRunOperationCallsInLoop im [OperationEngine]-Bereich der jitterbit.conf-Datei, Standardwert 50) die Anzahl der synchronen RunOperation-, RunOperationFromProject- und ReRunOperation-Aufrufe, die innerhalb einer einzelnen While-Schleife vorgenommen werden. Alle drei gemeinsam verwenden einen kumulativen Zähler pro Schleife. Sobald das Limit erreicht ist, gibt jeder weitere Aufruf false zurück, ohne einen Fehler auszulösen. Eine Schleife, die den Rückgabewert nicht überprüft, iteriert daher weiter, ohne zu bemerken, dass spätere Aufrufe keine Auswirkung hatten.

• Lösung:

  • Falls die Schleife den Rückgabewert nicht bereits prüft, wickeln Sie den Aufruf ein, damit eine Limitüberschreitung als Skriptfehler angezeigt wird, zum Beispiel: If(!RunOperation("<TAG>operation:MyOp</TAG>"), RaiseError(GetLastError()));.
  • Um das Limit für einen bestimmten Vorgang zu erhöhen, legen Sie die Jitterbit-Variable jitterbit.operation.max_sync_runop_calls_in_loop vor der Ausführung der Schleife fest, sofern Überschreibungen pro Vorgang zulässig sind (MaxSynchronousRunOperationCallsInLoopOverrideAllowed).
  • Um den agentweiten Standard zu erhöhen, erhöhen Sie MaxSynchronousRunOperationCallsInLoop im jitterbit.conf Datei-Abschnitt [OperationEngine].

Der Vergleich eines Strings mit einer Zahl liefert unerwartete Ergebnisse

• Symptom: Ein Vergleich zwischen einem String und einer Zahl liefert ein unerwartetes Ergebnis. Beispielsweise wird der Vergleich eines nicht numerischen Strings mit 0 als gleich bewertet, wodurch der falsche Zweig ausgeführt wird:

  $value = "test";
  If($value == 0, WriteToOperationLog("equal"), WriteToOperationLog("not equal"));
  // logs "equal", even though "test" is not 0
  

• Ursache: Wenn die beiden Operanden unterschiedliche Typen haben, konvertiert Jitterbit Script beide in Zahlen, um sie zu vergleichen. Ein String, der keine Zahl darstellt, wird zu 0 konvertiert, daher wird "test" == 0 zu 0 == 0, was true ist. Dies ist das erwartete Verhalten.

• Lösung: Vergleichen Sie Werte desselben Typs. Um einen String gegen einen bestimmten Wert zu testen, vergleichen Sie ihn mit einem String-Literal (zum Beispiel $value == "0" oder $value == "") anstatt mit einer Zahl. Falls ein Wert als beide Typen eingehen kann, konvertieren Sie beide Operanden vor dem Vergleich in denselben Typ (zum Beispiel mit String).

Unmap hebt die Zuordnung eines Feldes nicht auf, wenn es zusammen mit RunScript verwendet wird

• Symptom: Der Mapping-Ausdruck eines Zielfeldes umfasst sowohl RunScript als auch Unmap, aber das Feld wird nicht unmapped. Bei einem JSON- oder XML-Ziel wird das Feld in der Ausgabe mit einem null-Wert angezeigt, anstatt weggelassen zu werden.

• Mögliche Ursachen:

  • RunScript steht Unmap im selben Mapping-Ausdruck voraus (zum Beispiel RunScript("<TAG>script:MyScript</TAG>"); Unmap();). In Agent-Versionen vor 12.9 hat diese Kombination das Feld nicht unmapped.
  • Unmap wird innerhalb des von RunScript aufgerufenen Skripts aufgerufen, anstatt direkt im Mapping-Ausdruck des Zielfeldes selbst. RunScript gibt das Ergebnis des aufgerufenen Skripts als String zurück, anstatt ein Unmap-Signal zurück zum Mapping weiterzugeben, daher hat das Aufrufen von Unmap innerhalb des aufgerufenen Skripts keine Auswirkung, auf jeder Agent-Version, unabhängig von der bedingten Logik rund um den Aufruf. Dies ist das erwartete Verhalten.

• Lösung:

  • Falls RunScript und Unmap beide direkt im Mapping-Ausdruck des Zielfeldes aufgerufen werden, führen Sie ein Update auf Agent-Version 12.9 oder später durch.

  • Falls Unmap innerhalb des von RunScript aufgerufenen Skripts aufgerufen wird, verschieben Sie den Unmap-Aufruf aus dem aufgerufenen Skript heraus und in den Mapping-Ausdruck des Zielfeldes selbst, zum Beispiel:

    RunScript("<TAG>script:MyScript</TAG>"); If(<condition>, Unmap(), <value>);
    

DBExecute: Fehler wenn auto_commit und transaction beide true sind

• Symptom: Ein Vorgang, der DBExecute verwendet, schlägt mit einem Fehler fehl, der sich auf widersprüchliche Transaktionseinstellungen bezieht.
• Mögliche Ursache: Sowohl jitterbit.scripting.db.auto_commit als auch jitterbit.scripting.db.transaction sind im Skript vor dem DBExecute-Aufruf auf true gesetzt. Diese beiden Einstellungen schließen sich gegenseitig aus, und ihre Kombination führt zu einem Fehler.
• Lösung: Entscheiden Sie, ob Sie Auto-Commit-Verhalten oder explizite Transaktionskontrolle benötigen, und legen Sie dann nur die entsprechende Variable fest:
  • Für Auto-Commit (jede Anweisung wird sofort bestätigt): setzen Sie $jitterbit.scripting.db.auto_commit = true und lassen Sie jitterbit.scripting.db.transaction nicht gesetzt oder auf false.
  • Für Transaktionskontrolle (Bestätigung am Ende der Transformation): setzen Sie $jitterbit.scripting.db.transaction = true und jitterbit.scripting.db.auto_commit = false.

CallStoredProcedure: resultSet immer null bei ODBC-Treibern

• Symptom: Ein Skript mit CallStoredProcedure gibt null für den Parameter resultSet zurück, obwohl die gespeicherte Prozedur Daten zurückgibt.
• Mögliche Ursache: Der Parameter resultSet wird nur von JDBC-Datenbankentreibern unterstützt. Wenn der Datenbankendpunkt einen ODBC-Treiber verwendet, ist resultSet unabhängig von den Rückgabedaten der gespeicherten Prozedur immer null.
• Lösung:
  • Wenn das Resultset der gespeicherten Prozedur erforderlich ist, wechseln Sie den Datenbankendpunkt zu einem JDBC-Treiber statt ODBC.
  • Wenn ein Wechsel des Treibers nicht möglich ist, rufen Sie Ausgabedaten über Ausgabeparameter statt über das Argument resultSet ab.

CallStoredProcedure: „Stored proc or function could not be found" bei PostgreSQL JDBC

• Symptom: Ein Skript mit CallStoredProcedure gegen eine PostgreSQL-Datenbank schlägt fehl mit:

  CallStoredProcedure failed to execute call "<function-name>".
  java.sql.SQLException: Stored proc or function could not be found: <function-name>
  

• Mögliche Ursache: Der PostgreSQL-JDBC-Treiber unterscheidet zwischen Funktionen und Prozeduren. CallStoredProcedure erstellt seinen Aufruf immer nach einem Muster, das der Treiber als Suche nach einer Prozedur interpretiert. Wenn es sich bei dem Datenbankdbjekt um eine PostgreSQL-Funktion statt einer Prozedur handelt, kann der Treiber sie nicht finden und gibt die Fehlermeldung „not found" zurück.

• Lösung:
  1. Bestimmen Sie, ob das aufgerufene Datenbankdbjekt eine PostgreSQL-Funktion (gibt einen Wert zurück) oder eine Prozedur (kein Rückgabewert) ist.

  2. Ersetzen Sie CallStoredProcedure durch DBExecute und verwenden Sie die korrekte SQL-Syntax für den Dbjekttyp:

     • Funktion: verwenden Sie SELECT.

       $result = DBExecute("<TAG>Sources/My DB Connection</TAG>", "SELECT my_function(arg1, arg2)");
       

       DBExecute gibt ein Resultset zurück. Verwenden Sie eine While-Schleife mit Get, um die zurückgegebenen Werte zu lesen.

     • Prozedur: verwenden Sie CALL.

       DBExecute("<TAG>Sources/My DB Connection</TAG>", "CALL my_procedure(arg1, arg2)");
       

       PostgreSQL-Prozeduren geben keinen Wert zurück; der Rückgabewert von DBExecute kann ignoriert werden.

DBLoad: Erfordert einen JDBC-Datenbankentreiber

• Symptom: Ein Vorgang mit DBLoad schlägt fehl oder produziert keine Ausgabe, wenn der Datenbankendpunkt einen ODBC-Treiber verwendet.
• Mögliche Ursache: DBLoad funktioniert nur mit Datenbankendpunkten, die für die Verwendung eines JDBC-Treibers konfiguriert sind. Es wird nicht mit ODBC-Treibern unterstützt.
• Lösung: Überprüfen Sie, dass der mit der Zielaktivität verknüpfte Datenbankendpunkt einen JDBC-Treiber verwendet. Wenn ein ODBC-Treiber verwendet wird, wechseln Sie zu JDBC.

AESDecryption schlägt bei Daten fehl, die unter OpenSSL 3 verschlüsselt wurden

• Symptom: Ein Vorgang mit AESDecryption schlägt fehl oder gibt garbled Output zurück, wenn Daten entschlüsselt werden, die mit OpenSSL 3 verschlüsselt wurden.
• Mögliche Ursache: AESDecryption verwendet standardmäßig einen Legacy-AES-Algorithmus, der nicht mit OpenSSL 3-Verschlüsselung kompatibel ist. Wenn die verschlüsselten Daten mit OpenSSL 3 erstellt wurden, schlägt die Entschlüsselung ohne zusätzliche Konfiguration fehl.
• Lösung:
  • Für Private Agents Version 11.42 oder später setzen Sie jitterbit.scripting.aes.default in einem Skriptschritt vor dem AESDecryption-Aufruf auf true, um OpenSSL 3-Kompatibilität zu aktivieren.
  • Alternativ ersetzen Sie AESDecryption durch AESDecryptionEx, die standardmäßig OpenSSL 3 auf Agent-Versionen 11.42 oder später unterstützt.

Projektvariablen geben während Script- und Transformation-Tests leere Werte zurück

• Symptom: Beim Testen eines Script-Schritts oder einer Transformation in Studio gibt eine im Script oder Mapping referenzierte Projektvariable einen leeren Wert statt des konfigurierten Werts zurück. Der Test schlägt möglicherweise mit einem Fehler fehl, der nicht mit der Variable selbst zusammenhängt (beispielsweise ein Verbindungszeitüberschreitung durch eine leere Serveradresse).
• Mögliche Ursache: Projektvariablenwerte werden zur Laufzeit von der Harmony-Plattform eingefügt. Während eines Design-Zeit-Tests existiert kein Laufzeitkontext, um diesen Wert einzufügen. Eine Projektvariablenreferenz gibt daher einen leeren Wert zurück, es sei denn, die Variable hat einen Standardwert konfiguriert, der als Fallback verwendet wird. Die eigene Verbindungsauflösung einer Funktion ist ein separater Fall, der den Standardwert überhaupt nicht verwendet. Siehe Eine Funktion schlägt fehl, wenn ihr Endpunkt-Verbindungsfeld auf eine Variable eingestellt ist.
• Lösung:
  • Einen Standardwert für die Projektvariable festlegen: Geben Sie in der Projektvariablenkonfiguration den während des Tests zu verwendenden Wert im Feld Standardwert ein. Dies ist die einfachste Lösung für einen statisch konfigurierten Wert. Beachten Sie, dass der Standardwert verwendet wird, wenn die Variable zur Laufzeit nicht gesetzt wurde (nicht nur während Design-Zeit-Tests). Daher fungiert der Standardwert auch zur Laufzeit als Fallback, wenn die Variable anderweitig nicht gesetzt ist. Siehe Projektvariablen für Konfigurationsdetails.
  • Eine globale Variable verwenden: Ersetzen Sie die Projektvariablenreferenz durch eine globale Variable und weisen Sie ihren Wert im Script selbst vor der Zeile zu, die sie verwendet. Weil eine globale Variable ihren Wert aus der Script-Ausführung statt aus Laufzeiteinspeisung erhält, macht das Zuweisen vor der Verwendung sie während eines Design-Zeit-Tests verfügbar. Dies ist vorzuziehen, wenn der Wert in einem Script abgeleitet wird oder wenn kein Laufzeit-Fallback-Wert gewünscht ist. Siehe Globale Variablen für Details. Wenn die globale Variable in einem Connector-Konfigurationsfeld statt direkt in einem Script referenziert wird, müssen Sie auch einen feldspezifischen Standardwert für dieses Feld definieren (siehe Einen Standardwert definieren, das sowohl die Variable-Pill-Methode als auch die Inline-Syntax-Methode für Felder ohne Pill abdeckt).

Eine Funktion schlägt fehl, wenn ihr Endpunkt-Verbindungsfeld auf eine Variable eingestellt ist

• Symptom: Das Testen eines Scripts (mit Test ausführen), das eine Funktion wie DBLookup, DBExecute oder SfLookup aufruft, schlägt fehl, beispielsweise mit:

  No suitable driver found for [...]
  

  oder ein Fehler, der einen unaufgelösten Variablenplatzhalter in der Endpunktadresse anzeigt. Das gleiche Script wird erfolgreich ausgeführt, wenn es bereitgestellt und in einem Operation ausgeführt wird.

• Mögliche Ursache: Die von der Funktion verwendete Verbindung hat ein Feld (wie Anmeldung, Passwort, Verbindungszeichenfolge oder eine Serveradresse), das auf eine globale oder Projektvariable eingestellt ist. Das Testen eines Scripts führt nur das getestete Script aus, daher wurde die Variable ihren Laufzeitwert noch nicht zugewiesen, wenn die Funktion die Verbindung auflöst. Anders als eine Variable, die direkt in einem konfigurierten Feld einer Aktivität referenziert wird, wird dies nicht durch den Standardwert einer Variable abgedeckt. Eine Funktion wie diese liest den Standardwert nicht, wenn sie eine Verbindung auflöst. Für eine Variable, die direkt in einem Script oder Mapping referenziert wird und bei der ein Standardwert das Problem löst, siehe Projektvariablen geben während Script- und Transformation-Tests leere Werte zurück.

• Lösung: Weisen Sie der globalen oder Projektvariablen vor dem Funktionsaufruf vorübergehend ihren aktuellen Wert direkt im getesteten Skript zu (beispielsweise $login = "value"; für eine Variable namens login), und entfernen Sie die Zuweisung dann vor der Bereitstellung des Vorgangs.

IsNull gibt „false" für leere Strings aus JSON-Quelldaten zurück

• Symptom: IsNull gibt false für ein Feld zurück, das aus einer JSON-Quelle zugeordnet ist, auch wenn das Feld keinen Wert zu haben scheint. Nachgelagerte Logik, die von der Null-Prüfung abhängt, verhält sich unerwartet oder erzeugt falsche Ergebnisse.
• Mögliche Ursache: JSON unterscheidet zwischen einem fehlenden oder expliziten null-Wert und einem leeren String (""). Ein Feld, das in JSON auf "" gesetzt ist, ist ein leerer String, kein Null-Wert, daher gibt IsNull für ihn korrekterweise false zurück. Ab Agent 11.37 behält der Agent diese Unterscheidung korrekt bei. Skripte oder Transformationen, die sich zuvor darauf verlassen haben, dass IsNull für leere Strings true zurückgibt, waren auf ein früheres Verhalten angewiesen, das nicht länger korrekt ist.

• Lösung:

  • Verwenden Sie IfEmpty, um sowohl Null- als auch leere Strings zu behandeln: Die Funktion IfEmpty gibt einen Standardwert zurück, wenn das Argument null oder ein leerer String ist, und ist die empfohlene Lösung für dieses Szenario:

    // Gibt "default" zurück, wenn das Feld null oder ein leerer String ist
    result = IfEmpty($myField, "default");
    

  • Verwenden Sie Length, um leere Strings explizit zu testen: Wenn Sie nur überprüfen müssen, ob ein String leer ist (nicht null), verwenden Sie Length($myField) == 0.

  • Reparieren Sie die Quelldaten: Wenn die JSON-Quelle keinen Wert anzeigen soll, aktualisieren Sie sie, um "field": null zu senden oder lassen Sie das Feld ganz weg, anstatt "field": "" zu verwenden.

Ein String-Variable mit der Zahl 0 zu vergleichen, gibt unerwartet true zurück

• Symptom: Ein Vergleich wie $myVar == 0 gibt true zurück, auch wenn $myVar einen nicht-numerischen String enthält (beispielsweise "test"). If-Bedingungen und andere Logiken, die auf Null prüfen, erzeugen unerwartete Ergebnisse.
• Mögliche Ursache: Wenn Jitterbit Script Werte verschiedener Datentypen vergleicht, versucht es, beide Operanden als letzten Schritt in Double umzuwandeln. Bei Anwendung auf einen nicht-numerischen String schlägt die Umwandlung fehl und gibt 0 als Standardwert zurück. Der Vergleich wird dann als 0 == 0 ausgewertet, was true ist.

• Lösung:

  • Stellen Sie sicher, dass beide Seiten des Vergleichs den gleichen Datentyp verwenden. Wenn die Absicht darin besteht zu überprüfen, ob eine String-Variable den Wert "0" enthält, vergleichen Sie mit dem String-Literal "0" statt mit der Ganzzahl 0:

    // Compares string to integer: non-numeric strings coerce to 0 and match unexpectedly
    If($myVar == 0, ...)
    
    // Compares string to string: behaves as expected
    If($myVar == "0", ...)
    

  • Wenn die Variable einen numerischen Wert enthalten soll, stellen Sie sicher, dass sie vor dem Vergleich als Zahl und nicht als String zugewiesen wird.

Dezimalarithmetik erzeugt unerwartete Gleitkommaergebnisse

• Symptom: Ein arithmetischer Ausdruck mit Dezimalliteralen erzeugt ein Ergebnis, das sehr leicht vom erwarteten Wert abweicht. Beispiel: Double(12.01) - Double(12.00) gibt 0.00999999999999979 statt 0.01 zurück, und (4.9 * 100) - 490 wird zu 5.6843418860808e-14 statt 0 ausgewertet.
• Mögliche Ursache: Jitterbit Script speichert Zahlen als Gleitkommawerte. Die meisten Dezimalbruchteile können im binären Gleitkommaformat nicht exakt dargestellt werden, daher kann Arithmetik auf ihnen kleine Rundungsfehler ansammeln. Subtraktion, die den größten Teil eines Wertes aufhebt, macht diesen Rest sichtbar. Explizites Umwandeln von Werten als Double verhindert dies nicht: es legt den Datentyp fest, ändert aber nicht, wie der Wert gespeichert oder berechnet wird.
• Lösung:
  • Wenden Sie Round auf das Ergebnis an: Verwenden Sie Round mit der für die Berechnung erforderlichen Anzahl von Dezimalstellen:

$a = Round(Double(12.01) - Double(12.00), 2); // returns 0.01

• Dezimalliterale mit Float umwandeln: Umhüllen Sie das Dezimalliteral in Float vor der Berechnung:

  $a = (Float(4.9) * 100) - 490;
  WriteToOperationLog($a);
  

Datumsfunktionen geben Mitternacht statt eines reinen Datumswerts zurück

• Symptom: Nach dem Upgrade auf Agent-Version 12.8 oder später geben ConvertTimeZone, Date oder GeneralDate für eine Eingabe von exakt Mitternacht eine vollständige Datums- und Zeitzeichenfolge zurück (z. B. 2026-01-01 00:00:00) statt einer reinen Datumszeichenfolge (2026-01-01), was die Downstream-Logik beschädigen kann, die das kürzere Format erwartet. CVTDate ist davon nicht betroffen.
• Mögliche Ursache: Ab Agent-Version 12.8 behandeln diese Funktionen Mitternacht (00:00:00) als einen gültigen Zeitwert und behalten ihn im zurückgegebenen Wert, genau wie jede andere Zeit. Zuvor wurde ein Wert von exakt Mitternacht auf eine reine Datumszeichenfolge gekürzt, während jede andere Zeit korrekt beibehalten wurde.
• Lösung: Wenn die Downstream-Logik einen reinen Datumswert erfordert, verwenden Sie FormatDate, um das Ergebnis explizit zu formatieren, anstatt sich auf das Standard-Ausgabeformat der Funktion zu verlassen.

Zwischengespeicherter Wert läuft früher ab als erwartet

• Symptom: Ein in den Cache geschriebener Wert mit einer langen Ablaufzeit (z. B. 24 Stunden) verschwindet, bevor diese Zeit abläuft, oder läuft nach 30 Minuten ab, unabhängig von den Einstellungen in WriteCache.
• Mögliche Ursache: Jeder Aufruf von ReadCache setzt die Ablaufzeit des zwischengespeicherten Elements auf 30 Minuten (1800 Sekunden) zurück, es sei denn, der Parameter expirationSeconds wird explizit angegeben. Die Ablaufzeit von WriteCache gilt nur zum Zeitpunkt des Schreibens; nachfolgende Lesevorgänge ohne explizite Ablaufzeit verkürzen stillschweigend die verbleibende Lebensdauer.

• Lösung:

  • Legen Sie die Ablaufzeit in ReadCache fest: Übergeben Sie die gewünschte Anzahl von Sekunden als Parameter expirationSeconds, um die Lebensdauer des zwischengespeicherten Werts bei jedem Lesevorgang beizubehalten oder zu verlängern:

    // Resets expiration to 24 hours on each read
    testVal = ReadCache("CacheTest", 86400, "env");
    

  • Übergeben Sie -1, um die Schreib-Ablaufzeit beizubehalten: Das Übergeben eines nicht positiven Werts führt dazu, dass ReadCache die durch den letzten WriteCache-Aufruf festgelegte Ablaufzeit beibehält, anstatt eine neue anzuwenden:

    testVal = ReadCache("CacheTest", -1, "env");
    

RunXSLT schlägt fehl mit „XML-Version muss 1.0 oder 1.1 sein"

• Symptom: RunXSLT schlägt mit der Fehlermeldung fehl:

  Failed to execute xslt. XML version must be 1.0 or 1.1
  

  obwohl die Eingabe-XML-Datei eine gültige <?xml version="1.0"?>-Deklaration enthält.

• Mögliche Ursache: Das XSLT-Stylesheet ist so konfiguriert, dass es HTML-Ausgabe erzeugt (z. B. <xsl:output method="html"/>). RunXSLT unterstützt nur XML als Ausgabe. Wenn das Stylesheet HTML erzeugt, generiert die Funktion ein leeres Ergebnis, das diesen Fehler auslöst. Die Fehlermeldung bezieht sich auf die fehlende XML-Deklaration in der (leeren) Ausgabe, nicht auf die Eingabe-XML.

• Lösung:

  • XSLT aktualisieren, um XML-Ausgabe zu erzeugen: Ändern Sie die Output-Deklaration des Stylesheets in <xsl:output method="xml"/>, oder entfernen Sie die xsl:output-Deklaration komplett (XML ist die Standardeinstellung). Dies ist der empfohlene Ansatz und funktioniert sowohl auf Cloud- als auch auf Private Agents.

  • XSL Transform Plugin verwenden (nur Private Agents): Für Private Agent Groups unterstützt das veraltete XSL Transform Plugin den Saxon XSLT-Prozessor und ermöglicht Ausgabeformate außer XML, einschließlich HTML. Weitere Installationsdetails finden Sie unter Verfügbare Plugins.

SelectSingleNode gibt den falschen Knoten zurück, wenn es mit einem SelectNodes-Array-Element verwendet wird

• Symptom: SelectSingleNode gibt Daten aus dem falschen Element zurück (z. B. immer die erste Übereinstimmung im Dokument), wenn es auf ein Element aufgerufen wird, das aus einem SelectNodes-Array abgerufen wurde.
• Mögliche Ursache: Die Verwendung eines absoluten XPath-Ausdrucks (einer mit // beginnend) als Path-Argument führt dazu, dass SelectSingleNode vom Root des ursprünglichen XML-Dokuments aus sucht, anstatt relativ zum aktuellen Knoten. Ein Ausdruck wie "//Item/ItemName" findet den ersten ItemName im gesamten Dokument, unabhängig davon, welches Item-Element aus dem Array abgerufen wurde.

• Lösung:

  • Relativen Pfad verwenden: Lassen Sie das führende // weg und geben Sie nur den Elementnamen oder einen Pfad relativ zum aktuellen Knoten an. Dadurch wird die Suche auf den als erstes Argument übergebenen Knoten beschränkt:

    $itemName = SelectSingleNode($item, "ItemName");
    

  • Alternative: Knoten in String einwrappen: Das Konvertieren des Array-Elements in einen String vor der Übergabe an SelectSingleNode liefert auch das richtige Ergebnis. Die Verwendung eines relativen Pfads ist jedoch der bevorzugte Ansatz:

    $item = String($items[2]);
    $itemName = SelectSingleNode($item, "//Item/ItemName");
    

HexToBinary-Ausgabe sieht unverändert aus, wenn protokolliert

• Symptom: HexToBinary scheint keine Auswirkung zu haben: Der in das Operationsprotokoll geschriebene Wert sieht identisch mit der Hex-Eingabe aus, was darauf hindeutet, dass die Konvertierung nicht stattgefunden hat.
• Mögliche Ursache: WriteToOperationLog kann keine rohen Binärdaten ausgeben. Wenn ein Binärwert übergeben wird, konvertiert es diesen zur Anzeige zurück in Hexadezimal. Das gleiche Verhalten gilt im Script-Testfenster. Die Konvertierung funktioniert korrekt; nur die Anzeige ist betroffen.

• Lösung: Um mit der Binärausgabe zu arbeiten oder diese zu überprüfen, schreiben Sie sie mithilfe von WriteFile in eine Datei. Beispiel:

  WriteFile("<TAG>activity:ftp/FTP Endpoint/ftp_write/Write</TAG>", HexToBinary("1A3F"));
  

SortArray sortiert Dateinamen lexikografisch, nicht chronologisch

• Symptom: SortArray gibt Dateinamen in alphabetischer Reihenfolge zurück, anstatt der erwarteten chronologischen Reihenfolge, wenn Dateinamen eingebettete Datums- oder Zeitzeichenfolgen enthalten.
• Mögliche Ursache: SortArray führt eine String- (lexikografische) Sortierung durch. Bei einem Dateinamen wie ordall_DDMMYYHHMMSS.txt steht der Tagteil vor dem Jahrteil im String, sodass eine alphabetische Sortierung nicht mit einer datumsbasierten Sortierung übereinstimmt.
• Lösung:
  • Wenn Sie die Dateinamenskonvention kontrollieren, wechseln Sie zu einem Format, das bei alphabetischer Sortierung korrekt sortiert, z. B. YYYY-MM-DD_HHMMSS_filename.txt. Dies ist die einfachste und zuverlässigste Lösung.
  • Wenn das Dateinamenformat nicht geändert werden kann, analysieren Sie den Datumsanteil jedes Dateinamens in einen sortierbaren Schlüssel (z. B. YYYYMMDDHHMMSS) und sortieren Sie nach dem analysierten Schlüssel anstelle des unverarbeiteten Dateinamens.

URLEncode codiert bestimmte "sichere" oder Multibyte-Zeichen nicht

• Symptom: Ein Wert, der durch URLEncode geleitet wird, wird zum Ziel mit einigen uncodierten Zeichen gesendet, was dazu führt, dass das empfangende System die Anfrage ablehnt oder den Wert falsch interpretiert. Dies betrifft häufig Anmeldedaten oder Abfragewerte, die Zeichen wie $, + oder ! enthalten.
• Mögliche Ursachen:
  • URLEncode folgt RFC 1738 und behandelt diese Zeichen als "sicher", sodass sie niemals codiert werden: $ - _ . + ! * ' ( ) ,. Ein Ziel, das erwartet, dass diese Zeichen prozentual codiert sind, empfängt stattdessen das Rohzeichen.
  • Die Multibyte-Zeichenunterstützung in URLEncode erfordert Agent-Version 12.4 oder später. Bei früheren Agenten werden Multibyte-Zeichen möglicherweise nicht wie erwartet codiert.

• Lösung:

  • Wenn "sichere" Zeichen codiert werden müssen (z. B. in einem OAuth-Passwort oder einem Wert mit +), verwenden Sie die JavaScript-Funktion encodeURIComponent in einem JavaScript-Skriptschritt anstelle von URLEncode:

    <javascript>
    $my_username = "$Example+User";
    $loginValue = encodeURIComponent($my_username);
    </javascript>
    

    Dies gibt %24Example%2BUser zurück.

  • Um Multibyte-Zeichen mit URLEncode zu codieren, überprüfen Sie, ob der Agent Version 12.4 oder später ausführt.

JavaScript: Fehler "Call to Jitterbit Tomcat failed"

• Symptom: Ein komplexer oder langsam ausgeführter JavaScript-Schritt schlägt mit einem generischen Fehler fehl, der auf Tomcat verweist, obwohl sowohl die Jitterbit Apache- als auch die Jitterbit Tomcat-Dienste auf dem Agent ausgeführt werden. Das Skript wird möglicherweise erfolgreich ausgeführt, wenn seine Komplexität verringert wird (z. B. durch Reduzieren von Iterationszählern oder Rekursionstiefen).

  Call to Jitterbit Tomcat failed (null response). Make sure the Jitterbit Apache and Jitterbit Tomcat services are both running.
  Failed to execute script
  

• Mögliche Ursache: Stark rekursives JavaScript kann das Rekursionstiefe-Limit der JavaScript-Engine des Agenten überschreiten, was zu einem Stack Overflow führt, der sich als dieser generische Tomcat-Fehler äußert. Dieses Rekursionslimit ist beabsichtigt. Das Skript wird in der Regel abgeschlossen, sobald die Rekursionstiefe verringert wird.

• Lösung:
  • Reduzieren Sie die Rekursionstiefe, oder schreiben Sie die rekursive Logik in eine iterative Schleife um.
  • Wenn der Algorithmus tiefe Rekursion nicht vermeiden kann, verwenden Sie einen Ansatz, der nicht darauf beruht.
  • Beachten Sie, dass das separate Pro-Skript-Schleife-Iterations-Limit (JavaScriptMaxIterations, siehe Skript-Schleife Iterationslimit überschritten) die Rekursionsobergrenze nicht anhebt, die nicht als konfigurierbare Einstellung verfügbar gemacht ist.

JavaScript: Änderungen globaler Variablen gehen bei Skriptfehler verloren

• Symptom: Ein JavaScript-Skript, das globale Variablen ändert, wird in einigen Fällen ohne offensichtlichen Fehler ausgeführt, aber Änderungen an diesen globalen Variablen fehlen in nachfolgenden Skripten oder Operationen.
• Mögliche Ursachen:
  • In JavaScript werden Änderungen an globalen Variablen nur übernommen, wenn das Skript erfolgreich abgeschlossen wird. Wenn das Skript an einer beliebigen Stelle fehlschlägt, werden alle während dieser Ausführung vorgenommenen Änderungen an globalen Variablen verworfen.
  • Das Mischen von $variable-Syntax mit Jitterbit.SetVar/Jitterbit.GetVar für dieselbe Variable innerhalb eines JavaScript-Skripts kann zu unvorhersehbarem Laufzeitverhalten führen.
• Lösung:
  • Strukturieren Sie JavaScript-Skripte so, dass alle Zuweisungen globaler Variablen nach Logik erfolgen, die fehlschlagen könnte, oder verwenden Sie Fehlerbehandlung, um Fehler in der Mitte des Skripts zu verhindern.
  • Verwenden Sie für jede Variable in einem JavaScript-Skript entweder die $variable-Syntax oder Jitterbit.SetVar/Jitterbit.GetVar, niemals beide. Wählen Sie eine aus und verwenden Sie diese konsistent im gesamten Skript.
  • Um zu bestätigen, welche Variablen gesetzt werden, fügen Sie WriteToOperationLog-Aufrufe hinzu, um Variablenwerte an Schlüsselpunkten während der Ausführung zu protokollieren.

JavaScript: GetVar gibt für benutzerdefinierte Projektvariablen null zurück

• Symptom: Das Aufrufen von Jitterbit.GetVar für eine benutzerdefinierte Projektvariable in einem JavaScript-Skriptschritt gibt null statt des Wertes der Variablen zurück, ohne dass eine Fehlermeldung angezeigt wird.
• Mögliche Ursache: Jitterbit.GetVar und Jitterbit.SetVar sind für Jitterbit-Systemvariablen (z. B. jitterbit.operation.name) und für Variablennamen mit einem Punkt vorgesehen, auf die die Punktnotation von JavaScript nicht direkt zugreifen kann. Sie lesen keine gewöhnlichen benutzerdefinierten Projektvariablen, deren Namen keinen Punkt enthalten; das Übergeben solcher Namen an GetVar gibt null zurück. Referenziere diese Variablen stattdessen direkt mit $name. Diese Funktionen konvertieren alle Werte auch in Strings, daher sind sie nicht für Arrays oder Objekte geeignet. Ein mit SetVar festgelegter Wert kann mit GetVar innerhalb desselben Skripts ausgelesen werden, bleibt aber nicht in späteren Skripts erhalten.

• Lösung: Verwende die Syntax $variableName direkt in JavaScript, um auf benutzerdefinierte Projekt- und globale Variablen zuzugreifen, deren Namen keinen Punkt enthalten. Reserviere GetVar und SetVar für Jitterbit-Systemvariablen und für Variablen, deren Namen einen Punkt enthalten (z. B. $hello.world), auf die die Punktnotation von JavaScript nicht direkt zugreifen kann. Verwende für eine gegebene Variable entweder $-Präfix oder GetVar/SetVar, aber nicht beide. Siehe auch JavaScript: Änderungen an globalen Variablen bei Skriptfehlern verloren.

  // Correct: access a user-defined project variable directly
  var value = $myProjectVar;
  
  // Incorrect for user-defined variables without periods:
  var value = Jitterbit.GetVar("$myProjectVar"); // returns null
  

HTTP- und API-Fehler

504 Gateway Timeout

• Symptom: API-Aufrufe über das Cloud- oder Private-API-Gateway geben 504 Gateway Timeout zurück, typischerweise nach dem Timeout-Fenster des Gateways (30 bis 180 Sekunden).
• Ursache und Lösung: Der zugrunde liegende Vorgang überschreitet das Timeout des API-Gateways, oder die Anforderung kann keinem verfügbaren Agent zugewiesen werden. Siehe HTTP 504 Gateway Timeout im Fehlerbehebungsleitfaden des API-Managers für die vollständigen Ursachen und Lösungen.

507 Insufficient Storage

• Symptom: Ein API-Aufruf gibt Folgendes zurück:

  507 Insufficient Storage
  

• Mögliche Ursachen:

  • Der Agent oder die Gateway-Host verfügt über keinen Speicherplatz mehr.
  • Bei einem Private-API-Gateway kann das Gateway seine gehostete Payload- oder Antwortdatei nicht öffnen und gibt einen 507 zurück, auch wenn ausreichend Speicherplatz verfügbar ist. Dies deutet in der Regel auf ein Problem mit der Registrierung der privaten Domain oder mit der Gateway-Konfiguration hin.

• Lösung:

  • Stelle sicher, dass der Agent oder die Gateway-Host über ausreichend freien Speicherplatz verfügt.
  • Wenn ausreichend Speicherplatz vorhanden ist und die API über ein Private-API-Gateway bereitgestellt wird, siehe Private Gateway gibt HTTP 507 oder „No such file or directory" zurück für die Ursache und Lösung.

502 Bad Gateway

• Symptom: Ein Vorgang, der Jitterbit Message Queue (JBMQ) verwendet, schlägt fehl mit:

  502 Bad Gateway
  

  Der Server hat eine ungültige oder unvollständige Antwort zurückgegeben.

• Mögliche Ursache: Der JBMQ-Dienst hat keine vollständige Antwort auf die Anforderung zurückgegeben, was zu einem 502 führt. Dieser Fehler ist in der Regel vorübergehend und kann möglicherweise nicht reproduziert werden.

• Lösung:
  1. Wiederhole den Vorgang.
  2. Wenn der Fehler weiterhin auftritt, wende dich an den Jitterbit-Support.

Fehler zur Designzeit

Diese Probleme treten beim Erstellen, Validieren oder Bereitstellen eines Projekts in Studio auf, nicht wenn ein Vorgang ausgeführt wird.

Häufige Validierungsfehler von Vorgängen

Vorgänge mit Validierungsfehlern zeigen ein Ungültig-Symbol auf der Design-Canvas und im Projektbereich an. Klicken Sie auf das Symbol, um die spezifische Fehlermeldung anzuzeigen.

Die folgende Tabelle listet häufige Validierungsfehler und deren Lösungen auf:

HTTP-Validierungsregelfehlern

Eine der HTTP-Validierungsregeln gilt für Operationen, die das Zwei-Ziel-Archiv-Muster verwenden, bei dem eine HTTP-Aktivität in der Position Ziel 1 eine Antwort an eine zweite Zielaktivität (Ziel 2) schreibt. In diesem Szenario verlangt die Validierungsregel, dass eine HTTP-Aktivität vom Typ Ziel 1 nicht in anderen Zwei-Ziel-Archiv-Muster-Operationen verwendet werden darf, bei denen die HTTP-Aktivität vom Typ Ziel 1 zu einer anderen zweiten Zielaktivität schreibt.

Operationen, die gegen diese Validierungsregel verstoßen, erscheinen als ungültig mit einer Fehlermeldung ähnlich dem folgenden Beispiel:

HTTP-Validierungsfehler beheben

Befolgen Sie die Anweisungen in der Fehlermeldung, um die Operationen so zu korrigieren, dass sie gültig sind. Um diese Fehler zu beheben, führen Sie die folgenden Schritte aus:

1. Duplizieren Sie die HTTP-Zielaktivität in der Position Ziel 1 einer der Operationen, die das Zwei-Ziel-HTTP-Archiv-Muster verwendet.

2. Ersetzen Sie die HTTP-Zielaktivität in der Position Ziel 1 der identifizierten Operationen durch die duplizierte Kopie.

3. Wiederholen Sie den Vorgang für alle weiteren ungültigen Operationen. Nachdem Sie die Validierungsfehler behoben haben, stellen Sie die Operationen erneut bereit.

HTTP-Validierungsregel deaktivieren

In bestimmten Situationen möchten Sie möglicherweise diese HTTP-Validierungsregel deaktivieren. Um die Regel zu deaktivieren, führen Sie die folgenden Schritte aus:

1. Öffnen Sie die Projekteinstellungen:

   

2. Deaktivieren Sie auf der Registerkarte Bereitstellung die Einstellung HTTP-Validierungsregel:

   

3. Klicken Sie auf Speichern.

Nachdem Sie die Einstellung deaktiviert und gespeichert haben, sollten die Operationsvalidierungsfehler dieser Regel behoben sein. Allerdings schreiben alle HTTP-Aktivitäten vom Typ Ziel 1, die in einer Zwei-Ziel-Archiv-Muster-Operation verwendet werden, in die Aktivität Ziel 2 der zuletzt bereitgestellten Operation. Dieses Verhalten könnte dazu führen, dass ungültige Daten geschrieben werden.

HTTP-Validierungsregel erneut aktivieren

Wenn Sie die HTTP-Validierungsregel zuvor deaktiviert haben und sie erneut aktivieren möchten, führen Sie die folgenden Schritte aus:

1. Öffnen Sie die Projekteinstellungen.

2. Aktivieren Sie auf der Registerkarte Bereitstellung die Einstellung HTTP-Validierungsregel.

3. Klicken Sie auf Speichern. Diese Änderung ist eine Designzeit-Änderung und stellt keine Änderungen in der Harmony-Cloud bereit.

4. Beheben Sie alle HTTP-Validierungsfehler (siehe HTTP-Validierungsfehler beheben).

5. Stellen Sie das Projekt erneut bereit (siehe Projektbereitstellung).

   Hinweis

   Vor der erneuten Bereitstellung ermöglicht Harmony die Ausführung aller nun ungültigen Operationen, da Harmony die derzeit bereitgestellten Operationen ausführt. Eine erneute Bereitstellung der betroffenen Operationen ist erforderlich, damit die Änderungen an Harmony weitergegeben werden.

Komponentennamen müssen nach dem Projektimport eindeutig sein

• Symptom: Nach dem Importieren eines Projekts aus einer JSON-Exportdatei werden eine oder mehrere Komponenten als ungültig angezeigt, und die Bereitstellung schlägt mit einer ähnlichen Meldung fehl:

  [Operation / Connection / Activity / Transformation / Script / Tool / Email / Variable] names must be unique.
  

• Mögliche Ursache: Das importierte Projekt enthält mehrere Komponenten desselben Typs mit identischen Namen. Studio verhindert die Erstellung von doppelten Namen bei der direkten Konfiguration von Komponenten in der Benutzeroberfläche, aber ein vollständiger Projektimport wendet diese Prüfung nicht an.

• Lösung:
  1. Identifizieren Sie im Projektbereich die ungültigen Komponenten, die in roter Kursivschrift mit einem Fehlersymbol angezeigt werden.
  2. Klicken Sie auf das Fehlersymbol, um den spezifischen doppelten Namen anzuzeigen, der den Konflikt verursacht.
  3. Benennen Sie eine der doppelten Komponenten um, sodass jeder Name innerhalb seines Typs eindeutig ist.
  4. Stellen Sie das Projekt nach der Behebung aller Fehler mit doppelten Namen erneut bereit.
  5. Um nur ausgewählte Komponenten in ein vorhandenes Projekt zu importieren, verwenden Sie den selektiven Import, der Konflikte mit gleichnamigen Komponenten im Zielproject kennzeichnet und Ihnen ermöglicht, diese zu ersetzen oder beides beizubehalten.

Connector nur für private Agents blockiert den Import in eine Cloud-Agent-Umgebung

• Symptom: Das Importieren oder Migrieren eines Projekts in eine mit einer Cloud-Agent-Gruppe verknüpfte Umgebung wird blockiert, da das Projekt einen Connector verwendet, der nur für private Agents verfügbar ist. Die Meldung führt die Connectoren auf, die nur für private Agents verfügbar sind und für das Problem verantwortlich sind. Ein vollständiger Projektimport zeigt Folgendes an:

  The project you are importing uses private agent only connectors and cannot be imported into a cloud environment.
  

  Ein selektiver Import zeigt einen Dialog zum Komponentenimport nicht zulässig an:

  The components you are importing uses private agent only connectors and cannot be imported into a cloud environment.
  

• Mögliche Ursache: Das Projekt verwendet einen oder mehrere Connectoren, die nur auf privaten Agents verfügbar sind. Die Spalte Agent-Verfügbarkeit in der Connectorliste zeigt an, welche Connectoren nur für private Agents verfügbar sind. Cloud-Agents unterstützen diese Connectoren nicht, daher verhindert Studio, dass das Projekt in eine Cloud-Agent-Umgebung importiert oder migriert wird.

• Lösung:
  • Importieren oder migrieren Sie das Projekt in eine mit einer privaten Agent-Gruppe verknüpfte Umgebung, auf der der erforderliche Connector installiert ist.
  • Wenn das Projekt auf Cloud-Agents ausgeführt werden muss, ersetzen Sie die Connector-Aktivitäten, die nur für private Agents verfügbar sind, durch Cloud-kompatible Connectoren (wie HTTP v2 für REST-APIs oder der Database-Connector mit einem Cloud-zugänglichen Endpunkt), bevor Sie das Projekt importieren.

Das Hochladen einer Schemadatei ersetzt sie projektweit

• Symptom: Nach dem Hochladen einer neuen Schemadatei während der Transformationskonfiguration verhalten sich andere Transformationen im Projekt, die dasselbe Schema verwendet haben, unerwartet oder erzeugen Fehler.
• Mögliche Ursache: Wenn man eine Datei mit demselben Namen wie eine bereits im Projekt definierte Schemadatei hochlädt, zeigt Studio einen Dialog Datei überschreiben? an. Klickt man auf Weiter, wird die vorhandene Datei an allen Stellen ersetzt, an denen sie verwendet wird. Diese Ersetzung erfolgt projektweit und nicht nur im Umfang der aktuellen Transformation.
• Lösung:
  1. Bevor man eine Ersatzschemadatei hochlädt, sollte man überprüfen, ob das vorhandene Schema freigegeben ist: Öffne das Schema zum Bearbeiten. Falls es von mehr als einer Komponente referenziert wird, zeigt Studio einen Dialog Schema wird von mehreren Komponenten verwendet an, der diese auflistet (siehe Transformationsdefinierte Schemas aktualisieren). Bewerte die Auswirkungen auf alle aufgelisteten Komponenten, bevor du fortfährst.
  2. Falls nur eine Transformation das aktualisierte Schema verwenden soll, klicke im Dialog Datei überschreiben? auf Abbrechen (oder benenne die neue Datei vor dem Hochladen um), damit die freigegebene Datei nicht überschrieben wird.

Bereitstellung der Marketplace-Prozessvorlage schlägt aufgrund von Schema-Nichtübereinstimmung fehl

• Symptom: Ein aus einer Marketplace-Prozessvorlage importiertes Projekt kann nicht bereitgestellt werden oder erzeugt Fehler zur Laufzeit, da Felder in einer Transformation oder einer Quell- und Zielaktivität fehlen und die Validierung fehlschlägt.
• Mögliche Ursache: Prozessvorlagen werden für eine bestimmte Endpunkt-Instanz entwickelt. Wenn sich deine Instanz unterscheidet (z. B. wenn dein Salesforce- oder NetSuite-Org unterschiedliche benutzerdefinierte oder Standardfelder hat), stimmen die in den Transformationen der Vorlage eingebetteten Schemas möglicherweise nicht mit deinem Endpunkt überein.
• Lösung:
  1. Öffne in der betroffenen Transformation die Schemaeinstellungen und klicke auf das Aktualisierungssymbol (oder das Wort Aktualisieren), um das Schema von deinem verbundenen Endpunkt neu zu generieren.
  2. Falls das Schema nach dem Aktualisieren immer noch nicht übereinstimmt, lösche das vorhandene Schema und spiegle es erneut von einer aktuellen Beispieldatei oder direkt vom Endpunkt.
  3. Ordne alle Felder neu zu, die während der Schema-Neugenerierung hinzugefügt oder entfernt wurden.
  4. Stelle das Projekt erneut bereit und führe den Vorgang erneut aus, um zu bestätigen, dass das Problem behoben ist.

Studio wird langsam oder reagiert bei sehr großen Projekten nicht

• Symptom: Studio reagiert langsam, wenn ein einzelner Workflow eine sehr große Anzahl von Operationen enthält, oder wenn man ein sehr großes Skript speichert.
• Mögliche Ursache: Die Design-Canvas rendert alle Operationen im aktiven Workflow gleichzeitig, daher stellt ein Workflow mit einer sehr großen Anzahl von Operationen hohe Speicheranforderungen an den Browser.
• Lösung:
  • Unterteile große Workflows in kleinere, verknüpfte Sub-Workflows. Studio rendert nur die aktive Workflow-Canvas, daher verbessert sich die Responsivität mit weniger Operationen pro Workflow. Verwende Operationsaktionen, um Sub-Workflows miteinander zu verknüpfen.
  • Falls die Verlangsamung spezifisch beim Speichern eines großen Skripts auftritt, teile das Skript in kleinere Skripte auf und rufe sie mit RunScript auf.

System- und Ressourcenfehler

Chunking erfordert einen nativen Connector als Quelle

• Symptom: Ein Vorgang mit aktiviertem Chunking sendet alle Datensätze in einem einzigen Batch an das Ziel, anstatt die konfigurierte Chunk-Größe zu berücksichtigen. Fehler vom Ziel zeigen an, dass die Batch-Grenze überschritten wurde (beispielsweise gibt Salesforce EXCEEDED_ID_LIMIT: record limit reached. cannot submit more than 200 records into this call zurück).
• Mögliche Ursache: Chunking wird nur berücksichtigt, wenn die Quelle ein nativer Connector ist. Vorgänge, die native Quellen wie HTTP, Database, Variable und Local Storage verwenden, berücksichtigen Chunking normalerweise.
• Lösung:
  • Deaktiviere Chunking in den Vorgangsoptionen, falls es nicht erforderlich ist.
  • Falls Chunking erforderlich ist, teile den Vorgang in zwei auf:
    • Im ersten Vorgang liest man aus der ursprünglichen Quelle und schreibt in eine Variable Write-Aktivität.
    • Im zweiten Vorgang liest man aus einer Variable Read-Aktivität und schreibt mit aktiviertem Chunking in das ursprüngliche Ziel. Da der Variable-Connector nativ ist, funktioniert Chunking in diesem Vorgang korrekt. Die Schritte zur Einrichtung von Chunking findest du unter Configure operation chunking.

Variablenupdates in mehrstufigen Chunked-Vorgängen verloren

• Symptom: Wenn ein Vorgang mit aktiviertem Chunking und Max Number of Threads auf mehr als 1 eingestellt ist, gehen Updates von globalen oder Projektvariablen, die während des Vorgangs vorgenommen wurden, nach dem Abschluss nicht vollständig verloren. Ein möglicher Fall ist das Ausfüllen einer Dictionary- oder Array-Variable aus jedem Quelldatensatz und die Feststellung, dass sie danach nur einen Teil der Daten enthält (beispielsweise ungefähr die Hälfte der Datensätze bei zwei Threads). Dies kann bei Connectors auftreten, deren Standardkonfiguration mehr als einen Thread verwendet, z. B. Salesforce-Aktivitäten, die standardmäßig 2 Threads verwenden.
• Mögliche Ursache: Jeder Thread erhält zu Beginn der Verarbeitung eine eigene Kopie der globalen und Projektvariablen. Thread-lokale Änderungen werden nicht wieder in den gemeinsamen Status integriert. Nur Änderungen des ersten Threads bleiben erhalten, wenn der Vorgang abgeschlossen ist; Änderungen aller anderen Threads werden verworfen.
• Lösung:
  • Wenn Korrektheit wichtiger ist als der Pro-Vorgang-Durchsatz, stelle Max Number of Threads auf 1. Jeder Chunk wird dann sequenziell verarbeitet, sodass Variablenupdates nicht auf Threads verteilt werden.
  • Wenn mehrstufiger Durchsatz erforderlich ist, speichere keinen Pro-Datensatz-Status in einer globalen oder Projektvariable. Schreibe stattdessen die Ausgabe jedes Threads in eine eindeutige Temporary Storage-Datei oder eine Staging-Datenbanktabelle, und konsolidiere die Ergebnisse dann in einem nachfolgenden Vorgang mit einem Thread. Ein praktisches Beispiel des Staging-Musters findest du unter Variable scoping with chunking.
  • Allgemein gesagt solltest du dich nicht auf Variable-Updates aus Chunked-Vorgängen mit mehreren Threads in späteren Skripten oder Vorgängen verlassen. Wenn der Variablenstatus beibehalten werden muss, lege diese Variablen in einem Schritt ohne Chunking fest, der vor oder nach der Chunked-Transformation ausgeführt wird. Einzelheiten zum Chunking-Verhalten mit Variablen findest du unter Use variables with chunking.

Fehler beim Erstellen des temporären Verzeichnisses

• Symptom: Ein Operation schlägt beim Erstellen eines temporären Verzeichnisses fehl und gibt eine Fehlermeldung wie die folgende aus:

  Failed to create the directory '/tmp/jitterbit/...'. Reason: boost::filesystem::create_directories: Permission denied
  

  Bei einer Cloud-Agent-Gruppe kann stattdessen die Meldung No space left on device angezeigt werden.

• Mögliche Ursachen:

  • Bei einem privaten Agent verfügt das Jitterbit-Agent-Dienstkonto nicht über die erforderlichen Berechtigungen auf Betriebssystemebene im Pfad der temporären Dateien, oder die Festplatte ist voll.
  • Bei einer Cloud-Agent-Gruppe liegt die Ursache auf der Seite des von Jitterbit verwalteten Agents und nicht in deinem Projekt oder in der Konfiguration.

• Lösung:

  • Bei privaten Agents bestätigst du, dass das Agent-Dienstkonto ausreichende Berechtigungen im Pfad der temporären Dateien (/tmp oder TemporaryFiles) hat, und überprüfst, dass der Agent-Host ausreichend freien Speicherplatz hat.
  • Bei Cloud-Agent-Gruppen deutet dies auf ein Problem auf der Agent-Seite hin, das Jitterbit behebt. Kontaktiere Jitterbit Support und gib die Fehlermeldung und den Zeitpunkt der Fehler an.

Operation-Protokollmeldungen auf ca. 100 KB gekürzt

• Symptom: Eine Operation-Protokollmeldung erscheint abgeschnitten und endet mit message truncated. Dies kann in den Operation-Protokollen oder beim Anzeigen eines Operation-Protokolleintrags auf der Seite API-Protokolle des API Manager angezeigt werden.
• Mögliche Ursache: Operation-Protokollmeldungen, die ca. 100 KB (ca. 99.000 Zeichen) überschreiten, werden gekürzt. Der Kürzungspunkt ist am Ende der Meldung mit message truncated gekennzeichnet.
• Lösung: Falls du den vollständigen Protokollinhalt benötigst, reduzierst du die Ausführlichkeit der Protokollierung der Operation oder teilst die Operation in kleinere Einheiten auf, die kürzere Protokollmeldungen erzeugen.

Das Debug-Protokoll der Operation legt PII und Anmeldeinformationen im Klartext offen

• Symptom: Sensible Daten, Anmeldeinformationen oder personenbezogene Informationen (PII) werden in den Harmony-Cloud-Protokollen angezeigt.
• Mögliche Ursache: Wenn das Debug-Protokoll der Operation für eine Operation aktiviert ist, werden alle Request- und Response-Daten 30 Tage lang im Klartext in der Harmony-Cloud gespeichert.
• Lösung:
  • Verwende das Debug-Protokoll der Operation nur in kontrollierten, produktionsfremden Umgebungen oder während einer begrenzten Diagnosephase.
  • Um die Generierung von Komponenteneingabe- und -ausgabedaten für eine private Agent-Gruppe zu deaktivieren, stellst du verbose.logging.enable=false im Abschnitt [VerboseLogging] der Agent-Konfigurationsdatei ein.