Servicio de Escucha Harmony de Jitterbit¶

Descripción General¶

El Harmony Listening Service de Jitterbit es un servicio de aplicación que se ejecuta en un Agente Privado y es consumido por ciertos conectores de Cloud Studio que tienen capacidades de escucha. El servicio de escucha proporciona manejo de eventos asincrónicos para las operaciones implementadas en el agente.

Conectores con Actividades de Escucha¶

Los siguientes conectores y actividades utilizan el servicio de escucha. Estas actividades se lanzan como una versión beta. Puede proporcionar comentarios sobre errores y mejoras sugeridas a través de su Administrador de éxito del cliente (CSM).

Requisitos Previos¶

Para utilizar una actividad de escucha, se requiere un Grupo de Agentes Privados con uno o más agentes. Las actividades de escucha no se pueden utilizar con los Grupos de Agentes en Nube de Jitterbit. No todos los conectores admiten el servicio de escucha.

Estos requisitos previos deben cumplirse cuando el Grupo de Agentes Privados contiene uno o varios agentes:

• El servicio de escucha debe estar habilitado en cada agente como se describe en Habilitar el servicio de escucha en el Agente abajo. Este es un paso manual en la configuración y no está habilitado de forma predeterminada.

Para Grupos de Agentes Privados que contienen varios agentes, se deben cumplir estos requisitos previos adicionales para que los agentes se comuniquen entre sí:

• La versión del agente debe ser 10.78 o superior (para Agentes Privados 10.x), o 11.8 o superior (para Agentes Privados 11.x).
• Todos los agentes deben tener estos puertos disponibles:
  • 5701
  • 5801
• Todos los agentes deben estar dentro del mismo grupo de red.
• Si hay \(N\) agentes en el grupo de agentes, al menos \((N/2) + 1\) debe estar ejecutándose para que funcione el servicio de escucha.
• Establecer el valor para agent.sdk_framework.listeners.eventsQueue en el de cada agente jitterbit-agent-properties.config archivo debe ser menor o igual que el número de núcleos de procesador en el servidor alojar del agente. Alternativamente, establezca agent.sdk_framework.listeners.matchEventsQueueToAvailableCores a true.

Una vez que se implementa una operación, el proyecto de Cloud Studio debe tener el servicio de escucha habilitado tanto en el nivel de operación como en el nivel de actividad como se describe en Habilitar el servicio de escucha en la operación y actividad abajo. Este es un paso manual que se realiza en el momento del diseño o gestión del proyecto.

Habilite el Servicio de Escucha en el Agente¶

El servicio de escucha está deshabilitado de forma predeterminada en el agente y debe habilitarse manualmente siguiendo estos pasos:

1. En cada Agente Privado, abra jitterbit-agent-config.properties en un editor de texto.

   Este archivo se encuentra en <JITTERBIT_HOME>/Resources/, dónde <JITTERBIT_HOME> se reemplaza con el directorio raíz del Agente Privado.

2. Agregue esta línea al archivo para habilitar el marco de escucha:

   agent.sdk_framework.listener.enabled=true
   

3. Reiniciar el agente.

Habilitar el Servicio de Escucha en la Operación y Actividad¶

El servicio de escucha debe estar habilitado tanto en la operación como en la actividad de escucha. El servicio se puede alternar en el nivel de operación desde la operación de Cloud Studio o en el nivel de operación o actividad desde la página Proyectos de Management Console como se describe a continuación.

Operación de Cloud Studio¶

Una vez que se implementa una operación con una actividad de escucha, aparece un botón Eventos deshabilitados en la parte inferior de la operación en el tela de diseño. De forma predeterminada, la escucha de eventos está deshabilitada.

Para habilitar la escucha de eventos para la operación, haga clic en el botón de alternancia:

Esta acción también permitirá la escucha de eventos en cualquier actividad de escucha que contenga, como lo indica el color del icono del oyente en la parte superior derecha de la actividad:

• Un icono de oyente verde indica que la escucha está habilitada para esta actividad.
• Un ícono de oyente gris indica que la escucha no está habilitada para esta actividad.

Al deshabilitar la escucha de eventos en una operación, también se deshabilita la escucha de eventos en cualquier actividad de escucha que contenga. Los eventos recibidos pero aún no procesados cuando la escucha está desactivada no se pierden y se procesan normalmente.

Página de Proyectos de la Management Console¶

Una vez que se implementa una operación con una actividad de escucha, la operación y sus actividades de escucha se muestran en la Management Console Proyectos página en Oyentes pestaña:

• Buscar: Ingrese cualquier parte de la actividad, nombre de la operación o estado del oyente en el cuadro de búsqueda para filtrar la lista de actividades de escucha. La búsqueda no distingue entre mayúsculas y minúsculas.

• Actualizar: Haga clic en el ícono Actualizar para actualizar la lista de actividades de escucha.

• Actividad: El nombre de la actividad de escucha utilizando una forma abreviada del tipo de actividad del conector seguida del nombre de la conexión proporcionada por el usuario.

  Nota

  No se muestra el nombre de la actividad de escucha proporcionado por el usuario.

  Haga clic en el triángulo desplegable junto a la actividad para revelar los nombres de cada operación en la que se utiliza la actividad.

• Estado del oyente: El estado de escucha se proporciona para cada actividad y operación. Haga clic para alternar el estado de escucha entre Activado (activado) y Desactivado (desactivado). Nota:

  • Deshabilitar la escucha de eventos para una actividad deshabilitará automáticamente la escucha de todas las operaciones en las que se utiliza. Sin embargo, habilitar la escucha de eventos para una actividad no afecta el estado de las operaciones en las que se utiliza.
  • Las operaciones se pueden habilitar y deshabilitar para escuchar eventos individualmente.
  • El cambio de estado se sincroniza con la interfaz de usuario de Cloud Studio en ambas direcciones. Es decir, alternar el estado de escucha en Management Console afecta el estado en Cloud Studio. De manera similar, habilitar o deshabilitar eventos en una operación de Cloud Studio afecta el estado en Management Console. Es posible que sea necesaria una actualización para actualizar la pantalla.

Arquitectura del Sistema¶

Este diagrama muestra cómo se mueve un mensaje de evento a través de la arquitectura del sistema cuando se utiliza un único Agente Privado:

1. Se implementa y habilita para escucha una operación que contiene un conector configurado con una actividad de escucha de eventos. Una actividad de escucha se puede utilizar en muchas operaciones y proyectos para recibir el mismo evento pero procesarlo de manera diferente.
2. El servicio de escucha dentro del agente iniciará un escucha para esa operación.
3. El oyente comenzará a escuchar activamente cualquier notificación de evento desde el extremo.
4. Cuando ocurre un evento en el extremo, publica una notificación de evento que pueden recibir sus suscriptores.
5. El oyente recoge el mensaje de notificación del evento.
6. Si hay un agente en el grupo de agentes, el oyente transmite el mensaje de evento a la operación. Si el grupo de agentes contiene el número mínimo para permitir capacidades completas del servicio de escucha, el mensaje de evento se pasa al agente con la menor carga de trabajo.
7. Al recibir la notificación del evento, la operación desencadenará una operación abajo en la cadena.

Cuando el servicio de escucha está deshabilitado, los agentes de un grupo de agentes se comunican directamente con Harmony. Cuando está habilitado y hay una cantidad mínima de nodos de agentes activos, los agentes se comunican entre sí para formar un clúster. El primer agente registrado es designado líder del grupo. El líder es responsable de recibir mensajes y distribuirlos a los miembros del clúster para su procesamiento. El líder del clúster distribuye la carga entre todos los agentes y garantiza que dos agentes no procesen el mismo mensaje.

Persistencia¶

Los mensajes enviados a un agente se pueden almacenar en una base de datos. Si el agente falla, la base de datos proporciona un almacén persistente de mensajes que pueden reenviarse cuando el agente vuelve a estar en línea. La persistencia mediante el uso de la base de datos interna PostgreSQL está habilitada de forma predeterminada para los clústeres de agente único. Para clústeres con más de un agente, la persistencia se debe habilitar manualmente de la siguiente manera:

1. En cada Agente Privado, edite <JITTERBIT_HOME>/Resources/jitterbit-agent-config.properties dónde <JITTERBIT_HOME> se reemplaza con el directorio raíz del Agente Privado.

2. Agregue estas líneas al archivo:

   agent.sdk_framework.queueStore.enabled=true
   agent.sdk_framework.queueStore.type=dbinternal
   
   agent.sdk_framework.persistence.enabled=true
   agent.sdk_framework.persistence.type=dbinternal
   

3. Reiniciar el agente.

La configuración agent.sdk_framework.queueStore.type=dbinternal y agent.sdk_framework.persistence.type=dbinternal hacer que el agente utilice la base de datos local PostgreSQL para mensajes persistentes.

Para configurar una base de datos externa habilitada para JDBC o un servidor Redis, todos los agentes dentro del grupo de agentes deben usar la siguiente configuración, donde el usuario de la base de datos tiene permisos para crear, leer, actualizar y eliminar datos, y para crear tablas:

agent.sdk_framework.queueStore.enabled=true
agent.sdk_framework.queueStore.type=db

agent.sdk_framework.persistence.enabled=true
agent.sdk_framework.persistence.type=db

agent.sdk_framework.datastore.db.url=jdbc:sqlserver://harmony:1433;database=cloud
agent.sdk_framework.datastore.db.user=sa
agent.sdk_framework.datastore.db.password=******
agent.sdk_framework.datastore.db.databaseName=cloud
agent.sdk_framework.datastore.db.dialect=org.hibernate.dialect.SQLServerDialect
agent.sdk_framework.datastore.db.driver_class=com.microsoft.sqlserver.jdbc.SQLServerDriver

agent.sdk_framework.queueStore.enabled=true
agent.sdk_framework.queueStore.type=redis

agent.sdk_framework.persistence.enabled=true
agent.sdk_framework.persistence.type=redis

agent.sdk_framework.datastore.redis.url=redis://redis:6379

#Optional - pool configuration

agent.sdk_framework.datastore.redis.maxTotal=8
agent.sdk_framework.datastore.redis.maxIdle=8
agent.sdk_framework.datastore.redis.minIdle=0
agent.sdk_framework.datastore.redis.blockWhenExhausted=true
agent.sdk_framework.datastore.redis.maxWaitMillis=-1
agent.sdk_framework.datastore.redis.testOnBorrow=false
agent.sdk_framework.datastore.redis.testOnReturn=false
agent.sdk_framework.datastore.redis.jmxEnabled=true

Ejecute el siguiente comando en el servidor alojar del agente para obtener el estado del agente y el proceso de restauración:

curl localhost:46912/axis/v1/cdk/internal/members

Solución de Problemas¶

Mensaje No Entregado¶

El mecanismo de reintento de entrega de mensajes del clúster utiliza la siguiente configuración en el <JITTERBIT_HOME>/Resources/jitterbit-agent-config.properties archivo:

agent.sdk_framework.retry.deleteRetryableMessageAfter=60

Esta es la cantidad de minutos después de los cuales se elimina un mensaje reintentado.

Si se establece en -1, los mensajes nunca se eliminan y se almacenan indefinidamente.

Restaurar Después de una Falla del Agente¶

Si un agente falla con la persistencia habilitada, puede restaurarlo manualmente siguiendo estos pasos:

1. En el servidor del agente fallido, edite <JITTERBIT_HOME>/Resources/jitterbit-agent-config.properties y agregue lo siguiente:

   agent.sdk_framework.listener.running.mode=restore
   

2. Iniciar el agente.

3. Utilice la API REST para consultar el estado del agente.
4. Cuando el estado de leaderNodeState es RESTORED, detenga al agente.
5. Editar <JITTERBIT_HOME>/Resources/jitterbit-agent-config.properties y elimine o comente la línea agregada en el paso 1.
6. Iniciar el agente.