Comment maintenir deux systèmes liés, mais distincts, synchronisés l'un avec l'autre ?

Question

Mon projet de développement actuel comporte deux aspects.Premièrement, il existe un site Web public sur lequel les utilisateurs externes peuvent soumettre et mettre à jour des informations à diverses fins.Ces informations sont ensuite enregistrées sur un serveur SQL local dans l'installation de colo.

Le deuxième aspect est une application interne que les employés utilisent pour gérer ces mêmes enregistrements (conceptuellement) et fournir des mises à jour de statut, des approbations, etc.Cette application est hébergée dans le pare-feu de l'entreprise avec sa propre base de données SQL Server locale.

Les deux réseaux sont connectés par une solution VPN matérielle, ce qui est correct, mais évidemment pas la solution la plus rapide au monde.

Les deux bases de données sont similaires et partagent bon nombre des mêmes tables, mais elles ne sont pas identiques à 100 %.La plupart des tableaux des deux côtés sont très spécifiques à l'application interne ou externe.

La question est donc :lorsqu'un utilisateur met à jour ses informations ou soumet un enregistrement sur le site Web public, comment transférer ces données vers la base de données de l'application interne afin qu'elles puissent être gérées par le personnel interne ?Et vice versa...comment renvoyer les mises à jour effectuées par le personnel vers le site Web ?

Il convient de mentionner que plus ces mises à jour sont effectuées « en temps réel », mieux c'est.Non pas que cela doive être instantané, mais raisonnablement rapide.

Jusqu’à présent, j’ai pensé à utiliser les types d’approches suivants :

1. Réplication bidirectionnelle
2. Interfaces de service Web des deux côtés avec du code pour synchroniser les modifications au fur et à mesure qu'elles sont effectuées (en temps réel).
3. Interfaces de service Web des deux côtés avec du code pour synchroniser les modifications de manière asynchrone (à l'aide d'un mécanisme de mise en file d'attente).

Aucun conseil?Quelqu'un a-t-il déjà rencontré ce problème ?Avez-vous trouvé une solution qui a bien fonctionné pour vous ?

Answer 1

Il s’agit d’un scénario d’intégration assez courant, je crois.Personnellement, je pense qu'une solution de messagerie asynchrone utilisant une file d'attente est idéale.

Vous devriez pouvoir réaliser une synchronisation en temps quasi réel sans la surcharge ou la complexité de quelque chose comme la réplication.

Les services Web synchrones ne sont pas idéaux car votre code devra être très sophistiqué pour gérer les scénarios de panne.Que se passe-t-il lorsqu'un système est redémarré tandis que l'autre continue de publier des modifications ?Le système d'envoi subit-il des délais d'attente ?Qu'est-ce que ça fait avec ceux-là ?À moins que vous ne soyez prêt à perdre des données, vous aurez besoin d'une sorte de file d'attente transactionnelle (comme MSMQ) pour recevoir les avis de modification et veiller à ce qu'ils parviennent à l'autre système.Si l'un ou l'autre des systèmes est en panne, les modifications (transmises sous forme de messages) s'accumuleront simplement et dès qu'une connexion pourra être établie, le serveur de redémarrage traitera tous les messages en file d'attente et rattrapera son retard, ce qui rendra l'intégrité du système beaucoup plus facile à réaliser.

Il existe des outils open source qui peuvent vraiment vous faciliter la tâche si vous utilisez .NET (surtout si vous souhaitez utiliser MSMQ).

1. nServiceBus par Udi Dahan
2. Le transport en commun par Dru Sellers et Chris Patterson

Il existe également des produits commerciaux, et si vous envisagez une option commerciale, consultez ici pour une liste d’options sur .NET.Bien sûr, WCF peut effectuer une messagerie asynchrone à l'aide des liaisons MSMQ, mais un outil tel que nServiceBus ou MassTransit vous fournira une API d'envoi/réception ou Pub/Sub très simple qui fera de vos besoins un travail très simple.

Si vous utilisez Java, il existe un certain nombre d'implémentations de bus de services open source qui feront de ce type de messagerie asynchrone bidirectionnelle un jeu d'enfant, comme Mule ou peut-être simplement ActiveMQ.

Vous pouvez également envisager de lire Udi Dahan's blog, en écoutant certains de ses podcasts.Voici quelques autres bonnes ressources pour vous aider à démarrer.

Answer 2

Je suis à mi-chemin d'un projet similaire, sauf que j'ai plusieurs sites qui doivent rester synchronisés sur des connexions lentes (connexion commutée dans certains cas).

Tout d'abord, vous devez suivre les modifications, si vous pouvez utiliser SQL 2008 (même la version Express suffit si la limite de 2 Go n'est pas un problème), cela soulagera considérablement la douleur, activez simplement le suivi des modifications sur la base de données et chaque table.Nous utilisons SQL Server 2008 au siège social avec le schéma étendu et SQL Express 2008 sur chaque site avec un sous-ensemble de données et un schéma limité.

Deuxièmement, vous devez suivre vos modifications, Services de synchronisation fait bien l'affaire et prend en charge l'utilisation d'une passerelle WCF dans la base de données principale.Dans cet exemple, vous devrez utiliser le Synchroniser à l'aide du client SQL Express exemple comme point de départ, notez qu'il est basé sur SQL 2005, vous devrez donc le mettre à jour pour profiter des fonctionnalités de suivi des modifications en 2008.Par défaut, les services de synchronisation utilisent SQL CE sur les clients, ce qui, j'en suis sûr, n'est pas suffisant dans votre cas.Vous aurez besoin d'un service qui s'exécute sur votre serveur Web et qui exécute périodiquement (peut-être toutes les 10 secondes si vous le souhaitez) la méthode Synchronize().Cela informera votre base de données principale des modifications apportées localement, puis demandera au serveur toutes les modifications qui y sont apportées.Vous pouvez configurer le code get et appliquer le code SQL pour appeler des procédures stockées et vous pouvez ajouter des gestionnaires d'événements pour gérer les conflits (par ex.Client Update vs Server Update) et résolvez-les en conséquence à chaque extrémité.

Answer 3

Nous avons une boutique comme client, avec trois magasins connectés au même VPN
Deux des magasins disposent d'un ordinateur fonctionnant comme "serveur" pour ce magasin et le troisième dispose de la "base de données principale".
Pour tout synchroniser sur le maître nous n'avons pas la meilleure solution, mais ça marche :il y a un PC dédié exécutant une application qui vérifie l'horodatage de chaque enregistrement dans chaque table des deux magasins et s'il est différent de la dernière fois que vous synchronisez, il copie les résultats
Notez que cela fonctionne dans les deux sens.C'est à dire.si vous mettez à jour un produit dans la base de données principale, cette modification se propagera aux deux autres boutiques.Si vous avez une nouvelle commande dans l'une des boutiques, elle sera transmise au "maître".
Avec quelques optimisations, vous pouvez synchroniser tous les magasins en 20 minutes environ

Answer 4

Récemment, j'ai eu beaucoup de succès avec SQL Server Service Broker, qui offre une messagerie asynchrone fiable et persistante, prête à l'emploi, avec très peu de difficultés de mise en œuvre.

• Il est rapide à configurer et à mesure que vous en apprenez davantage, vous pouvez utiliser certaines des fonctionnalités les plus avancées.
• Inconnu de la plupart, il fait également partie des éditions de bureau et peut donc être utilisé comme système de messagerie pour poste de travail.
• Si vous possédez des compétences T-SQL, elles peuvent être exploitées car tout le code pour lire et écrire des messages est réalisé en SQL.
• C'est incroyablement rapide

Il s'agit d'une partie largement sous-estimée de SQL Server et qui mérite le détour.

Answer 5

Je dirais simplement d'avoir un travail qui copie les données de la table d'entrée de la base de données pub dans une table en attente de base de données privée.Ensuite, une fois que vous avez mis à jour les données du côté privé, faites-les répliquer vers le côté public.Si aucune des données répliquées du côté public n'est mise à jour, cela devrait être une solution de réplication transactionnelle assez simple.