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

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

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

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

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

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

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

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

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

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

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

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

פיתוח תהליך עבודה משותף

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

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

  1. מגדירים מה יהיה הסט המשותף של התכונות.

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

  2. מפתחים זרימה משותפת על ידי הטמעה של מדיניות ומשאבים תומכים, בדיוק כמו שמפתחים 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. בדוגמה הבאה אפשר לראות איך מייבאים Shared Flow באמצעות 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. פורסים את התהליך המשותף בסביבה לפני שפורסים פרוקסי או תהליכים משותפים שישתמשו בו. פריסת רכיב Shared Flow מתבצעת באותו אופן שבו פורסים שרת proxy ל-API. (מידע נוסף זמין במאמר סקירה כללית על פריסה).

    הזרימה המשותפת צריכה להיות באותו ארגון ולהיפרס באותה סביבה כמו שרתי ה-proxy של ה-API וזרימות משותפות אחרות שמשתמשות בה. פריסת הזרימה המשותפת לפני שרתי ה-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. (אפשר גם לצרף את ה-Shared Flow לשרת ה-proxy באמצעות flow hook).

    כדי להשתמש בתהליך משותף, מוסיפים מדיניות FlowCallout לשרת ה-proxy או לתהליך המשותף שבו רוצים להשתמש. בדומה למדיניות Service Callout שמאפשרת לקרוא לשירות אחר, מדיניות FlowCallout קוראת לזרימה המשותפת. צריך לפרוס את ה-proxy ל-API שמשתמש בזרימת הנתונים המשותפת אחרי זרימת הנתונים המשותפת, ובאותו סביבה שבה פרוסה זרימת הנתונים המשותפת. תהליך משותף צריך להיות מוגדר כשרוצים לבדוק קריאה אליו באמצעות המדיניות 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>

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

  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 ל-shared flow. (מידע נוסף על ניפוי באגים זמין במאמר כלי לניפוי באגים).

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

כשמשתמשים ב-Apigee API כדי ליצור Shared Flow, אפשר ליצור אותו מאפס או לייבא מקורות קיימים של Flow כקובץ ZIP של חבילת Flow.

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

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

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

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

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

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

  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. לוחצים על לצד שמירה ואז על שמירת הגרסה החדשה.

ראו בנוסף

שרשור של שרתי proxy ל-API