Azure Logic Apps のワークフローから Azure Service Bus に接続する

適用対象: Azure Logic Apps (従量課金プラン + Standard)

このガイドでは、Service Bus コネクタを使用して Azure Logic Apps のワークフローから Azure Service Bus にアクセスする方法について説明します。 その後、Service Bus のイベントによってトリガーされたときに実行される自動化されたワークフローを作成したり、Service Bus 項目を管理するアクションを実行したりできます。次に例を示します。

• キュー、トピック、およびトピック サブスクリプションにメッセージが届く (オートコンプリート) またはメッセージを受信する (ピークロック) のを監視します。
• メッセージを送信します。
• トピック サブスクリプションを作成および削除します。
• キューおよびトピック サブスクリプション内のメッセージを管理します。たとえば、取得、遅延の取得、完了、延期、破棄、配信不能などです。
• キューおよびトピック サブスクリプション内のメッセージとセッションに対するロックを更新します。
• キューとトピック内のセッションを閉じる。

トリガーを使うことができます。トリガーは Azure Service Bus からの応答を得て、その出力をワークフロー内の他の処理でも使うことができるようにします。 他のアクションに Service Bus アクションからの出力を使用させることもできます。

コネクタに関するテクニカル リファレンス

Service Bus コネクタには、ロジック アプリ ワークフローの種類とホスト環境に基づいてさまざまなバージョンがあります。

ロジック アプリ	環境	コネクタのバージョン
従量課金プラン	マルチテナント Azure Logic Apps	マネージド コネクタ。コネクタ ギャラリーの [ランタイム]>[共有] の下に表示されます。 注: Service Bus のマネージド コネクタ トリガーは、"長いポーリング トリガー" パターンに従います。つまり、トリガーはキューまたはトピック サブスクリプション内のメッセージを定期的にチェックします。 詳細については、次のドキュメントを確認してください。 - Service Bus マネージド コネクタのリファレンス - Azure Logic Apps のマネージド コネクタ
Standard	シングルテナント Azure Logic Apps と App Service Environment v3 (Windows プランのみ)	マネージド コネクタ (Azure でホスト) はコネクタ ギャラリーの [ランタイム]>[共有] に表示されます。組み込みコネクタはコネクタ ギャラリーの [ランタイム]>[アプリ内] に表示され、サービス プロバイダーベースです。 Service Bus のマネージド コネクタ トリガーは、"長いポーリング トリガー" パターンに従います。つまり、トリガーはキューまたはトピック サブスクリプション内のメッセージを定期的にチェックします。 Service Bus の組み込みコネクタの非セッション トリガーは、コネクタによって完全に管理される "継続的ポーリング トリガー パターン" に従います。 このパターンでは、トリガーがキューまたはトピック サブスクリプション内のメッセージを常に確認します。 セッション トリガーは、"ロングポーリング トリガー パターン" に従いますが、その構成は、clientRetryOptions:tryTimeout という Azure Functions 設定によって制御されます。 通常、組み込みのバージョンの方がパフォーマンス、機能、価格などに優れています。
詳細については、次のドキュメントを確認してください。 - Service Bus マネージド コネクタのリファレンス - Service Bus 組み込みコネクタによる操作 - Azure Logic Apps の組み込みコネクタ

前提条件

• Azure アカウントとサブスクリプション。 Azure サブスクリプションがない場合は、無料の Azure アカウントにサインアップしてください。

• Service Bus 名前空間と、キューなどのメッセージング エンティティ。 詳細については、次のドキュメントを確認してください。

  • Service Bus 名前空間の作成

  • Service Bus の名前空間とキューを作成する

  • サブスクリプションを含んだ Service Bus 名前空間とトピックを作成する

• Service Bus 名前空間およびメッセージング エンティティに接続するロジック アプリ ワークフロー。 Service Bus トリガー操作でワークフローを開始する場合は、空のワークフローから開始する必要があります。 ワークフローで Service Bus アクションを使用するには、任意のトリガーでワークフローを開始します。

• ロジック アプリ リソースでマネージド ID を使用して Service Bus 名前空間とメッセージング エンティティへのアクセスを認証する場合、対応するレベルでロールのアクセス許可が割り当てられていることを確認してください。 たとえば、キューにアクセスするには、そのキューに必要なアクセス許可を持つロールがマネージド ID に必要です。

  • ロジック アプリのワークフローが、異なるメッセージング エンティティにアクセスしている場合でも、各ロジック アプリ リソースで使用するマネージド ID は 1 つだけです。

  • キューまたはトピック サブスクリプションにアクセスする各マネージド ID は、独自の Service Bus API 接続を使用する必要があります。

  • 異なるメッセージング エンティティとメッセージを交換し、異なるアクセス許可を必要とする Service Bus 操作では、独自の Service Bus API 接続を使用する必要があります。

  マネージド ID の詳細については、「Azure Logic Apps でマネージド ID を使用して Azure リソースへのアクセスを認証する」を参照してください。

• 既定では、Service Bus 組み込みコネクタの操作は "ステートレス" です。 ステートフル モードでこれらの操作を実行するには、「ステートレス組み込みコネクタのステートフル モードを有効にする」を参照してください。

Azure Service Bus の運用における留意事項

無限ループ

重要

同じコネクタの種類を持つトリガーとアクションの両方を選択し、それらを使用してメッセージング キューやトピック サブスクリプションなどの同じエンティティを操作する場合は注意が必要です。 この組み合わせによって無限ループが発生し、結果としてロジック アプリが終了しなくなる可能性があります。

コネクタ キャッシュに保存されたセッションの制限

サブスクリプションや トピック などのサービス バス メッセージング エンティティ ごとのサービス バス コネクタでは、一度に最大 1,500 の一意のセッションをコネクタ キャッシュに保存できます。 セッション数がこの制限を超えると、古いセッションがキャッシュから削除されます。 詳細については、メッセージ セッション を参照してください。

相互関係のあるメッセージを順番に送信する

関連するメッセージを特定の順序で送信する必要がある場合は、Service Bus コネクタと "シーケンシャルなコンボイ" パターンを使用してワークフローを作成できます。 関連付けられたメッセージには、Azure Service Bus でのセッションの ID など、それらのメッセージ間の関係を定義するプロパティがあります。

従量課金のロジック アプリ ワークフローを作成するとき、シーケンシャルなコンボイ パターンを実装する Correlated in-order delivery using service bus sessions テンプレートを選択できます。 詳細については、関連のあるメッセージを順番に送信する方法に関するページを参照してください。

サイズの大きいメッセージのサポート

大規模なメッセージのサポートは、Service Bus 組み込みコネクタ操作を使用する場合にのみ Standard ワークフローで使用できます。 たとえば、組み込みのトリガーとアクションをそれぞれ使用して、大きなメッセージを受信できます。

Service Bus マネージド コネクタでは、Premium レベルの Service Bus 名前空間を使用する場合でも、メッセージの最大サイズは 1 MB に制限されます。

メッセージの受信と送信のタイムアウトを増やす

Service Bus の組み込み操作を使用する Standard ワークフローでは、メッセージの受信と送信のタイムアウトを増やすことができます。 たとえば、メッセージを受信するためのタイムアウト時間を長くするには、Azure Functions の拡張で次の設定を変更します。

{
   "version": "2.0",
   "extensionBundle": {
      "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
      "version": "[1.*, 2.0.0)"
   },
   "extensions": {
      "serviceBus": {
         "batchOptions": {
            "operationTimeout": "00:15:00"
         }
      }  
   }
}

メッセージ送信のタイムアウトを増やすには、ServiceProviders.ServiceBus.MessageSenderOperationTimeout アプリ設定を追加します。

Service Bus マネージド コネクタのトリガー

• Service Bus マネージド コネクタの場合、すべてのトリガーは "長いポーリング" です。 このトリガー タイプは、すべてのメッセージを処理し、さらにメッセージがキューまたはトピック サブスクリプションに表示されるまで 30 秒間待機します。 30 秒以内にメッセージが表示されない場合、トリガーの実行はスキップされます。 それ以外の場合、トリガーはキューまたは トピック サブスクリプションが空になるまでメッセージの読み取りを続けます。 次のトリガー ポーリングは、トリガーのプロパティで指定された繰り返し間隔に基づいています。

• [1 つ以上のメッセージがキューに届いたとき (オート コンプリート)] トリガーのように、1 つ以上のメッセージを返すトリガーもあります。 これらのトリガーが起動すると、1 からトリガーの [最大メッセージ数] プロパティで指定された数までのメッセージが返されます。

  Note

  オートコンプリートのトリガーでメッセージが自動的に完成しますが、これは次回の Service Bus 呼び出し時にのみ発生します。 このビヘイビアーはワークフローの設計に影響を与える可能性があります。 たとえば、オート コンプリート トリガーにおける同時並行性の変更は避けてください。なぜならこの変更によって、ワークフローがスロットルされた状態になった場合にメッセージの重複を発生させる可能性があるためです。 コンカレンシー コントロールを変更すると、次の条件が作成されます。

  • 調整されたトリガーは、WorkflowRunInProgress コードと共にスキップされます。

  • 完了操作は実行されません。

  • 次のトリガーの実行は、ポーリング間隔の後に行われます。

  ポーリング間隔より長い値にサービス バス ロック期間を設定する必要があります。 ただし、このように設定しても、ワークフローが次のポーリング間隔でもスロットルされた状態であり続けた場合は、メッセージが完了しない可能性があります。

  Service Bus の自動補完トリガーでコンカレンシーを変更する必要がある場合は、ワークフローを最初に保存する前にこの変更を行わないようにしてください。 トリガーを編集してコンカレンシーを変更する前に、最初にワークフローを作成して保存します。

Service Bus 組み込みコネクタ トリガー

Service Bus の組み込みコネクタの場合、非セッション トリガーは、コネクタによって完全に管理される "継続的ポーリング トリガー パターン" に従います。 このパターンでは、トリガーがキューまたはトピック サブスクリプション内のメッセージを常に確認します。 セッション トリガーは、"ロングポーリング トリガー パターン" に従いますが、その構成は、clientRetryOptions:tryTimeout という Azure Functions 設定によって制御されます。 現在、Service Bus 組み込みトリガーの構成設定は、ロジック アプリの host.json ファイルで定義されている Azure Functions ホスト拡張機能と、ロジック アプリのワークフローで定義されているトリガー設定 (デザイナーまたはコード ビューを使用して設定可能) の間で共有されます。 このセクションでは、両方の設定の場所について説明します。

• Standard ワークフローでは、[キューにメッセージがある場合] トリガーなど、1 つ以上のメッセージを返すトリガーもあります。 これらのトリガーが起動すると、1 からメッセージ数までの間が返されます。 この種類のトリガーで、[最大メッセージ数] パラメーターがサポートされていない場合でも、host.json ファイルの maxMessageBatchSize プロパティを使用して、受信するメッセージの数を制御できます。 このファイルを見つけるには、「Standard ロジック アプリのホストとアプリの設定を編集する」を参照してください。

  "extensions": {
    "serviceBus": {
        "maxMessageBatchSize": 25
    }
  }
  

• デザイナーを使用して、またはコードで、Service Bus トリガーでコンカレンシーを有効にすることもできます。

  "runtimeConfiguration": {
      "concurrency": {
          "runs": 100
      }
  }
  

  バッチを使用してコンカレンシーを設定する場合は、同時実行の数をバッチ サイズ全体よりも大きくします。 そうすることで、メッセージの読み取りが待機状態になることがなくなり、読み取り時には常に取得されます。 場合によっては、トリガーが最大でバッチ サイズの 2 倍になることがあります。

• コンカレンシーを有効にすると、SplitOn 上限が 100 項目に下がります。 この動作は、Service Bus トリガーだけでなく、すべてのトリガーに当てはまります。 コンカレンシーを有効にする場合には、指定されたバッチ サイズがこの制限を下回っていることを確認してください。

• トリガーがコンカレンシー設定を超える可能性があるシナリオがあります。 Azure Logic Apps では、これらの実行を失敗させるのではなく、開始できるようになるまで待機状態でキューに入れます。 maximumWaitingRuns[設定] で、待機状態にあることが可能な実行の数を制御します。

  "runtimeConfiguration": {
      "concurrency": {
          "runs": 100,
          "maximumWaitingRuns": 50
      }
  }
  

  Service Bus トリガーの使用にあたっては、これらの変更を慎重にテストして、実行がメッセージ ロック タイムアウトよりも長く待機しないようにしてください。 既定値の詳細については、こちらの「コンカレンシーと分割処理の制限」を参照してください。

• コンカレンシーを有効にした場合、既定では、バッチ読み取りの間に 30 秒の遅延が存在します。 この遅延により、トリガーで次の目標の達成が遅くなります。

  • コンカレンシーを適用する実行の数を確認するために送信されるストレージ呼び出しの数を減らす。

  • メッセージが見つからない場合に 30 秒の長いポーリングを行う Service Bus マネージド コネクタ トリガーの動作を模倣する。

  この遅延は変更できますが、既定値の変更は慎重にテストしてください。

  "workflow": {
      "settings": {
          "Runtime.ServiceProviders.FunctionTriggers.DynamicListenerEnableDisableInterval": "00:00:30"
      }
  }
  
  

手順 1: Service Bus 名前空間へのアクセスを確認する

ロジック アプリ リソースに Service Bus 名前空間にアクセスするためのアクセス許可があることを確認するには、次の手順に従います。

1. Azure portal で、ご利用の Service Bus "名前空間" に移動します。

2. 名前空間メニューで [設定] の [共有アクセス ポリシー] を選択します。 [要求] で、その名前空間に対して管理アクセス許可が付与されていることを確認します。

   

手順 2: 接続認証の要件を取得する

その後、Service Bus のトリガーまたはアクションを初めて追加すると、接続認証の種類など、接続情報の入力を求められます。 ロジック アプリのワークフローの種類、Service Bus コネクタのバージョン、選択した認証の種類に基づいて、次のものが必要になります。

マネージド コネクタの認証 (従量課金および Standard ワークフロー)

Authentication type	必要な情報
アクセス キー	Service Bus 名前空間の接続文字列を取得します。 詳細については、「Service Bus 名前空間の接続文字列を取得する」を参照してください
Microsoft Entra 統合	Service Bus 名前空間のエンドポイント URL。 詳細については、「Service Bus 名前空間のエンドポイント URL を取得する」を参照してください。
Logic Apps マネージド ID	Service Bus 名前空間のエンドポイント URL。 詳細については、「Service Bus 名前空間のエンドポイント URL を取得する」を参照してください。

組み込みコネクタの認証 (Standard ワークフローのみ)

Authentication type	必要な情報
接続文字列	Service Bus 名前空間の接続文字列を取得します。 詳細については、「Service Bus 名前空間の接続文字列を取得する」を参照してください
Active Directory OAuth	- Service Bus 名前空間の完全修飾名 (<your-Service-Bus-namespace>.servicebus.windows.net など)。 詳細については、「Service Bus 名前空間の完全修飾名を取得する」を参照してください。 その他のプロパティの値については、Microsoft Entra ID を使用した OAuth に関する記事をご覧ください。
マネージド ID	Service Bus 名前空間の完全修飾名 (<your-Service-Bus-namespace>.servicebus.windows.net など)。 詳細については、「Service Bus 名前空間の完全修飾名を取得する」を参照してください。

Service Bus 名前空間の接続文字列を取得する

Service Bus トリガーまたはアクションを追加するときに接続を作成するには、Service Bus 名前空間の接続文字列が必要です。 接続文字列は、sb:// プレフィックスで始まります。

1. Azure portal で、ご利用の Service Bus "名前空間" に移動します。

2. 名前空間メニューで [設定] の [共有アクセス ポリシー] を選択します。

3. [共有アクセス ポリシー] ウィンドウで、[RootManageSharedAccessKey] を選択します。

4. プライマリまたはセカンダリ接続文字列の横にあるコピーボタンを選択します。

   

   Note

   文字列が特定のメッセージング エンティティではなく名前空間の文字列であることを確認するには、接続文字列で EntityPath パラメーターを検索します。 このパラメーターがある場合、接続文字列は特定のエンティティを対象としています。これは、ワークフローで使用するのに適切な文字列ではありません。

5. 後で使用できるように接続文字列を保存します。

Service Bus 名前空間のエンドポイント URL を取得する

Service Bus マネージド コネクタを使用する場合、Microsoft Entra 統合または Logic Apps マネージド ID のいずれかの認証の種類を選択する場合に、このエンドポイント URL が必要です。 エンドポイント URL は、sb:// プレフィックスで始まります。

1. Azure portal で、ご利用の Service Bus "名前空間" に移動します。

2. 名前空間メニューの [設定] で、[プロパティ] を選択します。

3. [プロパティ] の下の [Service Bus エンドポイント] の横にあるエンドポイント URL をコピーし、後で Service Bus エンドポイント URL を指定する必要が生じたときに使用するために保存します。

Service Bus 名前空間の完全修飾名を取得する

1. Azure portal で、ご利用の Service Bus "名前空間" に移動します。

2. 名前空間メニューの [概要] を選択します。

3. [概要] ウィンドウで、[ホスト名] プロパティを見つけて、完全修飾名をコピーします。これは <your-Service-Bus-namespace>.servicebus.windows.net のようになります。

手順 3: オプション 1 - Service Bus トリガーを追加する

次に示す手順では Azure portal を使用しますが、適切な Azure Logic Apps 拡張機能を使用すれば、次のツールでロジック アプリ ワークフローを作成することもできます。

• 従量課金ワークフロー: Visual Studio Code
• Standard ワークフロー: Visual Studio Code

従量課金プラン

1. Azure portal で、従量課金ロジック アプリ リソースと空のワークフローをデザイナーで開きます。

2. デザイナーで、こちらの一般的な手順に従って、必要な Azure Service Bus トリガーを追加します。

   この例では、When a message is received in a queue (auto-complete) という名前のトリガーで続行します。

3. ダイアログが表示されたら、接続に関する次の情報を指定します。 完了したら [作成] を選択します。

   プロパティ	Required	説明
   接続名	はい	接続の名前
   認証の種類	はい	Service Bus 名前空間へのアクセスに使用する認証の種類。 詳細については、「マネージド コネクタ認証」を確認してください。
   接続文字列	はい	先ほどコピーして保存した接続文字列。

   たとえば、この接続はアクセス キー認証を使用し、Service Bus 名前空間の接続文字列を提供します。

   

4. トリガー情報ボックスが表示されたら、次の例のように必要な情報を入力します。

   プロパティ	Required	説明
   キュー名	はい	アクセスする選択されたキュー
   [キューの種類]	いいえ	選択したキューの種類
   [項目を確認する頻度]:	はい	キューで項目をチェックするポーリング間隔と頻度

   

5. その他の使用可能なプロパティをトリガーに追加するには、[新しいパラメーターの追加] リストを開き、必要なプロパティを選択します。

6. ワークフローに必要なアクションがあれば追加します。

   たとえば、新しいメッセージが届いたときにメールを送信するアクションを追加することができます。 トリガーがキューを確認して新しいメッセージを見つけた場合、ワークフローはそのメッセージに対して設定された処理を実行します。

7. 完了したら、ワークフローを保存します。 デザイナーのツール バーで、 [保存] を選択します。

Standard

Service Bus トリガーを追加して使用する手順は、組み込みコネクタ トリガーと "Azure" マネージド コネクタ トリガーのどちらを使用するかによって異なります。

• 組み込みトリガー: 組み込みトリガーを追加する手順について説明します。

• マネージド トリガー: マネージド トリガーを追加する手順について説明します。

組み込みコネクタ トリガー

既定では、Service Bus 組み込みコネクタはステートレス コネクタです。 このコネクタの操作をステートフル モードで実行するには、「ステートレス組み込みコネクタのステートフル モードを有効にする」を参照してください。 また、Service Bus 組み込みの非セッション トリガーは "プッシュ トリガー" パターンに従い、一方、セッション ベースのトリガーではポーリング機能が提供されます。

1. Azure portal で、Standard ロジック アプリ リソースと空のワークフローをデザイナーで開きます。

2. デザイナーで、こちらの一般的な手順に従って、必要な Azure Service Bus 組み込みトリガーを追加します。

   この例では、引き続き "キューでメッセージを使用できる場合" という組み込みのオートコンプリート トリガーを使用します。 このトリガーは、サービス バスからメッセージを読み取ります。 ロジック アプリでメッセージを取得し、トリガーの応答をストレージに保存できる場合、トリガーはメッセージを自動的に完了します。 そうではなくエラーが発生した場合、トリガーはメッセージを破棄します。 これらの動作はステートフル ワークフローにのみ適用されます。 ステートレス ワークフローの場合、自動完了または破棄の決定は、実行が完了した後にのみ行われます。

3. ダイアログが表示されたら、接続に関する次の情報を指定します。 完了したら [作成] を選択します。

   プロパティ	Required	説明
   接続名	はい	接続の名前
   認証の種類	はい	Service Bus 名前空間へのアクセスに使用する認証の種類。 詳細については、「組み込みコネクタ認証」を確認してください。
   接続文字列	はい	先ほどコピーして保存した接続文字列。

   たとえば、この接続は接続文字列認証を使用し、Service Bus 名前空間の接続文字列を提供します。

   

4. トリガー情報ボックスが表示されたら、次の例のように必要な情報を入力します。

   プロパティ	Required	説明
   キュー名	はい	アクセスする選択されたキュー
   IsSessionsEnabled	いいえ	セッション対応キューに接続していない場合は、- いいえ (既定値) - それ以外の場合ははい

   

5. ワークフローに必要なアクションがあれば追加します。

   たとえば、新しいメッセージが届いたときにメールを送信するアクションを追加することができます。 トリガーがキューを確認して新しいメッセージを見つけた場合、ワークフローはそのメッセージに対して設定された処理を実行します。

6. 完了したら、ワークフローを保存します。 デザイナーのツール バーで、 [保存] を選択します。

マネージド コネクタ トリガー

Service Bus マネージド トリガーは、"長いポーリング トリガー" パターンに従います。

1. Azure portal で、Standard ロジック アプリ リソースと空のワークフローをデザイナーで開きます。

2. デザイナーで、こちらの一般的な手順に従って、必要な Azure Service Bus マネージド トリガーを追加します。

   この例では、When a message is received in a queue (auto-complete) という名前のトリガーで続行します。

3. 接続ボックスに、以下の情報を指定します。 完了したら [作成] を選択します。

   プロパティ	Required	説明
   接続名	はい	接続の名前
   認証の種類	はい	Service Bus 名前空間へのアクセスに使用する認証の種類。 詳細については、「マネージド コネクタ認証」を確認してください。
   接続文字列	はい	先ほどコピーして保存した接続文字列。

   たとえば、この接続はアクセス キー認証を使用し、Service Bus 名前空間の接続文字列を提供します。

   

4. トリガー情報ボックスが表示されたら、次の例のように必要な情報を入力します。

   プロパティ	Required	説明
   キュー名	はい	アクセスする選択されたキュー
   [キューの種類]	いいえ	選択したキューの種類
   [項目を確認する頻度]:	はい	キューで項目をチェックするポーリング間隔と頻度

   

5. その他の使用可能なプロパティをトリガーに追加するには、[新しいパラメーターの追加] リストを開き、必要なプロパティを選択します。

6. ワークフローに必要なアクションがあれば追加します。

   たとえば、新しいメッセージが届いたときにメールを送信するアクションを追加することができます。 トリガーがキューを確認して新しいメッセージを見つけた場合、ワークフローはそのメッセージに対して設定された処理を実行します。

7. 完了したら、ワークフローを保存します。 デザイナーのツール バーで、 [保存] を選択します。

手順 3: オプション 2 - Service Bus アクションを追加する

次に示す手順では Azure portal を使用しますが、適切な Azure Logic Apps 拡張機能を使用すれば、次のツールでロジック アプリ ワークフローをビルドすることもできます。

• 従量課金ワークフロー: Visual Studio Code
• Standard ワークフロー: Visual Studio Code

従量課金プラン

1. Azure portal で、従量課金ロジック アプリとワークフローをデザイナーで開きます。

2. デザイナーで、こちらの一般的な手順に従って、必要な Azure Service Bus アクションを追加します。

   この例では、メッセージの送信アクションを続行します。

3. ダイアログが表示されたら、接続に関する次の情報を指定します。 完了したら [作成] を選択します。

   プロパティ	Required	説明
   接続名	はい	接続の名前
   認証の種類	はい	Service Bus 名前空間へのアクセスに使用する認証の種類。 詳細については、「マネージド コネクタ認証」を確認してください。
   接続文字列	はい	先ほどコピーして保存した接続文字列。

   たとえば、この接続はアクセス キー認証を使用し、Service Bus 名前空間の接続文字列を提供します。

   

4. アクション情報ボックスが表示されたら、次の例のように必要な情報を入力します。

   プロパティ	Required	説明
   Queue/Topic name (キュー/トピック名)	はい	メッセージを送信するために選択したキューまたはトピックの宛先
   セッション ID	いいえ	セッション対応キューまたはトピックにメッセージを送信する場合のセッション ID
   System properties (システムのプロパティ)	いいえ	- なし - 実行の詳細: 実行に関するメタデータ プロパティ情報をメッセージにカスタム プロパティとして追加します。

   

5. その他の使用可能なプロパティをアクションに追加するには、[新しいパラメーターの追加] リストを開き、必要なプロパティを選択します。

6. ワークフローに必要な他のアクションを追加します。

   たとえば、メッセージが送信されたことを確認するメールを送信するアクションを追加することができます。

7. 完了したら、ワークフローを保存します。 デザイナーのツール バーで、 [保存] を選択します。

Standard

Service Bus アクションを追加して使用する手順は、組み込みコネクタ トリガーと "Azure" マネージド コネクタ トリガーのどちらを使用するかによって異なります。

• 組み込みアクション: 組み込みアクションを追加する手順について説明します。

• マネージド アクション: マネージド アクションを追加する手順について説明します。

組み込みコネクタ アクション

組み込みの Service Bus コネクタは、既定ではステートレス コネクタです。 このコネクタの操作をステートフル モードで実行するには、「ステートレス組み込みコネクタのステートフル モードを有効にする」を参照してください。

1. Azure portal で、Standard ロジック アプリ リソースとワークフローをデザイナーで開きます。

2. デザイナーで、こちらの一般的な手順に従って、必要な Azure Service Bus 組み込みアクションを追加します。

   この例では、Send message というアクションを使用して、進めていきます。

3. ダイアログが表示されたら、接続に関する次の情報を指定します。 完了したら [作成] を選択します。

   プロパティ	Required	説明
   接続名	はい	接続の名前
   認証の種類	はい	Service Bus 名前空間へのアクセスに使用する認証の種類。 詳細については、「組み込みコネクタ認証」を確認してください。
   接続文字列	はい	先ほどコピーして保存した接続文字列。

   たとえば、この接続は接続文字列認証を使用し、Service Bus 名前空間の接続文字列を提供します。

   

4. アクション情報ボックスが表示されたら、次の例のように必要な情報を入力します。

   プロパティ	Required	説明
   キューまたはトピックの名前	はい	アクセスする選択されたキュー

   

5. その他の使用可能なプロパティをアクションに追加するには、[新しいパラメーターの追加] リストを開き、必要なプロパティを選択します。

6. ワークフローに必要な他のアクションを追加します。

   たとえば、メッセージが送信されたことを確認するメールを送信するアクションを追加することができます。

7. 完了したら、ワークフローを保存します。 デザイナーのツール バーで、 [保存] を選択します。

マネージド コネクタ アクション

1. Azure portal で、Standard ロジック アプリ リソースとワークフローをデザイナーで開きます。

2. デザイナーで、こちらの一般的な手順に従って、必要な Azure Service Bus マネージド アクションを追加します。

   この例では、Send message というアクションを使用して、進めていきます。

3. ダイアログが表示されたら、接続に関する次の情報を指定します。 完了したら [作成] を選択します。

   プロパティ	Required	説明
   接続名	はい	接続の名前
   認証の種類	はい	Service Bus 名前空間へのアクセスに使用する認証の種類。 詳細については、「マネージド コネクタ認証」を確認してください。
   接続文字列	はい	先ほどコピーして保存した接続文字列。

   たとえば、この接続はアクセス キー認証を使用し、Service Bus 名前空間の接続文字列を提供します。

   

4. アクション情報ボックスが表示されたら、次の例のように必要な情報を入力します。

   プロパティ	Required	説明
   Queue/Topic name (キュー/トピック名)	はい	メッセージを送信するために選択したキューまたはトピックの宛先
   セッション ID	いいえ	セッション対応キューまたはトピックにメッセージを送信する場合のセッション ID
   System properties (システムのプロパティ)	いいえ	- なし - 実行の詳細: 実行に関するメタデータ プロパティ情報をメッセージにカスタム プロパティとして追加します。

   

5. その他の使用可能なプロパティをアクションに追加するには、[新しいパラメーターの追加] リストを開き、必要なプロパティを選択します。

6. ワークフローに必要な他のアクションを追加します。

   たとえば、メッセージが送信されたことを確認するメールを送信するアクションを追加することができます。

7. 完了したら、ワークフローを保存します。 デザイナーのツール バーで、 [保存] を選択します。

Service Bus 組み込みのコネクタ アプリの設定

Standard ロジック アプリ リソースの Service Bus 組み込みコネクタには、メッセージの送信タイムアウトやメッセージ プール内のプロセッサ コアあたりのメッセージ送信者数など、さまざまなしきい値を制御するアプリ設定が含まれています。 詳細については、アプリ設定のリファレンス - local.settings.json を参照してください。

Service Bus 組み込みトリガーを使用して配信不能キューからメッセージを読み取る

Standard ワークフローで、キューまたはトピック サブスクリプションの配信不能キューからメッセージを読み取るために、指定されたトリガーを使用してこちらの手順に従います。

1. 空のワークフローで、シナリオに基づいて、When messages are available in a queue (キューにメッセージがある場合) または When a message are available in a topic subscription (peek-lock) (トピック サブスクリプションにメッセージがある場合 (ピークロック)) という名前の Service Bus "組み込み" コネクタ トリガーを追加します。

2. このトリガーで、次のパラメータ値を設定して、キューまたはトピック サブスクリプションの既定の配信不能キュー (他のキューと同様にアクセス可能) を指定します。

   • When messages are available in a queue (キューにメッセージがある場合) トリガー: Queue name パラメータを queuename/$deadletterqueue に設定します。

   • When a message are available in a topic subscription (peek-lock) (トピック サブスクリプションにメッセージがある場合 (ピークロック)) トリガー: Topic name パラメータを topicname/Subscriptions/subscriptionname/$deadletterqueue に設定します。

   詳細については、「Service Bus の配信不能キューの概要」を参照してください。

トラブルシューティング

ワークフローの更新の有効化が遅延する

Service Bus トリガーのポーリング間隔が 10 秒のように短い場合は、ワークフローに対して行った更新が有効になるまでに最大で 10 分かかる場合があります。 この問題に対処するために、ロジック アプリ リソースを無効にして、変更を行い、そして再度ロジック アプリ リソースを有効にすることができます。

利用可能なセッションがないか、他の受信者によってロックされている可能性があります

メッセージの完了やセッションの更新などの操作で、次のエラーが発生することがあります。

{
  "status": 400,
  "error": {
    "message": "No session available to complete the message with the lock token 'ce440818-f26f-4a04-aca8-555555555555'."
  }
}

場合によっては、次のエラーでセッション ベースのトリガーが失敗することがあります。

{
  "status": 400,
  "error": {
    "message": "Communication with the Service Bus namespace 'xxxx' and 'yyyy' entity failed. The requested session 'zzzz' cannot be accepted. It may be locked by another receiver."
  }
}

Service Bus コネクタでは、インメモリ キャッシュを使用して、セッションに関連するすべての操作をサポートします。 Service Bus メッセージ受信者は、メッセージを受信するロール インスタンス (仮想マシン) のメモリにキャッシュされます。 すべての要求を処理するために、接続のすべての呼び出しがこの同じロール インスタンスにルーティングされます。 セッション内のすべての Service Bus 操作には、特定のセッションのメッセージを受信するのと同じ受信者が必要であるため、この動作が必要です。

インフラストラクチャの更新、コネクタのデプロイなどの理由により、要求が同じロール インスタンスにルーティングされない可能性があります。 このイベントが発生すると、要求は次のいずれかの理由で失敗します。

• セッションで操作を実行する受信者は、要求を処理するロール インスタンスでは使用できません。

• 新しいロール インスタンスは、以前のロール インスタンスでタイムアウトしたか、閉じられていなかったセッションを取得しようとします。

このエラーがごくまれに発生するのであれば、エラーは想定されています。 エラーが発生した場合、メッセージは Service Bus に引き続き保持されます。 次のトリガーまたはワークフローの実行で、メッセージの処理が再試行されます。

次のステップ

• Azure Logic Apps のマネージド コネクタ
• Azure Logic Apps の組み込みコネクタ
• Azure Logic Apps の コネクタとは