SignalR Service-utlösarbindning för Azure Functions

Använd SignalR-utlösarbindningen för att svara på meddelanden som skickas från Azure SignalR Service. När funktionen utlöses parsas meddelanden som skickas till funktionen som ett json-objekt.

I serverlöst läge i SignalR Service använder SignalR Service funktionen Upstream för att skicka meddelanden från klienten till funktionsappen. Och Funktionsappen använder SignalR Service-utlösarbindning för att hantera dessa meddelanden. Den allmänna arkitekturen visas nedan:

Information om konfiguration och konfigurationsinformation finns i översikten.

Exempel

En C#-funktion kan skapas med något av följande C#-lägen:

• Isolerad arbetsmodell: Kompilerad C#-funktion som körs i en arbetsprocess som är isolerad från körningen. Isolerad arbetsprocess krävs för att stödja C#-funktioner som körs på LTS- och icke-LTS-versioner .NET och .NET Framework.
• Processmodell: Kompilerad C#-funktion som körs i samma process som Functions-körningen.
• C#-skript: Används främst när du skapar C#-funktioner i Azure-portalen.

Viktigt!

Supporten upphör för den pågående modellen den 10 november 2026. Vi rekommenderar starkt att du migrerar dina appar till den isolerade arbetsmodellen för fullt stöd.

Isolerad arbetsmodell

Följande exempel visar en C#-funktion som tar emot en meddelandehändelse från klienter och loggar meddelandeinnehållet.

[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);
}

Viktigt!

Klassbaserad modell av SignalR Service-bindningar i C#-isolerad arbetare optimerar inte hur du skriver SignalR-utlösare på grund av begränsningen i C#-arbetsmodellen. Mer information om klassbaserad modell finns i Klassbaserad modell.

Processmodell

SignalR Service-utlösarbindning för C#-in-processmodell har två programmeringsmodeller. Klassbaserad modell och traditionell modell. Klassbaserad modell ger en konsekvent signalR-programmering på serversidan. Den traditionella modellen ger mer flexibilitet och liknar andra funktionsbindningar.

Med klassbaserad modell

Mer information finns i Klassbaserad modell .

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

Med en traditionell modell

Den traditionella modellen följer konventionen för Azure Function som utvecklats av C#. Om du inte är bekant med det kan du lära dig av dokument.

[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}.");
}

Eftersom det kan vara svårt att använda ParameterNames i utlösaren visar följande exempel hur du använder SignalRParameter attributet för att definiera message attributet.

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

SignalR-utlösare stöds för närvarande inte för Java.

Här är bindningsdata i filen function.json :

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

Modell v4

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}.`)
        }
    })

Modell v3

Här är bindningsdata i filen function.json :

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

Här är JavaScript-koden:

module.exports = function (context, invocation) {
    context.log(`Receive ${context.bindingData.message} from ${invocation.ConnectionId}.`)
};

Slutför PowerShell-exempel väntar.

Här är Python-koden:

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']))

Attribut

C#-bibliotek för både process- och isolerad arbetsprocess använder attributet för att definiera SignalRTrigger funktionen. C#-skriptet använder i stället en function.json konfigurationsfil.

Isolerad arbetsmodell

I följande tabell förklaras egenskaperna för attributet SignalRTrigger .

Attributegenskap	beskrivning
HubName	Det här värdet måste anges till namnet på SignalR-hubben för att funktionen ska utlösas.
Kategori	Det här värdet måste anges som kategorin för meddelanden för att funktionen ska utlösas. Kategorin kan vara något av följande värden: anslutningar: Inklusive anslutna och frånkopplade händelser meddelanden: Inkludera alla andra händelser utom de i anslutningskategorin
Händelse	Det här värdet måste anges som händelse av meddelanden för att funktionen ska utlösas. För meddelandekategorin är händelsen målanropsmeddelandet som klienterna skickar. För anslutningskategori används endast anslutna och frånkopplade .
ParameterNames	(Valfritt) En lista med namn som binder till parametrarna.
Anslut ionStringSetting	Namnet på appinställningen som innehåller SignalR Service-anslutningssträng, som standard är AzureSignalRConnectionString.

Processmodell

I följande tabell förklaras egenskaperna för attributet SignalRTrigger .

Attributegenskap	beskrivning
HubName	Det här värdet måste anges till namnet på SignalR-hubben för att funktionen ska utlösas.
Kategori	Det här värdet måste anges som kategorin för meddelanden för att funktionen ska utlösas. Kategorin kan vara något av följande värden: anslutningar: Inklusive anslutna och frånkopplade händelser meddelanden: Inkludera alla andra händelser utom de i anslutningskategorin
Händelse	Det här värdet måste anges som händelse av meddelanden för att funktionen ska utlösas. För meddelandekategorin är händelsen målanropsmeddelandet som klienterna skickar. För anslutningskategori används endast anslutna och frånkopplade .
ParameterNames	(Valfritt) En lista med namn som binder till parametrarna.
Anslut ionStringSetting	Namnet på appinställningen som innehåller SignalR Service-anslutningssträng, som standard är AzureSignalRConnectionString.

Kommentarer

Det finns för närvarande ingen Java-anteckning som stöds för en SignalR-utlösare.

Konfiguration

I följande tabell förklaras de bindningskonfigurationsegenskaper som du anger i filen function.json .

function.json egenskap	beskrivning
typ	Måste anges till SignalRTrigger.
riktning	Måste anges till in.
Namn	Variabelnamn som används i funktionskoden för kontextobjekt för utlösare.
hubName	Det här värdet måste anges till namnet på SignalR-hubben för att funktionen ska utlösas.
Kategori	Det här värdet måste anges som kategorin för meddelanden för att funktionen ska utlösas. Kategorin kan vara något av följande värden: anslutningar: Inklusive anslutna och frånkopplade händelser meddelanden: Inkludera alla andra händelser utom de i anslutningskategorin
Händelse	Det här värdet måste anges som händelse av meddelanden för att funktionen ska utlösas. För meddelandekategorin är händelsen målanropsmeddelandet som klienterna skickar. För anslutningskategori används endast anslutna och frånkopplade .
parameterNames	(Valfritt) En lista med namn som binder till parametrarna.
connectionStringSetting	Namnet på appinställningen som innehåller SignalR Service-anslutningssträng, som standard är AzureSignalRConnectionString.

Se avsnittet Exempel för fullständiga exempel.

Användning

Nyttolaster

Indatatypen för utlösaren deklareras som antingen InvocationContext eller en anpassad typ. Om du väljer InvocationContextfår du fullständig åtkomst till begärandeinnehållet. För en anpassad typ försöker körningen parsa JSON-begärandetexten för att ange objektegenskaperna.

AnropContext

InvocationContext innehåller allt innehåll i meddelandet som skickas från en SignalR-tjänst, vilket innehåller följande egenskaper:

Property	beskrivning
Argument	Tillgänglig för meddelandekategori . Innehåller argument i anropsmeddelande
Fel	Tillgänglig för frånkopplad händelse. Den kan vara tom om anslutningen stängdes utan fel eller innehåller felmeddelandena.
Hubb	Hubbens namn som meddelandet tillhör.
Kategori	Kategorin för meddelandet.
Händelse	Händelsen för meddelandet.
ConnectionId	Anslutnings-ID för klienten som skickar meddelandet.
AnvändarID	Användaridentiteten för klienten som skickar meddelandet.
Sidhuvuden	Sidhuvudena för begäran.
Fråga	Frågan för begäran när klienter ansluter till tjänsten.
Anspråk	Klientens anspråk.

Använda ParameterNames

Med egenskapen ParameterNames i SignalRTrigger kan du binda argument för anropsmeddelanden till funktionsparametrarna. Du kan använda det namn som du definierade som en del av bindningsuttryck i andra bindningar eller som parametrar i koden. Det ger dig ett bekvämare sätt att komma åt argument för InvocationContext.

Anta att du har en JavaScript SignalR-klient som försöker anropa metoden broadcast i Azure Function med två argument message1, message2.

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

När du har angett parameterNamesmotsvarar de namn som du har definierat argumenten som skickas på klientsidan.

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

arg1 Innehåller sedan innehållet message1i och arg2 innehåller innehållet message2i .

ParameterNames Överväganden

För parameterbindningen är ordningen viktig. Om du använder ParameterNamesmatchar ordningen i ParameterNames ordningen för argumenten som du anropar i klienten. Om du använder attributet [SignalRParameter] i C# matchar argumentordningen i Azure Function-metoder argumentordningen i klienter.

ParameterNames och attributet [SignalRParameter]kan inte användas samtidigt, eller så får du ett undantag.

SignalR Service-integrering

SignalR Service behöver en URL för att få åtkomst till funktionsappen när du använder SignalR Service-utlösarbindning. URL:en ska konfigureras i Uppströms Inställningar på SignalR Service-sidan.

När du använder SignalR Service-utlösare kan URL:en vara enkel och formaterad på följande sätt:

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

Finns Function_App_URL på funktionsappens översiktssida och API_KEY genereras av Azure Function. Du kan hämta API_KEY från signalr_extension på bladet Appnycklar i Funktionsapp.

Om du vill använda mer än en funktionsapp tillsammans med en SignalR Service kan uppströms också stödja komplexa routningsregler. Mer information finns i Uppströmsinställningar.

Steg för steg-exempel

Du kan följa exemplet i GitHub för att distribuera ett chattrum i funktionsappen med SignalR Service-utlösarbindning och uppströmsfunktion: Dubbelriktad chattrumsexempel

Nästa steg

• Azure Functions-utveckling och -konfiguration med Azure SignalR Service
• SignalR Service-utlösarbindningsexempel
• SignalR Service-utlösarbindningsexempel i isolerad arbetsprocess