Partager via

Liaison de déclencheur SignalR Service pour Azure Functions

  • Article

Utilisez la liaison de déclencheur SignalR pour répondre aux messages envoyés par Azure SignalR Service. Quand la fonction est déclenchée, les messages passés à la fonction sont analysés en tant qu’objets JSON.

Dans le mode sans serveur du service SignaIR, le service SignaIR utilise la fonctionnalité en amont pour envoyer des messages du client vers Function App. Et Function App utilise la liaison de déclencheur de service SignalR pour gérer ces messages. L’architecture générale est illustrée ci-dessous :

Architecture du déclencheur SignalR

Pour plus d’informations sur les détails d’installation et de configuration, consultez la vue d’ensemble.

Exemple

Une fonction C# peut être créée à l’aide de l’un des modes C# suivants :

  • Modèle worker isolé : fonction C# compilée exécutée dans un processus worker isolé du runtime. Le processus Worker isolé est requis pour prendre en charge les fonctions C# exécutées sur les versions LTS et non-LTS de .NET et de .NET Framework.
  • Modèle In-process : fonction C# compilée exécutée dans le même processus que le runtime Functions.
  • Script C# : principalement utilisé lors de la création de fonctions C# dans le portail Azure.

Important

La prise en charge du modèle in-process prendra fin le 10 novembre 2026. Pour continuer à bénéficier d’une prise en charge complète, nous vous recommandons vivement de migrer vos applications vers le modèle worker isolé.

L’exemple suivant montre une fonction C# qui reçoit un événement de message des clients et journalise le contenu du message.

[Function(nameof(OnClientMessage))]
public static void OnClientMessage(
    [SignalRTrigger("Hub", "messages", "sendMessage", "content", ConnectionStringSetting = "SignalRConnection")]
        SignalRInvocationContext invocationContext, string content, FunctionContext functionContext)
{
    var logger = functionContext.GetLogger(nameof(OnClientMessage));
    logger.LogInformation("Connection {connectionId} sent a message. Message content: {content}", invocationContext.ConnectionId, content);
}

Important

Le modèle basé sur des classes des liaisons SignalR Service dans un worker isolé C# n’optimise pas la façon dont vous écrivez des déclencheurs SignalR en raison de la limitation du modèle worker C#. Pour plus d’informations sur le modèle basé sur des classes, consultez Modèle basé sur la classe.

Le déclencheur SignalR n’est actuellement pas pris en charge pour Java.

Voici les données de liaison dans le fichier function.json :

{
    "type": "signalRTrigger",
    "name": "invocation",
    "hubName": "hubName1",
    "category": "messages",
    "event": "SendMessage",
    "parameterNames": [
        "message"
    ],
    "direction": "in"
}

app.generic("function1",
    {
        trigger: { "type": "signalRTrigger", "name": "invocation", "direction": "in", "hubName": "hubName1", "event": "SendMessage", "category": "messages" },
        handler: (triggerInput, context) => {
            context.log(`Receive ${context.Arguments[0]} from ${triggerInput.ConnectionId}.`)
        }
    })

Des exemples PowerShell complets sont à venir.

Voici le code Python :

import logging
import json
import azure.functions as func

def main(invocation) -> None:
    invocation_json = json.loads(invocation)
    logging.info("Receive {0} from {1}".format(invocation_json['Arguments'][0], invocation_json['ConnectionId']))

Attributs

Les bibliothèques C# in-process et de processus Worker isolé utilisent l’attribut SignalRTrigger pour définir la fonction. Le script C# utilise à la place un fichier config function.json.

Le tableau ci-dessous explique les propriétés de l’attribut SignalRTrigger.

Propriété d’attribut Description
HubName Cette valeur doit être définie sur le nom du hub SignalR pour que la fonction soit déclenchée.
Catégorie Cette valeur doit être définie sur la catégorie des messages pour que la fonction soit déclenchée. La catégorie peut être l’une des valeurs suivantes :
  • connections : pour les événements connected et disconnected
  • messages : pour tous les autres événements, hormis ceux de la catégorie connections
Event Cette valeur doit être définie sur l’événement des messages pour que la fonction soit déclenchée. Pour la catégorie messages, l’événement est target dans les messages d’appel que les clients envoient. Pour la catégorie connections, seuls les événements connected et disconnected sont utilisés.
ParameterNames (Facultatif) Liste des noms liés aux paramètres.
ConnectionStringSetting Nom du paramètre d’application contenant la chaîne de connexion SignalR Service, dont la valeur par défaut est AzureSignalRConnectionString.

Annotations

Il n’existe actuellement aucune annotation Java prise en charge pour un déclencheur SignalR.

Configuration

Le tableau suivant décrit les propriétés de configuration de liaison que vous définissez dans le fichier function.json.

Propriété function.json Description
type Cette propriété doit être définie sur SignalRTrigger.
direction Cette propriété doit être définie sur in.
name Nom de variable utilisé dans le code de fonction pour le contexte d’appel du déclencheur.
hubName Cette valeur doit être définie sur le nom du hub SignalR pour que la fonction soit déclenchée.
category Cette valeur doit être définie sur la catégorie des messages pour que la fonction soit déclenchée. La catégorie peut être l’une des valeurs suivantes :
  • connections : pour les événements connected et disconnected
  • messages : pour tous les autres événements, hormis ceux de la catégorie connections
event Cette valeur doit être définie sur l’événement des messages pour que la fonction soit déclenchée. Pour la catégorie messages, l’événement est target dans les messages d’appel que les clients envoient. Pour la catégorie connections, seuls les événements connected et disconnected sont utilisés.
parameterNames (Facultatif) Liste des noms liés aux paramètres.
connectionStringSetting Nom du paramètre d’application contenant la chaîne de connexion SignalR Service, dont la valeur par défaut est AzureSignalRConnectionString.

Pour obtenir des exemples complets, consultez la section Exemple.

Utilisation

Payloads

Le type d’entrée du déclencheur est déclaré comme étant InvocationContext ou un type personnalisé. Si vous choisissez InvocationContext, vous obtenez un accès complet au contenu de la demande. Pour un type personnalisé, le runtime tente d’analyser le corps de la requête JSON pour définir les propriétés de l’objet.

InvocationContext

InvocationContext contient tout le contenu du message envoyé par un service SignalR, qui comprend les propriétés suivantes :

Propriété Description
Arguments Disponible pour la catégorie messages. Contient des arguments dans le message d’appel
Error Disponible pour l’événement disconnected. Elle peut être vide si la connexion s’est fermée sans erreur ou si elle contient les messages d’erreur.
Hub Nom du hub auquel appartient le message.
Catégorie Catégorie du message.
Événement Événement du message.
ConnectionId ID de connexion du client qui envoie le message.
UserId Identité d’utilisateur du client qui envoie le message.
En-têtes en-têtes de la requête.
Requête Requête de la demande lorsque les clients se connectent au service.
Revendications Revendications du client.

Utilisation de ParameterNames

La propriété ParameterNames dans SignalRTrigger vous permet de lier les arguments des messages d’appel aux paramètres des fonctions. Vous pouvez utiliser le nom que vous avez défini dans le cadre des expressions de liaison dans d’autres liaisons ou en tant que paramètres dans votre code. C’est un moyen plus pratique d’accéder aux arguments de InvocationContext.

Imaginons que vous ayez un client JavaScript SignalR qui tente d’appeler la méthode broadcast dans Azure Function avec deux arguments message1, message2.

await connection.invoke("broadcast", message1, message2);

Une fois que vous avez défini parameterNames, les noms que vous avez définis correspondent aux arguments envoyés côté client.

[SignalRTrigger(parameterNames: new string[] {"arg1, arg2"})]

Ensuite, le arg1 contenu contient le contenu , message1et arg2 contient le contenu de message2.

Considérations ParameterNames

L’ordre de la liaison de paramètre est important. Si vous utilisez ParameterNames, l’ordre dans ParameterNames correspond à l’ordre des arguments que vous appelez dans le client. Si vous utilisez l’attribut [SignalRParameter] en C#, l’ordre des arguments dans les méthodes Azure Functions correspond à l’ordre des arguments dans les clients.

ParameterNames et l’attribut [SignalRParameter] ne peuvent pas être utilisés en même temps, ou vous obtiendrez une exception.

Intégration du service signalR

Le service signalR a besoin d’une URL pour accéder à Function App lorsque vous utilisez la liaison de déclencheur de service SignalR. L’URL doit être configurée dans paramètres en amont du côté service SignalR.

Portail en amont

Lorsque vous utilisez le déclencheur SignalR Service, l’URL peut être simple et mise en forme comme suit :

<Function_App_URL>/runtime/webhooks/signalr?code=<API_KEY>

Vous trouverez la Function_App_URL page Vue d’ensemble de l’application de fonction et la API_KEY fonction Azure est générée. Vous pouvez récupérer API_KEY à partir de signalr_extension dans le panneau API_KEY de Function App. Clé API

Si vous souhaitez utiliser plusieurs Function App avec un service SignalR, les règles de routage complexes peuvent être prises en charge en amont. Pour plus d’informations, consultez Paramètres en amont.

Exemple pas à pas

Vous pouvez suivre l’exemple dans GitHub pour déployer une salle de conversation sur Function App avec la liaison de déclencheur du service SignalR et la fonctionnalité en amont : Exemple de salle de conversation bidirectionnelle

Étapes suivantes