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 consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X. Información

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 compartidos y hooks de flujo para poner en funcionamiento los proxies de API (solo versión beta por solicitud)

Una nueva función de “Flujos compartidos” te permite poner en funcionamiento la funcionalidad en los proxies de API. Si combinas políticas y recursos condicionalizados en un flujo compartido, puedes hacer referencia a él desde cualquier proxy de API para ejecutar lógica reutilizable de fuente única. Por ejemplo, un flujo compartido podría verificar la clave de API, proteger contra detenciones por picos de tráfico y registrar datos.

Los flujos compartidos se definen en la IU de administración (API > Flujos compartidos) y, luego, se hace referencia a ellos de dos maneras diferentes:

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

Mapas de valores de clave 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 existente de Edge (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 Management). Puedes acceder a los valores encriptados de KVM con Node.js o con la política de operaciones de asignación de pares clave-valor.

Crea KVM encriptados

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

Usa KVMs encriptados

Usa la política de operaciones de asignación de pares clave-valor para obtener y actualizar valores encriptados de KVM.
Cuando obtengas un valor de clave encriptado, agrega el prefijo “private” a la variable para que contenga el valor. 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 encriptados.
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 un 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 clave y get(key, callback) para 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 asignación de pares clave-valor intenta PUT una nueva clave-valor 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. A medida que se intentan nuevas PUT con claves nulas, solo se usa esa clave, por lo que es posible que los valores existentes para esa clave se reemplacen cada vez que se ejecute la política.

El comportamiento anterior de una clave nula era que la clave-valor no se agregara a KVM. En cambio, la entrada permaneció en la caché de la memoria del procesador de mensajes y estuvo disponible de forma temporal para las operaciones Get posteriores. Si la implementación de tu política 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 (anterior) que se crea para las claves nulas. (APIRT-3530).

Advertencia:

Validación de políticas en 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 realizó correctamente con un código de estado HTTP de 200, incluso si las políticas enumeradas en los pasos de FaultRule no existían y el error de 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 fallas de implementación si FaultRules hace referencia a políticas que no existen. (MGMT-3354)

URLs de OpenAPI Spec 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 esta especificación 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 del proxy, los metadatos incluyen la ruta de acceso a la especificación 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 nueva generación de Edge, que vincula las especificaciones de OpenAPI a proxies de API, productos de API y documentos de referencia de la 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 parámetro de prefijo nuevo te permite especificar el prefijo de la caché (si la caché está configurada para usar <CacheKey>/<Prefix>, como se describe en Propagar política de 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 recuperarla. (APIRT-3262).

Control de IP de cliente con Sense

A fin de controlar con mayor precisión dónde encontrar las 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 del cliente con una variable additionalIPVars. Por ejemplo, puedes configurar additionalIPVars para que use el encabezado true-client-ip, que contiene la IP correcta de Akamai a fin de evaluar en 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 las solicitudes de oferta del servicio de JavaScript
APIRT-3408	Versión de MP 160817: El módulo de estadísticas de Apigee-access procesa los mensajes de manera diferente
APIRT-3390	Cambio en la respuesta a errores que muestra la política de token 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 arrojado por las operaciones de la política de OAuthV2 GenerateAccessToken y RefreshAccessToken cuando la propiedad <GenerateResponse> de la política OAuthV2 se establece en false: `{"ErrorCode" : "invalid_client", "Error" :"Client identifier is required"}` se cambió por: `{"ErrorCode" : "InvalidClientIdentifier", "Error" :"Client identifier is required"}` Se recomienda que cambies las condiciones de las reglas de fallas que detecten "`invalid_client`" para detectar el código antiguo y el nuevo. Por ejemplo, en la regla de fallas, cambia lo siguiente: `(fault.name = "invalid_client")` a esto: `(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")`
APIRT-3389	Advertencia: Error al subir 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	Altas latencias en los proxies de producción del cliente
APIRT-3366	Las políticas de JavaScript fallan en todas las organizaciones de prueba nuevas
APIRT-3363	El análisis de la URL no válida muestra un estado 500 con ApplicationNotFound
APIRT-3356	Mensaje de token de OAuth no válido
APIRT-3355	Error 403 intermitente en el proxy de OAuth
APIRT-3285	Advertencia: Vencimiento incoherente del token de OAuth2 Cuando se genera un token de OAuth con la política de OAuth v2.0, puedes establecer el vencimiento del token por referencia o por un valor predeterminado hard-coded. Por ejemplo: `<ExpiresIn ref="kvm.oauth.expires_in">1800000</ExpiresIn>`. La primera vez que se estableció el vencimiento del token por referencia, Edge almacenó y usó ese valor para cada vencimiento de token nuevo. Este error se corrigió para que use el valor de referencia o, si no se proporciona, el vencimiento predeterminado que se define 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 más errores de tokens no válidos, que pueden requerir que implementes actualizaciones de tokens más frecuentes o que cambies el vencimiento predeterminado en tus políticas de OAuth.
APIRT-3261	Las credenciales se validan con otras apps 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 la transferencia a ASG
APIRT-3152	la llamada de administración de cachedlogs provoca que los mensajes de registro se dividan
APIRT-3117	El 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-2620	Conjunto de subprocesos independiente para algunos pasos de bloqueo a fin de mejorar el control de cargas
CORESERV-774	El acceso con una clave válida con una referencia de apiproduct no válida genera un error interno del servidor