数式項目の制約
数式項目は便利なデータ型ですが、数式を定義する際には以下のような制約事項があります。
- 数式項目に直接含まれる文字数制限 (3900)
- 含まれる他の数式項目を組み入れた後の数式の合計サイズ (5000 バイト)
ここでいう、文字数と数式サイズは少し意味が異なります。
文字数はコメントや空白を含めた字数のことで、簡単に言うと、数式エディタに記載されている文字数です。
数式の合計サイズ（以下、コード数と呼びます）は計算に影響のあるコード部分の文字数となります。
こちらは、コメントや空白は計算には影響しないのでカウントされません。
コード数＝数式に記載されている文字数（スペースやコメントは除く）ではないので注意してください。
実際に数式を作って検証
まずはものすごい長い数式を作ってみます。
今回は職業コード（ShokugyoCode__c）を職業に変換する数式項目（Shokugyo__c）を作成します。
このように、職業コードを職業に変換する数式をCase文を使ってひらすら羅列しています。
ある程度記載していくと、コード文字数が5,000字を越えるとエラーとなり、登録ができません。
エラー: コンパイルされた数式が大きすぎて実行できません (X,XXX文字)。5,000 文字以下にしてください。
文字数制限の3,900字条件よりコード数の5,000字の上限が先に来ました。
これは、標準で提供されているCase文にも内部で処理しているコードが使用されているため、その数がカウントされているためです。
コード数が5,000文字以下になるように調整して保存します。
コード数がギリギリの状態でも、スペースやコメントはコード数に加算されないので、ある程度のコメントは入れられます。
ただし、文字数にはカウントはされるため、数式内で3,900字を超えてしまうとエラーになります。
次に、別の数式を使用して、この数式を参照する数式を作成します。
職業を参照するように数式を作成すると、このように明らかに数式エディタ内が5,000字以下でもコード数の上限エラーが発生します。
つまり、数式を参照すると、数式の結果が代入されるのではなく、数式の計算式が代入される形となります。
上記の例で言うと、Shokugyo__cの部分が
"この会社の職種は" & Shokugyo__c & "です。"
という数式のShokugyo__cの部分が
"この会社の職種は" & "議会議員" & "です。"
といった結果が代入された形ではなく、
"この会社の職種は" & CASE( ShokugyoCode__c , "011","議会議員", "012","管理的国家公務員", "013","管理的地方公務員", ・・・ ) & "です。"
といった形で算出前のCASE文の形で代入されるため、コード数も多くなります。
そのため、数珠繋ぎ的に数式を参照していると雪だるま式にコード量が増え、あっという間に5,000字オーバーしてしまうので、そうならないように項目設計をしましょう。
関数使用の注意点
数式の中で提供されている関数は非常に便利なものが揃っていますが、モノによってはコード量を食うものがあります。
これらの関数を使った場合、その関数内で行われているコードが実行されることになるので、そのコード数もカウントされた数になっています。
CASESAFEID関数なんかはかなりのコード数を要するので、取り扱いには注意しましょう。
コード量を抑えるためには
上限がある以上、数式のコード数をできるだけ少なく抑える必要があります。
数式内で別項目を参照するときはAPI参照名が使用されますが、コード数はAPI参照名の長さは特に関係がないみたいです。
また、計算式はどうやら最適化されているみたいで、複雑な式を完結にしてもコード数は変わらない模様です。
（例：1+1 としても、2としてもコード数は同じ）
数式を乱用しないのが一番でしょう。
それでも使わざるを得ない場合は、項目の参照を最小限にしましょう。
例えば、
x__c * y__c + x__c * z__c
という式では、x__cへの参照が2回行われてしまうので、
x__c * (y__c + z__c)
とすることで、x__cへの参照が1回で済みます。
x__cがCase文などのコード数を要する数式だったらこれでかなりコード数が抑えられるので工夫してみてください。
それでも、コード数上限が足りない場合は数式を諦めてワークフローやトリガなどで項目自動更新するのも一つの手じゃないかと思います。
コメント