गड़बड़ी को ठीक करना

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

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

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

कस्टम गड़बड़ी को मैनेज करने की सुविधा से, गड़बड़ी होने पर मैसेज लॉग करने जैसी सुविधा भी जोड़ी जा सकती है.

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

वीडियो

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

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

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

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

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

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

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

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

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

आप किसी API प्रॉक्सी फ़्लो में भी INCREASEFault नीति को ठीक उसी तरह जोड़ सकते हैं जैसे आप किसी अन्य नीति में करते हैं. नीचे दिए गए प्रॉक्सी कॉन्फ़िगरेशन के उदाहरण में, Raise-Fault-1 नीति को TargetEnd रिस्पॉन्स में अटैच किया गया है. टारगेट सेवा के जवाब में "उपलब्ध नहीं है" शब्द मौजूद होने पर, INCREASEFault की नीति लागू हो जाती है और गड़बड़ी होती है.

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

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

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

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

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

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

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

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

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

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

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

FaultRules देखें

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

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

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

गड़बड़ियों को ठीक करने का आसान उदाहरण

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

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) जब प्रॉक्सी को गड़बड़ी की स्थिति में ले जाया जाए, तो नीति लागू करें.

1. पसंद के मुताबिक बनाए गए मैसेज की जानकारी देने वाली नीति बनाएं

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

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

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

नीचे 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> सेक्शन शामिल होंगे. हर FallRule एक अलग गड़बड़ी दिखाता है, जिसे आप मैनेज करना चाहते हैं. इस आसान उदाहरण में, हम आपको सिर्फ़ एक FaultRule का इस्तेमाल करके बताएंगे कि वह किस बारे में है.

अगर आपके FaultRules में से कोई भी नियम लागू नहीं किया गया है, तो आपको सामान्य गड़बड़ी का मैसेज देने के लिए, <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, स्थिति का आकलन करता है और नीति को सिर्फ़ तब लागू करता है, जब स्थिति सही हो. अगर एक से ज़्यादा FaultRules हैं, जिनका आकलन 'सही' करने के लिए होता है, तो एज, पहला नियम लागू करता है. (अहम जानकारी: एक जैसे नियम और कार्रवाई करने के नियम वाले सेक्शन में, FaultRules के क्रम का आकलन करने के लिए, टारगेट एंडपॉइंट और प्रॉक्सी एंडपॉइंट के बीच अंतर बताया गया है. यह क्रम, टॉप से बॉटम से बॉटम से टॉप तक का होता है) अगर आप कोई शर्त शामिल नहीं करते हैं, तो F रूप से लागू करने वाली नियम अपने-आप सही हो जाता है. हालांकि, यह सबसे सही तरीका नहीं है. हर FallRule की अपनी शर्त होनी चाहिए.

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

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

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

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

इस सेक्शन में बताया गया है कि Edge किस तरह F रूप से लागू किए गए नियमों को हैंडल करता है. साथ ही, यह भी बताता है कि वह F रूप से काम करने की स्थिति में किस तरह आ रहा है. इससे यह पता चलता है कि उनके FaultRule को ट्रिगर करने पर "अंदरूनी" कदम से जुड़ी शर्तें कैसे हैंडल की जाती हैं. इस सेक्शन में यह भी बताया गया है कि <ProxyEndpoint> बनाम <TargetEndpoint> में FulRules को कब तय करना है. साथ ही, यह भी बताया गया है कि FaultRules और raisingFault के नीति के बीच क्या संबंध है.

डिफ़ॉल्ट नियम लागू होना

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

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

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

3. अगर कोई FaultRule लागू नहीं किया जाता है, तो मौजूद होने पर एज, <DefaultFaultRule> को एक्ज़ीक्यूट करता है.

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

ProxyEndPoint एक्ज़ीक्यूशन

ProxyEndpoint FaultRules का इवैलुएशन सबसे नीचे है, इसलिए नीचे दिए गए नमूने में आखिरी FaultRule में पढ़ना शुरू करें और अपने हिसाब से काम करें. डिफ़ॉल्ट डिफ़ॉल्ट मिटाने का तरीका देखें.

<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 FaultRules का आकलन सबसे ऊपर होता है, इसलिए नीचे दिए गए नमूने में पहले FaultRule में पढ़ना शुरू करें और अपने हिसाब से काम करें. डिफ़ॉल्ट डिफ़ॉल्ट मिटाने का तरीका देखें.

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

गड़बड़ी के नियम का क्रम

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

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

इन नीतियों को शामिल करें

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

गड़बड़ी के नियम सिर्फ़ गड़बड़ी की स्थिति में ट्रिगर होते हैं (जारी रहने में गड़बड़ी के बारे में)

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

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

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

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

FaultRules तय करने का तरीका: ProxyEndPoint या TargetEndpoint

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

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

यहां एक और उदाहरण दिया गया है. अगर <ProxyEndpoint> जवाब में INCREASEFault की नीति के तहत कोई गड़बड़ी होती है, तो <TargetEndpoint> में FaultRule लागू नहीं होगा.

FaultRules बनाम raisingFault की नीति

गड़बड़ी के नियम और INCREASEFault की नीति, प्लैटफ़ॉर्म के साउंड पर लागू हो सकती है, जैसे कि गड़बड़ी को ठीक करने के दूसरे तरीके और कुछ मामलों में यह सही भी. हालांकि, वे साथ मिलकर काम करते हैं. इस सेक्शन में, दोनों के संबंध के बारे में बताया गया है. इस संबंध को समझने से, आपको गड़बड़ी से निपटने में मदद मिलेगी. खास तौर पर तब, जब आपको दोनों का इस्तेमाल करना हो.

संक्षेप में:

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

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

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

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

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

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

• FaultRule या डिफ़ॉल्टFaultRule को raisingFault की नीति के बाद लागू किया जाता है. इसलिए, FaultRule रिस्पॉन्स डेटा जीत जाता है.
• बढ़ाfault नीति के जवाब का डेटा (स्टेटस कोड, वजह से जुड़ा वाक्यांश या मैसेज का पेलोड) का इस्तेमाल तब किया जाता है, जब वह डेटा FaultRule याDefaultFaultRule से सेट नहीं किया गया हो.
• riseFault की नीति और F रूप से लागू होने वाली नीति, दोनों में कस्टम एचटीटीपी हेडर जोड़ने पर, ये दोनों जवाब में शामिल कर दिए जाते हैं. डुप्लीकेट हेडर नाम से कई वैल्यू वाला हेडर बनता है.

यहां एक उदाहरण दिया गया है, जिसे डॉक्टर के डिज़ाइन से जुड़ी नीति और 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 में दूसरी कंडीशन के लिए लागू करते हैं, जैसे कि कंडीशनल फ़्लो या INCREASEFault की स्थितियां.

इस सेक्शन के बाकी हिस्से को संदर्भ में रखने के लिए, यहां एक नमूना गड़बड़ी नियम दिया गया है, जिसमें एक बाहरी गड़बड़ी और आंतरिक चरण की स्थिति है.

<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 वैरिएबल के उदाहरण यहां दिए गए हैं. नीति के नेमस्पेस के लिए, नीति के रेफ़रंस वाले हर विषय में फ़्लो वैरिएबल देखें.

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

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

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

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

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

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

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

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

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

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

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

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

  इसके बाद, अगर आपको गड़बड़ियों को कंट्रोल करने के लिए ज़्यादा बारीकी से कंट्रोल करना है, तो इनर स्टेप कंडिशन का इस्तेमाल करें. उदाहरण के लिए, अगर आप अपने अनुरोध के फ़्लो में दो नीतियों के साथ अलग-अलग डेवलपर कोटा और ग्लोबल कोटा, दोनों लागू कर रहे हैं, तो QuotaViolation गड़बड़ी पर ट्रिगर होने के लिए "बाहरी" FallRule स्थिति सेट करें (दोनों में से किसी भी मामले में कोटा खत्म हो जाने पर). इसके बाद, दोनों कोटे की अपनी नीतियों में 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 समुदाय थ्रेड देखें.

• जब आप एक ही प्रकार की एक ही नीति का इस्तेमाल कर रहे हों, तो गड़बड़ियों को ठीक करने के लिए एक ही गड़बड़ी का नियम मानें. ऐसी नीति के फ़ेल होने पर, लागू होने वाले एक नियम को शामिल करें. साथ ही, हर संभावित गड़बड़ी को मैप करने वाले कई चरण शामिल करें. यह एक से ज़्यादा FaultRules (हर गड़बड़ी टाइप के लिए एक) के बजाय, एक 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>
  

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

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

नीचे दी गई Apigee कम्यूनिटी पोस्ट में, एक ही जगह पर गड़बड़ी को ठीक करने के तरीके के बारे में बताया गया है. यह कोड बिना डुप्लीकेट मौजूद है:

https://community.apigee.com/articles/23724/an-error-handling-pattern-for-apigee-proxies.html

किफ़ायती नियम बनाना

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

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

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

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

नीचे दिया गया उदाहरण एक सामान्य 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>

जब ऊपर दिए गए कॉन्फ़िगरेशन को डिप्लॉय किया जाता है, तो एपीआई प्रॉक्सी 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 से जुड़ी नीति, एक्सट्रैक्ट वैरिएबल नीति, assignMessage नीति या FaultRule में मौजूद किसी दूसरी नीति को इस्तेमाल किया जा सकता है. ध्यान दें कि इनमें से कोई स्थिति होने पर, FaultRule की प्रोसेसिंग तुरंत बंद हो जाती है:

• FaultRule में शामिल किसी भी नीति की वजह से गड़बड़ी हो सकती है
• FaultRule में से कोई भी नीति riseFault के तौर पर है

FaultRule से लौटाए गए कस्टम गड़बड़ी के मैसेज के बारे में बताना

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

नीचे दी गई assignMessage नीति का उदाहरण, <Payload>, <StatusCode>, और <ReasonPhase> टैग का इस्तेमाल करके, पसंद के मुताबिक बनाई गई गड़बड़ी के ऐसे रिस्पॉन्स को तय करता है जिसे अमान्यApiKey गड़बड़ी पर क्लाइंट को वापस भेजा जाता है. पिछला 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>

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

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

डिफ़ॉल्टFulRule बनाना

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

उदाहरण के लिए, नीचे TargetEndpoint कॉन्फ़िगरेशन एक डिफ़ॉल्टFaultRule के बारे में बताता है, जो Returnजेनेरिक गड़बड़ी नाम की नीति को शुरू करता है:

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

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

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

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

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

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

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

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

DefaultFaultRule का एक इस्तेमाल यह तय करने के लिए किया जाता है कि किस तरह की गड़बड़ी तब होती है, जब आप ऐसा नहीं कर पाते हैं. उदाहरण के लिए, आपका API प्रॉक्सी किसी ऐसी गड़बड़ी के लिए फ़ेल हो रहा है जिसका आप पता नहीं लगा सकते. इन डिफ़ॉल्ट मैसेज नीति को शुरू करने के लिए, डिफ़ॉल्टFallRule का इस्तेमाल करें. यह नीति, रिस्पॉन्स में 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 से जुड़ी नीति जोड़ना, तकनीकी रूप से गड़बड़ी को हैंडल करना नहीं है. गड़बड़ी की स्थिति में जानकारी लॉग करने के लिए, इसका इस्तेमाल किया जा सकता है. प्रॉक्सी सर्वर की मदद से सफलता पाने या न हो पाने की वजह से एक्ज़ीक्यूशन होता है. इसलिए, आपके पास PostClientFlow के लिए मैसेज लॉग करने की नीतियां लागू करने का विकल्प होता है. साथ ही, इस बात की भी गारंटी दी जा सकती है कि ये मैसेज हमेशा इस्तेमाल किए जाएंगे.

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

अब तक दिखाए गए सभी उदाहरण, गड़बड़ी की स्थिति के तौर पर किसी भी नीति से जुड़ी गड़बड़ी को ठीक करने के लिए, ProxyEndPoint या TargetEndpoint पर मौजूद F रूप से काम करने वाले नियम का इस्तेमाल करते हैं. इसकी वजह यह है कि नीति के 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 पर सेट करती है. हालांकि, प्रोसेसिंग मौजूदा फ़्लो में जारी रहती है.

इसके बाद, ProxyEndPoint के प्रीफ़्लो में, चरण के तौर पर VerificationAPIKey की नीति जोड़ें:

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

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

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

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

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

जब किसी riseFault की नीति के तहत कोई गड़बड़ी होती है, तो आप उसे प्रोसेस करने के लिए नीचे दिए गए FaultRule और स्थिति का इस्तेमाल कर सकते हैं:

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

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

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

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

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

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

अगले उदाहरण में, आप एचटीटीपी रिस्पॉन्स कोड 400 और 500 को डिफ़ॉल्ट एचटीटीपी कोड के साथ इस्तेमाल करने के लिए, success.codes प्रॉपर्टी का इस्तेमाल करें. ऐसे कोड को कामयाब मानने के बाद, 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 के लिए, पसंद के मुताबिक हैंडलर तय करने का विकल्प है. इससे अनुरोध करने वाले ऐप्लिकेशन पर, पसंद के मुताबिक बनाया गया रिस्पॉन्स मैसेज भेजा जा सकेगा. नीचे दिया गया टारगेट एंडपॉइंट, एचटीटीपी 400 और 500 के रिस्पॉन्स कोड मैनेज करने के लिए, ReturnError नाम की नीति का इस्तेमाल करता है:

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

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

गड़बड़ी की अलग-अलग कैटगरी

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

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

• वजह
• उपयोगकर्ता की ओर से तय किए गए कस्टम एट्रिब्यूट