Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur
Dokumentation zuApigee X wechseln. info
Symptom
Der API-Aufruf vom integrierten Entwicklerportal schlägt mit
Unknown Error oder einer leeren Antwort im
Bereich „API testen“
fehl.
Fehlermeldungen
Möglicherweise sehen Sie eine leere Antwort oder die folgende Fehlermeldung für die API Anfragen im integrierten Portal:
Unknown Error
Auf dem Tab Entwicklertools > Console sehen Sie die folgende Fehlermeldung:
Access to XMLHTTPRequest at 'API_URL' from origin 'URL_of_Integrated_DevPortal' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Eine allgemeine Fehlermeldung auf dem Tab „Entwicklertools > Console“ sieht so aus:
Mögliche Ursachen
| Ursache | Beschreibung | Anleitungen zur Fehlerbehebung gelten für |
|---|---|---|
| Nicht behandelter Richtlinienfehler | Die Standardfehlerantwort wird ohne CORS-Header gesendet, wenn eine Richtlinie im Runtime-Ablauf der API-Anfrage fehlschlägt. | Nutzer der Edge Public Cloud |
| Mehrere Werte für Access-Control-Allow-Origin | Verwenden von „Add“ anstelle von „Set“ in der Richtlinie „Assign Message“. | Nutzer der Edge Public Cloud |
Ursache: Nicht behandelter Richtlinienfehler
Diagnose
- Prüfen Sie, ob das Problem nur auftritt, wenn eine Antwort ohne
2XXerwartet wird. - Prüfen Sie bei fehlgeschlagenen Anfragen, ob Richtlinien im Proxy-Ablauf vorhanden sind.
-
Erstellen Sie einen Trace für die Anfrage und prüfen Sie, ob eine Richtlinie mit
continueOnError="false"fehlschlägt und einen Fehler auslöst. - Wenn ja, prüfen Sie, ob die AssignMessage-CORS-Richtlinie im Fehler antwortablauf ausgeführt wurde.
- Wenn nicht, ist das die Ursache für dieses Problem.
Wenn eine Richtlinie mit dem ElementcontinueOnError="false"fehlschlägt, wird die Anfrage in den Fehlerantwortablauf geleitet. Wenn im Fehlerantwortablauf keine explizite Fehlerbehandlung vorhanden ist, wird die Standardfehlerantwort für die Richtlinie zurückgesendet. Diese Fehlerantwort enthält keine CORS-Header. Daher schlägt der API-Aufruf vom integrierten Entwickler portal mitUnknown errorfehl.
Die folgenden Screenshots zeigen eine Beispiel-Fehlermeldung und eine Beispiel Erfolgsmeldung.
Beispiel-Fehlermeldung im Bereich API testen des integrierten Portals und im Fenster Trace des Proxys:
Beispiel-Erfolgsmeldung im Bereich API testen des integrierten Portals und im Fenster Trace des Proxys:
Auflösung
- Anstatt sich auf die Standardfehlermeldung zu verlassen, muss eine Fehlerregel implementiert werden, um die Fehlerantwort zu verarbeiten. Fügen Sie eine AssignMessage-CORS-Richtlinie mit den entsprechenden Headern hinzu und rufen Sie sie in der FaultRule auf.
- Manchmal ist es nicht möglich, für jeden Fehler eine Fehlerregel zu definieren. Daher kann eine Standardfehlerregel implementiert werden, um die AssignMessage-CORS-Richtlinie auszuführen:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="proxy-endpoint-name">
<Description/>
<!-- Add a default fault rule to add CORS -->
<DefaultFaultRule name="fault-rule">
<Step>
<Name>add-cors</Name>
</Step>
</DefaultFaultRule>
<FaultRules/>
<!--
<Flows />
Rest of the proxy definition
-->
</ProxyEndpoint>Ursache: Mehrere Werte für Access-Control-Allow-Origin
Diagnose
- Prüfen Sie den Wert des Headers Access-Control-Allow-Origin in einer Trace-Sitzung.
- Für den Access-Control-Allow-Origin Header kann nur ein einzelner Wert festgelegt werden. Wenn Sie mehr als einen Wert festlegen, kann dies zu einem CORS-Problem führen und das Entwicklerportal kann keine Antworten rendern.
- Wenn der Wert des Headers Access-Control-Allow-Origin im Trace
so aussieht:
*,*Das bedeutet, dass sowohl der Zielserver als auch die AssignMessage-CORS-Richtlinie den Wert festlegen. - Dies kann passieren, wenn ein Nutzer das
<Add> elementfür Access-Control-Allow-Origin in einer Richtlinie verwendet hat oder das Backend selbst mehrere Werte festlegt.
Beispiel: Access-Control-Allow-Origin gleich *,*:
Beispiel: Access-Control-Allow-Origin gleich *:
Beispiel mit <Add>:
Beispiel mit <Set>:
Auflösung
- Es wird empfohlen, das
<Set> element(anstelle des<Add> element) für Access-Control-Allow-Origin zu verwenden, da nur ein einzelner Wert zulässig ist. - Alternativ können Sie den Access-Control-Allow-Origin Header nur an einer Stelle festlegen, entweder in der AssignMessage-CORS-Richtlinie oder auf dem Zielserver.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <AssignMessage async="false" continueOnError="false" enabled="true" name="set-cors"> <DisplayName>Set CORS</DisplayName> <FaultRules/> <Properties/> <Set> <Headers> <Header name="Access-Control-Allow-Origin">*</Header> </Headers> </Set> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="false" transport="http" type="response"/> </AssignMessage>
Wenn Sie weiterhin Unterstützung vom Apigee-Support benötigen, lesen Sie den Abschnitt Erfassen von Diagnoseinformationen erforderlich.
Erfassen von Diagnoseinformationen erforderlich
Erfassen Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an den Apigee Edge-Support:
- Name der Organisation
- Name der Umgebung
- Name des API-Proxys
- Vollständiger Curl-Befehl zum Reproduzieren des Fehlers
- Trace-Datei für die API-Anfragen
- Vollständige Ausgabe der Antwort vom Ziel-/Backend-Server zusammen mit der Größe der Nutzlast