カテゴリー別アーカイブ: Logic Apps

Logic Appsで非同期応答を待つ

このエントリは2019/07/26現在の情報に基づきます。今後の機能追加・廃止に伴い、記載内容との齟齬が発生する可能性があります(以前作成したものを手違いで削除したため、新たに書き起こしました)。

関連エントリ

HTTP応答タイムアウト

ロジックアプリのHTTP同期応答タイムアウトは120秒(ISEは240秒)で、この間に応答がなければタイムアウトし、次のアクションに進む。

タイムアウト
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-limits-and-config#timeout
Timeout
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-limits-and-config#timeout

同期応答のタイムアウトを超えて待機する必要がある場合、非同期ポーリング、非同期webhook、もしくはUntilループを使うことが推奨されている。それぞれに関するドキュメントは以下の通り。

ポーリング アクション パターンで長時間タスクを実行する
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-create-api-app#async-pattern
Perform long-running tasks with the polling action pattern
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-create-api-app#perform-long-running-tasks-with-the-polling-action-pattern

webhook アクション パターンで長時間タスクを実行する
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-create-api-app#perform-long-running-tasks-with-the-webhook-action-pattern
Perform long-running tasks with the webhook action pattern
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-create-api-app#perform-long-running-tasks-with-the-webhook-action-pattern

Until アクション
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-workflow-actions-triggers#until-action
Until action
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-workflow-actions-triggers#until-action

まず、何も考えずにHTTP同期レスポンスタイムアウトの挙動を確認する

単純にタイムアウト時間を超えるようなロジックアプリを作成し、実行する。子ロジックアプリは以下のような感じ。

これを親ロジックアプリから実行すると、タイムアウト制限時間内にHTTP同期レスポンスがないために再試行し、結果として失敗してしまう。以下はPostmanから呼び出した例。2分過ぎでタイムアウト発生、504を返していることがわかる。

こちらは。Logic Appsの実行履歴。

子ロジックアプリ側は、親ロジックアプリにレスポンスを返そうとしたけれど、親ロジックアプリはすでにタイムアウトしているので送信できない、という状況。

非同期ポーリング アクション パターン

非同期ポーリング アクション パターンの場合、Untilループを使って結果を確認する。以下はその例。

  1. 子ロジックアプリを起動
  2. 子ロジックアプリが即座に202などを親ロジックアプリに返す
  3. 親ロジックアプリは後続の処理を続行
  4. 子ロジックアプリの処理終了後、何らかの記憶域に結果を書き出す
  5. 親ロジックアプリは、子ロジックアプリの処理状況(つまり子ロジックアプリの結果を書き出す記憶域)をループで確認して、その結果によって次のアクションに移るかどうか判断する。

この非同期ポーリングでは、親ロジックアプリで並列分岐のアクションを使えば、結果を待つ処理と、後続処理を並行させることができる。

この例はイメージしやすいので詳細は省略する。HTTP応答のタイムアウト設定などは、HTTP送信アクションの設定から構成できる。

Webhook アクション パターン

非同期ポーリングパターンとは異なり、親ロジックアプリがコールバックURLを子ロジックアプリに渡し、親ロジックアプリではコールバックを待機する。以下はその例。

  1. 子ロジックアプリを起動する際に、コールバックURLを登録する
  2. 親ロジックアプリはコールバックを待機
  3. 子ロジックアプリは処理終了後、コールバックURLに対して結果を返す
  4. 親ロジックアプリは、子ロジックアプリからのコールバックを受け取り、その結果によって次のアクションに移るかどうか判断する。

WS-BPELなどにおける非同期コールバックと似ているが、WS-BPELの場合、 (非同期ポーリングの場合と同様に) リクエストから非同期コールバックまでの間に処理を含めることができるのに対し、Wehookアクションの場合、子ロジックアプリ呼び出しのタイミングでコールバック待機するため、並行処理できないという点に大きな違いがある。

親ロジックアプリに少々手をいれ、着信と同時に202を返した後、子ロジックアプリを呼び出しつつコールバックを登録している。以下はその例。

子ロジックアプリも少々変更し、コールバックURLに対して応答を返すようにした。以下はその例。

実際に動作確認してみた。まずは先ほどと同様、Postmanで呼び出したところ、設定通り202を返すことがわかる。

実行履歴を見ると、2分以上経過しても待機しつづけ、完了まで待っている。

実行履歴の詳細を比較すると、相関IDである関連付けIDが一致していることもわかる。

Azure Service Bus の Queue/Topic にデータを出し入れする

このエントリは2019/06/28現在の情報に基づきます。今後の機能追加や廃止に伴い、記載内容との齟齬が発生する可能性があります。

Azure Service Busとは

Microsoft Azure Service Bus は、フル マネージド エンタープライズ統合メッセージ ブローカーです。 Service Bus の最も一般的な用途は、アプリとサービスを相互に分離する場合です。Service Bus は非同期データと状態転送に適した信頼性の高い安全なプラットフォームです。 データは、メッセージを使用してさまざまなアプリとサービス間で転送されます。 メッセージはバイナリ形式であり、JSON、XML、または単なるテキストを含むことができます。

Azure Service Bus とは
https://docs.microsoft.com/ja-jp/azure/service-bus-messaging/service-bus-messaging-overview

上記の通り、メッセージブローカーで、オンプレミスでいうところのWebSphere MQやRabbit MQ、JMS実装などに類するもの。名前だけだと、SOAのService Busと勘違いするが、そこは違うので要注意。

他サービスが提供するQueue/Topicとの違い

詳細は以下のドキュメントを参照。

Storage キューと Service Bus キューの比較
https://docs.microsoft.com/ja-jp/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted
Storage queues and Service Bus queues – compared and contrasted
https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted

Azure メッセージング サービスの中から選択する – Azure Event Grid、Event Hubs、および Service Bus
https://docs.microsoft.com/ja-jp/azure/event-grid/compare-messaging-services
Choose between Azure messaging services – Event Grid, Event Hubs, and Service Bus
https://docs.microsoft.com/ja-jp/azure/event-grid/compare-messaging-services

もしくは、以下のエントリを参照。

Queue/Topicが使えるサービス
https://logico-jp.io/2019/06/11/how-to-choose-queue-or-topic-services/

データの出し入れ

データを入れる場合

サポートされている Service Bus API クライアントを使用した Service Bus への送信操作では、通常、明示的に解決されます。API 操作は、Service Bus からの受信結果を受け取るまで待機してから送信操作を完了します。
Service Bus によってメッセージが拒否された場合、拒否には、”追跡 ID” が含まれたテキストとエラーのインジケーターが含まれます。 拒否には、操作が成功する可能性があり、操作を再試行するかどうかに関する情報も含まれています。 この情報はクライアント内で例外に変換され、送信操作の呼び出し元に報告されます。 メッセージが受け取られた場合、操作は自動的に完了します。

メッセージの転送、ロック、および解決 – 送信操作の解決
https://docs.microsoft.com/ja-jp/azure/service-bus-messaging/message-transfers-locks-settlement#settling-send-operations

ドキュメント上、送信して結果を受け取るところまで待機する方式で実装することが推奨されている。Fire-forget形式を選択することも可能ではあるが、データのロストが発生する可能性があることは認識しておく必要がある。

データを出す場合

PeekLock

受信クライアントが、受信したメッセージの明示的な解決を求めることを、ブローカーに指示します。 受信クライアントが処理できるよう、メッセージに排他的なロックがかけられ、他の競合受信クライアントからは認識できなくなります。 ロックの有効期間は、当初キューまたはサブスクリプション レベルで定義され、ロックを所有しているクライアントによる RenewLock 操作によって延長できます。

メッセージの転送、ロック、および解決 – 受信操作の解決
https://docs.microsoft.com/ja-jp/azure/service-bus-messaging/message-transfers-locks-settlement#settling-receive-operations

MQやJMSを知っている人になじみが深い挙動で、メッセージの取り扱いはクライアントに委ねられているため、明示的に完了を発行しなければメッセージはブローカーに滞留する(最大試行回数を超えると、Dead Letter Queueに入る)。

ReceiveAndDelete(受信して削除)

ブローカーは、ブローカーが受信クライアントに送信するすべてのメッセージを、送信時点で解決済みとみなします。 つまり、ブローカーが送信するとただちにメッセージは消費されたとみなされます。 メッセージの転送が失敗した場合、メッセージは失われます。
このモードのメリットは、受信側メッセージでそれ以上のアクションを実行する必要はなく、解決の結果を待機する遅延も発生しないことです。 各メッセージに含まれるデータの価値が低い、またはデータが意味を持つ時間が非常に短時間の場合は、このモードは妥当な選択です。

メッセージの転送、ロック、および解決 – 受信操作の解決
https://docs.microsoft.com/ja-jp/azure/service-bus-messaging/message-transfers-locks-settlement#settling-receive-operations

「受け取ったらブローカー側には責任がない」ので、クライアント側で障害があった場合や受け取りに失敗した場合にメッセージをロストする可能性がある。データを入れる際のFire-forget形式に近い。データロストを避けたいのであれば、この方式は使うべきではない。

動作を確認する

今回はLogic Appsを使って確認した。なお、Topicでも同様の挙動を示すため、Queueについてのみ紹介する。

PeekLock

Queueに入ったメッセージをPeekLockモードで受信し、Queue内のメッセージを完了せずに強制的にインスタンスを終了させるようなロジックアプリを作成した。Queueにメッセージを入れてこのロジックアプリが動作すると、Queueからはメッセージは削除されず、Retryが続いて最終的にDead Letter Queueにメッセージが入る。

続いて、Queue内のメッセージを完了させるよう「キュー内のメッセージを完了する」アクションを通すと、メッセージはQueueから消去される。

QueueのメッセージをDead Letter Queueに入れるように「キューのメッセージを配信不能にする」アクションを使うと、このタイミングでメッセージはDead Letter Queueに入り、ロックは解除される。そのため、このアクションの後に 「キュー内のメッセージを完了する」アクションを配置すると、すでにロックは存在しないので例外が発生する。

ReceiveAndDelete

Logic AppsではこのモードはAuto Completeと呼ばれる。

PeekLockモードと同様に、Queueに入ったメッセージをReceiveAndDeleteモードで受信し、強制的にインスタンスを終了させるようなロジックアプリを作成した。Queueにメッセージを入れてこのロジックアプリが動作すると、Queueからメッセージは削除される。これはメッセージがQueueから取り出された時点でブローカーはメッセージを削除しているためである。

続いて、「キュー内のメッセージを完了する」アクションを通すようにすると、元々ロックされていないメッセージに対してロックの解放を指示しているので、例外が発生する。

Dead Letter Queueに入れるよう「配信不能にする」アクションを指定すると、これも「キュー内のメッセージを完了する」場合と同様、ロック対象ではないものに対してロックリリースをしようとして失敗する。

まとめ

Service BusのQueue/Topicについて受信時の挙動を確認した。今回はロジックアプリで確認したが、Javaでクライアントを記述する場合、PeekLockモードで受信する場合にはQueueClient#completeをお忘れなく。

Logic Apps と Cosmos DB

このエントリは2019/06/21現在の情報に基づきます。そのため、将来の機能追加・廃止に伴い、記載内容との乖離が発生する可能性があります。

関連エントリ

Serverlessというコンセプトに則ったサービスであるLogic Appsは、複雑なロジックは向いていないながらも、シンプルなロジックであれば、コードをできるだけ書かずにFunctionsのような動作をさせることができる。今回はCosmos DBに対する操作を確認した。なお、データはAPI Managementのエントリで使っている3レターコードを格納したコレクションを使っている。

コネクタ

Azure Cosmos DBのコネクタが存在するが、アクションとしてのみ利用可能で、トリガーとして利用することはできない。変更フィードをLogic Appで取り扱うためには、現時点では以下のように、Cosmos DBとLogic Appの間mediationするものを挟む必要がある。

  • Functionsで受け取ってmediationするものを作成、もしくは連携する(Event GridやEvent Hub、Service Busなど)
  • 変更フィードプロセッサライブラリを使ってmediationするものを作成、もしくは連携する(ただし.NETのみ)
  • Azure Cosmos DB SQL API SDK を使用してmediationするものを作成、もしくは連携する

クエリ

[1つのドキュメントを取得する]アクションを使う場合、[ドキュメントID]はダブルクォーテーションで囲まない点に注意が必要。対して、[パーティション キーの値]は、必ずダブルクォーテーションで囲む必要がある。

SFOを指定した場合、以下のような結果が返る(一部マスク済み)。当然ながら、この内容はCosmos DBのデータエクスプローラーで確認できる値と同じ(ただし_tsを除く)。

{
    "code": "SFO",
    "id": "SFO",
    "en": "San Francisco, CA",
    "ja": "サンフランシスコ",
    "_rid": "...",
    "_self": "dbs/.../",
    "_etag": "...",
    "_attachments": "attachments/",
    "_ts": 1561101814
}

もし複数件のレコードを取得する可能性がある場合、[複数のドキュメントにクエリを実行する]を使うとクエリを記載できる。

この場合、codeとしてTを指定すると、以下のように複数のレコードが返る。

[
    {
        "code": "CTS",
        "en": "Sapporo (Chitose)",
        "ja": "札幌(千歳)"
    },
    {
        "code": "TTJ",
        "en": "Tottori",
        "ja": "鳥取"
    },
    {
        "code": "AXT",
        "en": "Akita",
        "ja": "秋田"
    },
    {
        "code": "NTQ",
        "en": "Noto",
        "ja": "能登"
    },
    {
        "code": "TOY",
        "en": "Toyama",
        "ja": "富山"
    },
    {
        "code": "TAK",
        "en": "Takamatsu",
        "ja": "高松"
    },
    {
        "code": "OIT",
        "en": "Oita",
        "ja": "大分"
    },
    {
        "code": "TYO",
        "en": "Tokyo (All)",
        "ja": "東京(すべて)"
    },
    {
        "code": "ITM",
        "en": "Osaka (Itami)",
        "ja": "大阪(伊丹)"
    },
    {
        "code": "NRT",
        "en": "Tokyo (Narita)",
        "ja": "東京(成田)"
    },
    {
        "code": "TKS",
        "en": "Tokushima",
        "ja": "徳島"
    },
    {
        "code": "TSJ",
        "en": "Tsushima",
        "ja": "対馬"
    }
]

挿入・更新

挿入・更新時には、Upsertするか否かを指定できる(デフォルトでは出てこないので、[新しいパラメーターの追加]から選択する必要がある)。また、[パーティション キーの値]は、必ずダブルクォーテーションで囲むこと。

削除

これも[1つのドキュメントを取得する]アクションと同様、[ドキュメントID]はダブルクォーテーションで囲まない点に注意が必要。対して、[パーティション キーの値]は、必ずダブルクォーテーションで囲む必要がある。

まとめ

設定フィールドごとにダブルクォーテーションで囲む・囲まないの設定が必要なので、注意が必要である。

Logic Apps でオンプレミスと接続

このエントリは2019/06/14現在の情報に基づきます。将来の機能追加・廃止に伴い、記述内容との齟齬が発生する可能性があります。

関連エントリ

On-premises Data Gateway

すべてのシステムがクラウドで稼働しているわけではないので、オンプレミスのシステムとの統合が必要な場合が多々ある。Logic Apps、というよりはAzure側からオンプレミスへの接続(つまりオンプレミス側からするとインバウンド接続)は通常Firewallなどで禁止されているため、オンプレミス側からのアウトバウンド接続を使って連携できるように工夫する必要がある。そのための仕組みが、On-premises Data Gateway。

動作のしくみ

On-premises Data GatewayはAzure内部でService Busを使ってメッセージングの信頼性を担保している。

詳細は以下のURLを参照。

ゲートウェイの動作
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-gateway-install#how-does-the-gateway-work
How does the gateway work?
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-gateway-install#how-does-the-gateway-work

可用性

On-premises Data Gatewayは可用性を担保するため、クラスター構成が可能。クラスター構成手順は以下を参照。

オンプレミス データ ゲートウェイの高可用性クラスター
https://docs.microsoft.com/ja-jp/power-bi/service-gateway-high-availability-clusters
High availability clusters for On-premises data gateway
https://docs.microsoft.com/en-us/power-bi/service-gateway-high-availability-clusters

特長

On-premises Data GatewayはLogic Appsだけでなく、その他4種類のサービスで共通して利用可能。ただし、Logic Apps、Azure Analysis Services以外は選択可能なリージョンに制限がある(というよりは、West Central USでなければ他のサービスと共同利用ができない)。

  • Microsoft Power BI
  • Microsoft PowerApps
  • Microsoft Flow
  • Azure Analysis Services

インストール時の注意点、手順

ドキュメントに詳細がある。

前提条件
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-gateway-install#prerequisites
Prerequisites
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-gateway-install#prerequisites

サインインが要求されるので、On-premises Data Gatewayを利用するメールアドレスを入力する。

メールアドレスの登録が完了すると、ゲートウェイ名、回復キー、リージョンの指定画面に遷移する。すでにゲートウェイクラスターを構成している場合にはチェックを入れておく。

リージョン設定の画面。推奨リージョンはWest Central US(米国中西部)で、このリージョンであればすべてのサービスへのゲートウェイとして利用できる。これ以外のリージョンを選択すると、Azureに含まないサービスのためのゲートウェイとして利用できない。 また、インストール後のリージョン変更は結構手間なので注意。 もし変更する場合には以下を参照。

場所の変更、または既存のゲートウェイの移行、復元、引き継ぎ
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-gateway-install#change-location-migrate-restore-or-take-over-existing-gateway
Change location, migrate, restore, or take over existing gateway
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-gateway-install#change-location-migrate-restore-or-take-over-existing-gateway

West Central USの場合
West Central US以外(ここではJapan East)を選択した場合には警告メッセージが出る。

[実行済み]をクリックし、構成を進めると以下の画面に到達する(今回はゲートウェイ名としてlocal-gwを設定)。東日本リージョンを指定しているので、Azureのサービス以外は使えないことがわかる。[閉じる]でインストールを完了する。

[ネットワーク]を見ると、TCPではなくHTTPSでの接続が有効になっている。これは2019年6月のリリースから、(更新ではなく)新規インストールの場合にはHTTPSがデフォルトになっているため(それまではTCPがデフォルトだった)。Service Busとの接続を考慮し、TCPに変更せずにそのままHTTPSを使うことを推奨する。

この変更は以下に記載がある(日本語ドキュメントは未反映)。

Forcing HTTPS communication with Azure Service Bus
https://docs.microsoft.com/en-us/power-bi/service-gateway-onprem-indepth#forcing-https-communication-with-azure-service-bus

Azure側での構成

インストールしたOn-premises Data GatewayインスタンスをAzure側で認識し利用できるようにするために、リンクを張っておく必要がある。詳細の手順は以下のURLを参照。

ゲートウェイ用の Azure リソースの作成
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-gateway-connection#create-azure-resource-for-gateway
Create Azure resource for gateway
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-gateway-connection#create-azure-resource-for-gateway

ロジックアプリの作成

特に通常の場合と違いはないが、On-premises Data Gatewayを利用する際にAPI接続を作成する。作成例は以下のURLを参照(これはSQL Serverの例)。個別のコネクタごとに設定方法が異なるので、コネクタ固有の設定はドキュメントを参照すること。

オンプレミスデータに接続する
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-gateway-connection#connect-to-on-premises-data
Connect to on-premises data
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-gateway-connection#connect-to-on-premises-data

API接続の編集

前項で作成したAPI接続は、後から設定を変更できる。詳細は以下。

接続の編集
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-gateway-connection#edit-connection
Edit Connection
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-gateway-connection#edit-connection

Logic Apps で EDI

このエントリは2019/06/14現在の情報に基づいています。将来の機能追加・廃止に伴い、記述内容との齟齬が発生する可能性があります。

関連エントリ

EDIを簡単に試すには

AS2での送受信ならびにMDN送信のサンプルがテンプレートとして公開されている。

Azure Logic Apps – AS2 Send Receive
https://github.com/Azure/azure-quickstart-templates/tree/master/201-logic-app-as2-send-receive

統合アカウント (Integration Account)

統合アカウントは、スキーマ、パートナー(取引先、トレーディングパートナー)、証明書、マップ、契約(アグリーメント)などのアーティファクトをすべて格納するクラウドベースのコンテナーです。

概要:Azure Logic Apps での Enterprise Integration Pack を使用した B2B エンタープライズ統合シナリオ
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-enterprise-integration-overview

簡単に言うと、EDIで使う情報をまとめて管理するための箱。自社のEDI連携のために利用する場合、統合アカウントは1個あれば十分。複数の統合アカウントを作成することもできるため、サービスプロバイダーとしてシステムを提供したい場合にも対応可能。統合アカウントの作成方法は以下のURLを参照。

統合アカウントを作成する
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-enterprise-integration-create-integration-account#create-integration-account
Create integration account
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-enterprise-integration-create-integration-account#create-integration-account

統合アカウントとLogic Appsインスタンスの紐付けおよび解除

作成した統合アカウントはLogic Appsインスタンスに紐付けることで、ロジックアプリから統合アカウントを利用できるようになる。このとき、紐付ける対象のLogic Appsインスタンスと統合アカウントは同一リージョンに存在していなければならない(ISEの場合も同様)。

ロジック アプリにリンクする
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-enterprise-integration-create-integration-account#link-to-logic-app
Link to logic app
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-enterprise-integration-create-integration-account#link-to-logic-app

統合アカウントへの紐付けを解除するには、Azure Resource Explorerを使う。

ロジック アプリのリンクを解除する
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-enterprise-integration-create-integration-account#unlink-from-logic-app
Unlink from logic app
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-enterprise-integration-create-integration-account#unlink-from-logic-app

取引先(トレーディングパートナー)

取引先とは、EDIで送受信する相手のこと。追加・削除は統合アカウントの設定画面から。詳細は以下。

Azure Logic Apps と Enterprise Integration Pack の統合アカウントに対して取引先を追加する
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-enterprise-integration-partners
Add trading partners for integration accounts in Azure Logic Apps with Enterprise Integration Pack
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-enterprise-integration-partners

作成時にかならず修飾子(Descriptor)とその値を指定する必要があるが、後から変更できるので、仮の値で作成しておいてもよい。

修飾子には種々の選択肢があり、取引先作成後、他の修飾子を追加できる。また、ロジックアプリから利用できるメタデータも、取引先に付加できる。

証明書

B2B通信の機密性を確保する必要がある場合、統合アカウントに証明書を追加することで、B2B通信を保護できる。例えばAS2のメッセージ署名および暗号化が必要な場合に利用できる。契約作成時にメッセージ暗号化や署名時に利用する証明書を指定するため、契約作成前に登録しておくことを推奨。

証明書を使用して B2B メッセージをセキュリティで保護する
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-enterprise-integration-certificates
Secure B2B messages with certificates
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-enterprise-integration-certificates

契約(アグリーメント)

ホスト取引先および1つのリモート取引先の2つの取引先間におけるビジネス・トランザクションのタイプを定義するもの。具体的には、どんな伝送形式を使うのか、どんなフォーマットで送受信するのか、など定義する。ここで、送受信の起点はホスト取引先であることに注意。契約の作成・編集・削除方法は以下のURLを参照。

Azure Logic Apps および Enterprise Integration Pack を使用して取引先契約を作成して管理します
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-enterprise-integration-agreements
Create and manage trading partner agreements by using Azure Logic Apps and Enterprise Integration Pack
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-enterprise-integration-agreements

メッセージ署名、暗号化用途で指定する証明書は、統合アカウントの証明書に存在するものを使う。

スキーマ

EDIFACTやX12のメッセージをXML形式に変換(Translation)する、またその逆を実現するために利用。ドキュメントプロトコルのスキーマに制限はなく、EDIFACTやX12だけでなく、カスタムのスキーマを指定することも可能(例えばドキュメントプロトコルとしてCSVを採用している場合に、当該CSV形式に合わせたカスタムスキーマを作成する、など)。X12、EDIFACTのスキーマはBizTalk Servicesのものを利用できる。

Microsoft Azure BizTalk Services SDK Setup
https://www.microsoft.com/en-us/download/details.aspx?id=39087

ロジックアプリの作成

ロジックアプリの作成方法自体は通常と変わらない。基本的な流れは以下の通り。

  • トリガーの作成
    • 着信を待つ(リスニングする)場合は、HTTPをトリガーにする
    • その他、何らかのトリガーで動作するようにしておく(サンプルの場合、1時間毎のスケジュール起動)
  • トリガーの後のアクションは…
    • 着信の場合
      • メッセージ交換プロトコルのコネクタ(例:AS2コネクタ)を使ってメッセージをデコード
      • ドキュメントプロトコルとしてX12やEDIFACTを使っている場合、各々のメッセージをデコード
    • 発信の場合
      • ドキュメントプロトコルに併せて各々のメッセージをエンコード
      • メッセージ交換プロトコルのコネクタを使ってメッセージをエンコード
    • 必要であれば業務ロジックを追加する。カスタムロジックを実装したFunctionsを呼ぶもよし…
    • メッセージを送信。着信応答が必要な場合は応答を返信する(MDNを返す必要がある場合はMDNを作成)

詳細は以下のドキュメントを参照。

Azure Logic Apps と Enterprise Integration Pack で B2B データを受信する
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-enterprise-integration-b2b
Receive B2B data with Azure Logic Apps and Enterprise Integration Pack
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-enterprise-integration-b2b

Logic Apps の基本

このエントリは2019/06/11現在の情報に基づいています。将来の機能追加・廃止に伴い、記述内容との齟齬が発生する可能性があります。

関連エントリ

Logic Appsとは

Azure Logic Apps は、企業または組織の間でアプリ、データ、システム、サービスを統合する必要がある場合に、タスク、ビジネス プロセス、ワークフローのスケジュール設定、自動化、調整に役立つクラウド サービスです。 Logic Apps を使えば、クラウド、オンプレミス、その両方のどこにあるかを問わず、アプリの統合、データの統合、システムの統合、Enterprise Application Integration (EAI)、および企業間 (B2B) 通信が可能になるスケーラブルなソリューションを設計および構築する作業を簡略化できます。

Azure Logic Apps とは
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-overview

BizTalkオーケストレーションや他社製品やサービスで言うBPELのような、システムオーケストレーションのためのサービス。

できること

  • 各種コネクタ(他社でいうアダプタ)を使って、システムやサービスをつないでデータを連携できる
  • オンプレミスにあるシステムと連携する場合、On-premise Data Gatewayを使う(On-premise Data GatewayはPower BI、Microsoft Flow、PowerApps、Azure Analysis Servicesなどでも利用可能)
  • システム連携だけでなく、EDI接続も可能(AS2、EDIFACTなどに対応)で、EDIと業務システム間をシームレスに統合できる
  • 統合サービス環境 (Integration Services Environment、以下ISE) で専用環境を作成し、VNetで保護されたVMなどで動作するサービスを呼び出すことができる

On-premise Data Gateway
https://docs.microsoft.com/ja-jp/azure/logic-apps/logic-apps-gateway-install#gateway-cloud-service
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-gateway-install#gateway-cloud-service
統合サービス環境(ISE : Integration Service Environment)
https://logico-jp.io/2019/06/05/integration-service-environment/

注意

BPMN標準には準拠しておらず、BPMNに基づいたプロセスの記述、実行、ならびにBPMN形式でのエクスポート・インポートは不可。ヒューマンワークフローの機能は含まれていないため、ヒューマンワークフロー用途で利用するのは適していない。

コネクタ

種々のシステムと接続するためのコンポーネント。他社製品ではアダプタと呼ばれるもの。所望のコネクタが存在しない場合、カスタムコネクタを作成できる。コネクタには複数のカテゴリがあり、追加費用が発生するものもある。

マネージドAPIコネクタ

追加費用不要で利用可能なコネクタ。例えば、Azure Blob Storage、Office 365、Dynamics、Power BI、OneDrive、Salesforce、SharePoint Online などのクラウドサービスやテクノロジーコネクタが該当する。詳細は以下。

マネージド API コネクタ
https://docs.microsoft.com/ja-jp/azure/connectors/apis-list#managed-api-connectors
Managed API connectors
https://docs.microsoft.com/en-us/azure/connectors/apis-list#managed-api-connectors

オンプレミス コネクタ

オンプレミスシステムと連係するためのコネクタ。オンプレミス データ ゲートウェイのダウンロード、インストール、設定を行う必要がある。追加費用なしで利用可能。 詳細は以下。

オンプレミス コネクタ
https://docs.microsoft.com/ja-jp/azure/connectors/apis-list#on-premises-connectors
On-premises connectors
https://docs.microsoft.com/ja-jp/azure/connectors/apis-list#on-premises-connectors

エンタープライズ コネクタ

SAP、IBM MQ、IBM 3270 などの一部のエンタープライズシステムへのアクセス用コネクタで、 利用にあたっては別途費用が必要。詳細は以下。

エンタープライズ コネクタ
https://docs.microsoft.com/ja-jp/azure/connectors/apis-list#enterprise-connectors
Enterprise connectors
https://docs.microsoft.com/en-us/azure/connectors/apis-list#enterprise-connectors

統合アカウント コネクタ

EDIのためのコネクタで、利用にあたっては別途費用が必要。詳細は以下。

統合アカウント コネクタ
https://docs.microsoft.com/ja-jp/azure/connectors/apis-list#integration-account-connectors
Integration account connectors
https://docs.microsoft.com/en-us/azure/connectors/apis-list#integration-account-connectors

Azure Logic Apps のコネクタ
https://docs.microsoft.com/ja-jp/azure/connectors/apis-list
Connectors for Azure Logic Apps
https://docs.microsoft.com/en-us/azure/connectors/apis-list

Logic Appsアプリ間の呼び出し

Logic Appsで作成したアプリは別のアプリを呼び出すことができる。その際、相関を自動構成するしくみになっているので、同一アプリの別インスタンスからの呼び出しと入れ違いになることはなく、別途明示的に相関を構成する必要はない。相関IDについては以下を参照。非同期呼び出しについては別途記載予定。

Logic Appsの相関
https://logico-jp.io/2019/05/14/correlation-of-logic-apps/

統合サービス環境(ISE : Integration Service Environment)

このエントリは、2019/06/05現在の情報を基にした備忘録として記述しているものです。この中で、Logic Appsはインスタンス、ロジック アプリはLogic Appsインスタンスで作成したアプリケーションを指すものとします。

統合サービス環境 (ISE: Integration Service Environment) とは

Azureが提供する、Logic Appsの分離された (isolated) プライベートインスタンスを作成するための環境。App Service Environment (ASE) のLogic Apps版。2019年5月に一部のリージョンを除きGA(東・西日本リージョンでも利用可能)。

統合サービス環境 (ISE) を使用して、Azure Logic Apps から Azure Virtual Network リソースにアクセスする
https://docs.microsoft.com/ja-jp/azure/logic-apps/connect-virtual-network-vnet-isolated-environment-overview
Access to Azure Virtual Network resources from Azure Logic Apps by using integration service environments (ISEs)
https://docs.microsoft.com/en-us/azure/logic-apps/connect-virtual-network-vnet-isolated-environment-overview

メリット

  • ストレージなど、専用リソースを使えるため、Noisy Neighborの影響を受けなくてすむ
  • 仮想ネットワーク内のシステムや仮想ネットワークに接続されているシステムに直接アクセスできる(つまり、プライベート IP アドレスを利用して非公開でサービス リソースと通信できる)

ISEインスタンスの作り方

前提条件

ドキュメントに記載の通りだが、特に注意しておくべきは以下。

https://docs.microsoft.com/ja-jp/azure/logic-apps/connect-virtual-network-vnet-isolated-environment#prerequisites
https://docs.microsoft.com/en-us/azure/logic-apps/connect-virtual-network-vnet-isolated-environment#prerequisites

  • 仮想ネットワークがすでに存在していること(ISE作成時に仮想ネットワークが存在しないと作成ができない)。
  • 必要なサブネットを作成済みであること(各サブネットに32個のアドレスが必要なので、最低でも /27のサブネットが4個必要)。

所要時間

ドキュメントには最長2時間かかる可能性がある、との記述がある。実際に作成した際には80分ほど要したので、帰宅前に仕込むぐらいの気持ちのほうがよい。

利用可能なコネクター

ドキュメントは以下(2019/06/05現在日本語ドキュメントは英語版に追いついていないので、英語版のみ)。
https://docs.microsoft.com/en-us/azure/logic-apps/connect-virtual-network-vnet-isolated-environment-overview#difference

前提

When you create your logic app, you select your ISE as your app’s location, which gives your logic app direct access to your virtual network and the resources in that network.
ロジック アプリを作成するときにアプリの場所として ISE を選択すると、ロジック アプリは仮想ネットワークとそのネットワーク内のリソースに直接アクセスできるようになります。

https://docs.microsoft.com/en-us/azure/logic-apps/connect-virtual-network-vnet-isolated-environment-overview#isolated-versus-global
https://docs.microsoft.com/ja-jp/azure/logic-apps/connect-virtual-network-vnet-isolated-environment-overview#isolated-versus-global

グローバル(ISEではない)のLogic Appsで利用可能なビルトイン コネクターだけでなく、ISE内専用のコネクターも利用できる。コネクター選択時にわかるようになっている。

ロジック アプリが稼働するのと同じISE内で利用できるビルトイン トリガーやアクションには、Coreというラベルが付いている。

ISEで動作するコネクターには、グローバル利用可能なコネクターも存在する。

  • ISEのラベルが付いたもの:ロジック アプリと同じISE内で実行したい場合に利用
  • ISEラベルのないもの:グローバルのLogic Appsサービスで実行

オンプレミスのデータソースへのアクセス

仮想ネットワークに接続済みのオンプレミスシステムの場合、ISEを当該ネットワークに参加させると、ロジック アプリは以下のようなコネクターやアクションを使って、直接システム間での通信が可能。

  • ISEラベルの付いたコネクター(例:SQL Server)
  • HTTPアクション
  • カスタムコネクター
    • On-premise Data Gatewayが必要であれば、ISEの外でコネクターを作成すると、ISE内のロジック アプリはこれらのコネクターを利用可能
    • ISE内で作成されたカスタムコネクターは、On-premise Data Gatewayを使った接続はできないが、ISEがホストされている仮想ネットワークに接続されているオンプレミスのデータソースに直接アクセス可能なので、ISE内のロジック アプリの場合、通常はOn-premise Data Gatewayを必要としない。

当然ながら、仮想ネットワークに接続していないオンプレミスシステムや、ISE版のコネクターがないオンプレミスシステムの場合、On-premise Data Gatewayを構成する必要がある。

Integration Account (統合アカウント)

統合アカウントは、EDIアーティファクト(トレーディングパートナー、アグリーメント、マップ、スキーマ、証明書など)を作成・格納・管理するために利用する。ロジック アプリがLogic Apps B2Bコネクターを使う場合には、ロジック アプリに統合アカウントを紐付ける必要がある。

注意点

統合アカウントはISE内でも利用可能だが、以下の注意点がある。

ISE内のロジック アプリは、実行環境であるISEに紐付けられた統合アカウントしか参照できないため、統合アカウントはLogic Appsと同じISEを使わなければならない。

これはグローバルのロジック アプリでも同様で、以下のような注意書きがドキュメントに存在する。

Your integration account and logic app must exist in the same region.
統合アカウントとロジック アプリは同じリージョン内にあることが必要です。

https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-enterprise-integration-create-integration-account#link-to-logic-app

環境のスケールアウト

スループットが必要であれば、スケールユニットを追加可能(自動スケールも可能)。メトリックに基づくスケール、特定インスタンス数へのスケールを設定できる。

設定>スケールアウト>自動スケーリングの有効化

その後、自動スケールのルールを設定する。

ドキュメントは以下から。

https://docs.microsoft.com/ja-jp/azure/logic-apps/connect-virtual-network-vnet-isolated-environment#add-ise-capacity
https://docs.microsoft.com/en-us/azure/logic-apps/connect-virtual-network-vnet-isolated-environment#add-ise-capacity