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

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

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

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

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

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

نقوش

استخدام سياسة FetchFault ضمن FaultRules بعد ظهور خطأ معيّن

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

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

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

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

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

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

التأثير

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

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

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

عندما تبرز سياسة Edge خطأ وتريد تخصيص رسالة الرد على الخطأ، استخدام سياسات AssignMessage أو JavaScript بدلاً من سياسة TakeFault.

يجب استخدام سياسة wault tault في مسار غير خطأ. بمعنى آخر، لا تستخدم إلا مكتبة riseFault (رفع الوعاء) للتعامل مع نوع شرط عدم حدوث خطأ، حتى إذا لم يحدث خطأ فعلي في إحدى السياسات أو في خادم الخلفية خادم وكيل واجهة برمجة التطبيقات. على سبيل المثال، يمكنك استخدام سياسة FetchFault للإشارة إلى أنّ الإدخال الإلزامي المعلمات مفقودة أو تحتوي على بنية غير صحيحة.

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

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

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