4.15.07.00 – הערות לגרסה של Apigee Edge לענן פרטי

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

ביום שלישי, 8 בספטמבר 2015, השקנו גרסת תכונות משמעותית של Apigee Edge for Private Cloud.

מאז הגרסה הקודמת להפצה של Edge for Private Cloud (4.15.04.00), התרחשו ההפצות הבאות והן נכללות בגרסה הזו להפצה:

• ‫Cloud: ‏ 15.04.15, 15.04.29,‏ 15.05.27,‏ 15.06.10 ו-15.06.24
• ענן פרטי: 4.15.04.01

לאילו גרסאות של Edge אפשר לשדרג ‫4.15.07.00

בהתאם לגרסה הנוכחית של Edge, אפשר:

• שדרוג ישירות לגרסה 4.15.07.00
• שדרוג מצטבר, כלומר צריך לשדרג מהגרסה הנוכחית לגרסה אחרת של Edge, ואז לשדרג לגרסה 4.15.07.00.

מידע נוסף זמין במאמר אילו גרסאות של Edge for Private Cloud אפשר לשדרג לגרסה 4.15.07.00.

לפני שדרוג מגרסה 4.15.01.x או מגרסה קודמת

1. בודקים את גרסת ה-SSTable של Cassandra:
   1. משנים את הספרייה ל-/<install-root>/apigee4/data/cassandra/data.
   2. מריצים פקודת חיפוש,
      > find . ‪-name *-ic-*
      התוצאות צריכות להחזיר קבוצה של קובצי ‎ .db אם מריצים Cassandra 1.2 SSTable.
   3. מריצים את פקודת החיפוש הבאה:
      > find . ‪-name *-hf-*
      התוצאות צריכות להיות ריקות, כלומר אין קבצים בפורמט ‎ .db בפורמט hf. אם לא מופיעים קבצים בפורמט hf, סיימתם את התהליך ואפשר לשדרג לגרסה 4.15.07.00.
      
      הפורמט hf מיועד לטבלאות SSTable ב-Cassandra 1.0. אם יש לכם קובצי ‎ *.db בפורמט hf, אתם צריכים לשדרג את SSTable כמו שמתואר בהמשך התהליך הזה.
2. אם אתם מוצאים קובצי ‎ *.db בפורמט hf, אתם צריכים לשדרג את SSTable. לשם כך, מריצים את הפקודה הבאה בכל צומת Cassandra עד שמשדרגים את כל צומתי Cassandra:‏
   > /<install-root>/apigee4/share/apache-cassandra/bin/nodetool -h localhost upgradesstables -a
3. חוזרים על שלב 1 כדי לוודא שכל קובצי ‎ *.db הם בפורמט ic לגרסה Cassandra 1.2.
4. חוזרים על שלבים 1 עד 3 בכל צומת של Cassandra בהתקנה של Edge.
5. שדרוג ל-Edge 4.15.07.00.
6. אחרי השדרוג לגרסה 4.15.07.00, בודקים את הקבצים ‎ *.db כדי לוודא שכולם שודרגו ל-sstable בסגנון C* 2.0:
   > cd /<install-root>/apigee4/data/cassandra/data
   > find . ‪-name *-jb-*
   הפקודה הזו אמורה להחזיר קבוצה של קובצי ‎ .db אם מריצים את Cassandra 2.0.

תכונות חדשות ושיפורים

בהמשך מפורטים התכונות והשיפורים החדשים בגרסה הזו.

התקנה ושדרוג

שדרוג והסרה של רכיבים ספציפיים

הסקריפטים apigee-upgrade.sh ו-apigee-uninstall.sh מאפשרים עכשיו לבחור את רכיבי Edge שרוצים לשדרג או להסיר. בעבר, הוא שדרג או הסיר את כל הרכיבים בצומת. (OPDK-1377, OPDK-1175)

החזרה לגרסה הקודמת

אם הסקריפט apigee-upgrade.sh נכשל במהלך שדרוג, עכשיו אפשר להשתמש בסקריפט apigee-rollback.sh כדי לבטל את השדרוג. אחרי שתפתרו את הבעיות בשדרוג, תוכלו לנסות לשדרג שוב. (OPDK-1275)

אפשרויות תסריט התקנה מקוצר

סקריפטים להתקנה לא מקבלים יותר אפשרויות בפורמט ארוך, כמו ‎--help. עכשיו הן מקבלות רק אפשרויות של אות אחת, כמו ‎-h. (OPDK-1356)

התקנה של SmartDocs

כשמתקינים את SmartDocs באמצעות הסקריפט setup-smartdocs.sh, מוצגת בקשה להזנת הארגון, הסביבה והמארח הווירטואלי, כדי לוודא ש-SmartDocs מותקן במיקום הצפוי. בעבר, הערכים האלה היו מוצפנים בסקריפט. (OPDK-1310)

הפעלת update-cass-pwd-in-config.sh ללא הנחיות

אפשר להריץ את הסקריפט update-cass-pwd-in-config.sh בלי הנחיות אם מגדירים את משתני הסביבה ENABLE_CASS_AUTH,‏ CASS_USERNAME ו-CASS_PASSWORD. (OPDK-1309)

פלטפורמת Edge

בהמשך מפורטות התכונות החדשות של פלטפורמת Edge שכלולות בגרסה הזו.

‫OpenJDK 1.7 נתמך על ידי Edge Private Cloud

הגרסה הזו של Edge תומכת ב-Oracle JDK 1.7 וב-OpenJDK 7, והוסרה ממנה התמיכה ב-JDK 1.6. (OPDK-1187)

תמיכה במערכת ההפעלה

הוספנו תמיכה במערכות הפעלה ב-Apigee Edge for Private Cloud, כולל Red Hat Enterprise Linux 6.6 & 7.0 (64-bit),‏ CentOS 6.5,‏ 6.6 & 7.0 (64-bit) ו-Oracle Linux 6.5.

‫Cassandra 2.0.15 כלול ב-OPDK 15.07

בגרסה הזו מותקנת Cassandra 2.0.15. אם אתם משדרגים מגרסה קודמת, גרסת Cassandra תעודכן. (OPDK-1197)

תמיכה ב-SHA2 לגיבוב של טוקנים של OAuth

כדי לשפר את ההגנה על טוקנים של OAuth במקרה של פרצת אבטחה במסד נתונים, Edge תומך באלגוריתמים של SHA2 לגיבוב טוקנים של OAuth (בנוסף ל-SHA1). בעזרת מאפיינים חדשים ברמת הארגון, אפשר להפעיל ולהגדיר גיבוב (hashing) של טוקנים חדשים, וגם לשמור על גיבוב מדור קודם של טוקנים שהיו קיימים לפני התכונה החדשה הזו. בעבר, ב-Edge for Private Cloud, מאפיין בשם hash.oauth.tokens.enabled בקובץ keymanagement.properties (בשרת הניהול ובמעבדי ההודעות) הפעיל גיבוב אוטומטי של אסימוני OAuth באמצעות SHA1. המאפיין הזה יצא משימוש.

אם השתמשתם בעבר בנכס hash.oauth.tokens.enabled כדי להפעיל גיבוב SHA1, סקריפט השדרוג של הגרסה הזו יוצר באופן אוטומטי את הנכסים החדשים ברמת הארגון בשבילכם. כדי לאמת אחרי השדרוג, צריך לבצע GET כאדמין במערכת באמצעות ה-API הזה: https://{host}:{port}/v1/o/{your_org}

• מידע על הפעלת גיבוב אסימונים בארגון באמצעות המאפיינים החדשים זמין בקטע 'גיבוב אסימונים במסד הנתונים' בנושא בקשת אסימוני גישה.
• מידע על גיבוב של אסימונים קיימים בכמות גדולה זמין במדריך התפעול של Edge for Private Cloud. (APIRT-1389)

מבנה שטוח של תיקיות לקובצי יומן

אפשר להגדיר את Edge כך שיאחסן קובצי יומן במבנה ספרייה שטוח על ידי הגדרת מאפיין חדש enable.flat.directory.structure לערך true בקובץ message-logging.properties. מידע נוסף זמין במאמר בנושא מדיניות רישום הודעות ביומן. (APIRT-1394)

ביצועי מטמון הסביבה

כדי לשפר את הניהול והניצול של מטמון בזיכרון, ההגדרות 'מספר מקסימלי של רכיבים בזיכרון' במשאבי מטמון של סביבה הוצאו משימוש. המספר הכולל של הרכיבים שמוצגים בכל משאבי המטמון (כולל מטמון ברירת המחדל) תלוי בזיכרון הכולל שהוקצה למטמון. כברירת מחדל, הזיכרון הכולל שמוקצה לשמירת נתונים במטמון במעבד הודעות נתון הוא 40% מהזיכרון הכולל שזמין, כפי שנקבע בהגדרות המאפיינים של המטמון בקובץ cache.properties של מעבד ההודעות. אלמנטים יוסרו מהמטמון בזיכרון רק אם אין מספיק זיכרון במטמון או אם תוקף האלמנטים פג.

כדי לחזור להתנהגות הקודמת של שימוש במאפיין Maximum Elements in Memory (מספר מקסימלי של רכיבים בזיכרון) לניהול המטמון, צריך להגדיר את המאפיין overrideMaxElementsInCacheResource=false בקובץ cache.properties. (APIRT-1140)

שירותי API

בהמשך מפורטות התכונות החדשות של שירותי ה-API שכלולות בגרסה הזו.

עורך ה-Proxy החדש כברירת מחדל

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

מדיניות חדשה בנושא מחיקת מידע OAuth v2.0

מדיניות חדשה בשם 'מחיקת מידע OAuth v2.0' מאפשרת לכם למחוק אסימוני גישה וקודי הרשאה של OAuth v2. המדיניות הזו מחליפה את הפונקציונליות שסופקה בעבר על ידי ה-API לניהול. מידע נוסף זמין במאמר בנושא מחיקת מדיניות OAuthV2 Info. (MGMT-2257)

מדיניות חדשה בנושא מחיקת מידע OAuth v1.0

מדיניות חדשה בשם 'מחיקת מידע על OAuth v1.0' מאפשרת לכם למחוק אסימוני בקשה, אסימוני גישה וקודי אימות של OAuth v1.0. המדיניות הזו מחליפה את הפונקציונליות שסופקה בעבר על ידי ה-API לניהול. מידע נוסף זמין במאמר בנושא מחיקת מדיניות מידע של OAuth V1. (APIRT-1351)

מדיניות בקרת גישה

שדרגנו את מדיניות בקרת הגישה כדי לאפשר הערכה מדויקת יותר של כתובות IP לצורך הוספה לרשימת ההיתרים והוספה לרשימת החסימה, כשכתובות ה-IP מופיעות בכותרת ה-HTTP‏ X-FORWARDED-FOR.

אם מפעילים את האפשרות לבדיקת כמה כתובות IP בכותרת (צריך לפנות לתמיכה כדי להגדיר את התכונה feature.enableMultipleXForwardCheckForACL), רכיב <ValidateBasedOn> חדש במדיניות מאפשר לבדוק את כתובת ה-IP הראשונה, את כתובת ה-IP האחרונה או את כל כתובות ה-IP בכותרת. מידע נוסף זמין במאמר בנושא מדיניות בקרת גישה.

ישויות חדשות במדיניות Access Entity

מדיניות Access Entity מספקת גישה לישויות החדשות הבאות: consumerkey-scopes,‏ authorizationcode,‏ requesttoken ו-verifier. מידע נוסף זמין במאמר בנושא מדיניות לגבי ישויות גישה.

מדיניות Statistics Collector: המרה אוטומטית של שם הנתונים הסטטיסטיים לאותיות קטנות

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

הסרה של Classic Trace בכלי לעריכת proxy ל-API

הגרסה החדשה ביותר של הפונקציונליות Trace בכלי לעריכת שרתי proxy של API עברה מגרסת בטא לגרסה שזמינה לכלל המשתמשים (GA). הגישה ל'כלי המעקב הקלאסי' באמצעות הקישור 'גישה לגרסה הקלאסית של כלי המעקב' כבר לא זמינה.

גישה לקהילת Apigee מתפריט העזרה בממשק הניהול

אפשר לגשת לקהילת Apigee מתפריט העזרה בממשק המשתמש לניהול.

הודעות שגיאה בממשק הניהול

השיפורים הבאים בוצעו בהודעות השגיאה בממשק המשתמש לניהול:

• ממשק ניהול שמשמש לקיבוץ ולהצגה של כל הודעות השגיאה בממשק המשתמש עבור כל סשן ההתחברות, אלא אם סגרתם אותן. בעקבות העדכון הזה, הודעות השגיאה נמחקות אוטומטית כשעוברים מהדף שבו הן הופיעו. (MGMT-2254)
• ממשק המשתמש לניהול לא מסתיר יותר הודעות שגיאה כפולות. (MGMT-2242)

שיפורים בביצועים של ממשק המשתמש ותיקוני שגיאות

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

היפר-קישורים לתפקידים בדף Organization Users (משתמשים בארגון) בממשק הניהול

בדף Organization Users (משתמשים בארגון) בממשק הניהול (Admin > Organization Users), שמות התפקידים הם עכשיו היפר-קישורים, כך שאפשר לנווט במהירות לדפי התפקידים. (MGMT-1055)

משתני טירגוט חדשים בזרימת ההודעות

משתנים חדשים בזרימות הודעות מספקים מידע מלא יותר על כתובות URL לנקודות קצה של יעד ושרתי יעד:

• ‫TargetEndpoint: ‏ request.url מחליף את target.basepath.with.query.
• ‫TargetServer: ‏ loadbalancing.targetserver מחליף את targetserver.name. בנוסף, הערך של target.basepath מאוכלס רק כשמשתמשים באלמנט <Path> באלמנט <LoadBalancer> של HTTPTargetConnection ב-TargetEndpoint.

תמיכה ב-Server Name Indication‏ (SNI)

‫Edge תומך בשימוש ב-Server Name Indication (הצגת שם השרת) בכיוון דרום (ממעבד ההודעות לנקודות הקצה של היעד). אם אתם רוצים להשתמש ב-SNI, פנו אל התמיכה של Apigee Edge.

נדרשת Java 1.7.

עם SNI, שהוא תוסף של TLS/SSL, אפשר להציג כמה יעדי HTTPS מאותה כתובת IP ומאותו פורט בלי שכל היעדים האלה יצטרכו להשתמש באותו אישור.

לא נדרשת הגדרה ספציפית ל-Edge. אם הסביבה שלכם מוגדרת ל-SNI מדרום לצפון (Edge Cloud מוגדר כך כברירת מחדל), ‏ Edge תומך בהגדרה הזו.

‫Edge מחלץ באופן אוטומטי את שם המארח מכתובת ה-URL של הבקשה ומוסיף אותו לבקשת לחיצת היד של SSL. לדוגמה, אם מארח היעד הוא https://example.com/request/path, ‏ Edge מוסיף את התוסף server_name כמו שמוצג בהמשך:

מידע נוסף על SNI זמין בכתובת http://en.wikipedia.org/wiki/Server_Name_Indication.

‫"Signature Algorithm" (אלגוריתם חתימה) בפרטים של אישורי SSL

שדה חדש בשם Signature Algorithm (אלגוריתם חתימה) נוסף לפרטי אישור SSL. אפשר לראות אותו בממשק המשתמש לניהול (אדמין > אישורי SSL) וב-API לניהול (Get Cert Details from a Keystore or Truststore). השדה מציג את הערך sha1WithRSAEncryption או sha256WithRSAEncryption, בהתאם לסוג אלגוריתם הגיבוב ששימש ליצירת האישור.

הצגת אישורי SSL שתוקפם עומד לפוג

בדף 'אישורי SSL' בממשק הניהול (אדמין > אישורי SSL) מצוין מתי תוקף אישורי ה-SSL יפוג תוך 10, 15, 30 או 90 ימים, בהתאם לבחירה שלכם בשדה החדש של התפריט הנפתח 'תוקף האישור יפוג'.

שגיאה בהגדרת ההגנה מפני איומים

כברירת מחדל, Edge מחזיר קוד סטטוס של שגיאת שרת פנימית מסוג HTTP 500 ושגיאה מסוג ExecutionFailed אם הודעה לא עוברת מדיניות של הגנה מפני איומים בפורמט JSON או XML. אפשר לשנות את התנהגות השגיאה הזו באמצעות נכס חדש ברמת הארגון. כשמגדירים את מאפיין הארגון features.isPolicyHttpStatusEnabled למצב True, מתרחשת ההתנהגות הבאה:

• בקשה: אם מדיניות להגנה מפני איומים מצורפת לכל זרימת בקשות, הודעות לא תקינות מחזירות קוד סטטוס 400, יחד עם הודעת שגיאה תואמת של המדיניות.
• תשובה: אם מדיניות להגנה מפני איומים מצורפת לכל זרימת תשובה, הודעות לא תקינות עדיין מחזירות קוד סטטוס 500, ואחת מהודעות השגיאה התואמות של המדיניות מופעלת (במקום רק ExecutionFailed).

לקוחות Cloud צריכים ליצור קשר עם התמיכה של Apigee Edge כדי להגדיר את מאפיין הארגון. התכונה הזו תהיה זמינה ללקוחות Edge Private Cloud בגרסה הבאה של Private Cloud, שיוצאת אחת לרבעון.

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

סכימות ההפניה עודכנו עבור ישויות שאינן קשורות למדיניות, כמו TargetEndpoint, ProxyEndpoint, APIProxy ועוד רבות אחרות. מידע נוסף מופיע כאן: https://github.com/apigee/api-platform-samples/tree/master/schemas. (APIRT-1249)

שירותים למפתחים

בהמשך מפורטות התכונות החדשות של שירותי המפתחים שכלולות בגרסה הזו.

זמינות כללית של SmartDocs

התכונה SmartDocs יוצאת מגרסת בטא ועוברת לזמינות כללית. העדכונים והתכונות החדשות כוללים:

• תמיכה ב-Swagger 2.0, כולל ייבוא לפי קובץ או כתובת URL, כולל תמיכה ב:‎ אובייקטים של אבטחה עם שמות מותאמים אישית.
• שיפורים בעיצוב הוויזואלי בתבניות שיוצרות מסמכים חכמים.
• שיפורים בשימושיות ובזרימת העבודה בפורטל למפתחים, שזמין דרך התפריט Content (תוכן) > SmartDocs ב-Drupal.
• מה שנקרא בעבר אימות באמצעות 'טוקן מותאם אישית' נקרא עכשיו 'מפתח API'.
• אובייקטים של אימות 'אבטחה' שמוגדרים ברמת הגרסה.
• הגדרת אימות לקוח ברמת התבנית. בגרסאות חדשות יותר, כבר לא מתבצע איפוס של פרטי הכניסה של לקוח SmartDocs שהוגדרו מראש.

לתיאורים נוספים של התכונות, אפשר לעיין בפוסט הזה בבלוג.

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

שם האפליקציה של המפתח שמוצג בממשק המשתמש לניהול

לאפליקציות למפתחים ב-Edge יש גם שם פנימי שלא משתנה וגם שם מוצג שאפשר לשנות. בדף של אפליקציית מפתח בממשק הניהול (Publish (פרסום) > Developer Apps (אפליקציות מפתח) > שם האפליקציה), השם הפנימי של האפליקציה מוצג לצד השם המוצג. כך קל יותר לזהות חזותית אפליקציות לפי השמות הפנימיים שלהן לצורך פתרון בעיות וניהול API.

שירותי Analytics

בהמשך מפורטות התכונות החדשות של שירותי Analytics שכלולות בגרסה הזו.

מגבלת הזמן לשמירת נתונים

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

הגרסה הקלאסית של דוחות בהתאמה אישית תוסר מממשק ניהול התוכן

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

ביצועים של הווידג'ט 'אינטראקציה עם מפתחים'

שיפרנו את הווידג'ט של המשפך בלוח הבקרה הראשי של Analytics (בקטע Developer Engagement) כדי לספק ביצועים טובים יותר.

מונטיזציה

בהמשך מפורטות התכונות החדשות למונטיזציה שכלולות בגרסה הזו.

התראות באימייל על תוכניות תמחור

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

סנכרון של עמלה חוזרת ותקופות של בסיס צבירה

בתוכנית תמחור, יכולות להיות שתי תקופות זמן שונות בתוקף:

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

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

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

המאפיין Aggregation Basis (בסיס צבירה) הוצא משימוש ויוסר מהמונטיזציה בגרסה עתידית. מידע נוסף זמין במאמר בנושא ציון פרטים של תוכנית תמחור.

מאפיינים בהתאמה אישית בדוחות סיכום של הכנסות

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

לקוחות של Apigee Edge for Private Cloud יכולים להגדיר את הדגל באמצעות הקריאה הבאה ל-API ופרטי הכניסה של מנהל המערכת.

curl -u email:password -X PUT -H "Content-type:application/xml" http://host:8080/v1/o/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <Properties>
        <Property name="features.isMonetizationEnabled">true</Property>
        <Property name="MINT.SUMMARY_CUSTOM_ATTRIBUTES">[&quot;my_attribute_1&quot;,&quot;my_attribute_2&quot;]</Property>
        <Property name="features.topLevelDevelopersAreCompanies">false</Property>
    </Properties>
</Organization>"

שימו לב שמערך המאפיינים המותאמים אישית בקריאה ל-API מקודד בכתובת ה-URL.

תהליך השדרוג של SmartDocs

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

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

חשוב לזכור שאפשר לעבד ולפרסם SmartDocs בפורטל המפתחים, אבל הם נוצרים ממודל ה-API שקיים בשירותי ניהול ה-API של Apigee Edge. כל שינוי שתבצעו במודל API ב-Edge יהיה זהה בכל הסביבות של Pantheon (בדומה לאופן שבו מפתחים קיימים בכל הסביבות של Pantheon).

כדי לשדרג מגרסת הבטא של SmartDocs לגרסה שזמינה לכלל המשתמשים

1. צריך לעדכן ולבדוק את גרסה 15.05.27 בסביבות הפיתוח או הבדיקה ב-Pantheon.
2. יוצרים מודל חדש כדי להחליף מודל API קיים שבו השתמשתם.
   • אם ייבאתם מסמכי Swagger או WADL, ייבאו אותם שוב לגרסה חדשה.
   • אם אתם מנהלים את מודל ה-API באמצעות מודול SmartDocs, תוכלו לייצא אותו כ-SmartDocs JSON ולייבא אותו למודל החדש באמצעות קובץ מצורף.
3. מגדירים את מאפייני האבטחה של הגרסה של המודל. בדף Content > SmartDocs > model (תוכן > SmartDocs > דגם), בוחרים באפשרות Security Settings (הגדרות אבטחה).
   
4. בודקים אם יש אימות שהוגדר מראש בדף ההגדרות של המודל (Content > SmartDocs) בלחיצה על Settings בעמודה Operations.
   
5. צריך לעדכן את כל התבניות המותאמות אישית כדי להשתמש בגרסה 6 של נכסי ה-CSS וה-JS, ולבצע שינויים שישקפו שמות אובייקטים חדשים, כמו authSchemes ו-apiSchema. מידע על עדכון תבניות SmartDocs זמין במאמר שימוש ב-SmartDocs לתיעוד ממשקי API.
6. מעבדים מחדש את הגרסה של המודל ומפרסמים אותה.
7. אחרי אימות התיעוד החדש, מעדכנים את פורטל הייצור לגרסה 15.05.27.

אם אתם לקוחות של Edge Enterprise ויש לכם שאלות או חששות לגבי תהליך השדרוג, אתם יכולים לשלוח אימייל לכתובות marsh@apigee.com ו-cnovak@apigee.com. אחרת, מומלץ להשתמש בקהילת Apigee כדי לקבל את התשובה הטובה ביותר.

שינויים ושיפורים עתידיים בתכונות

בקטע הזה מוצגת תצוגה מקדימה של שינויים ושיפורים צפויים בתכונות בעתיד:

שינוי בהתנהגות של מדיניות מטמון התגובות

בגרסה עתידית (שעדיין לא נקבעה), התנהגות ברירת המחדל של הרכיב <ExcludeErrorResponse> במדיניות Response Cache תשתנה.

ההתנהגות הנוכחית: אלמנט <ExcludeErrorResponse> במדיניות של מטמון התגובות מוגדר כ-false כברירת מחדל. המשמעות היא שבתגובות עם כל קוד סטטוס אפשרי של HTTP (כולל 3xx) מתבצעת שמירה במטמון על ידי מדיניות מטמון התגובות.

התנהגות עתידית: רכיב <ExcludeErrorResponse> במדיניות Response Cache יוגדר כ-true כברירת מחדל. המשמעות היא שברירת המחדל היא שמירה במטמון רק של תגובות עם קודי סטטוס HTTP 200 עד 205. כדי לשנות את ההתנהגות הזו ולשמור במטמון תגובות לכל קודי הסטטוס, צריך להגדיר את הרכיב <ExcludeErrorResponse> לערך true באופן מפורש.

פתרון עקיף נוכחי: ב-Private Cloud 4.15.07.00 ובגרסאות קודמות, אם רוצים לשמור במטמון תשובות רק עם קודי הסטטוס 200 עד 205, צריך להגדיר במפורש את הרכיב <ExcludeErrorResponse> כ-true.

באגים שתוקנו

בגרסה הזו תוקנו הבאגים הבאים.

בעיות מוכרות

בגרסה הזו יש את הבעיות הידועות הבאות.

> source /{install-dir}/apigee4/bin/apigee-env.sh

> VER=`basename $(find $SHARE_DIR/installer/monetization -name "mint-*.zip") | cut -d "-" -f 2,3,4`

> sed -i "s/^MONETIZATION_VERSION=.*/MONETIZATION_VERSION=$VER/" /install-dir/apigee4/bin/apigee-env.sh

> rm /install-dir/apigee4/share/monetization

**************************************
In order to complete the monetization upgrade please run:
sudo /opt/apigee4/share/monetization/schema/migration/MOPDK4.15.04.00/
365-create-notification-condition.sh
**************************************

connect.ranges.denied=10.0.0.0/8,192.168.0.0/16,127.0.0.1/32

<install_dir>/apigge4/bin/apigee-service message-processor restart