Azure Functions における SignalR Service のトリガー バインド
SignalR トリガー バインドを使用して、Azure SignalR Service から送信されたメッセージに応答します。 関数がトリガーされると、関数に渡されるメッセージは JSON オブジェクトとして解析されます。
SignalR Service サーバーレス モードでは、SignalR Service はアップストリーム機能を使用して、クライアントから関数アプリにメッセージを送信します。 また関数アプリでは、SignalR Service トリガー バインドを使用してこれらのメッセージを処理します。 一般的なアーキテクチャを次に示します。
セットアップと構成の詳細については、概要に関するページをご覧ください。
例
A C# 関数は、次の C# モードのいずれかを使用して作成できます。
- 分離されたワーカー モデル: ランタイムから分離されたワーカー プロセスで実行されるコンパイル済みの C# 関数。 分離ワーカー プロセスは、LTS および 非 LTS バージョンの .NET および .NET Framework で実行されている C# 関数をサポートするために必要です。
- インプロセス モデル: Functions ランタイムと同じプロセスで実行されるコンパイル済みの C# 関数。
- C# スクリプト: Azure portal で C# 関数を作成するときに主に使用されます。
重要
インプロセス モデルのサポートは 2026 年 11 月 10 日に終了します。 完全なサポートのために、分離ワーカー モデルにアプリを移行することを強くお勧めします。
次のサンプルは、クライアントからメッセージ イベントを受信し、メッセージの内容をログに記録する C# 関数を示しています。
[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);
}
重要
C# 分離ワーカーの SignalR Service バインドのクラス ベースモデルでは、C# ワーカー モデルの制限により SignalR トリガーの記述方法が最適化されません。 クラス ベースのモデルの詳細については、「 Class ベースのモデル」を参照してください。
SignalR トリガーは現在、Java ではサポートされていません。
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}.`)
}
})
PowerShell の完全な例は保留中です。
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']))
属性
インプロセスと分離ワーカー プロセスの C# ライブラリはどちらも、SignalRTrigger
属性を使用して関数を定義します。 C# スクリプトでは、代わりに function.json 構成ファイルを使います。
次の表では、SignalRTrigger
属性のプロパティについて説明します。
属性のプロパティ | 説明 |
---|---|
HubName | この値は、トリガーされる関数の SignalR ハブの名前に設定する必要があります。 |
カテゴリ | この値は、トリガーされる関数のメッセージのCategoryとして設定する必要があります。 カテゴリには、次のいずれかの値を指定できます。
|
Event | この値は、トリガーされる関数のメッセージのイベントとして設定する必要があります。 messages カテゴリの場合、イベントは「呼び出しメッセージ」でクライアントが送信する target です。 connections カテゴリの場合、connected および disconnected のみが使用されます。 |
ParameterNames | (省略可能) パラメーターにバインドする名前のリスト。 |
ConnectionStringSetting | SignalR Service 接続文字列が含まれているアプリ設定の名前。この既定値は AzureSignalRConnectionString です。 |
注釈
現在、SignalR トリガーでサポートされている Java 注釈はありません。
構成
次の表は、function.json ファイルで設定したバインド構成のプロパティを説明しています。
function.json のプロパティ | 説明 |
---|---|
type | SignalRTrigger に設定する必要があります。 |
direction | in に設定する必要があります。 |
name | トリガー呼び出しコンテキスト オブジェクトの関数コードで使用される変数名。 |
hubName | この値は、トリガーされる関数の SignalR ハブの名前に設定する必要があります。 |
category | この値は、トリガーされる関数のメッセージのCategoryとして設定する必要があります。 カテゴリには、次のいずれかの値を指定できます。
|
event | この値は、トリガーされる関数のメッセージのイベントとして設定する必要があります。 messages カテゴリの場合、イベントは「呼び出しメッセージ」でクライアントが送信する target です。 connections カテゴリの場合、connected および disconnected のみが使用されます。 |
parameterNames | (省略可能) パラメーターにバインドする名前のリスト。 |
connectionStringSetting | SignalR Service 接続文字列が含まれているアプリ設定の名前。この既定値は AzureSignalRConnectionString です。 |
完全な例については、セクションの例を参照してください。
使用方法
Payloads
トリガーの入力型は、InvocationContext
またはカスタム型のいずれかとして宣言されています。 InvocationContext
を選択すると、要求コンテンツへのフル アクセスが得られます。 カスタム型 の場合、ランタイムは JSON 要求本文を解析して、オブジェクトのプロパティを設定しようとします。
InvocationContext
InvocationContext
には、SignalR サービスから送信されるメッセージ内のすべてのコンテンツが含まれており、次のプロパティが含まれます:
プロパティ | 説明 |
---|---|
引数 | messages カテゴリで使用可能。 「呼び出しメッセージ」の arguments が格納されています |
エラー | disconnected イベントで使用可能。 接続がエラーなしで閉じられた場合、またはエラー メッセージが含まれている場合は、空になる場合があります。 |
ハブ | メッセージが属するハブ名。 |
カテゴリ | メッセージのカテゴリ。 |
Event | メッセージのイベント。 |
ConnectionId | メッセージを送信するクライアントの接続 ID。 |
UserId | メッセージを送信するクライアントのユーザー ID。 |
ヘッダー | 要求のヘッダー。 |
クエリ | クライアントがサービスに接続するときの要求のクエリ。 |
Claims | クライアントのクレーム。 |
ParameterNames
の使用
SignalRTrigger
のプロパティ ParameterNames
を使用すると、呼び出しメッセージの引数を関数のパラメーターにバインドできます。 定義した名前は、他のバインドのバインド式の一部として、またはコードのパラメーターとして使用できます。 これにより、InvocationContext
の引数へのアクセスがより便利になります。
たとえば、JavaScript SignalR クライアントが 2 つの引数 (message1
、message2
) を使用して Azure 関数でメソッド broadcast
を呼び出そうとしているとします。
await connection.invoke("broadcast", message1, message2);
parameterNames
を設定すると、定義した名前が、クライアント側で送信される引数に対応します。
[SignalRTrigger(parameterNames: new string[] {"arg1, arg2"})]
次に、 arg1
には message1
のコンテンツが含まれており、 arg2
には message2
のコンテンツが含まれます。
ParameterNames
の考慮事項
パラメーター バインドの場合、順序は重要です。 ParameterNames
を使用している場合、ParameterNames
の順序は、クライアントで呼び出した引数の順序と一致します。 C# で属性 [SignalRParameter]
を使用している場合、Azure 関数メソッドの引数の順序は、クライアントの引数の順序と一致します。
ParameterNames
と属性 [SignalRParameter]
同時に使用することはできません 、または例外が発生します。
SignalR Service の統合
SignalR Service トリガー バインドを使用している場合、SignalR サービスには関数アプリにアクセスするための URL が必要です。 URL は、SignalR Service 側のアップストリームの設定で構成する必要があります。
SignalR Service トリガーを使用する場合、URL は単純で、次のように書式設定できます。
<Function_App_URL>/runtime/webhooks/signalr?code=<API_KEY>
Function_App_URL
は Function App の [概要] ページにあり、API_KEY
は Azure Function によって生成されます。 関数アプリの API_KEY
ブレードで signalr_extension
から API_KEY
を取得できます。
1 つの SignalR サービスで複数の関数アプリを一緒に使用する場合は、アップストリームで複雑なルーティング規則をサポートすることもできます。 詳細については「アップストリームの設定」をご覧ください。
ステップ バイ ステップ サンプル
GitHub のサンプルに従って、SignalR Service トリガー バインドとアップストリーム機能を使用して関数アプリに関するチャット ルームをデプロイできます。双方向チャット ルームのサンプル