خطای ناشناخته در Try this panel API

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

علامت

فراخوانی API از پورتال توسعه‌دهندگان یکپارچه با Unknown Error یا پاسخ خالی در پنل «این API را امتحان کنید» با شکست مواجه می‌شود.

پیام‌های خطا

ممکن است برای درخواست‌های API در پورتال یکپارچه، پاسخی خالی یا پیام خطای زیر را مشاهده کنید:

Unknown Error

در تب Developer Tools > Console ، خطای زیر را مشاهده خواهید کرد:

Access to XMLHTTPRequest at 'API_URL' from origin 'URL_of_Integrated_DevPortal'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is
present on the requested resource.

یک پیام خطای عمومی که در تب Developer Tools > Console مشاهده می‌شود، به شرح زیر است:

علل احتمالی

علت: خطای سیاست مدیریت نشده

تشخیص

1. تأیید کنید که مشکل فقط در صورتی رخ می‌دهد که انتظار پاسخی غیر از 2XX وجود داشته باشد.
2. برای درخواست‌های ناموفق، بررسی کنید که آیا سیاست‌هایی در جریان پروکسی وجود دارد یا خیر.
3. درخواست را ردیابی کنید و بررسی کنید که آیا سیاستی با continueOnError="false" با شکست مواجه شده و خطا ایجاد می‌کند یا خیر.
1. اگر بله، بررسی کنید که آیا سیاست AssignMessage CORS در جریان پاسخ خطا اجرا شده است یا خیر.
2. اگر اینطور نیست، پس دلیل این مشکل همین است.
   دلیل این امر آن است که وقتی هر سیاستی با عنصر continueOnError="false" با شکست مواجه می‌شود، درخواست وارد جریان پاسخ خطا می‌شود. اگر هیچ مدیریت خطای صریحی در جریان پاسخ خطا وجود نداشته باشد، پاسخ خطای پیش‌فرض مربوط به سیاست بازگردانده می‌شود. این پاسخ خطا هیچ هدر CORS ندارد. در نتیجه، فراخوانی API از پورتال توسعه‌دهنده یکپارچه با Unknown error با شکست مواجه می‌شود.

تصاویر زیر یک نمونه پیام خطا و یک نمونه پیام موفقیت را نشان می‌دهند.

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

نمونه پیام موفقیت در پورتال یکپارچه این پنل API و در پنجره ردیابی پروکسی را امتحان کنید:

وضوح تصویر

1. به جای تکیه بر پیام خطای پیش‌فرض، باید یک قانون خطا برای مدیریت پاسخ خطا پیاده‌سازی شود. یک سیاست AssignMessage CORS را با هدرهای مناسب وارد کنید و آن را در FaultRule فراخوانی کنید.
2. گاهی اوقات ممکن است تعریف یک قانون خطا برای هر خطا امکان‌پذیر نباشد؛ بنابراین، می‌توان یک قانون خطای پیش‌فرض برای اجرای سیاست AssignMessage CORS پیاده‌سازی کرد:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="proxy-endpoint-name">
    <Description/>
    <!-- Add a default fault rule to add CORS -->
    <DefaultFaultRule name="fault-rule">
        <Step>
            <Name>add-cors</Name>
        </Step>
    </DefaultFaultRule>
    <FaultRules/>
    <!--
    <Flows />
    Rest of the proxy definition
    -->
</ProxyEndpoint>

علت: مقادیر چندگانه برای Access-Control-Allow-Origin

تشخیص

1. مقدار هدر Access-Control-Allow-Origin را در یک جلسه ردیابی بررسی کنید.
2. هدر Access-Control-Allow-Origin فقط اجازه تنظیم یک مقدار را می‌دهد. تنظیم بیش از یک مقدار می‌تواند باعث بروز مشکل CORS شود و پورتال توسعه‌دهنده نتواند هیچ پاسخی را ارائه دهد.
3. اگر مقدار هدر Access-Control-Allow-Origin در trace به شکل زیر باشد:
   *,*
این یعنی هم سرور هدف و هم سیاست AssignMessage CORS مقدار آن را تنظیم می‌کنند.
4. این می‌تواند زمانی اتفاق بیفتد که کاربر از <Add> element برای Access-Control-Allow-Origin در یک سیاست استفاده کرده باشد، یا خودِ backend چندین مقدار را تنظیم کرده باشد.

مثال Access-Control-Allow-Origin برابر با *,* :

مثال Access-Control-Allow-Origin برابر با * است:

مثال استفاده از <Add> :

مثال با استفاده از <Set> :

وضوح تصویر

1. رویکرد پیشنهادی این است که از <Set> element (به جای <Add> element ) برای Access-Control-Allow-Origin استفاده کنید، زیرا فقط یک مقدار واحد مجاز است.
2. روش دیگر این است که هدر Access-Control-Allow-Origin را فقط در یک جا تنظیم کنید؛ یا در پالیسی AssignMessage CORS یا در سرور هدف.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="set-cors">
    <DisplayName>Set CORS</DisplayName>
    <FaultRules/>
    <Properties/>
    <Set>
        <Headers>
            <Header name="Access-Control-Allow-Origin">*</Header>
        </Headers>
    </Set>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="response"/>
</AssignMessage>

اگر هنوز به هرگونه کمکی از پشتیبانی Apigee نیاز دارید، به بخش «باید اطلاعات تشخیصی را جمع‌آوری کنید» بروید.

باید اطلاعات تشخیصی جمع‌آوری کند

اطلاعات تشخیصی زیر را جمع‌آوری کنید و سپس با پشتیبانی Apigee Edge تماس بگیرید:

• نام سازمان
• نام محیط
• نام پروکسی API
• دستور curl کامل که برای بازتولید خطا استفاده می‌شود
• فایل ردیابی برای درخواست‌های API
• خروجی کامل پاسخ از سرور هدف/بک‌اند به همراه اندازه‌ی بار داده