MuleSoft 入門(3)Anypoint Studio による API の実装(2/2)

December 19, 2019 Naoki Kitaarashi

こんにちは、アピリオ北嵐です。MuleSoft 入門(3)Anypoint Studio による API の実装 の前半に引き続き、後半の今回は Mule アプリケーションの構成、アプリケーションの実行、アプリケーションのクラウド環境へのデプロイ手順についてご紹介していきます。

モジュールとコンポーネント

コンポーネントは Mule アプリケーションを構成する1つ1つの機能であり、様々な標準コンポーネントが提供されています。Mule API の実装ではコンポーネントをフロー上に配置し、各機能を組み合わながら処理を構築するコンポーネントベースの開発スタイルを取っています。 

コンポーネントはモジュール単位で管理されていて、モジュールとコンポーネントは Anypoint Studio の右側のパレットに配置され、ドラッグ&ドロップしてフロー定義上に配置します。

※ 外部のリソースに接続するモジュールは“コネクタ”と呼ばれますが、ここでは便宜上モジュール/コンポーネントと呼びます

[Anypoint Studio のコンポーネントパレット]

一例として下記のようなモジュールが提供されています。他にも MuleSoft からは様々な標準モジュール/コネクタが提供されており、生産性の高い API の開発を支えています。Exchange 上では標準以外の Public モジュール/コネクタも公開されていて、Anypoint Studio 上にインポートして使用することができます。

モジュール
含まれるコンポーネント/コネクタ

Core

Mule アプリケーションを作成するための標準コンポーネント

APIKit

RAML や SOAP ベースの Mule API を作成するためのツール

HTTP

HTTP ベースの送受信を行うためのコンポーネント

Database

データベースに直接アクセスするためのコンポーネント

File

ファイルアクセスを行うためのコンポーネント

ObjectStore

ObjectStore(Mule内部のキャッシュ機能)を使用するためのコンポーネント

Salesforce

Salesforce へアクセスするためのコンポーネント

Scripting

スクリプト(Groovy, JavaScript, Python など)を実行するためのコンポーネント

Web Service Consumer

SOAP リクエストを行うためのコンポーネント

Validation

各種 Validation 機能を提供するコンポーネント

XML

XML 処理を行うためのコンポーネント

 

グローバル設定 Global Configuration Elements

各コンポーネントには様々な設定項目が準備されていますが、これらの定義と組み合わせて使用されるのが グローバル設定(Global Configuration Elements)になります。

[グローバル設定の例]

Mule プロジェクト全体で有効になる下記のような設定をグローバル設定に追加します。

  • グローバルスコープで利用するプロパティの定義
  • プロパティファイルの指定
  • TLS の設定
  • Listener/Request の設定
  • コネクタの接続先設定
  • カスタム ObjectStore の設定

Mule イベント

Mule イベント(event)は Mule アプリケーション内で使用されるデータを表していて、フローが実行されると自動的にイベントにデータがセットされます。フロー処理では、Mule イベントを介して各コンポーネントはデータの受け渡しを行います。イベントは階層構造になっていて、Mule message と Variables が含まれます。

Mule message(メッセージ): HTTP リクエストなどの入力データを表していて、属性を表す Attributes(HTTPだとヘッダやパラメータ)とBody 部のデータを表す Payload から構成される

Variables(変数): アプリケーション内で設定できる変数。変数を使ってフローやコンポーネント間でデータを共有する

[Mule event の構成]

これらの中でも最も重要なのは Payload(ペイロード)です。フロー処理の中では外部リソースと Mule API でやり取りされるデータの本体は Payload に格納され、Payload に対してデータの変換を行い処理を進めていきます。API のリクエストデータとレスポンスデータはいずれも Payload に保持されます。また Payload はデータ本体だけでなく、データの表現形式として MIME type を保持しており、MIME type を切り替えることで、容易にデータの出力を切り替えることができます。

例えば、下記は DataWeave という Mule 独自の言語を使って記述したデータ変換の例です。MIME type を指定する"output"の記述を application/json から applicaiton/xml に切り替えるだけで、自動的に出力データのフォーマットが JSON から XML に変更されます。

[payload の JSON 形式での出力]

[payload の XML 形式での出力]

強力なデータ変換言語である DataWeave については、MuleSoft 入門(4)DataWeave によるデータ変換 を参照ください。  

ローカル環境でのアプリケーション実行

実装した Mule フローは、Anypoint Studio 上で実行/デバッグすることができます。この作業は Eclipse 上で普通に Java プログラムを実行するのと同じであり、デバッグ実行ではコンポーネントに対するブレイクポイントの設定、ステップ実行、変数の Watch が可能です。

アプリケーションを実行すると最初にビルドが実行され、Mule フロー(実態はXMLファイル)のコンパイルでエラーになると起動に失敗して、Java スタックトレースを含むエラーメッセージがコンソールに表示されます。
下記は起動に成功した時のログの出力例です。

[起動成功時のログ]

デバッガーの実行はかなりシステムに負荷がかかるようで、起動までに時間がかかります。また、繰り返しデバッガーを起動すると Anypoint Studio 自体が不安定になることがよくありました。そのため、便利ではあるものの、デバッガーの実行は必要最小限に留めておいた方が良いと思います。

[デバッガー起動時の画面]

CloudHub へのデプロイ

最後に MuleSoft が提供するクラウド環境の API 実行環境である CloudHub へ Anypoint Studio からデプロイする方法について説明します。

まずデプロイしたい Mule プロジェクト上で右クリックメニューを開き、[Anypoint] - [Deploy to CloudHub] を選択します。

デプロイする環境(Sandbox/Production)を聞いてくるので選択します。実行環境である Runtime Manager と API Manager ではテスト用と本番用の環境を管理できるようになっています。テスト環境は Salesforce と同様に Sandbox と呼ばれ、本番環境は Production です。通常は Anypoint Studio から直接デプロイする時はテスト環境である Sandbox を選択します。

下記のデプロイ設定画面が開きますので、必要に応じてデフォルト設定を変更します。

ランタイムアプリケーション名 : Mule 組織内でユニークとする必要があるため、sand-  等の環境を表す接頭辞を付加します。

Worker size : vCore はサーバーリソースの単位であり、Mule 環境における課金の単位にもなります。他のAPIを呼び出すだけのIO依存の実装であれば 0.1 vCores で大丈夫です。

Workers : アプリケーションを冗長構成にしたい場合は2以上を選択します。Production では障害対応のため、通常は2つ以上の Worker を立ち上げますが、Sandbox であれば1つで問題ありません。

Region : アプリケーションを稼働させるAWSのリージョンを選択します。通常は Asia Pacific (Tokyo) を選択します(検証環境ではUSリージョンしか選択できません)。

[ランタイムアプリケーションへのデプロイ設定画面]

[Deploy Application] ボタンを押すと、CloudHub へのデプロイが開始されます。デプロイ作業は、プロジェクトのビルド → サーバーへの jar ファイルの転送 → サーバー側でのアプリケーションの起動 の順で実行され、完了までには数分かかります。

デプロイが完了したかどうかは、Anypoint Platform の Runtime Manager 上のアプリケーションの一覧から確認を行ってください。

[Runtime Manager でのデプロイ済みアプリケーションの確認]

 

MuleSoft 入門の第3回目は Anypoint Studio による Mule API の開発作業について、Mule アプリケーションの構成と基本的な作業の流れを説明しました。Mule による API 開発のイメージはつかんでいただけたでしょうか。クラウド上のコンソールである Anypoint Platform とローカル開発環境である Anypoint Studio の2つの環境にまたがって作業を行うため、最初のうちは作業を繁雑に感じられる方もいらっしゃるかもしれませんが、慣れれば作業効率はそこそこ高いと感じました。また、コンポーネントベースの Mule フローの開発も各種コンポーネントに慣れるまでの時間が必要にはなりますが、コーディングベースの開発と比べれば明らかに生産性は高いと考えます。

なお、API の実装作業の中では一番難易度が高かったのは Mule 独自のデータ変換言語である DataWeave によるデータの変換作業でした。Java 等の手続き型プログラミング言語とは構造が大きく異なるため、多くの人は慣れるまでに少々時間がかかるかもしれません。

次回は この DataWeave について、詳しく説明したいと思います。

 

[MuleSoft入門シリーズ]

MuleSoft入門(1)MuleSoft による API-led なアプリケーションネットワーク

MuleSoft入門(2)ようこそ Anypoint Platform へ

MuleSoft入門(3)Anypoint Studio による API の実装

MuleSoft入門(4)DataWeave によるデータ変換

MuleSoft入門(5)Flow Designer で Mule アプリケーションを開発

MuleSoft入門(6)MUnit による単体テスト

MuleSoft入門(7)API 開発におけるテストの考え方

MuleSoft入門(8)ポリシーと SLA

MuleSoft入門(9)カスタムポリシーの開発

MuleSoft入門(10)Mule API のバージョン管理

MuleSoft入門(11)ランタイムログの自動アーカイブ

著者について

Naoki Kitaarashi

アピリオのシニアコンサルとしてクラウドの世界に身を投じてはや5年あまり。プロジェクトでの立場に応じて、アーキテクト、リーダー、デベロッパーと様々なロールの仕事に携わっています。続々と新しいサービスと技術が登場するSalesforceの世界はエンジニアとして常に刺激を持ち続けられるエリアであり、2019年からはMuleSoftソリューションの起ち上げに関わっています。しばらくはAPI-ledなシステム連携を広めることに全力投球!!

Naoki Kitaarashi のコンテンツをもっと見る
戻る
MuleSoft 入門(4)DataWeave によるデータ変換(1/2)
MuleSoft 入門(4)DataWeave によるデータ変換(1/2)

今回は、Mule アプリケーションを介して受け取ったデータ( payload, attributes, variables など)にアクセスし、変換するための独自の MuleSoft 式言語である DataWeav...

次へ
MuleSoft 入門(3)Anypoint Studio による API の実装(1/2)
MuleSoft 入門(3)Anypoint Studio による API の実装(1/2)

第3回目では、Mule API 開発の基本的な流れと Eclipse ベースの開発ツールである Anypoint Studio について説明します。前後編の2部構成になっていて、前半はMule API の開発作業全...

アピリオまでお気軽にお問合せください

ご質問はこちら