Quadro di integrazione centralizzato

5

Cerchiamo di centralizzare la nostra integrazione nella nostra azienda e mi chiedo quale altro tipo di soluzioni abbia per questo e quale sia il modo migliore per affrontarlo. Al momento abbiamo diversi tipi di integrazione che eseguono diverse lingue, diversi framework su server diversi, quindi stiamo cercando di spostarli tutti su un unico framework per renderlo più facile da gestire.

Alcune delle integrazioni correnti includono:

  • Attività pianificate di SQL Server (su 3 o 4 server)
  • Servizi di integrazione di SQL Server (su 2 o 3 server)
  • Applicazioni console (.NET su 2 server)
  • Servizi Windows (.NET su 2 server)

Quello che cerchiamo è:

  • 1 server che gestisce la pianificazione di tutti i lavori di integrazione (quindi è necessario installarlo solo una volta e sappiamo sempre dove trovarlo)
  • Un monitor dei lavori che visualizza la cronologia dei lavori eseguiti (molto simile al monitor Attività lavoro di SQL Server)
  • Potrebbe essere necessario che i lavori eseguano codice .NET personalizzato, in questo caso potrebbe essere utilizzata una sorta di API per consentire una maggiore flessibilità su SQL Server Integration Services
posta d1k_is 03.05.2011 - 04:39
fonte

2 risposte

2

I punti di integrazione sono un posto perfetto per un ESB . Possono semplicemente attivare eventi basati sulla messaggistica.

Ciò può consentire di disporre di un servizio centrale che utilizza il framework e attiva automaticamente altre azioni tramite un messaggio. Questi messaggi possono essere distribuiti localmente o in remoto, a servizi che attendono i messaggi e si attiveranno al loro arrivo per completare qualsiasi azione tu voglia.

  • Scheduler dice che è ora di eseguire stored proc per spostare i dati da db a un altro (un esempio di possibile lavoro pianificato)
  • Lo scheduler invia un messaggio TransferData
  • Un servizio è in attesa di questo messaggio, collegato al bus di servizio, che attiva un processo memorizzato quando viene ricevuto il messaggio
  • Il servizio può pubblicare un messaggio ActivityStatus sul bus di servizio
  • Un'attività di registrazione può ascoltare il messaggio ActivityStatus e registrare lo stato dell'evento a fini di reporting

Ora un ESB ti compra alcune cose qui. Si può facilmente rimuovere il servizio che attende il messaggio TransferData e sostituirlo con un altro che gestisce quel messaggio in un modo diverso.

Inoltre, se si dispone di importazioni di dati con file di importazione di grandi dimensioni, è possibile suddividerle. Non è difficile avere un servizio che ascolti la perdita di file, quindi legge il file e genera 1 messaggio che dice che i dati sono pronti o che suddivide il file in ogni record nel file di grandi dimensioni da elaborare. Rompere il file ti permette di tracciare più facilmente gli errori con un record specifico, correggerli e ripubblicarli nel sistema, ma a volte ordinare di più. Con l'avere ogni record nel file di grandi dimensioni come un singolo messaggio, è inoltre possibile scalare più servizi che consumano lo stesso messaggio, rende l'elaborazione del file in parallelo.

In .NET hai davvero due framework che si adattano come un ESB. MassTransit  o NServiceBus . Se vuoi davvero, prova BizTalk da MS ma probabilmente ti faranno tirare fuori i capelli. Sebbene tu possa utilizzare la Progettazione del flusso di lavoro se hai utenti non sviluppatori che configureranno i lavori.

So che MassTransit supporta in qualche modo eventi programmati, presumo che NServiceBus faccia altrettanto, anche se non lo so per certo.

    
risposta data 10.06.2011 - 02:03
fonte
-1

Hai considerato TeamCity ? Ha molti plug-in che potrebbero rivelarsi utili. C'è un'altra opzione - Cruise Control .NET , ma richiederà più configurazione. Infine, si consiglia di controllare il server TFS, tenere presente, tuttavia, il costo di questo elemento della configurazione.

    
risposta data 03.05.2011 - 08:28
fonte

Leggi altre domande sui tag