Hataları işleme

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

API proxy'leri uygulamalardan gelen isteklere hizmet verirken birçok hata koşulu ortaya çıkabilir. Örneğin, API proxy'leri arka uç hizmetleriyle iletişim kurarken ağ sorunlarıyla karşılaşabilir. uygulamalar, süresi dolmuş kimlik bilgileri sunabilir, istek mesajları yanlış biçimlendirilmiş olabilir ve bu nedenle beklemeye gerek yoktur.

Bir istemci uygulaması API proxy'sini çağırdıktan sonra hata oluşursa teslim edilir. Varsayılan olarak istemci, genellikle ayrıntı içermeyen şifreli bir hata iletisi alır veya rehberlik eder. Ancak varsayılan hata mesajlarını daha faydalı özel mesajlarla değiştirmek istiyorsanız ve bunları ek HTTP üstbilgileri gibi öğelerle zenginleştirseniz bile, özel hata URL'si bazı ipuçları vereceğim.

Özel hata işleme ayrıca, bir hata bildiriminde bulunduğunuzda mesaj kaydı gibi işlevler hatası oluşur.

API proxy'lerinizde özel hata işleme uygulamadan bahsetmeden önce, hataların nasıl oluştuğunu ve API proxy'lerinin bunlara nasıl tepki verdiğini anlayın.

Videolar

Arıza işleme hakkında daha fazla bilgi edinmek için aşağıdaki videoları izleyin.

Hatalar nasıl oluşur?

İlk olarak hataların nasıl oluştuğunu ele alacağız. Hataların nasıl ortaya çıktığını bilmek plan yapmanıza yardımcı olur kullanmanızı öneririz.

Otomatik hatalar

API proxy'si aşağıdaki durumlarda otomatik olarak hata bildirir:

• Bir politika hata verir. Örneğin, bir API çağrısı süresi dolmuş bir anahtar gönderirse VerifyAPIKey politikası otomatik olarak hata verir; veya API çağrılarının Kota politikası veya SpikeArrest politikası belirli bir sınırı aştığında hata verir. (Şu belge için Politika hatası referansı: (politikaların atabileceği hata türleri).
• API proxy mesaj akışında yönlendirme hatası gibi bir sorun var.
• Protokol düzeyindeki hatalardan kaynaklanan HTTP hatası, TLS/SSL gibi bir arka uç hatası var veya kullanılamayan bir hedef hizmet olabilir.
• Bellek dışı istisna gibi sistem düzeyinde bir hata oluştuğunda.

Bu hatalar hakkında daha fazla bilgi için bu konudaki Hata sınıflandırması bölümüne bakın.

Özel hatalar

Otomatik bir hatanın olmadığı durumlarda özel bir hata mesajı vermek isteyebilirsiniz; şunun için: Örneğin, yanıt "kullanılamıyor" kelimesini içeriyorsa veya HTTP durum kodu daha büyükse daha yüksek olduğunu tespit ettik. Bunu, uygun bir şekilde göstermeniz gerekir.

API proxy akışına diğer tüm politikalarda olduğu gibi RaiseFault politikası ekleyebilirsiniz. İçinde aşağıdaki proxy yapılandırması örneğine göre Raise-Fault-1 politikası hedef noktası yanıtıdır. "Kullanılamıyor" kelimesi hedefin yanıtta mevcut olması hizmetini geri yükleyin.

<TargetEndpoint name="default">
...
  <Response>
    <Step>
      <Name>Raise-Fault-1</Name>
      <Condition>(message.content Like "*unavailable*")</Condition>
    </Step>
  </Response>

Bu, size özel hatalar gönderebileceğinizi göstermek içindir. Sıradaki videoda, FaultRules ve RaiseFault politikasındaki RaiseFault politikası bölümüne ekleyin.

Daha fazla örnek için Apigee Topluluk Forumları'nda şu yayınlara göz atın:

• REQUESTFault'ta JavaScript değişkenlerine referans verme

Hata oluştuğunda API proxy'leri ne yapar?

Bir proxy hata verdiğinde ne olur?

Proxy ardışık düzeninden çıkın

Bir API proxy'si hatayla karşılaştığında, nasıl gerçekleştiğinden bağımsız olarak normal akış ardışık düzeninden çıkar ve ve istemci uygulamasına bir hata mesajı döndürüyor. API proxy'si, hata durumuna geçtikten sonra, işlemeyi normal akış ardışık düzenine geri döndüremez.

Örneğin, bir API proxy'sinin ProxyEndpoint'te aşağıdaki sırada olduğunu varsayın: istek:

1. API Anahtarını Doğrula
2. Kota
3. JSON'den XML'ye

API anahtarı doğrulanırken hata oluşursa API proxy'si hata durumuna geçer. İlgili içeriği oluşturmak için kullanılan Kota ve JSON - XML politikaları yürütülmez, proxy, TargetEndpoint'e ilerlemez. ve istemci uygulamasına bir hata mesajı döndürülür.

Hata Kurallarını Kontrol Et

Hata durumunda, API proxy'leri aynı zamanda İstemci uygulamasına varsayılan hata mesajı döndürmeden önce API proxy'si yapılandırması:

1. Şu mantığı içeren bir <FaultRules> bölümü: belirlediğiniz belirli koşullara dayalı olarak özel hata mesajlarını (ve diğer politikaları) tetiklemek tanımlar.
2. Varsayılan bir tetikleyiciyi tetikleyen <DefaultFaultRule> bölümü hata mesajı görebilirsiniz:
   • Tanımlanmış <FaultRules> yok.
   • Yürütülen mevcut <FaultRules> yok.
   • <AlwaysEnforce> öğesi doğru olarak ayarlanmış.

Özünde, API proxy'si size özel bir hata mesajı döndürme ve diğer mantığı tetiklemek için kullanır. Proxy bu bölümlerin ikisini de bulamıyorsa veya bu bölümler mevcut ancak özel tetiklendiğinde proxy, Edge tarafından oluşturulan kendi varsayılan mesajını gönderir.

Basit hata giderme örneği

API proxy'sine yapılan bir çağrının gerekli bir API'yi içermediği basit bir örnekle başlayalım tuşuna basın. Varsayılan olarak, istemci uygulamasına döndürülen yanıt aşağıdaki gibidir:

HTTP/1.1 401 Unauthorized
Date: Wed, 20 Jul 2016 19:19:32 GMT
Content-Type: application/json
Content-Length: 150
Connection: keep-alive
Server: Apigee Router

* Connection #0 to host myorg-test.apigee.net left intact
{"fault":{"faultstring":"Failed to resolve API Key variable request.queryparam.apikey","detail":{"errorcode":"steps.oauth.v2.FailedToResolveAPIKey"}}}

API kullanıcılarınız hata mesajını anlayabilir, ancak anlamayabilir. Ayrıca birçok varsayılan ve anlaşılması daha zordur.

Bir API geliştiricisi olarak bu mesajı, Google'a reklam verecek herkesin ihtiyaçlarını karşılayacak şekilde değiştirmek size ister iOS uygulaması geliştiricisi ister dahili test amaçlı olsun, sonuçta hata mesajını alacak grubu olmalıdır.

Aşağıda, bu hatayı işlemek için özel bir hata mesajını nasıl oluşturacağınıza dair temel bir örnek verilmiştir. Bu 1) özel mesajı tanımlayan bir politika ve 2) politikayı yürüten bir FaultRule kuralı gerektirir proxy hata durumuna geçtiğinden emin olun.

1. Politika oluştur özel mesajı tanımlayan

Öncelikle özel hata mesajını tanımlayan bir politika oluşturun. Her tür politikayı kullanabilirsiniz, Örneğin, bir yük ve isteğe bağlı HTTP üstbilgileri (ör. durum kodu ve neden ifadesi kullanılır. Mesaj Ata özelliği bunun için idealdir. Mesaj yükünü kontrol etmenizi sağlar, farklı HTTP durum kodu oluşturabilir, farklı bir HTTP nedeni ifadesi belirleyebilir ve HTTP üstbilgileri ekleyin.

Politikayı API proxy'sindeki herhangi bir akışa eklemeyin. URL'nin Google Cloud'da proxy paketi kullanabilirsiniz. Bunu yönetim arayüzü proxy düzenleyicisinde yapmak için, Geliştirme sekmesine gidin ve Gezinme bölmesini ve Politikalar çubuğundaki + simgesini tıklayın.

Bu sayede, API proxy'sindeki bir akışa eklemeden politika oluşturabilirsiniz. Politika herhangi bir akışa bağlı olmayan "ayrılmış" ifadesiyle işaretlenir simgesini şekilde gösterilen API anahtar mesaj politikasının yanında gösterilir.

Aşağıda, aşağıdaki özelliklere sahip bir AssignmentMessage politikası gösterilmektedir:

• Bir JSON mesajı döndürür.
• Bir HTTP durum kodu (911, var olmayan bariz bir durum kodudur) ayarlar. bunu da belirtebilirsiniz). Durum kodu, HTTP üstbilgisinde görünür.
• Bir HTTP neden ifadesi ayarlar (bunun için varsayılan "Yetkilendirilmemiş" neden ifadesinin yerine kullanılır) eksik API anahtarı hatası). HTTP'deki durum kodunun yanında neden ifadesi görünür kullanabilirsiniz.
• invalidKey adlı yeni bir HTTP üstbilgisi oluşturur ve bu üst bilgiyi doldurur.

<AssignMessage async="false" continueOnError="false" enabled="true" name="invalid-key-message">
    <DisplayName>Invalid key message</DisplayName>
    <Set>
        <Payload contentType="application/json">{"Citizen":"Where's your API key? I don't see it as a query parameter"}</Payload>
        <StatusCode>911</StatusCode>
        <ReasonPhrase>Rejected by API Key Emergency Services</ReasonPhrase>
    </Set>
    <Add>
        <Headers>
            <Header name="invalidKey">Invalid API key! Call the cops!</Header>
        </Headers>
    </Add>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

Bu politika yürütüldüğünde istemci uygulamasının yanıtı aşağıdaki gibi görünür. Bunu daha önce gösterilen varsayılan yanıtla karşılaştırın.

HTTP/1.1 911 Rejected by API Key Emergency Services
Date: Wed, 20 Jul 2016 18:42:36 GMT
Content-Type: application/json
Content-Length: 35
Connection: keep-alive
invalidKey: Invalid API key! Call the cops!
Server: Apigee Router

* Connection #0 to host myorg-test.apigee.net left intact
{"Citizen":"Where's your API key? I don't see it as a query parameter."}

Evet, biraz tuhaf ama yine de neler yapılabileceğini gösteriyor. En azından artık geliştirici, Mesaj alındığında, sorgu parametresi olarak API anahtarı eklemeyi unuttuğunu bilir.

Peki bu politika nasıl uygulanır? Sonraki bölümde gösterilir.

2. Şunu oluşturun: <FaultRule> politika tetikleyecek

Şu makalenin <ProxyEndpoint> veya <TargetEndpoint> bölümlerinde: proxy yapılandırmasından birini içeren <FaultRules> veya daha fazla ayrı <FaultRule> bölümü. Her FaultRule farklı bir hatası alırsınız. Bu basit örnekte, size hangi hatanın geçerli olduğunu göstermek için size yardımcı olur.

Ayrıca, özel bir genel hata sağlamak için <DefaultFaultRule> eklemeniz gerekir mesajıyla karşılaşırsınız.

Örnek

<ProxyEndpoint name="default">
...
    <FaultRules>
       <FaultRule name="invalid_key_rule">
            <Step>
                <Name>invalid-key-message</Name>
            </Step>
            <Condition>(fault.name = "FailedToResolveAPIKey")</Condition>
        </FaultRule>
    </FaultRules>
    <DefaultFaultRule name="default-fault">
        <Step>
            <Name>Default-message</Name>
        </Step>
    </DefaultFaultRule>

Önemli noktalar:

• FaultRules, ProxyEndpoint'te tanımlanır. Bu önemlidir. YouTube'da Daha sonra ProxyEndpoint ve TargetEndpoint'teki FaultRules karşılaştırması.
• <Name> - Yürütülecek politikanın adı. Ad aşağıdaki örnekteki gibi üst öğedeki politikanın name özelliğinden gelir: daha önce değineceğiz.

• <Condition> - Edge, durumu değerlendirir ve Politikayı yalnızca koşul doğruysa yürütür. Aynı hataya neden olan birden fazla olarak değerlendirdiğinizde, Edge doğru olan ilk öneriyi yürütür. (Önemli: açısından değerlendirildiğinden, yukarıdan aşağıya veya aşağıdan yukarıya doğru farklılık göstermekle Hedef Uç Noktası ve ProxyEndpoint, Birden Çok FaultKurallar ve yürütme mantığı bölümüne bakın.) Bir koşul eklemezseniz FaultRule otomatik olarak doğrudur. Ancak bu, en iyi uygulamalardan biri değildir. Her FaultRule kendine ait olmalıdır koşul.

• <DefaultFaultRule> - Özel bir FaultRule kuralı yoksa <DefaultFaultRule> yürütüldüğünde daha genel bir özel bir ileti gönderir. CEVAP <DefaultFaultRule> için de <Condition> olabilir, ancak çoğu durumda bunlara dahil olmazsınız çünkü son işlem olarak ne olursa olsun tatil köyü.

  DefaultFaultRule genellikle beklenmeyen bir hata oluştu. Örneğin, teknik destek. Bu varsayılan yanıt iki amaca hizmet eder: geliştirici dostu bilgiler sunarken arka uç URL'lerini veya diğer bilgileri ve sistemin güvenliğini tehlikeye atmak için kullanılabilir.

Çoklu Hata Kuralı ve yürütme mantığı

Basit hata giderme örneği bölümünde basit bir örnek kullandık durumunu değerlendirebilirsiniz. Gerçek bir API projesinde, olası tüm hatalarla ikisinde de birden çok FaultRules ve bir DefaultFaultRule <ProxyEndpoint> ve <TargetEndpoint>. Ama sonuçta API proxy'si hata durumuna geçtiğinde yalnızca bir FaultRule yürütülür.

Bu bölümde, Edge'in FaultRules'u işlemede kullandığı mantık, bir nasıl "inner" olarak çalıştırılacağına ilişkin tek bir FaultRule Adım koşulları, FaultRule değeri şu olduğunda işlenir: tetiklendi. Bu bölümde ayrıca, <ProxyEndpoint> - <TargetEndpoint> karşılaştırması ve FaultRules ve RaiseFault politikası arasındaki ilişki.

FaultRules'un yürütülmesi

Özetle, bir API proxy'si hata durumuna geçtiğinde Edge'in kullandığı mantığı aşağıda bulabilirsiniz. Lütfen ProxyEndpoint Değerlendirmesi'ndeki ve TargetEndpoint.

1. Edge, hatanın oluştuğu yer:
   • ProxyEndpoint: Kenar alt ile başlar <FaultRule> bölümüne yüklenir ve doğru şekilde çalışarak her bir <FaultRule> için <Condition> ("dış") durum, "iç" değil <Step> koşulları).
   • TargetEndpoint (Hedef Uç Nokta) - Kenar, üst <FaultRule> hatasına neden olur ve doğru şekilde her bir <FaultRule> için <Condition> ("dış") durum, "iç" değil <Step> koşulları).
2. Koşulu doğru olan ilk FaultRule'ı yürütür. Bir FaultRule koşul yok. Varsayılan değer "doğru"dur.
   • Bir FaultRule yürütüldüğünde, FaultRule içindeki tüm Adımlar yukarıdan aşağıya doğru inceleyebilirsiniz. Koşul içermeyen adımlar otomatik olarak yürütülür (politikalar yürütüldüğünden) ve <Condition> "true" olarak değerlendirilir yürütülür ("yanlış" olarak değerlendirilen koşullar yürütülmüştür).

   • Bir FaultRule yürütülürse ancak FaultRule'daki hiçbir Adım yürütülmezse (çünkü koşulları "false" olarak değerlendirilirse), Edge tarafından oluşturulan varsayılan hata mesajı istemci uygulaması. <DefaultFaultRule> yürütülmez, çünkü Edge bir FaultRule'u zaten yürütmüştür.

3. FaultRule yürütülmezse Edge, <DefaultFaultRule> komutunu çalıştırır. devam eder.

Aşağıda, satır içi yorumlar içeren örnekler verilmiştir.

ProxyEndpoint yürütmesi

ProxyEndpoint FaultRules'un değerlendirilmesi aşağıdan yukarıya doğru olduğundan okumaya en son Aşağıdaki örnekte FaultRule kodunu ekleyin ve yukarı doğru ilerleyin. Son olarak DefaultFaultRule'u inceleyin.

<ProxyEndpoint name="default">
...
    <FaultRules>
<!-- 3. This FaultRule is automatically TRUE, because there's no "outer" 
     condition. But because the FaultRule just below this got
     executed (bottom-to-top evaluation in a ProxyEndpoint), Edge
     doesn't even evaluate this FaultRule.
     Note that it's not a best practice to have a FaultRule without 
     an outer condition, which automatically makes the FaultRule true. -->
        <FaultRule name="random-error-message">
            <Step>
                <Name>Random-fault</Name>
            </Step>
        </FaultRule>
<!-- 2. Let's say this fault is TRUE. The Quota policy threw a QuotaViolation
     error. This is the first FaultRule to be TRUE, so it's executed. 
     Now the Steps are evaluated, and for the ones whose conditions
     evaluate to TRUE, their policies are executed. Steps without
     conditions are automatically true. -->
<FaultRule name="over_quota">
            <Step>
                <Name>developer-over-quota-fault</Name>
                <Condition>(ratelimit.developer-quota-policy.exceed.count GreaterThan "0")</Condition>
            </Step>
            <Step>
                <Name>global-over-quota-fault</Name>
                <Condition>(ratelimit.global-quota-policy.exceed.count GreaterThan "0")</Condition>
            </Step>
            <Step>
                <Name>log-error-message</Name>
            </Step>
            <Condition>(fault.name = "QuotaViolation")</Condition>
        </FaultRule>
<!-- 1. Because this is the ProxyEndpoint, Edge looks at this FaultRule
     first. But let's say this FaultRule is FALSE. A policy did not 
     throw a FailedToResolveAPIKey error. Edge moves UP to check
     the next FaultRule. -->
        <FaultRule name="invalid_key_rule">
            <Step>
                <Name>invalid-key-message</Name>
            </Step>
            <Condition>(fault.name = "FailedToResolveAPIKey")</Condition>
        </FaultRule>
    </FaultRules>

<!-- If no <FaultRule> is executed, the <DefaultFaultRule> is executed. 
     If a FaultRule is executed, but none of its Steps are executed,
     The DefaultFaultRule is not executed (because Edge has already
     executed its one FaultRule). -->
    <DefaultFaultRule name="default-fault">
        <Step>
            <Name>Default-message</Name>
        </Step>
    </DefaultFaultRule>

Hedef uç nokta yürütme

TargetEndpoint FaultRules'un değerlendirilmesi yukarıdan aşağıya doğru olduğundan okumaya ilk Aşağıdaki örnekte FaultRule kodunu ekleyin ve aşağı doğru ilerleyin. Son olarak DefaultFaultRule'u inceleyin.

<TargetEndpoint name="default">
...
    <FaultRules>
<!-- 1. Because this is the TargetEndpoint, Edge looks at this FaultRule
     first. Let's say this FaultRule is FALSE. 
     A policy did not throw a FailedToResolveAPIKey error. 
     Edge moves down to the next FaultRule. -->
        <FaultRule name="invalid_key_rule">
            <Step>
                <Name>invalid-key-message</Name>
            </Step>
            <Condition>(fault.name = "FailedToResolveAPIKey")</Condition>
        </FaultRule>
<!-- 2. Let's say this fault is TRUE. The Quota policy threw a QuotaViolation
     error. This is the first FaultRule to be TRUE, so it's executed. 
     Now the Steps are evaluated, and for the ones whose conditions
     evaluate to TRUE, their policies are executed. Steps without
     conditions are automatically true. -->
        <FaultRule name="over_quota">
            <Step>
                <Name>developer-over-quota-fault</Name>
                <Condition>(ratelimit.developer-quota-policy.exceed.count GreaterThan "0")</Condition>
            </Step>
            <Step>
                <Name>global-over-quota-fault</Name>
                <Condition>(ratelimit.global-quota-policy.exceed.count GreaterThan "0")</Condition>
            </Step>
            <Step>
                <Name>log-error-message</Name>
            </Step>
            <Condition>(fault.name = "QuotaViolation")</Condition>
        </FaultRule>
<!-- 3. This FaultRule is automatically TRUE, because there's no "outer" 
     condition. But because the FaultRule just above this got
     executed (top-to-bottom evaluation in a TargetEndpoint), Edge
     doesn't even evaluate this FaultRule.
     Note that it's not a best practice to have a FaultRule without 
     an outer condition, which automatically makes the FaultRule true. -->
        <FaultRule name="random-error-message">
            <Step>
                <Name>Random-fault</Name>
            </Step>
        </FaultRule>
    </FaultRules>

<!-- If no <FaultRule> is executed, the <DefaultFaultRule> is executed. 
     If a FaultRule is executed, but none of its Steps are executed,
     The DefaultFaultRule is not executed (because Edge has already
     executed its one FaultRule). -->
    <DefaultFaultRule name="default-fault">
        <Step>
            <Name>Default-message</Name>
        </Step>
    </DefaultFaultRule>

Hata kuralı sırası

Önceki örnekte görebileceğiniz gibi, FaultRules'u belirlediğiniz sıra veya hatanın ProxyEndpoint öğesinde mi yoksa TargetEndpoint.

Örneğin:

Dahil edilecek politikalar

FaultRule'daki tüm politikaları Adımlar bölümüne ekleyerek yürütebilirsiniz. Örneğin, şunları yapabilirsiniz: istemci uygulamasına verilen yanıtı biçimlendirmek için bir AssignmentMessage politikası yürütür ve günlüğe bir mesaj kaydeder MessageLogging politikasıyla uyumlu hale getirin. Politikalar belirlediğiniz sırayla yürütülür (XML'de yukarıdan aşağıya).

Hata kuralları YALNIZCA bir hata durumunda tetiklenir (continueOnError hakkında)

Başlık kendimizi tekrarlıyor gibi görünebilir ama yapmamız gereken belirli bir nüans var. API proxy'sinin hata durumu girmesine neden olan bir proxy hatasından haberdar olması veya bunun yerine bir hata durumu girmeyin: continueOnError politikası.

Özetlemek gerekirse: Bir API proxy'si, <FaultRules> ve yalnızca proxy bir hata durumu girdiyse <DefaultFaultRule>. O bir FaultRule koşulu "doğru" olarak değerlendirilse bile, proxy hata durumunda değil.

Bununla birlikte, burada oluşan bir hata ve proxy'nin hata durumuna girmemesiyle ilgili bir örnek verilmiştir. Şu tarihte: herhangi bir politika izlerseniz continueOnError adlı üst öğede bir özellik ayarlayabilirsiniz. Bu özellik, hata işleme açısından çok önemlidir çünkü o hatanın politika başarısız olursa proxy bir hata durumu girmez. Çoğu durumda (varsayılan değer continueOnError="false") seçin. Bu değer, politika başarısız olur ve özel hata işleme işleminiz tetiklenir. Ancak, continueOnError="true" (örneğin, bir Hizmette hata olmasını istemiyorsanız Proxy'nin yürütülmesini durdurma çağrısı) için, proxy bu durumda hata durumuna geçmez politika başarısız olur ve proxy, FaultRules'unuza bakmaz.

continueOnError="true" sırasında karşılaşılan günlük kaydı hataları hakkında bilgi için Mevcut akıştaki politika hatalarını işleme bölümüne bakın.

Konum FaultRules: ProxyEndpoint veya TargetEndpoint'i tanımlamak için

Bir API proxy'si hatayla karşılaştığında hata <ProxyEndpoint> (istemci uygulamasından gelen istek veya yanıt) ya da <TargetEndpoint> (hedef hizmete yapılan istek veya yanıt). Ne olursa olsun hatası oluşur.

Örneğin, bir hedef sunucu mevcut değilse (HTTP durum kodu 503) API proxy'si gider <TargetEndpoint> yanıtında ve normal API proxy'sinde hata durumuna akışı <ProxyEndpoint> bölümüne devam etmez. Daha önce tanımlanmış FaultRules yalnızca <ProxyEndpoint> içine alırsa bu hatayı işlemezler.

Bir örnek daha. Eğer <ProxyEndpoint> yanıt bir hatayı tetikler, <TargetEndpoint> içindeki bir FaultRule yürütüldü.

FaultRules ve RaiseFault politikası karşılaştırması

Hata kuralları ve PromoteFault politikası, ilk bakışta hata giderme; ve bazı açılardan doğru. Ama aynı zamanda birlikte kullanılabilirler. Bu bölümünde, ikisi arasındaki ilişki açıklanmaktadır. Bu ilişkiyi anlamak, özellikle de her ikisini de kullanmak istiyorsanız hata giderme yönteminizi tasarlarsınız.

Özet olarak:

• Hata kuralları, API proxy'si hata girdiğinde her zaman değerlendirilir durumu.

• RaiseFault politikası, API proxy'sini hata durumuna getirme yöntemidir bir hatanın meydana gelemeyeceği yeni bir yol belirledi.

  Örneğin, Hedef hizmet 200'den fazlaysa yanıtınıza RaiseFault politikası eklersiniz. akışı sağlar. URL şuna benzer olacaktır:

  <TargetEndpoint name="default">
      <PreFlow name="PreFlow">
  ...
          <Response>
              <Step>
                  <Name>Raise-Fault-1</Name>
  <!-- If the condition is true, the Raise-Fault-1 policy gets executed -->
                  <Condition>(response.status.code GreaterThan "200")</Condition>
              </Step>
          </Response> 
  

  REQUESTFault politikası, istemci uygulamasına bir hata mesajı da gönderir.

REQUESTFault politikası, proxy'yi hataya geçiren bir hatayı tetiklediğinde ne olur? olup olmadığını kontrol edin. Burada işler biraz karışabilir. Eğer bir hata mesajı döndürüyor ve bir FaultRule tetikleniyor ve hata mesajı döndürdüğünde istemci uygulamaya ne döndürülür?

• FaultRule veya DefaultFaultRule, RaiseFault politikasından sonra yürütüldüğü için FaultRule yanıt verileri kazanır.
• YieldFault politikası yanıt verileri (durum kodu, neden ifadesi veya mesaj yükü) söz konusu veriler FaultRule veya DefaultFaultRule tarafından ayarlanmazsa kullanılır.
• Hem REQUESTFault politikası hem de FaultRule özel HTTP üstbilgileri eklerse her ikisi de yanıt verelim. Yinelenen başlık adları birden çok değere sahip bir üstbilgi oluşturur.

Aşağıda, bir RaiseFault politikası ve FaultRule tarafından ayarlananlar ve istemci uygulamasına geri döndü. Örnekler en iyi uygulamalar için değil, kısa olması için tasarlanmıştır.

Status Code: 468
Reason Phrase: Something happened
Payload: {"Whoa":"Sorry."}
Header: 
  errorNote: woops,gremlins

Status Code: [none] 
Reason Phrase: Something happened
Payload: {"Whoa":"Sorry."}
Header: 
  errorNote: gremlins

Status Code: 468
Reason Phrase: Can't do that
Payload: {"DOH!":"Try again."}
Header: 
  errorNote: woops

Bina koşulları

Koşullar, FaultRule işlevinin yürütülmesinde kilit rol oynar. FaultRule koşullarını aynı şekilde oluşturursunuz aynısını Edge'deki diğer koşullar için de yapmanız gerekir (örneğin, koşullu akışlar veya RaiseFault koşulları).

Bu bölümün geri kalanını bir bağlama oturtmak için aşağıda, FaultRule koşulu ve iç adım koşulu.

<FaultRule name="invalid_key_rule">
    <Step>
        <Name>invalid-key-message</Name>
        <Condition>(oauthV2.Verify-API-Key-1.failed = true)</Condition>
    </Step>
    <Condition>(fault.name = "FailedToResolveAPIKey")</Condition>
</FaultRule>

Politikaya özel değişkenler hatalar

fault.name ve {policy_namespace}.{policy_name}.failed değişkenleri kullanılabilirliklerini gösterebilir.

fault.name

Bir politika başarısız olduğunda fault.name öğesini kullanarak bir koşuldaki hatayı yakalayın değişkenine eklenmelidir. Örneğin:

<Condition>(fault.name = "policy_error_name")</Condition>

Hata adı, varsayılan hata mesajında görünür. Örneğin, aşağıdaki örnekte hata ad FailedToResolveAPIKey. Bu örnekte, fault.name, FailedToResolveAPIKey değerine ayarlandı.

{"fault":{"faultstring":"Failed to resolve API Key variable request.queryparam.apikey","detail":{"errorcode":"steps.oauth.v2.FailedToResolveAPIKey"}}}

Koşul aşağıdaki gibi görünür:

<Condition>(fault.name = "FailedToResolveAPIKey")</Condition>

Bkz. Politika hatası referans bölümüne bakın.

{policy_namespace}.{politika_adı}.başarısız oldu

Bir politika başarısız olduğunda *.failed değişkeni kullanılabilir. Aşağıdakiler Farklı politikalar için *.failed değişkenlerine dair örnekler. Politika ad alanları için her bir politika referansı konusundaki akış değişkenlerine bakın.

• YükseltmeFault politikası: raisefault.failed (Tüm RaiseFault politikaları için aynı)
• VerifyAPIKey politikası: oauthV2.{policy_name}.failed, şunun için: örnek, oauthV2.Verify-API-Key-1.failed
• Kota politikası ve SpikeArrest politikası: örneğin ratelimit.{policy_name}.failed, ratelimit.Quota-1.failed

Kullanılabilen diğer değişkenler

Bir API proxy'si hata durumuna geçtiğinde yalnızca koşullarda kullanılabilecek değişkenler şunlardır:

• Politikanın başarısız olan değişkenleri.
• Hata noktasında mevcut olan HTTP mesajı değişkenleri. Örneğin, bir hata yanıtta tetiklendiğinde, <TargetEndpoint> içindeki bir FaultRule, HTTP kullanabilir veri response.status.code, message.content, error.content vb. Bir Kota politikası başarısız olduysa değişken ratelimit.{quota_policy_name}.exceed.count. İzleme aracını ve politikayı referans konuları inceleyin.

Daha fazla bilgi

• Koşullar: Koşullar referansı ve Akış değişkenleri ve koşullar

• Hatalar: Politika hatası referansı
• Değişkenler: Değişkenler referansı ve tek tek görün politika referans sayfaları da oluşturabilirsiniz.

Hata giderme için en iyi uygulamalar

Hata işleme, API proxy'si geliştirmek için önemli bir mimari tasarım görevidir. Bu önemli ve hataları nasıl ve ne zaman ele alacağınızı anlamak için zaman ayırın, ve hata mesajı biçimleri tasarlayabilirsiniz. Bunları çözdükten sonra (ya da öğrendikten sonra) ardından hata giderme uygulamanızda size yardımcı olacak bu en iyi uygulamalardan yararlanabilirsiniz.

Aşağıda, hata giderme sistemi tasarlama ve inşa etmeye ilişkin en iyi uygulamalardan bazıları verilmiştir:

• Her FaultRule için bir "outer" değeri sağlayın <Condition> ( <Step> öğesi). Dış koşulu olmayan hata kuralları otomatik olarak değerlendirilir doğrudur. "İç" Bir FaultRule'un doğru olup olmadığını belirlemek için adım koşulları kullanılmaz veya yanlış değerini alır. Adım koşulları yalnızca Edge'in bunları içeren FaultRule'ı yürütmesinden sonra değerlendirilir. Bir FaultRule ayarında, Mesaj Ata (veya diğer) politikaları ile birlikte birden fazla adım olması normaldir. her birinde bir Adım koşulu bulunur.

• Aynı türden birden fazla politikadaki (ör. birden fazla Kota) politikaları) ihlal ederseniz, alma olasılığınızın yüksek olduğu her politika hatası için bir FaultRule oluşturun. Örneğin, Kota politikalarında QuotaViolation, InvalidMessageWeight, StartTimeNotSupported. (Aşağıdaki Politika hatası referansı politika hataları. İşlenmesi gereken başka hatalar keşfettikçe ve bunları Hata Kurallarınıza ekleyin. İşlemleri tekrar etmenizde bir sakınca yoktur proxy yeniden dağıtımı). Bu yaklaşım, hangi sorun olursa olsun aynı türde hataları yakalamanıza politikası tarafından yayınlanır ve bu da FaultRules XML'inizin verimli olmasını sağlar.

  Ardından, daha ayrıntılı hata kontrolüne ihtiyacınız varsa iç Adım koşullarını kullanın. Örneğin, hem bireysel geliştirici kotasını hem de genel kotayı uygulamak için "Dış" isteklerinizi ayarlayın, Şu durumda tetiklenecek FaultRule koşulu QuotaViolation hatası (iki durumda da kota aşıldığında bu uyarı verilir). Sonra Her iki kotanızdaki exceed.count değişkenlerini değerlendirmek için Adım koşulları belirleyin politikalar. İstemciye yalnızca ilgili hata gönderilir (geliştirici kotası aşım veya global kota aşımı) için geçerlidir. Bu yapılandırmanın bir örneği aşağıda verilmiştir:

  <FaultRule name="over_quota">
  <!-- This condition catches a QuotaViolation in *any* Quota policy -->
    <Condition>(fault.name = "QuotaViolation")</Condition>
    <Step>
      <Name>developer-over-quota-fault</Name>
      <Condition>(ratelimit.developer-quota-policy.exceed.count GreaterThan "0")</Condition>
    </Step>
    <Step>
      <Name>global-over-quota-fault</Name>
      <Condition>(ratelimit.global-quota-policy.exceed.count GreaterThan "0")</Condition>
    </Step>
  </FaultRule>
  

  Başka bir örnek için bu Apigee Topluluğu ileti dizisine bakın.

• Tek türde tek bir politika kullanırken hataları işlemek için tek bir hatayı değerlendirin ve bu politika başarısız olduğunda yürütülen bir kuralı içeren ve her olası hatayı tespit ederiz. Bu, XML yerine tek bir FaultRule kullanarak birden fazla Hata Kuralı (her hata türü için bir tane). Örneğin:

  <FaultRule name="raise-fault-3">
  <!-- This condition catches *any* error in the Verify-API-Key-1 policy. -->
    <Condition>(oauthV2.Verify-API-Key-1.failed = "true")</Condition>
    <!-- This first step always executes, which handles errors you haven't mapped with inner conditions. -->
    <Step>
      <Name>Generic-Key-Fault</Name>
    </Step>
    <Step>
      <Name>Assign-Message-Raise-Fault-1</Name>
      <Condition>(fault.name = "FailedToResolveAPIKey")</Condition>
    </Step>
    <Step>
      <Name>Assign-Message-Raise-Fault-2</Name>
      <Condition>(fault.name = "InvalidApiKey")</Condition>
    </Step>
  </FaultRule>
  

• Hataların ortaya çıkacağı yer FaultRules ekleyin (istemci tarafı <ProxyEndpoint> veya hedef <TargetEndpoint>). Şu koşulları karşılayan her politika için FaultKurallar'ı dahil edin: her konumda görünür.
• FaultRules'da, istemciye mesaj döndürebilecek her türlü politikayı yürütebilirsiniz uygulamasını indirin. AssignmentMessage politikası bunun için idealdir. Ayrıca MessageLogging politikasına bakın.
• FaultRules ile birlikte RaiseFault politikalarını kullanırken yanıtı koordine edin hem RaiseFault politikası hem de FaultRule veri döndürdüğünde geri gönderilen veriler. Örneğin, Örneğin, RaiseFault politikanız HTTP durum kodunu sıfırlıyorsa FaultRule sıfırlaması yapmayın yer alır. Yapılabilecek en kötü şey, varsayılan durum kodunun istemci uygulaması.
• <DefaultFaultRule> yürütme:
  • <DefaultFaultRule> eklentisinin başka hiçbir zaman FaultRule yürütülür, ona <Condition> eklemeyin.
  • Bir <DefaultFaultRule> öğesinin, başka bir ayar açıkken bile her zaman yürütülmesini istiyorsanız FaultRule yürütüldü, <AlwaysEnforce>true</AlwaysEnforce> alt öğesi.

Desen: merkezi, tekrar kullanılabilir hata giderme

Aşağıdaki Apigee topluluk gönderisinde, kullanıcılarımıza sorunsuz bir şekilde merkezileştirilmiş hata giderme kod yinelemesi:

https://community.apigee.com/articles/23724/an-error-handling-pattern-for-apigee-proxies.html

Hata Kuralları Oluşturma

FaultRule eklemek için ProxyEndpoint veya TargetEndpoint. Bu düzenlemeyi kenarın Kod bölmesinde yapmak için Edge kullanıcı arayüzünü kullanabilirsiniz API proxy'si için Geliştirin görünümünü veya ProxyEndpoint ya da TargetEndpoint.

Yönetim kullanıcı arayüzünde FaultKuralları oluşturursanız önce yürütmek istediğiniz politikaları, bunları FaultRule yapılandırmasına ekleyin. (Bir FaultRule (henüz oluşturulmamış bir politikaya referans veren).)

FaultRule'a politika ekleme

FaultRule'a herhangi bir politika koyabilirsiniz, ancak AtananMessage politikası, bir hata koşulu için özel yanıt iletisi oluşturur. Atayan; yük, HTTP durum kodu, başlıklar ve HTTP durum kodu ve neden kelime öbeği öğeleri.

Aşağıdaki örnekte tipik bir AssignmentMessage politikası yapılandırması gösterilmektedir:

<AssignMessage name="fault_invalidkey">
  <Set>
      <Payload contentType="text/plain">Contact support at support@mycompany.com.</Payload>
      <StatusCode>401</StatusCode>
      <ReasonPhrase>Unauthorized</ReasonPhrase>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

Artık bu politikayı FaultRule'ınızda kullanabilirsiniz. Ataması'na nasıl referans verdiğinize dikkat edin politika:

<ProxyEndpoint name="default">
  ...
  <FaultRules>
    <FaultRule name="invalid_key_rule">
      <Step>
        <Name>fault_invalidkey</Name>
      </Step>
      <Condition>(fault.name = "InvalidApiKey")</Condition>
    </FaultRule>
  </FaultRules>
</ProxyEndpoint>

Yukarıdaki yapılandırmayı dağıttığınızda API proxy'si, assignMessage politikasını yürütür tarafından fault_invalidkey çağrılmasını sağlar.

Aşağıdaki örnekte gösterildiği gibi bir FaultRule içinde birden çok politika yürütebilirsiniz:

<ProxyEndpoint name="default">
  ...
  <FaultRules>
    <FaultRule name="invalid_key_rule">
      <Step>
        <Name>policy1</Name>
      </Step>
      <Step>
        <Name>policy2</Name>
      </Step>
      <Step>
        <Name>policy3</Name>
      </Step>
      <Condition>(fault.name = "InvalidApiKey")</Condition>
    </FaultRule>
  </FaultRules>
</ProxyEndpoint>

Politikalar belirlenen sıraya göre yürütülür. Örneğin, MessageLogging politikası, ExtractVariables politikası, AssignmentMessage politikası veya FaultRule. Bu durumlardan herhangi biri gerçekleşirse FaultRule işleminin hemen durdurulduğunu unutmayın gerçekleşenler:

• FaultRule'daki herhangi bir politika hataya neden oluyor
• FaultRule'daki politikalardan herhangi biri RaiseFault türünde

bir FaultRule'dan döndürülen özel hata mesajı

En iyi uygulama olarak, dönüşüm hunisinin her aşamasında net hata yanıtlarını API'ler. Bu şekilde müşterilerinize tutarlı ve yararlı bilgiler sunabilirsiniz.

Aşağıdaki AssignmentMessage politikası örneğinde <Payload> kullanılır, Özel parametreyi tanımlamak için <StatusCode> ve <ReasonPhase> etiketleri InvalidApiKey hatasıyla istemciye geri gönderilen hata yanıtı (önceki FaultRules örneğine bakın).

<AssignMessage name="fault_invalidkey">
  <Set>
    <Payload contentType="text/plain">You have attempted to access a resource without the correct authorization. 
       Contact support at support@mycompany.com.</Payload>
    <StatusCode>401</StatusCode>
    <ReasonPhrase>Unauthorized</ReasonPhrase>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

Bu yanıt şunları içerir:

• Destek ekibiyle iletişime geçmek için gerekli hata mesajını ve e-posta adresini içeren yük.
• Yanıtta döndürülen HTTP durum kodu.
• Hatanın kısa bir açıklaması olan neden ifadesi.

DefaultFaultRule Oluşturma

DefaultFaultRule, FaultRule'ı seçeceğim. Tüm FaultRules koşulları hatayla eşleşmiyorsa DefaultFaultRule hatayı işler. ProxyEndpoint etiketinin alt öğesi olarak <DefaultFaultRule> etiketini TargetEndpoint.

Örneğin, aşağıdaki TargetEndpoint yapılandırmasında bir DefaultFaultRule ReturnGenelError adlı politika:

<TargetEndpoint name="default">
  ...
  <FaultRules>
    ...
  </FaultRules>

  <DefaultFaultRule name="fault-rule">
    <Step>
      <Name>ReturnGenericError</Name>
    </Step>
  </DefaultFaultRule>

  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
  </HTTPTargetConnection>
</TargetEndpoint>

DefaultFaultRule genellikle beklenmedik bir durumda genel bir hata mesajı döndürmek için hatası gibi bir iletiyle karşılaşabilirsiniz. Bu varsayılan değer yanıt, geliştirici dostu bilgiler sağlama ve aynı zamanda arka uç URL'lerini veya sistemin güvenliğini ihlal etmek için kullanılabilecek diğer bilgileri karartmak.

Örneğin, genel bir hata döndürmesi için aşağıdakiassignMessage politikasını tanımlarsınız:

<AssignMessage name="ReturnGenericError">
  <Set>
    <Payload type="text/plain">SERVICE UNAVAILABLE. PLEASE CONTACT SUPPORT: support@company.com.</Payload>
  </Set>
</AssignMessage>

<AlwaysEnforce> öğesini Her hatada DefaultFaultRule'u yürütmek için <DefaultFaultRule> etiketi çalıştırılmış olması gerekir. DefaultFaultRule her zaman son FaultRule olur yürütme:

  <DefaultFaultRule name="fault-rule">
    <Step>
      <Name>ReturnGenericError</Name>
    </Step>
    <AlwaysEnforce>true</AlwaysEnforce>
  </DefaultFaultRule>

DefaultFaultRule'ın bir kullanımı da belirleyemez. Örneğin API proxy'niz, Search Console'da yayınladığınız bir belirleyemez. AşağıdakiassignMessage politikasını çağırmak için DefaultFaultRule'u kullanın. Bu politika, fault.name değerini DefaultFaultHeader adlı bir başlığa yazar yanıt:

<AssignMessage async="false" continueOnError="false" enabled="true" name="DefaultFaultRule">
  <DisplayName>DefaultFaultRule</DisplayName>
  <Set>
    <Headers>
      <Header name="DefaultFaultHeader">{fault.name}</Header>
    </Headers>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" transport="http" type="response"/>
</AssignMessage>

Ardından, sorunun nedenini görmek için Edge izleme aracında veya yanıttaki başlığı görüntüleyebilirsiniz. hatası.

Mesaj günlüğü PostClientFlow

Proxy hata girdikten sonra yürütülen tek akış PostClientFlow'dur durumu. Yürütülen bu akışa yalnızca MessageLogging politikası eklenebilir. yanıt gönderildikten sonra geri dönebilir. MessageLogging politikasını bu akışa eklemek teknik olarak hayır bu aracı, hata olması durumunda bilgileri günlüğe kaydetmek için kullanabilirsiniz. Çünkü proxy'nin başarılı olup olmamasından bağımsız olarak çalıştırıldığında, İleti Kaydı ve bu politikaların her zaman geçerli olacağını garanti edersiniz.

Mevcut akıştaki politika hatalarını ele alma

Şu ana kadar gösterilen örneklerin tümü, kullanması gereken ProxyEndpoint veya TargetEndpoint'te bir FaultRule politika hatalarını düzeltmez. Bunun nedeni, Politikanın continueOnError öğesi false değeridir. Bu durumda hatası oluşursa kontrol, hata durumuna yönlendirilir. Hata durumuna geçtikten sonra, kontrolü normal ardışık düzene geri döndüremediğinizi ve genellikle arama uygulamasına mesaj gönderebilirsiniz.

Ancak continueOnError öğesini bir öğe için true ilkesini seçerseniz kontrol mevcut akışta kalır ve ardışık düzendeki bir sonraki politika politika. Mevcut akışta hatayı ele almanın avantajı, isteği işlemeyi tamamlamak için hatadan kurtulmanın bir yolu olabilir.

Aşağıda,verify-api-key continueOnError öğesi true: olarak ayarlandı

<VerifyAPIKey async="false" continueOnError="true" enabled="true" name="verify-api-key">
  <DisplayName>Verify API Key</DisplayName>
  <APIKey ref="request.queryparam.apikey"/>
</VerifyAPIKey>

API anahtarı eksik veya geçersizse VerifyAPIKey politikası oauthV2.verify-api-key.failed değişkeni true olarak değiştirildi, ancak işleniyor devam eder.

Ardından, VerifyAPIKey politikasını ProxyEndpoint'in PreFlow'a bir adım olarak eklersiniz:

<ProxyEndpoint name="default">
  ...
  <PreFlow name="PreFlow">
    <Request>
      <Step>
        <Name>verify-api-key</Name>
      </Step>
      <Step>
        <Name>FaultInFlow</Name>
        <Condition>(oauthV2.verify-api-key.failed = "true")</Condition>
      </Step>
    </Request>
    <Response/>
  </PreFlow>      
</ProxyEndpoint>  

PreFlow'daki sonraki adımın bir koşulun mevcut olup olmadığını test etmek için nasıl kullanıldığına hatası. VerifAPIKey politikasında bir hata oluşmuşsa FaultInFlow politikası yürütülüyor. Aksi takdirde FaultInFlow politikası atlandı. FaultInFlow politikası, hatayı günlüğe kaydetme, veya başka bir işlem gerçekleştirilir.

RaiseFault yöntemini kullanarak hata tetikleme politika

Hata tetiklemek için akışta istediğiniz zaman RaiseFault politikasını kullanabilirsiniz. Bir Artış politikası yürütüldüğünde mevcut akış sonlandırılır ve kontrolü hataya aktarılır durumu.

YieldFault politikasının kullanımlarından biri, belirli bir koşulun, başka bir politikanın olmayabilir. Yukarıdaki örnekte, <Condition> FaultInFlow politikasının yürütülmesine neden olan PreFlow <Step> etiketi koşulun karşılanması gerekir. FaultInFlow bir REQUESTFault politikasıysa hata durumuna aktarılır. Alternatif olarak, hata ayıklamak için akışa bir RaiseFault politikası ekleyebilir test edebilirsiniz.

Bir RaiseFault politikası hata tetiklediğinde aşağıdaki FaultRule parametresini ve koşulunu kullanabilirsiniz aşağıdaki adımları izleyin:

<FaultRule name="raisefault_rule">
  <Step>
    <Name>{policy_name}</Name>
  </Step>
  <Condition>(fault.name = "RaiseFault")</Condition>
</FaultRule>

Koşulun RaiseFault adlı bir hata için test ettiğini unutmayın. GainFault politikası, fault.name değerini her zaman RaiseFault olarak ayarlar.

HTTP hata kodlarının özel olarak işlenmesi hedef sunucudan

Önceki bölümlerde gösterilen örnekler, politikalar tarafından oluşturulan hatalar için geçerlidir. Ancak, Ayrıca aktarım düzeyindeki hatalar için özel bir yanıt oluşturabilir. Bu, seçin. HTTP hatasından gelen yanıtı kontrol etmek için aşağıdaki gibi bir TargetEndpoint yapılandırın: HTTP yanıt kodlarını işleme.

Varsayılan olarak Edge, 1xx-3xx aralığındaki HTTP yanıt kodlarını "başarılı" ve HTTP olarak değerlendirir 4xx-5xx aralığındaki yanıt kodlarını 'başarısız' olarak ayarlayın. Bu, arka uçtan gelen herhangi bir yanıtın 4xx-5xx kodlu bir HTTP yanıt koduna sahip hizmet, hata durumunu otomatik olarak çağırır ve bu hata istekte bulunan istemciye doğrudan bir hata mesajı döndürür.

Tüm HTTP yanıt kodları için özel işleyiciler oluşturabilirsiniz. Örneğin, her ekip üyesinin 4xx-5xx aralığındaki tüm HTTP yanıt kodlarını 'başarısız' olarak işle ama yalnızca 5xx veya kullanarak HTTP yanıt kodları 400 ve 500 için özel hata mesajları döndürür.

Sonraki örnekte, success.codes 400 ve 500 kodlu HTTP yanıt kodlarını varsayılan HTTP ile birlikte başarılı olarak değerlendirecek TargetEndpoint ekleyebilirsiniz. Bu kodları başarılı olarak ele aldığımızda TargetEndpoint, yanıt mesajı gönderebilirsiniz:

<TargetEndpoint name="default">
  ...
  <HTTPTargetConnection>
    <Properties>
          <Property name="success.codes">1xx,2xx,3xx,400,500</Property>
    </Properties>
    <URL>http://weather.yahooapis.com</URL>
  </HTTPTargetConnection>
</TargetEndpoint>

Bu örnekte görebileceğiniz gibi success.codes özelliğini değerleri..

success.codes özelliği ayarlandığında, varsayılan değerleri. Bu nedenle, varsayılan başarı listesine HTTP kodu 400'ü eklemek isterseniz kodları için bu özelliği şu şekilde ayarlayın:

<Property name="success.codes">1xx,2xx,3xx,400</Property>

Ancak, HTTP kodu 400'ün başarılı kod olarak değerlendirilmesini istiyorsanız özelliği şu şekilde ayarlayın:

<Property name="success.codes">400</Property>

Artık HTTP yanıt kodları 400 ve 500 için özel işleyiciler tanımlayarak özelleştirilmiş bir istekte bulunan uygulamaya yanıt mesajı gönderebilir. Aşağıdaki TargetEndpoint, HTTP 400 ve 500 yanıt kodlarını işlemek için ReturnError:

<TargetEndpoint name="default">
  <PreFlow name="PreFlow">
    <Request/>
    <Response>
      <Step>
        <Name>ReturnError</Name>
        <Condition>(response.status.code = 400) or (response.status.code = 500)</Condition>
      </Step>
    </Response>
  </PreFlow>

  <HTTPTargetConnection>
    <Properties>
      <Property name="success.codes">1xx,2xx,3xx,400,500</Property>
    </Properties>
    <URL>http://weather.yahooapis.com</URL>
  </HTTPTargetConnection>
</TargetEndpoint>

Bu TargetEndpoint yapılandırması, ReturnError adlı politikanın TargetEndpoint, 400 veya 500 HTTP yanıt koduyla karşılaştığında yanıt alın.

Hata sınıflandırması

API Hizmetleri, hataları aşağıdaki kategoriler ve alt kategoriler halinde düzenler.

Bir hataya her zaman hatanın nedenine dair bir açıklama metni eklenir. sistem bir hata oluştuğunda, sorun gidermeye yardımcı olmak için bir dizi özellik doldurulur. Hata aşağıdaki bilgileri içerir:

• Neden
• Kullanıcı tanımlı özel özellikler