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

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

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

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

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

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

वीडियो

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

गलती से जुड़े नियम देखें

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

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 नीति, जो पेलोड और वैकल्पिक एचटीटीपी हेडर सेट कर सकता है. जैसे- स्टेटस कोड की वजह बताएं. इसके लिए, मैसेज असाइन करें सबसे सही विकल्प है. इसकी मदद से, मैसेज पेलोड को कंट्रोल किया जा सकता है, अलग एचटीटीपी स्टेटस कोड, दूसरी एचटीटीपी वजह वाला वाक्यांश सेट करें, और एचटीटीपी हेडर जोड़ें.

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

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

नीचे assignMessage नीति का उदाहरण दिया गया है:

• JSON मैसेज दिखाता है.
• एक एचटीटीपी स्टेटस कोड (911) सेट करता है. यह एक साफ़ तौर पर दिखने वाला स्टेटस कोड है, जो मौजूद नहीं है अपनी सुविधा के बारे में बताएं). स्टेटस कोड, एचटीटीपी हेडर में दिखता है.
• एक HTTP वजह वाक्यांश सेट करता है (इस के लिए डिफ़ॉल्ट "बिना मंज़ूरी वाली" वजह वाक्यांश को बदलने के लिए एपीआई पासकोड मौजूद न होने से जुड़ी गड़बड़ी). एचटीटीपी में स्टेटस कोड के बगल में क्यों दिखता है हेडर.
• इससे 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 अलग-अलग गड़बड़ी को ठीक करना चाहते हैं. इस आसान उदाहरण में, हम आपको यह दिखाने के लिए कि किस यह कई वेब पेजों से बना है.

आपको कोई कस्टम सामान्य गड़बड़ी देने के लिए, <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, स्थिति की जांच करता है और सिर्फ़ शर्त के सही होने पर ही नीति लागू करता है. अगर ऐसे कई गलती नियम हैं जो 'सही' के तौर पर जवाब देता है, तो Edge सही वैल्यू वाली पहली वैल्यू को एक्ज़ीक्यूट करता है. (अहम जानकारी: जिस क्रम में FaultRules का आकलन किया जाता है, ऊपर से नीचे या नीचे से ऊपर, उनके बीच में अंतर होता है TargetEndpoint और ProxyEndpoint, जैसा कि एक से ज़्यादा FaultRules और एक्ज़ीक्यूशन लॉजिक सेक्शन.) कोई शर्त शामिल न करने पर, गलती से नियम लागू होगा अपने आप सही हो जाता है. हालांकि, यह सबसे सही तरीका नहीं है. हर FaultRule का अपना खुद का नियम होना चाहिए स्थिति.

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

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

एक से ज़्यादा FaultRules और लागू करने का लॉजिक

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

इस सेक्शन में, FaultRules को मैनेज करने के लिए इस्तेमाल किए जाने वाले लॉजिक के बारे में बताया गया है. साथ ही, यह जानकारी भी दी गई है कि Edge "inner" को लागू करने के लिए, एक FaultRule तरह का इस्तेमाल करें चरण की शर्तें तब हैंडल की जाती हैं, जब FultRule का इस्तेमाल किया जाता है ट्रिगर किया गया. इस सेक्शन में यह भी बताया गया है कि <ProxyEndpoint> बनाम <TargetEndpoint>. FaultRules और RaiseFault Policy के बीच संबंध.

FaultRules लागू करना

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

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

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

3. अगर कोई भी गलती से नियम लागू नहीं होता है, तो Edge <DefaultFaultRule> को लागू करता है, अगर उपस्थित.

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

ProxyEndpoint फ़ंक्शन को एक्ज़ीक्यूट करना

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

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

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

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

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

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

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

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

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

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

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

जगह FaultRules: ProxyEndpoint या TargetEndpoint को तय करने के लिए

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

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

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

• RaiseFault नीति के बाद, FaultRule या defaultFaultRule को लागू किया जाता है, इसलिए FaultRule रिस्पॉन्स डेटा जीतता है.
• riseFault नीति का रिस्पॉन्स डेटा (स्टेटस कोड, वजह बताने वाले वाक्यांश या मैसेज पेलोड) यह है का इस्तेमाल तब किया जाता है, जब वह डेटा FaultRule या डिफ़ॉल्टFaultRule से सेट न किया गया हो.
• अगर 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 लागू करने में शर्तें सबसे अहम होती हैं. आप उसी तरह FaultRule की शर्तें बनाते हैं आप Edge की अन्य शर्तों के लिए ऐसा करते हैं, जैसे कि कंडिशनल फ़्लो या RaiseFault की शर्तें.

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

<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.failed (RaiseFault की सभी नीतियों के लिए एक जैसा)
• VerifyAPIKey नीति: oauthV2.{policy_name}.failed, इसके लिए उदाहरण के लिए, oauthV2.Verify-API-Key-1.failed
• कोटा की नीति और SpikeAreest की नीति: ratelimit.{policy_name}.failed, उदाहरण के लिए, ratelimit.Quota-1.failed

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

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

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

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

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

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

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

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

गड़बड़ियों को ठीक करने और उन्हें ठीक करने के लिए, यहां कुछ सबसे सही तरीके बताए गए हैं:

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

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

• एक ही तरह की नीति का इस्तेमाल करते समय होने वाली गड़बड़ियों को ठीक करने के लिए, एक ही गड़बड़ी पर ध्यान दें वह नियम जो उस एक नीति के विफल होने पर लागू होता है, और जिसमें ऐसे कई चरण शामिल होते हैं, जो हर संभावित गड़बड़ी को ठीक करना ज़रूरी है. यह एक्सएमएल को चालू रखने के लिए, एक से ज़्यादा FultRules का इस्तेमाल करें (हर तरह की गड़बड़ी के लिए एक). उदाहरण के लिए:

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

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

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

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

गलत नियम बनाना

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

अगर मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) में FaultRules बनाई जाती है, तो पहले वे नीतियां बनाएं जिन्हें आपको लागू करना है, इसके बाद, उन्हें 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>

अब इस नीति का इस्तेमाल FultRule में किया जा सकता है. ध्यान दें कि आपने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 कॉल किया जाता है.

जैसा कि नीचे दिए गए उदाहरण में बताया गया है, गलत नियम के तहत कई नीतियों को लागू किया जा सकता है:

<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 की कोई भी नीति RaiseFault तरह की होती है

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>

इस जवाब में ये चीज़ें शामिल होती हैं:

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

defaultFaultRule बनाना

defaultFaultRule ऐसी किसी भी गड़बड़ी के लिए अपवाद हैंडलर काम करता है जिसे खास तौर पर कोई दूसरा नियम लागू करें. अगर सभी FaultRules की शर्तें गड़बड़ी से मेल नहीं खाती हैं, तो defaultFaultRule गड़बड़ी को हैंडल करती है. इसे जोड़कर डिफ़ॉल्ट गड़बड़ी प्रबंधन सक्षम करें <DefaultFaultRule> टैग को ProxyEndpoint के चाइल्ड एलिमेंट के तौर पर या 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>

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

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

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

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

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

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

इसके साथ संदेश लॉगिंग को PostClientFlow

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

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

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

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

<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 की नीति का इस्तेमाल किया जा सकता है. जब riseFault नीति लागू होती है. यह मौजूदा फ़्लो को खत्म करती है और कंट्रोल को गड़बड़ी पर ट्रांसफ़र करती है राज्य.

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

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

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

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

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

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

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

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

अगले उदाहरण में, आप 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, इस नाम की नीति का इस्तेमाल करता है एचटीटीपी 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>

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

गलत टेक्सॉनमी

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

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

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