שליטה באופן שבו שרת proxy פועל באמצעות זרימה

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

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

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

הדוגמה הבאה של הגדרת זרימה מגדירה זרימה שבה מדיניות VerifyAPIKey מתבצע אם נתיב הבקשה הנכנסת מסתיים ב-/ וב-HTTP של הבקשה הפונקציה היא GET.

<Flow name="Get Food Carts">
    <Description>Get Food Carts</Description>
    <Request>
        <Step>
            <Name>Verify-API-Key</Name>
        </Step>
    </Request>
    <Condition>(proxy.pathsuffix MatchesPath "/") and (request.verb = "GET")</Condition>
</Flow>

הערך Verify-API-Key ברכיב <Name> של הזרימה מציג כדי לכלול מדיניות שהוגדרה במקום אחר בשרת ה-proxy באמצעות XML, למשל:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VerifyAPIKey async="false" continueOnError="false" enabled="true" name="Verify-API-Key">
    <DisplayName>Verify API Key</DisplayName>
    <Properties/>
    <APIKey ref="request.header.x-api-key"/>
</VerifyAPIKey>

עיצוב רצף ביצוע של תהליכים

הבנייה של האתר מתבצעת כך שהלוגיקה תוכל לפעול ברצף הנכון לאורך עיבוד נתונים.

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

שתי נקודות הקצה מכילות תהליכים, כפי שמתואר כאן:

אתם מגדירים תהליך באמצעות XML שמציין מה צריך לקרות ובאיזה סדר. הבאים איור שמראה איך תהליכי העבודה מסודרים ברצף בתוך נקודת קצה ויעד של שרת proxy נקודת קצה (endpoint):

גם נקודת הקצה (endpoint) של שרת ה-Proxy ונקודת הקצה (endpoint) של היעד מכילות תהליכים שניתן לארגן הרצף הבא:

הפעלת הקוד ראשונה עם PreFlow

PreFlow היא שימושית כשצריך לוודא שקוד מסוים פועל לפני כל דבר אחר קורה.

בנקודת קצה של שרת proxy, PreFlow הוא מקום מצוין לקוד שמאמת לקוח מגביל את התנועה מהלקוחות. בנקודת קצה (endpoint) יעד, שבה הוא מתחיל לשלוח בקשה יעד עורפי, PreFlow מתאימה לשלבים הראשונים בהכנה לשליחת הבקשה.

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

בדוגמה הבאה, כללי המדיניות SpikeArrest ו-Quota מופעלים לפני שהעיבוד מועבר אל וזרימה מותנית.

<PreFlow name="MyPreFlow">
    <Request>
        <Step>
            <Name>Spike-Arrest</Name>
        </Step>
        <Step>
            <Name>Quota</Name>
        </Step>
    </Request>
    <Response/>
</PreFlow>

לאחר את הקוד, באופן מותנה, באמצעות זרימה מותנית

בין PreFlow לבין PostFlow, תוכלו ליצור תהליכים שמופעלים באופן מותנה. הפעולה הזאת נותנת יש הזדמנות להגדיר כמה רצפים של לוגיקה, אבל להפעיל רק הרצה אחת במצב של שרת ה-proxy. זרם מותנה הוא אופציונלי אם ניתן להפעיל את כל הלוגיקה ב-PreFlow או אין צורך בתנאים כלשהם ב-PostFlow (במילים אחרות, רק נתיב אחד דרך נקודת הקצה נתמך).

כל זרימה הזו מציינת תנאי שבודק ערכי מצב שונים. כך ביצוע הסתעפויות על סמך תנאים. לדוגמה, יכול להיות שתרצו להמיר XML ל-JSON בלבד כשהאפליקציה ששלחה את הבקשה פועלת במכשיר נייד.

כאן, מגבלות מכסה נאכפות רק אם הבקשה היא בקשת GET עם דפוס URI של /issue/** (/issue/ עם כל דבר ב-URI אחרי ההעברה האחרונה) קו נטוי).

<Flow name="MyFlow">
    <Description/>
    <Request>
        <Step>
            <Name>Quota</Name>
        </Step>
    </Request>
    <Response/>
    <Condition>(proxy.pathsuffix MatchesPath "/issue/**") and (request.verb = "GET")</Condition>
</Flow>

משתמשים במשתני זרימה כדי לציין תנאים. למידע נוסף על השימוש במשתנים בתנאים, למידע נוסף, כדאי לעיין בקטע תנאים עם משתני זרימה.

במאמר התאמת דפוסים תוכלו לראות דוגמאות לשימוש בהתאמת דפוסים בתנאים.

קבלת קוד מופעל אחרי לוגיקת ליבה באמצעות PostFlow

PostFlow הוא מקום מצוין לבצע פעולות אחרי הלוגיקה הבסיסית של נקודת הקצה ולפני העיבוד של נקודות הקצה הסתיים. PostFlow מופעל אחרי זרימה מותנית ו-PreFlow.

PostFlow הוא מקום טוב לרשום בו נתונים, לשלוח התראה שמשהו קרה. תשנה את הפורמט של הודעת התשובה וכו'.

בדוגמה הבאה, מדיניות AssignMessage בשם SetResponseHeaders מגדירה כותרות של את הודעת התשובה לפני ש-Apigee Edge שולח את התשובה חזרה ללקוח.

<PostFlow>
    <Response>
        <Step>
            <Name>SetResponseHeaders</Name>
        </Step>
    </Response>
 </PostFlow>

הפעלת קוד לאחר שהלקוח מקבל את תגובת ה-proxy באמצעות PostClientFlow

PostClientFlow יכול לכלול את כללי המדיניות הבאים:

• המדיניות בנושא תוספי יתרונות מרכזיים
• המדיניות שלFlowCallout^*
• המדיניות של MessageLogging
• המדיניות בנושא ServiceCallout

^* המדיניות בנושא בקשות להצעת מחיר בזרימה יכולה להפעיל רק תהליכים משותפים שעומדים בדרישות קריטריונים להיכלל ב-PostClientFlow (כלומר, להכיל רק מדיניות תואמת).

אם תכללו אחד, PostClientFlow יהיה התהליך האחרון להפעלה, שיבוצע אחרי נשלחת ללקוח.

A PostClientFlow מתאים לרישום סופי ביומן. בנוסף, אתם יכולים לתעד את חותמות הזמן של ההתחלה והסיום של הודעת התשובה.

זאת דוגמה ל-PostClientFlow עם מדיניות MessageLogging.

    ...
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <PostClientFlow>
        <Request/>
        <Response>
            <Step>
                <Name>Message-Logging-1</Name>
            </Step>
        </Response>
    </PostClientFlow>
    ...

מידע נוסף זמין בדפים הבאים:

• חומר עזר בנושא הגדרה של שרת proxy ל-API
• מדריך : מאמר בקהילה של Apigee Edge – זרימה של לקוח פוסט

הוספת לוגיקה לתהליכים

כאשר מוסיפים לוגיקה לשרת ה-proxy, ניתן לעשות זאת על ידי הוספת מדיניות לתהליכים של שרת ה-proxy. בדיוק כמו יועברו ברצף (PreFlow ואז PostFlow ,ואז PostFlow, כמתואר בנושא זה), של רצף שרץ ברצף.

תצורת הזרימה הבאה לדוגמה מתייחסת לשלושה כללי מדיניות (שהוגדרו במקום אחר ב- קובצי XML משלהם). המדיניות שאליה מפנה Verify-API-Key תופעל לפני המדיניות שאליה מפנה Remove-API-Key; והמדיניות שמיוצגת על ידי Quota.

<Flow name="Get Food Cart Menus">
    <Description>Get Food Cart Menus</Description>
    <Request>
        <Step>
            <Name>Verify-API-Key</Name>
        </Step>
        <Step>
            <Name>Remove-API-Key</Name>
        </Step>
        <Step>
            <Name>Quota</Name>
        </Step>
    </Request>
    <Condition>(proxy.pathsuffix MatchesPath "/") and (request.verb = "GET")</Condition>
</Flow>

מסוף Apigee Edge מציג את רצף כללי המדיניות הזה כשורה של סמלים שבהם כל סמל שמייצג את המדיניות.

תהליכי ניפוי באגים

הכלי Apigee Edge Trace מספק דרך גרפית לראות איך הלוגיקה בשרת ה-proxy ל-API מבצע את הפעולה לפי בקשה. הכלי מדגים את העיבוד בין הבקשה לבין התגובה. הוא לא ממחישה באופן ספציפי את ההפרדה בין PreFlow, flows מותנים ו- PostFlow.

למידע נוסף על מעקב אחר שרתי proxy, ראו שימוש בכלי המעקב.

טיפול בשגיאות בתהליכים

אפשר להעלות שגיאות ממקומות שונים בשרת proxy ל-API, כולל מתהליכים.

הדוגמה הבאה היא שיר התגובה מ-PreFlow בנקודת קצה של יעד – הוא הקוד שמופעל מיד לאחר קבלת התגובה מיעד בקצה העורפי. בדוגמה הזו, יש שגיאה אם התגובה מהיעד היא לא 200 (הצלחה).

<PreFlow name="PreFlow">
    <Response>
        <Step>
            <Name>RaiseFault</Name>
            <Condition>(response.status.code GreaterThan "200")</Condition>
        </Step>
    </Response>
</PreFlow>

מידע נוסף על טיפול בשגיאות זמין במאמר טיפול בתקלות.