Servicio de Escucha Jitterbit Harmony¶

Descripción General¶

El Harmony Listening Service es el servicio de aplicación de Jitterbit 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 un manejo asincrónico de eventos 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 enviar comentarios sobre errores y sugerencias de mejoras a través de su Administrador de éxito del cliente (CSM).

Prerrequisitos¶

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 la nube de Jitterbit. No todos los conectores admiten el servicio de escucha.

Estos requisitos previos se deben cumplir cuando el grupo de agentes privados contiene un solo agente 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 a continuación. Este es un paso manual en la configuración y no está habilitado de manera predeterminada.

Para los grupos de agentes privados que contienen múltiples 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\) deben estar ejecutándose para que funcione el servicio de escucha.
• Establezca el valor para agent.sdk_framework.listeners.eventsQueue en cada agente jitterbit-agent-config.properties 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 implementada 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 a continuación. Este es un paso manual que se realiza en el momento del diseño o la gestión del proyecto.

Habilitar 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. Reinicie el agente.

Habilitar el Servicio de Escucha Sobre 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 habilitará la escucha de eventos en cualquier actividad de escucha que contenga, como lo indica el color del ícono de escucha en la parte superior derecha de la actividad:

• Un color verde el icono de oyente indica que la escucha está habilitada para esta actividad.
• Un icono de oyente gris el icono de escucha 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 seguido del nombre de conexión proporcionado por el usuario.

  Nota

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

  Haga clic en el triángulo de revelación 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 solo 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, editar <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. Reinicie 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

Este es el número de minutos después del cual se elimina un mensaje reintentado.

Si se configura 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 añade 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.