カスタムメタデータタイプのご紹介

本記事は英語版Salesforce Developers Blogのエントリ「Introducing custom metadata types: the app configuration engine for Force.com」の翻訳記事となります。 また、サンプルコードを Githubに公開しています。こちらも合わせてご確認ください。https://github.com/SalesforceDevelopersJapan/JP-SFDCConfig/

待望のカスタムメタデータ型がついに正式リリース

皆さんは、Salesforce MVP のAndrew Fawcett がこの記事 (英語) で次のように語ったのを覚えているでしょうか。「ここまでくると、プラットフォームでカスタムのメタデータを作成できるようにしたいですね。その日を心待ちにしましょう」

Summer ‘15 リリースで、ついに「その日」がやってきました。 これまで、Salesforce 開発者コミュニティでは、メタデータを作成する場合に Salesforce が提供する型を使うことしかできませんでした。カスタム項目を取引先オブジェクトに追加するにも、カスタムオブジェクトを作成するにも Apex クラスを作成するにも、選択肢は限られていて、Salesforce が標準で提供する方法を使うしかなかったのです。

しかし、Summer ’15 でついにカスタムメタデータ型が正式リリースされました。これまで Salesforce の社員にしか許されなかったことが皆さんにも可能になった—つまり、独自にメタデータ型を作成できるようになったのです。 このことは、アプリケーション設定の面で大きなメリットをもたらします。 現在、アプリケーションの設定には、エンジニア 1 ～ 2 人年相当の工数を要し、継続的な開発でさらに 20% 程度の作業負荷が加わります。カスタムメタデータ型があれば、導入に先立つ設定作業は数週間に短縮され、設定ツールの更新は数時間で完了します。

カスタムメタデータ型のレコード = メタデータ

カスタムメタデータ型は、メタデータのメタデータ、いわば「メタ・メタデータ」です。カスタムメタデータ型のレコードは、それ自体がメタデータであり、データではありません。

つまり、カスタムメタデータ型のレコードは、従来のカスタムオブジェクトやカスタム設定のレコードとは違い、変更セットを使ってサンドボックスからデプロイしたり、管理パッケージにパッケージ化したりすることが可能です。

カスタムオブジェクトやカスタム設定の場合、アプリケーションのデプロイでは、オブジェクトのメタデータ (ヘッダー) がデプロイされ、レコードはデプロイされずに残ります。

これらのデータが単なるサンプルデータ (例: 請求書カスタムオブジェクトの請求レコードなど) であれば、この動作で何ら問題はありません。

アプリケーション設定でカスタムメタデータ型を使う

一方、これらのレコードがアプリケーション設定に関するものだとしたらどうでしょう。困ったことになります。アプリケーション設定はアプリケーションの一部であり、アプリケーションから切り離すことはできません。

これまではどうしていたかというと、Salesforce ユーザやパートナーは、リストカスタム設定やカスタムオブジェクトを使って設定データを格納し、「レコードをアプリケーションと共にデプロイしたりパッケージ化したりできない」という問題に対処していました。しかし、カスタムメタデータ型を使えば、そのような対処は不要になります。アプリケーション設定のレコードを、取引先オブジェクトにカスタム項目を追加するような手軽さで、パッケージ化したりデプロイしたりできるようになります。

ユースケース

例を使って説明しましょう。「自社の組織と複数の銀行 (支払ゲートウェイ) を連携させる」というユースケースです (Dreamforce 2014 では、Fonteva IO がこのデモを実施しました)。ここでは、複数のテーブルを作成して、金融機関の API エンドポイントの定義、ログイン情報、API の名詞・動詞のほか、API 経由で取得するデータと API に送信されるデータがSalesforce のどこに保存されるかを示すマッピング情報などを格納します。 インテグレーションを実際に定義しているのは、これらのテーブルのレコードです。テーブルの 1 レコードが、1 件のAPI インテグレーションに対応します。 これらのテーブルをカスタムオブジェクトやカスタム設定で作成した場合、サンドボックスから本番組織にはヘッダーだけしかデプロイできません。ISV がパッケージ化できるのは組織のインストールに使われるヘッダーのみです。レコードについては別の方法で移行する必要があります。デプロイできるのは設定のフレームワークのみで、実際のアプリケーション設定は対象外です。 一方、カスタムメタデータ型を使用してテーブルを作成した場合は、定義とレコードの両方を含む設定全体をデプロイできます。これは非常に大きな違いです。

ユーザ企業のメリット – コンプライアンスの悩みを解消

設定に関するオブジェクトをそれほど使用していない (オブジェクトの数が少ない、あるいはレコードの数が少ない) 場合や、開発や更新自体をそれほど頻繁に行っていない場合は、カスタム設定やカスタムオブジェクトで対応するのが理にかなったやり方だと言えるでしょう。

しかし、Force.com を利用するほとんどの企業は、数十から数百のカスタムオブジェクトを運用しているか、あるいは、リストカスタム設定をアプリケーション設定用のオブジェクトに使用しています。こうした状況では、開発組織でレコードが作成、更新されるたびに、さまざまな組織にレコードを移行しなければなりません。多くの場合、本番組織へのデプロイにあたっては、インテグレーションテストやユーザ受け入れテストも必要になります。さらに、それを複数の本番組織で実行することが求められる場合もあります。

開発者やシステム管理者は、こうしたプロセスのあらゆるステップでレコードの移行を行うことになります。こうした処理を、メタデータとデータ API を組み合わせたスクリプトによって実行している企業もありますが、処理の順序は指定できるものの、すべてを単一のデプロイトランザクションに集約することはできません。手順は複雑になり、スクリプトの作成、テスト、更新などのコストもかさみます。

結果として、多くの企業は手動のプロセスに頼ることになります。データローダを使うほかに、ブラウザのウィンドウを 2 つ立ち上げてコピー & ペーストを繰り返すことすらあります。さらに、作業は一度で済むわけではなく、ソフトウェア開発ライフサイクルの各ステップで発生します。 こうしたプロセスでは、コストが高くつくだけでなく、エラーも起こりやすくなります。何よりも問題なのはコンプライアンスです。手動のプロセスは、コンプライアンス的にはもっとも避けたいやり方です。

パートナー企業のメリット – 年単位の開発作業からの解放

ISV などのパートナーも同じような問題に直面していますが、取り組みの方向性が異なります。パートナーが気にかけるのは、コンプライアンスではなくアプリケーションのライフサイクル管理です。顧客とプロフェッショナルサービス契約を結んでいない限り、ISV には、顧客の組織にレコードをロードして移行を行う権限はありません。また、そうしたアクセスを許可されたとしても、それほど拡張性のあるモデルにはなりません。 ISV は、通常、高機能なデプロイツールを開発することで問題に対処しようとします。しかし、ツールの開発自体に数か月を要し、場合によっては数年かかることすらあります。ツールのメンテナンスでもコストがかさみます。アプリケーション設定に影響を与える機能が開発されるたびに、デプロイツールの更新や再テストが必要になります。

カスタムメタデータ型が、ツールではなくアプリケーションの開発を可能にする

カスタムメタデータ型は、ソフトウェア開発ライフサイクルとアプリケーション管理ライフサイクルを自動化し、ユーザ企業とパートナー企業の双方にメリットをもたらします。レコードがデータではなくメタデータであるため、Force.com で現在提供されているあらゆるツールを活用して、管理、パッケージ化、デプロイを行えます。これにより、対症療法的なツールの作成に費やしていた時間を、アプリケーション開発に回せるようになります。

従来のアプリケーション設定プロセスを根本から見直す

アプリケーション設定でカスタムメタデータ型の利用が可能になったことは、これまでのアプリケーションのアーキテクチャを見直すきっかけにもなります。たとえば、リプレースできそうなリストカスタム設定はないでしょうか？ 組織データではなくアプリケーション設定データの格納に使用しているカスタムオブジェクトはどのくらいありますか？ ぜひ検討してみてください。 メタデータによるアプリケーション設定によって開発や管理のプロセスをどのように変革できるか、今回の記事を通じて、多少ともイメージをつかんでいただけたら幸いです。今後の記事 (英語) にもご期待ください。Summer ’15 リリースのカスタムメタデータ型に関する具体的な仕様、注目のユースケースのほか、このアプリケーション設定エンジンが提供する機能に関する拡張計画などをご紹介します。