Что нужно знать об ошибках политики

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info

В этой теме описывается структура ошибок политики и типы переменных потока, которые устанавливаются при возникновении ошибки политики. Эта информация необходима при проектировании и реализации обработки ошибок для ваших прокси-серверов.

Предполагается, что вы в целом понимаете, как работает обработка ошибок в Edge, и знаете, что такое правила обработки ошибок. Если вам нужно повторить материал, см. раздел «Обработка ошибок» . Информация здесь также поможет вам ориентироваться и использовать справочник по ошибкам политик .

О сообщении об ошибке политики по умолчанию

Когда политика выдает ошибку, Edge немедленно переходит в процесс обработки ошибок и генерирует сообщение об ошибке. Это сгенерированное системой сообщение представляет собой объект JSON, содержащий два элемента информации: код ошибки и строку ошибки .

Например:

{  
   "fault":{  
      "detail":{  
         "errorcode":"steps.extractvariables.SourceMessageNotAvailable"
      },
      "faultstring":"foo message is not available for ExtractVariable: ParseJsonResponse"
   }
}

Давайте быстро разберем это сообщение об ошибке:

Код ошибки состоит из префикса и имени ошибки , следующим образом: [prefix].[error_name] . В приведенном выше примере " steps.extractvariables " — это префикс, а SourceMessageNotAvailable — имя ошибки. Префикс указывает, какой тип политики вызвал ошибку. В приведенном выше примере видно, что ошибка была вызвана политикой "Извлечение переменных", а имя ошибки — SourceMessageNotAvailable .

Строка ошибки содержит описание ошибки. Обычно она включает подсказки, помогающие найти конкретную причину ошибки, например, имя политики, имя неразрешенной переменной или что-либо еще, способствовавшее ошибке. Например, в приведенном выше сообщении об ошибке « foo » — это имя неразрешенной переменной сообщения, на которую ссылается политика, а « ParseJsonResponse » — это имя политики, вызвавшей ошибку.

Переменные, специфичные для ошибок политики.

При возникновении ошибки политики заполняются определенные переменные потока, специфичные для этой ошибки. Эти переменные чрезвычайно полезны при обработке сбоев. Как объясняется в разделе «Обработка сбоев» , распространенной практикой является перехват системных ошибок политики и выполнение последующих действий, таких как создание пользовательского ответа об ошибке. Например, по соображениям безопасности вы можете захотеть запретить клиентам видеть фактические ошибки и коды состояния, возвращаемые Edge.

Переменная fault.name

Когда политика выдает ошибку, она устанавливает переменную потока fault.name в значение части error_name кода ошибки (как описано в предыдущем разделе). Очень часто эту переменную оценивают для условного выполнения правил обработки ошибок.

Вот пример правила обработки ошибок, которое проверяет значение параметра 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>

Важно помнить, что когда политика вызывает ошибку, переменная fault.name всегда устанавливается в имя ошибки.

Переменная [prefix].[policy_name].failed

Помимо fault.name , разработчики часто проверяют еще одну переменную — флаг [prefix].[policy_name].failed , который устанавливается в значение true или false при выполнении политики. В правилах обработки ошибок необходимо проверять, когда он равен true , то есть, произошла ли ошибка. Вот как создать условное выражение, проверяющее флаг [prefix].[policy_name].failed . Для правильной проверки этой переменной необходимо знать две вещи:

• Название проверяемой политики. Это значение атрибута name политики, а не отображаемое имя. Этот атрибут всегда включается в XML-файл определения политики.
• Префикс , специфичный для типа проверяемого вами полиса. (Ниже мы объясним, как найти префикс.)

Для наглядности приведем еще один пример правила обработки ошибок. Обратите внимание, как во внешнем условии формируется имя переменной [prefix].[policy_name].failed . В данном случае префикс — extractvariables , а имя политики — ParseJsonResponse . В этом случае правило обработки ошибок будет выполнено только в том случае, если эта переменная имеет значение true. И вот вам совет: поскольку правила обработки ошибок могут содержать несколько шагов, этот шаблон — хороший способ организовать правила обработки ошибок в блоки.

<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>

О переменных error и message ошибке.

Переменная error доступна только в потоке ошибок прокси-сервера. Из переменной error можно получить полезную информацию, такую ​​как сообщение об ошибке, код состояния, фраза причины и так далее. Шаблон форматирования переменной error следующий:

error.[error_component] = [value]

Например:

error.message = "request message is not available for ExtractVariable: ParseJsonResponse "

и

error.status.code = "500"

Переменная message также доступна в потоке обработки ошибок и может использоваться для аналогичных целей, что и переменная error . Переменная сообщения является особенной, поскольку она контекстная. В потоке запроса она ведет себя как переменная запроса, а в потоке ответа ее можно использовать для получения/установки значений ответа. Для получения дополнительной информации см. раздел «Варианты использования переменных сообщений» .

Для получения информации обо всех переменных Edge, включая error и message , обратитесь к справочнику переменных .