Ir para o conteúdo

Serviço de Escuta Harmony da Jitterbit

Visão Geral

O Harmony Listening Service da Jitterbit é um serviço de aplicativo executado em um Agente Privado e é consumido por determinados conectores do Cloud Studio que possuem recursos de escuta. O serviço de atendimento fornece manipulação de eventos assíncronos para operações implementadas no agente.

Conectores com Atividades Auditivas

Os conectores e atividades a seguir usam o serviço de atendimento. Essas atividades são lançadas como uma versão beta. Feedback sobre bugs e melhorias sugeridas podem ser fornecidos através do seu Gerente de sucesso do cliente (CSM).

- [Amazon SQS](/pt/cloud-studio/cloud-studio-reference/connectors/amazon-sqs/) - [Atividade de recebimento de mensagens](/pt/cloud-studio/cloud-studio-reference/connectors/amazon-sqs/receive-message-activity/) - [Google Pub Sub](/pt/cloud-studio/cloud-studio-reference/connectors/google-pub-sub/) - [Atividade de ouvir mensagem](/pt/cloud-studio/cloud-studio-reference/connectors/google-pub-sub/listen-message-activity/) - [JMS](/pt/cloud-studio/cloud-studio-reference/connectors/jms/) - [Atividade de consumo JMS](/pt/cloud-studio/cloud-studio-reference/connectors/jms/consume-activity/) - [Microsoft Azure ESB](/pt/cloud-studio/cloud-studio-reference/connectors/microsoft-azure-esb/) - [Consumir atividade da fila](/pt/cloud-studio/cloud-studio-reference/connectors/microsoft-azure-esb/consume-queue-activity/) - [Consumir atividade do tópico](/pt/cloud-studio/cloud-studio-reference/connectors/microsoft-azure-esb/consume-topic-activity/) - [RabbitMQ](/pt/cloud-studio/cloud-studio-reference/connectors/rabbitmq/) - [Consumir atividade](/pt/cloud-studio/cloud-studio-reference/connectors/rabbitmq/consume-activity/) - [Salesforce Events](/pt/cloud-studio/cloud-studio-reference/connectors/salesforce-events/) - [Inscrever-se na atividade do evento](/pt/cloud-studio/cloud-studio-reference/connectors/salesforce-events/subscribe-event-activity/) - [Inscrever-se Inserir atividade do evento CDC](/pt/cloud-studio/cloud-studio-reference/connectors/salesforce-events/subscribe-insert-cdc-event-activity/) - [Inscrever-se na atividade do evento de atualização do CDC](/pt/cloud-studio/cloud-studio-reference/connectors/salesforce-events/subscribe-update-cdc-event-activity/) - [Inscrever-se Excluir atividade do evento CDC](/pt/cloud-studio/cloud-studio-reference/connectors/salesforce-events/subscribe-delete-cdc-event-activity/)

Pré-requisitos

Para utilizar 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 Grupos de Agentes em Nuvem da Jitterbit. Nem todos os conectores suportam o serviço de escuta.

Estes 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 estar 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 está 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 agentes \(N\) no grupo de agentes, pelo menos \((N / 2) + 1\) deverão 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-properties.config arquivo seja menor ou igual ao número de núcleos de processador no servidor hospedar do agente. Alternativamente, defina agent.sdk_framework.listeners.matchEventsQueueToAvailableCores para true.

Depois que uma operação for implantada, o projeto do Cloud Studio deverá ter o serviço de escuta ativado no nível da operação e no nível da atividade, conforme descrito em Ativar o serviço de escuta na operação e na atividade abaixo. Esta é uma etapa manual executada no momento da concepção ou gerenciamento do projeto.

Habilite o Serviço de Escuta no Agente

O serviço de escuta está 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 ativar a estrutura do ouvinte:

    agent.sdk_framework.listener.enabled=true
    
  3. Reinicie o agente.

Dica

Para aproveitar ao máximo os recursos de balanceamento de carga e tolerância a falhas do serviço de escuta, é recomendável ter três ou mais Agentes Privados no Grupo de Agentes.

Habilite o Serviço de Escuta na Operação e Atividade

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

Operação do Cloud Studio

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

operação de atividade de recebimento de mensagens do Amazon SQS

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

consumir eventos de atividade de tópico habilitados

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

  • Um ícone de ouvinte verdeouvinte ativado indica que a escuta está habilitada para esta atividade.
  • Um ícone de ouvinte cinzaouvinte desativado 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 qualquer atividade de escuta que ela contenha. Os eventos recebidos, mas ainda não processados, quando a escuta está desativada, 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 ouvinte for implementada, a operação e suas atividades de escuta serão exibidas no Management Console Projetos na página Ouvintes aba:

projeta ouvintes

  • 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 busca não diferencia maiúsculas de minúsculas.

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

  • 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 da atividade de escuta fornecido pelo usuário não é mostrado.

    Clique no triângulo de divulgação 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 (ativado) e Desligado (desativado). Observação:

    • Desativar a escuta de eventos para uma atividade desativará automaticamente a escuta de 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 a IU do Cloud Studio em ambas as direções. Ou seja, alternar o estado de escuta no Management Console afeta o estado no Cloud Studio. Da mesma forma, ativar ou desativar eventos em uma operação do Cloud Studio 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:

arquitetura do sistema de serviço de escuta

  1. Uma operação que contém um conector configurado com uma atividade de escuta de eventos é implementada 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 maneira diferente.
  2. O serviço de escuta dentro do agente iniciará um ouvinte para essa operação.
  3. O ouvinte começará a ouvir 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 capta a mensagem de notificação de evento.
  6. Se houver um agente no grupo de agentes, o ouvinte retransmitirá a mensagem do evento para a operação. Se o grupo de agentes contiver o número mínimo para permitir recursos completos de serviço de escuta, a mensagem do evento será transmitida ao agente com 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 de um grupo de agentes se comunicam diretamente com o Harmony. Quando ativado e um número mínimo de nós de agente estiver ativo, os agentes se comunicam entre si para formar um cluster. O primeiro agente registrado é nomeado 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 dois agentes não processem 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 fornecerá um armazenamento persistente de mensagens que poderão ser reenviadas quando o agente voltar a ficar online. A persistência usando o banco de dados PostgreSQL interno é 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 mensagens persistentes.

Para configurar um banco de dados externo habilitado para JDBC ou 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:

JDBC-enabled database persistent store settings (Example)
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
Redis persistent store settings (Example)
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 Enviada

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

agent.sdk_framework.retry.deleteRetryableMessageAfter=60

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

Se definido para -1, as mensagens nunca são excluídas e são armazenadas indefinidamente.

Restaurar Após Falha do Agente

Se um agente falhar com a persistência habilitada, você poderá restaurá-lo manualmente seguindo 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. Inicie o agente.

  3. Use a API REST para consultar o status do agente.
  4. Quando o status de 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. Inicie o agente.