אתם צופים במסמכי העזרה של 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
. ב-stack trace מפורטים החריגה בפועל, קובץ המקור של Java ומספר השורה שבה השגיאה הופיעה.תוכלו להשתמש במידע הזה כדי לפתור את הבעיה בקוד Java.
בדוגמה הזו, מדיניות JavaCallout נכשלה בגלל ArithmeticException (חלוקה באפס) בקובץ
JavaError.java
בשורה 25.
רזולוציה
בהתאם לחריגה שנרשמה, מתקנים את הבעיה בקובצי המקור הרלוונטיים של Java. א. בדוגמה שלמעלה, הבעיה נגרמה בגלל שגיאה אריתמטית (חלוקה באפס). עוברים לקובץ המקור ולמספר השורה הספציפיים שצוינו ב-stack trace.
ב. מכיוון שאי אפשר לבצע חלוקה באפס, כדי לפתור את הבעיה צריך להסיר את הבלוק השלם אחר שמכיל את שורת הקוד הפגומה.
מחליפים את קובץ ה-JAR הרלוונטי שמכיל את הקבצים ששונו ברמה המתאימה (שרת proxy ל-API, סביבה או ארגון) שבו הם היו קיימים בעבר.
שומרים את שרת ה-API proxy ומפרסמים אותו כרוויזיה חדשה.