Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

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

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

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

Si tienes preguntas, comunícate con el equipo de asistencia de Apigee Edge.

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

14.02.19

Nuevas funciones y mejoras

Actualiza los atributos personalizados de los tokens de OAuth 2.0
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 establecer 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 variables de flujo
Apigee Edge ahora te permite propagar y acceder a la información de SSL en variables de flujo. Si estableces una nueva propiedad “propagate.additional.ssl.headers” en un ProxyEndpoint, tendrás acceso a la misma información de SSL disponible en un servidor web Apache.
http://apigee.com/docs/api-services/api/variables-reference
Encabezados de JMS como encabezados HTTP
Ahora, todos los encabezados de JMS se propagan como encabezados HTTP para el procesamiento de nivel inferior.
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, volos-quota-apigee 0.0.2.
Roles personalizados en la IU de administración (BETA)
Además de los roles de usuario existentes de “Usuario empresarial”, “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 Roles botón junto a un recurso.
- Usa la API de roles de usuario existente para trabajar con roles personalizados de forma programática.
Instalador de Advanced API Services (antes App Services)
Apigee Edge Advanced API Services (antes App Services) ahora está disponible para su uso de forma local. El instalador de Edge existente te permite implementar y configurar Advanced API Services en tu propio entorno local.
Instalador de Developer Services monetization (antes Monetization Services)
La capacidad de monetización forma parte de Edge Developer Services. El instalador local de Edge 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 propiedad BIND_ON_ALL_INTERFACES=n en el archivo de configuración de 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 cómo configurar 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 con JMS de Apigee, incluidas las siguientes:
- Ahora, todos los encabezados de JMS se propagan como encabezados HTTP para el procesamiento de nivel inferior.
- Ahora puedes especificar ExpiryTime y DeliveryMode para los mensajes colocados en ResponseQueue que usa el proxy de JMS. Todos los encabezados HTTP que coinciden con los encabezados JMS estándar se establecen “tal como está”, y otros encabezados HTTP se establecen como propiedades de JMS en el mensaje de respuesta que usa el proxy de JMS.

Fallas corregidas

Tema	Descripción
Permisos de roles personalizados	Los permisos establecidos con roles personalizados ahora funcionan como se espera.
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 agotado (como un tiempo de espera de lectura HTTP), los tiempos de latencia de destino incluidos 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.
Tokens de invalidación de OAuth 2.0	La funcionalidad de tokens de invalidación para las políticas de OAuth 2.0 de Apigee ahora coincide con la especificación de OAuth. Ya no es necesario proporcionar un “tipo” cuando se establece el parámetro “token”.
RBAC con mapas de clave-valor	El control de acceso basado en roles ahora funciona para los mapas de 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 fragmentada. 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 fragmentar. <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 fragmentada.

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 fragmentar.

</Headers>

</Remove>

<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>

</AssignMessage>