Se usó la API de Cloud Translation para traducir esta página.

14.01.00.00: Notas de la versión local de Apigee Edge

Estás viendo la documentación de Apigee Edge.
Ve a la documentación de Apigee X. info

El miércoles 29 de enero de 2014, lanzamos una nueva versión de Apigee Edge para las instalaciones.

Si tienes preguntas, visita la Asistencia al cliente de Apigee.

Esta versión incluye funciones y correcciones de errores de las siguientes versiones de Cloud:

14.02.19

Nuevas funciones y mejoras

OAuth 2.0 actualiza los atributos personalizados en los tokens
Una nueva política "Set OAuth v2.0 Info" te permite actualizar los atributos personalizados en los tokens de OAuth 2.0.
http://apigee.com/docs/api-services/content/set-oauth-tokens-attributes-using-setoauthv2info
Actualizaciones de la política de OAuth 1.0a
Esta versión incluye las siguientes actualizaciones de la política de OAuth 1.0a:
- Al igual que con los tokens de OAuth 2.0, ahora puedes configurar atributos personalizados en los tokens de OAuth 1.0a.
- Una nueva operación GenerateVerifier te permite generar y mostrar un verificador de OAuth 1.0a (similar a un código de autorización en OAuth 2.0).
http://apigee.com/docs/api-services/content/authorize-requests-using-oauth-10a
Información de SSL en las variables de flujo
Ahora, Apigee Edge te permite propagar y acceder a la información de SSL en las variables de flujo. Si configuras una nueva propiedad "propagate.additional.ssl.headers" en un ProxyEndpoint, tienes acceso a la misma información de SSL disponible en un servidor web Apache.
http://apigee.com/docs/api-services/api/variables-reference
Encabezados JMS como encabezados HTTP
Ahora, todos los encabezados JMS se propagan como encabezados HTTP para el procesamiento descendente.
Actualización del módulo de Node.js
Se actualizó el módulo integrado de Node.js de Apigee para incluir los siguientes módulos: 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 y volos-quota-apigee 0.0.2.
Roles personalizados en la IU de administración: Versión beta
Además de los roles de usuario existentes de "Usuario de la empresa", "Administrador de operaciones", "Administrador de la organización" y "Usuario", esta versión incluye una función beta que te permite crear roles personalizados en la IU de administración. Puedes controlar el acceso a varias funciones de Edge con roles personalizados.
Nota: No se proporciona documentación con esta versión beta. Usa la siguiente guía para trabajar con roles personalizados.
- Para crear un rol personalizado, selecciona Administrador > Roles de la organización en la IU de administración.
- Para asignar roles a diferentes recursos en la IU de administración, haz clic en el botón Roles junto a un recurso.
- Usa la API existente de Roles del usuario para trabajar con roles personalizados de forma programática.
Instalador de Advanced API Services (anteriormente App Services)
Advanced API Services (anteriormente App Services) de Apigee Edge ahora está disponible para su uso en las instalaciones. El instalador de Edge existente te permite implementar y configurar servicios de API avanzados en tu propio entorno local.
Instalador de monetización de los servicios para desarrolladores (anteriormente, Monetization Services)
La función de monetización forma parte de los servicios para desarrolladores de Edge. El instalador de Edge en las instalaciones ahora incluye un instalador de monetización integrado y mejorado. La monetización requiere una licencia pagada adicional.
Varios procesadores de mensajes en un solo host: instalación silenciosa
Esta mejora admite la topología de implementación de varios procesadores de mensajes instalados en un solo host, lo que requiere vincular cada procesador de mensajes a una dirección IP específica. Ahora puedes agregar un parámetro de configuración de la propiedad BIND_ON_ALL_INTERFACES=n en el archivo de configuración de la instalación silenciosa, lo que hace que un procesador de mensajes escuche una dirección IP específica, especificada por la propiedad HOSTIP en el mismo archivo. Para obtener más información sobre esta propiedad y sobre la configuración de la instalación silenciosa, consulta la Guía de instalación y configuración del kit de implementación local de Apigee.
Actualizaciones de JMS
Esta versión incluye varias actualizaciones de la compatibilidad de Apigee con JMS, como las siguientes:
- Todos los encabezados JMS ahora se propagan como encabezados HTTP para el procesamiento descendente.
- Ahora puedes especificar ExpiryTime y DeliveryMode para los mensajes que se colocan en la fila ResponseQueue que usa el proxy de JMS. Todos los encabezados HTTP que coincidan con los encabezados JMS estándar se configuran "tal como están", y otros encabezados HTTP se configuran como propiedades JMS en el mensaje de respuesta que usa el proxy JMS.

Fallas corregidas

Tema	Descripción
Permisos de roles personalizados	Los permisos establecidos con roles personalizados ahora funcionan según lo esperado.
Estadísticas de latencia de la API	En un flujo de proxy de API, cuando una llamada al sistema de destino genera un tiempo de espera (como un tiempo de espera de lectura HTTP), los tiempos de latencia objetivo se incluyen en las estadísticas de la API.
Atributo "type" en las políticas	El atributo "type" ahora funciona correctamente en todas las políticas de Apigee.
Invalidación de tokens de OAuth 2.0	La funcionalidad de invalidación de tokens para las políticas de OAuth 2.0 de Apigee ahora coincide con la especificación de OAuth. Ya no es necesario que proporciones un "tipo" cuando configures el parámetro "token".
RBAC con mapas clave-valor	El control de acceso basado en roles ahora funciona para los mapas clave-valor creados a nivel del entorno.
Formato de respuesta de la política de OAuth 1.0a	Cuando se realizan solicitudes a una API con una política de OAuth 1.0a, la respuesta ahora se muestra en el formato del encabezado Accept.

Problemas conocidos

Tema Descripción

Tema	Descripción
Solicitud HTTP 1.0, Respuesta HTTP 1.1	Este problema implica una situación en la que un cliente envía una solicitud con HTTP 1.0 con la propiedad `content-length` en el encabezado, pero el servicio de backend está configurado para usar HTTP 1.1 y, en su lugar, muestra una propiedad `transfer-encoding` para la codificación por fragmentos. Para controlar correctamente esta situación, puedes quitar la propiedad `transfer-encoding` de la respuesta HTTP 1.1 con la política AssignMessage. En la siguiente política, que se adjuntaría al flujo de respuesta del proxy de API, se quita la propiedad `transfer-encoding` del encabezado HTTP, lo que permite que el cliente reciba la respuesta sin dividir. <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>

Solicitud HTTP 1.0,
Respuesta HTTP 1.1

Este problema implica una situación en la que un cliente envía una solicitud con HTTP 1.0 con la propiedad content-length en el encabezado, pero el servicio de backend está configurado para usar HTTP 1.1 y, en su lugar, muestra una propiedad transfer-encoding para la codificación por fragmentos.

Para controlar correctamente esta situación, puedes quitar la propiedad transfer-encoding de la respuesta HTTP 1.1 con la política AssignMessage. En la siguiente política, que se adjuntaría al flujo de respuesta del proxy de API, se quita la propiedad transfer-encoding del encabezado HTTP, lo que permite que el cliente reciba la respuesta sin dividir.

</Headers>

</Remove>

<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>

</AssignMessage>