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
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
Le support prendra fin pour le modèle in-process le 10 novembre 2026. Nous vous recommandons vivement de migrer vos applications vers le modèle worker isolé pour une prise en charge complète.
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 :
|
| 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 :
|
| 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.
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