前回はGlobalファイルを作成して、設定情報を集約しました。今回はHTTP Listenerを1つのファイルにて集約していきたいと思います。
HTTP Listenerを集約する
GlobalファイルはConfig系を集約することで管理しやすくすることを目的としていました。
今まではHTTP Listenerについて、適宜Mule Paletteから追加していましたが、今回インタフェース部分を集約して1つにまとめたいと思います。Globalファイルは手動で集約する形でしたが、HTTP Listenerへの集約はAPIkitを使用して、定義したRAMLからコードを生成するような形になります。
以降、HTTP Listener集約したフローのことをinterfaceと呼ぶことにします。
interfaceの仕組み
HTTP Listenerを集約する前と後のイメージはこのようになります。
今までは、HTTP Listenerを各フローに配置していましたが、整理後はinterfaceというファイルにすべて集約されます。すべてのエンドポイントがinterfaceフロー内で受け止められて、APIKit Routerというコンポーネントによって、エンドポイントごとにフローを割り当てるような仕組みです。
interfaceファイルはDesign Centerから定義されたRAMLによって作成されます。
interfaceを作成する
globalファイルは自身で作成しましたが、interfeceファイルはAnypoint Studioで作成してもらいます。
まずは、Anypoint PlatformのDesign CenterからRAMLを定義します。今回はこのような感じで、「/hellomule」と「/getaccounts」のエンドポイントが定義されたRAMLを用意します。
以前「Design CenterによるAPI定義から取得まで」という記事でDesign CenterへのRAML記載からAPI情報の取得までをご紹介しましたが、この内容でほぼ手順としては8割方済んでいます。APIをExchangeから取得する際、「Do you want to scaffold ‘プロジェクト名’ specification?」というダイアログが表示されますが、今回はこちらの問いには「Yes」で回答します。
もし以前に「No」を選択した場合でも、プロジェクトから右クリック→「Anypoint Platform」→「Download RAML from Design Center」を選択することで、Design Centerで定義したRAML情報を取り込むことができます。
ダウンロードするとこのように、xmlファイルが自動で作成されています。Design Centerで定義したプロジェクト名がそのままファイル名となります。もし、同名のファイルが作成済みの場合は、ファイルが上書きされてしまいますので、作成済みのファイルをリネームしておくといいでしょう。
ダウンロード後、自動的に作成されたファイルの方をリネーム「interface.xml」という名前でリネームします(初回のみ)。
今後はHTTP Listenerをこのinterfaceファイルにて集約することになります。既に作成済みのHTTP Listenerについては削除します。
interface.xmlファイルにはDesign Centerで定義したエンドポイント単位でフローが作成されています。
エンドポイント「/hellomule」のHTTP Listenerを削除したので、interfaceにあるhellomuleのフローから、Flow Referenceコネクタを追加し、先ほどHTTP Listenerを削除したフローを呼び出すようにします。
新たにHTTP Listenerのエンドポイントが増えた場合は、以下の手順を踏むことで追加が可能です。
- Design CenterからRAMLのエンドポイントを追加
- Exchangeに公開
- Anypoint StudioでRAMLをダウンロード
- interface.xmlに追加したエンドポイントのフローが作成される
- 追加されたフローからFlow Referenceを追加する
また、手順3でダウンロードした場合、既に作成済みのinterface.xmlファイルに対して、既存のフローが初期化されたり、ファイル名がリネーム前の状態に戻ることはないのでご安心を。そのままinterface.xmlのファイルに対して、追加したエンドポイントのフローが追加されるので変更分だけ修正すればOKです。
まとめ
- Design Centerから定義したRAMLに基づいてinterfaceを生成
- 初回はDesign Centerのプロジェクト名で命名される、リネームする場合は初回のみで以降のリネームは不要
- APIkitによって、エンドポイント単位でinterface内のフローを振り分け、以降のロジックについてはFlow Referenceにてinterface外のフローから実施
- エンドポイント追加の場合は、RAMLの再定義から実施し、再度interfaceを取り込むが既存のフローについては上書きされることはない
これにて、HTTP Listener及びConfig系の集約が完了しました。次回はMuleのメッセージ領域について取り上げたいと思います。
コメント