Partager via

Transférer

Cette rubrique décrit le transfert dans le modèle de suivi d’activité Windows Communication Foundation (WCF).

Définition de transfert

Les transferts entre les activités représentent des relations causales entre les événements dans les activités associées au sein des points de terminaison. Deux activités sont liées à des transferts lorsqu'un contrôle circule entre ces activités, par exemple, un appel de méthode qui traverse des limites d'activité. Dans WCF, lorsque les octets sont reçus par le service, l’activité Écouter est transférée vers l’activité Réception des octets où l’objet message est créé. Pour obtenir une liste de scénarios de suivi de bout en bout, ainsi que leur conception d’activité et de suivi respective, consultez Scénarios de suivi de bout en bout.

Pour émettre des traces de transfert, utilisez le ActivityTracing paramètre sur la source de trace, comme illustré par le code de configuration suivant.

<source name="System.ServiceModel" switchValue="Verbose,ActivityTracing">

Utilisation du transfert pour mettre en corrélation les activités au sein des points de terminaison

Les activités et les transferts permettent à l’utilisateur de localiser de manière probabiliste la cause racine d’une erreur. Par exemple, si nous transférons de manière répétée entre les activités M et N respectivement dans les composants M et N, et qu’un incident se produit en N juste après le retour vers M, nous pouvons conclure qu’il est probable qu’il est dû au retour de données de N vers M.

Une trace de transfert est émise de l’activité M à l’activité N lorsqu’il existe un flux de contrôle entre M et N. Par exemple, N effectue un travail pour M en raison d’un appel de méthode qui traverse les limites des activités. N peut déjà exister ou a été créé. N est généré par M quand N est une nouvelle activité qui effectue un travail pour M.

Un transfert de M à N peut pas être suivi d’un transfert de N vers M. Cela est dû au fait que M peut générer du travail dans N et ne pas suivre quand N termine ce travail. En fait, M peut se terminer avant que N termine sa tâche. Cela se produit dans l’activité « Open ServiceHost » (M) qui génère des activités d’écouteur (N), puis se termine. Un transfert de N à M signifie que N a terminé le travail lié à M.

N peut continuer à effectuer d’autres traitements non liés à M, par exemple, une activité d’authentificateur existante (N) qui continue de recevoir des demandes de connexion (M) à partir de différentes activités de connexion.

Une relation d’imbrication n’existe pas nécessairement entre les activités M et N. Cela peut se produire pour deux raisons. Tout d’abord, lorsque l’activité M ne surveille pas le traitement réel effectué dans N bien que M initié N. Deuxièmement, quand N existe déjà.

Exemple de transferts

L’exemple suivant répertorie deux exemples de transfert.

  • Lorsque vous créez un hôte de service, le constructeur obtient le contrôle du code appelant ou le code appelant est transféré vers le constructeur. Lorsque le constructeur a terminé de s'exécuter, il retourne le contrôle au code appelant, ou le constructeur est transféré au code appelant. Il s’agit du cas d’une relation imbriquée.

  • Lorsqu'un écouteur commence à traiter des données de transport, il crée un nouveau thread et remet à l'activité Recevoir des octets le contexte de traitement approprié, c'est-à-dire en passant le contrôle et les données. Lorsque ce thread a terminé le traitement de la requête, l'activité de réception des octets ne renvoie rien à l'écouteur. Dans ce cas, la nouvelle activité de thread fait l'objet d'un transfert entrant mais pas d'un transfert sortant. Les deux activités sont liées, mais pas imbriquées.

Séquence de transfert d’activité

Une séquence de transfert d’activité bien formée comprend les étapes suivantes.

  1. Commencez une nouvelle activité, qui consiste à sélectionner un nouvel id gAId.

  2. Émettre une trace de transfert vers ce nouveau gAId à partir de l’ID d’activité actuel

  3. Définir le nouvel ID dans TLS

  4. Émettez une trace de démarrage pour indiquer le début de la nouvelle activité par.

  5. Revenir à l’activité d’origine se compose des éléments suivants :

  6. Émettre une trace de transfert vers le gAId d’origine

  7. Émettre une trace Stop pour indiquer la fin de la nouvelle activité

  8. Affecter au TLS l'ancien gAId

L’exemple de code suivant montre comment procéder. Cet exemple suppose qu'un appel bloquant est effectué lors du transfert vers la nouvelle activité, et inclut des suivis de suspension/reprise.

// 0. Create a trace source  
TraceSource ts = new TraceSource("myTS");  

// 1. remember existing ("ambient") activity for clean up  
Guid oldGuid = Trace.CorrelationManager.ActivityId;  
// this will be our new activity  
Guid newGuid = Guid.NewGuid();

// 2. call transfer, indicating that we are switching to the new AID  
ts.TraceTransfer(667, "Transferring.", newGuid);  

// 3. Suspend the current activity.  
ts.TraceEvent(TraceEventType.Suspend, 667, "Suspend: Activity " + i-1);  

// 4. set the new AID in TLS  
Trace.CorrelationManager.ActivityId = newGuid;  

// 5. Emit the start trace  
ts.TraceEvent(TraceEventType.Start, 667, "Boundary: Activity " + i);  

// trace something  
ts.TraceEvent(TraceEventType.Information, 667, "Hello from activity " + i);  

// Perform Work  
// some work.  
// Return  
ts.TraceEvent(TraceEventType.Information, 667, "Work complete on activity " + i);

// 6. Emit the transfer returning to the original activity  
ts.TraceTransfer(667, "Transferring Back.", oldGuid);  

// 7. Emit the End trace  
ts.TraceEvent(TraceEventType.Stop, 667, "Boundary: Activity " + i);  

// 8. Change the tls variable to the original AID  
Trace.CorrelationManager.ActivityId = oldGuid;

// 9. Resume the old activity  
ts.TraceEvent(TraceEventType.Resume, 667, "Resume: Activity " + i-1);

Voir aussi

  • Last updated on