パッケージ開発でカスタムメタデータを使ってみた

こんにちは、遠藤です。
Cariot事業部で Cariot（キャリオット） の開発や運用をしています。

さて、今回はSalesforceのカスタムメタデータという機能についてです。

パッケージ開発の中でカスタムメタデータを使ってみたので、実際に使ってみて、便利に感じた点や注意点とかを紹介します。
カスタムメタデータ、「名前は聞いたことはあるけど、何が嬉しいんだろう？」とか「カスタム設定と何が違うんだろう？」みたいな方のヒントになれば幸いです。

それではどうぞ↓↓

カスタムメタデータって何？

カスタムメタデータとは、ざっくり言うと、変更セットやパッケージにレコードを含めることができる特殊なカスタムオブジェクト（のようなもの）です *1。

出てくる用語、概念が紛らわしいですが、標準オブジェクト・カスタムオブジェクトとの対比で整理してみると、下の図のようになります。

標準オブジェクト・カスタムオブジェクトの場合は、型となるメタデータ（オブジェクト定義情報）があって、それに対する値（レコード）が存在します。
カスタムメタデータでも同じように型とレコードという関係があり、型の方を「カスタムメタデータ型」、値を「カスタムメタデータレコード」と呼びます。
両者の大きな違いは、カスタムメタデータレコードはそれ自体がメタデータである、という点です。
そして、メタデータであるために、変更セットやパッケージに含められるというわけです *2。

パッケージ開発においてカスタムメタデータのここが便利！

Cariotは AppExchangeアプリケーション として提供されており、管理パッケージの開発で、カスタムメタデータを使っています。
そこで感じたメリットや所感についてお話します。

パッケージ開発では以下のことに気を使って開発しています。

• 動作の後方互換性
  アップグレードしたら動きが変わってしまった、みたいなことがあると困りますよね？
• 設定データを使って、ある程度動作をコントロール、カスタマイズできるようにしたい
  毎回ApexやVFでのカスタマイズは骨が折れるので、基本的なところはポイントアンドクリックで変更できると便利ですよね？

このあたりの要件をまとめると、以下のようになります。

• パッケージをインストールしたときのデフォルトの設定値は、あらかじめ決めておきたい。
• インストール先の組織で、システム管理者が設定値を変更し、動作をカスタマイズできるようにしたい。
• パッケージのアップデートでデフォルトの設定値が変わった場合でも、今までの設定は維持しておきたい。

これらを満たすことができるのが、カスタムメタデータの機能（利点）です。

具体的に、私が開発で関わっているパッケージでは、以下のような設定データを管理するためにカスタムメタデータレコードを利用しています。

・動作を有効化、無効化するためのフラグ
・バッチの起動タイミング
・外部サーバのURL
・Visualforce画面を制御するための設定値

カスタムオブジェクト、カスタム設定との違い

カスタムメタデータの場合、レコード（カスタムメタデータレコード）を変更セット・パッケージに含めることができるというのが大きな違いです。

また、カスタム設定との比較については、Salesforce Developers Blogの以下のエントリにある比較表によくまとまっています。

How to use custom metadata types to save years of development on app configurations - Engineering

カスタム表示ラベルとの違い

カスタム表示ラベルの場合、値は単なる表示ラベル（テキスト）でしかないですが、カスタムメタデータの場合、独自の型を使って値を管理できます。

パッケージ開発という観点では、カスタム表示ラベルは基本的にインストールした先の組織で変更不可ですが、カスタムメタデータの場合、項目管理可能性オプションによってインストール先の組織で値を設定可能にすることができます。

使うべき？使わないべき？

上記のような使い分けを意識した上で、使えそうなら積極的に使っていくとよいのではないか、と思います。

比較的枯れた機能であるカスタム設定、カスタム表示ラベルに比べ、カスタムメタデータに関してはアップデートも多く、今後もどんどん便利になっていく（はず）でしょう。Summer ‘15でリリースされてから、主だったものでも以下のようなアップデートが行われています。

• Winter ‘16
  • 作成・編集・削除用の管理画面のリリース
  • カスタムメタデータレコードへのアクセスを制限する保護コンポーネントオプション
  • 項目管理可能性オプション
  • 設定変更履歴での変更追跡
• Spring ‘16
  • メタデータAPI upsertMetadata() によるカスタムメタデータレコードのupsertサポート
• Summer ‘16
  • 選択リスト項目のサポート
• Winter ‘17
  • メタデータリレーション項目（カスタムメタデータ型、標準オブジェクト定義、カスタムオブジェクト定義へのリンク）のサポート
• Spring ‘17
  • メタデータリレーション項目（項目定義へのリンク）のサポート
• Summer ‘17
  • カスタムメタデータへの入力規則サポート
  • ロングテキストエリア項目のサポート

また、支援ツールとしてCustomMetadataLoaderみたいなものも提供されています。

特に、新規の開発の場合、カスタム設定を使うのであれば、カスタムメタデータを使った方がよいと思います。また、Salesforceとしてもオススメしているみたいで、カスタム設定を新規に追加しようとすると、追加画面にて

リストカスタム設定の使用を考えている場合は、代わりにカスタムメタデータ型の使用を検討してください。リストカスタム設定とは異なり、カスタムメタデータ型のレコードはパッケージまたはメタデータ API ツールを使用して移行できます。

とヒントが表示されるくらいです。

一方、すでにカスタム設定を使っている場合であれば、わざわざ工数をかけてカスタムメタデータに移行するメリットがあるかというと…、うーん、そこまで強力なメリットはないかなという気もします。すでにカスタム設定でできてしまっているわけですから。

注意点

使えるデータ型

カスタムオブジェクト、カスタム設定、カスタムメタデータのどれも独自の項目を作成できますが、使えるデータ型には違いがあります。

データ型	カスタムオブジェクト	カスタム設定	カスタムメタデータ
URL	〇	〇	〇
チェックボックス	〇	〇	〇
テキスト	〇	〇	〇
テキストエリア	〇	〇	〇
パーセント	〇	〇	〇
メール	〇	〇	〇
ロングテキストエリア	〇	×	〇
数値	〇	〇	〇
通貨	〇	〇	×
選択リスト	〇（単一選択、複数選択）	×	〇（単一選択のみ）
電話	〇	〇	〇
日付	〇	〇	〇
日付/時間	〇	〇	〇
メタデータリレーション	×	×	〇

（注）カスタムオブジェクト固有のデータ型（自動採番、地理位置情報、テキストエリア（リッチ）、暗号化テキスト、数式など）は一覧から省略してします。

カスタムメタデータ固有のデータ型として、メタデータリレーションというものがあります。残念ながら（？）このデータ型はまだ使ったことがありません。どういうケースで使うのがベストなんでしょうか…？

制限

Salesforceでの開発においてはライセンスや各種制限を考慮したインテグレーションが必要です。

カスタムメタデータの場合も例外ではなく、制限や契約内容についてはきちんと確認しておきましょう。ちなみに、カスタムメタデータの場合、データのサイズについては10MBであることが明記されています。さすがにこの制限まで使い切るようなケースでは、使い方がマズい気がしますが…。

また、カスタムオブジェクトなどにありがちな作成数の制限に関しては、カスタムメタデータの場合、名言されたドキュメントが見つかりませんでした。

項目管理可能性オプション

パッケージの場合、インストール先の組織でレコードの項目値を変更できるようにするためには、項目の「項目管理可能性」オプションとして

• 「アプリケーションのカスタマイズ」権限を持つすべてのユーザ (パッケージのアップグレードでは値は上書きされません)

を選択する必要があります。

まとめ

カスタムメタデータを使うと、今まで面倒だった設定データの扱い、リリースを楽に行うことができます。うまく使って開発を効率化していきましょう！

*1:表面上はカスタムオブジェクトとカスタムメタデータは似て非なる機能ですが、JSforceやForce.com移行ツールでエクスポートした型情報のメタデータXMLファイルは、どちらもobjects以下に置かれ、管理されます。内部的にはほとんど同じなのかもしれませんね。

*2: ちなみに、こういった関係性から、カスタムメタデータ型はメタデータのメタデータという位置づけになるので、「メタ・メタデータ」と言われていたりします。
http://blogjp.sforce.com/2015/08/post-6ef4.html