সমস্যা ম্যানেজ করা

আপনি 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 Key যাচাই করা
2. কোটা
3. JSON থেকে XML

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

FaultRules চেক করা

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

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

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

সহজ ফল্ট হ্যান্ডলিংয়ের উদাহরণ

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

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

এর ফলে, আপনি API প্রক্সিতে কোনও ফ্লোয়ের সাথে নীতি অ্যাটাচ না করেই সেটি তৈরি করতে পারবেন। কোনও ফ্লোতে অ্যাটাচ করা নেই এমন নীতি নীতি তালিকায় "ডিটাচ করা" আইকন দিয়ে ফ্ল্যাগ করা হয়, যেমন আগের ছবিতে দেখানো API কী মেসেজ নীতির পাশে দেখানো হয়েছে।

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

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

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

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

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

একাধিক FaultRules ও এক্সিকিউশন লজিক

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

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

FaultRules এক্সিকিউশন

সংক্ষেপে, API প্রক্সি সমস্যার অবস্থায় চলে গেলে Edge এই যুক্তি ব্যবহার করে। মনে রাখবেন যে ProxyEndpoint-এ FaultRules মূল্যায়ন এবং 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-এর মধ্যে থাকা সব Step, XML কনফিগারেশনে উপর থেকে নিচে, ক্রম অনুযায়ী মূল্যায়ন করা হয়। কন্ডিশন ছাড়া ধাপগুলি অটোমেটিক এক্সিকিউট হয় (নীতি এক্সিকিউট হয়) এবং যে ধাপের <Condition> "সত্য" হিসেবে মূল্যায়ন করা হয় সেগুলি এক্সিকিউট হয় (যে কন্ডিশন "মিথ্যা" হিসেবে মূল্যায়ন করা হয় সেগুলি এক্সিকিউট হয় না)।

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

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

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

ProxyEndpoint এক্সিকিউশন

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 এক্সিকিউশন

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-এর ক্রম গুরুত্বপূর্ণ, এটি নির্ভর করে ProxyEndpoint-এ নাকি TargetEndpoint-এ সমস্যা হয়েছে তার উপর।

যেমন:

যেসব নীতি অন্তর্ভুক্ত করতে হবে

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

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

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

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

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

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

FaultRules কোথায় নির্ধারণ করতে হবে: ProxyEndpoint বা TargetEndpoint

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

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

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

FaultRules বনাম RaiseFault নীতি

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

সংক্ষেপে:

• API প্রক্সি কোনও এরর স্টেটে প্রবেশ করলে ফল্ট রুল সবসময় মূল্যায়ন করা হয়।

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

  যেমন, টার্গেট সার্ভিস থেকে পাওয়া রেসপন্সের HTTP স্ট্যাটাস কোড ২০০-এর বেশি হলে আপনি যদি কোনও সমস্যা দেখাতে চান, তাহলে আপনার রেসপন্স ফ্লোতে 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 নীতি কোনও সমস্যা ট্রিগার করলে কী হয়, যার ফলে প্রক্সিটি error স্টেটে চলে যায়, যা সম্ভাব্যভাবে 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 এক্সিকিউশনের জন্য শর্তাবলী অত্যন্ত গুরুত্বপূর্ণ। আপনি FaultRule কন্ডিশন ঠিক সেইভাবেই তৈরি করেন যেভাবে Edge-এ অন্যান্য কন্ডিশন তৈরি করেন, যেমন কনডিশনাল ফ্লো বা RaiseFault কন্ডিশন।

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

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

নীতি সংক্রান্ত সমস্যার জন্য নির্দিষ্ট ভেরিয়েবল

নীতিতে কোনও সমস্যা হলে fault.name ও {policy_namespace}.{policy_name}.failed ভেরিয়েবল উপলভ্য থাকে।

fault.name

কোনও নীতি কাজ না করলে, fault.name ভেরিয়েবল ব্যবহার করে কন্ডিশনে সমস্যাটি শনাক্ত করুন। যেমন:

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

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

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

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

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

নীতি সংক্রান্ত সমস্যার তালিকা পেতে নীতি সংক্রান্ত সমস্যা রেফারেন্স দেখুন।

{policy_namespace}.{policy_name}.failed

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

• RaiseFault নীতি: raisefault.failed (সব RaiseFault নীতির ক্ষেত্রে একই)
• VerifyAPIKey নীতি: oauthV2.{policy_name}.failed, যেমন oauthV2.Verify-API-Key-1.failed
• কোটা সংক্রান্ত নীতি ও SpikeArrest নীতি: 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> (sibling to the <Step> এলিমেন্ট) প্রদান করুন। কোনও আউটার কন্ডিশন না থাকা ফল্ট নিয়ম অটোমেটিক সত্য হিসেবে মূল্যায়ন করে। FaultRule সত্য না মিথ্যা তা নির্ধারণ করতে "Inner" Step কন্ডিশন ব্যবহার করা হয় না। Edge, FaultRule এক্সিকিউট করার পরেই ধাপের কন্ডিশন মূল্যায়ন করা হয়। FaultRule-এ, Assign Message (বা অন্য) নীতি সহ একাধিক Step থাকাটা স্বাভাবিক, প্রতিটি Step-এর একটি করে কন্ডিশন থাকে।

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

  তারপর, আরও সূক্ষ্মভাবে সমস্যা নিয়ন্ত্রণ করার প্রয়োজন হলে, ভেতরের ধাপের কন্ডিশন ব্যবহার করুন। যেমন, আপনার অনুরোধ ফ্লোতে দুটি নীতির মাধ্যমে আপনি যদি ব্যক্তিগত ডেভেলপার কোটা ও গ্লোবাল কোটা, দুটিই প্রয়োগ করেন, তাহলে আপনার "আউটার" FaultRule কন্ডিশন সেট করুন যাতে QuotaViolation error (কোটা অতিক্রম করলে এই error দেখানো হয়) ট্রিগার করা যায়। তারপরে আপনার কোটা নীতিতে 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 (প্রতিটি ধরনের সমস্যার জন্য একটি করে) ব্যবহার না করে একটি 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> এক্সিকিউশন:
  • অন্য কোনও FaultRule এক্সিকিউট না হলে A <DefaultFaultRule> অটোমেটিক এক্সিকিউট হয়। <DefaultFaultRule>-এ কোনও নিয়ম-লেভেল <Condition> চাইল্ড এলিমেন্ট যোগ করবেন না। কোনও <DefaultFaultRule>-এর মধ্যে শর্তসাপেক্ষে কোনও নীতি প্রয়োগ করতে, সেটির চাইল্ড <Step> এলিমেন্টে <Condition> প্লেস করুন।
  • আপনি যদি চান যে অন্য কোনও FaultRule এক্সিকিউট হয়ে গেলেও <DefaultFaultRule> সবসময় এক্সিকিউট হোক, তাহলে <AlwaysEnforce>true</AlwaysEnforce> চাইল্ড এলিমেন্ট যোগ করুন।

কেন্দ্রীয়ভাবে, আবার ব্যবহারযোগ্য সমস্যা সমাধানের প্যাটার্ন

নিচের Apigee কমিউনিটি পোস্টে কোড ডুপ্লিকেশন ছাড়াই সেন্ট্রালাইজড ফল্ট হ্যান্ডলিংয়ের একটি প্যাটার্ন বর্ণনা করা হয়েছে:

Apigee প্রক্সির জন্য সমস্যা ম্যানেজ করার প্যাটার্ন

FaultRules তৈরি করা হচ্ছে

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 নীতির উদাহরণে <Payload>, <StatusCode> ও <ReasonPhase> ট্যাগ ব্যবহার করে কাস্টম ভুল উত্তরকে সংজ্ঞায়িত করা হয়েছে। ভুল API কী সংক্রান্ত সমস্যার ক্ষেত্রে এই উত্তর ক্লায়েন্টকে পাঠানো হয় (আগের 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> ট্যাগ যোগ করে ডিফল্ট ফল্ট হ্যান্ডেলিং চালু করুন।

যেমন, নিচের 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>

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

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

DefaultFaultRule-এর একটি ব্যবহার হল, আপনি অন্যভাবে নির্ধারণ করতে না পারলে, সেটি থেকে হওয়া সমস্যার ধরন নির্ধারণ করা। যেমন, আপনার API প্রক্সি কোনও সমস্যার কারণে কাজ করছে না যা আপনি নির্ধারণ করতে পারছেন না। নিম্নলিখিত AssignMessage নীতি প্রয়োগ করতে DefaultFaultRule ব্যবহার করুন। এই নীতিটি উত্তরে DefaultFaultHeader নামের একটি হেডারে fault.name ভ্যালু লেখে:

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

এরপরে, Edge ট্রেস টুলে বা উত্তরের মধ্যে হেডারটি দেখে নিতে পারেন, যাতে কী কারণে সমস্যা হয়েছে তা বুঝতে পারেন।

PostClientFlow-তে মেসেজ লগিং যোগ করা

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

বর্তমান ফ্লোয়ের মধ্যে নীতি সংক্রান্ত ত্রুটি সমাধান করা

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

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

নিচে verify-api-key নামের একটি VerifyAPIKey নীতি দেখানো হয়েছে, যার continueOnError এলিমেন্ট true: হিসেবে সেট করা আছে

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

API কী না থাকলে বা সেটি ভুল হলে, VerifyAPIKey নীতি oauthV2.verify-api-key.failed ভেরিয়েবলকে true হিসেবে সেট করে, কিন্তু প্রসেসিং বর্তমান ফ্লোতে চলতে থাকে।

তারপরে, আপনি ProxyEndpoint-এর PreFlow-তে একটি ধাপ হিসেবে VerifyAPIKey নীতি যোগ করুন:

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

PreFlow-এর পরবর্তী ধাপে কীভাবে একটি কন্ডিশন ব্যবহার করে সমস্যা আছে কিনা তা পরীক্ষা করা হচ্ছে তা লক্ষ্য করুন। VerifAPIKey নীতিতে কোনও সমস্যা হলে, FaultInFlow নামের নীতি কার্যকর হয়। অন্যথায়, FaultInFlow নীতি এড়িয়ে যাওয়া হয়। FaultInFlow নীতি অনেক কিছু করতে পারে, যেমন, সমস্যা লগ করা, সমস্যার সমাধান করার চেষ্টা করা অথবা অন্য কোনও অ্যাকশন নেওয়া।

RaiseFault নীতি ব্যবহার করে কোনও সমস্যা ট্রিগার করা

কোনও ফ্লোতে যেকোনও সময় সমস্যা ট্রিগার করতে আপনি RaiseFault নীতি ব্যবহার করতে পারেন। RaiseFault নীতি এক্সিকিউট করা হলে, এটি বর্তমান ফ্লো বন্ধ করে দেয় এবং কন্ট্রোলকে সমস্যার স্টেটে ট্রান্সফার করে দেয়।

RaiseFault নীতির একটি ব্যবহার হল, কোনও নির্দিষ্ট কন্ডিশন পরীক্ষা করা যা অন্য কোনও নীতি শনাক্ত করতে নাও পারে। উপরের উদাহরণে, আপনি <Condition> ট্যাগটি একটি PreFlow <Step> ট্যাগে যোগ করেছেন যার ফলে শর্ত পূরণ হলে FaultInFlow নীতিটি এক্সিকিউট হবে। FaultInFlow যদি RaiseFault নীতি হয়, তাহলে কন্ট্রোল এরর স্টেটে ট্রান্সফার হয়। অথবা, আপনি কোনও ফ্লোতে RaiseFault নীতি যোগ করতে পারেন যাতে আপনার FaultRules ডিবাগ ও পরীক্ষা করা যায়।

RaiseFault নীতি কোনও সমস্যার ট্রিগার করলে, সেটি প্রসেস করার জন্য আপনি নিম্নলিখিত FaultRule ও কন্ডিশন ব্যবহার করতে পারবেন:

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

মনে রাখবেন, RaiseFault নামের একটি সমস্যার জন্য শর্ত পরীক্ষা করা হয়। RaiseFault নীতি সবসময় fault.name-এর ভ্যালু RaiseFault হিসেবে সেট করে।

টার্গেট সার্ভার থেকে পাওয়া HTTP সমস্যার কোড কাস্টমভাবে ম্যানেজ করা

আগের বিভাগে দেখানো উদাহরণগুলি নীতি সংক্রান্ত সমস্যার কারণে হওয়া ভুলের ক্ষেত্রে প্রযোজ্য। তবে, আপনি ট্রান্সপোর্ট লেভেল সমস্যার জন্য কাস্টম উত্তরও তৈরি করতে পারেন, অর্থাৎ টার্গেট সার্ভার থেকে ফেরত আসা HTTP সমস্যা। HTTP থেকে পাওয়া উত্তর নিয়ন্ত্রণ করতে, HTTP রেসপন্স কোড প্রসেস করার জন্য TargetEndpoint কনফিগার করুন।

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

আপনি যেকোনও HTTP রেসপন্স কোডের জন্য কাস্টম হ্যান্ডলার তৈরি করতে পারবেন। যেমন, আপনি হয়তো 4xx-5xx রেঞ্জের সব HTTP রেসপন্স কোডকে 'ব্যর্থ' হিসেবে বিবেচনা করতে চান না, শুধু 5xx-কে চান অথবা আপনি হয়তো 400 ও 500 HTTP রেসপন্স কোডের জন্য কাস্টম মেসেজ দেখাতে চান।

পরবর্তী উদাহরণে, আপনি success.codes প্রপার্টি ব্যবহার করে TargetEndpoint কনফিগার করেছেন যাতে ডিফল্ট HTTP কোডের পাশাপাশি HTTP রেসপন্স কোড 400 ও 500-কে সফল হিসেবে বিবেচনা করা হয়। সেইসব কোডকে সফল হিসেবে বিবেচনা করে, TargetEndpoint, সমস্যার স্টেট ইনভোক করার পরিবর্তে, উত্তর মেসেজ প্রসেস করার দায়িত্ব নেয়:

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

এই উদাহরণে যেমন দেখতে পাচ্ছেন, আপনি success.codes প্রপার্টিতে ভ্যালুর একটি রেঞ্জ সেট করতে ওয়াইল্ডকার্ড ব্যবহার করতে পারেন।

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

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

কিন্তু, আপনি যদি চান যে শুধু HTTP কোড 400-কে সাফল্যের কোড হিসেবে বিবেচনা করা হোক, তাহলে প্রপার্টি এভাবে সেট করুন:

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

অনুরোধকারী অ্যাপকে কাস্টমাইজ করা উত্তর মেসেজ ফেরত দিতে, আপনি এখন HTTP রেসপন্স কোড 400 ও 500-এর জন্য কাস্টম হ্যান্ডলার নির্ধারণ করতে পারবেন। নিম্নলিখিত TargetEndpoint 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>

এই TargetEndpoint কনফিগারেশন, ReturnError নামের নীতিকে রেসপন্স ম্যানেজ করতে বলে যখনই TargetEndpoint, 400 বা 500 HTTP রেসপন্স কোড পায়।

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

API পরিষেবা নিম্নলিখিত বিভাগ ও উপবিভাগে সমস্যাগুলিকে সাজায়।

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

• কারণ
• ব্যবহারকারীর সংজ্ঞায়িত কাস্টম অ্যাট্রিবিউট