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

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

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

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

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

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

برای مثال:

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

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

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

رشته خطا شامل توضیحی از خطا است. رشته خطا معمولاً شامل سرنخ‌هایی است که به شما در یافتن مشکل خاصی که باعث خطا شده است، مانند نام سیاست، نام یک متغیر حل نشده یا هر چیزی که در ایجاد خطا نقش داشته است، کمک می‌کند. به عنوان مثال، در پیام خطای بالا، " foo " نام یک متغیر پیام حل نشده است که در سیاست به آن ارجاع داده شده است و " ParseJsonResponse " نام سیاستی است که باعث ایجاد خطا شده است.

متغیرهای مختص خطاهای سیاستی

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

متغیر fault.name

وقتی یک سیاست خطایی ایجاد می‌کند، متغیر جریان fault.name را روی بخش error_name از errorcode تنظیم می‌کند (همانطور که در بخش قبل توضیح داده شد). ارزیابی این متغیر برای اجرای مشروط قوانین خطا بسیار رایج است.

در اینجا یک مثال از قانون fault آورده شده است که مقدار 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 که هنگام اجرای یک سیاست، روی true یا false تنظیم می‌شود. در قوانین fault، شما می‌خواهید بررسی کنید که چه زمانی true است -- یعنی بررسی کنید که آیا خطایی رخ داده است یا خیر. در اینجا نحوه ساخت یک شرط که پرچم [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 مورد استفاده قرار گیرد. متغیر message به دلیل وابسته به متن بودن، خاص است. در جریان درخواست، مانند یک متغیر درخواست رفتار می‌کند و در جریان پاسخ، می‌تواند برای دریافت/تنظیم مقادیر پاسخ استفاده شود. اگر می‌خواهید اطلاعات بیشتری کسب کنید، به موارد استفاده از متغیرهای message مراجعه کنید.

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