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 mit bekannten, connector-spezifischen Problemen auf, nicht jeden verfügbaren Connector. Die vollständige Liste der Connectoren finden Sie unter Connectoren. Beginnen Sie mit den Diagnoseschritten unten und suchen Sie dann 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, sofern die Organisationsrichtlinie Disable Auto Connector Update nicht aktiviert ist.

Verbindungsmetadaten und Aktivitätsschemas aktualisieren

Viele Connector-Probleme, wie fehlende Objekte, eine veraltete Feldliste oder ein Schema, das nicht mehr dem Endpunkt entspricht, werden durch zwischengespeicherte Metadaten verursacht. Nach jeder Änderung auf der Endpunktseite (neue Felder, eine API-Versionsaktualisierung oder eine Berechtigungsänderung) öffnen Sie die betroffene Aktivität erneut und klicken Sie auf das Aktualisierungssymbol (Refresh), 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. Bei 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 Agenten 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 muss, finden Sie im Abschnitt Troubleshooting auf der Dokumentationsseite des jeweiligen 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 sind nur in bestimmten Regionen verfügbar und erfordern ein Regionspräfix in der Modell-ID.

  • Lösung:
    1. Fügen Sie das Regionspräfix zur Modell-ID hinzu. Beispiel: anthropic.claude-3-5-haiku-20241022-v1:0 wird zu us-anthropic.claude-3-5-haiku-20241022-v1:0.
    2. Geben Sie die Modell-ID mit Präfix mithilfe der Option Modellkennung eingeben in der Aktivitätskonfiguration ein.

Cloud Datastore Connector

Aktivität „Elemente löschen" meldet Erfolg, löscht aber den Datensatz nicht

  • Symptom: Eine Cloud Datastore-Aktivität Elemente löschen meldet Erfolg im Operationsprotokoll, aber der Zieldatensatz existiert noch, wenn er danach abgefragt wird.
  • Mögliche Ursache: Elemente löschen identifiziert Datensätze anhand des Schlüssel-Werts (oder Alternativer Schlüssel) des Speichers, der im Array keys oder ids 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 Anfrage Elemente löschen vorbereitet, den Schlüssel-Wert (oder Alternativer Schlüssel) des Speichers zu, nicht die interne Datensatz-ID.
    • Wenn Sie von einer Aktivität Elemente abfragen 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 die API-Schlüssel-Authentifizierung verwendet wird.
  • Mögliche Ursache: Seit Coupa Release R35 (Januar 2023) sind Coupa API-Schlüssel veraltet und werden für die Authentifizierung nicht mehr unterstützt. Verbindungen, die für die 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 sie und führen Sie einen erneuten Test durch.

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, 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 versuchen möglicherweise fälschlicherweise, einen JDBC-Ergebniswert zu Base64-decodieren, der einem Base64-ähnlichen Muster entspricht, unabhängig davon, ob der Wert tatsächlich Base64-codierte Daten sind.

  • Lösung:

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

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

  • Symptom: Beim Lesen aus oder Schreiben in eine Datenbank über den Database-Connector mit einem ODBC-Treiber werden Mehrbyte- oder Nicht-ASCII-Zeichen (z. B. Zeichen mit Akzenten oder Nicht-Lateinzeichen) nicht korrekt verarbeitet.
  • Mögliche Ursache: Die Unterstützung für Mehrbyte-Zeichen für den Database-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 ist nicht erforderlich, wenn ein JDBC-Treiber verwendet wird.
  • 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. Beispiel 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 Datenbankconnector-Verbindungstest schlägt fehl mit:

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

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

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

    oder einen spezifischen Verbindungsstringparameter:

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

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

  • Lösung: Konfigurieren Sie auf einem privaten Agenten 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 Agenten neu.

Datenbank: DBLookup oder DBExecute schlägt beim Testen eines Skripts mit „No suitable driver found" fehl

  • Symptom: Das Testen eines Skripts (mit Run test), das DBLookup oder DBExecute aufruft, schlägt fehl mit:

    No suitable driver found for [...]

    Das gleiche Skript wird erfolgreich ausgeführt, wenn es bereitgestellt und in einem Vorgang ausgeführt wird.

  • Mögliche Ursache: Die Datenbankverbindung, die von der Funktion verwendet wird, hat ihr Feld Login, Password oder Connection String auf eine globale oder Projektvariable gesetzt. Ein Skripttest führt nur das getestete Skript aus, daher hat die Variable ihren Laufzeitwert noch nicht zugewiesen, wenn die Funktion die Verbindung auflöst. Im Gegensatz zu einer Variablen, auf die in einem konfigurierten Feld einer Aktivität selbst verwiesen wird, wird dies nicht durch den Standardwert einer Variablen abgedeckt; eine Datenbankfunktion liest den Standardwert nicht beim Auflösen einer Verbindung.

  • Lösung: Weisen Sie vor dem Funktionsaufruf die gleiche globale oder Projektvariable temporär ihren tatsächlichen Wert direkt im getesteten Skript zu (z. B. $login = "value"; für eine Variable namens login), und entfernen Sie dann die Zuweisung vor der Bereitstellung des Vorgangs.

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 eines der folgenden Elemente:

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

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

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

  • Lösung:
    1. Aktivieren Sie in der Konfiguration der Datenbankaktivität Insert, Update oder Upsert die Option Kürzung von Zeichenfeldern zulassen, um Feldlängenfehler zu vermeiden. Mit dieser Option werden Werte, die die Zielfeld-Länge überschreiten, gekürzt und der Vorgang meldet einen Erfolg mit Info-Status statt eines Fehler-Status.
    2. Falls eine Kürzung nicht akzeptabel ist, kürzen oder transformieren Sie das Quellfeld in der Transformationszuordnung, damit Werte die Zielspaltenlänge nie überschreiten, oder vergrößern Sie die Zielspalte auf der Datenbankseite.
    3. Stellen Sie den Vorgang erneut bereit und führen Sie ihn erneut aus.

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

  • Symptom: Benutzerdefinierte JDBC-Treiber-JAR-Dateien, die für den Datenbankconnector 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 diese in das richtige Verzeichnis und starten Sie den Agent neu.

Datenbank: Sonderzeichen in Spaltennamen verursachen Abfragefehler

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

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

  • Symptom: Eine Datenbankaktivität Query schlägt fehl oder wird gekürzt, wenn die konfigurierte SQL-Anweisung sehr lang ist.
  • Mögliche Ursache: Das SQL-Anweisungsfeld in einer Datenbankaktivitä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 auf iSeries: JDBC-Verbindung schlägt fehl

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

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

  • Symptom: Eine Datenbankverbindung mit dem IBM DB2 JCC JDBC-Treiber schlägt mit einem Fehler fehl, der auf eine fehlende Lizenz verweist, oder schlägt fehl oder erzeugt 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 weder den JCC-Treiber noch eine Lizenzdatei erfordert.

Kerberos: „Could not initialize class KerbAuthentication"

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

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

  • Mögliche Ursache: Die Kerberos-Konfigurationsdateien auf dem Agent-Host haben nicht die 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 führt dies zu Konflikten mit der Kerberos-Konfiguration.
  • Lösung:
    1. Entfernen Sie den Parameter -Dsun.security.jgss.native=true aus den JVM-Argumenten des Agents.
    2. Fügen Sie in krb5.conf unter dem Abschnitt [libdefaults] den Eintrag udp_preference_limit = 1 hinzu, um TCP statt UDP für Kerberos-Datenverkehr zu erzwingen.
    3. Starten Sie den Agent neu.

Microsoft Excel: „Operation must use an updateable query"

  • Symptom: Eine Datenbankaktivität vom Typ 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; hinzu, um die Excel-Datei im Lese-/Schreibmodus zu öffnen.

MySQL: Zugriff verweigert trotz korrekter Anmeldedaten

  • Symptom: Die Verbindung zu einer MySQL-Datenbank mit dem Database-Connector schlägt 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 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 Grant-Syntax 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 Insert- oder Update-Performance nicht

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

MySQL: ODBC-Treiber nicht in Studio-Dropdown aufgelistet

  • Symptom: Beim Konfigurieren einer Database-Verbindung zu MySQL mit einem ODBC-Treiber auf einem privaten Agenten wird der installierte Treiber nicht im Dropdown Driver in Studio angezeigt.
  • Mögliche Ursache: Der ODBC-Manager auf dem privaten Agent-Host 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 privaten Agent-Host (Windows) Data Sources (ODBC) (unter Administrative Tools) und bestätigen Sie, dass der MySQL ODBC-Treiber aufgelistet ist. Informationen zu MySQL-Treiberoptionen finden Sie unter Connect to MySQL.
    • 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 Database-Connectors zu PostgreSQL schlägt mit einem Fehler „client encoding mismatch" fehl.
  • Mögliche Ursache: Das Encoding, das der PostgreSQL-Server verwendet, unterscheidet sich vom Standard-Encoding, das der PostgreSQL ODBC-Treiber annimmt.
  • Lösung:
    • Fügen Sie in den Database-Verbindungseinstellungen ConnSettings=SET CLIENT_ENCODING to 'LATIN1' (ersetzen Sie das tatsächliche Encoding des Servers) zum Feld Additional Connection String Parameters hinzu.
    • Wenn der Server unter Windows ein kyrillisches Encoding wie WIN1251 verwendet, stellen Sie das Client-Encoding auch in den ODBC-Treibereinstellungen auf WIN1251 ein.

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 Windows Integrated Security.
  • 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 neu, nachdem Sie Berechtigungsänderungen angewendet haben.

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

  • Symptom: Eine Database-Connector-Operation, die 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 den 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, setzen Sie IDENTITY_INSERT auf der Zieltabelle in Pre- und Post-SQL-Skripten innerhalb der Aktivität:

    SET IDENTITY_INSERT <table> ON;

    SET IDENTITY_INSERT <table> OFF;

    Verwenden Sie diese Option nur, wenn Sie 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 aktualisierte den gebündelten Treiber auf eine Version, 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 dokumentiert, zusammen mit Jitterbit EDI-Problemen. 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-Passwort für Konten mit aktivierter 2-Faktor-Authentifizierung. Das Google-Kontokennwort wird von SMTP oder IMAP nicht akzeptiert, wenn die 2-Faktor-Authentifizierung aktiv ist; nur App-Passwörter funktionieren.
  • Lösung:
    1. Generieren Sie in Ihrem Google-Konto ein App-Passwort für die Jitterbit-Anwendung (siehe Googles Seite Mit App-Passwörtern anmelden).
    2. Geben Sie in der E-Mail-Verbindungskonfiguration in Studio das App-Passwort im Feld SMTP-Passwort und/oder IMAP-Passwort 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 Benutzername, Passwort, Client-ID, Mandanten-ID und Client-Geheimnis alle korrekt sind.
  • Mögliche Ursache: Die ROPC-Authentifizierung erfordert, dass die Multi-Faktor-Authentifizierung (MFA) für die Microsoft 365-Anmeldedaten, die mit dem Connector verwendet werden, deaktiviert ist. Der ROPC-Grant kann 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 mit Variablen oder Skripten zusammengestellt werden, fügen Sie eine Deduplizierungsprüfung hinzu, bevor Sie Adressen an die Aktivität übergeben.

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 der 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 den 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 Orte 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 Ort zu verschieben oder umzubenennen.

FTP, File Share, Local Storage und Temporary Storage: „Write Headers" 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 überhaupt keine Datei (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 (beispielsweise beim Lesen von Hunderten kleiner Dateien in einer Schleife oder bei vielen Operationen, die nach einem Zeitplan gegen den gleichen Server laufen), schlägt schließlich mit einer Anmeldungsverweigerung oder einem Verbindungsfehler fehl. Die gleiche Operation läuft unter geringerer Last erfolgreich.
  • 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, Operationsausführungen oder Projekte hinweg wiederverwendet. Dies ist beabsichtigt. Wenn viele Operationen gegen den gleichen Server laufen, beispielsweise mehrere geplante Operationen oder mehrere Projekte, die auf den gleichen Host abzielen, authentifiziert sich jede Ausführung 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 erforderlich sind. Ersetzen Sie eine Read-Aktivität in einer Schleife durch eine einzelne Read-Aktivität, die einen Platzhalter im Feld Get Files verwendet (beispielsweise *.xml oder data_*.csv), und teilen Sie die abgerufenen Daten dann in 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 „Login denied. Authentication failure." 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 erfolgreich von einem interaktiven SFTP-Client aus authentifizieren.

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

  • Mögliche Ursachen:

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

  • Lösung:

    • Bestätigen Sie für private Agents, 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-Endpoint-Konfiguration das Feld Password, wenn die Authentifizierung über SSH-Schlüssel erfolgt.
    • Bestätigen Sie, dass der Schlüssel in einem vom Agent unterstützten Format vorliegt (OpenSSH). Konvertieren Sie den Schlüssel mit ssh-keygen, falls er im PuTTY-Format (.ppk) oder einem anderen nicht-OpenSSH-Format vorliegt.

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

  • Symptom: Eine FTP-Write-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 Agents 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 Operationen mit archive pattern.

  • 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 (außer auf Windows-Private-Agents ab Agent-Version 12.10; siehe Zeichenkodierung und Multibyte-Unterstützung); bei aktiviertem Use FTP Rename lädt der Agent die Datei jedoch unter einem temporären Namen (Suffix -jbupload) hoch und benennt sie dann in den endgültigen Namen um. Wenn der Server den Multibyte-Namen nicht umbenennen kann, gibt er eine irreführende Fehlermeldung Permission denied zurück. 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, bei der Use FTP Rename mit SFTP wie erwartet funktioniert. Cloud-Agents werden automatisch aktualisiert; aktualisieren Sie Private-Agents 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 abgekürzten 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-Agents 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-Agents 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 Private-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 kein lokales Dateisystem für diesen Zweck bereit.
  • Lösung:
    • Verwenden Sie Private Agents für alle Vorgänge, die den Local Storage-Connector erfordern. Local Storage ist auf Private Agents standardmäßig deaktiviert, daher aktivieren Sie es auch in der Konfigurationsdatei des Private Agent (siehe Enable local file location).
    • Ersetzen Sie Local Storage für Cloud Agent-Workflows 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 Important notes.
  • Lösung:
    • Verknüpfen Sie Vorgänge, die Temporary Storage-Dateien gemeinsam nutzen müssen, in die gleiche operation chain mit operation actions, wobei das Temporary Storage-Verhalten konsistent und zuverlässig ist.
    • Für Private Agents 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).

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.
    • Wenn nur Cloud-Agenten verfügbar sind, teilen Sie große Datensätze 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 Authentifizierungsverwaltung. Fügen Sie keinen manuellen Authorization-Header neben der konfigurierten Authentifizierung hinzu.
    • Wenn 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]

    Dieselbe JSON funktioniert, wenn sie 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"}.
    • Wenn der JSON-Inhalt statisch ist, fügen Sie ihn direkt in die Spalte Value der Tabelle Request Headers ein, anstatt eine Variable zu verwenden. Der Connector wendet das erforderliche 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 Erstellen der endgültigen URL ein.

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

  • Symptom: REST-API-Aufrufe über den HTTP v2-Connector schlagen beim Zielsystem fehl, da URL-Parameter in der ausgehenden Anfrage doppelt codiert sind (z. B. wird ein %20-Leerzeichen zu %2520).
  • Mögliche Ursache: Wenn Encode request URL in den HTTP v2-Verbindungseinstellungen aktiviert ist, codiert der Connector die gesamte URL vor dem 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 erstellt 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 in diesem Teilpfad (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 Zielvariaablen 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 Zielvariaablen 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 als %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-Literal null 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 bereitgestellt wird, sendet der Connector ein zugeordnetes Null korrekt als JSON null.
  • Lösung:
    • Migrieren Sie die Aktivität zum HTTP v2-Connector, der Null korrekt serialisiert. Jitterbit empfiehlt, bestehende HTTP-Verbindungen und -Aktivitäten zu HTTP v2 zu konvertieren.
    • Wenn die Aktivität 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 Kinder sein, damit das Löschen erfolgreich ist.
  • Lösung:
    • Löschen Sie vor dem Löschen des übergeordneten Eintrags zunächst alle untergeordneten Einträge. Durchlaufen Sie die Hierarchie von den tiefsten Einträgen aufwärts.
    • Wenn das Löschen 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 Groß-/Kleinschreibung-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 Schreibweise (z. B. objectClass).
  • Lösung:
    1. Überprüfen Sie in der Konfiguration der LDAP-Aktivität Search Entry das vorausgefüllte Feld Filter Expression.
    2. Passen Sie die Groß-/Kleinschreibung von Attributnamen an das an, was der LDAP-Zielserver erwartet. Ändern Sie z. B. ObjectClass zu 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 bei diesen Endpunkten 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 wä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 Auswahliste ausgeschlossen.
  • Lösung: Die Felder onPremisesExtensionAttributes müssen nicht in Schritt 3 ausgewählt werden, um zurückgegeben zu werden. Sie werden im Ausgabeschema der Aktivität in Schritt 4 angezeigt und 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 mit den Metadaten nicht 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 Query: „Unsupported or invalid query filter clause" 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:
    • Tab „Basic": Aktivieren Sie das Kontrollkästchen Include Count. Dies fügt $count=true automatisch zur Abfrage hinzu.

    • Tab „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 „Logon failed" fehl

  • Symptom: Vorgänge mit dem Microsoft Dynamics AX-Connector für AX 2012 schlagen zur Laufzeit fehl, obwohl der Verbindungstest in Studio erfolgreich ist. Das 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 speziellen 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 Daten nur 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 Datenbereichskennung 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-Connectoren

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-Connector erfordert, dass der Oracle JDBC-Treiber (ojdbc8.jar) manuell auf dem Private 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 Private Agent-Host.
    3. Starten Sie alle Agents in der Agent-Gruppe neu.
    4. Testen Sie die Oracle EBS-Verbindung erneut.

Salesforce-Connectoren

Hinweis

Der Salesforce-Connector verfügt über einen speziellen Leitfaden zur Fehlerbehebung, der Authentifizierung, Schema, Aktivitätskonfiguration, Datensatzlimit und Bulk-Aktivitätsprobleme abdeckt. Siehe Salesforce-Connector-Fehlerbehebung.

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

  • Symptom: Nach dem Neustart oder der Neuinstallation eines Private Agent schlagen Salesforce Events-Connector-Events fehl, auch wenn die Verbindungsanmeldedaten korrekt sind.
  • Mögliche Ursache: Nach einem Neustart ist die Connector JAR-Datei möglicherweise noch nicht auf dem Agent vorhanden. Das Aktivieren eines Events erfordert, dass der Connector zunächst auf den Agent heruntergeladen wird.
  • 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 Connector 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 Connector-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 Studio-bekanntes Problem.
  • 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 fehl mit:

    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 vorausgehende Anfragetransformation 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 Anfragetransformation, die der SAP-Aktivität RFC vorausgeht, 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 Berechtigungsobjektzuweisungen 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 falsch geschrieben (z. B. en statt EN). SAP lehnt den ungültigen Schlüssel ab, wenn die Textumgebung des Ziels initialisiert wird.

  • Lösung:
    1. Bearbeiten Sie den SAP-Endpunkt in Studio und setzen Sie das Feld 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 Operationen laufen 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 Ausführungen 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 Durchlauf 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.

Shopify-Connector

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

  • Symptom: Nach dem Ändern der API-Version für eine Shopify-Verbindung geben eine oder mehrere Shopify-Aktivitäten Fehler zurück oder verhalten sich unerwartet, und ein konfiguriertes Objekt oder Unterobjekt scheint sich geändert zu haben.
  • Mögliche Ursache: Shopify 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 sicherzustellen, 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: Kennwortbasierte Verbindungen schlagen nach Authentifizierungsabschaffung fehl

  • Symptom: Operationen, die sich mit Snowflake über den Authentifizierungstyp Kennwort (Veraltet) verbinden, schlagen fehl, nachdem sie zuvor funktioniert haben.
  • Mögliche Ursache: Snowflake stellt die Authentifizierung mit einem Faktor (nur Kennwort) ein. Kennwortbasierte Verbindungen schlagen fehl, es sei denn, die TYPE-Eigenschaft des Snowflake-Benutzerkontos ist auf LEGACY_SERVICE gesetzt.

  • Lösung: Wählen Sie eine der folgenden Optionen:

    • Temporäre Problemumgehung: Setzen Sie in Snowflake die TYPE-Eigenschaft des Benutzerkontos auf LEGACY_SERVICE, um die kennwortbasierte Konnektivität wiederherzustellen:

      ALTER USER <username> SET TYPE = LEGACY_SERVICE;

      Diese Problemumgehung ist keine langfristige Lösung, da Snowflake die Unterstützung für LEGACY_SERVICE in einer zukünftigen Version möglicherweise einstellt.

    • Empfohlene Migration: Aktualisieren Sie die Snowflake-Connector-Verbindung in Studio, um OAuth oder Key-Pair-Authentifizierung zu verwenden, und konfigurieren Sie das Snowflake-Benutzerkonto entsprechend.

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 einen Ruhezustand, wenn sie längere Zeit nicht aufgerufen wurden. Während der Verbindungstest gegen eine ruhende Instanz erfolgreich sein kann, gibt die Instanz möglicherweise keine Tabellen- und Objektmetadaten zurück.
  • Lösung:
    1. Melden Sie sich in der Snowflake-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: Schreibweise des Flat-Schema-Stammknotens stimmt nicht überein und 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 Kleinbuchstaben in der XML-Antwort zurück. Wenn Studio ein Flat-Schema aus der Abfrage generiert, wird der Stammknotenname in Großbuchstaben erstellt. Die Schreibweiteabweichung zwischen dem Schema-Stammknoten (Großbuchstaben) und dem XML-Antwort-Stammknoten (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 Schreibweiteabweichung 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, zeigt beide Felder.
  • Mögliche Ursache: Externe Stages sind schreibgeschützte Verweise auf Dateien, die bereits im externen Cloud-Speicher (S3, GCS oder Azure Blob) vorhanden sind. Die Merge-Aktivität kann keinen Dateiinhalt in eine externe Stage hochladen, daher 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 Dateiinhalt aus dem Vorgang übertragen müssen, konfigurieren Sie die Merge-Aktivität für die Verwendung einer internen Stage. Das Schema zeigt dann stageName und fileContent.

Snowflake Insert oder Merge: SQL-Syntaxfehler durch Sonderzeichen

  • Symptom: Eine Snowflake-Insert- oder Merge-Aktivität 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 erscheinen, wobei Daten aus einem Feld in der falschen Spalte angezeigt werden.

  • Mögliche Ursachen:

    • Feldwerte, die einfache Anführungszeichen enthalten (z. B. ein Wert wie corner's), werden nicht maskiert, bevor sie in die SQL-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, die einfache Anführungszeichen enthalten: Aktivieren Sie in den Optionalen Einstellungen der Snowflake-Verbindung die Option Sonderzeichen maskieren. Dies maskiert automatisch einfache Anführungszeichen in den Nutzlasten der Aktivitäten Insert und Invoke Stored Procedure. Verwenden Sie für Merge-Aktivitäten oder als Alternative für Insert die Funktion 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-Speicherfehler 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 nur wenige Zeilen zurückgeben, oder wenn derselbe Agent auch über andere Connectoren mit Heap-Fehlern fehlschlägt, ist die Ursache wahrscheinlicher die Gesamtheap-Zuordnung des Agenten als die Größe des Ergebnissatzes. Siehe Java-Heap-Speicher: 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: Verwenden Sie für große Abfragevolumina den Database-Connector mit einem Snowflake-JDBC-Treiber statt des Snowflake-Connectors. Der Database-Connector puffert den vollständigen Ergebnissatz 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 ihn verwendet. Bei Agent 12.x und später benötigt diese Database-Verbindung auch enableArrowResultFormat=false&jdbc_query_result_format=json in ihrer Verbindungszeichenkette; siehe Snowflake: Operationen schlagen auf Agent 12.x fehl.

    Wenn Sie beim Snowflake-Connector bleiben müssen, können beide folgenden Maßnahmen den Speicherdruck verringern, obwohl keine garantiert ausreichend für Datenmengen im Millionenbereich ist:

    • Teilen Sie die Abfrage in Batches mit SQL-Klauseln LIMIT und OFFSET auf und führen Sie die Operation wiederholt mit inkrementellen 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 auf Agent 12.x fehl

  • Symptom: Auf 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 verweist auf die Arrow-Speicherschicht des Treibers, z. B.:
JDBC driver internal error: exception creating result java.lang.ExceptionInInitializerError at net.snowflake.client.jdbc.internal.apache.arrow.memory.unsafe.UnsafeAllocationManager

oder:

JDBC driver internal error: exception creating result java.lang.NoClassDefFoundError: Could not initialize class net.snowflake.client.jdbc.internal.apache.arrow.memory.RootAllocator
  • Mögliche Ursache: Der Snowflake JDBC-Treiber gibt Abfrageergebnisse standardmäßig im Apache Arrow-Format zurück, das nicht mit Agent-Version 12.x und später kompatibel ist. Weitere Informationen finden Sie in Snowflakes Artikel zur Fehlerbehebung bei diesem Java-Modulfehler. Der Verbindungstest gibt kein Resultset zurück, daher wird er trotzdem 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 im Arrow-Format 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, wenn 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 den Vorgang 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 Wertdaten --add-opens=java.base/java.nio=ALL-UNNAMED zu den vorhandenen Java-Optionen 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: „No WSDL with locator"

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

    Failed to deploy - Internal Error: No WSDL with locator

  • Mögliche Ursachen:

    • Die WSDL wurde entfernt, erneut importiert oder ihre interne Referenz wurde unterbrochen, sodass das Projekt auf eine WSDL-ID verweist, die nicht mehr vorhanden ist.

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

  • Lösung:

    1. WSDL für die betroffene Komponente erneut hochladen:

      • Für eine SOAP-Verbindung die Verbindung öffnen und URL hochladen oder Datei hochladen wählen (nicht Vorhandene auswählen), die WSDL erneut hochladen, die Einstellungen Port und Methoden auswählen überprüfen und dann Änderungen speichern klicken.
      • Für eine API-Aktivität SOAP Request oder SOAP Response die Aktivität öffnen und die WSDL in Schritt 1 der Konfiguration erneut hochladen.

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

    3. Das Projekt erneut bereitstellen.

    4. Falls das Projekt mehrere WSDLs hat und nicht klar ist, welche betroffen ist, siehe SOAP-Verbindung – Fehlerbehebung, um diese 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 von absoluten Remote-URLs nicht abrufen, wenn eine lokal importierte WSDL geladen wird.
  • Lösung:
    1. Die WSDL bearbeiten, sodass alle schemaLocation-Verweise relative Pfade verwenden (z. B. schema.xsd statt http://example.com/schema.xsd).
    2. Alle referenzierten XSD-Dateien im selben Verzeichnis wie die WSDL platzieren und die WSDL in der SOAP-Verbindung erneut importieren.

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

  • Symptom: Die von einer SOAP-Aktivität erzeugte XML-Envelope stimmt nicht mit den literalen Namespace-Präfixen oder der Struktur der Quell-WSDL überein (z. B. ersetzt der Connector xmlns:ns1 durch xmlns:glob). Strikte SOAP-Services, die den genauen Präfixtext vergleichen, lehnen die Anfrage ab.
  • Mögliche Ursache: Die Transformations-Engine verarbeitet SOAP-Nachrichten als strukturiertes XML, nicht als literalen Text. Sie erzeugt eine semantisch äquivalente 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, den SOAP-Connector umgehen und die Request-Payload als String erstellen:
    1. Eine HTTP v2-Verbindung erstellen, die auf die SOAP-Service-URL verweist.
    2. In einer Transformation die SOAP-Envelope als String erstellen, String-Literale und zugeordnete Werte mit dem +-Operator verketten. Alternativ eine Vorlage aus einer Datei lesen und dynamische Werte mit Replace ersetzen.
    3. In der HTTP v2-Aktivität POST das Standard-Request-Schema verwenden (kein benutzerdefiniertes Request-Schema hochladen) und die konstruierte SOAP-Envelope-String dem body-Feld dieses Schemas zuordnen. Der Connector sendet den body-Wert unverändert und bewahrt das literale XML.
    4. Den Content-Type-Header auf text/xml oder application/soap+xml setzen und den SOAPAction-Header setzen, falls der Service dies erfordert.
    5. Die Antwort des Service aus dem responseContent-Feld des Standard-Response-Schemas der Aktivität lesen.

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: Dem VTEX-Benutzer oder dem Anwendungsschlüssel, der der Verbindung zugeordnet ist, fehlen eine oder mehrere Berechtigungen, die der Connector zur Validierung der Verbindung verwendet. Diese Berechtigungen sind strenger als die für den grundlegenden Datenzugriff erforderlichen.

  • Lösung:
    1. Öffnen Sie im VTEX-Admin-Portal das Zugriffsprofil, das dem Benutzer oder Anwendungsschlüssel zugewiesen ist, den Jitterbit verwendet.
    2. Bestätigen Sie, dass das Zugriffsprofil die Funktion License Manager mit Zugriff auf die Ressource Get account by identifier enthält.
    3. Speichern Sie das Profil und testen Sie die VTEX-Verbindung in Studio erneut.

Workday-Connector

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

  • Symptom: Operationen, die den Workday-Connector mit WSDL-Version 42.0 oder 42.1 verwenden, schlagen beim Zugriff auf die Web-Services Human_Resources oder Resource_Management fehl.
  • Mögliche Ursache: WSDL v42.0 gibt bekanntermaßen Fehler für die Services Human_Resources (v42.0) und Resource_Management (v42.0) zurück. WSDL v42.1 gibt bekanntermaßen Fehler für den Service Human_Resources (v42.1) zurück. Dies sind bekannte Probleme, die 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 höher für Operationen, die die Services Human_Resources oder Resource_Management verwenden.
    2. Testen Sie die Verbindung und führen Sie die betroffenen Operationen erneut aus, um zu bestätigen, dass das Problem behoben ist.

Workday: Verbindungstest schlägt mit „Die eingereichte Aufgabe ist nicht autorisiert" fehl

  • 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/). Sie können den korrekten Wert auf der Workday-Seite View API Client bestätigen.
    2. Öffnen Sie in der Workday-Instanz die Aufgabe Assign Users to User-based Security Group, 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.