16.08.17 – נתוני הגרסה של Apigee Edge ל-Public Cloud

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

ביום שלישי, 30 באוגוסט 2016, השקנו גרסה חדשה של Apigee Edge ל-Public Cloud.

עדכונים ותכונות חדשות

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

מטענים ייעודיים (payloads) של JSON ברכיבים Assign Message ו-Raise Fault

השיפור הזה מאפשר להשתמש במשתנים באמצעות סוגריים מסולסלים בלי ליצור קובץ JSON לא תקין, כך שלא צריך פתרונות עקיפים כדי לוודא שפורמט הודעת ה-JSON תקין. לדוגמה, הפקודה הבאה מוסיפה את הערך של message.content להודעת ה-JSON:

<Payload contentType="application/json">{"message" : "{message.content}"}</Payload>

אם השתמשתם בפתרון עקיף, הקוד ימשיך לפעול כמו שהוא. אפשר גם להשתמש ב-variablePrefix וב-variableSuffix במקום בסוגריים מסולסלים כדי לציין משתנים.

אפשר לעיין ברכיב <Set><Payload> במסמכי העיון בנושא הקצאת מדיניות להודעה והעלאת מדיניות שגיאה. (APIRT-1160)

שיפורים במדיניות XML ל-JSON

הוספנו את היכולות הבאות למדיניות XML ל-JSON. אפשר להגדיר את המדיניות כך:

• התייחסות לחלק מאלמנטי ה-XML כמערכים במהלך ההמרה, כך שהערכים מוצבים בסוגריים מרובעים '[ ]' במסמך ה-JSON.
• הסרה או ביטול של רמות בהיררכיה של מסמך ה-XML במסמך ה-JSON הסופי.

מידע נוסף מופיע במאמר בנושא מדיניות XML to JSON. (APIRT-1144)

שימוש בכמה תווים כלליים בנתיבי משאבים של מוצר API

כשמגדירים נתיבי משאבים ב-API Product, אפשר לכלול תווים כלליים בכמה מקומות בנתיב משאב. לדוגמה, /team/*/invoices/** מאפשר שליחת קריאות ל-API עם כל ערך אחרי /team ועם כל נתיב משאב אחרי invoices/. דוגמה ל-URI מותר בקריאה ל-API:‏ proxyBasePath/team/finance/invoices/company/a.

אם אחרי הפרסום הזה נתיבי המשאבים הקיימים של מוצר ה-API מפסיקים לפעול כמצופה, צריך להגדיר את המאפיין הבא בארגון כדי לחזור להתנהגות הקודמת: features.enableStandardWildCardMatchForAPIProductResources = true

(MGMT-3273)

פונקציות הצפנה ב-JavaScript

זמין סט חדש של פונקציות JavaScript crypto עם ביצועים גבוהים ליצירה, לקבלת ולעדכון של האובייקטים הבאים של הגיבוב: MD5,‏ SHA-1,‏ SHA256,‏ SHA512. אובייקט crypto מאפשר גם לקבל את התאריך בפורמטים שונים. מידע נוסף זמין במאמר בנושא מודל אובייקטים של JavaScript. (APIRT-2886)

בדיקת הגרסה של Java Callout JAR

כשמעלים משאב Java JAR ל-proxy ל-API, מוחזר קוד סטטוס HTTP 400 (במקום 500) אם הגרסה של משאב Java לא תואמת לגרסה של Java שנתמכת ב-Edge, שמפורטת במאמר תוכנות נתמכות וגרסאות נתמכות. (MGMT-3420)

אימות משאבים של proxy ל-API

אם יש לכם קבצים של משאבי proxy ל-API (כמו JavaScript או Java JAR) שמאוחסנים בהיקף הסביבה או הארגון, לא תצטרכו יותר לכלול את המשאבים האלה גם ברמת ה-proxy ל-API בחבילת proxy כדי שהייבוא יעבור את האימות. אימות המשאבים מתבצע עכשיו בזמן הפריסה, ולא בזמן הייבוא. (MGMT-1430)

הגדרת פסק זמן (timeout) לכל שרת proxy של API

אפשר להגדיר שפרוקסי של API יפסיק לפעול אחרי פרק זמן מסוים (עם סטטוס של gateway timeout‏ 504). תרחיש השימוש העיקרי הוא ללקוחות Private Cloud שיש להם שרתי proxy של API שלוקח להם יותר זמן לפעול. לדוגמה, נניח שאתם צריכים שפרוקסי ספציפיים יפסיקו לפעול אחרי 3 דקות. אפשר להשתמש במאפיין api.timeout חדש בהגדרה של proxy ל-API. כך עושים זאת בדוגמה של 3 דקות:

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

   <ProxyEndpoint name="default">
     <HTTPProxyConnection>
       <BasePath>/v1/weather</BasePath>
       <Properties>
         <!-- api.timeout is in milliseconeds -->
         <Property name="api.timeout">180000</Property>
       </Properties>
       ...

3. עם זאת, שימו לב שהגדלת ערכי הזמן הקצוב לתפוגה של המערכת עלולה לגרום לבעיות בביצועים, כי כל שרתי ה-proxy ללא הגדרה של api.timeout משתמשים בערכי הזמן הקצוב לתפוגה החדשים והגבוהים יותר של מאזן העומסים, הנתב ומעבד ההודעות. לכן, כדאי להגדיר ששרתי proxy אחרים של API שלא דורשים פסק זמן ארוך יותר ישתמשו בפסק זמן קצר יותר. לדוגמה, הקוד הבא מגדיר ש-proxy ל-API יפסיק לפעול אחרי דקה אחת:
   <Property name="api.timeout">60000</Property>

לקוחות Cloud שלא יכולים לשנות את הזמן הקצוב לתפוגה של Edge יכולים גם להגדיר זמן קצוב לתפוגה של proxy ל-API, בתנאי שהזמן הקצוב לתפוגה קצר יותר מהזמן הקצוב לתפוגה הרגיל של מעבד ההודעות של Edge, שהוא 57 שניות.

אי אפשר לאכלס את הערך באמצעות משתנה. המאפיין הזה מוסבר בהפניה למאפייני נקודות קצה. (APIRT-1778)

מדיניות TLS/SSL לרישום הודעות ביומן

אפשר להגדיר את <KeyStore> ו-<TrustStore> בהגדרות SSLInfo של מדיניות רישום ההודעות, כדי לאפשר TLS/SSL חד-כיווני ודו-כיווני עם שירות רישום. מגדירים את SSLInfo במדיניות Message Logging (רישום הודעות) באותו אופן שבו מגדירים אותו ב- TargetEndpoint של שרת proxy. עם זאת, רישום הודעות ביומן TLS/SSL תומך רק בפרוטוקול TCP. (APIRT-1858)

באגים שתוקנו

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