Processus d’exploitation COM+ CRM
En fonctionnement normal, un composant d’application s’exécutant dans un processus d’application serveur utilise un CRM COM+ en créant un worker CRM. Le worker CRM implémente une interface COM spécifique à la tâche qu’il est conçu pour effectuer. Le composant d’application doit s’exécuter sous une transaction afin que le worker CRM hérite de la transaction du composant d’application. Les workers CRM ont toujours besoin d’une transaction.
Pour accéder à COM+ CRM, le worker CRM obtient d’abord l’interface ICrmLogControl , qui lui permet d’écrire des enregistrements dans le journal durable. Le worker CRM obtient cette interface en créant un composant de commis CRM.
Ensuite, le collaborateur CRM doit indiquer au commis CRM le nom du compensateur CRM qu’il souhaite utiliser. Pour ce faire, il appelle la méthode ICrmLogControl::RegisterCompensator . Une fois cette méthode appelée, le compensateur CRM est créé par l’infrastructure CRM une fois la transaction terminée.
Une fois que le worker CRM a inscrit son compensateur CRM, il peut écrire des enregistrements dans le journal CRM à l’aide d’ICrmLogControl. Le collaborateur CRM doit écrire à l’avance ; Autrement dit, il doit écrire un enregistrement dans le journal décrivant une action avant d’effectuer l’action, au cas où un plantage se produit immédiatement après l’exécution de l’action. Sans ces enregistrements de journal en écriture anticipée, il n’existe aucun moyen de corriger l’action.
En outre, écrire à l’avance signifie que le compensateur CRM, qui est le composant qui reçoit les enregistrements de journal lors de la récupération, doit traiter le cas où les enregistrements de journal ont été écrits, mais où l’action n’a pas eu lieu en fait. Les actions du compensateur CRM doivent être idempotentes; c’est-à-dire qu’ils doivent pouvoir être exécutés plus d’une fois, mais doivent conduire au même résultat. Par exemple, la définition d’un solde de compte sur la valeur de 100 $ est une action idempotente ; l’ajout de 100 $ au solde du compte n’est pas.
L’interface ICrmLogControl fournit les deux méthodes suivantes pour écrire des enregistrements de journal :
- WriteLogRecordVariants est utilisé pour écrire un enregistrement de journal structuré créé en tant que collection de variants. Il est principalement utilisé lors du développement de crm dans Microsoft Visual Basic.
- WriteLogRecord est utilisé pour écrire un enregistrement de journal non structuré en tant que blob d’octets. Il est principalement utilisé lors du développement de CRM dans Microsoft Visual C++. Étant donné que les structures d’enregistrement en C sont souvent constituées d’un ensemble d’en-têtes et de champs qui peuvent être dispersés en mémoire, la méthode WriteLogRecord implémente une fonctionnalité de collecte qui réduit la copie des données.
Notes
Vous ne devez pas créer de type pointeur utilisateur dans les structures de données d’un enregistrement de journal. Les pointeurs ne sont plus valides pendant la phase de récupération, car le compensateur CRM s’exécute dans un processus différent de celui du worker CRM qui a écrit l’enregistrement du journal. L’inclusion de types de pointeurs dans un enregistrement de journal peut entraîner le blocage ou l’endommagement d’une application pendant la récupération.
Ces deux méthodes d’écriture écrivent un enregistrement de journal sur le disque, mais ne garantissent pas la durabilité de l’enregistrement. Tout en autorisant l’accumulation des écritures différées avant que le forçage sur le disque puisse améliorer les performances, vous pouvez utiliser la méthode ICrmLogControl::ForceLog à la place pour garantir que toutes les écritures effectuées par le CRM sont durables sur le disque, ce qui est important en cas de récupération d’échec.
Lorsque le worker CRM a terminé ses actions et a terminé d’écrire et de forcer les enregistrements dans le journal, il doit libérer ICrmLogControl. Une fois la transaction terminée (généralement en raison du composant d’application appelant SetComplete ou SetAbort), l’infrastructure CRM crée le composant compensateur CRM, qui implémente l’interface ICrmCompensator ou l’interface ICrmCompensatorVariants . Ces interfaces sont utilisées pour passer les enregistrements non structurés (Visual C++) ou structurés (Visual Basic) au compensateur CRM, ainsi que les notifications de résultats de transaction.
Le compensateur CRM est d’abord informé de la phase de préparation de l’achèvement de la transaction et peut voter oui ou non à la demande de préparation. Si le compensateur CRM vote non, il ne reçoit pas d’autres notifications d’abandon. S’il vote oui à la demande de préparation, il reçoit les notifications de validation ou d’abandon. Dans le cas d’un abandon du client, aucune notification de préparation n’est reçue, mais uniquement les notifications d’abandon. Le compensateur CRM doit être prêt à gérer tous ces cas, et il doit également gérer le cas où aucun enregistrement de journal n’a été correctement écrit par le travailleur CRM. Le compensateur CRM ne doit pas supposer que le même instance compensatoire CRM recevra à la fois les notifications de phase 1 (préparation) et de phase 2 (validation ou abandon), car celles-ci pourraient être interrompues par la récupération.
En règle générale, un compensateur CRM utilise la notification d’abandon pour inverser l’action effectuée par le worker CRM. Le worker CRM peut laisser un état disponible au cas où il aurait besoin d’inverser son action. Cet état peut être entièrement contenu dans les enregistrements de journal et, si ce n’est pas le cas, le compensateur CRM doit propre cet état si la transaction est validée. C’est la raison pour laquelle le compensateur CRM reçoit la notification de validation. Le compensateur CRM ne s’exécute pas sous une transaction DTC.
Le compensateur CRM peut enregistrer de nouveaux enregistrements si nécessaire à l’aide de ICrmLogControl, qu’il reçoit au fur et à mesure de sa création. Le worker CRM et le compensateur CRM peuvent également oublier le dernier enregistrement de journal qu’ils ont écrit, ce qui peut être nécessaire pour éviter une récupération inutile.
Rubriques connexes