הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.
לעיון במסמכי התיעוד של Apigee Edge
ExecutionError
קוד שגיאה
steps.javacallout.ExecutionError
גוף תגובת השגיאה
{
"fault": {
"faultstring": "Execution returned an error result",
"detail": {
"errorcode": "flow.execution.ExecutionReturnedFailure"
}
}
}
מטרה
השגיאה הזו מתרחשת אם קוד Java יוצר חריגה או מחזיר null במהלך ההפעלה של מדיניות JavaCallout.
אבחון
מפעילים סשן מעקב כדי לתעד את השגיאה ולזהות את מדיניות JavaCallout שנכשלה.

בודקים את מדיניות JavaCallout ואת המשאב שבו נעשה שימוש. בדוגמה שלמעלה, JavaCallout policy משתמש במשאב בשם
hello.jar, כמו שמוצג בהמשך:<JavaCallout name="hello-java"> <ClassName>com.apigeesample.HelloJava</ClassName> <ResourceURL>java://hello.jar</ResourceURL> </JavaCallout>כדי לתעד ולאחסן את חריגת Java במשתנה של זרימת נתונים, צריך לשנות את קוד המקור, כמו שמתואר במאמר טיפול בשגיאות במדיניות JavaCallout.
קומפילציה והחלפה של המשאב המושפע (קובץ JAR) בפריט מידע מעודכן של Java.
פורסים את ה-API Proxy כגרסה חדשה ומבצעים את הקריאה ל-API.
מתחילים סשן חדש של מעקב.

שימו לב שהמשתנה
JAVA_STACKTRACEמכיל את פרטי דוח הקריסות. בדוח קריסות (stack trace) מפורטים החריגה בפועל, קובץ המקור של Java ומספר השורה שבה השגיאה מופעלת.אפשר להשתמש במידע הזה כדי לפתור את הבעיה בקוד Java.
בדוגמה הזו, המדיניות JavaCallout נכשלה בגלל ArithmeticException (חלוקה באפס) בקובץ
JavaError.javaבשורה #25.
רזולוציה
בהתאם לחריגה שנוצרה, מתקנים את הבעיה בקובץ או בקבצים הרלוונטיים של מקור Java. א. בדוגמה שלמעלה, הבעיה נגרמה בגלל שגיאה אריתמטית (חלוקה באפס). עוברים לקובץ המקור הספציפי ולמספר השורה שמצוינים ב-stack trace.

ב. מכיוון שאי אפשר לחלק באפס, כדי לפתור את הבעיה צריך להסיר את כל בלוק ה-else שמכיל את שורת הקוד הפגומה.
מחליפים את קובץ ה-JAR הרלוונטי שמכיל את הקבצים ששונו ברמה המתאימה (proxy ל-API, סביבה או ארגון), במקום שבו הוא היה קודם.
שומרים ופורסים את proxy ל-API כגרסה חדשה.