Zum Inhalt springen

Fehlerbehebung für APIs und API Manager

Dieses Handbuch behandelt häufige Fehler und Probleme, die beim Konfigurieren, Veröffentlichen und Verwenden von APIs in Jitterbit API Manager auftreten. Beginnen Sie mit den Diagnoseschritten unten, um Informationen zu sammeln, und suchen Sie dann Ihr spezifisches Problem im relevanten Abschnitt.

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

Alle Fehlerbehebungseinträge auf dieser Seite

Diagnoseschritte

Diese Schritte gelten für die meisten API Manager-Probleme und sind der empfohlene Ausgangspunkt.

API-Protokolle prüfen

Überprüfen Sie die API-Protokolle auf Anfrage- und Antwortwfehler im Zusammenhang mit der betroffenen API. Standardmäßig zeigen die Protokolle Metadaten wie Statuscodes, Fehlermeldungen und Zeitstempel an, die dabei helfen können, die Ursache einzugrenzen.

Um auch die vollständigen Anfrage- und Antwort-Payloads zu erfassen, nutzen Sie den Debug-Modus – die beste Option für aktive Fehlerbehebung: Er erfasst Anfrage- und Antwortdaten zusammen mit detailliertem Aktivitäts-Logging und deaktiviert sich automatisch am festgelegten Datum.

  1. Aktivieren Sie auf der Registerkarte Einstellungen der API-Konfiguration Debug-Modus aktivieren bis und legen Sie ein Datum fest, um ihn aktiv zu halten. Siehe die Konfigurationsreferenz für benutzerdefinierte APIs, OData-Services oder Proxy-APIs.
  2. Wiederholen Sie die Anfrage und überprüfen Sie dann die Payloads in den API-Protokollen.

Hinweis

Um Payloads fortlaufend statt für ein festes Fehlerbehebungsfenster zu protokollieren, nutzen Sie Ausführliches Logging oder Anfrage- und Antwort-Payloads in Protokollen anzeigen für benutzerdefinierte und OData-Services.

Jitterbit-Systemstatus prüfen

Falls ein Problem alle APIs oder die API Manager-Oberfläche selbst statt nur einer einzelnen API zu betreffen scheint, überprüfen Sie die Jitterbit-Systemstatusseite und die Seite Bekannte Probleme, bevor Sie weitere Untersuchungen durchführen.

Authentifizierungs- und Sicherheitsfehler

Microsoft Entra ID OAuth: Sicherheitsprofilname darf keine Leerzeichen enthalten

  • Symptom: API-Aufrufe mit einem Microsoft Entra ID (Azure AD) OAuth 2.0-Sicherheitsprofil mit drei Beinen schlagen mit einem Fehler von Microsoft fehl, der auf einen Umleitungs-URL-Konflikt hinweist:

    The reply URL specified in the request does not match the reply URLs configured for the application.

  • Mögliche Ursache: Der Sicherheitsprofilname enthält Leerzeichen. Leerzeichen im Profilnamen führen dazu, dass der OAuth-Umleitungs-URI falsch konstruiert wird und mit keiner der in der Azure-App-Registrierung registrierten Antwort-URLs übereinstimmt.

  • Lösung:
    1. Öffnen Sie das Sicherheitsprofil im API Manager und benennen Sie es um, um Leerzeichen zu entfernen (ändern Sie beispielsweise My Profile in MyProfile oder my-profile).
    2. Überprüfen Sie in der Azure-App-Registrierung, dass die dort registrierten Antwort-URLs mit dem Umleitungs-URI übereinstimmen, den API Manager für das umbenannte Profil generiert.

Microsoft Entra ID 2-legged OAuth: OAUTH_INVALID_TOKEN_CODE-Fehler

  • Symptom: API-Aufrufe, die durch ein Microsoft Entra ID OAuth 2.0-Sicherheitsprofil mit zwei Beinen geschützt sind, schlagen fehl mit:

    Failed to validate authentication token - HttpErrorResponse: OAUTH_INVALID_TOKEN_CODE

  • Mögliche Ursache: Der aud-Anspruch im JWT, das von Entra ID ausgestellt wird, stimmt nicht mit der im API Manager-Sicherheitsprofil konfigurierten Audience überein. Dies deutet normalerweise darauf hin, dass die Application ID URI in der Azure-App-Registrierung falsch konfiguriert ist oder der OAuth-Bereich, den der Client anfordert, nicht mit der registrierten URI übereinstimmt.

  • Lösung:
    1. Öffnen Sie im Azure-Portal die App-Registrierung, die diesem Sicherheitsprofil zugewiesen ist, und gehen Sie zu API verfügbar machen.
    2. Bestätigen Sie, dass die Application ID URI auf eine gültige URI im Format api://<Application (client) ID> eingestellt ist.
    3. Bestätigen Sie im Sicherheitsprofil, dass der OAuth-Bereich auf api://<Application (client) ID>/.default eingestellt ist.
    4. Aktualisieren Sie die Clientanwendung, um ein Token mit diesem genauen Bereich anzufordern.
    5. Wenn die Validierung weiterhin fehlschlägt, nachdem die Audience und der Bereich korrekt sind, öffnen Sie das Manifest der App-Registrierung und bestätigen Sie, dass requestedAccessTokenVersion auf 2 eingestellt ist. Ein fehlender oder anderer Wert kann auch dazu führen, dass die Token-Validierung fehlschlägt.

Azure AD Graph API wurde eingestellt

  • Symptom: API-Aufrufe, die zuvor mit einem Microsoft Entra ID (Azure AD)-Sicherheitsprofil funktionierten, schlagen mit Authentifizierungsfehlern fehl.
  • Mögliche Ursache: Die App-Registrierung des Sicherheitsprofils ist weiterhin für die Verwendung der Azure AD Graph API konfiguriert, die Microsoft am 30. Juni 2025 eingestellt hat. App-Registrierungen, die nicht zu Microsoft Graph migriert wurden, schlagen bei Anfragen fehl.
  • Lösung:
    1. Migrieren Sie im Azure-Portal die App-Registrierung zu Microsoft Graph.
    2. Aktualisieren Sie nach der Migration das App-Manifest, indem Sie die Schritte für API-Berechtigungen in der Microsoft Entra ID 2-legged OAuth-Sicherheitsprofilkonfiguration befolgen.

Google oder Salesforce-Identitätsanbieter: 2-legged OAuth wird nicht unterstützt

  • Symptom: Ein API-Sicherheitsprofil, das mit Google oder Salesforce als OAuth 2.0-Identitätsanbieter konfiguriert ist, schlägt fehl, wenn es für 2-legged OAuth konfiguriert ist.
  • Mögliche Ursache: Google und Salesforce OAuth 2.0-API-Sicherheitsprofile unterstützen 2-legged OAuth nicht.
  • Lösung: Verwenden Sie ein 3-legged OAuth 2.0-Sicherheitsprofil für APIs, die sich mit Google oder Salesforce als Identitätsanbieter authentifizieren.

Microsoft Copilot Studio: Standardauthentifizierung wird nicht unterstützt

  • Symptom: Das Verbinden einer benutzerdefinierten Jitterbit-API mit Microsoft Copilot Studio (als REST-API-Tool) schlägt fehl, wenn das Sicherheitsprofil der API Standardauthentifizierung verwendet.
  • Mögliche Ursache: Microsoft Copilot Studio unterstützt keine Standardauthentifizierung. Eine benutzerdefinierte Jitterbit-API, deren Sicherheitsprofil Standardauthentifizierung verwendet, kann nicht von Copilot Studio aufgerufen werden.
  • Lösung:
    1. Öffnen Sie im API Manager das Sicherheitsprofil, das der API zugewiesen ist.
    2. Ändern Sie den Authentifizierungstyp zu API-Schlüssel oder OAuth 2.0, oder entfernen Sie das Sicherheitsprofil von der API, wenn der Endpunkt keine Authentifizierung erfordert.
    3. Veröffentlichen Sie die API erneut und verbinden Sie sie dann in Microsoft Copilot Studio erneut. Siehe Verbinden Sie einen Jitterbit AI-Agent mit Microsoft Copilot Studio.

Schaltfläche „New API" ist trotz korrekter Organisationsrolle nicht sichtbar

  • Symptom: Die Schaltfläche New API wird im API Manager für einen Benutzer mit einer Organisationsrolle, der aber kein Organisationsadministrator ist, nicht angezeigt. Wenn man dem Benutzer die Berechtigung Admin auf Organisationsebene erteilt, wird die Schaltfläche angezeigt, aber es werden auch alle Umgebungen für den Benutzer freigegeben.
  • Mögliche Ursache: Eine Organisationsrolle allein reicht nicht aus, um APIs zu erstellen. Die Rolle muss auch Write-Zugriff auf Umgebungsebene für die spezifische Umgebung haben, in der der Benutzer APIs erstellen muss.
  • Lösung:
    1. Gehen Sie in der Management Console zu Environments und öffnen Sie die Umgebung, in der der Benutzer APIs erstellen muss.
    2. Bestätigen Sie für die Rolle des Benutzers in dieser Umgebung, dass Write-Zugriff aktiviert ist. Falls nicht, aktivieren Sie ihn und speichern Sie.
    3. Die Schaltfläche New API sollte jetzt für diese Umgebung sichtbar sein.
  • Symptom: Eine API mit zwei oder mehr zugewiesenen Basic-Auth-Sicherheitsprofilen zeigt unerwartete Benutzernamen in den API-Protokollen, einschließlich Benutzernamen, die zu keinem der Profile gehören. Einige Anfragen schlagen mit einem 401-Fehler (Unauthorized) fehl.
  • Mögliche Ursache: Der Browser oder API-Client (z. B. Postman) hat Basic-Auth-Anmeldedaten aus einer vorherigen Sitzung als Cookie zwischengespeichert. Wenn die API erneut aufgerufen wird, sendet der Client zuerst den zwischengespeicherten Cookie. Wenn die zwischengespeicherten Anmeldedaten nicht mit einem der konfigurierten Sicherheitsprofile übereinstimmen, wird die Anfrage abgelehnt und der unerwartete Benutzername wird in den Protokollen angezeigt, bevor die Authentifizierung mit den korrekten Anmeldedaten erfolgreich ist.

  • Lösung:

    1. Löschen Sie die Cookies und den Cache des Browsers, oder wechseln Sie zu einem Inkognito- oder privaten Browserfenster, bevor Sie die API erneut testen.
    2. Bestätigen Sie, dass das Verhalten nicht vorhanden ist, wenn eine neue Anfrage ohne vorherige Sitzungs-Cookies gestellt wird. Wenn der Fehler verschwindet, ist das Problem clientseitiges Caching von Anmeldedaten und kein Konfigurationsproblem.

    Beachten Sie, dass jeder HTTP-Client, der Cookies speichert (einschließlich browserbasierten Tools und API-Test-Dienstprogrammen), das gleiche Verhalten aufweisen kann.

401 Unauthorized mit einer gültigen IP-Allowlist (veralteter Cache)

  • Symptom: API-Aufrufe geben 401 Unauthorized zurück, obwohl die Client-IP korrekt in den vertrauenswürdigen IP-Gruppen des Sicherheitsprofils aufgelistet ist.
  • Mögliche Ursache: Ein veralteter Cache von Legacy-IP-Bereichseinträgen im Sicherheitsprofil überschreibt die aktiven vertrauenswürdigen IP-Gruppen.
  • Lösung: Migrieren Sie das Sicherheitsprofil von Legacy-IP-Bereichen zum Modell Trusted IP Groups, dem aktuellen Allowlist-Mechanismus: Definieren Sie die IPs als vertrauenswürdige IP-Gruppe und weisen Sie sie dem Profil zu. Das Deaktivieren der Einstellung Trust requests only from the following IP ranges in einem Profil, das noch Legacy-IP-Bereiche verwendet, entfernt diese Bereiche dauerhaft (eine Bestätigungsaufforderung warnt davor), daher migrieren Sie die IPs zu einer vertrauenswürdigen IP-Gruppe, anstatt die Einstellung zu deaktivieren, um den Cache zu löschen.

API-Veröffentlichung und -Bereitstellung

API kann nicht veröffentlicht werden: Abonnement-API-Limit erreicht

  • Symptom: Das Erstellen oder Veröffentlichen einer API schlägt mit einem Fehler wie dem folgenden fehl:

    You have reached Maximum no of API Service configured for your Jitterbit organization

  • Ursache: Die Organisation hat die maximale Anzahl von veröffentlichten API-URLs erreicht, die von ihrem Abonnement zulässig sind. Jede veröffentlichte benutzerdefinierte API, jeder OData-Service oder jede Proxy-API (und jeder ihrer veröffentlichten Klone) verwendet eine API-URL; Entwurf-APIs zählen nicht.

  • Lösung: Überprüfen Sie auf der Seite APIs des API Manager die Zählerstände Custom API URLs used und Proxy API URLs used, die oben auf der Seite angezeigt werden, anhand der von Ihrem Abonnement zulässigen Gesamtzahl. Heben Sie die Veröffentlichung von APIs auf oder löschen Sie APIs, die nicht mehr benötigt werden, um API-URLs freizugeben (Entwurf-APIs zählen nicht gegen das Limit). Um das Limit zu erhöhen, wenden Sie sich an Ihren Customer Success Manager.

Veröffentlichte API gibt 404 Not Found zurück

  • Symptom: Der Aufruf einer veröffentlichten API gibt einen 404-Fehler zurück.
  • Mögliche Ursachen:
    • Das Limit Hits pro Minute im zugewiesenen Sicherheitsprofil ist auf null gesetzt und blockiert alle Anfragen. Eine Änderung des Abonnementniveaus der Organisation kann dieses Limit zurücksetzen, sodass eine API, die zuvor funktioniert hat, 404-Fehler zurückgeben kann.
    • Die Konfiguration, die Basis-URL oder die Sichtbarkeitseinstellungen der API sind falsch.
    • Ein privates API-Gateway erkennt die API nach der Bereitstellung nicht.
    • Die API wurde nicht vollständig veröffentlicht oder ihre Metadaten sind unvollständig.
  • Lösung:
    • Öffnen Sie das Sicherheitsprofil, das der API zugewiesen ist, und bestätigen Sie, dass der Wert Hits pro Minute auf eine Zahl ungleich null gesetzt ist. Wenn das Limit kürzlich zurückgesetzt wurde (beispielsweise nach einer Abonnementänderung), stellen Sie es auf den beabsichtigten Wert zurück.
    • Überprüfen Sie auf der APIs-Seite, ob die API erfolgreich veröffentlicht wurde und ob ihre URL und Sichtbarkeitseinstellungen korrekt sind.
    • Wenn die API über ein privates API-Gateway bereitgestellt wird, überprüfen Sie die Gateway-Installation und Konnektivität auf Fehler oder Fehlkonfigurationen.

Service-URL überschreitet maximale Länge (HTTP 414)

  • Symptom: Das API-Gateway gibt folgende Meldung zurück:

    414 URI Too Large

  • Mögliche Ursache: Die konstruierte Service-URL (einschließlich Basis-URL, Service-Pfad und aller Pfad- oder Abfrageparameter) überschreitet 8.000 Zeichen.

  • Lösung:
    • Reduzieren Sie die Länge der Service-URL, indem Sie den Service-Pfad verkürzen oder die API in mehrere Endpunkte aufteilen.
    • Bestätigen Sie bei Proxy-APIs, dass die Kombination aus Basis-URL und allen definierten Service-Pfaden das 8.000-Zeichen-Limit nicht überschreitet.

Proxy-API: Service-Pfad-Parameter erfordern ein OpenAPI-Dokument

  • Symptom: Das Konfigurieren eines Proxy-API-Service-Pfads mit Pfadparametern (beispielsweise /resource/{id}) schlägt fehl, wenn dieser manuell eingegeben wird, da das Feld keine geschweiften Klammern akzeptiert.
  • Mögliche Ursache: Manuell definierte Service-Pfade in Proxy-APIs unterstützen die Zeichen { und } nicht, die zur Definition von Pfadparametern verwendet werden.
  • Lösung: Um Pfadparameter in einem Proxy-API-Service-Pfad zu verwenden, stellen Sie ein OpenAPI-Dokument bereit, das die Pfade und ihre Parameter definiert. API Manager erkennt die Pfade und ihre Parameter automatisch aus der OpenAPI-Spezifikation, anstatt sie manuell eingeben zu müssen.

API in API Manager kann nicht gelöscht werden

  • Symptom: Das Löschen einer API in API Manager schlägt fehl: Die Benutzeroberfläche zeigt einen generischen Fehler an und die API wird nicht entfernt. Der Fehler tritt im Browser auf, bevor eine Löschanfrage den Server erreicht, und wird als JavaScript TypeError in der Browser-Entwicklerkonsole angezeigt.
  • Mögliche Ursache: Die Rolle des Benutzers hat nicht die Berechtigung Admin. Das Löschen einer API prüft zunächst, welchen API-Gruppen die API zugeordnet ist, und der Zugriff auf die Seite API-Gruppen erfordert die Berechtigung Admin: Eine Rolle mit nur Write-Zugriff auf die Umgebung kann die Seite öffnen, aber nicht deren Inhalte lesen. Wenn die Rolle die API-Gruppen nicht lesen kann, erhält diese Prüfung einen Wert, den die Benutzeroberfläche nicht verarbeiten kann, und das Löschen wird nicht abgeschlossen.
  • Lösung: Lassen Sie einen Benutzer, dessen Rolle die Berechtigung Admin Rollenberechtigung hat, das Löschen durchführen. Das Gewähren der Berechtigung Admin für die betroffene Rolle funktioniert ebenfalls, ist aber eine umfassende Erhöhung auf Organisationsebene, daher ist es vorzuziehen, dass ein vorhandener Administrator die API löscht.

API-Umgebung kann nach der Erstellung nicht geändert werden

  • Symptom: Eine API wurde in der falschen Umgebung erstellt und muss verschoben werden, aber das Umgebungsfeld ist nicht bearbeitbar.
  • Mögliche Ursache: Die Umgebung wird zum Zeitpunkt der API-Erstellung festgelegt und kann danach nicht mehr geändert werden.
  • Lösung:
    • Um eine benutzerdefinierte oder Proxy-API in eine andere Umgebung zu verschieben, klonen Sie die API von der APIs-Seite und wählen Sie während des Klonens die richtige Umgebung aus.
    • Alternativ können Sie die API aus ihrer aktuellen Umgebung exportieren und in die Zielumgebung importieren.

CORS aktiviert: OPTIONS-Anfragen werden ohne Authentifizierung ausgeführt

  • Symptom: Nach dem Aktivieren von CORS auf einer benutzerdefinierten oder Proxy-API verarbeitet die OPTIONS-HTTP-Methode Anfragen ohne Authentifizierung.
  • Mögliche Ursache: Das Aktivieren von CORS führt dazu, dass Operationen mit der OPTIONS-Methode ohne Authentifizierung ausgeführt werden. Dies ist erforderlich, um Browser-Preflight-Anfragen zu unterstützen, bedeutet aber, dass jede OPTIONS-Anfrage die Operation erreicht, ohne das Sicherheitsprofil zu durchlaufen.
  • Lösung:
    • Wenn die API OPTIONS nicht für sensible Operationen verwendet, ist keine Aktion erforderlich. Dies ist das erwartete Verhalten, wenn CORS aktiviert ist.
    • Wenn eine authentifizierte Verarbeitung von OPTIONS erforderlich ist, deaktivieren Sie CORS auf der API oder strukturieren Sie die Operation so um, dass sie unauthentifizierte Preflight-Anfragen explizit erkennt und verarbeitet.

Cloud-Proxy-API: Ziel-API muss öffentlich zugänglich sein

  • Symptom: Eine Proxy-API, die das von Jitterbit gehostete Cloud-API-Gateway verwendet, gibt Fehler zurück oder kann die Ziel-API nicht erreichen.
  • Mögliche Ursache: Bei Verwendung des Cloud-API-Gateways muss die zu proxierende API aus dem öffentlichen Internet erreichbar sein. APIs hinter einer Firewall oder in einem privaten Netzwerk können vom Cloud-Gateway nicht erreicht werden.
  • Lösung:
    • Bestätigen Sie, dass die Ziel-API aus dem öffentlichen Internet erreichbar ist, auch wenn sie gesichert ist.
    • Wenn die Ziel-API hinter einer Firewall bleiben muss, stellen Sie stattdessen ein privates API-Gateway im selben privaten Netzwerk bereit, anstatt das Cloud-API-Gateway zu verwenden.
    • Um die IP-Adressen des Cloud-Gateways auf die Whitelist zu setzen, damit das Gateway auf die zu proxierende API zugreifen kann, siehe Whitelist-Informationen.

Die Einstellung „Request & Response Payloads anzeigen" hat keine Auswirkung auf Proxy-APIs

  • Symptom: Der Umschalter Request & Response Payloads in Logs anzeigen wird in den Einstellungen einer Proxy-API angezeigt, aber das Aktivieren hat keine Auswirkung auf die Protokollausgabe.
  • Mögliche Ursache: Die Protokollierung von Request- und Response-Payloads wird für Proxy-APIs nicht unterstützt. Der Umschalter ist in der Konfigurationsoberfläche sichtbar, funktioniert aber nicht für diesen API-Typ.
  • Lösung: Um Request- und Response-Payloads zu erfassen, verwenden Sie eine benutzerdefinierte API, die denselben Endpunkt aufruft, wobei die Einstellung Request & Response Payloads in Logs anzeigen unterstützt wird.

Leistung und Timeouts

HTTP 504 Gateway Timeout

  • Symptom: API-Aufrufe geben Folgendes zurück:
504 Gateway Timeout

Dies tritt normalerweise auf, nachdem das Timeout-Fenster des Gateways (30 bis 180 Sekunden, je nach Timeout-Einstellung der API) abgelaufen ist.

  • Mögliche Ursachen:

    • Die API-URL ist fehlerhaft oder Pfadparameter werden nicht korrekt verarbeitet, wodurch das Gateway beim Routing der Anfrage fehlschlägt.
    • Der Backend-Vorgang oder der externe Service antwortet zu langsam innerhalb des Timeout-Fensters des Gateways, beispielsweise aufgrund großer Payloads oder komplexer Transformationslogik.
    • Die Anfrage kann keinem verfügbaren Agent zugewiesen werden, beispielsweise weil die Agent-Gruppe die maximale Parallelität erreicht hat oder stark belastet ist, sodass ein Timeout am Gateway auftritt, bevor der Vorgang ausgeführt wird. Ein Zeichen dafür ist, dass die fehlgeschlagene Anfrage keinen entsprechenden Eintrag in den Vorgangslogs hat.

  • Lösung:

    • Überprüfen Sie, dass die API-URL korrekt formatiert ist. Falls die API Pfadparameter verwendet, erwägen Sie, ein Skript zum Vorgang hinzuzufügen, das die URL explizit analysiert und die Parameterwerte erfasst.
    • Falls das Timeout durch einen langsamen Backend verursacht wird, überprüfen Sie den Vorgang und seine Transformationslogik auf Performance-Engpässe, insbesondere große Datenmengen oder langsame externe Aufrufe, und reduzieren Sie den langsamen Schritt.
    • Falls der Vorgang tatsächlich mehr Zeit benötigt als die aktuelle Einstellung zulässt, erhöhen Sie das Timeout auf der API-Einstellungsregisterkarte. Das API-Timeout (Standard 30 Sekunden, Maximum 180 Sekunden) ist unabhängig vom Studio-Vorgangstimeout. Das Vorgangstimeout wird nur auf privaten Agents verwendet, wenn die EnableAPITimeout-Einstellung in der Agent-Konfiguration aktiviert ist.
    • Falls der Vorgang nicht innerhalb des maximalen Timeouts abgeschlossen werden kann oder eine Echtzeit-Antwort nicht erforderlich ist, gestalten Sie den API-Vorgang so um, dass die langfristige Arbeit asynchron gestartet wird (beispielsweise durch Aufrufen mit RunOperation im asynchronen Modus), damit die API eine Antwort zurückgeben kann, ohne auf den Abschluss zu warten. Siehe Asynchrone Vorgänge verwalten.
    • Bei zeitweiligen Timeouts fügen Sie Wiederholungen hinzu, damit ein vorübergehender Fehler erneut versucht wird: Verwenden Sie die integrierten Wiederholungseinstellungen der HTTP v2-Verbindung für ausgehende Aufrufe oder eine skriptgesteuerte RunOperation-Wiederholungsschleife mit einer Verzögerung zwischen den Versuchen.
    • Falls Timeouts mit der Agent-Last korrelieren, überprüfen Sie die Agent-Kapazität: Führen Sie API-bedienende Vorgänge auf Agents aus, die von schweren ETL-Workloads getrennt sind, und fügen Sie Agents zur Gruppe hinzu, falls diese überlastet ist. Siehe Optimieren und verbessern Sie die Performance von Jitterbit Private Agents.

Private Gateway gibt eine 400-Seite „Jitterbit Services überprüfen" ohne API-Log-Eintrag zurück

  • Symptom: Anfragen über ein privates API-Gateway schlagen zeitweilig mit einer HTTP-400-Antwort fehl. Statt einer normalen API-Antwort erhält der Aufrufer eine HTML-Fehlerseite ähnlich wie:

    Error connecting to Jitterbit Services. Please verify that all Jitterbit Services are running on your Jitterbit Agent machine - including the Apache server and Process Engine.

    Es erscheint kein Eintrag in den API-Logs für die fehlgeschlagene Anfrage, da die Anfrage nie einen Vorgang erreicht hat.

  • Mögliche Ursache: Die private Agent-Gruppe ist überlastet und hat keine verfügbaren Apache-Worker-Threads, um Jobs vom privaten API-Gateway anzunehmen. Wenn kein Worker-Thread frei ist, schlägt die Gateway-zu-Agent-Übergabe mit einem Verbindungsabbruch fehl, bevor die Anfrage protokolliert oder ausgeführt werden kann.

  • Lösung:
    1. Fügen Sie mehr Agents zur Agent-Gruppe hinzu, um die Last zu verteilen, und bestätigen Sie, dass die Agent-Hosts über ausreichend CPU und Speicher verfügen.
    2. Überwachen Sie die Apache-Worker-Thread-Nutzung der Agents. Falls native Observability aktiviert ist, überprüfen Sie die Diagramme Apache Thread Capability, Apache idle workers und Apache busy workers (siehe Dashboards), um zu bestätigen, ob Threads während der Fehler erschöpft sind.
    3. Falls die Agents auch nach dem Skalieren konsistent die Apache-Worker-Threads erschöpfen, kontaktieren Sie den Jitterbit-Support, um die Apache-Worker-Thread-Kapazität der Agents zu überprüfen (die MaxRequestWorkers-Einstellung). Ändern Sie die Jitterbit-Apache-Konfigurationsdateien nicht, es sei denn, Sie werden vom Jitterbit-Support angewiesen. Siehe Apache-Konfigurationsdateien.

Anzeige und Synchronisierung

API Portal spiegelt Projektänderungen nicht wider

  • Symptom: Das API Portal zeigt veraltete Projektnamen oder Attribute an, nachdem ein Projekt umbenannt oder aktualisiert wurde.
  • Mögliche Ursache: Das API Portal wurde nach der Projektänderung nicht automatisch synchronisiert.
  • Lösung:
    1. Um alle benutzerdefinierten und Proxy-APIs in der Umgebung zu aktualisieren, öffnen Sie den Portal Manager und klicken Sie auf Regenerate Docs. Um eine einzelne API zu aktualisieren, öffnen Sie deren Registerkarte Documentation auf der Seite APIs und klicken Sie auf Save & Publish.
    2. Überprüfen Sie, dass die aktualisierten Informationen korrekt im API Portal angezeigt werden.

Sicherheitsprofiländerungen benötigen mehrere Minuten, um wirksam zu werden

  • Symptom: Eine API verhält sich weiterhin so, als ob eine alte Sicherheitsprofil-Konfiguration aktiv ist, obwohl das Profil aktualisiert und gespeichert wurde.
  • Mögliche Ursache: Sicherheitsprofile werden auf dem API-Gateway zwischengespeichert. Änderungen an einem aktiven Sicherheitsprofil werden nicht sofort wirksam.
  • Lösung:
    1. Warten Sie mehrere Minuten nach dem Speichern einer Sicherheitsprofiländerung, bevor Sie die betroffene API testen.
    2. Wenn das Problem nach 10 Minuten weiterhin besteht, bestätigen Sie, dass die Änderung korrekt gespeichert wurde, indem Sie das Sicherheitsprofil erneut öffnen.

Das Löschen einer API aktualisiert die API Portal-Dokumentation nicht

  • Symptom: Nach dem Löschen einer API bleibt deren OpenAPI-Dokumentation im API Portal sichtbar.
  • Mögliche Ursache: Die API Portal-Dokumentation wird nicht automatisch aktualisiert, wenn eine API aus dem API Manager gelöscht wird.
  • Lösung:
    • Nach dem Löschen einer API öffnen Sie den Portal Manager und entfernen oder aktualisieren Sie dort manuell den Dokumentationseintrag der API.
    • Alternativ können Sie die Registerkarte Documentation für die API vor dem Löschen verwenden, um den Portal-Eintrag zuerst zu entfernen.

Sicherheitsprofil kann nicht gelöscht werden, während es noch einer veröffentlichten API zugewiesen ist

  • Symptom: Der Versuch, ein Sicherheitsprofil zu löschen, schlägt fehl oder die Löschoption ist nicht verfügbar, auch nachdem das Profil von einer API entfernt wurde.
  • Mögliche Ursache: Nach dem Entfernen eines Sicherheitsprofils aus der API-Konfiguration muss die API gespeichert und erneut veröffentlicht werden, bevor das Profil als vollständig nicht zugewiesen gilt. Bis die API erneut veröffentlicht wird, behandelt der API Manager das Profil weiterhin als in Verwendung.
  • Lösung:
    1. Nach dem Entfernen des Sicherheitsprofils von der API klicken Sie auf Save und dann auf Publish für die API.
    2. Sobald die API mit der aktualisierten Konfiguration erneut veröffentlicht wurde, wird das Sicherheitsprofil nicht mehr als in Verwendung angezeigt und kann gelöscht werden.

Probleme mit privatem Gateway

2-legged OAuth fällt auf 3-legged zurück bei privaten Gateway-Versionen vor 10.48

  • Symptom: Ein Sicherheitsprofil, das für 2-legged OAuth konfiguriert ist, verwendet stattdessen 3-legged OAuth, wenn es über ein privates API-Gateway bereitgestellt wird.
  • Mögliche Ursache: Private API-Gateways vor Version 10.48 unterstützen 2-legged OAuth nicht. Wenn die Gateway-Version unter 10.48 liegt, fällt das Sicherheitsprofil auf 3-legged OAuth zurück, auch wenn 2-legged OAuth konfiguriert ist.
  • Lösung:
    1. Überprüfen Sie die Version des privaten API-Gateways, das die API bereitstellt.
    2. Aktualisieren Sie das Gateway auf Version 10.48 oder später, um die Unterstützung für 2-legged OAuth zu aktivieren.

Multi-Gateway ALB: Alle Container müssen sich auf demselben Host befinden

  • Symptom: In einer containerisierten Multi-Gateway-Umgebung hinter einem Application Load Balancer (ALB) schlagen API-Aufrufe intermittierend fehl oder Payloads können nicht abgerufen werden, obwohl einzelne Gateways fehlerfrei erscheinen.
  • Mögliche Ursache: Bei Verwendung eines containerisierten privaten API-Gateways mit einem ALB müssen alle Gateway-Container auf demselben Host-Rechner ausgeführt werden. Container, die auf verschiedenen Hosts bereitgestellt werden, können die Payload-Abrufung nicht koordinieren, was zu intermittierenden Fehlern führt.
  • Lösung:
    1. Bestätigen Sie, dass alle privaten API-Gateway-Container in der Gruppe auf demselben physischen oder virtuellen Host ausgeführt werden.
    2. Wenn Container auf mehrere Hosts verteilt sind, konsolidieren Sie diese auf einem einzelnen Host.
    3. Für Multi-Host-Bereitstellungen überprüfen Sie die ALB-Konfiguration im Gateway-Installationshandbuch auf zusätzliche Konfigurationsanforderungen.

Privates Gateway: Benutzerdefinierte SSL-Konfiguration wird durch Upgrades überschrieben

  • Symptom: Nach einem Upgrade eines privaten API-Gateways werden benutzerdefinierte SSL-Protokoll- oder Cipher-Einstellungen nicht mehr angewendet und das Gateway kehrt zum Standard-TLS-Verhalten zurück.
  • Mögliche Ursache: Der Upgrade-Prozess des privaten API-Gateways überschreibt die On-Premise-Konfigurationsdatei (/usr/local/openresty/nginx/conf/onpremise.conf). Alle manuellen Änderungen an dieser Datei, einschließlich benutzerdefinierter SSL-Protokollbeschränkungen oder Cipher-Listen, gehen während des Upgrades verloren.
  • Lösung:
    1. Sichern Sie die On-Premise-Konfigurationsdatei, bevor Sie das private API-Gateway aktualisieren.
    2. Nach Abschluss des Upgrades wenden Sie Ihre benutzerdefinierten SSL-Einstellungen auf die neue Konfigurationsdatei an.

Privates Gateway gibt HTTP 507 oder „No such file or directory" zurück

  • Symptom: Private API-Gateway-Endpunkte geben 507 Insufficient Storage zurück. Gateway-Protokolle zeigen:

    could not open payload file: No such file or directory

    obwohl auf den Gateway-Hosts ausreichend Speicherplatz vorhanden ist.

  • Mögliche Ursache: Hier bedeutet 507, dass das Gateway die gehostete Payload- oder Antwortdatei für die Anfrage nicht öffnen konnte; dies bedeutet nicht unbedingt, dass der Host keinen Speicher mehr hat. In einem Multi-Node-Private-API-Gateway hinter einem Load Balancer kann dies vorkommen, wenn der Node, der eine Anfrage verarbeitet, nicht auf eine gehostete Datei zugreifen kann, die ein anderer Node erstellt hat, da diese Dateien lokal auf jedem Node vorhanden sind.

  • Lösung:

    1. Bestätigen Sie, dass die Gateway-Hosts nicht wirklich keinen Speicher mehr haben, indem Sie die Festplatte und Inode-Nutzung überprüfen (df -h und df -i). Geben Sie Speicherplatz frei und testen Sie erneut, nur wenn diese tatsächlich voll sind.
    2. Wenn das Gateway als mehrere Nodes hinter einem Load Balancer ausgeführt wird, bestätigen Sie, dass der Load Balancer jede Anfrage und ihre Antwort konsistent an denselben Node leitet, da gehostete Payload- und Antwortdateien lokal auf dem Node vorhanden sind, der sie erstellt hat. Für containerisierte Gateways siehe Multi-Gateway ALB: Alle Container müssen sich auf demselben Host befinden.
    3. Wenn der Fehler weiterhin besteht, aktivieren Sie die Trace-Protokollierung auf dem Gateway (setzen Sie traceLogsEnabled auf true in der Gateway-Konfiguration) und kontaktieren Sie den Jitterbit-Support mit den resultierenden Trace-Protokollen, den Gateway-Protokollen (/opt/jitterbit/var/log/api-gateway), den NGINX- oder OpenResty-Protokollen und der ls -lR-Ausgabe für die hosted-files-Verzeichnisse auf jedem Node. Der Support kann serverseitige Bedingungen überprüfen, die nicht vom Kunden konfigurierbar sind, wie z. B. die Host-zu-Umgebungs-Zuordnung, veraltete Private-Domain-Einträge und Dateiberechtigungen.

Installation oder Upgrade des privaten Gateways schlägt fehl mit fehlenden Abhängigkeiten

  • Symptom: Das Ausführen von yum install zur Installation oder zum Upgrade eines privaten API-Gateways für Linux (RPM) auf Version 10.62 oder später schlägt mit Fehlern zu fehlenden Abhängigkeiten fehl:

    Nothing provides geoip-devel needed by jitterbit-api-gateway-11.x.x-x.x86_64
Nothing provides libGeoIP.so.1()(64bit) needed by jitterbit-api-gateway-11.x.x-x.x86_64

  • Mögliche Ursache: Das private API-Gateway ab Version 10.62 erfordert die Pakete geoip-devel und libGeoIP, die vom EPEL-Repository bereitgestellt werden. Die dokumentierte Installation aktiviert EPEL vor der Installation des Gateways. Der Fehler tritt auf, wenn dieser Schritt übersprungen wird oder wenn der Gateway-Host keinen Internetzugang hat und EPEL nicht erreichen kann, um die Pakete herunterzuladen.

  • Lösung:

    • Aktivieren Sie auf einem Gateway-Host mit Internetzugang das EPEL-Repository vor der Installation des Gateways, wie unter Installation eines privaten API-Gateways beschrieben: Führen Sie yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm aus und führen Sie dann die Gateway-Installation erneut aus.
    • Auf einem isolierten Host ohne Internetzugang wird durch die Installation des Pakets epel-release allein nur die Repository-Definition hinzugefügt; die Pakete geoip-devel und libGeoIP werden nicht heruntergeladen. Laden Sie diese Pakete und ihre transitiven Abhängigkeiten auf einem Computer mit Internetzugang herunter, übertragen Sie sie auf den Gateway-Host und installieren Sie sie in Abhängigkeitsreihenfolge mit yum install <package.rpm>, bevor Sie die Gateway-Installation erneut ausführen.

Selbsttest des privaten Gateways gibt „Failure, test call to API failed" zurück

  • Symptom: Das Selbsttest-Dienstprogramm der Befehlszeile des privaten API-Gateways gibt Folgendes zurück:

    Failure, test call to API failed

  • Mögliche Ursache: Bei privaten API-Gateway-Versionen 11.30 und älter erstellt das Selbsttest-Dienstprogramm eine Test-API, der erforderliche Felder (Service Name und Path) fehlen, was dazu führt, dass der Testaufruf fehlschlägt.

  • Lösung:
    • Aktualisieren Sie das private API-Gateway auf Version 11.31 oder später, was dies automatisch behebt.
    • Falls ein sofortiges Upgrade nicht möglich ist: Öffnen Sie die API-Konfiguration für die API mit dem Namen ApiGatewayTest, füllen Sie das Feld Service Name mit einem beliebigen Wert (z. B. service), setzen Sie Path auf /, speichern und veröffentlichen Sie, führen Sie dann das Selbsttest-Dienstprogramm erneut aus.

Analytik und API-Verhalten

OData $count oder $inlinecount gibt einen Fehler zurück, wenn keine Datensätze übereinstimmen

  • Symptom: Eine OData-Serviceabfrage mit den Systemabfrageoptionen $count oder $inlinecount gibt einen Fehler statt 0 zurück, wenn keine Datensätze dem Filter entsprechen.
  • Mögliche Ursache: Ein OData-Service gibt standardmäßig einen Fehler statt 0 zurück, wenn eine $count- oder $inlinecount-Abfrage keine Datensätze findet.
  • Lösung: Setzen Sie auf privaten Agenten mit Version 11.32 oder später den OData-Parameter $noErrorOnZeroCount in der OData-Service-Konfiguration auf true. Dies führt dazu, dass $count-Abfragen 0 statt eines Fehlers zurückgeben, wenn keine Datensätze übereinstimmen.

Proxy-API: Anforderungsheader-Bindestriche durch Unterstriche ersetzt

  • Symptom: Ein Proxy-API-Vorgang empfängt Anforderungsheader, bei denen Bindestriche durch Unterstriche ersetzt werden (z. B. kommt X-Custom-Header als X_Custom_Header an), was dazu führt, dass Header-Lookups fehlschlagen.
  • Mögliche Ursache: Proxy-APIs haben eine Einstellung disable-hyphen-replacement, die steuert, ob Bindestriche in Anforderungsheader-Namen durch Unterstriche ersetzt werden. Bei neuen Proxy-APIs ist diese Einstellung standardmäßig auf true gesetzt (Ersetzung deaktiviert). Ältere Proxy-APIs können sie auf false gesetzt haben, was die Ersetzung verursacht.
  • Lösung:
    • Überprüfen Sie in der Proxy-API-Konfiguration die Header-Einstellung disable-hyphen-replacement. Um Bindestriche in Header-Namen beizubehalten, stellen Sie sicher, dass die Einstellung true ist.
    • Falls die Proxy-API vor Einführung dieses Standards erstellt wurde und die Ersetzung unerwartet auftritt, aktualisieren Sie die Einstellung auf true und veröffentlichen Sie die API erneut.

Operationsprotokolle sind nicht sichtbar für API-ausgelöste Operationen, wenn der Debug-Modus deaktiviert ist

  • Symptom: Nach dem Aufrufen einer API zeigt das API-Protokoll an, dass der Aufruf erfolgreich war, aber auf der Seite Runtime wird kein Operationsprotokoll für die von der API ausgelöste Operation angezeigt. Aufrufe von WriteToOperationLog aus der Operation heraus erzeugen ebenfalls keine sichtbaren Protokolleinträge.
  • Mögliche Ursache: Wenn eine Operation über eine veröffentlichte API ausgelöst wird, werden erfolgreiche Ausführungen standardmäßig nicht in den Operationsprotokollen angezeigt. Fehlgeschlagene Operationen werden immer protokolliert; nur erfolgreiche Operationsprotokolle und alle WriteToOperationLog-Ausgaben aus erfolgreichen Ausführungen werden ausgeblendet. Erfolgreiche Ausführungen werden nur angezeigt, wenn Debug-Modus aktivieren bis (eine API-Manager-Einstellung) oder Operationen-Debug-Protokollierung (eine Agent-Einstellung) aktiv ist.
  • Lösung:
    1. Um erfolgreiche Operationsprotokolle und WriteToOperationLog-Ausgaben anzuzeigen, aktivieren Sie Debug-Modus aktivieren bis für die API auf der Registerkarte API-Einstellungen, oder aktivieren Sie Operationen-Debug-Protokollierung auf dem Agent.
    2. Um auch die Rohanfrage- und Antwortdaten sowie Payloads zu erfassen, aktivieren Sie entweder Debug-Modus aktivieren bis (wie in Schritt 1), oder kombinieren Sie Operationen-Debug-Protokollierung mit Anfrage- und Antwort-Payloads in Protokollen anzeigen und Ausführliches Protokollieren. Welche Daten jede Einstellung erfasst, hängt von der aktivierten Kombination ab; eine vollständige Aufschlüsselung finden Sie unter API-Anfrage- und Antwortdaten.
    3. Deaktivieren Sie den Debug-Modus nach dem Erfassen der benötigten Protokolle, da das Aktivieren das Protokollvolumen erhöht.

API-Payload ist 2 Tage lang auf dem Agent verfügbar

  • Symptom: Ein Workflow, der eine API-Anfrage-Payload vom Agent mehr als 2 Tage nach dem API-Aufruf abruft, kann die Payload nicht finden.
  • Mögliche Ursache: API-Anfrage-Payloads für benutzerdefinierte APIs und OData-Services werden maximal 2 Tage lang auf dem Agent gespeichert. Nach diesem Zeitraum ist die Payload nur verfügbar, wenn die Operation sie bereits in einen persistenten Speicher-Connector geschrieben hat (z. B. Temporary Storage, File Share oder eine Datenbank).
  • Lösung:
    • Entwerfen Sie Operationen, die API-Anfrage-Payloads verarbeiten, um die Daten sofort zu verarbeiten, wenn die API aufgerufen wird, anstatt den Payload-Abruf zu verschieben.
    • Wenn die Payload für längere Verarbeitung beibehalten werden muss, schreiben Sie sie in der ursprünglichen API-ausgelösten Operation an einen persistenten Speicherort.

Die Seite API-Protokolle behält vorherige Filterauswahlen bei

  • Symptom: Die Seite API-Protokolle zeigt nicht die erwarteten Protokolleinträge an, obwohl die API erfolgreich ausgeführt wird.
  • Mögliche Ursache: Die Seite API-Protokolle speichert Filterauswahlen aus der vorherigen Sitzung. Ein zuvor angewendeter Filter könnte die erwarteten Ergebnisse ausblenden.
  • Lösung: Überprüfen Sie auf der Seite API-Protokolle alle aktiven Filter und löschen Sie alle, die die erwarteten Einträge möglicherweise ausschließen.

Unveröffentlichte APIs werden nicht in der Dropdown-Liste Analytics-APIs angezeigt

  • Symptom: Eine API wird nicht in der Dropdown-Liste APIs auf der Seite Analytics angezeigt, daher können Analysedaten für diese API nicht gefiltert werden.
  • Mögliche Ursache: Nur derzeit veröffentlichte APIs werden in der Dropdown-Liste APIs angezeigt. APIs, die unveröffentlicht wurden, werden aus der Dropdown-Liste ausgeschlossen, auch wenn API-Protokolle für diese APIs vorhanden sind.
  • Lösung:
    • Bestätigen Sie, dass die API veröffentlicht wurde. Um Analysedaten anzuzeigen, muss sich die API in einem veröffentlichten Zustand befinden.
    • Um Protokolleinträge für eine unveröffentlichte API anzuzeigen, verwenden Sie stattdessen die Seite API-Protokolle. Protokolldaten bleiben dort verfügbar, können aber nicht nach API-Name gefiltert werden.

Ratenbegrenzung

Fehler 429: Monatliches API-Hit-Kontingent überschritten

  • Symptom: Alle APIs in der Organisation geben plötzlich HTTP-429-Fehler zurück.
  • Mögliche Ursache: Die Organisation hat ihr monatliches API-Hit-Kontingent, das durch ihre Lizenz definiert ist, aufgebraucht. Wenn das Kontingent überschritten wird, werden alle API-Aufrufe für den Rest des Monats mit einer 429-Antwort abgelehnt.
  • Lösung:
    • Überprüfen Sie die aktuelle Hit-Anzahl gegen Ihr monatliches Kontingent auf der APIs-Seite. Das Kontingent wird am ersten Tag des folgenden Monats zurückgesetzt.
    • Um zu vermeiden, dass Sie das Limit erreichen, konfigurieren Sie Ratenbegrenzungen auf Umgebungs- oder Sicherheitsprofil-Ebene mit der Einstellung Hits pro Minute, um die Last zu verteilen und Verbrauchslimits pro Consumer durchzusetzen.
    • Um das monatliche Kontingent Ihrer Organisation zu erhöhen, kontaktieren Sie Ihren Customer Success Manager.

Fehler 429: Consumer-IP nicht im vertrauenswürdigen IP-Bereich

  • Symptom: Ein bestimmter Consumer oder eine bestimmte Anwendung erhält HTTP-429-Fehler beim Aufrufen einer API, während andere Consumer dieselbe API erfolgreich aufrufen können.
  • Mögliche Ursache: Das der API zugewiesene Sicherheitsprofil hat vertrauenswürdige IP-Gruppen konfiguriert. Anfragen von IP-Adressen außerhalb der zulässigen Bereiche werden mit einer 429-Antwort abgelehnt.
  • Lösung:
    1. Öffnen Sie das Sicherheitsprofil, das der API zugewiesen ist, und überprüfen Sie seine Konfiguration der vertrauenswürdigen IP-Gruppe.
    2. Fügen Sie die IP-Adresse oder den Adressbereich des Consumers zu einer vorhandenen vertrauenswürdigen IP-Gruppe hinzu, oder erstellen Sie eine neue vertrauenswürdige IP-Gruppe, die die erforderlichen Adressen enthält.

Plattform-Ratenbegrenzung: 200 Anfragen pro Minute

  • Symptom: APIs, die auf dem von Jitterbit verwalteten Cloud-API-Gateway gehostet werden, werden gedrosselt oder mit einer 429 Too Many Requests-Antwort unter hohem Datenverkehr abgelehnt, auch wenn die Ratenbegrenzungen des Sicherheitsprofils nicht erreicht wurden.
  • Mögliche Ursache: Das von Jitterbit verwaltete Cloud-API-Gateway erzwingt ein Plattform-Limit von 200 API-Anfragen pro Minute pro Organisation, das über alle API-Typen (benutzerdefiniert, Proxy und OData) verteilt ist. Dieses Limit gilt nicht für private API-Gateways.
  • Lösung:
    • Überprüfen Sie Ihre API-Verkehrsmuster und verteilen Sie Aufrufe nach Möglichkeit über die Zeit, um innerhalb des Limits von 200 Anfragen pro Minute zu bleiben.
    • Wenn Ihr Anwendungsfall einen anhaltenden Durchsatz über diesem Limit erfordert, stellen Sie ein privates API-Gateway bereit, bei dem der Durchsatz durch die Kapazität des Host-Servers und nicht durch eine Plattform-Obergrenze bestimmt wird.

Netzwerk und Konnektivität

Zscaler oder SSL-abfangende Firewall blockiert API-Zugriff

  • Symptom: API-Aufrufe schlagen mit Zertifikatfehlern fehl, oder Backend-Endpunkte können nicht auf APIs zugreifen, die mit TLS gesichert sind, wenn sie über ein Zscaler-verwaltetes oder ähnliches SSL-inspizierendes Netzwerk weitergeleitet werden.
  • Mögliche Ursachen:
    • Zscaler und ähnliche Sicherheitsproxys führen SSL/TLS-Inspektionen durch, indem sie HTTPS-Datenverkehr abfangen und mit ihrem eigenen CA-Zertifikat erneut signieren. Client-Systeme, die der Zscaler-Root-CA nicht vertrauen, lehnen die Verbindung ab.
    • Das manuelle Importieren des Jitterbit-Zertifikats in den Trust Store ist keine zuverlässige Lösung: Wenn Jitterbit sein Zertifikat erneuert, wird die manuell importierte Kopie veraltet und unterbricht die Verbindung erneut.
  • Lösung:
    • Installieren Sie das Zscaler-Root-CA-Zertifikat im Betriebssystem oder Browser-Trust Store auf den Systemen, die die API-Aufrufe durchführen, damit Zscaler-erneut signierte Zertifikate vertraut werden.
    • Konfigurieren Sie für Tools wie curl, wget oder openssl, dass sie den in der Zscaler-Umgebung definierten HTTP-Proxy verwenden.
    • Fordern Sie eine Zscaler-Richtlinienausnahme für die Jitterbit-API-Gateway-Hostnamen an, um die SSL-Inspektionen für diese spezifischen Ziele zu umgehen.
    • Überprüfen Sie die Regeln der PAC-Datei (Proxy Auto-Configuration) der Organisation, um zu bestätigen, dass Jitterbit-Endpunkte korrekt behandelt werden.
    • Importieren Sie das Jitterbit-Leaf-Zertifikat nicht manuell in einen Trust Store als Lösung: Verwenden Sie stattdessen die Zscaler-Root-CA, um Unterbrechungen bei der Zertifikatreneuerung durch Jitterbit zu vermeiden.