Zum Inhalt springen

Connector-Fehlerbehebung in Jitterbit Studio

Dieser Leitfaden behandelt Fehler und unerwartetes Verhalten, die spezifisch für einzelne Jitterbit Studio-Connectoren sind und nach Connector organisiert sind. Er 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.

Bei Problemen, die nicht spezifisch für einen Connector sind, wie z. B. ein Vorgang, der nicht ausgeführt wird, oder ein Problem mit einer Transformation, einem Skript oder einer Funktion, siehe Fehlerbehebung bei Vorgängen. Bei Problemen mit privaten Agenten, wie z. B. ein Agent, der offline, fehlerhaft oder langsam ist (was Vorgänge vollständig stoppen kann), siehe Fehlerbehebung bei privaten Agenten.

Eine einheitliche Referenz, die Integrations-, Automatisierungs-, API-Management-, EDI- und App-Entwicklungsprobleme an einem Ort abdeckt, finden Sie im Harmony-Fehlerbehebungsleitfaden.

Alle Fehlerbehebungseinträge auf dieser Seite

Diagnoseschritte

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

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 auf den Agent heruntergeladen, es sei denn, die Organisationsrichtlinie Automatische Connector-Aktualisierung deaktivieren ist aktiviert.

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 Endpunkt-Seite (neue Felder, eine API-Versionänderung 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.

Verfügbarkeit von Connectoren bestätigen und aktuell halten

Die Spalte Agent-Verfügbarkeit in der Connectorliste zeigt an, ob ein Connector einen privaten Agent erfordert.

Connectoren werden gemäß Jitterbit's Veröffentlichungsplan unabhängig vom Agent veröffentlicht und aktualisiert. Auf privaten Agenten wird beim Testen einer Verbindung die neueste Version des Connectors heruntergeladen (siehe Verbindung testen oben), sofern die Organisationsrichtlinie Automatische Connector-Aktualisierung deaktivieren nicht aktiviert ist. Um die Connectoren für eine Agent-Gruppe jederzeit zu aktualisieren, auch wenn diese Richtlinie aktiviert ist, wählen Sie auf der Seite Agents der Management Console für die Gruppe Aktion > Connectoren aktualisieren aus.

Ausführliches Connector-Logging aktivieren

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

Verbindungskonfiguration

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

  • Symptom: Viele Connectoren enthalten eine Tabelle Erweiterte Konfigurationseigenschaften für optionale Verbindungseinstellungen. Variablen, die in diesen Feldern verwendet werden und unformatiertes JSON enthalten, müssen das JSON maskiert haben. Das Übergeben von unformatiertem JSON über eine Variable führt dazu, dass der Feldwert fehlerhaft wird.
  • Mögliche Ursache: Felder in der Tabelle Erweiterte Konfigurationseigenschaften unterstützen keine Variablen, die unformatierte JSON-Objekte enthalten.
  • Lösung:
    • Maskieren Sie das JSON, bevor Sie JSON-Inhalte über eine Variable in ein Feld Erweiterte Konfigurationseigenschaften übergeben. 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 Erweiterte Konfigurationseigenschaften werden nur 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: Modellfehler „On-Demand-Durchsatz wird nicht unterstützt"

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

    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 keinen On-Demand-Durchsatz und erfordern stattdessen die ID eines regionsübergreifenden Inferenzprofils anstelle der Modell-ID, die in der Liste Modell auswählen der Aktivität zurückgegeben wird.

  • Lösung:
    1. Gehen Sie in der AWS Management Console zu Amazon Bedrock > Inferenzprofile 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. Für OpenAI's GPT-5.6-Modelle variieren gültige Inferenzprofil-ID-Präfixe je nach Modell und Region (z. B. us. oder global.), wie 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's Modellkarten für GPT-5.6 Sol, GPT-5.6 Terra und GPT-5.6 Luna.
    2. Geben Sie die Inferenzprofil-ID mit der Option Modellkennung eingeben in der Aktivitätskonfiguration ein.

Cloud Datastore-Connector

Die Aktivität „Delete Items" meldet Erfolg, löscht den Datensatz aber nicht

  • Symptom: Eine Cloud Datastore-Aktivität Delete Items meldet Erfolg im Operationsprotokoll, aber der Zieldatensatz existiert noch, wenn man ihn danach abfragt.
  • Mögliche Ursache: Delete Items identifiziert Datensätze anhand des Schlüssel-Werts (oder Alternativer Schlüssel) des Speichers, der im keys- oder ids-Array der Anfrage bereitgestellt wird. (Beide Arrays akzeptieren Schlüssel- oder alternative Schlüsselwerte.) Wenn statt des Schlüsselwerts die interne ID des Datensatzes bereitgestellt wird, stimmt kein Element überein, und die Aktivität meldet Erfolg, ohne etwas zu löschen.
  • Lösung:
    • Ordnen Sie in der Transformation, die die Delete Items-Anfrage vorbereitet, den Schlüssel-Wert (oder Alternativer Schlüssel) des Speichers zu, nicht die interne Datensatz-ID.
    • Wenn Sie von einer Query Items-Aktivität verketten, ordnen Sie den key-Wert aus der Abfrageantwort der Löschanfrage zu.

Coupa-Connector

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

  • Symptom: Ein Coupa-Connector-Vorgang 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 Coupa-Verbindungskonfiguration von der API-Schlüssel-Authentifizierung zur 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 und testen Sie erneut.

Database-Connector

Database (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 z. B. ein JWT oder ein anderes Zugriffstoken, obwohl die gleiche Abfrage bei direkter Ausführung gegen die Datenbank erfolgreich ist.

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

  • Lösung:

    • Aktualisieren Sie für private Agenten auf Version 12.9 oder später. Cloud-Agenten erhalten das Update automatisch.
    • Wenn Sie nicht sofort aktualisieren können, vermeiden Sie die Base64-Prüfung, indem Sie den betroffenen Wert in der SQL-Abfrage in Hexadezimal konvertieren und dann in einem Skriptschritt mit HexToString decodieren. Beispiel in PostgreSQL: SELECT encode(<column>, 'hex'). Verwenden Sie das entsprechende SQL decode(...,'hex') mit StringToHex, wenn Sie den Wert zurück in die Datenbank schreiben.

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

  • Symptom: Beim Lesen aus oder Schreiben in eine Datenbank über den Datenbank-Connector mit einem ODBC-Treiber werden Multibyte- oder Nicht-ASCII-Zeichen (z. B. Umlaute oder nicht-lateinische Zeichen) nicht korrekt verarbeitet.
  • Mögliche Ursache: Die Unterstützung für Multibyte-Zeichen beim Datenbank-Connector ü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ätigen Sie, dass der Agent Version 12.6 oder später ist.

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

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

    Alternativ können Sie einen JDBC-Treiber für die Datenbankverbindung verwenden, der Multibyte-Zeichen ohne diese Variable verarbeitet.

Datenbank: Verbindung durch Sicherheitsrichtlinie blockiert

  • Symptom: Ein Datenbank-Connector-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 schränken bestimmte Datenbankverbindungen und Verbindungsstring-Parameter standardmäßig aus Sicherheitsgründen ein. Dies umfasst Verbindungen zu localhost oder 127.0.0.1 sowie bestimmte Verbindungsstring-Parameter für die MySQL-, PostgreSQL-, Oracle- und SQL Server-Treiber. Eine Verbindung, die zuvor funktioniert hat, kann nach dem Upgrade eines privaten Agents auf Version 12.10 fehlschlagen, da die Einschränkung standardmäßig gilt, auch wenn 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 Parameter zu erlauben, den Sie benötigen, und starten Sie dann den Agent neu.

Datenbank: Verbindungs-Timeouts unter Last

  • Symptom: Datenbank-Quell- oder Zielvorgänge schlagen unter hoher gleichzeitiger Last intermittierend fehl, mit einer Ausnahme ähnlich wie:

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

  • Mögliche Ursache: Jeder Datenbankvorgang öffnet eine neue physische JDBC-Verbindung und schließt sie danach, anstatt eine vorhandene wiederzuverwenden. Unter gleichzeitiger Last erzeugt dies genug Verbindungswechsel gegen die Zieldatenbank, dass einige Verbindungsversuche ein Timeout verursachen.

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

Datenbank: Feldlängenfehler bei Insert, Update oder Upsert

  • Symptom: Eine Datenbank-Aktivität Insert, Update oder Upsert schlägt mit dem Betriebsstatus Error fehl, wenn ein zugeordneter Quellwert länger ist als die Zielpalte zulässt. Das Operationsprotokoll enthält einen der folgenden Einträge:

    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 Error, wenn ein zugeordneter Quellwert die definierte Länge der Zielpalte ü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 Allow truncation of character fields to avoid field length errors. Mit dieser Option werden Werte, die die Zielfeld-Länge überschreiten, gekürzt und die Operation meldet den Status Success with Info statt Error.
    2. Falls Kürzung nicht akzeptabel ist, kürzen oder transformieren Sie das Quellfeld in der Transformationszuordnung, damit Werte die Zielpalten-Länge nie überschreiten, oder vergrößern Sie die Zielpalte auf der Datenbankseite.
    3. Stellen Sie die Operation erneut bereit und führen Sie sie erneut aus.

Datenbank: JDBC-Treiber-JAR wird bei Agent-Upgrades ü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-Upgrades beibehalten. Benutzerdefinierte Treiber-JAR-Dateien, die an anderen Stellen in den Agent-Verzeichnissen platziert werden, sind Teil der verwalteten Bereitstellung und können während eines Upgrades entfernt oder überschrieben werden.
  • Lösung:
    • Platzieren Sie benutzerdefinierte JDBC-Treiber-JAR-Dateien stattdessen in <JITTERBIT_HOME>/tomcat/drivers/lib/. Dieses Verzeichnis wird bei Agent-Upgrades beibehalten.
    • Falls sich Treiber derzeit am falschen Ort befinden, verschieben Sie sie in das richtige Verzeichnis und starten Sie den Agent neu.

Datenbank: Sonderzeichen in Spaltennamen verursachen Abfragefehler

  • Symptom: Datenbank-Abfragen 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 für die physische Tabelle, die die betroffene Spalte unter einem Namen verfügbar macht, der keine Sonderzeichen enthält.
    2. Verweisen Sie die Datenbank-Aktivität auf die Ansicht statt auf die ursprüngliche Tabelle.

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

  • Symptom: Eine Datenbank-Aktivität Query schlägt fehl oder wird gekürzt, wenn die konfigurierte SQL-Anweisung sehr lang ist.
  • Mögliche Ursache: Das Feld für die SQL-Anweisung in einer Datenbank-Aktivität Query akzeptiert maximal 2.000 Zeichen.
  • Lösung:
    1. Erstellen Sie eine Datenbankansicht, die die komplexe Abfragelogik kapselt.
    2. Verweisen Sie in der Aktivität Query auf den Ansichtsnamen statt auf die vollständige SQL-Anweisung.

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

  • Symptom: Eine Datenbankverbindung zu IBM DB2 on iSeries (AS/400 oder IBM i) mit einem JDBC-Treiber kann keine Verbindung herstellen.
  • Mögliche Ursache: Einige Verbindungen zu DB2 on iSeries mit einem JDBC-Treiber verursachen Probleme, die bei einem ODBC-Treiber nicht auftreten.
  • Lösung: Wechseln Sie die Verbindung zu einem ODBC-Treiber statt 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 einem Fehler fehl, der 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 erfordert eine separate Lizenz-JAR-Datei. Die Treiber-JAR allein ist nicht ausreichend.
  • Lösung:
    • Verwenden Sie den db2jcc4.jar-Treiber, nicht die veraltete db2jcc.jar. Installieren Sie ihn in <JITTERBIT_HOME>/tomcat/drivers/lib/ auf dem privaten Agent.
    • Besorgen Sie sich die Lizenz-JAR-Datei von IBM (benannt db2jcc_license_cisuz-XX.jar, wobei XX die Versionsnummer ist) und kopieren Sie sie nach <JITTERBIT_HOME>/tomcat/shared/lib/.
    • Verwenden Sie alternativ die JTOpen-Open-Source-Bibliothek (auch als AS400-Treiber bekannt), die keinen JCC-Treiber oder Lizenzdatei erfordert.

Kerberos: „Klasse KerbAuthentication konnte nicht initialisiert werden"

  • 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 korrekten 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

    2. Starten Sie den Agent nach dem Ändern der Berechtigungen neu.

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

  • Symptom: Eine Datenbankverbindung mit Kerberos-Authentifizierung schlägt mit Fehlern fehl, die auf jgss oder gss verweisen.
  • Mögliche Ursache: Die JVM ist mit -Dsun.security.jgss.native=true konfiguriert, was sie anweist, die native GSSAPI-Bibliothek des Betriebssystems zu verwenden. Auf einigen Systemen verursacht dies einen Konflikt mit der Kerberos-Konfiguration.
  • Lösung:
    1. Entfernen Sie den Parameter -Dsun.security.jgss.native=true aus den JVM-Argumenten des Agenten.
    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: „Vorgang muss eine aktualisierbare Abfrage verwenden"

  • Symptom: Eine Datenbankaktivität Einfügen oder Aktualisieren für eine Microsoft Excel-Datei (über ODBC) schlägt fehl mit:

    [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, es sei denn, die Verbindungszeichenfolge legt explizit den Lese-/Schreibmodus fest.

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

MySQL: Zugriff verweigert trotz korrekter Anmeldedaten

  • Symptom: Die Verbindung zu einer MySQL-Datenbank mit dem Datenbankconnector schlägt fehl mit:

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

    auch wenn Benutzername und Passwort korrekt sind.

  • Mögliche Ursache: MySQL kann unterschiedliche Berechtigungen basierend auf der Client-IP-Adresse gewähren. Ein Benutzerkonto kann die erforderlichen Berechtigungen von bestimmten IP-Adressen aus haben, aber nicht von der IP-Adresse des privaten Agenten.

  • Lösung:

    • Überprüfen Sie in MySQL, dass das Benutzerkonto die erforderlichen Berechtigungen für Verbindungen von der IP-Adresse des privaten Agenten hat. Die genaue Syntax für Berechtigungen variiert je nach MySQL-Version (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 Konnektivität mit einem MySQL-Client, der direkt auf dem Agent-Host installiert ist, um festzustellen, ob das Problem netzwerkbasiert oder Jitterbit-spezifisch ist.

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

  • Symptom: Eine Datenbankaktivität vom Typ Insert oder Update mit dem MySQL JDBC-Treiber zeigt nach 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 einen echten serverseitigen Batch zu verwenden.
  • Lösung: Fügen Sie im Feld Zusätzliche Verbindungszeichenfolgen-Parameter 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 Agenten wird der installierte Treiber nicht in der Dropdown-Liste Treiber in Studio angezeigt.
  • Mögliche Ursache: Der ODBC-Manager auf dem Host des privaten Agenten zeigt den Treiber nicht an, normalerweise aufgrund einer 32-Bit- vs. 64-Bit-Nichtübereinstimmung oder einer unvollständigen Treiberinstallation.
  • Lösung:
    • Öffnen Sie auf dem Host des privaten Agenten (Windows) Datenquellen (ODBC) (unter Verwaltung) 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-Nichtübereinstimmung

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

PostgreSQL: Jitterbit-bereitgestellten Treiber unter Linux verwenden

  • Symptom: Operationen, die den Database-Connector verwenden, um sich von einem privaten Linux-Agent aus mit PostgreSQL zu verbinden, schlagen fehl oder erzeugen Fehler, auch 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 bereitgestellten PostgreSQL-Treiber. Verwenden Sie stattdessen den PostgreSQL-ODBC-Treiber, der mit der Jitterbit-Agent-Installation gebündelt ist.

SQL Server JDBC: Windows-integrierte Authentifizierung schlägt fehl

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

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

    Die Agent-Protokolle können auch Folgendes anzeigen:

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

  • Mögliche Ursachen:

    • Die für die Windows-integrierte Authentifizierung erforderliche mssql-jdbc_auth-DLL fehlt in den JRE-Verzeichnissen, die der Jitterbit-Agent zur Laufzeit verwendet. Das Platzieren der DLL im selben Verzeichnis wie die JDBC-JAR-Datei ist nicht ausreichend.
    • Die Verbindungszeichenfolge enthält nicht den Parameter integratedSecurity=true.

  • Lösung:

    1. Kopieren Sie auf dem Host des privaten Agents mssql-jdbc_auth-x.x.x.x64.dll (aus der JDBC-Treiberverteilung, mit der Version, die der mit Ihrem Agent gebündelten JDBC-JAR-Datei entspricht) in beide Verzeichnisse <JITTERBIT_HOME>/jre/bin und <JITTERBIT_HOME>/jre/lib. Sichern Sie die Datei, da sie bei größeren Agent-Upgrades möglicherweise entfernt wird.
    2. Fügen Sie in den Database-Verbindungseinstellungen integratedSecurity=true zum Feld Zusätzliche Verbindungszeichenfolgen-Parameter hinzu.
    3. Starten Sie den Jitterbit-Agent-Dienst neu.

SQL Server Windows-Authentifizierung: Unzureichende Berechtigungen

  • Symptom: Eine Database-Verbindung mit SQL Server Windows-Authentifizierung schlägt fehl, auch wenn 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 die Windows-integrierte Sicherheit.
  • Lösung:
    1. Gewähren Sie dem Domänenbenutzer die Windows-Berechtigungen Als Dienst anmelden und Als Teil des Betriebssystems fungieren auf dem Host des privaten Agents.
    2. Bestätigen Sie, dass der Domänenbenutzer Lese- und Schreibberechtigungen für das Installationsverzeichnis des Jitterbit-Agents hat.
    3. Starten Sie den Jitterbit-Agent-Dienst nach dem Anwenden von Berechtigungsänderungen neu.

SQL Server: „Kann keinen expliziten Wert für die Identitätsspalte einfügen" beim Einfügen in eine Identitätsspalte

  • Symptom: Ein Database-Connector-Vorgang, der in eine SQL Server-Tabelle mit einer Identitätsspalte schreibt, schlägt 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 Database-Connector für das Ziel generiert. SQL Server lehnt ein INSERT ab, das auf eine Identitätsspalte in seiner Spaltenliste verweist (mit einem expliziten Wert oder null), während IDENTITY_INSERT auf OFF gesetzt ist. Das Zuordnen des Felds zu einem Nullwert schließt es nicht aus: Ein Zielfeld wird aus dem INSERT nur ausgelassen, wenn es mit der Funktion Unmap zugeordnet ist.

  • Lösung:

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

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

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

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

      SET IDENTITY_INSERT <table> ON;

      SET IDENTITY_INSERT <table> OFF;

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

SQL Server: Verbindung schlägt mit PKIX-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 funktioniert hat, 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 for 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 fügen Sie es in eine manuelle Verbindungszeichenfolge ein. Dies funktioniert auf Cloud- und Private Agents. Weitere Informationen finden Sie unter Verbindungsverschlüsselung und Serverzertifikate.

    Warnung

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

EDI for Cloud v2 Connector

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

E-Mail-Connector

Gmail-Verbindungstest schlägt mit Authentifizierungsfehler fehl

  • Symptom: Ein Verbindungstest zu einem Gmail-Konto mit Basic Auth schlägt mit einem Authentifizierungsfehler fehl, auch wenn das richtige Google-Kontokennwort eingegeben wird.
  • Mögliche Ursache: Google erfordert ein App-Kennwort für Konten mit aktivierter 2-Faktor-Verifizierung. Das Google-Kontokennwort wird von SMTP oder IMAP nicht akzeptiert, wenn die 2-Faktor-Verifizierung aktiv ist; nur App-Kennwörter funktionieren.
  • Lösung:
    1. Generieren Sie in Ihrem Google-Konto ein App-Kennwort für die Jitterbit-Anwendung (siehe Googles Seite Mit App-Kennwörtern anmelden).
    2. Geben Sie in der E-Mail-Verbindungskonfiguration in Studio das App-Kennwort im Feld SMTP-Kennwort und/oder IMAP-Kennwort ein, anstatt das Google-Kontokennwort zu verwenden.

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

  • Symptom: E-Mails, die mit S/MIME-Signierung konfiguriert sind, können nicht versendet werden, werden vom Server des Empfängers abgelehnt oder kommen unsigniert an, wenn ein Cloud-E-Mail-Anbieter wie Microsoft 365 oder Exchange Online verwendet wird.
  • Mögliche Ursachen:
    • Cloud-Anbieter erfordern ein S/MIME-Zertifikat, das von einer vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt wurde. Selbstsignierte Zertifikate werden von Cloud-Anbietern wie Microsoft 365 (Exchange Online) nicht akzeptiert.
    • S/MIME funktioniert nur bei Verwendung von privaten Agenten. Wenn der Vorgang auf einem Cloud-Agent ausgeführt wird, gilt die S/MIME-Signierung unabhängig vom Zertifikattyp nicht.
  • 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 bei privaten Agenten, dass das Zertifikat korrekt in den Standard-Truststore des Agenten importiert wurde. Bei Cloud-Agenten wird die S/MIME-Signierung nicht unterstützt.

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

  • Symptom: Eine Microsoft 365-OAuth 2.0-Verbindung, die den ROPC-Grant (Resource Owner Password Credentials) verwendet, schlägt bei der Authentifizierung fehl, 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 Multi-Faktor-Authentifizierung (MFA) für die Microsoft 365-Anmeldedaten, die mit dem Connector verwendet werden, deaktiviert ist. Der ROPC-Grant kann eine MFA-Abfrage 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 unter Voraussetzungen für Microsoft 365 beschrieben.
    • Wenn MFA nicht aus dem Konto entfernt werden kann, verwenden Sie eine andere unterstützte Authentifizierungsmethode für die Verbindung anstelle von ROPC.

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

  • Symptom: Eine Email-Aktivität Email 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 Email-Connector erlaubt nicht, dass dieselbe Adresse in mehreren Empfängerfeldern in einer einzelnen Sendeanfrage erscheint. 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 jeder Transformationszuordnung für die Aktivität, um sicherzustellen, dass keine Adresse in mehr als einem Feld erscheint.
    • Wenn Empfängerlisten dynamisch mithilfe von Variablen oder Skripten zusammengestellt werden, fügen Sie vor der Übergabe von Adressen an die Aktivität eine Deduplizierungsprüfung hinzu.

Epicor-Connectoren

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

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

Datei-Connectoren

FTP, File Share und Local Storage: „Keine Dateien entsprechen dem Dateifilter" bei Archiv- oder Folgenschritten

  • Symptom: Eine FTP-, File Share- oder Local Storage-Lesaktivität schlägt fehl, weil sich die Datei, die gelesen werden soll, nicht mehr im Quellpfad befindet:

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

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

  • Mögliche Ursachen:

    • Die Verarbeitungsaktivität hat die Quelldatei bereits als Teil ihres After Processing-Verhaltens verschoben oder gelöscht, sodass der Archivschritt nichts zum Abgleichen hat.
    • 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 nach Abschluss in den endgültigen Namen um. Ein nachgelagerter Lesevorgang, der vor Abschluss der Umbenennung ausgelöst wird, findet die Datei nicht.
  • Lösung:
    • Bestätigen Sie, ob der vorherige Schritt die Archivierung bereits über seine integrierten After Processing-Optionen (verschieben, umbenennen, löschen) durchgeführt hat. Wenn ja, ist ein separater Archivschritt redundant und sollte entfernt werden.
    • Wenn ein separater Archivschritt erforderlich ist, gestalten Sie die Kette so um, dass Verarbeitung und Archivierung gegen dieselbe In-Memory-Dateireferenz erfolgen, anstatt erneut aus der Quelle zu lesen. Übergeben Sie beispielsweise den gelesenen Inhalt über Temporary Storage an den Archivschritt, anstatt den Quellpfad erneut zu lesen.
    • Wenn ein Folgenschritt eine Ausgabe liest, die von einem untergeordneten Vorgang erzeugt wird, führen Sie den untergeordneten Vorgang synchron aus, damit seine Ausgabe vor dem Lesen vorhanden ist. Stellen Sie den Run type des Invoke Operation-Tools auf Synchronously ein, oder führen Sie beim Aufrufen des Vorgangs aus einem Skript RunOperation synchron aus (Standard). Das Einfügen einer festen Verzögerung (z. B. mit der Sleep-Funktion) erhöht die Latenz und garantiert nicht, dass die Datei bereit ist.
    • Wenn eine FTP-Write-Aktivität in denselben Speicherort schreibt, überprüfen Sie, ob Use FTP Rename in der FTP Write-Aktivität aktiviert ist. Wenn der nachgelagerte Lesevorgang vor Abschluss der Umbenennung ausgelöst wird, deaktivieren Sie Use FTP Rename in der Schreibaktivität, oder stellen Sie sicher, dass der Lesevorgang erst ausgeführt wird, wenn die Schreibaktivität vollständig abgeschlossen ist.

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

  • Symptom: Nachdem eine FTP-, File Share- oder Local Storage-Aktivität fehlschlägt, wird keine Datei im konfigurierten Fehlerordner angezeigt.
  • Mögliche Ursache: Der Fehlerordner dient dazu, eine Kopie der Quelldatei nach erfolgloser Verarbeitung zu archivieren. Er erfasst Dateien nur, wenn die Aktivität ausgeführt wird und dann fehlschlägt (z. B. 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 (z. B. ein Authentifizierungsfehler oder eine Meldung, dass der Host nicht erreichbar ist).
    • Verwenden Sie die Schaltfläche Test für die Verbindung, um zu bestätigen, ob das Problem auf Netzwerk- oder Authentifizierungsebene liegt.

FTP, File Share und Local Storage: Dateinamen-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 unerweiterten Schlüsselworttext statt 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 Dateinamen-Schlüsselwortsubstitution. Variablen werden in diesen Feldern nicht erweitert.
    • Diese Felder beziehen sich auf Verzeichnisse auf dem Private Agent-Computer, nicht auf dem Remote-Server. Relative Pfade werden relativ zum Dateisystem des Agent-Hosts interpretiert.
  • Lösung:
    • Verwenden Sie nur literale Pfade (ohne Dateinamen-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 mit Dateifunktionen an den gewünschten Speicherort zu verschieben oder umzubenennen.

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

  • Symptom: Eine dateibasierte Schreibaktivität mit aktivierter Option Write Headers (FTP Write, File Share Write, Local Storage Write oder Temporary Storage Write) schreibt keine Header, wenn die Quelle keine Datensätze zurückgibt. Es wird entweder eine leere Datei erstellt oder es wird überhaupt keine Datei erstellt (wenn auch Do not create empty files ausgewählt ist).
  • Ursache: Dies ist das erwartete Verhalten. Header 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, sodass keine Ausgabe (einschließlich Header) geschrieben wird und Studio eine Warnung protokolliert, dass die Quelle leer ist. Dies ist nicht spezifisch für einen bestimmten Quell-Connector oder ein bestimmtes Flat-File-Ziel.

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

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

SFTP „Anmeldung verweigert. Authentifizierungsfehler." bei Verwendung von SSH-Schlüsseln

  • Symptom: Eine SFTP-Operation mit SSH-Authentifizierung mit privatem Schlüssel schlägt mit Login denied. Authentication failure. fehl, obwohl sich die gleichen 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 Einstellung PrivateKeyPassphrase fehlt im Abschnitt [SSH] der Agent-Datei jitterbit.conf.
    • Ein Passwort ist im FTP-Endpunkt zusammen mit dem privaten Schlüssel konfiguriert. Das Vorhandensein eines Passworts in den Endpunkt-Einstellungen beeinträchtigt die schlüsselbasierte Authentifizierung.

  • Lösung:

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

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

  • Symptom: Eine FTP-Write-Aktivität, die mit der Option Use FTP Rename konfiguriert ist, 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>.

    Der <reason> ist typischerweise 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 hat die Option Use FTP Rename den Umbenennungsschritt beim Schreiben auf einen SFTP-Server nicht zuverlässig berücksichtigt, 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 aktiviertem Use FTP Rename lädt der Agent die Datei jedoch unter einem temporären Namen (Suffix -jbupload) hoch und benennt sie dann um. 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 Einschränkung des SFTP-Servers, nicht von Jitterbit.

  • Lösung:

    • Stellen Sie sicher, dass der Agent Version 11.56 oder später ist, wo 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.

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

SFTP: Anfügen an Datei nicht unterstützt

  • Symptom: Eine FTP-Write-Aktivität, die mit der Option Append To File konfiguriert ist, fügt nicht an die vorhandene Datei an, wenn das Ziel ein SFTP-Server ist.
  • Mögliche Ursache: Das SFTP-Protokoll unterstützt das Anfügen an vorhandene Dateien nicht. Dies ist eine Einschränkung auf Protokollebene, kein Jitterbit-Konfigurationsproblem.
  • Lösung:
    • Verwenden Sie FTP oder FTPS, wenn das Anfügeverhalten erforderlich ist.
    • Wenn SFTP erforderlich ist, implementieren Sie die Anfüglogik manuell: Lesen Sie den vorhandenen Dateiinhalt, 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 analysiert 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 dazu zu bringen, Namen mit Sonderzeichen wie # URL-zu-kodieren, setzen Sie jitterbit.source.ftp.encode_url in einem Transformationsskript für Quell-Datei- oder Ordnernamen auf true, und jitterbit.target.ftp.encode_url auf true für Dateien, die in das Ziel geschrieben werden.

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

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

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

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

Local Storage: Nicht auf Cloud-Agenten verfügbar

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

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

  • Symptom: Temporary Storage-Dateien, die von einem Vorgang geschrieben wurden, fehlen, wenn ein späterer Vorgang versucht, sie zu lesen.
  • Mögliche Ursachen:
    • Der Cleanup-Service von Harmony löscht Dateien aus Temporary Storage standardmäßig nach 24 Stunden.
    • Jeder Agent in einer Agent-Gruppe hat seinen eigenen lokalen Temporary Storage. Vorgänge in der gleichen Vorgangskette werden garantiert auf dem gleichen Agent ausgeführt, aber ein späterer Vorgang, der sich nicht in der gleichen Kette befindet, kann an einen anderen Agent verteilt werden und auf eine andere Temporary Storage-Instanz zugreifen, sodass die Datei nicht gefunden wird, unabhängig vom 24-Stunden-Fenster. Siehe Wichtige Hinweise.
  • Lösung:
    • Verknüpfen Sie Vorgänge, die Temporary Storage-Dateien gemeinsam nutzen müssen, in die gleiche Vorgangskette mit Vorgangsaktionen, wobei das Temporary Storage-Verhalten konsistent und zuverlässig ist.
    • Für private Agenten kann die Cleanup-Häufigkeit im Abschnitt [FileCleanup] von jitterbit.conf angepasst werden. Siehe [FileCleanup].
    • Wenn Dateien nicht innerhalb der gleichen Kette verarbeitet werden können oder länger als 24 Stunden bestehen bleiben müssen, verwenden Sie stattdessen einen persistenten Speicher-Connector, auf den alle Agenten zugreifen können (z. B. File Share, FTP oder Cloud Datastore), anstelle von Temporary Storage.

Temporary Storage: Eingeschränkte Zeichen in Dateipfaden

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

Temporary Storage: 50-GB-Dateigrößenlimit bei Cloud-Agenten

  • Symptom: Eine Temporary Storage Write-Aktivität schlägt beim Schreiben großer Dateien über einen Cloud-Agenten fehl.
  • Mögliche Ursache: Cloud-Agenten setzen eine maximale Dateigröße von 50 GB pro Datei für Temporary Storage durch.
  • Lösung:
    • Verwenden Sie einen privaten Agenten für Workflows, die einzelne Dateien größer als 50 GB in Temporary Storage schreiben müssen.
    • Falls nur Cloud-Agenten verfügbar sind, teilen Sie große Datenmengen in mehrere Dateien unter 50 GB auf, bevor Sie sie in Temporary Storage 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 Authentifizierung auf Verbindungsebene als auch ein manuell definierter Authorization-Request-Header auf derselben Verbindung oder Aktivität konfiguriert sind.
  • Mögliche Ursache: Wenn die Authentifizierung auf einer HTTP v2-Verbindung konfiguriert ist (z. B. Basic oder OAuth), fügt der Connector automatisch einen Authorization-Header zu jeder Anfrage hinzu. Das manuelle Hinzufügen eines zweiten Authorization-Headers führt zu zwei widersprüchlichen Headern, die die meisten Server mit einem 400-Fehler ablehnen.
  • Lösung:
    • Entfernen Sie alle manuell hinzugefügten Authorization-Header aus den Request-Headern in der Aktivitäts- oder Verbindungskonfiguration.
    • Verwenden Sie nur die integrierten Authentifizierungseinstellungen in der Verbindung zur Authentifizierung. Fügen Sie keinen manuellen Authorization-Header neben der konfigurierten Authentifizierung hinzu.
    • Falls Sie den Authorization-Header dynamisch auf Aktivitätsebene festlegen müssen, setzen Sie den Authentifizierungstyp der Verbindung auf No Auth und konfigurieren Sie den Authorization-Request-Header der Aktivität nach Bedarf.

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

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

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

    Dasselbe JSON funktioniert, wenn es 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, escaped 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 nicht escapten Anführungszeichen unterbrechen die Header-Zeichenkette, bevor sie das Ziel erreicht.

  • Lösung:
    • Wenn Sie JSON in einer Projektvariablen speichern, die als Header-Wert verwendet wird, escapen Sie jedes doppelte Anführungszeichen mit einem Backslash. Speichern Sie den Wert beispielsweise als {\"success\": \"true\"} statt als {"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 das notwendige Escaping in diesem Pfad an.

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

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

  • Symptom: REST-API-Aufrufe über den HTTP v2-Connector schlagen beim Zielsystem fehl, da URL-Parameter in der ausgehenden Anfrage doppelt codiert erscheinen (z. B. wird ein %20-Leerzeichen zu %2520).
  • Mögliche Ursache: Wenn Encode request URL in den HTTP v2-Verbindungseinstellungen aktiviert ist, codiert der Connector die gesamte URL vor dem Senden. Wenn URL-Parameter bereits prozentcodierte Zeichen enthalten, werden diese Zeichen ein zweites Mal codiert.
  • Lösung:
    • Deaktivieren Sie Encode request URL in den HTTP v2-Verbindungseinstellungen, wenn die URL oder Parameter bereits codiert sind oder mit der Funktion URLEncode konstruiert wurden.
    • Wenn 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 Aktivitätspfad werden nicht aufgelöst

  • Symptom: Eine HTTP v2-Aktivität verwendet eine globale, Projekt- oder Jitterbit-Variable in ihrem Feld Path, aber zur Laufzeit wird die Variable buchstäblich (unaufgelöst) gesendet, anstatt durch ihren Wert ersetzt zu werden.
  • Mögliche Ursache: Eine vollständige URL (eine, die das Protokoll und den Host enthält, z. B. https://api.example.com/...) wurde in das Feld Path eingegeben. Variablen werden in vollständigen URLs nicht unterstützt. Sie werden nur in einem 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 Host-Teil des Endpunkts fest (z. B. 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 (z. B. /records/[recordId]). Der Connector löst die Variable auf und hängt das Ergebnis zur Laufzeit an die Base URL an.

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

  • Symptom: Skripte, die Jitterbit-Quell- oder Ziel-Variablen lesen, 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 Ziel-Variablen nicht auf. Antwortdaten, einschließlich des HTTP-Status-Codes, werden stattdessen über das Antwortsschema der Aktivität zurückgegeben.
  • Lösung:
    • Um den Status-Code mit dem Standard-Antwortsschema 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). Weitere Informationen zur Struktur des Antwortsschemas finden Sie in der Aktivitätskonfigurationsdokumentation für jede HTTP v2-Aktivität.
    • Um den Status-Code bei Verwendung eines benutzerdefinierten Antwortsschemas zu erfassen, aktivieren Sie Include Additional Properties from HTTP Response in the Schema in der Aktivitätskonfiguration. Dies umhüllt das Schema mit einer von Jitterbit definierten Struktur, die __jitterbit_api_statuscode__ (den Status-Code) und __jitterbit_api_errorbody__ (den Antwortkörper für erfolglose Anfragen) enthält.
    • Damit der Status-Code verfügbar ist, wenn die API eine erfolglose Antwort zurückgibt, aktivieren Sie Ignore operation error in case of non-successful status code in den optionalen Einstellungen der Aktivität. Ohne diese Einstellung schlägt der Vorgang bei erfolglosen Antworten fehl, bevor die Antwortdaten zugeordnet werden können.

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

  • Symptom: Ein HTTP v2-Vorgang, der eine XML-Payload an einen SOAP- oder XML-Webservice sendet, schlägt mit einem Serverfehler fehl (z. B. 500 Internal Server Error), obwohl die gleiche Payload erfolgreich von Postman oder SoapUI gesendet wird. Eine Überprüfung des vom Ziel empfangenen Request-Body zeigt, dass XML-Namespace-Deklarationen auf dem Root-Element 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 neu nummeriert).
  • Mögliche Ursache: Wenn in der HTTP v2-Aktivitätskonfiguration ein benutzerdefiniertes Request-Schema verwendet wird, normalisiert die Transformation standardmäßig die XML, indem alle Namespace-Deklarationen zum Root-Knoten verschoben und ihre Präfixe neu zugewiesen werden. SOAP-Services und andere XML-Endpunkte, die die Konsistenz von Namespace-Präfixen validieren, lehnen die geänderte Payload ab.

  • Lösung:

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

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

    • Wenn Ihre Private Agents älter als 12.8 sind, oder das Ziel auch die Konsolidierung von Namespace-Deklarationen auf dem Root-Element ablehnt, verwenden Sie stattdessen das Standard-Request-Schema und ordnen Sie die vollständige XML-Payload als String in das Feld body des Schemas zu. Die Payload wird dann als String behandelt und nicht als XML geparst, sodass ihre Namespace-Deklarationen erhalten bleiben. Das Antwortsschema kann weiterhin ein benutzerdefiniertes Schema sein.

HTTP v2: Leerzeichen werden als + statt %20 codiert

  • Symptom: REST-API-Aufrufe mit dem HTTP v2-Connector schlagen im Zielsystem fehl, weil Leerzeichen in der URL als + statt %20 codiert 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 Request-URL codieren. Der Connector codiert dann die Request-URL URL-konform und codiert Leerzeichen als %20.
    • Geben Sie die Request-URL vollständig uncodiert an. Codieren Sie Zeichen nicht vorab und wenden Sie die Funktion URLEncode nicht auf die URL an, da bereits codierte Zeichen doppelt codiert werden, wenn Request-URL codieren aktiviert ist (z. B. wird example+string%20value zu example%20string%2520value).

HTTP: Sendet null als String "null"

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

LDAP-Connector

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

  • Symptom: Eine LDAP-Aktivität Delete Entry schlägt mit einem Fehler vom LDAP-Server fehl (z. B. notAllowedOnNonLeaf oder eine Meldung, die angibt, dass der Eintrag kein Blattknoten ist).
  • Mögliche Ursache: Das LDAP-Protokoll erlaubt nicht das Löschen eines Eintrags, der untergeordnete Einträge (Unterordnungen) hat. Der Eintrag muss ein Blattknoten ohne untergeordnete Elemente 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 einer gesamten Teilstruktur erforderlich ist, implementieren Sie ein Skript, das Einträge von unten nach oben identifiziert und löscht, indem Sie RunOperation mit der LDAP-Aktivität Delete Entry für jeden Eintrag verwenden.

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

  • Symptom: Eine LDAP-Aktivität Search Entry gibt keine Ergebnisse zurück oder gibt einen Fehler aus, obwohl die abgefragten Einträge im Verzeichnis vorhanden sind.
  • Mögliche Ursache: Einige LDAP-Server erfordern, dass Attributnamen in Filterausdrücken genau der Groß-/Kleinschreibung entsprechen, die das Schema des Servers verwendet. Der von Studio vorausgefüllte Filterausdruck verwendet Titelschreibweise für die strukturelle Klasse (z. B. ObjectClass), aber einige Server erfordern eine andere Groß-/Kleinschreibung (z. B. objectClass).
  • Lösung:
    1. Überprüfen Sie in der LDAP-Aktivitätskonfiguration Search Entry das vorausgefüllte Feld Filter Expression.
    2. Passen Sie die Groß-/Kleinschreibung von Attributnamen an, die der LDAP-Zielserver erwartet. Ändern Sie z. B. ObjectClass in objectClass, wenn der Server Kleinbuchstaben erfordert.
    3. Konsultieren Sie die Dokumentation oder Schemadefinition Ihres LDAP-Servers für die erforderlichen Attributbenennungskonventionen.

Microsoft-Konnektoren

Microsoft SharePoint Online: SOAP-Schema-Verbindungen nach IDCRL-Einstellung fehlgeschlagen

  • Symptom: Operationen, die einen Microsoft SharePoint Server-Konnektor mit dem SOAP-Schema-Verbindungstyp verwenden, 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 wird. Nach dem 1. Mai 2026 wird erwartet, dass Operationen, die das SharePoint-SOAP-Schema für SharePoint Online-Verbindungen verwenden, fehlschlagen.
  • Lösung:
    1. Öffnen Sie in Studio jede betroffene SharePoint-Verbindung und ändern Sie die Schema-Einstellung von SOAP zu REST.
    2. Konfigurieren Sie alle Aktivitäten, die das SOAP-Schema verwendet haben, so um, dass sie entsprechende REST-Operationen verwenden.
    3. Testen und stellen Sie die betroffenen Operationen erneut bereit.
    4. Weitere Informationen zur Migration finden Sie in der Dokumentation zum Microsoft SharePoint Server-Konnektor.

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

  • Symptom: Operationen, die den Microsoft Dynamics 365 Business Central v2-Konnektor verwenden, schlagen mit Fehlern fehl, die darauf hindeuten, dass Typnamen in der Nutzlast nicht mit den OData-Metadaten kompatibel sind.
  • Mögliche Ursache: Bestimmte Dynamics 365 Business Central OData-API-Endpunkte erfordern OData-Typanmerkungen in der Anfragenutzlast. Standardmäßig enthält der Konnektor diese Anmerkungen nicht, was zu Typinkompatibilitätsfehlern für diese Endpunkte führt.
  • Lösung:
    1. Öffnen Sie die Konfiguration der Microsoft Dynamics 365 Business Central v2-Aktivität Aktualisieren.
    2. Aktivieren Sie unter Optionale Einstellungen die Option OData-Typ in Nutzlast festlegen.
    3. Speichern Sie die Aktivität und testen Sie die betroffenen Operationen erneut.

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

  • Symptom: Beim Konfigurieren einer Microsoft Entra ID-Aktivität Abfrage werden das Feld onPremisesExtensionAttributes und seine untergeordneten Erweiterungsattributfelder (z. B. extensionAttribute1 bis extensionAttribute15) nicht in der Auswahl Objektfelder in Schritt 3 angezeigt und können nicht als Bedingungsklausel-Filterbedingungen ausgewählt werden.
  • Mögliche Ursache: onPremisesExtensionAttributes ist ein komplexer Typ (verschachteltes) Objekt. Die Auswahl Objektfelder in Schritt 3 zeigt nur primitive Datentypen an; komplexe Typfelder sind von der Auswahlliste ausgeschlossen.
  • Lösung: Die Felder onPremisesExtensionAttributes müssen nicht in Schritt 3 ausgewählt werden, um zurückgegeben zu werden. Sie werden im Ausgabeschema der Aktivität in Schritt 4 angezeigt und zur Laufzeit aufgefüllt, wenn die Operation ausgeführt wird. Um auf Erweiterungsattributwerte zuzugreifen, ordnen Sie sie von onPremisesExtensionAttributes und seinen untergeordneten Feldern in der Transformation zu.

Microsoft Entra ID-Aktivität „Aktualisieren": DateTime-Felder mit Edm.String-Typkonflikt abgelehnt

  • Symptom: Eine Microsoft Entra ID-Aktivität Aktualisieren schlägt fehl mit:

    Ein Wert wurde gefunden, dessen Typname nicht mit den Metadaten kompatibel ist.
Der Wert gibt seinen Typ als „Edm.String" an, aber der in den Metadaten angegebene Typ ist „Edm.DateTimeOffset".
[HTTP/1.1 400 Bad Request]

  • Mögliche Ursache: Der Connector sendet DateTime-Feldwerte (z. B. employeeHireDate) ohne die von der 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-Aktivität Update.
    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 erneut aus.

Microsoft Entra ID-Abfrage: „Nicht unterstützte oder ungültige Abfragefilterbedingung" bei gefilterten Eigenschaften

  • Symptom: Eine Microsoft Entra ID-Aktivität Query 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 ist 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 ansonsten korrekt ist. Der Connector fügt automatisch den erforderlichen Header ConsistencyLevel: eventual ein, aber $count=true muss separat hinzugefügt werden.

  • Lösung: Wählen Sie je nach verwendetem Tab in Schritt 3 eine der folgenden Optionen:
    • Registerkarte „Basic": Aktivieren Sie das Kontrollkästchen Include Count. Dies fügt $count=true automatisch zur Abfrage hinzu.

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

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

Die Liste der Eigenschaften, die eine 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 „Anmeldung fehlgeschlagen" 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 Jitterbit Dynamics AX 2012 Connector REST Service-Protokoll 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 eingestellt. Die AX 2012-Authentifizierung erfordert, dass Domain Name die DNS-Domänennamenserweiterung ist (z. B. yourcompany.com), nicht ein kurzer oder NetBIOS-Domänenname. Ein falscher Domänenwert führt dazu, dass AX ansonsten gültige Anmeldedaten 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-Domänennamenserweiterung fest (z. B. yourcompany.com), nicht auf einen kurzen/NetBIOS-Domänennamen.
    3. Bestätigen Sie, dass Login der Benutzername des AX-Dienstkontos mit den erforderlichen Berechtigungen ist, und geben Sie das Password erneut ein, um einen veralteten Wert auszuschließen.
    4. Testen Sie die Verbindung und führen Sie den Vorgang erneut aus.

NetSuite-Connector

Hinweis

NetSuite verfügt über einen dedizierten Troubleshooting-Leitfaden, der zusätzliche Verbindungs-, Schema-, Aktivitätskonfigurations- und Leistungsprobleme abdeckt. Siehe NetSuite-Troubleshooting.

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

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

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

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

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

OData-Connector

OData v2-Entitätsmengen können nicht geladen werden mit „No entity sets found"

  • 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 über die Verbindungseinstellung OData version zum OData-Connector hinzugefügt. Bei Agents vor Version 11.59 unterstützt der Connector nur OData V4, daher kann eine Verbindung zu einem OData V2-Service die Objektliste nicht auffüllen. Der gleiche Fehler tritt in 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 und testen Sie die Verbindung erneut.
    3. Öffnen Sie die OData-Query-Aktivität erneut. Die Entitätsmengen sollten jetzt 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 für das Standardunternehmen des Benutzers zurück, daher fehlen Datensätze aus anderen Unternehmen in den Ergebnissen.
  • Mögliche Ursache: Ein Dynamics 365 Finance and Operations-OData-Endpunkt gibt standardmäßig nur die Daten zurück, die zum Standardunternehmen des Benutzers gehören. Um der Verbindung einen unternehmensübergreifenden (erweiterten) Umfang zu geben, muss eine unternehmensübergreifende Filterklausel an die OData metadata URL der Verbindung (die $metadata-URL) angehängt werden. Auf der Metadaten-URL wird ?cross-company=true allein nicht den erweiterten Umfang angewendet.

  • Lösung: Hängen Sie in der OData-Verbindung eine dataAreaId-Filterklausel an die OData metadata URL an, ersetzen Sie usrt durch Ihre Datenbereichs-ID und speichern Sie dann und testen Sie erneut:

    ?$filter=dataAreaId eq 'usrt'&cross-company=true

    Hintergrundinformationen zur Bereichsverwaltung von OData-Daten nach Unternehmen in Dynamics 365 finden Sie in der Microsoft-Dokumentation zum Thema unternehmensübergreifendes Verhalten.

Oracle-Konnektoren

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

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

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

  • Mögliche Ursache: Der Oracle EBS-Konnektor erfordert, dass der Oracle JDBC-Treiber (ojdbc8.jar) manuell auf dem privaten Agent platziert wird. Diese Datei ist nicht im Agent enthalten 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 speziellen Leitfaden zur Fehlerbehebung, der Authentifizierung, Schema, Aktivitätskonfiguration, Datensatzlimit und Bulk-Aktivitätsprobleme abdeckt. Siehe Salesforce-Konnektor-Fehlerbehebung.

Salesforce Events: Events können nach Agent-Neustart nicht aktiviert werden

  • Symptom: Nach dem Neustart oder der Neuinstallation eines privaten Agents können Salesforce Events-Konnektor-Events nicht aktiviert werden, auch 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 das Herunterladen der Konnektor-JAR auf den Agent.
    3. Nachdem der Verbindungstest erfolgreich ist, 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 Insert, Update und Delete CDC Event) sind zu erwarten 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 begrenzt die Anzahl der gleichzeitigen Clients (Abonnenten). Wenn diese Grenze 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 von der Salesforce API absichtlich 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 von der Salesforce API absichtlich 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, erscheinen in Studio als 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 Sie 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.
    • Wenn Daten aus mehreren Systemen in einem einzelnen Workflow erforderlich sind, teilen Sie die Logik auf separate Vorgänge auf und verketten Sie diese mithilfe von Vorgangsaktionen.

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

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

    JCoException occurred No RFC authorization for function module BAPI_TRANSACTION_COMMIT

  • Mögliche Ursachen:

    • Das SAP-Benutzerkonto in der Verbindung verfügt nicht über 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-fähig konfiguriert.
    • Die der Aktivität vorgelagerte Anforderungstransformation setzt das Commit-Steuerfeld nicht.

  • Lösung:

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

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

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

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

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

  • Lösung:
    1. Bearbeiten Sie den SAP-Endpunkt in Studio und setzen Sie das Feld Sprache auf einen unterstützten zweistelligen Sprachcode (z. B. EN für Englisch).
    2. Überprüfen Sie, dass der Wert einem auf dem SAP-Zielsystem installierten und aktiven Sprachcode entspricht. 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 von Studio aus, um zu bestätigen, dass die Initialisierung erfolgreich ist, bevor Sie den Vorgang erneut bereitstellen.

ServiceNow-Connector

Erste Operationsläufe sind nach Agent-Neustart oder auf Cloud-Agenten langsam

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

    • Auf privaten Agenten kann die erste Operation nach dem Agent-Neustart mehrere Minuten dauern; nachfolgende Läufe sind schnell.
    • Auf Cloud-Agenten laufen die Operationen zeitweise langsam und dauern Minuten, wenn sich der Metadaten-Cache des Connectors aktualisiert.

    Dies kann zu nachgelagerten API-Timeouts führen.

  • Mögliche Ursache: Der Connector speichert ServiceNow-Metadaten aggressiv. Nach einem Agent-Neustart auf einem privaten Agent (oder bei jedem Lauf für einen Cloud-Agent, der den Cache nicht beibehalten hat), muss die erste Operation den Cache neu aufbauen, was mehrere Minuten dauert.

  • Lösung:
    • Auf einem privaten Agent können Sie die Langsamkeit nach dem Neustart verringern, indem Sie getcolumnsmetadata=onUse zu den Erweiterten Optionen des ServiceNow-Endpunkts hinzufügen. Diese Einstellung ist nur auf privaten Agenten wirksam.
    • Für konsistente Leistung auf Cloud-Agenten rufen Sie die ServiceNow REST API über den HTTP v2-Connector auf, anstatt den ServiceNow-Connector zu verwenden. Der HTTP v2-Connector speichert keine Metadaten und vermeidet die Verzögerung beim Neuaufbau.

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 unter demselben Namen nicht gefunden werden.
  • Ursache: Die Verwendung der ServiceNow REST API durch den ServiceNow v2-Connector macht Objekte unter Verwendung des tatsächlichen Backend-Tabellennamens von ServiceNow verfügbar, der sich vom Namen unterscheiden kann, der für dasselbe Objekt im ServiceNow-Connector verwendet wird. Beispielsweise entspricht das Objekt mit dem Namen System im ServiceNow-Connector Sys im ServiceNow v2-Connector.
  • Lösung: Suchen Sie in ServiceNow den tatsächlichen Tabellennamen des Objekts unter System Definition > Tables auf und suchen Sie dann nach diesem Namen in der Aktivitätskonfiguration des ServiceNow v2-Connectors.

Shopify-Connector

Shopify: Aktivitätsobjektauswahlen können sich nach API-Versionsaktualisierung ändern

  • Symptom: Nach dem Ändern der API-Version auf einer Shopify-Verbindung geben eine oder mehrere Shopify-Aktivitäten Fehler zurück oder verhalten sich unerwartet, und ein konfiguriertes Objekt oder Unterobjekt scheint sich geändert zu haben.
  • Mögliche Ursache: Shopify veröffentlicht vierteljährlich neue API-Versionen und 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, was dazu führt, dass sich die konfigurierte Auswahl der Aktivität ändert, wenn die Konfiguration aktualisiert wird.
  • Lösung:
    1. Öffnen Sie nach dem Ändern der Shopify API-Version in der Verbindung jede betroffene Shopify-Aktivitätskonfiguration.
    2. Klicken Sie auf Aktualisieren, um die verfügbaren Objekte für die neue API-Version neu zu laden.
    3. Überprüfen Sie die Objekt- und Unterobjektauswahlen, um zu bestätigen, dass sie Ihre Absicht unter der neuen Version widerspiegeln.
    4. Aktualisieren Sie alle Auswahlen, die sich geändert haben, auf die korrekten Ersatzobjekte.
    5. Stellen Sie die betroffenen Operationen erneut bereit und testen Sie sie erneut.
    6. Informationen zu den Abschreibungszeitplänen der Shopify API-Version finden Sie im Shopify-Änderungsprotokoll.

Snowflake-Connector

Snowflake: 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, beispielsweise mit:

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

  • Mögliche Ursache: Snowflake stellt die Single-Factor-Authentifizierung (nur Passwort) ein, einschließlich für die LEGACY_SERVICE-Kontotypen, die für diesen Authentifizierungstyp erforderlich sind. Snowflake migriert LEGACY_SERVICE-Konten auf Basis eines rollierenden, kontoweisen Plans zu TYPE=SERVICE, was passwortbasierte Authentifizierung vollständig blockiert. Bei einigen Konten ist auch Multi-Factor-Authentifizierung (MFA) aktiviert, was 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: Aktualisieren Sie die Snowflake-Connector-Verbindung in Studio, um OAuth oder Key-Pair-Authentifizierung zu verwenden, und konfigurieren Sie das Snowflake-Benutzerkonto entsprechend. Stellen Sie sicher, dass es nicht in MFA registriert ist.

Snowflake: Developer-Instanz schläft, Metadatentabellen werden nicht gefüllt

  • Symptom: Beim Konfigurieren einer Snowflake-Aktivität wird die Liste der verfügbaren Objekte nicht gefüllt oder erscheint leer, obwohl der Verbindungstest erfolgreich ist.
  • Mögliche Ursache: Snowflake Developer Instances wechseln in den Ruhezustand, wenn auf sie lange nicht zugegriffen wurde. Während der Verbindungstest gegen eine schlafende Instanz erfolgreich sein kann, gibt die Instanz möglicherweise keine Tabellen- und Objektmetadaten zurück.
  • Lösung:
    1. Melden Sie sich bei der Snowflake-Weboberfläche an, um die Instanz zu aktivieren.
    2. Öffnen Sie die Snowflake-Verbindung in Studio erneut und klicken Sie auf Test, um die Anmeldedaten erneut zu testen.
    3. Öffnen Sie die Aktivitätskonfiguration erneut, um die Liste der verfügbaren Objekte zu aktualisieren.

Snowflake Query: Schemaabweichung bei Groß-/Kleinschreibung des Flat-Schema-Stammknotens verursacht ProcessFlatStream-Fehler

  • Symptom: Eine Snowflake-Query-Aktivität mit einem Flat-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 der XML-Antwort in Kleinbuchstaben zurück. Wenn Studio ein Flat-Schema aus der Abfrage generiert, wird der Stammknotenname in Großbuchstaben erstellt. Die Abweichung bei der Groß-/Kleinschreibung zwischen dem Schemastammknoten (Großbuchstaben) und dem XML-Antwortstammknoten (Kleinbuchstaben) führt dazu, dass die Flat-Stream-Verarbeitung fehlschlägt.

  • Lösung: Wählen Sie eine der folgenden Optionen:
    • Ändern Sie im Flat-Schema den Namen des Stammknotens in Kleinbuchstaben, um die Connector-Ausgabe zu entsprechen. Benennen Sie beispielsweise SALES_ORDERS in sales_orders um.
    • Verwenden Sie das Mirror-Schema mit Standardzuordnung anstelle eines manuell erstellten Flat-Schemas. Das Mirror-Schema leitet seine Struktur direkt aus der Connector-Antwort ab und weist diese Abweichung bei der Groß-/Kleinschreibung 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. Dieselbe Aktivität, die für eine interne Stage konfiguriert ist, stellt beide Felder bereit.
  • Mögliche Ursache: Externe Stages sind schreibgeschützte Verweise auf Dateien, die bereits in externem Cloud-Speicher (S3, GCS oder Azure Blob) vorhanden sind. Die Merge-Aktivität kann keinen Dateiinhalt in eine externe Stage hochladen, daher werden die Felder, die diesen Upload steuern, aus dem Schema weggelassen.
  • 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 dem Vorgang übertragen müssen, konfigurieren Sie die Merge-Aktivität für die Verwendung einer internen Stage. Das Schema stellt dann stageName und fileContent bereit.

Snowflake Insert oder Merge: SQL-Syntaxfehler durch Sonderzeichen

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

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

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

  • Mögliche Ursachen:

    • Feldwerte mit einfachen Anführungszeichen (z. B. ein Wert wie corner's) werden nicht maskiert, bevor sie in die SQL-Nutzlast aufgenommen werden. Das nicht maskierte Anführungszeichen beendet die Zeichenkette vorzeitig, wodurch der Rest des Werts 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 führt dies zu einem Syntaxfehler beim Bindestrich.

  • Lösung:

    • Für Werte mit einfachen Anführungszeichen: Aktivieren Sie in den Optionalen Einstellungen der Snowflake-Verbindung die Option Sonderzeichen maskieren. Dies maskiert automatisch einfache Anführungszeichen in Insert- und Invoke Stored Procedure-Aktivitätsnutzlasten. 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 maskieren, 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-Space-Fehler beim Abfragen großer Datenmengen

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

    Error executing query activity. Exception is Java heap space

    Der Connector meldet den Fehler in dieser Form, da 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 wenige Zeilen zurückgeben, oder wenn derselbe Agent auch über andere Connectors mit Heap-Fehlern fehlschlägt, ist die Ursache wahrscheinlicher die Gesamtheap-Zuordnung des Agenten als die Größe des Ergebnissatzes. Siehe Java heap space: OutOfMemoryError.

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

  • Lösung: Bei großen Abfragevolumina verwenden Sie den Database-Connector mit einem Snowflake-JDBC-Treiber anstelle des Snowflake-Connectors. Der Database-Connector puffert das vollständige Resultset nicht im Speicher, daher kann er viel größere Abfragevolumina verarbeiten. Installieren Sie den Snowflake-JDBC-Treiber auf dem privaten Agent und konfigurieren Sie dann eine Database-Verbindung, die diesen verwendet. Bei Agent 12.x und später benötigt diese Database-Verbindung auch enableArrowResultFormat=false&jdbc_query_result_format=json in ihrer Verbindungszeichenfolge; siehe Snowflake: Operationen schlagen bei Agent 12.x fehl.

    Falls Sie beim Snowflake-Connector bleiben müssen, können folgende Maßnahmen den Speicherdruck reduzieren, obwohl keine davon garantiert ausreichend für Datensätze mit Millionen von Zeilen ist:

    • Teilen Sie die Abfrage in Batches mit SQL-Klauseln LIMIT und OFFSET 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 Snowflake über einen Snowflake-JDBC-Treiber abfragen (eine Database-Verbindung oder ein DBExecute-Skript), zur Laufzeit fehl, obwohl der Verbindungstest erfolgreich ist. Der Fehler bezieht sich auf die Arrow-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: Standardmäßig gibt der Snowflake-JDBC-Treiber Abfrageergebnisse im Apache-Arrow-Format zurück, das nicht mit Agent-Version 12.x und später kompatibel ist. Weitere Details finden Sie in Snowflakes Artikel zur Fehlerbehebung bei diesem Java-Modulfehler. Der Verbindungstest gibt kein Resultset zurück, daher wird er bestanden, 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 statt Arrow zurückgibt:

    • Database-Connector: Fügen Sie enableArrowResultFormat=false&jdbc_query_result_format=json zur Snowflake-Verbindungszeichenfolge im Feld Zusätzliche Verbindungszeichenfolgen-Parameter hinzu (oder im Feld Verbindungszeichenfolge, falls Verbindungszeichenfolge verwenden ausgewählt ist).
    • Snowflake-Connector: Fügen Sie unter Optionale Einstellungen > Benutzerdefinierte Verbindungseigenschaften 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.

    Bei einem privaten Agent können Sie die Korrektur stattdessen auf JVM-Ebene anwenden, damit 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

    2. Öffnen Sie den Unterschlüssel Options.

    3. Fügen Sie im Feld Value data zu den vorhandenen Java-Optionen --add-opens=java.base/java.nio=ALL-UNNAMED hinzu.
    4. Klicken Sie auf Ok.
    5. 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 in den 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: „Keine WSDL mit 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 unterbrochen, sodass das Projekt auf eine WSDL-ID verweist, die nicht mehr vorhanden ist.

    • Das Projekt wurde vor der Harmony-Version 12.9 bereitgestellt oder in eine andere Umgebung übertragen, als die Bereitstellung eines Projekts noch WSDL-Dateien löschen konnte, die noch verwendet wurden. Die Version 12.9 verhindert das Löschen, aber eine vorher gelöschte WSDL 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 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 ihrer Konfiguration erneut hoch.

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

    3. Stellen Sie das Projekt erneut bereit.

    4. Wenn das Projekt mehrere WSDLs enthält und nicht klar ist, welche betroffen ist, lesen Sie SOAP-Verbindungsfehlersuche, 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 erzeugt Schemaauflösungsfehler zur Entwurfszeit.
  • 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 nicht von absoluten Remote-URLs 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-Activity erzeugte XML-Envelope stimmt nicht mit den literalen Namespace-Präfixen oder der Struktur der Quell-WSDL überein (beispielsweise ersetzt der Connector xmlns:ns1 durch xmlns:glob). Strikte SOAP-Services, die den exakten Präfixtext vergleichen, lehnen die Anfrage ab.
  • Mögliche Ursache: Die Transformations-Engine verarbeitet SOAP-Nachrichten als strukturiertes XML, nicht als literalen Text. Sie erzeugt eine semantisch äquivalente Payload, die möglicherweise andere Namespace-Präfixe als die 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 verweist.
    2. Erstellen Sie in einer Transformation die SOAP-Envelope als String, indem Sie String-Literale und zugeordnete Werte mit dem +-Operator verketten. Alternativ lesen Sie eine Vorlage aus einer Datei und ersetzen Sie dynamische Werte mit Replace.
    3. Verwenden Sie im HTTP v2 POST-Activity das Standard-Request-Schema (laden Sie kein benutzerdefiniertes Request-Schema hoch) und ordnen Sie die konstruierte SOAP-Envelope-String dem body-Feld dieses Schemas zu. Der Connector sendet den body-Wert unverändert und bewahrt das literale XML.
    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 des Activity.

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

VTEX-Connector

Verbindungstest schlägt mit „Sie haben keine Berechtigung, auf diese Ressource zuzugreifen" fehl

  • 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 der Anwendungsschlüssel, der der Verbindung zugeordnet ist, verfügt über eine oder mehrere Berechtigungen nicht, die der Connector zur Validierung der Verbindung verwendet. Diese Berechtigungen sind strenger als die für den grundlegenden Datenzugriff erforderlichen.

  • Lösung:
    1. Öffnen Sie im VTEX-Admin-Portal das Zugriffsprofil, das dem Benutzer oder 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 mit dem Workday-Connector, der mit WSDL-Version 42.0 oder 42.1 konfiguriert ist, 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 spezifisch für diese WSDL-Versionen auftreten.
  • 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 fehl mit „Die eingereichte Aufgabe ist nicht autorisiert"

  • Symptom: Ein Workday-Verbindungstest schlägt mit folgendem Fehler 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. Beachten Sie, dass Operationen zur Laufzeit erfolgreich ausgeführt werden können, auch wenn der Verbindungstest diesen Fehler zurückgibt, da der Test einen bestimmten Workday-Service (Get_Message_Template_Translation_Request) aufruft, der eine Berechtigung erfordert, die der ISU möglicherweise nicht hat, während die tatsächlichen Integrationsoperationen andere Services aufrufen.

  • Mögliche Ursachen:

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

  • Lösung:

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