Jitterbit Private API Gateway
Einführung
Ein Private API Gateway, das in einem privaten Netzwerk gehostet wird, verwaltet diese Sicherheitsfunktionen und Aufgaben beim Akzeptieren und Verarbeiten von API Manager API-Aufrufen:
- Datenverkehrsverwaltung.
- Autorisierung und Zugriffskontrolle.
- Ratenbegrenzung.
- API-Payload-Verarbeitung.
Sie können ein Private API Gateway auf Linux installieren und ausführen oder es als Linux-basiertes Docker-Container ausführen.
Ein Private API Gateway ist ein lokales Gateway zur direkten Verarbeitung von APIs von Ihren eigenen Servern. API Manager-Sicherheitsfunktionen werden auf API-Ebene oder Sicherheitsprofil-Ebene konfiguriert und im Private API Gateway zwischengespeichert. Diese werden dann während der API-Laufzeit wie unten beschrieben referenziert.
Systemarchitektur des Private API Gateway
Die Verwendung eines Private API Gateway bietet diese zusätzlichen Vorteile gegenüber dem Cloud API Gateway:
-
Internes Netzwerk: Das Private API Gateway und seine Agenten können ausschließlich auf ein internes Netzwerk hinter einer Firewall beschränkt werden und sind nicht über das Internet erreichbar.
Hinweis
Wenn sich Ihre Private API Gateway-Installation hinter einer Firewall in Ihrem Netzwerk befindet, müssen Sie erforderliche Jitterbit-Dienste auf die Allowlist setzen.
-
Payload-Sicherheit: API-Response-Payloads werden niemals über Jitterbit-Systeme übertragen.
- Kontrolle: Sie haben Kontrolle über die Hardware- und Softwareumgebung des Private API Gateway und stellen sicher, dass diese den Standards Ihres Unternehmens entspricht.
- Domänenname: Die Basis-API-Endpunkt-URL kann als Subdomain eines Domänennamens konfiguriert werden, den Sie kontrollieren, anstatt als Subdomain der Harmony-Region (
jitterbit.cc,jitterbit.euoderjitterbit.net). Eine Alternative zur Verwendung eines Private API Gateway zur Kontrolle des Domänennamens ist die Verwendung eines Tools von Drittanbietern wie Cloudflare oder eines DNS-Proxys, um einen benutzerdefinierten Domänennamen zur Basis-URL weiterzuleiten.
Dieses Diagramm zeigt die Systemarchitektur einer benutzerdefinierten API, die lokal mit einem privaten Agenten und einem Private API Gateway bereitgestellt wird:

-
Ein API-Consumer ruft die API auf, die sich im Private API Gateway befindet.
-
Das Private API Gateway referenziert die zwischengespeicherten Sicherheitsprofile (falls zutreffend) und API-Metadaten, um Authentifizierungs- und Zugriffskontrollaufgaben auszuführen. Wenn der Zugriff auf die API verweigert wird, gibt das Private API Gateway eine entsprechende HTTP-Antwort und einen Status an den API-Consumer zurück. Wenn der Zugriff auf die API gewährt wird, wird die API-Anfrage an den Messaging-Service weitergeleitet, der Anfragen für Agentgruppen weiterleitet.
-
Der private Agent empfängt die Anfrage vom Messaging-Service.
-
Der private Agent referenziert den während der benutzerdefinierten API-Konfiguration angegebenen API-Vorgang und löst den bereitgestellten Vorgang aus.
-
Der Vorgang antwortet mit einer API-Payload, die dem während der benutzerdefinierten API-Konfiguration ausgewählten Antworttyp entspricht.
-
Die API-Response-Payload wird vom privaten Agenten zurück zum Private API Gateway weitergeleitet, das die API-Payload extrahiert und die endgültige HTTP-Antwort und den Status festlegt. Die HTTP-Antwort und der Status werden an den API-Consumer gesendet.
Hinweis
Sofern der durch den API-Aufruf ausgelöste Vorgang nicht Temporary Storage verwendet, bleibt die API-Response-Payload maximal zwei Tage auf dem Agenten. Die API-Response-Payload bleibt im Private API Gateway nicht länger als das API Gateway-Timeout von 15 Sekunden.
Vorsicht
In Multi-Gateway-Umgebungen hinter einem Application Load Balancer (ALB) wie AWS ALB wird eine Proxy-Anfrage an das Gateway erstellt, das die angeforderte Payload hat, wenn ein Gateway diese nicht hat, um den Payload-Abruf sicherzustellen.
Das erfolgreiche Payload-Routing erfordert möglicherweise zusätzliche Konfiguration je nach Multi-Gateway-Umgebung.
-
Laufzeitstatusinformationen und Protokolle laufender Operationen werden an die Transaktionsprotokoll-Datenbank gesendet.
Hinweis
Verbraucherdaten werden in der Transaktionsprotokoll-Datenbank nicht gespeichert, es sei denn, der Debug-Modus ist während der benutzerdefinierten API-Konfiguration aktiviert.
Fehlerbehebung
Weitere Informationen zur Fehlerbehebung finden Sie in den folgenden Abschnitten im API Manager-Fehlerbehebungsleitfaden:
-
Private Gateway gibt eine 400-Seite „Jitterbit Services überprüfen" ohne API-Protokolleintrag zurück
-
2-legged OAuth fällt auf 3-legged auf Private Gateway-Versionen vor 10.48 zurück
-
Multi-Gateway ALB: Alle Container müssen sich auf demselben Host befinden
-
Private Gateway: Benutzerdefinierte SSL-Konfiguration wird durch Upgrades überschrieben
-
Private Gateway gibt HTTP 507 oder „Datei oder Verzeichnis nicht vorhanden" zurück
-
Private Gateway-Installation oder -Upgrade schlägt mit fehlenden Abhängigkeiten fehl
-
Private Gateway-Selbsttest gibt „Fehler, Testaufruf an API fehlgeschlagen" zurück