---
sourceDocument: Options de la plateforme d’IA ServiceNow de Yokohama
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/fr-FR/yokohama/servicenow-platform

 Release :

    - yokohama

ft:locale :

    - fr-FR

ft:publication_title :

    - Options de la plateforme d’IA ServiceNow de Yokohama

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# Réplication bidirectionnelle

# Réplication bidirectionnelle {#ariaid-title1}

* Rversion finale: Yokohama
* 
* Mis à jour 30 janv. 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes de lecture

La réplication bidirectionnelle dans (IDR) permet aux données de circuler d'une Réplication de données d'instance instance de créateur vers une instance de consommateur et d'accepter les données d'une instance de consommateur pour qu'elles soient renvoyées à l'instance du producteur.

Toutes les insertions et changements apportés aux enregistrements sur l'une des instances sont envoyés à l'autre instance pour que les tables restent identiques sur les deux instances. Par exemple, vous pouvez activer la réplication bidirectionnelle pour la table Incidents afin de synchroniser les enregistrements d'incidents entre deux instances.

Pour que les données circulent de manière bidirectionnelle, le système crée un ensemble de réplications du producteur sur l'instance du consommateur et un ensemble de réplications du consommateur sur l'instance du producteur.  
Figure 1. Réplication bidirectionnelle

Si vous examinez les ensembles de réplications sur l'instance du producteur d'origine, vous voyez le nom de l'ensemble de réplications et l'instance de consommateur générée automatiquement. Il porte le même nom ajouté avec le suffixe -\<long-number\>-reverse, où \<long-number\> est un nombre généré aléatoirement. Par exemple, si Test est le nom de l'ensemble de réplications du producteur, Test-2034802-reverse peut être le nom de l'ensemble de réplications du consommateur qui est automatiquement créé sur la même instance. Sur l'instance de consommateur d'origine, les mêmes noms s'affichent. Les ensembles de réplications avec le suffixe inverse sont en lecture seule.

Vous pouvez vérifier un consommateur sur une instance de créateur et un producteur sur une instance de consommateur en exécutant https://\<producer-instance-name\>/xmlstats.do ?include=idr et https://\<consumer-instance-name\>/xmlstats.do ?include=idr sur les instances producteur et consommateur. Dans l'image suivante, l'instance du producteur d'origine est à gauche et l'instance du consommateur d'origine est à droite.

La réplication bidirectionnelle présente les limitations suivantes :

* La résolution automatique des conflits n'est pas prise en charge.
* Des conflits de fusion se produisent si les instances de producteur et de consommateur modifient le même enregistrement en même temps. La mise à jour la plus récente l'emporte, ce qui signifie que les données sur les tables des consommateurs et des producteurs peuvent être différentes.

* La réplication bidirectionnelle prend en charge l'adaptateur [Number](https://servicenow-prod.fluidtopics.net/cZRHxVI~tBPpdSMGZVPkSA "Les adaptateurs modifient les données du producteur avant d’insérer les données sur les instances de consommateur dans Réplication de données d'instance (IDR).") mais aucun des autres adaptateurs.
* La réplication bidirectionnelle maintient les données synchronisées entre les instances producteur et consommateur. Toutefois, dans certains scénarios, évitez d'utiliser la réplication bidirectionnelle et utilisez plutôt la réplication unidirectionnelle.
  * Si vous envisagez d'utiliser des adaptateurs pour différencier les données répliquées entre deux instances, utilisez deux ensembles de réplication unidirectionnels pour répliquer les données dans les deux sens au lieu d'utiliser des ensembles bidirectionnels.
  * Si vous avez besoin d'amorcer des données d'une instance à une autre et vice versa, utilisez deux ensembles de réplication unidirectionnels.
  {#bidirectional-replication__ul_in1_hm3_gfc}
* Avec la réplication bidirectionnelle, les enregistrements créés sur l'instance du producteur sont répliqués sur une instance de consommateur, et vice versa. Lorsque l'enregistrement est inséré sur l'instance de consommateur et qu'il déclenche une règle métier qui met à jour l'enregistrement, cette mise à jour n'est pas répliquée sur l'instance du créateur.
{#bidirectional-replication__ul_shb_3x5_5fb}

Si vous devez comprendre les implications de la bidirection et du transfert de données entre instances, consultez [Confidentialité des données dans IDR](https://servicenow-prod.fluidtopics.net/mC_Ony6PIA6KV0lZ8vBBKg "La capacité des ensembles de réplication à héberger plusieurs consommateurs distants dans (IDR) signifie qu’il existe des problèmes potentiels de confidentialité des données à prendre en Réplication de données d'instance compte.") pour plus d'informations.