יצירת תהליכים משותפים לשימוש חוזר

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

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

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

בסרטון הבא אנחנו מדגימים איך ליצור ולנפות באגים בזרימת נתונים משותפת בממשק המשתמש של Apigee.

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

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

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

  • אבטחה, עם קוד הרשאה באמצעות OAuth ואימות מפתח API, וגם קוד להגנה מפני איומים.
  • רישום ביומן, ליצירת הודעות שגיאה סטנדרטיות.
  • גישור, להמרה בין פורמטים של הודעות XML ו-JSON.

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

תרשים זרימה שבו רואים את המדיניות POST /foodcarts עוברת למדיניות POST /menus ואז ל-AuthSharedFlow. טקסט היתרון המרכזי: ‫a) כמה שרתי proxy ל-API צורכים תהליך משותף באמצעות FlowCallouts. ‫ב) מדיניות FlowCallout מבצעת קריאות משרתי proxy ל-API ל-תהליך משותף. ‫ג) חבילת Shared flow מכילה לוגיקה לשימוש חוזר בצורת מדיניות ומשאבים.

פיתוח תהליך משותף

כשמפתחים תהליך משותף, תמיד צריך לבדוק אותו באמצעות קריאות שנשלחות ל-proxy ל-API. In other words, you can't send requests directly to a shared flow as you would an API proxy. במקום זאת, שולחים בקשות ל-proxy ל-API, שבתורו קורא לתהליך משותף.

אלה השלבים הכלליים לפיתוח של זרימת נתונים משותפת:

  1. להבין מה צריך להיות המאפיינים המשותפים.

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

  2. מפתחים תהליך משותף על ידי הטמעה של מדיניות ומשאבים תומכים, בדיוק כמו שמפתחים proxy ל-API.

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

    לדוגמה, במסגרת התמיכה בניהול התנועה, אפשר להטמיע מדיניות של Spike Arrest כדי לאפשר רק 30 בקשות בשנייה, כמו בדוגמה הבאה:

    <SpikeArrest async="false" continueOnError="false" enabled="true" name="Spike-Arrest">
    <DisplayName>Spike Arrest</DisplayName>
    <Properties/>
    <Identifier ref="request.header.some-header-name"/>
    <MessageWeight ref="request.header.weight"/>
    <Rate>30ps</Rate>
</SpikeArrest>

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

    <SharedFlow name="default">
    <Step>
        <Name>Spike-Arrest</Name>
    </Step>
</SharedFlow>

    מידע על הפעלת תהליך משותף במסוף הניהול זמין במאמר בנושא יצירת תהליך משותף בממשק המשתמש של Apigee.

    בדומה לשרתי proxy ל-API, אפשר לייבא קובץ ZIP שמכיל את ארטיפקטים של מקור זרימת הנתונים המשותפת באמצעות Create shared flow API. בדוגמה הבאה מוסבר איך לייבא תהליך משותף באמצעות Apigee API:

    curl "https://apigee.googleapis.com/v1/organizations/$ORG/sharedflows?action=import&name=mySharedFlow" \
  -X POST \
  -F "file=@sharedflow.zip" \
  -H "Authorization: Bearer $TOKEN"

    ‫$TOKEN מוגדר כאסימון הגישה מסוג OAuth 2.0, כפי שמתואר במאמר איך מקבלים אסימון גישה מסוג OAuth 2.0. מידע על האפשרויות curl שבהן נעשה שימוש בדוגמה הזו מופיע במאמר שימוש ב-curl. תיאור של משתני הסביבה שבהם אפשר להשתמש מופיע במאמר בנושא הגדרת משתני סביבה לבקשות API של Apigee.

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

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

    אפשר לפרוס תהליך משותף באמצעות קריאה ל-API של Apigee, כמו הקריאה הבאה:

    curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/sharedflows/$SHAREDFLOW/revisions/$REV/deployments \
  -X POST \
  -H "Authorization: Bearer $TOKEN"

    בדומה לשרתי proxy של API, כל הפריסות המוצלחות של תהליכים משותפים ב-Apigee הן פריסות ללא השבתה.

  4. מפתחים את ה-proxy ל-API שמשתמש בתהליך המשותף כדי שיוכל לקרוא לתהליך המשותף כחלק מהתהליך שלו.

    משרת proxy ל-API, קוראים לתהליך משותף באמצעות מדיניות FlowCallout. (אפשר גם לצרף את התהליך המשותף לשרת ה-proxy באמצעות flow hook).

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

    בדוגמת הקוד הבאה, מדיניות FlowCallout קוראת לזרימה משותפת בשם traffic-management-shared.

    <FlowCallout async="false" continueOnError="false" enabled="true" name="Traffic-Management-Flow-Callout">
    <DisplayName>Traffic Management FlowCallout</DisplayName>
    <Properties/>
    <SharedFlowBundle>traffic-management-shared</SharedFlowBundle>
</FlowCallout>

    מידע נוסף זמין במאמר בנושא קריאה לתהליך משותף מ-proxy ל-API או מתהליך משותף.

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

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

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

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

יצירת תהליך משותף בממשק המשתמש של Apigee

כשמשתמשים ב-Apigee API כדי ליצור זרימה משותפת, אפשר ליצור אותה מאפס או לייבא מקורות קיימים של זרימה כקובץ zip של חבילת זרימה.

נכנסים לדף Shared Flows (תזרימי נתונים משותפים), כמו שמתואר בהמשך. בדף Shared Flows, תוכלו לראות רשימה של זרימות משותפות בארגון, ולערוך או למחוק זרימות מהרשימה.

כדי ליצור תהליך משותף בממשק המשתמש של Apigee:

  1. במסוף Google Cloud , נכנסים לדף Apigee > Proxy development > Shared flows.

    מעבר לתהליכי עבודה משותפים

  2. בוחרים את הארגון שמכיל את התהליך המשותף. מידע נוסף זמין במאמר בנושא מעבר בין הארגונים.

    ה-Flow המשותף יהיה זמין לכל שרתי ה-proxy של ה-API ולכל ה-Flows המשותפים שנפרסו בסביבה מהארגון הזה. הוא לא יהיה זמין מחוץ לארגון הזה.

  3. יוצרים או מעלים זרימה משותפת:
    • לוחצים על יצירה כדי ליצור תהליך חדש מאפס. תוכלו להגדיר מדיניות ומשאבים כשלבים בתהליך.

      מוצגת תיבת הדו-שיח Create a Shared Flow (יצירת רכיב Shared Flow).

      1. מזינים את השם של התהליך המשותף.

        זה יהיה השם שבו משתמשים שרתי proxy של API ורכיבי Shared Flow אחרים כדי להפנות אל רכיב ה-Shared Flow הזה. השם צריך להיות תיאורי כדי שמפתחים יוכלו להבין את התהליך.

      2. מזינים תיאור כדי לספק מידע נוסף על הפעולות בתהליך.
      3. אם הארגון שלכם הפעיל את Apigee Spaces, תוכלו לשייך את הרכיב Shared Flow למרחב שנבחר מתוך רשימת האפשרויות הזמינות. מידע נוסף מופיע במאמר סקירה כללית על Apigee Spaces.
      4. לוחצים על יצירה.

        הזרימה המשותפת נוצרת.

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

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

      מוצגת תיבת הדו-שיח Create a Shared Flow (יצירת רכיב Shared Flow).

      1. בוחרים את קובץ ה-ZIP שמכיל את הארטיפקטים שרוצים להוסיף לתהליך החדש.
      2. לוחצים על פתיחה.
      3. מזינים שם לזרימת הנתונים המשותפת שיובאה.

        זה יהיה השם שבו משתמשים ב-API proxies ובזרימות משותפות אחרות כדי להתייחס לזרימה המשותפת הזו. השם צריך להיות תיאורי כדי שמפתחים שמשתמשים בתהליך יוכלו להבין אותו.

      4. לוחצים על יצירה.

        התהליך המשותף נוצר מהחבילה.

      5. לאחר מכן, אפשר לפתח את התכונות של התהליך המשותף ולפרוס אותו בסביבה הרצויה.

קריאה לתהליך משותף מ-proxy ל-API או מתהליך משותף

אפשר לקרוא לתהליך משותף מ-Proxy או מתהליך משותף אחר באמצעות מדיניות FlowCallout.

  1. מבצעים אחת מהפעולות הבאות:
  2. לוחצים על השם של ה-proxy או של התהליך המשותף שרוצים לשנות.
  3. לוחצים על הכרטיסייה פיתוח.
  4. בחלונית הניווט, לצד Policies (מדיניות), לוחצים על .
  5. ברשימת כללי המדיניות, בקטע Extension, בוחרים באפשרות FlowCallout.
  6. מזינים את השם המוצג ואת השם (מזהה ייחודי), ואז בוחרים את התהליך המשותף שהמדיניות הזו תקרא לו.
  7. לוחצים על יצירה.
  8. לוחצים על לצד שמירה ואז על שמירת הגרסה החדשה.

מידע נוסף

Chaining API proxies together