このエントリは2020/02/26現在の情報に基づいています。将来の機能追加・変更に伴い、記載内容との乖離が発生する可能性があります。
Azure Service Bus では、Azure Event Grid との新しい統合が利用可能になりました。 この機能の重要なシナリオは、メッセージが少量の Service Bus キューまたはサブスクリプションで、メッセージのレシーバー ポーリングを常時行う必要がなくなるというものです。
Azure Service Bus と Event Grid の統合の概要 / Azure Service Bus to Event Grid integration overview – https://docs.microsoft.com/azure/service-bus-messaging/service-bus-to-event-grid-integration-concept
ドキュメントに記載の通り、Event Gridを挟むことで、以下のメリットを享受できる。
- サブスクライバがService Busへのポーリング(Long polling)をする必要がなくなる
- サブスクライバは、Webhookなどのイベントハンドラーを登録してイベントを受信後、Service Busにメッセージを取得する(Service Busをリアクティブプログラミングモデルで利用)
ただ、以下の点は考慮しておく必要がある。
- Event Hubsから取得できるのはあくまでもイベントであり、Service Busに配信されたメッセージではないため、イベント着信後Service Busに接続する必要がある
- Service Busのトリガーバインド済みのFunctionsアプリであれば、わざわざEvent Gridとの連携をする必要はない(イベント受信後にService Busからメッセージを取り出すロジックにすること自体ナンセンス)
そのため、ドキュメントに記載の通り、常に待ち受けるのではなく、イベントを待って受け取る仕組みにしたほうがよい状況下で利用することを推奨する。
この連携については、以下のようなチュートリアルも用意されている。
チュートリアル:Azure Functions と Azure Logic Apps を使用して、Azure Event Grid 経由で受信した Azure Service Bus イベントに応答する / Tutorial: Respond to Azure Service Bus events received via Azure Event Grid by using Azure Functions and Azure Logic Apps
https://docs.microsoft.com/azure/service-bus-messaging/service-bus-to-event-grid-integration-example?tabs=v2
このチュートリアルのFunctionsを使う例はC#で記述しているが、他言語でもEvent Gridトリガーを使ったFunctionsアプリを作成すれば接続できる。また、Service Busにメッセージを投入するアプリは、Service Bus Explorerで代用できる。
例えばJavaでFunctionsアプリを作成する場合はMavenで以下のような感じで。
mvn archetype:generate \
-DarchetypeGroupId=com.microsoft.azure \
-DarchetypeArtifactId=azure-functions-archetype \
-DappName={functionAppName} \
-DappRegion={region} \
-DresourceGroup={resourceGroup} \
-DgroupId=com.{functionAppName}.group \
-DartifactId={functionAppName}-functions \
-Dpackage=com.{functionAppName} \
-DinteractiveMode=false
この後、Event Grid利用のため依存関係として以下を追加。pom.xmlにはリソースグループはリージョンなどを指定できるので、必要に応じて変更しておく。
<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>azure-eventgrid</artifactId>
<version>1.3.0</version>
</dependency>
今回は受け取ったイベントの内容をログに出力するという、シンプルなFunctionsアプリにする。以下のコードではwarningとして出力しているが、これはAzure Portalのログストリーミング機能で見分けがつくようにしたいだけで、それ以上の理由はない。
@FunctionName("events")
public void logEvent(
@EventGridTrigger(
name = "event"
) String event,
final ExecutionContext context) {
context.getLogger().warning("Event content: " + event);
}
受け取ったイベントを見ると、以下の情報が伝達されていることがわかる。
- Service Busインスタンス
- Subject
- メッセージが着信したTopic/Queue名、Subscription
