מוצג המסמך של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info
ExecutionError
קוד שגיאה
steps.javacallout.ExecutionError
גוף התגובה לשגיאה
{
"fault": {
"faultstring": "Execution returned an error result",
"detail": {
"errorcode": "flow.execution.ExecutionReturnedFailure"
}
}
}
סיבה
השגיאה הזו מתרחשת אם קוד Java גורם להפעלת חריגה או מחזיר את הערך null במהלך ההפעלה של מדיניות JavaCallout.
אבחון
מתחילים סשן מעקב כדי לתעד את השגיאה ולזהות איזו מדיניות של JavaCallout נכשלה.
בודקים את מדיניות JavaCallout ואת המשאב שנעשה בו שימוש. בדוגמה שלמעלה, מדיניות JavaCallout משתמשת במשאב בשם
hello.jar
, כמו בדוגמה הבאה:<JavaCallout name="hello-java"> <ClassName>com.apigeesample.HelloJava</ClassName> <ResourceURL>java://hello.jar</ResourceURL> </JavaCallout>
מתעדים ומאחסנים את החריג של Java במשתנה זרימה על ידי שינוי קוד המקור, כפי שמתואר במאמר טיפול בשגיאות בהסבר על Java.
הידור והחלפה של המשאב המושפע (קובץ JAR) בארטיפקט המעודכן של Java.
פורסים את שרת ה-proxy ל-API כגרסה חדשה ומבצעים את קריאת ה-API.
מתחילים פעילות מעקב נוספת.
שימו לב שניתוח סטאק זמין במשתנה
JAVA_STACKTRACE
. דוח הקריסות מפרט את החריגה בפועל ואת קובץ המקור ומספר השורה של Java שבהם מוצגת השגיאה.תוכלו להשתמש במידע הזה כדי לפתור את הבעיה בקוד Java.
בדוגמה הזו, מדיניות JavaCallout נכשלה בגלל ArithmeticException (חלוקה באפס) בקובץ
JavaError.java
בשורה 25.
רזולוציה
בהתאם לחריגה שנרשמה, מתקנים את הבעיה בקובצי המקור הרלוונטיים של Java. a. בדוגמה שלמעלה, הבעיה נגרמה כתוצאה משגיאה אריתמטית (חלוקה באפס). עוברים לקובץ המקור ולמספר השורה הספציפיים שמצוינים בדוח הקריסות.
ב. מכיוון שאי אפשר לבצע חלוקה באפס, כדי לפתור את הבעיה צריך להסיר את הבלוק השלם אחר שמכיל את שורת הקוד הפגומה.
מחליפים את קובץ ה-JAR הרלוונטי שמכיל את הקבצים ששונו ברמה המתאימה (שרת proxy ל-API, סביבה או ארגון) שבו הם היו קיימים בעבר.
שומרים ופורסים את שרת ה-proxy ל-API כגרסה חדשה.