הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.
לעיון במסמכי התיעוד של Apigee Edge
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> של מדיניות ServiceCallout הוא לא מסוג message. אם המשתנה הוא מחרוזת או כל סוג אחר שאינו הודעה, תוצג השגיאה הזו.
משתנים מסוג הודעה מייצגים בקשות ותגובות מלאות של HTTP. משתני הזרימה המובנים request, response ו-message הם מסוג message.
אבחון
מזהים את מדיניות ServiceCallout שבה התרחשה השגיאה ואת שם המשתנה שהסוג שלו שגוי. אפשר למצוא את שני הפריטים האלה ברכיב
faultstringשל תגובת השגיאה. לדוגמה, ברכיבfaultstringהבא, שם המדיניות הואExecuteGeocodingRequestוהמשתנה הואPostalCode:"faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable PostalCode value is not of type Message"ב-XML של מדיניות ServiceCallout שנכשלה, מוודאים שהשם של המשתנה שהוגדר ברכיב
<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>קובעים אם המשתנה הזה הוא מסוג הודעה או לא:
- מאתרים את הקוד בחבילת ה-API Proxy, שבו המשתנה הוגדר לראשונה.
- ברוב המקרים, משתנה הבעיה נוצר ומאוכלס במדיניות אחרת שמופעלת לפני מדיניות ServiceCallout. לדוגמה, המדיניות Assign Message משמשת בדרך כלל ליצירה ולאכלוס של משתנים בתהליך של API Proxy.
- אחרי שמגלים באיזו מדיניות המשתנה מוגדר ומאוכלס קודם, צריך לקבוע את סוג המשתנה באופן הבא:
- בודקים את הערך של מאפיין
type(אם הוא קיים). - אם המאפיין
typeלא מופיע, המשתנה נחשב למחרוזת.
- בודקים את הערך של מאפיין
- אם סוג המשתנה הוא לא הודעה (למשל מחרוזת), זו הסיבה לשגיאה. במאמר הפניה למשתני זרימה אפשר לקרוא על משתנים נפוצים ועל הסוגים שלהם.
לדוגמה, נניח שהמשתנה PostalCode שאליו מתייחסת מדיניות ServiceCallout נוצר במדיניות AssignMessage הבאה. שימו לב: הערך של משתנה הזרימה 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> של מדיניות ServiceCallout:
<?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> במדיניות ServiceCallout שנכשלה הוא משתנה מסוג message שקיים בתהליך, או לחלופין אפשר ליצור משתנה חדש מסוג הודעה ישירות במדיניות ServiceCallout (כפי שמוסבר במאמר בנושא מדיניות ServiceCallout) ולהשתמש בו.
כדי לתקן את המדיניות, צריך לשנות את רכיב <Request> כדי לציין משתנה קיים או חדש מסוג הודעה. לדוגמה, המשתנה GeocodingRequest שהוגדר במדיניות Assign Message הוא מסוג message, והוא יפעל בצורה תקינה במדיניות ServiceCallout. לדוגמה:
<?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> של מדיניות ServiceCallout הוא לא מסוג message. אם המשתנה הוא מסוג הודעת תגובה, מחרוזת או כל סוג אחר, תוצג השגיאה הזו.
משתנה מסוג message מייצג בקשות ותגובות מלאות של HTTP. משתני הזרימה המובְנים request, response ו-message הם מסוג message.
אבחון
מזהים את מדיניות ServiceCallout שבה התרחשה השגיאה ואת שם המשתנה שהסוג שלו שגוי. אפשר למצוא את שני הפריטים האלה ברכיב
faultstringשל תגובת השגיאה. לדוגמה, ברכיבfaultstringהבא, שם המדיניות הואExecuteGeocodingRequestוהמשתנה הואvar_response:"faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable var_response value is not of type Message"ב-XML של מדיניות ServiceCallout שנכשלה, מוודאים שהשם של המשתנה שהוגדר ברכיב
<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>בודקים אם המשתנה הוא מסוג הודעת בקשה:
- מאתרים את הקוד בחבילת ה-API Proxy, שבו המשתנה הוגדר לראשונה.
- ברוב המקרים, משתנה הבעיה נוצר ומאוכלס במדיניות אחרת שמופעלת לפני מדיניות ServiceCallout. לדוגמה, המדיניות Assign Message משמשת בדרך כלל ליצירה ולאכלוס של משתנים בתהליך של API Proxy.
- אחרי שמגלים באיזו מדיניות המשתנה מוגדר ומאוכלס קודם, צריך לקבוע את סוג המשתנה באופן הבא:
- בודקים את הערך של מאפיין
type(אם הוא קיים). - אם המאפיין
typeלא מופיע, המשתנה נחשב למחרוזת.
- בודקים את הערך של מאפיין
- אם סוג המשתנה הוא לא בקשת הודעה, זו הסיבה לשגיאה. במאמר הפניה למשתני זרימה אפשר לקרוא על משתנים נפוצים ועל הסוגים שלהם.
לדוגמה, נניח שהמשתנה var_response שאליו מתייחסת מדיניות ServiceCallout נוצר במדיניות Assign Message הבאה. שימו לב שהסוג response מוקצה למשתנה var_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> של מדיניות ServiceCallout.
<?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> במדיניות ServiceCallout שנכשלה הוא משתנה מסוג message שקיים, או לחלופין אפשר ליצור משתנה חדש מסוג הודעת בקשה ישירות במדיניות ServiceCallout (כפי שמוסבר במאמר בנושא מדיניות ServiceCallout) ולהשתמש בו.
כדי לתקן את המדיניות, צריך לשנות את רכיב <Request> כדי לציין משתנה קיים או חדש מסוג הודעת בקשה, והוא יפעל במדיניות ServiceCallout. לדוגמה:
<?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 של היעד במדיניות ServiceCallout היא בפורמט שגוי או שיש בה שם מארח לא תקין או שלא ניתן להגיע אליו. |
| שגיאה בשרת בק-אנד | השרת העורפי מחזיר תגובת שגיאה מסוג 4XX או 5XX. |
הסיבה: כתובת URL לא תקינה או לא מעוצבת
כתובת ה-URL של היעד במדיניות ServiceCallout היא בפורמט שגוי או שיש בה שם מארח לא תקין או שלא ניתן להגיע אליו.
אבחון
מזהים את מדיניות ServiceCallout שגרמה לשגיאה. שם המדיניות מופיע ברכיב
faultstringשל תגובת השגיאה. לדוגמה, ב-faultstringהבא, שם מדיניות ServiceCallout שנכשלה הואExecuteGeocodingRequest."faultstring": "ServiceCallout[ExecuteGeocodingRequest]"במדיניות ServiceCallout שנכשלה, בודקים את הרכיב
<URL>. אם הוא מעוצב בצורה לא תקינה או שיש בו שם מארח לא תקין או שלא ניתן להגיע אליו, זו הסיבה לשגיאה הזו. לדוגמה, במדיניות ServiceCallout הבאה מצוין<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://, אבל אין לו שם מארח תקין. לכן, מדיניות ServiceCallout נכשלת עם השגיאה:Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: Host not reachable.
רזולוציה
מוודאים שרכיב <URL> במדיניות ServiceCallout שנכשלה מכיל כתובת URL תקינה עם שם מארח שאפשר להגיע אליו.
כדי לתקן את מדיניות ServiceCallout שמוצגת למעלה, אפשר לשנות את הרכיב <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.
אבחון
מזהים את מדיניות ServiceCallout שגרמה לשגיאה. שם המדיניות מופיע ברכיב
faultstringשל תגובת השגיאה. לדוגמה, ב-faultstringהבא, שם מדיניות ServiceCallout שנכשלה הואExecuteGeocodingRequest."faultstring": "ServiceCallout[ExecuteGeocodingRequest]בודקים את
faultstringבגוף תגובת השגיאה, ומחפשים קודי תגובה מסוג 4XX או 5XX שמופיעים ב-Reason. לדוגמה, מחרוזת השגיאה הבאה מציינת בבירור שקוד התגובה 502 הוחזר משרת הקצה העורפי:"faultstring": "Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: ResponseCode 502 is treated as error"
רזולוציה
אחרי שתזהו את קוד התגובה לשגיאה, תוכלו לפתור את הבעיה הזו כמו כל שגיאה מסוג 4XX או 5XX.