নীতিগত ত্রুটি সম্পর্কে আপনার যা জানা দরকার

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

এই বিষয় নীতির ত্রুটির গঠন এবং নীতির ত্রুটি ঘটলে সেট করা ফ্লো ভেরিয়েবলের ধরনের বর্ণনা করে। আপনি যদি আপনার প্রক্সিগুলির জন্য ফল্ট হ্যান্ডলিং ডিজাইন এবং বাস্তবায়ন করেন তবে এই তথ্যটি অপরিহার্য।

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

ডিফল্ট নীতি ত্রুটি প্রতিক্রিয়া সম্পর্কে

যখন একটি নীতি একটি ত্রুটি নিক্ষেপ করে, এজ অবিলম্বে ত্রুটি প্রবাহে প্রবেশ করে এবং একটি ত্রুটি বার্তা তৈরি করে। এই সিস্টেম-উত্পাদিত বার্তাটি একটি JSON অবজেক্ট যাতে দুটি বিট তথ্য রয়েছে: একটি ত্রুটি কোড এবং একটি ফল্টস্ট্রিং ।

যেমন:

{  
   "fault":{  
      "detail":{  
         "errorcode":"steps.extractvariables.SourceMessageNotAvailable"
      },
      "faultstring":"foo message is not available for ExtractVariable: ParseJsonResponse"
   }
}

আসুন দ্রুত এই ত্রুটি বার্তাটি ডিকনস্ট্রাক্ট করি:

ত্রুটি কোড একটি উপসর্গ এবং একটি ত্রুটির নাম নিয়ে গঠিত, নিম্নরূপ: [prefix].[error_name] । উপরের উদাহরণে " steps.extractvariables " হল উপসর্গ এবং SourceMessageNotAvailable হল ত্রুটির নাম৷ উপসর্গটি আপনাকে বলে যে কোন ধরনের নীতি ত্রুটি তৈরি করেছে। উপরের উদাহরণে, আপনি বলতে পারেন যে একটি এক্সট্র্যাক্ট ভেরিয়েবল নীতি ত্রুটি তৈরি করেছে এবং ত্রুটিটির নাম SourceMessageNotAvailable ।

ফল্টস্ট্রিং-এ ত্রুটির বর্ণনা রয়েছে। ফল্ট স্ট্রিংয়ে সাধারণত নির্দিষ্ট সমস্যা খুঁজে পেতে সাহায্য করার জন্য ক্লু অন্তর্ভুক্ত থাকে যা ত্রুটির কারণ হয়, যেমন নীতির নাম, একটি অমীমাংসিত ভেরিয়েবলের নাম, বা যা কিছু ত্রুটিতে অবদান রাখে। উদাহরণস্বরূপ, উপরের ত্রুটি বার্তাটিতে, " foo " নীতিতে উল্লেখ করা একটি অমীমাংসিত বার্তা ভেরিয়েবলের নাম হতে পারে এবং " ParseJsonResponse " হল সেই নীতির নাম যা ত্রুটিটি ট্রিগার করেছে৷

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

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

fault.name পরিবর্তনশীল

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

এখানে একটি উদাহরণ ফল্ট নিয়ম যা fault.name এর মান পরীক্ষা করে:

<faultrule name="VariableOfNonMsgType"<>/faultrule><FaultRule name="Source Message Not Available Fault">
    <Step>
        <Name>AM-CustomErrorMessage</Name>
        <Condition>(fault.name Matches "SourceMessageNotAvailable") </Condition>
    </Step>
</FaultRule>

মনে রাখার বিষয় হল যে যখন একটি নীতি একটি ত্রুটি ট্রিগার করে, fault.name ভেরিয়েবলটি সর্বদা ত্রুটির নামে সেট করা হয়।

[prefix].[policy_name].failed ভেরিয়েবল

fault.name ছাড়াও, আরেকটি ভেরিয়েবল যা ডেভেলপাররা সাধারণত চেক করে তা হল [prefix].[policy_name].failed পতাকা, যেটি নীতি কার্যকর করার সময় সত্য বা মিথ্যাতে সেট করা হয়। ভুল নিয়মে, আপনি এটি কখন সত্য তা দেখতে পরীক্ষা করতে চাইবেন -- অর্থাৎ, একটি ত্রুটি ঘটেছে কিনা তা পরীক্ষা করতে৷ এখানে কিভাবে একটি শর্তসাপেক্ষ গঠন করা যায় যা [prefix].[policy_name].failed পতাকা পরীক্ষা করে। এই ভেরিয়েবলটি সঠিকভাবে চেক করতে, আপনাকে দুটি জিনিস জানতে হবে:

• আপনি যে নীতিটি পরীক্ষা করছেন তার নাম । এটি নীতির নামের বৈশিষ্ট্যের মান, প্রদর্শনের নাম নয়। এই বৈশিষ্ট্যটি সর্বদা নীতি সংজ্ঞার XML-এ অন্তর্ভুক্ত থাকে।
• একটি উপসর্গ যা আপনি যে ধরনের নীতি পরীক্ষা করছেন তার জন্য নির্দিষ্ট। (আমরা নীচের উপসর্গটি কীভাবে খুঁজে বের করব তা ব্যাখ্যা করব।)

ব্যাখ্যা করার জন্য, এখানে আরেকটি ফল্ট নিয়ম উদাহরণ। বাইরের অবস্থায় লক্ষ্য করুন কিভাবে [prefix].[policy_name].failed পরিবর্তনশীল নাম গঠিত হয়। এই ক্ষেত্রে প্রিফিক্স হল extractvariables এবং নীতির নাম ParseJsonResponse । এই ক্ষেত্রে, ফল্ট নিয়ম শুধুমাত্র কার্যকর হবে যদি এই পরিবর্তনশীলটি সত্য হয়। এবং, এখানে একটি টিপ: কারণ ফল্ট নিয়মে একাধিক ধাপ থাকতে পারে, এই প্যাটার্নটি ত্রুটির নিয়মগুলিকে ব্লকে সংগঠিত করার একটি চমৎকার উপায়।

<faultrule name="VariableOfNonMsgType"></faultrule><FaultRule name="Extract Variable Faults">
    <Step>
        <Name>AM-CustomErrorMessage</Name>
        <Condition>(fault.name Matches "SourceMessageNotAvailable") </Condition>
    </Step>
    <Condition>(extractvariables.ParseJsonResponse.failed = true) </Condition>
</FaultRule>

error এবং message ভেরিয়েবল সম্পর্কে

error ভেরিয়েবলটি শুধুমাত্র একটি প্রক্সির ত্রুটি প্রবাহে উপলব্ধ। আপনি ত্রুটি ভেরিয়েবল থেকে দরকারী তথ্য পেতে পারেন, যেমন ত্রুটি বার্তা, স্থিতি কোড, কারণ বাক্যাংশ, এবং তাই। ত্রুটি ভেরিয়েবলের বিন্যাস প্যাটার্ন হল:

error.[error_component] = [value]

যেমন:

error.message = "request message is not available for ExtractVariable: ParseJsonResponse

এবং

error.status.code = "500"

message ভেরিয়েবলটি ত্রুটির প্রবাহেও উপলব্ধ এবং error ভেরিয়েবলের মতো একই উদ্দেশ্যে ব্যবহার করা যেতে পারে। বার্তা পরিবর্তনশীল বিশেষ কারণ এটি প্রাসঙ্গিক। একটি অনুরোধ প্রবাহে, এটি একটি অনুরোধ ভেরিয়েবলের মতো আচরণ করে এবং একটি প্রতিক্রিয়া প্রবাহে, এটি প্রতিক্রিয়া মান পেতে/সেট করতে ব্যবহার করা যেতে পারে। আপনি যদি আরও জানতে চান, বার্তা ভেরিয়েবলের জন্য কেস ব্যবহার করুন দেখুন।

error এবং message সহ সমস্ত এজ ভেরিয়েবলের তথ্যের জন্য ভেরিয়েবল রেফারেন্স দেখুন।