BizTalk Server から Azure Logic Apps に移行する理由

このガイドでは、BizTalk Server から Azure Logic Apps への移行を開始するのに役立つ理由と利点、機能、およびその他の情報の概要について説明します。 このガイドに従って、成功した結果を得るために役立つ移行戦略、計画に関する考慮事項、ベスト プラクティスに関するその他のガイドを紹介します。

理由と利点

統合ワークロードを Azure Logic Apps に移行すると、主に次のような利点があります。

BizTalk Server のしくみ

BizTalk Server の中核として使われているのは、MessageBox データベースによるパブリッシュ サブスクライブ メッセージング エンジン アーキテクチャです。 MessageBox は、メッセージ、メッセージのプロパティ、サブスクリプション、オーケストレーション状態、追跡データ、その他の情報を格納する役割を担います。

BizTalk Server がメッセージを受信すると、サーバーはパイプラインを介してメッセージを渡して処理します。 このステップでは、メッセージが正規化されて MessageBox に発行されます。 その後、BizTalk Server は既存のサブスクリプションを評価し、メッセージ コンテキストプロパティに基づいてメッセージで意図されている受信者を決定します。 最後に、BizTalk Server は、サブスクリプションまたはフィルターに基づいて、意図されている受信者にメッセージをルーティングします。 この受信者はオーケストレーションまたは送信ポートのいずれかであり、BizTalk Server がメッセージを送信する宛先、または BizTalk Server がメッセージを受信できる送信元です。 BizTalk Server は、送信パイプラインを通してメッセージを渡すことにより、送信ポートを介してメッセージを送信します。 送信パイプラインは、アダプターを通じてメッセージを送信する前に、受信側が予期するネイティブ形式にメッセージをシリアル化します。

MessageBox データベースには、次のコンポーネントがあります。

• メッセージング エージェント

  BizTalk Server が MessageBox との対話に使用するこのエージェントは、メッセージの発行、メッセージのサブスクライブ、メッセージの取得などのためのインターフェイスを提供します。

• 1 つ以上の SQL Server データベース

  これらのデータベースにより、メッセージ、メッセージのパーツ、メッセージのプロパティ、サブスクリプション、オーケストレーションの状態、追跡データ、ルーティング用のホスト キューなどのための永続的なストアが提供されます。

次の図は、BizTalk Server メッセージング エンジンのしくみを示しています。

受信ポートがメッセージを受信した後、MessageBox は、ビジネス プロセスによる処理のため、または特定のメッセージへのサブスクリプションを持つ送信ポートにルーティングするために、そのメッセージを格納します。

詳しくは、後の「パブリッシュ サブスクライブ アーキテクチャ」をご覧ください。

Azure Logic Apps: BizTalk の後継

Azure Logic Apps は、Microsoft のエンタープライズ レベルのワークフロー オーケストレーションと統合プラットフォームです。 このプラットフォームは、クラウド環境とハイブリッド環境全体で確定的で実行時間の長いステートフル プロセス用に設計されています。 重要な差別化要因は、低コードのビジュアル ワークフローと、セキュリティ、ID、ネットワーク、監視、ガバナンスなどのファースト クラスの Azure プラットフォーム機能を組み合わせたものです。 Azure Logic Apps では、複数のデプロイ モデル (従量課金、標準、ハイブリッド) がサポートされています。このモデルを使用すると、信頼性、状態管理、監査可能な実行を維持しながら、Azure またはオンプレミス システムの近くで完全に管理されたワークフローを実行できます。 この柔軟性により、プラットフォームは、BizTalk Server 資産の最新化、B2B/EDI 統合の調整、SaaS、ERP、CRM、および従来のシステムの接続のための自然なバックボーンになります。この場合、持続性と可観測性は否定できません。

ただし、Azure Logic Apps は単に "ローコード" ではありません。 お客様は、インライン C#、JavaScript、PowerShell、Azure Logic Apps で実行されるローカル関数を使用したカスタム コード、カスタム コネクタなどのビジュアル ワークフローと共に、プロコードの拡張性を日常的に使用しています。 この拡張性により、チームはワークフロー モデルを壊すことなく、複雑なビジネス ロジック、変換、プロトコル処理、検証をオーケストレーション内に直接埋め込むことができます。 クレーム処理、オンボード、コンプライアンス パイプライン、メインフレーム、医療統合などの実際のシナリオでは、お客様は、決定論的オーケストレーションとカスタム コードを組み合わせた制御された実行レイヤーとして機能し、ガバナンス、セキュリティ、運用上の信頼性を大規模に維持しながら、ますます AI 支援の意思決定を行う Azure Logic Apps に依存しています。

Azure Logic Apps では、ビジュアル デザイナーでプログラミングを行う "構成要素" の方法と、数百のコネクタからの事前構築済み操作を使用して、ロジック アプリ ワークフローとして実行可能なビジネス プロセスとアプリケーションを作成できます。最小限のコードを必要とします。 ロジック アプリ ワークフローは、トリガー操作で始まり、その後に 1 つ以上のアクション操作が続き、各操作はワークフロー実装プロセスの 1 つの論理ステップとして機能します。 ワークフローでは、アクションを使って外部のソフトウェア、サービス、システムを呼び出すことができます。 一部のアクションは、条件、ループ、データ操作、変数管理などのプログラミング タスクを実行します。

Azure Logic Apps には、次の例のような利点があります。

• デザイナー第一 (宣言型)

  わかりやすい設計ツールを使って複雑なプロセスを設計し、他の方法ではコードで実装するのが難しいパターンやワークフローを実装します。

• コード優先開発

  Visual Studio Code を使用して包括的なコード ベースのソリューションを作成し、既存の従来の .NET Framework コードを再利用し、最新の .NET バージョンを組み込むことができます。

• 柔軟でスケーラブル

  Azure Logic Apps は、進化するビジネス ニーズに合わせて自動的にスケーリングおよび適応する、クラウドベースのサーバーレスで拡張性の高いコンピューティング サービスです。

開発者エクスペリエンス

このセクションでは、BizTalk Server (Visual Studio 中心) から Azure Logic Apps (Visual Studio Code 中心) に移行するときに開発ツールがどのように変化するか、および多くのチームが Azure Logic Apps ワークフロー モデルをより迅速に構築して保守しやすくする理由について説明します。

• ツールとオーサリング モデル

  BizTalk では、日常の統合作業が Visual Studio で行われ、スキーマ、マップ、オーケストレーション、パイプラインなどの複数の成果物の種類に加えて、共有サーバー環境への展開パッケージ (MSI/バインド) に分散されます。

  Azure Logic Apps では、多くのチームが Visual Studio Code に移行し、ソリューションの複雑さを軽減し、より小さな増分変更を促進する、よりシンプルな "ワークフロー + コネクタ" アプローチを使用してワークフロー定義と関連ファイルを編集します。 実際には、Visual Studio Code は通常、BizTalk と Visual Studio のバージョンの配置を維持するよりも、チーム間でインストール、更新、標準化を行う方が高速です。 テキストベースのワークフロー定義では、大規模なコンパイル済みの BizTalk ソリューションと比較して、Git の差分とマージ、コード レビュー、再利用が向上する傾向があります。

• Azure Logic Apps への移行を改善する方法

  Azure Logic Apps では、Visual Studio Code ベースの開発とクラウド ネイティブの診断がペアになります。 ワークフローをすばやく検証して更新し、ワークフロー実行履歴を使用して、サーバー側のコンソールやホスト インスタンスのトラブルシューティングに依存することなく、操作の入力と出力を表示できます。 移行プロジェクトでは、この利点により、通常、イテレーション (編集、デプロイ、更新、検証) が高速化され、ワークフローの確認とバージョン管理が容易になり、接続と設定を外部化することで環境の分離がクリーンになり、"そのサーバーで動作する" 構成の誤差が軽減されるため、コラボレーションが向上します。

Connectors

コネクタは、ワークフローのステップとして使用できる操作を提供します。 Azure Logic Apps を使用してワークフローを構築する場合、コネクタを使用すると、多くの場合、コードを記述することなく、アプリ、サービス、システム、プロトコル、プラットフォーム全体でデータ、イベント、およびリソースを操作できます。 BizTalk Server、Salesforce、Office 365、IBM メインフレーム、SQL データベース、Azure Functions、Azure Storage、Azure Service Bus などの多くの Azure サービス、オンプレミス アプリ、SaaS、API など、Microsoft とパートナーの両方のサービスとシステムの統合ソリューションを構築できます。 アクセスするリソースに対して事前構築済みのコネクタが存在しない場合は、汎用 HTTP 操作を使用してサービスと通信するか、カスタム コネクタを作成できます。

技術的には、コネクタは、基になるサービスまたはシステムが Azure Logic Apps との通信に使用する API のプロキシまたはラッパーです。 コネクタは、Azure Logic Apps での接続機能を備え、基になる SaaS システムによって通常所有される API の上位の抽象化を提供します。 これらの API を簡単に呼び出せるよう、コネクタではメタデータを使ってメッセージング コントラクトが記述されており、開発者は要求と応答で期待されるデータを把握できます。 その後、コネクタは、構成可能なプロパティを持つトリガーまたはアクションとして操作を公開します。 一部のトリガーとアクションでは、まず、基になるサービスまたはシステムへの接続を作成して構成し、ユーザー アカウントへのアクセスを認証する必要があります。

Azure Logic Apps のほとんどのコネクタは、組み込みまたは管理されています。 一部のコネクタは両方のバージョンで使用でき、可用性は従量課金ロジック アプリワークフローと Standard ロジック アプリ ワークフローのどちらを作成するかによって異なります。 BizTalk Server の移行シナリオでは、標準レベルで BizTalk 移行機能を使用できるため、標準ロジック アプリ ワークフローをお勧めします。

多くの BizTalk 移行では、選択したコネクタは、オンプレミス接続、SFTP などのファイル転送、メッセージング システム、基幹業務システムなどの一般的な統合要件によって駆動されます。

• 組み込みコネクタは、Azure Logic Apps ランタイムでネイティブに実行されます。 マネージド コネクタと比較して、組み込みのコネクタは通常、待機時間を短縮し、コネクタとシナリオに応じて、マネージド コネクタ サービスへの接続ごとの呼び出しを回避します。

• マネージド コネクタは、Microsoft によって Azure でデプロイ、ホスト、管理されます。 これらのコネクタにより、クラウドサービス、オンプレミス システム、またはその両方に対してトリガーとアクションが提供されます。

デザイナーのコネクタ ギャラリーでは、組み込みコネクタが 組み込みラベルの下に 表示され、マネージド コネクタは 共有 ラベルの下に表示されます。 従量課金ロジック アプリ ワークフローの場合、マネージド コネクタは Standard または Enterprise の価格モデルに従います。

• カスタム コネクタを使用すると、事前構築済みのコネクタが存在しない場合に、一般的に OPENAPI 定義または SOAP API を使用して WSDL を使用して REST API をラップできます。 使用する API 用の事前構築済みコネクタが存在しない場合は、カスタム コネクタを作成し、適切なアクセス許可を持つロジック アプリ ワークフローからそのコネクタにアクセスできます。

REST API の場合、通常は OpenAPI 定義を使用して API を記述します。 SOAP API の場合は、WSDL を使用します。 カスタム コネクタは、Azure Logic Apps と API の間にコントラクトを作成します。これは、要求メッセージをアセンブルし、ダウンストリーム アクションで使用できる型指定された応答を受信するのに役立ちます。 カスタム コネクタは、パブリック API またはプライベート API (ローカル ネットワーク上の API を含む) を参照できます。

カスタム コネクタを実装する場合は、要求を送信し、型指定された応答を受信するための共通インターフェイスを提供します。これにより、開発エクスペリエンスが簡素化されます。

詳細については、以下を参照してください。

• 組み込みコネクタの概要
• マネージド コネクタの概要
• Azure Logic Apps で使用できるマネージド コネクタ
• カスタム コネクタと API

データの整形と成果物

統合を Azure Logic Apps に移行する場合、通常は次のものが必要です。

• ワークフロー内のデータ 整形 (解析、作成、マッピングなど)。

• スキーマ、マップ、テンプレート、アセンブリなどの再利用可能な成果物を格納およびデプロイするための明確な戦略。

次のセクションでは、変換の主な組み込みオプションと、Standard ワークフローと共有 B2B シナリオのサポート成果物を格納するための一般的な場所についてまとめます。

• ワークフローでのデータ シェイプ: データ操作、式、Liquid テンプレート

  ロジック アプリ ワークフローのほとんどの JSON 変換では、JSON の作成アクションや解析アクションなどの組み込みのデータ操作を、条件やループなどの式やワークフロー コントロール アクションと共に使用してデータを整形します。 より高度なマッピング シナリオでは、特に JSON から JSON、JSON からテキストへの変換、XML から JSON、XML からテキストへの変換などの再利用可能なテンプレートが必要な場合は、Liquid テンプレートを使用できます。 Liquid テンプレートは、オープンソースの Liquid テンプレート言語を使用してマッピングを記述します。 テンプレートは、ワークフローと共に成果物としてバージョン管理およびデプロイできます。

• スキーマ ベースの XML 操作: XML の解析と XML の作成

  ロジック アプリ ワークフローでの XML の作成と検証のシナリオでは、スキーマを含む XML の作成やスキーマ アクションによる XML の解析 などの組み込みの XML 操作を使用できます。 これらのアクションは、ペイロードをプレーン テキストとして扱うのではなく、厳密に型指定された XML 処理 (XSD ベース) が必要な場合に最も役立ちます。 たとえば、複数のワークフロー間で一貫した要素名、データ型、構造が必要です。

• 標準ロジック アプリに成果物を格納する

  Standard ロジック アプリ ワークフローの場合は、ロジック アプリ リソース自体に統合成果物を格納できます。 Azure portal では、マップとスキーマを Standard ロジック アプリ リソースに直接アップロードできます。 Visual Studio Code で作業している場合は、プロジェクトの Artifacts ディレクトリの下にある適切なフォルダーにスキーマ、マップ、テンプレートを追加し、ワークフローと共に配置できます。 この機能により、成果物をソース管理に保持しやすくなります。

  標準ワークフローでは、XSLT マップからの .NET Framework アセンブリなどのカスタム コンパイル アセンブリの呼び出しがサポートされています。 このサポートは、既存の変換ロジックに依存する BizTalk 移行シナリオに役立ちます。

• 統合アカウントに共有 B2B 成果物を格納する

  統合アカウントは、複数のワークフローで共有できる再利用可能な B2B と統合成果物への一元的なアクセスを提供する Azure リソースです。 成果物には、取引先、契約、XSD スキーマ、XSLT マップ、Liquid テンプレート ベースのマップ、証明書、バッチ構成、および .NET Framework アセンブリを含めることができます。

  B2B/EDI シナリオでは、統合アカウントを一般的に使用します。このシナリオでは、1 つのワークフローとは別に、管理された共有成果物ストアが必要です。 Standard ワークフローの場合、多くの場合、スキーマ、マップ、テンプレートを Standard ロジック アプリ プロジェクトにパッケージ化し、それらを一緒にデプロイすることで、統合アカウントを回避できます。 標準ワークフローでは 、XSLT 変換からの .NET Framework アセンブリの呼び出しもサポートされています。これは、既存の BizTalk マップとヘルパー ライブラリを移植するときに役立ちます。 プロジェクト ベースのアプローチを使用する場合は、Visual Studio Code でスキーマ、マップ、アセンブリを追加し、Azure にデプロイします。

• EDI スキーマ: B2B 統合用の特殊化された XSD 成果物

  EDI ドキュメント スキーマは、EDI トランザクション ドキュメントの種類の構造または本文を定義します。 BizTalk 移行プロジェクトでは、多くの場合、チームは同じ XSD 定義を再利用してから、取引先固有のバリエーションを繰り返し検証します。 Azure Logic Apps のワークフローでは、 Microsoft Integration GitHub リポジトリ の多くの BizTalk EDI スキーマを一般公開しています。 実装アプローチに基づいて、これらのスキーマを Standard ロジック アプリと共にプロジェクト成果物として格納することも、複数のワークフロー間で再利用するために統合アカウントに一元的に格納することもできます。

Connectivity

Azure Logic Apps と BizTalk Server で接続モデルが異なる理由の一部は、API 経済の進化によるものです。 基になるシステムとデータへのアクセスを公開する組織が増えるにつれて、プラットフォームに依存しないアプローチが必要になりました。 現在では、REST が最新の Web サービスを設計するための主要なアーキテクチャ アプローチです。

Azure Logic Apps では、REST がシステムを接続するための既定のアプローチです。 Microsoft や他のソフトウェア ベンダーにより、システムとデータを基にして RESTful サービスが公開されているので、Azure Logic Apps ではこの種類の情報を公開して使用できます。 OpenAPI 仕様を使うと、人間とコンピューターの両方が、メタデータを介したクライアントとサーバー間の相互作用を理解できます。 この理解の一環として、要求ペイロードと応答ペイロードの両方が派生します。つまり、動的コンテンツを使ってワークフロー アクションの入力を設定し、ダウンストリーム アクションで応答からの出力を使用できます。

コネクタが呼び出す基盤サービスを実装するソフトウェア ベンダーに応じて、コネクタにより認証スキームは異なります。 一般に、これらのスキームには次の種類が含まれます。

• 基本的な
• クライアント証明書
• Active Directory OAuth
• Raw
• マネージド ID

Microsoft は、保存時と転送中にデータを暗号化することで、強力な保護レイヤーを提供します。 Azure のお客様のトラフィックが、Microsoft または Microsoft の代理によって制御されない物理的境界の外側のデータセンター間を移動するときは、IEEE 802.1AE MAC Security Standards (MACsec) を使用するデータリンク層の暗号化方法が、基になるネットワーク ハードウェアのポイント間で適用されます。

Microsoftは、クラウド サービスとお客様の間を移動するデータを保護するためにトランスポート層セキュリティ (TLS) プロトコルを使用するオプションを提供します。 Microsoft のデータ センターは、Azure サービスに接続するクライアント システムとの TLS 接続をネゴシエートします。 TLS は、強力な認証、メッセージの機密性、整合性 (メッセージの改ざん、傍受、偽造を検出できます) と共に、相互運用性、アルゴリズムの柔軟性、デプロイと使用のしやすさを備えています。

このセクションでは主にコネクタを使用する RESTful 接続について述べていますが、SOAP の重要機能を備えたカスタムのコネクタ エクスペリエンスか API Management エクスペリエンスを使用することによって、SOAP Web サービス接続を実装できます。 詳細については、「 SOAP レガシ資産と Azure Logic Apps と Azure API Management を統合してビジネス価値を高める」を参照してください。

メッセージの持続性

Azure Logic Apps では、次の方法でメッセージの持続性が提供されます。

• Standard ロジック アプリのステートフル ワークフローは、チェックポイントを使用してワークフローの状態と操作の入力と出力をストレージに保持します。 この永続化により、永続的な実行と豊富なワークフロー実行履歴が提供されるため、詳細な操作の入力と出力を確認できます。

• Azure portal または API を使用して、ワークフロー実行を 再送信 または再実行できます。

  再送信によってワークフローが同じメッセージを再処理する可能性があるため、必ず設計段階で少なくとも 1 回の処理を想定し、べき等性を実装してください。 たとえば、重複除去キー、アップサート、または宛先側での厳密に 1 回だけの効果を使用します。

  ワークフローの種類と構成に基づいて、実行の特定のポイントから再送信することもできます。 ただし、ダウンストリーム システムが再試行と重複の可能性を安全に処理できることを確認してください。

• Azure Service Bus の ピーク ロック メッセージング を使用すると、受信者はメッセージを処理し、そのメッセージを明示的に解決できます。 たとえば、受信者はメッセージを完了してからキューから削除できます。または、受信者はメッセージを破棄して再配信できるようにします。

  Azure Logic Apps でこの機能を使用するには、Azure Service Bus コネクタを使用します。 ピーク ロック モードでは信頼性が向上し、再試行または再配信パターンがサポートされます。 ただし、エンドツーエンド処理で厳密に一度だけの処理を行うには、通常、ダウンストリームシステムで冪等性が必要です。

• RabbitMQ では、一般的に持続性を実現するには、永続的なキューを使用するか、永続的なメッセージと交換し、コンシューマーの受信確認に依存して、受信確認を送信する前に処理が失敗した場合にシステムがメッセージを再配信できるようにします。 RabbitMQ コネクタを使用して統合する場合は、他のブローカーと同じ設計原則を適用してください。再試行や重複の可能性を考慮し、ダウンストリーム処理を冪等性にするようにしてください。

• IBM MQ では、通常、永続メッセージとトランザクション処理 (作業単位) を使用して持続性と信頼性の高い配信に対処できます。 その後、受信したメッセージをコミットまたはロールバックし、ダウンストリームの作業を一緒に行うことができます。 作業がコミットされる前にエラーが発生した場合、またはメッセージが確認された場合、メッセージは再配信可能になる可能性があります。

  IBM MQ コネクタを使用する場合は、少なくとも 1 回の配信を設計し、宛先で重複する可能性を処理します。 BizTalk の移行シナリオでは、このパターンは通常、安全な再処理のためにロジック アプリ ワークフローやダウンストリーム エンドポイントを設計することに対応します。たとえば、エンド ツー エンドでの厳密に 1 回だけの動作をブローカーのみに依存するのではなく、相関識別子、重複除去、べき等書き込みなどを使用した設計です。

パブリッシュ サブスクライブ アーキテクチャ

Azure Logic Apps は、BizTalk Server メッセージング エンジンと比較して、コネクタと外部メッセージング サービスを使用して、ワークフロー オーケストレーションと共にメッセージング パターンを実装します。 Azure Logic Apps でのパブリッシュ/サブスクライブ (pub-sub) パターンの場合、一般的なブローカー オプションには、Azure Service Bus (トピックとサブスクリプション) と RabbitMQ が含まれます。 Azure Service Bus は、アプリケーションとサービスを切り離すために使用できるキューと pub-sub トピックを備えたフル マネージドのエンタープライズ メッセージ ブローカーです。次の利点があります。

• 競合する worker 間で処理を負荷分散します。
• サービスとアプリケーションの境界を越えた制御により、データを安全にルーティングおよび転送します。
• 高い信頼性を必要とするトランザクションの作業を調整します。

Azure Logic Apps には、メッセージへのパブリッシュとサブスクライブを行う際に使用できる Azure Service Bus コネクタが含まれています。 ワークフローから独立してメッセージングを使用できるという利点があります。 BizTalk Server とは異なり、メッセージングはワークフロー エンジンから切り離されます。 Azure Service Bus でメッセージ サブスクリプションを作成し、トピック サブスクリプションのフィルターによって評価されるキーと値のペアとしてメッセージ プロパティ (ユーザー プロパティ) を使用できます。 これらのユーザー プロパティは、Azure Service Bus 操作を設定するときに、1 つ以上のキーと値のペアを追加することによって定義します。 デモについては、 ビデオ「Azure Integration Services を使用した Pub Sub Messaging - パート 2 コンテンツ ベースのルーティング」を参照してください。

標準ワークフローを備えた Azure Logic Apps には、メッセージの送受信に使用できる RabbitMQ 組み込みコネクタも含まれています。 RabbitMQ では、通常、交換に発行することで pub-sub パターンを実装し、複数のコンシューマーが、その交換にバインドされた個別のキュー (多くの場合、交換の種類に基づくルーティング キーまたはヘッダーベースのルーティングを使用して) を介してメッセージを受信するようにします。 このアプローチでは、Service Bus のトピックやサブスクリプション ルールに似たファンアウトとルーティングベースの配布パターンがサポートされますが、RabbitMQ の交換、バインド、キューの設定を使用して構成されています。 RabbitMQ は、多くの場合、既存のオンプレミスの RabbitMQ 資産がある場合、Azure Service Bus が利用できない環境でブローカー機能が必要な場合、またはプロデューサーとコンシューマーが実行されるネットワークに対してローカルなメッセージングを維持する場合に、強力なオプションです。 ブローカーベースの統合と同様に、再試行と重複の可能性を考慮して設計します。たとえば、必要に応じて受信確認、永続的なキュー、永続的なメッセージを使用し、ダウンストリーム処理をべき等にします。

多くの BizTalk 移行プロジェクトでは、Azure Service Bus がクラウドネイティブ pub-sub の一般的な既定の選択肢です。これは、サービスがフル マネージドであり、組み込みのトピックとサブスクリプションセマンティクスをフィルター処理で提供するためです。 オンプレミスの pub-sub 要件の場合、RabbitMQ は、特に Azure Logic Apps ハイブリッド デプロイ モデルに適しています。これは、Azure Service Bus はクラウド サービスであり、オンプレミスのデプロイ オプションがないためです。 このような場合は、持続性と再試行セマンティクスを標準化し、ワークフローとエンドポイントの境界でべき等性を適用します。

ビジネス ルール エンジン

Azure Logic Apps には、 Azure Logic Apps ルール エンジンが含まれています。 このルール エンジンには BizTalk ビジネス ルール エンジン (BRE) ランタイムが含まれているため、既存の BizTalk BRE ポリシーを再利用できます。 現在、サポートは XML と .NET Framework のファクトに対してのみ存在します。

ネットワーク

受信接続と送信接続の場合、Azure には、ネットワーク境界内でサービスを分離し、オンプレミスとクラウドのワークロードに接続するための複数の方法が用意されています。 次の一覧では、Azure リソースとネットワーク境界内のリソースを統合できるさまざまな方法について説明します。

• ハイブリッド接続

  Azure サービスと Azure App Service の機能の両方で、ハイブリッド接続はシナリオをサポートし、Azure App Service 以外の機能を提供します。 Azure App Service の外部での使用について詳しくは、Azure Relay ハイブリッド接続に関する記事をご覧ください。 Azure App Service では、ハイブリッド接続を使用して、ポート 443 経由で Azure への発信呼び出しを行うことができる任意のネットワーク内のアプリケーション リソースにアクセスできます。 ハイブリッド接続では、アプリから TCP エンドポイントへのアクセスが提供され、アプリにアクセスするための新しい方法は有効になりません。 Azure App Service では、各ハイブリッド接続は、単一の TCP ホストとポートの組み合わせに関連付けられます。 この機能により、TCP エンドポイントが存在する限り、任意の OS 上のリソースにアプリからアクセスできます。 ハイブリッド接続では、アプリケーション プロトコルやアクセス先は認識されず、考慮されません。 この機能では、ネットワーク アクセスだけが提供されます。

• 仮想ネットワークの統合

  Azure Virtual Network 統合を使うと、Azure で構成されている仮想ネットワークに Azure リソースを接続でき、アプリでその仮想ネットワーク内のリソースにアクセスできます。 Azure Logic Apps での仮想ネットワーク統合は、Azure リソースから仮想ネットワークへのアウトバウンド呼び出しを行うためにのみ使われます。

  仮想ネットワーク ピアリングを使うと、オンプレミスのネットワークを Azure に接続でき、オンプレミスのリソースと Azure サービスの間の双方向接続が提供されます。 Azure Integration Services は仮想ネットワーク接続を提供し、ハイブリッド統合を可能にします。

  次の図では、Standard ロジック アプリ リソースの [ネットワーク] ページが開かれ、[Outbound Traffic] (アウトバウンド トラフィック) ボックスで強調されているように、仮想ネットワーク統合が有効になっています。 この構成により、すべてのアウトバウンド トラフィックがこの仮想ネットワークから送信されます。

  

• プライベート エンドポイント

  "プライベート エンドポイント" は、仮想ネットワークのプライベート IP アドレスを使用するネットワーク インターフェイスです。 このネットワーク インターフェイスは、Azure Private Link を利用する Azure リソースに、非公開で安全に接続します。 プライベート エンドポイントを有効にすることで、その Azure リソースが仮想ネットワークに取り込まれ、ネットワーク内のリソースで Azure リソースへのインバウンド呼び出しを行えるようになります。

カスタム コード

Azure Logic Apps では、標準ロジック アプリ ワークフローで .NET コードを作成して実行できます。 これを行うには、Visual Studio Code と Azure Logic Apps (Standard) 拡張機能を使用する必要があります。

インライン コード操作コネクタには、JavaScript コードの実行、CSharp スクリプト コードの実行、PowerShell コードの実行という名前のアクションが用意されています。 これらのアクションを使用して、動的なコンテンツの入力と出力をサポートするコードを追加できます。 Azure Logic Apps エンジンでは、このコードの実行時間が短くなります。 コードの実行が完了すると、ダウンストリーム アクションがワークフローで使用できるようになります。

前述のように、XSLT マップから .NET Framework アセンブリを呼び出すサポートは、現在、統合アカウントにそれらのアセンブリをアップロードするときにロジック アプリ ワークフローで使用できます。 この機能は、カスタム データ変換ルールをサポートするのに役立ちます。 Standard ロジック アプリ ワークフローの場合、統合アカウントなしで XSLT マップから .NET Framework コードを呼び出すことができます。 また、Visual Studio Code でアセンブリとマップを Standard ロジック アプリ プロジェクトに追加した後、Azure にデプロイすることもできます。 詳細については、 Azure Logic Apps (Standard) XSLT 変換に追加された .NET Framework アセンブリのサポートに関するページを参照してください。

アプリケーション グループ

Azure Logic Apps では、Standard ロジック アプリ リソースに複数のワークフローを含め、実行することで、1 対多のリレーションシップを実現できます。 ローカル環境の Visual Studio Code で Standard ロジック アプリ プロジェクトの作業を行っている場合、ロジック アプリ リソースはこの 1 つのプロジェクトにマップされます。 この方法を使うと、関連するワークロード、コード、成果物を同じプロジェクトに簡単かつ論理的にグループ化し、そのプロジェクトを 1 つのユニットとしてデプロイできます。

クラウド アーキテクチャの動作は、BizTalk などのサーバー ベースのパラダイムとは異なります。 Azure Logic Apps (Standard) では、コードと成果物を取り込むためにプル モデルが使われます。 その結果、追加の必要な成果物をプロジェクトにコピーし、その後、コードやその他の成果物と共にデプロイします。 場合によっては、必要なコードと成果物をコピーする必要がないようにしたい場合があります。 その場合は、個別に管理できるが、ワークフローから呼び出すことができるサービスに、この機能を変換することを検討できます。

たとえば、組織で広く使われているデータ変換があるとします。 複数のロジック アプリ プロジェクトに変換のマップを含めるのではなく、変換をサービスとして提供するインターフェイスを実装できます。 その後は、そのサービスのライフサイクルをロジック アプリ プロジェクトとは別に管理し、ワークフローからそのサービスを呼び出すことができます。

Standard ロジック アプリ プロジェクトに複数のワークフローを含める機能では、1 つまたは複数のプロジェクトでそれらのワークフローを整理する方法を疑問に思う場合があります。 それに対する答えは、通常、要件によって異なります。次に例を示します。

• ビジネス プロセス アフィニティ
• エンド ツー エンドの監視とサポート
• セキュリティ、ロールベースのアクセス制御、ネットワークの分離
• パフォーマンスとビジネスの重要度
• 地理的な場所と geo 冗長性

詳しくは、Azure Logic Apps (Standard) でのロジック アプリ ワークフローの整理に関する記事をご覧ください。

セキュリティとガバナンス

Azure Logic Apps は、次のセキュリティ機能をサポートしています。

• Azure Key Vault

  Azure Key Vault を使って、資格情報、シークレット、API キー、証明書を格納できます。 Azure Logic Apps では、Azure Key Vault コネクタを使ってこの情報にアクセスでき、セキュリティ保護された入力と出力の機能を使って、プラットフォームのログと実行履歴からこの情報を除外できます。

  後の「追跡」セクションでは、ワークフローの実行を 1 ステップずつ再生する実行履歴機能について説明します。 Azure Logic Apps にはワークフロー実行でのすべての入力と出力をキャプチャする機能が用意されていますが、機密データへのアクセスをさらに細かく管理することが必要な場合があります。 トリガーとアクションでセキュリティ保護された入力と出力の機能を使って、このデータの難読化を設定して、そのようなコンテンツが実行履歴に表示されず、このデータが Azure Monitor (具体的には Log Analytics と Application Insights) に送信されないようにすることができます。 次の画像は、実行履歴でセキュリティ保護された入力とセキュリティ保護された出力を有効にした結果の例です。

  

• OAuth ベースの統合

  ほとんどのコネクタでは、接続を作成するときにこの認証の種類が使われます。 この方法を使うと、メール アドレスとパスワードを指定するだけで簡単に、多くの SaaS サービスと統合できます。 Azure API Management では OAuth もサポートされているため、統合認証スキームを提供することで両方のサービスを一緒に使用できます。

  BizTalk Server でこの機能をネイティブに使うことはできません。

• マネージド ID

  Azure Logic Apps (Standard) では、マネージド ID を使用してストレージ アカウントへのアクセスを認証できます。 一部のコネクタでは、Microsoft Entra ID によって保護されているリソースへのアクセスの認証に対し、マネージド ID の使用がサポートされています。 接続を認証するためにマネージド ID を使用する場合は、資格情報、シークレット、または Microsoft Entra トークンを指定する必要はありません。

アプリケーションの管理とアクセスの管理

Azure portal は、管理者とサポート担当者がインターフェイスの正常性を表示および監視するために使用する一般的なツールです。 Azure Logic Apps の場合、このエクスペリエンスには、実行履歴で使用できる豊富なトランザクション トレースが含まれます。 きめ細かいロールベースのアクセス制御 (RBAC) も使用できるため、さまざまなレベルで Azure リソースへのアクセスを管理および制限できます。

Storage

Azure Logic Apps では、Azure Storage を利用して、データが格納され、自動的に保存データが暗号化されます。 この暗号化によってデータが保護され、組織のセキュリティとコンプライアンスの要件を満たすことができます。 既定では、Azure Storage は Microsoft マネージド キーを使用してデータを暗号化します。 詳細については、「保存データ向け Azure ストレージの暗号化」をご覧ください。

Azure Portal で Azure Storage を使用すると、 すべてのトランザクションが HTTPS 経由で実行されます。 また、HTTPS 経由で Storage REST API を使って Azure Storage を操作することもできます。 REST API を呼び出してストレージ アカウント内のオブジェクトにアクセスするときに HTTPS の使用を強制するには、ストレージ アカウントに必要なセキュリティ保護された転送を有効にします。

Azure Logic Apps (Standard) ハイブリッド デプロイ モデルは、SQL Server に依存しています。 この依存関係により、BizTalk Server で既存のオンプレミス SQL Server 環境を使用できます。

大きなファイルの処理

BizTalk Server での大きなファイルの処理と Azure Logic Apps との間には、いくつかの基本的な違いがあります。 たとえば、最新のクラウド環境ではこの問題を解決する方法が異なる可能性があるため、大きなメッセージのシナリオを慎重に調べて、適切なソリューションを見つけます。

ファイル サイズ制限

Azure では、一貫した信頼性の高いエクスペリエンスを保証するため、ファイル サイズの制限が存在します。 シナリオの確認については、Azure Logic Apps でのサービスの制限に関するドキュメントをご覧ください。 一部のコネクタでは、既定のメッセージ サイズ制限 (コネクタによって異なります) を超えるメッセージのメッセージ チャンクがサポートされています。 メッセージ チャンクにより、大きなメッセージは小さなメッセージに分割されます。

メッセージのサイズに制限があるサービスは、Azure Logic Apps だけではありません。 たとえば、Azure Service Bus にもそのような制限があります。 Azure Service Bus での大きなメッセージの処理について詳しくは、「大きいメッセージのサポート」をご覧ください。

ファイル サイズの制限を回避するには、クレーム チェック パターンを実装できます。これは、大きなメッセージを "クレーム チェック" とペイロードに分割することで機能します。 クレーム チェックはメッセージング プラットフォームに送信し、ペイロードは外部サービスに格納します。 こうすることで、大きなメッセージを処理しながら、メッセージ バスとクライアントを過負荷から保護できます。 また、通常はストレージの方がメッセージング プラットフォームで使われるリソース ユニットより安いので、このパターンはコストの削減にも役立ちます。

監視とアラート

Azure Logic Apps では、Application Insights のサポートを有効にして、Azure サービスを監視するための基盤としてキュレーションされた視覚化を提供できます。 キュレートされた情報を、Azure Logic Apps (Standard) 用に特別に設計されたダッシュボードを使用して視覚化することによって、Standard ワークフローをより効果的に監視できるようになります。 ダッシュボード スコープは、Standard ロジック アプリ内のワークフローを対象としています。 Azure Workbooks で構築されたダッシュボードでは、さまざまな視覚化が実現されています。 これらのブックは、特定のニーズに合わせて簡単に拡張したりカスタマイズしたりできます。

Serverless 360 は Kovai の外部ソリューションであり、Azure Logic Apps、Azure Service Bus、Azure API Management、Azure Functions などの Azure サービスのマッピングを通じて監視と管理を提供します。 Azure Service Bus の配信不能キューを使ってメッセージを再処理したり、断続的なサービスの中断に対処するために自己復旧を有効にしたり、代理トランザクションによるプロアクティブな監視を設定したりできます。

カスタム監視ルールを構成し、ポータル エクスペリエンスでログを表示できます。 メール、Microsoft Teams、ServiceNow など、さまざまなチャネルを通じて通知を送ることができます。 インターフェイスの正常性を目で見て判断するには、サービス マップを使用できます。

ビジネス アクティビティの監視

さまざまな Azure リソースを使ってサービスとシステムを統合するソリューションの作業を行う開発者またはビジネス アナリストは、ソリューション内の技術コンポーネントとビジネス シナリオの間の関係を視覚化するのが難しい場合があります。 Azure リソースに関するビジネス コンテキストをソリューションに含めるには、これらのリソースによって実装されるビジネス ロジックを視覚的に表すビジネス プロセスを構築できます。 Azure ビジネス プロセス追跡でのビジネス プロセスは、実際のビジネス シナリオを流れるタスクを表す一連のステージです。

もう 1 つのオプションとして、Serverless 360 という名前の Kovai の外部ソリューションを使うこともできます。 監視プラットフォームと共に、クラウドネイティブとハイブリッドの統合全体でビジネス プロセス フローをエンド ツー エンドで追跡するビジネス アクティビティの監視機能を使用できます。 開発者は、この機能に含まれるマネージド コネクタを使って、コードをインストルメント化し、重要なビジネス データをキャプチャできます。 その後、管理者は、ダッシュボードを構築してビジネス アナリストと共有できます。

追跡

Azure Logic Apps には豊富なワークフロー実行履歴が用意されているため、開発者とサポート アナリストは、処理されたすべての入力と出力を含む、アクションごとのテレメトリを確認できます。 機密データを保護するには、ワークフロー内の個々のアクションでセキュリティ保護された入力と出力を有効にできます。 この機能は、リークを防ぐために、ログとワークフロー実行履歴のデータを難読化または非表示にします。

データの難読化以外に、Azure RBAC ルールを使ってデータ アクセスを保護できます。 Azure RBAC には、Azure Logic Apps (Standard) 用の特定の組み込みロールが含まれています。 Azure RBAC を超えて、 IP アドレス範囲で Azure Logic Apps の実行履歴へのアクセスを制限できます。

Hosting

• ホスティング プラン

  シングルテナントの Azure Logic Apps では、1 つのワークフロー サービス プランを使用して、複数の Standard ロジック アプリをホストできます。 つまり、すべてのワークフローを 1 つの Standard ロジック アプリ リソースにデプロイする必要はありません。 代わりに、これらのワークフローを論理グループ (ロジック アプリ) にまとめて、ソリューションの他の側面をより適切に管理できます。 このアプローチは、ワークフロー サービス プランを最大限に活用し、アプリケーションを将来も利用できるようにするのに役立ち、個別にスケーリングできるように実装できます。

  Standard ロジック アプリには、WS1、WS2、WS3 の価格レベルがあります。 提供される機能は、どのレベルでも同じです。 コンピューティングとメモリの要件によって、次のようなシナリオに最適なものが決まります。

  価格階層	仮想 CPU (vCPU)	メモリ (GB)
  WS1	1	3.5
  WS2	2	7
  WS3	4	14

  詳細については、「Standard モデルの価格レベル」を参照してください。

• ハイブリッド デプロイ モデル

  Azure Logic Apps には、オンプレミス、プライベート クラウド、またはパブリック クラウドのシナリオで Standard ロジック アプリ ワークフローをデプロイおよびホストできるように、ハイブリッド デプロイ モデルが用意されています。 このモデルによって、ローカル処理、データ ストレージ、ネットワーク アクセスを使用する必要があるときに、部分的に接続された環境で統合ソリューションをホストする機能が提供されます。 ハイブリッド オプションを使用すると、ワークフローに最適な環境を自由に、かつ柔軟に選択できます。 詳細については、「 ハイブリッド展開を使用して標準ロジック アプリ用の独自のインフラストラクチャを設定する」を参照してください。

• 可用性と冗長性

  Azure では、可用性ゾーンによって回復性、分散型可用性、アクティブ アクティブ アクティブ ゾーンのスケーラビリティが提供されます。 ロジック アプリ ワークロードの可用性を高めるには、可用性ゾーンのサポートを有効にできますが、ロジック アプリを作成するときにだけ行うことができます。 ゾーン冗長性がサポートされていて有効にされた Azure リージョンには、少なくとも 3 つの分離された可用性ゾーンが存在する必要があります。 Azure Logic Apps プラットフォームでは、これらのゾーンを配置し、ロジック アプリのワークロードをこれらのゾーン全体に分散します。 この機能は、回復性があるアーキテクチャを有効にするため、およびリージョンでデータセンターの障害が発生した場合に高可用性を提供するための重要な要件です。 詳しくは、「可用性ゾーンを使用した高可用性のためのソリューションの構築」をご覧ください。

• 分離された専用の環境

  Standard ロジック アプリの場合、デプロイ環境として App Service Environment (ASE) v3 を選択できます。 ASE v3 を使うと、予測可能な価格でアプリケーションを大規模に実行するための完全に分離された専用環境が得られます。 作成して実行するロジック アプリの数に関係なく、ASE App Service プランに対してのみ支払います。

追加の Azure 統合サービスを必要とするシナリオについては、次のドキュメントを参照してください。

• Azure Service Bus の Premium および Standard メッセージング レベル
• Azure API Management - 機能レベルの比較

デプロイ

Azure Logic Apps では、Azure Resource Management テンプレートを使用してインフラストラクチャ リソースを作成する機能を提供することで、コードとしてのインフラストラクチャ (IaC) がサポートされます。 ARM テンプレートは、理解したり統合ソリューションとして実装するのが複雑に思えるかもしれませんが、Bicep、Terraform、Pulumi など、インフラストラクチャ定義を作成するためのコードのようなエクスペリエンスを提供する抽象化ツールを使用できます。 これらのツールは、ARM テンプレートに対する抽象化レイヤーを提供しますが、最終的には ARM テンプレートを生成し、それらのテンプレートを自動的にデプロイできます。

インフラストラクチャの用意ができたら、エンド ツー エンドのワークフローを実装するロジックをデプロイできます。 Azure Integration Services には統合ワークフローを実装するためのツールのコレクションが用意されているので、各コンポーネントをデプロイする必要があります。 Azure Integration Services を使って構築されたソリューションの場合、通常、CI/CD パイプラインはコンポーネントのオーケストレーションのデプロイが基になります。 DevOps エンジニアは、デプロイ アクティビティを抽象化する組み込みアクションを使うことも、CLI コマンドまたは PowerShell や Bash などの自動化スクリプトを実行する汎用アクションを使うこともできます。 ほとんどの場合、エンジニアは、アプリケーションのニーズに基づいてパイプラインをカスタマイズし、公式ドキュメントのガイダンスを確認し、サンプル リポジトリを出発点として使います。

各コンポーネントをデプロイできるようにするプロセスでは、通常、次の手順を考慮します。

• 継続的インテグレーション フェーズ

  1. ソース コードの最新バージョンを取得します。

  2. 環境固有の構成でコードを準備します。

     このステップの詳細は、環境変数の外部挿入に対する各テクノロジのサポートによって異なります。 基本的な前提として、接続文字列や外部リソースの参照などの環境ベースの構成情報は、アプリケーション設定リポジトリを参照するために抽象化されています。 そのため、このシナリオでは、クリア テキストにできる参照はアプリケーション設定リポジトリに直接格納しますが、シークレットなどの機密性の値は、Azure キー コンテナーなどのシークレット ストア内のエントリへの参照ポインターとして格納します。

     Azure Logic Apps の Standard ロジック アプリ リソースでは、アプリケーション設定リポジトリへの参照をサポートすることでこのアプローチが可能になっており、名前と値のペアをキー コンテナー内のエントリにマップできます。

  3. さまざまな環境でのデプロイ用にコードをパッケージ化します。

• 継続的デプロイ フェーズ

  1. パッケージ化されたコードを対象の環境にデプロイします。

  2. クリア テキストまたはキー コンテナー内のエントリへの参照を使って、環境の正しい値でアプリケーション設定リポジトリを更新します。

  3. コードに依存する必要なアクセス許可を更新します。

  4. 必要に応じて、アプリケーションを実行できるようにします。

機能の比較

次の表と図は、BizTalk Server、Azure Logic Apps (Standard)、およびその他のサービス間でリソース、成果物、機能が比較および一致する方法を示しています。 Azure Logic Apps の機能を可能な限り使用して、まとまりのある、よりコスト効率の高いソリューションを構築してください。

Azure Logic Apps Standard (クラウド)

Azure Logic Apps Standard ハイブリッド (オンプレミス)

最新の取り組みに関する情報を入手するには、Azure での統合に関するブログ - Tech Community にサブスクライブしてください。

次のステップ

Azure Logic Apps と BizTalk Server の比較の詳細について学習しました。 次に、推奨されるアプローチとリソース、計画に関する考慮事項、および移行のベスト プラクティスを確認します。