Serviço de escuta Jitterbit

Visão geral

O Jitterbit Listening Service é o serviço de aplicação do Jitterbit que roda em um agente privado e é consumido por certos Integration Studio conectores que têm capacidades de escuta. O serviço de escuta fornece tratamento de eventos assíncronos para operações implantadas no agente.

Conectores com atividades de escuta

Os seguintes conectores e atividades usam o serviço de escuta:

Pré-requisitos

Para usar uma atividade de escuta, é necessário um grupo de agentes privados com um ou mais agentes. As atividades de escuta não podem ser usadas com os grupos de agentes em nuvem do Jitterbit. Nem todos os conectores oferecem suporte ao serviço de escuta.

Esses pré-requisitos devem ser atendidos quando o grupo de agentes privados contém um único agente ou vários agentes:

• O serviço de escuta deve ser habilitado em cada agente, conforme descrito em Habilitar o serviço de escuta no agente abaixo. Esta é uma etapa manual na configuração e não é habilitada por padrão.

Para grupos de agentes privados que contêm vários agentes, estes pré-requisitos adicionais devem ser atendidos para que os agentes se comuniquem entre si:

• A versão do agente deve ser 10.78 ou superior (para agentes privados 10.x) ou 11.8 ou superior (para agentes privados 11.x).
• Todos os agentes devem ter estas portas disponíveis:
  • 5701
  • 5801
• Todos os agentes devem estar no mesmo grupo de rede.
• Se houver \(N\) agentes no grupo de agentes, pelo menos \((N / 2) + 1\) deve estar em execução para que o serviço de escuta funcione.
• Defina o valor para agent.sdk_framework.listeners.eventsQueue em cada agente jitterbit-agent-config.properties arquivo para ser menor ou igual ao número de núcleos do processador no servidor hospedar do agente. Como alternativa, defina agent.sdk_framework.listeners.matchEventsQueueToAvailableCores para true.

Uma vez que uma operação é implantada, a Integration Studio o projeto deve ter o serviço de escuta habilitado tanto no nível de operação quanto no nível de atividade, conforme descrito em Habilitar o serviço de escuta na operação e na atividade abaixo. Esta é uma etapa manual realizada no momento do design do projeto ou do gerenciamento do projeto.

Habilitar o serviço de escuta no agente

O serviço de escuta é desabilitado por padrão no agente e deve ser habilitado manualmente seguindo estas etapas:

1. Em cada agente privado, abra jitterbit-agent-config.properties em um editor de texto.

   Este arquivo está localizado em <JITTERBIT_HOME>/Resources/, onde <JITTERBIT_HOME> é substituído pelo diretório raiz do agente privado.

2. Adicione esta linha ao arquivo para habilitar o framework listener:

   agent.sdk_framework.listener.enabled=true
   

3. Reinicie o agente.

Habilitar o serviço de escuta na operação e atividade

O serviço de escuta deve ser habilitado tanto na operação quanto na atividade de escuta. O serviço pode ser alternado no nível de operação do Integration Studio operação ou no nível de operação ou atividade na página Projetos do Management Console, conforme descrito abaixo.

Integration Studio operação

Depois que uma operação com uma atividade de ouvinte é implantada, uma alternância Eventos desabilitados aparece na parte inferior da operação na quadro de design. Por padrão, a escuta de eventos está desabilitada.

Para habilitar a escuta de eventos para a operação, clique no botão de alternância:

Esta ação também habilitará a escuta de eventos em quaisquer atividades de escuta que ela contenha, conforme indicado pela cor do ícone do ouvinte no canto superior direito da atividade:

• Um verde ícone de ouvinte indica que a escuta está habilitada para esta atividade.
• Um cinza o ícone do ouvinte indica que a escuta não está habilitada para esta atividade.

Desabilitar a escuta de eventos em uma operação também desabilita a escuta de eventos em quaisquer atividades de escuta que ela contenha. Eventos recebidos, mas ainda não processados quando a escuta é desabilitada, não são perdidos e são processados normalmente.

Página de Projetos do Management Console

Depois que uma operação com uma atividade de escuta é implantada, a operação e suas atividades de escuta são exibidas no Management Console Projetos página em Ouvintes aba:

• Pesquisar: Insira qualquer parte da atividade, nome da operação ou status do ouvinte na caixa de pesquisa para filtrar a lista de atividades de escuta. A pesquisa não diferencia maiúsculas de minúsculas.

• Atualizar: Clique no ícone Atualizar para atualizar a lista de atividades de escuta.

• Atividade: O nome da atividade de escuta usando uma forma abreviada do tipo de atividade do conector seguido pelo nome da conexão fornecido pelo usuário.

  Nota

  O nome fornecido pelo usuário da atividade de escuta não é exibido.

  Clique no triângulo de divulgação ao lado da atividade para revelar os nomes de cada operação em que a atividade é usada.

• Status do ouvinte: O estado de escuta é fornecido para cada atividade e operação. Clique para alternar o estado de escuta entre Ligado (habilitado) e Desligado (desabilitado). Observação:

  • Desabilitar a escuta de eventos para uma atividade desabilitará automaticamente a escuta para todas as operações em que ela é usada. No entanto, habilitar a escuta de eventos para uma atividade não afeta o estado de nenhuma operação em que ela é usada.
  • As operações podem ser habilitadas e desabilitadas para escuta de eventos individualmente.
  • A alteração do estado é sincronizada com o Integration Studio UI em ambas as direções. Ou seja, alternar o estado de escuta no Management Console afeta o estado em Integration Studio. Da mesma forma, habilitar ou desabilitar eventos em an Integration Studio a operação afeta o estado no Management Console. Uma atualização pode ser necessária para atualizar a exibição.

Arquitetura do sistema

Este diagrama mostra como uma mensagem de evento se move pela arquitetura do sistema ao usar um único agente privado:

1. Uma operação contendo um conector configurado com uma atividade de escuta de evento é implantada e habilitada para escuta. Uma atividade de escuta pode ser usada em muitas operações e projetos para receber o mesmo evento, mas processá-lo de forma diferente.
2. O serviço de escuta dentro do agente iniciará um ouvinte para essa operação.
3. O ouvinte começará a escutar ativamente quaisquer notificações de eventos do endpoint.
4. Quando um evento acontece no endpoint, ele publica uma notificação de evento que pode ser recebida por seus assinantes.
5. O ouvinte recebe a mensagem de notificação do evento.
6. Se houver um agente no grupo de agentes, o listener retransmite a mensagem de evento para a operação. Se o grupo de agentes contiver o número mínimo para permitir capacidades de serviço de escuta completas, a mensagem de evento é passada para o agente com a menor carga de trabalho.
7. Ao receber a notificação do evento, a operação acionará uma operação abaixo.

Quando o serviço de escuta está desabilitado, os agentes em um grupo de agentes se comunicam diretamente com o Harmony. Quando habilitado, e um número mínimo de nós de agentes está ativo, os agentes se comunicam entre si para formar um cluster. O primeiro agente registrado é nomeado como o líder do cluster. O líder é responsável por receber mensagens e distribuí-las aos membros do cluster para processamento. O líder do cluster distribui a carga entre todos os agentes e garante que nenhum dos dois agentes processe a mesma mensagem.

Persistência

As mensagens enviadas a um agente podem ser armazenadas em um banco de dados. Se o agente falhar, o banco de dados fornece um armazenamento persistente de mensagens que podem ser reenviadas quando o agente voltar a ficar online. A persistência usando o banco de dados interno PostgreSQL é habilitada por padrão para clusters de agente único. Para clusters com mais de um agente, a persistência deve ser habilitada manualmente da seguinte forma:

1. Em cada agente privado, edite <JITTERBIT_HOME>/Resources/jitterbit-agent-config.properties onde <JITTERBIT_HOME> é substituído pelo diretório raiz do agente privado.

2. Adicione estas linhas ao arquivo:

   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 o agente.

As configurações agent.sdk_framework.queueStore.type=dbinternal e agent.sdk_framework.persistence.type=dbinternal fazer com que o agente use o banco de dados PostgreSQL local para persistir mensagens.

Para configurar um banco de dados externo habilitado para JDBC ou um servidor Redis, todos os agentes dentro do grupo de agentes devem usar as seguintes configurações, onde o usuário do banco de dados tem permissões para criar, ler, atualizar e excluir dados e para criar tabelas:

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

Execute o seguinte comando no servidor hospedar do agente para obter o status do agente e o processo de restauração:

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

Solução de problemas

Mensagem não entregue

O mecanismo de repetição de entrega de mensagens do cluster usa a seguinte configuração no <JITTERBIT_HOME>/Resources/jitterbit-agent-config.properties arquivo:

agent.sdk_framework.retry.deleteRetryableMessageAfter=60

Este é o número de minutos após o qual uma mensagem repetida é excluída.

Se definido como -1, as mensagens nunca são apagadas e são armazenadas indefinidamente.

Restaurar após falha do agente

Se um agente falhar com a persistência habilitada, você pode restaurá-lo manualmente usando estas etapas:

1. No servidor do agente com falha, edite <JITTERBIT_HOME>/Resources/jitterbit-agent-config.properties e adicione o seguinte:

   agent.sdk_framework.listener.running.mode=restore
   

2. Iniciar o agente.

3. Use a API REST para consultar o status do agente.
4. Quando o status para leaderNodeState é RESTORED, pare o agente.
5. Editar <JITTERBIT_HOME>/Resources/jitterbit-agent-config.properties e remova ou comente a linha adicionada na etapa 1.
6. Iniciar o agente.