Unbekannter Fehler im Bereich „API testen“

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:

Allgemeine Fehlermeldung (zum Vergrößern klicken) allgemeine Fehlermeldung

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

  1. Prüfen Sie, ob das Problem nur auftritt, wenn eine Antwort ohne 2XX erwartet wird.
  2. Prüfen Sie bei fehlgeschlagenen Anfragen, ob Richtlinien im Proxy-Ablauf vorhanden sind.
  3. 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.
    1. Wenn ja, prüfen Sie, ob die AssignMessage-CORS-Richtlinie im Fehler antwortablauf ausgeführt wurde.
    2. Wenn nicht, ist das die Ursache für dieses Problem.
      Wenn eine Richtlinie mit dem Element continueOnError="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 mit Unknown error fehl.

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 für Fehlermeldung, für größeres Bild klicken Beispiel für Fehlermeldung

Beispiel-Erfolgsmeldung im Bereich API testen des integrierten Portals und im Fenster Trace des Proxys:

Beispiel für eine Erfolgsmeldung (zum Vergrößern klicken) Beispiel für eine Erfolgsmeldung

Auflösung

  1. 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.
  2. 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

  1. Prüfen Sie den Wert des Headers Access-Control-Allow-Origin in einer Trace-Sitzung.
  2. 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.
  3. 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.
  4. Dies kann passieren, wenn ein Nutzer das <Add> element für Access-Control-Allow-Origin in einer Richtlinie verwendet hat oder das Backend selbst mehrere Werte festlegt.

Beispiel: Access-Control-Allow-Origin gleich *,*:

Beispiel für mehrere verwendete Werte, für größeres Bild klicken Beispiel für die Verwendung mehrerer Werte

Beispiel: Access-Control-Allow-Origin gleich *:

Beispiel für einen verwendeten Einzelwert (zum Vergrößern klicken) Beispiel für einen verwendeten Einzelwert

Beispiel mit <Add>:

Beispiel für die Verwendung von „Hinzufügen“, für größeres Bild klicken Beispiel für die Verwendung von „Hinzufügen“

Beispiel mit <Set>:

Beispiel mit „Set“, für größeres Bild klicken Beispiel mit „Set“

Auflösung

  1. 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.
  2. 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