אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info
ארגון הוא המאגר ברמה העליונה ב-Apigee Edge. הוא מכיל את כל שרת ה-proxy של ה-API ואת המשאבים הקשורים. בהמשך הנושא נסביר בהרחבה על ארגונים, אבל ריכזנו כאן כמה נקודות מעשיות:
- כברירת מחדל, שם הארגון מופיע בכתובת ה-URL שמשמש לקריאה לשרתי ה-proxy של ה-API, כפי שמתואר בקטע מידע על מארחים וירטואליים.
לדוגמה:
http(s)://your_org_name-environment.apigee.net/proxy_base_path/...
- שם הארגון מופיע בכתובת ה-URL של ממשק המשתמש לניהול Edge. לדוגמה, בכתובת ה-URL הבאה מוצגים שרתי ה-proxy ל-API של הארגון
docs:
- יכול להיות שיצרתם רק ארגון אחד, אבל אתם יכולים להשתייך לארגונים אחרים בתור משתמשים או אדמינים עם הרשאות ספציפיות. בממשק המשתמש לניהול ב-Edge, אם אתם משתייכים למספר ארגונים, תוכלו לעבור לארגון אחר כפי שמתואר בקטע מעבר בין ארגונים.
- כשמתקשרים באמצעות ה-Management API כמשתמש בתפקיד 'אדמין ארגוני', הארגון הוא חלק חיוני מהנתיב ברוב הקריאות. לדוגמה, בקשת ה-cURL הבאה של API הניהול מחזירה רשימה של כל שרת ה-proxy של ה-API בארגון:
curl https://api.enterprise.apigee.com/v1/organizations/your_org_name/apis -u org_admin_email_address
סרטון: כאן מוסבר איך ארגונים תומכים בארכיטקטורה של ריבוי דיירים לצורך ניהול API.
רכיבי הארגון
כשיוצרים חשבון Edge, המערכת יוצרת עבורכם ארגון באופן אוטומטי. אחרי היצירה, אפשר להוסיף משתמשים לארגון, ליצור שרתי proxy ל-API ומוצרי API ולרשום מפתחים ואפליקציות.
בתמונה הבאה מוצגים הרכיבים העיקריים של מודל הארגון של Edge. המודל הזה מגדיר את הקשר בין ממשקי ה-API, מוצרי ה-API, האפליקציות ומפתחי האפליקציות ב-Edge.
המודל הזה לא מציג את כל התכונות של Apigee Edge. אם משתמשים במונטיזציה, למודל יהיו רכיבים נוספים. מידע נוסף זמין במאמר סקירה כללית בנושא מונטיזציה. למידע על ניהול חברות ומפתחים עם מונטיזציה, אפשר לעיין במאמר ניהול חברות ומפתחים.
שמות הארגונים
שם הארגון הוא:
- הארגון שמבצע את ההערכה:
username-eval - ארגון בתשלום: מוגדר על ידי המשתמש בזמן ההקצאה הראשונית
אי אפשר לשנות את השם של הארגון אחרי היצירה שלו.
כששולחים בקשה ל-Edge management API, שם הארגון הופך לחלק מכתובת ה-URL לשרתי ה-proxy ל-API. לדוגמה, כתובת URL רגילה שמשמשת לגישה ל-proxy של API היא:
http://org-name-env.apigee.net/v1/weather/forecastrss
כאשר:
- org-name הוא שם הארגון.
- env היא סביבת הפריסה של שרת ה-proxy ל-API, והיא יכולה להיות test או prod.
לדוגמה:
http://myorg-test.apigee.net/v1/weather/forecastrss
רכיבי הארגון
בטבלה הבאה מתוארים רכיבי המודל הארגוני בפירוט רב יותר:
| רכיב | תיאור |
|---|---|
|
ארגון |
כל חשבון Apigee ממופה לארגון אחד או יותר ב-Apigee Edge. הארגון מכיל ייצוג של כל הרכיבים, כולל שרתי proxy ל-API, מוצרי API, חבילות API, אפליקציות ומפתחים. בעלי החשבון לא מוגבלים לארגון אחד. חלק מבעלי החשבונות עשויים להגדיר כמה ארגונים שתומכים בקהילות שונות של מפתחי אפליקציות, או להיות חברים בכמה ארגונים כאלה. |
| סביבה | הקשר של ביצוע בזמן ריצה לשרתי proxy ל-API בארגון. מידע נוסף על סביבות מופיע בקטע שבהמשך. |
|
משתמש |
בארגון שבו האדם שיוצר את החשבון מוגדר אוטומטית כאדמין, אפשר ליצור משתמשים נוספים. המשתמשים הם חברי צוות ה-API של הארגון, שיכול לכלול אדמינים, יוצרים של מוצרים ושרתי proxy של ממשקי API, משתמשים שמנטרים ניתוח נתונים ונתונים סטטיסטיים אחרים ועוד. למשתמשים שונים יכולים להיות תפקידים והרשאות גישה שונים. לדוגמה, אפשר להגדיר משתמשים מסוימים כאדמינים ארגוניים ומנהלי תפעול עם הרשאות לשינוי הארגון והרכיבים שלו. מגדירים משתמשים אחרים עם הרשאות ליצור שרתי proxy ל-API ומוצרי API, אבל בלי ההרשאות לשנות משתמשים אחרים. המשתמשים יכולים להיות חברים במספר ארגונים. לדוגמה, יכול להיות שהחברה שלכם תגדיר כמה ארגונים ב-Apigee Edge כדי לתמוך בקהילות שונות של מפתחים. עם זאת, מבפנים, אותם אנשים יוצרים את כל שרתי ה-proxy ל-API ואת כל מוצרי ה-API, ולכן הם חברים בכל הארגונים שלכם. אתם לא צריכים ליצור חשבון ב-Apigee – כלומר ליצור ארגון ב-Apigee – כדי להשתמש. אדמין יכול להוסיף אותך לארגון קיים. כל המשתמשים מתחברים ל-Apigee Edge כאן: https://enterprise.apigee.com. |
|
API מסוג proxy |
המשתמשים בארגון יוצרים שרת proxy אחד או יותר של API. שרת proxy של API מגדיר מיפוי של נקודת קצה (endpoint) של HTTP שזמינה לכולם לשירות לקצה העורפי. אפשר גם להגדיר ששרתי proxy של API יכללו אבטחה (כמו OAuth), יבצעו טרנספורמציה של הודעות (כמו XML ל-JSON), יגבילו את התנועה לשירותים לקצה העורפי ויבצעו פעולות חשובות אחרות בבקשה, בתגובה ובקריאות לשירותים. Edge אוסף נתונים לצורך ניתוח נתונים בשרתי proxy ל-API. |
|
מוצר API |
המשתמשים בארגון יוצרים מוצר API אחד או יותר, כאשר מוצר API הוא חבילה של שרתי proxy ל-API בשילוב עם חבילת שירות. תוכנית השירות הזו יכולה להגדיר מגבלות גישה על שרתים proxy של API, לספק אבטחה, לאפשר מעקב וניתוח נתונים ולספק תכונות נוספות. Edge אוסף נתונים לצורך ניתוח נתונים של מוצרים עם ממשקי API. |
|
מפתח |
ארגון מכיל מפתח אחד או יותר שמפתחים את האפליקציות שמשתמשות בממשקי ה-API (שמורכבים למוצרי API) שהוגדרו על ידי הארגון. מפתחים צורכים ממשקי API, אבל לא יכולים ליצור ממשקי API או לבצע פעולות אחרות בארגון. המפתחים יכולים להיות עובדים פנימיים בחברה, שותפים או מפתחים חיצוניים שמשלמים על גישה לממשקי ה-API שלכם. כדי שהמפתחים יוכלו לרשום אפליקציה ולקבל מפתח API לגישה לממשקי ה-API שלכם, הם צריכים להיות רשומים בארגון. בתור ספקי API, אתם קובעים איך להוסיף, לעדכן או להסיר מפתחים בארגון. אפשר להוסיף אותם באופן ידני דרך ממשק המשתמש לניהול של Edge, ליצור פורטל למפתחים כדי לרשום אותם דרך אתר או להגדיר מנגנון רישום משלכם באמצעות Edge Management API. למפתחים אין צורך בחשבון ב-Edge, ורוב המפתחים לא יצטרכו לדעת דבר על Edge. אם למפתח יש חשבון ב-Edge, בדרך כלל הוא משמש כמשתמש בארגון אחר או לשימוש בשירותי Edge API. |
|
אפליקציה |
מפתחים יוצרים אפליקציית לקוח אחת או יותר שמשתמשות בממשקי ה-API שלכם. המפתחים צריכים לרשום את האפליקציות שלהם בארגון. אפליקציה ב-Edge היא ייצוג של האפליקציה בפועל של המפתח, שמספקת למפתח מפתח API שצריך להעביר עם כל בקשה לממשקי ה-API שלכם. מאחר שכל האפליקציות רשומות בארגון, אפשר להשתמש ב-Edge כדי לעקוב אחרי האפליקציה ולאסוף מידע אנליטי עליה ועל השימוש שלה בממשקי ה-API שלכם. |
|
מפתח API/אסימון OAuth |
בהתאם למנגנון ההרשאות שהגדרתם לממשקי ה-API, האפליקציה מעבירה מפתח API יחד עם כל בקשה שנשלחת לממשקי ה-API שלכם. אם המפתח תקף, הבקשה מורשית. Edge תומך בסוגים שונים של אימות, כמו מפתח API פשוט, OAuth דו-רגלי, OAuth תלת-רגלי ועוד. כספקי API, עליכם להגדיר למפתחים את הדרך לרישום האפליקציות שלהם. כדי לגשת אל ממשקי ה-API שלך, צריך לרשום את האפליקציה של המפתח ולהחזיר למפתח את המפתח שנדרש כדי לגשת לממשקי ה-API. בזמן רישום האפליקציה, המפתח יכול לבחור לגשת למוצר API יחיד או למספר מוצרי API. האפליקציה בפועל של המפתח משתמשת באותו מפתח כדי לגשת לכל מוצרי ה-API המשויכים לאפליקציה (התצוגה הרשומה של האפליקציה של המפתח ב-Edge). אתם יכולים לבטל את המפתח בכל שלב כדי לאפליקציה של המפתח לא תהיה יותר גישה לממשקי ה-API שלכם (גם אם הייצוג המורשה של האפליקציה של המפתח עדיין קיים בארגון). לחלופין, אפשר להגדיר מגבלה זמן למפתח כדי שהמפתח צריך לרענן את המפתח אחרי זמן מסוים. |
מידע על סביבות
סביבה היא הקשר של זמן הריצה של שרת ה-proxy ל-API בארגון. כדי לגשת לשרת proxy של API, צריך לפרוס אותו בסביבה. אפשר לפרוס שרת proxy של API בסביבה אחת או בכמה סביבות.
ארגון יכול להכיל כמה סביבות. לדוגמה, אפשר להגדיר סביבות dev, test ו-prod בארגון.
הארגון מספק היקף לחלק מהיכולות של Apigee. לדוגמה, אפשר להפוך נתונים של מפה של מפתח/ערך (KVM) לזמינים ברמת הארגון. כלומר, שרתים proxy של API שנפרסים בכל סביבה יקבלו את אותם נתונים מ-KVM. אפשר להגביל חלק מהיכולות, כמו שמירה במטמון, לארגון או לסביבה ספציפית בארגון. נתוני הניתוח של Apigee מחולקים לפי שילוב של ארגון וסביבה.
למטה מוצגות הישויות העיקריות שאתם מנהלים בארגון, כולל הישויות שמוגדרות בכל העולם בארגון, ואלו שמוגדרות באופן ספציפי לסביבה:
