פתרון בעיות בזמן ריצה של יתרונות מרכזיים של שירות

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

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 הם מסוג message. מידע נוסף על משתני הודעות זמין במאמר בנושא משתנים.

אבחון

  1. מזהים את מדיניות Service Callout שבה התרחשה השגיאה ואת שם המשתנה שסוגו שגוי. אפשר למצוא את שני הפריטים האלה ברכיב faultstring של תגובת השגיאה. לדוגמה, בקטע faultstring הבא, שם המדיניות הוא ExecuteGeocodingRequest והמשתנה הוא PostalCode:

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

  2. ב-XML של מדיניות Service Callout שנכשלה, מוודאים שהשם של המשתנה שהוגדר ברכיב <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. מאתרים את הקוד בחבילת ה-API Proxy, שבו המשתנה הוגדר לראשונה.
    2. ברוב המקרים, משתנה הבעיה נוצר ומאוכלס במדיניות אחרת שמופעלת לפני מדיניות Service Callout. לדוגמה, המדיניות Assign Message משמשת בדרך כלל ליצירה ולאכלוס של משתנים בתהליך של API Proxy.
    3. אחרי שמגלים באיזו מדיניות המשתנה מוגדר ומאוכלס קודם, צריך לקבוע את סוג המשתנה באופן הבא:
      • בודקים את הערך של מאפיין type (אם הוא קיים).
      • אם המאפיין type לא מופיע, המשתנה נחשב למחרוזת.
    4. אם סוג המשתנה הוא לא הודעה (למשל מחרוזת), זו הסיבה לשגיאה. במאמר הפניה למשתנים אפשר לקרוא על משתנים נפוצים ועל הסוגים שלהם.

לדוגמה, נניח שהמשתנה PostalCode שאליו מתבצעת הפניה במדיניות Service Callout נוצר במדיניות Assign Message הבאה. שימו לב: הערך של משתנה הזרימה 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> של מדיניות Service Callout:

<?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 שהוגדר במדיניות Assign Message הוא מסוג message, והוא יפעל בצורה תקינה במדיניות Service Callout. לדוגמה:

<?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 הוא לא מסוג request message. אם המשתנה הוא מסוג הודעת תגובה, מחרוזת או כל סוג אחר, תוצג השגיאה הזו.

משתנים מסוג Message מייצגים בקשות ותגובות מלאות של HTTP. המשתנים המובנים של זרימת Edge‏ request, response ו-message הם מסוג message. מידע נוסף על משתני הודעות זמין במאמר בנושא משתנים.

אבחון

  1. מזהים את מדיניות Service Callout שבה התרחשה השגיאה ואת שם המשתנה שסוגו שגוי. אפשר למצוא את שני הפריטים האלה ברכיב faultstring של תגובת השגיאה. לדוגמה, בקטע faultstring הבא, שם המדיניות הוא ExecuteGeocodingRequest והמשתנה הוא var_response:

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

  2. ב-XML של מדיניות Service Callout שנכשלה, מוודאים שהשם של המשתנה שהוגדר ברכיב <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. מאתרים את הקוד בחבילת ה-API Proxy, שבו המשתנה הוגדר לראשונה.
    2. ברוב המקרים, משתנה הבעיה נוצר ומאוכלס במדיניות אחרת שמופעלת לפני מדיניות Service Callout. לדוגמה, המדיניות Assign Message משמשת בדרך כלל ליצירה ולאכלוס של משתנים בתהליך של API Proxy.
    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> של מדיניות Service Callout.

<?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> במדיניות Service Callout שנכשלה הוא משתנה מסוג request message שקיים, או לחלופין אפשר ליצור משתנה חדש מסוג request message ישירות במדיניות Service Callout (כמו שמוסבר במסמכי המדיניות) ולהשתמש בו.

כדי לתקן את המדיניות, צריך לשנות את האלמנט <Request> כדי לציין משתנה קיים או חדש מסוג הודעת בקשה, והיא תפעל במדיניות Service Callout. לדוגמה:

<?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 של היעד במדיניות Service Callout היא בפורמט שגוי או שיש בה שם מארח לא תקין או שלא ניתן להגיע אליו.
שגיאה בשרת בק-אנד השרת העורפי מחזיר תגובת שגיאה מסוג 4XX או 5XX.

הסיבה: כתובת URL לא תקינה או לא מעוצבת

כתובת ה-URL של היעד במדיניות Service Callout היא בעלת פורמט שגוי או שהיא מכילה שם מארח לא תקין או שלא ניתן להגיע אליו.

אבחון

  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://, אבל לא מכיל שם מארח תקין. לכן, המדיניות Service Callout נכשלת עם השגיאה: Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: Host not reachable.

רזולוציה

מוודאים שלרכיב <URL> במדיניות Service Callout שנכשלה יש כתובת URL תקינה עם שם מארח שאפשר להגיע אליו.

כדי לתקן את מדיניות Service Callout שמוצגת למעלה, אפשר לשנות את הרכיב <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. לדוגמה, מחרוזת השגיאה הבאה מציינת בבירור שקוד התגובה 502 הוחזר משרת הקצה העורפי:

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

רזולוציה

אחרי שתזהו את קוד התגובה לשגיאה, תוכלו לפתור את הבעיה הזו כמו כל שגיאה מסוג 4XX או 5XX. הוראות לפתרון שגיאות 4XX או 5XX מופיעות במדריכים לפתרון שגיאות בזמן ריצה (4XX/5XX).