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

أنت الآن بصدد الاطّلاع على مستندات 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> من سياسة Service Callout ليس من النوع 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. تحديد ما إذا كان هذا المتغيّر من نوع رسالة أم لا:

    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 ليس من نوع الرسالة (بل هو سلسلة في هذا المثال)، ستتلقّى رمز الخطأ: steps.servicecallout.RequestVariableNotMessageType.

الدقة

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

لتصحيح السياسة، عليك تعديل العنصر <Request> لتحديد متغيّر حالي أو جديد من نوع الرسالة. على سبيل المثال، المتغيّر 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> من سياسة Service Callout ليس من النوع رسالة الطلب. ستظهر لك رسالة الخطأ هذه إذا كان المتغير من نوع رسالة رد أو سلسلة أو أي نوع آخر.

تمثّل متغيرات النوع Message طلبات HTTP واستجاباته بالكامل. تكون متغيّرات تدفق Edge المضمّنة request وresponse و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 المُشار إليه في سياسة "استدعاء الخدمة" في سياسة "تعيين الرسالة" التالية. يُرجى العِلم أنّ 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>. إذا كان التنسيق غير صحيح أو كان اسم المضيف غير صالح أو لا يمكن الوصول إليه، سيكون ذلك هو سبب هذا الخطأ. على سبيل المثال، تحدِّد سياسة "استدعاء الخدمة" التالية <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 صالحًا مع اسم مضيف يمكن الوصول إليه.

لتصحيح سياسة "وسائل الشرح الخاصة بالخدمة" الموضّحة أعلاه، يمكنك تعديل العنصر <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 التالي، اسم سياسة Service Callout التي تعذّر تنفيذها هو ExecuteGeocodingRequest.

    "faultstring": "ServiceCallout[ExecuteGeocodingRequest]

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

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

الدقة

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