您目前查看的是 Apigee Edge 說明文件。
前往 Apigee X 說明文件。 info
我們在 2014 年 1 月 29 日 (星期三) 發布了新版 Apigee Edge On-Premises。
如有任何問題，請與 Apigee Edge 支援團隊聯絡。
這個版本包含下列雲端版本的相關功能和錯誤修正：
新功能和強化項目
- OAuth 2.0 更新權杖的自訂屬性
您可以使用新的「設定 OAuth 2.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.3、 volos-oauth-apigee 0.0.2、volos-quota-apigee 0.0.2。
-
管理 UI 中的自訂角色 - BETA 版
除了現有的「商家使用者」、「營運管理員」、「機構管理員」和「使用者」角色，這個版本還包含 Beta 版功能，可讓您在管理 UI 中建立自訂角色。您可以透過自訂角色控管各種 Edge 功能的存取權。 - 進階 API 服務 (原名為「應用程式服務」) 安裝程式
Apigee Edge 進階 API 服務 (原名為「應用程式服務」) 現已可供內部部署使用。 現有的 Edge 安裝程式可讓您在自己的內部部署環境中部署及設定 Advanced API Services。
- 開發人員服務營利 (舊稱「營利服務」) 安裝程式
營利功能是 Edge 開發人員服務的一部分。Edge 本機安裝程式現在包含強化版整合式營利安裝程式。如要營利，必須取得額外付費授權。
- 單一主機上的多個訊息處理器 - 無訊息安裝
這項強化功能支援在單一主機上安裝多個訊息處理器的部署拓撲，這需要將每個訊息處理器繫結至特定 IP 位址。您現在可以在無聲安裝設定檔中新增BIND_ON_ALL_INTERFACES=n屬性設定，讓訊息處理器監聽同一檔案中HOSTIP屬性指定的特定 IP 位址。如要進一步瞭解這項屬性，以及如何設定無訊息安裝，請參閱 Apigee On-premises Deployment Kit 安裝和設定指南。
-
JMS 更新
這個版本包含 Apigee JMS 支援的各項更新，包括：- 所有 JMS 標頭現在都會以 HTTP 標頭的形式傳播，供下游處理。
- 您現在可以為 JMS Proxy 使用的 ResponseQueue 中的訊息指定 ExpiryTime 和 DeliveryMode。所有符合標準 JMS 標頭的 HTTP 標頭都會「照原樣」設定，其他 HTTP 標頭則會在 JMS Proxy 使用的回應訊息中設為 JMS 屬性。
修正錯誤
| 主題 | 說明 |
|---|---|
| 自訂角色權限 | 使用自訂角色設定的權限現在可正常運作。 |
| API 延遲時間分析 | 在 API Proxy 流程中，如果對目標系統的呼叫導致逾時 (例如 HTTP 讀取逾時)，API 數據分析會納入目標延遲時間。 |
| 政策的「type」屬性 | 「type」屬性現在可在所有 Apigee 政策中正常運作。 |
| OAuth 2.0 權杖失效 | Apigee OAuth 2.0 政策的權杖失效功能現在符合 OAuth 規格。設定「token」參數時，您不再需要提供「type」。 |
| 使用鍵/值對應的 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 屬性。在下列政策中，transfer-encoding 屬性會從 HTTP 標頭中移除，讓用戶端接收未分塊的回應。這項政策會附加至 API Proxy 回應流程。
<AssignMessage name="RemoveChunkedEncoding">
<AssignTo createNew="false" type="response"></AssignTo>
<Remove>
<Headers>
<Header name="Transfer-Encoding"/>
<Header name="transfer-encoding"/>
</Headers>
</Remove>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>
|