Вы просматриваете документацию по Apigee Edge.
Перейдите к документации по Apigee X. Информация
В этой статье описана структура ошибок правил и типы переменных потока, которые задаются при возникновении ошибки правил. Эта информация необходима, если вы разрабатываете и реализуете обработку ошибок для своих прокси.
В этой статье предполагается, что вы знакомы с тем, как обрабатываются ошибки в Edge, и знаете, что такое правила обработки ошибок. Если вам нужна проверка, ознакомьтесь с разделом Обработка ошибок. Информация в этой статье также поможет вам ориентироваться в справочнике по ошибкам, связанным с нарушением правил.
Ответ об ошибке в связи с нарушением правил по умолчанию
Если правило вызывает ошибку, Edge немедленно переходит к обработке ошибки и генерирует сообщение об ошибке. Это сообщение, сгенерированное системой, представляет собой объект JSON, который содержит два элемента: errorcode и faultstring.
Пример:
{ "fault":{ "detail":{ "errorcode":"steps.extractvariables.SourceMessageNotAvailable" }, "faultstring":"foo message is not available for ExtractVariable: ParseJsonResponse" } }
Давайте разберем это сообщение об ошибке:
Код ошибки состоит из префикса и названия ошибки в следующем формате: [prefix].[error_name]. В примере выше "steps.extractvariables" – это префикс, а SourceMessageNotAvailable – название ошибки. Префикс указывает, какие правила были нарушены. В приведенном выше примере видно, что ошибку с названием SourceMessageNotAvailable сгенерировали правила Extract Variables.
В элементе faultstring содержится описание ошибки. Строка ошибки обычно содержит подсказки, которые помогают найти проблему, вызвавшую ошибку, например название правила, название неразрешенной переменной или что-то ещё, что привело к ошибке. Например, в приведенном выше сообщении об ошибке "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. Совет. Поскольку правила fault могут содержать несколько шагов, этот шаблон позволяет удобно организовать их в блоки.
<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_component] = [value]
Пример:
error.message = "request message is not available for ExtractVariable:
ParseJsonResponse"
и
error.status.code = "500"
Переменная message также доступна в потоке ошибок и может использоваться для тех же целей, что и переменная error. Переменная message является особенной, поскольку она контекстная. В потоке запроса он ведет себя как переменная запроса, а в потоке ответа его можно использовать для получения и установки значений ответа. Подробнее о примерах использования переменных в сообщениях…
Информацию обо всех переменных Edge, включая error и message, можно найти в справочнике по переменным.