Lorsque vous êtes prêt à copier les données de tables du serveur de production vers le serveur de transfert, utilisez l'utilitaire de copie de transfert. Les tables pouvant être copiées sont répertoriées dans la rubrique Tables de transfert. Après la configuration du serveur de transfert pour des tables personnalisées, vous pouvez également copier, dans le serveur de transfert, toute nouvelle table créée pour stocker des données personnalisées.
La table STAGLOG agit comme un journal interne. Chaque fois que vous modifiez un enregistrement dans une table d'un serveur de transfert, un déclencheur enregistre ce changement dans la table STAGLOG. Pour chaque enregistrement modifié, un déclencheur enregistre le type de modification (insertion, suppression ou mise à jour), le nom de la table dans laquelle se trouve l'enregistrement, ainsi que la clé primaire ou l'index à entrée unique de l'enregistrement. Lorsque vous avez fini de modifier et de tester les enregistrements de la base de données sur le serveur de transfert, l'utilitaire de propagation de transfert vous permet de retransmettre ces modifications au serveur de production.
Les tables de la base de données relevant du serveur de transfert ne doivent jamais être mises à jour sur la base de données de production au cours d'une session de transfert. Une session de transfert débute lorsque vous utilisez l'utilitaire de copie de transfert pour copier la base de données de production sur celle de transfert. Une session de transfert cesse lorsque vous utilisez à nouveau l'utilitaire de copie de transfert pour copier une autre session de transfert. Au début de la session de transfert, lorsque l'utilitaire a copié la base de données de production sur celle de transfert, ces deux bases de données sont synchronisées, pour ce qui est des tables protégées par le serveur de transfert. Lorsque ceci est réalisé, les modifications des tables de la base de données de production ne sont plus autorisées. Vous devez tout d'abord mettre à jour la base de données de transfert et lancer ensuite l'utilitaire de propagation pour propager les modifications apportées vers la base de données de production. Si vous mettez à jour les deux bases de données, votre propagation risque d'échouer du fait d'un conflit potentiel de clés ou d'une violation d'intégrité référentielle. Si vous devez mettre à jour la base de données de production au cours d'une session de transfert, utilisez l'utilitaire de copie de transfert pour synchroniser vos bases de données et commencez une nouvelle session de transfert.
Afin de garantir que les tables relevant du serveur de transfert ne sont jamais mises à jour sur la base de données de production au cours d'une session de transfert, elles doivent être sous le seul contrôle d'un administrateur de site. Parfois, les tables de transfert de votre base de données de production doivent être mises à jour par un client ou un commerçant après votre copie de transfert. Par exemple, vous ne pouvez empêcher un commerçant de modifier la table OFFRE dans la base de données de production après la copie de transfert. Dans cette situation, vous ne pouvez utiliser le serveur de transfert. Cependant, les objets RFQ sont une exception. Lorsque vous créez des objets RFQ sur la base de données de production, des colonnes sont insérées dans des tables d'échange de la base de données de production. Si vous créez des contrats dans la base de données de transfert, vous insérez également des colonnes dans les tables d'échange de la base de données de transfert. Dans ce cas, vous mettez à jour les mêmes tables de la base de données de transfert et la base de données de production.
Il existe quelques limites concernant le serveur de transfert lors de l'utilisation des objets RFQ. Vous devez également lancer l'utilitaire de Vérification de transfert pour trouver les éventuels conflits de clé d'index unique et les corriger avant de lancer l'utilitaire de Propagation de transfert pour propager les modifications à la base de données de production.
Dans un site classique de vente direct, les tables peuvent être divisées en deux groupes : les données de configuration et d'opération. Les tables de configuration contiennent des données relatives aux magasins, catalogues, entrées catalogue, langues, taxes, remises, etc. Ces tables sont contrôlées par l'administrateur de site ; un client particulier ne peut pas les modifier. Les tables d'exploitation contiennent des données relatives aux informations client, adresse, commandes, SET (transactions sécurisées), etc. Les clients ne peuvent modifier les tables d'exploitation. Le serveur de transfert ne traite que les tables de configuration. Pour connaître la liste des tables traitées par le serveur de transfert, reportez-vous à la rubrique Tables de transfert de WebSphere Commerce.
Il est également important de vérifier que les tables traitées par le serveur de transfert n'ont pas de référence de clés associées à des tables d'exploitation. Sinon, la propagation pourrait échouer du fait d'une suppression potentielle de la clé primaire de la base de données de production. Avant d'utiliser le serveur de transfert, vérifiez que seule l'entreprise est propriétaire des données d'exploitation et non l'utilisateur, tel que l'administrateur de catalogue.
Avant d'utiliser le serveur de transfert, il est important de connaître les informations suivantes :
![]() |