गड़बड़ियों को ठीक करना

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

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

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

कस्टम फ़ॉल्ट हैंडलिंग की मदद से, मैसेज लॉग करने जैसी सुविधाएं भी जोड़ी जा सकती हैं. ऐसा तब किया जाता है, जब कोई गड़बड़ी होती है.

इससे पहले कि हम आपकी एपीआई प्रॉक्सी में गड़बड़ी को ठीक करने के लिए कस्टम तरीके लागू करने के बारे में बात करें, यह समझना ज़रूरी है कि गड़बड़ियां कैसे होती हैं और एपीआई प्रॉक्सी उन पर कैसे प्रतिक्रिया करती हैं.

वीडियो

गड़बड़ी ठीक करने के बारे में ज़्यादा जानने के लिए, यहां दिए गए वीडियो देखें.

गड़बड़ियां कैसे होती हैं

सबसे पहले, हम यह बताएंगे कि गड़बड़ियां कैसे होती हैं. गड़बड़ियां कैसे होती हैं, यह जानने से आपको उन अलग-अलग स्थितियों के लिए प्लान बनाने में मदद मिलती है जिनमें आपको गड़बड़ी को मैनेज करने की कस्टम सुविधा लागू करनी है.

अपने-आप होने वाली गड़बड़ियां

एपीआई प्रॉक्सी इन स्थितियों में अपने-आप गड़बड़ी का मैसेज दिखाती है:

• किसी नीति में गड़बड़ी हुई है. उदाहरण के लिए, अगर कोई एपीआई कॉल ऐसी कुंजी भेजता है जिसकी समयसीमा खत्म हो चुकी है, तो VerifyAPIKey नीति अपने-आप गड़बड़ी का मैसेज दिखाती है. इसके अलावा, अगर एपीआई कॉल की संख्या किसी तय सीमा से ज़्यादा हो जाती है, तो Quota नीति या SpikeArrest नीति गड़बड़ी का मैसेज दिखाती है. (नीतियों के उल्लंघन से जुड़ी गड़बड़ियों के बारे में जानने के लिए, नीति के उल्लंघन से जुड़ी गड़बड़ियों के रेफ़रंस देखें).
• एपीआई प्रॉक्सी के मैसेज फ़्लो में कोई समस्या है. जैसे, राउटिंग से जुड़ी गड़बड़ी.
• बैकएंड में कोई गड़बड़ी हुई है. जैसे, प्रोटोकॉल लेवल की गड़बड़ियों, टीएलएस/एसएसएल गड़बड़ियों या टारगेट सेवा के उपलब्ध न होने की वजह से एचटीटीपी गड़बड़ी हुई है.
• सिस्टम लेवल पर कोई गड़बड़ी हुई है. जैसे, मेमोरी खत्म होने की वजह से कोई अपवाद.

इन गड़बड़ियों के बारे में ज़्यादा जानने के लिए, इस विषय में गड़बड़ी की टैक्सोनॉमी देखें.

कस्टम गड़बड़ियां

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

किसी एपीआई प्रॉक्सी फ़्लो में RaiseFault नीति को उसी तरह जोड़ा जा सकता है जिस तरह कोई दूसरी नीति जोड़ी जाती है. प्रॉक्सी कॉन्फ़िगरेशन के इस उदाहरण में, Raise-Fault-1 नीति को TargetEndpoint रिस्पॉन्स से जोड़ा गया है. अगर टारगेट सेवा से मिले जवाब में "unavailable" शब्द मौजूद है, तो RaiseFault नीति लागू हो जाती है और गड़बड़ी दिखती है.

<TargetEndpoint name="default">
...
  <Response>
    <Step>
      <Name>Raise-Fault-1</Name>
      <Condition>(message.content Like "*unavailable*")</Condition>
    </Step>
  </Response>

यह सिर्फ़ आपको यह दिखाने के लिए है कि कस्टम गड़बड़ियां थ्रो की जा सकती हैं. हमने FaultRules vs. the RaiseFault policy सेक्शन में, RaiseFault नीति के बारे में ज़्यादा जानकारी दी है.

ज़्यादा उदाहरणों के लिए, Apigee कम्यूनिटी फ़ोरम पर ये पोस्ट देखें:

• RaiseFault में JavaScript वैरिएबल को रेफ़रंस करना

गड़बड़ियां होने पर एपीआई प्रॉक्सी क्या करती हैं

यहां बताया गया है कि प्रॉक्सी से गड़बड़ी होने पर क्या होता है.

प्रॉक्सी पाइपलाइन से बाहर निकलें

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

उदाहरण के लिए, मान लें कि किसी एपीआई प्रॉक्सी में ProxyEndpoint अनुरोध में, नीतियां इस क्रम में हैं:

1. एपीआई पासकोड की पुष्टि करना
2. अनुरोध भेजने की तय सीमा
3. JSON से XML

अगर एपीआई पासकोड की पुष्टि करने के दौरान कोई गड़बड़ी होती है, तो एपीआई प्रॉक्सी गड़बड़ी की स्थिति में चली जाती है. कोटा और JSON से XML में बदलने की नीतियां लागू नहीं होती हैं. प्रॉक्सी, TargetEndpoint पर नहीं जाती है. साथ ही, क्लाइंट ऐप्लिकेशन को गड़बड़ी का मैसेज दिखता है.

FaultRules की जांच करना

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

1. <FaultRules> सेक्शन, जिसमें आपकी तय की गई शर्तों के आधार पर, गड़बड़ी के कस्टम मैसेज (और अन्य नीतियां) ट्रिगर करने का लॉजिक होता है.
2. एक <DefaultFaultRule> सेक्शन, जो इन स्थितियों में गड़बड़ी का डिफ़ॉल्ट मैसेज ट्रिगर करता है:
   • कोई <FaultRules> तय नहीं किया गया है.
   • कोई भी मौजूदा <FaultRules> लागू नहीं होता.
   • <AlwaysEnforce> एलिमेंट को सही पर सेट किया गया है.

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

गड़बड़ी ठीक करने का सामान्य उदाहरण

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

HTTP/1.1 401 Unauthorized
Date: Wed, 20 Jul 2016 19:19:32 GMT
Content-Type: application/json
Content-Length: 150
Connection: keep-alive
Server: Apigee Router

* Connection #0 to host myorg-test.apigee.net left intact
{"fault":{"faultstring":"Failed to resolve API Key variable request.queryparam.apikey","detail":{"errorcode":"steps.oauth.v2.FailedToResolveAPIKey"}}}

आपके एपीआई उपयोगकर्ताओं को गड़बड़ी के मैसेज के बारे में पता चल सकता है, लेकिन ऐसा हो सकता है कि उन्हें इसके बारे में पता न चले. साथ ही, कई डिफ़ॉल्ट गड़बड़ियां ज़्यादा मुश्किल होती हैं और उन्हें समझना मुश्किल होता है.

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

यहां इस गड़बड़ी को ठीक करने के लिए, कस्टम गड़बड़ी का मैसेज बनाने का एक बुनियादी उदाहरण दिया गया है. इसके लिए, 1) एक ऐसी नीति की ज़रूरत होती है जो कस्टम मैसेज तय करती है. साथ ही, 2) एक ऐसे FaultRule की ज़रूरत होती है जो प्रॉक्सी के गड़बड़ी की स्थिति में जाने पर नीति को लागू करता है.

1. कस्टम मैसेज के लिए नीति बनाना

सबसे पहले, ऐसी नीति बनाएं जिसमें कस्टम गड़बड़ी के मैसेज के बारे में बताया गया हो. किसी भी तरह की नीति का इस्तेमाल किया जा सकता है. जैसे, AssignMessage नीति. यह नीति, पेलोड और स्टेटस कोड और वजह बताने वाले वाक्यांश जैसे वैकल्पिक एचटीटीपी हेडर सेट कर सकती है. इसके लिए, मैसेज असाइन करने की सुविधा सबसे सही है. इसकी मदद से, मैसेज पेलोड को कंट्रोल किया जा सकता है. साथ ही, अलग-अलग एचटीटीपी स्टेटस कोड, एचटीटीपी की वजह बताने वाला अलग वाक्यांश सेट किया जा सकता है. इसके अलावा, एचटीटीपी हेडर जोड़े जा सकते हैं.

नीति को एपीआई प्रॉक्सी में किसी भी फ़्लो से न जोड़ें. यह ज़रूरी नहीं है कि यह प्रॉक्सी बंडल में मौजूद हो. मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में ऐसा करने के लिए, Develop टैब पर जाएं. इसके बाद, नेविगेशन पैनल में जाकर, Policies बार पर मौजूद + आइकॉन पर क्लिक करें.

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

यहां AssignMessage नीति का एक उदाहरण दिया गया है, जिसमें:

• JSON मैसेज दिखाता है.
• यह कुकी, एचटीटीपी स्टेटस कोड (911, जो कि एक ऐसा स्टेटस कोड है जो मौजूद नहीं है. इसे सिर्फ़ यह दिखाने के लिए इस्तेमाल किया गया है कि आपके पास कितनी तरह के विकल्प हैं) सेट करती है. स्टेटस कोड, एचटीटीपी हेडर में दिखता है.
• यह एचटीटीपी वजह का वाक्यांश सेट करता है. इसका इस्तेमाल, एपीआई कुंजी मौजूद न होने की वजह से हुई गड़बड़ी के लिए, डिफ़ॉल्ट रूप से इस्तेमाल होने वाले "अधिकार नहीं है" वाक्यांश को बदलने के लिए किया जाता है. वजह बताने वाला वाक्यांश, एचटीटीपी हेडर में स्टेटस कोड के बगल में दिखता है.
• यह invalidKey नाम का नया एचटीटीपी हेडर बनाता है और उसे भरता है.

<AssignMessage async="false" continueOnError="false" enabled="true" name="invalid-key-message">
    <DisplayName>Invalid key message</DisplayName>
    <Set>
        <Payload contentType="application/json">{"Citizen":"Where's your API key? I don't see it as a query parameter"}</Payload>
        <StatusCode>911</StatusCode>
        <ReasonPhrase>Rejected by API Key Emergency Services</ReasonPhrase>
    </Set>
    <Add>
        <Headers>
            <Header name="invalidKey">Invalid API key! Call the cops!</Header>
        </Headers>
    </Add>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

इस नीति के लागू होने पर, क्लाइंट ऐप्लिकेशन को मिलने वाला जवाब ऐसा दिखेगा. इसकी तुलना, पहले दिखाए गए डिफ़ॉल्ट जवाब से करें.

HTTP/1.1 911 Rejected by API Key Emergency Services
Date: Wed, 20 Jul 2016 18:42:36 GMT
Content-Type: application/json
Content-Length: 35
Connection: keep-alive
invalidKey: Invalid API key! Call the cops!
Server: Apigee Router

* Connection #0 to host myorg-test.apigee.net left intact
{"Citizen":"Where's your API key? I don't see it as a query parameter."}

हां, यह थोड़ा अजीब है, लेकिन इससे आपको पता चलता है कि क्या-क्या किया जा सकता है. कम से कम अब मैसेज पाने वाले डेवलपर को यह पता चल गया है कि वह क्वेरी पैरामीटर के तौर पर एपीआई पासकोड शामिल करना भूल गया है.

हालांकि, इस नीति को लागू कैसे किया जाता है? अगले सेक्शन में आपको यह जानकारी मिलेगी.

2. ऐसी <FaultRule> बनाएं जो नीति को ट्रिगर करेगी

प्रॉक्सी कॉन्फ़िगरेशन के <ProxyEndpoint> या <TargetEndpoint> सेक्शन में, आपको <FaultRules> एक्सएमएल ब्लॉक जोड़ना होगा. इसमें एक या उससे ज़्यादा <FaultRule> सेक्शन शामिल होते हैं. हर FaultRule, उस अलग गड़बड़ी को दिखाता है जिसे आपको ठीक करना है. इस आसान उदाहरण में, हम सिर्फ़ एक FaultRule का इस्तेमाल करेंगे. इससे आपको पता चलेगा कि यह किन चीज़ों से मिलकर बना है.

अगर आपकी कोई भी FaultRule लागू नहीं होती है, तो आपको <DefaultFaultRule> भी जोड़ना चाहिए, ताकि गड़बड़ी का कस्टम मैसेज दिखाया जा सके.

उदाहरण

<ProxyEndpoint name="default">
...
    <FaultRules>
       <FaultRule name="invalid_key_rule">
            <Step>
                <Name>invalid-key-message</Name>
            </Step>
            <Condition>(fault.name = "FailedToResolveAPIKey")</Condition>
        </FaultRule>
    </FaultRules>
    <DefaultFaultRule name="default-fault">
        <Step>
            <Name>Default-message</Name>
        </Step>
    </DefaultFaultRule>

खास बातें:

• FaultRules को ProxyEndpoint में तय किया जाता है. यह ज़रूरी है. बाद में, ProxyEndpoint और TargetEndpoint में FaultRules डालने के बारे में ज़्यादा जानकारी.
• <Name> - लागू की जाने वाली नीति का नाम. यह नाम, पैरंट एलिमेंट पर मौजूद नीति के name एट्रिब्यूट से मिलता है. इसे नीति के उदाहरण में दिखाया गया है.

• <Condition> - Edge, शर्त का आकलन करता है और नीति को सिर्फ़ तब लागू करता है, जब शर्त सही हो. अगर कई FaultRule सही के तौर पर नतीजे देते हैं, तो Edge उस FaultRule को लागू करता है जो सबसे पहले सही के तौर पर नतीजे देता है. (अहम जानकारी: एक से ज़्यादा FaultRule और उन्हें लागू करने का लॉजिक सेक्शन में बताया गया है कि TargetEndpoint और ProxyEndpoint में, FaultRule का आकलन करने का क्रम अलग-अलग होता है. यह क्रम ऊपर से नीचे या नीचे से ऊपर की ओर होता है.) अगर आपने कोई शर्त शामिल नहीं की है, तो FaultRule अपने-आप सही हो जाता है. हालांकि, यह सबसे सही तरीका नहीं है. हर FaultRule की अपनी शर्त होनी चाहिए.

• <DefaultFaultRule> - अगर कोई कस्टम FaultRule लागू नहीं होता है, तो <DefaultFaultRule> लागू होता है. इससे Edge की ओर से जनरेट किए गए मुश्किल मैसेज के बजाय, ज़्यादा सामान्य कस्टम मैसेज भेजा जाता है. <DefaultFaultRule> में <Condition> भी हो सकता है. हालांकि, ज़्यादातर मामलों में इसे शामिल नहीं किया जाता, क्योंकि आपको इसे आखिरी विकल्प के तौर पर इस्तेमाल करना होता है.

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

कई FaultRule और एक्ज़ीक्यूशन लॉजिक

गड़बड़ी ठीक करने के आसान उदाहरण सेक्शन में, हमने एक FaultRule और शर्त का आसान उदाहरण इस्तेमाल किया है. किसी एपीआई प्रोजेक्ट में, होने वाली सभी संभावित गड़बड़ियों के साथ, आपके पास कई FaultRule और <ProxyEndpoint> और <TargetEndpoint>, दोनों में एक DefaultFaultRule होने की संभावना होती है. हालांकि, आखिर में जब एपीआई प्रॉक्सी में गड़बड़ी होती है, तब सिर्फ़ एक FaultRule लागू होता है.

इस सेक्शन में, Edge के फ़ॉल्ट रूल को मैनेज करने के लॉजिक के बारे में बताया गया है. इसमें यह जानकारी शामिल है कि Edge, फ़ॉल्ट रूल को कैसे लागू करता है. साथ ही, इसमें यह भी बताया गया है कि फ़ॉल्ट रूल ट्रिगर होने पर, "इनर" स्टेप की शर्तों को कैसे मैनेज किया जाता है. इस सेक्शन में यह भी बताया गया है कि <ProxyEndpoint> में FaultRules कब तय किए जाने चाहिए और <TargetEndpoint> में कब. साथ ही, इसमें FaultRules और RaiseFault नीति के बीच के संबंध के बारे में बताया गया है.

FaultRules का एक्ज़ीक्यूशन

संक्षेप में, यहां बताया गया है कि जब कोई एपीआई प्रॉक्सी गड़बड़ी की स्थिति में चली जाती है, तो Edge किस लॉजिक का इस्तेमाल करता है. ध्यान दें कि ProxyEndpoint और TargetEndpoint में FaultRules के आकलन में थोड़ा अंतर होता है.

1. गड़बड़ी कहां हुई, इसके आधार पर Edge, ProxyEndpoint या TargetEndpoint में FaultRules का आकलन करता है:
   • ProxyEndpoint - Edge, कॉन्फ़िगरेशन एक्सएमएल में bottom <FaultRule> से शुरू होता है और ऊपर की ओर बढ़ता है. इस दौरान, वह हर <FaultRule> के <Condition> का आकलन करता है. यह "आउटर" शर्त होती है, "इनर" <Step> शर्तें नहीं.
   • TargetEndpoint - Edge, कॉन्फ़िगरेशन एक्सएमएल में top <FaultRule> से शुरू होता है और नीचे की ओर बढ़ता है. साथ ही, हर <FaultRule> के <Condition> का आकलन करता है. यह "आउटर" शर्त होती है, न कि "इनर" <Step> शर्तें.
2. यह उस पहले FaultRule को लागू करता है जिसकी शर्त पूरी होती है. अगर किसी FaultRule में कोई शर्त नहीं है, तो डिफ़ॉल्ट रूप से यह सही होती है.
   • जब कोई FaultRule लागू होता है, तो FaultRule में मौजूद सभी चरणों का आकलन क्रम से किया जाता है. ये चरण, एक्सएमएल कॉन्फ़िगरेशन में ऊपर से नीचे की ओर होते हैं. शर्तों के बिना वाले चरण अपने-आप लागू हो जाते हैं (नीतियों को लागू किया जाता है). साथ ही, जिन चरणों में <Condition> की वैल्यू "true" होती है वे भी लागू हो जाते हैं. जिन शर्तों की वैल्यू "false" होती है वे लागू नहीं होती हैं.

   • अगर कोई FaultRule लागू होता है, लेकिन FaultRule में कोई भी चरण लागू नहीं होता है (क्योंकि उनकी शर्तें "false" के तौर पर तय होती हैं), तो Edge से जनरेट किया गया डिफ़ॉल्ट गड़बड़ी का मैसेज, क्लाइंट ऐप्लिकेशन को वापस भेज दिया जाता है. <DefaultFaultRule> लागू नहीं होता, क्योंकि Edge पहले ही अपना एक FaultRule लागू कर चुका है.

3. अगर कोई FaultRule लागू नहीं होता है, तो Edge, <DefaultFaultRule> को लागू करता है. हालांकि, ऐसा सिर्फ़ तब होता है, जब <DefaultFaultRule> मौजूद हो.

यहां इनलाइन टिप्पणियों के साथ उदाहरण दिए गए हैं.

ProxyEndpoint को लागू करना

ProxyEndpoint की FaultRule का आकलन नीचे से ऊपर की ओर होता है. इसलिए, यहां दिए गए सैंपल में सबसे आखिर वाली FaultRule से पढ़ना शुरू करें और ऊपर की ओर बढ़ते जाएं. DefaultFaultRule को आखिर में देखें.

<ProxyEndpoint name="default">
...
    <FaultRules>
<!-- 3. This FaultRule is automatically TRUE, because there's no "outer"
     condition. But because the FaultRule just below this got
     executed (bottom-to-top evaluation in a ProxyEndpoint), Edge
     doesn't even evaluate this FaultRule.
     Note that it's not a best practice to have a FaultRule without
     an outer condition, which automatically makes the FaultRule true. -->
        <FaultRule name="random-error-message">
            <Step>
                <Name>Random-fault</Name>
            </Step>
        </FaultRule>
<!-- 2. Let's say this fault is TRUE. The Quota policy threw a QuotaViolation
     error. This is the first FaultRule to be TRUE, so it's executed.
     Now the Steps are evaluated, and for the ones whose conditions
     evaluate to TRUE, their policies are executed. Steps without
     conditions are automatically true. -->
<FaultRule name="over_quota">
            <Step>
                <Name>developer-over-quota-fault</Name>
                <Condition>(ratelimit.developer-quota-policy.exceed.count GreaterThan "0")</Condition>
            </Step>
            <Step>
                <Name>global-over-quota-fault</Name>
                <Condition>(ratelimit.global-quota-policy.exceed.count GreaterThan "0")</Condition>
            </Step>
            <Step>
                <Name>log-error-message</Name>
            </Step>
            <Condition>(fault.name = "QuotaViolation")</Condition>
        </FaultRule>
<!-- 1. Because this is the ProxyEndpoint, Edge looks at this FaultRule
     first. But let's say this FaultRule is FALSE. A policy did not
     throw a FailedToResolveAPIKey error. Edge moves UP to check
     the next FaultRule. -->
        <FaultRule name="invalid_key_rule">
            <Step>
                <Name>invalid-key-message</Name>
            </Step>
            <Condition>(fault.name = "FailedToResolveAPIKey")</Condition>
        </FaultRule>
    </FaultRules>

<!-- If no <FaultRule> is executed, the <DefaultFaultRule> is executed.
     If a FaultRule is executed, but none of its Steps are executed,
     The DefaultFaultRule is not executed (because Edge has already
     executed its one FaultRule). -->
    <DefaultFaultRule name="default-fault">
        <Step>
            <Name>Default-message</Name>
        </Step>
    </DefaultFaultRule>

TargetEndpoint को लागू करना

TargetEndpoint की FaultRules का आकलन ऊपर से नीचे की ओर किया जाता है. इसलिए, यहां दिए गए सैंपल में पहली FaultRule से पढ़ना शुरू करें और नीचे तक पढ़ें. DefaultFaultRule को आखिर में देखें.

<TargetEndpoint name="default">
...
    <FaultRules>
<!-- 1. Because this is the TargetEndpoint, Edge looks at this FaultRule
     first. Let's say this FaultRule is FALSE.
     A policy did not throw a FailedToResolveAPIKey error.
     Edge moves down to the next FaultRule. -->
        <FaultRule name="invalid_key_rule">
            <Step>
                <Name>invalid-key-message</Name>
            </Step>
            <Condition>(fault.name = "FailedToResolveAPIKey")</Condition>
        </FaultRule>
<!-- 2. Let's say this fault is TRUE. The Quota policy threw a QuotaViolation
     error. This is the first FaultRule to be TRUE, so it's executed.
     Now the Steps are evaluated, and for the ones whose conditions
     evaluate to TRUE, their policies are executed. Steps without
     conditions are automatically true. -->
        <FaultRule name="over_quota">
            <Step>
                <Name>developer-over-quota-fault</Name>
                <Condition>(ratelimit.developer-quota-policy.exceed.count GreaterThan "0")</Condition>
            </Step>
            <Step>
                <Name>global-over-quota-fault</Name>
                <Condition>(ratelimit.global-quota-policy.exceed.count GreaterThan "0")</Condition>
            </Step>
            <Step>
                <Name>log-error-message</Name>
            </Step>
            <Condition>(fault.name = "QuotaViolation")</Condition>
        </FaultRule>
<!-- 3. This FaultRule is automatically TRUE, because there's no "outer"
     condition. But because the FaultRule just above this got
     executed (top-to-bottom evaluation in a TargetEndpoint), Edge
     doesn't even evaluate this FaultRule.
     Note that it's not a best practice to have a FaultRule without
     an outer condition, which automatically makes the FaultRule true. -->
        <FaultRule name="random-error-message">
            <Step>
                <Name>Random-fault</Name>
            </Step>
        </FaultRule>
    </FaultRules>

<!-- If no <FaultRule> is executed, the <DefaultFaultRule> is executed.
     If a FaultRule is executed, but none of its Steps are executed,
     The DefaultFaultRule is not executed (because Edge has already
     executed its one FaultRule). -->
    <DefaultFaultRule name="default-fault">
        <Step>
            <Name>Default-message</Name>
        </Step>
    </DefaultFaultRule>

फ़ॉल्ट के नियम का क्रम

पिछले उदाहरण में देखा जा सकता है कि आपकी FaultRule किस क्रम में रखी गई हैं. यह इस बात पर निर्भर करता है कि गड़बड़ी ProxyEndpoint में हुई है या TargetEndpoint में.

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

शामिल की जाने वाली नीतियां

FaultRule से किसी भी नीति को लागू किया जा सकता है. इसके लिए, उन्हें Steps में रखें. उदाहरण के लिए, क्लाइंट ऐप्लिकेशन को जवाब देने के लिए, AssignMessage नीति लागू की जा सकती है. इसके बाद, MessageLogging नीति का इस्तेमाल करके मैसेज लॉग किया जा सकता है. नीतियों को उसी क्रम में लागू किया जाता है जिस क्रम में उन्हें रखा गया है (एक्सएमएल में ऊपर से नीचे की ओर).

गड़बड़ी होने पर ही फ़ॉल्ट के नियम ट्रिगर होते हैं (continueOnError के बारे में)

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

संक्षेप में: एपीआई प्रॉक्सी, <FaultRules> और <DefaultFaultRule> का आकलन सिर्फ़ तब करती है, जब प्रॉक्सी में गड़बड़ी हुई हो. इसका मतलब है कि अगर FaultRule की कोई शर्त सही होती है, तब भी यह ट्रिगर नहीं होगी. ऐसा तब होता है, जब प्रॉक्सी में कोई गड़बड़ी नहीं होती.

हालांकि, यहां गड़बड़ी होने का एक उदाहरण दिया गया है. इसमें प्रॉक्सी, गड़बड़ी वाली स्थिति में नहीं जाती है. किसी भी नीति के लिए, पैरंट एलिमेंट पर continueOnError नाम का एट्रिब्यूट सेट किया जा सकता है. गड़बड़ी ठीक करने के लिए, यह एट्रिब्यूट बहुत ज़रूरी है. इसकी वजह यह है कि इससे यह तय होता है कि नीति का पालन न होने पर, प्रॉक्सी गड़बड़ी की स्थिति में पहुंचता है या नहीं. ज़्यादातर मामलों में, आपको डिफ़ॉल्ट continueOnError="false" को चालू रखना होगा. इससे नीति का पालन न होने पर, प्रॉक्सी में गड़बड़ी की स्थिति आ जाती है. साथ ही, गड़बड़ी को ठीक करने के लिए, आपके कस्टम तरीके का इस्तेमाल किया जाता है. हालांकि, अगर continueOnError="true" (उदाहरण के लिए, अगर आपको सर्विस कॉलआउट के फ़ेल होने पर प्रॉक्सी के एक्ज़ीक्यूशन को रोकना नहीं है), तो नीति के फ़ेल होने पर प्रॉक्सी, गड़बड़ी की स्थिति में नहीं जाएगी. साथ ही, प्रॉक्सी आपकी FaultRules को नहीं देखेगी.

continueOnError="true" के दौरान गड़बड़ियों को लॉग करने के बारे में जानकारी के लिए, मौजूदा फ़्लो में नीति से जुड़ी गड़बड़ियों को ठीक करना लेख पढ़ें.

FaultRules को कहां तय करें: ProxyEndpoint या TargetEndpoint

जब किसी एपीआई प्रॉक्सी में गड़बड़ी होती है, तो यह गड़बड़ी <ProxyEndpoint> (क्लाइंट ऐप्लिकेशन से अनुरोध या उसे जवाब) या <TargetEndpoint> (टारगेट सेवा से अनुरोध या उससे जवाब) में होती है. जहां भी यह गड़बड़ी होती है, Edge वहां FaultRules ढूंढता है.

उदाहरण के लिए, अगर टारगेट सर्वर उपलब्ध नहीं है (एचटीटीपी स्टेटस कोड 503), तो एपीआई प्रॉक्सी, <TargetEndpoint> रिस्पॉन्स में गड़बड़ी की स्थिति में चली जाएगी. साथ ही, सामान्य एपीआई प्रॉक्सी फ़्लो, <ProxyEndpoint> तक जारी नहीं रहेगा. अगर आपने <ProxyEndpoint> में सिर्फ़ FaultRules तय किए हैं, तो वे उस गड़बड़ी को ठीक नहीं करेंगे.

यहां एक और उदाहरण दिया गया है. अगर <ProxyEndpoint> रिस्पॉन्स पर मौजूद RaiseFault नीति से कोई गड़बड़ी ट्रिगर होती है, तो <TargetEndpoint> में मौजूद कोई भी FaultRule लागू नहीं होगा.

FaultRules और RaiseFault नीति के बीच अंतर

गड़बड़ी के नियमों और RaiseFault नीति को देखने पर, ऐसा लग सकता है कि ये गड़बड़ी को ठीक करने के वैकल्पिक तरीके हैं. कुछ मामलों में यह बात सही भी है. हालांकि, ये दोनों एक साथ भी काम करते हैं. इस सेक्शन में, दोनों के बीच के संबंध के बारे में बताया गया है. इन दोनों के बीच के संबंध को समझने से, आपको गड़बड़ी ठीक करने की सुविधा डिज़ाइन करने में मदद मिलेगी. खास तौर पर, अगर आपको दोनों का इस्तेमाल करना है.

संक्षेप में:

• जब एपीआई प्रॉक्सी में कोई गड़बड़ी होती है, तब गड़बड़ी के नियम हमेशा लागू होते हैं.

• RaiseFault नीति का इस्तेमाल करके, एपीआई प्रॉक्सी को गड़बड़ी वाली स्थिति में रखा जा सकता है. ऐसा तब किया जाता है, जब गड़बड़ी होने की कोई वजह न हो.

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

  <TargetEndpoint name="default">
      <PreFlow name="PreFlow">
  ...
          <Response>
              <Step>
                  <Name>Raise-Fault-1</Name>
  <!-- If the condition is true, the Raise-Fault-1 policy gets executed -->
                  <Condition>(response.status.code GreaterThan "200")</Condition>
              </Step>
          </Response>

  RaiseFault नीति, क्लाइंट ऐप्लिकेशन को गड़बड़ी का मैसेज भी भेजती है.

जब RaiseFault नीति, गड़बड़ी को ट्रिगर करती है, तो प्रॉक्सी गड़बड़ी की स्थिति में आ जाती है. इससे FaultRule लागू हो सकता है. यहाँ कुछ चीज़ें थोड़ी मुश्किल हो सकती हैं. अगर RaiseFault नीति से गड़बड़ी का मैसेज मिलता है और कोई FaultRule ट्रिगर होता है और उससे गड़बड़ी का मैसेज मिलता है, तो क्लाइंट ऐप्लिकेशन को क्या मिलता है?

• FaultRule या DefaultFaultRule, RaiseFault नीति के बाद लागू होती है. इसलिए, FaultRule के जवाब का डेटा इस्तेमाल किया जाता है.
• RaiseFault नीति के जवाब के डेटा (स्थिति कोड, वजह बताने वाला वाक्यांश या मैसेज पेलोड) का इस्तेमाल तब किया जाता है, जब उस डेटा को FaultRule या DefaultFaultRule सेट नहीं करता है.
• अगर RaiseFault नीति और FaultRule, दोनों कस्टम एचटीटीपी हेडर जोड़ते हैं, तो दोनों को रिस्पॉन्स में शामिल किया जाता है. हेडर के नाम डुप्लीकेट होने पर, एक से ज़्यादा वैल्यू वाला हेडर बन जाता है.

यहां RaiseFault नीति और FaultRule के ज़रिए सेट की गई जानकारी का एक उदाहरण दिया गया है. साथ ही, यह भी बताया गया है कि क्लाइंट ऐप्लिकेशन को क्या जानकारी मिलती है. ये सैंपल, सबसे सही तरीकों के लिए नहीं, बल्कि कम शब्दों में जानकारी देने के लिए डिज़ाइन किए गए हैं.

Status Code: 468
Reason Phrase: Something happened
Payload: {"Whoa":"Sorry."}
Header:
  errorNote: woops,gremlins

Status Code: [none]
Reason Phrase: Something happened
Payload: {"Whoa":"Sorry."}
Header:
  errorNote: gremlins

Status Code: 468
Reason Phrase: Can't do that
Payload: {"DOH!":"Try again."}
Header:
  errorNote: woops

शर्तें तय करना

FaultRule को लागू करने के लिए, शर्तें ज़रूरी होती हैं. Edge में, FaultRule की शर्तें उसी तरह बनाई जाती हैं जिस तरह अन्य शर्तें बनाई जाती हैं. जैसे, कंडिशनल फ़्लो या RaiseFault की शर्तें.

इस सेक्शन के बाकी हिस्से को समझने के लिए, यहां गड़बड़ी से जुड़े नियम का एक सैंपल दिया गया है. इसमें बाहरी FaultRule की शर्त और अंदरूनी Step की शर्त शामिल है.

<FaultRule name="invalid_key_rule">
    <Step>
        <Name>invalid-key-message</Name>
        <Condition>(oauthV2.Verify-API-Key-1.failed = true)</Condition>
    </Step>
    <Condition>(fault.name = "FailedToResolveAPIKey")</Condition>
</FaultRule>

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

fault.name और {policy_namespace}.{policy_name}.failed वैरिएबल तब उपलब्ध होते हैं, जब कोई नीति गड़बड़ी दिखाती है.

fault.name

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

<Condition>(fault.name = "policy_error_name")</Condition>

गड़बड़ी का नाम, गड़बड़ी के डिफ़ॉल्ट मैसेज में दिखता है. उदाहरण के लिए, यहां फ़ॉल्ट का नाम FailedToResolveAPIKey है. इस मामले में, fault.name नाम के फ़्लो वैरिएबल को FailedToResolveAPIKey वैल्यू पर सेट किया जाता है.

{"fault":{"faultstring":"Failed to resolve API Key variable request.queryparam.apikey","detail":{"errorcode":"steps.oauth.v2.FailedToResolveAPIKey"}}}

इसलिए, शर्त कुछ इस तरह दिखेगी:

<Condition>(fault.name = "FailedToResolveAPIKey")</Condition>

नीति से जुड़ी गड़बड़ियों की सूची देखने के लिए, नीति से जुड़ी गड़बड़ियों का रेफ़रंस देखें.

{policy_namespace}.{policy_name}.failed

नीति के उल्लंघन का पता चलने पर, *.failed वैरिएबल उपलब्ध होता है. अलग-अलग नीतियों के लिए, *.failed वैरिएबल के उदाहरण यहां दिए गए हैं. नीति के नेमस्पेस के लिए, हर नीति के रेफ़रंस विषय में फ़्लो वैरिएबल देखें.

• RaiseFault नीति: raisefault.failed (सभी RaiseFault नीतियों के लिए एक जैसी)
• VerifyAPIKey नीति: oauthV2.{policy_name}.failed, उदाहरण के लिए, oauthV2.Verify-API-Key-1.failed
• कोटा नीति और SpikeArrest नीति: ratelimit.{policy_name}.failed, उदाहरण के लिए, ratelimit.Quota-1.failed

अन्य उपलब्ध वैरिएबल

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

• नीति के वे वैरिएबल जो लागू नहीं हो सके.
• गड़बड़ी के समय मौजूद एचटीटीपी मैसेज वैरिएबल. उदाहरण के लिए, अगर रिस्पॉन्स में कोई गड़बड़ी होती है, तो <TargetEndpoint> में मौजूद कोई FaultRule, एचटीटीपी डेटा response.status.code, message.content, error.content वगैरह का इस्तेमाल कर सकता है. इसके अलावा, अगर कोटा नीति लागू नहीं होती है, तो ratelimit.{quota_policy_name}.exceed.count वैरिएबल का इस्तेमाल किया जा सकता है. ट्रेस टूल और नीति के रेफ़रंस विषय का इस्तेमाल करके, यह पता लगाएं कि कौनसे वैरिएबल और एचटीटीपी डेटा उपलब्ध हैं.

ज़्यादा जानकारी

• शर्तें: शर्तों का रेफ़रंस और फ़्लो वैरिएबल और शर्तें

• गड़बड़ियां: नीति से जुड़ी गड़बड़ी का रेफ़रंस
• वैरिएबल: वैरिएबल रेफ़रंस देखें. साथ ही, हर नीति के साथ उपलब्ध वैरिएबल के लिए, नीति के हिसाब से रेफ़रंस पेज देखें.

गड़बड़ियों को ठीक करने के सबसे सही तरीके

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

यहां गड़बड़ी ठीक करने की सुविधा को डिज़ाइन और बनाने के कुछ सबसे सही तरीके दिए गए हैं:

• हर FaultRule के लिए, "outer" <Condition> (<Step> एलिमेंट का सिबलिंग) दें. आउटर कंडीशन के बिना फ़ॉल्ट के नियम, अपने-आप सही के तौर पर इवैल्यूएट होते हैं. "Inner" स्टेप की शर्तों का इस्तेमाल, यह तय करने के लिए नहीं किया जाता कि कोई FaultRule सही है या गलत. स्टेप की शर्तों का आकलन सिर्फ़ तब किया जाता है, जब Edge उनमें मौजूद FaultRule को लागू कर देता है. FaultRule में, Assign Message या अन्य नीतियों के साथ कई चरण होते हैं. इनमें से हर चरण में, Step की शर्त होती है.

• एक ही तरह की कई नीतियों (उदाहरण के लिए, कई कोटा नीतियां) से जुड़ी गड़बड़ियों को ठीक करने के लिए, हर नीति से जुड़ी गड़बड़ी के लिए एक FaultRule बनाएं. उदाहरण के लिए, कोटा नीतियों में होने वाली हर संभावित गड़बड़ी के लिए एक FaultRule बनाएं. जैसे, QuotaViolation, InvalidMessageWeight, StartTimeNotSupported. (नीति से जुड़ी गड़बड़ियों के बारे में जानने के लिए, नीति से जुड़ी गड़बड़ियों के रेफ़रंस देखें. अगर आपको ऐसी अन्य गड़बड़ियों का पता चलता है जिन्हें ठीक करना ज़रूरी है, तो बाद में वापस जाकर उन्हें FaultRules में जोड़ा जा सकता है. इसे बार-बार दोहराया जा सकता है. हालांकि, इसके लिए प्रॉक्सी को फिर से डिप्लॉय करना ज़रूरी है.) इस तरीके से, एक ही तरह की गड़बड़ी को पकड़ा जा सकता है. इससे कोई फ़र्क़ नहीं पड़ता कि किस नीति से गड़बड़ी हुई है. इससे आपकी FaultRules एक्सएमएल फ़ाइल बेहतर तरीके से काम करती है.

  अगर आपको गड़बड़ी को ज़्यादा बारीकी से कंट्रोल करना है, तो अंदरूनी चरण की शर्तों का इस्तेमाल करें. उदाहरण के लिए, अगर आपको अपने अनुरोध फ़्लो में दो नीतियों के साथ, डेवलपर के लिए तय किए गए कोटे और ग्लोबल कोटे, दोनों को लागू करना है, तो "आउटर" FaultRule की शर्त को QuotaViolation गड़बड़ी (यह गड़बड़ी तब होती है, जब कोटे की सीमा पार हो जाती है) के ट्रिगर होने पर सेट करें. इसके बाद, दोनों कोटा नीतियों में exceed.count वैरिएबल का आकलन करने के लिए, चरण की शर्तें सेट करें. क्लाइंट को सिर्फ़ काम की गड़बड़ी भेजी जाती है. जैसे, डेवलपर के कोटे से ज़्यादा इस्तेमाल या ग्लोबल कोटे से ज़्यादा इस्तेमाल. यहां इस कॉन्फ़िगरेशन का एक उदाहरण दिया गया है:

  <FaultRule name="over_quota">
  <!-- This condition catches a QuotaViolation in *any* Quota policy -->
    <Condition>(fault.name = "QuotaViolation")</Condition>
    <Step>
      <Name>developer-over-quota-fault</Name>
      <Condition>(ratelimit.developer-quota-policy.exceed.count GreaterThan "0")</Condition>
    </Step>
    <Step>
      <Name>global-over-quota-fault</Name>
      <Condition>(ratelimit.global-quota-policy.exceed.count GreaterThan "0")</Condition>
    </Step>
  </FaultRule>

  एक और उदाहरण के लिए, Apigee कम्यूनिटी की यह थ्रेड देखें.

• एक ही तरह की एक नीति का इस्तेमाल करते समय गड़बड़ियों को ठीक करने के लिए, एक गड़बड़ी वाला नियम बनाएं. यह नियम तब लागू होता है, जब वह नीति लागू नहीं होती. साथ ही, इसमें कई ऐसे चरण शामिल करें जो हर संभावित गड़बड़ी से मैप होते हैं. इससे आपकी एक्सएमएल फ़ाइल ज़्यादा असरदार बनती है. ऐसा इसलिए, क्योंकि इसमें हर तरह की गड़बड़ी के लिए एक-एक FaultRule इस्तेमाल करने के बजाय, सिर्फ़ एक FaultRule का इस्तेमाल किया जाता है. उदाहरण के लिए:

  <FaultRule name="raise-fault-3">
  <!-- This condition catches *any* error in the Verify-API-Key-1 policy. -->
    <Condition>(oauthV2.Verify-API-Key-1.failed = "true")</Condition>
    <!-- This first step always executes, which handles errors you haven't mapped with inner conditions. -->
    <Step>
      <Name>Generic-Key-Fault</Name>
    </Step>
    <Step>
      <Name>Assign-Message-Raise-Fault-1</Name>
      <Condition>(fault.name = "FailedToResolveAPIKey")</Condition>
    </Step>
    <Step>
      <Name>Assign-Message-Raise-Fault-2</Name>
      <Condition>(fault.name = "InvalidApiKey")</Condition>
    </Step>
  </FaultRule>

• उन जगहों पर FaultRules जोड़ें जहां गड़बड़ियां होंगी (क्लाइंट साइड <ProxyEndpoint> या टारगेट साइड <TargetEndpoint>). हर उस नीति के लिए FaultRules शामिल करें जो हर जगह दिखती है.
• FaultRules में, ऐसी किसी भी नीति को लागू किया जा सकता है जो क्लाइंट ऐप्लिकेशन को मैसेज भेज सकती है. इसके लिए, AssignMessage नीति सबसे सही है. अगर आपको गड़बड़ियों को ट्रैक करना है, तो MessageLogging नीति का इस्तेमाल करके मैसेज लॉग करें.
• RaiseFault नीतियों को FaultRules के साथ इस्तेमाल करते समय, उस रिस्पॉन्स डेटा को व्यवस्थित करें जो RaiseFault नीति और FaultRule, दोनों के डेटा वापस करने पर भेजा जाता है. उदाहरण के लिए, अगर आपकी RaiseFault नीति, एचटीटीपी स्टेटस कोड को रीसेट करती है, तो FaultRule से स्टेटस कोड को रीसेट न करें. ज़्यादा से ज़्यादा यह हो सकता है कि क्लाइंट ऐप्लिकेशन को डिफ़ॉल्ट स्टेटस कोड वापस मिल जाए.
• <DefaultFaultRule> execution:
  • अगर आपको यह चाहिए कि कोई अन्य FaultRule लागू न होने पर, <DefaultFaultRule> हमेशा लागू हो, तो इसमें <Condition> शामिल न करें.
  • अगर आपको <DefaultFaultRule> को हमेशा लागू करना है, भले ही कोई अन्य FaultRule लागू हो गया हो, तो <AlwaysEnforce>true</AlwaysEnforce> चाइल्ड एलिमेंट जोड़ें.

एक ही जगह पर मौजूद, बार-बार इस्तेमाल किए जा सकने वाले फ़ॉल्ट हैंडलिंग के लिए पैटर्न

Apigee कम्यूनिटी की इस पोस्ट में, कोड को डुप्लीकेट किए बिना, फ़ॉल्ट को एक जगह से मैनेज करने का तरीका बताया गया है:

Apigee प्रॉक्सी के लिए, गड़बड़ी को ठीक करने का पैटर्न

FaultRule बनाना

FaultRule जोड़ने के लिए, आपको ProxyEndpoint या TargetEndpoint के एक्सएमएल कॉन्फ़िगरेशन में बदलाव करना होगा. एपीआई प्रॉक्सी के लिए, डेवलप व्यू के कोड पैन में यह बदलाव करने के लिए, Edge यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल किया जा सकता है. इसके अलावा, ProxyEndpoint या TargetEndpoint को तय करने वाली एक्सएमएल फ़ाइल में बदलाव किया जा सकता है.

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

किसी FaultRule में नीतियां जोड़ना

FaultRule में किसी भी नीति को शामिल किया जा सकता है. हालांकि, आम तौर पर AssignMessage नीति का इस्तेमाल किया जाता है, ताकि गड़बड़ी की स्थिति के लिए कस्टम जवाब वाला मैसेज जनरेट किया जा सके. AssignMessage की मदद से, पेलोड, एचटीटीपी स्टेटस कोड, हेडर, और वजह बताने वाले वाक्यांश के एलिमेंट के साथ एचटीटीपी रिस्पॉन्स को कॉन्फ़िगर किया जा सकता है.

यहां दिए गए उदाहरण में, AssignMessage नीति के सामान्य कॉन्फ़िगरेशन को दिखाया गया है:

<AssignMessage name="fault_invalidkey">
  <Set>
      <Payload contentType="text/plain">Contact support at support@mycompany.com.</Payload>
      <StatusCode>401</StatusCode>
      <ReasonPhrase>Unauthorized</ReasonPhrase>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

अब इस नीति का इस्तेमाल, अपनी FaultRule में किया जा सकता है. ध्यान दें कि FaultRule में, AssignMessage नीति का नाम कैसे रेफ़रंस किया जाता है:

<ProxyEndpoint name="default">
  ...
  <FaultRules>
    <FaultRule name="invalid_key_rule">
      <Step>
        <Name>fault_invalidkey</Name>
      </Step>
      <Condition>(fault.name = "InvalidApiKey")</Condition>
    </FaultRule>
  </FaultRules>
</ProxyEndpoint>

ऊपर दिए गए कॉन्फ़िगरेशन को डिप्लॉय करने पर, एपीआई प्रॉक्सी, AssignMessage नीति fault_invalidkey को तब लागू करेगी, जब कोई ऐप्लिकेशन अमान्य एपीआई पासकोड सबमिट करेगा.

FaultRule में एक से ज़्यादा नीतियां लागू की जा सकती हैं. इसका उदाहरण यहां दिया गया है:

<ProxyEndpoint name="default">
  ...
  <FaultRules>
    <FaultRule name="invalid_key_rule">
      <Step>
        <Name>policy1</Name>
      </Step>
      <Step>
        <Name>policy2</Name>
      </Step>
      <Step>
        <Name>policy3</Name>
      </Step>
      <Condition>(fault.name = "InvalidApiKey")</Condition>
    </FaultRule>
  </FaultRules>
</ProxyEndpoint>

नीतियों को तय किए गए क्रम में लागू किया जाता है. उदाहरण के लिए, MessageLogging नीति, ExtractVariables नीति, AssignMessage नीति या FaultRule में मौजूद किसी अन्य नीति का इस्तेमाल किया जा सकता है. ध्यान दें कि इनमें से कोई भी स्थिति होने पर, FaultRule की प्रोसेसिंग तुरंत बंद हो जाती है:

• FaultRule में मौजूद किसी भी नीति की वजह से गड़बड़ी होती है
• FaultRule में मौजूद कोई भी नीति, RaiseFault टाइप की हो

FaultRule से मिले कस्टम गड़बड़ी के मैसेज को तय करना

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

AssignMessage नीति के इस उदाहरण में, <Payload>, <StatusCode>, और <ReasonPhase> टैग का इस्तेमाल किया गया है. इनकी मदद से, InvalidApiKey गड़बड़ी होने पर क्लाइंट को भेजे जाने वाले कस्टम गड़बड़ी के रिस्पॉन्स को तय किया जाता है. (पिछले FaultRules के उदाहरण देखें).

<AssignMessage name="fault_invalidkey">
  <Set>
    <Payload contentType="text/plain">You have attempted to access a resource without the correct authorization.
       Contact support at support@mycompany.com.</Payload>
    <StatusCode>401</StatusCode>
    <ReasonPhrase>Unauthorized</ReasonPhrase>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

इस जवाब में ये शामिल हैं:

• इस पेलोड में गड़बड़ी का मैसेज और सहायता टीम से संपर्क करने के लिए ईमेल पता होता है.
• जवाब में मिला एचटीटीपी स्टेटस कोड.
• वजह बताने वाला वाक्यांश, जिसमें गड़बड़ी के बारे में कम शब्दों में जानकारी दी जाती है.

DefaultFaultRule बनाना

DefaultFaultRule, किसी भी ऐसी गड़बड़ी के लिए अपवाद हैंडलर के तौर पर काम करता है जिसे किसी अन्य FaultRule ने साफ़ तौर पर हैंडल नहीं किया है. अगर सभी FaultRule की शर्तें, गड़बड़ी से मेल नहीं खाती हैं, तो DefaultFaultRule गड़बड़ी को हैंडल करता है. ProxyEndpoint या TargetEndpoint के चाइल्ड एलिमेंट के तौर पर <DefaultFaultRule> टैग जोड़कर, गड़बड़ी मैनेज करने की डिफ़ॉल्ट सुविधा चालू करें.

उदाहरण के लिए, नीचे दिए गए TargetEndpoint कॉन्फ़िगरेशन में, DefaultFaultRule के बारे में बताया गया है. यह ReturnGenericError नाम की नीति को लागू करता है:

<TargetEndpoint name="default">
  ...
  <FaultRules>
    ...
  </FaultRules>

  <DefaultFaultRule name="fault-rule">
    <Step>
      <Name>ReturnGenericError</Name>
    </Step>
  </DefaultFaultRule>

  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
  </HTTPTargetConnection>
</TargetEndpoint>

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

उदाहरण के लिए, सामान्य गड़बड़ी दिखाने के लिए, यहां दी गई AssignMessage नीति तय करें:

<AssignMessage name="ReturnGenericError">
  <Set>
    <Payload type="text/plain">SERVICE UNAVAILABLE. PLEASE CONTACT SUPPORT: support@company.com.</Payload>
  </Set>
</AssignMessage>

हर गड़बड़ी के लिए DefaultFaultRule को लागू करने के लिए, <DefaultFaultRule> टैग में <AlwaysEnforce> एलिमेंट को शामिल करें. भले ही, कोई अन्य FaultRule पहले ही लागू किया जा चुका हो. DefaultFaultRule हमेशा आखिरी FaultRule होता है, जिसे लागू किया जाता है:

  <DefaultFaultRule name="fault-rule">
    <Step>
      <Name>ReturnGenericError</Name>
    </Step>
    <AlwaysEnforce>true</AlwaysEnforce>
  </DefaultFaultRule>

DefaultFaultRule का इस्तेमाल, उस गड़बड़ी का टाइप पता लगाने के लिए किया जाता है जिसके बारे में आपको कोई जानकारी नहीं होती. उदाहरण के लिए, आपकी एपीआई प्रॉक्सी में ऐसी गड़बड़ी हो रही है जिसके बारे में आपको पता नहीं है. नीचे दी गई AssignMessage नीति को लागू करने के लिए, DefaultFaultRule का इस्तेमाल करें. यह नीति, रिस्पॉन्स में DefaultFaultHeader नाम वाले हेडर में fault.name वैल्यू लिखती है:

<AssignMessage async="false" continueOnError="false" enabled="true" name="DefaultFaultRule">
  <DisplayName>DefaultFaultRule</DisplayName>
  <Set>
    <Headers>
      <Header name="DefaultFaultHeader">{fault.name}</Header>
    </Headers>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" transport="http" type="response"/>
</AssignMessage>

इसके बाद, Edge ट्रेस टूल या जवाब में हेडर देखा जा सकता है. इससे यह पता चलता है कि गड़बड़ी किस वजह से हुई.

PostClientFlow में मैसेज लॉगिंग जोड़ना

PostClientFlow ही ऐसा फ़्लो है जो प्रॉक्सी के गड़बड़ी वाले स्टेटस में आने के बाद काम करता है. इस फ़्लो में सिर्फ़ MessageLogging नीति को अटैच किया जा सकता है. यह नीति, क्लाइंट को जवाब भेजे जाने के बाद लागू होती है. हालांकि, इस फ़्लो में MessageLogging नीति को अटैच करना तकनीकी रूप से गड़बड़ी को ठीक करने का तरीका नहीं है, लेकिन इसका इस्तेमाल गड़बड़ी होने पर जानकारी को लॉग करने के लिए किया जा सकता है. इसे इस बात से कोई फ़र्क़ नहीं पड़ता कि प्रॉक्सी काम कर रही है या नहीं. इसलिए, Message Logging की नीतियों को PostClientFlow में रखा जा सकता है. इससे यह पक्का किया जा सकता है कि वे हमेशा लागू हों.

मौजूदा फ़्लो में नीति से जुड़ी गड़बड़ियों को ठीक करना

अब तक दिखाए गए सभी उदाहरणों में, गड़बड़ी की स्थिति में नीति से जुड़ी किसी भी गड़बड़ी को ठीक करने के लिए, ProxyEndpoint या TargetEndpoint पर FaultRule का इस्तेमाल किया गया है. ऐसा इसलिए होता है, क्योंकि किसी नीति के continueOnError एलिमेंट की डिफ़ॉल्ट वैल्यू false होती है. इसका मतलब है कि जब किसी नीति में कोई गड़बड़ी होती है, तो कंट्रोल को गड़बड़ी वाली स्थिति में भेज दिया जाता है. गड़बड़ी की स्थिति में, कंट्रोल को सामान्य पाइपलाइन पर वापस नहीं लाया जा सकता. आम तौर पर, कॉलिंग ऐप्लिकेशन को गड़बड़ी का कोई मैसेज भेजा जाता है.

हालांकि, अगर आपने किसी नीति के लिए continueOnError एलिमेंट को true पर सेट किया है, तो कंट्रोल मौजूदा फ़्लो में बना रहता है. साथ ही, पाइपलाइन में मौजूद अगली नीति, गड़बड़ी की वजह बनने वाली नीति के बाद लागू होती है. मौजूदा फ़्लो में गड़बड़ी को ठीक करने का फ़ायदा यह है कि आपके पास गड़बड़ी को ठीक करने का कोई तरीका हो सकता है, ताकि अनुरोध को प्रोसेस किया जा सके.

यहां verify-api-key नाम की VerifyAPIKey नीति दिखाई गई है. इसमें continueOnError एलिमेंट को true: पर सेट किया गया है

<VerifyAPIKey async="false" continueOnError="true" enabled="true" name="verify-api-key">
  <DisplayName>Verify API Key</DisplayName>
  <APIKey ref="request.queryparam.apikey"/>
</VerifyAPIKey>

अगर एपीआई पासकोड मौजूद नहीं है या अमान्य है, तो VerifyAPIKey नीति, oauthV2.verify-api-key.failed वैरिएबल को true पर सेट करती है. हालांकि, प्रोसेसिंग मौजूदा फ़्लो में जारी रहती है.

इसके बाद, VerifyAPIKey नीति को ProxyEndpoint के PreFlow में एक चरण के तौर पर जोड़ें:

<ProxyEndpoint name="default">
  ...
  <PreFlow name="PreFlow">
    <Request>
      <Step>
        <Name>verify-api-key</Name>
      </Step>
      <Step>
        <Name>FaultInFlow</Name>
        <Condition>(oauthV2.verify-api-key.failed = "true")</Condition>
      </Step>
    </Request>
    <Response/>
  </PreFlow>
</ProxyEndpoint>

ध्यान दें कि PreFlow के अगले चरण में, किसी गड़बड़ी के मौजूद होने की जांच करने के लिए शर्त का इस्तेमाल किया जाता है. अगर VerifAPIKey नीति में कोई गड़बड़ी होती है, तो FaultInFlow नाम वाली नीति लागू होती है. ऐसा न होने पर, FaultInFlow नीति लागू नहीं होती. FaultInFlow नीति कई काम कर सकती है. जैसे, गड़बड़ी को लॉग करना, गड़बड़ी को ठीक करने की कोशिश करना या कोई अन्य कार्रवाई करना.

RaiseFault नीति का इस्तेमाल करके गड़बड़ी ट्रिगर करना

किसी गड़बड़ी को ट्रिगर करने के लिए, फ़्लो में किसी भी समय RaiseFault नीति का इस्तेमाल किया जा सकता है. RaiseFault नीति लागू होने पर, मौजूदा फ़्लो बंद हो जाता है और कंट्रोल, गड़बड़ी की स्थिति में ट्रांसफ़र हो जाता है.

RaiseFault नीति का इस्तेमाल, किसी ऐसी खास शर्त की जांच करने के लिए किया जाता है जिसे दूसरी नीति शायद न पहचान पाए. ऊपर दिए गए उदाहरण में, आपने PreFlow <Step> टैग में <Condition> टैग जोड़ा है. इससे शर्त पूरी होने पर, नीति FaultInFlow लागू होगी. अगर FaultInFlow एक RaiseFault नीति है, तो कंट्रोल गड़बड़ी की स्थिति में ट्रांसफ़र हो जाता है. इसके अलावा, फ़्लो में RaiseFault नीति को शामिल करके, FaultRules को डीबग और टेस्ट किया जा सकता है.

जब RaiseFault नीति से कोई गड़बड़ी ट्रिगर होती है, तो उसे प्रोसेस करने के लिए, यहां दिए गए FaultRule और शर्त का इस्तेमाल किया जा सकता है:

<FaultRule name="raisefault_rule">
  <Step>
    <Name>{policy_name}</Name>
  </Step>
  <Condition>(fault.name = "RaiseFault")</Condition>
</FaultRule>

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

टारगेट सर्वर से मिले एचटीटीपी गड़बड़ी कोड को कस्टम तरीके से हैंडल करना

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

डिफ़ॉल्ट रूप से, Edge, 1xx-3xx रेंज में मौजूद एचटीटीपी रिस्पॉन्स कोड को 'सफलता' के तौर पर और 4xx-5xx रेंज में मौजूद एचटीटीपी रिस्पॉन्स कोड को 'विफलता' के तौर पर मानता है. इसका मतलब है कि बैकएंड सेवा से मिलने वाले किसी भी रिस्पॉन्स में, एचटीटीपी रिस्पॉन्स कोड 4xx-5xx होने पर, गड़बड़ी की स्थिति अपने-आप शुरू हो जाती है. इसके बाद, अनुरोध करने वाले क्लाइंट को गड़बड़ी का मैसेज सीधे तौर पर मिलता है.

किसी भी एचटीटीपी रिस्पॉन्स कोड के लिए, कस्टम हैंडलर बनाए जा सकते हैं. उदाहरण के लिए, हो सकता है कि आपको 4xx-5xx रेंज के सभी एचटीटीपी रिस्पॉन्स कोड को 'गड़बड़ी' के तौर पर न मानना हो, बल्कि सिर्फ़ 5xx को मानना हो. इसके अलावा, हो सकता है कि आपको एचटीटीपी रिस्पॉन्स कोड 400 और 500 के लिए, कस्टम गड़बड़ी के मैसेज दिखाने हों.

इस अगले उदाहरण में, success.codes प्रॉपर्टी का इस्तेमाल करके TargetEndpoint को कॉन्फ़िगर किया गया है. इससे, डिफ़ॉल्ट एचटीटीपी कोड के साथ-साथ एचटीटीपी रिस्पॉन्स कोड 400 और 500 को भी सफलता के तौर पर माना जाएगा. इन कोड को सक्सेस कोड के तौर पर मानने से, TargetEndpoint, गड़बड़ी की स्थिति को लागू करने के बजाय, जवाब के मैसेज को प्रोसेस करने का काम करता है:

<TargetEndpoint name="default">
  ...
  <HTTPTargetConnection>
    <Properties>
          <Property name="success.codes">1xx,2xx,3xx,400,500</Property>
    </Properties>
    <URL>http://weather.yahooapis.com</URL>
  </HTTPTargetConnection>
</TargetEndpoint>

इस उदाहरण में दिखाया गया है कि success.codes प्रॉपर्टी को वैल्यू की किसी रेंज पर सेट करने के लिए, वाइल्डकार्ड का इस्तेमाल किया जा सकता है..

success.codes प्रॉपर्टी सेट करने पर, डिफ़ॉल्ट वैल्यू बदल जाती हैं. इसलिए, अगर आपको डिफ़ॉल्ट तौर पर इस्तेमाल होने वाले स्टेटस कोड की सूची में एचटीटीपी कोड 400 जोड़ना है, तो इस प्रॉपर्टी को इस तरह सेट करें:

<Property name="success.codes">1xx,2xx,3xx,400</Property>

हालांकि, अगर आपको सिर्फ़ एचटीटीपी कोड 400 को सफलता कोड के तौर पर इस्तेमाल करना है, तो प्रॉपर्टी को इस तरह सेट करें:

<Property name="success.codes">400</Property>

अब एचटीटीपी रिस्पॉन्स कोड 400 और 500 के लिए कस्टम हैंडलर तय किए जा सकते हैं, ताकि अनुरोध करने वाले ऐप्लिकेशन को पसंद के मुताबिक बनाया गया रिस्पॉन्स मैसेज भेजा जा सके. यहां दिए गए TargetEndpoint में, ReturnError नाम की नीति का इस्तेमाल किया गया है. इससे एचटीटीपी 400 और 500 रिस्पॉन्स कोड को हैंडल किया जा सकता है:

<TargetEndpoint name="default">
  <PreFlow name="PreFlow">
    <Request/>
    <Response>
      <Step>
        <Name>ReturnError</Name>
        <Condition>(response.status.code = 400) or (response.status.code = 500)</Condition>
      </Step>
    </Response>
  </PreFlow>

  <HTTPTargetConnection>
    <Properties>
      <Property name="success.codes">1xx,2xx,3xx,400,500</Property>
    </Properties>
    <URL>http://weather.yahooapis.com</URL>
  </HTTPTargetConnection>
</TargetEndpoint>

इस TargetEndpoint कॉन्फ़िगरेशन की वजह से, ReturnError नाम की नीति, रिस्पॉन्स को मैनेज करती है. ऐसा तब होता है, जब TargetEndpoint को 400 या 500 का एचटीटीपी रिस्पॉन्स कोड मिलता है.

गड़बड़ी की टेक्सॉनमी

API सेवाएं, गड़बड़ियों को इन कैटगरी और सब-कैटगरी में व्यवस्थित करती हैं.

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

• कारण
• उपयोगकर्ता के तय किए गए कस्टम एट्रिब्यूट