Antipattern: استخدام سياسة صحيفةFault في ظروف غير ملائمة

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

تتيح سياسة RaiseFault لمطوّري واجهات برمجة التطبيقات بدء مسار الخطأ، وضبط متغيّرات الخطأ في رسالة نص استجابة، وضبط رموز حالة الاستجابة المناسبة. يمكنك أيضًا استخدام سياسة RaiseFault لضبط متغيّرات المسار المتعلّقة بالخطأ، مثل fault.name وfault.type و وfault.category. بما أنّ هذه المتغيّرات تظهر في بيانات "إحصاءات Google" وسجلاتّ وصول جهاز التوجيه المستخدَمة لتحديد الأخطاء وحلّها، من المهم تحديد الخطأ بدقة.

يمكنك استخدام سياسة 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 على أنّه fault.name في API Monitoring وعلى أنّه x_apigee_fault_policy في سجلاتّ وصول "إحصاءات Google" وجهاز التوجيه. يساعد ذلك في تشخيص سبب الخطأ بسهولة.

ممارسة غير مستحسنة

استخدام سياسة RaiseFault ضمن FaultRules بعد أن تكون سياسة أخرى قد أظهرت خطأً

لنأخذ المثال أدناه، حيث تعذّر تنفيذ سياسة OAuthV2 في مسار وكيل واجهة برمجة التطبيقات بسبب خطأ InvalidAccessToken. عند حدوث الخطأ، سيضبط Edge fault.name على InvalidAccessToken، وسيدخل مسار الخطأ، وسينفّذ أيّ FaultRules محدّدة. في FaultRule، هناك سياسة RaiseFault باسم RaiseFault ترسل استجابة خطأ مخصّصة كلّما حدث خطأ InvalidAccessToken. ومع ذلك، فإنّ استخدام سياسة RaiseFault في FaultRule يعني أنّه يتم استبدال المتغيّر 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>

استخدام سياسة RaiseFault في FaultRule في جميع الظروف

في المثال أدناه، يتم تنفيذ سياسة 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. يصعّب هذا السلوك تحديد السياسة التي تسبّبت فعليًا في حدوث الخطأ بدون الوصول إلى ملف تتبُّع يعرض الخطأ أو إعادة إنتاج المشكلة.

استخدام سياسة RaiseFault لعرض استجابة HTTP 2xx خارج مسار الخطأ

في المثال أدناه، يتم تنفيذ سياسة RaiseFault باسم HandleOptionsRequest عندما يكون فعل الطلب هو OPTIONS:

<!-- /antipatterns/examples/raise-fault-conditions-4.xml  -->
<PreFlow name="PreFlow">
    <Request>
        …
        <Step>
            <Name>HandleOptionsRequest</Name>
            <Condition>(request.verb Equals "OPTIONS")</Condition>
        </Step>
        …
</PreFlow>

الهدف هو عرض الاستجابة على عميل واجهة برمجة التطبيقات على الفور بدون معالجة السياسات الأخرى. ومع ذلك، سيؤدي ذلك إلى بيانات "إحصاءات Google" مضلّلة لأنّ متغيّرات الخطأ ستحتوي على اسم سياسة RaiseFault ، ما يجعل تحديد الأخطاء وحلّها في الوكيل أكثر صعوبة. الطريقة الصحيحة لتنفيذ السلوك المطلوب هي استخدام المسارات مع شروط خاصة، كما هو موضّح في مقالة إضافة دعم CORS.

التأثير

يؤدي استخدام سياسة RaiseFault كما هو موضّح أعلاه إلى استبدال متغيّرات الخطأ الرئيسية باسم سياسة RaiseFault بدلاً من اسم السياسة التي تعذّر تنفيذها. في سجلاتّ وصول "إحصاءات Google" وNGINX، يتم استبدال المتغيّرات x_apigee_fault_code وx_apigee_fault_policy . في API Monitoring، يتم استبدال Fault Code وFault Policy . يصعّب هذا السلوك تحديد المشاكل وحلّها و تحديد السياسة التي تسبّبت فعليًا في حدوث الخطأ.

في لقطة الشاشة أدناه من API Monitoring، يمكنك ملاحظة أنّه تم استبدال "رمز الخطأ" و"سياسة الخطأ" بقيم عامة RaiseFault ، ما يجعل من المستحيل تحديد السبب الجذري للخطأ من السجلاتّ:

أفضل الممارسات

عندما تظهر سياسة Edge خطأً وتريد تخصيص رسالة استجابة الخطأ، استخدِم سياسات AssignMessage أو JavaScript بدلاً من سياسة RaiseFault.

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

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

محتوى إضافي للقراءة

• التعامل مع الأخطاء
• سياسة RaiseFault
• مناقشة في المنتدى حول أنماط معالجة الأخطاء