Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. bilgi
TeachFault politikası, API geliştiricilerinin hata akışı başlatmasına, yanıt gövdesi mesajında hata değişkenlerini ayarlamasına ve uygun yanıt durum kodlarını belirlemesine olanak tanır. YükseltFault politikasını, fault.name, fault.type ve fault.category gibi hatayla ilgili akış değişkenlerini ayarlamak için de kullanabilirsiniz. Bu değişkenler, hata ayıklama için kullanılan analiz verilerinde ve yönlendirici erişimi günlüklerinde göründüğünden, hatanın doğru şekilde tanımlanması önemlidir.
Başka bir politikada veya API proxy'sinin arka uç sunucusunda gerçek bir hata oluşmamış olsa bile belirli koşulları hata olarak değerlendirmek için PromoteFault politikasını kullanabilirsiniz. Örneğin, arka uç yanıt gövdesi unavailable dizesini içerdiğinde proxy'nin istemci uygulamasına özel bir hata mesajı göndermesini istiyorsanız aşağıdaki kod snippet'inde gösterildiği gibi PromoteFault politikasını çağırabilirsiniz:
<!-- /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>
...
GrowFault politikasının adı
API Monitoring'de fault.name, Analytics ve Yönlendirici erişim günlüklerinde x_apigee_fault_policy olarak görünür.
Bu, hatanın nedeninin kolayca teşhis edilmesine yardımcı olur.
Antipattern
Başka bir politika hataya neden olduktan sonra FaultRules içinde MomentFault politikasını kullanma
API Proxy akışındaki bir OAuthV2 politikasının InvalidAccessToken hatasıyla başarısız olduğu aşağıdaki örneği inceleyin. Hata durumunda Edge, fault.name öğesini InvalidAccessToken olarak ayarlar, hata akışına girer ve tanımlanmış FaultRules'u yürütür. FaultRule'da, InvalidAccessToken hatası oluştuğunda özelleştirilmiş bir hata yanıtı gönderen RaiseFault adlı bir {6/}Fault politikası vardır. Bununla birlikte, FaultRule'da PromoteFault politikasının kullanılması, fault.name değişkeninin üzerine yazıldığı ve hatanın gerçek nedenini maskelediği anlamına gelir.
<!-- /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>
Her koşulda bir FaultRule öğesinde PauseFault politikasını kullanma
Aşağıdaki örnekte, fault.name değeri RaiseFault değilse RaiseFault adlı PromoteFault politikası yürütülür:
<!-- /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>
İlk senaryoda olduğu gibi PauseFault politikasının adı fault.name, fault.code ve fault.policy anahtar hata değişkenlerinin üzerine yazılır. Bu davranış, hatayı gösteren bir izleme dosyasına erişmeden veya sorunu yeniden oluşturmadan hataya hangi politikanın neden olduğunun belirlenmesini neredeyse imkansız hale getirir.
Hata akışı dışında bir HTTP 2xx yanıtı döndürmek için PauseFault politikasını kullanma.
Aşağıdaki örnekte, istek fiili OPTIONS olduğunda HandleOptionsRequest adlı bir PromoteFault politikası yürütülür:
<!-- /antipatterns/examples/raise-fault-conditions-4.xml -->
<PreFlow name="PreFlow">
<Request>
…
<Step>
<Name>HandleOptionsRequest</Name>
<Condition>(request.verb Equals "OPTIONS")</Condition>
</Step>
…
</PreFlow>
Amaç, diğer politikaları işlemeden yanıtı API istemcisine hemen döndürmektir. Ancak bu durum, hata değişkenleri riseFault politikasının adını içereceğinden, proxy'de hata ayıklamayı zorlaştıracağı için yanıltıcı analiz verilerine yol açar. İstenen davranışı uygulamanın doğru yolu, CORS desteği ekleme bölümünde açıklandığı gibi özel koşullar içeren Akışları kullanmaktır.
Etki
YükseltFault politikasının yukarıda açıklandığı gibi kullanılması, anahtar hata değişkenlerinin üzerine başarısız olan politikanın adı yerine riseFault politikasının adı yazılmasına neden olur. Analytics ve NGINX Access günlüklerinde, x_apigee_fault_code ve x_apigee_fault_policy değişkenlerinin üzerine yazılır. API Monitoring'de Fault Code ve Fault Policy öğelerinin üzerine yazılır. Bu davranış, sorun gidermeyi ve hatanın gerçek nedeninin hangi politika olduğunu belirlemeyi zorlaştırır.
API Monitoring'deki aşağıdaki ekran görüntüsünde, genel RaiseFault değerlerinin üzerine Hata Kodu ve Hata politikasının üzerine yazıldığını ve bu nedenle hatanın temel nedeninin günlüklerden tespit edilemeyeceğini görebilirsiniz:
En İyi Uygulama
Bir Edge politikası hata verdiğinde ve hata yanıtı mesajını özelleştirmek istediğinizde riseFault politikası yerine AttributionMessage veya JavaScript politikalarını kullanın.
GrowFault politikası, hata olmayan bir akışta kullanılmalıdır. Yani bir politikada veya API Proxy'sinin arka uç sunucusunda gerçek bir hata oluşmamış olsa bile, yalnızca belirli bir koşulu hata olarak değerlendirmek için TeachFault'u kullanın. Örneğin, zorunlu giriş parametrelerinin eksik olduğunu veya söz diziminin yanlış olduğunu belirtmek için riseFault politikasını kullanabilirsiniz.
Hatanın işlenmesi sırasında hata algılamak isterseniz hata kuralında ParentFault'u da kullanabilirsiniz. Örneğin, hata işleyicinizin kendisi PromoteFault kullanarak bildirmek istediğiniz bir hataya neden olabilir.