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. בודקים את גרסת Cassandra SSTable:
   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 Platform

בהמשך מפורטות התכונות החדשות של פלטפורמת 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 ביט), CentOS 6.5,‏ 6.6 ו-7.0 (64 ביט) ו-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 של מעבד ההודעות. רכיבים יוסרו מהמטמון בזיכרון רק אם אין מספיק זיכרון במטמון או אם תוקף הרכיבים פג.

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

שירותי API

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

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

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

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

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

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

מדיניות חדשה בשם 'מחיקת מידע על OAuth v1.0' מאפשרת לכם למחוק אסימוני בקשה, אסימוני גישה וקודי אימות של OAuth v1.0. המדיניות הזו מחליפה את הפונקציונליות שסופקה בעבר על ידי Management 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: המרה אוטומטית של שם הנתונים הסטטיסטיים לאותיות קטנות

כשיוצרים אוסף נתונים מותאם אישית של Analytics בכלי לעריכת proxy ל-API (הדף 'פיתוח' > 'כלים' > 'אוסף נתונים מותאם אישית של Analytics'), צריך להשתמש באותיות קטנות בשם של משתנה (סטטיסטיקה) של אוסף הנתונים. אם מזינים את השם באותיות רישיות, הכלי ממיר אוטומטית את שם הנתון לאותיות קטנות במדיניות של כלי איסוף הנתונים. (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> ברכיב HTTPTargetConnection <LoadBalancer> של 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 Certificates (אישורי SSL) בממשק הניהול (Admin > SSL Certificates) מצוין מתי תוקף אישורי ה-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)

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

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

זמינות לכלל המשתמשים (GA) של SmartDocs

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

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

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

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

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

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

שירותי Analytics

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

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

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

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

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

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

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

מונטיזציה

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

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

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

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

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

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

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

אם אין עמלה חוזרת, החבילות מאופסות על סמך בסיס הצבירה שמוגדר בתעריפים. לדוגמה, אם מפתח מתחיל להשתמש בתעריפים ב-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 במהלך תקופת הבטא, תכונות ויכולות חדשות בגרסת הזמינות לכלל המשתמשים (GA) דורשות שתשדרגו את 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, בוחרים באפשרות Security Settings.
   
4. כדי לבדוק אם יש אימות שהוגדר מראש בדף הגדרות המודל (Content > SmartDocs), לוחצים על Settings (הגדרות) בעמודה Operations (פעולות).
   
5. צריך לעדכן את כל התבניות המותאמות אישית כדי להשתמש בנכסי CSS ו-JS בגרסה 6, ולבצע שינויים שישקפו שמות אובייקטים חדשים, כמו 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