आपको Apigee Edge दस्तावेज़ दिख रहा है.
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
इस पेज पर जाएं
Apigee X दस्तावेज़. जानकारी
RaiseFault की नीति की मदद से एपीआई डेवलपर, गड़बड़ी वाला फ़्लो शुरू कर सकते हैं और गड़बड़ी के वैरिएबल सेट कर सकते हैं
और सही प्रतिक्रिया स्थिति कोड सेट करें. आपके पास RaiseFault को
इस नीति की मदद से, गड़बड़ी से जुड़े फ़्लो वैरिएबल सेट किए जा सकते हैं. जैसे, fault.name, fault.type,
और fault.category. क्योंकि ये वैरिएबल, Analytics डेटा और राऊटर ऐक्सेस लॉग में दिखते हैं
इसका इस्तेमाल डीबग करने के लिए किया जाता है, तो गड़बड़ी की सही पहचान करना ज़रूरी है.
कुछ स्थितियों को गड़बड़ियों के तौर पर देखने के लिए, RaiseFault नीति का इस्तेमाल किया जा सकता है. भले ही, असल गड़बड़ी में
किसी अन्य नीति या API प्रॉक्सी के बैकएंड सर्वर में नहीं हुआ है. उदाहरण के लिए, अगर आपको
इस प्रॉक्सी की मदद से बैकएंड रिस्पॉन्स मिलने पर, क्लाइंट ऐप्लिकेशन को गड़बड़ी का कस्टम मैसेज भेजा जाता है
मुख्य हिस्से में 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 नीति का नाम, में fault.name के तौर पर दिखता है
एपीआई मॉनिटरिंग और Analytics और राऊटर के ऐक्सेस लॉग में x_apigee_fault_policy के तौर पर.
इससे गड़बड़ी की वजह का आसानी से पता लगाने में मदद मिलती है.
एंटीपैटर्न
अगर किसी नीति में पहले से ही गड़बड़ी हो, तो FaultRules में RaiseFault नीति का इस्तेमाल करना
नीचे दिए गए उदाहरण पर विचार करें. इसमें एपीआई प्रॉक्सी फ़्लो में, OAuthV2 नीति, InvalidAccessToken के साथ फ़ेल हुई है
गड़बड़ी. फ़ेल होने पर, Edge fault.name को InvalidAccessToken के तौर पर सेट कर देगा और
और तय किए गए FaultRules लागू करें. FaultRule में, RaiseFault की एक नीति है
RaiseFault, जो InvalidAccessToken होने पर पसंद के मुताबिक गड़बड़ी का जवाब भेजता है
कोई गड़बड़ी होती है. हालांकि, किसी गड़बड़ी के नियम में 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>
सभी स्थितियों में, गड़बड़ी के नियम में 'बढ़ाएं' नीति का इस्तेमाल करना
नीचे दिए गए उदाहरण में, RaiseFault नाम की RaiseFault नीति लागू होती है, अगर fault.name
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>
इंटेंट, अन्य नीतियों को प्रोसेस किए बिना एपीआई क्लाइंट को तुरंत रिस्पॉन्स देता है. हालांकि, इससे विश्लेषण का डेटा गुमराह करने वाला होगा, क्योंकि गड़बड़ी वाले वैरिएबल में riseFault नीति का नाम. इसकी वजह से, प्रॉक्सी को डीबग करना मुश्किल हो जाता है. लागू करने का सही तरीका आपकी इच्छा है कि आप 'flows' का इस्तेमाल खास शर्तों के साथ करें, जैसा कि सीओआरएस सहायता जोड़ना.
असर
ऊपर दी गई जानकारी के हिसाब से, RaiseFault की नीति का इस्तेमाल करने पर, गड़बड़ी के मुख्य वैरिएबल की जगह
काम न करने वाली नीति के नाम के बजाय, RaiseFault नीति का नाम लिखें. Analytics और NGINX ऐक्सेस लॉग में,
x_apigee_fault_code और x_apigee_fault_policy वैरिएबल
ओवरराइट हो जाते हैं. एपीआई मॉनिटरिंग में, Fault Code
और Fault Policy ओवरराइट हो जाते हैं. इस व्यवहार से समस्या हल करना और
यह पता लगाया जा सकता है कि किस नीति के उल्लंघन की वजह सही है.
नीचे दिए गए एपीआई मॉनिटरिंग के स्क्रीनशॉट में,
देखें कि गड़बड़ी कोड और गड़बड़ी से जुड़ी नीति, सामान्य RaiseFault में बदल दी गई है
वैल्यू दी गई हैं, जिससे लॉग से गड़बड़ी की असल वजह का पता लगाना मुश्किल हो जाता है:
सबसे सही तरीका
जब Edge नीति में कोई गड़बड़ी होती है और आपको गड़बड़ी के रिस्पॉन्स वाले मैसेज को पसंद के मुताबिक बनाना होता है, तो RaiseFault नीति के बजाय, Tasks मैसेज या JavaScript की नीतियों का इस्तेमाल करें.
RaiseFault की नीति का इस्तेमाल बिना गड़बड़ी वाले फ़्लो में किया जाना चाहिए. इसका मतलब है कि RaiseFault को सिर्फ़ किसी खास स्थिति में गड़बड़ी हुई है, भले ही नीति या बैकएंड सर्वर में कोई असल गड़बड़ी न हुई हो एपीआई प्रॉक्सी की ज़रूरत नहीं है. उदाहरण के लिए, RaiseFault नीति का इस्तेमाल करके यह बताया जा सकता है कि इनपुट में ज़रूरी पैरामीटर मौजूद नहीं हैं या उनका सिंटैक्स गलत है.
अगर आपको किसी गड़बड़ी के बारे में जानकारी चाहिए, तो गड़बड़ी. उदाहरण के लिए, आपके गड़बड़ी हैंडलर की वजह से ऐसी गड़बड़ी हो सकती है जिसे आपको RaiseFault का इस्तेमाल करके दिखाना हो.