Zum Inhalt springen

Connector-Fehlerbehebung in Jitterbit Studio

Diese Anleitung behandelt Fehler und unerwartet auftretendes Verhalten, das spezifisch für einzelne Jitterbit Studio-Connectoren ist und nach Connector organisiert wird. Sie listet nur Connectoren mit bekannten, connector-spezifischen Problemen auf, nicht jeden verfügbaren Connector. Die vollständige Liste der Connectoren finden Sie unter Connectoren. Beginnen Sie mit den Diagnoseschritten unten und suchen Sie dann nach Ihrem Connector im entsprechenden Abschnitt.

Bei Problemen, die nicht spezifisch für einen Connector sind, wie beispielsweise ein Vorgang, der nicht ausgeführt wird, oder ein Problem mit einer Transformation, einem Script oder einer Funktion, finden Sie weitere Informationen unter Fehlerbehebung bei Vorgängen. Bei Problemen mit privaten Agents, wie beispielsweise ein Agent, der offline, fehlerhaft oder langsam ist (was den Stopp aller Vorgänge verursachen kann), finden Sie weitere Informationen unter Fehlerbehebung bei privaten Agents.

Eine einheitliche Referenz zu Integrations-, Automatisierungs-, API-Management-, EDI- und App-Entwicklungsproblemen an einem Ort finden Sie im Harmony-Leitfaden zur Fehlerbehebung.

Alle Einträge zur Fehlerbehebung auf dieser Seite

Diagnose-Schritte

Diese Schritte gelten für die meisten Connector-bezogenen Fehler und sind der empfohlene Ausgangspunkt, bevor man einen spezifischen Connector-Fehler untersucht.

Verbindung testen

Klicke in der Verbindungskonfiguration auf die Schaltfläche Test, um zu bestätigen, dass die Verbindung erfolgreich ist. Durch Klicken auf Test wird auch die neueste Version des Connectors zum Agenten heruntergeladen, sofern die Organisationsrichtlinie Disable Auto Connector Update nicht aktiviert ist.

Verbindungsmetadaten und Aktivitätsschemas aktualisieren

Viele Connector-Probleme, wie fehlende Objekte, eine veraltete Feldliste oder ein Schema, das nicht mehr dem Endpoint entspricht, entstehen durch zwischengespeicherte Metadaten. Nach jeder Änderung auf der Endpoint-Seite (neue Felder, eine API-Versionänderung oder eine Berechtigungsänderung) öffnet man die betroffene Aktivität erneut und klickt auf das Aktualisierungssymbol (Aktualisieren), um Objekte und Schemas vom Endpoint neu zu laden.

Connector-Verfügbarkeit bestätigen und aktuell halten

Die Spalte Agent-Verfügbarkeit auf der Connectors-Liste zeigt, ob ein Connector einen privaten Agent erfordert.

Connectors werden gemäß Jitterbit's Veröffentlichungsplan separat vom Agent veröffentlicht und aktualisiert. Auf privaten Agents lädt das Testen einer Verbindung die neueste Version des Connectors herunter (siehe Verbindung testen oben), sofern nicht die Organisationsrichtlinie Automatische Connector-Aktualisierung deaktivieren aktiviert ist. Um die Connectors für eine Agent-Gruppe jederzeit zu aktualisieren, auch wenn diese Richtlinie aktiviert ist, wählt man Aktion > Connectors aktualisieren für die Gruppe auf der Seite Agents der Management Console.

Connector Verbose Logging aktivieren

Auf Anweisung des Jitterbit-Supports aktiviert man Connector Verbose Logging auf dem privaten Agent, um Details auf Connector-Ebene zu erfassen, reproduziert dann das Problem und überprüft die Logs. Verbose Logging verwendet einen Connector-spezifischen Logger-Eintrag; die exakte Zeile, die zu logback.xml hinzugefügt werden muss, ist im Abschnitt Troubleshooting der Dokumentationsseite des jeweiligen Connectors unter Connectors angegeben.

Verbindungskonfiguration

Erweiterte Konfigurationseigenschaften: Variablen mit Raw JSON müssen maskiert werden

  • Symptom: Viele Connectors enthalten eine Tabelle Erweiterte Konfigurationseigenschaften für optionale Verbindungseinstellungen. Variablen, die in diesen Feldern verwendet werden und Raw JSON enthalten, müssen mit Escapezeichen versehen sein; das Übergeben von unescaptem Raw JSON über eine Variable führt dazu, dass der Feldwert fehlerhaft wird.
  • Mögliche Ursache: Felder in der Tabelle Erweiterte Konfigurationseigenschaften unterstützen keine Variablen, die unescapte Raw JSON-Objekte enthalten.
  • Lösung:
    • Vor dem Übergeben von JSON-Inhalten über eine Variable in ein Feld Erweiterte Konfigurationseigenschaften müssen die JSON-Zeichen maskiert werden. Zum Beispiel muss {"success": "true"} als {\"success\": \"true\"} maskiert werden, bevor es der Variablen zugewiesen wird.
    • Wenn man den JSON-Wert direkt in das Feld eingibt (nicht über eine Variable), ist keine Maskierung erforderlich.
    • Variablen in Feldern Erweiterte Konfigurationseigenschaften werden nur zur Laufzeit auf Agent-Version 10.75 / 11.13 oder später befüllt. Falls ein Variablenwert zur Laufzeit nicht angezeigt wird, bestätigt man, dass der Agent diese Mindestversion erfüllt.

Amazon Bedrock Connector

Amazon Bedrock: Modellfehler „on-demand throughput isn't supported"

  • Symptom: Eine Amazon Bedrock-Aktivität schlägt mit folgender Meldung fehl:

    Invocation of model ID <model-name> with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile that contains this model.

  • Mögliche Ursache: Einige Modelle, einschließlich OpenAI's GPT-5.6-Modelle, unterstützen On-Demand-Durchsatz nicht und benötigen stattdessen die ID eines regionsübergreifenden Inference-Profils anstelle der Modell-ID, die in der Liste Modell auswählen der Aktivität angezeigt wird.

  • Lösung:
    1. In der AWS Management Console navigiert man zu Amazon Bedrock > Inference profiles und lokalisiert die Inference-Profil-ID für das Modell. Zum Beispiel ist die Inference-Profil-ID für anthropic.claude-3-5-haiku-20241022-v1:0 in den USA us.anthropic.claude-3-5-haiku-20241022-v1:0. Für OpenAI's GPT-5.6-Modelle variieren gültige Inference-Profil-ID-Präfixe je nach Modell und Region (z. B. us. oder global.), wie z. B. us.openai.gpt-5.6-terra oder global.openai.gpt-5.6-terra. Für die exakte Inference-Profil-ID für das eigene Modell und die Region siehe AWS's Modellkarten für GPT-5.6 Sol, GPT-5.6 Terra und GPT-5.6 Luna.
    2. Man gibt die Inference-Profil-ID über die Option Modellkennung eingeben in der Aktivitätskonfiguration ein.

Cloud Datastore Connector

Query Items-Aktivität gibt nicht alle übereinstimmenden Datensätze zurück, wenn nach mehreren Werten desselben Feldes gefiltert wird

  • Symptom: Eine Query Items-Aktivität, die mehrere spezifische Datensätze gleichzeitig abrufen soll (z. B. über eine Liste von Key-Werten), gibt nur einen Datensatz zurück, obwohl alle Datensätze im Speicher vorhanden sind und in der Management Console auf der Seite Cloud Datastore bestätigt werden können.
  • Mögliche Ursache: Der Filterausdruck der Abfrage kombiniert mehrere Bedingungen auf demselben Feld (z. B. mehrere verschiedene Key-Werte in einem einzelnen Filter). Cloud Datastore Filterbedingungen können nur kombiniert werden, wenn jede Bedingung ein anderes Feld angibt. Ein Filter kann dasselbe Feld nicht mehr als einmal angeben, und auf demselben Feld können nicht mehrere Bedingungen oder Operatoren angewendet werden.
  • Lösung: Führen Sie für jeden Wert einen separaten Query Items-Aufruf durch, anstatt mehrere Werte desselben Feldes in einen Filter zu kombinieren. Details zu unterstützten Filterbedingungen finden Sie unter Query Items-Aktivität.

Delete Items-Aktivität meldet Erfolg, löscht den Datensatz aber nicht

  • Symptom: Eine Cloud Datastore Delete Items-Aktivität meldet im Operationsprotokoll Erfolg, aber der Zieldatensatz ist nach einer späteren Abfrage noch vorhanden.
  • Mögliche Ursache: Delete Items identifiziert Datensätze über den Key (oder Alternative Key) des Speichers, der im keys- oder ids-Array der Anfrage angegeben ist. (Beide Arrays akzeptieren Schlüssel- oder alternative Schlüsselwerte.) Wenn die interne ID des Datensatzes anstelle seines Schlüsselwerts angegeben wird, stimmt kein Element überein, und die Aktivität meldet Erfolg, ohne etwas zu löschen.
  • Lösung:
    • In der Transformation, die die Delete Items-Anfrage vorbereitet, ordnen Sie den Key (oder Alternative Key) des Speichers zu, nicht die interne Datensatz-ID.
    • Wenn Sie eine Verkettung aus einer Query Items-Aktivität vornehmen, ordnen Sie den key-Wert aus der Abfrageantwort in die Löschanfrage ein.

Coupa Connector

Coupa: API-Schlüssel-Authentifizierung gibt 403 Forbidden zurück

  • Symptom: Eine Coupa-Connector-Operation schlägt mit einem Forbidden (403)-Fehler fehl, wenn API-Schlüssel-Authentifizierung verwendet wird.
  • Mögliche Ursache: Seit Coupa Release R35 (Januar 2023) sind Coupa-API-Schlüssel veraltet und werden für die Authentifizierung nicht mehr unterstützt. Verbindungen, die für API-Schlüssel-Authentifizierung konfiguriert sind, erhalten einen 403-Fehler.
  • Lösung:
    1. Wechseln Sie in der Coupa-Verbindungskonfiguration von der API-Schlüssel-Authentifizierung zu OAuth 2.0-Authentifizierung.
    2. Erstellen Sie in Ihrer Coupa-Instanz eine OAuth 2.0-Clientanwendung und rufen Sie die Client-Anmeldeinformationen ab.
    3. Aktualisieren Sie die Verbindungskonfiguration mit den OAuth 2.0-Anmeldeinformationen, speichern Sie sie und führen Sie erneut einen Test durch.

Datenbankconnector

Datenbank (JDBC): DBLookup oder DBExecute schlägt mit Base64-Dekodierungsfehler fehl

  • Symptom: Eine DBLookup- oder DBExecute-Funktion für eine PostgreSQL- oder SQL Server-Datenbank über einen JDBC-Treiber schlägt zur Laufzeit fehl mit:

    Base64 decoding failed. Reason: error:00000000:lib(0)::reason(0)

    Dies tritt auf, wenn der zurückgegebene Wert wie Base64-codierte Daten aussieht, z. B. ein JWT oder ein anderes Zugriffstoken, obwohl die gleiche Abfrage bei direkter Ausführung gegen die Datenbank erfolgreich ist.

  • Mögliche Ursache: Versionen des Agenten vor 12.9 können fälschlicherweise versuchen, einen JDBC-Ergebniswert zu Base64-dekodieren, der einem Base64-ähnlichen Muster entspricht, unabhängig davon, ob der Wert tatsächlich Base64-codierte Daten sind.

  • Lösung:

    • Aktualisieren Sie für private Agenten auf Version 12.9 oder später. Cloud-Agenten erhalten das Update automatisch.
    • Falls ein sofortiges Upgrade nicht möglich ist, vermeiden Sie die Base64-Überprüfung, indem Sie den betroffenen Wert in der SQL-Abfrage in Hexadezimal umwandeln und dann in einem Skriptschritt mit HexToString dekodieren. Beispiel in PostgreSQL: SELECT encode(<column>, 'hex'). Verwenden Sie das entsprechende SQL-Äquivalent decode(...,'hex') mit StringToHex, wenn Sie den Wert zurück in die Datenbank schreiben.

Datenbank (ODBC): Mehrbyte-Zeichen werden nicht korrekt verarbeitet

  • Symptom: Beim Lesen oder Schreiben in einer Datenbank über den Datenbankconnector mit einem ODBC-Treiber werden Mehrbyte- oder Nicht-ASCII-Zeichen (z. B. akzentuierte oder nicht-lateinische Zeichen) nicht korrekt verarbeitet.
  • Mögliche Ursache: Die Unterstützung für Mehrbyte-Zeichen beim Datenbankconnector über einen ODBC-Treiber ist standardmäßig nicht aktiviert. Die Jitterbit-Variable jitterbit.scripting.db.multibyte.enable muss auf true gesetzt werden. Diese Unterstützung ist ab Agent-Version 12.6 verfügbar und nicht erforderlich, wenn ein JDBC-Treiber verwendet wird.

  • Lösung:

    1. Überprüfen Sie, ob der Agent Version 12.6 oder später ist.

    2. Setzen Sie die Variable jitterbit.scripting.db.multibyte.enable auf true, bevor der Datenbankvorgang ausgeführt wird. Beispiel in einem Skriptschritt:

      $jitterbit.scripting.db.multibyte.enable = true;

    Verwenden Sie alternativ einen JDBC-Treiber für die Datenbankverbindung, der Mehrbyte-Zeichen ohne diese Variable verarbeitet.

Datenbank: Verbindung durch Sicherheitsrichtlinie blockiert

  • Symptom: Ein Test der Datenbankconnector-Verbindung schlägt fehl mit:

    HttpErrorResponse: The database connection could not be established due to a security policy violation.

    mit einer Detailzeile, die entweder eine Loopback-Verbindung benennt:

    Details: java.lang.IllegalArgumentException - JDBC connections to loopback addresses are not permitted.

    oder einen spezifischen Verbindungsstring-Parameter:

    Details: java.lang.IllegalArgumentException - JDBC connection parameter 'allowmultiqueries' cannot be enabled.

  • Mögliche Ursache: Agent-Version 12.10 und später beschränken standardmäßig bestimmte Datenbankverbindungen und Verbindungsstring-Parameter aus Sicherheitsgründen. Dies umfasst Verbindungen zu localhost oder 127.0.0.1 sowie spezifische Verbindungsstring-Parameter für die MySQL-, PostgreSQL-, Oracle- und SQL Server-Treiber. Eine Verbindung, die zuvor funktioniert hat, kann nach dem Upgrade eines privaten Agenten auf Version 12.10 fehlschlagen, da die Beschränkung standardmäßig gilt, obwohl der Abschnitt [JdbcSecurity] nicht automatisch zu einer vorhandenen jitterbit.conf-Datei hinzugefügt wird.

  • Lösung: Konfigurieren Sie auf einem privaten Agent den Abschnitt [JdbcSecurity] der Agent-Konfigurationsdatei (jitterbit.conf), um die spezifische Verbindung oder den benötigten Parameter zuzulassen, und starten Sie dann den Agent neu.

Datenbank: Verbindungszeitüberschreitungen unter Last

  • Symptom: Datenbankquellen- oder Zieloperationen schlagen unter hoher gleichzeitiger Last zeitweise fehl, mit einer Ausnahme ähnlich wie:

    java.sql.SQLException: Network error IOException: Connection timed out
Caused by: java.net.ConnectException: Connection timed out

  • Mögliche Ursache: Jede Datenbankoperation öffnet eine neue physische JDBC-Verbindung und schließt sie danach, anstatt eine bestehende Verbindung wiederzuverwenden. Unter gleichzeitiger Last entsteht dadurch genug Verbindungswechsel gegen die Zieldatenbank, dass einige Verbindungsversuche zeitüberschritten werden.

  • Lösung: Agent-Version 12.11 und später können Verbindungen poolen und wiederverwenden, anstatt für jede Operation eine neue zu öffnen und zu schließen, was diesen Wechsel reduziert. Konfigurieren Sie auf einem privaten Agent jdbc.hikari.enabled=true im Abschnitt [SourceTargetPooling] der Agent-Konfigurationsdatei (jitterbit.conf), und starten Sie dann den Agent neu.

Datenbank: Feldlängefehler bei Insert, Update oder Upsert

  • Symptom: Eine Datenbank-Aktivität Insert, Update oder Upsert schlägt mit einem Error-Betriebsstatus fehl, wenn ein zugeordneter Quellwert länger ist als das Zielfeld zulässt. Das Operationsprotokoll enthält eines der folgenden Elemente:

    One or more values were truncated when inserting and/or updating the field

    Field value too long
FieldName: m_site  Length: 3  Length Allowed: 1

  • Mögliche Ursache: Standardmäßig lehnt die Aktivität die Zeile ab und meldet einen Error-Status, wenn ein zugeordneter Quellwert die definierte Länge des Zielfelds überschreitet, anstatt den Wert zu kürzen.

  • Lösung:
    1. Aktivieren Sie in der Konfiguration der Datenbankaktivität Insert, Update oder Upsert die Option Allow truncation of character fields to avoid field length errors (Abkürzung von Zeichenfeldern zur Vermeidung von Feldlängenfehlern zulassen). Mit dieser Option aktiviert werden Werte, die die Zielfleldlänge überschreiten, gekürzt und die Operation meldet einen Success with Info-Status anstelle eines Error-Status.
    2. Wenn das Kürzen nicht akzeptabel ist, trimmen oder transformieren Sie das Quellfeld in der Transformationszuordnung, so dass Werte nie die Zielfleldlänge überschreiten, oder erweitern Sie das Zielfeld auf der Datenbankseite.
    3. Stellen Sie die Operation erneut bereit und führen Sie sie erneut aus.

Datenbank: JDBC-Treiber-JAR bei Agent-Upgrades überschrieben

  • Symptom: Benutzerdefinierte JDBC-Treiber-JAR-Dateien, die für den Datenbankconnector installiert wurden, werden beim Agent-Upgrade gelöscht oder überschrieben.
  • Mögliche Ursache: Bei Agent-Upgrades wird nur das Verzeichnis <JITTERBIT_HOME>/tomcat/drivers/lib/ beibehalten. Benutzerdefinierte Treiber-JAR-Dateien, die an anderer Stelle in den Agent-Verzeichnissen platziert werden, sind Teil der verwalteten Bereitstellung und können während eines Upgrades entfernt oder überschrieben werden.
  • Lösung:
    • Platzieren Sie benutzerdefinierte JDBC-Treiber-JAR-Dateien stattdessen in <JITTERBIT_HOME>/tomcat/drivers/lib/. Dieses Verzeichnis wird bei Agent-Upgrades beibehalten.
    • Wenn sich die Treiber derzeit am falschen Ort befinden, verschieben Sie sie in das richtige Verzeichnis und starten Sie den Agent neu.

Datenbank: Sonderzeichen in Spaltennamen verursachen Abfragefehler

  • Symptom: Datenbankabfragen oder Transformationen schlagen fehl, wenn eine Quelltabelle Spaltennamen enthält, die Sonderzeichen wie @ enthalten.
  • Mögliche Ursache: ODBC-Treiber können bestimmte Sonderzeichen in Datenbankspaltennnamen nicht verarbeiten.
  • Lösung:
    1. Erstellen Sie eine Datenbankansicht auf der physischen Tabelle, die die betroffene Spalte unter einem Namen verfügbar macht, der keine Sonderzeichen enthält.
    2. Leiten Sie die Datenbankaktivität auf die Ansicht statt auf die ursprüngliche Tabelle.

Datenbank: SQL-Anweisung überschreitet das Limit von 2.000 Zeichen

  • Symptom: Eine Datenbankaktivität vom Typ Query schlägt fehl oder wird abgeschnitten, wenn die konfigurierte SQL-Anweisung sehr lang ist.
  • Mögliche Ursache: Das SQL-Anweisungsfeld in einer Datenbankaktivität vom Typ Query akzeptiert maximal 2.000 Zeichen.
  • Lösung:
    1. Erstellen Sie eine Datenbankansicht, die die komplexe Abfragelogik kapselt.
    2. Verweisen Sie den Namen der Ansicht in der Aktivität Query statt auf die vollständige SQL-Anweisung.

IBM DB2 on iSeries: JDBC-Verbindung schlägt fehl

  • Symptom: Eine Datenbankverbindung zu IBM DB2 on iSeries (AS/400 oder IBM i) mit einem JDBC-Treiber kann sich nicht verbinden.
  • Mögliche Ursache: Einige Verbindungen zu DB2 on iSeries mit einem JDBC-Treiber verursachen Probleme, die bei einem ODBC-Treiber nicht auftreten.
  • Lösung: Wechseln Sie die Verbindung zum Verwenden eines ODBC-Treibers statt JDBC. ODBC-Verbindungen werden nur auf privaten Agents unterstützt.

IBM DB2: JCC JDBC-Treiber-Setup (veraltete JAR- und Lizenzdatei)

  • Symptom: Eine Datenbankverbindung mit dem IBM DB2 JCC JDBC-Treiber schlägt fehl mit einem Fehler, der sich auf eine fehlende Lizenz bezieht, oder schlägt fehl oder erzeugt Kompatibilitätsfehler mit neueren DB2-Releases.
  • Mögliche Ursachen:
    • Die Treiberdatei db2jcc.jar implementiert die veraltete JDBC-3-Spezifikation. Die aktuelle db2jcc4.jar implementiert JDBC 4, das neuere DB2-Releases erfordern.
    • Der JCC-Treiber erfordert eine separate Lizenz-JAR-Datei. Die Treiber-JAR allein ist nicht ausreichend.
  • Lösung:
    • Verwenden Sie den Treiber db2jcc4.jar statt der veralteten db2jcc.jar. Installieren Sie ihn in <JITTERBIT_HOME>/tomcat/drivers/lib/ auf dem privaten Agent.
    • Beziehen Sie die Lizenz-JAR-Datei von IBM (benannt db2jcc_license_cisuz-XX.jar, wobei XX die Versionsnummer ist) und kopieren Sie sie nach <JITTERBIT_HOME>/tomcat/shared/lib/.
    • Verwenden Sie alternativ die JTOpen-Open-Source-Bibliothek (auch als AS400-Treiber bekannt), die keinen JCC-Treiber oder eine Lizenzdatei erfordert.

Kerberos: „Could not initialize class KerbAuthentication"

  • Symptom: Eine Datenbankverbindung mit Kerberos-Authentifizierung schlägt fehl mit:

    Could not initialize class com.microsoft.sqlserver.jdbc.KerbAuthentication

  • Mögliche Ursache: Die Kerberos-Konfigurationsdateien auf dem Agent-Host haben nicht die richtigen Dateiberechtigungen.

  • Lösung:
    1. Setzen Sie auf dem privaten Agent-Host die Dateiberechtigungen für die Kerberos-Konfigurationsdateien (jaas.conf, krb5.conf und die Kerberos-Ticketcache-Datei) auf 644:
chmod 644 jaas.conf krb5.conf krb5cc_agent
  1. Starten Sie den Agent nach Anwendung der Berechtigungsänderungen neu.

Kerberos: JGSS- oder GSS-Fehler während des Verbindungstests

  • Symptom: Eine Database-Verbindung mit Kerberos-Authentifizierung schlägt mit Fehlern fehl, die auf jgss oder gss verweisen.
  • Mögliche Ursache: Die JVM ist mit -Dsun.security.jgss.native=true konfiguriert, was sie anweist, die native GSSAPI-Bibliothek des Betriebssystems zu verwenden. Auf einigen Systemen führt dies zu Konflikten mit der Kerberos-Konfiguration.
  • Lösung:
    1. Entfernen Sie den Parameter -Dsun.security.jgss.native=true aus den JVM-Argumenten des Agents.
    2. Fügen Sie in krb5.conf unter dem Abschnitt [libdefaults] den Eintrag udp_preference_limit = 1 hinzu, um TCP statt UDP für den Kerberos-Datenverkehr zu erzwingen.
    3. Starten Sie den Agent neu.

Microsoft Excel: „Operation must use an updateable query"

  • Symptom: Eine Database Insert- oder Update-Aktivität, die auf eine Microsoft Excel-Datei (über ODBC) abzielt, schlägt mit folgendem Fehler fehl:

    [Microsoft][ODBC Excel Driver] Operation must use an updateable query

  • Mögliche Ursache: Der ODBC Excel-Treiber öffnet die Excel-Datei standardmäßig im Modus „Nur lesen", es sei denn, die Verbindungszeichenfolge legt explizit den Lese-/Schreibmodus fest.

  • Lösung: Fügen Sie im Feld Connection String der Datenbankverbindung (eingegeben unter Optional Settings mit ausgewähltem Use Connection String) am Ende der Verbindungszeichenfolge ReadOnly=0; an, um die Excel-Datei im Lese-/Schreibmodus zu öffnen.

MySQL: Zugriff verweigert trotz korrekter Anmeldedaten

  • Symptom: Die Verbindung zu einer MySQL-Datenbank mit dem Database connector schlägt mit folgendem Fehler fehl:

    Access denied for user 'root'@'%' to database 'test'

    obwohl Benutzername und Passwort korrekt sind.

  • Mögliche Ursache: MySQL kann unterschiedliche Berechtigungen basierend auf der IP-Adresse des Clients gewähren. Ein Benutzerkonto verfügt möglicherweise über die erforderlichen Berechtigungen von bestimmten IP-Adressen, aber nicht von der IP-Adresse des privaten Agents.

  • Lösung:

    • Überprüfen Sie in MySQL, dass das Benutzerkonto die erforderlichen Berechtigungen für Verbindungen von der IP-Adresse des privaten Agents hat. Die genaue GRANT-Syntax variiert je nach MySQL-Version (siehe MySQL-Dokumentation oder kontaktieren Sie Ihren MySQL-Administrator), hat aber grundsätzlich die folgende Form:

      GRANT ALL ON database.* TO 'user'@'agent-ip';

    • Testen Sie die Konnektivität mit einem MySQL-Client, der direkt auf dem Agent-Host installiert ist, um festzustellen, ob das Problem netzwerkbedingt oder Jitterbit-spezifisch ist.

MySQL: „Enable Batch" verbessert die Insert- oder Update-Leistung nicht

  • Symptom: Eine Database Insert- oder Update-Aktivität mit dem MySQL JDBC-Treiber zeigt wenig oder keine Leistungsverbesserung nach Aktivierung von Enable Batch, auch bei einer großen Anzahl von Datensätzen.
  • Mögliche Ursache: Der MySQL JDBC-Treiber (Connector/J) sendet standardmäßig unabhängig von Enable Batch eine Anweisung pro Zeile statt eines echten serverseitigen Batches.
  • Lösung: Fügen Sie im Feld Additional Connection String Parameters der Verbindung rewriteBatchedStatements=true hinzu.

MySQL: ODBC-Treiber wird nicht in der Studio-Dropdown angezeigt

  • Symptom: Beim Konfigurieren einer Datenbankverbindung zu MySQL mit einem ODBC-Treiber auf einem privaten Agent wird der installierte Treiber nicht in der Dropdown Treiber in Studio angezeigt.
  • Mögliche Ursache: Der ODBC-Manager auf dem Host des privaten Agents zeigt den Treiber nicht an, normalerweise aufgrund eines 32-Bit- vs. 64-Bit-Konflikts oder einer unvollständigen Treiberinstallation.
  • Lösung:
    • Öffnen Sie auf dem Host des privaten Agents (Windows) die Anwendung Datenquellen (ODBC) (unter Verwaltung) und bestätigen Sie, dass der MySQL ODBC-Treiber aufgelistet ist. Weitere Optionen für den MySQL-Treiber finden Sie unter Mit MySQL verbinden.
    • Bestätigen Sie, dass der Agent eine Verbindung zum korrekten Computer herstellt: Der ODBC-Treiber muss auf dem Agent-Host installiert sein, nicht auf dem Computer des Studio-Benutzers.

PostgreSQL: Fehler beim Client-Encoding-Mismatch

  • Symptom: Ein Verbindungstest mit einem Datenbankconnector zu PostgreSQL schlägt mit dem Fehler „Client-Encoding-Mismatch" fehl.
  • Mögliche Ursache: Das Encoding, das der PostgreSQL-Server verwendet, unterscheidet sich vom Standard-Encoding, das der PostgreSQL ODBC-Treiber voraussetzt.
  • Lösung:
    • Fügen Sie in den Datenbankverbindungseinstellungen ConnSettings=SET CLIENT_ENCODING to 'LATIN1' (mit dem tatsächlichen Encoding des Servers ersetzen) zum Feld Zusätzliche Verbindungszeichenfolgenparameter hinzu.
    • Wenn der Server unter Windows ein kyrillisches Encoding wie WIN1251 verwendet, legen Sie das Client-Encoding auch in den ODBC-Treibereinstellungen auf WIN1251 fest.

PostgreSQL: Verwenden Sie den von Jitterbit bereitgestellten Treiber unter Linux

  • Symptom: Operationen, die den Datenbankconnector verwenden, um sich von einem privaten Linux-Agent mit PostgreSQL zu verbinden, schlagen fehl oder verursachen Fehler, auch wenn ein Treiber installiert zu sein scheint.
  • Mögliche Ursache: Viele Linux-Distributionen enthalten einen PostgreSQL ODBC-Treiber, der mit unixODBC paketiert ist und nicht zuverlässig mit Harmony funktioniert.
  • Lösung: Verwenden Sie nicht den vom Distributor gepackten PostgreSQL-Treiber. Verwenden Sie stattdessen den PostgreSQL ODBC-Treiber, der in der Jitterbit-Agent-Installation gebündelt ist.

SQL Server JDBC: Windows-Authentifizierung schlägt fehl

  • Symptom: Bei privaten Agents schlägt eine Datenbankverbindung zu SQL Server mit einem JDBC-Treiber und Windows-Authentifizierung fehl mit:

    This driver is not configured for integrated authentication. ClientConnectionId:...

    Bei Verwendung des SQL Server MS JDBC-Treibers können die Agent-Protokolle auch Folgendes anzeigen:

    java.lang.UnsatisfiedLinkError: no mssql-jdbc_auth-8.2.0.x64 in java.library.path

  • Mögliche Ursachen:

    • Verwendung des SQL Server jTDS-Treibers: Die Datei ntlmauth.dll, die für die Windows-Authentifizierung erforderlich ist, fehlt im JRE-Verzeichnis, das der Jitterbit-Agent zur Laufzeit verwendet.
    • Verwendung des SQL Server MS JDBC-Treibers oder eines neueren Microsoft JDBC Driver für SQL Server: Die DLL mssql-jdbc_auth, die für die Windows-Authentifizierung erforderlich ist, fehlt in den JRE-Verzeichnissen, die der Jitterbit-Agent zur Laufzeit verwendet. Es reicht nicht aus, die DLL in dasselbe Verzeichnis wie die JDBC-JAR-Datei zu platzieren.
    • Die Verbindungszeichenfolge enthält nicht die erforderlichen Parameter für Ihren Treiber.

  • Lösung: Wählen Sie die Option, die zu Ihrem JDBC-Treiber passt:

    • SQL Server jTDS:
      1. Kopieren Sie auf dem Host des privaten Agenten ntlmauth.dll (aus dem Ordner x64/SSO des jTDS-Projektdownload-Pakets) in <JITTERBIT_HOME>/jre/bin.
      2. Fügen Sie in den Datenbankverbindungseinstellungen integratedSecurity=true zum Feld Additional Connection String Parameters hinzu.
      3. Starten Sie den Jitterbit-Agent-Dienst neu.
    • SQL Server MS JDBC oder ein neuerer Microsoft JDBC Driver für SQL Server:
      1. Kopieren Sie auf dem Host des privaten Agenten mssql-jdbc_auth-x.x.x.x64.dll (aus der JDBC-Treiberverteilung, mit der Version, die mit der in Ihrem Agent gebündelten JDBC-JAR-Datei übereinstimmt) in beide Verzeichnisse: <JITTERBIT_HOME>/jre/bin und <JITTERBIT_HOME>/jre/lib. Sichern Sie die Datei, da diese bei größeren Agent-Updates entfernt werden kann.
      2. Fügen Sie in den Datenbankverbindungseinstellungen integratedSecurity=true;trustServerCertificate=true zum Feld Additional Connection String Parameters hinzu.
      3. Starten Sie den Jitterbit-Agent-Dienst neu.

SQL Server Windows-Authentifizierung: Unzureichende Berechtigungen

  • Symptom: Eine Datenbankverbindung mit SQL Server Windows-Authentifizierung schlägt fehl, selbst wenn die Domänenkreditdaten richtig zu sein scheinen.
  • Mögliche Ursache: Der Windows-Domänenbenutzer, der den Jitterbit-Agent-Dienst ausführt, verfügt nicht über die erforderlichen Berechtigungen auf Betriebssystemebene für Windows Integrated Security.
  • Lösung:
    1. Erteilen Sie dem Domänenbenutzer die Windows-Berechtigungen Anmelden als Dienst und Fungieren als Teil des Betriebssystems auf dem Host des privaten Agenten.
    2. Bestätigen Sie, dass der Domänenbenutzer Lese- und Schreibberechtigungen für das Jitterbit-Agent-Installationsverzeichnis hat.
    3. Starten Sie den Jitterbit-Agent-Dienst neu, nachdem Sie die Berechtigungen angewendet haben.

SQL Server: „Cannot insert explicit value for identity column" beim Einfügen in eine Identitätsspalte

  • Symptom: Ein Database Connector-Vorgang, der in eine SQL Server-Tabelle mit einer Identitätsspalte schreibt, schlägt mit folgender Meldung fehl:

    Database Error: Cannot insert explicit value for identity column in table '<table>' when IDENTITY_INSERT is set to OFF.

  • Mögliche Ursache: Die Identitätsspalte ist in der INSERT-Anweisung enthalten, die der Database Connector für das Ziel generiert. SQL Server lehnt ein INSERT ab, das auf eine Identitätsspalte in ihrer Spaltenliste verweist (mit einem expliziten Wert oder einem Nullwert), während IDENTITY_INSERT auf OFF gesetzt ist. Das Zuordnen des Felds zu einem Nullwert schließt es nicht aus: Ein Zielfeld wird nur aus dem INSERT weggelassen, wenn es mit der Funktion Unmap zugeordnet ist.

  • Lösung:

    • Damit SQL Server den Identitätswert automatisch zuweist, schließen Sie die Spalte aus dem INSERT aus, indem Sie das Identitätszielfeld mit der Funktion Unmap zuordnen. Um die Spalte nur auszuschließen, wenn die Quelle keinen Wert bereitstellt, verwenden Sie eine bedingte Zuordnung:

      If($source.id != "", $source.id, Unmap())

      Wenn die Bedingung „false" ist, entfernt Unmap die Spalte aus dem INSERT und SQL Server weist den nächsten Identitätswert zu. (Das Bereitstellen eines expliziten Werts im „true"-Zweig erfordert dennoch, dass IDENTITY_INSERT ON ist; siehe die nächste Option.)

    • Wenn Sie explizite Werte in die Identitätsspalte einfügen müssen, setzen Sie IDENTITY_INSERT auf der Zieltabelle in Pre- und Post-SQL-Skripten innerhalb der Aktivität:

SET IDENTITY_INSERT <table> ON;

SET IDENTITY_INSERT <table> OFF;

Verwenden Sie diese Option nur, wenn Sie absichtlich Identitätswerte von außerhalb der Datenbank steuern möchten. Sie ermöglicht das Einfügen expliziter Werte in die Identitätsspalte.

SQL Server: Verbindung schlägt mit PKIX-Zertifikatpfadfehler fehl

  • Symptom: Eine Datenbankverbindung zu SQL Server schlägt fehl mit:

    "encrypt" property is set to "true" and "trustServerCertificate" property is set to "false" but the driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption: Error: (certificate_unknown) PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.

    Eine Verbindung, die zuvor funktioniert hat, kann nach einem Agent-Upgrade auf Version 12.8 oder später zu fehlschlagen beginnen.

  • Mögliche Ursache: Aktuelle Versionen des SQL Server MS JDBC-Treibers fordern standardmäßig eine verschlüsselte Verbindung an und validieren das Zertifikat, das der Datenbankserver präsentiert. Die Verbindung schlägt fehl, wenn dieses Zertifikat nicht auf eine Zertifizierungsstelle (CA) zurückgeführt werden kann, der der Agent bereits vertraut, wie etwa ein selbstsigniertes Zertifikat, ein intern ausgestelltes Zertifikat oder das Amazon RDS CA-Zertifikat, das eine Amazon RDS for SQL Server-Instanz präsentiert. Dies ist ein Fehler beim Zertifikatsvertrauen und nicht bei der Verschlüsselung, daher kann eine Datenbank Verschlüsselung aktiviert haben und ein gültiges Zertifikat installiert haben und trotzdem fehlschlagen. Agent-Version 12.8 hat den gebündelten Treiber auf eine Version aktualisiert, die standardmäßig Verschlüsselung anfordert, daher kann eine Verbindung, die vor diesem Upgrade konfiguriert wurde, danach fehlschlagen.

  • Lösung: Geben Sie encrypt=false; im Feld Zusätzliche Verbindungszeichenfolgenparameter unter Optionale Einstellungen der Datenbankverbindung ein, oder fügen Sie es in eine manuelle Verbindungszeichenfolge ein. Dies funktioniert auf Cloud- und Private Agents. Weitere Informationen finden Sie unter Verbindungsverschlüsselung und Serverzertifikate.

    Vorsicht

    Bei encrypt=false werden Daten zwischen dem Agent und der Datenbank unverschlüsselt übertragen. Verwenden Sie diese Option nur in Fällen, in denen dies für die beteiligten Daten und den Netzwerkpfad akzeptabel ist.

EDI for Cloud v2 Connector

Einträge zur Fehlerbehebung für den EDI for Cloud v2-Connector finden Sie im EDI-Fehlerbehebungshandbuch, zusammen mit Jitterbit EDI-Problemen. Relevante Einträge sind:

Email-Connector

Gmail-Verbindungstest schlägt mit Authentifizierungsfehler fehl

  • Symptom: Ein Verbindungstest zu einem Gmail-Konto mit Basic Auth schlägt mit einem Authentifizierungsfehler fehl, auch wenn das korrekte Google-Kontopasswort eingegeben wird.
  • Mögliche Ursache: Google erfordert ein App-Passwort für Konten mit aktivierter 2-Schritte-Verifizierung. Das Google-Kontopasswort wird von SMTP oder IMAP nicht akzeptiert, wenn die 2-Schritte-Verifizierung aktiv ist. Nur App-Passwörter werden akzeptiert.
  • Lösung:
    1. Generieren Sie in Ihrem Google-Konto ein App-Passwort für die Jitterbit-Anwendung (siehe die Mit App-Passwörtern anmelden-Seite von Google).
    2. Geben Sie in der Email-Verbindungskonfiguration in Studio das App-Passwort im Feld SMTP-Passwort und/oder IMAP-Passwort ein, anstelle des Google-Kontopassworts.

S/MIME-Signierung schlägt fehl oder wird von Cloud-E-Mail-Anbietern abgelehnt

  • Symptom: E-Mails, die mit S/MIME-Signierung konfiguriert sind, können nicht versendet werden, werden vom Server des Empfängers abgelehnt oder kommen unsigniert an, wenn ein Cloud-E-Mail-Anbieter wie Microsoft 365 oder Exchange Online verwendet wird.
  • Mögliche Ursachen:
    • Cloud-Anbieter erfordern ein S/MIME-Zertifikat, das von einer vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt wurde. Selbstsignierte Zertifikate werden von Cloud-Anbietern wie Microsoft 365 (Exchange Online) nicht akzeptiert.
    • S/MIME funktioniert nur bei Verwendung von privaten Agenten. Wenn der Vorgang auf einem Cloud-Agent ausgeführt wird, wird die S/MIME-Signierung unabhängig vom Zertifikattyp nicht angewendet.
  • Lösung:
    1. Besorgen Sie sich ein S/MIME-Zertifikat von einer vertrauenswürdigen CA. Let's Encrypt stellt kostenlose Zertifikate zur Verfügung, die von großen Cloud-Anbietern akzeptiert werden.
    2. Ersetzen Sie das selbstsignierte Zertifikat in der E-Mail-E-Mail versenden-Aktivität durch das von der CA ausgestellte Zertifikat (siehe Voraussetzungen für S/MIME-Verschlüsselung).
    3. Bestätigen Sie bei privaten Agenten, dass das Zertifikat korrekt im Standard-Truststore des Agenten importiert ist. Bei Cloud-Agenten wird die S/MIME-Signierung nicht unterstützt.

Microsoft 365-E-Mail-Verbindung mit ROPC-Authentifizierung schlägt fehl, wenn MFA aktiviert ist

  • Symptom: Eine Microsoft 365 OAuth 2.0-Verbindung, die den Grant „Resource Owner Password Credentials" (ROPC) verwendet, kann nicht authentifiziert werden, auch wenn Benutzername, Passwort, Client-ID, Mandanten-ID und Client-Geheimnis alle korrekt sind.
  • Mögliche Ursache: Die ROPC-Authentifizierung erfordert, dass die Multi-Faktor-Authentifizierung (MFA) für die Microsoft 365-Anmeldedaten, die mit dem Connector verwendet werden, deaktiviert ist. Der ROPC-Grant kann keine MFA-Herausforderung erfüllen, daher schlägt die Token-Anforderung fehl, wenn eine MFA-Richtlinie für das Konto gilt.
  • Lösung:
    • Verwenden Sie ein Microsoft 365-Konto, dessen Anmeldedaten nicht einer MFA-Richtlinie unterliegen. Um die Sicherheit zu gewährleisten, erstellen Sie einen dedizierten Microsoft Entra ID-Mandanten oder ein Verzeichnis, das keine MFA erzwingt, wie unter Voraussetzungen für Microsoft 365 beschrieben.
    • Wenn MFA nicht aus dem Konto entfernt werden kann, verwenden Sie stattdessen eine andere unterstützte Authentifizierungsmethode für die Verbindung als ROPC.

E-Mail versenden schlägt fehl, wenn dieselbe Adresse in mehreren Empfängerfeldern vorkommt

  • Symptom: Eine E-Mail-E-Mail versenden-Aktivität schlägt zur Laufzeit fehl, wenn dieselbe E-Mail-Adresse in mehr als einem der Felder An, CC oder BCC vorhanden ist.
  • Mögliche Ursache: Der E-Mail-Connector gestattet nicht, dass dieselbe Adresse in mehreren Empfängerfeldern in einer einzelnen Versendanforderung vorkommt. Dies gilt für Adressen, die direkt in der Aktivität konfiguriert sind, und für Adressen, die dynamisch durch eine Transformationszuordnung bereitgestellt werden.
  • Lösung:
    • Überprüfen Sie die Felder An, CC und BCC in der Aktivitätskonfiguration und in allen Transformationszuordnungen für die Aktivität, um sicherzustellen, dass keine Adresse in mehreren Feldern vorkommt.
    • Wenn Empfängerlisten dynamisch mit Variablen oder Scripts zusammengestellt werden, fügen Sie eine Deduplizierungsprüfung hinzu, bevor Sie Adressen an die Aktivität übergeben.

Epicor-Konnektoren

Epicor Prophet 21: Vorgang schlägt zur Laufzeit mit mehreren Filterbedingungen fehl

  • Symptom: Eine Epicor Prophet 21 Query-Aktivität schlägt zur Laufzeit fehl, wenn die Filter String mehr als eine Filterbedingung enthält, obwohl die Aktivität in Studio gültig erscheint.
  • Mögliche Ursache: Eine Limitation der Epicor Prophet 21 Middleware API verhindert die Verarbeitung mehrerer Filterbedingungen. Der Vorgang erscheint in Studio gültig, schlägt aber zur Laufzeit fehl, wenn mehr als ein Filter vorhanden ist.
  • Lösung:
    • Reduziere die Filter String auf eine einzelne Filterbedingung.
    • Falls mehrere Filterbedingungen erforderlich sind, rufe einen breiteren Ergebnissatz mit einem einzelnen Filter ab und wende die zusätzliche Filterung in einem Transformations- oder Skriptschritt nach der Aktivität an.

Datei-Konnektoren

FTP, Dateifreigabe und lokaler Speicher: „Keine Dateien stimmen mit dem Dateifilter überein" bei Archiv- oder Folgschritten

  • Symptom: Eine FTP, Dateifreigabe oder lokaler Speicher-Lesaktivität schlägt fehl, weil sich die Datei, die gelesen werden soll, nicht mehr im Quellpfad befindet:

    Failed to read file from the source "Read". Reason: No files match the file filter "<filter>".

    Die Aktivität, die die Datei zuvor verarbeitet hat, war erfolgreich; der Fehler tritt in einem späteren Schritt auf (häufig ein Archiv- oder Benachrichtigungsschritt), der versucht, dieselbe Datei mit demselben Filter zu lesen.

  • Mögliche Ursachen:

    • Die Verarbeitungsaktivität hat die Quelldatei bereits als Teil des Verhaltens Nach Verarbeitung verschoben oder gelöscht, sodass der Archivschritt keine Übereinstimmung findet.
    • Ein untergeordneter Vorgang wird asynchron gestartet und der übergeordnete Vorgang versucht, die Ausgabedatei des untergeordneten Vorgangs zu lesen, bevor dieser das Schreiben abgeschlossen hat.
    • Eine FTP-Schreibaktivität mit aktiviertem FTP-Umbenennung verwenden (Standard) schreibt die Datei unter einem temporären Namen und benennt sie nach Abschluss in den endgültigen Namen um. Ein nachgelagerter Lesevorgang, der vor Abschluss der Umbenennung ausgelöst wird, findet die Datei nicht.
  • Lösung:
    • Überprüfe, ob der vorherige Schritt bereits über seine integrierten Optionen Nach Verarbeitung (verschieben, umbenennen, löschen) archiviert hat. Falls ja, ist ein separater Archivschritt überflüssig und sollte entfernt werden.
    • Falls ein separater Archivschritt erforderlich ist, gestalte die Kette neu, damit Verarbeitung und Archivierung mit derselben In-Memory-Dateireferenz stattfinden, anstatt erneut von der Quelle zu lesen. Übergebe den gelesenen Inhalt beispielsweise über den temporären Speicher an den Archivschritt, anstatt den Quellpfad erneut zu lesen.
    • Falls ein Folgschritt die von einem untergeordneten Vorgang erzeugte Ausgabe liest, führe den untergeordneten Vorgang synchron aus, damit seine Ausgabe vor dem Lesen vorhanden ist. Stelle den Run type des Invoke Operation-Tools auf Synchronously ein, oder führe beim Aufrufen des Vorgangs aus einem Skript RunOperation synchron aus (Standard). Das Einfügen einer festen Verzögerung (z. B. mit der Sleep-Funktion) erhöht die Latenz und garantiert nicht, dass die Datei bereit ist.
    • Falls eine FTP-Schreibaktivität am selben Speicherort schreibt, überprüfe, ob FTP-Umbenennung verwenden in der FTP Write-Aktivität aktiviert ist. Falls der nachgelagerte Lesevorgang vor Abschluss der Umbenennung ausgelöst wird, deaktiviere FTP-Umbenennung verwenden in der Schreibaktivität, oder stelle sicher, dass der Lesevorgang erst ausgeführt wird, nachdem die Schreibaktivität vollständig abgeschlossen ist.

FTP, File Share und Local Storage: Fehlerordner wird bei Verbindungsfehler nicht geschrieben

  • Symptom: Nachdem eine FTP-, File Share- oder Local Storage-Aktivität fehlschlägt, wird keine Datei im konfigurierten Fehlerordner angezeigt.
  • Mögliche Ursache: Der Fehlerordner dient zum Archivieren einer Kopie der Quelldatei nach fehlgeschlagener Verarbeitung und erfasst Dateien nur, wenn die Aktivität ausgeführt wird und anschließend fehlschlägt (z. B. ein Schreibzugriffsfehler auf dem Server). Wenn die Verbindung zum Server überhaupt nicht hergestellt werden kann, schlägt der Vorgang fehl, bevor die Aktivität eine Datei liest. Es gibt daher keine Datei, die in den Fehlerordner geschrieben werden kann.
  • Lösung:
    • Falls der Fehlerordner nach einem Fehler leer ist, überprüfen Sie die Operationsprotokolle auf einen Verbindungsfehler (z. B. einen Authentifizierungsfehler oder eine „Host nicht erreichbar"-Meldung).
    • Verwenden Sie die Test-Schaltfläche für die Verbindung, um zu bestätigen, ob das Problem auf Netzwerk- oder Authentifizierungsebene auftritt.

FTP, File Share und Local Storage: Dateiname-Schlüsselwörter werden in Erfolgs- und Fehlerordnerpfaden nicht aufgelöst

  • Symptom: Vorgänge verschieben Dateien nach der Verarbeitung in Erfolgs- oder Fehlerordner, aber der Zielpfad enthält nicht erweiterte Schlüsselworttexte anstelle von aufgelösten Werten. Der Vorgang kann fehlschlagen oder Dateien an unerwartete Speicherorte schreiben.
  • Mögliche Ursachen:
    • Die Felder „Erfolgsordner" und „Fehlerordnerpfad" in FTP-, File Share- und Local Storage-Aktivitäten unterstützen keine Dateiname-Schlüsselwortersetzung. Variablen werden in diesen Feldern nicht erweitert.
    • Diese Felder verweisen auf Verzeichnisse auf dem Private-Agent-Computer, nicht auf dem Remote-Server. Relative Pfade werden relativ zum Dateisystem des Agent-Hosts interpretiert.
  • Lösung:
    • Verwenden Sie nur Literalpfade (ohne Dateiname-Schlüsselwortvariablen) für die Erfolgs- und Fehlerordnerfelder.
    • Falls dynamische Pfade erforderlich sind, fügen Sie nach der Aktivität einen Skriptschritt hinzu, um die verarbeitete Datei mithilfe von Dateifunktionen an den beabsichtigten Speicherort zu verschieben oder umzubenennen.

FTP, File Share, Local Storage und Temporary Storage: „Überschriften schreiben" erstellt keine nur-Header-Datei, wenn die Quelle keine Datensätze zurückgibt

  • Symptom: Eine dateibasierte Schreibaktivität mit aktivierter Option Überschriften schreiben (FTP Write, File Share Write, Local Storage Write oder Temporary Storage Write) schreibt keine Überschriften, wenn die Quelle keine Datensätze zurückgibt. Es wird entweder eine leere Datei erstellt oder gar keine Datei (falls Leere Dateien nicht erstellen ebenfalls ausgewählt ist).
  • Ursache: Dies ist das erwartete Verhalten. Überschriften werden als Teil der Transformationsausgabe geschrieben und die Transformation wird nur ausgeführt, wenn die Quelle mindestens einen Datensatz zurückgibt. Wenn die Quelle keine Datensätze zurückgibt, wird die Transformation übersprungen, es werden keine Ausgaben geschrieben (einschließlich Überschriften), und Studio protokolliert eine Warnung, dass die Quelle leer ist. Dies ist nicht spezifisch für einen bestimmten Quell-Connector oder ein Flatfile-Ziel.

FTP: Vorgang schlägt nach vielen schnellen Anmeldungen beim gleichen Server fehl

  • Symptom: Ein Vorgang, der den FTP-Connector verwendet (über FTP- oder SFTP-Protokoll) und sich in schneller Folge mehrfach beim gleichen Server authentifiziert (beispielsweise beim Lesen von Hunderten kleiner Dateien in einer Schleife oder bei vielen Vorgängen, die zeitgesteuert gegen denselben Server laufen), schlägt schließlich mit einer Anmeldungsverweigerung oder einem Verbindungsfehler fehl. Der gleiche Vorgang funktioniert unter geringerer Last.
  • Mögliche Ursachen:
    • Der FTP-Connector öffnet und authentifiziert eine neue Verbindung für jede Aktivitätsausführung und schließt sie, wenn der Vorgang endet; eine Sitzung wird nicht über Aktivitäten hinweg, über Vorgangsläufe hinweg oder über Projekte hinweg wiederverwendet. Dies ist beabsichtigt. Wenn viele Vorgänge gegen denselben Server laufen, beispielsweise mehrere zeitgesteuerte Vorgänge oder mehrere Projekte auf denselben Host, authentifiziert sich jeder Lauf unabhängig.
    • Der Remote-Server ist mit einer maximalen Anzahl von Verbindungen, Authentifizierungen pro Minute oder gleichzeitigen Sitzungen pro Benutzer konfiguriert, und die kombinierte Jitterbit-Anmeldungsrate überschreitet diesen Grenzwert.
  • Lösung:
    • Gestalten Sie den Vorgang nach Möglichkeit neu, um weniger Verbindungen herzustellen. Ersetzen Sie eine Read-Aktivität in einer Schleife durch eine einzelne Read-Aktivität, die einen Platzhalter im Feld Get Files verwendet (beispielsweise *.xml oder data_*.csv), und teilen Sie die abgerufenen Daten dann in einer Transformation in einzelne Datensätze auf.
    • Wenn der Vorgang Dateien einzeln verarbeiten muss, bitten Sie den FTP-Server-Administrator, das Limit für gleichzeitige Verbindungen oder Authentifizierungen pro Minute pro Benutzer zu erhöhen.

SFTP „Login denied. Authentication failure." bei Verwendung von SSH-Schlüsseln

  • Symptom: Ein SFTP-Vorgang mit SSH-Authentifizierung mit privatem Schlüssel schlägt mit Login denied. Authentication failure. fehl, obwohl sich die gleichen Schlüssel erfolgreich von einem interaktiven SFTP-Client aus authentifizieren.

    Failed to get ftp directory list for url sftp://example.com:22/. Login denied. Authentication failure.

  • Mögliche Ursachen:

    • Der private Schlüssel ist durch eine Passphrase geschützt, aber die PrivateKeyPassphrase-Einstellung fehlt im [SSH]-Abschnitt der Datei jitterbit.conf des Agenten.
    • Im FTP-Endpoint ist ein Passwort zusammen mit dem privaten Schlüssel konfiguriert. Das Vorhandensein eines Passworts in den Endpoint-Einstellungen beeinträchtigt die schlüsselbasierte Authentifizierung.

  • Lösung:

    • Bestätigen Sie für private Agenten, dass der [SSH]-Abschnitt von jitterbit.conf den korrekten PrivateKeyFile-Pfad und, falls der Schlüssel durch eine Passphrase geschützt ist, den entsprechenden PrivateKeyPassphrase-Wert enthält (siehe Verbindung zu SFTP mit SSH-Schlüsseln).
    • Löschen Sie in der FTP-Endpoint-Konfiguration das Feld Password, wenn die Authentifizierung über SSH-Schlüssel erfolgt.
    • Bestätigen Sie, dass der Schlüssel in einem vom Agent unterstützten Format vorliegt (OpenSSH). Konvertieren Sie den Schlüssel mit ssh-keygen, falls er im PuTTY- (.ppk) oder einem anderen Nicht-OpenSSH-Format vorliegt.

FTP Write: „Use FTP Rename" schlägt beim Schreiben auf einen SFTP-Server fehl

  • Symptom: Eine FTP-Aktivität Write mit der Option Use FTP Rename schlägt fehl, wenn das Ziel ein SFTP-Server ist, mit einer Fehlermeldung ähnlich wie:

    Failed to put ... to the url ...
Quote command returned error. Rename command failed: <reason>.

    Der <reason> ist typischerweise No such file or directory oder Permission denied für eine Datei, deren Name Mehrbyte-Zeichen enthält.

  • Mögliche Ursachen:

    • Bei Agenten vor Version 11.56 hat die Option Use FTP Rename den Umbenennungsschritt beim Schreiben auf einen SFTP-Server nicht zuverlässig berücksichtigt, besonders bei archive pattern-Vorgängen.

  • Der Dateiname enthält Multibyte-Zeichen und der SFTP-Server unterstützt das Umbenennen von Dateien mit solchen Namen nicht. Ab Agent-Version 12.8 kann der FTP-Connector Dateien mit Multibyte-Namen lesen und schreiben. Bei aktivierter Option Use FTP Rename lädt der Agent die Datei jedoch unter einem temporären Namen (mit dem Suffix -jbupload) hoch und benennt sie dann um. Kann der Server den Multibyte-Namen nicht umbenennen, wird eine irreführende Fehlermeldung Permission denied zurückgegeben. Dateinamen, die nur ASCII-Zeichen enthalten, sind nicht betroffen. Dies ist eine Beschränkung des SFTP-Servers und nicht von Jitterbit.

  • Lösung:

    • Stellen Sie sicher, dass der Agent mindestens Version 11.56 ist, in der Use FTP Rename mit SFTP erwartungsgemäß funktioniert. Cloud-Agenten werden automatisch aktualisiert; führen Sie bei privaten Agenten bei Bedarf ein Upgrade durch.

    • Deaktivieren Sie das Kontrollkästchen Use FTP Rename in der Aktivitätskonfiguration, damit der Agent direkt in den Zielordner schreibt, anstatt unter einem temporären Namen hochzuladen und umzubenennen. Dadurch entfällt der Umbenennungsschritt und beide Ursachen werden behoben.

    • Verwenden Sie im Fall von Multibyte-Zeichen alternativ einen SFTP-Server, der das Umbenennen von Dateien mit Multibyte-Zeichen im Namen unterstützt.

SFTP: Anhängen an Datei nicht unterstützt

  • Symptom: Eine FTP-Write-Aktivität, die mit der Option Append To File konfiguriert ist, hängt nichts an die vorhandene Datei an, wenn das Ziel ein SFTP-Server ist.
  • Mögliche Ursache: Das SFTP-Protokoll unterstützt das Anhängen an vorhandene Dateien nicht. Dies ist eine Einschränkung auf Protokollebene und kein Jitterbit-Konfigurationsproblem.
  • Lösung:
    • Verwenden Sie FTP oder FTPS, wenn das Anhängen erforderlich ist.
    • Wenn SFTP erforderlich ist, implementieren Sie die Anhängungslogik manuell: Lesen Sie den vorhandenen Dateiinhalt, kombinieren Sie ihn mit den neuen Daten und schreiben Sie das komplette Ergebnis als vollständige Datei zurück.

FTP: Dateinamen mit # werden nicht korrekt verarbeitet

  • Symptom: Eine FTP-Connector-Aktivität (über FTP oder SFTP-Protokoll) schlägt fehl, wenn der Quell- oder Zieldateiname ein Hash-Zeichen (#) enthält. Das Lesen der Datei gibt einen Fehler wie No File with that name oder Error in SSH Layer zurück, und das Schreiben der Datei führt zu einem abgekürzten Dateinamen.
  • Mögliche Ursache: Der FTP-Connector behandelt den Dateipfad als URL, bei der das Hash-Zeichen ein reserviertes Fragment-Trennzeichen ist. Der Connector analysiert den Teil des Pfads vor # und verwirft den Rest.
  • Lösung:
    • Benennen Sie die Dateien um, um das #-Zeichen zu entfernen oder zu ersetzen, bevor Jitterbit sie liest oder schreibt.
    • Damit der Connector Namen mit Sonderzeichen wie # URL-kodiert, setzen Sie jitterbit.source.ftp.encode_url in einem Transformationsskript auf true für Quelldatei- oder -ordnernamen und jitterbit.target.ftp.encode_url auf true für in das Ziel geschriebene Dateien.

File Share: UNC-Pfade mit Servernamen schlagen auf Cloud-Agenten fehl

  • Symptom: File Share-Verbindungen, die UNC-Pfade verwenden (z. B. \\server\share), können sich nicht verbinden, wenn der Vorgang auf einem Cloud-Agent ausgeführt wird.
  • Mögliche Ursache: Cloud-Agenten können UNC-Pfade mithilfe einer öffentlichen IP-Adresse auflösen, können aber Servernamen in UNC-Pfaden nicht auflösen.
  • Lösung:
    • Ersetzen Sie den Servernamen im UNC-Pfad durch die öffentliche IP-Adresse des Servers (z. B. \\192.0.2.1\share).
    • Wenn die Servernamensauflösung in UNC-Pfaden erforderlich ist, verwenden Sie stattdessen einen privaten Agent.

File Share: Dateien größer als 2 GB können nicht abgerufen werden

  • Symptom: Eine File Share Read-Aktivität kann einzelne Dateien größer als 2 GB möglicherweise nicht abrufen. Kleinere Dateien werden ohne Probleme abgerufen.
  • Mögliche Ursache: Der File Share-Connector hat eine bekannte Einschränkung bei einzelnen Dateien größer als 2 GB.
  • Lösung: Es gibt keine Konfigurationsoption, die dieses Limit aufhebt. Teilen Sie die Datei zur Problemlösung in kleinere Segmente auf der Quelle auf, sodass jede Datei vor dem Abrufen durch die File Share Read-Aktivität kleiner als 2 GB ist.

Local Storage: Nicht auf Cloud-Agenten verfügbar

  • Symptom: Ein Vorgang mit einem Local Storage-Connector schlägt fehl, wenn er auf einem Cloud-Agent ausgeführt wird.
  • Mögliche Ursache: Local Storage greift auf das Dateisystem des Computers zu, auf dem der Agent installiert ist. Cloud-Agenten werden in einer gehosteten Umgebung ausgeführt und stellen zu diesem Zweck kein lokales Dateisystem zur Verfügung.
  • Lösung:
    • Verwenden Sie Private Agents für alle Vorgänge, die den Local Storage-Connector benötigen. Local Storage ist auf Private Agents standardmäßig deaktiviert, also aktivieren Sie es auch in der Konfigurationsdatei des Private Agents (siehe Enable local file location).
    • Ersetzen Sie für Cloud Agent-Workflows Local Storage durch Temporary Storage oder einen externen Storage-Connector (File Share, FTP oder Cloud Datastore).

Temporary Storage: Dateien fehlen beim Lesen durch einen späteren Vorgang

  • Symptom: Temporary Storage-Dateien, die von einem Vorgang geschrieben werden, fehlen, wenn ein späterer Vorgang versucht, diese zu lesen.
  • Mögliche Ursachen:
    • Der Cleanup-Service von Harmony löscht standardmäßig nach 24 Stunden Dateien aus dem Temporary Storage.
    • Jeder Agent in einer Agent-Gruppe hat seinen eigenen lokalen Temporary Storage. Vorgänge in der gleichen Vorgangskette werden garantiert auf dem gleichen Agent ausgeführt, aber ein späterer Vorgang, der sich nicht in der gleichen Kette befindet, kann auf einen anderen Agent verteilt werden und auf eine andere Temporary Storage-Instanz zugreifen. Dadurch findet dieser die Datei nicht, unabhängig vom 24-Stunden-Fenster. Siehe Important notes.
  • Lösung:
    • Verbinden Sie Vorgänge, die Temporary Storage-Dateien gemeinsam nutzen müssen, mit der gleichen operation chain unter Verwendung von operation actions, wobei das Temporary Storage-Verhalten konsistent und zuverlässig ist.
    • Bei Private Agents kann die Cleanup-Häufigkeit im Bereich [FileCleanup] von jitterbit.conf angepasst werden. Siehe [FileCleanup].
    • Wenn Dateien nicht innerhalb der gleichen Kette verbraucht werden können oder länger als 24 Stunden bestehen bleiben müssen, verwenden Sie stattdessen einen persistenten Storage-Connector, der für alle Agenten erreichbar ist (z. B. File Share, FTP oder Cloud Datastore), anstelle von Temporary Storage.

Temporary Storage: Begrenzte Zeichen in Dateipfaden

  • Symptom: Eine Temporary Storage Read- oder Write-Aktivität schlägt fehl, wenn der Dateipfad bestimmte Sonderzeichen enthält.
  • Mögliche Ursache: Die folgenden Zeichen werden in Temporary Storage-Dateipfaden nicht unterstützt: ~, %, $, ", <, >, :, ?
  • Lösung:
    • Entfernen oder ersetzen Sie die nicht unterstützten Zeichen im Dateipfad. Die folgenden Zeichen werden unterstützt: !, @, #, ^, &, *, (, ), [, ], ', ;
    • Sowohl / als auch \ werden als Pfadtrennzeichen akzeptiert.

Temporary Storage: 50-GB-Dateisizenlimit bei Cloud-Agenten

  • Symptom: Eine Temporary Storage Write-Aktivität schlägt beim Schreiben großer Dateien über einen Cloud-Agenten fehl.
  • Mögliche Ursache: Cloud-Agenten erzwingen eine maximale Dateigröße von 50 GB pro Datei für Temporary Storage.
  • Lösung:
    • Verwenden Sie einen Private Agent für Workflows, die einzelne Dateien größer als 50 GB in Temporary Storage schreiben müssen.
    • Wenn nur Cloud-Agenten verfügbar sind, teilen Sie große Datenmengen vor dem Schreiben in Temporary Storage in mehrere Dateien kleiner als 50 GB auf.

HTTP-Connector

HTTP v2: Doppelter Authorization-Header verursacht 400 Bad Request

  • Symptom: HTTP v2 Connector-Vorgänge schlagen mit einem 400-Fehler fehl, wenn sowohl Authentifizierung auf Verbindungsebene als auch ein manuell definierter Authorization-Request-Header auf derselben Verbindung oder Aktivität konfiguriert sind.
  • Mögliche Ursache: Wenn die Authentifizierung auf einer HTTP v2-Verbindung konfiguriert ist (z. B. Basic oder OAuth), fügt der Connector automatisch einen Authorization-Header zu jeder Anfrage hinzu. Das Hinzufügen eines zweiten Authorization-Headers manuell führt zu zwei widersprüchlichen Headern, die die meisten Server mit einem 400-Fehler ablehnen.
  • Lösung:
    • Entfernen Sie alle manuell hinzugefügten Authorization-Header aus den Request-Headern in der Aktivitäts- oder Verbindungskonfiguration.
    • Verwenden Sie nur die integrierten Authentifizierungseinstellungen in der Verbindung für die Autorisierung. Fügen Sie keinen manuellen Authorization-Header neben der konfigurierten Authentifizierung hinzu.
    • Wenn Sie den Authorization-Header dynamisch auf Aktivitätsebene festlegen müssen, stellen Sie den Authentifizierungstyp der Verbindung auf No Auth ein und konfigurieren Sie den Authorization-Request-Header der Aktivität je nach Bedarf.

HTTP v2: JSON-Wert in einer Request-Header-Projektvariablen wird nicht geparst

  • Symptom: Eine HTTP v2-Aktivität, die einen Request-Header-Wert aus einer Projektvariablen mit einer JSON-Zeichenkette liest, schlägt mit einem Parse-Fehler fehl:

    Expected a ',' or ']' at 139 [character 140 line 1]

    Dieselbe JSON funktioniert, wenn sie direkt in die Spalte „Wert" der Tabelle Request Headers eingefügt wird.

  • Mögliche Ursache: Wenn ein Request-Header-Wert aus einer Projektvariablen gelesen wird, verarbeitet der HTTP v2 Connector die eingebetteten Anführungszeichen nicht auf die gleiche Weise wie bei direkter Eingabe des Werts in die Tabelle Request Headers. Die ungefügten Anführungszeichen unterbrechen die Header-Zeichenkette, bevor sie das Ziel erreicht.

  • Lösung:
    • Escapen Sie beim Speichern von JSON in einer Projektvariablen, die als Header-Wert verwendet wird, jedes doppelte Anführungszeichen mit einem Backslash. Speichern Sie z. B. den Wert als {\"success\": \"true\"} statt als {"success": "true"}.
    • Wenn der JSON-Inhalt statisch ist, fügen Sie ihn direkt in die Spalte „Wert" der Tabelle Request Headers ein, anstatt eine Variable zu verwenden. Der Connector wendet das erforderliche Escaping auf diesem Pfad an.

HTTP und HTTP v2: URL enthält mehrere ?-Zeichen

  • Symptom: Ein HTTP- oder HTTP v2-Vorgang schlägt beim Zielsystem fehl. Die Agent-Protokolle zeigen, dass die Anfrage-URL mehr als ein ? zwischen den Segmenten enthält, z. B. https://api.example.com/endpoint?param1=A?param2=B.
  • Mögliche Ursache: Abfrageparameter wurden an zwei Stellen deklariert: direkt an den URL-Pfad angehängt und auch zur Tabelle Request Parameters der Aktivität hinzugefügt. Der Connector verkettet beide Sätze und fügt ein zweites ? statt eines & ein.
  • Lösung:
    • Entfernen Sie alle Abfrage-String-Segmente aus dem URL-Pfad. Die Basis-URL sollte nur den Pfad selbst enthalten (z. B. https://api.example.com/endpoint).
    • Definieren Sie alle Abfrageparameter in der Tabelle Request Parameters der Aktivität. Der Connector fügt die Zeichen ? und & beim Konstruieren der endgültigen URL automatisch ein.

HTTP v2: Doppelte URL-Codierung, wenn „Encode request URL" aktiviert ist

  • Symptom: REST-API-Aufrufe über den HTTP v2-Connector schlagen beim Zielsystem fehl, da URL-Parameter in der ausgehenden Anfrage doppelt codiert sind (z. B. wird ein %20-Leerzeichen zu %2520).
  • Mögliche Ursache: Wenn Encode request URL in den HTTP v2-Verbindungseinstellungen aktiviert ist, codiert der Connector die gesamte URL vor dem Versenden. Wenn URL-Parameter bereits Prozentzeichen-codierte Zeichen enthalten, werden diese Zeichen ein zweites Mal codiert.
  • Lösung:
    • Deaktivieren Sie Encode request URL in den HTTP v2-Verbindungseinstellungen, wenn die URL oder Parameter bereits codiert sind oder mit der Funktion URLEncode konstruiert wurden.
    • Falls Encode request URL aktiviert bleiben muss, stellen Sie sicher, dass Parameter, die in die URL übergeben werden, nicht vorcodiert sind, bevor sie die Verbindung erreichen.

HTTP v2: Vorgang schlägt fehl, wenn Base URL umleitet

  • Symptom: Ein HTTP v2-Vorgang schlägt sofort fehl, wenn die konfigurierte Base URL eine Umleitungsantwort (3xx) zurückgibt.
  • Mögliche Ursache: Follow redirects ist in den HTTP v2-Verbindungseinstellungen deaktiviert, daher werden Umleitungsantworten als Fehler behandelt, statt automatisch befolgt zu werden.
  • Lösung: Aktivieren Sie in den HTTP v2-Verbindungseinstellungen Follow redirects, um dem Connector zu ermöglichen, Umleitungsantworten automatisch zur endgültigen Ziel-URL zu befolgen.

HTTP v2: Variablen im Aktivitätspfad werden nicht aufgelöst

  • Symptom: Eine HTTP v2-Aktivität verwendet eine globale, Projekt- oder Jitterbit-Variable in ihrem Feld Path, aber zur Laufzeit wird die Variable literal (unaufgelöst) gesendet, statt durch ihren Wert ersetzt zu werden.
  • Mögliche Ursache: Eine vollständige URL (eine, die das Protokoll und den Host enthält, z. B. https://api.example.com/...) wurde in das Feld Path eingegeben. Variablen werden in vollständigen URLs nicht unterstützt. Sie werden nur in einem partiellen Pfad aufgelöst, der an die Base URL der Verbindung angehängt wird.
  • Lösung:
    1. Legen Sie in der HTTP v2-Verbindung die Base URL auf den Protokoll- und Host-Anteil des Endpunkts fest (z. B. https://api.example.com).
    2. Geben Sie im Aktivitätsfeld Path nur den partiellen Pfad ein, der der Basis-URL folgt, und platzieren Sie die Variable in diesem partiellen Pfad (z. B. /records/[recordId]). Der Connector löst die Variable auf und hängt das Ergebnis zur Laufzeit an die Base URL an.

HTTP v2: Antwortstatus-Code nicht in Jitterbit-Variablen verfügbar

  • Symptom: Skripte, die Jitterbit-Quell- oder Zielvarablen auslesen, um den HTTP-Antwortstatus-Code nach Ausführung einer HTTP v2-Aktivität zu erfassen, erhalten keinen Wert. Der gleiche Ansatz funktioniert mit dem HTTP-Connector, aber nicht mit HTTP v2.
  • Mögliche Ursache: Der HTTP v2-Connector füllt Jitterbit-Quell- oder Zielvarablen nicht auf. Antwortdaten, einschließlich des HTTP-Status-Codes, werden stattdessen über das Antwortrschema der Aktivität zurückgegeben.
  • Lösung:
    • Zum Erfassen des Status-Codes mit dem Standard-Antwortrschema ordnen Sie das Feld statusCode zu, das sich unter dem Knoten responseItem/error der Antwort befindet und den HTTP-Status-Code enthält (z. B. 200, 403). Details zur Struktur des Antwortrschemas finden Sie in der Aktivitätskonfigurationsdokumentation für eine beliebige HTTP v2-Aktivität.
    • Zum Erfassen des Status-Codes bei Verwendung eines benutzerdefinierten Antwortrschemas aktivieren Sie Zusätzliche Eigenschaften aus HTTP-Antwort im Schema einbeziehen in der Aktivitätskonfiguration. Dies umhüllt das Schema mit einer von Jitterbit definierten Struktur, die __jitterbit_api_statuscode__ (den Status-Code) und __jitterbit_api_errorbody__ (den Antwortkörper für fehlgeschlagene Anfragen) enthält.
    • Damit der Status-Code verfügbar ist, wenn die API eine fehlgeschlagene Antwort zurückgibt, aktivieren Sie Betriebsfehler bei nicht erfolgreichem Status-Code ignorieren in den optionalen Einstellungen der Aktivität. Ohne diese Einstellung schlägt die Operation bei fehlgeschlagenen Antworten fehl, bevor die Antwortdaten zugeordnet werden können.

HTTP v2: XML-Namespaces werden bei Verwendung eines benutzerdefinierten Anforderungsschemas umgeschrieben

  • Symptom: Ein HTTP v2-Vorgang, der eine XML-Nutzlast an einen SOAP- oder XML-Webservice sendet, schlägt mit einem Serverfehler fehl (z. B. 500 Internal Server Error), obwohl die gleiche Nutzlast beim Senden von Postman oder SoapUI erfolgreich ist. Beim Untersuchen des Anforderungskörpers, der vom Ziel empfangen wird, wird angezeigt, dass XML-Namespace-Deklarationen auf das Root-Element konsolidiert wurden und die ursprünglichen Namespace-Präfixe durch generische ersetzt wurden (z. B. wird soapenv:Envelope zu Envelope xmlns="...", und Elementpräfixe werden als ns, ns1, ns2 neu nummeriert).
  • Mögliche Ursache: Wenn ein benutzerdefiniertes Anforderungsschema in der HTTP v2-Aktivitätskonfiguration verwendet wird, normalisiert die Transformation standardmäßig die XML, indem alle Namespace-Deklarationen auf den Root-Knoten verschoben und ihre Präfixe neu zugewiesen werden. SOAP-Services und andere XML-Endpunkte, die die Konsistenz von Namespace-Präfixen überprüfen, lehnen die geänderte Nutzlast ab.

  • Lösung:

    • Auf Agent-Version 12.8 oder später setzen Sie jitterbit.target.xml.preserve.namespace.prefix in einem Skriptschritt vor der Transformation auf true, um die Namespace-Präfixe der Quell-XML beizubehalten, anstatt generische Präfixe neu zuzuweisen:

      $jitterbit.target.xml.preserve.namespace.prefix = true;

    • Wenn Ihre privaten Agents älter als Version 12.8 sind oder wenn das Ziel auch die Konsolidierung von Namespace-Deklarationen auf dem Root-Element ablehnt, verwenden Sie das Standard-Anforderungsschema anstelle eines benutzerdefinierten und ordnen Sie die vollständige XML-Nutzlast als Zeichenfolge dem Feld body des Schemas zu. Die Nutzlast wird dann als Zeichenfolge behandelt und nicht geparst, daher bleiben ihre Namespace-Deklarationen erhalten. Das Antwortrschema kann weiterhin ein benutzerdefiniertes Schema sein.

HTTP v2: Leerzeichen werden als + statt %20 codiert

  • Symptom: REST-API-Aufrufe mit dem HTTP v2-Connector schlagen beim Zielsystem fehl, weil Leerzeichen in der URL als + statt %20 codiert werden, wodurch das Ziel einen Fehler „Ressource nicht gefunden" zurückgibt.
  • Lösung:
    • Aktivieren Sie in der HTTP v2-Verbindung die Option Anfrage-URL codieren. Der Connector codiert dann die Anfrage-URL und codiert Leerzeichen als %20.
    • Geben Sie die Anfrage-URL vollständig uncodiert an. Codieren Sie Zeichen nicht vor oder wenden Sie die Funktion URLEncode auf die URL an, da bereits codierte Zeichen doppelt codiert werden, wenn Anfrage-URL codieren aktiviert ist (beispielsweise wird example+string%20value zu example%20string%2520value).

HTTP: Sendet null als String "null"

  • Symptom: Eine HTTP-POST- oder PUT-Aktivität sendet Felder, die mit der Funktion Null zugeordnet sind, als String "null" (oder lässt sie aus), statt ein JSON-Literal null auszugeben. Dies tritt auf, wenn das Anforderungsschema für die Aktivität definiert ist.
  • Mögliche Ursache: Wenn das Anforderungsschema für die HTTP-Aktivität definiert ist, serialisiert der Connector ein zugeordnetes Null nicht als JSON-null. Wenn das Schema stattdessen in der Transformation definiert ist und für die Aktivität kein Anforderungsschema bereitgestellt wird, sendet der Connector ein zugeordnetes Null korrekt als JSON-null.
  • Lösung:
    • Migrieren Sie die Aktivität zum HTTP v2-Connector, der Null korrekt serialisiert. Jitterbit empfiehlt, bestehende HTTP-Verbindungen und -Aktivitäten zu HTTP v2 zu konvertieren.
    • Wenn die Aktivität bei HTTP bleiben muss, definieren Sie das Anforderungsschema in der Transformation statt in der Aktivität, und lassen Sie das Anforderungsschema der Aktivität ungesetzt. Mit dem in der Transformation definierten Schema serialisiert der Connector ein zugeordnetes Null korrekt zu einem JSON-null.

LDAP-Connector

LDAP Delete Entry schlägt fehl, wenn der Zieldatensatz untergeordnete Einträge hat

  • Symptom: Eine LDAP-Aktivität Delete Entry schlägt mit einem Fehler des LDAP-Servers fehl (beispielsweise notAllowedOnNonLeaf oder eine Meldung, die angibt, dass der Eintrag kein Blattknoten ist).
  • Mögliche Ursache: Das LDAP-Protokoll erlaubt nicht das Löschen eines Eintrags, der untergeordnete Einträge (Unterordnungen) hat. Der Eintrag muss ein Blattknoten ohne Kinder sein, damit das Löschen erfolgreich ist.
  • Lösung:
    • Löschen Sie vor dem Löschen des übergeordneten Eintrags zuerst alle untergeordneten Einträge. Durchsuchen Sie die Hierarchie von den tiefsten Einträgen nach oben.
    • Wenn das Löschen einer ganzen Substruktur erforderlich ist, implementieren Sie ein Skript, das Einträge von unten nach oben in der Struktur identifiziert und löscht, indem Sie RunOperation mit der LDAP-Aktivität Delete Entry für jeden Eintrag verwenden.

LDAP Search Entry: Filterausdruck ist auf einigen Servern case-sensitiv

  • Symptom: Eine LDAP-Aktivität Search Entry liefert keine Ergebnisse oder gibt einen Fehler zurück, obwohl die abgefragten Einträge im Verzeichnis vorhanden sind.
  • Mögliche Ursache: Einige LDAP-Server erfordern, dass Attributnamen in Filterausdrücken exakt der Schreibweise der Serverschemas entsprechen. Der von Studio vorausgefüllte Filterausdruck verwendet Titelschreibweise für die strukturelle Klasse (beispielsweise ObjectClass), einige Server erfordern jedoch eine andere Schreibweise (beispielsweise objectClass).
  • Lösung:
    1. Überprüfen Sie in der LDAP-Aktivitätskonfiguration Search Entry das vorausgefüllte Feld Filter Expression.
    2. Passen Sie die Schreibweise der Attributnamen an das an, was der Ziel-LDAP-Server erwartet. Ändern Sie beispielsweise ObjectClass zu objectClass, wenn der Server Kleinschreibung erfordert.
    3. Konsultieren Sie die Dokumentation oder Schemadefinition Ihres LDAP-Servers für die erforderlichen Konventionen für die Attributbenennung.

Microsoft-Konnektoren

Microsoft SharePoint Online: SOAP-Schemaverbindungen nach IDCRL-Abschaltung fehlgeschlagen

  • Symptom: Operationen, die einen Microsoft SharePoint Server-Konnektor mit dem Verbindungstyp SOAP-Schema nutzen, schlagen fehl oder geben Authentifizierungsfehler zurück, wenn eine Verbindung zu SharePoint Online hergestellt wird.
  • Mögliche Ursache: Microsoft hat die IDCRL-Methode (Identity Client Runtime Library) abgeschaltet, die von SOAP-Schemaverbindungen zu SharePoint Online verwendet wird. Nach dem 1. Mai 2026 werden Operationen mit dem SharePoint SOAP-Schema für SharePoint Online-Verbindungen voraussichtlich fehlschlagen.
  • Lösung:
    1. Öffnen Sie in Studio jede betroffene SharePoint-Verbindung und ändern Sie die Schema-Einstellung von SOAP zu REST.
    2. Konfigurieren Sie alle Aktivitäten, die das SOAP-Schema verwendet haben, so um, dass sie entsprechende REST-Operationen nutzen.
    3. Testen und stellen Sie die betroffenen Operationen erneut bereit.
    4. Weitere Informationen zur Migration finden Sie in der Dokumentation zum Microsoft SharePoint Server-Konnektor.

Microsoft Dynamics 365 Business Central v2: Typnamen nicht kompatibel mit Metadaten

  • Symptom: Operationen mit dem Microsoft Dynamics 365 Business Central v2-Konnektor schlagen mit Fehlern fehl, die angeben, dass Typnamen in der Nutzlast nicht mit den OData-Metadaten kompatibel sind.
  • Mögliche Ursache: Bestimmte OData-API-Endpunkte von Dynamics 365 Business Central erfordern OData-Typanmerkungen in der Request-Nutzlast. Der Konnektor fügt diese Anmerkungen standardmäßig nicht ein, was bei diesen Endpunkten zu Typinkompatibilitätsfehlern führt.
  • Lösung:
    1. Öffnen Sie die Konfiguration der Update-Aktivität für Microsoft Dynamics 365 Business Central v2.
    2. Aktivieren Sie unter Optionale Einstellungen die Option OData-Typ in Nutzlast festlegen.
    3. Speichern Sie die Aktivität und testen Sie die betroffenen Operationen erneut.

Microsoft Entra ID: Erweiterungsattribute nicht als Abfragefilter-Bedingungen auswählbar

  • Symptom: Beim Konfigurieren einer Microsoft Entra ID-Query-Aktivität erscheint das Feld onPremisesExtensionAttributes und seine untergeordneten Erweiterungsattributfelder (z. B. extensionAttribute1 bis extensionAttribute15) nicht in der Auswahl Objektfelder in Schritt 3 und können nicht als Filterbedingungen für bedingte Klauseln ausgewählt werden.
  • Mögliche Ursache: onPremisesExtensionAttributes ist ein komplexer Objekttyp (verschachtelt). Die Auswahl Objektfelder in Schritt 3 zeigt nur primitive Datentypen an; komplexe Feldtypen werden von der Auswahliste ausgeschlossen.
  • Lösung: Die Felder onPremisesExtensionAttributes müssen nicht in Schritt 3 ausgewählt werden, um zurückgegeben zu werden. Sie werden im Ausgabeschema der Aktivität in Schritt 4 angezeigt und während der Ausführung der Operation mit Werten gefüllt. Um auf Erweiterungsattributwerte zuzugreifen, greifen Sie bei der Transformation auf onPremisesExtensionAttributes und seine untergeordneten Felder zu.

Microsoft Entra ID-Update-Aktivität: DateTime-Felder mit Edm.String-Typinkompatibilität zurückgewiesen

  • Symptom: Eine Microsoft Entra ID-Update-Aktivität schlägt fehl mit:
Es wurde ein Wert gefunden, dessen Typname mit den Metadaten nicht kompatibel ist.
Der Wert gab seinen Typ als "Edm.String" an, aber der in den Metadaten angegebene Typ ist "Edm.DateTimeOffset".
[HTTP/1.1 400 Bad Request]
  • Mögliche Ursache: Der Connector sendet DateTime-Feldwerte (wie employeeHireDate) ohne die von der Microsoft Graph API erforderliche @odata.type-Annotation. Ohne die Annotation wird der Wert als Edm.String statt Edm.DateTimeOffset interpretiert, was zu einem 400-Fehler führt.
  • Lösung:
    1. Öffnen Sie die Konfiguration der Microsoft Entra ID Update-Aktivität.
    2. Erweitern Sie in Schritt 1 Optionale Einstellungen und aktivieren Sie OData-Typ in Payload festlegen.
    3. Speichern Sie die Aktivität, stellen Sie sie erneut bereit und führen Sie den Vorgang erneut aus.

Microsoft Entra ID Query: „Unsupported or invalid query filter clause" bei gefilterten Eigenschaften

  • Symptom: Eine Microsoft Entra ID Query-Aktivität schlägt fehl, wenn in Schritt 3 eine Filterbedingung angewendet wird:

    (Request_UnsupportedQuery) Unsupported or invalid query filter clause specified for property '<property>' of resource '<object>'. [HTTP/1.1 400 Bad Request]

    Dieselbe Abfrage wird erfolgreich ausgeführt, wenn kein Filter angewendet wird.

  • Mögliche Ursache: Das Filtern nach bestimmten Microsoft Entra ID-Eigenschaften (wie companyName und createdDateTime) nutzt die erweiterte Abfragefunktion der Microsoft Graph API, die $count=true in der Abfragezeichenfolge erfordert. Ohne diese lehnt die API den Filter ab, auch wenn die Syntax ansonsten korrekt ist. Der Connector bezieht automatisch den erforderlichen ConsistencyLevel: eventual-Header ein, aber $count=true muss separat hinzugefügt werden.

  • Lösung: Wählen Sie je nach Registerkarte, die in Schritt 3 verwendet wird, eine der folgenden Optionen:
    • Registerkarte „Basis": Aktivieren Sie das Kontrollkästchen Anzahl einbeziehen. Dies fügt $count=true automatisch zur Abfrage hinzu.

    • Registerkarte „Erweitert": Fügen Sie &$count=true manuell an die Filterzeichenfolge an. Beispiel:

      $filter=companyName eq 'Example Corp'&$count=true

Eine Liste der Eigenschaften, die erweiterte Abfragesyntax erfordern, finden Sie unter Advanced query capabilities on Microsoft Entra ID objects in der Microsoft Graph-Dokumentation.

Microsoft Dynamics AX 2012-Operationen schlagen mit „Logon failed" fehl

  • Symptom: Operationen mit dem Microsoft Dynamics AX-Connector für AX 2012 schlagen zur Laufzeit fehl, obwohl der Verbindungstest in Studio erfolgreich ist. Das Jitterbit Dynamics AX 2012 Connector REST Service-Protokoll enthält:

    The server has rejected the client credentials.

    The logon attempt failed

  • Ursache: Das Feld Domänenname in der AX 2012-Verbindung ist nicht auf den korrekten Wert eingestellt. Die AX 2012-Authentifizierung erfordert, dass Domänenname die DNS-Domänennamenserweiterung ist (beispielsweise yourcompany.com), nicht ein kurzer oder NetBIOS-Domänenname. Ein falscher Domänenwert führt dazu, dass AX ansonsten gültige Anmeldeinformationen mit einem Anmeldefehler ablehnt, auch wenn der Verbindungstest erfolgreich ist.

  • Lösung:
    1. Öffnen Sie die Dynamics AX 2012-Verbindung in Studio.
    2. Stellen Sie das Feld Domänenname auf Ihre DNS-Domänennamenserweiterung ein (beispielsweise yourcompany.com), nicht auf einen kurzen/NetBIOS-Domänennamen.
    3. Bestätigen Sie, dass Anmeldung der AX-Dienstkontobenutzername mit den erforderlichen Berechtigungen ist, und geben Sie das Passwort erneut ein, um einen veralteten Wert auszuschließen.
    4. Testen Sie die Verbindung und führen Sie dann den Vorgang erneut aus.

NetSuite-Connector

Hinweis

NetSuite verfügt über ein dediziertes Troubleshooting-Handbuch, das zusätzliche Verbindungs-, Schema-, Activity-Konfiguration und Leistungsprobleme abdeckt. Siehe NetSuite-Troubleshooting.

NetSuite Create, Update oder Upsert schlägt fehl mit „is not a legal value for Country"

  • Symptom: Eine NetSuite-Activity zum Erstellen, Aktualisieren oder Upsert schlägt fehl, wenn der Quellwert für ein Länderfeld nicht mit einem NetSuite-Country-Enum-Wert übereinstimmt:

    FaultString: org.xml.sax.SAXException: <country_value> is not a legal value for {urn:types.common_<version>.platform.webservices.netsuite.com}Country

  • Mögliche Ursache: Die NetSuite SuiteTalk API erfordert, dass Country (und andere aufgezählte Felder) einer der vordefinierten Enum-Werte aus der WSDL entsprechen (z. B. _unitedStates). Ein Ländername zur Anzeige, ein ISO-Ländercode oder ein beliebiger Wert, der nicht exakt mit dem WSDL-Enum übereinstimmt, wird abgelehnt.

  • Lösung:
    • Übersetzen Sie in der Transformation, die dem NetSuite-Ziel zugeordnet ist, den Quell-Länderwert in den entsprechenden NetSuite-Enum-Wert, bevor Sie ihn schreiben. Ein Nachschlagewerk, eine Case-Anweisung oder eine Nachschlagetabelle funktionieren alle.
    • Erstellen Sie das Nachschlagewerk aus dem Country-Enum, das in der NetSuite SuiteTalk WSDL definiert ist, die Ihr Connector verwendet. Die gültigen Werte unterscheiden sich zwischen den WSDL-Versionen, daher sollten Sie immer anhand der WSDL-Version überprüfen, die derzeit auf der Verbindung konfiguriert ist.
    • Wenden Sie denselben Ansatz auf alle anderen Felder an, die durch ein NetSuite-Enum gestützt werden (z. B. State, Currency), bei denen die Quellwerte nicht bereits mit dem WSDL-Enum übereinstimmen.

OData-Connector

OData v2 Entity Sets können nicht geladen werden mit „No entity sets found"

  • Symptom: Das Konfigurieren einer OData-Query-Activity, die auf einen OData v2.0-Dienst verweist, gibt einen Fehler beim Abrufen der Objektliste zurück, obwohl der Verbindungstest erfolgreich ist:

    An error occurred while fetching the data:
Error while generating for query activity object list. The Exception is No entity sets found for the address provided.

  • Mögliche Ursache: Die Unterstützung für OData V2-Dienste wurde in Agent-Version 11.59 über die Verbindungseinstellung OData version zum OData-Connector hinzugefügt. Bei älteren Agenten als 11.59 unterstützt der Connector nur OData V4, daher kann eine Verbindung, die auf einen OData V2-Dienst verweist, die Objektliste nicht auffüllen. Der gleiche Fehler tritt auch bei 11.59 oder später auf, wenn OData version für einen OData V2-Dienst auf V4 gesetzt bleibt.

  • Lösung:
    1. Führen Sie für private Agents ein Upgrade auf Version 11.59 oder später durch. Cloud Agents erhalten das Update automatisch.
    2. Stellen Sie in der OData-Verbindung OData version auf V2 (die Standardeinstellung ist V4). Speichern Sie die Verbindung und testen Sie sie erneut.
    3. Öffnen Sie die OData-Query-Activity erneut. Die Entity Sets sollten nun geladen werden.

OData: Microsoft Dynamics 365 gibt nur Daten des Standardunternehmens zurück

  • Symptom: Eine OData-Verbindung zu einem Microsoft Dynamics 365 Finance and Operations-Endpunkt gibt Daten nur für das Standardunternehmen des Benutzers zurück, daher fehlen Datensätze anderer Unternehmen in den Ergebnissen.
  • Mögliche Ursache: Ein Dynamics 365 Finance and Operations OData-Endpunkt gibt standardmäßig nur Daten zurück, die zum Standardunternehmen des Benutzers gehören. Um der Verbindung einen unternehmensübergreifenden (erweiterten) Bereich zu geben, muss eine unternehmensübergreifende Filterklausel an die OData metadata URL der Verbindung (die $metadata-URL) angehängt werden. Bei der Metadaten-URL wird ?cross-company=true allein nicht den erweiterten Bereich angewendet.
  • Lösung: Fügen Sie in der OData-Verbindung eine dataAreaId-Filterklausel an die OData metadata URL an, ersetzen Sie usrt durch Ihre Datenbereich-Kennung und speichern Sie dann und testen Sie erneut:
?$filter=dataAreaId eq 'usrt'&cross-company=true

Hintergrund zur Geltendmachung von OData-Daten nach Unternehmen in Dynamics 365 finden Sie in der Microsoft-Dokumentation zu unternehmensübergreifendem Verhalten.

Oracle-Konnektoren

Oracle EBS: Verbindungsfehler „benutzerdefinierte Provider-JAR-Datei nicht vorhanden"

  • Symptom: Die Verbindung zu einer Oracle E-Business Suite (EBS)-Instanz schlägt fehl mit:

    Error connecting to Oracle EBS instance. Error is: The custom provider JAR file is not present in the Jitterbit Private Agent or it is not in the right location ($JITTERBIT_HOME/Connectors/Providers)

  • Mögliche Ursache: Der Oracle EBS-Konnektor setzt voraus, dass der Oracle JDBC-Treiber (ojdbc8.jar) manuell auf dem privaten Agenten platziert wird. Diese Datei ist nicht im Agenten enthalten und muss vor erfolgreicher Verbindung hinzugefügt werden.

  • Lösung:
    1. Laden Sie ojdbc8.jar von der Oracle-Website herunter (ein Oracle-Konto ist erforderlich).
    2. Platzieren Sie ojdbc8.jar im Verzeichnis $JITTERBIT_HOME/Connectors/Providers/ auf dem Host des privaten Agenten.
    3. Starten Sie alle Agenten in der Agentengruppe neu.
    4. Testen Sie die Oracle EBS-Verbindung erneut.

Salesforce-Konnektoren

Hinweis

Der Salesforce-Konnektor verfügt über einen speziellen Fehlerbehebungsleitfaden zur Authentifizierung, zum Schema, zur Aktivitätskonfiguration, zu Datensatzlimits und zu Bulk-Aktivitätsproblemen. Siehe Fehlerbehebung für Salesforce-Konnektoren.

Salesforce Events: Ereignisse können nach Agentenneustart nicht aktiviert werden

  • Symptom: Nach einem Neustart oder einer Neuinstallation eines privaten Agenten schlägt die Aktivierung von Salesforce Events-Konnektoren fehl, auch wenn die Verbindungsanmeldedaten korrekt sind.
  • Mögliche Ursache: Nach einem Neustart ist die Konnektor-JAR-Datei möglicherweise noch nicht auf dem Agenten vorhanden. Um ein Ereignis zu aktivieren, muss der Konnektor zuerst auf den Agenten heruntergeladen werden.
  • Lösung:
    1. Öffnen Sie die Konfiguration der Salesforce Events-Verbindung in Studio.
    2. Klicken Sie auf Test, um die Verbindung zu testen. Dies erzwingt, dass die Konnektor-JAR auf den Agenten heruntergeladen wird.
    3. Versuchen Sie nach erfolgreichem Verbindungstest, das Ereignis erneut zu aktivieren.

Salesforce Events: „Der angegebene Kanal ist nicht gültig" bei Aktivierung einer Change Data Capture-Listening-Aktivität

  • Symptom: Die Aktivierung eines Vorgangs, der eine Salesforce Events-Listening-Aktivität für Change Data Capture (CDC) enthält, schlägt mit einem Fehler fehl, ähnlich wie:

    Unable to subscribe to [/data/<ObjectName>ChangeEvent:-1] [...]: 400::The channel specified is not valid {/data/<ObjectName>ChangeEvent}

  • Mögliche Ursache: Das Objekt ist in Salesforce nicht für Change Data Capture ausgewählt.

  • Lösung: Wechseln Sie in Salesforce zu Setup > Platform Tools > Integrations > Change Data Capture, fügen Sie das Objekt zu Selected Entities hinzu, und aktivieren Sie dann den Vorgang erneut. Die vollständigen Schritte finden Sie unter Auswahl der Entitäten, die Ereignisse generieren.

Salesforce Events: Einschränkungen der Listening-Aktivität

Die folgenden Verhaltensweisen von Salesforce Events Listening-Aktivitäten (Subscribe Event und die Subscribe-Aktivitäten Insert, Update und Delete CDC Event) sind zu erwarten und deuten nicht auf einen Connector-Fehler hin:

  • Events können nicht aktiviert werden, weil die maximale Anzahl von Abonnenten erreicht ist. Die Salesforce-Instanz begrenzt die Anzahl gleichzeitiger Clients (Abonnenten). Wenn dieses Limit erreicht ist, können keine weiteren Events aktiviert werden. Verringern Sie die Anzahl der aktiven Abonnenten, die mit der Instanz verbunden sind.
  • Maßeinheitensymbole wie $ und % fehlen in der Antwort. Diese Symbole werden nicht zurückgegeben, gemäß dem Design der Salesforce-API.
  • Ungeänderte Felder werden in Change Data Capture (CDC)-Antworten als null zurückgegeben. Bei CDC-Aktivitäten werden nur geänderte Felder aufgefüllt; ungeänderte Felder werden als null zurückgegeben, gemäß dem Design der Salesforce-API.

SAP-Connector

Mehrere SAP-Aktivitäten in einer Operation schlagen zur Laufzeit fehl

  • Symptom: Eine Operation, die mehr als eine SAP-Aktivität enthält, oder die eine SAP-Aktivität mit einer NetSuite-, Salesforce-, Salesforce Service Cloud-, ServiceMax- oder SOAP-Aktivität kombiniert, wird bereitgestellt, ohne dass ein Validierungsfehler auftritt, schlägt aber bei der Ausführung fehl.
  • Mögliche Ursache: Operationen, die diese Aktivitätstypen mischen, erscheinen in Studio als gültig und können erfolgreich bereitgestellt werden, aber diese Kombinationen werden zur Laufzeit nicht unterstützt. Die Operationsvalidierungsregeln kennzeichnen dieses Muster zur Entwurfszeit nicht als Fehler. Dies ist ein dokumentiertes Studio-bekanntes Problem.
  • Lösung:
    • Gestalten Sie jede Operation so, dass sie nur eine einzelne SAP-Aktivität enthält, ohne weitere SAP-, NetSuite-, Salesforce-, Salesforce Service Cloud-, ServiceMax- oder SOAP-Aktivitäten in derselben Operation.
    • Wenn Daten aus mehreren Systemen in einem einzelnen Workflow benötigt werden, teilen Sie die Logik in separate Operationen auf und verknüpfen Sie sie mithilfe von Operationsaktionen.

SAP RFC: „Keine RFC-Berechtigung für Funktionsmodul BAPI_TRANSACTION_COMMIT"

  • Symptom: Eine SAP-RFC-Aktivität schlägt zur Laufzeit mit folgendem Fehler fehl:

    JCoException occurred No RFC authorization for function module BAPI_TRANSACTION_COMMIT

  • Mögliche Ursachen:

    • Das SAP-Benutzerkonto in der Verbindung hat keine S_RFC-Berechtigung für BAPI_TRANSACTION_COMMIT oder die zugehörigen Funktionsgruppen.
    • Das Funktionsmodul BAPI_TRANSACTION_COMMIT ist nicht als Remote-fähig im SAP-System konfiguriert.
    • Die Anforderungstransformation vor der Aktivität setzt das Commit-Kontrollfeld nicht.

  • Lösung:

    • Bestätigen Sie im SAP-System, dass das Funktionsmodul BAPI_TRANSACTION_COMMIT Remote-fähig ist.
    • Setzen Sie in der Anforderungstransformation, die der SAP-Aktivität RFC vorangeht, das Feld BAPI_COMMIT auf true.
    • Vergewissern Sie sich, dass das in der Verbindung referenzierte SAP-Benutzerkonto S_RFC-Berechtigung für BAPI_TRANSACTION_COMMIT und alle zugehörigen Funktionsgruppen hat.
    • Wenn das Problem weiterhin besteht, wenden Sie sich an Ihren SAP-BASIS-Administrator, um die Autorisierungsobjektzuweisungen des Benutzers zu überprüfen.

SAP-Verbindung schlägt mit „Ungültiger Sprachschlüssel" fehl

  • Symptom: Eine SAP-Verbindung schlägt während der Initialisierung mit einem Fehler zum Sprachschlüssel fehl:

    Connector Error: AdapterResourceException: Error while creating Destination. 00024Invalid language key when configuring the text environment.

  • Mögliche Ursache: Der im SAP-Endpunkt konfigurierte Sprachcode ist für das SAP-Zielsystem ungültig: Der Code ist auf diesem System nicht installiert oder unterstützt, ist falsch geschrieben oder hat die falsche Groß-/Kleinschreibung (z. B. en statt EN). SAP lehnt den ungültigen Schlüssel ab, wenn die Textumgebung des Ziels initialisiert wird.

  • Lösung:
    1. Bearbeiten Sie den SAP-Endpunkt in Studio und setzen Sie das Feld Language auf einen unterstützten zweistelligen Sprachcode (z. B. EN für Englisch).
    2. Überprüfen Sie, dass der Wert einem auf dem SAP-Zielsystem installierten und aktiven Sprachcode entspricht. Falls unsicher, bestätigen Sie die Standardsprache des Integrationsbenutzers im SAP-Benutzerprofil und verwenden Sie diese.
    3. Testen Sie die Verbindung von Studio aus, um zu bestätigen, dass die Initialisierung erfolgreich ist, bevor Sie den Vorgang erneut bereitstellen.

ServiceNow-Connector

Erste Vorgänge sind nach Agentneunstart oder auf Cloud-Agenten langsam

  • Symptom: Vorgänge, die den ServiceNow-Connector verwenden, laufen in zwei Szenarien langsam:

    • Bei privaten Agenten kann der erste Vorgang nach dem Neustart des Agenten mehrere Minuten dauern; nachfolgende Ausführungen sind schnell.
    • Bei Cloud-Agenten sind Ausführungen zeitweise langsam und dauern Minuten, wenn sich der Metadaten-Cache des Connectors aktualisiert.

    Dies kann zu nachgelagerten API-Timeouts führen.

  • Mögliche Ursache: Der Connector speichert ServiceNow-Metadaten aggressiv zwischen. Nach einem Agentneunstart bei einem privaten Agenten (oder bei jeder Ausführung für einen Cloud-Agenten, der den Cache nicht beibehielt), muss der erste Vorgang den Cache neu aufbauen, was mehrere Minuten dauert.

  • Lösung:
    • Entschärfen Sie die Verlangsamung nach dem Neustart bei einem privaten Agenten, indem Sie getcolumnsmetadata=onUse zu den Advanced Options des ServiceNow-Endpunkts hinzufügen. Diese Einstellung ist nur auf privaten Agenten wirksam.
    • Für eine konsistente Leistung auf Cloud-Agenten rufen Sie die ServiceNow REST API über den HTTP v2-Connector auf, anstatt den ServiceNow-Connector zu verwenden. Der HTTP v2-Connector speichert keine Metadaten zwischen und vermeidet die Neuerstellungsverzögerung.

ServiceNow v2-Connector

ServiceNow v2: Ein Objekt wird nicht unter seinem ServiceNow-Connector-Namen aufgelistet

  • Symptom: Ein Objekt, das im ServiceNow-Connector unter einem bekannten Namen ausgewählt werden kann, wird im ServiceNow v2-Connector nicht unter demselben Namen gefunden.
  • Ursache: Die Verwendung der ServiceNow REST API durch den ServiceNow v2-Connector stellt Objekte mit ServiceNows tatsächlichem Backend-Tabellennamen bereit, der vom Namen desselben Objekts im ServiceNow-Connector abweichen kann. Das Objekt mit dem Namen System im ServiceNow-Connector entspricht beispielsweise Sys im ServiceNow v2-Connector.
  • Lösung: Suchen Sie in ServiceNow den tatsächlichen Tabellennamen des Objekts unter System Definition > Tables auf und suchen Sie dann in der Aktivitätskonfiguration des ServiceNow v2-Connectors nach diesem Namen.

Shopify-Connector

Shopify: Auswahlvorgänge für Aktivitätsobjekte können sich nach API-Versionsaktualisierung ändern

  • Symptom: Nach dem Ändern der API-Version auf einer Shopify-Verbindung geben eine oder mehrere Shopify-Aktivitäten Fehler zurück oder verhalten sich unerwartet, und ein konfiguriertes Objekt oder Unterobjekt scheint sich geändert zu haben.
  • Mögliche Ursache: Shopify veröffentlicht vierteljährlich neue API-Versionen und veraltet ältere Versionen nach 12 Monaten. Wenn Sie zu einer anderen API-Version wechseln, können Objekte oder Unterobjekte, die in der neuen Version nicht verfügbar sind, nicht mehr ausgewählt werden. Dies führt dazu, dass sich die konfigurierte Auswahl der Aktivität ändert, wenn die Konfiguration aktualisiert wird.
  • Lösung:
    1. Nach dem Ändern der Shopify-API-Version in der Verbindung öffnen Sie jede betroffene Shopify-Aktivitätskonfiguration.
    2. Klicken Sie auf Aktualisieren, um die verfügbaren Objekte für die neue API-Version neu zu laden.
    3. Überprüfen Sie die Objekt- und Unterobjekt-Auswahl, um zu bestätigen, dass sie Ihrer Absicht unter der neuen Version entsprechen.
    4. Aktualisieren Sie alle Auswahl, die sich in die korrekten Ersatzobjekte geändert haben.
    5. Stellen Sie die betroffenen Operationen erneut bereit und testen Sie sie erneut.
    6. Informationen zu den Abschreibungszeitplänen der Shopify-API-Version finden Sie im Shopify-Änderungsprotokoll.

Snowflake-Connector

Snowflake: Kennwortbasierte Verbindungen schlagen nach Authentifizierungsabschreibung fehl

  • Symptom: Operationen, die sich mit Snowflake unter Verwendung des Authentifizierungstyps Kennwort (veraltet) verbinden, schlagen nach vorherigem Funktionieren fehl, beispielsweise mit:

    HttpErrorResponse: Error opening connection. Exception is Failed to authenticate: MFA authentication is required, but none of your current MFA methods are supported for programmatic authentication.

  • Mögliche Ursache: Snowflake phased die Authentifizierung mit einem Faktor (nur Kennwort) aus, einschließlich für die LEGACY_SERVICE-Kontotypen, die für diesen Authentifizierungstyp erforderlich sind. Snowflake migriert LEGACY_SERVICE-Konten zu TYPE=SERVICE auf Basis eines rollierenden, kontoabhängigen Systems, was die kennwortbasierte Authentifizierung vollständig blockiert. Einige Konten haben auch die Multi-Faktor-Authentifizierung (MFA) aktiviert, die mit dieser vollautomatischen programmgesteuerten Verbindung nicht kompatibel ist, da MFA einen Menschen in der Schleife erfordert. Weitere Informationen finden Sie unter Kennwort (veraltet) für den Abschreibungszeitplan.

  • Lösung: Aktualisieren Sie die Verbindung des Snowflake-Connectors in Studio, um OAuth oder Key-Pair-Authentifizierung zu verwenden, und konfigurieren Sie das Snowflake-Benutzerkonto entsprechend. Stellen Sie dabei sicher, dass es nicht bei MFA registriert ist.

Snowflake: Entwicklerinstanz schläft, Metadatentabellen werden nicht ausgefüllt

  • Symptom: Beim Konfigurieren einer Snowflake-Aktivität wird die Liste der verfügbaren Objekte nicht ausgefüllt oder scheint leer zu sein, obwohl der Verbindungstest erfolgreich war.
  • Mögliche Ursache: Snowflake-Entwicklerinstanzen gehen in den Ruhezustand über, wenn auf sie kürzlich nicht zugegriffen wurde. Obwohl der Verbindungstest gegen eine ruhende Instanz erfolgreich sein kann, gibt die Instanz möglicherweise keine Tabellen- und Objektmetadaten zurück.
  • Lösung:
    1. Melden Sie sich in der Snowflake-Webbenutzeroberfläche an, um die Instanz zu aktivieren.
    2. Öffnen Sie die Snowflake-Verbindung in Studio erneut und klicken Sie auf Testen, um die Anmeldedaten erneut zu testen.
    3. Öffnen Sie die Aktivitätskonfiguration erneut, um die Liste der verfügbaren Objekte zu aktualisieren.

Snowflake Query: Flache Schema-Wurzelknoten-Fallabweichung verursacht ProcessFlatStream-Fehler

  • Symptom: Eine Snowflake-Aktivität Query mit einem flachen Schema schlägt zur Laufzeit fehl mit:

    StartElement() error, starting element does not match with the root.
qName= "<table_name_lowercase>", root name="<TABLE_NAME_UPPERCASE>"

ProcessFlatStream error

    Dieser Fehler tritt auf, wenn die Abfrage eine WHERE-Klausel, eine LIMIT-Klausel oder einen Variablenverweis in einer WHERE-Klausel enthält.

  • Mögliche Ursache: Der Snowflake-Connector gibt den Tabellennamen in Kleinbuchstaben in der XML-Antwort zurück. Wenn Studio ein flaches Schema aus der Abfrage generiert, wird der Name des Root-Knotens in Großbuchstaben erstellt. Die Unterscheidung zwischen dem Root-Knoten des Schemas (Großbuchstaben) und dem Root-Knoten der XML-Antwort (Kleinbuchstaben) führt dazu, dass die Verarbeitung des flachen Streams fehlschlägt.

  • Lösung: Wählen Sie eine der folgenden Optionen:
    • Ändern Sie im flachen Schema den Namen des Root-Knotens in Kleinbuchstaben, um die Connector-Ausgabe zu entsprechen. Benennen Sie beispielsweise SALES_ORDERS in sales_orders um.
    • Verwenden Sie das Mirror-Schema mit Standard-Mapping anstelle eines manuell erstellten flachen Schemas. Das Mirror-Schema leitet seine Struktur direkt aus der Connector-Antwort ab und weist diese Groß-/Kleinschreibungs-Nichtübereinstimmung nicht auf.

Snowflake Merge: stageName und fileContent fehlen im Request-Schema für externe Stages

  • Symptom: Eine Snowflake-Merge-Aktivität, die für eine externe Stage konfiguriert ist, zeigt ein Request-Schema ohne die Felder stageName und fileContent an. Dieselbe Aktivität, die für eine interne Stage konfiguriert ist, zeigt beide Felder.
  • Mögliche Ursache: Externe Stages sind schreibgeschützte Verweise auf Dateien, die bereits in externem Cloud-Speicher vorhanden sind (S3, GCS oder Azure Blob). Die Merge-Aktivität kann keinen Dateiinhalt in eine externe Stage hochladen, daher werden die Felder weggelassen, die diesen Upload steuern.
  • Lösung:
    • Wenn die Aktivität auf eine externe Stage abzielt, stellen Sie sicher, dass die Datendateien bereits an dem Cloud-Speicherort vorhanden sind, auf den die Stage verweist. Die Merge-Aktivität liest direkt aus diesen Dateien; das Feld fileContent ist nicht erforderlich.
    • Wenn Dateiinhalt aus dem Vorgang übertragen werden muss, konfigurieren Sie die Merge-Aktivität für die Verwendung einer internen Stage. Das Schema zeigt dann stageName und fileContent an.

Snowflake Insert oder Merge: SQL-Syntaxfehler durch Sonderzeichen

  • Symptom: Eine Snowflake-Aktivität Insert oder Merge schlägt mit einem SQL-Kompilierungsfehler fehl, z. B.:

    SQL compilation error:
syntax error line 1 at position <n> unexpected '<token>'.

    Spaltenwerte können auch falsch zugeordnet sein, wobei Daten aus einem Feld in der falschen Spalte angezeigt werden.

  • Mögliche Ursachen:

    • Feldwerte, die einfache Anführungszeichen enthalten (z. B. ein Wert wie corner's), werden nicht maskiert, bevor sie in die SQL-Payload aufgenommen werden. Das nicht maskierte Anführungszeichen beendet die Zeichenkette vorzeitig, was dazu führt, dass der Rest des Wertes als SQL-Syntax anstelle von Daten interpretiert wird.
    • Ein Spaltenzielname enthält ein Sonderzeichen, z. B. einen Bindestrich (z. B. Zip-Code). Snowflake erfordert, dass ein Bezeichner mit einem Sonderzeichen in Anführungszeichen gesetzt wird; ohne Anführungszeichen führt dies zu einem Syntaxfehler am Bindestrich.

  • Lösung:

    • Für Werte mit einfachen Anführungszeichen: Aktivieren Sie in den Optionalen Einstellungen der Snowflake-Verbindung die Option Sonderzeichen maskieren. Dies maskiert automatisch einfache Anführungszeichen in Insert- und Invoke Stored Procedure-Aktivitäts-Payloads. Verwenden Sie für Merge-Aktivitäten oder als Alternative zu Insert SQLEscape in der Transformationszuordnung, um einfache Anführungszeichen in betroffenen Feldwerten zu maskieren, bevor sie die Aktivität erreichen.
    • Für Spaltennamen mit Sonderzeichen: Bestätigen Sie, dass Anführungszeichen für Snowflake-Bezeichner verwenden für die Verbindung aktiviert ist (standardmäßig aktiviert).

Snowflake: Java-Heap-Space-Fehler beim Abfragen großer Datenmengen

  • Symptom: Eine Snowflake-Aktivität Query schlägt mit dem folgenden Fehler fehl, wenn die Abfrage eine große Anzahl von Zeilen zurückgibt:

    Error executing query activity. Exception is Java heap space

    Der Connector meldet den Fehler in dieser Form, weil er den zugrunde liegenden Java-Fehler umhüllt, der weiter unten in der Stack-Trace angezeigt wird:

    Caused by: java.lang.OutOfMemoryError: Java heap space

    Falls dieser Fehler bei Abfragen auftritt, die nur wenige Zeilen zurückgeben, oder wenn der gleiche Agent auch mit Heap-Fehlern über andere Connectoren fehlschlägt, liegt die Ursache eher bei der gesamten Heap-Zuweisung des Agents als bei der Größe des Ergebnissatzes. Siehe Java heap space: OutOfMemoryError.

  • Mögliche Ursache: Der Snowflake-Connector lädt den gesamten Abfrageergebnissatz in den JVM-Speicher, bevor er ihn an die Transformation übergibt. Bei sehr großen Ergebnissätzen wird der Tomcat-JVM-Heap im privaten Agent damit erschöpft.

  • Lösung: Verwenden Sie bei großen Abfragemengen statt des Snowflake-Connectors den Database-Connector mit einem Snowflake-JDBC-Treiber. Der Database-Connector puffert den vollständigen Ergebnissatz nicht im Speicher, daher kann er viel größere Abfragemengen verarbeiten. Installieren Sie den Snowflake-JDBC-Treiber im privaten Agent, und konfigurieren Sie anschließend eine Database-Verbindung, die ihn nutzt. Bei Agent 12.x und später benötigt diese Database-Verbindung auch enableArrowResultFormat=false&jdbc_query_result_format=json in der Verbindungszeichenfolge; siehe Snowflake: Operations fail on agent 12.x.

    Falls Sie beim Snowflake-Connector bleiben müssen, können beide folgenden Maßnahmen den Speicherdruck verringern, obwohl keine ausreichend ist, um Datensätze mit Millionen von Zeilen zu verarbeiten:

    • Teilen Sie die Abfrage mit SQL-Klauseln LIMIT und OFFSET in Batches auf, und führen Sie den Vorgang wiederholt mit ansteigenden Offsets durch, bis alle Zeilen verarbeitet sind.
    • Erhöhen Sie die Tomcat-JVM-Heap-Größe im privaten Agent (siehe Tomcat heap memory).

Snowflake: Operationen schlagen bei Agent 12.x fehl

  • Symptom: Bei einem privaten Agent mit Version 12.x schlagen Operationen, die Snowflake über einen Snowflake-JDBC-Treiber abfragen (eine Database-Verbindung oder ein DBExecute-Skript), zur Laufzeit fehl, obwohl der Verbindungstest erfolgreich ist. Der Fehler bezieht sich auf die Arrow-Memory-Schicht des Treibers, beispielsweise:

    JDBC driver internal error: exception creating result java.lang.ExceptionInInitializerError at net.snowflake.client.jdbc.internal.apache.arrow.memory.unsafe.UnsafeAllocationManager

    oder:

    JDBC driver internal error: exception creating result java.lang.NoClassDefFoundError: Could not initialize class net.snowflake.client.jdbc.internal.apache.arrow.memory.RootAllocator

  • Mögliche Ursache: Der Snowflake-JDBC-Treiber gibt Abfrageergebnisse standardmäßig im Apache-Arrow-Format zurück, das nicht mit Agent-Version 12.x und später kompatibel ist. Weitere Details finden Sie in Snowflakes Artikel zur Fehlerbehebung bei diesem Java-Modul-Fehler. Der Verbindungstest gibt keinen Ergebnissatz zurück, daher funktioniert er weiterhin, während Abfragen fehlschlagen. Ein Upgrade der JDBC-Treiberversion behebt dieses Problem nicht.

  • Lösung: Setzen Sie enableArrowResultFormat auf false und jdbc_query_result_format (oder JDBC_QUERY_RESULT_FORMAT) auf json, damit der Treiber Ergebnisse im JSON-Format statt im Arrow-Format zurückgibt:
    • Database-Connector: Fügen Sie enableArrowResultFormat=false&jdbc_query_result_format=json zur Snowflake-Verbindungszeichenfolge im Feld Additional Connection String Parameters hinzu (oder im Feld Connection String, falls Use Connection String ausgewählt ist).
    • Snowflake-Connector: Fügen Sie unter Optional settings > Connection Custom Properties den Eintrag enableArrowResultFormat mit dem Wert false hinzu. Ein Eintrag JDBC_QUERY_RESULT_FORMAT mit dem Wert JSON ist dort standardmäßig bereits vorhanden.

Dann speichern, die Verbindung erneut testen und den Vorgang erneut ausführen.

Bei einem privaten Agent kann die Korrektur stattdessen auf JVM-Ebene angewendet werden, sodass sie nicht pro Verbindung wiederholt werden muss. Hierzu wird --add-opens=java.base/java.nio=ALL-UNNAMED zu CATALINA_OPTS hinzugefügt:

=== "Linux"

    Füge die folgende Zeile zu `/opt/jitterbit/tomcat/bin/setenv.sh` hinzu:

    ```sh
    export CATALINA_OPTS="$CATALINA_OPTS --add-opens=java.base/java.nio=ALL-UNNAMED"
    ```

    Starten Sie anschließend den Agent neu.

=== "Windows"

    1.  Öffne den Registry Editor und suche den folgenden Schlüssel:

        ```txt
        HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Apache Software Foundation\Procrun 2.0\Jitterbit Tomcat Server\Parameters\Java
        ```

    2.  Öffne den Unterschlüssel **Options**.
    3.  Füge im Feld **Value data** `--add-opens=java.base/java.nio=ALL-UNNAMED` zu den vorhandenen Java-Optionen hinzu.
    4.  Klicke auf **Ok**.
    5.  Starten Sie den Agent neu.

=== "Docker"

    Verwende eine der folgenden Strategien, um die Einstellung anzuwenden:

    1.  Aktualisiere das Dockerfile und erstelle das Docker-Image neu:

        ```
        docker build -t my-agent .
        ```

    2.  Füge es zum Docker-Befehl `run` hinzu:

        ```
        docker run -e CATALINA_OPTS="--add-opens=java.base/java.nio=ALL-UNNAMED" my-agent
        ```

    3.  Füge es zu `docker-compose.yml` hinzu und starten Sie den Container neu:

        ```
        environment:
          - CATALINA_OPTS=--add-opens=java.base/java.nio=ALL-UNNAMED
        ```

SOAP-Connector

SOAP-Bereitstellungsfehler: "No WSDL with locator"

  • Symptom: Die Bereitstellung eines Projekts, das eine SOAP-Verbindung oder eine API-Aktivität SOAP Request oder SOAP Response enthält, schlägt fehl mit:

    Failed to deploy - Internal Error: No WSDL with locator

  • Mögliche Ursachen:

    • Die WSDL wurde entfernt, neu importiert oder die interne Referenz wurde beschädigt. Das Projekt verweist daher auf einen WSDL-Bezeichner, der nicht mehr vorhanden ist.

    • Das Projekt wurde vor dem Harmony-Release 12.9 bereitgestellt oder in eine andere Umgebung übertragen. Damals konnten noch in Verwendung befindliche WSDL-Dateien bei der Bereitstellung eines Projekts gelöscht werden. Das Release 12.9 verhindert diesen Löschvorgang, aber eine vorher gelöschte WSDL muss erneut hochgeladen werden.

  • Lösung:

    1. Lade die WSDL für die betroffene Komponente erneut hoch:

      • Für eine SOAP-Verbindung öffne die Verbindung und wähle Upload URL oder Upload file (nicht Select existing), lade die WSDL erneut hoch, überprüfe die Einstellungen für Port und Select methods und klicke dann auf Save Changes.
      • Für eine API-Aktivität SOAP Request oder SOAP Response öffne die Aktivität und lade die WSDL erneut in Schritt 1 der Konfiguration hoch.

      Wenn beim Upload ein Validierungsfehler angezeigt wird, siehe WSDL-Upload-Anforderungen.

    2. Überprüfe alle Transformationen, die Schemas aus der neu hochgeladenen WSDL erben, und generiere sie neu, falls erforderlich.

    3. Stelle das Projekt erneut bereit.

    4. Falls das Projekt mehrere WSDLs enthält und unklar ist, welche betroffen ist, siehe SOAP-Verbindung – Fehlerbehebung, um diese anhand eines JSON-Exports zu identifizieren.

SOAP WSDL: schemaLocation muss relative Verweise verwenden

  • Symptom: Eine SOAP-Verbindung, die auf eine WSDL mit importierten XSD-Schemadateien verweist, kann nicht geladen werden oder erzeugt Schemaauflösungsfehler zur Entwurfszeit. Das Upload der WSDL kann einen Fehler anzeigen wie:
Failed to parse WSDL: ENOENT: no such file or directory, open '<path>/types.xsd'

wobei types.xsd der Name der fehlenden Datei ist. Wenn sich die WSDL in einer ZIP-Datei befindet, beginnt die Fehlermeldung stattdessen mit Failed to parse WSDL file 'filename':, wobei filename der Name der WSDL-Datei in der ZIP-Datei ist.

  • Mögliche Ursachen:

    • Die WSDL verwendet absolute URLs in ihren schemaLocation-Attributen für importierte XSD-Dateien (z. B. http://example.com/schema.xsd). Der Agent kann beim Laden einer lokal importierten WSDL keine Schemas von absoluten Remote-URLs abrufen.

    • Die WSDL importiert eine XSD-Datei, die nicht mit ihr hochgeladen wurde. XSD-Dateien, die die WSDL über relative Pfade importiert, müssen zusammen mit der WSDL in einer ZIP-Datei hochgeladen werden.

  • Lösung:

    1. Bearbeite die WSDL so, dass alle schemaLocation-Referenzen relative Pfade verwenden (z. B. schema.xsd statt http://example.com/schema.xsd).

    2. Speichere alle referenzierten XSD-Dateien im selben Verzeichnis wie die WSDL oder am relativen Speicherort, den jeder schemaLocation angibt. Füge die WSDL- und XSD-Dateien zu einer ZIP-Datei hinzu und lade die ZIP-Datei in der SOAP-Verbindung über Upload file hoch.

    3. Alle Upload-Anforderungen findest du unter WSDL-Upload-Anforderungen.

SOAP-Connector schreibt XML-Namespace-Präfixe und -Struktur um

  • Symptom: Die XML-Enveloppe, die von einer SOAP-Aktivität erzeugt wird, stimmt nicht mit den literalen Namespace-Präfixen oder der Struktur der Quell-WSDL überein (z. B. ersetzt der Connector xmlns:ns1 durch xmlns:glob). Strikte SOAP-Services, die den genauen Präfixtext vergleichen, lehnen die Anfrage ab.
  • Mögliche Ursache: Die Transformations-Engine verarbeitet SOAP-Nachrichten als strukturiertes XML, nicht als literalen Text. Sie erzeugt eine semantisch äquivalente Nutzlast, die andere Namespace-Präfixe als die Quell-WSDL verwenden kann.
  • Lösung: Für SOAP-Services, die eine literale XML-Struktur erfordern, umgehe den SOAP-Connector und erstelle die Anfragenutzlast als String:
    1. Erstelle eine HTTP v2-Verbindung, die auf die SOAP-Service-URL verweist.
    2. Erstelle in einer Transformation die SOAP-Enveloppe als String, indem du String-Literale und zugeordnete Werte mit dem +-Operator verkettест. Alternativ kannst du eine Vorlage aus einer Datei lesen und dynamische Werte mit Replace ersetzen.
    3. In der HTTP v2 POST-Aktivität verwendest du das Standard-Request-Schema (lade kein benutzerdefiniertes Request-Schema hoch) und ordnest die konstruierte SOAP-Enveloppe-String dem body-Feld dieses Schemas zu. Der Connector sendet den body-Wert unverändert und preserviert damit das literale XML.
    4. Setze den Content-Type-Header auf text/xml oder application/soap+xml und den SOAPAction-Header, falls der Service ihn erfordert.
    5. Lese die Antwort des Service aus dem responseContent-Feld des Standard-Response-Schemas der Aktivität.

SOAP: MTOM/XOP-Nachrichten werden nicht unterstützt

VTEX-Connector

Verbindungstest schlägt mit „You don't have permission to access this resource" fehl

  • Symptom: Ein VTEX-Verbindungstest schlägt in Studio mit einer Berechtigungsfehlermeldung fehl, obwohl die gleichen Anmeldeinformationen in externen Tools wie Postman funktionieren.
Sie haben keine Berechtigung, auf diese Ressource zuzugreifen
  • Mögliche Ursache: Dem VTEX-Benutzer oder dem Anwendungsschlüssel, der der Verbindung zugeordnet ist, fehlen eine oder mehrere Berechtigungen, die der Connector zur Validierung der Verbindung verwendet. Diese Berechtigungen sind strenger als die für den grundlegenden Datenzugriff erforderlichen.
  • Lösung:
    1. Öffnen Sie im VTEX-Admin-Portal das Zugriffsprofil, das dem Benutzer oder dem Anwendungsschlüssel zugewiesen ist, den Jitterbit verwendet.
    2. Bestätigen Sie, dass das Zugriffsprofil die Funktion License Manager mit Zugriff auf die Ressource Get account by identifier enthält.
    3. Speichern Sie das Profil und testen Sie die VTEX-Verbindung in Studio erneut.

Workday-Connector

Workday: WSDL v42.0 und v42.1 geben Fehler für bestimmte Services zurück

  • Symptom: Operationen, die den Workday-Connector mit WSDL-Version 42.0 oder 42.1 verwenden, schlagen beim Zugriff auf die Webservices Human_Resources oder Resource_Management fehl.
  • Mögliche Ursache: WSDL v42.0 gibt bekanntermaßen Fehler für die Services Human_Resources (v42.0) und Resource_Management (v42.0) zurück. WSDL v42.1 gibt bekanntermaßen Fehler für den Service Human_Resources (v42.1) zurück. Dies sind bekannte Probleme, die spezifisch für diese WSDL-Versionen auftreten.
  • Lösung:
    1. Ändern Sie in der Workday-Verbindungskonfiguration die WSDL-Version für Operationen, die die Services Human_Resources oder Resource_Management verwenden, auf 41.x oder 43.0 oder höher.
    2. Testen Sie die Verbindung und führen Sie die betroffenen Operationen erneut aus, um zu bestätigen, dass das Problem behoben ist.

Workday: Verbindungstest schlägt mit „The task submitted is not authorized" fehl

  • Symptom: Ein Workday-Verbindungstest schlägt fehl mit:

    Error occurred while opening connection. The Exception is Processing error occurred. The task submitted is not authorized.

    Dieser Fehler kann bei beiden Authentifizierungstypen (Basic Auth und JWT Bearer) auftreten. Beachten Sie, dass Operationen zur Laufzeit erfolgreich ausgeführt werden können, auch wenn der Verbindungstest diesen Fehler zurückgibt, da der Test einen bestimmten Workday-Service (Get_Message_Template_Translation_Request) aufruft, für den eine Berechtigung erforderlich ist, die der ISU möglicherweise nicht hat, während die eigentlichen Integrationsvorgänge andere Services aufrufen.

  • Mögliche Ursachen:

    • Der Integration System User (ISU) wurde nicht der Sicherheitsgruppe Setup Administrator in Workday zugewiesen. Der Testverbindungsaufruf des Connectors wird abgelehnt, wenn dem ISU diese Sicherheitsgruppenmitgliedschaft fehlt.
    • Das Feld Workday Host enthält einen falschen Wert. Ein falscher Host führt dazu, dass die Verbindung fehlschlägt, bevor die Authentifizierung versucht wird.

  • Lösung:

    1. Überprüfen Sie, ob der Wert Workday Host in der Verbindungskonfiguration korrekt ist. Der Host sollte die Basis-URL Ihres Workday-Mandanten sein (z. B. https://wd5-impl-services1.workday.com/). Sie können den richtigen Wert auf der Workday-Seite View API Client bestätigen.
    2. Öffnen Sie in der Workday-Instanz die Aufgabe Assign Users to User-based Security Group (Benutzer Benutzergestützten Sicherheitsgruppen zuweisen), wählen Sie Setup Administrator aus, und bestätigen Sie, dass der ISU unter System Users aufgelistet ist. Fügen Sie den ISU hinzu, falls nicht. Vollständige Schritte finden Sie unter Voraussetzungen.
    3. Bestätigen Sie, dass die Aufgabe Configure Web Service Security auch für den ISU abgeschlossen wurde, wie auf der Seite Voraussetzungen beschrieben.
    4. Testen Sie die Verbindung erneut.