数式項目のコンパイルサイズ制限をかいくぐる(後編)

  • 投稿日
  • 更新日
  • 著者 LIMA
  • カテゴリー Web系

前編に引き続き、「Tips for Reducing Formula Size(Last updated: October 19, 2013) PDF資料」の日本語訳です。

免責事項

当コンテンツの閲覧及び利用に伴い、何らかのトラブルや損失を負った場合などのいかなる損害も当方では一切の責任を負いません。利用者による自己責任の元でご参照ください。
当コンテンツにてご紹介しているウェブサイトやソフトウェアの合法性、正確性、最新性、適切性など、その内容については一切の保証を致しかねます。

ファンクションのコール数を最小限にする

全ての数式の関数が、等しくコンパイルされるとは限らない。
DATE()やMONTH()のような日付関連の関数は大きな結果を生成する。
関数の参照数が少なくあればあるほど、コンパイル結果は望みどおり小さくなる。
CASE()ロジックで項目を呼ばれる数を減らした例を見たばかりだが、これは関数にも応用できる。
Answers communityからの別の例だ。選択リストには航空会社の名前が含まれていて、この数式は航空会社のウェブサイトへのリンクを返す様になっている。

CASE( Airline__c,
"Airline 1",  HYPERLINK("http://airline1.com", "Airline 1"),
"Airline 2",  HYPERLINK("http://airline2.com", "Airline 2"),
/* Dozens of other airlines */
""
)

選択肢がとても多いリストだったので、この数式はコンパイルサイズの制限を超えてしまった。しかし、リンクの表示名が、選択肢の表示名と同じ場合には、HYPERLINK()をCASE()の外に出すことで参照数を一回に抑える事ができる。
この見直しによって、各選択肢のコンパイルサイズが133文字あったものを38文字まで減らす事ができた。

選択項目を再考する

上に挙げた航空会社の例ではCASE()が選択リストの値をチェックし、数式を項目にセットしている。もし20以上の選択肢をCASE()でチェックする予定なら、選択リストではなく参照（ルックアップ）を検討したらどうだろう。
選択リストか参照（ルックアップ）を選ぶ場合、次の事項について考えてみよう。

  • オブジェクトのサポート数（セールスフォースのエディション次第）
  • 他の項目値に依存するかどうか
  • 使用者のユーザ・エクスペリエンス
  • 選択リスト値の変更頻度
  • クロスオブジェクト参照数の制限にどれぐらい近付いているか

他の方法で数式のコンパイルサイズを減らせない場合、選択リストの値をそれぞれ他のカスタムオブジェクトの項目値として設定することも検討してみよう。
以前例示した手数料の数式では、「Commission Multiplier」というAgentオブジェクトの数値項目があった場合には、数式はクロスオブジェクト参照を用いた簡単なものになる。

Base_Commission__c * Agent__r.Commission_Multiplier__c

オマケ：もし新しいagentが増えたとしても、その都度数式に手を加える必要がなくなる。良い感じ。

原因について違う風に考えてみる

それでもだめなら、ワークフローの項目自動更新を使う

SalesForce