初期値をセットするカスタムボタン作成を試してみました。Spring'20から使えるようになった機能の一つです。
さっくり設定してみるとこんな感じ。文字列の指定の場合はシングルクォーテーションとかは不要でした。
パラメータの設定に誤りがあると初期値がセットされずに空白のまま表示されるので、表示されなければどこか間違っていると思って調べれば良さそうです。最初にTrailheadやリリースノートのサンプルを試したときに値がセットされていなかったので、動かないと思ったりしましたが、一部のパラメータを除外したときにカッコの消し忘れがあって動かないだけでした。固定値ではなく変数の値をセットするなどでも問題なく動きます。
レポートの基準線をつかったグラフ幅の調整を試してみました。レポートのグラフ表示ですが抽出条件によっては集計結果に大きく差が出て一つのグラフが突出して長くなったります。
表示結果としては正しいのですが、画面の左端から右端まで視線を動かすことになるためちょっと疲れる気がしました。
このグラフ表示の長さが気になる問題については基準線の表示機能を使うことで解決します。
データの中で一番大きい値よりも更に大きい値を基準線として指定することでグラフの長さを調整できます。小さい値のグラフはより短くなりますが、値の表示をすれば大きな問題は無いのかなと感じました。
長さの調整はできましたがもう少し見やすくできます。基準線の色です。
青色とかだと少し気になってしまうので灰色系の色に設定してあげると良いと思います。
ブラウザのコンソール機能などで標準の色のカラーコードを調べてセットすればより自然ですが、そこまで気にする場所では無いのでそれらしい近い色を指定しておけば問題ないと思います。
レポートの基準線をつかったグラフ幅の調整についてはこんな感じでした。
Apex開発で押さえておきたいポイントについてです。
Apex開発は社内の業務をより効率良くSalesforce上で行えるように機能を開発できる仕組みです。データ入力の負担削減のための画面開発や日々のデータの自動更新など様々な場面で利用される仕組みだと思います。
Apex開発は基本的に何かしらの課題を解決するために行います。そのためユーザから要望を受けて開発案件が開始されます。
Apex開発イメージとして以下の要件を例に紹介します。
①取引先のデータを登録する画面を開発してほしい。
②取引先データ作成が成功したら画面に成功メッセージを表示してユーザにわかるようにしてほしい。
この要件を満たすコードはこんな感じ。(画面周りの処理等細かい部分は省略します。)
画面側の処理は今回は省略しますので開発者コンソールから動かします。
データ登録を確認できました。取引先の登録機能が完成です。
できた機能を試したユーザから追加の要件を提示されました。
①未入力のまま処理を行うと正しいデータ登録がされないので入力チェックをしてください。
②未入力の場合は登録処理を行わないで大丈夫です。
③未入力エラーの場合は作業者にわかるようにメッセージを戻り値としてセットしてください。
要件を満たすようにエラー判定を追加しましょう。
ユーザは正常系と値未入力の場合の両方の動作確認を行い問題がないことを確認しました。これで要件を満たした機能の開発をすることができました。やったー。
本番リリース前に予期せぬエラーが発生したときのためにデバッグログの処理を入れておきましょう。これで問題がおきたときの調査が進められます。エラー判定の要件には含まれていないのでメッセージの表示はいらないですね。
これで取引先登録機能の運用を開始することができました。
運用開始後問題なく動作する日々が続くと思います。そんなある日、ユーザの管理者があることに気づきました。「あれ..ここしばらくデータ登録が行われていない..」。
ユーザの管理者が作業者に確認したところ、作業はいつもどおりにやっているようでした。
ユーザは原因の調査のため、開発者コンソールを開き画面にアクセスして登録処理を動かし、デバッグログを確認しました。
デバッグログをチェックしてシステムのエラーが発生していることに気付くことができました。どうやら画面開発からしばらく経過した後に入力規則が追加設定され、取引先登録に必要な条件を満たせなくなっていたようです。
無事に原因を特定できて対策についての検討を開始できました。数日、もしくは数ヶ月のデータ登録は行われていない状況となりましたが、これで問題解決の流れに進められます。
−−−− 上記の流れは一見問題無いように見えますが、Apex開発時にひと手間加えることでトラブルを大きくせずに対処することが可能となっています。
①今回ユーザが開発者コンソールでログを確認することで不具合の調査を行うことができました。ただ、実際のところ開発者コンソールを開いてデバッグログをチェックして調査するユーザは基本的にはいない前提で考えた方が良いかもしれません。ユーザが異常発生に気付く仕組みについては考慮が必要です。
②一度運用が開始されるとそれ以降に機能の追加は行われないというケースは考えにくいです。開発した機能とは別に入力規則が追加されることや権限周りの変更が行なわれたりという場面は考慮する必要があります。
①開発時にExceptionエラーを考慮する
いつの日か追加される入力規則の判定処理を事前に実装するのは不可能です。ですがこうしたエラーはExceptionエラーでチェックできます。System.debugでは調査はできても検知はできないので、画面開発の場合は、作業者に異常が発生していることがわかるように画面に表示してあげるのが良いと思います。
予期せぬエラー発生時にExceptionメッセージを画面に表示することで、作業者が異常発生に気づく仕組みを用意できました。少し良くなりましたが、まだ改善が可能です。上記キャプチャの通り、Exceptionエラーのメッセージはシステム用管理者向けメッセージでシステム利用者向けではありません。(システム用語の英語が含まれている辺りですね。)
今回の登録処理で予期せぬエラーをチェックしたい場合はDmlExceptionで判定しましょう。これにより入力規則判定で設定したエラーメッセージをそのまま取得することができます。
こうすることでユーザ向けに違和感の無いメッセージを表示できます。
不具合発生に気付けるのは早ければ早い方が良いです。いくつか方法はあると思いますがメール通知の仕組みがあると良いかもしれません。
おそらく開発時の要件としてユーザが提示することは無い部分ですが、こうした考慮を行うことでシステムを健全に運用することが可能になります。
運用時に考慮しておきたいのは下記の２つ。
①管理者ユーザでもシステムで異常がおきていないかを日常的にはチェックできない。
②一般ユーザが異常発生時に連絡をくれるとは限らない。
基本的にシステム利用者はシステムは正しく動作している前提で利用します。
「新しい判定を追加したらシステムが動かなくなった。」「長く運用していたらシステムが動かなくなった。」これ自体は日常的に起きることで特に問題は無いと思います。システムは一度作ったら完成ではなく日々メンテナンスが必要になります。ただし、異常発生が隠されていると対処できることも対処できません。(今回のように入力規則追加後に画面が動かなくなることを確認できれば入力規則追加を一旦見送って画面を改修という選択は普通に行なわれると思います。)
①Apexテストクラスをつかったエラーチェック
Apex開発時にはテストクラスの開発が必要になります。テストクラスがあれば新しい処理を追加する際に、もしも既存機能に影響を与えてしまう場合はそれに気づくことができます。(すべての影響チェックが可能になるわけではありませんがデータ登録ができなくなるレベルでしたら気づけるはず。)
②Sandbox環境の構築
Apex開発では開発用にSandbox環境を構築できます。本番と同じ設定情報を持つ組織で安全に開発作業を行うことができます。Apexテストクラスの仕組みと合わせることで、システム開発を適切に行うことができます。
上記画面開発の例としてtry-catch処理でのException判定を紹介しましたが、これはユーザの目に触れる部分のための判定方法となります。
バッチやトリガについては裏側で動く仕組みのため、Exception判定を省略しても支障は無いと思います。Apex開発では予期せぬエラー発生時に、try-chatch処理でエラーを握りつぶさなければ、管理者宛にエラー通知が送られる仕組みがデフォルトで用意されています。またロールバック処理なども独自に実装する必要なくデフォルトで用意されています。
(Exceptionエラー発生時の細かい部分については組織ごとのルールがあると思いますが、コード見てtry-catchの記述が無いからといって気にする必要はありません。)
システムは日々メンテナンスが必要なものです。放置したまま長く使っていけば動かなくなり対応が必要になることは普通のことだと思います。(開発時に考慮漏れやうっかりミスをしてしまったというのも、良くはないですが発生します。防ぐ努力は当然すべきですし、起こしてはダメなレベルのミスはありますが..)
大事なのはそうした場面が発生しまうのを事前に防止するためにきちんと管理していくことと、もし問題が起きてしまったときでもスムーズに解決できるように準備しておくことが大事だと思います。
上記内容を見てソースコードを確認された方で、極端にエラー判定が無い。予期せぬエラーが起きた。とする必要は基本は無いと思います。また、複雑な要件の機能の開発や既存機能の改修を引き継いて作業する場面など、状況によってExceptionエラーをあえて握りつぶさないと行けない場面も発生するかもしれません。
気にしなくてはいけないのは、一から作ってもらった機能の大半でトラブルが起きているとしたらそれはちょっと気にしたほうが良いかもしれません。
昔書いたApex開発で押さえておきたいポイントに関する記事です。
qiita.com
Visualforceのモバイルアプリのアクセス制御についてです。Visualforceページの開発ではモバイル端末での利用は対象から除外して開発することはよくあると思います。そうした場合、モバイルデバイスのサイズでページにアクセスできてしまうとレイアウトが崩れた状態で表示されてしまいます。この問題を回避するにはVisualforce設定の「Lightning Experience、Lightning コミュニティ、およびモバイルアプリケーションで利用可能」チェックを除外することで対応できます。
チェックボックスの説明の中に「Lightning Experience」の記載が含まれていますが、チェックOFFの状態でもPC利用の場合は問題なくページにアクセスできました。(確認したのはタブ経由のVFアクセスとカスタムボタン経由のVFアクセスの2パターンです。)
確認したのは上記2つですが、これがサポートされていればほぼ問題は無いと思います。また、ヘルプの方にも「Salesforce モバイルアプリケーションと Salesforce フルサイトの両方に表示する」場合の設定として紹介されていることを確認しました。
モバイルからのアクセスは許可したくない場合は、チェックをOFFにすれば良いと思います。
Lightning ExperinceのURLとオブジェクトの子リレーション名についてです。Lightning ExperienceのURLにはオブジェクトのAPI名が含まれます。
詳細ページは通常のオブジェクトAPI名ですが、関連リストのすべての表示ページなどでは子リレーション名が表示されます。
標準オブジェクトの場合は特に気になりませんが、カスタムオブジェクトの場合は任意の子リレーション名を指定するので少し注意が必要です。
今まで子リレーション名を使うのはApex開発のSOQLクエリ実装の場面ぐらいでしたが、Lightning ExperienceではURLに使われるようになっているので設定の際にはURLでの使用も考慮して名前付けすると良さそうです。
SOQLクエリで位置の近い順の取得を試してみました。Salesforceでは位置情報用のデータ型を作成でき、緯度・経度の情報を登録できます。緯度・経度の情報があれば、SOQLクエリのORDER BY処理で取得することが可能です。
(Twitterで教えてもらいました。)
ORDER BY DISTANCE(AddressLatLng__c, GEOLOCATION(35.6797885, 139.7623838), 'km') ASC
AddressLatLng__cはカスタム項目のAPI名です。これとGEOLOCATION関数を組み合わせることで対象項目と指定した緯度・経度の情報から距離を判定してORDER BY処理を行うことができます。
上記のクエリで東京駅辺りの緯度経度を中心に近い順に取得した結果がこちら。
だいたい正しく取得できていそうでした。位置情報のORDER BY処理は「DISTANCE」関数と「GEOLOCATION」関数を利用すれば対応できます。
ちなみに緯度・経度の情報はGoogleMapのURLなどで確認できます。
個人的に思っているApex開発でのエラーハンドリング処理で避けたほうが良い実装方法を紹介します。
if (isError) {
System.debug('エラーが見つかったため処理を終了');
return;
}
try {
// ・・・何かの処理・・・
} catch(Exception e) {
System.debug('エラーが見つかったため処理を終了');
return;
}
上記のようにエラー発生時にSystem.debug処理だけ動かして処理を終了する方法はエラー自体に気づけ無い可能性が高いので避けたほうが良いのではと個人的には考えています。
【ユーザがシステム管理者に相談】
・管理者が原因の調査を開始できる。しかし画面上反応が無いため調査は難航。
【ユーザが管理者に相談せずに作業終了】
・エラー発生は誰に知られることなく闇の中へ。
・管理者が気づいた頃には異常系データが大量生産されている。
・通常、バッチ処理内でエラーが発生すると管理者宛に通知メールが届く。また、Apexジョブのページでもエラーメッセージを確認することができるので異常に気付くことができる。
・System.debugを呼び出して終了することで、バッチ処理は正常に終了したように見えてしまう。→データの更新結果をチェックしないとエラーに気付けない。
やめたほうが良いですと書くからには代わりの実装案を書かないと行けないと思うので紹介します。下記のように対応すると良いと思います。
※エラー発生時にユーザから報告がもらえない場面は普通に発生します。連絡が無くても管理者側で把握できるようにするのが大切です。
