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

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

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

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

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

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

वीडियो

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

गड़बड़ी के नियम देखें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नीचे 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. नीति को ट्रिगर करने के लिए, <FaultTerms> बनाएं

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

अगर आपका कोई भी FaultTerms लागू नहीं होता है, तो आपको सामान्य गड़बड़ी का कस्टम मैसेज देने के लिए <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>

खास बातें:

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

  • <Condition> - Edge, स्थिति का आकलन करता है और नीति को तभी लागू करता है, जब स्थिति सही हो. अगर ऐसे कई Faultरूल हैं जो सही के तौर पर आकलन करते हैं, तो Edge पहले 'सही' को एक्ज़ीक्यूट करता है. (अहम जानकारी: जिस क्रम में गड़बड़ी के नियम का आकलन किया जाता है, उनमें ऊपर से नीचे या नीचे से ऊपर की ओर, यह तय किया जाता है कि वह TargetEndpoint और प्रॉक्सीEndpoint का आकलन करते हैं, जैसा कि एक से ज़्यादा गड़बड़ी नियम और निष्पादन लॉजिक सेक्शन में बताया गया है. कोई शर्त शामिल न करने पर, गड़बड़ी नियम अपने-आप लागू हो जाता है. हालांकि, यह सबसे सही तरीका नहीं है. हर गड़बड़ी के नियम की अपनी शर्त होनी चाहिए.

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

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

एक से ज़्यादा गड़बड़ियां और उन्हें लागू करने का लॉजिक

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

इस सेक्शन में बताया गया है कि 'एज, गड़बड़ी' नियम को मैनेज करने के लिए किस लॉजिक का इस्तेमाल करता है. इसमें गड़बड़ी के एक नियम को लागू करने के तरीके से लेकर "इनर" स्टेप की शर्तों को हैंडल करने के तरीके तक की जानकारी दी गई है. इस सेक्शन में यह भी बताया गया है कि <ProxyEndpoint> बनाम <TargetEndpoint> में, गड़बड़ी के नियम कब तय किए जाएं. साथ ही, इस सेक्शन में गड़बड़ी से जुड़े नियम और बढ़ावा देने से जुड़ी नीति के बीच के संबंध के बारे में भी बताया गया है.

गलत नियम लागू करना

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

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

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

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

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

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

प्रॉक्सीEndpoint Faultरूल का मूल्यांकन नीचे से ऊपर किया गया है, इसलिए नीचे दिए गए नमूने में दिए गए आखिरी गड़बड़ी नियम से पढ़ना शुरू करें और अपने हिसाब से कोशिश करें. आखिर में defaultFaultTerms देखें.

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

टारगेटएंडपॉइंट का इस्तेमाल करना

टारगेटएंडपॉइंट के गड़बड़ी वाले नियम का मूल्यांकन ऊपर से नीचे किया गया है. इसलिए, नीचे दिए गए सैंपल में दिए गए पहले गड़बड़ी नियम को पढ़ना शुरू करें और आगे बढ़ने की कोशिश करें. आखिर में defaultFaultTerms देखें.

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

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

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

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

प्रॉक्सीEndpoint का क्रम टारगेटएंडपॉइंट का क्रम

नीचे दिए गए उदाहरण में, आकलन सबसे नीचे से ऊपर की ओर होता है, इसलिए FaultTerms 3 लागू होती है. इसका मतलब है कि FaultTerms 2 और 1 का आकलन नहीं किया गया है.

5. गड़बड़ी का नियम 1: FALSE

4. गड़बड़ी नियम 2: TRUE

3. गड़बड़ी-नियम 3: TRUE

2. गड़बड़ी-नियम 4: FALSE

1. गड़बड़ी के नियम: 5 गलत

नीचे दिए गए उदाहरण में, मूल्यांकन ऊपर से नीचे होता है, इसलिए FaultTerms 2 लागू होती है. इसका मतलब है कि FaultTerms 3, 4, और 5 का आकलन नहीं किया गया है.

1. गड़बड़ी का नियम 1: FALSE

2. गड़बड़ी नियम 2: TRUE

3. गड़बड़ी-नियम 3: TRUE

4. गड़बड़ी-नियम 4: FALSE

5. गड़बड़ी के नियम: 5 गलत

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

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

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

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

ध्यान दें: एपीआई प्रॉक्सी, <FaultRules> और <DefaultFaultRule> का सिर्फ़ तब आकलन करता है, जब प्रॉक्सी में कोई गड़बड़ी हो. इसका मतलब है कि अगर FaultTerms की कोई स्थिति'सही' पर सेट है, तो प्रॉक्सी के गड़बड़ी की स्थिति में न होने पर, यह ट्रिगर नहीं होगी.

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

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

FaultTerms को कहां तय करना है: प्रॉक्सीEndpoint या TargetEndpoint

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

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

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

गड़बड़ी के नियम बनाम riseFault की नीति

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

संक्षेप में:

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

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

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

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

  • Fault{/4} या DefaultFaultTerms को लागू करने के लिए, riseFault नीति का पालन करें. इस वजह से, FaultTerms रिस्पॉन्स का डेटा जीत जाता है.
  • RayFault की नीति से मिले रिस्पॉन्स डेटा (स्टेटस कोड, वजह वाला वाक्यांश या मैसेज पेलोड) का इस्तेमाल तब किया जाता है, जब वह डेटा, FaultTerms या डिफ़ॉल्ट के तौर पर सेट न हो.
  • अगर RayFault की नीति और FaultTerms, दोनों में पसंद के मुताबिक एचटीटीपी हेडर जोड़े जाते हैं, तो दोनों रिस्पॉन्स में शामिल होते हैं. डुप्लीकेट हेडर नाम, कई वैल्यू वाला हेडर बनाते हैं.

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

क्लाइंट ऐप्लिकेशन को ये फ़ायदे मिलते हैं:

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

<- दर्शाने के लिए, riseFault की नीति सेट करती है:

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

बिल्डिंग की शर्तें

शर्तें, FaultTerms लागू करने के लिए अहम हैं. आप FaultTerms की शर्तें बनाते हैं, जैसे कि Edge की दूसरी शर्तों के लिए करते हैं, जैसे कि कंडीशनल फ़्लो या riseFault की स्थितियों के लिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

    दूसरे उदाहरण के लिए, यह Apigee समुदाय थ्रेड देखें.

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

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

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

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

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

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

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

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

गड़बड़ी के नियम में नीतियां जोड़ना

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

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

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

अब इस नीति का इस्तेमाल गड़बड़ी के नियम में किया जा सकता है. ध्यान दें कि आप FaultTerms में नाम के आधार पर Assignments मैसेज नीति का रेफ़रंस कैसे देते हैं:

<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 नाम की टीम Assignments नीति को लागू करेगा.

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

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

  • Faultनियमों में मौजूद किसी भी नीति की वजह से गड़बड़ी होती है
  • FultTerms की कोई भी नीति इस तरह की है: riseFault

गड़बड़ी नियम से मिले कस्टम गड़बड़ी के मैसेज की पहचान करना

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

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

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

इस रिस्पॉन्स में ये चीज़ें शामिल हैं:

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

डिफ़ॉल्ट गड़बड़ी नियम बनाना

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

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

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

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

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

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

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

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

हर गड़बड़ी के लिए defaultFaultनियमों को लागू करने के लिए, <DefaultFaultRule> टैग में <AlwaysEnforce> एलिमेंट शामिल करें, भले ही कोई दूसरा FaultTerms पहले ही लागू हो चुका हो. डिफ़ॉल्टFault{/4} हमेशा लागू होने वाला आखिरी गड़बड़ी नियम होता है:

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

डिफ़ॉल्टFaultTerms का एक इस्तेमाल यह तय करने के लिए भी होता है कि किस तरह की गड़बड़ी तब होती है, जब आप उसके बारे में पता नहीं लगा सकते. उदाहरण के लिए, आपका एपीआई प्रॉक्सी किसी ऐसी गड़बड़ी की वजह से काम नहीं कर रहा है जिसका पता नहीं लगाया जा सकता. नीचे दी गई AssignmentsMessage नीति लागू करने के लिए, defaultFaultTerms का इस्तेमाल करें. यह नीति रिस्पॉन्स में, 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 पर FaultTerms का इस्तेमाल करते हैं. ऐसा इसलिए है, क्योंकि किसी नीति के 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 पर सेट करती है. हालांकि, मौजूदा फ़्लो में प्रोसेस जारी रहती है.

इसके बाद, प्रॉक्सीEndpoint के PreFlow में पुष्टि करने वाली नीति को एक चरण के तौर पर जोड़ा जा सकता है:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

गलत कैटगरी

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

कैटगरी सबकैटगरी गलती का नाम ब्यौरा
मैसेज सेवा मैसेज फ़्लो के दौरान होने वाली गड़बड़ियां (इनमें नीति की असफलता शामिल नहीं है)
कस्टम फ़ॉल्ट {fault_name} riseFault की नीति का इस्तेमाल करके, एपीआई प्रॉक्सी सर्वर की गड़बड़ी को साफ़ तौर पर ठीक करता है
रिस्पॉन्स कोड InternalServerError, नहीं मिला एचटीटीपी गड़बड़ी कोड 5xx, 4xx
रूटिंग संबंधी विफलताएं NoRoutesMatched किसी अनुरोध के लिए, नाम वाले TargetEndpoint नहीं चुने जा सके
कैटगरी तय नहीं हो सकी NotFound अनुरोध यूआरआई की वजह से आने वाली समस्याएं, जो किसी भी प्रॉक्सीEndpoint कॉन्फ़िगरेशन के लिए किसी भी BasePath से मेल नहीं खाती
परिवहन एचटीटीपी के ट्रांसपोर्ट लेवल की गड़बड़ियां
कनेक्टिविटी कनेक्शन से मना किया गया, कनेक्शन रीसेट, कनेक्शन टाइमआउट नेटवर्क या ट्रांसपोर्ट-लेवल कनेक्शन बनाते समय गड़बड़ी होती है
पुष्टि करने का अनुरोध करें कॉन्टेंट की लंबाई मौजूद नहीं है, HostHeader missing हर अनुरोध के सिमैंटिक की जांच के दौरान गड़बड़ियां होती हैं
प्रतिक्रिया पुष्टि हर जवाब के सिमैंटिक की जांच के दौरान गड़बड़ियां होती हैं
IO की गड़बड़ियां SSLHandShakeError, ReadTimeout, ReadError, WriteTimeout, WriteError, ChankError क्लाइंट या टारगेट एंडपॉइंट पर पढ़ने/लिखने में होने वाली गड़बड़ियां, टाइम आउट, TLS/एसएसएल की गड़बड़ियां, और कई छोटी-छोटी गड़बड़ियां
सिस्टम रनटाइम की ऐसी गड़बड़ियां जो तय नहीं की गई हैं
मेमोरी OutOfMemory, GCOverLimit मेमोरी से जुड़ी गड़बड़ियां
Thread RogueTaskTerminated रन-अवे टास्क बंद करने जैसी गड़बड़ी
नीति हर नीति के टाइप की गड़बड़ियों के बारे में नीति के रेफ़रंस में बताया गया है.

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

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