עיצוב נגדי: שימוש במדיניות RaiseFault בתנאים לא הולמים

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

המדיניות של UploadFault מאפשרת למפתחי API להתחיל תהליך של שגיאה ולהגדיר משתני שגיאה בהודעה בגוף התשובה, ולהגדיר קודי סטטוס מתאימים לתגובה. אפשר גם להשתמש ב-IncreaseFault להגדיר משתני זרימה שקשורים לתקלה, כמו fault.name, fault.type, ו-fault.category. כי המשתנים האלה גלויים בנתוני ניתוח נתונים וביומני הגישה לנתבים שמשמש לניפוי באגים, חשוב לזהות את השגיאה באופן מדויק.

אפשר להשתמש במדיניות IncreaseFault כדי להתייחס לתנאים ספציפיים כאל שגיאות, גם אם קרתה שגיאה לא התרחשה במדיניות אחרת או בשרת הקצה העורפי של ה-proxy ל-API. לדוגמה, אם רוצים שרת ה-proxy לשלוח הודעת שגיאה מותאמת אישית לאפליקציית הלקוח בכל פעם שיש תגובה מהקצה העורפי הגוף מכיל את המחרוזת unavailable, ואז אפשר להפעיל את מדיניות IncreaseFault בתור שמוצגת בקטע הקוד הבא:

<!-- /antipatterns/examples/raise-fault-conditions-1.xml  -->
<TargetEndpoint name="default">
...
  <Response>
    <Step>
      <Name>RF-Service-Unavailable</Name>
      <Condition>(message.content Like "*unavailable*")</Condition>
   </Step>
  </Response>
...

השם של מדיניות IncreaseFault גלוי בתור fault.name ב- API Monitoring וגם כ-x_apigee_fault_policy ביומני הגישה ל-Analytics ולנתב. כך אפשר לאבחן בקלות את הגורם לשגיאה.

נגד דוגמת עיצוב

שימוש במדיניות liftFault ב-FaultRules אחרי שמדיניות אחרת כבר גרמה לשגיאה

נבחן את הדוגמה הבאה, שבה מדיניות OAuthV2 בתהליך ה-Proxy ל-API נכשלה עם InvalidAccessToken שגיאה. אם הפעולה תיכשל, Edge יגדיר את fault.name בתור InvalidAccessToken, ונכנס אל את זרימת השגיאה ומבצעים את כל כללי FaultRules שהוגדרו. ב-FultRule יש מדיניות IncreaseFault בשם RaiseFault ששולח תגובת שגיאה מותאמת אישית בכל פעם שמתקבלת InvalidAccessToken מתרחשת שגיאה. עם זאת, השימוש במדיניות IncreaseFault ב-FaultRule הוא fault.name. מוחלף ומוסווה את הסיבה האמיתית לכשל.

<!-- /antipatterns/examples/raise-fault-conditions-2.xml  -->
<FaultRules>
  <FaultRule name="generic_raisefault">
    <Step>
        <Name>RaiseFault</Name>
        <Condition>(fault.name equals "invalid_access_token") or (fault.name equals "InvalidAccessToken")</Condition>
    </Step>
  </FaultRule>
</FaultRules>

שימוש במדיניות IncreaseFault ב-FultRule בכל התנאים

בדוגמה הבאה, מדיניות riseFault בשם RaiseFault תופעל אם fault.name אינו RaiseFault:

<!-- /antipatterns/examples/raise-fault-conditions-3.xml  -->
<FaultRules>
    <FaultRule name="fault_rule">
        ....
        <Step>
            <Name>RaiseFault</Name>
            <Condition>!(fault.name equals "RaiseFault")</Condition>
        </Step>
    </FaultRule>
</FaultRules>

כמו בתרחיש הראשון, משתני התקלה העיקריים fault.name, fault.code, ו-fault.policy מוחלפים בשם מדיניות liftFault. לכן, כמעט בלתי אפשרי לקבוע איזו מדיניות גרמה בפועל לכשל, בלי לגשת למעקב שמציג את הכשל או משחזר את הבעיה.

שימוש במדיניות IncreaseFault כדי להחזיר תגובת HTTP 2xx מחוץ לתהליך השגיאה.

בדוגמה הבאה, מדיניות riseFault בשם HandleOptionsRequest תופעל כאשר פועל הבקשה הוא OPTIONS:

<!-- /antipatterns/examples/raise-fault-conditions-4.xml  -->
<PreFlow name="PreFlow">
    <Request>
        …
        <Step>
            <Name>HandleOptionsRequest</Name>
            <Condition>(request.verb Equals "OPTIONS")</Condition>
        </Step>
        …
</PreFlow>

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

השפעה

השימוש במדיניות IncreaseFault כפי שמתואר למעלה יוביל להחלפת משתני השגיאה העיקריים השם של מדיניות IncreaseFault במקום השם של המדיניות שנכשלו. ביומנים של Analytics ו-NGINX Access, המשתנים x_apigee_fault_code ו-x_apigee_fault_policy מוחלפים. ב-API Monitoring, הפונקציה Fault Code ו-Fault Policy מוחלפים. התנהגות כזו מקשה על פתרון בעיות לקבוע איזו מדיניות היא הסיבה האמיתית לכשל.

בצילום המסך שלמטה מ-API Monitoring, ניתן לראות שהמדיניות 'קוד שגיאה' ו'קוד שגיאה' הוחלפה למדיניות הכללית של RaiseFault ולכן לא ניתן לקבוע ביומנים את שורש הבעיה לכשל:

שיטה מומלצת

אם מדיניות של Edge מעלה תקלה ואתם רוצים להתאים אישית את הודעת השגיאה, להשתמש במדיניות AssignMessage או JavaScript במקום במדיניות IncreaseFault.

יש להשתמש במדיניות IncreaseFault בתהליך שאינו שגיאות. כלומר, צריך להשתמש רק ב-Fault לטיפול ברמה גבוהה יותר בתור שגיאה, גם אם לא אירעה שגיאה בפועל במדיניות או בשרת העורפי. של ה-API Proxy. לדוגמה, אפשר להשתמש במדיניות IncreaseFault כדי לציין שקלט החובה חסרים פרמטרים או שהתחביר שלהם שגוי.

אפשר גם להשתמש ב-IncreaseFault בכלל שגיאה אם רוצים לזהות שגיאה במהלך העיבוד טעות. לדוגמה, המטפל בתקלה עצמו עלול לגרום לשגיאה שאתם רוצים לאותת באמצעות UploadFault.

קריאה נוספת

• טיפול בתקלות
• מדיניות LiftFault
• דיון בקהילה בנושא דפוסי טיפול בתקלות