Diese Seite gilt für Apigee und Apigee Hybrid.
Apigee Edge-Dokumentation aufrufen
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 von der Funktionsweise der Fehlerbehandlung in Apigee haben und die Fehlerregeln kennen. 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, tritt Apigee sofort in den Fehlerablauf und generiert eine Fehlermeldung. Diese vom System generierte Nachricht ist ein JSON-Objekt, das zwei Informationseinheiten enthält: errorcode und faultstring.
Beispiele:
{
"fault":{
"detail":{
"errorcode":"steps.extractvariables.SourceMessageNotAvailable"
},
"faultstring":"mymessage message is not available for ExtractVariable: ParseJsonResponse"
}
}
Diese Fehlermeldung lässt sich schnell zusammenfassen:
errorcode besteht aus einem prefix und einem error
name, nämlich [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 ExtractVariables-Richtlinie den Fehler generiert hat und der Fehlername SourceMessageNotAvailable lautet.
Der faultstring enthält eine Fehlerbeschreibung. Der Fehlerstring enthält in der Regel Hinweise, mit denen Sie das Problem ermitteln können, das den Fehler verursacht hat, z. B. den Namen der Richtlinie, den Namen einer noch nicht aufgelösten Variable oder, was sonst zum Fehler beigetragen hat. Beispiel: In der obigen Fehlermeldung ist mymessage der Name einer nicht aufgelösten Nachrichtenvariable, auf die in der Richtlinie verwiesen wird, und ParseJsonResponse ist 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 Apigee 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 error abrufen, z. B. die Fehlermeldung, den Statuscode und die Begründung. Das Formatierungsmuster für die Fehlervariable sieht so aus:
error.ERROR_COMPONENT = VALUE
Beispiele:
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 zu allen Apigee-Variablen, einschließlich error und message, finden Sie in der Referenz zu Ablaufvariablen.