Unbekannter Fehler im Bereich „API testen“

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen

Symptom

Beim API-Aufruf vom integrierten Entwicklerportal wird Unknown Error oder eine leere Antwort im Bereich API testen zurückgegeben.

Fehlermeldungen

Im integrierten Portal wird möglicherweise eine leere Antwort oder die folgende Fehlermeldung für die API-Anfragen angezeigt:

Unknown Error

Auf dem Tab Entwicklertools > Console wird folgender Fehler angezeigt:

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.

Hier eine allgemeine Fehlermeldung, die auf dem Tab Entwicklertools > Console angezeigt wird:

Mögliche Ursachen

Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
Unbehandelter Richtlinienfehler	Die Standardfehlerantwort wird ohne CORS-Header gesendet, wenn eine Richtlinie im Laufzeitablauf der API-Anfrage fehlschlägt.	Edge Public Cloud-Nutzer
Mehrere Werte für Access-Control-Allow-Origin	Verwendung von „Hinzufügen“ anstelle von „Festlegen“ in der Richtlinie zum Zuweisen von Nachrichten.	Edge Public Cloud-Nutzer

Ursache: Unbehandelter Richtlinienfehler

Diagnose

1. Achten Sie darauf, dass das Problem nur auftritt, wenn eine andere Antwort als 2XX erwartet wird.
2. Prüfen Sie bei fehlgeschlagenen Anfragen, ob der Proxyablauf Richtlinien enthält.
3. Verfolgen Sie 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 CORS-Richtlinie von AttributionMessage im Fehlerantwortablauf ausgeführt wurde oder nicht.
2. Falls nicht, ist das die Ursache des Problems.
   Das liegt daran, dass die Anfrage in den Fehlerantwortfluss eintritt, wenn eine Richtlinie mit dem Element continueOnError="false" fehlschlägt. Wenn im Fehlerantwortablauf keine explizite Fehlerbehandlung erfolgt, wird die der Richtlinie entsprechende Standardfehlerantwort zurückgesendet. Diese Fehlerantwort hat keine CORS-Header. Daher schlägt der API-Aufruf des integrierten Entwicklerportals mit Unknown error fehl.

Die folgenden Screenshots zeigen eine Beispiel-Fehlermeldung und eine Beispiel-Erfolgsmeldung.

Beispiel für eine Fehlermeldung im integrierten Portal API testen und im Fenster Trace des Proxys:

Beispiel für eine Erfolgsmeldung im Bereich API testen des integrierten Portals und im Fenster Trace des Proxys:

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 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 CORS-Richtlinie von "AssignMessage" 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 Header Access-Control-Allow-Origin kann nur ein einziger Wert festgelegt werden. Wenn mehr als ein Wert festgelegt wird, kann dies zu einem CORS-Problem führen und das Entwicklerportal rendert keine Antworten.
3. Wenn der Wert des Headers Access-Control-Allow-Origin in Trace wie folgt aussieht:
   *,*
Das bedeutet, dass sowohl der Zielserver als auch die CORS-Richtlinie „AssignMessage“ ihren Wert festlegen.
4. Das kann passieren, wenn ein Nutzer <Add> element für Access-Control-Allow-Origin in einer Richtlinie verwendet hat oder das Back-End selbst mehrere Werte festlegt.

Beispiel für Access-Control-Allow-Origin gleich *,*:

Beispiel für Access-Control-Allow-Origin gleich *:

Beispiel mit <Add>:

Beispiel mit <Set>:

Auflösung

1. Es wird empfohlen, <Set> element (anstelle von <Add> element) für Access-Control-Allow-Origin zu verwenden, da nur ein einziger Wert zulässig ist.
2. Alternativ können Sie den Header Access-Control-Allow-Origin an nur 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 Diagnoseinformationen müssen erfasst werden.

Erfassen von Diagnoseinformationen erforderlich

Erfassen Sie die folgenden Diagnoseinformationen und wenden Sie sich an den Apigee Edge-Support:

• Name der Organisation
• Name der Umgebung
• API-Proxy-Name
• Schließen Sie den curl-Befehl ab, um den Fehler zu reproduzieren.
• Ablaufverfolgungsdatei für die API-Anfragen
• Vollständige Ausgabe der Antwort vom Ziel-/Back-End-Server zusammen mit der Größe der Nutzlast