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

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

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

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

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

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

ভিডিও

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

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

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

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

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

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

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

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

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

আপনি একটি API প্রক্সি ফ্লোতে একটি RaiseFault নীতি যোগ করতে পারেন যেমন আপনি অন্য কোনো নীতি করেন। নিম্নলিখিত প্রক্সি কনফিগারেশন উদাহরণে, Raise-Fault-1 নীতি টার্গেটএন্ডপয়েন্ট প্রতিক্রিয়ার সাথে সংযুক্ত করা হয়েছে। টার্গেট সার্ভিসের প্রতিক্রিয়াতে "অনুপলব্ধ" শব্দটি উপস্থিত থাকলে, 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 নীতিগুলি কার্যকর করা হয় না, প্রক্সি টার্গেটএন্ডপয়েন্টে যায় না এবং ক্লায়েন্ট অ্যাপে একটি ত্রুটি বার্তা ফেরত আসে৷

FaultRules জন্য চেক করুন

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

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

সংক্ষেপে, 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 অ্যাপ বিকাশকারী হোক বা একটি অভ্যন্তরীণ পরীক্ষামূলক গোষ্ঠী যার নিজস্ব ত্রুটি বার্তা বিন্যাসের প্রয়োজনীয়তা রয়েছে৷

এই ত্রুটিটি পরিচালনা করার জন্য আপনি কীভাবে একটি কাস্টম ত্রুটি বার্তা তৈরি করবেন তার একটি প্রাথমিক উদাহরণ এখানে। এর জন্য প্রয়োজন 1) একটি নীতি যা কাস্টম বার্তাকে সংজ্ঞায়িত করে এবং 2) একটি ফল্ট রুল যা নীতিটি কার্যকর করে যখন প্রক্সি একটি ত্রুটির অবস্থায় যায়৷

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

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

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

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

নিম্নলিখিত একটি উদাহরণ AssignMessage নীতি যা:

• একটি JSON বার্তা ফেরত দেয়।
• একটি এইচটিটিপি স্ট্যাটাস কোড সেট করে (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 কী অন্তর্ভুক্ত করতে ভুলে গেছেন।

কিন্তু কিভাবে এই নীতি কার্যকর করা হয়? পরবর্তী অধ্যায় আপনাকে দেখায়.

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

প্রক্সি কনফিগারেশনের <ProxyEndpoint> বা <TargetEndpoint> বিভাগে, আপনি একটি <FaultRules> XML ব্লক যোগ করবেন যাতে এক বা একাধিক স্বতন্ত্র <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 এ সংজ্ঞায়িত করা হয়েছে। এটা গুরুত্বপূর্ণ। পরবর্তীতে প্রক্সিএন্ডপয়েন্ট বনাম টার্গেটএন্ডপয়েন্টে ফল্ট রুলস রাখার বিষয়ে আরও।
• <Name> - কার্যকর করার নীতির নাম। নামটি মূল উপাদানে নীতির name বৈশিষ্ট্য থেকে এসেছে, যেমনটি পূর্বে নীতির উদাহরণে দেখানো হয়েছে।

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

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

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

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

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

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

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

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

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

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

3. যদি কোনো ফল্ট রুল কার্যকর করা না হয়, তাহলে এজ <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>

ফল্ট নিয়ম আদেশ

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

যেমন:

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

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

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

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

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

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

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

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

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

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

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

FaultRules বনাম RaiseFault নীতি

ফল্ট নিয়ম এবং 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 ট্রিগার হয়ে যায় এবং একটি ত্রুটি বার্তা ফেরত দেয়, তাহলে ক্লায়েন্ট অ্যাপে কী ফেরত দেওয়া হবে?

• যেহেতু FaultRule বা DefaultFaultRule RaiseFault নীতির পরে কার্যকর করা হয়, তাই 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 কার্যকর করার মূল চাবিকাঠি। আপনি FaultRule শর্তগুলি তৈরি করেন যেভাবে আপনি এজ-এর অন্যান্য অবস্থার জন্য করেন, যেমন শর্তসাপেক্ষ প্রবাহ বা RaiseFault শর্তগুলির জন্য।

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

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

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

fault.name এবং {policy_namespace}.{policy_name}.failed ভেরিয়েবল উপলভ্য হয় যখন একটি নীতি একটি ত্রুটি থ্রো করে।

দোষ.নাম

যখন একটি নীতি ব্যর্থ হয়, fault.name ভেরিয়েবল ব্যবহার করে একটি শর্তে ত্রুটি ধরুন। যেমন:

<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 প্রক্সি একটি ত্রুটির অবস্থায় যায়, তখন শর্তে ব্যবহারের জন্য শুধুমাত্র উপলব্ধ ভেরিয়েবলগুলি হল:

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

আরও তথ্য

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

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

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

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

নিম্নোক্ত ত্রুটি হ্যান্ডলিং ডিজাইন এবং বিল্ডিং কিছু সেরা অনুশীলন:

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

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

  তারপর যদি আপনার আরও সূক্ষ্ম-দানাযুক্ত ত্রুটি নিয়ন্ত্রণের প্রয়োজন হয় তবে অভ্যন্তরীণ পদক্ষেপের শর্তগুলি ব্যবহার করুন। উদাহরণস্বরূপ, আপনি যদি আপনার অনুরোধের প্রবাহে দুটি নীতি সহ পৃথক বিকাশকারী কোটা এবং গ্লোবাল কোটা উভয়ই প্রয়োগ করছেন, তাহলে QuotaViolation ত্রুটিতে ট্রিগার করার জন্য আপনার "বাহ্যিক" ফল্ট রুলের শর্ত সেট করুন (যেটি উভয় ক্ষেত্রেই কোটা শেষ হয়ে গেলে ফেলে দেওয়া হয়)। তারপর আপনার উভয় কোটা নীতিতে exceed.count ভেরিয়েবলের মূল্যায়ন করার জন্য ধাপ শর্ত সেট করুন। শুধুমাত্র প্রাসঙ্গিক ত্রুটি ক্লায়েন্টকে পাঠানো হয় (ডেভেলপার কোটা ওভারেজ বা গ্লোবাল কোটা ওভারেজ)। এখানে এই কনফিগারেশনের একটি উদাহরণ:

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

  আরেকটি উদাহরণের জন্য, এই Apigee কমিউনিটি থ্রেডটি দেখুন।

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

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

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

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

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

একটি 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 এ এই নীতিটি ব্যবহার করতে পারেন। লক্ষ্য করুন কিভাবে আপনি ফল্ট রুলে নাম দ্বারা 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-এর যে কোনো পলিসি RaiseFault টাইপের

একটি FaultRule থেকে ফিরে কাস্টম ত্রুটি বার্তা সংজ্ঞায়িত করা

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

নিম্নলিখিত 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 তৈরি করা হচ্ছে

একটি DefaultFaultRule অন্য কোন ত্রুটির জন্য একটি ব্যতিক্রম হ্যান্ডলার কাজ করে যা স্পষ্টভাবে অন্য FaultRule দ্বারা পরিচালিত হয় না। যদি সমস্ত FaultRules এর শর্তাবলী ত্রুটির সাথে মেলে না, তাহলে DefaultFaultRule ত্রুটিটি পরিচালনা করে। একটি ProxyEndpoint বা একটি 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>

প্রতিটি ত্রুটির জন্য DefaultFaultRule কার্যকর করতে <DefaultFaultRule> ট্যাগে <AlwaysEnforce> উপাদানটি অন্তর্ভুক্ত করুন, এমনকি অন্য একটি FaultRule ইতিমধ্যেই কার্যকর করা হলেও। DefaultFaultRule সর্বদাই কার্যকর করার শেষ ফল্টরুল:

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

ডিফল্টফাল্ট্রুলের একটি ব্যবহার হ'ল আপনি যখন অন্যথায় এটি নির্ধারণ করতে পারবেন না তখন ত্রুটিটির ধরণটি নির্ধারণ করা। উদাহরণস্বরূপ, আপনার এপিআই প্রক্সি এমন একটি ত্রুটির জন্য ব্যর্থ হচ্ছে যা আপনি নির্ধারণ করতে পারবেন না। নিম্নলিখিত অ্যাসাইনমেসেজ নীতিটি অনুরোধ করতে ডিফল্টফুলট্রুল ব্যবহার করুন। এই নীতিটি প্রতিক্রিয়াতে DefaultFaultHeader নামের একটি শিরোনামে fault.name মান লিখেছেন:

<AssignMessage async="false" continueOnError="false" enabled="true" name="DefaultFaultRule">
  <DisplayName>DefaultFaultRule</DisplayName>
  <Set>
    <Headers>
      <Header name="DefaultFaultHeader">{fault.name}</Header>
    </Headers>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" transport="http" type="response"/>
</AssignMessage>

তারপরে আপনি প্রান্তের ট্রেস সরঞ্জামে বা ত্রুটিটি কী কারণে ঘটেছে তা দেখতে প্রতিক্রিয়াটিতে শিরোনামটি দেখতে পারেন।

পোস্টক্লিয়েন্টফ্লোতে বার্তা লগিং যুক্ত করা হচ্ছে

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

বর্তমান প্রবাহের মধ্যে নীতি ত্রুটিগুলি পরিচালনা করা

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

তবে, আপনি যদি কোনও নীতিমালার জন্য continueOnError উপাদানটিকে true সেট করেন তবে নিয়ন্ত্রণ বর্তমান প্রবাহে থাকে এবং পাইপলাইনে পরবর্তী নীতিটি ত্রুটি সৃষ্টি করে এমন নীতিমালার পরে কার্যকর করে। বর্তমান প্রবাহে ত্রুটিটি পরিচালনা করার সুবিধাটি হ'ল আপনার অনুরোধের প্রক্রিয়াজাতকরণ সম্পূর্ণ করতে ত্রুটি থেকে পুনরুদ্ধার করার কোনও উপায় থাকতে পারে।

নীচে দেখানো হয়েছে একটি যাচাই-এপিআই-কী নামে একটি verify-api-key continueOnError করা হয়েছে true:

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

যদি এপিআই কীটি অনুপস্থিত বা অবৈধ থাকে, তবে যাচাইযোগ্যতা নীতিটি oauthV2.verify-api-key.failed ভেরিয়েবলকে true হিসাবে সেট করে, তবে বর্তমান প্রবাহে প্রক্রিয়াজাতকরণ অব্যাহত থাকে।

তারপরে আপনি প্রক্সিএন্ডপয়েন্টের প্রিফ্লোয়ের একটি পদক্ষেপ হিসাবে যাচাইযোগ্য নীতি যুক্ত করুন:

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

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

রিসফাল্ট নীতি ব্যবহার করে একটি ত্রুটি ট্রিগার করা

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

রাইজফাল্ট নীতিমালার একটি ব্যবহার হ'ল একটি নির্দিষ্ট শর্তের জন্য পরীক্ষা করা যা অন্য নীতি সনাক্ত করতে পারে না। উপরের উদাহরণে, আপনি একটি প্রিফ্লো <Step> ট্যাগের সাথে একটি <Condition> ট্যাগ যুক্ত করেছেন যা শর্তটি পূরণ করা হলে নীতিগত FaultInFlow কার্যকর করতে পারে। যদি FaultInFlow একটি রাইজফাল্ট নীতি হয় তবে ত্রুটি অবস্থায় স্থানান্তর নিয়ন্ত্রণ করুন। অথবা, আপনি আপনার ফ্যালট্রুলগুলি ডিবাগ এবং পরীক্ষা করার জন্য একটি প্রবাহে একটি রাইজফল্ট নীতি সন্নিবেশ করতে পারেন।

যখন কোনও রিসফাল্ট নীতি কোনও ত্রুটি ট্রিগার করে, আপনি এটি প্রক্রিয়া করতে নিম্নলিখিত ফাল্ট্রুল এবং শর্তটি ব্যবহার করতে পারেন:

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

নোট করুন যে শর্তটি RaiseFault নামে একটি ত্রুটির জন্য পরীক্ষা করে। রাইজফল্ট নীতি সর্বদা RaiseFault fault.name মান নির্ধারণ করে।

লক্ষ্য সার্ভার থেকে এইচটিটিপি ত্রুটি কোডগুলির কাস্টম হ্যান্ডলিং

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

ডিফল্টরূপে, এজ 1xx-3xx রেঞ্জের এইচটিটিপি প্রতিক্রিয়া কোডগুলি 'সাফল্য' হিসাবে এবং 'ব্যর্থতা' হিসাবে 4xx-5xx রেঞ্জের এইচটিটিপি প্রতিক্রিয়া কোডগুলি বিবেচনা করে। এর অর্থ এইচটিটিপি রেসপন্স কোড 4xx-5xx সহ ব্যাকএন্ড পরিষেবা থেকে কোনও প্রতিক্রিয়া স্বয়ংক্রিয়ভাবে ত্রুটি অবস্থার আহ্বান জানায়, যা পরে অনুরোধকারী ক্লায়েন্টকে সরাসরি একটি ত্রুটি বার্তা দেয়।

আপনি যে কোনও এইচটিটিপি প্রতিক্রিয়া কোডের জন্য কাস্টম হ্যান্ডলার তৈরি করতে পারেন। উদাহরণস্বরূপ, আপনি 4xx-5xx রেঞ্জের সমস্ত এইচটিটিপি রেসপন্স কোডগুলি 'ব্যর্থতা' হিসাবে চিকিত্সা করতে চাইতে পারেন না তবে কেবল 5xx, বা আপনি এইচটিটিপি প্রতিক্রিয়া কোড 400 এবং 500 এর জন্য কাস্টম ত্রুটি বার্তাগুলি ফিরিয়ে দিতে চাইতে পারেন।

পরবর্তী উদাহরণে, আপনি সাফল্যটি ব্যবহার করেন D এই কোডগুলিকে একটি সাফল্য হিসাবে বিবেচনা করে, টার্গেটেন্ডপয়েন্টটি ত্রুটি অবস্থার জন্য অনুরোধ না করে প্রতিক্রিয়া বার্তার প্রক্রিয়াজাতকরণ গ্রহণ করে:

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

আপনি এই উদাহরণে দেখতে পাচ্ছেন, আপনি সাফল্য সেট করতে ওয়াইল্ডকার্ডগুলি ব্যবহার করতে পারেন od কোডগুলি সম্পত্তি বিভিন্ন মানগুলিতে ..

সাফল্য নির্ধারণ। সম্পত্তি সম্পত্তি ডিফল্ট মানগুলিকে ওভাররাইট করে। অতএব, আপনি যদি ডিফল্ট সাফল্য কোডগুলির তালিকায় HTTP কোড 400 যুক্ত করতে চান তবে এই সম্পত্তিটি সেট করুন:

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

তবে, আপনি যদি কেবল এইচটিটিপি কোড 400 কে সাফল্যের কোড হিসাবে বিবেচনা করতে চান তবে সম্পত্তিটি সেট করুন:

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

অনুরোধকারী অ্যাপ্লিকেশনটিতে একটি কাস্টমাইজড প্রতিক্রিয়া বার্তা ফেরাতে আপনি এখন HTTP প্রতিক্রিয়া কোড 400 এবং 500 এর জন্য কাস্টম হ্যান্ডলারগুলি সংজ্ঞায়িত করতে পারেন। নিম্নলিখিত টার্গেটেন্ডপয়েন্টটি HTTP 400 এবং 500 প্রতিক্রিয়া কোডগুলি পরিচালনা করতে ReturnError নামের নীতিটি ব্যবহার করে:

<TargetEndpoint name="default">
  <PreFlow name="PreFlow">
    <Request/>
    <Response>
      <Step>
        <Name>ReturnError</Name>
        <Condition>(response.status.code = 400) or (response.status.code = 500)</Condition>
      </Step>
    </Response>
  </PreFlow>

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

এই টার্গেট পয়েন্ট কনফিগারেশনটি যখনই টার্গেটেন্ডপয়েন্টটি 400 বা 500 এর এইচটিটিপি রেসপন্স কোডের মুখোমুখি হয় তখনই ReturnError নামক নীতিটি প্রতিক্রিয়া পরিচালনা করে।

ফল্ট ট্যাক্সনোমি

এপিআই পরিষেবাগুলি নিম্নলিখিত বিভাগ এবং উপশ্রেণীতে ত্রুটিগুলি সংগঠিত করে।

একটি ত্রুটি সর্বদা ব্যর্থতার কারণের একটি পাঠ্য বিবরণ সহ থাকে। সিস্টেম যখন কোনও ত্রুটি উত্থাপন করে, তখন সমস্যা সমাধানে সহায়তা করার জন্য বৈশিষ্ট্যের একটি সেট জনবহুল হয়। একটি ত্রুটি নিম্নলিখিত তথ্য অন্তর্ভুক্ত:

• কারণ
• ব্যবহারকারী-সংজ্ঞায়িত কাস্টম বৈশিষ্ট্য