Service Bus トリガーを使用して、Service Busキューまたはトピックからのメッセージに応答します。 拡張機能バージョン 3.1.0 以降では、セッションが有効なキューまたはトピックでトリガーを実行できます。
セットアップと構成の詳細については、概要に関するページをご覧ください。
従量課金プランと Premium プランのService Busスケーリングの決定は、ターゲット ベースのスケーリングに基づいて行われます。 詳しくは、「ターゲット ベースのスケーリング」をご覧ください。
重要
この記事では、タブを使用して、Node.js プログラミング モデルの複数のバージョンに対応しています。 v4 モデルは一般提供されており、JavaScript と TypeScript の開発者にとって、より柔軟で直感的なエクスペリエンスが得られるように設計されています。 v4 モデルの動作の詳細については、Azure Functions Node.js 開発者ガイドを参照してください。 v3 と v4 の違いの詳細については、移行ガイドを参照してください。
Azure Functionsでは、Python用の 2 つのプログラミング モデルがサポートされています。 バインドを定義する方法は、選択したプログラミング モデルによって異なります。
Python v2 プログラミング モデルを使用すると、Python関数コードでデコレーターを使用してバインドを直接定義できます。 詳細については、Python 開発者ガイドを参照してください。
この記事は、両方のプログラミング モデルをサポートしています。
例
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;
}
この例では、C# 関数を示します。この関数は、単一のService Bus キュー メッセージを受信してログに書き込みます。
[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;
}
この例では、C# 関数 1 つのバッチで複数のService Bus キュー メッセージを受信し、それぞれをログに書き込む方法を示します。
[Function(nameof(ServiceBusReceivedMessageBatchFunction))]
public void ServiceBusReceivedMessageBatchFunction(
[ServiceBusTrigger("queue", Connection = "ServiceBusConnection", IsBatched = true)] ServiceBusReceivedMessage[] messages)
{
foreach (ServiceBusReceivedMessage message in messages)
{
_logger.LogInformation("Message ID: {id}", message.MessageId);
_logger.LogInformation("Message Body: {body}", message.Body);
_logger.LogInformation("Message Content-Type: {contentType}", message.ContentType);
}
}
この例ではC# 関数複数のService Bus キュー メッセージを受信し、ログに書き込み、完了したメッセージを解決します。
[Function(nameof(ServiceBusMessageActionsFunction))]
public async Task ServiceBusMessageActionsFunction(
[ServiceBusTrigger("queue", Connection = "ServiceBusConnection", AutoCompleteMessages = false)]
ServiceBusReceivedMessage message,
ServiceBusMessageActions messageActions)
{
_logger.LogInformation("Message ID: {id}", message.MessageId);
_logger.LogInformation("Message Body: {body}", message.Body);
_logger.LogInformation("Message Content-Type: {contentType}", message.ContentType);
// Complete the message
await messageActions.CompleteMessageAsync(message);
}
次のJava関数は、Java 関数ランタイム ライブラリの @ServiceBusQueueTrigger 注釈 を使用して、Service Bus キュー トリガーの構成を記述します。 この関数は、キューにあるメッセージを取得し、ログに追加します。
@FunctionName("sbprocessor")
public void serviceBusProcess(
@ServiceBusQueueTrigger(name = "msg",
queueName = "myqueuename",
connection = "myconnvarname") String message,
final ExecutionContext context
) {
context.getLogger().info(message);
}
Java関数は、メッセージが Service Bus トピックに追加されたときにトリガーすることもできます。 次の例では、トリガー構成を記述する @ServiceBusTopicTrigger 注釈を使用します。
@FunctionName("sbtopicprocessor")
public void run(
@ServiceBusTopicTrigger(
name = "message",
topicName = "mytopicname",
subscriptionName = "mysubscription",
connection = "ServiceBusConnection"
) String message,
final ExecutionContext context
) {
context.getLogger().info(message);
}
この例では、Service Bus トリガーによって提供される sdk 型 ServiceBusReceivedMessageServiceBusMessageContext を使用します。
import '@azure/functions-extensions-servicebus'; // Ensure the Service Bus extension is imported
import { app, type InvocationContext } from '@azure/functions';
import { type ServiceBusMessageContext, messageBodyAsJson } from '@azure/functions-extensions-servicebus';
// This sample uses sdkBinding = true with manual message completion.
// With v0.4.0, message.body is returned as a raw Buffer instead of auto-parsed object.
export async function serviceBusQueueTrigger(
serviceBusMessageContext: ServiceBusMessageContext,
context: InvocationContext
): Promise<void> {
const message = serviceBusMessageContext.messages[0];
// v0.4.0: message.body is a Buffer — use messageBodyAsJson<T>() from the extension for one-line parsing
const bodyData = messageBodyAsJson(message);
context.log('Parsed message body:', bodyData);
// Get current retry count from custom properties, default to 0
const currentRetryCount = message.applicationProperties?.retryCnt
? parseInt(message.applicationProperties.retryCnt as string)
: 0;
context.log(`Current retry count: ${currentRetryCount}`);
if (currentRetryCount >= 3) {
// After 3 retries, complete the message to remove it from the queue
context.log(`Maximum retry count (3) reached. Completing message to prevent infinite loop.`);
await serviceBusMessageContext.actions.complete(message);
context.log('Message completed after maximum retries');
} else {
// Abandon with updated retry count
const newRetryCount = currentRetryCount + 1;
const propertiesToModify = {
retryCnt: newRetryCount.toString(),
lastRetryTime: new Date().toISOString(),
errorMessage: 'Processing failed',
};
context.log(`Abandoning message with retry count: ${newRetryCount}`);
await serviceBusMessageContext.actions.abandon(message, propertiesToModify);
}
context.log('triggerMetadata: ', context.triggerMetadata);
}
app.serviceBusQueue('serviceBusQueueTrigger1', {
connection: 'ServiceBusConnection',
queueName: 'testqueue',
sdkBinding: true,
SDK の種類を使用する別の例については、exponential バックオフ戦略のサンプルを参照してください。
詳細については、Node.js リファレンス記事の SDK の種類 を参照してください。
次の例は、Service Bus トリガー TypeScript 関数を示しています。 この関数は、message メタデータを読み取り、Service Bus キュー メッセージをログに記録します。
import { app, InvocationContext } from '@azure/functions';
export async function serviceBusQueueTrigger1(message: unknown, context: InvocationContext): Promise<void> {
context.log('Service bus queue function processed message:', message);
context.log('EnqueuedTimeUtc =', context.triggerMetadata.enqueuedTimeUtc);
context.log('DeliveryCount =', context.triggerMetadata.deliveryCount);
context.log('MessageId =', context.triggerMetadata.messageId);
}
app.serviceBusQueue('serviceBusQueueTrigger1', {
connection: 'MyServiceBusConnection',
queueName: 'testqueue',
handler: serviceBusQueueTrigger1,
});
次の例は、Service Bus トリガー JavaScript 関数を示しています。 この関数は、message メタデータを読み取り、Service Bus キュー メッセージをログに記録します。
const { app } = require('@azure/functions');
app.serviceBusQueue('serviceBusQueueTrigger1', {
connection: 'MyServiceBusConnection',
queueName: 'testqueue',
handler: (message, context) => {
context.log('Service bus queue function processed message:', message);
context.log('EnqueuedTimeUtc =', context.triggerMetadata.enqueuedTimeUtc);
context.log('DeliveryCount =', context.triggerMetadata.deliveryCount);
context.log('MessageId =', context.triggerMetadata.messageId);
},
});
次の例は、function.json ファイル内のService Bus トリガー バインドと、バインドを使用する PowerShell 関数を示しています。
function.json ファイルのバインディング データを次に示します。
{
"bindings": [
{
"name": "mySbMsg",
"type": "serviceBusTrigger",
"direction": "in",
"topicName": "mytopic",
"subscriptionName": "mysubscription",
"connection": "AzureServiceBusConnectionString"
}
]
}
Service Bus メッセージが送信されたときに実行される関数を次に示します。
param([string] $mySbMsg, $TriggerMetadata)
Write-Host "PowerShell ServiceBus queue trigger function processed message: $mySbMsg"
この例では、SDK 型を使用して、Service Bus トリガーによって提供される基になる ServiceBusReceivedMessage オブジェクトに直接アクセスします。
import logging
import azure.functions as func
import azurefunctions.extensions.bindings.servicebus as servicebus
app = func.FunctionApp(http_auth_level=func.AuthLevel.FUNCTION)
@app.service_bus_queue_trigger(arg_name="receivedmessage",
queue_name="QUEUE_NAME",
connection="SERVICEBUS_CONNECTION")
def servicebus_queue_trigger(receivedmessage: servicebus.ServiceBusReceivedMessage):
logging.info("Python ServiceBus queue trigger processed message.")
logging.info("Receiving: %s\n"
"Body: %s\n"
"Enqueued time: %s\n"
"Lock Token: %s\n"
"Message ID: %s\n"
"Sequence number: %s\n",
receivedmessage,
receivedmessage.body,
receivedmessage.enqueued_time_utc,
receivedmessage.lock_token,
receivedmessage.message_id,
receivedmessage.sequence_number)
この関数は、 ServiceBusReceivedMessage 型のさまざまなプロパティを読み取り、ログに記録します。
Service Bus SDK の種類の使用例については、ServiceBusReceivedMessage サンプルを参照してください。 関数アプリに SDK 型のバインドを含める方法の詳細なチュートリアルについては、Service Bus Sample の
注意
既知の制限事項は次のとおりです。
-
messageプロパティはサポートされていません。 - バッチ メッセージのサポートには、バージョン 4.1039 以降の Functions ランタイムが必要です。
他の SDK 型バインドがサポートされているものも含め、詳細については、 SDK の型バインドに関するページを参照してください。
この例では、トリガーを介してService Busキュー メッセージを読み取る方法を示します。 この例は、v1 または v2 のどちらのプログラミング モデルPythonを使用するかによって異なります。
import logging
import azure.functions as func
app = func.FunctionApp()
@app.function_name(name="ServiceBusQueueTrigger1")
@app.service_bus_queue_trigger(arg_name="msg",
queue_name="<QUEUE_NAME>",
connection="<CONNECTION_SETTING>")
def test_function(msg: func.ServiceBusMessage):
logging.info('Python ServiceBus queue trigger processed message: %s',
msg.get_body().decode('utf-8'))
次の例では、トリガーを使用して Service Bus キュー トピックを読み取る方法を示します。
import logging
import azure.functions as func
app = func.FunctionApp()
@app.function_name(name="ServiceBusTopicTrigger1")
@app.service_bus_topic_trigger(arg_name="message",
topic_name="TOPIC_NAME",
connection="CONNECTION_SETTING",
subscription_name="SUBSCRIPTION_NAME")
def test_function(message: func.ServiceBusMessage):
message_body = message.get_body().decode("utf-8")
logging.info("Python ServiceBus topic trigger processed message.")
logging.info("Message Body: " + message_body)
以下の例は、Azure Service Busのキュートリガー関数で受信メッセージをログにするものです:
package main
import (
"context"
"log"
"github.com/azure/azure-functions-golang-worker/sdk"
"github.com/azure/azure-functions-golang-worker/sdk/bindings"
"github.com/azure/azure-functions-golang-worker/worker"
)
func main() {
app := sdk.FunctionApp()
app.ServiceBusQueue("serviceBusQueueTrigger", processMessage,
sdk.WithQueueName("myqueue"),
sdk.WithConnection("ServiceBusConnection"),
)
worker.Start(app)
}
func processMessage(ctx context.Context, msg bindings.ServiceBusMessage) error {
log.Printf("Service Bus queue trigger processed message: %s", msg.Body)
log.Printf("Message ID: %s", msg.MessageId)
return nil
}
属性
in-process と isolated worker process C# ライブラリはどちらも、ServiceBusTriggerAttribute 属性を使用して関数トリガーを定義します。 C# スクリプトでは、C# スクリプト ガイドで説明されているように、代わりに function.json 構成ファイルを使用します。
次の表では、このトリガー属性を使用して設定できるプロパティについて説明します。
| プロパティ | 説明 |
|---|---|
| キュー名 | 監視するキューの名前。 トピックではなくキューを監視する場合にのみ設定します。 |
| TopicName | 監視するトピックの名前。 キューではなくトピックを監視する場合にのみ設定します。 |
| SubscriptionName | 監視するサブスクリプションの名前。 キューではなくトピックを監視する場合にのみ設定します。 |
| 接続 | Service Busに接続する方法を指定するアプリ設定または設定コレクションの名前。 「接続」を参照してください。 |
| IsBatched | メッセージはバッチで配信されます。 配列またはコレクション型が必要です。 |
| IsSessionsEnabled |
trueキューまたはサブスクリプションに接続する場合は true。 それ以外の場合は false (既定値)。 |
| AutoCompleteMessages |
true トリガーが正常に呼び出された後にメッセージを自動的に完了する必要がある場合は 。
false コードでメッセージの受け渡しを する場合など。 明示的に設定しない場合、動作はautoCompleteMessagesのhost.json構成に基づいています。 |
デコレーター
Python v2 プログラミング モデルにのみ適用されます。
デコレーターを使用して定義Python v2 関数の場合、service_bus_queue_triggerの次のプロパティ。
| プロパティ | 説明 |
|---|---|
arg_name |
関数コード内のキューまたはトピック メッセージを表す変数の名前。 |
queue_name |
監視するキューの名前。 トピックではなくキューを監視する場合にのみ設定します。 |
connection |
Service Busに接続する方法を指定するアプリ設定または設定コレクションの名前。 「接続」を参照してください。 |
function.json を使用して定義Python関数については、「Configuration」セクションを参照してください。
注釈
ServiceBusQueueTrigger注釈を使用すると、Service Bus キュー メッセージの作成時に実行される関数を作成できます。 使用可能な構成オプションには、次のプロパティがあります。
| プロパティ | 説明 |
|---|---|
| 名前 | 関数コード内のキューまたはトピック メッセージを表す変数の名前。 |
| queueName | 監視するキューの名前。 トピックではなくキューを監視する場合にのみ設定します。 |
| topicName | 監視するトピックの名前。 キューではなくトピックを監視する場合にのみ設定します。 |
| の subscriptionName | 監視するサブスクリプションの名前。 キューではなくトピックを監視する場合にのみ設定します。 |
| 接続 | Service Busに接続する方法を指定するアプリ設定または設定コレクションの名前。 「接続」を参照してください。 |
ServiceBusTopicTrigger 注釈を使用すると、関数をトリガーするデータを対象とするトピックとサブスクリプションを指定できます。
ローカルで開発する場合は、 コレクション内の Valuesにアプリケーション設定を追加します。
詳細については、トリガーの例を参照してください。
構成
Python v1 プログラミング モデルにのみ適用されます。
次の表では、options または app.serviceBusQueue() メソッドに渡される app.serviceBusTopic() オブジェクトに対して設定できるプロパティについて説明します。
| プロパティ | 説明 |
|---|---|
| queueName | 監視するキューの名前。 トピックではなくキューを監視する場合にのみ設定します。 |
| topicName | 監視するトピックの名前。 キューではなくトピックを監視する場合にのみ設定します。 |
| の subscriptionName | 監視するサブスクリプションの名前。 キューではなくトピックを監視する場合にのみ設定します。 |
| 接続 | Service Busに接続する方法を指定するアプリ設定または設定コレクションの名前。 「接続」を参照してください。 |
| accessRights | 接続文字列のアクセス権。 使用できる値は manage と listen です。 既定値は manage で、connection がmanageアクセス許可を持つことを示します。
Manage 権限を持たない接続文字列を使用する場合は、accessRights を "listen" に設定します。 設定しないと、Functions ランタイムが管理権限を必要とする操作の試行に失敗する可能性があります。 Azure Functions バージョン 2.x 以降では、Service Bus SDK の最新バージョンでは管理操作がサポートされていないため、このプロパティは使用できません。 |
| isSessionsEnabled |
trueキューまたはサブスクリプションに接続する場合は true。 それ以外の場合は false (既定値)。 |
| autoComplete | C# 以外の関数の場合は true である必要があります。これは、トリガーが処理後に complete を自動的に呼び出すか、関数コードが手動で complete を呼び出す必要があることを意味します。true に設定した場合、関数の実行が正常に完了すると、トリガーによって自動的にメッセージが完了され、それ以外の場合はメッセージが破棄されます。関数の例外により、ランタイム呼び出しがバックグラウンドで abandonAsync されます。 例外が発生しなかった場合は、バックグラウンドで completeAsync が呼び出されます。 このプロパティは、Azure Functions 2.x 以降でのみ使用できます。 |
次の表は、function.json ファイルで設定したバインド構成のプロパティを説明しています。
| function.json のプロパティ | 説明 |
|---|---|
| タイプ |
serviceBusTrigger に設定する必要があります。 このプロパティは、Azure ポータルでトリガーを作成するときに自動的に設定されます。 |
| 方向 | "in" に設定する必要があります。 このプロパティは、Azure ポータルでトリガーを作成するときに自動的に設定されます。 |
| 名前 | 関数コード内のキューまたはトピック メッセージを表す変数の名前。 |
| queueName | 監視するキューの名前。 トピックではなくキューを監視する場合にのみ設定します。 |
| topicName | 監視するトピックの名前。 キューではなくトピックを監視する場合にのみ設定します。 |
| の subscriptionName | 監視するサブスクリプションの名前。 キューではなくトピックを監視する場合にのみ設定します。 |
| 接続 | Service Busに接続する方法を指定するアプリ設定または設定コレクションの名前。 「接続」を参照してください。 |
| accessRights | 接続文字列のアクセス権。 使用できる値は manage と listen です。 既定値は manage で、connection がmanageアクセス許可を持つことを示します。
Manage 権限を持たない接続文字列を使用する場合は、accessRights を "listen" に設定します。 設定しないと、Functions ランタイムが管理権限を必要とする操作の試行に失敗する可能性があります。 Azure Functions バージョン 2.x 以降では、Service Bus SDK の最新バージョンでは管理操作がサポートされていないため、このプロパティは使用できません。 |
| isSessionsEnabled |
trueキューまたはサブスクリプションに接続する場合は true。 それ以外の場合は false (既定値)。 |
| autoComplete | C# 以外の関数の場合は true である必要があります。これは、トリガーが処理後に complete を自動的に呼び出すか、関数コードが手動で complete を呼び出す必要があることを意味します。true に設定した場合、関数の実行が正常に完了すると、トリガーによって自動的にメッセージが完了され、それ以外の場合はメッセージが破棄されます。関数の例外により、ランタイム呼び出しがバックグラウンドで abandonAsync されます。 例外が発生しなかった場合は、バックグラウンドで completeAsync が呼び出されます。 このプロパティは、Azure Functions 2.x 以降でのみ使用できます。 |
完全な例については、セクションの例を参照してください。
使用方法
次のパラメーター型は、すべての C# モダリティと拡張機能バージョンでサポートされています。
| タイプ | 説明 |
|---|---|
| System.String | メッセージが単純なテキストである場合に使用します。 |
| byte[] | バイナリ データ メッセージに使用します。 |
| オブジェクト | メッセージに JSON が含まれている場合、Functions は JSON データを既知の plain-old CLR オブジェクト型に逆シリアル化しようとします。 |
メッセージング固有のパラメーター型には、追加のメッセージ メタデータが含まれます。 Service Bus トリガーでサポートされる特定の型は、Functions ランタイムのバージョン、拡張機能パッケージのバージョン、使用される C# モダリティによって異なります。
関数で 1 つのメッセージを処理する場合、Service Bus トリガーは次の型にバインドできます。
| タイプ | 説明 |
|---|---|
string |
文字列としてのメッセージ。 メッセージが単純なテキストである場合に使用します。 |
byte[] |
メッセージのバイト数。 |
| JSON シリアル化可能な型 | イベントに JSON データが含まれている場合、Functions は JSON データを単純な従来の CLR オブジェクト (POCO) 型に逆シリアル化しようとします。 |
| ServiceBusReceivedMessage1 | メッセージ オブジェクト。ServiceBusReceivedMessageにバインドする場合は、必要に応じて、ServiceBusMessageActions1,2 型のパラメーターを含め、message settlement アクションを実行することもできます。 |
関数でメッセージのバッチを処理する場合、Service Bus トリガーは次の型にバインドできます。
| タイプ | 説明 |
|---|---|
T[] (T は単一メッセージ型の 1 つ) |
バッチのイベントの配列。 各エントリは 1 つのイベントを表します。ServiceBusReceivedMessage[]にバインドする場合は、必要に応じて、ServiceBusMessageActions1,2 型のパラメーターを含め、message settlement アクションを実行することもできます。 |
1 これらの型を使用するには、Microsoft.Azure を参照する必要があります。Functions.Worker.Extensions.ServiceBus 5.14.1 以降 および SDK 型バインドのcommon 依存関係。
2ServiceBusMessageActionsを使用する場合は、トリガー属性のAutoCompleteMessagesプロパティをfalseに設定します。 これにより、関数の呼び出しが成功した後にランタイムがメッセージを完了することを試みなくなります。
Connection プロパティが定義されていない場合、Functions は AzureWebJobsServiceBus という名前のアプリ設定を検索します。これは、Service Bus 接続文字列の既定の名前です。
Connection プロパティを設定して、使用するService Bus 接続文字列を含むアプリケーション設定の名前を指定することもできます。
受信Service Bus メッセージは、ServiceBusQueueMessage または ServiceBusTopicMessage パラメーターを使用して使用できます。
Service Bus インスタンスは、function.json ファイルの name プロパティで構成されたパラメーターを使用して使用できます。
キュー メッセージは、func.ServiceBusMessage として型指定されたパラメーターを介して関数で使用できます。 Service Bus メッセージは、文字列または JSON オブジェクトとして関数に渡されます。
関数では、Azure Service Busの Python SDK 型バインドもサポートされています。これにより、基になる SDK の種類を使用してデータを操作できます。
重要
Python での Service Bus SDK の種類のサポートはプレビュー段階であり、Python v2 プログラミング モデルでのみサポートされます。 詳細については、「Python の
完全な例については、例のセクションを参照してください。
接続
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という名前のアプリ設定で。
有害メッセージ
有害メッセージの処理は、Azure Functionsで制御または構成することはできません。 Service Busは有害メッセージ自体を処理します。
PeekLock 動作
Functions ランタイムは、メッセージを PeekLock モードで受信します。
既定では、ランタイムは、関数が正常に終了した場合はメッセージに Complete を呼び出し、関数が失敗した場合は Abandon を呼び出します。
autoCompleteMessages
host.json
プロパティを使用して、自動補完を無効にすることができます。
既定では、ランタイムは、関数が正常に終了した場合はメッセージに Complete を呼び出し、関数が失敗した場合は Abandon を呼び出します。 自動補完は、autoCompleteMessageshost.json プロパティを使用するか、トリガー属性のプロパティを使用して無効にすることができます。 関数コードがメッセージ決済を処理する場合は、自動補完を無効にする必要があります。
関数が実行されている限り、関数の実行時間が PeekLock タイムアウトよりも長くなると、ロックが自動的に更新されます。
maxAutoRenewDuration は host.json で構成可能であり、これは ServiceBusProcessor.MaxAutoLockRenewalDuration にマップされます。 この設定の既定値は 5 分です。
メッセージのメタデータ
メッセージング固有の型を使用すると、オブジェクトのプロパティとしてメタデータを簡単に取得できます。 これらのプロパティは、Functions ランタイムのバージョン、拡張機能パッケージのバージョン、および使用される C# のモダリティによって異なります。
これらのプロパティは ServiceBusReceivedMessage クラスのメンバーです。
| プロパティ | タイプ | 説明 |
|---|---|---|
ApplicationProperties |
ApplicationProperties |
送信者によって設定されたプロパティ。 |
ContentType |
string |
アプリケーション固有のロジックのために送信者と受信者が利用するコンテンツ タイプ識別子。 |
CorrelationId |
string |
関連付け ID。 |
DeliveryCount |
Int32 |
配信回数。 |
EnqueuedTime |
DateTime |
エンキューされた時刻 (UTC)。 |
ScheduledEnqueueTimeUtc |
DateTime |
スケジュールされたエンキュー時刻 (UTC)。 |
ExpiresAt |
DateTime |
有効期限 (UTC)。 |
MessageId |
string |
有効Service Bus場合、重複するメッセージを識別するために使用できるユーザー定義の値。 |
ReplyTo |
string |
キュー アドレスへの返信。 |
Subject |
string |
Label メタデータ プロパティの代わりに使用できるアプリケーション固有のラベル。 |
To |
string |
送信先アドレス。 |
次のステップ
Azure Functions (出力バインド)