Servicio de escucha Jitterbit

Descripción general

El Jitterbit Listening Service es el servicio de aplicación de Jitterbit que se ejecuta en un agente privado y es consumido por ciertos Integration Studio conectores 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:

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 para que sea menor o igual que la cantidad de núcleos de procesador en el servidor alojar del agente. Alternativamente, configure agent.sdk_framework.listeners.matchEventsQueueToAvailableCores a true.

Una vez que se implementa una operación, la Integration Studio el proyecto 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 la 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 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 activar y desactivar en el nivel de operación desde el Integration Studio operación o en el nivel de operación o actividad desde la página Proyectos de la Management Console como se describe a continuación.

Integration Studio operación

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 interruptor:

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 oyente 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á deshabilitada no se pierden y se procesan de manera normal.

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, el nombre de la operación o el estado del receptor 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: Se proporciona el estado de escucha para cada actividad y operación. Haga clic para alternar el estado de escucha entre Activado (habilitado) y Desactivado (deshabilitado). Nota:

  • Deshabilitar la escucha de eventos para una actividad deshabilitará automáticamente la escucha para todas las operaciones en las que se utiliza. Sin embargo, habilitar la escucha de eventos para una actividad no afecta el estado de ninguna de las operaciones en las que se utiliza.
  • Las operaciones se pueden habilitar y deshabilitar para la escucha de eventos individualmente.
  • El cambio de estado se sincroniza con el Integration Studio UI en ambas direcciones. Es decir, alternar el estado de escucha en la Management Console afecta el estado en Integration Studio. De manera similar, habilitar o deshabilitar eventos en an Integration Studio La operación afecta el estado en la Management Console. Es posible que se requiera 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 una operación que contiene un conector configurado con una actividad de escucha de eventos y se habilita para la escucha. Una actividad de escucha se puede utilizar en muchas operaciones y proyectos para recibir el mismo evento, pero procesarlo de forma diferente.
2. El servicio de escucha dentro del agente iniciará un oyente para esa operación.
3. El oyente comenzará a escuchar activamente cualquier notificación de eventos del extremo.
4. Cuando ocurre un evento en el extremo, este publica una notificación de evento que pueden recibir sus suscriptores.
5. El oyente capta el mensaje de notificación del evento.
6. Si hay un agente en el grupo de agentes, el receptor transmite el mensaje de evento a la operación. Si el grupo de agentes contiene la cantidad mínima para permitir capacidades de servicio de escucha completas, el mensaje de evento se transmite al agente con la menor carga de trabajo.
7. Al recibir la notificación del evento, la operación activará 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 agente activos, los agentes se comunican entre sí para formar un clúster. El primer agente registrado se designa como líder del clúster. 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 no haya dos agentes que 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 almacenamiento persistente de mensajes que se pueden reenviar cuando el agente vuelve a estar en línea. La persistencia mediante la base de datos PostgreSQL interna está habilitada de forma predeterminada para los clústeres de un solo agente. Para los 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. Reinicie el agente.

Los ajustes agent.sdk_framework.queueStore.type=dbinternal y agent.sdk_framework.persistence.type=dbinternal hacer que el agente utilice la base de datos PostgreSQL local para persistir los mensajes.

Para configurar una base de datos externa habilitada para JDBC o un servidor Redis, todos los agentes dentro del grupo de agentes deben usar las siguientes configuraciones, 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.