আপনি 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 ত্রুটির সাথে ব্যর্থ হয়েছে৷ ব্যর্থ হলে, এজ fault.name InvalidAccessToken হিসাবে সেট করবে, ত্রুটির প্রবাহে প্রবেশ করবে এবং যেকোন সংজ্ঞায়িত ফল্ট রুলস কার্যকর করবে। 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>
প্রথম দৃশ্যের মতো, কী ফল্ট ভেরিয়েবল 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>
উদ্দেশ্য হল অন্য নীতিগুলি প্রক্রিয়া না করে অবিলম্বে API ক্লায়েন্টের কাছে প্রতিক্রিয়া ফেরত দেওয়া৷ যাইহোক, এটি বিভ্রান্তিকর বিশ্লেষণ ডেটার দিকে নিয়ে যাবে কারণ ফল্ট ভেরিয়েবলে RaiseFault নীতির নাম থাকবে, প্রক্সিটিকে ডিবাগ করা আরও কঠিন করে তুলবে৷ পছন্দসই আচরণ বাস্তবায়নের সঠিক উপায় হল বিশেষ শর্তগুলির সাথে ফ্লো ব্যবহার করা, যেমনটি CORS সমর্থন যোগ করাতে বর্ণিত হয়েছে।
প্রভাব
উপরে বর্ণিত RaiseFault নীতির ব্যবহার ব্যর্থ নীতির নামের পরিবর্তে RaiseFault নীতির নামের সাথে কী ফল্ট ভেরিয়েবল ওভাররাইট করে। Analytics এবং NGINX অ্যাক্সেস লগগুলিতে, x_apigee_fault_code এবং x_apigee_fault_policy ভেরিয়েবল ওভাররাইট করা হয়. API মনিটরিং- এ, Fault Code এবং Fault Policy ওভাররাইট করা হয়। এই আচরণটি সমস্যা সমাধান করা এবং কোন নীতি ব্যর্থতার প্রকৃত কারণ তা নির্ধারণ করা কঠিন করে তোলে।
API মনিটরিং থেকে নীচের স্ক্রিনশটে, আপনি দেখতে পাচ্ছেন যে ফল্ট কোড এবং ফল্ট নীতি সাধারণ RaiseFault মানগুলিতে ওভাররাইট করা হয়েছে, ফলে লগগুলি থেকে ব্যর্থতার মূল কারণ নির্ধারণ করা অসম্ভব:
ভাল অভ্যাস
যখন একটি এজ নীতি একটি ত্রুটি উত্থাপন করে এবং আপনি ত্রুটি প্রতিক্রিয়া বার্তাটি কাস্টমাইজ করতে চান, তখন RaiseFault নীতির পরিবর্তে AssignMessage বা JavaScript নীতিগুলি ব্যবহার করুন৷
RaiseFault নীতি একটি ত্রুটিহীন প্রবাহে ব্যবহার করা উচিত। অর্থাৎ, শুধুমাত্র RaiseFault ব্যবহার করে একটি নির্দিষ্ট অবস্থাকে একটি ত্রুটি হিসেবে বিবেচনা করুন, এমনকি যদি কোনো প্রকৃত ত্রুটি কোনো নীতিতে বা API প্রক্সির ব্যাকএন্ড সার্ভারে না ঘটে থাকে। উদাহরণস্বরূপ, আপনি বাধ্যতামূলক ইনপুট পরামিতি অনুপস্থিত বা ভুল সিনট্যাক্স আছে তা সংকেত দিতে RaiseFault নীতি ব্যবহার করতে পারেন।
আপনি যদি একটি ফল্টের প্রক্রিয়াকরণের সময় একটি ত্রুটি সনাক্ত করতে চান তবে আপনি একটি ফল্ট নিয়মে RaiseFault ব্যবহার করতে পারেন। উদাহরণস্বরূপ, আপনার ফল্ট হ্যান্ডলার নিজেই একটি ত্রুটি সৃষ্টি করতে পারে যা আপনি RaiseFault ব্যবহার করে সংকেত দিতে চান।