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

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

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

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

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

בסרטון הבא שאורכו 5 דקות מוצגות הוראות ליצירה ולמעקב של זרימת נתונים משותפת בממשק המשתמש של Edge בגרסה הקלאסית (Edge לענן פרטי בלבד).

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

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

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

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

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

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

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

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

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

    curl -X POST -F "file=@/path/to/zip/file.zip" \ 'https://api.enterprise.apigee.com/v1/o/{org_name}/sharedflows?action=import&name=shared-flow-name' \
-u email:password
  3. פורסים את התהליך המשותף בסביבה לפני שפורסים פרוקסי או תהליכים משותפים שישתמשו בו. פריסת תהליך משותף מתבצעת באותו אופן שבו פורסים proxy ל-API. (מידע נוסף זמין במאמר סקירה כללית על פריסה).

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

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

    curl -X POST --header "Content-Type: application/octet-stream" \
https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/sharedflows/{shared_flow_name}/revisions/{revision_number}/deployments \
-u email:password

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

    curl -X POST --header "Content-Type:application/x-www-form-urlencoded" \
https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/sharedflows/{shared_flow_name}/revisions/{revision_number}/deployments?"override=true" \
-u email:password
  4. מפתחים את ה-proxy ל-API שמשתמש בתהליך המשותף כדי שיוכל לקרוא לתהליך המשותף כחלק מהתהליך שלו.

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

    כדי להשתמש בתהליך משותף, מוסיפים מדיניות 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.

    אלה השלבים:

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

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

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

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

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

    Edge

    כדי לגשת לדף Shared Flows (תהליכים משותפים) באמצעות ממשק המשתמש של Edge:

    1. נכנסים לחשבון בכתובת apigee.com/edge.
    2. בוחרים את הארגון שמכיל את התהליך המשותף. אפשר לקרוא על כך במאמר מעבר בין הארגונים.

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

    3. בסרגל הניווט הימני, בוחרים באפשרות פיתוח > תהליכים משותפים.

    ‫Classic Edge (ענן פרטי)

    כדי לגשת לדף 'זרימות משותפות' באמצעות ממשק המשתמש הקלאסי של Edge:

    1. מתחברים אל http://ms-ip:9000, כאשר ms-ip היא כתובת ה-IP או שם ה-DNS של צומת שרת הניהול.
    2. בוחרים את הארגון שמכיל את התהליך המשותף. אפשר לקרוא על כך במאמר מעבר בין הארגונים.

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

    3. בסרגל הניווט העליון, בוחרים באפשרות APIs > Shared Flows (ממשקי API > תהליכים משותפים).
  2. לוחצים על הלחצן + Shared Flow כדי להתחיל להוסיף זרימה משותפת חדשה.
  3. בדף Build a Shared Flow (יצירת רכיב Shared Flow), בוחרים איך ליצור את הרכיב החדש:
    • יוצרים תהליך חדש מאפס. תוכלו להגדיר מדיניות ומשאבים כשלבים בתהליך.
      1. בוחרים באפשרות Empty Shared Flow (ריקון הזרימה המשותפת).
      2. מזינים ערך לשם. זה יהיה השם שבו משתמשים שרתי proxy של API ורכיבי Shared Flow אחרים כדי להפנות אל רכיב ה-Shared Flow הזה. השם צריך להיות תיאורי כדי שמפתחים יוכלו להבין את התהליך.
      3. מזינים תיאור כדי לספק מידע נוסף על הפעולות שמתבצעות בתהליך.
      4. לוחצים על הבא.
      5. אפשר גם לבחור את הסביבות שבהן רוצים לפרוס את התהליך החדש.

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

      6. לוחצים על Build and Deploy(בנייה ופריסה) כדי ליצור את התהליך המשותף החדש ולפרוס אותו בסביבות שבחרתם. אם לא בחרתם סביבה, התהליך המשותף ייצור, אבל לא יופעל.

    • כדי ליצור תהליך משותף ממקורות קיימים, מעלים חבילת תהליכים.
      1. בוחרים באפשרות Shared Flow Bundle כדי לציין קובץ ZIP שמכיל את הארטיפקטים שרוצים לכלול בתהליך החדש.

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

      2. לוחצים על הבא.
      3. לוחצים על Choose File (בחירת קובץ) כדי לעיין בקובץ ה-ZIP שמכיל את מקורות הזרימה המשותפים שרוצים לייבא.
      4. בתיבה שם התהליך המשותף, מזינים שם לתהליך המיובא. זה יהיה השם שבו משתמשים ב-API proxy ובזרימות משותפות אחרות כדי להפנות לזרימה המשותפת הזו. השם צריך להיות תיאורי כדי שמפתחים יוכלו להבין את התהליך.
      5. לוחצים על הבא.
      6. לוחצים על יצירה כדי ליצור את התהליך החדש ממקורות הנתונים שמייבאים.

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

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

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

ראה גם

Chaining API proxies together