Utilize um nó de DatabaseInput para responder aos eventos em um banco de dados. Por exemplo, o broker pode manter um sistema externo sincronizado com um banco de dados enviando atualizações para o sistema de destino sempre que os dados forem alterados no banco de dados.
O banco de dados deve registrar o fato de que os dados tenham mudado em um armazenamento de eventos, que é tipicamente uma tabela de banco de dados. O armazenamento de eventos não é igual aos dados do aplicativo. O diagrama a seguir mostra a interação entre o banco de dados, o armazenamento de eventos e o broker.
O diagrama a seguir mostra como funciona o nóDatabaseInput.
Quando o evento inicia, o ReadEvents verifica o armazenamento de eventos para os novos eventos, que são, em seguida, usados pelo BuildMessage para construir a mensagem. Esta mensagem é propagada para o fluxo de mensagens e, em seguida, o EndEvent atualiza o armazenamento de eventos para assegurar que o evento não possa ser processado novamente. Quando todos os eventos tiverem sido processados, o broker chamará ReadEvents para recuperar quaisquer eventos que tenham sido incluídos desde a verificação anterior. Se o armazenamento de eventos estiver vazio, o broker espera até que o intervalo de sondagem tenha expirado e, em seguida, chama o ReadEvents novamente. Para evitar a contenção, a verificação do armazenamento de eventos é de encadeamento único.
Para cada evento que é lido pelo ReadEvents, o BuildMessage constrói a mensagem que é propagada para o fluxo de mensagens. A construção da mensagem normalmente usa os dados do evento para consultar dados na tabela do aplicativos. Os dados da tabela de aplicativos então são usados para construir a mensagem. Quando o BuildMessage termina, a mensagem é automaticamente propagada para o fluxo de mensagens. Quando a mensagem é propagada, o broker inicia quaisquer nós de recebimento de dados que sejam requeridos para processar a mensagem.
Após a mensagem ter sido propagada para o fluxo de mensagens, o EndEvent atualiza o armazenamento de eventos para assegurar que o evento que acabou de ser processado não possa ser processado novamente.
As operações detalhadas ReadEvents, BuildMessage e EndEvent são controladas pelo código ESQL. O nó DatabaseInput contém um módulo ESQL com o código de amostra e os comentários, que você deve modificar para adequar-se a seus requisitos. Para obter informações sobre como modificar o ESQL, consulte Configurando um Nó DatabaseInput.
Os processos que são concluídos pelo nó DatabaseInput são divididos em transações separadas. Uma nova transação é iniciada quando o ReadEvents inicia. Quando o ReadEvents inicia, esta transação é confirmada e os novos eventos são marcados para processamento. Confirmando esta transação, quaisquer travas colocadas no banco de dados pelo código ESQL que é executado a partir do ReadEvents são liberadas. Em seguida, para cada evento recebido pelo BuildMessage, uma nova transação é iniciada. Esta nova transação é confirmada após o EndEvent ser concluído.
Para escalar um nó DatabaseInput para muitos eventos, altere a propriedade Instâncias adicionais na guia Instâncias de seu valor padrão 0 para o número de instâncias que você precisa. Se estiver usando instâncias adicionais, o banco de dados deve ser configurado para que múltiplos aplicativos possam ler diferentes linhas da tabela de aplicativos ao mesmo tempo. O ReadEvents sempre executa em modo de encadeamento único para evitar a contenção de banco de dados, mesmo se você usar instâncias adicionais. Para melhorar o desempenho, o ReadEvents pode ler múltiplos eventos de cada vez que executar e esses eventos podem ser processados ao mesmo tempo por múltiplas instâncias do BuildMessage. O armazenamento de eventos deve ter uma chave primária, que o ReadEvents usa para identificar eventos que estão sendo processados atualmente. Você não tem de gravar o ESQL no ReadEvents para filtrar eventos que estão sendo processados atualmente pelo fluxo de mensagens.