Comment Le système génère un BOD

Voici les étapes que suit le système pour générer un BOD.

1. Cette application utilise son moteur de réplication pour générer chaque BOD. Deux processus distincts peuvent déclencher la génération d'un BOD :
   • Génération de tables : Une modification est apportée à une table et déclenche une demande UpdateCollection.
   • Génération de fonction : Un événement métier se produit dans le système et déclenche un appel de méthode distante.

   Chacun de ceux-ci est considéré comme un point d'intégration de la génération de BOD. Les événements métier qui génèrent un BOD sont répertoriés dans l'écran Réf-X docs de réplication émis.

   Exemple 1 - Génération de tables : Lorsque vous ajoutez un nom de table à une catégorie de réplication, toute modification apportée à un enregistrement de la table déclenche la génération d'un BOD. Si cet élément est trop général, c'est-à-dire que vous ne souhaitez pas qu'un BOD soit généré à chaque contact avec un élément de cette table, vous pouvez limiter la génération de BOD à l'aide de l'attribut Filtre pour définir un filtre déterminant si un changement dans la table déclenche la génération d'un BOD. Ne sont inclus que les enregistrements correspondant au filtre. Il existe également 3 cases à cocher qui vous permettent de limiter la génération de BOD sur la base du type de changement apporté à la table : Ignorer insert., Ignorer màj et Ignorer suppr. Tout ceci est effectué via l'écran Catég. réplication.

   Exemple 2 - Génération de fonctions : Utilisez cette technique si un simple trigger (déclencheur) reposant sur une mise à jour de table ne vous convient pas. Par exemple, supposons que vous souhaitiez déclencher un BOD à la création d'un nouvel ordre d'achat. Etant donné qu'un ordre d'achat se constitue de données hiérarchiques et peut comporter de nombreuses lignes et versions, il est impossible d'identifier une table unique déclenchant la génération de BOD. Vous ne disposez d'aucun moyen de savoir quand la dernière ligne ou version a été insérée.

   Autre exemple : si vous souhaitez déclencher la génération de BOD à l'occasion d'un événement d'application qui n'a aucun lien avec une mise à jour de table, vous pouvez déclencher par programme la mise à jour du BOD à l'aide d'un trigger "Fonction". Le nom "Fonction" indiqué dans l'écran Catég. réplication ne correspond que rarement à une procédure enregistrée réelle. Il s'agit simplement d'un paramètre transmis vers l'une des procédures enregistrées dans le système de réplication qui déclenche la génération de BOD. La procédure enregistrée porte le nom de RemoteMethodForReplicationTargetSp. Vous pouvez également appeler cette procédure enregistrée à partir d'un trigger, d'un autre SP ou d'une classe d'extension IDO.

   Pour illustrer le trigger de l'ordre d'achat mentionné ci-dessus : Un utilisateur exécute l'ordre d'achat (état) pour créer un nouvel ordre d'achat. Dans le cadre de la logique exécutée, la procédure enregistrée TriggerPurchaseOrderSyncSp est appelée via un appel de méthode distante, ce qui déclenche la logique de réplication de la génération de BOD.

   Les procédures enregistrées appelées via un appel de méthode distante ne sont pas de réelles procédures enregistrées existant dans la base de données. L'appel peut transmettre ou non des paramètres. Si l'appel transmet des paramètres, les écrans Docs de réplication feront référence à ceux-ci dans l'ordre, c'est-à-dire que P1 fera référence au premier paramètre, P2 fera référence au second paramètre, etc. L'extrait de code suivant montre les deux paramètres transmis par un appel de méthode distante à la procédure TriggerPurchaseOrderSyncSp :

   
    EXEC @Severity  = dbo.RemoteMethodForReplicationTargetsSp                          
      @IdoName        = 'SL.ESBSLPos'
    , @MethodName = 'TriggerPurchaseOrderSyncSp'
    , @Infobar           = @Infobar OUTPUT
    , @Parm1Value   = @PoPoNum
    , @Parm2Value   = @Infobar

2. Dans l'écran Catég. réplication, chaque catégorie contient l'ensemble des tables et fonctions nécessaires à la réplication d'une partie donnée du système. Une catégorie appelée ESB contient l'ensemble des appels de méthode distante définis ou les noms d'objet auxquels font référence les documents de réplication pour les points d'intégration aux autres applications nécessitant des XML au format de BOD Infor. TriggerPurchaseOrderSyncSp est par exemple répertorié dans la catégorie ESB.

   Pour des documents XML génériques (c'est-à-dire les documents destinés aux applications nécessitant que les XML ne soient pas au format de BOD Infor), vous devrez créer une catégorie de réplication distincte contenant les appels de méthode distante appropriés ou les noms d'objet.

3. Si une règle de réplication existe entre un site local et un site Infor ESB pour lequel la catégorie est définie sur ESB, chaque fois qu'une modification de table ou d'événement métier avec un point d'intégration se produit au niveau du site local, le système ajoute une entrée dans les tables de réplication.

   Pour des documents XML génériques, vous devrez créer une règle de réplication entre un site local et le site défini pour l'application. Ce site doit être configuré sur un intranet défini de manière à utiliser le protocole de transport HTTP.

4. Le réplicateur extrait les lignes des tables de réplication et les place dans MSMQ.
5. ReplQListener extrait les lignes de MSMQ et détermine qu'il s'agit de lignes devant être envoyées à d'autres applications BOD. Il génère ensuite un BOD pour la modification de table ou d'événement métier. Comme cela a déjà été indiqué, l'événement peut transmettre des paramètres.

   Dans notre exemple 2 ci-dessus, un utilisateur exécute l'ordre d'achat (état), qui appelle TriggerPurchaseOrderSyncSp. Une règle existant pour une catégorie dans laquelle cette procédure est définie, le système crée un document de réplication. Il trouve une référence croisée de réplication pour PurchaseOrder.Sync où la méthode S'applique à est TriggerPurchaseOrderSyncSp ; il récupère donc le modèle de document de réplication PurchaseOrder et crée le document XML BOD, en utilisant le nom et le verbe définis dans l'écran Réf-X docs de réplication émis, ainsi que les informations d'élément et d'attribut définies dans les écrans Docs de réplication, Eléments docs de réplication et Attributs docs de réplication.

   Dans cet exemple, le numéro d'ordre d'achat est transmis en tant que premier paramètre (P1). Le document de réplication utilise ces informations dans un filtre (PoNum=FP(P1)) de manière à ce que le BOD généré ne contienne des données que pour l'ordre d'achat spécifié.

6. ReplQueueListener place le XML BOD généré dans la Boîte envoi docs de réplication.

   Les documents XML génériques, plutôt que d'être dirigés vers la boîte d'envoi, sont envoyés à l'URL de intranet définie pour une réplication non transactionnelle.