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

Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. bilgi

RaiseFault politikası, API geliştiricilerin hata akışı başlatmasına, yanıt gövdesi mesajında hata değişkenleri ayarlamasına ve uygun yanıt durum kodları belirlemesine olanak tanır. Ayrıca, hata ile ilgili akış değişkenlerini (ör. fault.name, fault.type ve fault.category) ayarlamak için RaiseFault politikasını da kullanabilirsiniz. Bu değişkenler, hata ayıklama için kullanılan analiz verilerinde ve yönlendirici erişim 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 RaiseFault 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 RaiseFault 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>
...

RaiseFault politikasının adı, API İzleme'de fault.name, Analytics ve yönlendirici erişim günlüklerinde ise x_apigee_fault_policy olarak görünür. Bu sayede hatanın nedenini kolayca teşhis edebilirsiniz.

Antipattern

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

Aşağıdaki örneği ele alalım. Bu örnekte, API proxy akışındaki bir OAuthV2 politikası InvalidAccessToken hatasıyla başarısız oluyor. Başarısızlık durumunda Edge, fault.name değerini InvalidAccessToken olarak ayarlar, hata akışına girer ve tanımlanan tüm FaultRule'ları yürütür. FaultRule'da, RaiseFault adlı bir RaiseFault politikası vardır. Bu politika, InvalidAccessToken hatası oluştuğunda özelleştirilmiş bir hata yanıtı gönderir. Ancak bir FaultRule'da RaiseFault politikasının kullanılması, fault.name değişkeninin üzerine yazıldığı ve hatanın gerçek nedeninin gizlendiğ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>

RaiseFault politikasını tüm koşullarda bir FaultRule içinde kullanma

Aşağıdaki örnekte, RaiseFault adlı bir RaiseFault politikası, fault.name RaiseFault değilse 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, fault.name, fault.code ve fault.policy temel hata değişkenlerinin üzerine RaiseFault politikasının adı yazılır. Bu davranış, hatayı gösteren bir izleme dosyasına erişmeden veya sorunu yeniden üretmeden hataya hangi politikanın neden olduğunu belirlemeyi neredeyse imkansız hale getirir.

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

Aşağıdaki örnekte, istek fiili OPTIONS olduğunda HandleOptionsRequest adlı bir RaiseFault 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şlemeksizin yanıtı API istemcisine hemen döndürmektir. Ancak bu durum, hata değişkenleri RaiseFault politikasının adını içereceğinden yanıltıcı analiz verilerine yol açar ve proxy'nin hata ayıklamasını zorlaştırır. İstenen davranışı uygulamanın doğru yolu, CORS desteği ekleme bölümünde açıklandığı gibi özel koşullara sahip akışları kullanmaktır.

Etki

Yukarıda açıklandığı gibi RaiseFault politikasının kullanılması, anahtar hata değişkenlerinin başarısız olan politikanın adı yerine RaiseFault politikasının adıyla üzerine yazılmasına neden olur. Analytics ve NGINX erişim günlüklerinde x_apigee_fault_code ve x_apigee_fault_policy değişkenlerinin üzerine yazılır. API İzleme'de Fault Code ve Fault Policy değerlerinin üzerine yazılır. Bu davranış, sorun gidermeyi ve hatanın gerçek nedeninin hangi politika olduğunu belirlemeyi zorlaştırır.

API İzleme'den alınan aşağıdaki ekran görüntüsünde, Hata Kodu ve Hata Politikası'nın genel RaiseFault değerleriyle üzerine yazıldığını görebilirsiniz. Bu durum, hatanın temel 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 istediğinizde RaiseFault politikası yerine AssignMessage veya JavaScript politikalarını kullanın.

RaiseFault politikası, hata içermeyen bir akışta kullanılmalıdır. Yani, API proxy'sinin bir politikasında veya arka uç sunucusunda gerçek bir hata oluşmamış olsa bile yalnızca belirli bir durumu hata olarak değerlendirmek için RaiseFault'u kullanın. Örneğin, zorunlu giriş parametrelerinin eksik olduğunu veya yanlış söz dizimine sahip olduğunu belirtmek için RaiseFault politikasını kullanabilirsiniz.

Bir hatanın işlenmesi sırasında hatayı tespit etmek istiyorsanız hata kuralında RaiseFault'u da kullanabilirsiniz. Örneğin, hata işleyicinizin kendisi, RaiseFault kullanarak sinyal vermek istediğiniz bir hataya neden olabilir.

Daha fazla bilgi