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

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

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 במשתנה של זרימת נתונים, צריך לשנות את קוד המקור, כמו שמתואר במאמר טיפול בשגיאות ב-Java Callout.

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

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

  6. מתחילים סשן חדש של מעקב.

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

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

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

רזולוציה

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

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

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

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