Esta página se aplica a Apigee y Apigee Hybrid.
Consulta la documentación de
Apigee Edge.
En este tema se describe la estructura de los errores de política y los tipos de variables de flujo que se definen cuando se produce un error de política. Esta información es esencial si diseñas e implementas la gestión de errores de tus proxies.
En este tema se da por hecho que tienes una idea general de cómo funciona la gestión de errores en Apigee y que sabes qué son las reglas de error. Si necesitas una revisión, consulta Gestionar errores. La información que se incluye en este artículo también te ayudará a consultar y usar la referencia de errores de las políticas.
Acerca de la respuesta de error de política predeterminada
Cuando una política genera un error, Apigee entra inmediatamente en el flujo de errores y genera un mensaje de error. Este mensaje generado por el sistema es un objeto JSON que incluye dos elementos de información: un errorcode y un faultstring.
Por ejemplo:
{ "fault":{ "detail":{ "errorcode":"steps.extractvariables.SourceMessageNotAvailable" }, "faultstring":"mymessage message is not available for ExtractVariable: ParseJsonResponse" } }
Vamos a analizar rápidamente este mensaje de error:
El errorcode consta de un prefix y un error
name, como se indica a continuación: [prefix].[error_name]. En el ejemplo anterior,
"steps.extractvariables" es el prefijo y SourceMessageNotAvailable es
el nombre del error. El prefijo indica qué tipo de política ha generado el error. En el ejemplo anterior, puedes ver que una política ExtractVariables ha generado el error y que el nombre del error es SourceMessageNotAvailable.
El faultstring contiene una descripción del error. La cadena de error
suele incluir pistas que te ayudan a encontrar el problema específico que ha provocado el error, como el
nombre de la política, el nombre de una variable sin resolver o cualquier otro elemento que haya contribuido al error. Por ejemplo, en el mensaje de error anterior, mymessage es el nombre de una variable de mensaje no resuelta a la que se hace referencia en la política y ParseJsonResponse es el nombre de la política que ha activado el error.
Variables específicas de errores de políticas
Cuando se activa un error de política, se rellenan determinadas variables de flujo específicas del error. Estas variables son muy útiles para gestionar errores. Como se explica en Gestión de errores, es habitual detectar los errores de política generados por el sistema y realizar una acción posterior, como crear una respuesta de error personalizada. Por ejemplo, por motivos de seguridad, puede que quieras evitar que los clientes vean los errores y códigos de estado reales que devuelve Apigee.
Variable fault.name
Cuando una política genera un error, asigna a la variable de flujo fault.name la parte error_name del código de error (como se describe en la sección anterior). Es muy habitual evaluar esta variable para ejecutar reglas de error de forma condicional.
A continuación, se muestra un ejemplo de regla de error que comprueba el valor de fault.name:
<faultrule name="VariableOfNonMsgType"></faultrule><FaultRule name="Source Message Not Available Fault">
<Step>
<Name>AM-CustomErrorMessage</Name>
<Condition>(fault.name Matches "SourceMessageNotAvailable") </Condition>
</Step>
</FaultRule>Lo importante es recordar que, cuando una política activa un error, la variable fault.name
siempre se asigna al nombre del error.
La variable [prefix].[policy_name].failed
Además de fault.name, otra variable que suelen comprobar los desarrolladores es la marca [prefix].[policy_name].failed, que se asigna al valor true o false cuando se ejecuta una política. En las reglas de errores, debes comprobar cuándo es true, es decir, si se ha producido un error. A continuación, se indica cómo crear una condición que compruebe la marca [prefix].[policy_name].failed. Para comprobar correctamente esta variable, debes saber dos cosas:
- El nombre de la política que estás consultando. Este es el valor del atributo name de la política, no el nombre visible. Este atributo siempre se incluye en el XML de la definición de la política.
- Un prefijo específico del tipo de política que estés consultando. (Más abajo te explicamos cómo encontrar el prefijo).
Para ilustrarlo, aquí tienes otro ejemplo de regla de fallo. Fíjate en cómo se forma el nombre de la variable [prefix].[policy_name].failed en la condición externa. En este caso, el prefijo es
extractvariables y el nombre de la política es ParseJsonResponse. En este caso, la regla de fallo solo se ejecutará si esta variable es verdadera. Además, te damos un consejo: como las reglas de errores pueden contener varios pasos, este patrón es una buena forma de organizar las reglas de errores en bloques.
<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>
Acerca de las variables error y message
La variable error solo está disponible en el flujo de errores de un proxy. Puede obtener información útil de la variable error, como el mensaje de error, el código de estado, etc. El patrón de formato de la variable de error es el siguiente:
error.ERROR_COMPONENT = VALUE
Por ejemplo:
error.message = "request message is not available for ExtractVariable: ParseJsonResponse"
y
error.status.code = "500"
La variable message también está disponible en el flujo de errores y se puede usar con fines similares a la variable error. La variable de mensaje es especial porque es contextual. En un flujo de solicitud, se comporta como una variable de solicitud y, en un flujo de respuesta, se puede usar para obtener o definir valores de respuesta.
Consulte la referencia de variables de flujo para obtener información sobre todas las variables de Apigee, incluidas error y message.