Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация
В этом разделе описывается структура ошибок политики и типы переменных потока, которые задаются при возникновении ошибки политики. Эта информация важна, если вы разрабатываете и реализуете обработку ошибок для своих прокси.
В этом разделе предполагается, что вы имеете общее представление о том, как работает обработка ошибок в 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. В правилах ошибок вы захотите проверить, когда это истинно , то есть проверить, произошла ли ошибка. Вот как можно создать условие, проверяющее флаг [prefix].[policy_name].failed . Чтобы правильно проверить эту переменную, нужно знать две вещи:
- Название политики, которую вы проверяете. Это значение атрибута имени политики, а не отображаемого имени. Этот атрибут всегда включается в 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_component] = [value]
Например:
error.message = "request message is not available for ExtractVariable: ParseJsonResponse "
и
error.status.code = "500"
Переменная message также доступна в потоке ошибок и может использоваться для тех же целей, что и переменная error . Переменная сообщения является особенной, поскольку она контекстуальна. В потоке запросов он ведет себя как переменная запроса, а в потоке ответов его можно использовать для получения/установки значений ответа. Если вы хотите узнать больше, см. Варианты использования переменных сообщения .
Обратитесь к справочнику по переменным для получения информации обо всех переменных Edge, включая error и message .