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

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

לדוגמה, נניח שהמשתנה PostalCode שיש אליו הפניה במדיניות בנושא יתרונות מרכזיים של שירות נוצר במדיניות הבאה של הקצאת הודעה. שימו לב ש-PostalCode מקבל את הערך של משתנה הזרימה request.queryparam.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> במדיניות בנושא יתרונות מרכזיים של שירות שנכשל הוא משתנה זרימה מסוג הודעה שקיים. לחלופין, אפשר ליצור משתנה חדש של סוג הודעה ישירות במדיניות בנושא יתרונות מרכזיים של שירות (כפי שמוסבר במסמכי המדיניות) ולהשתמש בו.

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

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

אבחון

  1. מאתרים את המדיניות של Service Callout שבה התרחשה השגיאה ואת שם המשתנה שהסוג שלו שגוי. שני הפריטים האלה מופיעים ברכיב 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. מאתרים את הקוד בחבילת שרת ה-proxy ל-API, שבו המשתנה הוגדר לראשונה.
    2. ברוב המקרים, משתנה הבעיה נוצר ומאוכלס במדיניות אחרת שמופעלת לפני המדיניות בנושא יתרונות מרכזיים של שירות. לדוגמה, המדיניות 'הקצאת הודעה' משמשת בדרך כלל כדי ליצור ולאכלס משתנים בתהליך proxy ל-API.
    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> של המדיניות בנושא מודעות 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> במדיניות של נכס היתרונות המרכזיים שנכשלו הוא משתנה מסוג הודעת בקשה שקיים. לחלופין, אפשר ליצור משתנה חדש של סוג הודעת בקשה ישירות במדיניות 'יתרונות מרכזיים של שירות' (כפי שמוסבר במסמכי המדיניות) ולהשתמש בו.

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

הסיבה: כתובת URL לא תקינה או שגויה

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

אבחון

  1. מזהים את המדיניות בנושא יתרונות מרכזיים של שירות שגרמה לשגיאה. שם המדיניות מופיע ברכיב faultstring של תגובת השגיאה. לדוגמה, בfaultstring הבאים, השם של המדיניות בנושא יתרונות מרכזיים של שירות שנכשל הוא 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. מזהים את המדיניות בנושא יתרונות מרכזיים של שירות שגרמה לשגיאה. שם המדיניות מופיע ברכיב 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).