অ্যান্টিপ্যাটার্ন: অনুপযুক্ত পরিস্থিতিতে RaiseFault নীতি ব্যবহার করা

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

RaiseFault নীতি API ডেভেলপারদের একটি ত্রুটি ফ্লো শুরু করতে, রেসপন্স বডি মেসেজে ত্রুটি ভেরিয়েবল সেট করতে এবং উপযুক্ত রেসপন্স স্ট্যাটাস কোড সেট করতে দেয়। এছাড়াও, আপনি RaiseFault নীতি ব্যবহার করে, ফল্ট সম্পর্কিত ফ্লো ভেরিয়েবল সেট করতে পারেন, যেমন, fault.name, fault.type, এবং fault.category। যেহেতু এই ভেরিয়েবলগুলি অ্যানালিটিক্স ডেটা ও রাউটার অ্যাক্সেস লগে দেখা যায় এবং সেগুলি ডিবাগ করার জন্য ব্যবহার করা হয়, তাই সঠিকভাবে সমস্যা শনাক্ত করা গুরুত্বপূর্ণ।

আপনি RaiseFault নীতি ব্যবহার করে নির্দিষ্ট পরিস্থিতিকে সমস্যা হিসেবে বিবেচনা করতে পারেন, এমনকি অন্য কোনও নীতিতে বা API প্রক্সির ব্যাকএন্ড সার্ভারে কোনও প্রকৃত সমস্যা না হয়ে থাকলেও এটি করতে পারেন। যেমন, আপনি যদি চান যে ব্যাকএন্ডের উত্তর বডিতে unavailable স্ট্রিং থাকলে, প্রক্সি যেন ক্লায়েন্ট অ্যাপকে কাস্টম সমস্যার মেসেজ পাঠায়, তাহলে আপনি নিচে দেখানো কোড স্নিপেটের মতো RaiseFault নীতি প্রয়োগ করতে পারেন: 

<!-- /antipatterns/examples/raise-fault-conditions-1.xml  -->
<TargetEndpoint name="default">
...
  <Response>
    <Step>
      <Name>RF-Service-Unavailable</Name>
      <Condition>(message.content Like "*unavailable*")</Condition>
   </Step>
  </Response>
...

RaiseFault নীতির নাম API মনিটরিং-এ fault.name হিসেবে এবং Analytics ও রাউটার অ্যাক্সেস লগে x_apigee_fault_policy হিসেবে দেখা যায়। এর ফলে সমস্যার কারণ সহজেই বোঝা যায়।

অ্যান্টিপ্যাটার্ন

আগে থেকেই অন্য কোনও নীতি কোনও সমস্যা তৈরি করার পরে FaultRules-এর মধ্যে RaiseFault নীতি ব্যবহার করা

নিচের উদাহরণটি দেখুন, যেখানে API প্রক্সি ফ্লোতে OAuthV2 নীতি InvalidAccessToken সমস্যা সহ ব্যর্থ হয়েছে। কাজ না হলে, Edge fault.name-কে InvalidAccessToken হিসেবে সেট করবে, সমস্যার ফ্লোতে প্রবেশ করবে এবং কোনও সংজ্ঞায়িত FaultRules এক্সিকিউট করবে। FaultRule-এ, RaiseFault নীতি আছে যার নাম হল RaiseFault। InvalidAccessToken সমস্যা হলে এটি কাস্টমাইজ করা সমস্যার উত্তর পাঠায়। তবে, FaultRule-এ RaiseFault নীতি ব্যবহার করার অর্থ হল, fault.name ভেরিয়েবল ওভাররাইট করা হয় এবং ব্যর্থতার আসল কারণটি আড়াল করে দেওয়া হয়। 

<!-- /antipatterns/examples/raise-fault-conditions-2.xml  -->
<FaultRules>
  <FaultRule name="generic_raisefault">
    <Step>
        <Name>RaiseFault</Name>
        <Condition>(fault.name equals "invalid_access_token") or (fault.name equals "InvalidAccessToken")</Condition>
    </Step>
  </FaultRule>
</FaultRules>

সব পরিস্থিতিতে FaultRule-এর অধীনে RaiseFault নীতি ব্যবহার করা

নিচের উদাহরণে, RaiseFault নামের একটি RaiseFault নীতি fault.name RaiseFault না হলে এক্সিকিউট হয়: 

<!-- /antipatterns/examples/raise-fault-conditions-3.xml  -->
<FaultRules>
    <FaultRule name="fault_rule">
        ....
        <Step>
            <Name>RaiseFault</Name>
            <Condition>!(fault.name equals "RaiseFault")</Condition>
        </Step>
    </FaultRule>
</FaultRules>

প্রথম পরিস্থিতির মতো, RaiseFault নীতির নাম দিয়ে মূল ফল্ট ভেরিয়েবল fault.name, fault.code, ও fault.policy ওভাররাইট করা হয়। এই আচরণের ফলে, নীতি লঙ্ঘনের কারণ নির্ধারণ করা প্রায় অসম্ভব হয়ে পড়ে, যদি না ব্যর্থতা দেখানো কোনও ট্রেস ফাইল অ্যাক্সেস করা হয় অথবা সমস্যাটি আবার তৈরি করা হয়।

ভুল ফ্লোয়ের বাইরে HTTP 2xx উত্তর রিটার্ন করতে RaiseFault নীতি ব্যবহার করা।

নিচের উদাহরণে, HandleOptionsRequest নামের একটি RaiseFault নীতি এক্সিকিউট হয় যখন অনুরোধের ক্রিয়া OPTIONS হয়: 

<!-- /antipatterns/examples/raise-fault-conditions-4.xml  -->
<PreFlow name="PreFlow">
    <Request>
        …
        <Step>
            <Name>HandleOptionsRequest</Name>
            <Condition>(request.verb Equals "OPTIONS")</Condition>
        </Step>
        …
</PreFlow>

অন্যান্য নীতি প্রসেস না করেই API ক্লায়েন্টকে অবিলম্বে উত্তর ফেরত দেওয়াই হল উদ্দেশ্য। তবে, এর ফলে বিভ্রান্তিকর অ্যানালিটিক্স ডেটা তৈরি হবে কারণ ফল্ট ভেরিয়েবলে RaiseFault নীতির নাম থাকবে, যার ফলে প্রক্সি ডিবাগ করা আরও কঠিন হয়ে যাবে। কাঙ্ক্ষিত আচরণ প্রয়োগ করার সঠিক উপায় হল বিশেষ শর্ত সহ ফ্লো ব্যবহার করা, যা CORS সহায়তা যোগ করা নিবন্ধে বর্ণনা করা হয়েছে।

প্রভাব

উপরে বর্ণিত RaiseFault নীতি ব্যবহার করলে, ব্যর্থ হওয়া নীতির নামের পরিবর্তে RaiseFault নীতির নাম দিয়ে মূল ফল্ট ভেরিয়েবল ওভাররাইট করা হয়। Analytics এবং NGINX অ্যাক্সেস লগে, x_apigee_fault_code এবং x_apigee_fault_policy ভেরিয়েবল ওভাররাইট করা হয়। API মনিটরিং-এ, Fault Code ও Fault Policy ওভাররাইট করা হয়। এই ধরনের আচরণ সমস্যার সমাধান করা এবং কোন নীতি লঙ্ঘনের কারণে সমস্যা হয়েছে তা নির্ধারণ করা কঠিন করে তোলে।

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

পেশাদার পদ্ধতি

Edge নীতি কোনও সমস্যা তৈরি করলে এবং আপনি সমস্যার উত্তর মেসেজ কাস্টমাইজ করতে চাইলে, RaiseFault নীতির পরিবর্তে AssignMessage বা JavaScript নীতি ব্যবহার করুন।

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

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

আরও পড়ুন