Azure Service Bus出力バインドを使用して、キューまたはトピック メッセージを送信します。
セットアップと構成の詳細については、概要に関する記事を参照してください。
重要
この記事では、タブを使用して、Node.js プログラミング モデルの複数のバージョンに対応しています。 v4 モデルは一般提供されており、JavaScript と TypeScript の開発者にとって、より柔軟で直感的なエクスペリエンスが得られるように設計されています。 v4 モデルの動作の詳細については、Azure Functions Node.js 開発者ガイドを参照してください。 v3 と v4 の違いの詳細については、移行ガイドを参照してください。
Azure Functionsでは、Python用の 2 つのプログラミング モデルがサポートされています。 バインドを定義する方法は、選択したプログラミング モデルによって異なります。
Python v2 プログラミング モデルを使用すると、Python関数コードでデコレーターを使用してバインドを直接定義できます。 詳細については、Python 開発者ガイドを参照してください。
この記事は、両方のプログラミング モデルをサポートしています。
例
このバインドに関しては現在、Goのサポートは利用できません。
A C# 関数は、次の C# モードのいずれかを使用して作成できます。
-
分離されたワーカー モデル: ランタイムから分離されたワーカー プロセスで実行されるコンパイル済みの C# 関数。 分離ワーカー プロセスは、.NETおよび .NET Framework の LTS および LTS 以外のバージョンで実行されている C# 関数をサポートするために必要です。 分離ワーカー プロセス関数の拡張機能では、
Microsoft.Azure.Functions.Worker.Extensions.*名前空間が使用されます。 -
インプロセス モデル: Functions ランタイムと同じプロセスで実行されるコンパイル済みの C# 関数。 このモデルの一部では、主に C# ポータルの編集のためにサポートされている C# スクリプトを使用して Functions を実行できます。 インプロセス関数の拡張機能では、
Microsoft.Azure.WebJobs.Extensions.*名前空間を使用します。
重要
インプロセス モデルのサポートは 2026 年 11 月 10 日に終了します。 完全なサポートのために、分離ワーカー モデルにアプリを移行することを強くお勧めします。
このコードにより、ILogger が定義され初期化されます。
private readonly ILogger<ServiceBusReceivedMessageFunctions> _logger;
public ServiceBusReceivedMessageFunctions(ILogger<ServiceBusReceivedMessageFunctions> logger)
{
_logger = logger;
}
この例では、メッセージを受信して 2 番目のキューに書き込む C# 関数を示します。
[Function(nameof(ServiceBusReceivedMessageFunction))]
[ServiceBusOutput("outputQueue", Connection = "ServiceBusConnection")]
public string ServiceBusReceivedMessageFunction(
[ServiceBusTrigger("queue", Connection = "ServiceBusConnection")] ServiceBusReceivedMessage message)
{
_logger.LogInformation("Message ID: {id}", message.MessageId);
_logger.LogInformation("Message Body: {body}", message.Body);
_logger.LogInformation("Message Content-Type: {contentType}", message.ContentType);
var outputMessage = $"Output message created at {DateTime.Now}";
return outputMessage;
}
この例では、HTTP トリガーと OutputType オブジェクトを使用して、HTTP 応答を送信し、出力メッセージを書き込みます。
[Function("HttpSendMsg")]
public async Task<OutputType> Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestData req, FunctionContext context)
{
_logger.LogInformation($"C# HTTP trigger function processed a request for {context.InvocationId}.");
HttpResponseData response = req.CreateResponse(HttpStatusCode.OK);
await response.WriteStringAsync("HTTP response: Message sent");
return new OutputType()
{
OutputEvent = "MyMessage",
HttpResponse = response
};
}
このコードでは、複数の出力の種類 OutputType を定義します。これには、OutputEvent のService Bus出力バインド定義が含まれます。
public class OutputType
{
[ServiceBusOutput("TopicOrQueueName", Connection = "ServiceBusConnection")]
public string OutputEvent { get; set; }
public HttpResponseData HttpResponse { get; set; }
}
次の例は、HTTP 要求によってトリガーされたときにメッセージを Service Bus キュー myqueue に送信するJava関数を示しています。
@FunctionName("httpToServiceBusQueue")
@ServiceBusQueueOutput(name = "message", queueName = "myqueue", connection = "AzureServiceBusConnection")
public String pushToQueue(
@HttpTrigger(name = "request", methods = {HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS)
final String message,
@HttpOutput(name = "response") final OutputBinding<T> result ) {
result.setValue(message + " has been sent.");
return message;
}
Java関数ランタイム ライブラリで、値がService Bus キューに書き込まれる関数パラメーターに対して、@QueueOutput 注釈を使用します。 パラメーターの型は OutputBinding<T> にする必要があります。ここで、T は、プランの古い Java オブジェクト (POJO) のネイティブ Java型です。
Java関数は、Service Bus トピックに書き込むこともできます。 次の例では、出力バインディングの構成を記述する@ServiceBusTopicOutput注釈を使用します。
@FunctionName("sbtopicsend")
public HttpResponseMessage run(
@HttpTrigger(name = "req", methods = {HttpMethod.GET, HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS) HttpRequestMessage<Optional<String>> request,
@ServiceBusTopicOutput(name = "message", topicName = "mytopicname", subscriptionName = "mysubscription", connection = "ServiceBusConnection") OutputBinding<String> message,
final ExecutionContext context) {
String name = request.getBody().orElse("Azure Functions");
message.setValue(name);
return request.createResponseBuilder(HttpStatus.OK).body("Hello, " + name).build();
}
次の例は、タイマーでトリガーされた、5 分ごとにキュー メッセージを送信する TypeScript 関数を示しています。
import { app, InvocationContext, output, Timer } from '@azure/functions';
export async function timerTrigger1(myTimer: Timer, context: InvocationContext): Promise<string> {
const timeStamp = new Date().toISOString();
return `Message created at: ${timeStamp}`;
}
app.timer('timerTrigger1', {
schedule: '0 */5 * * * *',
return: output.serviceBusQueue({
queueName: 'testqueue',
connection: 'MyServiceBusConnection',
}),
handler: timerTrigger1,
});
複数のメッセージを出力するには、1 つのオブジェクトではなく配列を返します。 次に例を示します。
const timeStamp = new Date().toISOString();
const message = `Message created at: ${timeStamp}`;
return [`1: ${message}`, `2: ${message}`];
次の例は、タイマーでトリガーされた、5 分ごとにキュー メッセージを送信する JavaScript 関数を示しています。
const { app, output } = require('@azure/functions');
const serviceBusOutput = output.serviceBusQueue({
queueName: 'testqueue',
connection: 'MyServiceBusConnection',
});
app.timer('timerTrigger1', {
schedule: '0 */5 * * * *',
return: serviceBusOutput,
handler: (myTimer, context) => {
const timeStamp = new Date().toISOString();
return `Message created at: ${timeStamp}`;
},
});
複数のメッセージを出力するには、1 つのオブジェクトではなく配列を返します。 次に例を示します。
const timeStamp = new Date().toISOString();
const message = `Message created at: ${timeStamp}`;
return [`1: ${message}`, `2: ${message}`];
次の例は、function.json ファイル内のService Bus出力バインドと、バインドを使用する PowerShell 関数を示しています。
function.json ファイルのバインディング データを次に示します。
{
"bindings": [
{
"type": "serviceBus",
"direction": "out",
"connection": "AzureServiceBusConnectionString",
"name": "outputSbMsg",
"queueName": "outqueue",
"topicName": "outtopic"
}
]
}
関数の出力としてメッセージを作成する PowerShell を次に示します。
param($QueueItem, $TriggerMetadata)
Push-OutputBinding -Name outputSbMsg -Value @{
name = $QueueItem.name
employeeId = $QueueItem.employeeId
address = $QueueItem.address
}
次の例では、Service Busトピックに書き込み、Python内のキューをService Busする方法を示します。 この例は、v1 または v2 のどちらのプログラミング モデルPythonを使用するかによって異なります。
この例では、Service Bus トピックに書き出す方法を示します。
import logging
import azure.functions as func
app = func.FunctionApp()
@app.route(route="put_message")
@app.service_bus_topic_output(arg_name="message",
connection="AzureServiceBusConnectionString",
topic_name="outTopic")
def main(req: func.HttpRequest, message: func.Out[str]) -> func.HttpResponse:
input_msg = req.params.get('message')
message.set(input_msg)
return 'OK'
この例では、Service Bus キューに書き出す方法を示します。
import azure.functions as func
app = func.FunctionApp()
@app.route(route="put_message")
@app.service_bus_queue_output(
arg_name="msg",
connection="AzureServiceBusConnectionString",
queue_name="outqueue")
def put_message(req: func.HttpRequest, msg: func.Out[str]):
msg.set(req.get_body().decode('utf-8'))
return 'OK'
属性
インプロセスと分離ワーカー プロセスのどちらの C# ライブラリも、属性を使用して出力バインドを定義します。 C# スクリプトでは、C# スクリプト ガイドで説明されているように、代わりに function.json 構成ファイルを使用します。
C# クラス ライブラリでは、ServiceBusOutputAttribute を使用して、出力によって書き込まれるキューまたはトピックを定義します。
次の表では、この属性を使用して設定できるプロパティについて説明します。
| プロパティ | 説明 |
|---|---|
| EntityType | エンティティ型には、キューにメッセージを送信する場合は Queue、トピックにメッセージを送信する場合は Topic のいずれかを設定します。 |
| QueueOrTopicName | メッセージの送信先となるトピックまたはキューの名前。
EntityType を使って送信先の型を指定します。 |
| 接続 | Service Busに接続する方法を指定するアプリ設定または設定コレクションの名前。 「接続」を参照してください。 |
デコレーター
Python v2 プログラミング モデルにのみ適用されます。
デコレーターを使用して定義Python v2 関数の場合、service_bus_topic_outputの次のプロパティ。
| プロパティ | 説明 |
|---|---|
arg_name |
関数コード内のキューまたはトピック メッセージを表す変数の名前。 |
queue_name |
キューの名前。 トピックではなくキューのメッセージを送信する場合にのみ設定します。 |
topic_name |
トピックの名前。 キューではなくトピックのメッセージを送信する場合にのみ設定します。 |
connection |
Service Busに接続する方法を指定するアプリ設定または設定コレクションの名前。 「接続」を参照してください。 |
function.json を使用して定義Python関数については、「Configuration」セクションを参照してください。
注釈
ServiceBusQueueOutput と ServiceBusTopicOutput 注釈を使用して、関数の出力としてメッセージを書き込むことができます。 これらの注釈で修飾されたパラメーターは OutputBinding<T> として宣言されている必要があります。ここで、T はメッセージの型に対応する型です。
構成
Python v1 プログラミング モデルにのみ適用されます。
次の表では、options メソッドに渡される output.serviceBusQueue() オブジェクトに対して設定できるプロパティについて説明します。
| プロパティ | 説明 |
|---|---|
| queueName | キューの名前。 |
| 接続 | Service Busに接続する方法を指定するアプリ設定または設定コレクションの名前。 「接続」を参照してください。 |
次の表では、options メソッドに渡される output.serviceBusTopic() オブジェクトに対して設定できるプロパティについて説明します。
| プロパティ | 説明 |
|---|---|
| topicName | トピックの名前。 |
| 接続 | Service Busに接続する方法を指定するアプリ設定または設定コレクションの名前。 「接続」を参照してください。 |
次の表は、function.json ファイルと ServiceBus 属性で設定したバインド構成のプロパティを説明しています。
| function.json のプロパティ | 説明 |
|---|---|
| タイプ |
serviceBus に設定する必要があります。 このプロパティは、Azure ポータルでトリガーを作成するときに自動的に設定されます。 |
| 方向 |
out に設定する必要があります。 このプロパティは、Azure ポータルでトリガーを作成するときに自動的に設定されます。 |
| 名前 | 関数コード内のキューまたはトピック メッセージを表す変数の名前。 "$return" に設定して、関数の戻り値を参照します。 |
| queueName | キューの名前。 トピックではなくキューのメッセージを送信する場合にのみ設定します。 |
| topicName | トピックの名前。 キューではなくトピックのメッセージを送信する場合にのみ設定します。 |
| 接続 | Service Busに接続する方法を指定するアプリ設定または設定コレクションの名前。 「接続」を参照してください。 |
| accessRights (v1 のみ) | 接続文字列のアクセス権。 使用できる値は manage と listen です。 既定値は manage で、connection がmanageアクセス許可を持つことを示します。
Manage アクセス許可を持たない接続文字列を使用する場合は、accessRights を "listen" に設定します。 設定しないと、Functions ランタイムが管理権限を必要とする操作の試行に失敗する可能性があります。 Azure Functions バージョン 2.x 以降では、Service Bus SDK の最新バージョンでは管理操作がサポートされていないため、このプロパティは使用できません。 |
完全な例については、セクションの例を参照してください。
使用方法
すべての C# モダリティと拡張バージョンでは、次の出力パラメーター型がサポートされています。
| タイプ | 説明 |
|---|---|
| System.String | 書き込むメッセージが単純なテキストである場合に使います。 関数が終了したときにパラメーター値が null の場合、Functions はメッセージを作成しません。 |
| byte[] | バイナリ データのメッセージを書き込む場合に使います。 関数が終了したときにパラメーター値が null の場合、Functions はメッセージを作成しません。 |
| オブジェクト | メッセージに JSON が含まれている場合、Functions はオブジェクトを JSON メッセージ ペイロードにシリアル化します。 関数が終了したときにこのパラメーターの値が null の場合、Functions は、null オブジェクトでメッセージを作成します。 |
メッセージング固有のパラメーター型には追加のメッセージ メタデータが含まれており、JSON シリアル化と互換性がありません。 その結果、分離モデルの出力バインドで ServiceBusMessage を使用することはできません。 出力バインドによってサポートされる特定の型は、Functions ランタイムのバージョン、拡張機能パッケージのバージョン、使用する C# のモダリティによって異なります。
関数で 1 つのメッセージを書き込む場合、Service Bus出力バインドは次の型にバインドできます。
| タイプ | 説明 |
|---|---|
string |
文字列としてのメッセージ。 メッセージが単純なテキストである場合に使用します。 |
byte[] |
メッセージのバイト数。 |
| JSON シリアル化可能な型 | メッセージを表すオブジェクト。 Functions は、単純な従来の CLR オブジェクト (POCO) 型を JSON データにシリアル化しようとします。 |
関数で複数のメッセージを書き込む場合、Service Bus出力バインドは次の型にバインドできます。
| タイプ | 説明 |
|---|---|
T[] (T は単一メッセージ型の 1 つ) |
複数のメッセージを含む配列。 各エントリは 1 つのメッセージを表します。 |
その他の出力シナリオでは、ServiceBusClient を作成し、Azure の他の型と共に使用します。Messaging.ServiceBus 直接。 依存関係の挿入を使用してAzure SDKからクライアントの種類を作成する例については、「クライアントをAzure登録する」を参照してください。
Azure Functions 1.x では、ランタイムはキューが存在せず、accessRights を manage に設定している場合にキューを作成します。 バージョン 2.x 以降Azure Functions、キューまたはトピックが既に存在している必要があります。存在しないキューまたはトピックを指定すると、関数は失敗します。
組み込みの出力バインドではなく、Azure Service Bus SDK を使用します。
Service Busへの出力は、Push-OutputBinding コマンドレットを使用して使用できます。ここで、バインドの name パラメーターで指定された名前に一致する引数を function.json ファイルに渡します。
出力関数パラメーターは、 func.Out[str] または func.Out[bytes]として定義する必要があります。 詳細については、 出力例 を参照してください。
または、組み込みの出力バインドではなく、Azure Service Bus SDK を使用することもできます。
完全な例については、例のセクションを参照してください。
接続
connectionプロパティは、アプリケーション設定内のキーを参照し、Functionsランタイムが拡張で使用されるService Busインスタンスに接続するために使う値を返します。 接続プロパティ設定の値は接続の種類によって異なります:
-
マネージド・アイデンティティ接続:
connectionプロパティは、複数の設定が共有する<CONNECTION_NAME_PREFIX>であり、これらが共にアイデンティティベースの接続をService Busに定義します。 詳細については、「 同一性接続の定義」を参照してください。 -
Key Vault参照:
connectionプロパティ設定は、接続文字列が中央管理されている場所への参照Azure Key Vaultを返します。 詳細については、「Key Vault connectionsの定義」をご覧ください。 -
App Configuration reference:
connectionプロパティ設定は接続文字列またはKey Vault参照を返すAzure App Configuration参照を返します。 詳細については、接続記事のAzure App Configurationをご覧ください。 -
Connection string:
connectionプロパティ設定はService Busインスタンスの実際の接続文字列を返します。 接続文字列には共有の秘密鍵が含まれているため、可能であれば管理型アイデンティティ接続の使用を検討すべきです。 詳細については、「 接続の定義」を参照してください。
バインディング接続について詳しく知りたい方は、Azure Functionsの「Manage connection in Connection」をご覧ください。
接続文字列は、管理資格情報の取得に関する記事の手順に従って取得します。 接続文字列は、特定のキューまたはトピックに限らず、Service Bus 名前空間のものである必要があります。
アプリ設定名が AzureWebJobsで始まる場合は、名前の残りだけを指定します。 たとえば、 connection を MyServiceBus に設定すると、Functions ランタイムは AzureWebJobsMyServiceBus という名前のアプリ設定を検索します。
connection空のままにすると、Functionsランタイムはアプリの設定にあるデフォルトのService Bus 接続文字列であるAzureWebJobsServiceBusを使用します。
権限のスケーリング
Service Bus拡張はService Bus管理API(GetQueueRuntimePropertiesAsync / GetSubscriptionRuntimePropertiesAsync)を利用して、スケール決定のための正確なメッセージカウントを取得します。 このAPIは、メッセージの送受信に必要な権限以上の追加権限を必要とします:
- SAS接続文字列:SASポリシーには 「アクセス管理 権限」を含める必要があります。
-
アイデンティティベースの接続:アイデンティティはAzure Service Busデータオーナーロール、または
Microsoft.ServiceBus/namespaces/*/readを含むカスタムロールを割り当てる必要があります。
接続にこれらの権限がない場合は、起動時にエラーは発生しません。 代わりに、拡張は静かにピークベースのメッセージ推定に戻ってしまいますが、これは精度が低く、スケーリングの判断が遅れたり誤ったりする恐れがあります。
ヒント
自動スケーリングに依存する本番ワークロードでは、アクセス権管理権限(SAS)を含めるか、Azure Service Bus Data Owner ロール(アイデンティティベースの接続)を割り当てて正確なスケール動作を確保しましょう。 接続文字列AzureWebJobsServiceBusという名前のアプリ設定で。
例外とリターン コード
| バインド | リファレンス |
|---|---|
| Service Bus | Service Bus エラー コード |
| Service Bus | Service Bus制限 |