Politika hataları hakkında bilmeniz gerekenler

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

Bu konuda, politika hatalarının yapısı ve politika hatası oluştuğunda ayarlanan akış değişkenlerinin türleri açıklanmaktadır. Bu bilgiler, proxy'leriniz için hata işleme tasarlayıp uyguluyorsanız çok önemlidir.

Bu konuda, Edge'de hata yönetimi sürecinin işleyiş şekli hakkında genel bilgi sahibi olduğunuz ve hata kurallarının ne olduğunu bildiğiniz varsayılmaktadır. İnceleme yapılması gerekiyorsa Hataları ele alma başlıklı makaleyi inceleyin. Buradaki bilgiler, Politika hatası referansında gezinmenize ve bu referansı kullanmanıza da yardımcı olur.

Varsayılan politika hatası yanıtı hakkında

Bir politika hata verdiğinde Edge hemen hata akışına girer ve hata mesajı oluşturur. Sistem tarafından oluşturulan bu mesaj, iki bilgi içeren bir JSON nesnesidir: errorcode ve faultstring.

Örneğin:

{  
   "fault":{  
      "detail":{  
         "errorcode":"steps.extractvariables.SourceMessageNotAvailable"
      },
      "faultstring":"foo message is not available for ExtractVariable: ParseJsonResponse"
   }
}

Bu hata mesajını hızlıca inceleyelim:

errorcode, prefix ve error name'den oluşur. Örneğin: [prefix].[error_name]. Yukarıdaki örnekte "steps.extractvariables" ön ek, SourceMessageNotAvailable ise hata adıdır. Önek, hataya hangi politikanın neden olduğunu gösterir. Yukarıdaki örnekte, bir Değişkenleri Çıkar politikası hatayı oluşturdu ve hata adının SourceMessageNotAvailable olduğunu görebilirsiniz.

faultstring, hatanın açıklamasını içerir. Hata dizesi genellikle hataya neden olan belirli sorunu bulmanıza yardımcı olacak ipuçları içerir. Örneğin, politika adı, çözümlenmemiş bir değişkenin adı veya hataya katkıda bulunan diğer unsurlar. Örneğin, yukarıdaki hata mesajında "foo", politikada referans verilen çözümlenmemiş bir mesaj değişkeninin adı, "ParseJsonResponse" ise hatayı tetikleyen politikanın adıdır.

Politika hatalarına özgü değişkenler

Bir politika hatası tetiklendiğinde hataya özel belirli akış değişkenleri doldurulur. Bu değişkenler, hata yönetiminde son derece yararlıdır. Hataları işleme başlıklı konuda açıklandığı gibi, sistem tarafından oluşturulan politika hatalarını yakalamak ve ardından özel bir hata yanıtı oluşturmak gibi bir işlem yapmak yaygın bir uygulamadır. Örneğin, güvenlik nedeniyle istemcilerin Edge'in döndürdüğü gerçek hataları ve durum kodlarını görmesini engellemek isteyebilirsiniz.

fault.name değişkeni

Bir politika hata verdiğinde akış değişkeni fault.name, hata kodunun error_name kısmına ayarlanır (önceki bölümde açıklandığı gibi). Hata kurallarını koşullu olarak yürütmek için bu değişkenin değerlendirilmesi çok yaygındır.

fault.name değerini test eden bir hata kuralı örneğini aşağıda bulabilirsiniz:

<faultrule name="VariableOfNonMsgType"<>/faultrule><FaultRule name="Source Message Not Available Fault">
    <Step>
        <Name>AM-CustomErrorMessage</Name>
        <Condition>(fault.name Matches "SourceMessageNotAvailable") </Condition>
    </Step>
</FaultRule>

Unutulmaması gereken nokta, bir politika hataya neden olduğunda fault.name değişkeninin her zaman hata adına ayarlanacağıdır.

[prefix].[policy_name].failed değişkeni

Geliştiricilerin yaygın olarak kontrol ettiği bir diğer değişken de fault.name dışında [prefix].[policy_name].failed işaretidir. Bu işaret, bir politika yürütüldüğünde doğru veya yanlış olarak ayarlanır. Hata kurallarında, doğru olup olmadığını kontrol etmeniz gerekir. Bu, bir hata oluşup oluşmadığını kontrol etmek anlamına gelir. [prefix].[policy_name].failed işaretini kontrol eden bir koşul oluşturma adımları aşağıda verilmiştir. Bu değişkeni doğru şekilde kontrol etmek için iki şeyi bilmeniz gerekir:

• Kontrol ettiğiniz politikanın adı. Bu, politikanın görünen adı değil, ad özelliğinin değeridir. Bu özellik her zaman politika tanımının XML'sine dahil edilir.
• Kontrol ettiğiniz politika türüne özel bir önek. (Ön eki nasıl bulacağınızı aşağıda açıklayacağız.)

Örnek olarak, başka bir hata kuralı örneğini aşağıda bulabilirsiniz. Dış koşulda [prefix].[policy_name].failed değişken adının nasıl oluşturulduğuna dikkat edin. Bu durumda, önek extractvariables ve politika adı ParseJsonResponse olur. Bu durumda, hata kuralı yalnızca bu değişken doğruysa yürütülür. Ayrıca, bir ipucu: Hata kuralları birden fazla adım içerebileceğinden bu kalıp, hata kurallarını bloklar halinde düzenlemek için iyi bir yöntemdir.

<faultrule name="VariableOfNonMsgType"></faultrule><FaultRule name="Extract Variable Faults">
    <Step>
        <Name>AM-CustomErrorMessage</Name>
        <Condition>(fault.name Matches "SourceMessageNotAvailable") </Condition>
    </Step>
    <Condition>(extractvariables.ParseJsonResponse.failed = true) </Condition>
</FaultRule>

error ve message değişkenleri hakkında

error değişkeni yalnızca bir proxy'nin hata akışında kullanılabilir. Hata değişkeninden hata mesajı, durum kodu, neden ifadesi gibi faydalı bilgiler edinebilirsiniz. Hata değişkeninin biçimlendirme kalıbı şöyledir:

error.[error_component] = [value]

Örneğin:

error.message = "request message is not available for ExtractVariable: ParseJsonResponse"

ve

error.status.code = "500"

message değişkeni, hata akışında da kullanılabilir ve error değişkeniyle benzer amaçlar için kullanılabilir. İleti değişkeni, bağlamsal olduğu için özeldir. İstek akışında istek değişkeni gibi davranır. Yanıt akışında ise yanıt değerlerini almak/ayarlamak için kullanılabilir. Daha fazla bilgi edinmek için Mesaj değişkenlerinin kullanım alanları başlıklı makaleyi inceleyin.

error ve message dahil olmak üzere tüm Edge değişkenleri hakkında bilgi için Değişkenler referansı konusuna bakın.