您正在查看 Apigee Edge 文档。
前往 Apigee X 文档。 信息
2014 年 1 月 29 日（星期三），我们发布了 Apigee Edge 的新本地版本。
如果您有任何疑问，请与 Apigee Edge 支持团队联系。
此版本包含以下云版本中的功能和 bug 修复：
新功能和增强功能
- 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 Web 服务器上提供的相同 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。
-
管理界面中的自定义角色 - Beta 版
除了现有的“商家用户”“运营管理员”“组织管理员”和“用户”用户角色之外，此版本还包含一项 Beta 版功能，可让您在管理界面中创建自定义角色。您可以使用自定义角色控制对各种 Edge 功能的访问权限。 - 高级 API 服务（以前称为应用服务）安装程序
Apigee Edge 高级 API 服务（以前称为应用服务）现在可供本地使用。 借助现有的 Edge 安装程序，您可以在自己的本地环境中部署和配置 Advanced API Services。
- 开发者服务变现（以前称为“变现服务”）安装程序
变现功能是 Edge 开发者服务的一部分。Edge 本地安装程序现在包含增强型集成式创收安装程序。创收需要额外的付费许可。
- 单个主机上的多个消息处理器 - 静默安装
此增强功能支持在单个主机上安装多个消息处理器的部署拓扑，这需要将每个消息处理器绑定到特定的 IP 地址。现在，您可以在静默安装配置文件中添加BIND_ON_ALL_INTERFACES=n属性设置，使消息处理器监听同一文件中HOSTIP属性指定的特定 IP 地址。如需详细了解此属性以及如何配置静默安装，请参阅 Apigee 本地部署套件安装和配置指南。
-
JMS 更新
此版本对 Apigee 的 JMS 支持进行了多项更新，包括：- 所有 JMS 标头现在都作为 HTTP 标头进行传播，以便进行下游处理。
- 现在，您可以为 JMS 代理使用的 ResponseQueue 中放置的消息指定 ExpiryTime 和 DeliveryMode。与标准 JMS 标头匹配的所有 HTTP 标头都按原样设置，其他 HTTP 标头则在 JMS 代理使用的响应消息中设置为 JMS 属性。
已修复 Bug
| 主题 | 说明 |
|---|---|
| 自定义角色权限 | 使用自定义角色设置的权限现在可正常发挥作用。 |
| API 延迟时间分析 | 在 API 代理流中，当对目标系统的调用导致超时（例如 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 属性。在以下政策中（将附加到 API 代理响应流），系统会从 HTTP 标头中移除 transfer-encoding 属性，从而允许客户端接收未分块的响应。
<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>
|