您正在查看 Apigee Edge 說明文件。
查看 Apigee X 說明文件。 資訊
2014 年 1 月 29 日星期三,我們發布了全新的 Apigee Edge 地端部署版本。
如有任何問題,請前往 Apigee 客戶服務頁面。
這個版本包含下列雲端版本的功能和錯誤修正:
新功能和強化項目
- OAuth 2.0 更新權杖的自訂屬性
全新的「設定 OAuth v2.0 資訊」政策可讓您更新 OAuth 2.0 權杖的自訂屬性。
http://apigee.com/docs/api-services/content/set-oauth-tokens-attributes-using-setoauthv2info
-
OAuth 1.0a 政策更新
這個版本包含下列 OAuth 1.0a 政策更新:- 與 OAuth 2.0 權杖相同,您現在可以為 OAuth 1.0a 權杖設定自訂屬性。
- 全新的 GenerateVerifier 作業可讓您產生並傳回 OAuth 1.0a 驗證器 (類似 OAuth 2.0 中的授權碼)。
- 流程變數中的 SSL 資訊
Apigee Edge 現在可讓您傳播及存取流程變數中的 SSL 資訊。只要在 ProxyEndpoint 上設定新的「propagate.additional.ssl.headers」屬性,即可存取 Apache 網路伺服器上可用的相同 SSL 資訊。
http://apigee.com/docs/api-services/api/variables-reference
- JMS 標頭做為 HTTP 標頭
現在所有 JMS 標頭都會以 HTTP 標頭的形式套用到下游處理。
- Node.js 模組更新
Apigee 的內建 Node.js 模組已更新,包含下列模組:argo 0.4.9、async 0.2.9、express 3.4.8、underscore 1.5.2、usergrid 0.10.7, volos-cache-memory 0.0.2, volos-oauth.詳細說明
-
管理 UI 中的自訂角色 - Beta 版
除了「企業使用者」、「作業管理員」、「機構管理員」和「使用者」的現有使用者角色外,這個版本還提供 Beta 版功能,可讓您在管理使用者介面中建立自訂角色。您可以使用自訂角色來控管各種 Edge 功能的存取權。 - 進階 API 服務 (舊稱「應用程式服務」) 安裝程式
Apigee Edge Advanced API 服務 (舊稱「App Services」) 現已可在地端部署系統使用。現有的 Edge 安裝程式可讓您在自己的地端部署環境中部署及設定 Advanced API 服務。
- 開發人員服務營利 (原稱「營利服務」) 安裝程式
營利功能是 Edge Developer Services 的一部分。Edge 地端部署安裝程式現在包含經過改良的整合式營利安裝程式。您必須另外付費授權,才能使用營利功能。
- 在單一主機上執行多個訊息處理器 - 無訊息安裝
這項強化功能支援在單一主機上為多個訊息處理處理器進行部署模擬作業,而這需要將每個訊息處理器繫結至特定的 IP 位址。您現在可以在無訊息安裝設定檔中新增BIND_ON_ALL_INTERFACES=n
屬性設定,讓訊息處理工具監聽特定 IP 位址 (由相同檔案中的HOSTIP
屬性指定)。如要進一步瞭解這項屬性,以及如何設定無訊息安裝,請參閱 Apigee 地端部署部署套件安裝與設定指南。
-
JMS 更新
這個版本包含 Apigee 支援 JMS 支援的多種更新內容,包括:- 所有 JMS 標頭現在都會以 HTTP 標頭的形式傳播,以進行下游處理。
- 您現在可以針對 JMS Proxy 使用 ResponseQueue 的訊息指定 ExpiryTime 和 DeliveryMode。所有符合標準 JMS 標頭的 HTTP 標頭都會設為「現狀」,其他 HTTP 標頭則會在 JMS Proxy 使用的回應訊息中設為 JMS 屬性。
修正錯誤
主題 | 說明 |
---|---|
自訂角色權限 | 使用自訂角色設定的權限現在可正常運作。 |
API 延遲時間分析 | 在 API Proxy 流程中,如果呼叫目標系統導致逾時 (例如 HTTP 讀取逾時),API 數據分析中會包含的目標延遲時間。 |
政策的「type」屬性 | 現在「type」屬性在所有 Apigee 政策中都能正確運作。 |
將權杖失效 | Apigee 2.0 政策的撤銷權杖功能現在與 OAuth 規格相符。設定「token」參數時,您不再需要提供「類型」。 |
具有鍵/值對應關係的 RBAC | 角色型存取權控管現在適用於在環境層級建立的鍵/值對應。 |
OAuth 1.0a 政策回應格式 | 透過 OAuth 1.0a 政策向 API 發出要求時,系統現在會以 Accept 標頭格式傳回回應。 |
已知問題
主題 | 說明 |
---|---|
HTTP 1.0 要求、 HTTP 1.1 回應 |
這個問題涉及以下情境:用戶端透過 HTTP 1.0 傳送要求,標頭中含有
content-length 屬性,但後端服務設定為使用 HTTP 1.1,並改為傳回區塊編碼的 transfer-encoding 屬性。
想要成功處理這種情況,您可以使用 AssignMessage 政策,從 HTTP 1.1 回應中移除
transfer-encoding 屬性。下列政策會附加至 API Proxy 回應流程,並從 HTTP 標頭中移除 transfer-encoding 屬性,這樣用戶端才能不分區塊接收回應。
<AssignMessage name="RemoveChunkedEncoding">
<AssignTo createNew="false" type="response"></AssignTo>
<移除>
<標頭>
<Header name="Transfer-Encoding"/>
<Header name="transfer-encoding"/>
</Headers>
</移除>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>
|