2016-12-20

May 2016

Volume 31 Number 5

Microsoft Azure - Azure Logic Apps を使用したエンタープライズアプリケーション統合

Srikantan Sankaran | May 2016

ビジネスプロセスの管理は、多くの企業が重視する分野で、プロセス自動化の中心になるのが異種システムとの統合です。この状況に新たに登場した重要なユースケースが、企業と Microsoft Azure Cloud との間でデータの取り込み、変換、およびルーティングを行う統合です。従来型のアプローチを使用してこのようなエンタープライズアプリケーション統合 (EAI) シナリオを実装すると、多くの時間やコストが必要になります。従来型のアプローチですべてのシナリオをサポートするには、ツールの特定と投資、技術的専門知識の習得、コンピューティングインフラストラクチャの準備などを行う必要があるためです。この種の問題に対処するのが、Azure Logic Apps のようなクラウドベースのマネージサービスです。

Azure App Service の Logic Apps 機能は、ビジュアル編集機能を提供します。開発者はこの機能を利用して、標準統合コネクターやエンタープライズ統合コネクターのセットを使い、複数のシステムやデータソース間での複雑なデータ交換を構成できます。このサービスを利用すれば、クラウドベースのアーキテクチャ特有の一時的なエラーを処理するようなシナリオや、条件に基づくプロセスフローのルーティング、長時間のトランザクションのようなシナリオも、簡単に実装できるようになります。

ここでは、エンタープライズ統合シナリオを使って、Logic Apps の機能をデモします。この統合シナリオでは、販売側の企業が注文受付システムを Azure にデプロイして、Logic Apps が提供する機能を利用します。この Logic Apps プロセスは、購入側が公開するセキュアなパブリックエンドポイントからの注文を受け取ります。その後、データの取得、変換、ルーティングで構成される多くの手順を経て、バックエンドシステムに注文を登録します。登録される注文ごとに確認 ID が生成され、購入側企業に送り返されます。

EAI プロセスフロー

図 1 は、Logic Apps を使用して実装されるシンプルな EAI シナリオを表しています。

図 1 エンタープライズアプリケーション統合のプロセスフロー

統合をトリガーする注文データは、購入側企業がフラットファイルの形式でアップロードします。このファイルは、インターネット経由で SSH ファイル転送プロトコル (SFTP) エンドポイントを使用して安全に公開されます。そのエンドポイントへのアクセスは、販売側企業と共有する認証資格情報を使ってセキュリティが確保されます。注文データを書き込むフィルダーと、確認メッセージを受け取るフォルダーは分けて作成します。ファイルの受け取りと書き込み用のエンドポイントをホストする SFTP サーバーには、CentOS Linux を実行する Azure 仮想マシンを使用します。

Azure SFTP コネクターを使用して SFTP エンドポイントに接続し、このエンドポイントから、時間をトリガーとして定期的に注文データを取得します。このコネクターのインスタンスは、Azure ポータルで作成し、Azure Marketplace から API アプリとしてデプロイします。この API アプリの同じインスタンスを使用し、注文の確認データをアップロードして SFTP エンドポイントに返します。

Logic Apps フローに追加する際に、SFTP コネクターのインスタンス構成で設定する主なパラメーターを以下に示します。

トリガーの頻度: 今回のシナリオ実装では 2 分間隔。
取得場所: 先ほど SFTP コネクターのインスタンスで構成したルートパスからの相対パス (例、/ホーム/<sftpユーザー名>) を追加。今回は b2b/orders。
[Delete File after Read (読み取り後にファイルを削除)] オプションを選択。

BizTalk FlatFile Encoder を使用して、SFTP コネクター API アプリからフラットファイルを読み取り、スキーマを持つ XML ドキュメントに変換します。BizTalk FlatFile Encoder は、Logic Apps 用エンタープライズ統合コネクターの一部として入手できます。このコネクターのインスタンスは、Logic Apps フローで利用する前に作成して、Azure Marketplace から API アプリとしてデプロイしておきます。FlatFile Encoder は、フラットファイルや JSON ドキュメントからの基本 XSD スキーマの生成をサポートしますが、このシナリオで使用するような複数の子レコードが関係する複雑な要件では、Visual Studio 2012 と BizTalk サービス SDK を使用してスキーマを生成します。その後、XSD スキーマドキュメントを BizTalk FlatFile Encoder Connector API アプリにアップロードします。

BizTalk Transform Services コネクターは、注文取得データベース (Order Capture Database) に挿入するため、注文データを含む XML ドキュメントを XML ペイロードに変換します。この変換には、Visual Studio 2012 と BizTalk サービス SDK を使って作成した変換マップを使用します。API アプリとしてデプロイされるこのコネクターのインスタンスに対して、注文登録フローと確認フローの両方のマップファイルをアップロードします。マップで使用するスキーマファイルは、この API アプリにアップロードする必要はありません。

SQL Database Connector API アプリのインスタンスが、前の手順の XML ドキュメントのペイロードを使って、注文データを Azure SQL Database に挿入します。この挿入操作を目的として XML ペイロードの生成に使用するスキーマは、BizTalk Services と Visual Studio 2012 で、XML ドキュメントのインスタンスに基づいて生成できます。あるいは、SQL Server 向け BizTalk WCF LOB Adapter を使用して生成することもできます。ただし、Azure SQL Database Connector API アプリ自体が、データベースのすべての操作を対象とするスキーマの生成をサポートするようになり、Azure ポータルの API アプリの構成から直接生成できるようになります。今回の場合、BizTalk WCF LOB Adapter や他のサードパーティのソリューションのような追加ツールは必要ありませんが、オンプレミスの配置では必要になる可能性があります。

図 2 に、Azure SQL Database Connector で設定する主なパラメーターの一部を示します。

図 2 Azure SQL Database Connector の構成

注文データの挿入に成功したら、Database Connector からの応答を、前の手順で構成した BizTalk Transform Service Connector API アプリを使用して、注文 ID 番号の配列からコンマ区切りのリストに変換します。

前の手順のデータベース挿入が失敗した場合は、Azure Storage Blob Connector API アプリのインスタンスを Logic Apps フローで使用して、エラーメッセージを格納します。

応答で生成される注文 ID は、前半で購入側企業の SFTP エンドポイントに対して構成した SFTP Connector を使用してアップロードします。

Logic Apps のプロセスフローは、完成時に 図 3 のように表示されます。

図 3 完成した Logic Apps フロー

今回、新しい Logic Apps を作成する際に使用した既定のスキーマバージョンは、2015-08-01-preview バージョンです。このバージョンでは、エンタープライズコネクターを追加する機能がまだ提供されていません。そのため、現在の EAI シナリオを実装するには、このスキーマバージョンを 2014-12-01-preview に置き換える必要があります。この置き換えは、Logic Apps のコードビューで JSON コードを直接編集することによって実行できます。

変更を反映するには、必ず変更を保存し、Logic Apps エディターを閉じて、再度読み込みます。

Logic Apps フローにリソースを追加するときは、Azure SQL Database や Storage Connections などの他のすべてのコネクターと同様に、すべてのリソースを 1 つのリソースグループにまとめて、簡単に処理およびデプロイできるようにします。また、リソースを同じ地域 (Azure Datacenter) にデプロイして、フローの実行にかかる待機時間を最小限に抑えます。

フローでの一時エラーの処理

Azure Logic Apps では、再試行のロジックを組み込むことにより、クラウドベースのアーキテクチャ固有の一時エラーを処理できるようにしています。そのためには、JSON コードを追加します (図 4 参照)。

図 4 一時エラーの処理

"b2bmicrosoftsqlconnector": {
  "type": "ApiApp",
  "inputs": {
    "apiVersion": "2015-01-14",
    "host": {
      },
    "operation": "XMLInsertOnordersax",
    "parameters": {
      "requestMessage": {
        "InputXml": "@{body('transformservice').OutputXml}"
      }
    },
    "retryPolicy" : {
      "type": "fixed",
      "interval": "PT30S",
      "count": 2
    },
  },

Azure SQL Database で注文の挿入操作を実行する際に一時エラーや接続の例外が発生すると、Connector API アプリは要求を 2 回再試行してからエラーを返します。

Logic Apps では、Repeating Call (事前に決めた条件に合うまで呼び出しを繰り返す)、Wait Actions (待機操作の実装)、他のワークフローを呼び出すなどの機能も追加できます。

Logic Apps フローの条件付き実行

Logic Appｓフロー内では、直前の操作の結果に基づくアクションを定義できます。条件を定義するオプションは、デザイナーの構成ペインか、Logic Apps のコードビューで設定します。

たとえば、今回のフローの場合、Azure SQL Database への注文の挿入に成功すると、応答メッセージを変換して、購入側企業の SFTP エンドポイントにアップロードします。

エラーが発生した場合は、Azure Blob Storage Connector を使用して、エラーメッセージを Azure Storage にアップロードします。Logic Apps の UI は、構成を変更したフローを視覚的に表示します。条件付きアクションの定義方法や、条件付きアクションを含むフローを Logic Apps が視覚的に表示するようすを図 6 に示します。

図 6 条件付きアクションのビジュアル表現

XSD スキーマドキュメントの操作

BizTalk Server ベースのエンタープライズ統合ソリューションの成果物をビルドするために開発者が使用している開発ツールを拡張して、Logic Apps で使用することもできます。BizTalk サービス SDK を Visual Studio 2012 と組み合わせると、追加のプロジェクトテンプレートを利用できるようになり、開発者は XSD スキーマや変換マップを生成および作成できるようになります。組み込みのウィザードが用意されており、このウィザードを使用して、フラットファイルのインスタンスや XML ドキュメントのインスタンスから XSD スキーマや変換マップを生成できます。Visual Studio 2012 で生成された出力の XSD スキーマドキュメントは、Logic Apps で使用される FlatFile Encoder インスタンスに直接アップロードできます。

Azure SQL Database の注文データ挿入に利用する XSD スキーマの生成 (Visual Studio 2012 のスキーマ生成ウィザードを使用して生成) で使用したサンプルの XML ファイルを図 5 に示します。

図 5 Azure SQL Database の注文データ挿入に使用する XSD スキーマの生成で使用した XML ファイル

<Insert xmlns="https://schemas.microsoft.com/Sql/2008/05/TableOp/dbo/ordersax ">
  <Rows>
  <ordersax xmlns="https://schemas.microsoft.com/Sql/2008/05/Types/Tables/dbo">
    <orderidsap>sap0101</orderidsap>
    <orderdate>2016-02-03</orderdate>
    <supplierid>sail001</supplierid>
    <orderamount>25000</orderamount>
    <currency>INR</currency>
    <discount>12</discount>
    <delvydate>2016-06-03</delvydate>
    <contract>C001</contract>
    <contact>Mr</contact>
  </ordersax>
  <ordersax xmlns="https://schemas.microsoft.com/Sql/2008/05/Types/Tables/dbo">
    <...>
  </ordersax>
... and more records ...
  </Rows>
</Insert>

BizTalk Server を使用した EAI ソリューションのオンプレミス配置に利用されるこのような成果物は再利用可能なため、企業は高い投資効果から、ソリューションのデプロイ先として Azure を検討するようになります。さらに、迅速なデプロイ、インフラストラクチャを簡単なプロビジョニング、ソリューションの管理や監視が容易といったメリットも加わります。

マップの操作

Azure BizTalk 変換サービスコネクターは、BizTalk 変換マップを使用して XML ドキュメントを変換します。ただし、このようなマップを作成するには、BizTalk サービス SDK と Visual Studio 2012 が必要です。XSD のスキーマと同様、ここで生成したマップ変換ファイルは、Azure Logic Apps に直接インポートできます。

ここで考えるプロセスフローでは、MapEach Loop Functoid を使用して、着信注文 XML をデータベースの Insert XML スキーマにマップし、着信するドキュメントのレコード全体を反復します (図 7 参照)。

図 7 注文挿入確認のマップ

注文作成の応答メッセージを送信メッセージにマップするには、SQL Server データベースから生成された注文 ID の配列を 1 つの要素内部でコンマ区切り値に変換する必要があります。そのためには、Cumulative Concatenate Functoid を使用します。

シナリオの実行

今回のシナリオを試すには、WinSCP ツールまたは同等のツールを使用して、orderssap.csv ファイルを /home/<sftpusername>/b2b/orders フォルダーに配置します。

Logic Apps コネクターのトリガーログのステータスを監視して、トリガーが実際に実行されたことを確認します。

エラーがなければ、Azure の注文処理システムから生成されたコンマ区切りの注文 ID 値を含む resp.XML ファイルを、/home/<sftpusername>/b2b/resp フォルダーに配置します。

次に、orderssap.csv ファイルを、変更しないで、再度同じフォルダーに配置します。データベースの一意制約に違反するため、Database Connector は例外をスローします。エラーメッセージは Azure Blob ストレージの "orders" コンテナーにアップロードされます。

Logic Apps の実行 - 追跡と監視

操作タイルを使用して、Logic Apps フローの実行を監視します。また、Logic Apps にはトリガーイベントのログも別にあります。各トリガーイベントの詳細を確認して、フローにおける各コネクターの実行のしくみ、実行結果、および実行期間を表示します。

プレミス間統合のシナリオの拡張

このシナリオで利用している SQL データベースは Azure にデプロイされていますが、企業ネットワーク内で運用する SQL Server データベースとも簡単に統合できます。Logic Apps を含む Azure App Services インフラストラクチャには、ハイブリッド接続という機能があります。この機能の実装には、企業ネットワークのファイアウォール背後にあるサーバーにハイブリッド接続マネージャーをインストールする必要があり、Logic Apps はこのマネージャーを使ってデータベースと統合します。SQL Server 以外にハイブリッド接続を使用してアクセスできるデータベースには、Oracle、DB2、Informix などがあります。

ハイブリッド接続を使用すると、BizTalk エンタープライズコネクターの使用を、企業ネットワーク内に配置された SAP や SharePoint のような基幹業務 (LOB) システムに拡張できます。また、オンプレミスに配置される REST サービスや Web サービスに拡張することもできます。

このシナリオを実装するためのソフトウェアの前提条件

今回のシナリオの実装に必要な Azure サブスクリプション以外に、以下に示す開発ツールと追加のソフトウェアが必要です。

Windows 8/8.1/10 または Windows Server 2012 R2 上で実行する、BizTalk サービス SDK と Visual Studio 2012。
Azure SQL Database を作成して接続できるようにする、SQL Server 2014 (以降) の SQL Management Studio。または、Visual Studio 2012 (以上) の Tools for SQL Server。
SFTP サーバーに接続し、送信フォルダーと受信フォルダーを作成し、メッセージを書き込み、受け取るための WinSCP ツールまたは同等のツール。

ダウンロード可能な成果物

今回のシナリオの実装に使用した以下の成果物は、GitHub リポジトリ (bit.ly/1poJPgs、英語) からダウンロードできます。

Azure SQL Database 作成スクリプト (ordersax.sql)
サンプル注文データファイル (orderssap.csv)
XSD スキーマ:
- dbinsert_sampledata.xsd: SQL 挿入スキーマ
- dbinsert_sampledata1.xsd: 上記のスキーマで参照される一部分
- orderssap.xsd: 受信する注文ドキュメントのスキーマ
- orderresponse.xsd: SQL 挿入の応答
- orderresponse1.xsd: SQL の挿入応答スキーマで参照される一部分
- ordersaxresp.xsd: 送信する XML 応答メッセージのスキーマ
マップ:
- orders.trfm: 着信メッセージから SQL 挿入スキーマへのマッピング
- ordersaxtosap.trfm: SQL 挿入の応答スキーマから送信メッセージのスキーマへのマッピング

今回のシナリオのソリューションを実装するには、以下の参考資料がに役立ちます。

このソリューションで使用するスキーマとマップを開発するためのソフトウェア前提条件: https://msdn.microsoft.com/library/azure/hh689760.aspx
Visual Studio 2012 を使用して、フラットファイルからスキーマを生成する: https://msdn.microsoft.com/library/aa577898.aspx
Azure で SFTP コネクターを構成する: bit.ly/254QfC2

まとめ

Azure Logic Apps は、エンドツーエンドの EAI シナリオを実装するためのプラットフォームを提供します。このプラットフォームが提供する標準コネクターとエンタープライズコネクターの包括的なセットにより、企業のさまざまな LOB システムと、クラウド上の SaaS アプリケーションを統合できるようになります。BizTalk Server 2013 を使用して、スキーマやマップのような、オンプレミスの EAI ソリューションのデプロイ向けに生成された成果物をシームレスに利用できます。これにより、企業は現在の投資を再活用し、クラウドにシナリオを実装する可能性を開き、Azure が提供する高可用性、信頼性、およびインフラストラクチャのセットアップの容易性といったメリットを活用することができます。Logic Apps のハイブリッド接続サポートを利用すると、クラウドで運用される統合シナリオに参加できるようになり、これまで投資してきたオンプレミスに配置した LoB システムから新たなメリットを得ることができます。

ヒント

ソリューションの成果物の開発に着手するための簡単な方法は、BizTalk Server 2013 Standard Edition を実行する Azure 管理ポータルでギャラリーの VM イメージを使用することです。VM への Visual Studio 2012 と BizTalk Services SDK のインストールは 30 分もかかりません。

Srikantan Sankaran は、インドのバンガロールを拠点に各地で活動する DX チームのテクニカルエバンジェリストです。彼は、インドのさまざまな独立系ソフトウェアベンダー (ISV) と共に活動しており、Microsoft Azure にソリューションをデプロイしています。連絡先は sansri@microsoft.com (英語のみ) です。

この記事のレビューに協力してくれたマイクロソフト技術スタッフの Sandeep Alur に心より感謝いたします。
Sandeep Alur は、インドのバンガロールを拠点に各地で活動する DX チームのリードエバンジェリストです。