Sie sehen sich die Dokumentation zu Apigee Edge an.
Sehen Sie sich die Apigee X-Dokumentation an. info
In diesem Thema werden die Struktur von Richtlinienfehlern und die Arten von Ablaufvariablen beschrieben, die beim Auftreten eines Richtlinienfehlers festgelegt werden. Diese Informationen sind wichtig, wenn Sie die Fehlerbehandlung für Ihre Proxys entwerfen und implementieren.
In diesem Thema wird davon ausgegangen, dass Sie ein allgemeines Verständnis darüber haben, wie die Fehlerbehandlung in Edge funktioniert, und dass Sie wissen, was Fehlerregeln sind. Weitere Informationen finden Sie unter Fehlerbehandlung. Die Informationen hier helfen Ihnen auch beim Verwenden der Richtlinienfehlerreferenz.
Standardantwort des Richtlinienfehlers
Wenn eine Richtlinie einen Fehler ausgibt, geht Edge sofort in den Fehlerfluss ein und generiert eine Fehlermeldung. Diese vom System generierte Nachricht ist ein JSON-Objekt mit zwei Informationenteilen: einem Fehlercode und einem Fehlerstring.
Beispiel:
{
"fault":{
"detail":{
"errorcode":"steps.extractvariables.SourceMessageNotAvailable"
},
"faultstring":"foo message is not available for ExtractVariable: ParseJsonResponse"
}
}
Diese Fehlermeldung lässt sich schnell zusammenfassen:
Der errorcode besteht aus einem Präfix und einem Fehlernamen: [prefix].[error_name]. Im obigen Beispiel ist „steps.extractvariables“ das Präfix und SourceMessageNotAvailable der Fehlername. Das Präfix gibt an, welche Art von Richtlinie den Fehler generiert hat. Im obigen Beispiel können Sie feststellen, dass eine Variablenextraktionsrichtlinie den Fehler generiert hat und der Fehlername SourceMessageNotAvailable lautet.
Der Fehlerstring enthält eine Fehlerbeschreibung. Der Fehlerstring enthält in der Regel Hinweise, die Ihnen helfen, ein bestimmtes Problem zu finden, das den Fehler verursacht hat, z. B. den Namen der Richtlinie, den Namen einer nicht aufgelösten Variable oder alles, was zum Fehler beigetragen hat. In der obigen Fehlermeldung ist „foo” beispielsweise der Name einer noch nicht aufgelösten Nachrichtenvariable, auf die in der Richtlinie verwiesen wird, und „ParseJsonResponse” der Name der Richtlinie, die den Fehler ausgelöst hat.
Für Richtlinienfehler spezifische Variablen
Beim Auslösen eines Richtlinienfehlers werden bestimmte variablenspezifische Ablaufvariablen mit Daten gefüllt. Diese Variablen sind bei der Fehlerbehandlung äußerst nützlich. Wie unter Fehler beheben erläutert, ist es üblich, die vom System generierten Richtlinienfehler zu beheben und eine nachfolgende Aktion auszuführen, z. B. zum Erstellen einer benutzerdefinierten Fehlerantwort. Aus Sicherheitsgründen möchten Sie möglicherweise verhindern, dass Clients die tatsächlichen Fehler und Statuscodes sehen, die Edge zurückgibt.
Die Variable fault.name
Wenn eine Richtlinie einen Fehler auslöst, setzt sie die Ablaufvariable fault.name auf den Teil error_name des Fehlercodes (wie im vorherigen Abschnitt beschrieben). Es ist sehr üblich, diese Variable auszuwerten, um Fehlerregeln bedingt auszuführen.
Das folgende Beispiel zeigt eine Fehlerregel, die den Wert von fault.name prüft:
<faultrule name="VariableOfNonMsgType"<>/faultrule><FaultRule name="Source Message Not Available Fault">
<Step>
<Name>AM-CustomErrorMessage</Name>
<Condition>(fault.name Matches "SourceMessageNotAvailable") </Condition>
</Step>
</FaultRule>
Denken Sie daran, dass die Variable fault.name immer auf den Fehlernamen gesetzt ist, wenn eine Richtlinie einen Fehler auslöst.
Die Variable [prefix].[policy_name].failed
Neben fault.name ist das Flag [prefix].[policy_name].failed, das bei der Ausführung einer Richtlinie auf „true“ oder „false“ gesetzt wird, eine weitere Variable, die Entwickler häufig prüfen. In Fehlerregeln sollten Sie prüfen, ob es true ist, d. h. ob ein Fehler aufgetreten ist. So erstellen Sie eine Bedingung, mit der das Flag [prefix].[policy_name].failed geprüft wird. Zum Prüfen dieser Variable müssen Sie zwei Dinge beachten:
- Der Name der Richtlinie, die Sie prüfen. Dies ist der Wert des Namensattributs der Richtlinie, nicht des Anzeigenamens. Dieses Attribut ist immer im XML-Code der Richtliniendefinition enthalten.
- Ein Präfix, das für den Typ der Richtlinie steht, die Sie prüfen möchten (Weiter unten wird erklärt, wie man das Präfix findet.)
Hier ist ein weiteres Beispiel für Fehlerregeln. Beachten Sie in der äußeren Bedingung, wie der Variablenname [prefix].[policy_name].failed erstellt wird. In diesem Fall lautet das Präfix extractvariables und der Richtlinienname ParseJsonResponse. In diesem Fall wird die Fehlerregel nur ausgeführt, wenn diese Variable wahr ist. Noch ein Tipp: Da Fehlerregeln mehrere Schritte enthalten können, ist es eine gute Möglichkeit, Fehlerregeln in Blöcken zu organisieren.
<faultrule name="VariableOfNonMsgType"></faultrule><FaultRule name="Extract Variable Faults">
<Step>
<Name>AM-CustomErrorMessage</Name>
<Condition>(fault.name Matches "SourceMessageNotAvailable") </Condition>
</Step>
<Condition>(extractvariables.ParseJsonResponse.failed = true) </Condition>
</FaultRule>
Informationen zu den Variablen error und message
Die Variable error ist nur im Fehlerablauf eines Proxys verfügbar. Sie können nützliche Informationen aus der Fehlervariablen abrufen, z. B. die Fehlermeldung, den Statuscode, die Begründungsphrase usw. Das Formatierungsmuster für die Fehlervariable sieht so aus:
error.[error_component] = [value]
Beispiel:
error.message = "request message is not available for ExtractVariable:
ParseJsonResponse"
und
error.status.code = "500"
Die Variable message ist auch im Fehlerablauf verfügbar und kann für ähnliche Zwecke wie die Variable error verwendet werden. Die Nachrichtenvariable ist besonders, weil sie kontextbezogen ist. In einem Anfrageablauf verhält es sich wie eine Anfragevariable. In einem Antwortablauf können damit Antwortwerte abgerufen/festgelegt werden. Weitere Informationen finden Sie unter Anwendungsfälle für Nachrichtenvariablen verwenden.
Informationen zu allen Edge-Variablen, einschließlich error und message, finden Sie unter Variablenreferenz.