Antipattern: Uygun olmayan koşullar altında PromoteFault Politikası'nı kullanın

Apigee Edge belgelerini görüntülüyorsunuz.
. Git: Apigee X belgeleri. bilgi

PromoteFault politikası, API geliştiricilerinin hata akışı başlatmasını ve hata değişkenlerini yazmanızı ve uygun yanıt durum kodlarını belirlemenizi öneririz. Ayrıca, feed'inizdeki politika kullanarak hatayla ilgili akış değişkenlerini (ör. fault.name, fault.type, ve fault.category. Bu değişkenler analiz verilerinde ve Yönlendirici erişim günlüklerinde görülebilir. bu hatanın doğru şekilde tespit edilmesi önemlidir.

Gerçek bir hatada hata olarak değerlendirilse bile belirli durumları hata olarak değerlendirmek için veya API proxy'sinin arka uç sunucusunda gerçekleşmediğinden emin olun. Örneğin, arka uç yanıtı her zaman istemci uygulamasına özel bir hata mesajı göndermek için proxy gövde unavailable dizesini içeriyorsa RaiseFault politikasını aşağıdaki kod snippet'inde gösterilmiştir: 

<!-- /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>
...

REQUESTFault politikasının adı, içindeki fault.name olarak görünür API Monitoring'de, Analytics ve Yönlendirici erişim günlüklerinde x_apigee_fault_policy olarak gösterilir. Bu, hatanın nedenini kolayca teşhis etmeye yardımcı olur.

Antipattern

Başka bir politika zaten hata bildirdikten sonra FaultRules içinde RaiseFault politikasını kullanma

API Proxy akışındaki bir OAuthV2 politikasının InvalidAccessToken ile başarısız olduğu aşağıdaki örneği düşünün hatası. Başarısız olmanız durumunda Edge, fault.name değerini InvalidAccessToken olarak ayarlar ve ve tanımlanmış FaultRules'un uygulanmasıdır. FaultRule'da, Her InvalidAccessToken için özelleştirilmiş hata yanıtı gönderen RaiseFault hatası oluşur. Ancak bir FaultRule içinde RaiseFault politikasının kullanılması fault.name değişkeninin üzerine yazılır ve hatanın gerçek nedenini gizler. 

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

Bir FaultRule'de RaiseFault politikasını tüm koşullar altında kullanma

Aşağıdaki örnekte, RaiseFault adlı bir RaiseFault politikası fault.name RaiseFault değil: 

<!-- /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 fault.name, fault.code, ve fault.policy öğelerinin üzerine REQUESTFault politikasının adı yazılır. Bu davranış, İzlemeye erişmeden, hangi politikanın hataya gerçekten neden olduğunu belirlemek neredeyse imkansızdır hatasını gösteren veya sorunu yeniden oluşturan bir dosya oluşturun.

Hata akışının dışında bir HTTP 2xx yanıtı döndürmek için RaiseFault politikasının kullanılması.

Aşağıdaki örnekte, HandleOptionsRequest adlı bir RaiseFault politikası aşağıdaki durumlarda yürütülür: talep fiili OPTIONS şeklindedir: 

<!-- /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 API istemcisine yanıtı hemen döndürmektir. Ancak, hata değişkenlerinde REQUESTFault politikasının adı, proxy'de hata ayıklamayı zorlaştırır. Planlamanın doğru yolu Akışları özel koşullarla kullanmak, tercih edilen davranış olarak CORS desteği ekleme.

Etki

Yukarıda açıklandığı gibi PromoteFault politikasının kullanılması, Hata veren politikanın adı yerine RaiseFault politikasının adı. Analytics ve NGINX erişimi günlüklerinde x_apigee_fault_code ve x_apigee_fault_policy değişkenleri üzerine yazılır. API Monitoring'de, Fault Code ve Fault Policy üzerine yazılır. Bu davranış, sorun gidermeyi ve sorunları gidermeyi hatanın gerçek nedeninin hangi politika olduğunu belirleyebilirsiniz.

API Monitoring'deki aşağıdaki ekran görüntüsünde, Gördüğünüz gibi Hata Kodu ve Hata politikasının üzerine, genel RaiseFault değerleri nedeniyle hatanın kök nedeninin günlüklerden belirlenmesini imkansız hale getirir:

En İyi Uygulama

Bir Edge politikası hata verdiğinde ve hata yanıtı mesajını özelleştirmek isterseniz YieldFault politikası yerine Ataması veya JavaScript politikalarını kullanmanız gerekir.

REQUESTFault politikası, hata olmayan bir akışta kullanılmalıdır. Yani, yalnızca belirli bir bir politikada veya arka uç sunucusunda gerçek bir hata oluşmamış olsa bile bir hata olarak kabul edilir hakkında daha fazla bilgi edinin. Örneğin, RaiseFault politikasını kullanarak bu zorunlu girişin Parametreler eksik veya hatalı söz dizimi içeriyor.

Bir hata kuralının işlenmesi sırasında hata tespit etmek isterseniz YükseltFault işlevini kullanabilirsiniz. fark etmez. Örneğin, hata işleyicinizin kendisi RaiseFault yöntemini kullanarak bildirmek istediğiniz bir hataya neden olabilir.

Daha fazla bilgi