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

আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশনে যান । তথ্য

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

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

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

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

ভিডিও

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

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

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

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

নিম্নলিখিত পরিস্থিতিতে একটি API প্রক্সি স্বয়ংক্রিয়ভাবে একটি ত্রুটি ছুঁড়ে ফেলে:

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

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

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

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

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

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

এটি কেবল আপনাকে দেখানোর জন্য যে আপনি কাস্টম ত্রুটিগুলি ফেলে দিতে পারেন। আমরা FaultRules বনাম RaiseFault নীতি বিভাগে RaiseFault নীতি সম্পর্কে আরও বিস্তারিত আলোচনা করব।

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

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

ত্রুটি দেখা দিলে API প্রক্সিগুলি কী করে

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

প্রক্সি পাইপলাইন থেকে বেরিয়ে আসুন

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

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

1. API কী যাচাই করুন
2. কোটা
3. JSON থেকে XML

API কী যাচাইকরণের সময় যদি কোনও ত্রুটি দেখা দেয়, তাহলে API প্রক্সিটি একটি ত্রুটি অবস্থায় চলে যায়। কোটা এবং JSON থেকে XML নীতিগুলি কার্যকর করা হয় না, প্রক্সিটি TargetEndpoint-এ অগ্রসর হয় না এবং ক্লায়েন্ট অ্যাপে একটি ত্রুটি বার্তা ফিরে আসে।

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

ত্রুটি অবস্থায়, API প্রক্সিগুলি ক্লায়েন্ট অ্যাপে একটি ডিফল্ট ত্রুটি বার্তা ফেরত দেওয়ার আগে API প্রক্সি কনফিগারেশনে নিম্নলিখিত (ক্রমানুসারে) উপস্থিতি পরীক্ষা করে:

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

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

সহজ ত্রুটি ব্যবস্থাপনার উদাহরণ

একটি সহজ উদাহরণ দিয়ে শুরু করা যাক, যেখানে একটি API প্রক্সিতে কল করার সময় একটি প্রয়োজনীয় API কী থাকে না। ডিফল্টরূপে, ক্লায়েন্ট অ্যাপে ফিরে আসা প্রতিক্রিয়াটি নিম্নরূপ:

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

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

একজন API ডেভেলপার হিসেবে, যারা শেষ পর্যন্ত ত্রুটি বার্তাটি পাবে তাদের চাহিদা পূরণের জন্য এই বার্তাটি পরিবর্তন করা আপনার উপর নির্ভর করে, তা সে iOS অ্যাপ ডেভেলপারই হোক বা কোনও অভ্যন্তরীণ পরীক্ষামূলক গোষ্ঠী যার নিজস্ব ত্রুটি বার্তা বিন্যাসের প্রয়োজনীয়তা রয়েছে।

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

১. কাস্টম বার্তা সংজ্ঞায়িত করে এমন একটি নীতি তৈরি করুন

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

API প্রক্সির কোনও প্রবাহের সাথে নীতিটি সংযুক্ত করবেন না। এটি কেবল প্রক্সি বান্ডেলের মধ্যেই বিদ্যমান থাকা যথেষ্ট। ম্যানেজমেন্ট UI প্রক্সি এডিটরে এটি করতে, ডেভেলপ ট্যাবে যান এবং নেভিগেশন প্যানে যান এবং নীতি বারে + আইকনে ক্লিক করুন।

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

AssignMessage নীতির একটি উদাহরণ নিচে দেওয়া হল যা:

• একটি JSON বার্তা ফেরত দেয়।
• একটি HTTP স্ট্যাটাস কোড সেট করে (911, যা আপনার নমনীয়তা বোঝানোর জন্য একটি স্পষ্টতই অস্তিত্বহীন স্ট্যাটাস কোড)। স্ট্যাটাস কোডটি HTTP হেডারে প্রদর্শিত হয়।
• একটি HTTP কারণ বাক্যাংশ সেট করে (এই অনুপস্থিত API কী ত্রুটির জন্য ডিফল্ট "অননুমোদিত" কারণ বাক্যাংশটি প্রতিস্থাপন করতে)। 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 কী কোয়েরি প্যারামিটার হিসেবে অন্তর্ভুক্ত করতে ভুলে গেছেন।

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

২. <FaultRule> তৈরি করুন যা নীতিটি ট্রিগার করবে

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

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

উদাহরণ

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

গুরুত্বপূর্ণ বিষয়:

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

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

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

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

একাধিক ত্রুটি-নিয়ম এবং কার্যকর করার যুক্তি

"Simple fault handling example" বিভাগে, আমরা একটি একক FaultRule এবং শর্তের একটি সহজ উদাহরণ ব্যবহার করেছি। একটি বাস্তব-বিশ্বের API প্রকল্পে, সম্ভাব্য সমস্ত ত্রুটি ঘটতে পারে, আপনার <ProxyEndpoint> এবং <TargetEndpoint> উভয় ক্ষেত্রেই একাধিক FaultRules এবং একটি DefaultFaultRule থাকার সম্ভাবনা থাকে। যদিও, শেষ পর্যন্ত, যখন একটি API প্রক্সি ত্রুটি অবস্থায় চলে যায় তখন শুধুমাত্র একটি FaultRule কার্যকর করা হয়।

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

ফল্টরুলস কার্যকরকরণ

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

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

   • যদি একটি FaultRule কার্যকর করা হয়, কিন্তু FaultRule-এর কোনও ধাপ কার্যকর না করা হয় (কারণ তাদের শর্তগুলি "মিথ্যা" হিসাবে মূল্যায়ন করা হয়), তাহলে Edge-উত্পন্ন ডিফল্ট ত্রুটি বার্তাটি ক্লায়েন্ট অ্যাপে ফেরত পাঠানো হয়। <DefaultFaultRule> কার্যকর করা হয় না , কারণ Edge ইতিমধ্যেই তার একটি FaultRule কার্যকর করেছে।

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

ইনলাইন মন্তব্য সহ উদাহরণগুলি নিচে দেওয়া হল।

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

ProxyEndpoint FaultRules এর মূল্যায়ন নিচ থেকে উপরে, তাই নিচের নমুনার শেষ 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 FaultRules এর মূল্যায়ন উপর থেকে নীচে পর্যন্ত করা হয়েছে, তাই নিম্নলিখিত নমুনায় প্রথম FaultRule পড়া শুরু করুন এবং তারপর নিচের দিকে এগিয়ে যান। শেষের DefaultFaultRule দেখুন।

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

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

ফল্ট নিয়মের ক্রম

আগের উদাহরণে আপনি দেখতে পাচ্ছেন, ProxyEndpoint বনাম TargetEndpoint-এ ত্রুটিটি ঘটে কিনা তার উপর নির্ভর করে আপনি আপনার FaultRules কে কোন ক্রমে রাখবেন তা গুরুত্বপূর্ণ।

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

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

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

ত্রুটির নিয়মগুলি শুধুমাত্র একটি ত্রুটি অবস্থায় ট্রিগার করা হয় (continueOnError সম্পর্কে)

শিরোনামটি মনে হতে পারে আমরা নিজেদের পুনরাবৃত্তি করছি, কিন্তু একটি প্রক্সি ত্রুটির কারণে একটি API প্রক্সি একটি ত্রুটি অবস্থায় প্রবেশ করে - অথবা বরং, একটি ত্রুটি অবস্থায় প্রবেশ না করে - সে সম্পর্কে সচেতন থাকার জন্য একটি বিশেষ সূক্ষ্মতা রয়েছে: একটি নীতিতে continueOnError বৈশিষ্ট্য।

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

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

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

ফল্টরুলস কোথায় সংজ্ঞায়িত করবেন: প্রক্সিএন্ডপয়েন্ট অথবা টার্গেটএন্ডপয়েন্ট

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

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

এখানে আরেকটি উদাহরণ দেওয়া হল। যদি <ProxyEndpoint> প্রতিক্রিয়াতে একটি RaiseFault নীতি একটি ত্রুটি ট্রিগার করে, তাহলে <TargetEndpoint> এ একটি FaultRule কার্যকর হবে না।

ফল্টরুলস বনাম রাইজফল্ট নীতি

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

সংক্ষেপে:

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

• 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-এর অন্যান্য শর্তের মতো FaultRule শর্ত তৈরি করেন, যেমন কন্ডিশনাল ফ্লো বা RaiseFault শর্তের জন্য।

এই বিভাগের বাকি অংশ প্রসঙ্গে বলতে গেলে, এখানে একটি নমুনা ফল্ট নিয়ম রয়েছে যার একটি বাইরের ফল্টরুল শর্ত এবং একটি অভ্যন্তরীণ স্টেপ শর্ত রয়েছে।

<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 ভ্যারিয়েবলের উদাহরণ নিচে দেওয়া হল। পলিসির নেমস্পেসের জন্য, প্রতিটি পলিসি রেফারেন্স টপিকে ফ্লো ভ্যারিয়েবলগুলি দেখুন।

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

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

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

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

অধিক তথ্য

• শর্তাবলী : শর্তাবলীর রেফারেন্স এবং প্রবাহের ভেরিয়েবল এবং শর্তাবলী

• ত্রুটি : নীতি ত্রুটির রেফারেন্স
• ভেরিয়েবল : ভেরিয়েবল রেফারেন্স , এবং প্রতিটি পলিসির সাথে উপলব্ধ ভেরিয়েবলের জন্য পৃথক পলিসি রেফারেন্স পৃষ্ঠাগুলি দেখুন।

ত্রুটি মোকাবেলার জন্য সর্বোত্তম অনুশীলন

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

নকশা এবং বিল্ডিং ফল্ট হ্যান্ডলিং এর কিছু সেরা অনুশীলন নিচে দেওয়া হল:

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

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

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

• যখন আপনি এক ধরণের একক নীতি ব্যবহার করেন তখন ত্রুটিগুলি পরিচালনা করার জন্য, একটি একক ফল্ট নিয়ম বিবেচনা করুন যা সেই নীতিটি ব্যর্থ হলে কার্যকর করা হয় এবং প্রতিটি সম্ভাব্য ত্রুটির সাথে মানানসই একাধিক পদক্ষেপ অন্তর্ভুক্ত করুন। এটি একাধিক FaultRules (প্রতিটি ত্রুটির ধরণের জন্য একটি) ব্যবহার না করে একটি একক FaultRule ব্যবহার করে আপনার 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>

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

কেন্দ্রীভূত, পুনঃব্যবহারযোগ্য ফল্ট হ্যান্ডলিং এর প্যাটার্ন

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

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

ফল্টরুল তৈরি করা হচ্ছে

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

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

একটি FaultRule-এ নীতিমালা যোগ করা

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>

যখন আপনি উপরের কনফিগারেশনটি স্থাপন করবেন, তখন যখনই কোনও অ্যাপ একটি অবৈধ API কী উপস্থাপন করবে, তখন API প্রক্সি 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>

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

উদাহরণস্বরূপ, আপনি একটি জেনেরিক ত্রুটি ফেরত দেওয়ার জন্য নিম্নলিখিত 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