Les données stockées dans le référentiel de TIBCO EBX® peuvent être copiées en miroir dans des tables relationnelles dédiées afin d'offrir un accès direct aux données via des requêtes et des vues SQL.
Tout comme l'historique et le mode relationnel, cette réplication des données est transparente pour l'utilisateur final et pour les applications clientes. Certaines actions provoquent des modifications automatiques des répliques dans la base de données :
L'activation de la réplique, au niveau du modèle, met à jour le schéma de la base de données en exécutant automatiquement les déclarations de DDL nécessaires.
Les évolutions du modèle de données impactant les tables répliquées, telles que la création d'une nouvelle colonne, actualisent aussi le schéma de la base de données par le biais de déclarations DDL.
En utilisant le mode d'actualisation 'onCommit' : la mise à jour des données du référentiel d'EBX® déclenche les insertions, mises à jour et suppressions associées aux répliques en base de données.
table répliquée : désigne une table de données de référence qui a fait l'objet d'une réplication
table de réplique (ou réplique) : désigne une table en base de données qui est la cible de la réplication
Pour définir une unité de réplication sur un modèle de données, utiliser l'élément osd:replication sous les éléments annotation/appinfo. Chaque unité de réplication désigne des tables dans un jeu de données unique dans un espace de données spécifique.
Les éléments imbriqués sont les suivants :
Élément | Description | Requis |
|---|---|---|
| Nom de l'unité de réplication. Ce nom identifie l'unité de réplication dans le modèle de données. Ce nom doit être unique. | Oui |
| Indique l'espace de données concerné par la réplication. Cet espace de données ne peut ni être une version ni être relationnel. | Oui |
| Indique le jeu de données concerné par la réplication. | Oui |
| Spécifie la politique de synchronisation des données. Les politiques disponibles sont :
| Oui |
| Indique le chemin de la table dans le modèle de données qui doit être répliquée dans la base de données. | Oui |
| Indique le nom de la table dans la base de données qui contiendra les données répliquées. Ce nom doit être unique par rapport à toutes les unités de réplication. | Oui |
| Indique le chemin de la liste agrégée dans la table qui doit être répliquée dans la base de données. | Oui |
| Indique le nom de la table dans la base de données qui contiendra les données répliquées de la liste agrégée. Ce nom doit être unique par rapport à toutes les unités de réplication. | Oui |
Par exemple :
<xs:schema> <xs:annotation> <xs:appinfo> <osd:replication> <name>ProductRef</name> <dataSpace>ProductReference</dataSpace> <dataSet>productCatalog</dataSet> <refresh>onCommit</refresh> <table> <path>/root/domain1/tableA</path> <nameInDatabase>PRODUCT_REF_A</nameInDatabase> </table> <table> <path>/root/domain1/tableB</path> <nameInDatabase>PRODUCT_REF_B</nameInDatabase> <element> <path>/retailers</path> <nameInDatabase>PRODUCT_REF_B_RETAILERS</nameInDatabase> </element> </table> </osd:replication> </xs:appinfo> </xs:annotation> ...</xs:schema> |
Remarques :
Voir Restrictions du modèle de données pour les tables répliquées
Si, lors de la compilation du modèle de données, le jeu de données et/ou l'espace de données spécifiés n'existent pas dans le référentiel courant, un avertissement est émis, mais la table des réplicats est créée dans la base de données. Une fois que l'espace de données et le jeu de données sont créés, la réplication est activée.
Si, lors de la compilation d'un modèle de données, une table répliquée est effacée, ou si certaines des propriétés ci-dessus ont été modifiées, la réplique est effacée de la base de données, puis recréée avec la nouvelle définition si besoin.
Le comportement par défaut d'une table répliquée est la copie de tous ses éléments pris en charge (voir Restrictions du modèle de données pour les tables répliquées).
Il est possible de désactiver la réplication pour un champ ou un groupe spécifique, soit grâce à l'assistant de modèle de données, soit en modifiant le modèle de données sous-jacent.
Pour désactiver la réplication d'un champ ou d'un groupe en modifiant le modèle de données, utiliser l'élément osd:replication avec l'attribut disable="true".
<xs:element name="longDescription" type="xs:string"> <xs:annotation> <xs:appinfo> <osd:replication disable="true" /> </xs:appinfo> </xs:annotation></xs:element> |
Pour désactiver la réplication d'un champ ou d'un groupe à l'aide de l'assistant du modèle de données, utiliser la propriété Replication des Advanced properties de l'élément.
Lorsque cette propriété est définie sur un groupe, la réplication est désactivée récursivement pour tous ses descendants. Une fois que la réplication a été désactivée sur un groupe, il n'est pas possible de la ré-activer sur un descendant.
Si la table contenant le champ ou le groupe n'est pas répliquée, cette propriété n'aura aucun effet.
Il n'est pas possible de désactiver la réplication pour les champs de clé primaire.
Cette section décrit comment accéder directement à une réplique en utilisant SQL.
Pour chaque table de réplique d'EBX®, une table correspondante est générée dans le SGBDR. Grâce à l'interface utilisateur d'EBX®, il est possible de trouver le nom de cette table de base de données en cliquant sur le panneau de documentation de la table.
L'accès direct aux répliques en base de données n'est autorisé qu'en mode lecture-seule. Il est de la responsabilité de l'administrateur de la base de données de bloquer l'accès en écriture à tous les utilisateurs de la base de données à l'exception de celui utilisé par EBX®.
Les lectures directes en SQL sont possibles sur des transactions bien encadrées et de préférence de courte durée. Toutefois, pour de tels accès, les permissions d'EBX® ne sont pas prises en compte. Par conséquent, les applications ayant le droit d'effectuer des lectures doivent être sécurisées par le biais de permissions et de processus d'authentification tiers.
La politique d'actualisation 'onDemand' nécessite une requête explicite pour actualiser les données de la table répliquée.
Il y a plusieurs moyens pour demander une actualisation de réplication :
Interface utilisateur : Dans le menu d'actions du jeu de données, utiliser l'action 'Rafraîchir les répliques' sous le groupe 'Réplication' pour lancer l'assistant d'actualisation de réplication.
Services de données: Utiliser l'opération de services de données de l'actualisation des réplications. Voir Replication refresh pour davantage d'informations concernant les services de données.
API Java : Appeler les méthodes ReplicationUnit.performRefresh dans l'API ReplicationUnit afin d'actualiser l'unité de réplication.
La fonctionnalité de réplication a certains impacts et des limitations connues, listés ci-dessous. En cas d'utilisation de la réplication, il est fortement conseillé de lire attentivement ces limitations et de contacter le support de Cloud Software Group, Inc. pour toute question.
Voir Supported databases pour les bases de données qui prennent en charge la réplication.
Certaines contraintes de modèle de données d'EBX® deviennent bloquantes lorsque la réplication est activée. Pour plus d'informations, voir Contraintes structurelles.
Certaines restrictions s'appliquent aux modèles de données contenant des tables répliquées :
L'héritage de jeu de données n'est pas pris en charge dans le cas de la politique d'actualisation 'onCommit' si le jeu de données spécifié n'est pas un jeu de données racine ou s'il n'a pas encore été créé. Voir héritage de jeu de données pour plus d'informations.
De la même manière, l'héritage de champ est uniquement pris en charge pour la politique d'actualisation 'onDemand'. Cela signifie qu'à la compilation du modèle de données, une erreur est émise si le mode d'actualisation est 'onCommit' et que la table devant être répliquée a un champ hérité. Voir champs hérités pour plus d'informations.
Les valeurs calculées sont ignorées.
Il existe des limitations pour deux catégories de listes agrégées : les listes agrégées sous une autre liste agrégée, et les listes agrégées sous un groupe terminal. Les modèles de données contenant de telles listes agrégées peuvent être utilisées, toutefois ces listes seront ignorées (non repliquées).
Les attributs personnalisés ne sont pas pris en charge. Une erreur de compilation est émise s'ils sont inclus dans une unité de réplication.
Les évolutions du modèle de données peuvent aussi être limitées par le SGBDR sous-jacent, en fonction des données déjà contenues dans les tables concernées.
L'opération d'actualisation est optimisée pour transmettre uniquement les lignes de la table source qui ont été modifiées (création et suppression) depuis la dernière actualisation. Toutefois, en fonction du volume de données échangées, cette opération peut se révéler volumineuse et nécessiter des transactions importantes. En particulier, la première opération d'actualisation peut concerner un grand nombre de lignes. Il est nécessaire que la base de données soit configurée correctement afin de permettre l'exécution de ces transactions de manière optimale.
Par exemple, avec Oracle :
Il est impératif que l'ensemble des tables de réplique dans une unité de réplication puisse être contenu dans l'espace de table 'UNDO'.
Il est recommandé de fournir suffisamment d'espace dans le cache de données afin de permettre à ces transactions de s'exécuter avec un minimum d'accès disque.
Il est recommandé de réserver suffisamment d'espace pour les groupes de logs 'REDO' pour que les transactions n'aient pas à attendre le processus 'db_writer'.
La réplication est disponible sur le master D3 ainsi que sur les espaces de données de livraison esclaves. Sur le master, le comportement de réplication est le même que dans un espace de données sémantique standard, mais sur les esclaves, le contenu répliqué est celui de la dernière image diffusée.
Dans un espace de données de livraison esclave, certaines restrictions s'appliquent :
La politique d'actualisation définie dans le modèle de données n'a aucune influence sur le comportement décrit plus haut : la réplication se déclenche toujours à la suite de la création de l'image.
L'action Refresh replicas n'est pas disponible.
L'invocation de la méthode ReplicationUnit.performRefresh n'est pas autorisée.
Dans le cas de l'héritage, un champ d'enregistrement répliqué ne peut être une "valeur héritée" (AdaptationValue.INHERIT_VALUE). Il ne fait que contenir la valeur héritée dans ce genre de cas. Plus généralement, il n'est pas possible de distinguer l'état héritage de l'état réécriture.