আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন .info- তে যান।
দ্য RaiseFault পলিসি এপিআই ডেভেলপারদের একটি এরর ফ্লো শুরু করতে, রেসপন্স বডি মেসেজে এরর ভ্যারিয়েবল সেট করতে এবং উপযুক্ত রেসপন্স স্ট্যাটাস কোড সেট করতে দেয়। এছাড়াও আপনি ফল্ট সম্পর্কিত ফ্লো ভ্যারিয়েবল, যেমন fault.name , fault.type , এবং fault.category সেট করার জন্য RaiseFault পলিসি ব্যবহার করতে পারেন। যেহেতু এই ভ্যারিয়েবলগুলো অ্যানালিটিক্স ডেটা এবং ডিবাগিংয়ের জন্য ব্যবহৃত রাউটার অ্যাক্সেস লগে দেখা যায়, তাই ফল্টটি সঠিকভাবে শনাক্ত করা গুরুত্বপূর্ণ।
আপনি RaiseFault পলিসি ব্যবহার করে নির্দিষ্ট পরিস্থিতিকে ত্রুটি হিসেবে গণ্য করতে পারেন, এমনকি যদি অন্য কোনো পলিসিতে বা এপিআই প্রক্সির ব্যাকএন্ড সার্ভারে কোনো প্রকৃত ত্রুটি না ঘটে থাকে। উদাহরণস্বরূপ, যদি আপনি চান যে যখনই ব্যাকএন্ড রেসপন্স বডিতে 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 হিসেবে এবং অ্যানালিটিক্স ও রাউটার অ্যাক্সেস লগ-এ x_apigee_fault_policy হিসেবে দেখা যায়। এটি ত্রুটির কারণ সহজে নির্ণয় করতে সাহায্য করে।
অ্যান্টিপ্যাটার্ন
অন্য কোনো পলিসি ইতিমধ্যে ত্রুটি দেখানোর পর FaultRules-এর মধ্যে RaiseFault পলিসি ব্যবহার করা।
নিচের উদাহরণটি বিবেচনা করুন, যেখানে এপিআই প্রক্সি ফ্লো-তে একটি OAuthV2 পলিসি InvalidAccessToken ত্রুটির কারণে ব্যর্থ হয়েছে। ব্যর্থ হলে, Edge ` fault.name কে InvalidAccessToken হিসেবে সেট করবে, এরর ফ্লো-তে প্রবেশ করবে এবং সংজ্ঞায়িত যেকোনো `FaultRule` কার্যকর করবে। `FaultRule`-টির মধ্যে 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>
সকল পরিস্থিতিতে একটি FaultRul-এ 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>
প্রথম পরিস্থিতির মতোই, fault.name , fault.code , এবং fault.policy এই মূল ফল্ট ভ্যারিয়েবলগুলো RaiseFault পলিসির নাম দিয়ে ওভাররাইট হয়ে যায়। এই আচরণের ফলে, ব্যর্থতা দেখানো কোনো ট্রেস ফাইল অ্যাক্সেস করা বা সমস্যাটি পুনরায় তৈরি করা ছাড়া, কোন পলিসিটি আসলে ব্যর্থতার কারণ তা নির্ধারণ করা প্রায় অসম্ভব হয়ে পড়ে।
এরর ফ্লো-এর বাইরে 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>
এর উদ্দেশ্য হলো অন্য কোনো পলিসি প্রসেস না করেই এপিআই ক্লায়েন্টের কাছে তাৎক্ষণিকভাবে প্রতিক্রিয়া ফেরত পাঠানো। তবে, এর ফলে বিভ্রান্তিকর অ্যানালিটিক্স ডেটা পাওয়া যাবে, কারণ ফল্ট ভেরিয়েবলগুলোতে RaiseFault পলিসির নামটি থাকবে, যা প্রক্সি ডিবাগ করাকে আরও কঠিন করে তুলবে। কাঙ্ক্ষিত আচরণটি বাস্তবায়নের সঠিক উপায় হলো বিশেষ শর্তসহ ফ্লো (Flows) ব্যবহার করা, যেমনটি "CORS সাপোর্ট যোগ করা" অংশে বর্ণনা করা হয়েছে।
প্রভাব
উপরে বর্ণিত পদ্ধতিতে RaiseFault পলিসি ব্যবহার করলে, ব্যর্থ হওয়া পলিসির নামের পরিবর্তে RaiseFault পলিসির নাম দিয়ে মূল ফল্ট ভেরিয়েবলগুলো ওভাররাইট হয়ে যায়। অ্যানালিটিক্স এবং NGINX অ্যাক্সেস লগে, x_apigee_fault_code এবং x_apigee_fault_policy ভেরিয়েবলগুলো দেখা যায়। x_apigee_fault_policy ভেরিয়েবলগুলো ওভাররাইট হয়ে যায়। এপিআই মনিটরিং- এ, Fault Code এবং Fault Policy ওভাররাইট হয়ে যায়। এই আচরণের কারণে সমস্যা সমাধান করা এবং কোন পলিসিটি ব্যর্থতার আসল কারণ তা নির্ধারণ করা কঠিন হয়ে পড়ে।
এপিআই মনিটরিং থেকে নেওয়া নিচের স্ক্রিনশটে আপনি দেখতে পাচ্ছেন যে, ফল্ট কোড এবং ফল্ট পলিসিকে জেনেরিক RaiseFault ভ্যালু দিয়ে ওভাররাইট করা হয়েছে, যার ফলে লগ থেকে ব্যর্থতার মূল কারণ নির্ণয় করা অসম্ভব হয়ে পড়েছে:
সর্বোত্তম অনুশীলন
যখন কোনো Edge পলিসি একটি ফল্ট তৈরি করে এবং আপনি এরর রেসপন্স মেসেজটি কাস্টমাইজ করতে চান, তখন RaiseFault পলিসির পরিবর্তে AssignMessage বা JavaScript পলিসি ব্যবহার করুন।
RaiseFault পলিসিটি একটি ত্রুটিহীন ফ্লো-তে ব্যবহার করা উচিত। অর্থাৎ, পলিসিতে বা এপিআই প্রক্সির ব্যাকএন্ড সার্ভারে কোনো প্রকৃত ত্রুটি না ঘটলেও, শুধুমাত্র একটি নির্দিষ্ট পরিস্থিতিকে ত্রুটি হিসেবে গণ্য করার জন্য RaiseFault ব্যবহার করুন। উদাহরণস্বরূপ, বাধ্যতামূলক ইনপুট প্যারামিটার অনুপস্থিত বা সেগুলোর সিনট্যাক্স ভুল—এই সংকেত দিতে আপনি RaiseFault পলিসিটি ব্যবহার করতে পারেন।
কোনো ফল্ট প্রক্রিয়াকরণের সময় ত্রুটি শনাক্ত করতে চাইলে, আপনি ফল্ট রুলে RaiseFault ব্যবহার করতে পারেন। উদাহরণস্বরূপ, আপনার ফল্ট হ্যান্ডলার নিজেই এমন একটি ত্রুটি ঘটাতে পারে, যা আপনি RaiseFault ব্যবহার করে সংকেত দিতে চান।