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

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

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

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

<!-- /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 नीति का नाम, API मॉनिटरिंग में fault.name के तौर पर दिखता है. साथ ही, Analytics और राऊटर के ऐक्सेस लॉग में x_apigee_fault_policy के तौर पर दिखता है. इससे गड़बड़ी की वजह का आसानी से पता लगाने में मदद मिलती है.

ऐंटीपैटर्न

किसी दूसरी नीति से पहले ही गड़बड़ी होने के बाद, FaultRules में RaiseFault नीति का इस्तेमाल करना

यहां दिए गए उदाहरण में, एपीआई प्रॉक्सी फ़्लो में OAuthV2 नीति का पालन नहीं किया गया है. इसलिए, InvalidAccessToken गड़बड़ी हुई है. अगर ऐसा नहीं होता है, तो Edge, fault.name को InvalidAccessToken के तौर पर सेट कर देगा. साथ ही, गड़बड़ी वाले फ़्लो में चला जाएगा और तय की गई किसी भी FaultRule को लागू करेगा. FaultRule में, RaiseFault नीति है. इसका नाम RaiseFault है. यह InvalidAccessToken गड़बड़ी होने पर, गड़बड़ी का कस्टम जवाब भेजती है. हालांकि, FaultRule में RaiseFault नीति का इस्तेमाल करने का मतलब है कि 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>

सभी स्थितियों में, FaultRule के तहत RaiseFault नीति का इस्तेमाल करना

यहां दिए गए उदाहरण में, अगर fault.name RaiseFault नहीं है, तो 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 को RaiseFault नीति के नाम से बदल दिया जाता है. इस वजह से, यह पता लगाना मुश्किल हो जाता है कि किस नीति की वजह से गड़बड़ी हुई है. इसके लिए, गड़बड़ी दिखाने वाली ट्रेस फ़ाइल को ऐक्सेस करना या समस्या को फिर से दोहराना ज़रूरी होता है.

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

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

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

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

असर

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

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

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

जब Edge की कोई नीति गड़बड़ी करती है और आपको गड़बड़ी के जवाब के मैसेज में बदलाव करना होता है, तो RaiseFault नीति के बजाय AssignMessage या JavaScript नीतियों का इस्तेमाल करें.

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

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

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

• समस्याएं हल करना
• RaiseFault नीति
• गड़बड़ी ठीक करने के पैटर्न पर कम्यूनिटी में चर्चा