Fehlersuche bei Operationen im Jitterbit Integration Studio

Einführung

Wenn Sie Probleme bei der Ausführung einer Operation haben, werden die folgenden Fehlersuche-Maßnahmen empfohlen.

Verbindung testen

Für alle Operationen, die Connectoren verwenden, klicken Sie in der Verbindung auf die Schaltfläche Test, um sicherzustellen, dass die Verbindung erfolgreich ist.

Für auf Connector SDK-basierten Connectoren, die in Operationen ausgeführt werden, die auf privaten Agenten laufen, stellt das Klicken auf die Schaltfläche Test sicher, dass die neueste Version des Connectors auf den Agenten heruntergeladen wird (es sei denn, die Automatische Connector-Aktualisierung deaktivieren Organisationsrichtlinie wird verwendet).

Überprüfen Sie die Operationsprotokolle

Überprüfen Sie die Operationsprotokolle auf Informationen, die während der Ausführung der Operation geschrieben wurden.

Je nach Agententyp können Sie Folgendes tun, um zusätzliche Protokolldateien und Daten abzurufen:

• Aktivieren Sie das Debug-Protokoll für Operationen (für Cloud-Agenten oder für private Agenten)
• Aktivieren Sie das ausführliche Protokoll für Connectoren (nur private Agenten)
• Überprüfen Sie die Agentenprotokolle (nur private Agenten)

Mögliche Fehler in den Operationsprotokollen

Die folgenden Abschnitte behandeln Fehler, die in einem Operationsprotokoll vorhanden sein können, und deren Behebung.

Warnung vor zusätzlichen Unterelementen

Eine Warnung über zusätzliche Unterelemente in den Protokollnachrichten kann im Allgemeinen ignoriert werden. Diese Warnung zeigt an, dass die API-Nutzlast eines Connectors mehr Knoten oder Felder von Daten zurückgegeben hat, als im Antwortdatenschema definiert sind.

Unzulässige Zeichen in XML-Schema-Zuordnungen

Je nach Connector-Aktivität sind diese Zeichen ungültig und führen zu einem Laufzeitfehler:

Wenn die Eingabe- oder Ausgabedaten, die an eine Transformation angrenzen, die mit einer XML-basierten Connector-Aktivität verbunden ist, eines der oben genannten Zeichen enthalten, wird zur Laufzeit ein spezifischer Fehler zurückgegeben, der auf dieses Zeichen verweist. Zum Beispiel, wenn das \x1E Steuerzeichen in der Antworttransformation für die Epicor Kinetic Get BAQ-Aktivität vorhanden ist, wird dieser Fehler zur Laufzeit zurückgegeben:

Die Ausnahme ist ungültiges Leerzeichenzeichen (0x1e) im Text zur Ausgabe

Nicht unterstützte XML-Elemente, wenn sie in JSON eingebettet sind

Character data (CDATA) sections werden nicht unterstützt, wenn XML in JSON eingebettet ist, das durch eine Transformation gesendet werden soll. Das Einfügen von CDATA-Abschnitten kann zur folgenden Fehlermeldung im Betriebsprotokoll zur Laufzeit führen:

Transformation fehlgeschlagen. Fehler: Die Operation "Operation" ist fehlgeschlagen.
Fehler: XML-Datei konnte nicht in JSON konvertiert werden.
org.jitterbit.integration.server.engine.EngineSessionException: org.xml.sax.SAXParseException ...

Um dies zu umgehen, verwenden Sie ein Jitterbit-Skript, um die Zeichen &, <, >, ' und " des gesamten CDATA-Abschnitts, einschließlich seiner Definition (<![CDATA[ ... ]]>), durch &amp, &lt, &gt, &apos, &quot zu ersetzen. Falls erforderlich, kann der gesamte XML-String, der den CDATA-Abschnitt enthält, ersetzt werden, wenn das gezielte Ersetzen des Abschnitts nicht zu Ihrem Anwendungsfall passt.

Das folgende Beispiel wird ohne Ersetzungen als ungültig betrachtet:

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

Reprocessing of mirrored XML schemas

Aufgrund von Änderungen in den Harmony-Versionen 10.25 und 10.27 können Sie in Projekten, die vor diesen Versionen erstellt wurden, ein anderes Verhalten feststellen. Diese Änderungen betreffen XML-Schemas, die gespiegelt wurden, und haben wahrscheinlich Auswirkungen auf Zuordnungen, die XML-Funktionen verwenden, die Namensräume betreffen, wie die Funktion SelectNodes. In diesem Fall können Zuordnungen, die zuvor gültig waren, jetzt ungültig sein, mit einem Fehler, der sich auf die Syntax der XML-Funktion bezieht.

Vergleichen Sie die Unterschiede zwischen diesem Beispiel eines gespiegelten XML-Schemas vor 10.25 und einem, das in 10.25 oder später erstellt wurde:

• Beispiel XML-Schema vor 10.25: In Projekten, die vor 10.25 erstellt wurden, verwenden spiegelte XML-Schemas das Standard-Namensraum-Präfix für XML-Dokumente: xsi. Wie oben rot hervorgehoben, erklärt xmlns:xsi den Namensraum und nicht zugeordnete Felder werden im Schema mit dem Attribut xsi:nil="true" angezeigt.
• Beispiel XML-Schema in 10.25 und später: In Projekten, die in 10.25 und später erstellt wurden und oben grün hervorgehoben sind, verwenden spiegelte XML-Schemas das Namensraum-Präfix ns, um einen qualifizierten Namensraum zu deklarieren. Nicht zugeordnete Felder werden im Schema nicht angezeigt.

In den Versionen 10.25 und 10.26, wenn Sie ein Projekt mit einem spiegelten XML-Schema, das vor 10.25 erstellt wurde, importiert haben, wurde das Schema neu verarbeitet und geändert, um das qualifizierte Namensraum-Präfix zu verwenden.

Ab Version 10.27 behalten importierte Projekte, deren spiegelte XML-Schemas vor 10.25 erstellt wurden, das Standard-Namensraum-Präfix des XML-Schemas, sodass das Schema identisch ist mit dem, als es erstellt wurde. Diese Änderung bedeutet, dass alle Projekte vor 10.25, die in die aktuelle Version importiert werden, wie ursprünglich entworfen funktionieren sollten.

Um ein vor 10.25 erstelltes XML-Schema zu zwingen, das aktualisierte Namensraum-Präfix zu verwenden, können Sie das Schema neu generieren, indem Sie es aktualisieren oder die Aktivität, die das Schema bereitstellt, neu konfigurieren.

Sonderzeichen in von Konnektoren bereitgestellten JSON-Schemas

Wenn eine Transformation ein JSON-Schema verwendet, das von einer angrenzenden Konnektor-Aktivität geerbt wurde, werden alle Sonderzeichen in einem Schemafeld oder Knotennamen durch Unterstriche (_) ersetzt.

Bei der Verwendung der veralteten JSON-Verarbeitung (der Standard für Projekte, die vor der 11.48 Harmony-Version erstellt wurden), kann dieses Verhalten dazu führen, dass Fehler von dem Endpunkt zurückgegeben werden.

Zum Beispiel, wenn die Aktivität einen Feldnamen von location_ids[] bereitstellt, wird dieser in location_ids__ umgewandelt, jedoch erwartet der Endpunkt weiterhin den ursprünglichen Feldnamen location_ids[] und gibt den Fehler zurück, wie zum Beispiel "error_message": "{location_ids:expected String to be a Array}",}}.

Um dieses Problem zu lösen, befolgen Sie diese Schritte:

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

   

2. Konfigurieren Sie das Projekt so, dass die JSON-Namen beibehalten Verarbeitung verwendet wird, indem Sie die JSON-Namen beibehalten Projekteinstellung aktivieren (Agenten-Version 11.48 oder höher ist erforderlich).

3. Konfigurieren Sie die Operation neu, stellen Sie sie bereit und führen Sie sie aus.

   Wichtig

   Wenn JSON-Namen beibehalten in einem Projekt aktiviert wird, in dem es derzeit deaktiviert ist, beachten Sie, dass die JSON-Namen beibehalten Verarbeitung nur für Operationen und Schemata verwendet wird, die nach der Aktivierung der Einstellung konfiguriert werden. Das heißt, bestehende Operationen und Schemata verwenden weiterhin die alte JSON-Verarbeitung. Wir empfehlen, alle bestehenden Operationen und Schemata in solchen Projekten neu zu konfigurieren, da die Verwendung beider Schema-Verarbeitungsmethoden in einem einzigen Projekt zu Inkonsistenzen im Projekt führen kann.

Wenn Sie die JSON-Namen beibehalten Verarbeitung verwenden, können Sie den Feld- oder Knotennamen, der an den Endpunkt übergeben wird, überprüfen, indem Sie den jsonPropertyName in den Eingabe- oder Ausgabedaten der Aktivität anzeigen, wenn das Debug-Logging aktiviert ist (für Cloud-Agenten oder für private Agenten). Der Wert des jsonPropertyName ist der Wert, der in der Anfrage gesendet wird: