नीति से जुड़ी गड़बड़ियों के बारे में आपके लिए ज़रूरी जानकारी

Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं. जानकारी

इस विषय में, नीति से जुड़ी गड़बड़ियों का स्ट्रक्चर बताया गया है. साथ ही, यह भी बताया गया है कि नीति से जुड़ी कोई गड़बड़ी होने पर किस तरह के फ़्लो वैरिएबल सेट किए जाते हैं. अपने प्रॉक्सी को डिज़ाइन करने और उसमें गड़बड़ी ठीक करने के लिए, यह जानकारी देना ज़रूरी है.

इस विषय से यह मान लिया जाता है कि आपको इस बारे में सामान्य जानकारी है कि Edge में गड़बड़ी को ठीक करने का तरीका कैसे काम करता है. साथ ही, आपको पता है कि गड़बड़ी के नियम क्या हैं. अगर आपको समीक्षा करनी है, तो गड़बड़ियां ठीक करना देखें. यहां दी गई जानकारी से, आपको नीति से जुड़ी गड़बड़ी के रेफ़रंस को नेविगेट करने और उसका इस्तेमाल करने में भी मदद मिलेगी.

नीति से जुड़ी डिफ़ॉल्ट गड़बड़ी के जवाब के बारे में जानकारी

जब किसी नीति में गड़बड़ी होती है, तो Edge तुरंत गड़बड़ी वाले फ़्लो में आ जाता है और गड़बड़ी का मैसेज जनरेट करता है. सिस्टम से जनरेट किया गया मैसेज, एक JSON ऑब्जेक्ट है. इसमें दो तरह की जानकारी शामिल होती है: errorcode और faultstring.

उदाहरण के लिए:

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

आइए, गड़बड़ी के इस मैसेज को तुरंत समझाते हैं:

गड़बड़ी कोड में प्रीफ़िक्स और गड़बड़ी का नाम होता है, जो इस तरह है: [prefix].[error_name]. ऊपर दिए गए उदाहरण में "steps.extractvariables" प्रीफ़िक्स है और SourceMessageNotAvailable गड़बड़ी का नाम है. प्रीफ़िक्स से पता चलता है कि किस नीति से गड़बड़ी हुई है. ऊपर दिए गए उदाहरण में, बताया जा सकता है कि वैरिएबल एक्सट्रैक्ट करने की नीति से गड़बड़ी जनरेट हुई है और गड़बड़ी का नाम SourceMessageNotAvailable है.

faultstring में गड़बड़ी की जानकारी होती है. गड़बड़ी वाली स्ट्रिंग में आम तौर पर सुराग शामिल होते हैं. इनकी मदद से, उस समस्या का पता लगाया जा सकता है जिसकी वजह से गड़बड़ी हुई थी. जैसे, नीति का नाम, समाधान न किए गए वैरिएबल का नाम या गड़बड़ी की वजह से जुड़ी कोई भी जानकारी. उदाहरण के लिए, ऊपर दिए गए गड़बड़ी के मैसेज में, "foo" नीति में बताए गए ऐसे मैसेज वैरिएबल का नाम है जिसे ठीक नहीं किया गया है. साथ ही, "ParseJsonResponse" उस नीति का नाम है जिसने गड़बड़ी को ट्रिगर किया था.

नीति से जुड़ी गड़बड़ियों के लिए खास वैरिएबल

जब नीति से जुड़ी कोई गड़बड़ी ट्रिगर होती है, तो कुछ गड़बड़ी से जुड़े फ़्लो वैरिएबल अपने-आप भर जाते हैं. ये वैरिएबल, गड़बड़ी ठीक करने में बहुत मदद करते हैं. जैसा कि गड़बड़ियां ठीक करना विषय में बताया गया है, सिस्टम से जनरेट की गई नीति की गड़बड़ियों को फंसाना और बाद में कोई कार्रवाई करना, एक सामान्य तरीका है. जैसे, कस्टम गड़बड़ी का जवाब बनाना. उदाहरण के लिए, सुरक्षा से जुड़ी वजहों से, ऐसा हो सकता है कि आप क्लाइंट को, Edge से मिलने वाली असल गड़बड़ियों और स्टेटस कोड को देखने से रोकना चाहें.

fault.name वैरिएबल

जब किसी नीति में गड़बड़ी होती है, तो यह फ़्लो वैरिएबल fault.name को गड़बड़ी कोड के error_name वाले हिस्से पर सेट करती है. इसके बारे में पिछले सेक्शन में बताया गया है. शर्त के साथ गड़बड़ी के नियमों को लागू करने के लिए, इस वैरिएबल का आकलन करना बहुत आम बात है.

यहां गड़बड़ी से जुड़े नियम का एक उदाहरण दिया गया है, जो fault.name की वैल्यू की जांच करता है:

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

ध्यान रखें कि जब कोई नीति किसी गड़बड़ी को ट्रिगर करती है, तो fault.name वैरिएबल हमेशा गड़बड़ी के नाम पर सेट होता है.

[prefix].[policy_name].failed वैरिएबल

fault.name के अलावा, डेवलपर आम तौर पर एक और वैरिएबल [prefix].[policy_name].failed फ़्लैग की जांच करते हैं, जो किसी नीति के लागू होने पर सही या गलत पर सेट होता है. गड़बड़ी के नियमों में, आपको यह देखना होगा कि वैल्यू सही है या नहीं. इसका मतलब है कि गड़बड़ी हुई है या नहीं. यहां ऐसे कंडीशनल बनाने का तरीका बताया गया है जो [prefix].[policy_name].failed फ़्लैग की जांच करे. इस वैरिएबल की सही तरीके से जांच करने के लिए, आपके पास दो चीज़ों के बारे में जानकारी होनी चाहिए:

• उस नीति का नाम जिसकी आपको जांच करनी है. यह नीति के नाम वाले एट्रिब्यूट की वैल्यू है, न कि डिसप्ले नेम की. इस एट्रिब्यूट को हमेशा नीति की परिभाषा के एक्सएमएल में शामिल किया जाता है.
• आपकी जांच की जा रही नीति के हिसाब से, प्रीफ़िक्स लगाया जा सकता है. (हम नीचे प्रीफ़िक्स ढूंढने का तरीका बताएंगे.)

इसे दिखाने के लिए, यहां गड़बड़ी से जुड़े नियम का एक और उदाहरण दिया गया है. बाहरी स्थिति में ध्यान दें कि [prefix].[policy_name].failed वैरिएबल का नाम कैसे बनाया गया. इस मामले में, प्रीफ़िक्स extractvariables है और नीति का नाम ParseJsonResponse है. इस मामले में, गड़बड़ी वाला नियम सिर्फ़ तब लागू होगा, जब यह वैरिएबल सही होगा. साथ ही, एक सलाह: गलती से जुड़े नियमों में कई चरण हो सकते हैं. इसलिए, इस पैटर्न की मदद से, गड़बड़ी वाले नियमों को ब्लॉक में व्यवस्थित किया जा सकता है.

<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 और message वैरिएबल के बारे में जानकारी

error वैरिएबल सिर्फ़ प्रॉक्सी के गड़बड़ी फ़्लो में उपलब्ध होता है. आपको गड़बड़ी के वैरिएबल से काम की जानकारी मिल सकती है. जैसे, गड़बड़ी का मैसेज, स्टेटस कोड, वजह बताने वाला वाक्यांश वगैरह. गड़बड़ी वाले वैरिएबल के लिए फ़ॉर्मैटिंग का पैटर्न यह है:

error.[error_component] = [value]

उदाहरण के लिए:

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

और

error.status.code = "500"

message वैरिएबल, गड़बड़ी के फ़्लो में भी उपलब्ध है और इसे error वैरिएबल जैसे कामों के लिए इस्तेमाल किया जा सकता है. मैसेज वैरिएबल खास होता है, क्योंकि यह कॉन्टेक्स्ट के हिसाब से होता है. अनुरोध के फ़्लो में, यह अनुरोध वैरिएबल की तरह काम करता है. रिस्पॉन्स फ़्लो में, इसका इस्तेमाल रिस्पॉन्स वैल्यू पाने/सेट करने के लिए किया जा सकता है. अगर आपको ज़्यादा जानना है, तो मैसेज वैरिएबल के इस्तेमाल के उदाहरण देखें.

error और message के साथ-साथ सभी Edge वैरिएबल की जानकारी के लिए, वैरिएबल का रेफ़रंस देखें.