BizTalk Server から Azure Integration Services に移行する理由
このガイドでは、オンプレミスの BizTalk Server からクラウドベースの Azure Integration Services への移行を始めるのに役立つ、理由と利点、製品の比較、機能、その他の情報の概要について説明します。 このガイドの後で、シナリオに最適なサービスを選択する方法と、成功するために役立つ移行戦略、計画に関する考慮事項、ベスト プラクティスについて説明されている他のガイドを参照してください。
理由と利点
統合ワークロードを Azure Integration Services に移行すると、主に次のような利点があります。
| 特長 | 説明 |
|---|---|
| 最新のサービスとしての統合プラットフォーム (iPaaS) | Azure Integration Services には、BizTalk Server が最初に作成されたときにはまだ考えられていなかった機能が用意されています。次に例を示します。 - REST API を作成および管理する機能 - スケーラブルなクラウド インフラストラクチャ - 安全性が高く、実装が容易な最新の認証スキーム - 多くの Web ブラウザー ベースのエクスペリエンスを含む、簡素化された開発ツール - プラットフォームの自動更新と、他のクラウドネイティブ サービスとの統合 |
| 使用量ベースの価格 | 従来のミドルウェア プラットフォームでは、多くの場合、ライセンスとインフラストラクチャの調達に多大な資本投資を行う必要があり、"ピーク時に合わせた構築" が強いられ、効率が悪くなります。 Azure Integration Services には、複数の価格モデルが用意されており、通常は、使用したものに支払うことができます。 一部の価格モデルでは、より高度な機能にアクセスできますが、使用した分を柔軟に支払うことができます。 |
| エントリの壁を低くする | BizTalk Server は高性能のミドルウェア ブローカーですが、学習と習熟にはかなりの時間が必要です。 Azure Integration Services を使うと、ソリューションの開始、学習、構築、提供に必要な時間が短縮されます。 たとえば、Azure Logic Apps に含まれビジュアル デザイナーでは、宣言型ワークフローを構築するためのノーコードまたはローコードのエクスペリエンスが提供されます。 |
| SaaS の接続性 | アプリケーション統合の標準になりつつある REST API をデータ交換用のアプローチとして採用する SaaS 企業が増えています。 Microsoft は、Microsoft や Microsoft 以外のサービス、システム、プロトコルで動作する数百の API を使用して、拡大し続ける広大なコネクタ エコシステムを構築しています。 Azure Logic Apps では、ワークフロー デザイナーを使って、これらのコネクタから操作を選び、接続を簡単に作成して認証し、使用する操作を構成できます。 この機能により、開発が高速化され、OAuth2 を使ってこれらのサービスへのアクセスを認証するときの一貫性が向上します。 |
| 複数の場所へのデプロイ | Azure では、現在、他のどのクラウド プロバイダーより多い 60 以上のリージョンの提供が発表されているため、自社や顧客に適したデータセンターとリージョンを簡単に選択できます。 この範囲により、多くの場所に一貫した方法でソリューションをデプロイし、スケーラビリティと冗長性の両方の観点から有利な状況を提供できます。 |
Azure Integration Services とは
Azure Integration Services には、包括的な統合ソリューションを作成し、既存の BizTalk Server ソリューションを移行するために、クラウドベース、サーバーレス、スケーラブル、Microsoft マネージドの次のような構成要素が含まれています。
| サービス | 説明 |
|---|---|
| Azure Logic Apps | アプリ、データ、サービス、システムを統合する自動化されたロジック アプリ ワークフローを作成して実行します。 エンタープライズと企業間 (B2B) のシナリオ向けのスケーラビリティの高い統合ソリューションを短期間で開発できます。 ビジュアル ワークフロー デザイナーを使って、マイクロサービス、API オーケストレーション、基幹業務の統合を可能にします。 業務に不可欠なワークフローを自動化しながら、スケールと移植性を向上させるには、Kubernetes が実行できる任意の場所にデプロイして実行します。 従量課金または Standard のロジック アプリ リソースを作成できます。 従量課金ロジック アプリには、マルチテナントの Azure Logic Apps で実行されるステートフル ワークフローが 1 つだけ含まれます。 Standard ロジック アプリには、シングルテナントの Azure Logic Apps、App Service Environment v3、または Azure Arc 対応 Logic Apps で実行される複数のステートフルまたはステートレス ワークフローを含めることができます。 Azure Integration Services 内での Azure Logic Apps の位置づけとして、このガイドでは、エンタープライズ機能、コスト、機敏性の最適なバランスを提供する Standard ロジック アプリに焦点を当てます。 詳細については、Azure Logic Apps に関するページを参照してください。 |
| Azure Functions | コードの記述と保守するインフラストラクチャが少なくなり、アプリケーションを実行するためのコストを節約できます。 サーバーをデプロイして保守する必要がなく、クラウド インフラストラクチャによって、アプリケーションの実行を維持するために必要な最新のリソースがすべて提供されます。 詳細については、Azure Functions に関するページを参照してください。 |
| Azure Data Factory | 90 を超える組み込みのメンテナンス不要のコネクタを追加コストなしで使用して、すべてのデータ ソースを視覚的に統合します。 抽出、変換、読み込み (ETL) と抽出、読み込み、変換 (ELT) のプロセスを、直感的な環境でコードを記述しないで簡単に構築することも、独自のコードを記述することもできます。 ビジネスに関する分析情報を入手するには、統合データを Azure Synapse Analytics に提供します。 詳細については、Azure Data Factory に関する記事を参照してください。 |
| Azure Service Bus | この信頼性の高いエンタープライズ メッセージ ブローカーを使用して、オフラインの場合でも、アプリケーションとサービスの間でデータを転送します。 構造化された先入れ先出し (FIFO) メッセージング、パブリッシュとサブスクライブの機能、非同期操作により、クライアントとサーバーの間でメッセージを仲介するときの柔軟性が向上します。 詳しくは、Azure Service Bus に関する記事をご覧ください。 |
| Azure Event Grid | イベント ブローカーによってサブスクライバーの宛先 (Azure サービス、他のアプリケーション、Event Grid がネットワーク アクセスできるエンドポイントなど) に配信されるイベントを使って、アプリケーションを統合します。 イベント ソースには、他のアプリケーション、SaaS サービス、Azure サービスを含めることができます。 詳しくは、Azure Event Grid に関する記事をご覧ください。 |
| Azure API Management | API ゲートウェイをサイド バイ サイドでデプロイし、Azure、他のクラウド、オンプレミスでホストされている API を使ってトラフィック フローを最適化します。 セキュリティとコンプライアンスの要件を満たしながら、内部と外部のすべての API で統一された管理エクスペリエンスと完全な監視を実現できます。 詳しくは、Azure API Management に関する記事をご覧ください。 |
補完的な Azure サービス
前述のサービス以外に、Microsoft からは、Azure Integration Services の基になる機能を提供し、移行プロジェクトで使用する可能性が高い、補完的なサービスも提供されています。
| サービス | 説明 |
|---|---|
| Azure Storage | クラウドのさまざまなデータ オブジェクト向けに、高可用性で、スケーラビリティが高く、持続性とセキュリティを備えた最新のストレージを提供します。 これらのデータ オブジェクトには、REST API を使って、HTTP または HTTPS 経由で世界中のどこからでもアクセスできます。 Azure Integration Services は、トランザクションがプラットフォームを通過する間、これらの機能を使って、構成とテレメトリのデータを安全に格納します。 詳しくは、「Azure Storage」に関する記事をご覧ください。 |
| Azure ロールベースのアクセス制御 (Azure RBAC) | クラウド リソースへのアクセスを管理します。これは、クラウドを使用するすべての組織にとって重要な機能です。 Azure RBAC は Azure Resource Manager 上に構築された承認システムであり、Azure リソースに対するアクセスをきめ細かく管理できます。 Azure のリソースにアクセスできるユーザー、ユーザーがそれらのリソースでできること、ユーザーがアクセスできる領域を管理できます。 詳細については、Azure RBAC に関するページを参照してください。 |
| Azure Key Vault | シークレット管理、キー管理、証明書管理に関連する問題を解決するのに役立つ機能を提供します。 Azure Integration Services は、アプリケーションの構成設定とコネクタを通して、Azure Key Vault との統合を提供します。 この機能を使うと、シークレット、資格情報、キー、証明書を安全で便利な方法で格納できます。 詳しくは、Azure Key Vault に関する記事をご覧ください。 |
| Azure Policy | 組織の標準を適用し、スケーラブルな方法でコンプライアンスを評価するのに役立つ機能を提供します。 コンプライアンス ダッシュボードのリソースおよびポリシーごとの細分性でドリルダウンする機能を使って、集計ビューを取得し、環境の全体的な状態を評価できます。 Azure Integration Services は Azure Policy と統合されるため、広範なガバナンスを効率的に実装できます。 詳細については、Azure Policy に関するページをご覧ください。 |
| Azure のネットワーク | 接続性、アプリケーション保護サービス、アプリケーション配信サービス、ネットワーク監視など、さまざまなネットワーク機能を提供します。 Azure Integration Services は、これらの機能により、仮想ネットワークとプライベート エンドポイントを使ってサービス間の接続を提供します。 詳しくは、Azure ネットワークに関する記事をご覧ください。 |
| Azure Event Hubs | 動的なデータ パイプラインを構築し、シンプルで信頼できるスケーラブルなフル マネージドのリアルタイム データ インジェスト サービスを使って、任意のソースから 1 秒あたり何百万ものイベントをストリーミングすることで、ビジネス上の課題に即座に対応します。 API Management は、分離された追跡ソリューションを Azure に実装するときの最適なソリューションの 1 つである Event Hubs を使って、カスタム ログを実行します。 詳細については、Azure Event Hubs に関するページを参照してください。 |
| Azure SQL データベース | ある時点で、統合ソリューションをサポートするために、カスタム ログ戦略またはカスタム構成を作成することが必要になる場合があります。 オンプレミスではこの目的に SQL Server がよく使われますが、オンプレミスの SQL Server データベースをクラウドに移行するときは、Azure SQL Database によって実現可能なソリューションが提供される場合があります。 詳細については、「Azure SQL Database」を参照してください。 |
| Azure App Configuration | アプリケーションの設定と機能フラグを一元的に管理します。 最新のプログラム (特にクラウドで実行されるもの) は、その性質上、多くの分散コンポーネントを含むのが一般的です。 これらのコンポーネント全体に構成設定を分散させると、アプリケーションのデプロイの間に、トラブルシューティングの難しいエラーが発生する可能性がありす。 App Configuration を使うと、アプリケーションのすべての設定を 1 か所に格納して、アクセスをセキュリティで保護できます。 詳しくは、Azure App Configuration に関する記事をご覧ください。 |
| Azure Monitor | Azure Monitor の一部である Application Insights では、ライブ アプリのパフォーマンスの管理と監視が提供されます。 アプリケーションのテレメトリを格納し、統合プラットフォームの全体的な正常性を監視します。 また、しきい値を設定し、構成したしきい値をパフォーマンスが超えたらアラートを受け取る機能もあります。 詳しくは、Application Insights に関する記事をご覧ください。 |
| Azure Automation | Azure の管理タスクを自動化し、Azure 内の外部システム間でアクションを調整します。 PowerShell ワークフロー上に構築されるので、この言語の多くの機能を使用できます。 詳細については、「Azure Automation」を参照してください。 |
サポートされている開発者エクスペリエンス
このセクションでは、BizTalk Server と Azure Integration Services でサポートされる開発者ツールについて説明します。
| サービス | 製品またはサービスとサポートされているツール |
|---|---|
| BizTalk Server | BizTalk Server の各バージョンでは、Visual Studio の特定のバージョンがサポートされています。 たとえば、BizTalk Server 2020 では Visual Studio 2019 Enterprise または Professional がサポートされています。 ただし、Visual Studio Community Edition はサポートされていません。 |
| Azure Integration Services | - Azure Logic Apps (Standard): Azure portal、Visual Studio Code - Azure Logic Apps (従量課金): Azure portal、Visual Studio Code、Visual Studio 2019、2017、2015 - Azure Functions: Azure portal、Visual Studio Code、Visual Studio 2022 - Azure API Management: Azure portal、Visual Studio Code - Azure Service Bus: Azure portal、Service Bus Explorer - Azure Data Factory: Azure portal、Visual Studio 2015、2013 |
BizTalk Server と Azure Integration Services の比較
BizTalk Server と Azure Integration Services を比較し、移行方法について検討するため、最初に、BizTalk Server とはどういうものかを簡単にまとめておきましょう。 2000 年に最初に使用できるようになった BizTalk Server は、アダプターを使ってさまざまなシステムを接続する、オンプレミスの安定したミドルウェア プラットフォームです。 このプラットフォームは、企業、システム、またはアプリケーション間のブローカーとして機能し、現在は十分に確立された統合プラットフォームです。 異なる言語で開発され、異なるプロトコルと形式を使って接続できるさまざまなシステムを組み合わせるという課題を簡単にするため、BizTalk Server には次の主な機能が用意されています。
オーケストレーション (ビジネス フロー)
オーケストレーションまたはグラフィカルに定義されたビジネス プロセスを作成して実行する機能を提供します。
メッセージング
幅広いソフトウェア アプリケーションと通信する機能を提供します。 アダプターを使うことで、BizTalk Server のメッセージング コンポーネントはさまざまなプロトコルやデータ形式と対話できます。
BizTalk Server エンジンには、次のコンポーネントが含まれています。
| コンポーネント | 説明 |
|---|---|
| ビジネス ルール エンジン (BRE) | 複雑なルールのセットを評価します。 |
| エンタープライズ シングル サインオン (SSO) | Windows と Windows 以外のシステム間で認証情報をマップする機能を提供します。 |
| ビジネス アクティビティ監視 (BAM) | インフォメーション ワーカーが実行中のビジネス プロセスを監視できるようにします。 |
| グループ ハブ | サポート担当者が、実行するエンジンとオーケストレーションを管理できるようにします。 |
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 は、ビジネス プロセスによる処理のため、または特定のメッセージへのサブスクリプションを持つ送信ポートにルーティングするために、そのメッセージを格納します。
詳しくは、後の「パブリッシュ サブスクライブ アーキテクチャ」をご覧ください。
ビジネス プロセス
このセクションでは、BizTalk Server と Azure Integration Services で実行できるビジネス プロセスの設計と構築に関するオプションについて説明します。
BizTalk Server
BizTalk Server でのオーケストレーションは、MessageBox データベースを使ってメッセージのサブスクライブ (受信) とメッセージのパブリッシュ (送信) を行うことができる実行可能なビジネス プロセスです。 オーケストレーションでは、新しいメッセージを構築し、サブスクリプションとルーティング インフラストラクチャを使ってメッセージを受信できます。 MessageBox でオーケストレーション用のサブスクリプションがいっぱいになると、新しい "インスタンス" (オーケストレーションの実行) がアクティブになり、MessageBox によってメッセージが配信されます。 必要な場合は、インスタンスがリハイドレートされてから、メッセージが配信されます。 オーケストレーションから送信されたメッセージは、受信場所に到着したメッセージと同じように MessageBox にパブリッシュされ、ルーティングのための適切なプロパティがデータベースに追加されます。
パブリッシュ サブスクライブ メッセージングを有効にするため、オーケストレーションではサブスクリプションの作成に役立つバインディングが使われます。 オーケストレーションのポートは、対話処理を表す論理ポートです。 メッセージを配信するには、これらの論理ポートを物理ポートにバインドする必要がありますが、このバインド プロセスは、メッセージのルーティングのためのサブスクリプションの構成にすぎません。
BizTalk Server には、次の例のような利点があります。
デザイナー第一 (宣言型)
わかりやすい設計ツールを使って複雑なプロセスを設計し、他の方法ではコードで実装するのが難しいパターンやワークフローを実装します。
エンド システムでの抽象化
エンド システムではなく、メッセージに重点を置いてプロセスを設計します。 たとえば、ソリューションの開発時に、FILE アダプターと FTP アダプターのどちらを使うかを気にする必要はありません。 代わりに、通信の種類、一方向か要求 - 応答か、処理するメッセージの種類に注目します。 後で、ソリューションをデプロイするときに、アダプターとエンド システムを指定できます。
Azure Integration Services
Azure Logic Apps では、ビジュアル デザイナーでの "構成要素" のプログラミング方法と、数百のコネクタの事前構築済み操作を使って、ロジック アプリ ワークフローとして実行可能なビジネス プロセスとアプリケーションを作成でき、必要なコードは最小限で済みます。 ロジック アプリ ワークフローは、トリガー操作で始まり、その後に 1 つ以上のアクション操作が続き、各操作はワークフロー実装プロセスの 1 つの論理ステップとして機能します。 ワークフローでは、アクションを使って外部のソフトウェア、サービス、システムを呼び出すことができます。 一部のアクションでは、条件 (if ステートメント)、ループ、データ操作、変数管理などのプログラミング タスクが実行されます。
Azure Logic Apps には、次の例のような利点があります。
デザイナー第一 (宣言型)
わかりやすい設計ツールを使って複雑なプロセスを設計し、他の方法ではコードで実装するのが難しいパターンやワークフローを実装します。
柔軟でスケーラブル
Azure Logic Apps は、サーバーレスで拡張性の高いクラウドベースのコンピューティング サービスであり、進化するビジネス ニーズに合わせて自動的にスケーリングおよび適応します。
何にでも接続する
何百もの事前構築済みコネクタを含む拡大し続けるギャラリーから選ぶことで、ワークフローを構築します。 コネクタによって提供される操作を、ワークフローのステップとして使用できます。 Microsoft とパートナー両方のほとんどのサービスとシステム (BizTalk Server、Salesforce、Office 365、SQL データベース、ほとんどの Azure サービス (Azure Functions、Azure Storage、Azure Service Bus など)、その他多数) に加えて、オンプレミスのアプリケーションやシステム、メインフレーム、SaaS、API のための、統合ソリューションを構築できます。 アクセスしたいリソース用の事前構築済みコネクタがない場合は、一般的な HTTP 操作を使ってサービスと通信するか、カスタム コネクタを作成することができます。
再利用可能なコンポーネント
統合プラットフォームでは、一貫性のある統一された方法で問題を解決するための手段が提供され、多くの場合、再利用可能なコンポーネントを通じてそれを実現できます。 このセクションでは、BizTalk Server と Azure Integration Services でコンポーネントを再利用する方法について説明します。
BizTalk Server
オーケストレーション
共通のビジネス ロジックを作成し、同じアプリケーション内または複数のアプリケーションで、異なるワークフロー間のオーケストレーションとして共有できます。 BizTalk Server ネイティブのパブリッシュ サブスクライブ メカニズムを使うか (分離された方法)、オーケストレーション呼び出し (同期呼び出しの場合) またはオーケストレーション開始 (非同期呼び出しの場合) という名前のオーケストレーション図形を使って、オーケストレーションをトリガーできます。
アダプター
アダプタはソフトウェア コンポーネントであり、一般に知られているデータ プロトコルとドキュメント形式を使って BizTalk Server と取引先の間の接続を提供します。 これらのコンポーネントでは、SMTP、FTP、HTTP などの一般に知られた標準に準拠する配信メカニズムが使われているので、メッセージを簡単に送受信できます。 アダプターはコア プラットフォームの一部であるため、既存のすべてのアプリケーションで共有されます。 また、BizTalk アダプター フレームワークを使って、ネイティブな、または Windows Communication Foundation (WCF) に基づくカスタム アダプターを作成することで、このレイヤーを拡張することもできます。
スキーマ
XML スキーマ定義 (XSD) のスキーマを使うと、BizTalk Server でコントラクト ベースのメッセージングが可能になります。 冗長なスキーマが作成されないようにするため、コンパイル済みアセンブリからスキーマを参照できます。 共有スキーマを使うには、BizTalk プロジェクトから共有アセンブリへの参照を追加する必要があります。
このステップは簡単に思えるかもしれませんが、依存関係のチェーンのため、共有アセンブリに対する変更の管理が難しくなる可能性があります。 共有アセンブリで更新が必要な場合は、共有アセンブリを参照するすべてのプロジェクトを BizTalk Server から削除して、更新プログラムをインストールする必要があります。 ただし、これらの制約を回避するため、アセンブリのバージョン管理を実装でき、スキーマまたは共有スキーマの新しいバージョンをデプロイしても、既存のソリューションが壊れることはありません。
マップとカスタム Functoid
マップを使うと、BizTalk Server で XML メッセージを翻訳または変換できるようになります。 マップを共有できますが、共有スキーマと同様の注意が共有マップにも適用されます。 依存関係のチェーンがあるので、慎重に作業を進めて、変更管理のための成熟したソフトウェア開発ライフサイクルがあることを確認してください。
マップの Functoid は、定義済みの数式と引数と呼ばれる特定の値を使って計算を実行します。 BizTalk Server には、さまざまな操作をサポートする多くの Functoid が用意されています。 カスタム Functoid を使うと、BizTalk Server のマッピング環境で使用できる操作の範囲を広げることができます。
多くのマップの作成を始めると、似たロジックを繰り返し実装していることがわかります。 その結果、通常は 1 つのマップ内または複数のマップの複数の場所にコピーして貼り付ける複数の同等のコード スニペットを保守するために時間が費やされることがわかります。 このようなコード スニペットはカスタム Functoid に変換することを検討します。 そうすることで、Functoid を 1 回だけ作成し、必要な数のマップで Functoid を再利用して、1 か所で Functoid を更新できます。 各カスタム Functoid は、Microsoft.BizTalk.BaseFunctoids 名前空間から派生したクラスを使って .NET アセンブリとしてデプロイされます。 1 つのアセンブリに複数のカスタム Functoid を含めることができます。
.NET Fx アセンブリ
これらのアセンブリは、複数の BizTalk Server プロジェクト間で共有できます。 依存関係の観点からは、これらのアセンブリは管理するのが簡単です。 破壊的変更が存在しない場合、.NET Fx アセンブリを更新するには、グローバル アセンブリ キャッシュ (GAC) 内の DLL を更新する必要があります。これにより、他のアセンブリでその変更を自動的に使用できるようになります。 破壊的変更が存在する場合は、.NET Fx アセンブリでの変更を反映するように依存プロジェクトも更新する必要があります。
カスタム パイプラインとパイプライン コンポーネント
BizTalk Server がメッセージを受信して送信するとき、ビジネス上の理由により、サーバーで入ってきて出ていくメッセージを準備して変換することが必要な場合があります。 BizTalk Server のパイプラインは、パイプとフィルターの統合パターンの実装を提供し、JSON エンコーダーとデコーダー、MIME または SMIME デコーダーなどの多くの機能を備えています。
メッセージのコンテキストに情報を追加する必要があるときに、パイプラインのカスタマイズが必要な場合、BizTalk Server にはカスタム パイプライン コンポーネントを作成することでこれらのパイプラインをカスタマイズする機能があります。 .NET クラスであるカスタム パイプライン コンポーネントを使って複数の BizTalk インターフェイスを実装し、カスタム パイプラインのさまざまなステージ内でそれを使います。 そのようなコンポーネントのコードを記述するには、.NET 用の C# または Visual Basic を使用できます。
ルール エンジン ポリシー
ビジネス ルール エンジン ポリシーは、同じ BizTalk グループ内にデプロイされた BizTalk Server アプリケーション間で共有できる別の種類の成果物です。 たとえば、メッセージのルーティングに関連するビジネス ルール エンジンの一般的なルールがある場合は、これらのルールを 1 つの場所で管理し、インストールされている BizTalk アプリケーション間で広く共有できます。 ビジネス ルール エンジンではこれらのルールがキャッシュされるため、これらのルールを更新する場合は、ビジネス ルール エンジン更新サービスを再起動する必要があります。 そうしないと、変更は次のキャッシュ タイムアウトで取得されます。
Azure Integration Services
統合アカウント
Azure Logic Apps の場合、統合アカウントはクラウドベースのコンテナーであり、再利用可能な成果物への一元的なアクセスを提供する Azure リソースです。 従量課金ロジック アプリ ワークフローの場合、これらの成果物には、取引先、契約、XSD スキーマ、XSLT マップ、Liquid テンプレート ベースのマップ、証明書、バッチ構成、.NET Fx アセンブリが含まれます。
Standard ロジック アプリ ワークフローの場合、Azure Logic Apps には、最近、統合アカウントを必要としない XSLT 変換からの .NET Fx アセンブリの呼び出しのサポートが導入されました。 または、Visual Studio Code で Standard ロジック アプリ プロジェクトにスキーマ、マップ、アセンブリを追加した後で、Azure にデプロイすることもできます。
API
API は、デジタル エクスペリエンスを実現し、データとサービスを再利用してユニバーサルにアクセスできるようにし、アプリケーションの統合を簡素化し、新しいデジタル製品を支えます。 API の急増とそれらに対する依存の増加に伴い、組織はライフサイクル全体にわたってファーストクラスの資産としてそれらを管理する必要があります。
API (特に Azure API Management で管理されるもの) は、Azure Integration Services 内で再利用できます。 Azure API Management に API を追加した後は、API Management コネクタと従量課金ロジック アプリ ワークフローを使って、管理とガバナンスが行われた方法で API に簡単にアクセスできます。 また、Azure Logic Apps では、カスタム API の作成と使用もサポートされているため、組織は企業全体で再利用を促進し、他の方法では開発者が作成する可能性がある不要で冗長なコネクタを回避できます。 また、カスタム API は、特定の API を使用するメカニズムの理解を開発者に任せるのではなく、これらの API を使用できるユーザーを民主化します。
カスタム コネクタ
使いたい API に事前構築済みのコネクタが存在しない場合は、OpenAPI スキーマで外部 API をラップしてカスタム コネクタを作成し、適切なアクセス許可を持つ従量課金ロジック アプリ ワークフローからそのコネクタにアクセスできます。 カスタム コネクタは、Azure Logic Apps と API の間のコントラクトを作成します。これにより、要求メッセージを簡単に作成でき、ダウンストリーム アクションで使用できる種類の応答を Azure Logic Apps で受け取ることができます。 REST API と SOAP API の両方がサポートされており、ローカル ネットワークに存在するパブリック API またはプライベート API を参照できます。 また、Microsoft Power Automate と Microsoft Power Apps でカスタム コネクタを使うこともできます。
Standard ロジック アプリ ワークフローの場合は、サービス プロバイダーを基にして独自の組み込みカスタム コネクタを作成できます。
カスタム コネクタを実装すると、要求メッセージを送信し、特定の種類の応答を受信するための共通インターフェイスを作成することで、開発エクスペリエンスを簡素化できます。 詳しくは、カスタム コネクタと API に関する記事をご覧ください。
アダプターとコネクタ
このセクションでは、BizTalk Server でのアダプターと Azure Integration Services でのコネクタの概念について説明します。
BizTalk Server
外部のシステム、アプリケーション、エンティティとメッセージを交換するために BizTalk Server で提供されているアダプターは、COM または .NET Fx コンポーネントであり、さまざまな通信プロトコルを使って、ファイル システム、データベース、カスタム ビジネス アプリケーションなどのビジネス エンドポイントとの間でメッセージを双方向に転送します。 BizTalk Server には、次のようなさまざまなプロトコルをサポートするネイティブ アダプターが用意されています。
- ファイルの場所からのメッセージの送受信をサポートするファイル アダプター
- EDI、FTP、HTTP、MSMQ、SMTP、POP3、および SOAP プロトコルのアダプター
- Windows SharePoint Services 用のアダプター
BizTalk アダプター フレームワークでは、すべてのアダプターで実装したり、BizTalk Server メッセージング エンジンの処理にアクセスしたりするための、安定したオープンなメカニズムが提供されています。 Microsoft.BizTalk.Adapter.Framework 名前空間のインターフェイスを使うと、アダプターで構成プロパティ ページを変更できます。 BizTalk アダプター フレームワークには、サービスとスキーマを BizTalk プロジェクトにインポートする機能も用意されています。 さまざまなベンダーやコミュニティ メンバーのパートナー アダプターも利用できます。 既知のアダプターの一覧については、BizTalk Server のサード パーティ製アダプターの一覧に関する記事をご覧ください。
Azure Integration Services
Azure Logic Apps を使ってワークフローを構築するときは、事前構築済みのコネクタを使って他のアプリ、サービス、システム、プロトコル、プラットフォームのデータ、イベント、リソースに簡単にすばやく使用できます。通常、コードを書く必要はありません。 Azure Logic Apps には拡大し続けるギャラリーがあり、何百ものコネクタを使用できます。 BizTalk Server、Salesforce、Office 365、SQL データベース、ほとんどの Azure サービス、メインフレーム、API など、Microsoft とパートナー両方のクラウドベースまたはオンプレミスの多くのサービスとシステムのための、統合ソリューションを構築できます。 一部のコネクタには、条件 (if) ステートメント、ループ、データ操作、変数管理など、プログラミング操作を実行する操作が用意されています。 目的のリソースに使用できるコネクタがない場合は、一般的な HTTP 操作を使用してサービスと通信するか、カスタム コネクタを作成することができます。
技術的には、コネクタとは基になるサービスまたはシステムによって Azure Logic Apps との通信に使われる API のプロキシまたはラッパーです。 このコネクタによって、タスクを実行するためにワークフローで使用する操作が提供されます。 操作は、構成できるプロパティを備えたトリガーまたはアクションとして使用できます。 一部のトリガーやアクションでは、最初に基になるサービスやシステムへの接続を作成して構成することが必要な場合もあります。 その後、必要に応じて、ユーザー アカウントへのアクセスの認証も行います。
Azure Logic Apps のほとんどのコネクタは、組み込みコネクタまたはマネージド コネクタです。 両方のバージョンで使用できるコネクタもあります。 使用できるバージョンは、作成するロジック アプリ ワークフローが従量課金か Standard かによって異なります。
組み込みコネクタは、Azure Logic Apps ランタイムでネイティブに実行するように設計されており、通常は、対応するマネージド コネクタと比較して、パフォーマンス、スループット、容量、その他の利点が優れています。
マネージド コネクタは、Microsoft によって Azure でデプロイ、ホスト、管理されます。 これらのコネクタにより、クラウドサービス、オンプレミス システム、またはその両方に対してトリガーとアクションが提供されます。 Standard ロジック アプリ ワークフローでは、すべてのマネージド コネクタが Azure コネクタとしてグループ化されます。 一方、従量課金ロジック アプリ ワークフローでは、マネージド コネクタは価格レベルに基づいて Standard または Enterprise としてグループ化されます。
詳しくは、次のドキュメントをご覧ください。
アプリケーションの接続
このセクションでは、BizTalk Server と Azure Integration Services から他のアプリケーションと接続するためのオプションについて説明します。
BizTalk Server
アダプターは、BizTalk Server の接続機能を提供し、送受信操作を実行する BizTalk サーバー上でローカルに実行します。 約 30 個のアダプターをすぐに使用でき、ISV アダプターの小さなエコシステムで追加機能が提供されます。 ローカル環境で実行されるこれらのアダプターでは、Windows 認証が一般的な認証方法です。 よく使われるアダプターとしては、FILE、SFTP、SQL、WCF (Basic-HTTP)、HTTP、SMTP があります。 この一覧から、BizTalk Server のアダプターは主にプロトコル アダプターであると判断できます。 その結果、アダプターでは、通常、メッセージ指向のメッセージング パターンが使われ、完全なメッセージが他のシステムと交換されます。それらのシステムで、最終的なデータ ストアにデータを読み込む前にデータを解析する必要があります。
Azure Integration Services
コネクタは、Azure Logic Apps での接続機能を備え、基になる SaaS システムによって通常所有される API の上位の抽象化を提供します。 たとえば、SharePoint などのサービスは API 優先アプローチを使って構築され、API がエンド ユーザー向けの機能をサービスに提供しますが、他のシステムには API の呼び出しを通じて同じ機能が公開されます。 これらの API を簡単に呼び出せるよう、コネクタではメタデータを使ってメッセージング コントラクトが記述されており、開発者は要求と応答で期待されるデータを把握できます。
次のスクリーンショットは、シングルテナント Azure Logic Apps での Standard ロジック アプリ ワークフローのためのコネクタ検索エクスペリエンスを示したものです。 [組み込み] タブを選ぶと、Azure Functions、Azure Service Bus、SQL Server、Azure Storage、ファイル システム、HTTP などの組み込みコネクタが見つかります。 [Azure] タブでは、他の Microsoft SaaS コネクタやパートナーの SaaS コネクタなど、800 を超えるコネクタが見つかります。
![[組み込み] タブと [Azure] タブのどちらかの選択に基づいて使用可能なコネクタを示す、Azure portal の Standard ロジック アプリ ワークフロー デザイナーのスクリーンショット。](media/biztalk-server-to-azure-integration-services-overview/azure-logic-apps-connectors-standard.png)
Web サービスと API 接続
このセクションでは、BizTalk Server と Azure Integration Services での Web サービスと API 接続のサポートについて説明します。
BizTalk Server
Web サービスのサポートは、BizTalk Server での一般的な機能であり、Windows Communication Foundation (WCF) と統合することで利用できます。 BizTalk でのこのサポートは、WCF サービスの発行と使用という 2 つのカテゴリに分類されます。
WCF アダプタは、WS-Addressing、WS-Security、WS-AtomicTransaction など、WS-* 標準のサポートを提供します。 ただし、WCF アダプタの現在のリリースでは、WS-ReliableMessaging はサポートされていません。
WCF アダプターは、偽装によるシングル サインオン (SSO) をサポートし、WCF アダプターで SSO を使うために Enterprise SSO チケットを取得します。 この機能により、ユーザー コンテキストはシステム間をフローできます。 認証の観点からは、サービス認証は None、Windows、Certificate の種類をサポートします。 クライアント認証では、Anonymous、UserName、Windows、Certificate の種類がサポートされています。 サポートされているセキュリティ モードの種類は、トランスポート、メッセージ、混合です。
WCF では WS-AutomicTransaction プロトコルを使用したトランザクションがサポートされており、これは WCF-WsHttp、WCF-NetTcp、WCF-NetMsmq などの WCF アダプターで見つかります。 この機能は、次のシナリオでサポートされています。
- MessageBox データベースへのメッセージのトランザクション送信
- MessageBox からトランザクションの送信先へのメッセージのトランザクション転送
トランザクション スコープは、MessageBox コンポーネントによって制限されます。 たとえば、BizTalk オーケストレーションはクライアントのトランザクションに参加できません。 同様に、送信先エンドポイントは、BizTalk オーケストレーションによって開始されたトランザクションに参加できません。
WCF の拡張性は、WCF カスタム バインドを通じて使用できます。 カスタム コードをコンパイルして、グローバル アセンブリ キャッシュ (GAC) に追加する必要があります。 新しい拡張機能を含めるには、machine.config ファイルを更新する必要もあります。 バインドをインストールした後、拡張機能は WCF-Custom と WCF-CustomIsolated アダプタによって認識されるようになります。
BizTalk Server で BizTalk 管理コンソールを使うと、WCF-BasicHTTP の受信場所を Azure API Management 内のエンドポイントとして公開できます。 Azure portal で API Management を使って、BizTalk Server から API Management を通して SOAP エンドポイントを公開することもできます。 詳しくは、「API Management で BizTalk WCF-BasicHTTP エンドポイントを発行する」をご覧ください。
Azure Integration Services
Azure Integration Services と BizTalk Server で接続モデルが異なる理由の一部は、API 経済の進化によるものです。 基になるシステムとデータへのアクセスを公開する組織が増えるにつれて、プラットフォームに依存しないアプローチが必要になりました。 現在では、REST が最新の Web サービスを設計するための主要なアーキテクチャ アプローチです。
Azure Logic Apps では、REST がシステムを接続するための既定のアプローチです。 Microsoft や他のソフトウェア ベンダーにより、システムとデータを基にして RESTful サービスが公開されているので、Azure Logic Apps ではこの種類の情報を公開して使用できます。 OpenAPI 仕様を使うと、人間とコンピューターの両方が、メタデータを介したクライアントとサーバー間の相互作用を理解できます。 この理解の一環として、要求ペイロードと応答ペイロードの両方が派生します。つまり、動的コンテンツを使ってワークフロー アクションの入力を設定し、ダウンストリーム アクションで応答からの出力を使用できます。
コネクタが呼び出す基盤サービスを実装するソフトウェア ベンダーに応じて、コネクタにより認証スキームは異なります。 一般に、これらのスキームには次の種類が含まれます。
Microsoft は、保存時と転送中にデータを暗号化することで、強力な保護レイヤーを提供します。 Azure のお客様のトラフィックが、Microsoft または Microsoft の代理によって制御されない物理的境界の外側のデータセンター間を移動するときは、IEEE 802.1AE MAC Security Standards (MACsec) を使用するデータリンク層の暗号化方法が、基になるネットワーク ハードウェアのポイント間で適用されます。
Microsoftは、クラウド サービスとお客様の間を移動するデータを保護するためにトランスポート層セキュリティ (TLS) プロトコルを使用するオプションを提供します。 Microsoft のデータ センターは、Azure サービスに接続するクライアント システムとの TLS 接続をネゴシエートします。 TLS は、強力な認証、メッセージの機密性、整合性 (メッセージの改ざん、傍受、偽造を検出できます) と共に、相互運用性、アルゴリズムの柔軟性、デプロイと使用のしやすさを備えています。
このセクションでは、コネクタを介した RESTful 接続に重点を置きますが、カスタム コネクタ エクスペリエンスを使って SOAP Web サービス接続を実装できます。
アダプターまたはコネクタの使用をブロックする
このセクションでは、BizTalk Server でのアダプターの使用と Azure Integration Services でのコネクタの使用を禁止するためのオプションについて説明します。
BizTalk Server
BizTalk Server には、異なるアプリケーションから特定のアダプターをブロックするという概念は含まれていませんが、それらのアダプターを環境から削除することにより、アプリケーションでの使用を "ブロック" できます。 BizTalk Server のアダプターはプラットフォームの設定の一部であるため、インストールされているアダプターは誰でも使用できます。 また、アダプターごとに特定の受信ハンドラーと送信ハンドラーを定義することもできます。これにより、それらのハンドラーを実行または処理できる BizTalk グループに属するコンピューターを定義します。
Azure Integration Services
Azure Logic Apps のマネージド コネクタを使って、制限されたリソースまたは未承認のリソースに接続することが、組織で許可されていない場合は、ロジック アプリ ワークフローでそれらの接続を作成および使用する機能をブロックできます。 Azure Policy では、ブロックするコネクタに対する接続を作成または使用するのを防止するポリシーを定義して適用できます。 たとえば、セキュリティ上の理由から、特定のソーシャル メディア プラットフォームやその他のサービスまたはシステムへの接続をブロックすることが必要になる場合があります。
メッセージの持続性
このセクションでは、BizTalk Server と Azure Integration Services でのメッセージの永続化について説明します。
BizTalk Server
MessageBox データベースには、永続化ポイントとして機能して、エンドポイントへの送信を試みる前にメッセージをストレージに保持するという、もう 1 つの利点があります。 構成されている再試行回数の上限に達した後でメッセージの送信が失敗した場合、メッセージは中断され、MessageBox に格納されます。
管理者は、中断されているメッセージを BizTalk 管理コンソールから再開できます。 オーケストレーションを使用する場合も同じ動作が発生します。 オーケストレーション ランタイムはビジネス ロジックを保持しており、ユーザーは問題が発生した場合にそれを再開できます。 たとえば、次のシナリオにおいてオーケストレーションでメッセージを再開できます。
- 非アトミック スコープ内で送信されたメッセージ
- トランザクション スコープの最後
- 新しいオーケストレーション インスタンスの開始時 (オーケストレーションの開始図形)
- デバッグ ブレークポイント内
- エンジンが退避を決定したとき
- オーケストレーションが完了したとき
- システムがシャットダウンするとき
BizTalk Server では、これらの機能すべてをすぐに使用できます。 BizTalk Server が自動的に処理するため、永続化の実装について心配する必要はありません。
Azure Integration Services
Azure Logic Apps では、次の方法でメッセージの持続性が提供されます。
ステートフル ワークフロー (従量課金ロジック アプリでは既定、Standard ロジック アプリでは使用可能) には、ワークフローの状態を追跡し、ワークフローのアクションを通過するときにメッセージを格納するチェックポイントがあります。 この機能により、トリガーとワークフロー インスタンス実行履歴に格納されている豊富なデータにアクセスでき、入力と出力の詳細な値を確認できます。
Azure portal または API を使用して、実行インスタンスを再処理できます。 この場合、前の実行でエラーが発生した場所に関係なく、実行インスタンス全体が実行されます。 この動作は、メッセージが "少なくとも 1 回" 配信され、べき等処理がコンシューマーで行われることを意味します。
Azure Service Bus で利用できるピーク ロック メッセージングにより、メッセージの正常な実行後にメッセージをコミットするか、エラーが発生したときにメッセージを破棄することができます。 Azure Logic Apps でこの機能を使うには、Azure Service Bus コネクタを選びます。 コミットされたメッセージはメッセージ キューから削除されますが、破棄されたメッセージはロック解除され、クライアントで処理できます。 ピーク ロックは、"正確に 1 回" のメッセージングを実現するための優れた方法です。
パブリッシュ サブスクライブ アーキテクチャ
このセクションでは、BizTalk Server と Azure Integration Services でパブリッシュ サブスクライブ パターンを実装するためのオプションについて説明します。
BizTalk Server
パブリッシュ サブスクライブ (pub-sub) 機能は、前の「BizTalk Server のしくみ」セクションで説明した MessageBox データベースを使って行われます。 サブスクリプションを作成する一般的な方法は、昇格させたプロパティを使用するものであり、これにより定義されたメッセージ スキーマ内の特定の要素または属性を昇格させたプロパティとして識別できます。 その後、サブスクリプションを確立し、昇格させたプロパティに対する特定の条件に基づいてメッセージをフィルター処理できます。 たとえば、City という名前のスキーマ要素を昇格させた場合、City 要素で特定の都市をフィルター処理するサブスクリプションを作成できます。 条件が満たされた場合、サブスクリプション、送信ポート、またはオーケストレーションはメッセージのコピーを受信します。
Azure Integration Services
BizTalk Server とはアーキテクチャが全く異なる Azure Integration Services では、ほとんどのサービスはイベント ベースです。 パブリッシュ サブスクライブ ソリューションを実装する必要がある場合は、Azure Service Bus を使用できます。 このサービスは、名前空間内にメッセージ キューとパブリッシュ サブスクライブ トピックを含むフル マネージドのエンタープライズ メッセージ ブローカーです。 Azure Service Bus を使うと、アプリケーションとサービスを相互に分離することができ、次のような利点があります。
- 競合する worker 間で処理を負荷分散します。
- サービスとアプリケーションの境界を越えた制御により、データを安全にルーティングおよび転送します。
- 高い信頼性を必要とするトランザクションの作業を調整します。
Azure Logic Apps に含まれる Azure Service Bus コネクタを使って、メッセージのパブリッシュとサブスクライブを行うことができます。 Service Bus を使用する利点は、ワークフローから独立してメッセージングを使用できることです。 BizTalk Server とは異なり、メッセージングはワークフロー プラットフォームから切り離されています。 Azure Integration Services ではメッセージングとワークフローの機能が切り離されていますが、メッセージ プロパティ (ユーザー プロパティ) をサポートするメッセージ サブスクリプションを Azure Service Bus で作成できます。 これらのプロパティを使って、トピック サブスクリプションで作成されたフィルターによって評価されるキーと値のペアを提供します。 これらのユーザー プロパティは、Azure Service Bus 操作を設定するときに、1 つ以上のキーと値のペアを追加することによって定義します。 デモについては、ビデオ「Azure Integration Services を使用する Pub Sub メッセージング - パート 2 コンテンツ ベースのルーティング」をご覧ください。
Azure Integration Services の外部では、Azure Cache for Redis を使ってパブリッシュ サブスクライブのシナリオを実装することもできます。
ビジネス ルール エンジン
このセクションでは、BizTalk Server と Azure Integration Services でビジネス ルールを設定するためのオプションについて説明します。
BizTalk Server
BizTalk Server に含まれるフォワード チェーン ルール エンジンを使うと、ビジュアル エディターで "if-then-else" ルールを構築できます。 これらのルールは、IT ランドスケープ内の他の環境に転送可能なポリシー内にバンドルできます。 これらのポリシーでは、XSD スキーマ、.NET Fx コード、SQL Server データベースのテーブルにアクセスして、データを検索し、出力をエンリッチすることもできます。
Azure Integration Services
現在、Azure に同等のルール エンジン機能はありませんが、お客様は Azure Functions でカスタム コードを使ってルールを実装することがよくあります。 その後は、Azure Logic Apps の組み込み Azure Functions コネクタを使って、これらのルールにアクセスします。
この分野での今後の取り組みについて詳しくは、このガイドで後ほど説明する「ロード マップ」セクションをご覧ください。
データの変換
このセクションでは、BizTalk Server と Azure Integration Services でのデータ変換機能について説明します。
BizTalk Server
XML メッセージをある形式から別の形式に変換するための豊富なツールを提供します。 データ変換で使われる XSLT マップでは、カスタム .NET Fx コードをこれらのマップの中間に挿入できる拡張オブジェクトがサポートされています。 また、リッチなマップを構築するのに役立つ再利用可能な機能を提供する、そのまま使える Functoid を使用することもできます。
コア XML 変換以外に、BizTalk Server には CSV および JSON 形式のエンコードとデコードも用意されているため、これらの形式と XML の間で変換を行ってさまざまな形式をサポートできます。
Azure Integration Services
Enterprise Integration Pack
このコンポーネントは BizTalk Server での同様の概念に従っており、Azure Logic Apps で B2B 機能を簡単に使用できます。 ただし、大きな違いの 1 つは、Enterprise Integration Pack のアーキテクチャは統合アカウントに基づいていることです。 これらのアカウントを使うと、B2B のシナリオで取引先、契約、マップ (XSLT または Liquid テンプレート)、スキーマ、証明書などの成果物を格納、管理、使用する方法が簡単になります。
Liquid テンプレート
ロジック アプリ ワークフローでの基本的な JSON 変換の場合は、Compose アクションや Parse JSON アクションなどの組み込みのデータ操作を使用できます。 ただし、一部のシナリオでは、反復、制御フロー、変数などの要素を含む高度で複雑な変換が必要になる場合があります。 JSON から JSON、JSON からテキスト、XML から JSON、または XML からテキストへの変換の場合、Liquid オープンソース テンプレート言語を使って、必要なマッピングまたは変換を記述する Liquid テンプレートを作成できます。
EDI スキーマ
EDI ドキュメント スキーマでは、EDI トランザクション ドキュメントの種類の本体を定義します。 ロジック アプリ ワークフローでは、Microsoft Integration GitHub リポジトリ内のすべての BizTalk EDI スキーマを、誰でも使用できます。
Standard ロジック アプリ
Azure portal では、マップとスキーマを Standard ロジック アプリ リソースに直接アップロードできます。 Visual Studio Code で Standard ロジック アプリ プロジェクトを使っている場合は、統合アカウントを使わずに、Artifacts フォルダー内のそれぞれのフォルダーにこれらの成果物をアップロードできます。 XSLT マップからコンパイル済みのカスタム アセンブリを呼び出すこともできます。
Azure Functions
C# または他のプログラミング言語を使って XSLT または Liquid テンプレート変換を実行し、Azure API Management または Azure Logic Apps で呼び出すことができる Azure 関数を作成できます。
ネットワーク接続
このセクションでは、BizTalk Server と Azure Integration Servicesで のネットワーク接続機能について説明します。
BizTalk Server
BizTalk Server は常にサーバー環境にインストールされるので、ネットワーク接続は基になるサーバーのネットワーク構成に依存します。 BizTalk Server のネットワーク接続を設定するときは、通常、次のものを構成する必要があります。
- 依存関係
- エンド システムへのインバウンドとアウトバウンドの接続
依存関係の構成
マルチサーバー環境で BizTalk Server を完全に構成するには、ネットワーク接続のすべての依存関係に特に注意する必要があります。これには、通常、既知のサービスまたはプロトコル用に TCP と UDP ポートを有効にするためのファイアウォール構成が含まれます。 たとえば、このようなサービスとプロトコルには、SQL Server エンジン、Microsoft 分散トランザクション コーディネーター (MSDTC)、クラスター化されたネットワーク ドライブ、別のサーバーにインストールされている場合の SSO サービス、SharePoint へのアクセスが含まれ、インバウンドとアウトバウンドの規則を作成することですべてのサービスを構成して接続を実装する必要があります。
インバウンドとアウトバウンドの接続構成
BizTalk Server を完全に設定し、アプリケーションをデプロイする準備ができたら、ホスト インスタンスが、内部または外部どちらのネットワークに存在しても、さまざまなサービスに接続してアクセスできるようにするファイアウォール規則を実装します。 組織ネットワークの外部にあるエンド システムへの接続を検討する場合は、セキュリティに関しても考慮する必要があります。 さまざまなシステムは、防御の最前線として許可された IP アドレスのリストの定義に依存するため、BizTalk Server では、すべてのアウトバウンド通信をパブリック IP アドレスの明確に定義されたリストを介してルーティングするのが理想的です。
パートナー サービスが BizTalk Server にアクセスしようとするときは、組織のコア サービスを利用できる可能性がある組織のネットワークまたは内部レイヤー内にあるインスタンスに到達しないようにします。 代わりに、パートナー サービスには、組織のネットワークの最も外側の境界である境界ネットワーク (非武装地帯 (DMZ) とも呼ばれます) 内に存在するエンドポイントにアクセスさせます。 ただし、BizTalk Server がメッセージをルーティングする必要がある先のサービスは、通常、組織のネットワーク内に存在するため、その内部レイヤーにアクセスできる必要があります。
これらのシナリオを実現するには、次のような複数のアプローチが存在します。
- BizTalk Server を境界ネットワークに実装し、その独自のサービス (ホスト インスタンス) のみに組織のネットワークへのアクセスを許可します
- 2 つの BizTalk Server を、1 つは境界ネットワーク内、もう 1 つは組織のネットワーク内に設定します。 その後、境界ネットワーク内のサーバーで、組織ネットワーク内のサーバーが使用するメッセージを発行します。
- リバース プロキシとして機能し、境界ネットワーク内で BizTalk の代わりにメッセージを受信し、それらの呼び出しを BizTalk Server にリダイレクトすることができる、NetScaler や F5 などのカスタム アプリケーションまたはアプライアンス ソフトウェアを開発します。
Azure Integration Services
受信接続と送信接続
Azure には、ネットワーク境界内のサービスを分離し、オンプレミスとクラウドのワークロードを接続するための、複数の方法が用意されています。 次の一覧では、Azure リソースとネットワーク境界内のリソースを統合できるさまざまな方法について説明します。
オンプレミスのデータ ゲートウェイ
このゲートウェイは、Azure とネットワーク境界内のリソースの間のブリッジとして機能し、オンプレミスのデータとさまざまな Microsoft クラウド サービスの間の迅速で安全なデータ転送を提供します。 このようなサービスとしては、Azure Logic Apps、Microsoft Power BI、Microsoft Power Apps、Microsoft Power Automate、Azure Analysis Services などがあります。 このゲートウェイを使うと、オンプレミス ネットワーク内にデータベースや他のデータ ソースを維持し、そのオンプレミス データをクラウド サービスで安全に使用できます。
ハイブリッド接続
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] (アウトバウンド トラフィック) ボックスで強調されているように、仮想ネットワーク統合が有効になっています。 この構成により、すべてのアウトバウンド トラフィックがこの仮想ネットワークから送信されます。
![Azure portal の Standard ロジック アプリ リソースの [ネットワーク] ページで仮想ネットワーク統合が有効になっていることを示すスクリーンショット。](media/biztalk-server-to-azure-integration-services-overview/standard-logic-app-networking-page-virtual-network-integration.png)
プライベート エンドポイント
"プライベート エンドポイント" は、仮想ネットワークのプライベート IP アドレスを使用するネットワーク インターフェイスです。 このネットワーク インターフェイスは、Azure Private Link を利用する Azure リソースに、非公開で安全に接続します。 プライベート エンドポイントを有効にすることで、その Azure リソースが仮想ネットワークに取り込まれ、ネットワーク内のリソースで Azure リソースへのインバウンド呼び出しを行えるようになります。
次の表では、各 Azure Integration Services リソースで使用できるネットワーク接続方法を示します。
| リソース | オンプレミスのデータ ゲートウェイ | ハイブリッド接続 | 仮想ネットワークの統合 | プライベート エンドポイント |
|---|---|---|---|---|
| Azure API Management | ✅ | ✅ | ✅ | |
| Azure Logic Apps (従量課金) | ✅ | |||
| Azure Logic Apps (Standard) | ✅ (Azure コネクタを使用) |
✅ (組み込みコネクタを使用) |
✅ (組み込みコネクタを使用) |
✅ |
| Azure Service Bus | ✅ | ✅ | ||
| Azure Event Grid |
カスタム コード
このセクションでは、BizTalk Server と Azure Integration Services で独自のコードを作成して実行するためのオプションについて説明します。
BizTalk Server
BizTalk を拡張するには、カスタム .NET Fx コードなどの多くの方法を使用できます。
| 機能 | 説明 |
|---|---|
| インライン コード | オーケストレーションの図形内にインライン C# コードを記述できます。 BizTalk マップ内でインライン コードを記述することもできます。 どちらのシナリオでも、コード スニペットはその性質上一般的に単純であり、デバッグできません。 |
| コンパイル済みアセンブリ | これらのアセンブリは、次の場所から呼び出すことができます。 - オーケストレーション内の式の図形 - BizTalk マップ (スクリプト Functoid を使用) - ビジネス ルール エンジンのポリシー - パイプライン (カスタム パイプライン コンポーネントとして) Visual Studio デバッガーを適切なホスト インスタンスの Windows プロセスにアタッチすることで、コンパイル済みアセンブリをデバッグできます。 |
| カスタム アダプター | BizTalk Server にはそのまま使用できるアダプターが多数含まれていますが、必要に応じていつでも独自のアダプターを作成できます。 |
| カスタム WCF の動作 | BizTalk Server には、そのまま使用できるアダプターが多数含まれており、大部分は Windows Communication Foundation (WCF) が基になっています。 システム通信への OAuth ヘッダーの適用など、場合によっては、カスタム動作を開発して機能を拡張することが必要になります。 |
| BizTalk Server のマップでの拡張性 | - C#、JScript、Visual Basic、XSLT、または XSLT 呼び出しテンプレートを使ってインライン コードを作成し、既製の Functoid を使う場合の制限や困難を抑制できます。 - スクリプト Functoid を使って外部アセンブリを呼び出すことができます。 - すべてのマップで使用するカスタム Functoid を作成できます。 |
Azure Integration Services
Azure Functions には、Azure Logic Apps 内の Azure Functions コネクタから実行できるコードを記述する機能があります。 Functions プラットフォームでは、さまざまなプログラミング言語とランタイムがサポートされており、高い柔軟性が提供されます。 これらの機能は、一般に、実行時間が短くなるように設計されており、ローカル環境での開発とデバッグをサポートするための豊富な開発者ツール セットが存在します。
Azure Logic Apps のインライン コード コネクタには、JavaScript コードの実行というアクションが用意されています。 このアクションを使って、JavaScript で小さなコード スニペットを記述できます。 これらのコード スニペットは、実行時間が短く、コンテンツの動的な入力と出力をサポートすることも想定されています。 コードを実行した後の出力を、ワークフロー内のダウンストリーム アクションで使用できます。 現在、このアクションを直接デバッグするためのサポートはありませんが、ワークフロー インスタンスの実行履歴で入力と出力を見ることができます。
「再利用可能なコンポーネント」セクションで説明したように、XSLT マップから .NET Fx アセンブリを呼び出すサポートは、現在、従量課金ロジック アプリ ワークフローでそれらのアセンブリを統合アカウントにアップロードするときに使用できます。 この機能は、カスタム データ変換ルールをサポートするのに役立ちます。 Standard ロジック アプリ ワークフローについては、最近、統合アカウントを必要とせずに XSLT マップから .NET Fx コードを呼び出すためのサポートを、Azure Logic Apps チームがリリースしました。 また、Visual Studio Code でアセンブリとマップを Standard ロジック アプリ プロジェクトに追加した後、Azure にデプロイすることもできます。 詳しくは、「Azure Logic Apps (Standard) XSLT 変換に追加された .NET Framework アセンブリのサポート」および「ロード マップ」セクションをご覧ください。
また、Azure App Service で作成した Azure API アプリまたは Web アプリを含めることで、ワークフローを拡張することもできます。 Web アプリ、REST API、モバイル バックエンドをホストする必要がある場合、Azure App Service は HTTP ベースの頼りになるソリューションです。 Azure App Service でホストされているアプリとオンプレミスまたはクラウドのサービスを統合できます。 このプラットフォームは、アプリケーションを実行およびスケーリングするための Windows ベースと Linux ベース両方の環境と、さまざまな言語やフレームワーク (ASP.NET Core、Java、Ruby、Node.js、PHP、Python など) をサポートします。
アプリケーション グループ
このセクションでは、BizTalk Server と Azure Integration Services でワークロードを整理するためのオプションについて説明します。
BizTalk Server
ソフトウェア開発ライフサイクルの一部として、論理パッケージでのコードと成果物のビルドと管理が含まれます。 BizTalk Server では、Visual Studio ソリューションを BizTalk アプリケーションにデプロイできるアプリケーションの概念がサポートされています。 そのため、リソースを共有する必要があるシナリオがある場合は、他のアプリケーションを参照できます。
BizTalk Server で使われる明示的な共有モデルでは、コンパイル済みアセンブリへの参照を追加できます。 これらのアセンブリがグローバル アセンブリ キャッシュ (GAC) にある場合、BizTalk ランタイムは必要に応じてアセンブリを検索して読み込みます。 1 つの欠点は、共有アセンブリを更新する必要がある場合は、バージョン管理スキームを実装しない限り、更新を行う前に、アセンブリを参照するすべての BizTalk プロジェクトをアンインストールする必要があるということです。 この制限により、デプロイのタイムラインが長くなり、複数のインストールとアンインストールの管理が複雑になることがあります。
Azure Integration Services
Azure Logic Apps では、従量課金ロジック アプリ リソースに含まれるステートフル ワークフローは 1 つだけです。つまり、ワークフローとロジック アプリ リソース (アプリケーション) の間には、常に 1 対 1 のリレーションシップがあります。 Standard ロジック アプリ リソースでは、アプリケーションの概念が進化しました。 Standard ロジック アプリ リソースがアプリケーションであることに変わりはありませんが、このリソースに複数のワークフローを含めて実行すると、1 対多のリレーションシップになります。 ローカル環境の Visual Studio Code で Standard ロジック アプリ プロジェクトの作業を行っている場合、ロジック アプリ リソースはこの 1 つのプロジェクトにマップされます。 この方法を使うと、関連するワークロード、コード、成果物を同じプロジェクトに簡単かつ論理的にグループ化し、そのプロジェクトを 1 つのユニットとしてデプロイできます。
クラウド アーキテクチャの動作は、BizTalk などのサーバー ベースのパラダイムとは異なります。 Azure Logic Apps (Standard) では、コードと成果物を取り込むためにプル モデルが使われます。 その結果、成果物を追加する必要がある場合は、それをプロジェクトにコピーした後、コードや他の成果物と共にデプロイします。 場合によっては、必要なすべてのコードと成果物のコピーを不要にしたいことがあります。 その場合は、個別に管理できるが、ワークフローから呼び出すことができるサービスに、この機能を変換することを検討できます。
たとえば、組織で広く使われているデータ変換があるとします。 複数のロジック アプリ プロジェクトに変換のマップを含めるのではなく、変換をサービスとして提供するインターフェイスを実装できます。 その後は、そのサービスのライフサイクルをロジック アプリ プロジェクトとは別に管理し、ワークフローからそのサービスを呼び出すことができます。
Standard ロジック アプリ プロジェクトに複数のワークフローを含める機能では、1 つまたは複数のプロジェクトでそれらのワークフローを整理する方法を疑問に思う場合があります。 それに対する答えは、通常、要件によって異なります。次に例を示します。
- ビジネス プロセス アフィニティ
- エンド ツー エンドの監視とサポート
- セキュリティ、ロールベースのアクセス制御、ネットワークの分離
- パフォーマンスとビジネスの重要度
- 地理的な場所と geo 冗長性
詳しくは、Azure Logic Apps (Standard) でのロジック アプリ ワークフローの整理に関する記事をご覧ください。
セキュリティとガバナンス
セキュリティとガバナンスは、統合ソリューションを構築する際に当然重要です。 定義上、ミドルウェアは 2 つ以上のシステムの間に存在します。 接続を確立するときにこれらのシステムに接続してアクセスするには、多くの場合、資格情報またはシークレットを渡す必要があるため、この機密情報の管理についてよく考える必要があります。
BizTalk Server
BizTalk に含まれる Enterprise Single Sign-On (SSO) を使うと、アダプターによって使われる暗号化された資格情報を格納、マップ、送信できます。 この暗号化された情報は、SSO データベースに格納されます。 接続するシステムまたは基幹業務システムを表す論理エンティティである SSO 関連アプリケーションを構成することもできます。
Azure Integration Services
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
一部のコネクタでは、Microsoft Entra ID によって保護されているリソースへのアクセスの認証に対するマネージド ID の使用がサポートされています。 接続を認証するためにマネージド ID を使用する場合は、資格情報、シークレット、または Microsoft Entra トークンを指定する必要はありません。
アプリケーションの管理とアクセスの管理
このセクションでは、BizTalk Server と Azure Integration Services でアプリケーションとアクセスを管理するためのオプションについて説明します。
BizTalk Server
管理者は、BizTalk Server 管理者コンソールを使って BizTalk Server アプリケーションを管理します。 このツールは Microsoft 管理コンソール (MMC) のシック クライアント アプリケーションであり、管理者はそれを使って、アプリケーションを展開したり、トランザクション (以前のもの、アクティブなもの、キューに登録されたもの) を確認したり、トレースの確認やトランザクションの再送信などの詳細なトラブルシューティング アクティビティを実行したりできます。
Azure Integration Services
Azure portal は、管理者とサポート担当者がインターフェイスの正常性を表示および監視するために使用する一般的なツールです。 Azure Logic Apps の場合、このエクスペリエンスには、実行履歴で使用できる豊富なトランザクション トレースが含まれます。
きめ細かいロールベースのアクセス制御 (RBAC) も使用できるため、さまざまなレベルで Azure リソースへのアクセスを管理および制限できます。
ストレージ
このセクションでは、BizTalk Server と Azure Integration Services でのデータ ストレージのオプションについて説明します。
BizTalk Server
BizTalk Server は、データ ストアとデータの永続化について SQL Server に大きく依存しています。 BizTalk Server の他のすべてのコンポーネントとホストには、さまざまなビジネス アプリケーションの統合において固有の役割があります (メッセージの受信、処理、ルーティングなど)。 一方、データベース コンピューターは、この作業をキャプチャしてディスクに保持します。 たとえば、BizTalk Server が受信メッセージを受け取ると、受信ホストはそのメッセージを MessageBox データベースに保存し、他のホストはオーケストレーション処理や送信のためにそこからメッセージを取得します。
SQL データベースのプロビジョニングと管理では、高可用性がアップタイムを保証するための重要なアーキテクチャ コンポーネントです。 BizTalk Server データベースの高可用性を提供するため、お客様は、多くの場合、Windows クラスタリングを使って、SQL Server を実行する 2 台以上のコンピューターを含むサーバー クラスターを作成します。 このサーバー クラスターにより、BizTalk Server データベースの冗長性とフォールト トレランスが提供されます。 コンピューターのグループが連携して可用性とスケーラビリティを高める負荷分散クラスタリングとは異なり、サーバー クラスタリングでは、通常、データベース コンピューターのペアがアクティブ パッシブ構成で使用され、一方のコンピューターが他のコンピューターのバックアップ リソースを提供します。
Azure Integration Services
Azure Logic Apps は、Azure Storage を利用して、データを格納し、自動的に保存データを暗号化します。 この暗号化によってデータが保護され、組織のセキュリティとコンプライアンスの要件を満たすことができます。 既定では、Azure Storage は Microsoft マネージド キーを使用してデータを暗号化します。 詳細については、「保存データ向け Azure ストレージの暗号化」をご覧ください。
Azure portal で Azure Storage を操作するときは、すべてのトランザクションが HTTPS 経由で行われます。 また、HTTPS 経由で Storage REST API を使って Azure Storage を操作することもできます。 REST API を呼び出してストレージ アカウント内のオブジェクトにアクセスするときに HTTPS の使用を強制するには、ストレージ アカウントに必要なセキュリティ保護された転送を有効にします。
データの構成
環境間で統合ソリューションを移動するときに、コードの再コンパイルや再アセンブルが必要ないようにするには、構成とコードの分離が重要になります。 通常、構成情報は環境に固有であるため、ランドスケープ全体にソリューションをデプロイするときに変更する必要があるエンドポイントやその他の詳細を定義できます。
BizTalk Server
BizTalk NT Service の実行可能ファイル
この実行可能ファイルは、BTSNTSvc.exe.config という名前の app.config ファイルを呼び出します。このファイルでは、クリア テキストで構成情報を格納できるよう、キーと値のペアが提供されます。 ただし、このファイルでは次の考慮事項に注意してください。
BizTalk グループ内のすべてのコンピューターに構成を慎重にレプリケートします。
構成を変更したら、ホスト インスタンスを再起動して、この構成ファイルの最新の値を取得する必要があります。
この構成ファイルに構文エラーがあると、ホスト インスタンスは開始できず、ダウンタイムが発生します。
Enterprise SSO ツール
このツールを構成ストアとして使うこともできます。 Enterprise SSO を使ったデータ管理を有効にするには、コミュニティ ツールも利用できます。 その後、SDK ツールを使ってこのデータにアクセスし、実行時にこのデータを取得できます。
カスタム キャッシュ コンポーネント
これらのコンポーネントは、多くの場合、キーと値のペアでは対応できないユース ケースに対処するために導入されます。 たとえば、SQL Server データベースに表形式のデータを格納し、ホスト インスタンスの起動時にそのデータをメモリに読み込むとします。 この実装を使うと、BizTalk Server は、カスタム .NET Fx コードを実行することによって実行時にこの情報を取得できます。 その後、オーケストレーション、BizTalk マップ、カスタム パイプライン コンポーネントからこのデータにアクセスできます。
カスタム データベース
データベースは、開発者と管理者の両方がよく知っているテクノロジと言語であるため、カスタム データベースは、アプリケーション構成データを格納するためのもう 1 つの一般的なオプションです。
ビジネス ルール エンジン (BRE)
主要なユース ケースではありませんが、BRE は構成ストアとしても機能できます。 オーケストレーションまたはパイプライン コンポーネントのどちらからエンジンを呼び出す場合でも、BRE ポリシーで環境固有の情報を定義し、対応するポリシーを関連する環境にデプロイできます。 実行時には、オーケストレーションまたはパイプライン コンポーネントでこの情報にアクセスし、マップなどのダウンストリーム機能やルーティング状況で使用できます。
カスタム構成ファイル
カスタム構成 (.config) ファイルを使ってアプリケーションの構成データを格納できますが、おそらく、すべての環境でこれらのファイルに静的で固定の場所を維持する必要があるため、この方法は一般的ではありません。
Windows レジストリ
アプリケーションの構成値を格納するための有効なオプションとして、Windows レジストリを使用できます。 このレジストリは、1 つ以上のユーザー、アプリケーション、ハードウェア デバイス用にシステムを構成するために必要な情報を格納するため、Microsoft Windows オペレーティング システムによって使われる中央階層データベースです。 レジストリには、ハイブ、キー、値という基本的な要素が含まれています。 ただし、レジストリに格納されている値を維持することは、複数のレジストリを持つ大規模な環境では困難であり、個々のアプリケーション設定をバックアップするのが難しい場合があります。
Azure Integration Services
Azure Key Vault
このサービスは、暗号化キーと、アプリケーションやクラウド サービスで使われる他のシークレットを、格納して保護します。 セキュリティ保護されたキーの管理はクラウド内のデータを保護するために不可欠であるため、Azure Key Vault を使って、キーとシークレット (パスワードなど) を暗号化して格納します。
Azure App Configuration
このサービスは、アプリケーションの設定と機能フラグを一元的に管理します。 世界中のホストされた場所にあるすべての Azure アプリの構成を格納できます。 時間のかかる再デプロイを回避することで、顧客に影響を与えることなく、リアルタイムで構成を効果的かつ確実に管理します。 Azure App Configuration は、速度、スケーラビリティ、セキュリティのために構築されています。
Azure Cosmos DB
このサービスは、最新のアプリ開発のためのフル マネージド NoSQL データベースであり、10 ミリ秒未満の応答時間と、すべての規模で速度を保証する自動的で瞬時のスケーラビリティを備えています。 構成データを Azure Cosmos DB に読み込んでから、Azure Logic Apps で Azure Cosmos DB コネクタを使ってそのデータにアクセスできます。
Azure Table Storage
このサービスでは、構成データを低コストで保持するための別のストレージ機能が提供されます。 このデータには、Azure Logic Apps で Azure Table Storage コネクタを使って簡単にアクセスできます。 詳しくは、Azure Table Storage に関する記事をご覧ください。
カスタム キャッシュ
Azure Integration Services を使ってカスタム キャッシュ ソリューションを実装することもできます。 一般的な方法としては、Azure API Management と Azure Cache for Redis でのキャッシュ ポリシーの使用があります。
カスタム データベース
データベースは、開発者と管理者の両方がよく知っているテクノロジと言語であるため、カスタム データベースは、アプリケーション構成データを格納するためのもう 1 つの一般的なオプションです。
大きなファイルの処理
このセクションでは、BizTalk Server と Azure Integration Services で大きなファイルを処理するためのオプションについて説明します。
BizTalk Server
大きなファイルの処理に対処するため、BizTalk Server には次のプロファイルに基づく最適化が含まれます。
メッセージ ルーティングのみ
昇格させたメッセージ プロパティに基づくメッセージのルーティングにのみ BizTalk Server を使う場合、メッセージは .NET XmlReader インターフェイスを使って MessageBox データベースにストリーミングされます。 BizTalk Server では個々のメッセージの部分はメモリに読み込まれないので、このシナリオではメモリ不足エラーは問題になりません。 一方で、主な考慮事項は、MessageBox データベースに非常に大きなメッセージ (100 MB 超) を書き込むのに必要な時間です。 BizTalk Server の開発チームは、ルーティングを実行するだけのときは、最大 1 GB までのメッセージの処理で問題がないことをテストしています。 詳しくは、「パイプラインのパフォーマンスの最適化」をご覧ください。
マップを使用したデータ変換
BizTalk Server でマップを使ってドキュメントを変換すると、多くのメモリを消費する可能性があるこの操作によって、メッセージが .NET XslCompiledTransform クラスに渡され、XSL スタイル シートが読み込まれます。 読み込み操作が正常に完了した後は、複数のスレッドで同時に Transform メソッドを呼び出すことができます。 詳しくは、「XslCompiledTransform クラス」をご覧ください。
BizTalk Server は、変換中にメモリに読み込まれるドキュメントに関する構成可能なメッセージ サイズしきい値を実装することにより、大きなドキュメントのメモリ管理を大幅に改善します。 既定のメッセージ サイズしきい値は 1 MB です。 サイズがこのしきい値より小さいメッセージの場合、BizTalk Server はメモリ内でメッセージを処理します。 メッセージのサイズがこのしきい値を超える場合、BizTalk Server は必要なメモリを減らすため、メッセージをファイル システムにバッファーします。
Azure Integration Services
BizTalk Server などのオンプレミスのミドルウェア プラットフォームと、Azure Logic Apps などの PaaS オファリングの間には、大きなファイルの処理に関していくつかの基本的な違いがあります。 たとえば、最新のクラウド環境ではこの問題を解決する方法が異なる可能性があるため、大きなメッセージのシナリオを慎重に調べて、適切なソリューションを見つけます。
ファイル サイズ制限
Azure では、一貫した信頼性の高いエクスペリエンスを保証するため、ファイル サイズの制限が存在します。 シナリオの確認については、Azure Logic Apps でのサービスの制限に関するドキュメントをご覧ください。 一部のコネクタでは、既定のメッセージ サイズ制限 (コネクタによって異なります) を超えるメッセージのメッセージ チャンクがサポートされています。 メッセージ チャンクにより、大きなメッセージは小さなメッセージに分割されます。
メッセージのサイズに制限があるサービスは、Azure Logic Apps だけではありません。 たとえば、Azure Service Bus にもそのような制限があります。 Azure Service Bus での大きなメッセージの処理について詳しくは、「大きいメッセージのサポート」をご覧ください。
クレーム チェック パターン
ファイル サイズの制限を回避するには、クレーム チェック パターンを実装できます。これは、大きなメッセージを "クレーム チェック" とペイロードに分割することで機能します。 クレーム チェックはメッセージング プラットフォームに送信し、ペイロードは外部サービスに格納します。 こうすることで、大きなメッセージを処理しながら、メッセージ バスとクライアントを過負荷から保護できます。 また、通常はストレージの方がメッセージング プラットフォームで使われるリソース ユニットより安いので、このパターンはコストの削減にも役立ちます。
Azure Data Factory
Azure Data Factory には、大きなファイルを処理するための別のオプションがあります。 このサービスは、直感的な作成と単一ウィンドウの監視と管理のための、コード不要のビジュアル エクスペリエンスを備えた、スケーラブルなサーバーレス データ統合とデータ変換に関する Azure の ELT オファリングです。 また、既存の SQL Server Integration Services (SSIS) パッケージを Azure にリフト アンド シフトし、Azure Data Factory と完全に互換性があるように実行することもできます。 SSIS Integration Runtime によってフル マネージド サービスが提供されるため、インフラストラクチャの管理について心配する必要はありません。 詳しくは、「SQL Server Integration Services ワークロードをクラウドにリフト アンド シフトする」をご覧ください。
オンプレミスのアーキテクチャでは、SSIS が、データベースへの大きなファイルの読み込みを管理するための一般的なオプションでした。 クラウドでそのアーキテクチャに相当する Azure Data Factory は、ファイル システム、データベース、SAP、Azure Blob Storage、Azure Data Explorer、Oracle、DB2、Amazon RDS など、さまざまなデータ ソース間での大きなデータセットの変換と移動に対応できます。 大きなデータを処理する必要があるときは、Azure Logic Apps と Azure Service Bus より優れたオプションとして Azure Data Factory の使用を検討してください。
監視とアラート
BizTalk Server
-
このツールは MMC スナップインであり、BizTalk Server 環境の正常性の監視と、メンテナンス タスクの実行に使用できます。 機能には、MsgBox Viewer (MBV) レポート、ターミネータ ツール タスク、メール通知、レポート コレクション、perfmon の統合が含まれます。
-
このツールも管理者用の MMC スナップインであり、エラー、中断されたインスタンス、現在再試行されているトランザクション、状態などを検出できます。 常にコンソールを更新して最新の情報を確認する必要があるため、このツールのエクスペリエンスは本質的に反応が非常に優れています。
-
BizTalk Server 環境を完全に制御できる外部 Web ソリューション。 この 1 つのツールで、BizTalk Server の操作、監視、分析の機能が提供されます。
Azure Integration Services
-
Azure リソースを監視するには、このサービスと共に、クラウドとオンプレミスの環境からのテレメトリ データを収集、分析、処理するための包括的なソリューションとして Log Analytics の機能を使用できます。
Azure Logic Apps では、次のオプションを使用できます。
従量課金ロジック アプリ ワークフローの場合は、Logic Apps 管理ソリューション (プレビュー) を Azure portal にインストールし、診断データを収集するように Azure Monitor ログを設定できます。 そのデータを Azure Log Analytics ワークスペースに送信するようにロジック アプリを設定すると、Logic Apps 管理ソリューションで正常性を表示できる場所にテレメトリが送られます。 詳細については、「Azure Monitor ログを設定し、Azure Logic Apps の診断データを収集する」を参照してください。 診断を有効にすると、Azure Monitor を使って、トリガーや実行が失敗した場合など、さまざまな種類のシグナルに基づいてアラートを送信することもできます。 詳細については、「Azure Logic Apps での実行状態の監視、トリガー履歴の確認、アラートの設定」を参照してください。
Standard ロジック アプリ ワークフローの場合、ロジック アプリ リソースの作成時に Application Insights を有効にして、診断ログとトレースをロジック アプリのワークフローから送信できます。 Application Insights では、アプリケーション マップを見て、インターフェイスのパフォーマンスと正常性の特性をよりよく理解できます。 Application Insights には、エンドポイントを事前に呼び出し、特定の HTTP 状態コードまたはペイロードの応答を評価する合成テストを構成するための、可用性機能も含まれています。 ユーザーが構成した条件に基づいて、関係者に通知を送ったり、Webhook を呼び出して他のオーケストレーション機能を使ったりすることができます。
Serverless 360 は Kovai の外部ソリューションであり、Azure Logic Apps、Azure Service Bus、Azure API Management、Azure Functions などの Azure サービスのマッピングを通じて監視と管理を提供します。 Azure Service Bus の配信不能キューを使ってメッセージを再処理したり、断続的なサービスの中断に対処するために自己復旧を有効にしたり、代理トランザクションによるプロアクティブな監視を設定したりできます。
カスタム監視ルールを構成し、ポータル エクスペリエンスでログを表示できます。 メール、Microsoft Teams、ServiceNow など、さまざまなチャネルを通じて通知を送ることができます。 インターフェイスの正常性を目で見て判断するには、サービス マップを使用できます。
ビジネス アクティビティの監視
このセクションでは、BizTalk Server と Azure Integration Services でワークロードのテレメトリを監視および収集するためのオプションについて説明します。
BizTalk Server
BizTalk Server に含まれるビジネス アクティビティの監視 (BAM) と呼ばれる機能を使うと、開発者とビジネス アナリストは、オーケストレーションに適用できる追跡プロファイルを定義できます。 メッセージが受信ポートと送信ポートを通過すると、データ属性がキャプチャされて、BAM データベースに格納されます。 カスタム実装は、.NET Fx API で使うこともできます。
Azure Integration Services
Azure には同等のビジネス アクティビティ監視機能はありませんが、Application Insights や他のデータ プラットフォームなどの機能を使って、カスタム ソリューションを構築できます。 ワークフローの実行全体で、これらのデータ ストアに関連情報を送信するコードまたは構成をインストルメント化し、そこで Power BI を使って追加の分析と視覚化を実行できます。 この分野での今後の取り組みについて詳しくは、このガイドで後ほど説明する「ロード マップ」セクションをご覧ください。
もう 1 つのオプションとして、Serverless 360 という名前の Kovai の外部ソリューションを使うこともできます。 監視プラットフォームと共に、クラウドネイティブとハイブリッドの統合全体でビジネス プロセス フローをエンド ツー エンドで追跡するビジネス アクティビティの監視機能を使用できます。 開発者は、この機能に含まれるマネージド コネクタを使って、コードをインストルメント化し、重要なビジネス データをキャプチャできます。 その後、管理者は、ダッシュボードを構築してビジネス アナリストと共有できます。
追跡
このセクションでは、BizTalk Server と Azure Integration Services でパフォーマンス監視と正常性分析のために成果物を追跡するためのオプションについて説明します。
BizTalk Server
メッセージの追跡
BizTalk Server 管理者は、メッセージ本文の追跡を使って、トラブルシューティングと監査のためにメッセージ本文をストレージに保持するタイミングを示すことができます。 メッセージの追跡は、パフォーマンスとストレージの両方の点で高コストの操作であるため、この機能はパフォーマンスの問題を回避するために選択的に使ってください。 受信ポートと送信ポートでメッセージ本文の追跡を有効にすると、BizTalk Server は、TrackedMessages_Copy_<MessageBox 名>.という名前の SQL Server エージェント ジョブを使って、BizTalk Tracking データベース (BizTalkDTADb) にデータをコピーします。
オーケストレーション、パイプライン、受信ポート、送信ポート、スキーマ、ビジネス ルールなど、ほぼすべての BizTalk Server 成果物に追跡を適用できます。 これらのオプションは、コード (ソリューション) に影響を与えたり、再起動を必要としたりすることなく、実行時に有効または無効にされます。
状態と動作状況の追跡 (HAT)
HAT ツールは BizTalk Server 2009 エディション以降で削除されましたが、この機能は BizTalk 管理コンソールにまだ存在します。 管理者は、[グループの概要] エクスペリエンスの [新しいクエリ] インターフェイスを使ってデータを検索できます。 イベントの種類、ポート名、URI、スキーマ名など、さまざまな条件に基づいてクエリを調整できます。 受信または送信ポートを通過したメッセージの本文を確認したい場合は、ポート レベルの追跡を有効にしてあれば、この情報にアクセスできます。 詳しくは、「状態と動作状況の追跡」をご覧ください。
Application Insights および Azure Event Hubs との統合
BizTalk Server 2016 Feature Pack 1 の時点では、Azure Monitor の Application Insights または Azure Event Hubs にテレメトリを発行できます。 この方法では、SQL Server のディスク容量の問題が回避されるので、Azure Logic Apps で Application Insights、Log Analytics、実行履歴などのクラウドベースのエラスティック データ ストアを代わりに使用できます。
Azure Integration Services
Azure Logic Apps には豊富な実行履歴が用意されているため、開発者とサポート アナリストは、処理されたすべての入力と出力などのアクション テレメトリによってアクションを確認できます。 機密データを保護するには、ワークフロー内の個々のアクションでセキュリティ保護された入力と出力を有効にできます。 この機能は、リークを防ぐために、ログとワークフロー実行履歴のデータを難読化または非表示にします。
データの難読化以外に、Azure RBAC ルールを使ってデータ アクセスを保護できます。 Azure RBAC には、Azure Logic Apps 専用の組み込みロールとして、ロジック アプリ共同作成者とロジック アプリ オペレーターの 2 つが含まれています。
Azure RBAC 以外に、IP アドレス範囲によって Azure Logic Apps の実行履歴へのアクセスを制限することもできます。
Hosting
このセクションでは、BizTalk Server と Azure Integration Services のホスティング オプションについて説明します。
BizTalk Server
BizTalk Server 2020 では、次の Microsoft プラットフォームと製品がサポートされています。
- Windows Server 2019、Windows Server 2016、Windows 10
- Visual Studio 2019 Enterprise、Visual Studio 2019 Professional
- SQL Server 2019、SQL Server 2017、SQL Server 2016 SP2
- Office 2019、Office 2016
BizTalk Server は、独自のハードウェア、オンプレミスの仮想マシン、または Azure 仮想マシンにインストールして実行できます。 Azure Virtual Machines では、BizTalk Server、Windows Server、SQL Server、その他をサポートするさまざまなコンピューティング ソリューションを柔軟に仮想化できます。 現在のすべての世代の仮想マシンに、負荷分散と自動スケーリングが無償で含まれています。
Azure Integration Services
Azure Logic Apps
ホスティング プラン
シングルテナントの Azure Logic Apps では、Standard ロジック アプリは Azure 関数または Web アプリに似ており、1 つのワークフロー サービス プランを使って複数の Standard ロジック アプリをホストできます。 この類似性は、すべてのワークフローを 1 つの Standard ロジック アプリ リソースにデプロイする必要がないことを意味します。 代わりに、これらのワークフローを論理グループ (ロジック アプリ) にまとめて、ソリューションの他の側面をより適切に管理できます。 このアプローチは、ワークフロー サービス プランを最大限に活用し、アプリケーションを将来も利用できるようにするのに役立ち、個別にスケーリングできるように実装できます。
Standard ロジック アプリには、WS1、WS2、WS3 の価格レベルがあります。 提供される機能は、どのレベルでも同じです。 コンピューティングとメモリの要件によって、シナリオに最適なものが決まります。次はその例です。
Pricing tier 仮想 CPU (vCPU) メモリ (GB) WS1 1 3.5 WS2 2 7 WS3 4 14 詳しくは、「標準モデルの価格レベル」をご覧ください。
可用性と冗長性
Azure では、可用性ゾーンによって回復性、分散型可用性、アクティブ アクティブ アクティブ ゾーンのスケーラビリティが提供されます。 ロジック アプリ ワークロードの可用性を高めるには、可用性ゾーンのサポートを有効にできますが、ロジック アプリを作成するときにだけ行うことができます。 ゾーン冗長性がサポートされていて有効にされた Azure リージョンには、少なくとも 3 つの分離された可用性ゾーンが存在する必要があります。 Azure Logic Apps プラットフォームでは、これらのゾーンを配置し、ロジック アプリのワークロードをこれらのゾーン全体に分散します。 この機能は、回復性があるアーキテクチャを有効にするため、およびリージョンでデータセンターの障害が発生した場合に高可用性を提供するための重要な要件です。 詳しくは、「可用性ゾーンを使用した高可用性のためのソリューションの構築」をご覧ください。
分離された専用の環境
Standard ロジック アプリの場合、デプロイ環境として App Service Environment (ASE) v3 を選択できます。 ASE v3 を使うと、予測可能な価格でアプリケーションを大規模に実行するための完全に分離された専用環境が得られます。 作成して実行するロジック アプリの数に関係なく、ASE App Service プランに対してのみ支払います。
Azure Service Bus
Azure Service Bus にはさまざまな価格レベルが用意されているので、ニーズに合った最適なレベルを選べます。 エンタープライズ環境の場合、お客様は通常、Premium または Standard レベルを選びます。 予測可能なパフォーマンスと高度なネットワークのサポートを備えた高スループットを必要とするお客様の場合は、Premium レベルの方が優れたオプションです。 または、スループットが変化し、メッセージ処理量が少なくてもかまわない場合は、Standard レベルの方が理にかなっているかもしれません。 次の表は、両方のレベルをまとめたものです。
| Premium レベル | Standard レベル |
|---|---|
| 高スループット | 変わりやすいスループット |
| 予測可能なパフォーマンス | 変わりやすい待機時間 |
| 固定価格 | 従量課金制の変わりやすい料金 |
| ワークロードをスケールアップおよびスケールダウンする機能 | 使用不可 |
| 最大 100 MB のメッセージ サイズ。 「大きいメッセージのサポート」をご覧ください。 | 最大 256 KB のメッセージ サイズ |
最新の情報については、「Service Bus の Premium および Standard メッセージング レベル」をご覧ください。
Azure API Management
Azure API Management にはさまざまな価格レベルが用意されているので、ニーズに合った最適なレベルを選べます。 各レベルには独自の機能があり、Consumption、Developer、Basic、Standard、Premium という名前です。
これらのレベルの機能は、Microsoft Entra 統合、Azure 仮想ネットワークのサポート、組み込みキャッシュ、セルフホステッド ゲートウェイなど、多岐にわたります。 これらのレベルとその機能について詳しくは、「Azure API Management レベルの機能に基づく比較」をご覧ください。
Azure Data Factory
Azure Data Factory にはさまざまな価格モデルが用意されているので、ニーズに合った最適なモデルを選べます。 オプションは基になるランタイムの種類によって異なり、Azure Integration Runtime、Azure マネージド VNET 統合ランタイム、セルフホステッド統合ランタイムなどがあります。 各ランタイム オファリング内で、オーケストレーション、データ移動アクティビティ、パイプライン アクティビティ、外部パイプライン アクティビティのサポートを検討してください。 コスト計画と価格について詳しくは、「Azure Data Factory のコストを管理するための計画」と「Data Factory の価格を実例から理解する」をご覧ください
デプロイ
BizTalk Server
BizTalk Server のネイティブ デプロイ パッケージは、Microsoft インストーラー (MSI) ファイルと環境構成 (つまりバインド) ファイルの組み合わせに基づいています。 これら 2 つのファイルにより、コンポーネントのインストール間の分離が作成されます。次の BizTalk Server リポジトリにデプロイされるこれらのコンポーネントでは、エンドポイント、シークレット、パイプライン構成など、ポートとパイプラインのレベルでの設定が定義されています。
- 管理 DB
- BizTalk Server のローカル フォルダー
- .NET グローバル アセンブリ キャッシュ
このプロセスは効果的ですが、個々の環境構成をコードとは別に管理する必要もあります。 BizTalk Deployment Framework (BTDF) オープンソース プロジェクトでは、この問題に対する 1 つの解決策が提供されています。 このツールでは、設計時に作成するトークン化されたバインド ファイルと、環境ごとに Excel ファイルとして作成するトークン マトリックスを使って、BizTalk Server ソリューションの一部として環境構成を管理できます。
その後、ビルド プロセスによって、統合およびバージョン管理された MSI ファイルが作成されます。 このファイルでは、同じパッケージからコンポーネントのデプロイと環境の構成がサポートされており、複数の環境に実装するソリューションのバージョンをより適切に制御できます。
継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインでの BTDF パッケージのサポートは、BizTalk Server 2020 で利用でき、これには BizTalk Server 2016 Feature Pack で導入されたこの機能が含まれています。 この機能と Azure DevOps プラットフォームを使って、複数の環境での BizTalk Server ソリューションの自動デプロイを効率化できます。
Azure Integration Services
Azure Integration Services のコンポーネントまたはソリューションを Azure にデプロイするときは、次の項目を管理する必要があります。
デプロイするソリューションのコンテナーまたはインフラストラクチャとして機能する Azure リソース (API Management インスタンス、Standard ロジック アプリ リソース、Service Bus 名前空間、Event Grid トピックなど)
API、ワークフロー、キュー、サブスクリプションなどの各コンポーネントによって実装される実際のロジック
各コンポーネントに関連付けられている環境固有の構成 (アクセス許可、シークレット、アラートなど)
インフラストラクチャの定義をコードから切り離しておくと、インフラストラクチャの定義を、バージョン管理し、ソース管理リポジトリに安全に格納し、定義が変更されたらデプロイをトリガーできる、別のコードとして扱うことができます。 一般にコードとしてのインフラストラクチャ (IaC) と呼ばれるこの方法を使うと、環境ごとにバージョンを作成し、ソース管理まで変更を追跡できるため、環境の品質が向上します。
Azure Integration Services では、Azure Resource Management テンプレートを使ってインフラストラクチャ リソースを作成する機能を提供することで、IaC がサポートされています。 ARM テンプレートは、理解したり統合ソリューションとして実装するのが複雑に思えるかもしれませんが、Bicep、Terraform、Pulumi など、インフラストラクチャ定義を作成するためのコードのようなエクスペリエンスを提供する抽象化ツールを使用できます。 これらのツールは、ARM テンプレートに対する抽象化レイヤーを提供しますが、最終的には ARM テンプレートを生成し、それらのテンプレートを自動的にデプロイできます。
インフラストラクチャの用意ができたら、エンド ツー エンドのワークフローを実装するロジックをデプロイできます。 Azure Integration Services には統合ワークフローを実装するためのツールのコレクションが用意されているので、各コンポーネントをデプロイする必要があります。 Azure Integration Services を使って構築されたソリューションの場合、通常、CI/CD パイプラインはコンポーネントのオーケストレーションのデプロイが基になります。 DevOps エンジニアは、デプロイ アクティビティを抽象化する組み込みアクションを使うことも、CLI コマンドまたは PowerShell や Bash などの自動化スクリプトを実行する汎用アクションを使うこともできます。 ほとんどの場合、エンジニアは、アプリケーションのニーズに基づいてパイプラインをカスタマイズし、公式ドキュメントのガイダンスを確認し、サンプル リポジトリを出発点として使います。
各コンポーネントをデプロイできるようにするプロセスでは、通常、次の手順を考慮します。
継続的インテグレーション フェーズ
ソース コードの最新バージョンを取得します。
環境固有の構成でコードを準備します。
このステップの詳細は、環境変数の外部挿入に対する各テクノロジのサポートによって異なります。 基本的な前提として、接続文字列や外部リソースの参照などの環境ベースの構成情報は、アプリケーション設定リポジトリを参照するために抽象化されています。 そのため、このシナリオでは、クリア テキストにできる参照はアプリケーション設定リポジトリに直接格納しますが、シークレットなどの機密性の値は、Azure キー コンテナーなどのシークレット ストア内のエントリへの参照ポインターとして格納します。
Azure Logic Apps の Standard ロジック アプリ リソースでは、アプリケーション設定リポジトリへの参照をサポートすることでこのアプローチが可能になっており、名前と値のペアをキー コンテナー内のエントリにマップできます。
Azure API Management の場合は、名前と値の構成を使うことで同様の結果を実現でき、Azure Key Vault もサポートされます。
さまざまな環境でのデプロイ用にコードをパッケージ化します。
継続的デプロイ フェーズ
パッケージ化されたコードを対象の環境にデプロイします。
クリア テキストまたはキー コンテナー内のエントリへの参照を使って、環境の正しい値でアプリケーション設定リポジトリを更新します。
コードに依存する必要なアクセス許可を更新します。
必要に応じて、アプリケーションを実行できるようにします。
機能の比較
次の表と図は、BizTalk Server と Azure Integration Services のリソース、成果物、機能を大まかに比較したものですが、一対一で対応してはいません。 Azure Integration Services は統合ワークロードの重要なプラットフォームですが、使用可能なすべての Azure 機能を全体として考慮してください。
| 機能 | BizTalk Server | Azure |
|---|---|---|
| オーケストレーション | - BizTalk Server オーケストレーション - C# コード (ヘルパー クラスまたは Web サービス) |
- Azure Logic Apps ワークフロー - Azure Functions 関数アプリ - Azure API アプリ |
| Pipelines | - BizTalk Server パイプライン - パイプライン コンポーネント |
- Azure Logic Apps ワークフロー (パイプラインとして) - Azure API Management (パイプラインとして) - Azure Functions または Azure API アプリ |
| メッセージ ルーティング | - MessageBox - プロパティの昇格 - フィルター |
- Azure Service Bus キューとトピック (メッセージ ヘッダー、メッセージ プロパティ、サブスクリプション) - Azure Event Grid または Azure API Management - SQL Server または Azure Cache for Redis |
| アプリケーションの接続 | - BizTalk Server の既製およびカスタム アダプター - インターネット インフォメーション サービス (IIS) と Azure API Management (ハイブリッド機能) |
- Azure Logic Apps コネクタ - Azure API Management (コネクタとして) - Azure Functions または Azure API アプリ |
| クロスリファレンス | BizTalk 管理データベースの xref_* テーブル (BizTalkMgmtDb) | - Azure Functions - SQL Server - Custom |
| スキーマ (XSD) | - BizTalk Server スキーマ - XML、JSON、フラット ファイルのスキーマ |
- Azure Logic Apps (従量課金) と Azure 統合アカウント - Azure Functions と Azure ストレージ アカウント - Azure Logic Apps と Azure API アプリ - Azure Logic Apps (Standard) |
| Maps | - BizTalk マッパー - XSLT マップ - Azure API Management (ハイブリッド機能) |
- Azure Logic Apps (従量課金) と Azure 統合アカウント (XSLT マップ、Liquid) - Azure Functions と Azure ストレージ アカウント - Azure Logic Apps と Azure API アプリ - Azure Logic Apps (Standard) |
| ビジネス ルール | BizTalk Server ビジネス ルール エンジン | - Azure Functions - SQL Server - カスタム データベース |
| ビジネス アクティビティの監視 | BizTalk Server ビジネス アクティビティの監視 | - SQL Server - Azure Monitor (Application Insights) - Power BI |
| EDI | - BizTalk Server の既製機能 - パーティ、パートナー、契約、AS2、X12、EDIFACT |
Azure Logic Apps と Azure 統合アカウント (パートナー、契約、AS2、X12、EDIFACT) |
| HL7、RosettaNet、SWIFT | HL7、RosettaNet、SWIFT 用の BizTalk Server アクセラレータ | - Azure Logic Apps、RosettaNet および SWIFT コネクタ、Azure 統合アカウント - Azure API Management for FHIR (HL7) - Azure Blueprint (Azure で SWIFT CSP コンプライアンスを有効にする) |
| シークレット | エンタープライズ シングル サインオン (SSO) | - Azure Key Vault - SQL Server - アプリケーションの構成 |
| セキュリティとガバナンス | - Enterprise Single Sign-On (SSO) - SSO 関連アプリケーション - Active Directory - 署名証明書 - IIS セキュリティ認証 - ネットワーク セキュリティ |
- Microsoft Entra ID - Azure ネットワーク セキュリティ - Azure ロールベースのアクセス制御 (Azure RBAC) - クレーム、トークン - 共有アクセス ポリシー |
| データの構成 | - 構成ファイル - Enterprise SSO アプリケーションの構成 - カスタム キャッシュ コンポーネント - カスタム データベース - ビジネス ルール エンジン - Windows レジストリ |
- Azure Key Vault - Azure App Configuration - Azure Cosmos DB - Azure Table Storage - Azure Logic Apps (Standard) の構成 - Azure Functions の構成 - Azure API Management の名前付きの値とバックエンド - SQL Server - カスタム キャッシュ - カスタム データベース |
| デプロイ | - BizTalk Server バインド ファイル | - Azure DevOps パイプライン - Bicep スクリプト - Terraform |
| 追跡 | - BizTalk Server 追跡機能 (受信ポート、送信ポート、パイプライン、オーケストレーション) - IIS 追跡 - Azure API Management の組み込み分析 (ハイブリッド機能) |
- Azure Logic Apps の実行履歴と追跡されたプロパティ - Azure ストレージ アカウント - Azure Monitor (Application Insights) - Azure API Management の組み込み分析 - カスタム ソリューション (Azure Event Hubs と Azure Functions と SQL Server と Azure Data Explorer など) |
| 監視 | - BizTalk 管理コンソール - BizTalk 正常性モニター |
Azure Monitor (Application Insights、Log Analytics) |
| 操作 | - BizTalk Server 管理コンソール - Azure DevOps パイプライン - MSI、PowerShell - BizTalk Deployment Framework |
- Azure portal - Azure Monitor - Azure Resource Manager テンプレート - Azure DevOps パイプライン - PowerShell、CLI、Bicep |
ロード マップ
Azure Integration Services へのワークロードとインターフェイスの移行における BizTalk のお客様のニーズに応えるため、現在、Microsoft は次の取り組みを優先して行っています。
| 期間 | 機能への取り組み |
|---|---|
| 短期 | - XSLT + .NET Framework のサポート (パブリック プレビュー) - SWIFT MT のエンコーダーとデコーダー (パブリック プレビュー) - Azure Logic Apps (Standard) からカスタム .NET Framework コードを呼び出す |
| 中期 | - EDI と統合アカウントの機能強化 - ネイティブ XML のサポート - WCF と SOAP のサポート - ビジネス ルール エンジンのサポート |
| 長期 | ビジネス イベントの追跡 |
最新の取り組みに関する情報を入手するには、Azure での統合に関するブログ - Tech Community にサブスクライブしてください。
次の手順
Azure Integration Services と BizTalk Server の比較について詳しく説明しました。 次に、シナリオに最適な Azure 機能を選択する方法を理解してください。 または、推奨されるアプローチとリソース、計画に関する考慮事項、移行のベスト プラクティスの確認に進んでください。