【Salesforce】カスタム設定まとめ

Salesforce

前々から気になっていたカスタム設定。カスタム3兄弟の中ではいつも末っ子のカスタム表示ラベルばかり使っているのだが、次男坊(カスタム設定)の面白い特徴を聞いたので、これを機にちゃんと使い方を覚えようかなと。

長兄のカスタムメタデータはまた今度だ!!

カスタム設定の特徴

ちょっと触るとわかることなんだけど、カスタム設定はオブジェクトのような感じでデータを保持できる。で、使い所がありそうだなと思ったのは次の2点。

  • Apexから更新できる
  • 階層型

詳しくは公式の開発者ガイド参照。

Apexから更新できるというのはそのままの意味。カスタム表示ラベルはApexから更新できないのでシステム定数としての用途にとどまるけど、Apexから更新できるとなるとだいぶ用途が広がるなーという印象。カスタム3兄弟は定数として使うものだとばかり思っていたけど、それだけではないみたい。

そして階層型。カスタム設定を階層型で作成すると、データはプロファイル毎、ユーザ毎に保持できる。それと・・・うーん、あれだな、階層型は言葉ではなかなか伝えづらいなぁ。正直、初めて開発者ガイドを見たときも全然イメージが沸かなかったし。なので少し詳しく書いてみる。

階層型のイメージ

先にも触れたが、カスタム設定はオブジェクトに近い構成だ。例えば下は試しに作った「カスタム設定サンプル」という名前のカスタム設定だが

オブジェクトで言うと、赤枠の部分がオブジェクト定義で、青枠の部分が項目定義に相当する。オブジェクトみたいな感じで項目を自由に追加できる。上の例では試しに「フラグ」というチェックボックス型の項目と、「メモ」というテキスト型の項目を追加してみた。

で、このカスタム設定にデータを新規作成しようとすると、「保存場所」でプロファイルかユーザを選ぶことになる。

なので、例えば↓こんな感じとか

↓こんな感じで登録する。

登録したデータはこうなる。

このカスタム設定を下の2人のユーザが参照したらどうなるか?

↓こうなる。

ユーザのデータがあればそっちを参照するし、無ければプロファイルのデータを参照する。より具体的な情報を勝手に見に行ってくれる。

こんな感じでプロファイル毎、ユーザ毎にデータを保持できる。
使い所としては、カスタム表示ラベルの場合は値を変更すると組織全体に影響してしまうんだけど、カスタム設定の場合は特定のプロファイルやユーザに対してのみ変更を反映させることができるところかな。

うーん・・どうだろ、説明長くなっちゃったな。

なお階層型の特性上、同じプロファイルやユーザのデータを複数持たすことはできない。

階層型でも全プロファイルのデータを登録しておく必要はない

上の話だけで語るとだ。例えば下のような新たな登場人物が出てくると

どのデータともマッチしない。

じゃあ、少なくとも全てのプロファイルのデータを作ってあげないといけないの!?というのはあまりにも面倒だし、保守性が悪い。

さっきハショッてしまったんだけど、カスタム設定では組織のデフォルト値が設定できて、プロファイルにもユーザーにも合致しない場合は組織のデフォルトを勝手に参照してくれる。いいね!

数式項目からカスタム設定を参照

カスタム設定は数式項目から参照できるみたい。
コードを使用したカスタム設定へのアクセス

{!$Setup.CustomSettingName__c.CustomFieldName__c}

数式から参照できるのは有り難い。階層型の特性を理解していれば、けっこう使い所ありそうな予感!

Apexから参照

Apexから参照する場合はこう。API参照名は、上で試しにつくったカスタム設定サンプルのやつね。

// インスタンス生成
CustomSettingSample__c custom = CustomSettingSample__c.getInstance();

// 項目の値を参照
Boolean flag = custom.Flag__c; //フラグ
String memo = custom.Memo__c; //メモ

getInstanceメソッドでインスタンスを生成すると、ログインユーザに該当するデータを選んで引っ張ってきてくれる。あとはオブジェクトと同じような扱いをすれば良いので、感覚的にも使いやすい。

オブジェクトと同じような使い方ということで、下記のようにSOQLでも取ってこれるみたいだが

List<CustomSettingSample__c> customList = [SELECT Id, Flag__c, Memo__c FROM CustomSettingSample__c];

階層型の特性を考えると、いまいち使い所が違うというか、ナンセンスな気がする。

あと注意点として
例えば該当するデータが無くて、組織のデフォルト値も登録されていない場合、カスタム設定の値は取得できない。ただその場合でもインスタンスがnullにならない。取得できなかったことを判定したいなら下記のように書けばいける。

// インスタンス生成
CustomSettingSample__c custom = CustomSettingSample__c.getInstance();

// 取得できなかった場合
if (custom.Id == null) {
    System.debug(‘カスタム設定が取得できませんでした’);
}

他にも何だかいろいろできるみたい。こちらを参照。
コードを使用したカスタム設定へのアクセス
カスタム設定メソッド

Apexから更新

カスタム設定値をApexから更新する場合も、オブジェクトと同じようにDML操作でいける。

// インスタス生成
customSettingA__c custom = customSettingA__c.getInstance();

// カスタム設定が取得できた場合、更新
if (custom.Id != null) {
    custom.Flag__c = true;
    custom.Memo__c = ‘更新’;
    // 更新
    update custom;
}

最後に

いやー今までカスタム表示ラベルで実装していた処理も、カスタム設定使えばよかったなー・・というものがいくつか思いあたりました。カスタム設定は、カスタム表示ラベルの上位互換という印象ですね。

でもまあカスタム表示ラベルの方が使い勝手が良いし、なんといっても理解しやすい!運用やメンテナンスを誰か別な人に引き継ぐことを考えると、やっぱカスタム表示ラベルなのかな~という思いもあります。使い所ですかね。

あとはカスタムメタデータ、近々使ってみよ。

コメント

タイトルとURLをコピーしました