Liaison de déclencheur SignalR Service pour Azure Functions

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 :

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

Exemple

Vous pouvez créer une fonction C# à 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. Un processus de travail isolé est nécessaire pour prendre en charge les fonctions C# s’exécutant sur la prise en charge à long terme (LTS) et les versions non LTS pour .NET et .NET Framework.
• Modèle in-process : fonction C# compilée qui s’exécute dans le même processus que le runtime Azure 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é.

Modèle de 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.

Modèle in-process

La liaison de déclencheur SignalR Service pour le modèle in-process C# a deux modèles de programmation. un modèle basé sur la classe et un modèle traditionnel. Le modèle basé sur la classe offre une expérience de programmation cohérente côté serveur SignalR. Le modèle traditionnel offre une plus grande souplesse et est similaire aux autres liaisons de fonction.

Avec un modèle basé sur la classe

Pour plus d’informations, consultez Modèle basé sur la classe.

public class HubName1 : ServerlessHub
{
    [FunctionName("SignalRTest")]
    public Task SendMessage([SignalRTrigger]InvocationContext invocationContext, string message, ILogger logger)
    {
        logger.LogInformation($"Receive {message} from {invocationContext.ConnectionId}.");
    }
}

Avec un modèle traditionnel

Le modèle traditionnel obéit à la convention d’Azure Function développée par C#. Si vous n’êtes pas familiarisé avec ce langage, vous pouvez vous reporter à ces documents.

[FunctionName("SignalRTest")]
public static Task Run([SignalRTrigger("SignalRTest", "messages", "SendMessage", parameterNames: new string[] {"message"})]InvocationContext invocationContext, string message, ILogger logger)
{
    logger.LogInformation($"Receive {message} from {invocationContext.ConnectionId}.");
}

Comme il peut être difficile d’utiliser ParameterNames dans le déclencheur, l’exemple suivant vous montre comment utiliser l’attribut SignalRParameter pour définir l’attribut message.

[FunctionName("SignalRTest")]
public static Task Run([SignalRTrigger("SignalRTest", "messages", "SendMessage")]InvocationContext invocationContext, [SignalRParameter]string message, ILogger logger)
{
    logger.LogInformation($"Receive {message} from {invocationContext.ConnectionId}.");
}

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"
}

Modèle v4

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

Modèle v3

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"
}

Voici le code JavaScript :

module.exports = function (context, invocation) {
    context.log(`Receive ${context.bindingData.message} from ${invocation.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.

Modèle de worker isolé

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

Propriété d’attribut	Descriptif
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
Événement	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 ou de la collection de paramètres qui contient le service SignalR chaîne de connexion, qui est AzureSignalRConnectionStringdéfini par défaut sur .

Modèle in-process

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

Propriété d’attribut	Descriptif
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
Événement	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 ou de la collection de paramètres qui contient le service SignalR chaîne de connexion, qui est AzureSignalRConnectionStringdéfini par défaut sur .

Commentaires

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

Paramétrage

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	Descriptif
type	Cette propriété doit être définie sur SignalRTrigger.
direction	Cette propriété doit être définie sur in.
nom	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.
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
événement	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 ou de la collection de paramètres qui contient le service SignalR chaîne de connexion, qui est AzureSignalRConnectionStringdéfini par défaut sur .

Pour obtenir des exemples complets, consultez la section Exemple.

Utilisation

Connexions basées sur des identités managées

Pour une sécurité optimale, votre application de fonction doit utiliser des identités managées lors de la connexion au service Azure SignalR au lieu d’utiliser une chaîne de connexion, qui contient une clé secrète partagée. Pour plus d’informations, consultez Autoriser les demandes adressées aux ressources Azure SignalR Service avec des identités managées Microsoft Entra.

Charges utiles

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.

Contexte d'Appel

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

Propriété	Descriptif
Les arguments	Disponible pour la catégorie messages. Contient des arguments dans le message d’appel
Erreur	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.
Centre	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.
ID utilisateur	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.

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.

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

• Développement et configuration Azure Functions avec Azure SignalR Service
• Exemple de liaison de déclencheur SignalR Service
• Exemple de liaison de déclencheur de service SignalR dans un processus Worker isolé