নীতি সংক্রান্ত সমস্যার ব্যাপারে আপনার যা জানা প্রয়োজন

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

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

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

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

কোনও নীতিতে সমস্যা হলে, Edge সঙ্গে সঙ্গে সমস্যার ফ্লোতে প্রবেশ করে এবং একটি সমস্যার মেসেজ তৈরি করে। সিস্টেম-জেনারেটেড এই মেসেজটি হল একটি JSON অবজেক্ট যাতে দুটি তথ্য থাকে: একটি errorcode এবং একটি faultstring।

যেমন:

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

এই সমস্যার মেসেজটি দ্রুত বিশ্লেষণ করা যাক:

errorcode-এ একটি প্রিফিক্স ও একটি সমস্যার নাম থাকে, যেমন: [prefix].[error_name]। উপরের উদাহরণে "steps.extractvariables" হল প্রিফিক্স এবং SourceMessageNotAvailable হল সমস্যার নাম। প্রিফিক্স থেকে আপনি বুঝতে পারবেন যে কোন ধরনের নীতির কারণে সমস্যা হয়েছে। উপরের উদাহরণে, আপনি বুঝতে পারবেন যে Extract Variables নীতিটি সমস্যা তৈরি করেছে এবং সমস্যার নাম হল SourceMessageNotAvailable।

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

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

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

fault.name ভেরিয়েবল

কোনও নীতিতে সমস্যা হলে, সেটি ফ্লো ভেরিয়েবল fault.name-কে errorcode-এর error_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 ফ্ল্যাগ, যা কোনও নীতি কার্যকর হলে true বা false হিসেবে সেট করা হয়। ফল্ট নিয়মে, আপনি কখন সত্য -- হচ্ছে তা চেক করতে চাইবেন -- অর্থাৎ, কোনও সমস্যা হয়েছে কিনা তা চেক করতে। [prefix].[policy_name].failed ফ্ল্যাগ চেক করে এমন কন্ডিশনাল কীভাবে তৈরি করবেন তা এখানে দেওয়া হল। এই ভেরিয়েবল সঠিকভাবে চেক করতে, আপনাকে দুটি জিনিস জানতে হবে:

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

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

<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 সহ Edge ভেরিয়েবল সম্পর্কে তথ্য পান।