Activités d’écoute

Le SDK Teams expose un routeur Fluent afin que vous puissiez vous abonner à ces activités avec des méthodes de gestionnaire dédiées à l’aide d’un minimum d’API.

Le SDK Teams expose un routeur Fluent pour que vous puissiez vous abonner à ces activités avec @app.event("activity").

Le SDK Teams expose un routeur Fluent pour que vous puissiez vous abonner à ces activités avec app.on('<route>', …).

teams.OnMessage(async (context, cancellationToken) =>
{
    await context.SendAsync($"you said: {context.Activity.Text}", cancellationToken);
});

@app.on_message
async def handle_message(ctx: ActivityContext[MessageActivity]):
    await ctx.send(f"You said '{ctx.activity.text}'")

app.on('message', async ({ activity, send }) => {
  await send(`You said: ${activity.text}`);
});

Dans l’exemple ci-dessus, la context.Activity propriété est de type MessageActivity, qui a une Text propriété. Vous remarquerez que le gestionnaire ici ne renvoie rien, mais gère à la place l’activité Senden renvoyant un message. Pour les activités de messagerie, Teams ne s’attend pas à ce que votre application renvoie quoi que ce soit (bien qu’il soit généralement judicieux d’envoyer une sorte d’accusé de réception amical !).

Dans l’exemple ci-dessus, le ctx.activity paramètre est de type MessageActivity, qui a une text propriété. Vous remarquerez que le gestionnaire ici ne renvoie rien, mais le traite senden renvoyant un message. Pour les activités de messagerie, Teams ne s’attend pas à ce que votre application renvoie quoi que ce soit (bien qu’il soit généralement judicieux d’envoyer une sorte d’accusé de réception amical !).

Dans l’exemple ci-dessus, le activity paramètre est de type MessageActivity, qui a une text propriété. Vous remarquerez que le gestionnaire ici ne renvoie rien, mais le traite senden renvoyant un message. Pour les activités de messagerie, Teams ne s’attend pas à ce que votre application renvoie quoi que ce soit (bien qu’il soit généralement judicieux d’envoyer une sorte d’accusé de réception amical !).

D’autres types d’activités ont des propriétés différentes et d’autres résultats requis. Pour un gestionnaire donné, le SDK déterminera automatiquement le type de retour et appliquera également le type de activity retour correct.

Les commandes Slash arrivent sous forme de messages ciblés. Vérifiez-les Recipient.IsTargeted et traitez-les explicitement :

teams.OnMessage(async (context, cancellationToken) =>
{
    if (context.Activity.Recipient?.IsTargeted == true)
    {
        await context.SendAsync($"Received slash command: {context.Activity.Text}", cancellationToken);
    }
});

@app.on_message
async def handle_message(ctx: ActivityContext[MessageActivity]):
    if ctx.activity.recipient and ctx.activity.recipient.is_targeted:
        await ctx.send(f"Received slash command: {ctx.activity.text}")
        return

    await ctx.next()

app.on('message', async ({ activity, send, next }) => {
  if (activity.recipient?.isTargeted) {
    await send(`Received slash command: ${activity.text}`);
    return;
  }

  await next();
});

Dans le SDK Teams pour .NET, les gestionnaires d’activités ne forment pas une chaîne de traitement de type next(). Au lieu de cela, chaque gestionnaire qui correspond à une activité est appelé dans l’ordre dans lequel elle a été enregistrée, et un gestionnaire ne peut pas empêcher l’exécution des gestionnaires correspondants suivants. Si vous devez intercepter, court-circuiter ou encapsuler le traitement des demandes (par exemple, pour arrêter l’exécution lorsqu’une condition est remplie), implémentez ITurnMiddleware et contrôlez s’il faut appeler nextTurn(...).

Les event gestionnaires d’activité (et les attributs) suivent un modèle d’intergiciel similaire au python fonctionnement des intergiciels. Cela signifie que pour chaque gestionnaire d’activité, une next fonction est passée et peut être appelée pour passer le contrôle au gestionnaire suivant. Cela vous permet de créer une chaîne de gestionnaires qui peuvent traiter la même activité de différentes manières.

@app.on_message
async def handle_message(ctx: ActivityContext[MessageActivity]):
    """Handle message activities using the new generated handler system."""
    print(f"[GENERATED onMessage] Message received: {ctx.activity.text}")
    await ctx.next()

@app.on_message
async def handle_message(ctx: ActivityContext[MessageActivity]):
    """Handle message activities using the new generated handler system."""
    if ctx.activity.text == "/help":
        await ctx.send("Here are all the ways I can help you...")
    await ctx.next()

@app.on_message
async def handle_message(ctx: ActivityContext[MessageActivity]):
    await ctx.send(f"You said '{ctx.activity.text}'")

Les on gestionnaires d’activités suivent un modèle d’intergiciel similaire au express fonctionnement des intergiciels. Cela signifie que pour chaque gestionnaire d’activité, une next fonction est passée et peut être appelée pour passer le contrôle au gestionnaire suivant. Cela vous permet de créer une chaîne de gestionnaires qui peuvent traiter la même activité de différentes manières.

app.on('message', async ({ next }) => {
  console.log('global logger');
  next(); // pass control onward
});

app.on('message', async ({ activity, next }) => {
  if (activity.text === '/help') {
    await send('Here are all the ways I can help you...');
    return;
  }

  // Conditionally pass control to the next handler
  next();
});

app.on('message', async ({ activity }) => {
  // Fallthrough to the final handler
  await send(`Hello! you said ${activity.text}`);
});

Référence d’activité

L’application prend en charge un certain nombre de types d’activités :

Itinéraires d’activités principales

Itinéraires de configuration

Itinéraires de dialogue

Voies d’authentification

Itinéraires d’interaction de message

Itinéraires de gestion des fichiers

Itinéraires d’extension de message

Itinéraires du cycle de vie

Itinéraires de mise à jour de conversation

Itinéraires de réunion