こんにちは。株式会社VALGOエンジニアのヌマです。
地元秋田からリモートで東京や大阪など全国各地のお仕事をしています。
背景
多数のSaaSを導入していたり、社内システムが多い会社では、データの整合性やリアルタイムでのデータ連携が素早くできることがデータ活用の鍵となってきます。
Salesforce社の「Mulesoft」はデータの利活用を促進する目的で導入されることが多く、世界中の企業で導入が進んでいます。
ローコード開発でスムーズに導入していけるのが特徴ですが、開発者目線では詰まることが多々あります。
今回はAnypoint Studioを使っているときにつまずくポイントをまとめました。
質問回答集
Q1. Local環境でデプロイがうまく実行しない
このエラーに関しては、始めてからよく詰まるところになります。
よくみる原因をいくつか列挙します。
A1-1. Anypoint Platformへのログインセッションが切れている
エラーメッセージ
Failed to execute goal on project "projectName": Could not resolve dependencies for project "orgId:projectName:mule-application:version"...
Mule Paletteの「Search in Exchange」をクリックし、Add Account（もしくは再ログイン）することで依存関係にあるRAMLやコネクタを正常に読み込み、デプロイができるようなります。
ログイン画面下の方にセッションが切れる日付を設定する項目があり、ここで最大値の15を入力しておくことで、15日間はこのエラーに怯えなくてもよくなります。
A1-2. Mavenリポジトリのローカルキャッシュがおかしくなっている
エラーメッセージ
Failed to execute goal on project "projectName": Could not resolve dependencies for project "orgId:projectName:version": Failed to collect dependencies "orgId:projectName:zip:raml:version": Failed to read artifact descriptor for "orgId:projectName:zip:raml:version": The following artifacts could not be resolved "orgId:projectName:pom:version"(absent): Could not transfer artifact "orgId:projectName:pom:version" from/to MuleRepository ("MuleRepositoryURL"): status code: 401, reason phrase: Unauthorized (401) -> [Help 1]
Anypoint PlatformのExchangeで公開したRAMLをダウンロードする際に不具合があった場合にMavenリポジトリのローカルキャッシュに不要なファイルが入ってしまうことがありました。
ユーザー > “ユーザー名” > .m2 > repository > “組織ID” > “API名” フォルダの中にそのAPIのバージョンごとにフォルダが作成されています。
デプロイを行いたかったバージョンのフォルダを削除してからデプロイを行うとローカルキャッシュに対して再度ダウンロードが走るため問題なくデプロイできるようになります。
A1-3. secure-properties configのkeyを設定し忘れている
エラーメッセージ
Couldn't find configuration property value for key ${runtime.property}
config.yamlファイルやconfig.propertiesファイルに入力している接続情報を暗号化している場合、デプロイ時に複合化キーを渡してあげる必要があります。
【参考】https://docs.mulesoft.com/jp/mule-runtime/latest/secure-configuration-properties
Anypoint Studioで複合化キーを渡すために「Run configurations」で設定をする必要があります。
画面イメージでは、runtime.propertyというグローバル変数に対して”xxx…”という複合化キーを渡しています。
Q2. Munitがうまく実行しない
A2-1. Local環境でデプロイがうまく実行できていない
こちらもデプロイ時と同じエラーが発生します。A1-1からA1-3の解決方法を試してみてください。
A2-2. Mock whenのPick processorで指定している先のコンポーネントを間違えている
モックしているコンポーネントやそのコンポーネントのdoc:idなどが間違えているとそのコンポーネントがうまくモックされず、エラーやfailuresになります。
A2-3. テストを行っているフローとは別のフローを動かすのにEnable Flow Sourcesに登録を行っていない
画面イメージはMunitフローの画面イメージですが、ここの一番下にある”Enable Flow Sources”に何も設定していないことが見えます。
もしこのMunitのMock whenでThen Callを使い、テスト用のフロー（図中ではstub-apiFlow）を呼び出したいときは、下図のように設定を行わなければいけません。
A2-4. readUrlで読み込みを行っているjsonファイルのスペースの数や改行コードが違う
Munitを行う際に、MockからのResponseや判定に利用するJsonをsrc/test/resourcesに格納することで、readUrlというDataweave関数を使って参照することが可能になります。
格納したjsonファイルをAssert equalsで利用する際にPayloadとの差分がないはずなのにFailure判定になることがあります。
したがって、サクラエディタやVisual Studio Codeなどのエディタを使ってスペースと改行コードを修正することで解消する可能性がありますのでお試しください。
Q3. Runtime Managerへのデプロイがうまくできない
A3-1. Munitがうまく実行しない
A2-1からA2-4までの解決方法を試してみてください。
A3-2. pomファイルで設定するバージョンのアップができていない
エラーメッセージ
[An asset already exists with this version and publish lifecycle state.]
画像イメージの7行目に記載があるversionですが、以前上げたバージョンと同じバージョンだとデプロイが走った際にバージョン重複エラーが発生します。
バージョンアップしなければならない場合はバージョンアップをしましょう。
バージョンアップしたくない場合は以下の手順となります。
末尾に-SNAPSHOTと記載することで、同じバージョンでリリースできるようになります。
まとめ
開発した資材をLocalにデプロイするところからRuntime Managerにデプロイするところまででつまずくポイントの解決方法をいくつか紹介いたしました。
ローコード開発ですので、新たにMulesoftを始める方も多くいらっしゃると思います。今回のブログでで少しでもMuleSoft初学者の手助けになれば幸いです。