Scrivi dati su SQL Server direttamente da BizTalk o usa un servizio esterno?

Adotterei un approccio pragmatico. Se il requisito corrente è principalmente quello di ottenere i dati xml in uno stile Sql con ETL , al momento non è possibile sovrascrivere la soluzione.

Anche se si sta tentando di rendere il processo di caricamento asincrono tramite MSMQ:

• BizTalk può essere visto come una sorta di meccanismo di accodamento (basato su Sql) di per sé, mediante il buffering dei messaggi nella messagebox (sebbene non consiglierei di archiviare troppi backlog in BizTalk, dato che le prestazioni si degradano con #messages nella messagebox)
• Se gli unici motivi per utilizzare MSMQ durante il caricamento limitano il throughput e / o gestiscono i tempi di inattività del database Sql, ci sono alcune manopole in adattatore WCF-Sql , e il meccanismo standard dei tentativi nella porta di trasmissione dovrebbe soddisfare la mancata disponibilità di Sql a valle (e se tutto il resto fallisce, è possibile orchestrare i requisiti di carico e affidabilità , ad es. con Singleton / Multiton orch)

IMO l'opzione per passare a un servizio SOA sarebbe guidata da domande come:

• Esistono altri sistemi (diversi dal tuo server BizTalk) che devono inviare gli stessi dati al server Sql?
• Se ci sono regole aggiuntive che devono essere applicate con i dati, che potrebbero richiedere informazioni da ulteriori dati / servizi.
• Se sono richiesti passaggi di arricchimento o pulizia dei dati
• Ci sono altri servizi SOA necessari altrove nella tua azienda che potrebbero rovesciare le scale verso un layer di caricamento WCF?

Se prevedi di modificare l'accoppiamento diretto di BizTalk con il database Destination Sql in futuro, puoi utilizzare uno schema canonico in Biztalk per i tuoi dati xml, che viene quindi mappato alla porta di invio WCF-SQL il più tardi possibile (ovvero in modo da essere disaccoppiati il più possibile dallo schema Sql-WCF generato, che può essere scartato).

Molto dipende dal tuo ambiente e dai tuoi requisiti. Se BizTalk può tenere il passo con il traffico, allora mi piacerebbe solo che scrivesse i dati nel database. Semplice, facile da capire e implementare.

Se ha problemi a tenere il passo, allora, andrei con la soluzione MSMQ. Ciò fornirà un po 'di buffering, oltre a un punto utile per aggiungere cose come bilanciamento del carico o sharding, se queste diventano importanti. Permette inoltre un'architettura pulita se è necessario introdurre una catena di filtri tra l'origine e il database. Infatti, se BizTalk diventa il collo di bottiglia, è sufficiente scrivere un semplice servizio per prendere l'XML e scaricarlo nella coda, quindi fare in modo che BizTalk lo legga da lì. In questo modo non rischierai di perdere messaggi perché il tuo servizio BizTalk non può rispondere abbastanza velocemente e ti consentirebbe anche di aggiungere ulteriori istanze del servizio per gestire carichi di dati pesanti.

Se il database è locale, puoi utilizzare l'adattatore WCF-SQL per utilizzarlo direttamente stored procedure nelle porte di invio e ricezione delle posizioni. Un vantaggio di questo è che è possibile coordinare la transazione del database con le transazioni di messaggi BizTalk pure.

Se il database è remoto, consiglierei di usare i servizi o un approccio di messaggistica / accodamento.

Eviterei di creare qualsiasi tipo di collegamento a catena tra: XML Document, BizTalk e Website. A meno che BizTalk non stia facendo qualcosa di magico con i dati del file XML e / o gli utenti stiano modificando i dati che verrebbero inviati al database del sito Web, terrei BizTalk e il database del sito web completamente separati. Non inviare nulla da uno all'altro. Motivo: perché rischiare di dover modificare la funzionalità di esportazione di WebSite a causa di una modifica di BizTalk?

Potresti scoprire che lo schema su cui stai infrangendo il documento XML è vantaggioso per entrambi i sistemi, quindi crea un servizio separato che gestisce i documenti XML e lo inserisce in una sorta di schema che può essere facilmente utilizzato. Questo ti dà una singola fonte per il documento XML e spero che le eventuali modifiche apportate non interrompano l'interfaccia. Ciò consente anche a entrambi i sistemi di utilizzare i dati XML di cui hanno bisogno.

Anche se molto dipende dall'impostazione del database, dal momento che BizTalk viene fornito con alcuni adattatori di database, direi che è progettato per gestire scenari del genere senza che il servizio esterno scriva nel database.

Ci sono vantaggi nell'usare BizTalk,

1. Puoi facilmente diagnosticare se ci sono errori da BizTalk senza scavare nei log
2. L'intera base di codice risiede in un repository, quindi la pipeline di compilazione / distribuzione è più semplice
3. Poiché possono esserci modifiche allo schema, le modifiche avvengono solo in una base di codice.
4. Puoi facilmente mappare lo schema XML al database usando il mapper BizTalk.
5. Non devi preoccuparti delle transazioni e della coerenza dei dati poiché BizTalk gestirà questi dati per te.