Estrutura de Integração Centralizada

5

Estamos buscando centralizar nossa integração em nossa empresa e estou me perguntando que tipo de soluções outras têm para isso e qual seria a melhor maneira de abordá-lo. No momento, temos tipos diferentes de integração executando diferentes lanuages, estruturas diferentes em servidores diferentes, por isso estamos procurando movê-los para um único framework para facilitar o gerenciamento.

Algumas das integrações atuais incluem:

  • Tarefas agendadas do SQL Server (em 3 ou 4 servidores)
  • Serviços de integração do SQL Server (em 2 ou 3 servidores)
  • Aplicativos de console (.NET em 2 servidores)
  • Windows Services (.NET em 2 servidores)

O que procuramos é:

  • 1 servidor que gerencia todos os agendamentos de trabalhos de integração (portanto, isso só precisa ser configurado uma vez e sempre sabemos onde encontrá-los)
  • Um monitor de tarefas que exibe o histórico de tarefas executadas (muito parecido com o monitor de atividade de tarefas do SQL Server)
  • Talvez seja necessário executar um código .NET personalizado. Aqui, algum tipo de API pode ser usado para permitir mais flexibilidade no SQL Server Integration Services
por d1k_is 03.05.2011 / 04:39
fonte

2 respostas

2

Os pontos de integração são um lugar perfeito para um ESB . Eles podem apenas ativar eventos baseados em mensagens.

Isso pode permitir que você tenha um serviço central que use a estrutura e ele mesmo ative outras ações por meio de uma mensagem. Essas mensagens podem ser distribuídas local ou remotamente, para serviços que estão aguardando as mensagens e serão ativadas ao recebê-las para concluir qualquer ação desejada.

  • O Scheduler diz que é hora de executar o procedimento armazenado para mover dados do banco de dados para outro (um exemplo de possível trabalho agendado)
  • O agendador envia uma mensagem TransferData
  • Um serviço está aguardando esta mensagem, anexada ao barramento de serviço, que ativa um procedimento armazenado quando a mensagem é recebida
  • O serviço pode publicar uma mensagem ActivityStatus no barramento de serviço
  • Uma atividade de registro pode ouvir a mensagem ActivityStatus e registrar o status do evento para fins de relatório

Agora um ESB compra algumas coisas aqui. Um você pode facilmente remover o serviço que aguarda a mensagem TransferData e substituí-lo por outro que lida com essa mensagem de uma maneira diferente.

Além disso, se você tiver importações de dados com arquivos grandes de importação, poderá separá-los. Não é difícil ter um serviço que ouça a perda de arquivos, leia o arquivo e gere uma mensagem dizendo que há dados prontos ou divide o arquivo em cada registro no arquivo grande a ser processado. Quebrar o arquivo permite rastrear mais facilmente os erros com um registro específico, corrigi-los e repostá-los para o sistema, mas, às vezes, fazer pedidos é mais importante. Com cada registro no arquivo grande como uma única mensagem, você também pode dimensionar vários serviços que consomem a mesma mensagem, fazendo o processamento do arquivo acontecer em paralelo.

No .NET você realmente tem dois frameworks que se encaixam como um ESB. MassTransit  ou NServiceBus . Se você realmente quiser, tente o BizTalk da MS, mas isso provavelmente fará com que você retire o cabelo. Embora você possa usar o Designer de Fluxo de Trabalho se tiver usuários que não sejam desenvolvedores que estarão configurando as tarefas.

Eu sei que o MassTransit suporta eventos agendados de alguma forma, eu assumo que o NServiceBus faz o mesmo, embora eu não tenha certeza disso.

    
por 10.06.2011 / 02:03
fonte
-1

Você já considerou o TeamCity ? Tem muitos plug-ins que podem ser úteis. Existe outra opção - Cruise Control .NET , mas exigirá mais configuração. Por último, você pode querer verificar o servidor TFS, tenha em mente, no entanto, o custo deste IC.

    
por 03.05.2011 / 08:28
fonte