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

16.09.21: Notas de la versión de Apigee Edge para la nube pública

Estás viendo la documentación de Apigee Edge.
Consulta la documentación de Apigee X.

El jueves 13 de octubre de 2016, comenzamos a lanzar una nueva versión de Apigee Edge para la nube pública.

Nuevas funciones y actualizaciones

A continuación, presentamos las nuevas funciones y actualizaciones de esta versión.

Flujos y hooks de flujo compartidos para poner en funcionamiento proxies de API (solo solicitud por versión beta)

Una nueva función de "flujos compartidos" le permite poner en funcionamiento la funcionalidad en proxies de API. Cuando combinas políticas y recursos condicionales en un flujo compartido, puedes hacer referencia a este desde cualquier proxy de API para ejecutar una lógica reutilizable de fuente única. Por ejemplo, un flujo compartido puede verificar la clave de API, protegerse contra los ataques de aumentos de actividad y registrar datos.

Debes definir los flujos compartidos en la IU de administración (API > Flows compartidos) y, luego, hacer referencia a ellos de dos maneras diferentes:

Con una nueva política de texto destacado de flujo en un proxy de API
o
En un artefacto nuevo llamado Hooks de flujo, que se encuentra en las siguientes ubicaciones:
- Solicitud: Antes del flujo previo al proxy, después del PostFlow de TargetEndpoint.
- Respuesta: Antes del TargetFlow PreFlow, después del PostFlow de ProxyEndpoint
Estos puntos de acoplamiento te permiten ejecutar la lógica operativa antes o después de los puntos de flujo principales del proxy individual. Puedes asignar flujos compartidos a estas ubicaciones de enlace de flujo en la IU de administración (API > Configuración del entorno > Enlaces de flujo).

Mapas de par clave-valor encriptados

Puedes crear mapas de clave-valor (KVM) encriptados para almacenar información sensible, como credenciales o datos de PII/HIPAA. Esta función es diferente del almacén seguro de Edge existente (vault) y está diseñada para reemplazarla, ya que solo se puede acceder a los valores de Vault con Node.js (además de la API de administración). Puedes acceder a valores de KVM encriptados con Node.js o la política de Operaciones de mapas de valores.

Crea KVMs encriptadas

Usar las API de KVM existentes Cuando incluyes “encrypted”: “true” en la definición de la carga útil cuando creas una KVM, Edge encripta la KVM y genera una clave de encriptación que tiene el mismo alcance que la KVM.
No puedes usar la política de operaciones de mapas de pares clave-valor para crear una KVM encriptada.
No puedes encriptar un KVM existente no encriptado.

Usa KVMs encriptados

Usa la política de operaciones de mapas de par clave-valor para obtener y actualizar valores de KVM encriptados.
Cuando obtenga un valor de clave encriptada, prefija la variable para que contenga el valor "private". Por ejemplo: <Get assignTo="private.secretVar">. Esa variable private.secretVar contiene el valor desencriptado.
Cuando actualizas un valor con la política, no necesitas hacer nada especial. El valor se encriptará automáticamente en KVM encriptadas.
También puede acceder al valor desencriptado con el módulo apigee-access en el código de Node.js. Usa la función getKeyValueMap() para recuperar una KVM según el nombre y el alcance. Hay dos funciones disponibles en el objeto que se muestra: getKeys(callback) para obtener un array de nombres de claves y get(key, callback) a fin de obtener el valor de una clave en particular. Por ejemplo:
```
var apigee = require('apigee-access');
  var encryptedKVM = apigee.getKeyValueMap('VerySecureKVM', 'apiproxy'); 
  encryptedKVM.get('secret1', function(err, secretValue) { 
  // use the secret value here 
});
```

(APIRT‐1197)

Advertencia:

Operaciones PUT de KVM con claves nulas

Si una política de operaciones de mapa de pares clave-valor intenta PUT una clave-valor nueva en un mapa de clave-valor (KVM) con una clave nula, se crea automáticamente la siguiente clave: __$$_EDGE_KVM_EMPTY_KEY_$$__

Esta situación ocurriría, por ejemplo, si propagas una clave con una referencia de variable y la variable a la que se hace referencia es nula. Como se intentan nuevas PUT con claves nulas, solo se usa esa clave, por lo que los valores existentes para esa clave pueden reemplazarse cada vez que se ejecute la política.

El comportamiento anterior para una clave nula fue que la clave/valor no se agregó a KVM. En su lugar, la entrada permaneció en la caché en la memoria del procesador de mensajes y estuvo disponible temporalmente para las operaciones Get posteriores. Si tu implementación de políticas de KVM se basa en el comportamiento anterior, las operaciones Get en claves nulas ahora fallarán porque no hacen referencia al nuevo nombre de clave (arriba) que se crea para claves nulas. (APIRT‐3530)

Advertencia:

Validación de las políticas en los pasos de FaultRule antes de la implementación

Durante la implementación del proxy de API, Edge ahora valida las políticas enumeradas en los pasos de FaultRule antes de la implementación. Antes de esta corrección, la implementación se realizaba correctamente con un código de estado HTTP de 200, incluso si las políticas que se indicaban en los pasos de FaultRule no existían y el error InvalidPolicyReference no se producía hasta el tiempo de ejecución. Ahora se muestra un estado HTTP 400 junto con un error InvalidPolicyReference durante la implementación. Si usas secuencias de comandos para implementar proxies de API, ahora verás errores de implementación si las políticas de referencia de FaultRules no existen. (MGMT‐3354)

URLs de especificaciones de OpenAPI incluidas en los metadatos del proxy de API

Cuando creas un proxy de API basado en una especificación de OpenAPI, la ubicación de las especificaciones de OpenAPI se almacena en los metadatos del proxy de API. Por ejemplo, si usas la API de administración para obtener los detalles de una revisión de proxy, los metadatos incluyen la ruta de acceso a las especificaciones de OpenAPI en el siguiente formato:

"spec" : "https://raw.githubusercontent.com/apigee/api-platform-samples/master/default-proxies/helloworld/openapi/mocktarget.yaml"

Esta mejora admite la versión de próxima generación de Edge, que vincula las especificaciones de OpenAPI con los proxies de API, los productos de API y los documentos de referencia de API en el nuevo portal para desarrolladores. (MGMT-2913)

Advertencia:

Nuevo parámetro de prefijo para Node.js getCache()

Cuando se obtiene una caché perimetral en Node.js con la función getCache() del módulo apigee-access, un nuevo parámetro de prefijo te permite especificar el prefijo de la caché (si la caché está configurada para usar <CacheKey>/<Prefix>, como se describe en la política de almacenamiento en caché). Por ejemplo:

var cache = apigee.getCache('Cache1', {resource: 'Cache1', scope: 'global', prefix: 'UserToken__'});

Anteriormente, si una caché incluía un prefijo de clave de caché, la función getCache() no podía recuperar la caché. (APIRT‐3262)

Control de IP de cliente con Sense

A fin de controlar con mayor precisión dónde encontrar direcciones IP para la detección de bots de Sense cuando se usan productos de enrutamiento como Akamai, Sense te permite definir la ubicación de la IP de cliente con una variable additionalIPVars. Por ejemplo, puedes configurar additionalIPVars para usar el encabezado true-client-ip, que contiene la IP correcta de Akamai a fin de evaluar las reglas del bot. (APIRT‐3332)

Fallas corregidas

En esta versión, se corrigieron los siguientes errores. Esta lista está dirigida principalmente a usuarios que verifican si sus tickets de asistencia se corrigieron. No está diseñada para proporcionar información detallada a todos los usuarios.

ID del problema	Descripción
APIRT‐3507	Errores intermitentes (como errores de SNI) en los textos destacados del servicio de JavaScript
APIRT‐3408	Versión de módulo 160817 del módulo de estadísticas de Apigee de acceso que procesa los mensajes de manera diferente
APIRT‐3390	Cambio en la respuesta de errores que muestra la política de tokens de acceso de actualización Advertencia: Cambio en el código de error de OAuthV2 "invalid_client". Ten en cuenta el siguiente cambio en un código de error que arrojan las operaciones de la política de OAuthV2: GenerateAccessToken y RefreshAccessToken cuando la propiedad <GenerateResponse> de la política de OAuthV2 se configura como false: `{"ErrorCode" : "invalid_client", "Error" :"Client identifier is required"}` se cambió a: `{"ErrorCode" : "InvalidClientIdentifier", "Error" :"Client identifier is required"}` Se recomienda que cambies las condiciones de las reglas de fallas que atrapen "`invalid_client`" para captar tanto el código antiguo como el nuevo. Por ejemplo, en tu regla de errores, cambia lo siguiente: `(fault.name = "invalid_client")` a esto: `(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")`
APIRT‐3389	Advertencia: Se produjo un error cuando se cargaban cargas útiles de Node.js de más de 25 KB Ahora se permite subir cargas útiles de Node.js de más de 25 KB.
APIRT‐3381	Latencias altas en los proxies de producción del cliente
APIRT‐3366	Las políticas de JavaScript fallan en todas las organizaciones nuevas de prueba
APIRT‐3363	El análisis de URL no válido muestra un estado 500 con ApplicationNotFound
APIRT‐3356	Mensaje de token no válido de OAuth
APIRT‐3355	Error intermitente 403 en el proxy de OAuth
APIRT‐3285	Advertencia: El vencimiento del token OAuth2 no es coherente Cuando se genera un token de OAuth con la política de OAuth v2.0, puedes establecer su vencimiento como referencia o mediante un valor predeterminado hard-coded. Por ejemplo: `<ExpiresIn ref="kvm.oauth.expires_in">1800000</ExpiresIn>`. La primera vez que el vencimiento del token se configuró por referencia, Edge almacenó y usó ese valor para cada vencimiento del token nuevo. Este error se corrigió para usar el valor de referencia o, si no se proporcionó, el vencimiento predeterminado definido en la política. Esta corrección puede cambiar la duración de los vencimientos de los tokens, y es posible que experimentes efectos secundarios, como errores de tokens no válidos, que requieran que implementes actualizaciones de tokens más frecuentes o que cambies el vencimiento predeterminado de tus políticas de OAuth.
APIRT‐3261	Las credenciales se validan en comparación con otra aplicación para desarrolladores en producción
APIRT‐3234	La app de Node.js muestra NPE
APIRT‐3223	Problema de caché inactiva de Apigee
APIRT‐3193	El servidor de destino de Node.js se bloquea después de migrar a ASG
APIRT‐3152	La llamada de administración de cachelogs hace que se rompan los mensajes de registro.
APIRT‐3117	MP alcanzó el 100% de uso de CPU y dejó de entregar tráfico
APIRT‐3064	Router: Mensaje de error 503 personalizado del router
APIRT‐2,620	Grupo de subprocesos separado para algunos pasos de bloqueo a fin de mejorar el manejo de cargas
CORESERV‐774	El acceso con una clave válida con una referencia de apiproduct no válida genera un error de servidor interno