एंटीपैटर्न: गलत स्थितियों में riseFault की नीति का इस्तेमाल करें

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

InsertFault नीति की मदद से एपीआई डेवलपर गड़बड़ी का फ़्लो शुरू कर सकते हैं, रिस्पॉन्स के मुख्य हिस्से के मैसेज में गड़बड़ी के वैरिएबल सेट कर सकते हैं, और सही रिस्पॉन्स स्टेटस कोड सेट कर सकते हैं. गड़बड़ी से जुड़े फ़्लो वैरिएबल सेट करने के लिए, riseFault की नीति का इस्तेमाल भी किया जा सकता है. जैसे, fault.name, fault.type, और fault.category. ये वैरिएबल, डीबग करने के लिए इस्तेमाल किए गए आंकड़ों के डेटा और राऊटर ऐक्सेस लॉग में दिखते हैं. इसलिए, गड़बड़ी की सटीक पहचान करना ज़रूरी है.

कुछ खास स्थितियों को गड़बड़ियों के तौर पर मेज़र करने के लिए, riseFault की नीति का इस्तेमाल किया जा सकता है. ऐसा तब भी किया जा सकता है, जब किसी दूसरी नीति या एपीआई प्रॉक्सी के बैकएंड सर्वर में कोई असल गड़बड़ी न हुई हो. उदाहरण के लिए, अगर आपकी इच्छा है कि जब भी बैकएंड में रिस्पॉन्स के मुख्य हिस्से में unavailable स्ट्रिंग हो, तो प्रॉक्सी, क्लाइंट ऐप्लिकेशन को गड़बड़ी का कस्टम मैसेज भेजे, तो आपके पास इस कोड स्निपेट में दिखाए गए तरीके से riseFault नीति लागू करने का विकल्प है:

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

riseFault नीति का नाम एपीआई की निगरानी में fault.name के तौर पर और Analytics और राऊटर ऐक्सेस लॉग में x_apigee_fault_policy के तौर पर दिखता है. इससे गड़बड़ी की वजह का आसानी से पता लगाने में मदद मिलती है.

एंटीपैटर्न

अगर किसी अन्य नीति के उल्लंघन की वजह से, यह गड़बड़ी ठीक नहीं की जा रही है, तो गलती से जुड़े नियम के लिए riseFault की नीति का इस्तेमाल करें

नीचे दिया गया उदाहरण देखें, जिसमें एपीआई प्रॉक्सी फ़्लो में, OAuthV2 नीति InvalidAccessToken गड़बड़ी की वजह से फ़ेल हो गई है. फ़ेल होने पर, Edge fault.name को InvalidAccessToken के तौर पर सेट कर देगा, गड़बड़ी के फ़्लो में आ जाएगा, और तय किए गए सभी फ़ॉल्ट रूल लागू करेगा. गड़बड़ी के नियम में, RaiseFault नाम की मिलती-जुलती नीति मौजूद है. यह InvalidAccessToken गड़बड़ी होने पर, पसंद के मुताबिक गड़बड़ी का जवाब भेजती है. हालांकि, किसी गड़बड़ी के नियम में गणनाFault नीति का इस्तेमाल करने का मतलब है कि fault.name वैरिएबल ओवरराइट हो जाता है और फ़ेल होने की सही वजह को छिपा देता है.

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

सभी स्थितियों में गड़बड़ी के नियम में riseFault की नीति का इस्तेमाल करना

यहां दिए गए उदाहरण में, अगर fault.name, RaiseFault नहीं है, तो RaiseFault नाम की करामाती नीति लागू की जाती है:

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

पहले स्थिति की तरह ही, मुख्य गड़बड़ी वाले वैरिएबल fault.name, fault.code, और fault.policy को riseFault नीति के नाम से बदल दिया जाता है. इस तरीके से, यह पता लगाना करीब-करीब नामुमकिन हो जाता है कि किस नीति की वजह से गड़बड़ी हुई. ऐसा, गड़बड़ी दिखाने या समस्या को फिर से लाने वाली ट्रेस फ़ाइल को ऐक्सेस किए बिना किया जा सकता है.

गड़बड़ी के फ़्लो के अलावा, एचटीटीपी 2xx रिस्पॉन्स दिखाने के लिए GrowFault की नीति का इस्तेमाल करना.

यहां दिए गए उदाहरण में, HandleOptionsRequest नाम की riseFault नीति तब लागू होती है, जब अनुरोध की कार्रवाई OPTIONS होती है:

<!-- /antipatterns/examples/raise-fault-conditions-4.xml  -->
<PreFlow name="PreFlow">
    <Request>
        …
        <Step>
            <Name>HandleOptionsRequest</Name>
            <Condition>(request.verb Equals "OPTIONS")</Condition>
        </Step>
        …
</PreFlow>

इसका मकसद, अन्य नीतियों को प्रोसेस किए बिना, एपीआई क्लाइंट को तुरंत रिस्पॉन्स भेजना है. हालांकि, इससे आंकड़ों से जुड़ा गुमराह करने वाला डेटा मिल जाएगा, क्योंकि गड़बड़ी वाले वैरिएबल में ReceiveFault नीति का नाम शामिल होगा. इस वजह से, प्रॉक्सी को डीबग करना ज़्यादा मुश्किल हो जाएगा. अपने हिसाब से व्यवहार लागू करने का सही तरीका, खास शर्तों वाले फ़्लो का इस्तेमाल करना है, जैसा कि सीओआरएस सहायता जोड़ना सेक्शन में बताया गया है.

असर

ऊपर बताए गए तरीके से riseFault की नीति का इस्तेमाल करने पर, गड़बड़ी वाली मुख्य वैरिएबल की जगह riseFault की नीति के नाम के बजाय दूसरी नीति के नाम से ओवरराइट हो जाएगा. Analytics और NGINX ऐक्सेस लॉग में, x_apigee_fault_code और x_apigee_fault_policy वैरिएबल ओवरराइट हो जाते हैं. एपीआई मॉनिटरिंग में, Fault Code और Fault Policy को ओवरराइट किया जाता है. इस तरीके से, समस्या को हल करना मुश्किल हो जाता है. साथ ही, यह पता लगाना भी मुश्किल हो जाता है कि कौनसी नीति गड़बड़ी की सही वजह है.

एपीआई मॉनिटरिंग के स्क्रीनशॉट में, देखा जा सकता है कि गड़बड़ी कोड और गड़बड़ी से जुड़ी नीति को सामान्य RaiseFault वैल्यू में बदल दिया गया है. इस वजह से, लॉग से गड़बड़ी की असल वजह का पता नहीं चल पा रहा है:

सबसे सही तरीका

जब किसी Edge की नीति में कोई गड़बड़ी होती है और आपको गड़बड़ी के जवाब देने वाले मैसेज को अपनी पसंद के मुताबिक बनाना होता है, तो दर्शाने के लिए समझौते के तौर पर सेट मैसेज या JavaScript की नीतियों का इस्तेमाल करें.

riseFault की नीति का इस्तेमाल बिना गड़बड़ी वाले फ़्लो में किया जाना चाहिए. इसका मतलब है कि किसी खास शर्त को गड़बड़ी के तौर पर इस्तेमाल करने के लिए, riseFault का इस्तेमाल करें. भले ही, किसी नीति या एपीआई प्रॉक्सी के बैकएंड सर्वर में कोई गड़बड़ी न हुई हो. उदाहरण के लिए, ShakeFault की नीति का इस्तेमाल करके, यह बताया जा सकता है कि ज़रूरी इनपुट पैरामीटर मौजूद नहीं हैं या उनका सिंटैक्स गलत है.

अगर आपको किसी गड़बड़ी को प्रोसेस करने के दौरान किसी गड़बड़ी का पता लगाना है, तो गड़बड़ी के नियम में भी riseFault का इस्तेमाल किया जा सकता है. उदाहरण के लिए, आपका गड़बड़ी हैंडलर अपने आप ही एक गड़बड़ी पैदा कर सकता है, जिसे आप riseFault का इस्तेमाल करके सिग्नल देना चाहते हैं.

इसके बारे में और पढ़ें

• गड़बड़ियां ठीक करना
• InsertFault की नीति
• गड़बड़ी से निपटने के तरीकों पर समुदाय में होने वाली चर्चा