ما تحتاج إلى معرفته عن أخطاء السياسة

أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلىمستندات Apigee X. info

يوضّح هذا الموضوع بنية أخطاء السياسات وأنواع متغيّرات التدفق التي يتم ضبطها عند حدوث خطأ في السياسة. هذه المعلومات ضرورية إذا كنت تصمّم وتنفّذ عملية معالجة الأخطاء في الخوادم الوكيلة.

يفترض هذا الموضوع أنّ لديك فهمًا عامًا لكيفية عمل عملية معالجة الأخطاء في Edge، و أنّك على دراية بقواعد الأخطاء. إذا كنت بحاجة إلى مراجعة، يُرجى الاطّلاع على مقالة معالجة الأخطاء. ستساعدك المعلومات الواردة هنا أيضًا في التنقّل واستخدام مرجع أخطاء السياسات.

لمحة عن الردّ التلقائي على أخطاء السياسات

عندما تعرض سياسة خطأً، ينتقل Edge على الفور إلى تدفق الأخطاء ويُنشئ رسالة خطأ. هذه الرسالة التي ينشئها النظام هي كائن 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" هو اسم السياسة التي أدت إلى حدوث الخطأ.

المتغيّرات الخاصة بأخطاء السياسات

عندما يتم تفعيل خطأ في السياسة، تتم تعبئة متغيّرات تدفق معيّنة خاصة بالخطأ. هذه المتغيّرات مفيدة للغاية في معالجة الأخطاء. كما هو موضّح في موضوع معالجة الأخطاء، من الشائع اعتراض أخطاء السياسات التي ينشئها النظام وتنفيذ إجراء لاحق، مثل إنشاء ردّ مخصّص على الخطأ. على سبيل المثال، لأسباب أمنية، قد تريد منع العملاء من الاطّلاع على الأخطاء الفعلية ورموز الحالة التي يعرضها Edge.

المتغيّر fault.name

عندما تعرض سياسة خطأً، تضبط المتغيّر fault.name على الـ 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، التي يتم ضبطها على "صحيح" أو "خطأ" عند تنفيذ سياسة. في قواعد الأخطاء، عليك التحقّق من وقت ضبطها على صحيح -- أي للتحقّق مما إذا حدث خطأ. في ما يلي كيفية إنشاء شرط يتحقّق من العلامة [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 variables

لا يتوفّر المتغيّر error إلا في تدفق الأخطاء في خادم وكيل. يمكنك الحصول على معلومات مفيدة من متغيّر الخطأ، مثل رسالة الخطأ ورمز الحالة وعبارة السبب وما إلى ذلك. نمط التنسيق لمتغيّر الخطأ هو:

error.[error_component] = [value]

على سبيل المثال:

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

و

error.status.code = "500"

يتوفّر المتغيّر message أيضًا في تدفق الأخطاء ويمكن استخدامه لأغراض مشابهة للمتغيّر error. متغيّر الرسالة خاص لأنّه سياقي. في تدفق الطلب، يتصرف كمتغيّر طلب، وفي تدفق الاستجابة، يمكن استخدامه للحصول على قيم الاستجابة أو ضبطها. إذا أردت معرفة المزيد، يُرجى الاطّلاع على حالات استخدام متغيّرات الرسائل.

يُرجى الرجوع إلى مرجع المتغيّرات للحصول على معلومات عن جميع متغيّرات Edge، بما في ذلك error و message.