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

يتم الآن عرض مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. المعلومات

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

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

<!-- /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>
...

يظهر اسم سياسة riseFault ضمن fault.name في مراقبة واجهة برمجة التطبيقات وبالاسم x_apigee_fault_policy في سجلات وصول "إحصاءات Google" وجهاز التوجيه. ويساعد ذلك في تشخيص سبب الخطأ بسهولة.

مضادة للأنماط

استخدام سياسة GrowFault ضمن FaultRules بعد حدوث خطأ في سياسة أخرى

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

استخدام سياسة riseFault في FaultRule في جميع الشروط

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

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

في المثال أدناه، يتم تنفيذ سياسة DrawFault المسماة 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>

والغرض من ذلك هو عرض الرد على عميل واجهة برمجة التطبيقات على الفور بدون معالجة سياسات أخرى. ومع ذلك، سيؤدي ذلك إلى الحصول على بيانات إحصائية مضلِّلة لأنّ متغيرات الأخطاء ستحتوي على اسم سياسة AcceleratedFault، ما يزيد من صعوبة تصحيح أخطاء الخادم الوكيل. والطريقة الصحيحة لتنفيذ السلوك المطلوب هي استخدام المسارات ذات الشروط الخاصة، كما هو موضّح في إضافة دعم سياسة مشاركة الموارد متعددة المصادر (CORS).

التأثير

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

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

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

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

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

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

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

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