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:

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

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

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 5000 eventos por segundo, pero es posible que algunos sistemas externos o API no tengan un rendimiento equivalente. Para evitar la sobrecarga de estos sistemas, puede utilizar el Límite y Aceleración API 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 limitación de 200 llamadas por segundo para su 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.

IMPORTANT
Reglas de límite se configuran en el nivel de entorno limitado, para un punto de conexión específico (la dirección URL llamada ) pero son globales para todos los recorridos de dicho entorno limitado. El límite está disponible tanto en fuentes de datos como en acciones personalizadas.
Las Reglas de limitación solo están configuradas en zonas protegidas de producción, para un extremo específico, pero de forma global para todos los recorridos de todas las zonas protegidas. Solo puede tener una configuración de restricción por organización. La restricción solo está disponible en acciones personalizadas.
El maxCallsCount el valor debe ser mayor que 1.

Para obtener más información sobre cómo trabajar con las API, consulte estas secciones:

Una descripción detallada de las API está disponible en Documentación de 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.

NOTE
Si una fuente de datos utiliza una autenticación personalizada con un extremo diferente al que se usa para la fuente de datos, debe ponerse en contacto con Adobe para incluir en la lista de permitidos también este.

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 puede admitir 200, debe definir una configuración de límite o de limitación para que el sistema no se sature. Obtenga información sobre cómo configurar acciones

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

¿Cómo puedo configurar una regla de restricción o límite? ¿Existe una regla predeterminada?

De forma predeterminada, no hay ninguna regla de restricción o límite. Las reglas se definen a nivel de zona protegida para un extremo específico (la dirección URL llamada ), mediante la API de límite o limitación. Consulte esta sección.

¿Cuántos reintentos se realizan? ¿Puedo cambiar el número de reintentos o definir un período de espera mínimo entre reintentos?

Para una llamada determinada, se puede realizar un máximo de tres reintentos después de la primera llamada, hasta que se alcance el final de la duración del tiempo de espera. No se puede cambiar el número de reintentos ni el tiempo entre cada reintento. Consulte esta sección.

¿Dónde puedo configurar el tiempo de espera? ¿Hay un valor máximo?

En cada recorrido, puede definir una duración de tiempo de espera. La duración del tiempo de espera se configura en las propiedades de un recorrido. La duración del tiempo de espera debe estar entre 1 segundo y 30 segundos. Consulte esta sección y esta página.

recommendation-more-help
b22c9c5d-9208-48f4-b874-1cefb8df4d76