פתרון בעיות של שגיאות בזמן ריצה במדיניות JavaCallout

אתם צופים במסמכי התיעוד של Apigee ושל Apigee Hybrid.
לעיון במסמכי התיעוד של Apigee Edge.

ExecutionError

קוד שגיאה

steps.javacallout.ExecutionError

גוף התשובה לשגיאה

{
  "fault": {
    "faultstring": "Execution returned an error result",
    "detail": {
      "errorcode": "flow.execution.ExecutionReturnedFailure"
    }
  }
}

מטרה

השגיאה הזו מתרחשת אם קוד Java יוצר חריגה או מחזיר null במהלך ההפעלה של מדיניות JavaCallout.

אבחון

  1. מפעילים סשן מעקב כדי לתעד את השגיאה ולזהות איזו מדיניות JavaCallout נכשלה.

  2. בודקים את מדיניות JavaCallout ואת המשאב שבו נעשה שימוש. בדוגמה שלמעלה, JavaCallout policy משתמש במשאב בשם hello.jar, כמו שמוצג בהמשך:

    <JavaCallout name="hello-java">
   <ClassName>com.apigeesample.HelloJava</ClassName>
   <ResourceURL>java://hello.jar</ResourceURL>
</JavaCallout>

  3. כדי לתעד ולאחסן את חריגת ה-Java במשתנה של זרימת הנתונים, צריך לשנות את קוד המקור, כמו שמתואר במאמר טיפול בשגיאות במדיניות JavaCallout.

  4. קומפילציה והחלפה של המשאב המושפע (קובץ JAR) בפריט מידע מעודכן של Java.

  5. פורסים את ה-API Proxy כגרסה חדשה ומבצעים את הקריאה ל-API.

  6. מתחילים סשן מעקב נוסף.

  7. שימו לב שהמשתנה JAVA_STACKTRACE מכיל את פרטי ה-stack trace. בדוח קריסות מפורטים החריגה בפועל, קובץ המקור של Java ומספר השורה שבה השגיאה מופעלת.

  8. אפשר להשתמש במידע הזה כדי לפתור את הבעיה בקוד Java.

  9. בדוגמה הזו, המדיניות JavaCallout נכשלה בגלל ArithmeticException (חלוקה באפס) בקובץ JavaError.java בשורה ‎ #25.

רזולוציה

  1. בהתאם לחריגה שנוצרה, פותרים את הבעיה בקובץ או בקבצים הרלוונטיים של מקור Java. א. בדוגמה שלמעלה, הבעיה נגרמה בגלל שגיאה אריתמטית (חלוקה באפס). עוברים לקובץ המקור הספציפי ולמספר השורה שמצוינים בדוח קריסות.

    ב. מכיוון שאי אפשר לחלק באפס, כדי לפתור את הבעיה צריך להסיר את כל בלוק ה-else שמכיל את שורת הקוד הפגומה.

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

  3. שומרים את ה-proxy ל-API ומפרסמים אותו כגרסה חדשה.