سياسة RaiseFault

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

المزايا

إنشاء رسالة مخصّصة استجابةً لشرط خطأ يمكن استخدام riseFault لتحديد الاستجابة للخطأ التي يتم إرجاعها إلى التطبيق صاحب الطلب عند ظهور حالة معينة.

للحصول على معلومات عامة عن التعامل مع الأخطاء، يمكنك الاطّلاع على معالجة الأخطاء.

نماذج

<RaiseFault name="404">
 <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
 <FaultResponse>
   <Set>
     <StatusCode>404</StatusCode>
     <ReasonPhrase>The resource requested was not found</ReasonPhrase>
   </Set>
 </FaultResponse>
</RaiseFault>

<RaiseFault name="ExceptionHandler">
 <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
 <FaultResponse>
   <Set>
     <Payload contentType="text/xml">
       <root>Please contact support@company.com</root>
     </Payload>
     <StatusCode>{response.status.code}</StatusCode>
     <ReasonPhrase>Server error</ReasonPhrase>
   </Set>
   <Add>
     <Headers>
       <Header name="FaultHeader">{fault.name}</Header>
     </Headers>
   </Add>
 </FaultResponse>
</RaiseFault>

لمحة عن سياسة AskFault

تتيح لك Apigee Edge إجراء معالجة مخصّصة للاستثناء باستخدام سياسة من النوع AskFault. تشبه سياسة riseFault سياسة assignMessage: إنشاء رد مخصّص للخطأ استجابةً لأحد حالات الخطأ.

يمكنك استخدام سياسة RestoreFault لتحديد الاستجابة الخاطئة للتطبيق الذي قدّم الطلب. عند ظهور شرط معين لخطأ. يمكن أن تتكون الاستجابة للخطأ من عناوين HTTP أو طلب بحث والمعلمات وحمولة الرسالة. قد تكون الاستجابة المخصّصة للأخطاء مفيدة أكثر لمطوِّري التطبيقات. المستخدمين النهائيين والتطبيق مقارنة برسائل الخطأ العامة أو رموز استجابة HTTP.

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

يمكنك استخدام FoundFault في ProxyEndpoint أو TargetEndpoint. عادةً، ستقوم بإرفاق الحالة إلى سياسة riseFault بعد تنفيذ AskFault، سيعمل Apigee بشكل طبيعي معالجة الأخطاء، بتقييم قواعد الأخطاء أو في حال عدم تحديد قواعد للخطأ، يتم إنهاء المعالجة. بالطلب.

مرجع العنصر

يصف مرجع العنصر عناصر سياسة AskFault وسماتها.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault async="false" continueOnError="false" enabled="true" name="Raise-Fault-1">
    <DisplayName>RaiseFault 1</DisplayName>
    <FaultResponse>
        <AssignVariable>
          <Name/>
          <Value/>
        </AssignVariable>
        <Add>
            <Headers/>
        </Add>
        <Copy source="request">
            <Headers/>
            <StatusCode/>
            <ReasonPhrase/>
        </Copy>
        <Remove>
            <Headers/>
        </Remove>
        <Set>
            <Headers/>
            <Payload/>
            <ReasonPhrase/>
            <StatusCode/>
        </Set>
    </FaultResponse>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>

<RaiseFault> السمات

<RaiseFault async="false" continueOnError="false" enabled="true" name="Raise-Fault-1">

يصف الجدول التالي السمات المشتركة بين جميع العناصر الرئيسية للسياسة:

<DisplayName> عنصر

استخدِمه مع السمة name لتصنيف السياسة في إدارة خادم وكيل لواجهة المستخدم باسم مختلف بلغة طبيعية.

<DisplayName>Policy Display Name</DisplayName>

<IgnoreUnresolvedVariables> عنصر

(اختياري) يتجاهل أي خطأ متغيّر لم يتم حله في التدفق. القيم الصالحة هي: true/false. true التلقائي.

<FaultResponse> عنصر

(اختياري) تحدِّد هذه السياسة رسالة الردّ التي يتم إرجاعها إلى البرنامج الذي أرسل الطلب. استخدامات استجابة الخطأ الإعدادات نفسها المُستخدَمة في سياسة AssignMessage (غير متوفّرة في Apigee Edge for Private Cloud).

<FaultResponse><AssignVariable> عنصر

يعيّن قيمة لمتغير تدفق وجهة. في حال عدم توفّر متغيّر التدفق، سينشئه AssignVariable.

على سبيل المثال، يمكنك استخدام الرمز التالي لضبط المتغيّر المُسمّى myFaultVar. في سياسة AskFault:

<FaultResponse>
  <AssignVariable>
    <Name>myFaultVar</Name>
    <Value>42</Value>
  </AssignVariable>
  ...
</FaultResponse>

يمكنك بعد ذلك الرجوع إلى ذلك المتغيّر في نماذج الرسائل لاحقًا في سياسة AnchorFault. ويمكن أيضًا للسياسة المرتبطة بقاعدة FaultRule الوصول إلى المتغيّر. على سبيل المثال، ما يلي تستخدم سياسة AssignMessage المتغيّر الذي تم ضبطه في RestoreFault لضبط عنوان في الاستجابة للخطأ:

<AssignMessage enabled="true" name="Assign-Message-1">
  <Add>
    <Headers>
      <Header name="newvar">{myFaultVar}</Header>
    </Headers>
  </Add>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" transport="http" type="response"/>
</AssignMessage>

تستخدم <AssignVariable> في سياسة AskFault البنية نفسها مثل العنصر <AssignVariable> في سياسة AssignMessage. لاحظ أن هذه الوظيفة غير متاح حاليًا في Apigee Edge for Private Cloud.

<FaultResponse><Add>/<Headers> عنصر

إضافة عناوين HTTP إلى رسالة الخطأ لاحظ أن الرأس الفارغ لا يضيف <Add><Headers/></Add> أي عنوان. هذا النمط المثال ينسخ قيمة متغير التدفق request.user.agent إلى .

<Add>
    <Headers>
        <Header name="user-agent">{request.user.agent}</Header>
    </Headers>
</Add>

<FaultResponse><Copy> عنصر

تنسخ المعلومات من الرسالة التي يحدِّدها source السمة إلى رسالة الخطأ.

    <Copy source="request">
        <Headers/>
        <StatusCode/>
        <ReasonPhrase/>
    </Copy>

السمات

 <Copy source="response">

<FaultResponse><Copy>/<Headers> عنصر

يتم نسخ عنوان HTTP المحدد من المصدر إلى رسالة الخطأ. لنسخ جميع العناوين، تحديد <Copy><Headers/></Copy>.

<Copy source='request'>
    <Headers>      
        <Header name="headerName"/>
    </Headers> 
</Copy>

في حال وجود عدة عناوين تحمل الاسم نفسه، استخدِم الصيغة التالية:

<Copy source='request'>
    <Headers>
      <Header name="h1"/>
      <Header name="h2"/>
      <Header name="h3.2"/>
    </Headers>
</Copy>

ينسخ هذا المثال "h1" و"h2" والقيمة الثانية "h3". إذا كانت "h3" لديه واحدة فقط فلن يتم نسخها.

<FaultResponse><Copy>/<StatusCode> عنصر

رمز حالة HTTP المطلوب نسخه من الكائن الذي حدَّدته السمة المصدر إلى الخطأ .

<Copy source='response'>
    <StatusCode>404</StatusCode>      
</Copy>

<FaultResponse><Copy>/<ReasonPhrase> عنصر

سبب الوصف للنسخ من العنصر الذي حددته سمة المصدر إلى الخطأ .

<Copy source='response'>     
    <ReasonPhrase>The resource requested was not found.</ReasonPhrase>     
</Copy>

<FaultResponse><Remove>/<Headers> عنصر

إزالة عناوين HTTP المحددة من رسالة الخطأ لإزالة جميع الرؤوس، حدِّد <Remove><Headers/></Remove> يؤدي هذا المثال إلى إزالة عنوان user-agent من الرسالة.

<Remove>     
    <Headers>      
        <Header name="user-agent"/>     
    </Headers> 
</Remove>

في حال وجود عدة عناوين تحمل الاسم نفسه، استخدِم الصيغة التالية:

<Remove>
    <Headers>
      <Header name="h1"/>
      <Header name="h2"/>
      <Header name="h3.2"/>
    </Headers>
</Remove>

يزيل هذا المثال "h1" و"h2" والقيمة الثانية "h3". إذا كانت "h3" لديه واحدة فقط فلن تتم إزالتها.

<FaultResponse><Set> عنصر

لضبط المعلومات في رسالة الخطأ.

    <Set>
        <Headers/>
        <Payload> </Payload>
        <StatusCode/>
        <ReasonPhrase/>
    </Set>

<FaultResponse>/<Set>/<Headers> عنصر

لضبط عناوين HTTP أو استبدالها في رسالة الخطأ. لاحظ أن الرأس الفارغ لم يتم ضبط أي عنوان من قِبل "<Set><Headers/></Set>". يحدد هذا المثال عنوان user-agent إلى متغيّر الرسالة المحدّد العنصر <AssignTo>

<Set>
    <Headers>
        <Header name="user-agent">{request.header.user-agent}</Header>     
    </Headers>
</Set>

<FaultResponse>/<Set>/<Payload> عنصر

تضبط حمولة رسالة الخطأ.

<Set>
    <Payload contentType="text/plain">test1234</Payload>
</Set>

ضبط حمولة JSON:

<Set>
    <Payload contentType="application/json">
        {"name":"foo", "type":"bar"}
    </Payload>
</Set>

في حمولة JSON، يمكنك إدراج المتغيّرات باستخدام السمة variablePrefix variableSuffix بأحرف محدِّدة كما هو موضح في ما يلي مثال.

<Set>
    <Payload contentType="application/json" variablePrefix="@" variableSuffix="#">
        {"name":"foo", "type":"@variable_name#"}
    </Payload>
</Set>

أو، اعتبارًا من الإصدار 16.08.17 من السحابة الإلكترونية، يمكنك أيضًا استخدام الأقواس المتعرجة لإدراج المتغيرات:

<Set>
    <Payload contentType="application/json">
        {"name":"foo", "type":"{variable_name}"}
    </Payload>
</Set>

ضبط حمولة مختلطة في XML:

<Set>
    <Payload contentType="text/xml">
        <root>
          <e1>sunday</e1>
          <e2>funday</e2>
          <e3>{var1}</e3>
    </Payload>
</Set>

السمات

 
<Payload contentType="content_type" variablePrefix="char" variableSuffix="char">

<FaultResponse>/<Set>/<StatusCode> عنصر

لضبط رمز حالة الردّ.

<Set source='request'>
    <StatusCode>404</StatusCode>
</Set>

<FaultResponse>/<Set>/<ReasonPhrase> عنصر

تحدد عبارة السبب للرد.

<Set source='request'>     
    <ReasonPhrase>The resource requested was not found.</ReasonPhrase>
</Set>

<ShortFaultReason> عنصر

يُحدد لعرض سبب قصير للخطأ في الردّ:

<ShortFaultReason>true|false</ShortFaultReason>

وفقًا للإعدادات التلقائية، يكون سبب الخطأ في الردّ على السياسة هو:

"fault":{"faultstring":"Raising fault. Fault name : Raise-Fault-1","detail":{"errorcode":"errorCode"}}}

لتسهيل قراءة الرسالة، يمكنك ضبط العنصر <ShortFaultReason>. على "صحيح" لتقصير السمة faultstring إلى اسم السياسة فقط:

"fault":{"faultstring":"Raise-Fault-1","detail":{"errorcode":"errorCode"}}}

القيم الصالحة هي: true/false(تلقائيًا).

متغيّرات التدفق

تعمل متغيرات التدفق على تمكين السلوك الديناميكي للسياسات والتدفقات في وقت التشغيل، بناءً على HTTP العناوين أو محتوى الرسالة أو سياق التدفق. تتوفّر متغيّرات التدفق المحدَّدة مسبقًا التالية بعد تنفيذ سياسة FetchFault. لمزيد من المعلومات حول متغيّرات التدفق، اطّلِع على مرجع المتغيرات.

مثال على استخدام AskFault

يستخدم المثال التالي شرطًا لفرض وجود queryparam بالاسم zipcode في الطلب الوارد في حال حذف عدم توفّر queryparam، سيؤدي تدفّق البيانات إلى حدوث خطأ باستخدام riseFault:

<Flow name="flow-1">
  <Request>
    <Step>
        <Name>RF-Error-MissingQueryParam</Name>
        <Condition>request.queryparam.zipcode = null</Condition>
    </Step>
   ...
   </Request>
   ...
   <Condition>(proxy.pathsuffix MatchesPath "/locations") and (request.verb = "GET")</Condition>
</Flow>

<RaiseFault name='RF-Error-MissingQueryParam'>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <FaultResponse>
    <Set>
      <Payload contentType='application/json'>{
  "error" : {
    "code" : 400.02,
    "message" : "invalid request. Pass a zipcode queryparam."
  }
}
</Payload>
      <StatusCode>400</StatusCode>
      <ReasonPhrase>Bad Request</ReasonPhrase>
    </Set>
  </FaultResponse>
</RaiseFault>

مرجع الخطأ

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

أخطاء بيئة التشغيل

يمكن أن تحدث هذه الأخطاء عند تنفيذ السياسة.

أخطاء النشر

بلا عُري

متغيّرات الأخطاء

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

مثال على استجابة الخطأ

{
   "fault":{
      "detail":{
         "errorcode":"steps.raisefault.RaiseFault"
      },
      "faultstring":"Raising fault. Fault name: [name]"
   }
}

المخطط

يتم تحديد كل نوع سياسة من خلال مخطّط XML (.xsd). يمكنك الرجوع إلى مخططات السياسات المتوفرة على جيت هب.

مواضيع ذات صلة

يُرجى الاطّلاع على معالجة الأخطاء.