Integración con sistemas externos external-systems
Esta página presenta las diferentes protecciones proporcionadas por Journey Optimizer al integrar un sistema externo, así como las prácticas recomendadas: cómo optimizar la protección del sistema externo mediante la API de límite, cómo configurar el tiempo de espera de recorrido y cómo funcionan los reintentos.
Journey Optimizer le permite configurar conexiones a sistemas externos mediante fuentes de datos y acciones personalizadas. Esto le permite, por ejemplo, enriquecer sus recorridos con datos procedentes de un sistema de reservas externo o enviar mensajes mediante un sistema de terceros como Epsilon o Facebook.
Al integrar un sistema externo, puede encontrar varios problemas, el sistema puede ser lento, puede dejar de responder o es posible que no pueda gestionar un volumen grande. Journey Optimizer ofrece varias protecciones para proteger el sistema de la sobrecarga.
Todos los sistemas externos son diferentes en términos de rendimiento. Debe adaptar la configuración a sus casos de uso.
Cuando Journey Optimizer ejecuta una llamada a una API externa, las protecciones técnicas se ejecutan de la siguiente manera:
-
Se aplican reglas de límite o restricción: si se alcanza la tasa máxima, las llamadas restantes se descartan o se ponen en cola.
-
Tiempo de espera y reintento: si se cumple la regla de límite o regulación, Journey Optimizer intenta realizar la llamada hasta que se alcanza el final de la duración del tiempo de espera.
cacheDuration , especialmente en cargas de trabajo pesadas, para evitar discrepancias de caducidad y errores 401.API de límite y restricción capping
Acerca de las API de restricción y límite
Al configurar una fuente de datos o una acción, se establece una conexión con un sistema para recuperar información adicional que se utilizará en los recorridos o enviar mensajes o llamadas de API.
Las API de recorridos admiten hasta 5.000 eventos por segundo, pero es posible que algunos sistemas externos o API no tengan un rendimiento equivalente. Para evitar sobrecargar estos sistemas, puede usar las API Límite y Aceleración para limitar el número de eventos enviados por segundo.
Cada vez que recorrido realiza una llamada a la API, esta pasa por el motor de API. Si se alcanza el límite establecido en la API, la llamada se rechaza si se utiliza la API de límite, o se pone en cola durante un máximo de 6 horas y se procesa lo antes posible en el orden en que se recibió si se utiliza la API de limitación.
Por ejemplo, supongamos que ha definido una regla de límite o restricción de 200 llamadas por segundo para el sistema externo. Una acción personalizada llama al sistema en 10 recorridos diferentes. Si un recorrido recibe 300 llamadas por segundo, utilizará las 200 ranuras disponibles y descartará o pondrá en cola las 100 restantes. Como la velocidad máxima se ha superado, los otros 9 recorridos no tendrán ninguna ranura. Esta granularidad ayuda a proteger el sistema externo de sobrecargas y caídas.
Para obtener más información sobre cómo trabajar con las API, consulte estas secciones:
Hay disponible una descripción detallada de las API en Documentación de las API de Adobe Journey Optimizer
Capacidad de fuentes de datos y acciones personalizadas capacity
Para fuentes de datos externas, el número máximo de llamadas por segundo está limitado a 15. Si se supera este límite, las llamadas adicionales se descartan o se ponen en cola según la API en uso. Es posible aumentar este límite para las fuentes de datos externas privadas poniéndose en contacto con Adobe para incluir en la lista de permitidos el extremo, pero esto no es una opción para las fuentes de datos externas públicas. * Obtenga información sobre cómo configurar fuentes de datos.
Para acciones personalizadas, debe evaluar la capacidad de su API externa. Por ejemplo, si Journey Optimizer envía 1000 llamadas por segundo y el sistema solo admite 200 llamadas por segundo, debe definir una configuración de límite o restricción para que el sistema no se sature. Obtenga información sobre cómo configurar acciones
Extremos con tiempo de respuesta lento response-time
Cuando un extremo tiene un tiempo de respuesta mayor de 0,75 segundos, sus llamadas de acción personalizadas se enrutan a través de un servicio de acción personalizada lenta dedicado en lugar del servicio predeterminado.
Este servicio de acción personalizada lenta aplica un límite de 150 000 llamadas cada 30 segundos. El límite se aplica mediante una ventana deslizante, que puede comenzar en cualquier milisegundo dentro de ese período de 30 segundos. Una vez que la ventana está llena, las llamadas adicionales se rechazan con errores de límite. El sistema no espera al siguiente intervalo fijo, pero comienza la restricción inmediatamente después de alcanzar el umbral de 30 segundos.
Dado que los extremos lentos pueden causar retrasos en todas las acciones en cola de la canalización, se recomienda no configurar acciones personalizadas con extremos que tengan tiempos de respuesta lentos. El enrutamiento de estas acciones al servicio lento ayuda a proteger el rendimiento general del sistema y evita una latencia adicional para otras acciones personalizadas.
Tiempo de espera y reintentos timeout
Si se cumple la regla de límite o restricción, se aplica la regla de tiempo de espera.
En cada recorrido, puede definir una duración de tiempo de espera. Esto le permite establecer una duración máxima al llamar a un sistema externo. La duración del tiempo de espera se configura en las propiedades de un recorrido. Consulte esta página.
Este tiempo de espera es global para todas las llamadas externas (llamadas a API externas en acciones personalizadas y fuentes de datos personalizadas). De forma predeterminada, se establece en 30 segundos.
Durante el tiempo de espera definido, Journey Optimizer intenta llamar al sistema externo. Después de la primera llamada, se puede realizar un máximo de tres reintentos hasta que se alcance el final de la duración del tiempo de espera. No se puede cambiar el número de reintentos.
Cada reintento utiliza una ranura. Si tiene un límite de 100 llamadas por segundo y cada una de las llamadas requiere dos reintentos, la tasa cae a 30 llamadas por segundo (cada llamada utiliza 3 ranuras: la primera llamada y dos reintentos).
El valor de duración del tiempo de espera depende del caso de uso. Si desea enviar el mensaje rápidamente, por ejemplo, cuando el cliente entra en el almacén, no desea configurar un tiempo de espera largo. Además, cuanto más tiempo de espera sea, más elementos se pondrán en cola. Esto puede afectar en gran medida al rendimiento. Si Journey Optimizer realiza 1000 llamadas por segundo, mantener 5 o 15 segundos de datos puede saturar rápidamente al sistema.
Veamos un ejemplo para un tiempo de espera de 5 segundos.
-
La primera llamada dura menos de 5 segundos: la llamada se realiza correctamente, no se realiza ningún reintento.
-
La primera llamada dura más de 5 segundos: la llamada se cancela y no hay reintento. Se cuenta como un error de tiempo de espera en los informes.
-
La primera llamada falla después de 2 segundos (el sistema externo devuelve un error): quedan 3 segundos para los reintentos, si están disponibles los espacios de límite.
- Si uno de los tres reintentos se realiza correctamente antes del final de los 5 segundos, se realiza la llamada y no hay ningún error.
- Si se alcanza el final de la duración del tiempo de espera durante los reintentos, la llamada se cancela y se cuenta como un error de tiempo de espera en el sistema de informes.
Preguntas frecuentes faq
A continuación, encontrará las preguntas más frecuentes sobre la integración de Journey Optimizer con sistemas externos.
¿Necesita más información? Use las opciones de comentarios situados en la parte inferior de esta página para plantear su pregunta o conecte con la comunidad de Adobe Journey Optimizer.
El proxy de salida proporciona una dirección IP estática para las llamadas salientes de Journey Optimizer a los sistemas externos. Utilícelo cuando los puntos de conexión de terceros requieran una inclusión en la lista de permitidos IP.
Importante: El proxy de salida NO controla el rendimiento, los límites de velocidad ni el número de conexiones simultáneas. Para administrar el volumen de llamadas y los límites de conexión, usa la API de límite o la API de restricción.
Usar proxy de salida para:
- Inclusión en la lista de permitidos de una IP estática en el firewall o extremo de terceros
Usar API de límite/restricción para:
- Limitación del número de llamadas de API por segundo
- Control de conexiones simultáneas al punto final
- Protección del sistema externo frente a sobrecargas
Póngase en contacto con Adobe para habilitar el proxy de salida para su organización si necesita una IP estática para fines de inclusión en la lista de permitidos.
Con el proxy IP habilitado y una configuración de restricción definida en el punto de conexión de destino, el número de conexiones se basa en la velocidad (son estimaciones, no números garantizados):
- entre 200 y 2000 c/s: 50 conexiones
- entre 2000 y 3000: 75 conexiones
- entre 3000 y 4000: 100 conexiones
- entre 4000 y 5000: 125 conexiones
Si no se define ninguna configuración de restricción en un punto de conexión, el motor de Journey Optimizer está diseñado para ampliarse y puede llegar a un número elevado de conexiones (más de 2000). Para obtener un número limitado de conexiones, los clientes deben utilizar una configuración de regulación.