Zum Inhalt springen

Connector-Fehlerbehebung in Jitterbit Studio

Dieses Handbuch behandelt Fehler und unerwartetes Verhalten, die spezifisch für einzelne Jitterbit Studio-Connectoren sind und nach Connector organisiert sind. Es listet nur Connectoren auf, die bekannte, Connector-spezifische Probleme dokumentieren, 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 Ihren Connector im relevanten Abschnitt.

Informationen zu Problemen, die nicht spezifisch für einen Connector sind, z. B. ein Vorgang, der nicht ausgeführt wird, oder ein Problem mit einer Transformation, einem Skript oder einer Funktion, finden Sie unter Fehlerbehebung für Vorgänge. Bei Problemen mit privaten Agenten, z. B. ein Agent, der offline ist, fehlerhaft funktioniert oder langsam läuft (was Vorgänge vollständig stoppen kann), finden Sie Informationen unter Fehlerbehebung für private Agenten.

Eine einheitliche Referenz, die Probleme bei Integration, Automatisierung, API-Verwaltung, EDI und App-Entwicklung an einer Stelle abdeckt, finden Sie im Harmony-Fehlerbehebungshandbuch.

Alle Fehlerbehebungseinträge auf dieser Seite

Diagnoseschritte

Diese Schritte gelten für die meisten Connector-bezogenen Fehler und sind der empfohlene Ausgangspunkt vor der Untersuchung eines spezifischen Connector-Fehlers.

Verbindung testen

Klicken Sie 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 Automatische Connector-Aktualisierung deaktivieren nicht aktiviert ist.

Verbindungsmetadaten und Aktivitätsschemas aktualisieren

Viele Connector-Probleme wie fehlende Objekte, eine veraltete Feldliste oder ein Schema, das nicht mehr dem Endpunkt entspricht, werden durch zwischengespeicherte Metadaten verursacht. Nach jeder Änderung auf der Endpunktseite (neue Felder, eine API-Versionsaktualisierung oder eine Berechtigungsänderung) öffnen Sie die betroffene Aktivität erneut und klicken Sie auf das Aktualisierungssymbol (Aktualisieren), um Objekte und Schemas vom Endpunkt neu zu laden.

Connector-Verfügbarkeit bestätigen und aktuell halten

Die Spalte Agent availability in der Connectors-Liste zeigt, ob ein Connector einen privaten Agent erfordert.

Connectors werden gemäß Jitterbit's Veröffentlichungsplan unabhängig vom Agent veröffentlicht und aktualisiert. Auf privaten Agenten lädt das Testen einer Verbindung die neueste Version des Connectors herunter (siehe Verbindung testen oben), solange die Organisationsrichtlinie Disable Auto Connector Update nicht aktiviert ist. Um die Connectors für eine Agent-Gruppe jederzeit zu aktualisieren, auch wenn diese Richtlinie aktiviert ist, wählen Sie auf der Management Console-Seite Agents die Option Action > Update connectors für die Gruppe aus.

Connector Verbose Logging aktivieren

Aktivieren Sie auf Anweisung des Jitterbit Support das Connector Verbose Logging auf dem privaten Agent, um Details auf Connector-Ebene zu erfassen. Reproduzieren Sie dann das Problem und überprüfen Sie die Protokolle. Verbose Logging verwendet einen Connector-spezifischen Logger-Eintrag. Die genaue Zeile, die zu logback.xml hinzugefügt werden soll, finden Sie im Abschnitt Troubleshooting in der Dokumentationsseite des jeweiligen Connectors unter Connectors.

Verbindungskonfiguration

Advanced Configurations Properties: Variablen mit unformatiertem JSON müssen maskiert werden

  • Symptom: Viele Connectors enthalten eine Tabelle Advanced Configurations Properties für optionale Verbindungseinstellungen. Variablen, die in diesen Feldern verwendet werden und unformatierten JSON enthalten, müssen das JSON maskiert haben. Das Übergeben von unmaschiertem unformatierten JSON über eine Variable führt dazu, dass der Feldwert malformed ist.
  • Mögliche Ursache: Felder in der Tabelle Advanced Configurations Properties unterstützen keine Variablen, die unformatierte JSON-Objekte enthalten.
  • Lösung:
    • Bevor JSON-Inhalt über eine Variable in ein Feld Advanced Configurations Properties übermittelt wird, maskieren Sie das JSON. Beispiel: {"success": "true"} muss als {\"success\": \"true\"} maskiert werden, bevor es der Variablen zugewiesen wird.
    • Wenn Sie den JSON-Wert direkt in das Feld eingeben (nicht über eine Variable), ist eine Maskierung nicht erforderlich.
    • Variablen in Feldern Advanced Configurations Properties werden erst zur Laufzeit auf Agent-Version 10.75 / 11.13 oder später gefüllt. Wenn ein Variablenwert zur Laufzeit nicht angezeigt wird, bestätigen Sie, dass der Agent diese Mindestversion erfüllt.

Amazon Bedrock Connector

Amazon Bedrock: Modell-Fehler "on-demand throughput isn't supported"

  • Symptom: Eine Amazon Bedrock-Aktivität schlägt mit folgendem Fehler 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 keine On-Demand-Durchsätze und erfordern stattdessen die ID eines regionenübergreifenden Inferenzprofils anstelle der in der Liste Select a model zurückgegebenen Modell-ID.

  • Lösung:
    1. Gehen Sie in der AWS Management Console zu Amazon Bedrock > Inference profiles und suchen Sie die Inferenzprofil-ID für das Modell. Beispiel: Die Inferenzprofil-ID für anthropic.claude-3-5-haiku-20241022-v1:0 in den USA ist us.anthropic.claude-3-5-haiku-20241022-v1:0. Bei OpenAI's GPT-5.6 Modellen variieren gültige Inferenzprofil-ID-Präfixe je nach Modell und Region (z. B. us. oder global.), wie beispielsweise us.openai.gpt-5.6-terra oder global.openai.gpt-5.6-terra. Die genaue Inferenzprofil-ID für Ihr Modell und Ihre Region finden Sie in AWS Modellkarten für GPT-5.6 Sol, GPT-5.6 Terra und GPT-5.6 Luna.
    2. Geben Sie die Inferenzprofil-ID über die Option Enter model identifier in der Aktivitätskonfiguration ein.

Cloud-Datastore-Connector

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

  • Symptom: Eine Query Items-Aktivität, die mehrere spezifische Datensätze gleichzeitig nachschlagen soll (z. B. anhand einer Liste von Key-Werten), gibt nur einen Datensatz zurück, obwohl alle Datensätze im Speicher vorhanden sind und dies auf der Cloud Datastore-Seite in der Management Console bestätigt werden kann.
  • Mögliche Ursache: Der Filter der Abfrage kombiniert mehrere Bedingungen für dasselbe Feld (z. B. mehrere unterschiedliche 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 mehrfach angeben, und es können nicht mehrere Bedingungen oder Operatoren auf dasselbe Feld angewendet werden.
  • Lösung: Geben Sie für jeden Wert einen separaten Query Items-Aufruf aus, statt mehrere Werte desselben Feldes in einem Filter zu kombinieren. Einzelheiten 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-Aktivität Delete Items meldet im Operationsprotokoll Erfolg, aber der Zieldatensatz existiert weiterhin, wenn er danach abgefragt wird.
  • Mögliche Ursache: Delete Items identifiziert Datensätze anhand des Key- (oder Alternative Key-) Wertes des Speichers, der im keys- oder ids-Array der Anforderung angegeben ist. (Beide Arrays akzeptieren Schlüssel- oder alternative Schlüsselwerte.) Wird statt des Schlüsselwertes die interne ID des Datensatzes angegeben, stimmt kein Element überein, und die Aktivität meldet Erfolg, ohne etwas zu löschen.
  • Lösung:
    • In der Transformation, die die Delete Items-Anforderung vorbereitet, ordnen Sie den Key- (oder Alternative Key-) Wert des Speichers zu, nicht die interne Datensatz-ID.
    • Wenn eine Verkettung von einer Query Items-Aktivität erfolgt, ordnen Sie den key-Wert aus der Abfrageantwort der Löschanforderung zu.

Coupa-Connector

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

  • Symptom: Eine Connector-Operation von Coupa 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 nicht mehr für die Authentifizierung unterstützt. Verbindungen, die für die Verwendung von API-Schlüssel-Authentifizierung konfiguriert sind, erhalten einen 403-Fehler.
  • Lösung:
    1. Wechseln Sie in der Konfiguration der Coupa-Verbindung von der API-Schlüssel-Authentifizierung zu OAuth-2.0-Authentifizierung.
    2. Erstellen Sie in Ihrer Coupa-Instanz eine OAuth-2.0-Clientanwendung und besorgen Sie sich die Client-Anmeldedaten.
    3. Aktualisieren Sie die Verbindungskonfiguration mit den OAuth-2.0-Anmeldedaten, speichern Sie sie, und führen Sie einen erneuten Test durch.

Datenbankconnector

Datenbank (JDBC): DBLookup oder DBExecute schlägt mit Base64-Decodierungsfehler 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 Base64-codierten Daten ähnelt, wie etwa ein JWT oder anderer Zugriffstoken, obwohl die gleiche Abfrage bei direkter Ausführung gegen die Datenbank erfolgreich ist.

  • Mögliche Ursache: Agentversionen vor 12.9 versuchen möglicherweise fälschlicherweise, einen JDBC-Ergebniswert zu Base64-decodieren, der einem Base64-ähnlichen Muster entspricht, unabhängig davon, ob der Wert tatsächlich Base64-codierte Daten sind.

  • Lösung:

    • Bei Private Agents wird auf Version 12.9 oder später aktualisiert. Cloud Agents erhalten das Update automatisch.
    • Falls eine sofortige Aktualisierung nicht möglich ist, wird die Base64-Prüfung umgangen, indem der betroffene Wert in der SQL-Abfrage in Hexadezimalformat konvertiert wird und dann in einem Skriptschritt mit HexToString decodiert wird. Beispiel in PostgreSQL: SELECT encode(<column>, 'hex'). Bei dem Zurückschreiben des Werts in die Datenbank wird das entsprechende SQL decode(...,'hex') mit StringToHex verwendet.

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

  • Symptom: Beim Lesen oder Schreiben in eine Datenbank über den Datenbankconnector mit einem ODBC-Treiber werden Multibyte- oder Nicht-ASCII-Zeichen (beispielsweise Umlaute oder Nicht-Latin-Zeichen) nicht korrekt verarbeitet.
  • Mögliche Ursache: Die Unterstützung für Multibyte-Zeichen für den 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 wird bei Verwendung eines JDBC-Treibers nicht benötigt.

  • Lösung:

    1. Bestätigung, dass der Agent Version 12.6 oder später ausführt.

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

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

    Alternativ wird ein JDBC-Treiber für die Datenbankverbindung verwendet, welcher Multibyte-Zeichen ohne diese Variable verarbeitet.

Datenbank: Verbindung durch Sicherheitsrichtlinie blockiert

  • Symptom: Ein Datenbankconnector-Verbindungstest 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 bestimmten Verbindungsstring-Parameter:

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

  • Mögliche Ursache: Agent-Version 12.10 und später beschränkt standardmäßig bestimmte Datenbankverbindungen und Verbindungsstring-Parameter aus Sicherheitsgründen. Dies umfasst Verbindungen zu localhost oder 127.0.0.1 sowie bestimmte Verbindungsstring-Parameter für MySQL-, PostgreSQL-, Oracle- und SQL Server-Treiber. Eine Verbindung, die vorher funktioniert hat, kann nach der Aktualisierung eines Private Agents 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 den Agent neu.

Datenbank: Verbindungszeitüberschreitungen unter Last

  • Symptom: Datenquellen- oder Zieloperationen schlagen unter starker gleichzeitiger Last zeitweise fehl und zeigen eine ähnliche Ausnahme:

    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 anschließend, anstatt eine vorhandene wiederzuverwenden. Unter gleichzeitiger Last entsteht dadurch eine so hohe Verbindungsauslastung für die Zieldatenbank, dass es bei manchen Verbindungsversuchen zu Zeitüberschreitungen kommt.

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

Datenbank: Feldlängenfehler bei Insert, Update oder Upsert

  • Symptom: Eine Datenbank-Aktivität vom Typ Insert, Update oder Upsert schlägt mit dem Operationsstatus Fehler fehl, wenn ein zugeordneter Quellwert länger ist als die Zieldatenbank zulässt. Das Operationsprotokoll enthält eine der folgenden Meldungen:

    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 den Status Fehler, wenn ein zugeordneter Quellwert die definierte Länge der Zieldatenbank überschreitet, anstatt den Wert zu kürzen.

  • Lösung:
    1. Aktivieren Sie in der Konfiguration der Datenbank-Aktivität Insert, Update oder Upsert die Option Kürzung von Textfeldern zulassen, um Feldlängenfehler zu vermeiden. Mit dieser Option werden Werte, die die Zielfeld-Länge überschreiten, gekürzt und die Operation meldet den Status Erfolg mit Info anstelle von Fehler.
    2. Falls Kürzung nicht akzeptabel ist, kürzen oder transformieren Sie das Quellfeld in der Transformationszuordnung so, dass Werte die Zielspaltenlänge nie überschreiten, oder erweitern Sie die Zielspaltenlänge auf der Datenbankseite.
    3. Stellen Sie die Operation erneut bereit und führen Sie sie erneut aus.

Datenbank: JDBC-Treiber-JAR wird bei Agent-Aktualisierungen überschrieben

  • Symptom: Benutzerdefinierte JDBC-Treiber-JAR-Dateien, die für den Datenbank-Connector installiert wurden, werden gelöscht oder überschrieben, wenn der Agent aktualisiert wird.
  • Mögliche Ursache: Nur das Verzeichnis <JITTERBIT_HOME>/tomcat/drivers/lib/ wird bei Agent-Aktualisierungen beibehalten. Benutzerdefinierte Treiber-JAR-Dateien, die an anderen Stellen in den Agent-Verzeichnissen abgelegt werden, sind Teil der verwalteten Bereitstellung und können während einer Aktualisierung 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-Aktualisierungen beibehalten.
    • Falls sich Treiber derzeit an der falschen Stelle 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 mit Sonderzeichen wie @ enthält.
  • Mögliche Ursache: ODBC-Treiber können bestimmte Sonderzeichen in Datenbankspaltennamen nicht verarbeiten.
  • Lösung:
    1. Erstellen Sie eine Datenbankansicht in der physischen Tabelle, die die betroffene Spalte unter einem Namen bereitstellt, der keine Sonderzeichen enthält.
    2. Richten Sie die Datenbankaktivität auf die Ansicht anstelle der ursprünglichen Tabelle.

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

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

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

  • Symptom: Eine Datenbankverbindung zu IBM DB2 unter iSeries (AS/400 oder IBM i) mit einem JDBC-Treiber kann keine Verbindung herstellen.
  • Mögliche Ursache: Bei einigen Verbindungen zu DB2 unter iSeries mit einem JDBC-Treiber treten Probleme auf, die bei einem ODBC-Treiber nicht auftreten.
  • Lösung: Wechseln Sie die Verbindung zu einem ODBC-Treiber anstelle von JDBC. ODBC-Verbindungen werden nur auf privaten Agenten unterstützt.

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

  • Symptom: Eine Datenbankverbindung mit dem IBM DB2 JCC JDBC-Treiber schlägt mit einer Fehlermeldung fehl, die auf eine fehlende Lizenz verweist, oder schlägt fehl oder verursacht Kompatibilitätsfehler mit neueren DB2-Versionen.
  • Mögliche Ursachen:
    • Die Treiberdatei db2jcc.jar implementiert die veraltete JDBC-3-Spezifikation. Die aktuelle db2jcc4.jar implementiert JDBC 4, das neuere DB2-Versionen erfordern.
    • Der JCC-Treiber benötigt eine separate Lizenz-JAR-Datei. Die Treiber-JAR allein ist nicht ausreichend.
  • Lösung:
    • Verwenden Sie den Treiber db2jcc4.jar, nicht das veraltete db2jcc.jar. Installieren Sie diesen 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 in <JITTERBIT_HOME>/tomcat/shared/lib/.
    • Verwenden Sie alternativ die Open-Source-Bibliothek JTOpen (auch als AS400-Treiber bekannt), die weder den JCC-Treiber noch 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. Legen Sie auf dem privaten Agent-Host die Dateiberechtigungen für die Kerberos-Konfigurationsdateien (jaas.conf, krb5.conf und die Kerberos-Ticket-Cache-Datei) auf 644 fest:
chmod 644 jaas.conf krb5.conf krb5cc_agent
  1. Starten Sie den Agent neu, nachdem Sie die Berechtigungsänderungen angewendet haben.

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, wodurch sie die native GSSAPI-Bibliothek des Betriebssystems verwendet. 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 Kerberos-Datenverkehr zu erzwingen.
    3. Starten Sie den Agent neu.

Microsoft Excel: „Operation must use an updateable query"

  • Symptom: Eine Database-Aktivität vom Typ Insert oder Update für eine Microsoft-Excel-Datei (über ODBC) 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 schreibgeschützten Modus, sofern die Verbindungszeichenfolge nicht explizit den Lese-/Schreibmodus festlegt.

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

MySQL: Zugriff verweigert trotz korrekter Anmeldedaten

  • Symptom: Das Verbinden mit einer MySQL-Datenbank mithilfe des Database Connectors schlägt mit folgendem Fehler fehl:

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

    obwohl der Benutzername und das Passwort korrekt sind.

  • Mögliche Ursache: MySQL kann je nach Client-IP-Adresse unterschiedliche Berechtigungen gewähren. Ein Benutzerkonto kann über bestimmte IP-Adressen die erforderlichen Berechtigungen haben, aber nicht über die 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 ist je nach MySQL-Version unterschiedlich (siehe MySQL-Dokumentation oder kontaktieren Sie Ihren MySQL-Administrator), folgt aber grundsätzlich diesem Format:

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

    • Testen Sie die Verbindung mit einem MySQL-Client, der direkt auf dem Agent-Host installiert ist, um zu prüfen, ob das Problem netzwerkbasiert oder Jitterbit-spezifisch ist.

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

  • Symptom: Eine Database-Aktivität vom Typ Insert oder Update mit dem MySQL-JDBC-Treiber zeigt nach der Aktivierung von Enable Batch wenig oder keine Leistungsverbesserung, 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, anstatt ein echtes serverseitiges Batch durchzuführen.
  • Lösung: Fügen Sie im Feld Additional Connection String Parameters der Verbindung rewriteBatchedStatements=true hinzu.

MySQL: ODBC-Treiber nicht in der Studio-Dropdown-Liste aufgeführt

  • Symptom: Beim Konfigurieren einer Datenbankverbindung zu MySQL mit einem ODBC-Treiber auf einem privaten Agent wird der installierte Treiber nicht in der Dropdown-Liste Treiber in Studio angezeigt.
  • Mögliche Ursache: Der ODBC-Manager auf dem privaten Agent-Host zeigt den Treiber nicht an, normalerweise wegen eines Missverhältnisses zwischen 32-Bit und 64-Bit oder einer unvollständigen Treiberinstallation.
  • Lösung:
    • Öffnen Sie auf dem privaten Agent-Host (Windows) Datenquellen (ODBC) (unter Verwaltungsprogramme) und bestätigen Sie, dass der MySQL ODBC-Treiber aufgeführt ist. Informationen zu MySQL-Treiberoptionen finden Sie unter Mit MySQL verbinden.
    • Bestätigen Sie, dass der Agent sich mit dem richtigen Computer verbindet: Der ODBC-Treiber muss auf dem Agent-Host installiert sein, nicht auf dem Computer des Studio-Benutzers.

PostgreSQL: Fehler bei Client-Encoding-Mismatch

  • Symptom: Ein Datenbankverbindungs-Test zu PostgreSQL schlägt mit einem Fehler "Client-Encoding-Mismatch" fehl.
  • Mögliche Ursache: Die vom PostgreSQL-Server verwendete Codierung unterscheidet sich von der Standardcodierung, die vom PostgreSQL ODBC-Treiber vorausgesetzt wird.
  • Lösung:
    • Fügen Sie in den Datenbankverbindungseinstellungen ConnSettings=SET CLIENT_ENCODING to 'LATIN1' (ersetzen Sie durch die tatsächliche Codierung des Servers) zum Feld Zusätzliche Verbindungszeichenfolgen-Parameter hinzu.
    • Legen Sie unter Windows, wenn der Server eine kyrillische Codierung wie WIN1251 verwendet, die Client-Codierung in den ODBC-Treibereinstellungen auch auf WIN1251 fest.

PostgreSQL: Verwenden Sie den von Jitterbit bereitgestellten Treiber unter Linux

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

SQL Server JDBC: Windows-Authentifizierung mit integrierter Authentifizierung schlägt fehl

  • Symptom: Bei privaten Agents schlägt eine Datenbankverbindung zu SQL Server mit einem JDBC-Treiber und Windows-integrierter 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-integrierte 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 for SQL Server: Die Datei mssql-jdbc_auth DLL, die für die Windows-integrierte Authentifizierung erforderlich ist, fehlt in den JRE-Verzeichnissen, die der Jitterbit-Agent zur Laufzeit verwendet. Das Platzieren der DLL im gleichen Verzeichnis wie die JDBC JAR-Datei ist nicht ausreichend.
    • Die Verbindungszeichenfolge enthält nicht die erforderlichen Parameter für Ihren Treiber.

  • Lösung: Wähle die Option, die zu deinem JDBC-Treiber passt:

    • SQL Server jTDS:
      1. Kopiere auf dem Host des privaten Agenten ntlmauth.dll (aus dem Ordner x64/SSO des jTDS-Projektdownload-Pakets) in <JITTERBIT_HOME>/jre/bin.
      2. Füge in den Datenbankverbindungseinstellungen integratedSecurity=true zum Feld Zusätzliche Verbindungszeichenfolgen-Parameter hinzu.
      3. Starte den Jitterbit-Agent-Dienst neu.
    • SQL Server MS JDBC oder neuere Microsoft JDBC Driver für SQL Server:
      1. Kopiere auf dem Host des privaten Agenten mssql-jdbc_auth-x.x.x.x64.dll (aus der JDBC-Treiberverteilung, mit der Version, die der JDBC-JAR-Datei gebündelt mit deinem Agent entspricht) in beide Verzeichnisse: <JITTERBIT_HOME>/jre/bin und <JITTERBIT_HOME>/jre/lib. Erstelle eine Sicherung der Datei, da diese während größerer Agent-Upgrades entfernt werden kann.
      2. Füge in den Datenbankverbindungseinstellungen integratedSecurity=true;trustServerCertificate=true zum Feld Zusätzliche Verbindungszeichenfolgen-Parameter hinzu.
      3. Starte den Jitterbit-Agent-Dienst neu.

SQL Server Windows-Authentifizierung: Unzureichende Berechtigungen

  • Symptom: Eine Datenbankverbindung mit SQL Server Windows-Authentifizierung schlägt fehl, obwohl die Domänenanmeldedaten korrekt 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-integrierte Sicherheit.
  • Lösung:
    1. Gewähre dem Domänenbenutzer auf dem Host des privaten Agenten die Windows-Berechtigungen Anmelden als Dienst und Agieren als Teil des Betriebssystems.
    2. Bestätige, dass der Domänenbenutzer Lese- und Schreibberechtigungen für das Installationsverzeichnis des Jitterbit-Agenten hat.
    3. Starte den Jitterbit-Agent-Dienst neu, nachdem du die Berechtigungen angewendet hast.

SQL Server: „Expliziter Wert kann nicht in Identitätsspalte eingefügt werden" beim Einfügen in eine Identitätsspalte

  • Symptom: Ein Vorgang des Datenbankconnectors, der in eine SQL Server-Tabelle mit einer Identitätsspalte schreibt, schlägt fehl mit:

    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 Datenbankconnector für das Ziel generiert. SQL Server lehnt eine INSERT ab, die eine Identitätsspalte in ihrer Spaltenliste referenziert (mit einem expliziten Wert oder einem Nullwert), während IDENTITY_INSERT auf OFF gesetzt ist. Die Zuordnung des Felds zu einem Nullwert schließt es nicht aus: Ein Zielfeld wird aus der INSERT nur dann weggelassen, wenn es mit der Funktion Unmap zugeordnet ist.

  • Lösung:

    • Um SQL Server die Identitätswert automatisch zuweisen zu lassen, schließe die Spalte aus der INSERT aus, indem du das Zielfeld der Identität mit der Funktion Unmap zuordnest. Um die Spalte nur auszuschließen, wenn die Quelle keinen Wert bereitstellt, verwende eine bedingte Zuordnung:

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

      Wenn die Bedingung falsch ist, entfernt Unmap die Spalte aus der INSERT und SQL Server weist den nächsten Identitätswert zu. (Das Angeben eines expliziten Werts im wahren Zweig erfordert weiterhin, dass IDENTITY_INSERT auf ON gesetzt ist; siehe die nächste Option.)

    • Wenn du explizite Werte in die Identitätsspalte einfügen musst, setze 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. Dies ermöglicht es, explizite Werte in die Identitätsspalte einzufügen.

SQL Server: Verbindung schlägt mit PKIX-Zertifikatpfad-Fehler 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 funktionierte, kann nach einem Agent-Upgrade auf Version 12.8 oder später fehlschlagen.

  • 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, z. B. ein selbstsigniertes Zertifikat, ein intern ausgestelltes Zertifikat oder das Amazon-RDS-CA-Zertifikat, das eine Amazon RDS für SQL Server-Instanz präsentiert. Dies ist ein Fehler des Zertifikatvertrauens und nicht 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 vor diesem Upgrade konfigurierte Verbindung danach fehlschlagen.

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

    Warnung

    Bei encrypt=false werden Daten zwischen dem Agent und der Datenbank unverschlüsselt übertragen. Verwenden Sie diese Option nur, wenn dies für die betroffenen Daten und den Netzwerkpfad akzeptabel ist.

EDI for Cloud v2-Connector

Fehlerbehebungseinträge für den EDI for Cloud v2-Connector sind im EDI-Fehlerbehebungshandbuch zusammen mit Jitterbit-EDI-Problemen dokumentiert. Relevante Einträge umfassen:

E-Mail-Connector

Gmail-Verbindungstest schlägt mit Authentifizierungsfehler fehl

  • Symptom: Ein Verbindungstest zu einem Gmail-Konto mit Basis-Authentifizierung schlägt mit einem Authentifizierungsfehler fehl, auch wenn das richtige Google-Kontopasswort eingegeben wird.
  • Mögliche Ursache: Google erfordert ein App-Passwort für Konten mit aktivierter Zwei-Faktor-Authentifizierung. Das Google-Kontopasswort wird von SMTP oder IMAP nicht akzeptiert, wenn die Zwei-Faktor-Authentifizierung 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 Google's Mit App-Passwörtern anmelden-Seite).
    2. Geben Sie in der E-Mail-Verbindungskonfiguration in Studio das App-Passwort im Feld SMTP-Passwort und/oder IMAP-Passwort statt des Google-Kontopassworts ein.

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 ist nur bei Verwendung von privaten Agenten funktionsfähig. Wenn der Vorgang auf einem Cloud-Agent ausgeführt wird, ist die S/MIME-Signierung unabhängig vom Zertifikattyp nicht anwendbar.
  • Lösung:
    1. Besorgen Sie sich ein S/MIME-Zertifikat von einer vertrauenswürdigen CA. Let's Encrypt stellt kostenlose Zertifikate bereit, die von großen Cloud-Anbietern akzeptiert werden.
    2. Ersetzen Sie das selbstsignierte Zertifikat in der E-Mail-Aktivität E-Mail senden durch das von der CA ausgestellte Zertifikat (siehe Voraussetzungen für S/MIME-Verschlüsselung).
    3. Bestätigen Sie für private Agenten, dass das Zertifikat ordnungsgemäß in den Standard-Truststore des Agenten importiert wurde. Für 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 die ROPC-Authentifizierung (Resource Owner Password Credentials) verwendet, kann sich nicht authentifizieren, auch wenn der Benutzername, das Kennwort, die Client-ID, die Mandanten-ID und das Client-Geheimnis alle korrekt sind.
  • Mögliche Ursache: Die ROPC-Authentifizierung erfordert, dass die mehrstufige Authentifizierung (MFA) für die Microsoft 365-Anmeldedaten deaktiviert ist, die mit dem Connector verwendet werden. Die ROPC-Bewilligung kann eine MFA-Anforderung nicht 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 MFA nicht erzwingt, wie in Voraussetzungen für Microsoft 365 beschrieben.
    • Wenn MFA nicht aus dem Konto entfernt werden kann, verwenden Sie für die Verbindung eine andere unterstützte Authentifizierungsmethode anstelle von ROPC.

E-Mail senden schlägt fehl, wenn dieselbe Adresse in mehreren Empfängerfeldern angezeigt wird

  • Symptom: Eine E-Mail-Aktivität E-Mail senden 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 lässt nicht zu, dass dieselbe Adresse in einer einzelnen Sendeanforderung in mehreren Empfängerfeldern angezeigt wird. 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 zu bestätigen, dass keine Adresse in mehr als einem Feld angezeigt wird.
    • Wenn Empfängerlisten dynamisch mit Variablen oder Skripten zusammengestellt werden, fügen Sie vor dem Übergeben von Adressen an die Aktivität eine Deduplizierungsprüfung hinzu.

Epicor-Connectoren

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 der Filter String mehr als eine Filterbedingung enthält, obwohl die Aktivität in Studio gültig erscheint.
  • Mögliche Ursache: Eine Beschränkung der Epicor Prophet 21 Middleware API verhindert die Verarbeitung mehrerer Filterbedingungen. Der Vorgang erscheint in Studio gültig, schlägt jedoch zur Laufzeit fehl, wenn mehr als ein Filter vorhanden ist.
  • Lösung:
    • Den Filter String auf eine einzelne Filterbedingung reduzieren.
    • Falls mehrere Filterbedingungen erforderlich sind, ein breiteres Ergebnisset mit einem einzelnen Filter abrufen und die zusätzliche Filterung in einem Transformations- oder Skriptschritt nach der Aktivität anwenden.

Datei-Connectoren

FTP, File Share und Local Storage: „Keine Dateien stimmen mit dem Dateifilter überein" bei Archivierungs- oder Folgeschritten

  • Symptom: Eine FTP-, File Share- oder Local Storage-Leseaktivität schlägt fehl, weil sich die zu lesende Datei 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 bei einem späteren Schritt (häufig ein Archivierungs- oder Benachrichtigungsschritt) auf, der versucht, dieselbe Datei mit demselben Filter zu lesen.

  • Mögliche Ursachen:

    • Die Verarbeitungsaktivität hat die Quelldatei bereits als Teil ihres After Processing-Verhaltens verschoben oder gelöscht, daher hat der Archivierungsschritt nichts mehr zum Abgleichen.
    • Ein untergeordneter Vorgang wird asynchron gestartet und der übergeordnete Vorgang versucht, die Ausgabedatei des untergeordneten Vorgangs zu lesen, bevor dieser das Schreiben beendet hat.
    • Eine FTP Write-Aktivität mit aktiviertem Use FTP Rename (Standard) schreibt die Datei unter einem temporären Namen und benennt sie bei Abschluss in den endgültigen Namen um. Ein nachgelagerter Lesevorgang, der vor Abschluss der Umbenennung ausgelöst wird, findet die Datei nicht.
  • Lösung:
    • Bestätigen, ob der vorherige Schritt die Archivierung bereits über seine integrierten After Processing-Optionen (verschieben, umbenennen, löschen) durchgeführt hat. Falls ja, ist ein separater Archivierungsschritt redundant und sollte entfernt werden.
    • Falls ein separater Archivierungsschritt erforderlich ist, die Kette neu gestalten, damit Verarbeitung und Archivierung gegen dieselbe In-Memory-Dateireferenz erfolgen, anstatt erneut aus der Quelle zu lesen. Beispielsweise den gelesenen Inhalt über Temporary Storage zum Archivierungsschritt durchreichen, anstatt den Quellpfad erneut zu lesen.
    • Falls ein Folgeschritt eine Ausgabe liest, die von einem untergeordneten Vorgang produziert wird, den untergeordneten Vorgang synchron ausführen, sodass die Ausgabe vor dem Lesen vorhanden ist. Den Run type des Invoke Operation-Tools auf Synchronously setzen oder beim Aufrufen des Vorgangs aus einem Skript RunOperation synchron ausführen (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 Write-Aktivität an denselben Speicherort schreibt, prüfen, ob Use FTP Rename auf der FTP Write-Aktivität aktiviert ist. Falls der nachgelagerte Lesevorgang vor Abschluss der Umbenennung ausgelöst wird, Use FTP Rename auf der Schreibaktivität deaktivieren oder sicherstellen, dass der Lesevorgang nicht ausgeführt wird, bis die Schreibaktivität vollständig abgeschlossen ist.

FTP, File Share und lokaler Speicher: Fehlerordner wird bei Verbindungsfehler nicht geschrieben

  • Symptom: Nach einem Fehler bei einer FTP-, File Share- oder Local Storage-Aktivität erscheint keine Datei im konfigurierten Fehlerordner.
  • Mögliche Ursache: Der Fehlerordner ist dafür konzipiert, nach einer fehlgeschlagenen Verarbeitung eine Kopie der Quelldatei zu archivieren. Er erfasst Dateien nur, wenn die Aktivität ausgeführt wird und dann fehlschlägt (beispielsweise ein Schreibberechtigungsfehler 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:
    • Wenn der Fehlerordner nach einem Fehler leer ist, überprüfen Sie die Vorgangsprotokolle auf einen Fehler auf Verbindungsebene (beispielsweise ein Authentifizierungsfehler oder eine Meldung, dass der Host unerreichbar ist).
    • Verwenden Sie die Schaltfläche Testen für die Verbindung, um zu überprüfen, ob das Problem auf Netzwerk- oder Authentifizierungsebene liegt.

FTP, File Share und lokaler Speicher: 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 erweiterten Schlüsselworttext anstelle aufgelöster Werte. Der Vorgang kann fehlschlagen oder Dateien an unerwartete Speicherorte schreiben.
  • Mögliche Ursachen:
    • Die Felder für den Erfolgsordner und den Fehlerordnerpfad in FTP-, File Share- und Local Storage-Aktivitäten unterstützen keine Ersetzung von Dateiname-Schlüsselwörtern. Variablen werden in diesen Feldern nicht erweitert.
    • Diese Felder verweisen auf Verzeichnisse auf dem Private-Agent-Computer und nicht auf dem Remote-Server. Relative Pfade werden relativ zum Dateisystem des Agent-Hosts interpretiert.
  • Lösung:
    • Verwenden Sie nur wörtliche Pfade (ohne Dateiname-Schlüsselwortvariablen) für die Erfolgs- und Fehlerordnerfelder.
    • Wenn dynamische Pfade erforderlich sind, fügen Sie nach der Aktivität einen Skriptschritt hinzu, um die verarbeitete Datei mithilfe von Dateienfunktionen an den gewünschten Speicherort zu verschieben oder umzubenennen.

FTP, File Share, lokaler Speicher und temporärer Speicher: „Kopfzeilen schreiben" erzeugt keine Datei nur mit Kopfzeile, wenn die Quelle keine Datensätze zurückgibt

  • Symptom: Eine dateibasierte Schreibaktivität mit aktivierter Option Kopfzeilen schreiben (FTP Write, File Share Write, Local Storage Write oder Temporary Storage Write) schreibt keine Kopfzeilen, wenn die Quelle keine Datensätze zurückgibt. Es wird entweder eine leere Datei erstellt oder überhaupt keine Datei erstellt (wenn auch Keine leeren Dateien erstellen ausgewählt ist).
  • Ursache: Dies ist das erwartete Verhalten. Kopfzeilen 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, daher wird keine Ausgabe (einschließlich Kopfzeilen) geschrieben, und Studio protokolliert eine Warnung, dass die Quelle leer ist. Dies ist nicht spezifisch für einen bestimmten Quellkonnektor oder ein flaches Dateiziel.

FTP: Operation schlägt nach vielen schnellen Anmeldungen auf demselben Server fehl

  • Symptom: Eine Operation mit dem FTP-Connector (über das FTP- oder SFTP-Protokoll), der sich in schneller Folge mehrmals beim selben Server authentifiziert (z. B. beim Lesen von Hunderten von kleinen Dateien in einer Schleife oder bei vielen Operationen, die nach einem Zeitplan auf demselben Server ausgeführt werden), schlägt schließlich mit einer Anmeldungsverweigerung oder einem Verbindungsfehler fehl. Dieselbe Operation funktioniert unter leichterer Last.
  • Mögliche Ursachen:
    • Der FTP-Connector öffnet und authentifiziert für jede Activity-Ausführung eine neue Verbindung und schließt sie, wenn die Operation endet; eine Session wird nicht über Activities, über Operation-Durchläufe oder über Projekte hinweg wiederverwendet. Dies ist beabsichtigt. Wenn viele Operationen auf demselben Server ausgeführt werden, beispielsweise mehrere geplante Operationen oder mehrere Projekte, die auf denselben Host abzielen, authentifiziert sich jeder Durchlauf unabhängig.
    • Der Remote-Server ist mit einer maximalen Anzahl von Verbindungen, Authentifizierungen pro Minute oder gleichzeitigen Sessions pro Benutzer konfiguriert, und die kombinierte Jitterbit-Anmeldungsrate überschreitet diesen Grenzwert.
  • Lösung:
    • Gestalten Sie die Operation nach Möglichkeit so um, dass weniger Verbindungen erforderlich sind. Ersetzen Sie eine Read-Activity in einer Schleife durch eine einzelne Read-Activity, die einen Platzhalter im Feld Get Files verwendet (z. B. *.xml oder data_*.csv), und teilen Sie die abgerufenen Daten dann in einzelne Records in einer Transformation auf.
    • Wenn die Operation Dateien einzeln verarbeiten muss, bitten Sie den FTP-Server-Administrator, den Grenzwert pro Benutzer für gleichzeitige Verbindungen oder Authentifizierungen pro Minute zu erhöhen.

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

  • Symptom: Eine SFTP-Operation mit SSH-Private-Key-Authentifizierung schlägt mit Login denied. Authentication failure. fehl, obwohl sich dieselben Schlüssel von einem interaktiven SFTP-Client aus erfolgreich 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 in der [SSH]-Sektion der Datei jitterbit.conf des Agenten.
    • Im FTP-Endpoint ist neben dem privaten Schlüssel ein Passwort konfiguriert. Das Vorhandensein eines Passworts in den Endpoint-Einstellungen beeinträchtigt die schlüsselbasierte Authentifizierung.

  • Lösung:

    • Bestätigen Sie bei privaten Agenten, dass die [SSH]-Sektion von jitterbit.conf den korrekten PrivateKeyFile-Pfad und, falls der Schlüssel mit einer Passphrase geschützt ist, den entsprechenden PrivateKeyPassphrase-Wert enthält (siehe Verbindung zu SFTP mit SSH-Schlüsseln).
    • Löschen Sie im FTP-Endpoint-Konfiguration das Feld Password, wenn die Authentifizierung per SSH-Schlüssel erfolgt.
    • Bestätigen Sie, dass der Schlüssel in einem vom Agent unterstützten Format (OpenSSH) vorliegt. Konvertieren Sie den Schlüssel mit ssh-keygen, falls er im PuTTY-Format (.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-Write-Activity mit der Option Use FTP Rename schlägt fehl, wenn das Ziel ein SFTP-Server ist, mit einem Fehler ähnlich wie:

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

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

  • Mögliche Ursachen:

    • Bei Agenten vor Version 11.56 funktioniert die Option Use FTP Rename beim Schreiben auf einen SFTP-Server nicht zuverlässig, besonders bei Archive-Pattern-Operationen.

  • 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 Use FTP Rename lädt der Agent die Datei jedoch unter einem temporären Namen (Suffix -jbupload) hoch und benennt sie dann um, und wenn der Server die Multibyte-Namen nicht umbenennen kann, wird eine irreführende Fehlermeldung Permission denied zurückgegeben. Dateinamen mit nur ASCII-Zeichen sind nicht betroffen. Dies ist eine Beschränkung des SFTP-Servers und nicht von Jitterbit.

  • Lösung:

    • Stellen Sie sicher, dass der Agent Version 11.56 oder höher ist, wobei Use FTP Rename mit SFTP wie erwartet funktioniert. Cloud-Agenten werden automatisch aktualisiert. Aktualisieren Sie private Agenten bei Bedarf.

    • Deaktivieren Sie das Kontrollkästchen Use FTP Rename in der Aktivitätskonfiguration, damit der Agent direkt in den Zielpfad schreibt, anstatt unter einem temporären Namen hochzuladen und umzubenennen. Dies vermeidet den Umbenennungsschritt und behebt beide Ursachen.

    • Für den Multibyte-Fall können Sie alternativ einen SFTP-Server verwenden, der das Umbenennen von Dateien mit Multibyte-Namen unterstützt.

SFTP: Anfügen an Datei wird nicht unterstützt

  • Symptom: Eine FTP-Aktivität Schreiben, die mit der Option Append To File konfiguriert ist, fügt nicht an die bestehende Datei an, wenn das Ziel ein SFTP-Server ist.
  • Mögliche Ursache: Das SFTP-Protokoll unterstützt das Anfügen an bestehende Dateien nicht. Dies ist eine Beschränkung auf Protokollebene und kein Jitterbit-Konfigurationsproblem.
  • Lösung:
    • Verwenden Sie FTP oder FTPS, wenn das Anfügeverhalten erforderlich ist.
    • Wenn SFTP erforderlich ist, implementieren Sie die Anfügelog manuelle: Lesen Sie den Inhalt der bestehenden Datei, kombinieren Sie ihn mit den neuen Daten und schreiben Sie das vollständige 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 erzeugt einen abgeschnittenen Dateinamen.
  • Mögliche Ursache: Der FTP-Connector behandelt den Dateipfad als URL, in der das Hash-Zeichen ein reserviertes Fragment-Trennzeichen ist. Der Connector verarbeitet den Teil des Pfads vor dem # 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.
    • Um den Connector so zu verwenden, dass Namen mit Sonderzeichen wie # URL-kodiert werden, setzen Sie jitterbit.source.ftp.encode_url in einem Transformationsskript für Quellnamen auf true und jitterbit.target.ftp.encode_url auf true für Dateien, die ins Ziel geschrieben werden.

Dateifreigabe: UNC-Pfade mit Servernamen schlagen auf Cloud-Agenten fehl

  • Symptom: Dateifreigabe-Verbindungen, die UNC-Pfade verwenden (z. B. \\server\share), können nicht verbunden werden, wenn der Vorgang auf einem Cloud-Agent ausgeführt wird.
  • Mögliche Ursache: Cloud-Agenten können UNC-Pfade mit einer öffentlichen IP-Adresse auflösen, können aber keine Servernamen in UNC-Pfaden 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 Servername-Auflösung in UNC-Pfaden erforderlich ist, verwenden Sie stattdessen einen privaten Agent.

Dateifreigabe: Dateien größer als 2 GB können möglicherweise nicht abgerufen werden

  • Symptom: Eine Dateifreigabe-Aktivität vom Typ Lesen kann möglicherweise einzelne Dateien größer als 2 GB nicht abrufen. Kleinere Dateien werden ohne Probleme abgerufen.
  • Mögliche Ursache: Der Dateifreigabe-Connector hat eine bekannte Einschränkung bei einzelnen Dateien größer als 2 GB.
  • Lösung: Es gibt keine Konfigurationsoption, die diese Grenze entfernt. Teilen Sie die Datei als Abhilfemaßnahme an der Quelle in kleinere Segmente auf, sodass jede Datei unter 2 GB liegt, bevor die Dateifreigabe-Aktivität Lesen sie abruft.

Lokaler Speicher: Nicht auf Cloud-Agents verfügbar

  • Symptom: Ein Vorgang mit einem Lokaler Speicher-Connector schlägt fehl, wenn er auf einem Cloud-Agent ausgeführt wird.
  • Mögliche Ursache: Der lokale Speicher greift auf das Dateisystem auf dem Computer zu, auf dem der Agent installiert ist. Cloud-Agents werden in einer gehosteten Umgebung ausgeführt und stellen kein lokales Dateisystem für diesen Zweck bereit.
  • Lösung:
    • Verwenden Sie private Agents für alle Vorgänge, die den Connector für lokalen Speicher erfordern. Der lokale Speicher ist auf privaten Agents standardmäßig deaktiviert. Aktivieren Sie ihn daher auch in der Konfigurationsdatei des privaten Agents (siehe Lokalen Dateispeicherort aktivieren).
    • Ersetzen Sie für Cloud-Agent-Workflows den lokalen Speicher durch Temporärer Speicher oder einen externen Speicher-Connector (Dateifreigabe, FTP oder Cloud Datastore).

Temporärer Speicher: Dateien fehlen beim Lesen durch einen späteren Vorgang

  • Symptom: Temporärer Speicher-Dateien, die von einem Vorgang geschrieben wurden, fehlen, wenn ein späterer Vorgang versucht, sie zu lesen.
  • Mögliche Ursachen:
    • Der Cleanup-Service von Harmony löscht Dateien nach 24 Stunden standardmäßig aus dem temporären Speicher.
    • Jeder Agent in einer Agent-Gruppe hat seinen eigenen lokalen temporären Speicher. Vorgänge in der gleichen Vorgangskette werden garantiert auf dem gleichen Agent ausgeführt. Ein späterer Vorgang, der sich nicht in der gleichen Kette befindet, kann jedoch auf einen anderen Agent verteilt werden und auf eine andere Instanz des temporären Speichers zugreifen. Daher findet er die Datei unabhängig vom 24-Stunden-Fenster nicht. Siehe Wichtige Hinweise.
  • Lösung:
    • Verknüpfen Sie Vorgänge, die Dateien des temporären Speichers gemeinsam nutzen müssen, in die gleiche Vorgangskette mit Vorgangsaktionen, wobei das Verhalten des temporären Speichers konsistent und zuverlässig ist.
    • Bei privaten Agents kann die Cleanup-Häufigkeit im Bereich [FileCleanup] der Datei jitterbit.conf angepasst werden. Siehe [FileCleanup].
    • Falls Dateien nicht in der gleichen Kette verarbeitet werden können oder länger als 24 Stunden erhalten bleiben müssen, verwenden Sie stattdessen einen persistenten Speicher-Connector, auf den alle Agents zugreifen können (z. B. Dateifreigabe, FTP oder Cloud Datastore).

Temporärer Speicher: Eingeschränkte Zeichen in Dateipfaden

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

Temporärer Speicher: Dateigrößenlimit von 50 GB bei Cloud-Agenten

  • Symptom: Eine Temporärer Speicher-Write-Aktivität schlägt fehl, wenn große Dateien über einen Cloud-Agenten geschrieben werden.
  • Mögliche Ursache: Cloud-Agenten setzen eine maximale Dateigröße von 50 GB pro Datei für Temporären Speicher durch.
  • Lösung:
    • Verwenden Sie einen privaten Agenten für Workflows, die einzelne Dateien größer als 50 GB in den Temporären Speicher schreiben müssen.
    • Falls nur Cloud-Agenten verfügbar sind, teilen Sie große Datenmengen in mehrere Dateien von weniger als 50 GB auf, bevor Sie diese in den Temporären Speicher schreiben.

HTTP-Connector

HTTP v2: Doppelter Authorization-Header verursacht 400 Bad Request

  • Symptom: HTTP v2-Connector-Operationen schlagen mit einem 400-Fehler fehl, wenn sowohl die 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 bei 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 widersprechenden 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 zur Handhabung der Authentifizierung. Fügen Sie neben der konfigurierten Authentifizierung keinen manuellen Authorization-Header hinzu.
    • Wenn Sie den Authorization-Header auf der Aktivitätsebene dynamisch setzen müssen, legen Sie den Authentifizierungstyp der Verbindung auf No Auth fest und konfigurieren Sie den Authorization-Request-Header der Aktivität wie erforderlich.

HTTP v2: JSON-Wert in einer Request-Header-Projektvariablen kann nicht analysiert werden

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

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

    Derselbe JSON funktioniert, wenn er direkt in die Spalte Value der Tabelle Request Headers eingefügt wird.

  • Mögliche Ursache: Wenn ein Request-Header-Wert aus einer Projektvariablen gelesen wird, maskiert der HTTP v2-Connector die eingebetteten Anführungszeichen nicht so, wie es der Fall ist, wenn Sie den Wert direkt in die Tabelle Request Headers eingeben. Die unmaskierten Anführungszeichen unterbrechen die Header-Zeichenfolge, bevor sie das Ziel erreicht.

  • Lösung:
    • Wenn Sie JSON in einer Projektvariablen speichern, das als Header-Wert verwendet wird, maskieren Sie jedes doppelte Anführungszeichen mit einem Backslash. Speichern Sie den Wert beispielsweise als {\"success\": \"true\"} statt {"success": "true"}.
    • Falls der JSON-Inhalt statisch ist, fügen Sie ihn direkt in die Spalte Value der Tabelle Request Headers ein, statt eine Variable zu verwenden. Der Connector wendet die erforderliche Maskierung in diesem Fall automatisch an.

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

  • Symptom: Ein HTTP- oder HTTP v2-Vorgang schlägt im Zielsystem fehl. Die Agent-Logs zeigen, dass die Anfrage-URL mehr als ein ? zwischen Segmenten enthält, beispielsweise 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 statt eines & ein zweites ? ein.
  • Lösung:
    • Entfernen Sie jeden Abfrage-String-Segment aus dem URL-Pfad. Die Basis-URL sollte nur den Pfad selbst enthalten (beispielsweise https://api.example.com/endpoint).
    • Definieren Sie jeden Abfrageparameter in der Tabelle Request Parameters der Aktivität. Der Connector fügt die Zeichen ? und & automatisch beim Konstruieren der endgültigen URL ein.

HTTP v2: Doppelte URL-Codierung bei aktivierter Option „Encode request URL"

  • Symptom: REST-API-Aufrufe über den HTTP v2-Connector schlagen im Zielsystem fehl, da URL-Parameter in der ausgehenden Anfrage doppelt codiert sind (beispielsweise 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 Senden. Falls 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 mithilfe der Funktion URLEncode konstruiert werden.
    • 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 die Basis-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, anstatt 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 Pfad der Aktivität werden nicht aufgelöst

  • Symptom: Eine HTTP v2-Aktivität verwendet eine globale, Projekt- oder Jitterbit-Variable im Feld Path, doch zur Laufzeit wird die Variable buchstäblich (unaufgelöst) gesendet, anstatt durch ihren Wert ersetzt zu werden.
  • Mögliche Ursache: Eine vollständige URL (eine, die Protokoll und Host enthält, wie https://api.example.com/...) wurde im Feld Path eingegeben. Variablen werden in vollständigen URLs nicht unterstützt. Sie werden nur in einem Teilpfad 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 Hostteil des Endpunkts fest (beispielsweise https://api.example.com).
    2. Geben Sie im Feld Path der Aktivität nur den Teilpfad ein, der der Basis-URL folgt, und platzieren Sie die Variable innerhalb dieses Teilpfads (beispielsweise /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 Zielvariablen 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 Zielvariablen nicht auf. Antwortdaten, einschließlich des HTTP-Status-Codes, werden stattdessen durch das Antwortschemata der Aktivität zurückgegeben.
  • Lösung:
    • Um den Status-Code mit dem Standard-Antwortschemata zu erfassen, 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 Antwortschematas finden Sie in der Aktivitätskonfigurationsdokumentation für jede HTTP v2-Aktivität.
    • Um den Status-Code bei Verwendung eines benutzerdefinierten Antwortschematas zu erfassen, aktivieren Sie Zusätzliche Eigenschaften aus der HTTP-Antwort in das Schema einschließen in der Aktivitätskonfiguration. Dies umhüllt das Schema mit einer von Jitterbit definierten Struktur, die __jitterbit_api_statuscode__ (der Status-Code) und __jitterbit_api_errorbody__ (der Antwortkörper bei fehlgeschlagenen Anfragen) enthält.
    • Damit der Status-Code verfügbar ist, wenn die API eine nicht erfolgreiche Antwort zurückgibt, aktivieren Sie Operationsfehler bei nicht erfolgreichem Status-Code ignorieren in den optionalen Einstellungen der Aktivität. Ohne diese Einstellung schlägt die Operation bei nicht erfolgreichen Antworten fehl, bevor die Antwortdaten zugeordnet werden können.

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

  • Symptom: Eine HTTP v2-Operation, die eine XML-Nutzlast an einen SOAP- oder XML-Webdienst sendet, schlägt mit einem Serverfehler (z. B. 500 Internal Server Error) fehl, obwohl die gleiche Nutzlast erfolgreich vom Postman oder SoapUI gesendet wird. Bei der Überprüfung des Anfragekörpers, den das Ziel empfängt, wird deutlich, dass XML-Namespace-Deklarationen auf das Wurzelelement konsolidiert wurden und die ursprünglichen Namespace-Präfixe durch generische ersetzt wurden (z. B. wird soapenv:Envelope zu Envelope xmlns="...", und Element-Präfixe werden als ns, ns1, ns2 umnummeriert).
  • Mögliche Ursache: Wenn in der HTTP v2-Aktivitätskonfiguration ein benutzerdefiniertes Anforderungsschema verwendet wird, normalisiert die Transformation standardmäßig die XML-Datei, indem alle Namespace-Deklarationen auf den Wurzelknoten verschoben und ihre Präfixe neu zugewiesen werden. SOAP-Dienste und andere XML-Endpunkte, die die Konsistenz von Namespace-Präfixen validieren, lehnen die geänderte Nutzlast ab.

  • Lösung:

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

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

    • Wenn Ihre privaten Agents älter als 12.8 sind, oder wenn das Ziel auch die Konsolidierung von Namespace-Deklarationen auf dem Wurzelelement ablehnt, verwenden Sie das Standard-Anforderungsschema anstelle eines benutzerdefinierten und ordnen Sie die komplette XML-Nutzlast als Zeichenfolge dem Feld body des Schemas zu. Die Nutzlast wird dann als Zeichenfolge behandelt und nicht als XML analysiert, sodass ihre Namespace-Deklarationen beibehalten bleiben. Das Antwortschemata kann weiterhin ein benutzerdefiniertes Schema sein.

HTTP v2: Leerzeichen werden als + statt als %20 kodiert

  • Symptom: REST-API-Aufrufe mit dem HTTP v2-Connector schlagen im Zielsystem fehl, weil Leerzeichen in der URL als + statt als %20 kodiert werden, was dazu führt, dass das Ziel einen Fehler „Ressource nicht gefunden" zurückgibt.
  • Lösung:
    • Aktivieren Sie in der HTTP v2-Verbindung die Option Anfrage-URL kodieren. Der Connector kodiert dann die Anfrage-URL mit URL-Kodierung und kodiert Leerzeichen als %20.
    • Geben Sie die Anfrage-URL vollständig unkodiert an. Kodieren Sie Zeichen nicht vorab und wenden Sie die Funktion URLEncode nicht auf die URL an, da bereits kodierte Zeichen doppelt kodiert werden, wenn Anfrage-URL kodieren aktiviert ist (beispielsweise wird example+string%20value zu example%20string%2520value).

HTTP: Sendet null als die Zeichenkette "null"

  • Symptom: Eine HTTP-POST- oder PUT-Aktivität sendet Felder, die mit der Funktion Null zugeordnet sind, als die Zeichenkette "null" (oder lässt sie weg), anstatt ein JSON-null-Literal auszugeben. Dies tritt auf, wenn das Anforderungsschema in der Aktivität definiert ist.
  • Mögliche Ursache: Wenn das Anforderungsschema in der 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 in der Aktivität kein Anforderungsschema vorhanden ist, 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, vorhandene HTTP-Verbindungen und -Aktivitäten zu HTTP v2 zu konvertieren.
    • Falls die Aktivität auf HTTP verbleiben muss, definieren Sie das Anforderungsschema in der Transformation anstelle 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-Eintrag löschen schlägt fehl, wenn der Ziel-Eintrag untergeordnete Einträge hat

  • Symptom: Eine LDAP-Aktivität Eintrag löschen schlägt mit einem Fehler vom LDAP-Server 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 hat (Untergeordnete). 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 zunächst alle untergeordneten Einträge. Durchlaufen Sie die Hierarchie von den tiefsten Einträgen aufwärts.
    • Wenn das Löschen eines gesamten Teilbaums erforderlich ist, implementieren Sie ein Skript, das Einträge von unten des Baums aufwärts identifiziert und löscht, indem Sie RunOperation mit der LDAP-Aktivität Eintrag löschen für jeden Eintrag verwenden.

LDAP-Sucheintrag: Filterausdruck ist auf einigen Servern Groß-/Kleinschreibung-empfindlich

  • Symptom: Eine LDAP-Aktivität Eintrag suchen gibt keine Ergebnisse oder 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 Groß-/Kleinschreibung entsprechen, die das Schema des Servers verwendet. Der von Studio vorausgefüllte Filterausdruck verwendet Titelschreibweise für die strukturelle Klasse (beispielsweise ObjectClass), aber einige Server erfordern eine andere Groß-/Kleinschreibung (beispielsweise objectClass).
  • Lösung:
    1. Überprüfen Sie in der LDAP-Aktivitätskonfiguration Sucheintrag das vorausgefüllte Feld Filterausdruck.
    2. Passen Sie die Groß-/Kleinschreibung von Attributnamen an das an, was der LDAP-Zielserver erwartet. Ändern Sie beispielsweise ObjectClass zu objectClass, wenn der Server Kleinbuchstaben erfordert.
    3. Konsultieren Sie die Dokumentation oder Schemadefinition Ihres LDAP-Servers für die erforderlichen Namenskonventionen für Attribute.

Microsoft-Connectoren

Microsoft SharePoint Online: SOAP-Schema-Verbindungen fallen nach IDCRL-Einstellung aus

  • Symptom: Vorgänge mit einem Microsoft SharePoint Server-Connector mit dem Verbindungstyp SOAP-Schema 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) eingestellt, die von SOAP-Schema-Verbindungen zu SharePoint Online verwendet wurde. Nach dem 1. Mai 2026 wird erwartet, dass Vorgänge mit dem SharePoint-SOAP-Schema für SharePoint Online-Verbindungen fehlschlagen.
  • Lösung:
    1. Öffne in Studio jede betroffene SharePoint-Verbindung und ändere die Schema-Einstellung von SOAP zu REST.
    2. Konfiguriere alle Aktivitäten, die das SOAP-Schema verwendet haben, neu, um entsprechende REST-Vorgänge zu verwenden.
    3. Teste und stellen die betroffenen Vorgänge erneut bereit.
    4. Weitere Informationen zur Migration findest du in der Dokumentation des Microsoft SharePoint Server-Connectors.

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

  • Symptom: Vorgänge mit dem Microsoft Dynamics 365 Business Central v2-Connector schlagen mit Fehlern fehl, die darauf hindeuten, dass Typnamen in der Payload nicht mit den OData-Metadaten kompatibel sind.
  • Mögliche Ursache: Bestimmte Dynamics 365 Business Central OData API-Endpunkte erfordern OData-Typ-Anmerkungen in der Request-Payload. Der Connector enthält diese Anmerkungen standardmäßig nicht, was zu Typ-Inkompatibilitätsfehlern für diese Endpunkte führt.
  • Lösung:
    1. Öffne die Microsoft Dynamics 365 Business Central v2 Update-Aktivitätskonfiguration.
    2. Aktiviere in Optionale Einstellungen die Option OData-Typ in Payload setzen.
    3. Speichere die Aktivität und teste die betroffenen Vorgänge erneut.

Microsoft Entra ID: Erweiterungsattribute nicht als Abfrage-Filterbedingungen auswählbar

  • Symptom: Beim Konfigurieren einer Microsoft Entra ID Query-Aktivität erscheinen 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 in bedingten Klauseln ausgewählt werden.
  • Mögliche Ursache: onPremisesExtensionAttributes ist ein komplexer Typ (verschachteltes Objekt). Die Auswahl Objektfelder in Schritt 3 zeigt nur primitive Datentypen; komplexe Typen sind von der Auswahliste ausgeschlossen.
  • Lösung: Die Felder onPremisesExtensionAttributes müssen nicht in Schritt 3 ausgewählt werden, um zurückgegeben zu werden. Sie erscheinen im Ausgabeschema der Aktivität in Schritt 4 und werden zur Laufzeit ausgefüllt, wenn der Vorgang ausgeführt wird. Um auf Erweiterungsattributwerte zuzugreifen, verbinde mit onPremisesExtensionAttributes und seinen untergeordneten Feldern in der Transformation.

Microsoft Entra ID Update-Aktivität: DateTime-Felder mit Edm.String-Typ-Nichtübereinstimmung abgelehnt

  • Symptom: Eine Microsoft Entra ID Update-Aktivität schlägt mit folgendem Fehler fehl:
Ein Wert wurde erkannt, dessen Typname nicht mit den Metadaten kompatibel ist.
Der Wert hat den Typ 'Edm.String' angegeben, aber der in den Metadaten angegebene Typ ist 'Edm.DateTimeOffset'.
[HTTP/1.1 400 Bad Request]
  • Mögliche Ursache: Der Connector sendet DateTime-Feldwerte (z. B. employeeHireDate) ohne die für die Microsoft Graph API erforderliche @odata.type-Anmerkung. Ohne die Anmerkung wird der Wert als Edm.String statt als 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 für Payload festlegen.
    3. Speichern Sie die Aktivität, stellen Sie sie erneut bereit und führen Sie den Vorgang 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]

    Die gleiche Abfrage erfolgt erfolgreich, wenn kein Filter angewendet wird.

  • Mögliche Ursache: Das Filtern nach bestimmten Microsoft Entra ID-Eigenschaften (z. B. 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 sonst korrekt ist. Der Connector fügt automatisch den erforderlichen ConsistencyLevel: eventual-Header hinzu, aber $count=true muss separat hinzugefügt werden.

  • Lösung: Wählen Sie eine der folgenden Optionen je nach der in Schritt 3 verwendeten Registerkarte:
    • 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-Vorgänge schlagen mit „Logon failed" fehl

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

    The server has rejected the client credentials.

    The logon attempt failed

  • Ursache: Das Feld Domain Name in der AX 2012-Verbindung ist nicht auf den korrekten Wert gesetzt. Die AX 2012-Authentifizierung erfordert, dass Domain Name die DNS-Domain-Namenserweiterung ist (z. B. yourcompany.com), nicht ein kurzer oder NetBIOS-Domain-Name. Ein falscher Domain-Wert 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. Legen Sie das Feld Domain Name auf Ihre DNS-Domain-Namenserweiterung (z. B. yourcompany.com) fest, nicht auf einen kurzen/NetBIOS-Domain-Namen.
    3. Bestätigen Sie, dass der Login 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 bietet einen dedizierten Troubleshooting-Guide mit zusätzlichen Informationen zu Verbindungs-, Schema-, Aktivitätskonfigurations- und Leistungsproblemen. Siehe NetSuite-Troubleshooting.

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

  • Symptom: Eine NetSuite Create-, Update- oder Upsert-Aktivität schlägt fehl, wenn der Quellwert für ein Länderfeld keinem NetSuite-Country-Enum-Wert entspricht:

    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) einen der im WSDL vordefinierten Enum-Werte hat (z. B. _unitedStates). Ein Ländername, 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 zum NetSuite-Ziel zugeordnet wird, den Quellländerwert vor dem Schreiben in den entsprechenden NetSuite-Enum-Wert. Dafür eignen sich ein Querverweisverzeichnis, eine Case-Anweisung oder eine Nachschlagetabelle.
    • Erstellen Sie den Querverweis aus dem Country-Enum, das im NetSuite SuiteTalk WSDL definiert ist, den Ihr Connector verwendet. Die gültigen Werte unterscheiden sich zwischen WSDL-Versionen. Prüfen Sie daher immer gegen die WSDL-Version, die derzeit auf der Verbindung konfiguriert ist.
    • Wenden Sie denselben Ansatz auf alle anderen Felder an, die auf einem NetSuite-Enum basieren (z. B. State, Currency), wenn die Quellwerte nicht bereits mit dem WSDL-Enum übereinstimmen.

OData-Connector

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

  • Symptom: Das Konfigurieren einer OData Query-Aktivität, die auf einen OData v2.0-Service 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-Services wurde in Agent-Version 11.59 dem OData-Connector durch die Verbindungseinstellung OData version hinzugefügt. Bei Agents vor Version 11.59 unterstützt der Connector nur OData V4, daher kann eine Verbindung, die auf einen OData V2-Service verweist, die Objektliste nicht ausfüllen. Der gleiche Fehler tritt auch bei Version 11.59 oder später auf, wenn OData version für einen OData V2-Service auf V4 belassen wird.

  • Lösung:
    1. Aktualisieren Sie für private Agents auf Version 11.59 oder später. Cloud Agents erhalten das Update automatisch.
    2. Legen Sie in der OData-Verbindung OData version auf V2 fest (Standard ist V4). Speichern Sie und testen Sie die Verbindung erneut.
    3. Öffnen Sie die OData Query-Aktivität erneut. Die Entity Sets sollten nun geladen werden.

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

  • Symptom: Eine OData-Verbindung zu einem Microsoft Dynamics 365 Finance and Operations-Endpunkt gibt nur Daten des Standardunternehmens des Benutzers zurück, sodass Datensätze von anderen Unternehmen in den Ergebnissen fehlen.
  • Mögliche Ursache: Ein Dynamics 365 Finance and Operations OData-Endpunkt gibt standardmäßig nur die Daten des Standardunternehmens des Benutzers zurück. Um der Verbindung einen unternehmensübergreifenden (erweiterten) Bereich zu geben, muss eine unternehmensübergreifende Filterklausel an die OData-Metadaten-URL der Verbindung angehängt werden (die $metadata-URL). Auf der Metadaten-URL wird ?cross-company=true allein den erweiterten Bereich nicht anwenden.
  • Lösung: Hängen Sie in der OData-Verbindung eine dataAreaId-Filterklausel an die OData-Metadaten-URL an, ersetzen Sie usrt durch Ihre Datenbereiche-ID und speichern Sie dann die Änderungen und testen Sie erneut:
?$filter=dataAreaId eq 'usrt'&cross-company=true

Informationen zur Verwaltung von OData-Daten nach Unternehmen in Dynamics 365 finden Sie in der Microsoft-Dokumentation zum Cross-Company-Verhalten.

Oracle-Konnektoren

Oracle EBS: Verbindungsfehler „Custom Provider JAR-Datei ist 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 erfordert, dass der Oracle JDBC-Treiber (ojdbc8.jar) manuell auf dem privaten Agent platziert wird. Diese Datei wird nicht mit dem Agent gebündelt und muss vor der erfolgreichen 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 Agents.
    3. Starten Sie alle Agents in der Agent-Gruppe neu.
    4. Testen Sie die Oracle EBS-Verbindung erneut.

Salesforce-Konnektoren

Hinweis

Der Salesforce-Konnektor verfügt über einen eigenen Troubleshooting-Leitfaden, der Authentifizierung, Schema, Aktivitätskonfiguration, Datensatzlimit und Bulk-Aktivitätsprobleme abdeckt. Siehe Salesforce-Konnektor Troubleshooting.

Salesforce Events: Events können nach dem Neustart des Agents nicht aktiviert werden

  • Symptom: Nach dem Neustart oder der Neuinstallation eines privaten Agents können Salesforce Events-Konnektor-Events nicht aktiviert werden, selbst wenn die Verbindungsanmeldedaten korrekt sind.
  • Mögliche Ursache: Nach einem Neustart ist die Konnektor-JAR-Datei möglicherweise noch nicht auf dem Agent vorhanden. Um ein Event zu aktivieren, muss der Konnektor zunächst auf den Agent heruntergeladen werden.
  • Lösung:
    1. Öffnen Sie die Salesforce Events-Verbindungskonfiguration in Studio.
    2. Klicken Sie auf Test, um die Verbindung zu testen. Dies erzwingt den Download der Konnektor-JAR auf den Agent.
    3. Nach erfolgreicherem Verbindungstest versuchen Sie erneut, das Event zu aktivieren.

Salesforce Events: Einschränkungen bei Listening-Aktivitäten

Die folgenden Verhaltensweisen von Salesforce Events-Listening-Aktivitäten (Subscribe Event und die Subscribe-Aktivitäten für Insert, Update und Delete CDC Event) sind normal und deuten nicht auf einen Konnektor-Fehler hin:

  • Events können nicht aktiviert werden, da die maximale Anzahl von Abonnenten erreicht ist. Die Salesforce-Instanz beschränkt die Anzahl gleichzeitiger Clients (Abonnenten). Wenn dieses Limit erreicht ist, können keine weiteren Events aktiviert werden. Reduzieren Sie die Anzahl der aktiven Abonnenten, die mit der Instanz verbunden sind.
  • Messsymbole wie $ und % fehlen in der Antwort. Diese Symbole werden vom Salesforce API-Design nicht zurückgegeben.
  • Unveränderte Felder werden in Change Data Capture (CDC)-Antworten als null zurückgegeben. Bei CDC-Aktivitäten werden nur geänderte Felder gefüllt; unveränderte Felder werden vom Salesforce API-Design als null zurückgegeben.

SAP-Connector

Mehrere SAP-Aktivitäten in einem Vorgang schlagen zur Laufzeit fehl

  • Symptom: Ein Vorgang, der mehr als eine SAP-Aktivität enthält oder eine SAP-Aktivität mit einer NetSuite-, Salesforce-, Salesforce Service Cloud-, ServiceMax- oder SOAP-Aktivität kombiniert, wird ohne Validierungsfehler bereitgestellt, schlägt aber bei der Ausführung fehl.
  • Mögliche Ursache: Vorgänge, die diese Aktivitätstypen mischen, wirken in Studio gültig und können erfolgreich bereitgestellt werden, aber diese Kombinationen werden zur Laufzeit nicht unterstützt. Die Validierungsregeln des Vorgangs kennzeichnen dieses Muster zur Entwurfszeit nicht als Fehler. Dies ist ein dokumentiertes bekanntes Problem in Studio.
  • Lösung:
    • Gestalten jeden Vorgang so, dass er nur eine einzelne SAP-Aktivität enthält, ohne weitere SAP-, NetSuite-, Salesforce-, Salesforce Service Cloud-, ServiceMax- oder SOAP-Aktivitäten im selben Vorgang.
    • Falls Daten aus mehreren Systemen in einem einzelnen Workflow erforderlich sind, teilen Sie die Logik auf separate Vorgänge auf und verknüpfen Sie diese mit Vorgangsaktionen.

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

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

    JCoException occurred No RFC authorization for function module BAPI_TRANSACTION_COMMIT

  • Mögliche Ursachen:

    • Das SAP-Benutzerkonto in der Verbindung besitzt keine S_RFC-Berechtigung für BAPI_TRANSACTION_COMMIT oder die zugehörigen Funktionsgruppen.
    • Das Funktionsmodul BAPI_TRANSACTION_COMMIT ist im SAP-System nicht als remote-aktiviert 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-aktiviert ist.
    • Setzen Sie in der Anforderungstransformation vor der SAP-RFC-Aktivität das Feld BAPI_COMMIT auf true.
    • Überprüfen Sie, dass das SAP-Benutzerkonto, auf das in der Verbindung verwiesen wird, S_RFC-Berechtigung für BAPI_TRANSACTION_COMMIT und alle zugehörigen Funktionsgruppen besitzt.
    • Falls das Problem weiterhin besteht, wenden Sie sich an Ihren SAP-BASIS-Administrator, um die Berechtigungsobjektzuweisungen des Benutzers zu überprüfen.

SAP-Verbindung schlägt fehl mit „Invalid language key"

  • 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 nicht gültig für das Ziel-SAP-System: Der Code ist nicht installiert oder wird auf diesem System nicht unterstützt, oder er ist falsch geschrieben oder falsch geschrieben (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 Ziel-SAP-System installierten und aktiven Sprachcode entspricht. Wenn Sie sich nicht sicher sind, bestätigen Sie die Standardsprache des Integrationsbenutzers im SAP-Benutzerprofil und verwenden Sie diese.
    3. Testen Sie die Verbindung aus Studio, um zu bestätigen, dass die Initialisierung erfolgreich ist, bevor Sie den Vorgang erneut bereitstellen.

ServiceNow-Connector

Erste Operationsausführungen sind nach Agent-Neustart oder auf Cloud-Agents langsam

  • Symptom: Operationen mit dem ServiceNow-Connector laufen in zwei Szenarien langsam:

    • Bei privaten Agents kann die erste Operation nach dem Agent-Neustart mehrere Minuten dauern; nachfolgende Ausführungen sind schnell.
    • Bei Cloud-Agents sind Ausführungen zeitweilig 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. Nach einem Agent-Neustart bei einem privaten Agent (oder bei jedem Durchlauf für einen Cloud-Agent, der den Cache nicht beibehalten hat), muss die erste Operation den Cache neu erstellen, was mehrere Minuten dauert.

  • Lösung:
    • Bei einem privaten Agent kann die Verlangsamung nach dem Neustart durch Hinzufügen von getcolumnsmetadata=onUse zu den Erweiterten Optionen des ServiceNow-Endpunkts gemildert werden. Diese Einstellung ist nur bei privaten Agents wirksam.
    • Für konsistente Leistung bei Cloud-Agents 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 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 auswählbar ist, kann im ServiceNow v2-Connector nicht unter demselben Namen gefunden werden.
  • Ursache: Der ServiceNow v2-Connector gibt durch die Verwendung der ServiceNow REST API Objekte mit ServiceNows tatsächlichem Backend-Tabellennamen an, der sich vom Namen desselben Objekts im ServiceNow-Connector unterscheiden kann. Beispielsweise entspricht das im ServiceNow-Connector mit System benannte Objekt im ServiceNow v2-Connector Sys.
  • Lösung: Schlagen Sie in ServiceNow unter System Definition > Tables den tatsächlichen Tabellennamen des Objekts nach und suchen Sie dann nach diesem Namen in der Aktivitätskonfiguration des ServiceNow v2-Connectors.

Shopify-Connector

Shopify: Aktivitätsobjektauswahl kann sich nach API-Versionsaktualisierung ändern

  • Symptom: Nach Änderung der API-Version für eine 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 gibt vierteljährlich neue API-Versionen frei und stellt ältere Versionen nach 12 Monaten ein. Wenn Sie zu einer anderen API-Version wechseln, sind Objekte oder Unterobjekte, die in der neuen Version nicht verfügbar sind, möglicherweise nicht mehr auswählbar, wodurch sich die konfigurierte Auswahl der Aktivität bei der Aktualisierung der Konfiguration ändern kann.
  • Lösung:
    1. Nachdem Sie die Shopify API-Version in der Verbindung geändert haben, öffnen Sie die Konfiguration jeder betroffenen Shopify-Aktivität.
    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 Unterobjektauswahl, um zu bestätigen, dass diese Ihre Absicht in der neuen Version widerspiegeln.
    4. Aktualisieren Sie alle geänderten Auswahlen zu den richtigen Ersatzobjekten.
    5. Stellen Sie die betroffenen Operationen erneut bereit und testen Sie sie erneut.
    6. Weitere Informationen zu Shopify-Versionsdeprecation-Zeitplänen finden Sie unter Shopifys Änderungsprotokoll.

Snowflake-Connector

Snowflake: Passwortbasierte Verbindungen schlagen nach Authentifizierungsabschaffung fehl

  • Symptom: Operationen, die sich mit Snowflake über den Authentifizierungstyp Password (Deprecated) verbinden, schlagen fehl, nachdem sie zuvor funktioniert haben, z. B. 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 stellt die Single-Factor-Authentifizierung (nur Passwort) ein, einschließlich der Konten vom Typ LEGACY_SERVICE, die für diesen Authentifizierungstyp erforderlich sind. Snowflake migriert LEGACY_SERVICE-Konten auf schrittweiser, kontospezifischer Basis zu TYPE=SERVICE, was passwortbasierte Authentifizierung vollständig blockiert. Bei einigen Konten ist auch die Multi-Faktor-Authentifizierung (MFA) aktiviert, die mit dieser vollständig automatisierten, programmgesteuerten Verbindung nicht kompatibel ist, da MFA eine Person im Prozess erfordert. Siehe Password (Deprecated) für den Abschaffungsplan.

  • Lösung: Aktualisiere die Snowflake-Connector-Verbindung in Studio auf OAuth oder Key-Pair-Authentifizierung und konfiguriere das Snowflake-Benutzerkonto entsprechend. Stelle sicher, dass es nicht in MFA registriert ist.

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

  • Symptom: Beim Konfigurieren einer Snowflake-Aktivität wird die Liste der verfügbaren Objekte nicht aufgefüllt oder ist leer, obwohl der Verbindungstest erfolgreich ist.
  • Mögliche Ursache: Snowflake-Entwicklerinstanzen wechseln in den Schlafmodus, wenn auf sie kürzlich nicht zugegriffen wurde. Obwohl der Verbindungstest gegen eine schlafende Instanz erfolgreich sein kann, gibt die Instanz möglicherweise keine Tabellen- und Objektmetadaten zurück.
  • Lösung:
    1. Melde dich in der Snowflake-Weboberfläche an, um die Instanz aufzuwecken.
    2. Öffne die Snowflake-Verbindung in Studio erneut und klicke auf Test, um die Anmeldedaten erneut zu testen.
    3. Öffne die Aktivitätskonfiguration erneut, um die Liste der verfügbaren Objekte zu aktualisieren.

Snowflake-Abfrage: Schemaabweichung im Stammknoten mit flachem Schema verursacht ProcessFlatStream-Fehler

  • Symptom: Eine Snowflake-Query-Aktivität mit flachem 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 Stammknotens in Großbuchstaben erstellt. Die Abweichung zwischen dem Stammknoten des Schemas (Großbuchstaben) und dem Stammknoten der XML-Antwort (Kleinbuchstaben) verursacht, dass die Verarbeitung des flachen Streams fehlschlägt.

  • Lösung: Wähle eine der folgenden Optionen:
    • Ändere im flachen Schema den Namen des Stammknotens in Kleinbuchstaben, um die Connector-Ausgabe zu entsprechen. Benenne z. B. SALES_ORDERS in sales_orders um.
    • Verwende das Mirror-Schema mit Standardzuordnung statt eines manuell erstellten flachen Schemas. Das Mirror-Schema leitet seine Struktur direkt aus der Connector-Antwort ab und weist diese Abweichung 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. Die gleiche Aktivität, die für eine interne Stage konfiguriert ist, zeigt beide Felder an.
  • Mögliche Ursache: Externe Stages sind schreibgeschützte Verweise auf Dateien, die bereits im externen Cloud-Speicher (S3, GCS oder Azure Blob) vorhanden sind. Die Merge-Aktivität kann keinen Dateiinhalt in eine externe Stage hochladen, daher fehlen im Schema die Felder, die diesen Upload steuern.
  • Lösung:
    • Wenn die Aktivität auf eine externe Stage abzielt, stellen Sie sicher, dass die Datendateien bereits am Cloud-Speicherort vorhanden sind, auf den die Stage verweist. Die Merge-Aktivität liest direkt aus diesen Dateien; kein fileContent-Feld ist erforderlich.
    • Wenn Sie Dateiinhalte aus der Operation übertragen müssen, 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 vom Typ 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 mit einfachen Anführungszeichen (z. B. ein Wert wie corner's) werden nicht escaped, bevor sie in die SQL-Payload aufgenommen werden. Das ungeescapte Anführungszeichen beendet die Zeichenkette vorzeitig, wodurch der Rest des Wertes als SQL-Syntax statt als Daten interpretiert wird.
    • Ein Zielspaltennamen 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 erzeugt es einen Syntaxfehler am Bindestrich.

  • Lösung:

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

Snowflake: Java-Heap-Speicherfehler beim Abfragen großer Datensätze

  • Symptom: Eine Snowflake-Aktivität vom Typ 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

    Wenn dieser Fehler bei Abfragen auftritt, die nur wenige Zeilen zurückgeben, oder wenn derselbe Agent auch durch andere Connectors mit Heap-Fehlern fehlschlägt, ist die Ursache eher die Gesamtheap-Zuordnung des Agenten als die Größe des Ergebnissatzes. Weitere Informationen finden Sie unter Java-Heap-Speicherfehler: 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 damit der Tomcat-JVM-Heap auf dem Private Agent erschöpft.

  • Lösung: Verwenden Sie für große Abfragemengen den Database-Connector mit einem Snowflake-JDBC-Treiber anstelle des Snowflake-Connectors. Der Database-Connector puffert das vollständige Resultset nicht im Speicher, sodass er wesentlich größere Abfragemengen verarbeiten kann. Installieren Sie den Snowflake-JDBC-Treiber auf dem privaten Agent und konfigurieren Sie dann eine Datenbankverbindung, die diesen verwendet. Bei Agent 12.x und höher benötigt diese Datenbankverbindung auch enableArrowResultFormat=false&jdbc_query_result_format=json in der Verbindungszeichenfolge; siehe Snowflake: Operationen schlagen bei Agent 12.x fehl.

    Wenn Sie beim Snowflake-Connector bleiben möchten, können Sie mit einer der folgenden Optionen den Speicherdruck verringern, obwohl keine davon garantiert für Datenmengen im Millionenbereich ausreichend ist:

    • Teilen Sie die Abfrage mit SQL-Klauseln LIMIT und OFFSET in Batches auf und führen Sie die Operation wiederholt mit inkrementierenden Offsets aus, bis alle Zeilen verarbeitet sind.
    • Erhöhen Sie die Tomcat-JVM-Heap-Größe auf dem privaten Agent (siehe Tomcat-Heap-Speicher).

Snowflake: Operationen schlagen bei Agent 12.x fehl

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

    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 mit Agent-Version 12.x und höher nicht kompatibel ist. Details finden Sie in Snowflakes Artikel zur Fehlerbehebung dieses Java-Modulfehlers. Der Verbindungstest gibt kein Resultset zurück, daher ist er weiterhin erfolgreich, während Abfragen fehlschlagen. Ein Upgrade der JDBC-Treiberversion behebt das 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 anstelle von Arrow zurückgibt:

    • Database-Connector: Fügen Sie enableArrowResultFormat=false&jdbc_query_result_format=json zur Snowflake-Verbindungszeichenfolge im Feld Zusätzliche Verbindungszeichenfolge-Parameter hinzu (oder im Feld Verbindungszeichenfolge, wenn Verbindungszeichenfolge verwenden ausgewählt ist).
    • Snowflake-Connector: Fügen Sie unter Optionale Einstellungen > Verbindung benutzerdefinierte Eigenschaften die Option enableArrowResultFormat mit dem Wert false hinzu. Eine Zeile JDBC_QUERY_RESULT_FORMAT mit dem Wert JSON ist dort bereits standardmäßig vorhanden.

    Speichern Sie dann, testen Sie die Verbindung erneut und führen Sie die Operation erneut aus.

    Auf einem privaten Agent können Sie die Reparatur stattdessen auf JVM-Ebene anwenden, sodass sie nicht pro Verbindung wiederholt werden muss, indem Sie --add-opens=java.base/java.nio=ALL-UNNAMED zu CATALINA_OPTS hinzufügen:

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

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

    Starten Sie dann den Agent neu.

    1. Öffnen Sie den Registry Editor und suchen Sie den folgenden Schlüssel:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Apache Software Foundation\Procrun 2.0\Jitterbit Tomcat Server\Parameters\Java
  1. Öffnen Sie den Unterschlüssel Options.
  2. Fügen Sie im Feld Value data den Wert --add-opens=java.base/java.nio=ALL-UNNAMED zu den vorhandenen Java-Optionen hinzu.
  3. Klicken Sie auf Ok.
  4. Starten Sie den Agent neu.

Verwenden Sie eine der folgenden Strategien, um die Einstellung anzuwenden:

  1. Aktualisieren Sie die Dockerfile und erstellen Sie das Docker-Image neu:

    docker build -t my-agent .

  2. Fügen Sie es im Docker-Befehl run ein:

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

  3. Fügen Sie es in docker-compose.yml ein 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, erneut importiert oder ihre interne Referenz wurde beschädigt, sodass das Projekt auf eine WSDL-Kennung verweist, die nicht mehr vorhanden ist.

    • Das Projekt wurde vor der Version Harmony 12.9 bereitgestellt oder in eine andere Umgebung übertragen, als die Bereitstellung eines Projekts WSDL-Dateien löschen konnte, die noch verwendet wurden. Mit Version 12.9 wird das Löschen verhindert, aber eine WSDL, die vorher gelöscht wurde, muss erneut hochgeladen werden.

  • Lösung:

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

      • Öffnen Sie für eine SOAP-Verbindung die Verbindung und wählen Sie Upload URL oder Upload file (nicht Select existing), laden Sie die WSDL erneut hoch, überprüfen Sie die Einstellungen unter Port und Select methods, und klicken Sie dann auf Save Changes.
      • Öffnen Sie für eine API-Aktivität SOAP Request oder SOAP Response die Aktivität und laden Sie die WSDL in Schritt 1 der Konfiguration erneut hoch.

    2. Überprüfen Sie alle Transformationen, die Schemas von der erneut hochgeladenen WSDL erben, und regenerieren Sie diese bei Bedarf.

    3. Stellen Sie das Projekt erneut bereit.

    4. Wenn das Projekt mehrere WSDLs enthält und unklar ist, welche betroffen ist, konsultieren Sie SOAP-Verbindungsfehlerbehebung, um sie aus einem JSON-Export 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 führt zu Schemaauflösungsfehlern zur Designzeit.
  • Mögliche Ursache: Die WSDL verwendet absolute URLs in ihren schemaLocation-Attributen für importierte XSD-Dateien (z. B. http://example.com/schema.xsd). Der Agent kann Schemas von absoluten Remote-URLs nicht abrufen, wenn eine lokal importierte WSDL geladen wird.
  • Lösung:
    1. Bearbeiten Sie die WSDL so, dass alle schemaLocation-Verweise relative Pfade verwenden (z. B. schema.xsd statt http://example.com/schema.xsd).
    2. Platzieren Sie alle referenzierten XSD-Dateien im selben Verzeichnis wie die WSDL und importieren Sie die WSDL erneut in die SOAP-Verbindung.

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

  • Symptom: Die vom SOAP-Connector generierte XML-Datei stimmt nicht mit den literalen Namespace-Präfixen oder der Struktur des Quell-WSDL überein (beispielsweise ersetzt der Connector xmlns:ns1 durch xmlns:glob). Strikte SOAP-Services, die den exakten Präfix-Text vergleichen, lehnen die Anfrage ab.
  • Mögliche Ursache: Die Transformations-Engine verarbeitet SOAP-Nachrichten als strukturierte XML, nicht als Literaltext. Sie erzeugt eine semantisch gleichwertige Payload, die möglicherweise andere Namespace-Präfixe als das Quell-WSDL verwendet.
  • Lösung: Für SOAP-Services, die eine literale XML-Struktur erfordern, umgehen Sie den SOAP-Connector und erstellen Sie die Request-Payload als String:
    1. Erstellen Sie eine HTTP v2-Verbindung, die auf die SOAP-Service-URL zeigt.
    2. Erstellen Sie in einer Transformation die SOAP-Datei als String, indem Sie String-Literale und zugeordnete Werte mit dem Operator + verketten. Alternativ können Sie eine Vorlage aus einer Datei lesen und dynamische Werte mit Replace ersetzen.
    3. Verwenden Sie in der HTTP v2 POST-Aktivität das Standard-Request-Schema (laden Sie kein benutzerdefiniertes Request-Schema hoch) und ordnen Sie die konstruierte SOAP-Datei dem body-Feld dieses Schemas zu. Der Connector sendet den body-Wert unverändert und behält die literale XML bei.
    4. Setzen Sie den Content-Type-Header auf text/xml oder application/soap+xml, und setzen Sie den SOAPAction-Header, falls der Service dies erfordert.
    5. Lesen Sie 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 fehl mit „Sie haben keine Berechtigung für den Zugriff auf diese Ressource"

  • Symptom: Ein VTEX-Verbindungstest schlägt in Studio mit einem Berechtigungsfehler fehl, obwohl die gleichen Anmeldedaten in externen Tools wie Postman funktionieren.

    You don't have permission to access this resource

  • Mögliche Ursache: Der VTEX-Benutzer oder Anwendungsschlüssel, der der Verbindung zugeordnet ist, verfügt über fehlende Berechtigungen, die der Connector zur Validierung der Verbindung verwendet. Diese Berechtigungen sind strenger als diejenigen, die für den grundlegenden Datenzugriff erforderlich sind.

  • Lösung:
    1. Öffnen Sie im VTEX-Admin-Portal das Zugriffsprofil, das dem Benutzer oder 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 Web-Services 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 für diese WSDL-Versionen spezifisch sind.
  • Lösung:
    1. Ändern Sie in der Workday-Verbindungskonfiguration die WSDL-Version auf 41.x oder 43.0 oder später für Operationen, die die Services Human_Resources oder Resource_Management verwenden.
    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 mit folgender Fehlermeldung fehl:

    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. Beachte, dass Vorgänge zur Laufzeit möglicherweise erfolgreich ausgeführt werden, auch wenn der Verbindungstest diese Fehlermeldung zurückgibt. Das liegt daran, dass der Test einen bestimmten Workday-Dienst (Get_Message_Template_Translation_Request) aufruft, der eine Berechtigung erfordert, die der ISU möglicherweise nicht zugewiesen ist, während die tatsächlichen Integrationsvorgänge andere Dienste aufrufen.

  • Mögliche Ursachen:

    • Der Integration System User (ISU) wurde nicht der Sicherheitsgruppe Setup Administrator in Workday zugewiesen. Der Verbindungstest des Connectors wird abgelehnt, wenn dem ISU diese Sicherheitsgruppenzugehörigkeit 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üfe, dass der Wert Workday Host in der Verbindungskonfiguration korrekt ist. Der Host sollte die Basis-URL deines Workday-Mandanten sein (z. B. https://wd5-impl-services1.workday.com/). Den korrekten Wert kannst du auf der Workday-Seite View API Client bestätigen.
    2. Öffne in der Workday-Instanz die Aufgabe Assign Users to User-based Security Group, wähle Setup Administrator aus und überprüfe, ob der ISU unter System Users aufgeführt ist. Falls nicht, füge den ISU hinzu. Vollständige Schritte findest du unter Voraussetzungen.
    3. Bestätige, dass auch die Aufgabe Configure Web Service Security für den ISU abgeschlossen wurde, wie auf der Seite Voraussetzungen beschrieben.
    4. Teste die Verbindung erneut.