تحديد وحلّ المشاكل المتعلقة بأخطاء وقت تشغيل وسيلة شرح الخدمة

أنت تطّلع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. info

RequestVariableNotMessageType

رمز الخطأ

steps.servicecallout.RequestVariableNotMessageType

نص الاستجابة للخطأ

{
    "fault": {
        "faultstring": "ServiceCallout[policy_name]: request variable [variable_name] value is not of type Message",
        "detail": {
            "errorcode": "steps.servicecallout.RequestVariableNotMessageType"
        }
    }
}

السبب

يحدث هذا الخطأ إذا لم يكن المتغيّر المحدّد في عنصر <Request> من سياسة عرض معلومات الخدمة من النوع message. إذا كان المتغيّر سلسلة أو أي نوع آخر غير رسالة، ستظهر لك رسالة الخطأ هذه.

تمثّل متغيّرات أنواع الرسائل طلبات HTTP واستجاباتها بالكامل. متغيرات تدفق Edge المضمنة request وresponse وmessage من نوع الرسالة. لمزيد من المعلومات عن متغيّرات الرسائل، اطّلِع على مرجع المتغيّرات.

التشخيص

1. حدِّد سياسة عرض الخدمة التي حدث فيها الخطأ واسم المتغيّر الذي يكون نوعه غير صحيح. يمكنك العثور على كلا العنصرَين في عنصر faultstring من استجابة الخطأ. على سبيل المثال، في العنصر faultstring التالي، اسم السياسة هو ExecuteGeocodingRequest والمتغيّر هو PostalCode:

   "faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable PostalCode value is not of type Message"

2. في ملف XML لسياسة "تسمية الخدمة" التي تعذّر تنفيذها، تأكَّد من أنّ اسم المتغيّر الذي تم ضبطه في عنصر <Request> يتطابق مع اسم المتغيّر المحدّد في سلسلة الخطأ (الخطوة 1 أعلاه). على سبيل المثال، تحدّد السياسة التالية متغيّر طلب باسم PostalCode يتطابق مع ما هو وارد في faultstring:

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <ServiceCallout name="ExecuteGeocodingRequest">
       <Request variable="PostalCode"/>
       <Response>GeocodingResponse</Response>
       <HTTPTargetConnection>
           <URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
       </HTTPTargetConnection>
   </ServiceCallout>
   

3. حدِّد ما إذا كان هذا المتغيّر من النوع message أم لا:

   1. حدِّد موقع الرمز داخل حزمة الخادم الوكيل لواجهة برمجة التطبيقات، حيث تم تحديد المتغيّر أولاً.
   2. في معظم الحالات، ستلاحظ أنّ متغيّر المشكلة يتم إنشاؤه وتعبئته في سياسة أخرى يتم تنفيذها قبل سياسة عرض معلومات الخدمة. على سبيل المثال، تُستخدَم سياسة "تعيين الرسالة" عادةً لإنشاء متغيّرات وتعبئتها في مسار وكيل واجهة برمجة التطبيقات.
   3. بعد تحديد السياسة التي تم فيها تعريف المتغيّر وملؤه أولاً، عليك تحديد نوع هذا المتغيّر على النحو التالي:
      • تحقّق من قيمة السمة type (إذا كانت متوفّرة).
      • إذا لم تكن سمة type متوفّرة، يُعتبَر المتغيّر سلسلة.
   4. إذا كان نوع المتغير ليس رسالة (مثل سلسلة)، يكون هذا هو سبب الخطأ. يمكنك الاطّلاع على المتغيّرات الشائعة وأنواعها في مرجع المتغيّرات.

على سبيل المثال، لنفترض أنّه تم إنشاء المتغيّر PostalCode المُشار إليه في سياسة نصائح الخدمات في سياسة تحديد الرسالة التالية. يُرجى العِلم أنّه تمّ تعيين قيمة متغيّر التدفق request.queryparam.postalcode إلى PostalCode. هذه القيمة هي سلسلة، لأنّه لا تتوفّر سمة type في عملية ضبط المتغيّر.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage name="GenerateGeocodingRequest">
        <AssignTo createNew="true" type="request">GeocodingRequest</AssignTo>
    <Set>
        <QueryParams>
            <QueryParam name="address">{request.queryparam.postalcode}</QueryParam>
            <QueryParam name="region">{request.queryparam.country}</QueryParam>
            <QueryParam name="sensor">false</QueryParam>
        </QueryParams>
        <Verb>GET</Verb>
    </Set>
    <AssignVariable>
        <Name>PostalCode</Name>
        <Ref>request.queryparam.postalcode</Ref>
    </AssignVariable>
    <AssignVariable>
        <Name>Country</Name>
        <Ref>request.queryparam.country</Ref>
    </AssignVariable>
</AssignMessage>

تذكَّر الآن أنّه يتم استخدام المتغيّر PostalCode في العنصر <Request> من سياسة عرض الأسعار:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="ExecuteGeocodingRequest">
    <Request variable="PostalCode"/>
    <Response>GeocodingResponse</Response>
    <HTTPTargetConnection>
        <URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
    </HTTPTargetConnection>
</ServiceCallout>

بما أنّ PostalCode ليس من النوع message (إنّه سلسلة في هذا المثال)، ستتلقّى رمز الخطأ: steps.servicecallout.RequestVariableNotMessageType.

الدقة

تأكَّد من أنّ المتغيّر الذي تم ضبطه في عنصر <Request> في سياسة طلب الدعم التي تعذّر تنفيذها هو متغيّر مسار من النوع message متوفّر، أو يمكنك بدلاً من ذلك إنشاء متغيّر جديد لنوع الرسالة مباشرةً في سياسة طلب الدعم (كما هو موضّح في مستندات السياسة) واستخدامه.

لتصحيح السياسة، عليك تعديل العنصر <Request> لتحديد متغيّر حالي أو جديد من النوع message. على سبيل المثال، المتغيّر GeocodingRequest الذي تم ضبطه في سياسة "تعيين الرسالة" هو من النوع "رسالة"، وسيعمل بشكل جيد في سياسة "معلومات الخدمة". على سبيل المثال:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="ExecuteGeocodingRequest">
    <Request variable="GeocodingRequest"/>
    <Response>GeocodingResponse</Response>
    <HTTPTargetConnection>
        <URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
    </HTTPTargetConnection>
</ServiceCallout>

RequestVariableNotRequestMessageType

رمز الخطأ

steps.servicecallout.RequestVariableNotRequestMessageType

نص الاستجابة للخطأ

{
    "fault": {
        "faultstring": "ServiceCallout[policy_name]: request variable [variable_name] value is not of type Request Message",
        "detail": {
            "errorcode": "steps.servicecallout.RequestVariableNotRequestMessageType"
        }
    }
}

السبب

يحدث هذا الخطأ إذا لم يكن المتغيّر المحدّد في عنصر <Request> من سياسة عرض بيانات الخدمة من النوع رسالة طلب. إذا كان المتغير هو نوع رسالة رد أو سلسلة أو أي نوع آخر، سيظهر لك هذا الخطأ.

تمثّل متغيّرات نوع الرسالة طلبات HTTP واستجاباتها بالكامل. المتغيّرات المضمّنة لمسار Edge، وهي request وresponse وmessage، من النوع message. لمعرفة المزيد من المعلومات عن متغيّرات الرسائل، اطّلِع على مرجع المتغيّرات.

التشخيص

1. حدِّد سياسة عرض بيانات الخدمة التي حدث فيها الخطأ واسم المتغيّر الذي يكون نوعه غير صحيح. يمكنك العثور على كلا العنصرَين في عنصر faultstring من استجابة الخطأ. على سبيل المثال، في سياسة faultstring التالية، يكون اسم السياسة هو ExecuteGeocodingRequest والمتغيّر هو var_response:

   "faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable var_response value is not of type Message"

2. في ملف XML الخاص بسياسة "تسمية الخدمة" التي تعذّر تنفيذها، تأكَّد من أنّ اسم المتغيّر الذي تم ضبطه في عنصر <Request> يتطابق مع اسم المتغيّر المحدّد في سلسلة الخطأ (الخطوة 1 أعلاه). على سبيل المثال، تحدّد السياسة التالية متغيّر طلب باسم var_response يتطابق مع ما هو وارد في faultstring:

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <ServiceCallout name="ExecuteGeocodingRequest">
       <Request variable="var_response"/>
       <Response>GeocodingResponse</Response>
       <HTTPTargetConnection>
           <URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
       </HTTPTargetConnection>
   </ServiceCallout>
   

3. حدِّد ما إذا كان المتغيّر من نوع رسالة الطلب أم لا:

   1. حدِّد مكان الرمز ضمن حِزمة "الوكيل لواجهة برمجة التطبيقات"، حيث تم تعريف المتغيّر أولاً.
   2. في معظم الحالات، ستلاحظ أنّ متغيّر المشكلة يتم إنشاؤه وتعبئته في سياسة أخرى يتم تنفيذها قبل سياسة عرض معلومات الخدمة. على سبيل المثال، تُستخدَم سياسة "تعيين الرسالة" عادةً لإنشاء متغيّرات وتعبئتها في مسار وكيل واجهة برمجة التطبيقات.
   3. بعد تحديد السياسة التي تم فيها تعريف المتغيّر وملؤه أولاً، عليك تحديد نوع هذا المتغيّر على النحو التالي:
      • تحقّق من قيمة السمة type (إذا كانت متوفّرة).
      • إذا لم تكن سمة type متوفّرة، يُعتبَر المتغيّر سلسلة.
   4. إذا لم يكن نوع المتغيّر من النوع رسالة طلب، هذا هو سبب الخطأ. يمكنك التعرّف على المتغيّرات الشائعة وأنواعها في مرجع المتغيّرات.

على سبيل المثال، لنفترض أنّه تم إنشاء المتغيّر var_response المُشار إليه في سياسة Service Callout في سياسة Assign Message التالية. يُرجى العلم أنّه تم منح var_response النوع response. وبالتالي، يكون نوع المتغيّر var_response هو رسالة الردّ.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage name="GenerateGeocodingRequest">
        <AssignTo createNew="true" type="request">GeocodingRequest</AssignTo>
    <AssignTo createNew="true" type="response">var_response</AssignTo>
    <Set>
        <QueryParams>
            <QueryParam name="address">{request.queryparam.postalcode}</QueryParam>
            <QueryParam name="region">{request.queryparam.country}</QueryParam>
            <QueryParam name="sensor">false</QueryParam>
        </QueryParams>
        <Verb>GET</Verb>
    </Set>
    <AssignVariable>
        <Name>PostalCode</Name>
        <Ref>request.queryparam.postalcode</Ref>
    </AssignVariable>
    <AssignVariable>
        <Name>Country</Name>
        <Ref>request.queryparam.country</Ref>
    </AssignVariable>
</AssignMessage>

يُرجى تذكُّر أنّه يتم استخدام المتغيّر var_response في عنصر <Request> ضمن سياسة تصنيف الخدمات.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="ExecuteGeocodingRequest">
    <Request variable="var_response"/>
    <Response>GeocodingResponse</Response>
    <HTTPTargetConnection>
        <URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
    </HTTPTargetConnection>
</ServiceCallout>

بما أنّ var_response ليس من النوع رسالة طلب (نوعه هو رسالة استجابة)، يظهر لك رمز الخطأ: steps.servicecallout.RequestVariableNotRequestMessageType.

الدقة

تأكَّد من أنّ المتغيّر الذي تم ضبطه في عنصر <Request> في سياسة "معلومات الاتصال بالخدمة" التي تعذّر إكمالها هو متغيّر نوع رسالة الطلب متوفّر، أو يمكنك بدلاً من ذلك إنشاء متغيّر نوع رسالة طلب جديد مباشرةً في سياسة "معلومات الاتصال بالخدمة" (كما هو موضّح في مستندات السياسة) واستخدامه.

لتصحيح السياسة، عليك تعديل العنصر <Request> لتحديد متغيّر حالي أو جديد من النوع رسالة طلب، وسيعمل ذلك في سياسة عرض معلومات الخدمة. على سبيل المثال:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="ExecuteGeocodingRequest">
    <Request variable="GeocodingRequest"/>
    <Response>GeocodingResponse</Response>
    <HTTPTargetConnection>
        <URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
    </HTTPTargetConnection>
</ServiceCallout>

ExecutionFailed

رمز الخطأ

steps.servicecallout.ExecutionFailed

نص الاستجابة للخطأ

{
    "fault": {
        "faultstring": "Execution of ServiceCallout [policy_name] failed. Reason: Host not reachable",
        "detail": {
            "errorcode": "steps.servicecallout.ExecutionFailed"
        }
    }
}

أو

{
    "fault": {
        "faultstring": "Execution of ServiceCallout [policy_name] failed. Reason: ResponseCode [http_code] is treated as error",
        "detail": {
            "errorcode": "steps.servicecallout.ExecutionFailed"
        }
    }
}

الأسباب المحتملة

في ما يلي الأسباب المحتمَلة لهذا الخطأ:

السبب	الوصف
عنوان URL غير صالح أو مكتوب بشكلٍ غير صحيح	عنوان URL المستهدَف في سياسة عرض معلومات الخدمة مكتوب بشكل غير صحيح أو يحتوي على اسم مضيف غير صالح أو لا يمكن الوصول إليه.
خطأ في خادم الخلفية	يعرض خادم الخلفية استجابة خطأ من النوع 4XX أو 5XX.

السبب: عنوان URL غير صالح أو مكتوب بصيغة غير صحيحة

عنوان URL المستهدَف في سياسة عرض معلومات الخدمة مكتوب بشكل غير صحيح أو يحتوي على اسم مضيف غير صالح أو لا يمكن الوصول إليه.

التشخيص

1. حدِّد سياسة Service Callout التي أدّت إلى حدوث الخطأ. يظهر اسم السياسة في عنصر faultstring من استجابة الخطأ. على سبيل المثال، في faultstring التالي، اسم سياسة Service Callout التي تعذّر تطبيقها هو ExecuteGeocodingRequest.

   "faultstring": "ServiceCallout[ExecuteGeocodingRequest]"

2. في سياسة وسائل شرح الخدمة التي تعذّر تنفيذها، افحص العنصر <URL>. إذا كان مكتوبًا بشكل غير صحيح أو يحتوي على اسم مضيف غير صالح أو لا يمكن الوصول إليه، فإن هذا هو سبب هذا الخطأ. على سبيل المثال، تحدّد سياسة Service Callout التالية <URL> غير صالحة:

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <ServiceCallout name="ExecuteGeocodingRequest">
       <Request variable="GeocodingRequest"/>
       <Response>GeocodingResponse</Response>
       <HTTPTargetConnection>
           <URL>http://</URL>
       </HTTPTargetConnection>
   </ServiceCallout>
   

   يحتوي العنصر <URL> على البروتوكول http:// فقط، ولكن لا يحتوي على اسم مضيف صالح. لذلك، يتعذّر تنفيذ سياسة وسيلة شرح الخدمة مع ظهور الخطأ: Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: Host not reachable.

الدقة

تأكَّد من أنّ عنصر <URL> في سياسة عرض معلومات الخدمة التي تعذّر إكمالها يحتوي على عنوان URL صالح مع اسم مضيف يمكن الوصول إليه.

لتصحيح سياسة Service Callout policy (سياسة توضيح الخدمة) الموضّحة أعلاه، يمكنك تعديل العنصر <URL> لتحديد عنوان URL صالح:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="ExecuteGeocodingRequest">
    <Request variable="GeocodingRequest"/>
    <Response>GeocodingResponse</Response>
    <HTTPTargetConnection>
        <URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
    </HTTPTargetConnection>
</ServiceCallout>

السبب: خطأ في خادم الخلفية

يعرض خادم الخلفية استجابة خطأ من النوع 4XX أو 5XX.

التشخيص

1. حدِّد سياسة Service Callout التي أدّت إلى حدوث الخطأ. يظهر اسم السياسة في العنصر faultstring في استجابة الخطأ. على سبيل المثال، في faultstring التالية، يكون اسم سياسة وسيلة شرح الخدمة التي تعذّر تنفيذها هو ExecuteGeocodingRequest.

   "faultstring": "ServiceCallout[ExecuteGeocodingRequest]

2. راجِع faultstring في نص استجابة الخطأ وتحقّق ممّا إذا كانت هناك أي رموز استجابة من النوع 4XX أو 5XX مُدرَجة في Reason. على سبيل المثال، تشير سلسلة الخطأ التالية بوضوح إلى أنّه تم إرجاع رمز الاستجابة 502 من خادم الخلفية:

   "faultstring": "Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: ResponseCode 502 is treated as error"

الدقة

بعد تحديد رمز استجابة الخطأ، يمكنك تحديد هذه المشكلة وحلّها كما تفعل مع أيّ خطأ من نوع 4XX أو 5XX. راجِع كتب الخطط المتعلّقة بأخطاء وقت التشغيل (4XX/5XX) للحصول على تعليمات حول تحديد أخطاء 4XX أو 5XX وحلّها.