آنچه باید درباره خطاهای خط‌مشی بدانید

درحال مشاهده اسناد Apigee Edge هستید.
به اسناد Apigee X بروید. اطلاعات

این موضوع ساختار خطاهای خط‌مشی و انواع متغیرهای جریانی را که هنگام بروز خطای خط‌مشی تنظیم می‌شوند شرح می‌دهد. اگر درحال طراحی و پیاده‌سازی مدیریت خطا برای پراکسی‌هایتان هستید، این اطلاعات ضروری است.

این موضوع فرض می‌کند که شما درک کلی از نحوه عملکرد مدیریت خطا در Edge دارید و می‌دانید قوانین خطا چیست. اگر به بازبینی نیاز دارید، رسیدگی به خطاها را ببینید. اطلاعات اینجا همچنین به شما کمک می‌کند تا در مرجع خطای خط‌مشی پیمایش و از آن استفاده کنید.

درباره پاسخ خطای خط‌مشی پیش‌فرض

وقتی خط‌مشی‌ای خطا می‌دهد، Edge بلافاصله وارد جریان خطا می‌شود و پیام خطا تولید می‌کند. این پیام تولیدشده توسط سیستم یک شیء JSON است که شامل دو بخش اطلاعات است: یک errorcode و یک faultstring.

برای مثال:

{  
   "fault":{  
      "detail":{  
         "errorcode":"steps.extractvariables.SourceMessageNotAvailable"
      },
      "faultstring":"foo message is not available for ExtractVariable: ParseJsonResponse"
   }
}

بیایید این پیام خطا را به‌سرعت تجزیه‌وتحلیل کنیم:

errorcode از یک پیشوند و یک نام خطا تشکیل شده است، به این صورت: [prefix].[error_name]. در مثال بالا «steps.extractvariables» پیشوند و SourceMessageNotAvailable نام خطا است. پیشوند به شما می‌گوید که چه نوع خط‌مشی‌ای باعث ایجاد خطا شده است. در مثال بالا، می‌توانید متوجه شوید که خط‌مشی «استخراج متغیرها» خطا را تولید کرده است و نام خطا SourceMessageNotAvailable است.

faultstring حاوی شرحی از خطا است. رشته خطا معمولاً شامل نشانه‌هایی است که به شما کمک می‌کند مشکل خاصی را که باعث خطا شده است پیدا کنید، مانند نام خط‌مشی، نام متغیر حل‌نشده، یا هر چیزی که در بروز خطا نقش داشته است. برای مثال، در پیام خطای بالا، «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

متغیر error فقط در جریان خطای یک پراکسی دردسترس است. می‌توانید اطلاعات مفیدی از متغیر خطا دریافت کنید، ازجمله پیام خطا، کد وضعیت، عبارت دلیل، و غیره. الگوی قالب‌بندی برای متغیر خطا به‌صورت زیر است:

error.[error_component] = [value]

برای مثال:

‫error.message = "request message is not available for ExtractVariable: ParseJsonResponse اینچ

و

error.status.code = "500"

متغیر message نیز در جریان خطا دردسترس است و می‌تواند برای اهداف مشابه متغیر error استفاده شود. متغیر پیام ویژه است زیرا زمینه‌ای است. در جریان درخواست، این متغیر مثل متغیر درخواست عمل می‌کند و در جریان پاسخ، می‌توان از آن برای دریافت/تنظیم مقادیر پاسخ استفاده کرد. اگر می‌خواهید بیشتر بدانید، استفاده از حروف برای متغیرهای پیام را ببینید.

برای اطلاعات درباره همه متغیرهای Edge، ازجمله error و message، به مرجع متغیرها مراجعه کنید.