হ্যান্ডলিং ত্রুটি

আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন .info- তে যান।

অ্যাপ থেকে আসা অনুরোধগুলো পরিষেবা দেওয়ার সময় এপিআই প্রক্সিগুলোতে নানা ধরনের ত্রুটি দেখা দিতে পারে। উদাহরণস্বরূপ, ব্যাকএন্ড পরিষেবাগুলোর সাথে যোগাযোগের সময় এপিআই প্রক্সিগুলো নেটওয়ার্ক সমস্যার সম্মুখীন হতে পারে, অ্যাপগুলো মেয়াদোত্তীর্ণ ক্রেডেনশিয়াল ব্যবহার করতে পারে, অনুরোধ বার্তাগুলোর ফরম্যাট ভুল হতে পারে, ইত্যাদি।

যখন কোনো ক্লায়েন্ট অ্যাপ একটি এপিআই প্রক্সিকে কল করার পর কোনো ত্রুটি ঘটে, তখন ক্লায়েন্টের কাছে একটি ত্রুটি বার্তা ফেরত পাঠানো হয়। ডিফল্টরূপে, ক্লায়েন্ট প্রায়শই একটি দুর্বোধ্য ত্রুটি বার্তা পায়, যাতে কোনো বিবরণ বা নির্দেশনা থাকে না। কিন্তু আপনি যদি ডিফল্ট ত্রুটি বার্তাগুলোকে আরও দরকারি কাস্টম বার্তা দিয়ে প্রতিস্থাপন করতে চান, এবং এমনকি অতিরিক্ত HTTP হেডারের মতো বিষয় দিয়ে সেগুলোকে আরও সমৃদ্ধ করতে চান, তাহলে আপনাকে Edge-এ কাস্টম ফল্ট হ্যান্ডলিং সেট আপ করতে হবে।

কাস্টম ফল্ট হ্যান্ডলিং আপনাকে ত্রুটি ঘটলে মেসেজ লগিং-এর মতো কার্যকারিতাও যোগ করার সুযোগ দেয়।

আপনার এপিআই প্রক্সিতে কাস্টম এরর হ্যান্ডলিং প্রয়োগ করার বিষয়ে আলোচনা করার আগে, এরর কীভাবে ঘটে এবং এপিআই প্রক্সিগুলো সেগুলোর প্রতি কীভাবে প্রতিক্রিয়া দেখায় তা বোঝা সহায়ক হবে।

ভিডিও

ত্রুটি ব্যবস্থাপনা সম্পর্কে আরও জানতে নিম্নলিখিত ভিডিওগুলো দেখুন।

কীভাবে ত্রুটি ঘটে

প্রথমে আমরা আলোচনা করব কীভাবে ত্রুটি ঘটে। ত্রুটি কীভাবে ঘটে তা জানা থাকলে, আপনি বিভিন্ন পরিস্থিতিতে কাস্টম ত্রুটি হ্যান্ডলিং প্রয়োগ করার জন্য পরিকল্পনা করতে পারবেন।

স্বয়ংক্রিয় ত্রুটি

একটি এপিআই প্রক্সি নিম্নলিখিত পরিস্থিতিতে স্বয়ংক্রিয়ভাবে একটি ত্রুটি প্রদর্শন করে:

• একটি পলিসি একটি ত্রুটি দেখায়। উদাহরণস্বরূপ, যদি কোনো এপিআই কল একটি মেয়াদোত্তীর্ণ কী পাঠায়, তাহলে VerifyAPIKey পলিসি স্বয়ংক্রিয়ভাবে একটি ত্রুটি দেখায়; অথবা যদি এপিআই কলের সংখ্যা একটি নির্দিষ্ট সীমা অতিক্রম করে, তাহলে Quota পলিসি বা SpikeArrest পলিসি একটি ত্রুটি দেখায়। (পলিসিগুলো কী ধরনের ত্রুটি দেখাতে পারে, তা জানতে পলিসি ত্রুটি রেফারেন্স দেখুন)।
• এপিআই প্রক্সি মেসেজ ফ্লোতে একটি সমস্যা আছে, যেমন রাউটিং ত্রুটি।
• ব্যাকএন্ডে কোনো ব্যর্থতা ঘটেছে, যেমন প্রোটোকল স্তরের ব্যর্থতার কারণে HTTP ত্রুটি, TLS/SSL ত্রুটি, অথবা লক্ষ্য পরিষেবাটি অনুপলব্ধ থাকা।
• সিস্টেম-স্তরের কোনো ত্রুটি ঘটেছে, যেমন মেমোরি-সংক্রান্ত ব্যতিক্রম।

এই ত্রুটিগুলো সম্পর্কে আরও তথ্যের জন্য, এই বিষয়ের ফল্ট ট্যাক্সোনমি দেখুন।

কাস্টম ত্রুটি

যেসব ক্ষেত্রে স্বয়ংক্রিয় কোনো এরর থাকে না, সেখানে আপনি একটি কাস্টম এরর দেখাতে চাইতে পারেন; যেমন, যদি কোনো রেসপন্সে "unavailable" শব্দটি থাকে, অথবা যদি HTTP স্ট্যাটাস কোড 201-এর বেশি হয়। এটি করার জন্য, একটি API প্রক্সি ফ্লো-এর উপযুক্ত স্থানে একটি RaiseFault পলিসি যোগ করুন।

অন্যান্য পলিসির মতোই আপনি একটি এপিআই প্রক্সি ফ্লোতে একটি RaiseFault পলিসি যোগ করতে পারেন। নিম্নলিখিত প্রক্সি কনফিগারেশন উদাহরণে, Raise-Fault-1 পলিসিটি TargetEndpoint রেসপন্সের সাথে সংযুক্ত করা হয়েছে। যদি টার্গেট সার্ভিসের রেসপন্সে "unavailable" শব্দটি উপস্থিত থাকে, তাহলে RaiseFault পলিসিটি কার্যকর হয় এবং একটি এরর থ্রো করে।

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

আপনাকে এটা দেখানোর জন্যই যে আপনি কাস্টম এরর থ্রো করতে পারেন। আমরা 'FaultRules বনাম RaiseFault পলিসি' সেকশনে RaiseFault পলিসি সম্পর্কে আরও বিস্তারিত আলোচনা করেছি।

আরও উদাহরণের জন্য, Apigee কমিউনিটি ফোরামের এই পোস্টগুলি দেখুন:

• RaiseFault-এ জাভাস্ক্রিপ্ট ভেরিয়েবল উল্লেখ করা

ত্রুটি ঘটলে এপিআই প্রক্সিগুলো কী করে

প্রক্সি ত্রুটি দেখালে যা ঘটে তা এখানে দেওয়া হলো।

প্রক্সি পাইপলাইন থেকে প্রস্থান করুন

যখন একটি এপিআই প্রক্সি কোনো ত্রুটির সম্মুখীন হয়, তা যেভাবেই ঘটুক না কেন, এটি স্বাভাবিক প্রবাহ পথ থেকে বেরিয়ে যায়, একটি ত্রুটিপূর্ণ অবস্থায় প্রবেশ করে এবং ক্লায়েন্ট অ্যাপে একটি ত্রুটি বার্তা ফেরত পাঠায়। এপিআই প্রক্সি একবার ত্রুটিপূর্ণ অবস্থায় প্রবেশ করলে, এটি আর স্বাভাবিক প্রবাহ পথে তার কার্যক্রম ফিরিয়ে আনতে পারে না।

উদাহরণস্বরূপ, ধরে নিন একটি API প্রক্সির ProxyEndpoint অনুরোধে পলিসিগুলো নিম্নলিখিত ক্রমে রয়েছে:

1. এপিআই কী যাচাই করুন
2. কোটা
3. JSON থেকে XML

এপিআই কী যাচাইকরণের সময় কোনো ত্রুটি ঘটলে, এপিআই প্রক্সিটি একটি ত্রুটিপূর্ণ অবস্থায় চলে যায়। কোটা এবং JSON থেকে XML পলিসিগুলো কার্যকর হয় না, প্রক্সিটি টার্গেটএন্ডপয়েন্টে অগ্রসর হয় না এবং ক্লায়েন্ট অ্যাপে একটি ত্রুটি বার্তা ফেরত পাঠানো হয়।

ফল্টরুলস পরীক্ষা করুন

ত্রুটিপূর্ণ অবস্থায়, ক্লায়েন্ট অ্যাপে একটি ডিফল্ট ত্রুটি বার্তা ফেরত পাঠানোর আগে, এপিআই প্রক্সিগুলো এপিআই প্রক্সি কনফিগারেশনে নিম্নলিখিত বিষয়গুলোর (ক্রমানুসারে) উপস্থিতি যাচাই করে:

1. একটি <FaultRules> সেকশন, যেখানে আপনার সংজ্ঞায়িত নির্দিষ্ট শর্তের উপর ভিত্তি করে কাস্টম ত্রুটি বার্তা (এবং অন্যান্য নীতি) সক্রিয় করার লজিক থাকে।
2. একটি <DefaultFaultRule> সেকশন, যা নিম্নলিখিত পরিস্থিতিতে একটি ডিফল্ট ত্রুটি বার্তা প্রদর্শন করে:
   • কোনো <FaultRules> সংজ্ঞায়িত করা নেই।
   • বিদ্যমান কোনো <FaultRules> কার্যকর হয় না।
   • <AlwaysEnforce> এলিমেন্টটির মান true সেট করা হয়েছে।

মূলত, এপিআই প্রক্সি আপনাকে একটি কাস্টম ত্রুটির বার্তা ফেরত দেওয়ার এবং অন্যান্য লজিক ট্রিগার করার সুযোগ দেয়। যদি প্রক্সি সেই বিভাগগুলির কোনোটিই খুঁজে না পায়, অথবা সেগুলি বিদ্যমান থাকা সত্ত্বেও কোনো কাস্টম ত্রুটি ট্রিগার না হয়, তাহলে প্রক্সি তার নিজস্ব 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"}}}

আপনার এপিআই ব্যবহারকারীরা ত্রুটির বার্তাটি বুঝতে পারলেও পারেন, আবার নাও পারেন। এবং অনেক ডিফল্ট ত্রুটি আরও সূক্ষ্ম ও দুর্বোধ্য হয়।

একজন এপিআই ডেভেলপার হিসেবে, এই বার্তাটি পরিবর্তন করার দায়িত্ব আপনারই, যাতে এটি চূড়ান্তভাবে যিনি এরর মেসেজটি পাবেন, তাঁর প্রয়োজন মেটানো যায়; তিনি একজন আইওএস অ্যাপ ডেভেলপার হোন বা কোনো অভ্যন্তরীণ টেস্টিং গ্রুপ, যাদের এরর মেসেজ ফরম্যাটের নিজস্ব প্রয়োজনীয়তা রয়েছে।

এই ত্রুটিটি পরিচালনা করার জন্য কীভাবে একটি কাস্টম ত্রুটি বার্তা তৈরি করবেন তার একটি সাধারণ উদাহরণ এখানে দেওয়া হলো। এর জন্য প্রয়োজন ১) একটি পলিসি যা কাস্টম বার্তাটি নির্ধারণ করে, এবং ২) একটি ফল্টরুল যা প্রক্সিটি ত্রুটিপূর্ণ অবস্থায় গেলে পলিসিটি কার্যকর করে।

১. একটি নীতি তৈরি করুন যা কাস্টম বার্তা নির্ধারণ করে।

প্রথমে, একটি পলিসি তৈরি করুন যা কাস্টম এরর মেসেজটি নির্ধারণ করবে। আপনি যেকোনো ধরনের পলিসি ব্যবহার করতে পারেন, যেমন একটি AssignMessage পলিসি , যা একটি পেলোড এবং ঐচ্ছিক HTTP হেডার, যেমন স্ট্যাটাস কোড ও রিজন ফ্রেজ, সেট করতে পারে। এর জন্য Assign Message পলিসিটি আদর্শ। এটি আপনাকে মেসেজ পেলোড নিয়ন্ত্রণ করতে, একটি ভিন্ন HTTP স্ট্যাটাস কোড ও রিজন ফ্রেজ সেট করতে এবং HTTP হেডার যোগ করতে দেয়।

এপিআই প্রক্সির কোনো ফ্লো-এর সাথে পলিসিটি সংযুক্ত করবেন না। এটি কেবল প্রক্সি বান্ডেলে থাকলেই যথেষ্ট। এটি করার জন্য, ম্যানেজমেন্ট UI প্রক্সি এডিটরে, Develop ট্যাবে যান এবং নেভিগেশন প্যানে Policies বারের + আইকনে ক্লিক করুন।

এর মাধ্যমে আপনি এপিআই প্রক্সিতে কোনো ফ্লো-এর সাথে সংযুক্ত না করেই একটি পলিসি তৈরি করতে পারেন। যে পলিসি কোনো ফ্লো-এর সাথে সংযুক্ত নয়, সেটিকে পলিসি তালিকায় "ডিটাচড" আইকন দিয়ে চিহ্নিত করা হয়, যেমনটি পূর্ববর্তী চিত্রে দেখানো এপিআই কী মেসেজ পলিসির পাশে দেখানো হয়েছে।

নিচে একটি AssignMessage পলিসির উদাহরণ দেওয়া হলো যা:

• একটি JSON বার্তা ফেরত দেয়।
• একটি HTTP স্ট্যাটাস কোড সেট করে (৯১১, যা একটি সুস্পষ্ট অস্তিত্বহীন স্ট্যাটাস কোড, শুধুমাত্র আপনার উপলব্ধ নমনীয়তা দেখানোর জন্য)। স্ট্যাটাস কোডটি HTTP হেডারে প্রদর্শিত হয়।
• একটি HTTP কারণ বাক্যাংশ সেট করে (এই অনুপস্থিত API কী ত্রুটির জন্য ডিফল্ট "Unauthorized" কারণ বাক্যাংশটি প্রতিস্থাপন করতে)। কারণ বাক্যাংশটি HTTP হেডারে স্ট্যাটাস কোডের পাশে প্রদর্শিত হয়।
• invalidKey নামে একটি নতুন HTTP হেডার তৈরি করে এবং তাতে তথ্য যোগ করে।

<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."}

হ্যাঁ, এটা কিছুটা হাস্যকর, কিন্তু এটা দেখিয়ে দেয় যে কী করা সম্ভব। অন্তত এখন বার্তাটি গ্রহণকারী ডেভেলপার জানতে পারবেন যে তিনি কোয়েরি প্যারামিটার হিসেবে একটি এপিআই কী (API key) অন্তর্ভুক্ত করতে ভুলে গেছেন।

কিন্তু এই নীতিটি কীভাবে কার্যকর করা হয়? পরবর্তী অংশে তা দেখানো হবে।

২. <FaultRule> তৈরি করুন যা পলিসিটি সক্রিয় করবে।

প্রক্সি কনফিগারেশনের <ProxyEndpoint> বা <TargetEndpoint> সেকশনে, আপনাকে একটি <FaultRules> XML ব্লক যোগ করতে হবে, যেটিতে এক বা একাধিক স্বতন্ত্র <FaultRule> সেকশন থাকবে। প্রতিটি FaultRule একটি ভিন্ন ত্রুটিকে নির্দেশ করে, যা আপনি সমাধান করতে চান। এই সহজ উদাহরণে, এটি কী কী দিয়ে গঠিত তা দেখানোর জন্য আমরা কেবল একটি FaultRule ব্যবহার করব।

আপনার কোনো FaultRule কার্যকর না হলে একটি নিজস্ব সাধারণ ত্রুটির বার্তা দেখানোর জন্য আপনার একটি <DefaultFaultRule> যোগ করা উচিত।

উদাহরণ

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

মূল বিষয়গুলো:

• FaultRules-গুলো ProxyEndpoint-এ সংজ্ঞায়িত করা হয়। এটি একটি গুরুত্বপূর্ণ বিষয়। ProxyEndpoint বনাম TargetEndpoint-এ FaultRules স্থাপন করার বিষয়ে পরে আরও আলোচনা করা হবে।
• <Name> - যে পলিসিটি কার্যকর করা হবে তার নাম। নামটি প্যারেন্ট এলিমেন্টের পলিসির name অ্যাট্রিবিউট থেকে নেওয়া হয়, যেমনটি আগের পলিসি উদাহরণে দেখানো হয়েছে।

• <Condition> - Edge শর্তটি মূল্যায়ন করে এবং পলিসিটি শুধুমাত্র তখনই কার্যকর করে যখন শর্তটি সত্য হয়। যদি একাধিক FaultRule সত্য বলে প্রমাণিত হয়, Edge প্রথম সত্য FaultRule-টি কার্যকর করে। ( গুরুত্বপূর্ণ : FaultRule-গুলো কোন ক্রমে মূল্যায়ন করা হবে, উপর থেকে নিচে নাকি নিচ থেকে উপরে, তা TargetEndpoint এবং ProxyEndpoint-এর মধ্যে ভিন্ন হয়, যেমনটি ' একাধিক FaultRule এবং কার্যকর করার যুক্তি' বিভাগে বর্ণনা করা হয়েছে।) আপনি যদি কোনো শর্ত অন্তর্ভুক্ত না করেন, তাহলে FaultRule-টি স্বয়ংক্রিয়ভাবে সত্য হয়ে যায়। কিন্তু এটি একটি উত্তম অনুশীলন নয়। প্রতিটি FaultRule-এর নিজস্ব শর্ত থাকা উচিত।

• <DefaultFaultRule> - যদি কোনো কাস্টম FaultRule কার্যকর না হয়, তাহলে <DefaultFaultRule> কার্যকর হয় এবং Edge দ্বারা তৈরি দুর্বোধ্য ডিফল্ট বার্তার পরিবর্তে একটি অপেক্ষাকৃত সাধারণ কাস্টম বার্তা পাঠায়। একটি <DefaultFaultRule> এর একটি <Condition> ও থাকতে পারে, কিন্তু বেশিরভাগ ক্ষেত্রে আপনি তা অন্তর্ভুক্ত করবেন না, কারণ শেষ উপায় হিসেবে আপনি চাইবেন এটি যেন সব পরিস্থিতিতেই কার্যকর হয়।

  যেকোনো অপ্রত্যাশিত ত্রুটির জন্য একটি সাধারণ ত্রুটি বার্তা ফেরত দিতে DefaultFaultRule সাধারণত ব্যবহৃত হয়। উদাহরণস্বরূপ, এমন একটি বার্তা যাতে প্রযুক্তিগত সহায়তার জন্য যোগাযোগের তথ্য থাকে। এই ডিফল্ট প্রতিক্রিয়াটি দুটি উদ্দেশ্য পূরণ করে: এটি একদিকে যেমন ডেভেলপার-বান্ধব তথ্য সরবরাহ করে, তেমনই অন্যদিকে ব্যাকএন্ড ইউআরএল বা অন্যান্য তথ্য গোপন রাখে যা সিস্টেমের নিরাপত্তা বিঘ্নিত করতে ব্যবহার করা হতে পারে।

একাধিক ফল্টরুল এবং এক্সিকিউশন লজিক

"সাধারণ ফল্ট হ্যান্ডলিং উদাহরণ" অংশে, আমরা একটিমাত্র FaultRule এবং শর্তের একটি সাধারণ উদাহরণ ব্যবহার করেছি। একটি বাস্তব API প্রোজেক্টে, ঘটতে পারে এমন সমস্ত সম্ভাব্য ত্রুটির কারণে, আপনার <ProxyEndpoint> এবং <TargetEndpoint> উভয় স্থানেই একাধিক FaultRule এবং একটি DefaultFaultRule থাকার সম্ভাবনা রয়েছে। তবে, শেষ পর্যন্ত, যখন একটি API প্রক্সি ত্রুটিপূর্ণ অবস্থায় যায়, তখন শুধুমাত্র একটি FaultRule-ই কার্যকর হয়।

এই বিভাগে Edge কীভাবে FaultRules পরিচালনা করে তার যুক্তি বর্ণনা করা হয়েছে; যেমন, এটি কীভাবে কার্যকর করার জন্য একটি একক FaultRule নির্ধারণ করে এবং যখন কোনো "অভ্যন্তরীণ" Step-এর FaultRule ট্রিগার হয় তখন তার শর্তগুলো কীভাবে পরিচালনা করা হয়। এই বিভাগে <ProxyEndpoint> এবং <TargetEndpoint> এ কখন FaultRules সংজ্ঞায়িত করতে হবে সে সম্পর্কেও নির্দেশনা দেওয়া হয়েছে এবং FaultRules ও RaiseFault পলিসির মধ্যকার সম্পর্ক বর্ণনা করা হয়েছে।

ফল্টরুলস এক্সিকিউশন

সংক্ষেপে, যখন কোনো এপিআই প্রক্সি ত্রুটিপূর্ণ অবস্থায় চলে যায়, তখন Edge এই লজিকটি ব্যবহার করে। উল্লেখ্য যে, ProxyEndpoint এবং TargetEndpoint-এর মধ্যে FaultRules মূল্যায়নে সামান্য পার্থক্য রয়েছে।

1. ত্রুটিটি কোথায় ঘটেছে তার উপর নির্ভর করে Edge, ProxyEndpoint অথবা TargetEndpoint-এর যেকোনো একটিতে FaultRules-গুলো মূল্যায়ন করে।
   • ProxyEndpoint - Edge কনফিগারেশন XML-এর একেবারে নিচের <FaultRule> থেকে কাজ শুরু করে এবং উপরের দিকে অগ্রসর হয়, প্রতিটি <FaultRule> এর <Condition> মূল্যায়ন করে (এখানে "বাইরের" শর্তটি মূল্যায়ন করা হয়, "ভেতরের" <Step> শর্তগুলো নয়)।
   • টার্গেটএন্ডপয়েন্ট - Edge কনফিগারেশন XML-এর শীর্ষস্থানীয় <FaultRule> থেকে শুরু করে নিচের দিকে অগ্রসর হয় এবং প্রতিটি <FaultRule> এর <Condition> মূল্যায়ন করে (এখানে "বাইরের" শর্তটি মূল্যায়ন করা হয়, "ভেতরের" <Step> শর্তগুলো নয়)।
2. প্রথম সেই FaultRule-টি কার্যকর করে যার শর্তটি সত্য। যদি কোনো FaultRule-এর কোনো শর্ত না থাকে, তবে সেটি ডিফল্টরূপে সত্য হয়।
   • যখন একটি FaultRule কার্যকর করা হয়, তখন XML কনফিগারেশনে FaultRule-এর ভেতরের সমস্ত Step উপর থেকে নিচে ক্রমানুসারে মূল্যায়ন করা হয়। শর্তবিহীন Step-গুলো স্বয়ংক্রিয়ভাবে কার্যকর হয় (পলিসিগুলো কার্যকর হয়), এবং যে Step-গুলোর <Condition> 'true' হিসেবে মূল্যায়ন করা হয়, সেগুলো কার্যকর করা হয় (যে শর্তগুলো 'false' হিসেবে মূল্যায়ন করা হয়, সেগুলো কার্যকর করা হয় না)।

   • যদি কোনো FaultRule কার্যকর করা হয়, কিন্তু এর অন্তর্ভুক্ত কোনো Step কার্যকর না হয় (কারণ সেগুলোর শর্ত 'false' হিসেবে বিবেচিত হয়), তাহলে Edge-এর তৈরি ডিফল্ট ত্রুটির বার্তাটি ক্লায়েন্ট অ্যাপে ফেরত পাঠানো হয়। <DefaultFaultRule> কার্যকর হয় না , কারণ Edge ইতিমধ্যেই তার নিজের একটি FaultRule কার্যকর করে ফেলেছে।

3. যদি কোনো FaultRule কার্যকর না হয়, তাহলে Edge <DefaultFaultRule> টি কার্যকর করে, যদি সেটি উপস্থিত থাকে।

নিচে ইনলাইন কমেন্টসহ কিছু উদাহরণ দেওয়া হলো।

প্রক্সিএন্ডপয়েন্ট এক্সিকিউশন

ProxyEndpoint FaultRule-গুলোর মূল্যায়ন নিচ থেকে উপরের দিকে করা হয়, তাই নিচের নমুনাটির শেষ FaultRule থেকে পড়া শুরু করুন এবং ক্রমান্বয়ে উপরের দিকে যান। সবশেষে DefaultFaultRule-টি দেখুন।

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

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

টার্গেটএন্ডপয়েন্ট এক্সিকিউশন

TargetEndpoint FaultRule-গুলোর মূল্যায়ন উপর থেকে নিচে করা হয়, তাই নিচের নমুনাটির প্রথম 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-এ ঘটছে, তার উপর নির্ভর করে আপনার FaultRules-গুলো কোন ক্রমে সাজাচ্ছেন তা গুরুত্বপূর্ণ।

উদাহরণস্বরূপ:

অন্তর্ভুক্ত করার জন্য নীতিমালা

আপনি একটি FaultRule থেকে যেকোনো পলিসিকে Steps-এর মধ্যে রেখে তা কার্যকর করতে পারেন। উদাহরণস্বরূপ, আপনি ক্লায়েন্ট অ্যাপে একটি প্রতিক্রিয়া ফরম্যাট করার জন্য AssignMessage পলিসি কার্যকর করতে পারেন, তারপর MessageLogging পলিসি দিয়ে একটি বার্তা লগ করতে পারেন। পলিসিগুলো আপনি যে ক্রমে রাখেন (XML-এ উপর থেকে নিচে) সেই ক্রমেই কার্যকর হয়।

ফল্ট রুলগুলো শুধুমাত্র একটি এরর স্টেটে ট্রিগার হয় (continueOnError সম্পর্কে)।

শিরোনাম দেখে মনে হতে পারে আমরা একই কথার পুনরাবৃত্তি করছি, কিন্তু প্রক্সি ত্রুটির কারণে কোনো এপিআই প্রক্সি যখন ত্রুটিপূর্ণ অবস্থায় চলে যায়—কিংবা বলা ভালো, ত্রুটিপূর্ণ অবস্থায় যায় না —তখন একটি বিশেষ সূক্ষ্ম বিষয় সম্পর্কে সচেতন থাকা প্রয়োজন, আর তা হলো পলিসির continueOnError অ্যাট্রিবিউট।

সংক্ষেপে বলতে গেলে: একটি এপিআই প্রক্সি <FaultRules> এবং <DefaultFaultRule> শুধুমাত্র তখনই মূল্যায়ন করে যখন প্রক্সিটি একটি ত্রুটিপূর্ণ অবস্থায় প্রবেশ করে। এর মানে হলো, একটি FaultRule শর্ত সত্য বলে প্রমাণিত হলেও, প্রক্সিটি ত্রুটিপূর্ণ অবস্থায় না থাকলে সেটি ট্রিগার হবে না।

তবে, এখানে একটি ত্রুটি ঘটার এবং প্রক্সিটি ত্রুটি অবস্থায় প্রবেশ না করার একটি উদাহরণ দেওয়া হলো। যেকোনো পলিসিতে, আপনি প্যারেন্ট এলিমেন্টে continueOnError নামক একটি অ্যাট্রিবিউট সেট করতে পারেন। ফল্ট হ্যান্ডলিং-এর ক্ষেত্রে এই অ্যাট্রিবিউটটি খুবই গুরুত্বপূর্ণ, কারণ পলিসি ব্যর্থ হলে প্রক্সিটি ত্রুটি অবস্থায় প্রবেশ করবে কি না, তা এটি নির্ধারণ করে। বেশিরভাগ ক্ষেত্রে, আপনি ডিফল্ট continueOnError="false" রাখতে চাইবেন, যা পলিসি ব্যর্থ হলে প্রক্সিটিকে একটি ত্রুটি অবস্থায় রাখে এবং আপনার কাস্টম ত্রুটি হ্যান্ডলিং ট্রিগার হবে। তবে, যদি continueOnError="true" (উদাহরণস্বরূপ, যদি আপনি না চান যে একটি সার্ভিস কলআউটের ব্যর্থতা প্রক্সির এক্সিকিউশন থামিয়ে দিক), তাহলে সেই পলিসি ব্যর্থ হলেও প্রক্সিটি ত্রুটি অবস্থায় যাবে না এবং প্রক্সিটি আপনার FaultRules দেখবে না।

continueOnError="true" হলে ত্রুটি লগ করার তথ্যের জন্য, বর্তমান ফ্লো-এর মধ্যে পলিসি ত্রুটি পরিচালনা দেখুন।

FaultRules কোথায় সংজ্ঞায়িত করতে হবে: ProxyEndpoint নাকি TargetEndpoint

যখন কোনো এপিআই প্রক্সিতে ত্রুটি দেখা দেয়, তখন সেই ত্রুটিটি হয় <ProxyEndpoint> (ক্লায়েন্ট অ্যাপ থেকে অনুরোধ বা ক্লায়েন্ট অ্যাপে পাঠানো প্রতিক্রিয়া) অথবা <TargetEndpoint> (টার্গেট সার্ভিসে অনুরোধ বা টার্গেট সার্ভিস থেকে পাঠানো প্রতিক্রিয়া)-এ ঘটে। যেখানেই সেই ত্রুটিটি ঘটুক না কেন, Edge সেখানেই FaultRules খুঁজে থাকে।

উদাহরণস্বরূপ, যদি কোনো টার্গেট সার্ভার উপলব্ধ না থাকে (HTTP স্ট্যাটাস কোড 503), তাহলে API প্রক্সিটি <TargetEndpoint> রেসপন্সে একটি এরর স্টেটে চলে যাবে এবং স্বাভাবিক API প্রক্সি ফ্লো <ProxyEndpoint> পর্যন্ত অগ্রসর হবে না। যদি আপনার FaultRules শুধুমাত্র <ProxyEndpoint> এ সংজ্ঞায়িত করা থাকে, তবে সেগুলো সেই এররটি হ্যান্ডেল করবে না।

এখানে আরেকটি উদাহরণ দেওয়া হলো। যদি <ProxyEndpoint> রেসপন্সের উপর থাকা কোনো RaiseFault পলিসি একটি এরর ট্রিগার করে, তাহলে <TargetEndpoint> এর মধ্যে থাকা FaultRule-টি এক্সিকিউট হবে না।

FaultRules বনাম RaiseFault পলিসি

ফল্ট রুল এবং রেইজফল্ট পলিসি আপাতদৃষ্টিতে ফল্ট হ্যান্ডলিং সম্পন্ন করার দুটি বিকল্প উপায় বলে মনে হতে পারে; এবং কিছু দিক থেকে তা সত্যিও। কিন্তু এগুলো একসাথেও কাজ করে। এই অংশে উভয়ের মধ্যকার সম্পর্ক ব্যাখ্যা করা হয়েছে। এই সম্পর্কটি বুঝতে পারলে আপনার ফল্ট হ্যান্ডলিং ডিজাইন করতে সুবিধা হবে, বিশেষ করে যদি আপনি উভয়ই ব্যবহার করতে চান।

সংক্ষেপে:

• যখন কোনো এপিআই প্রক্সি ত্রুটিপূর্ণ অবস্থায় প্রবেশ করে, তখন ফল্ট রুলগুলো সর্বদা মূল্যায়ন করা হয়।

• RaiseFault পলিসি হলো এমন একটি উপায় যার মাধ্যমে কোনো API প্রক্সিকে ত্রুটিপূর্ণ অবস্থায় রাখা হয়, যখন অন্যথায় কোনো ত্রুটি ঘটত না।

  উদাহরণস্বরূপ, যদি আপনি চান যে টার্গেট সার্ভিসের রেসপন্সে থাকা HTTP স্ট্যাটাস কোড 200-এর বেশি হলে একটি এরর দেখানো হোক, তাহলে আপনাকে আপনার রেসপন্স ফ্লোতে একটি RaiseFault পলিসি যোগ করতে হবে। এটি দেখতে অনেকটা এইরকম হবে:

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

  RaiseFault পলিসিটি ক্লায়েন্ট অ্যাপে একটি ত্রুটি বার্তাও পাঠায়।

যখন একটি RaiseFault পলিসি কোনো ত্রুটি ঘটায়, যা প্রক্সিকে একটি ত্রুটিপূর্ণ অবস্থায় ফেলে দেয় এবং এর ফলে একটি FaultRule কার্যকর হতে পারে, তখন কী ঘটে? এখানেই বিষয়টি কিছুটা জটিল হয়ে উঠতে পারে। যদি RaiseFault পলিসি একটি ত্রুটি বার্তা ফেরত দেয় এবং একটি FaultRule ট্রিগার হয়ে একটি ত্রুটি বার্তা ফেরত দেয়, তাহলে ক্লায়েন্ট অ্যাপে কী ফেরত পাঠানো হবে?

• যেহেতু RaiseFault পলিসির পরে FaultRule বা DefaultFaultRule কার্যকর হয়, তাই FaultRule-এর প্রতিক্রিয়া ডেটা প্রাধান্য পায়।
• RaiseFault পলিসির রেসপন্স ডেটা (স্ট্যাটাস কোড, কারণ বাক্যাংশ, বা মেসেজ পেলোড) ব্যবহার করা হয়, যদি সেই ডেটা FaultRule বা DefaultFaultRule দ্বারা সেট করা না থাকে।
• যদি RaiseFault পলিসি এবং FaultRule উভয়ই কাস্টম HTTP হেডার যোগ করে, তবে উভয়ই রেসপন্সে অন্তর্ভুক্ত হয়। একই নামের হেডার ব্যবহার করলে এমন একটি হেডার তৈরি হয় যাতে একাধিক ভ্যালু থাকে।

একটি RaiseFault পলিসি এবং একটি FaultRule দ্বারা কী সেট করা হয় এবং ক্লায়েন্ট অ্যাপে কী ফেরত পাঠানো হয়, তার একটি উদাহরণ এখানে দেওয়া হলো। এই নমুনাগুলো সংক্ষিপ্ততার জন্য তৈরি করা হয়েছে, সেরা অনুশীলনের জন্য নয়।

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

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

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

ভবনের অবস্থা

FaultRule কার্যকর করার মূল চাবিকাঠি হলো শর্তাবলী। Edge-এ আপনি অন্যান্য শর্তাবলী, যেমন শর্তসাপেক্ষ ফ্লো বা RaiseFault শর্তাবলীর জন্য যেভাবে শর্ত তৈরি করেন, ঠিক সেভাবেই FaultRule-এর শর্তাবলীও তৈরি করতে পারেন।

এই অংশের বাকি আলোচনাকে প্রাসঙ্গিক করার জন্য, এখানে একটি নমুনা ফল্ট রুল দেওয়া হলো, যেটিতে একটি বাইরের FaultRule কন্ডিশন এবং একটি ভেতরের Step কন্ডিশন রয়েছে।

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

নীতিগত ত্রুটির জন্য নির্দিষ্ট ভেরিয়েবল

যখন কোনো পলিসি ত্রুটি দেখায়, তখন fault.name এবং {policy_namespace}.{policy_name}.failed ভেরিয়েবলগুলো উপলব্ধ হয়।

ত্রুটি.নাম

যখন কোনো পলিসি ব্যর্থ হয়, তখন fault.name ভেরিয়েবল ব্যবহার করে একটি কন্ডিশনে ত্রুটিটি ধরুন। উদাহরণস্বরূপ:

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

ডিফল্ট এরর মেসেজে এররের নামটি দেখা যায়। উদাহরণস্বরূপ, নিচের ক্ষেত্রে ফল্টের নাম হলো FailedToResolveAPIKey । এক্ষেত্রে, fault.name নামক একটি ফ্লো ভ্যারিয়েবলের মান FailedToResolveAPIKey সেট করা হয়।

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

সুতরাং শর্তটি দেখতে এইরকম হবে:

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

পলিসি ত্রুটির তালিকার জন্য পলিসি ত্রুটি নির্দেশিকা দেখুন।

{policy_namespace}.{policy_name}.failed

যখন কোনো পলিসি ব্যর্থ হয়, তখন *.failed ভেরিয়েবলটি উপলব্ধ হয়। নিচে বিভিন্ন পলিসির জন্য *.failed ভেরিয়েবলের উদাহরণ দেওয়া হলো। পলিসি নেমস্পেসের জন্য, প্রতিটি পলিসি রেফারেন্স টপিকে ফ্লো ভেরিয়েবলগুলো দেখুন।

• RaiseFault পলিসি : raisefault.failed (সকল RaiseFault পলিসির জন্য একই)
• VerifyAPIKey policy : oauthV2.{policy_name}.failed , উদাহরণস্বরূপ, oauthV2.Verify-API-Key-1.failed
• কোটা পলিসি এবং স্পাইকঅ্যারেস্ট পলিসি : ratelimit.{policy_name}.failed , উদাহরণস্বরূপ, ratelimit.Quota-1.failed

অন্যান্য উপলব্ধ ভেরিয়েবল

যখন কোনো এপিআই প্রক্সি ত্রুটিপূর্ণ অবস্থায় চলে যায়, তখন কন্ডিশনে ব্যবহারের জন্য শুধুমাত্র নিম্নলিখিত ভেরিয়েবলগুলো উপলব্ধ থাকে:

• পলিসির যে ভেরিয়েবলগুলো ব্যর্থ হয়েছে।
• ব্যর্থতার মুহূর্তে যে HTTP মেসেজ ভেরিয়েবলগুলো বিদ্যমান থাকে। উদাহরণস্বরূপ, যদি রেসপন্সে কোনো এরর আসে, তাহলে <TargetEndpoint> এর একটি FaultRule HTTP ডেটা response.status.code , message.content , error.content ইত্যাদি ব্যবহার করতে পারে। অথবা যদি কোনো কোটা পলিসি ব্যর্থ হয়, তাহলে আপনি ratelimit.{quota_policy_name}.exceed.count ভেরিয়েবলটি ব্যবহার করতে পারেন। কোন ভেরিয়েবল এবং HTTP ডেটাগুলো উপলব্ধ আছে তা খুঁজে বের করতে Trace টুল এবং পলিসি রেফারেন্স টপিকগুলো ব্যবহার করুন।

আরও তথ্য

• শর্তাবলী : শর্তাবলীর উল্লেখ এবং প্রবাহের চলক ও শর্তাবলী

• ত্রুটিসমূহ : পলিসি ত্রুটির রেফারেন্স
• ভেরিয়েবল : ভেরিয়েবল রেফারেন্সের জন্য , এবং প্রতিটি পলিসির সাথে উপলব্ধ ভেরিয়েবলগুলো জানতে স্বতন্ত্র পলিসি রেফারেন্স পেজগুলো দেখুন।

ত্রুটি ব্যবস্থাপনার সর্বোত্তম অনুশীলন

এপিআই প্রক্সি ডেভেলপমেন্টের জন্য ফল্ট হ্যান্ডলিং একটি প্রধান আর্কিটেকচারাল ডিজাইন টাস্ক। কীভাবে এবং কখন আপনি ত্রুটিগুলি পরিচালনা করবেন, ত্রুটির বার্তাগুলি কী হবে তা নির্ধারণ করবেন এবং ত্রুটির বার্তার ফরম্যাট ডিজাইন করবেন—এই বিষয়গুলো বের করতে সময় নেওয়া গুরুত্বপূর্ণ। এই বিষয়গুলো বের করার পরে (বা যখন আপনি এই বিষয়গুলো বের করবেন), তখন আপনার ফল্ট হ্যান্ডলিং বাস্তবায়নে সহায়তার জন্য এই সেরা অনুশীলনগুলি ব্যবহার করুন।

ফল্ট হ্যান্ডলিং ডিজাইন ও নির্মাণের ক্ষেত্রে নিম্নলিখিত কিছু সর্বোত্তম অনুশীলন অনুসরণ করা উচিত:

• প্রতিটি FaultRule-এর জন্য, একটি "বাইরের" <Condition> (যা <Step> এলিমেন্টের অংশ) প্রদান করুন। যে FaultRule-গুলিতে কোনো বাইরের শর্ত থাকে না, সেগুলি স্বয়ংক্রিয়ভাবে সত্য বলে বিবেচিত হয়। একটি FaultRule সত্য না মিথ্যা, তা নির্ধারণ করতে "ভেতরের" Step শর্তগুলি ব্যবহৃত হয় না । Edge যখন Step শর্তযুক্ত FaultRule-টি কার্যকর করে, শুধুমাত্র তখনই সেই শর্তগুলি মূল্যায়ন করা হয়। একটি FaultRule-এ সাধারণত Assign Message (বা অন্য) পলিসি সহ একাধিক Step থাকে, এবং প্রতিটি Step-এর একটি করে Step শর্ত থাকে।

• একই ধরনের একাধিক পলিসিতে (যেমন, একাধিক কোটা পলিসি) ত্রুটি পরিচালনা করার জন্য, আপনার পাওয়ার সম্ভাবনা আছে এমন প্রতিটি পলিসি ত্রুটির জন্য একটি করে FaultRule তৈরি করুন। উদাহরণস্বরূপ, কোটা পলিসির প্রতিটি সম্ভাব্য ত্রুটির জন্য একটি করে FaultRule তৈরি করুন, যেমন QuotaViolation , InvalidMessageWeight , StartTimeNotSupported । (পলিসি ত্রুটির জন্য পলিসি এরর রেফারেন্স দেখুন। যখন আপনি এমন অতিরিক্ত ত্রুটি খুঁজে পাবেন যা পরিচালনা করা প্রয়োজন, তখন আপনি পরে ফিরে এসে সেগুলোকে আপনার FaultRule-এ যোগ করতে পারেন। পুনরাবৃত্তিমূলক হওয়া ঠিক আছে, যদিও এর জন্য প্রক্সি রিডিপ্লয়মেন্টের প্রয়োজন হয়।) এই পদ্ধতিটি আপনাকে একই ধরনের ত্রুটি ধরতে সাহায্য করে, তা যে পলিসি থেকেই আসুক না কেন, যা আপনার FaultRules XML-কে কার্যকর করে তোলে।

  এরপর, আরও সূক্ষ্ম ত্রুটি নিয়ন্ত্রণের প্রয়োজন হলে অভ্যন্তরীণ স্টেপ কন্ডিশন ব্যবহার করুন। উদাহরণস্বরূপ, যদি আপনি আপনার রিকোয়েস্ট ফ্লোতে দুটি পলিসির মাধ্যমে ব্যক্তিগত ডেভেলপার কোটা এবং গ্লোবাল কোটা উভয়ই প্রয়োগ করেন, তাহলে আপনার "বাইরের" ফল্টরুল কন্ডিশনটি 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 কমিউনিটি থ্রেডটি দেখুন।

• যখন আপনি একই ধরনের একটিমাত্র পলিসি ব্যবহার করছেন, তখন ত্রুটি সামলানোর জন্য একটিমাত্র ফল্ট রুল বিবেচনা করুন যা সেই পলিসিটি ব্যর্থ হলে কার্যকর হবে, এবং প্রতিটি সম্ভাব্য ত্রুটির জন্য একাধিক ধাপ অন্তর্ভুক্ত করুন। এটি একাধিক ফল্ট রুলের (প্রতিটি ত্রুটির ধরনের জন্য একটি করে) পরিবর্তে একটিমাত্র ফল্ট রুল ব্যবহার করে আপনার XML-কে কার্যকর রাখে। উদাহরণস্বরূপ:

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

• যেখানে ত্রুটি ঘটবে (ক্লায়েন্ট সাইড <ProxyEndpoint> অথবা টার্গেট সাইড <TargetEndpoint> ) সেখানে FaultRules যোগ করুন। প্রতিটি অবস্থানে থাকা প্রতিটি পলিসির জন্য FaultRules অন্তর্ভুক্ত করুন।
• FaultRules-এ, আপনি এমন যেকোনো ধরনের পলিসি প্রয়োগ করতে পারেন যা ক্লায়েন্ট অ্যাপে একটি বার্তা ফেরত পাঠাতে পারে। এর জন্য AssignMessage পলিসিটি আদর্শ। এছাড়াও, আপনি যদি ত্রুটিগুলোর হিসাব রাখতে চান, তবে MessageLogging পলিসি ব্যবহার করে বার্তা লগ করার কথাও বিবেচনা করতে পারেন।
• FaultRule-এর সাথে একত্রে RaiseFault পলিসি ব্যবহার করার সময়, যখন RaiseFault পলিসি এবং FaultRule উভয়ই ডেটা ফেরত পাঠায়, তখন ফেরত পাঠানো রেসপন্স ডেটার মধ্যে সমন্বয় সাধন করুন। উদাহরণস্বরূপ, যদি আপনার RaiseFault পলিসি HTTP স্ট্যাটাস কোড রিসেট করে, তাহলে কোনো FaultRule-কে দিয়ে স্ট্যাটাস কোড রিসেট করাবেন না। সবচেয়ে খারাপ যা হতে পারে তা হলো, ক্লায়েন্ট অ্যাপে ডিফল্ট স্ট্যাটাস কোডটি ফেরত পাঠানো হবে।
• <DefaultFaultRule> কার্যকর করা:
  • যদি আপনি চান যে অন্য কোনো FaultRule কার্যকর না হলে একটি <DefaultFaultRule> সর্বদা কার্যকর হোক, তাহলে সেটিতে কোনো <Condition> অন্তর্ভুক্ত করবেন না।
  • যদি আপনি চান যে অন্য কোনো FaultRule কার্যকর হওয়ার পরেও একটি <DefaultFaultRule> সর্বদা কার্যকর হোক, <AlwaysEnforce>true</AlwaysEnforce> চাইল্ড এলিমেন্টটি যোগ করুন।

কেন্দ্রীভূত, পুনঃব্যবহারযোগ্য ত্রুটি ব্যবস্থাপনার জন্য প্যাটার্ন

নিম্নলিখিত Apigee কমিউনিটি পোস্টে কোড ডুপ্লিকেশন ছাড়াই কেন্দ্রীভূত ফল্ট হ্যান্ডলিং-এর একটি প্যাটার্ন বর্ণনা করা হয়েছে:

Apigee প্রক্সিগুলির জন্য একটি ত্রুটি পরিচালনা প্যাটার্ন

ফল্টরুল তৈরি করা

একটি FaultRule যোগ করতে হলে আপনাকে ProxyEndpoint বা TargetEndpoint-এর XML কনফিগারেশন সম্পাদনা করতে হবে। আপনি Edge UI ব্যবহার করে একটি API প্রক্সির Develop ভিউ-এর Code প্যানে এই সম্পাদনাটি করতে পারেন, অথবা ProxyEndpoint বা TargetEndpoint-কে সংজ্ঞায়িত করে এমন XML ফাইলটি সম্পাদনা করতে পারেন।

আপনি যদি ম্যানেজমেন্ট UI-তে FaultRule তৈরি করেন, তাহলে প্রথমে যে পলিসিগুলো কার্যকর করতে চান সেগুলো তৈরি করুন, তারপর সেগুলোকে FaultRule কনফিগারেশনে যোগ করুন। (যদি আপনি এমন কোনো FaultRule সেভ করার চেষ্টা করেন যা এখনো তৈরি হয়নি এমন কোনো পলিসিকে রেফারেন্স করে, তাহলে UI-তে একটি এরর পাবেন।)

একটি ফল্টরুল-এ পলিসি যোগ করা

যদিও আপনি FaultRule-এ যেকোনো পলিসি রাখতে পারেন, তবে কোনো ত্রুটির ক্ষেত্রে একটি কাস্টম প্রতিক্রিয়া বার্তা তৈরি করতে সাধারণত AssignMessage পলিসি ব্যবহার করা হয়। AssignMessage আপনাকে পেলোড, HTTP স্ট্যাটাস কোড, হেডার এবং কারণ বাক্যাংশ উপাদানগুলির সাথে একটি HTTP প্রতিক্রিয়া কনফিগার করতে সক্ষম করে।

নিচের উদাহরণটি একটি সাধারণ AssignMessage পলিসি কনফিগারেশন দেখাচ্ছে:

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

আপনি এখন আপনার FaultRule-এ এই পলিসিটি ব্যবহার করতে পারেন। লক্ষ্য করুন, আপনি FaultRule-এ কীভাবে নাম ধরে AssignMessage পলিসিটিকে উল্লেখ করেছেন:

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

আপনি যখন উপরের কনফিগারেশনটি স্থাপন করবেন, তখন কোনো অ্যাপ একটি অবৈধ এপিআই কী উপস্থাপন করলেই এপিআই প্রক্সি fault_invalidkey নামক AssignMessage পলিসিটি কার্যকর করবে।

আপনি একটি FaultRule-এ একাধিক পলিসি কার্যকর করতে পারেন, যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে:

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

পলিসিগুলো নির্ধারিত ক্রমেই কার্যকর হয়। উদাহরণস্বরূপ, আপনি FaultRule-এ MessageLogging পলিসি , ExtractVariables পলিসি , AssignMessage পলিসি , বা অন্য যেকোনো পলিসি ব্যবহার করতে পারেন। মনে রাখবেন যে, নিম্নলিখিত পরিস্থিতিগুলোর কোনোটি ঘটলে FaultRule-এর প্রক্রিয়াকরণ অবিলম্বে বন্ধ হয়ে যায়:

• FaultRule-এর যেকোনো পলিসি একটি ত্রুটির কারণ হয়।
• FaultRule-এর অন্তর্ভুক্ত যেকোনো পলিসি RaiseFault ধরনের।

FaultRule থেকে ফেরত আসা কাস্টম ত্রুটি বার্তা নির্ধারণ করা

একটি উত্তম অনুশীলন হিসেবে, আপনার এপিআই (API)-গুলোর জন্য সুস্পষ্ট ত্রুটি প্রতিক্রিয়া নির্ধারণ করা উচিত। এর মাধ্যমে, আপনি আপনার ক্লায়েন্টদের কাছে সামঞ্জস্যপূর্ণ এবং সহায়ক তথ্য পৌঁছে দিতে পারবেন।

নিম্নলিখিত AssignMessage পলিসি উদাহরণটি একটি InvalidApiKey ত্রুটির ক্ষেত্রে ক্লায়েন্টের কাছে ফেরত পাঠানো কাস্টম ত্রুটি প্রতিক্রিয়া সংজ্ঞায়িত করতে <Payload> , <StatusCode> , এবং <ReasonPhase> ট্যাগ ব্যবহার করে (পূর্ববর্তী 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>

এই উত্তরে অন্তর্ভুক্ত রয়েছে:

• পেলোডটিতে ত্রুটির বার্তা এবং সাপোর্টের সাথে যোগাযোগের জন্য একটি ইমেল ঠিকানা রয়েছে।
• প্রতিক্রিয়ায় প্রাপ্ত HTTP স্ট্যাটাস কোড।
• কারণ বাক্যাংশ, যা হলো ত্রুটিটির একটি সংক্ষিপ্ত বিবরণ।

একটি ডিফল্ট ফল্ট রুল তৈরি করা

একটি DefaultFaultRule এমন যেকোনো ত্রুটির জন্য একটি এক্সেপশন হ্যান্ডলার হিসেবে কাজ করে, যা অন্য কোনো FaultRule দ্বারা স্পষ্টভাবে হ্যান্ডেল করা হয় না। যদি সমস্ত FaultRule-এর শর্তগুলো ত্রুটিটির সাথে না মেলে, তাহলে DefaultFaultRule-টি ত্রুটিটি হ্যান্ডেল করে। একটি ProxyEndpoint বা TargetEndpoint-এর চাইল্ড এলিমেন্ট হিসেবে <DefaultFaultRule> ট্যাগটি যোগ করে ডিফল্ট ফল্ট হ্যান্ডলিং সক্রিয় করুন।

উদাহরণস্বরূপ, নিচের TargetEndpoint কনফিগারেশনটি একটি DefaultFaultRule সংজ্ঞায়িত করে যা ReturnGenericError নামের একটি পলিসিকে আহ্বান করে:

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

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

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

DefaultFaultRule সাধারণত যেকোনো অপ্রত্যাশিত ত্রুটির জন্য একটি সাধারণ ত্রুটি বার্তা ফেরত দিতে ব্যবহৃত হয়, যেমন এমন একটি বার্তা যাতে প্রযুক্তিগত সহায়তার জন্য যোগাযোগের তথ্য থাকে। এই ডিফল্ট প্রতিক্রিয়াটি দুটি উদ্দেশ্য পূরণ করে: এটি একদিকে যেমন ডেভেলপার-বান্ধব তথ্য সরবরাহ করে, তেমনই অন্যদিকে ব্যাকএন্ড ইউআরএল বা অন্যান্য তথ্য গোপন রাখে যা সিস্টেমের নিরাপত্তা বিঘ্নিত করতে ব্যবহার করা হতে পারে।

উদাহরণস্বরূপ, একটি জেনেরিক ত্রুটি ফেরত দেওয়ার জন্য আপনি নিম্নলিখিত AssignMessage পলিসিটি সংজ্ঞায়িত করেন:

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

Include the <AlwaysEnforce> element in the <DefaultFaultRule> tag to execute the DefaultFaultRule for every error, even if another FaultRule has already been executed. The DefaultFaultRule is always the last FaultRule to execute:

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

One use of the DefaultFaultRule is to determine the type of error that occurs when you otherwise cannot determine it. For example, your API proxy is failing for an error that you cannot determine. Use the DefaultFaultRule to invoke the following AssignMessage policy. This policy writes the fault.name value to a header named DefaultFaultHeader in the response:

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

You can then view the header in the Edge trace tool or on the response to see what caused the error.

Adding message logging to the PostClientFlow

The PostClientFlow is the only flow that executes after the proxy enters the error state. Only the MessageLogging policy can be attached to this flow, which is executed after the response is sent back to the client. Although attaching the MessageLogging policy to this flow is technically not error handling, you can use it to log information in the event of an error. Because it is executed regardless of whether the proxy succeeded or failed, you can put Message Logging policies in the PostClientFlow and be guaranteed that they always execute.

Handling policy faults within the current flow

The examples shown so far all use a FaultRule on the ProxyEndpoint or TargetEndpoint to handle any policy errors as part of the error state. That is because the default value of the continueOnError element of a policy is false , meaning that when an error occurs in a policy, control is directed to the error state. Once in the error state, you cannot return control back to the normal pipeline and you typically return some form of error message to the calling app.

However, if you set the continueOnError element to true for a policy, control stays in the current flow and the next policy in the pipeline executes after the policy that caused the error. The advantage to handling the error in the current flow is that you might have a way to recover from the error to complete processing of the request.

Shown below is a VerifyAPIKey policy named verify-api-key with the continueOnError element set to true:

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

If the API key is missing or invalid, then the VerifyAPIKey policy sets the oauthV2.verify-api-key.failed variable to true , but processing continues in the current flow.

You then add VerifyAPIKey policy as a step in the PreFlow of the ProxyEndpoint:

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

Notice how the next step in the PreFlow uses a condition to test for the existence of an error. If an error occurred in the VerifAPIKey policy, then the policy named FaultInFlow policy executes. Otherwise, the FaultInFlow policy is skipped. The FaultInFlow policy can do many things, such as logging the error, attempting to fix the error, or performing some other action.

Triggering an error by using the RaiseFault policy

You can use the RaiseFault policy at any time in a flow to trigger an error. When a RaiseFault policy executes, it terminates the current flow and transfers control to the error state.

One use of the RaiseFault policy is to test for a specific condition that another policy might not detect. In the example above, you added a <Condition> tag to a PreFlow <Step> tag that caused the policy FaultInFlow to execute if the condition is met. If FaultInFlow is a RaiseFault policy, then control transfers to the error state. Or, you might insert a RaiseFault policy in a flow to debug and test your FaultRules.

When a RaiseFault policy triggers an error, you can use the following FaultRule and condition to process it:

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

Note that the condition tests for a fault named RaiseFault . The RaiseFault policy always sets the value of fault.name to RaiseFault .

Custom handling of HTTP error codes from the target server

The examples shown in the previous sections apply to errors created by policies. However you can also create a custom response for transport-level errors, meaning HTTP errors returned from the target server. To control the response from an HTTP error, configure a TargetEndpoint to process HTTP response codes.

By default, Edge treats HTTP response codes in the 1xx-3xx range as 'success', and HTTP response codes in the range 4xx-5xx as 'failure'. That means any response from the backend service with an HTTP response code 4xx-5xx automatically invokes the error state, which then returns an error message directly to the requesting client.

You can create custom handlers for any HTTP response codes. For example, you might not want to treat all HTTP response codes in the range 4xx-5xx as 'failure' but only 5xx, or you might want to return custom error messages for HTTP response codes 400 and 500.

In the next example, you use the success.codes property to configure the TargetEndpoint to treat HTTP response codes 400 and 500 as a success, along with the default HTTP codes. By treating those codes as a success, the TargetEndpoint takes over the processing of the response message, instead of invoking the error state:

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

As you can see in this example, you can use wildcards to set the success.codes property to a range of values..

Setting the success.codes property overwrites the default values. Therefore, if you want to add HTTP code 400 to the list of default success codes, set this property as:

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

But, if you only want HTTP code 400 to be treated as a success code, set the property as:

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

You can now define custom handlers for HTTP response codes 400 and 500 to return a customized response message to the requesting app. The following TargetEndpoint uses the policy named ReturnError to handle HTTP 400 and 500 response codes:

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

This TargetEndpoint configuration causes the policy called ReturnError to handle the response whenever the TargetEndpoint encounters an HTTP response code of 400 or 500.

Fault taxonomy

API Services organizes faults into the following categories and subcategories.

An error is always accompanied by a text description of the reason for the failure. When the system raises a fault, a set of attributes are populated to assist in troubleshooting. A fault includes the following information:

• কারণ
• User-defined custom attributes