プログラマ38の日記

主にプログラムメモです。

Salesforce: オブジェクト情報取得マクロとメタデータエクスポート取得ツールをバージョンアップしました(APIVer42)

SalesforceがSpring18(APIVer42)にバージョンアップしたので、次のツールをバージョンあげました。

 

Excel VBA : オブジェクト一覧と項目一覧の取得マクロ

 

Java : メタデータエクスポートツール

 

使い方は前回の内容から変更はありません。 

crmprogrammer38.hatenablog.com

  

crmprogrammer38.hatenablog.com

 

バージョンアップは、エンドポイントを41.0から42.0へ変更して、メタデータのエクスポートツールはAPIVer42.0用のwsdlで作成したjarに置き換えています。

Excel VBASOAP EnvelopeのXMLから定義情報を取得しているので、XMLの構造が変わると作りを変えないといけないのですが、今回は、APIの仕様はあまり変更がありませんでした。

 

Salesforce: Lightning ページレイアウトの設定

Lightningでのページレイアウトは、今まで通りのページレイアウトの指定と、Lightningレコードページで指定します。

 

今まで通りのページレイアウトの指定では次のような画面表示となります。

[詳細タブ]

f:id:crmprogrammer38:20180213092751p:plain
[関連タブ]

f:id:crmprogrammer38:20180213093858p:plain

 

① コンパクトレイアウトで指定した項目の表示
② 「モバイルおよび Lightning Experience のアクション」で指定した詳細ボタンとアクション
③ ページレイアウトでクイックアクションで投稿を指定した場合の表示
④ ページレイアウトの詳細項目
⑤ ページレイアウトのカスタムリンク
⑥ ページレイアウトの関連リストとリストボタン

 

①ですが、レイアウトの設定後にコンパクトを変更しても反映されませんでした。(反映が遅いだけですかね)再度、ページレイアウトを保存すると反映されました。

 

②は、LightningではJavaScriptボタンが使えません。カスタムボタンが使えないと勘違いしてました。

 

③は投稿のクイックアクションを指定しないと、フィード追跡が表示されるだけになります。

 

④は今まで通りです。

 

⑤はカスタムリンクもJavaScriptのリンクは使えません。

 

⑥の関連リストボタンもJavaScriptボタンが使えません。

 

最後に

JavaScriptボタンとJavaScriptリンクが使えないという点がインパクトがあると思いました。(Googleで検索すると、いくつか回避策がヒットしました)

基本的には、Visualforceボタンにすれば今まで通りに近いアプリケーションが作れると思いました。

ですが、1つのトランザクションではガバナ制限を超えてしまうため、JavaScriptボタンからカスタムWebServiceを何度かコールするという作りをする場合、JavaScriptボタンではなく、Lightningコンポーネントを使うのかなと勝手に考えています。

もうちょっと理解を進める必要がありそうです。Lightningコンポーネントは今までのVisualforceとは大分違うので道のりは長そうです。

Salesforce: Lightning オブジェクトの設定

Lightningではオブジェクトマネージャで、標準オブジェクトでも、カスタムオブジェクトもまとめて一覧表示する仕組みが追加されています。

f:id:crmprogrammer38:20180206100236p:plain

f:id:crmprogrammer38:20180206100459p:plain

LightningでもClassicでも、オブジェクトの作成と項目の追加に変更はありませんでした。
が、Lightningレコードページは、オブジェクトマネージャからでないと設定できませんでした。

後、検索レイアウトの、「タブ」「ルックアップダイアログ」「ルックアップ電話ダイアログ」の設定はLightningで使用する箇所はなく、「検索結果」のみ使用していました。

 

最後に


Lightningの設定ページや、オブジェクトマネージャは慣れるまで時間がかかりそうです。各設定で、ページ内の検索機能があるのは便利だなーと思いました。


ただ、オブジェクトマネージャの一覧表示で、添付ファイル(Attachment)や、ファイル(ContentVersion)などの内部のオブジェクトは表示されておらず、内部のオブジェクトにトリガを作成する場合は開発者コンソールやForce.com IDEから作成するのは今まで通りのようです。

Salesforce: Lightning experience を勉強したいと思いました

SalesforceのLightning Experienceに対して、見た目がかっこいいとか、カスタムボタンが使えないとかそれぐらいのイメージしか持っていませんでした。

(後、基本的にいやなのが、動作が遅かったり、Lightningの設定画面だけでは全ての設定ができないという点です。これでLightningに変える気になれていませんでした)

 

ですが、今後はClassicの機能追加が終了して、Classicの開発知識は陳腐化していくんだろうなーと思います。

そこで、Lightningを勉強しようと思います。

 

次のようないつものSalesforce開発をLightningで行えるようになりたいと思っています。

  • オブジェクトを作成
  • レイアウトを作成
  • ビューを作成 
  • 標準画面に詳細カスタムボタンを追加
  • 標準画面の関連リストにリストボタンを追加
  • ビューにボタン追加
  • アプリケーションを作成

 

できればボタンの上書きとかVisualforce、Lightningコンポーネントも触って行きたいと思いますが目標は低めが好きなので、まず上記でやってみます。

trailbrazerやhelp & training 、色々なブログ情報などから情報を集めるところからスタートしようと思います。

 

Salesforce: プロファイルのリリースで気をつけたいこと

Salesforceで、モジュールのリリースはとても大変な作業です。

リリースの中で特にプロファイルのリリースは気を使います。

プロファイルをリリースする際の注意点をメモしておこうと思います。

 

変更セットでリリースする際は、プロファイル別にアクセス権が付与できるコンポーネントと一緒に変更セットを作成する

アプリケーション、オブジェクト、タグ、レコードタイプ、Apexクラス、Visualforceページ、項目レベルセキュリティといったプロファイルで制御できるコンポーネントとプロファイルを1つの変更セットにまとめることで、プロファイルのアクセス権とともにリリースできます。

 

ただし、変更セットでは標準オブジェクトとそのタブ、標準項目が選べません。ですので変更セットではリリースできず標準オブジェクトとそのタブ、標準項目は手動での設定となります。

 

サイトプロファイルのリリース

各環境でサイトの設定をした後サイトの公開アクセス設定からサイトのプロファイル画面に行き、プロファイルの名前を揃えます。

f:id:crmprogrammer38:20180130105005p:plain

プロファイルの名前を揃えておけば、プロファイル設定をリリースできるようになります。

 

変更セットのプロファイルリリース時に、ログイン IP アドレスの制限もリリースされる

SandBoxと本番でIPアドレスの制限を変えて運用していることは多いと思いますが、変更セットでリリースするとIPアドレスの制限も一緒にリリースしてしまいます。

本番環境だけセキュリティを厳しくしている場合はこれは本当に困ります。

プロファイルはリリースせずに手動でプロファイル設定を行うことで対応できますが、リリースするコンポーネントでプロファイル制御する数(カスタム項目など)が多い場合、手動だと厳しい場合があります。

そういう時はプロファイルをデプロイ(IDEや、移行ツール)するのも1つの手かなと思います。手動で設定して間違えるくらいならプロファイルのメタデータxmlで不要な箇所を除いて(ログインIPアドレスの制限箇所をコメントアウトにする)デプロイの方が正確にリリースできます。

 

最後に

権限セットでアクセス権を付与することにすれば、項目権限(FieldPermissions)、オブジェクト権限(ObjectPermissions)はデータローダで設定できるようになります。

あまりに項目権限の設定が煩雑な場合は権限セットを使ってしまう手もあります。でも、プロファイルで正しく定義しておく方がオススメです。

Salesforce: 本番運用後に発覚しがちな制限

SandBoxで開発している時は気づかないけど、本番運用後にエラーになってはじめて気付く制限があります。

SandBoxではデータのサイズ制限があるので、開発時には気付くことはできないという

事情はあります。

でも、事情は関係なしにエラーがでれば不具合扱いなので避けたいところです。

以下に今後気をつけたい制限のメモを3つ程メモしておこうと思います。

 

ApexClassで、100,000件以上のオブジェクトをインデックス指定無しで検索する

ほぼ開発時には気付きません。データが溜まって初めて気付く制限の典型です。

日付や電話番号は外部IDでインデックス作成ができないのですが、顧客の特定で生年月日や電話番号で検索しがちなので気をつけたいところです。

※日付や電話番号の項目のインデックスは、カスタムインデックスの作成をSalesforce社へ依頼することになります

 

Visualforceで、<apex:repeat>の繰り返しの上限が1000

SOQLの取得件数は1000以上ですが、Visualforceの画面表示の上限が1000までです。StandardSetControllerや、カスタムでページング処理を使って対処します。

 

Visualforceのビューステートの制限

このエラーが出た場合、対処は困難を極めます(そもそもある程度大きい件数で多くの項目を入力したいという要件でこのエラーがでます)

表示項目にはtransientを指定したり、入力項目を減らしたり、入力項目の桁数を減らしたり涙ぐましい努力が必要になります。

最初からJavaScriptベースでVisualforceの開発をすることで回避できる可能性がありますが、そこまで戻れないのが実状だと思います。

 

最後に

バージョンアップで制限も変更となっていくのですが、今時点(Winter18)では以上が気をつけたいなーと感じていることです。

もちろんToo Many SOQLの対処などもありますが、これは発生頻度が高く開発時で気をつけるのが習慣となりつつあります。

昔は、SOQLで、子リレーションの副問合せで取得した子オブジェクトのレコード数の200件まで 制限があった気がしますが、今はなくなってるようです。(気のせいかもしれません)

 

あと、ガバナ制限ではないですが、ファイルが格納されている、コンテンツバージョン(ContentVersion)オブジェクトは、システム管理者でも全てのレコードを取得できないようになっています。後からAPIで取得したくでもできなくなります。(画面からはすべて参照できます)

なので、コンテンツドキュメントリンク(ContentDocumentLink)にトリガでデータを作成しておくようにしておくと良いと思います。

例えば、トリガで特定のchatterグループに全てのファイルをひもづけておけば、そのchatterグループに管理者をメンバーとすることで管理者は全てのファイルをコンテンツバージョン(ContentVersion)オブジェクトから取得できます。

後で、ContentVersionをAPIで操作する要件が見えているなら、トリガをあらかじめ用意しておくのがいいかなーと思います。

 

Salesforce: メールの文字コードについて

Salesforceからメールを送信する時の文字コードではまったのでメモです。

(はまったのはユーザ情報でメールの文字コードを「Shift_JIS」にしていたのに、送信されたメールで丸数字"①"などが化けていたという事象です。原因はメールテンプレートの文字コードが「JIS」でした。。)

 

Salesforceでは次の2箇所でメールの文字コードを指定することができます。

・メールテンプレートでの指定

f:id:crmprogrammer38:20180125094735p:plain

・ユーザ情報での指定

f:id:crmprogrammer38:20180125095023p:plain

 

上記で指定した文字コードがどのメール送信時に使用されるかは次のようになります。

メールを送る方法 使用される文字コード
ワークフローでのメールアラート メールアラートで指定したメールテンプレートの文字コード
活動履歴関連リストのメール送信 テンプレートを選択した場合:
選択したメールテンプレートの文字コード
テンプレートを選択しない場合:
ユーザ情報のメールの文字コード
ケースの関連リストのメール(メールメッセージ) テンプレートを選択した場合:
選択したメールテンプレートの文字コード
テンプレートを選択しない場合:
ユーザ情報のメールの文字コード
Apex Class
Messaging.sendEmailでMessaging.SingleEmailMessageを送信する
setCharsetで文字コード指定した場合:
指定した文字コード
setCharsetで文字コードを指定しない場合:
ユーザ情報のメールの文字コード
SOAP API
sendEmailでSingleEmailMessageを送信する
setCharsetで文字コード指定した場合:
指定した文字コード
setCharsetで文字コードを指定しない場合:
ユーザ情報のメールの文字コード

※Apex ClassとSOAP APIのsendEmailで、MassEmailMessageを送信した時の文字コードは未調査です。。

 

最後に

基本的に、メールテンプレートを使う場合はメールテンプレートの文字コードが優先されます。

日本語環境でSalesforceの設定を行うと、ユーザ情報やメールテンプレートの文字コードはデフォルトで「日本語(JIS)」が選択されています。

そのまま保存してしまうと、JISのためメール送信時に丸数字などが文字化けとなってしまいます。

特に、メールテンプレートを利用者が作成する運用を取る場合に気をつけないといけないなーと思いました。

 

でも、未だにメールのデフォルトがJISって1990年代の話のような気がして感慨深いものがあります。今ならUTF-8でもいいのではないかなーと思いました。