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

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

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

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

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

هنگامی که یک خط مشی خطا می دهد، 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 از کد خطا قرار می دهد (همانطور که در بخش قبل توضیح داده شد). ارزیابی این متغیر برای اجرای مشروط قوانین خطا بسیار رایج است.

در اینجا یک مثال قانون خطا وجود دارد که مقدار 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 تنظیم می‌شود. در قوانین خطا، باید بررسی کنید تا ببینید چه زمانی درست است -- یعنی بررسی کنید که آیا خطایی رخ داده است یا خیر. در اینجا نحوه ساخت یک شرطی است که [prefix].[policy_name].failed flag. برای بررسی صحیح این متغیر، باید دو چیز را بدانید:

• نام سیاستی که در حال بررسی آن هستید. این مقدار ویژگی نام خط مشی است، نه نام نمایشی. این ویژگی همیشه در 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 ، به مرجع متغیرها مراجعه کنید.