Méthode ICrmLogControl ::RegisterCompensator (comsvcs.h)

Article
02/28/2024

Le worker CRM utilise cette méthode pour inscrire l’compensateur CRM auprès de l’infrastructure CRM. Il doit s’agir de la première méthode appelée par le worker CRM, et elle ne peut être appelée avec succès qu’une seule fois. Si le worker CRM reçoit un code d’erreur « récupération en cours » lors de l’appel de cette méthode, il doit appeler cette méthode à nouveau jusqu’à ce qu’elle ait réussi.

Syntaxe

HRESULT RegisterCompensator(
  [in] LPCWSTR lpcwstrProgIdCompensator,
  [in] LPCWSTR lpcwstrDescription,
  [in] LONG    lCrmRegFlags
);

Paramètres

[in] lpcwstrProgIdCompensator

ProgId du compensateur CRM. Le CLSID du compensateur CRM sous forme de chaîne est également accepté.

[in] lpcwstrDescription

Chaîne de description à utiliser par les interfaces de supervision.

[in] lCrmRegFlags

Indique à partir de l’énumération CRMREGFLAGS que contrôlent les phases d’achèvement de transaction qui doivent être reçues par le compensateur CRM et si la récupération doit échouer si des transactions douteuses subsistent après la tentative de récupération.

Valeur retournée

Cette méthode peut retourner les valeurs suivantes.

Code de retour	Description
S_OK	La commande s'est correctement terminée.
E_POINTER	Un pointeur NULL a été fourni en tant qu’argument.
E_UNEXPECTED	Une erreur inattendue s’est produite.
XACT_E_NOTRANSACTION	Le composant qui crée le commis CRM n’a pas de transaction.
XACT_E_RECOVERYINPROGRESS	La récupération du fichier journal CRM est toujours en cours.
XACT_E_RECOVERY_FAILED	La récupération du fichier journal CRM a échoué en raison de transactions douteuses.
XACT_E_WRONGSTATE	Cette méthode a été appelée dans un état incorrect ; avant RegisterCompensator ou lorsque la transaction est terminée (CRM Worker).
E_OUTOFMEMORY	Une erreur de mémoire insuffisante s’est produite.
E_NOINTERFACE	Le compensateur CRM ne prend pas en charge au moins une des interfaces requises (ICrmCompensator ou ICrmCompensatorVariants).

Remarques

Le paramètre lCrmRegFlags permet à l’implémenteur de décider quelles phases d’achèvement de transaction le compensateur CRM souhaite recevoir. Certains compensateurs CRM peuvent n’effectuer aucun travail pendant la phase de préparation et n’ont donc pas besoin de recevoir de notifications de préparation ; il peut améliorer les performances pour spécifier qu’aucune phase de préparation n’est requise dans ce cas.

Il est recommandé de développer les workers CRM et les compensateurs CRM en tant que composants threadés « Both » (Threading Model = Any Apartment). Toutefois, dans certains cas, cela peut ne pas être possible en raison de contraintes de langage (par exemple, lors du développement de crms avec Visual Basic). Les compensateurs CRM avec threads d’appartement (Threading Model = Single Thread Apartment) sont bloqués dans la phase de préparation, sauf si leur propriété de synchronisation est définie sur « non pris en charge ». Une autre alternative pour les compensateurs CRM avec thread d’appartement consiste à ignorer la phase de préparation si ce n’est pas nécessaire.

Dans les scénarios avec plusieurs coordinateurs de transactions distribuées (DTC), il est possible qu’une transaction DTC passe à l’état doute. Normalement, cela est dû au fait qu’une interruption s’est produite pendant une transaction et que l’auteur de la transaction ne peut pas être contacté pour connaître le résultat de la transaction. Dans ce cas, l’infrastructure CRM ne peut pas déterminer le résultat de la transaction. Un implémenteur CRM peut décider si de nouvelles transactions doivent être autorisées dans ce cas.

L’indicateur « échec si les doutes restent » est utilisé comme suit : en spécifiant l’indicateur « échec si les doutes demeurent » sur RegisterCompensator, si les transactions douteuses restent après la récupération, l’appel à RegisterCompensator échoue avec un code d’erreur « échec de la récupération ». Si l’indicateur « échec si des doutes subsistent » n’est pas spécifié, la récupération réussit, de nouvelles transactions sont autorisées et les transactions douteuses restent dans le fichier journal CRM. L’infrastructure CRM tente de résoudre à nouveau ces transactions douteuses lors de la prochaine récupération (lorsque le processus du serveur d’applications est redémarré).

Configuration requise

Condition requise	Valeur
Client minimal pris en charge	Windows 2000 Professionnel [applications de bureau uniquement]
Serveur minimal pris en charge	Windows 2000 Server [applications de bureau uniquement]
Plateforme cible	Windows
En-tête	comsvcs.h

Voir aussi

ICrmLogControl

Partager via