BizTalk Server から Azure Logic Apps に接続する
BizTalk Server と Azure のロジック アプリ ワークフローの間でメッセージを交換するには、BizTalk Server for Azure Logic Apps のアダプターを使用できます。 このガイドでは、ロジック アプリ ワークフローから BizTalk Server でメッセージを受信する方法について説明します。 ワークフローは BizTalk Server にメッセージを送信できます。 受信側は、インターネット インフォメーション サービス (IIS) アプリケーションを使用して、Azure サービスとの通信を処理します。
BizTalk Server がオンプレミスにあり、ドメインに参加している場合は、オンプレミス データ ゲートウェイを BizTalk Server にインストールし、Azure にオンプレミス データ ゲートウェイ リソースを作成する必要があります。 ただし、BizTalk Server が Azure 仮想マシンにインストールされている場合は、呼び出すことができる URL を持つ HTTP エンドポイントとして仮想マシンを公開するかどうかを選択できます。
HTTP エンドポイント オプションを選択した場合、ゲートウェイを使用する必要はありません。 代わりに、ロジック アプリ ワークフローを作成し、必要な BizTalkServer コネクタ アクションを追加し、アクションの接続情報で必要に応じて HTTP エンドポイント URL を指定します。 ただし、オンプレミス オプションを選択する場合は、このガイドで後述するデータ ゲートウェイを設定して使用する必要があります。
このガイドでは、BizTalk Server からロジック アプリ ワークフローにメッセージを送信する方法についても説明します。 別の言い方をすると、ロジック アプリ ワークフローは BizTalk Server からメッセージを受信できます。
このガイドでは、Azure Logic Apps アダプターを使用して受信場所と送信ポートを作成する方法について説明します。 このアダプターは、オンプレミスの BizTalk Server または BizTalk Server を実行している Azure 仮想マシンと共に使用できます。
Azure portal にサインインし、ロジック アプリのリソースとワークフローを作成できるように、Azure アカウントとサブスクリプション。 サブスクリプションをお持ちでない場合は、無料の Azure アカウントにサインアップ
。 BizTalk Server の要件は、サーバーがインストールされている場所に基づいています。
BizTalk Server を使用したオンプレミス コンピューター: Azure Logic Apps用のオンプレミス データ ゲートウェイ
をインストールして設定します。 次に、Azure portal で、ロジック アプリ ワークフローの BizTalk Server コネクタで使用する データ ゲートウェイ リソース を作成します。 BizTalk Server を使用する Azure 仮想マシン:
仮想マシンが HTTP エンドポイントとして公開されていない場合は、Azure Logic Apps用の
オンプレミス データ ゲートウェイをインストールして設定します。 次に、Azure portal で、ロジック アプリ ワークフローで BizTalk Server コネクタで使用する データ ゲートウェイ リソース を作成します。 仮想マシンが HTTP エンドポイントとして公開されている場合、データ ゲートウェイのインストールを使用したり、データ ゲートウェイ リソースを作成したりする必要はありません。
Azure Logic Apps に関する知識。 ロジック アプリを初めて使用する場合は、「
Azure Logic Apps とは」を参照してください。マルチテナント Azure Logic Appsで従量課金ロジック アプリ ワークフローの例を して作成します。 必要に応じて、ワークフローが HTTP 要求を受信できるトリガー (要求 トリガーなど) で始まる場合は、ロジック アプリ ワークフローをトリガーするテスト メッセージを送信できます。 このメッセージを送信するには、ワークフロー内のトリガーに対して生成されたエンドポイント URL に HTTP 要求を送信できるツールを使用します。 次の一覧には、いくつかのツールの例が含まれています。
- Visual Studio Marketplace から拡張機能を使用して Visual Studio Code
する - PowerShell Invoke-RestMethod の
- Microsoft Edge - ネットワーク コンソール ツール
- ブルーノ
- Curl
注意事項
資格情報、シークレット、アクセス トークン、API キーなどの機密データがあるシナリオでは、必要なセキュリティ機能でデータを保護し、オフラインまたはローカルで動作し、データをクラウドに同期せず、オンライン アカウントにサインインする必要がないツールを必ず使用してください。 これにより、機密データを一般に公開するリスクを軽減できます。
- Visual Studio Marketplace から拡張機能を使用して Visual Studio Code
BizTalk Server 2020 以降、Azure Logic Apps アダプターは BizTalk Server のインストールに含まれています。
BizTalk Server で、Azure Logic Apps アダプターをダウンロードしてインストールします。
Microsoft BizTalk Server Adapter for Logic Appsに移動し、[ダウンロード]を選択します。
インストールするには、LogicAppAdapter.iso ファイルを開き、LogicApp Adapter.msi ファイルを実行します。
使用許諾契約書に同意し、[のインストール]
選択します。
インストールが完了したら、
BizTalkServerApplication を再起動し、BizTalkServerIsolatedHost ホスト インスタンスをします。
インストールが完了すると、次の状態になります。
Azure Logic Apps アダプターが BizTalk 管理に追加されます。
送信ハンドラーが作成され、BizTalkServerApplication ホスト インスタンスが使用されます。
受信ハンドラーは Windows Communication Foundation サービスとして作成され、BizTalkServerIsolatedHost ホスト インスタンスを使用します。
LogicApp Adapter フォルダーは、BizTalk インストール ディレクトリ内に作成され、管理 と ReceiveServiceの 2 つのサービスが含まれています。 管理: データ ゲートウェイを使用して BizTalk Server に接続するために、ロジック アプリ ワークフローの BizTalk コネクタによって使用されます。 この管理サービスを使用すると、BizTalk Server はデータ ゲートウェイを使用してロジック アプリ ワークフローからメッセージを受信できます。 このサービスは、BizTalk の受信側でのみ使用され、送信側では使用されません。
ReceiveService: 受信場所を持つロジック アプリ ワークフローの BizTalk コネクタによって使用されます。 このサービスは、ロジック アプリ ワークフローからメッセージを送信する役割を担います。 このサービスは、BizTalk の受信側でのみ使用され、送信側では使用されません。
このセクションでは、BizTalk Server がロジック アプリ ワークフローからメッセージを受信するために必要な追加の手順を示します。 Azure portal が変更される可能性があるため、一部の手順が一覧と完全に一致しない場合があります。
Azure Logic Apps アダプターと NullAdapter をインストールすると、次のエラーが表示されることがあります。
同じ OutboundEngineCLSID 値を持つ別のアダプターが既に存在
アダプター クラス GUID は、Azure Logic Apps アダプターと NullAdapter で同じです。 両方のアダプターが必要な場合は、次の手順に従います。
GitHubで
NullAdapter ソース コードをダウンロードします。 NullSendAdapter.cs クラスで、GUID を更新します。
NullAdapter.reg ファイルで、OutboundEngineCLSID 値を更新します。
NullAdapter をビルドしてデプロイします。
IIS アプリケーションは、管理 と ReceiveService
ヒント
新しいアプリケーション プールを作成する場合は、必ず既定の .NET CLR バージョンとマネージド パイプラインを保持してください。 BizTalk サービス アカウントと同じ BizTalk グループへのメンバーシップを持つ ID (詳細設定) を選択してください。
ロジック アプリ ワークフローの BizTalkServer コネクタは、この IIS アプリケーションの URL を使用して、BizTalk Server 上のデータ ゲートウェイ経由で接続します。
BizTalk 構成ウィザードを使用して REST API を構成します。
詳細については、構成ガイドのを参照してください。
REST API の詳細については、BizTalk REST API リファレンスを参照してください。
Web ブラウザーで、
http://localhost/BizTalkManagementService/Schemas
に移動します。Web ブラウザーに基づいて、スキーマの一覧が表示されるか、schemas.json ファイルを開いて保存するように求めるメッセージが表示されます。 どちらも発生していない場合は、REST API の構成を確認します。
インターネット インフォメーション サービス (IIS) マネージャーを開きます。
既定の Web サイト ショートカット メニューから、[アプリケーション追加] を選択します。 この新しいアプリケーションでは、次の操作を行います。
IISLogicAppなど、アプリケーションの
エイリアス (名前)入力します。 アプリケーション プールを選択します。
物理パス を
C:\Program Files (x86)\Microsoft BizTalk Server 2016\LogicApp Adapter\Management
に設定します。設定をテストして、アプリケーション プール ID が
認証 に合格したことを確認し、承認 テストします。
[OK]
選択して変更を保存します。 Web ブラウザーで、
http://localhost/YourApplicationAlias/schemas?api-version=2016-10-26
(例:http://localhost/IISLogicApp/Schemas?api-version=2016-10-26
) に移動します。Web ブラウザーに基づいて、スキーマの一覧が表示されるか、schemas.json ファイルを開いて保存するように求めるメッセージが表示されます。 どちらも発生しない場合は、AppPool ID に BizTalk グループのメンバーシップが不足している可能性があります。
ロジック アプリ ワークフローの BizTalkServer コネクタは、指定した受信場所にこの IIS アプリケーションの URL を使用します。
インターネット インフォメーション サービス (IIS) マネージャーを開きます。
既定の Web サイト ショートカット メニューを開き、[アプリケーション追加] を選択します。 この新しいアプリケーションでは、次の手順に従います。
ReceiveWCFServiceなど、アプリケーションの
エイリアス (名前)入力します。 前の IIS アプリケーションと同じアプリケーション プールを選択します。
物理パス バージョンに基づいて、次のように設定します。
- BizTalk Server 2020:
C:\Program Files (x86)\Microsoft BizTalk Server\LogicApp Adapter\ReceiveService
- BizTalk Server 2016:
C:\Program Files (x86)\Microsoft BizTalk Server 2016\LogicApp Adapter\ReceiveService
- BizTalk Server 2020:
設定をテストして、アプリケーション プール ID が
認証 に合格したことを確認し、承認 テストします。
[OK]
選択して変更を保存します。
Azure portalで、新しいロジック アプリ リソースと空のワークフローを作成します。
作成したワークフローに基づいて、次
一般的な手順に従って、http 要求がワークフローに 受信されたときにという名前の 要求 トリガーを追加します。次の一般的な手順に従って、JSON からメッセージを準備 という名前の BizTalkServer アクションをワークフローに追加します。アクションの接続ウィンドウで、次の情報を指定します。
財産 形容 オンプレミス データ ゲートウェイ 経由で接続する オンプレミス データ ゲートウェイを使用しているかどうかを選択します。 ゲートウェイは、次のシナリオでのみ必要です。
- オンプレミスの BizTalk Server を使用しています。
- Azure 仮想マシンで BizTalk Server を使用していますが、仮想マシンは HTTP エンドポイントとして公開されていません。接続名の 接続のフレンドリ名を入力します。 BizTalk Server URL IIS アプリケーション URL に BizTalk Management の完全修飾ドメイン名 (FQDN) を入力します。 たとえば、「 http://BizTalkServerName.corp.contoso.com/IISLogicApp/
」と入力します。認証の種類の [Windows 選択します。 ユーザー名 の IIS アプリケーション プールの ID を入力します。 パスワードの IIS アプリケーション プールのパスワードを入力します。 ゲートウェイ - サブスクリプション: Azure portal で作成したゲートウェイ リソースに関連付けられている Azure サブスクリプションを選択します。
- ゲートウェイ: Azure portal で作成したゲートウェイ リソースを選択します。[新しい
作成] を選択します。 アクション情報ウィンドウが表示されたら、次に例を示す必要な詳細を指定します。
財産 形容 Body HTTP 本文の出力を選択します。 スキーマ 使用するスキーマを選択します。 注意
この手順では、BizTalk のスキーマについて理解していることと、必要なスキーマがわかっていることを前提としています。 不明な場合は、HelloWorld SDK サンプルをデプロイし、その成果物を更新して Azure Logic Apps アダプターを使用し、そのスキーマとサンプル メッセージを使用します。
次の一般的な手順に従って、メッセージ をワークフローに送信という名前 BizTalkServer アクションを追加します。財産 形容 受信場所の 一覧から URL を選択するか、ReceiveService IIS アプリケーション URL の完全修飾ドメイン名 (FQDN) を入力します。 たとえば、「 http://BizTalkServerName.corp.contoso.com/ReceiveWCFService/Service1.svc
」と入力します。
受信場所を作成するときに、受信場所のトランスポート プロパティの パブリック アドレス として、[全般] タブにもこの正確な URL を入力します。Body 前の BizTalk Server アクションの本文出力を選択します。 ワークフローを保存します。 デザイナーのツール バーで、[保存]
選択します。 この手順では、要求 トリガーに表示されるエンドポイント URL が自動的に作成されます。 この URL に HTTP 要求を送信すると、 がトリガーされるか、ワークフローの実行が開始
。 エンドポイント URL をコピーして保存します。 この情報は、手順 4:メッセージを送信するために必要です。
このセクションでは、独自の成果物を作成する方法について説明します。
ヒント
独自の受信ポートと受信場所を作成するのではなく、HelloWorld SDK サンプルをデプロイし、Azure Logic Apps アダプターを使用するように成果物を更新できます。
BizTalk Server の管理で、次を展開します。
BizTalk グループ
アプリケーション BizTalk Server 管理の 受信場所の実行に使用するアプリケーションを展開します。 たとえば、BizTalk アプリケーション - 受信
展開します。 受信ポート ショートカット メニューから、[新しい] を選択し、[一方向受信ポート] 選択します。 受信ポートの プロパティに、次の情報を入力します。
財産 形容 名の 受信ポートの名前を入力します。 たとえば、「laReceivePort 」と入力します。 認証
- 認証 なし (既定): 認証を無効にします。
- 認証が失敗した場合にメッセージを削除: 認証を有効にしますが、認証されていないメッセージを削除します。
- 認証に失敗した場合はメッセージを保持: 認証を有効にし、認証されていないメッセージを保持します。失敗したメッセージのルーティングを有効にする 別の受信ポートやオーケストレーション スケジュールなど、サブスクライブしているアプリケーションに処理に失敗したメッセージをルーティングします。 失敗したメッセージを中断し、否定受信確認 (NACK) を生成するには、このオプションをオフにします。 既定では、このオプションはオフになっています。
詳細については、「受信ポートの失敗したメッセージのルーティングを有効にする方法」を参照してください。[受信場所
] を選択し、[新しい] 選択します。 受信場所の 名 を入力します。 たとえば、「laReceiveLoc
入力します。 [
の種類] で、[LogicApp選択し、の構成 選択します。 [全般] タブで、ロジック アプリ ワークフローのエンドポイント アドレスを設定します。
財産 形容 アドレス (URI) 必須。 BizTalk ReceiveService IIS アプリケーション URL を次のように入力します。
形式:/{your-IIS-app2-name}/Service1.svc
例:/ReceiveWCFService/Service1.svc
.パブリック アドレスの 必須。 次の URL を次のように入力します。
形式:http://{fully-qualified-machine-name}/{your-IIS-App2-name}/Service1.svc
.
例:http://btsProd.northamerica.corp.contoso.com/ReceiveWCFService/Service1.svc
この正確な URL は、受信場所のロジック アプリにも一覧表示されます。省略可能なです。 [バインド] タブで、基になる WCF-WebHttp バインドのタイムアウトとエンコード関連のプロパティを構成します。 大きなメッセージを処理する場合は、次のプロパティが役立ちます。
財産 形容 オープン タイムアウト チャネルを開く操作が完了するまでに予想される時間間隔を入力します。 この値は、System.TimeSpan.Zero 以上です。
- 既定値: 00:01:00
- 最大値: 23:59:59送信タイムアウト 送信操作が完了するまでに予想される時間間隔を入力します。 この値は、System.TimeSpan.Zero 以上です。 要求応答受信ポートを使用する場合、クライアントが大きなメッセージを返した場合でも、この値は対話全体が完了するまでの期間を指定します。
- 既定値: 00:01:00
- 最大値: 23:59:59タイムアウト を閉じる チャネルの終了操作が完了するまでに予想される時間間隔を入力します。 この値は、System.TimeSpan.Zero 以上です。
- 既定値: 00:01:00
- 最大値: 23:59:59最大受信メッセージ サイズ (バイト) ネットワークで受信するメッセージ (ヘッダーを含む) の最大サイズをバイト単位で入力します。 メッセージ サイズは、各メッセージに割り当てられたメモリの量によって制限されます。 このプロパティを使用して、サービス拒否 (DoS) 攻撃への露出を制限できます。
- 既定値: 65536
- 最大値: 2147483647最大同時呼び出し 1 つのサービス インスタンスに対する同時呼び出しの数を入力します。 制限を超える呼び出しはキューに登録されます。 この値を 0 に設定することは、値を int32.MaxValue設定することと同じです。
既定値: 200省略可能なです。 [セキュリティ] タブで、セキュリティ プロパティを構成します。 開発の目的で、[なし]
選択できます。 財産 形容 セキュリティ モードの - なし: 転送中にメッセージがセキュリティで保護されません。
- トランスポート: セキュリティは HTTPS トランスポートを使用して提供されます。 SOAP メッセージは HTTPS を使用してセキュリティで保護されます。 このモードを使用するには、IIS で Secure Sockets Layer (SSL) を設定する必要があります。
- TransportCredentialOnly: 既定値。トランスポート クライアント資格情報の種類 クライアント認証を使用する場合は、資格情報の種類を選択します。
- なし: トランスポート レベルでは認証は行われません。
- 基本: 基本認証を使用して、ネットワーク経由でプレーン テキストでユーザー名とパスワードを送信します。 資格情報に対応するドメインまたはローカル ユーザー アカウントを作成する必要があります。
- ダイジェスト: ダイジェスト認証を使用して、ネットワーク経由でパスワードをハッシュ値として送信します。 Windows Server オペレーティング システム認証を実行しているドメイン コントローラーがあるドメインでのみ使用できます。 クライアント資格情報に対応するドメインまたはローカル ユーザー アカウントを作成する必要があります。
- Ntlm (既定値): クライアントは、この受信場所にパスワードを送信せずに資格情報を送信します。 クライアント資格情報に対応するドメインまたはローカル ユーザー アカウントを作成する必要があります。
- Windows: Windows 統合認証は Kerberos または NTLM をネゴシエートし、ドメインが存在する場合は Kerberos を優先します。 Kerberos を使用するには、クライアントにサービス プリンシパル名 (SPN) を使用してサービスを識別してもらう必要があります。 クライアント資格情報に対応するドメインまたはローカル ユーザー アカウントを作成する必要があります。
- 証明書: クライアント証明書を使用します。 クライアントがこの受信場所に対して認証できるように、このコンピューターの信頼されたルート証明機関の証明書ストアにクライアント X.509 証明書の CA 証明書チェーンをインストールする必要があります。
- InheritedFromHostシングル サインオン を使用する 省略可能なです。 [メッセージ] タブで、送信 HTTP ヘッダー プロパティを使用してカスタム ヘッダーを追加し、エラーに役立つ追加プロパティを使用します。
財産 形容 送信 HTTP ヘッダー の 応答メッセージにスタンプする HTTP ヘッダーを入力します。 失敗時の場所を無効にする 受信パイプラインのエラーまたはルーティングエラーが原因で受信処理が失敗した場合は、受信場所を無効にします。 既定では、このオプションはオフになっています。 失敗時に要求メッセージを中断 受信パイプラインのエラーまたはルーティングエラーが原因で受信処理が失敗した場合は、要求メッセージを中断します。 既定では、このオプションはオフになっています。 エラー に例外の詳細を含める エラーが発生した場合は、デバッグに役立つ SOAP エラーを返します。 既定では、このオプションはオフになっています。
受信ポートと場所のプロパティの詳細については、「受信場所の管理
HTTP メッセージまたは要求を送信するためのツールを開きます。
ロジック アプリ ワークフローの Request トリガーから保存したエンドポイント URL を貼り付けます。 前の手順でこの URL をコピーしました。
使用 HTTP メソッドとして POST を選択します。 Content-type ヘッダーを
application/json
に設定します。 要求本文に次の JSON を貼り付け、ツールの指示に従って HTTP メッセージを送信します。{"hello":"world"}
要求は BizTalk への一方向の呼び出しであるため、結果として HTTP 202 が必要です。
HelloWorld SDK サンプルを使用している場合は、BizTalk サーバーに移動します。 送信フォルダーにファイルが存在する可能性があります。
Azure portalで、新しいロジック アプリ リソースと空のワークフローを作成します。
次の一般的な手順に従って、http 要求を受信したときにワークフローに という名前の 要求 トリガーを追加します。Microsoft の職場または学校アカウントがある場合は、次 一般的な手順に従って、Office 365 Outlook アクションをワークフローに送信 を追加します。
メッセージが表示されたら、Office 365 Outlook にサインインします。
アクションの接続ウィンドウで、次の情報を指定します。
財産 形容 への Office 365 のメール アドレスを入力します。 件名の 「Sending from BizTalk」と入力します。 Body 編集ボックス内を選択します。 稲妻アイコンと関数アイコンが表示されたら、稲妻アイコンを選択して動的コンテンツ リストを開きます。 一覧の [HTTP 要求が受信されたとき、電子メールに含めるトリガー出力を選択します。 ワークフローは次の例のようになります。
ワークフローを保存します。 デザイナーで、[保存]を選択します。
要求トリガー 情報で、ワークフローの保存時に自動的に作成される HTTP URLをコピーします。 次の手順では、この URL が必要です。 URL が表示されない場合は、ロジック アプリを閉じて再度開く必要があります。
BizTalk Server がロジック アプリ ワークフローにメッセージを送信するには、ワークフローは manual
トリガーで開始する必要があります (例: HTTP 要求が受信されたとき。
BizTalk Server の管理で、次を展開します。
BizTalk グループ
アプリケーション BizTalk Server 管理の 送信ポートの実行に使用するアプリケーションを展開します。 たとえば、[BizTalk アプリケーション -の送信]
展開します。 送信ポート ショートカット メニューから、[新しい]選択し、[静的一方向送信ポート 選択します。 送信ポートの 名 を入力します。 たとえば、「LASendPort
入力します。 の種類 一覧から LogicApp選択し、の構成 選択します。 [全般] タブで、オプションを選択して、ロジック アプリ ワークフロー トリガーの コールバック URI を指定します。
オプション 1
トリガー (コールバック URI) プロパティに、以前にコピーした HTTP URL貼り付けます。
ヒント
Azure Resource Manager API を使用して、この URI を取得することもできます。
オプション 2
コールバック URIがわからない場合は、[の構成] を選択し、Azure にサインインします。
サブスクリプション 、リソース グループ 、ロジック アプリ 、およびトリガーの値を選択します。 省略可能なです。 [バインド] タブで、基になる WCF-WebHttp バインドのタイムアウトとエンコード関連のプロパティを構成します。 これらのプロパティは、大きなメッセージを処理するときに役立ちます。
財産 形容 オープン タイムアウト チャネルを開く操作が完了するまでに予想される時間間隔を入力します。 この値は、System.TimeSpan.Zero 以上です。
- 既定値: 00:01:00
- 最大値: 23:59:59送信タイムアウト 送信操作が完了するまでに予想される時間間隔を入力します。 この値は、System.TimeSpan.Zero 以上です。 要求応答受信ポートを使用する場合、クライアントが大きなメッセージを返した場合でも、この値は対話全体が完了するまでの期間を指定します。
- 既定値: 00:01:00
- 最大値: 23:59:59タイムアウト を閉じる チャネルの終了操作が完了するまでに予想される時間間隔を入力します。 この値は、System.TimeSpan.Zero 以上です。
- 既定値: 00:01:00
- 最大値: 23:59:59最大受信メッセージ サイズ (バイト) ネットワークで受信するメッセージ (ヘッダーを含む) の最大サイズをバイト単位で入力します。 メッセージ サイズは、各メッセージに割り当てられたメモリの量によって制限されます。 このプロパティを使用して、サービス拒否 (DoS) 攻撃への露出を制限できます。
Azure Logic Apps アダプターは、バッファー転送モードでWebHttpBinding クラスを使用してエンドポイントと通信します。 バッファー転送モードの場合、WebHttpBinding.MaxBufferSize プロパティは常にこのプロパティの値と等しくなります。
- 既定値: 65536
- 最大値: 2147483647省略可能なです。 [メッセージ] タブで、送信メッセージにカスタム ヘッダーを追加するには、送信 HTTP ヘッダー プロパティを使用します。
[OK]
選択して構成を保存します。
送信ポートのプロパティの詳細については、「送信ポートと送信ポート グループの管理」を参照してください。
ファイル アダプターを使用して、受信ポートと受信場所を作成できます。 ロジック アプリ リソースが有効になっていることを確認します。
受信ポート (例: *FileSendPort) を作成します。
受信場所を作成し、次の値の例のようなプロパティを設定します。
財産 サンプル入力 受信フォルダーの C:\temp\In\
ファイル マスクの *.txt
パイプラインの PassThruReceive
前に作成した送信ポートで、フィルター を次の値の例に設定します。
財産 演算子 価値 BTS を します。ReceivePortName == FileSendPort
次のテキスト 含む {file-name}.txt という名前のテキスト ファイルを作成し、次のテキスト ファイルをサンプル メッセージとして作成します。
<Data> <DataID>DataID_0</DataID> <DataDetails>DataDetails_0</DataDetails> </Data>
{file-name} .txt を受信フォルダーにコピーします。
送信ポートは、指定した URI を使用して、.txt ファイルをロジック アプリ ワークフローに送信します。 ワークフローがファイルを受信すると、ワークフローはサンプル メッセージを含む電子メールを、指定した To アドレスに送信します。
- Azure Logic Apps とは
- マルチテナント Azure Logic Apps で従量課金ロジック アプリ ワークフローの例を作成する
- BizTalk Server でのアダプターの使用