Qué debes saber acerca de los errores de política

Estás viendo la documentación de Apigee X.
Consulta la documentación de Apigee Edge.

En este tema, se describe la estructura de errores de política y los tipos de variables de flujo que se configuran cuando se produce un error de política. Esta información es esencial si diseñas y también implementas el manejo de fallas para tus proxies.

En este tema, se da por hecho que tienes un conocimiento general de cómo funciona el manejo de fallas en Apigee y que sabes qué son las reglas de fallas. Si necesitas una revisión, consulta Soluciona errores. Esta información también te ayudará a navegar y usar la referencia de políticas.

Acerca de la respuesta de error de la política predeterminada

Cuando una política genera un error, Apigee ingresa de inmediato el flujo de error y genera un mensaje de error. Este mensaje generado por el sistema es un objeto JSON que incluye dos bits 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 deconstruir rápidamente este mensaje de error:

El errorcode consta de un prefix y un error name, de la siguiente manera: [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 generó el error. En el ejemplo anterior, puedes saber que una política de extracción generó el error y que el nombre del error es SourceMessageNotAvailable.

faultstring contiene una descripción del error. Por lo general, la string de la falla incluye pistas para ayudarte a encontrar el problema específico que causó el error, como el nombre de la política, el nombre de una variable sin resolver o lo que haya contribuido al error. Por ejemplo, en el mensaje de error anterior, mymessage es el nombre de una variable de mensaje sin resolver a la que se hace referencia en la política, y ParseJsonResponse es el nombre de la política que activó el.

Variables específicas para errores de la política

Cuando se activa un error de política, se propagan ciertas variables de flujo específicas para errores. Estas variables son muy útiles para controlar errores. Como se explica en la sección sobre cómo manejar los errores, se recomienda capturar los errores de políticas generados por el sistema y realizar una acción posterior, como crear una respuesta de error personalizada. Por ejemplo, por motivos de seguridad, es posible que quieras evitar que los clientes vean los códigos de estado y errores reales que muestra Apigee.

La variable fault.name

Cuando una política genera un error, establece la variable de flujo fault.name en la parte error_name del código de error (como se describe en la sección anterior). Es muy común evaluar esta variable para ejecutar reglas de error de forma condicional.

Esta es una regla de falla de ejemplo que prueba 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 que debes recordar es que, cuando una política activa un error, la variable fault.name siempre se establece en el nombre del error.

La variable [prefix].[policy_name].failed

Además de fault.name, otra variable que los desarrolladores suelen verificar es la marca [prefix].[policy_name].failed, que se configura como verdadera o falsa cuando se ejecuta una política. En las reglas de fallas, se recomienda verificar si es true, es decir, verificar si se produjo un error. A continuación, se muestra cómo construir un condicional que verifique la marca [prefix].[policy_name].failed. Para comprobar correctamente esta variable, debes saber dos cosas:

  • El nombre de la política que verificas. Este es el valor del atributo de nombre de la política, no el nombre visible. Este atributo siempre se incluye en el XML de la definición de política.
  • Un prefijo específico del tipo de política que verificas. (También explicaremos cómo encontrar el prefijo a continuación).

A modo de ejemplo, aquí hay otro ejemplo de regla de fallas. Observa en la condición externa cómo se forma el nombre de variable [prefix].[policy_name].failed. En este caso, el prefijo es extractvariables y el nombre de la política es ParseJsonResponse. En este caso, la regla de falla solo se ejecutará si esta variable es verdadera. Este es un consejo: como las reglas de fallas pueden contener varios pasos, este patrón es una buena manera de organizar las reglas de fallas 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 error de un proxy. Puedes obtener información útil de la variable error, como el mensaje de error, el código de estado, la frase del motivo, etcétera. El patrón de formato para 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 error y se puede usar para propósitos similares como 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 establecer valores de respuesta.

Consulta la referencia de variables de flujo para obtener información sobre todas las variables de Apigee, incluidas error y message.