インストールしたパッケージをカスタマイズする上でハマったこと
Force.com上で開発していく上で、パッケージをカスタマイズしていくことも多々あるのではないでしょうか?
(当方、glovia OrderManagementをカスタマイズすることが多いですが...)
そんなパッケージのカスタマイズの中で、思わぬ出来事に遭遇しましたのでご紹介しようかと。
結論から先に言うと...
ということです。
※予期せぬ例外が発生することもあるので避けるべき、ということです。
具体例
準備
今回発生したケースの前提です。
- パッケージ管理内で、「Status__c」というAPI名がテキスト型として定義されている(実際には、xxx__Status__c というAPI名になります)
- 上記のオブジェクトにカスタム項目として「Status__c」を選択リスト型として追加する
パッケージ内のオブジェクトとしては、こんな項目が定義されたようになります。
- xxx__Status__c(テキスト型)
- Status__c(選択リスト型)
ここで、さらに入力規則 or 項目自動更新で、「Status__c」を数式に使ってみます。例えば
IF( TEXT ( Status__c ) = 'xxxx', 100, 0);
という感じの数式を埋め込んでみます。
※ココでは、新たに追加した選択リスト型のStatus__cを使う感じです。
例外発生!
項目自動更新が実行されると、こんなエラーが発生するようになりました。
このレコードを保存するとき、ワークフローまたは承認プロセスの項目自動更新によるエラーが発生しました。(中略)
関数 'TEXT()' のパラメータが間違っています。期待数字, 日付, DateTime, 選択リスト、受信テキスト
え?
関数 TEXT() は選択リスト型で使用しているのに、なぜこんなエラーがッ...!?
大まかに書くと、こんな感じの現象でしょうか。。
原因は?
管理パッケージ内のトリガが起動したとき、それに併せて入力規則(パッケージ管理外で定義された入力規則も含めて)が評価されると思います。
入力規則を評価する際に、パッケージ内のトリガで発生してきた場合にはパッケージ内の項目を優先的に参照するのではないでしょうか?
(ただ、標準のSalesforce画面からデータ操作した場合、エラーなく処理されることもあったりと良く分からない・・ところもあります。すみません。。。)
回避策は?
結局のところ、
パッケージ内で定義されているAPI名で項目を追加するのは避けましょう
に尽きると思います。
今回の例でいうと、
- パッケージ内では Status__c(テキスト)で定義されている。(外部からは xxx__Status__c)
- パッケージ外で Status__c(選択リスト)で定義する
ということは止めましょう、という話ですね。
ただ、上記の現象とは別に、類似した名称で定義するのは混乱の火種になりかねないので、名前付けは熟考しましょう、ということですね。
※当たり前すぎる話でオチもないですが・・(苦笑)
最後に
一応、Salesforceに問い合わせたところ、既知の不具合のようで将来的なリリースにて修正予定とのことでした。(時期は未定)
そんなわけで、しばらくは
類似したAPI名を使うのは避ける
という回避策で逃げましょう。
今回はパッケージをカスタマイズしていく上でハマったお話でした。
ではでは〜