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 travailleurs CRM nécessitent toujours une transaction.

Pour accéder à COM+ CRM, le worker CRM obtient d’abord l’interface ICrmLogControl , ce qui permet au worker CRM d’écrire des enregistrements dans le journal durable. Le travailleur CRM obtient cette interface en créant un composant de commis CRM.

Ensuite, le travailleur CRM doit indiquer au commis CRM le nom de l’intervenant CRM qu’il souhaite utiliser. Elle le fait en appelant la méthode ICrmLogControl::RegisterCompensator . Une fois cette méthode appelée, la compensation CRM est créée par l’infrastructure CRM lorsque la transaction se termine.

Une fois que le travailleur CRM a inscrit son compensation CRM, il peut écrire des enregistrements dans le journal CRM à l’aide d’ICrmLogControl. Le worker CRM doit écrire avant ; autrement dit, il doit écrire un enregistrement dans le journal décrivant une action avant qu’elle n’exécute réellement l’action, en cas d’incident se produit immédiatement après la fin de l’action. Sans ces enregistrements de journal en écriture avant, il n’existe aucun moyen de corriger l’action.

En outre, l’écriture en avance signifie que le CRM Compensation, qui est le composant qui reçoit les enregistrements de journal sur la récupération, doit traiter le cas où les enregistrements du journal ont été écrits, mais l’action n’a pas eu lieu en fait. Les actions effectuées par le répêdateur CRM doivent être idempotentes; c’est-à-dire qu’ils doivent être capables d’ê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é qui est généré en tant que collection de Variants. Il est principalement utilisé lors du développement de CRMs 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 CRMs 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.

Remarque

Vous ne devez pas être des types de pointeurs utilisateur dans des structures de données dans un enregistrement de journal. Les pointeurs ne sont plus valides au cours de la phase de récupération, car le serveur de compensation CRM s’exécute dans un processus différent de celui du travailleur CRM qui a écrit l’enregistrement du journal. L’inclusion de types de pointeurs dans un enregistrement de journal peut entraîner un blocage ou une corruption d’une application lors de 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 les écritures différées à accumuler avant de forcer sur le disque peut 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 pour la récupération d’échec.

Lorsque le worker CRM est terminé avec ses actions et a terminé l’écriture et le forçage des enregistrements dans le journal, il doit libérer ICrmLogControl. Lorsque la transaction se termine (généralement en raison du composant d’application appelant SetComplete ou SetAbort), l’infrastructure CRM crée le composant compensation CRM, qui implémente l’interface ICrmCompensator ou l’interface ICrmCompensatorVariants . Ces interfaces sont utilisées pour transmettre les enregistrements non structurés (Visual C++) ou structurés (Visual Basic) au CRM Compensation, ainsi que les notifications de résultat des transactions.

L’indemnisation CRM est d’abord avertie de la phase de préparation de la fin de la transaction et peut voter oui ou non à la demande de préparation. Si le CRM Compensation ne vote pas, il ne reçoit aucune notification d’abandon supplémentaire. S’il vote oui à la demande de préparation, il reçoit les notifications de validation ou d’abandon. Dans le cas d’une abandon du client, aucune notification de préparation n’est reçue, mais uniquement les notifications d’abandon. La compensation CRM doit être préparée pour traiter tous ces cas, et elle doit également gérer le cas où aucun enregistrement de journal n’a été écrit par le travailleur CRM. Le résumeur CRM ne doit pas supposer que la même instance de compensation CRM recevra à la fois la phase 1 (préparer) et les notifications de phase 2 (validation ou abandon), car elles pourraient être interrompues par la récupération.

En règle générale, une compensation CRM utilise la notification d’abandon pour inverser l’action effectuée par le travailleur CRM. Le worker CRM peut laisser un état disponible dans le cas où il doit inverser son action. Cet état peut être entièrement contenu dans les enregistrements de journal et, si ce n’est pas le cas, le crm Compensation doit nettoyer cet état si la transaction est validée. Il s’agit de la raison pour laquelle la compensation CRM reçoit la notification de validation. La compensation CRM ne s’exécute pas sous une transaction DTC.

Le compensation CRM peut enregistrer de nouveaux enregistrements si nécessaire à l’aide d’ICrmLogControl, qu’il reçoit à mesure qu’il est créé. Le travailleur CRM et le compensation CRM peuvent également oublier le dernier enregistrement du journal qu’ils ont écrit, ce qui peut être nécessaire pour éviter une récupération inutile.

Concepts de Resource Manager de compensation COM+

Démarrage et récupération COM+ CRM