Discussion :

[Barsy]

Bonjour,

J'ai deux applications qui doivent dialoguer ensemble. J'aimerai savoir s'il était possible d'envisager la réplication en mode "transactionnelle" pour cela. Il y aurait d'un côté des tables dédiés pour les échanges de l'application A vers l'application B et de l'autre des tables pour les échanges de la B vers la A. C'est ensuite un service Windows qui viendrait détecter les changements dans les tables de "réception" et écrire dans les tables d'"émission" (environ chaque seconde)

Ne me demandez pas pourquoi je pars sur une solution comme ça au lieu d'employer une véritable messagerie en socket, il se trouve qu'il y a plusieurs contraintes qui imposent cela sachant que la solution proposée à la base consistait en l'emploi de triggers pour gérer tous ces échanges de base à base. Mais je trouve ça beaucoup trop complexe à mettre en œuvre et je ne suis pas fan du tout des triggers.

Voilà ma question, que pensez-vous d'une solution à base de réplications transactionnelles pour supplanter une messagerie ? Est-ce que certains parmi vous on déjà utilisé ce genre de solution ? Est-ce viable ? Quelle sont les contraintes ? Le (dé)conseillez-vous ?

Merci d'avance !!

Barsy

[Boubou2020]

la Réplication transactionnelle : réplique uniquement les transactions, soit les modifications effectuées dans un seul sens par exemple dans ton exemple A vers l'application B

C'est pour cela tu doit pointer sur la Réplication de fusion : ce mode permet aux abonnés de modifier les données en local sur une copie des bases bien à eux. Par la suite, ils ont la possibilité de fusionner ces bases avec celle du serveur de publication.

[SQLpro]

Bonjour,

J'ai deux applications qui doivent dialoguer ensemble. J'aimerai savoir s'il était possible d'envisager la réplication en mode "transactionnelle" pour cela. Il y aurait d'un côté des tables dédiés pour les échanges de l'application A vers l'application B et de l'autre des tables pour les échanges de la B vers la A.

la réplication transactionnelle nécessite que les tables soient strictement identique (binairement) et que vous fassiez en préalable une copie de votre base A par sauvegarde et restauration à titre de base B... Si les deux bases diverges ce mode n'est pas envisageable.

C'est ensuite un service Windows qui viendrait détecter les changements dans les tables de "réception" et écrire dans les tables d'"émission" (environ chaque seconde)

Il serait bien plus adapté d'utiliser Service broker qui est justement fait pour cela : faire la communication de données entre base hétérogène par le biais de services web intégrés à la base...
Les avantages de Service Broker sont nombreux :
1) transactionné
2) sérialisé
3) contrôle de la réception par le biais de message de métadonnées (acquittement, fermeture de la "conversation")
4) agit sur couche HTTP (worlwide)
5) sécurisé (authentification et chiffrement des données en transit)
6) naturellement résilient (une coupure de réseau ou d'Internet laisse les messages en file d'attente et le "push" reprendra dès que possible).
7) portable (intégré à la base, une simple sauvegarde restaure permet de déplacer la chose).
Pour ma part je l'ais fait implanté chez Pasteur Mérieux pour le contrôle de la production des vaccins.

Ne me demandez pas pourquoi je pars sur une solution comme ça au lieu d'employer une véritable messagerie en socket, il se trouve qu'il y a plusieurs contraintes qui imposent cela sachant que la solution proposée à la base consistait en l'emploi de triggers pour gérer tous ces échanges de base à base. Mais je trouve ça beaucoup trop complexe à mettre en œuvre et je ne suis pas fan du tout des triggers.

Voilà ma question, que pensez-vous d'une solution à base de réplications transactionnelles pour supplanter une messagerie ? Est-ce que certains parmi vous on déjà utilisé ce genre de solution ? Est-ce viable ? Quelle sont les contraintes ? Le (dé)conseillez-vous ?

Merci d'avance !!

Barsy

Pour en savoir plus :
http://blog.developpez.com/sqlpro/p1...au-gout-de-sql


A +

[Barsy]

Merci pour les réponses :

@abdallah_mehdoini : Oui la réplication transactionnelle ne marche que dans un sens. Mais je peux créer des publication en mode transactionnel sur chaque serveur SQL avec un abonnement sur l'autre pour échanger dans les deux sens. Le problème du mode "fusion" c'est que l'échange n'est pas instantané après une mise à jour de la base, il se produit de façon périodique et j'ai besoin que les échanges soient assez fréquents après une mise à jour (de l'ordre de la seconde au maximum).

@SQLpro : Effectivement, les structures des deux bases seront identiques (la réplication transactionnelle permet d'ailleurs d'envoyer un "instantané" pour cela). Je ne connaissais pas le Service Broker, ça à l'air intéressant mais celui-ci permet d'envoyer des messages simples non ? Après il faut faire les développements pour pousser ces données dans la base ? Je continue à creuser de ce côté. Après plusieurs tests, la réplication transactionnelle semble fonctionner cela-dit.

[SQLpro]

Je ne connaissais pas le Service Broker, ça à l'air intéressant mais celui-ci permet d'envoyer des messages simples non ? Après il faut faire les développements pour pousser ces données dans la base ? Je continue à creuser de ce côté. Après plusieurs tests, la réplication transactionnelle semble fonctionner cela-dit.

C'est vous qui structurez vos messages en lançant une requête XML en utilisant la clause FOR XML par exemple dans un déclencheur.
Pour les intégrer il faut simplement une procédure attachée au service d'écoute qui parsera le XML pour alimenter les tables destination.

A +