Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация
Политика RaiseFault позволяет разработчикам API инициировать поток ошибок, устанавливать переменные ошибок в теле сообщения ответа и устанавливать соответствующие коды состояния ответа. Вы также можете использовать политику RaiseFault для установки переменных потока, относящихся к ошибке, таких как fault.name , fault.type и fault.category . Поскольку эти переменные видны в аналитических данных и журналах доступа к маршрутизатору, используемых для отладки, важно точно определить неисправность.
Вы можете использовать политику RaiseFault для обработки определенных условий как ошибок, даже если фактическая ошибка не произошла в другой политике или на внутреннем сервере прокси-сервера API. Например, если вы хотите, чтобы прокси-сервер отправлял пользовательское сообщение об ошибке клиентскому приложению всякий раз, когда тело ответа серверной части содержит строку unavailable , вы можете вызвать политику RaiseFault, как показано в фрагменте кода ниже:
<!-- /antipatterns/examples/raise-fault-conditions-1.xml -->
<TargetEndpoint name="default">
...
<Response>
<Step>
<Name>RF-Service-Unavailable</Name>
<Condition>(message.content Like "*unavailable*")</Condition>
</Step>
</Response>
...
Имя политики RaiseFault отображается как fault.name в мониторинге API и как x_apigee_fault_policy в журналах аналитики и доступа к маршрутизатору. Это помогает легко диагностировать причину ошибки.
Антипаттерн
Использование политики RaiseFault в FaultRules после того, как другая политика уже выдала ошибку.
Рассмотрим приведенный ниже пример, в котором политика OAuthV2 в потоке прокси-сервера API завершилась с ошибкой InvalidAccessToken . В случае сбоя Edge установит fault.name как InvalidAccessToken , войдет в поток ошибок и выполнит все определенные FaultRules. В FaultRule есть политика RaiseFault с именем RaiseFault , которая отправляет настроенный ответ об ошибке всякий раз, когда возникает ошибка InvalidAccessToken . Однако использование политики RaiseFault в FaultRule означает, что переменная fault.name перезаписывается и маскирует истинную причину сбоя.
<!-- /antipatterns/examples/raise-fault-conditions-2.xml -->
<FaultRules>
<FaultRule name="generic_raisefault">
<Step>
<Name>RaiseFault</Name>
<Condition>(fault.name equals "invalid_access_token") or (fault.name equals "InvalidAccessToken")</Condition>
</Step>
</FaultRule>
</FaultRules>
Использование политики RaiseFault в FaultRule при любых условиях
В приведенном ниже примере политика RaiseFault с именем RaiseFault выполняется, если fault.name не RaiseFault :
<!-- /antipatterns/examples/raise-fault-conditions-3.xml -->
<FaultRules>
<FaultRule name="fault_rule">
....
<Step>
<Name>RaiseFault</Name>
<Condition>!(fault.name equals "RaiseFault")</Condition>
</Step>
</FaultRule>
</FaultRules>
Как и в первом сценарии, ключевые переменные ошибки fault.name , fault.code и fault.policy перезаписываются именем политики RaiseFault. Такое поведение делает практически невозможным определить, какая политика на самом деле вызвала сбой, без доступа к файлу трассировки, показывающему сбой или воспроизводящему проблему.
Использование политики RaiseFault для возврата ответа HTTP 2xx вне потока ошибок.
В приведенном ниже примере политика RaiseFault с именем HandleOptionsRequest выполняется, когда глагол запроса имеет значение OPTIONS :
<!-- /antipatterns/examples/raise-fault-conditions-4.xml -->
<PreFlow name="PreFlow">
<Request>
…
<Step>
<Name>HandleOptionsRequest</Name>
<Condition>(request.verb Equals "OPTIONS")</Condition>
</Step>
…
</PreFlow>
Цель состоит в том, чтобы немедленно вернуть ответ клиенту API без обработки других политик. Однако это приведет к получению ошибочных аналитических данных, поскольку переменные ошибки будут содержать имя политики RaiseFault, что усложнит отладку прокси-сервера. Правильный способ реализовать желаемое поведение — использовать Flows со специальными условиями, как описано в разделе Добавление поддержки CORS .
Влияние
Использование политики RaiseFault, как описано выше, приводит к перезаписи ключевых переменных ошибки именем политики RaiseFault вместо имени сбойной политики. В журналах Analytics и NGINX Access x_apigee_fault_code и x_apigee_fault_policy переменные перезаписываются. При мониторинге API Fault Code и Fault Policy перезаписываются. Такое поведение затрудняет устранение неполадок и определение того, какая политика является истинной причиной сбоя.
На скриншоте ниже из API Monitoring вы можете видеть, что код ошибки и политика ошибки были перезаписаны на общие значения RaiseFault , что делает невозможным определение основной причины сбоя по журналам:
Лучшая практика
Если политика Edge выдает ошибку и вы хотите настроить ответное сообщение об ошибке, используйте политики AssignMessage или JavaScript вместо политики RaiseFault.
Политику RaiseFault следует использовать в потоке без ошибок. То есть используйте RaiseFault только для обработки определенного состояния как ошибки, даже если фактическая ошибка не произошла в политике или на внутреннем сервере прокси-сервера API. Например, вы можете использовать политику RaiseFault, чтобы сигнализировать об отсутствии обязательных входных параметров или их неправильном синтаксисе.
Вы также можете использовать RaiseFault в правиле сбоя, если хотите обнаружить ошибку во время обработки сбоя. Например, сам обработчик ошибок может вызвать ошибку, о которой вы хотите сообщить с помощью RaiseFault.