意外と情報の少ないパートナーコミュニティですが、Trailheadにコミュニティの参加方法などの情報が記載されていました。
パートナーコミュニティのサイトはこちら。
↧
SFDC：パートナーコミュニティへの参加方法
↧
SFDC：アプリケーションセキュリティの学習
Trailheadにアプリケーションセキュリティについて学ぶことができるモジュールが用意されています。
セキュリティについて学ぶための専用の組織も用意されています。この組織をつかってTrailheadの課題を進めることでどのようなセキュリティリスクがあるのか把握して対策方法を学ぶことができるようになっていました。
学習用のDE組織にログインするとこのように必要なタブやアプリケーションが用意されていました。
専用の環境があるので安全にかつ簡単に学ぶことができて便利そうです。
↧
↧
SFDC：標準オブジェクトの使い方
セールスフォースには標準オブジェクトがたくさん用意されていますが、どんな情報を入力すればいいか確認するのも大変。。ということで動画でまとめてみました。
下記のオブジェクトについてざっくりとですがまとめてあります。
- 商品
- 価格表
- 取引先
- 取引先責任者
- 商談
- 契約
- 注文
- ケース
- ソリューション
- 納入商品
- リード
- キャンペーン
- 作業指示
より正確で詳細な情報を確認したい場合はセールスフォースのヘルプページで確認できます。
↧
SFDC：外部URLへのリダイレクトを防止する方法
Visualforceページの開発ではURLパラメータでリダイレクト先のURLを保持してリダイレクトを行うというケースがよくあると思います。もしそこで外部URLを入力されてしまったときにエラーにする方法についてです。
まずは外部URLへのリダイレクトを許可した状態のパターンです。これでsaveボタンの処理を実行するとリダイレクト先はGoogleになります。
続いてリダイレクトを防止する場合です。次のコードを挿入します。
if(finishURL.startsWith('/')){
finishURL.replaceFirst('/','');
}
savePage = new PageReference('/'+finishURL);replace処理を追加してPageReferenceのURLの先頭に'/'を付けます。
コードの全体です。
String finishURL = ApexPages.currentPage().getParameters().get('finishURL');
if(finishURL.startsWith('/')){
finishURL.replaceFirst('/','');
}
savePage = new PageReference('/'+finishURL);
savePage.setRedirect(true);
return savePage;
こうすることでリダイレクト先が相対パス指定になり外部サイトにはリダイレクトできなくなります。
ちなみに内部URLの場合は問題なくリダイレクトできます。
この話についての詳細はこちらです。
↧
SFDC：Live Agentを試してみました
Trailheadを見ながらService Cloudの便利機能、Live Agentを試してみました。
設定画面で有効化することで利用できるようになります。
有効化すると各設定が追加され、エンドポイントが割り当てられます。
Live Agentを利用するにはユーザに権限を付与する必要があります。
エージェントがどのような知識をもっているかのスキル情報を作成します。
名称を入力して対象ユーザまたはプロファイルを指定します。
これでスキルの設定は完了です。
続いてチャット構成の設定です。Live Agent Configurationsで設定します。
細かい設定がいろいろ用意されていますが、ひとまず設定不要です。名称と対象ユーザまたはプロファイルを指定して設定を保存します。
これでLive Agent Configurationsの設定ができました。
次はブランドイメージの設定です。マイドメインの有効化とForce.comサイトの有効化が必要になります。
Trailheadから画像をダウンロードして静的リソースにアップします。
Online, Offline, ChatWindowの３つです。
これができたらチャットボタンの作成を行います。
こんな感じ。
これでチャットボタンのコードが自動生成されます。
次はDeploymentsの設定です。
こんな感じになります。これでDeployment Codeも生成されます。
ここまで設定できたらコンソールにLive Agentを追加します。設定のアプリケーション作成でコンソールアプリケーションを作成します。こんな感じです。
Live Agentを有効化した場合は次の設定が追加されていました。
このような画面が表示されれば大丈夫です。
これで基本的な設定が完了しました。Visualforceページを用意してチャット機能を試してみます。
<apex:page> <h1>Let’s start chatting...</h1> <br /> Click the big button to start a chat. <br /> <!--Button Code--> <!--Deployment Code--> </apex:page>
Button CodeとDeveloyment Codeに先程の設定で生成されたコードを差し込みます。すると次のような表示のページができると思います。
画像をクリックするとウィンドウが開きます。
ウィンドウを開いた状態でコンソールアプリを開き右下のLive Agentウィンドウを開きます。ステータスをオンラインにすると対象チャットが表示されます。
Acceptボタンをクリックするとチャットを開始できます。設定によってはチャットの右側に取引先やケースの作成ページを表示できます。
送信したメッセージは相手側に表示されます。
このような感じでやりとりできます。
今回は両方とも内部ユーザとして操作しましたが、コンソール側を内部ユーザ、チャット起動をForce.comサイトなどの外部サイトに配置して利用することになると思います。基本的に複数タブでコンソールを開いてチャットを扱うといった利用の仕方はできないみたいです。接続が切断されました。
以上がLive Agentの基本的な設定の流れです。詳細はTrailheadにまとめられています。
↧
↧
SFDC：Live Agentのその他のオプションを試してみました
Live Agentのその他のオプションを試してみました。基本的な設定は下記に記載してあります。
Trailheadで紹介されている内容です。
Live Agentには下記の主要な機能が用意されています。
- 1.スキル
- 2.基本的なブランド
- 3.訪問者に記録を保存させる
- 4.スニークピーク
- 5.ファイル転送
- 6.アシスタントフラグ
- 7.チャット転送と会議
- 8.クイックテキスト
訪問者に記録を保存させる
設定→ DeploymentsにAllow Visitors to Save Transcriptsがあるのでチェックをつけると利用できます。
このように訪問者のチャット画面にSaveボタンが追加されます。クリックするとチャットの内容がtxtファイルでダウンロードできます。
スニークピーク
Live Agent Configurationsの設定です。Sneak Peek Enabledのチェックをつけると利用できます。
対象のナレッジ記事が登録されている場合、入力中に自動補完されるようになるみたいです。
ファイル転送
Live Agent Configurationsの設定です。Agent File Transfer Enabledのチェックをつけると利用できます。
エージェントは顧客からファイルを要求できます。とのことでしたがちょっと使い方はわかりませんでした。
アシスタントフラグ
支援フラグは、エージェントがチャットに援助を必要とするときに、スーパーバイザに仮想フラグを発生させる。彼らがバックアップを呼び出すための最速の方法です。
ここから利用できるみたいです。
チャット転送と会議
エージェントがチャットで一緒に作業する方法です。転送により、エージェントは他のエージェントに直接転送したり、別のスキルに移したり、別のチャット・ボタンに転送したりして、チャットを転送することができます。
たぶんここから設定。
クイックテキスト
クイックテキストでは、エージェントが同じメッセージを何度も繰り返し入力する必要がないように、パッケージ化された応答を作成できます。
タブからレコード登録する形で登録できます。
↧
SFDC：レモネードスタンドアプリ開発をやってみました
Trailheadのレモネードスタンドアプリ開発をやってみました。
はじめに
Developer Edition組織を作成してLightning Experienceを有効化します。
アプリケーションとカスタムオブジェクトを作成する
設定からアプリケーションとカスタムオブジェクトを作成します。Salesforce Clasiccの設定にあるAdd Appボタンで作成します。
- App: Lemonade Stand
- Label: Flavor
- Plural Label: Flavors
Lemonade Standアプリとカスタムオブジェクトを用意できました。
設定メニューからDrink Orderオブジェクトを追加します。
- Label: Drink Order
- Plural Label: Drink Orders
- Object Name: Drink_Order
- Record Name: Drink Order Name
- Data Type: Auto Number
- Display Format: ORDER-{0000}
- Starting Number: 1
- Under Optional Features, select Allow Reports
- Click Save & New to save this object and start creating another one
もうひとつFulfillment Queueオブジェクトを作成します。
- Label: Fulfillment Queue
- Plural Label: Fulfillment Queues
- Object Name: Fulfillment_Queue
- Record Name: Fulfillment Queue Name
- Data Type: Text
- Under Optional Features, select Allow Reports
Drink OrderとFulfillment Queueのカスタムタブを作成します。
Lemonade Standアプリケーションのタブに表示します。
またアプリケーションの編集でShow in Lightning Experienceにチェックをつけます。
ここからはLightning Experienceで進めます。アプリケーションでLemonade Standを選択します。
先程作成したタブが表示されることを確認します。
Flavorタブでレモネードの味を登録します。
- Flavor Name: Classic Lemonade
- Flavor Name: Strawberry Lemonade
- Flavor Name: Black Cherry
このように3つの味を登録しました。
カスタム項目の作成
Flavorオブジェクトに価格を登録するためのカスタム項目を追加します。
- DataType: Currency
- Field Label: Price
- Field Name: Price
- Length: 4
- Decimal Places: 0
Drink Orderオブジェクトにも必要な項目を追加します。
- DataType: Picklist
- Field Label: Status
- Field Name: Status
- Placed
- Completed
- Cancelled
- DataType: Number
- Field Label: Quantity
- Field Name: Quantity
- Length: 2
- Decimal Places: 0
その他参照関係と主従関係の項目を作成します。
Fulfillment Queueオブジェクトにもカスタム項目を作成します。作成するのは積み上げ集計項目です。
もうひとつ作ります。
２つの積み上げ集計項目を作成しました。
データの登録
カスタム項目を用意したのでデータの登録を行います。Flavorオブジェクトの価格に値を登録します。
Fulfillment Queueオブジェクトには下記２つのデータを登録します。
- Classic Lemonade Queue
- Black Cherry and Strawberry Lemonade Queue
こうなります。
数式で自動計算項目を作成
こんな感じ。
ステータス更新アクションを作成
こんな感じ。
ページレイアウトにアクション追加
こんな感じ。
Fulfillment Queueのページレイアウトをカスタマイズ
関連リストに必要な項目を追加します。
カスタムレポートタイプの作成
サンプルオーダーの作成
3件の顧客を登録します。
- First Name: Juan
- Last Name: Mendoza
- First Name: Ayana
- Last Name: Bello
- First Name: Emily
- Last Name: Washington
Ayana Belloにレモネードを販売します。まずは注文の受付です。
- Contact: Ayana Bello
- Quantity: 1
- Flavor: Classic Lemonade
- Fulfillment Queue: Classic Lemonade Queue
商品を渡した後、Order Completedアクションでステータスを更新します。
ステータスが更新されて、Ayana Belloにレモネードを販売できたことを記録に残せました。
販売記録はレポートで管理します。
・・・このあたりはもう普通につくるだけなのでTrailheadを確認するほうがわかりやすいです。。
これでレモネードスタンドアプリが形になりました。実際にはもっと便利になるようにいろいろカスタマイズしていくことになりますが、オブジェクトの作成からデータ登録、レポート&ダッシュボードの使い方を確認できたと思います。
↧
SFDC：Waveを使用した製品パイプラインダッシュボードの作成をやってみました
TrailheadのWaveを使用した製品パイプラインダッシュボードの作成をやってみました。
WaveにCSVファイルをアップロードする
サンプルデータのCSVファイルはTrailheadからダウンロードできます。
作成→データセットでアップロード画面を表示できます。
データソースを選択でCSVを選択。
先程のCSVファイルを指定してアップロードします。
ファイルサイズによっては少し時間がかかるかもしれません。
ホームでデータセットが作成されたことを確認できます。
このデータセットをつかってダッシュボードを作成します。データセットをクリックすると新規レンズの画面が表示されます。これをカスタマイズします。
グループをクリックしてStage項目を選択。右側に条件ボタンがありますが、左側の項目名をクリックすると一気に設定できます。
グルーピング後のグラフはこのようになります。
画面右上のデザイナにクリップのアイコンを選択します。
すると新規ダッシュボード画面が表示されます。
Stage_1のステップが用意されているのでそれをクリックします。
Stage_1をドラッグ&ドロップで中央に配置するとデータセットで用意したグラフをダッシュボードに設置できます。
タイトルをつけると確認しやすくなります。
保存アイコンで設定内容を保存できます。
続いて地図グラフを表示します。Stage_1をクリックするとステップのコピーができます。
同じようにドラッグ&ドロップで配置してマップグラフとして表示します。
マップグラフではタイトルの指定の他にマップ種別も設定できます。
最後にピラミットグラフを表示してみます。データセットでProductを基準に指定します。
基準を追加で合計→Pipeline Amount を指定します。
このように２つのグラフが表示されました。
歯車アイコンのオプションでソート順を変更できます。
デザイナにクリップでさきほどと同じようにダッシュボードに追加します。
チャートタイプでピラミットを指定します。
Left Axis and set the the title to Opportunities.というのは左軸のタイトルにOpportunitiesを指定するという意味でした。
最後表示サイズなどを調整して見やすいようにします。
Waveを使用した製品パイプラインダッシュボードの作成はこんな感じでした。
↧
SFDC：個人取引先の取引先責任者IDについて
個人取引先を有効化すると取引先オブジェクトで取引先責任者の項目を利用できるようになります。そのため個人取引先レコード１つで取引先と取引先責任者の情報を管理することができます。
個人取引先は取引先責任者のルックアップ項目からも選択できるようになっています。取引先ルックアップ、取引先責任者ルックアップの両方で選択できるので既存の作りを壊さずに利用することができました。
Apexで扱うときはひとつ注意が必要です。取引先責任者参照項目に個人取引先IDをセットしてINSERTやUPDATEを実行するとエラーとなります。個人取引先IDは取引先オブジェクトのIDとなるためです。
個人取引先オブジェクトは裏側で取引先責任者のIDも保持しています。設定画面では確認できませんでしたが検索してみたところ『PersonContactId』項目で保持されているみたいです。
クエリを実行してみたところ取引先責任者IDが保持されていることを確認できました。
Apexから取引先責任者のルックアップ項目に個人取引先IDをセットしたいときは『PersonContactId』の値をセットして登録処理を行えばいいみたいです。
せっかくなのでPersonContactIdが保持している取引先責任者IDをつかってContactオブジェクトにクエリを実行するとどうなるかも確認してみました。問題なく取得することができました。
参考
↧
↧
SFDC：Lightning Loginを試してみました
Winter'17の新機能『Lightning Login』を試してみました。Salesforce Authenticatorと組み合わせて利用する機能でセキュリティを確保したままログインを簡単にすることができる機能です。
この機能を利用するにはセキュリティのコントロールにあるセッションの設定で有効化する必要があります。
またプロファイルか権限セットでユーザの利用を許可する必要があります。
プロファイルで一括有効化するよりも権限セットで各ユーザに割り当てるほうが柔軟なカスタマイズができると思います。
権限追加後は、ユーザの詳細ページで認証キーを登録します。
登録リンクをクリックすると次の画面が表示されます。
モバイル端末のSalesforce Authenticatorで承認画面が表示されます。
承認をタップするとTouchIDの登録画面が表示されます。
これでLightning Loginの利用準備が整いました。登録後に利用停止したい場合はキャンセルリンクが表示されるのでそれをクリックすればいいみたいです。
Lightning Loginをつかってログインするにはログイン時にユーザを保存しておく必要があります。
すると次回ログイン時にこのように対象ユーザが表示されます。
ユーザを選択すると次のログイン承認画面が表示されます。
画面が表示されるとSalesforce Authenticatorアプリ側に通知が届きます。承認をタップしてTouchIDをつかってログインを承認できます。
以上がLightning Loginを利用する際の流れになります。2要素認証+TouchIDをつかった強固なセキュリティを用意することができました。ちなみにLightning Login有効化後でもユーザ名とパスワードでログインできるみたいです。
今まで2要素認証を導入しようとするとログイン時の操作が一手間追加されて少し不便でしたが、Lightning Loginを利用することで2要素認証導入しながらログイン手順をシンプルにできそうです。
↧
SFDC：MavensMate for Salesforce v0.0.11 (beta版)を試してみました
MavensMate for Salesforce v0.0.11(beta版)を試してみました。
まだβ版ですがv0.0.11でLightning Design Systemのスタイルが適用されています。
Zipファイルをダウンロードして解凍するとappファイルを取得できます。
これをアプリケーションフォルダに格納して利用します。
起動するとこんな感じです。
プロジェクトを開くときはAuth認証経由でSalesforceにログインできます。
認証ページ
プロジェクトを選択すると次の操作ができるようになります。
PROJECT
METADATA
LIGHTNING
DEPLOY
DEBUGGING & TESTING
EDITORS
SALESFORCE
SALESFORCEのメニューからSalesforce APIの使用数を確認できることがなかなか便利そうです。
参考
↧
SFDC：個人取引先へのデータ変更と所有者の扱い
個人取引先を有効化するときに既存データの変換対応が必要になります。
その際に取引先と取引先責任者の所有者が異なるとどのような扱いになるか確認してみました。
取引先
取引先責任者
変換処理はこんな感じです。
// 個人取引先のレコードタイプ取得 RecordType recordType = [SELECT Id FROM RecordType WHERE DeveloperName = 'PersonAccount' AND SObjectType = 'Account' LIMIT 1]; // 変換したい法人取引先データを取得 Account account = [SELECT Id FROM Account WHERE Id = '<YOUR ACCOUNT ID>' LIMIT 1]; // 個人取引先のレコードタイプをセット account.RecordTypeId = recordType.Id; // 更新 update account;
結果はこちら。
下記エラーが発生して変換できませんでした。
Line: 8, Column: 1
System.DmlException: Update failed. First exception on row 0 with id 001p000000KrybFAAR; first error: INVALID_PERSON_ACCOUNT_OPERATION, account cannot be converted to person-account: []
所有者を同じにして変換処理を実行したところ正常に変換することができました。既存の取引先と取引先責任者を個人取引先に変換する場合は事前に所有者を同じにしておく必要があるみたいです。
個人を管理している場合、取引先責任者はメンテナンスされていても取引先は情報が古いままになっている可能性もあるので注意しておいた方がよさそうです。
↧
SFDC：DreamhouseのFacebook Messenger Botとアプリの公開設定について
ちょっと教えて貰った内容なのですが、DreamhouseのFacebook Messenger Botを動かした時、自分以外のFacebookユーザがメッセージを送ってもBotが動いてくれませんでした。この問題が発生したときはFacebook Developersサイトのアプリ設定で非公開になっていないか確認すればいいみたいです。
デフォルトでは開発者モードで非公開に設定されています。これを公開にすると自分以外のFacebookユーザでもMessenger Botを動かしてみることができるようになるみたいです。
公開済みの場合はこのように表示されます。
必要かはわかりませんが、一部条件のアプリの場合は審査が必要になるみたいなので本格的にアプリ開発するときにはこのあたりのルールも把握する必要がありそうです。
Facebook Developersサイトはこちら。
Dreamhouseのサイトはこちらです。
追記
公開したくないときでも開発者やテスターとして追加して利用する設定が用意されているみたいです。
Facebook Messenger Botのデモ動画
関連記事
↧
↧
SFDC：LEXの別組織のユーザ切り替え機能
Lightning Experienceで別組織ユーザに簡単に切り替えることができる機能が利用できるようになっています。ログインセッションが保持されていればクリック1つで切り替えることができました。
この機能を利用するにはログインページでログイン情報を保存しておく必要があります。
ログイン情報が保存されているユーザは次回ログイン時に確認することができます。
確認はしていませんがマイドメインの有効化を行っている必要もあると思います。
↧
SFDC：テストクラスのアンチパターン『ダミークラス大作戦』について
テストクラスのアンチパターン『ダミークラス大作戦』についてです。Apex開発を行うときテストクラスを用意する必要があり、テストのカバー率が組織全体で75%以上になっていないと本番環境にリリースできないようになっています。
その昔テストクラス作るのはコストになるからということでダミークラス大作戦が考えられました。意味のないコードを数万行程度用意してそれをテストで通すことで強制的にカバー率をあげることができるテクニックです。
Developer組織で実際に試してみると確認できると思いますが、状況によっては通常のテストクラスを一切用意しなくてもカバー率を80%近くまで向上させることができると思います。
この方法ですがやってはいけないアンチパターンとなっていて推奨されないテクニックとなっています。
アンチパターンの理由としてダミークラスでテストカバー率を上げる方法はSalesforceに負荷を与えてしまいます。負荷を与えるというと利用者には関係無さそうとなるかもしれませんが、Salesforceではパフォーマンスチェックや組織が正常に利用できる状態かチェックする仕組みがきちんと用意されています。
そのため1つの組織で異常な負荷を発生させていると、異常な負荷が発生しているので確認してください。とチェックが入る...かもしれません。(実際にあるかはわかりませんが..)
負荷を与えるという裏側の理由以外にもダミークラスを用意するやり方で組織を作り込むことで大きなトラブルが発生することも想定されます。
ダミークラスをつかったカバー率向上ですが、無限に対応できるわけではありません。数千行のコードのカバー率を75%以上にするために2万行のダミー処理が必要だったとして、2万行のコードをカバーするため5万行用意しても75%を保持できなくなっていきます。
そのため下記のケースが発生すると思います。
「開発時間短縮のためテストクラスは一切用意しません。そのかわり目視のテストでバグがないかを担保します。」というようなプロジェクトが始まり、予定どおり目視の検証だけでバグのないシステムを完成させて納品できました。
数年後、その組織で新たなプロジェクトが立ち上がることになり、今度はその分野に強い別の会社に依頼して開発を進めることになりました。そのプロジェクトではApexクラス毎にテストクラスを用意して開発した部分についてはきちんとカバーするように進めていきました。ですが組織のコード量が増えたことでダミークラスの効果が薄まり本番環境にリリースできなくなります。
こうなると大変です。新しいプロジェクト側では正しくテストクラスを用意しているのでこれ以上をカバー率を向上させることはできません。組織全体のコード量が多くなったため、ダミークラスの処理を増やす方法でも効果がでません。では最初の会社に依頼して用意してもらうかとなっても数年経っていると対応が難しくなると思います。追加工数を用意してテストクラスをつくり始めても当時気づかれなかった小さなバグがたくさん見つかりApexクラス側の改修が必要になることもあると思います。
このようにダミークラスをつかったやり方は一時的にうまくいくように思えても将来的に大きなトラブルにつながります。また目視のテストには当然時間が必要です。開発フェーズ→テストフェーズときちんと時間がとれるプロジェクト中は問題ありませんが、保守期間にちょっとした機能追加を依頼したくなったときに、目視ですべての機能を再検証する時間を作るのは難しいため、結果として調査しないとその機能の実装をして既存機能に影響がないかわかりません。機能追加後に検証工数がかかりますとなってしまいます。そうなった組織は最終的に何もできなくなり数年後には使えない組織となると思います。セールスフォースは使いづらいね。別のプラットフォームで一から作り変えようという選択しか取れなくなってしまうと思います。
テストクラスを用意したらバグの無いシステムが完成するかというとそうはなりませんが、開発中にちょっとしたバグに気づくことはできますし、将来身動きの取れないシステムが完成するのは回避できると思います。
ということでテストクラス作成工数を省略するダミークラス大作戦を前提としたやり方はやめておくのがオススメです。
↧
SFDC：プロファイル設定で意識しておくこと
Salesforceではアクセス権限まわりの設定はプロファイル設定で管理できるようになっています。プロファイル設定にはたくさんのチェックボックスが用意されているのでよくわからないから全部にチェックをつけて置こうとなるケースがあるかもしれません。
このときデータの管理権限を一般ユーザに対して付与するのはやめておいた方がいいと思います。
データの管理権限はシステム管理者クラスの権限になっています。一般ユーザに付与してしまうとロールや公開グループなどでアクセス権限を制御しようとしたときに制御できなくなってしまいます。
また権限を広げるのは簡単ですが、権限を狭めようとするといままで出来ていたのにできなくなった..といろんなところに影響がでてしまうので検証時間が必要になってしまいます。なので最初は権限を与えないで本当に必要になったときに付与する形がオススメです。
ですが一般ユーザの権限を広げたいときでもデータの管理権限は基本付与する必要はありません。セールスフォースには共有設定や公開グループなど権限を付与させる設定がきちんと用意されています。一部のアクセス権限を付与したいときはデータの管理チェックを気軽に与えるのではなくこうした設定を利用するのがオススメです。
↧
SFDC：プロセスビルダーとレコードID指定について
プロセスビルダーのアンチパターンについてです。プロセスビルダーを利用すると項目自動更新やChatter投稿などの便利な機能をプログラミングなしで実現することができます。ワークフロールールなどでもそうでしたが値更新処理などでレコードIDの直接指定を行うのはオススメしません。
レコードIDは環境依存したデータとなるためSandbox環境と本番環境で値が変わってしまいます。そのためSandbox環境でカスタマイズした内容を本番環境にリリースすると動かなくなってしまいます。
Sandboxと本番環境で別々の設定で管理するのは現実的ではありませんし、プロセスビルダーで値を変更するときは一度別バージョンとして作成して有効化するという少し手間のかかる手順が発生します。数が少なければそれでもなんとかなるかもしれませんが、数が多くなると対応できなくなります。
このときに問題になるのがSandbox環境のリフレッシュをしたときです。本来本番環境と同じ設定内容で最新化できるSandboxのリフレッシュですが、上記対応を行っていると動かない機能がたくさんできてしまいます。このような理由でエラーが発生すると下記のようなメッセージが表示されます。
フローのトリガに失敗しました。というエラーメッセージでは原因が確認できないのでなぜエラーが発生したのか調査するのも大変です。
こうしたトラブルを避けるためにもプロセスビルダーでレコードIDなど環境依存する値を利用するのは避けるのがオススメです。
↧
↧
SFDC：主従関係と参照関係の違いについて
主従関係と参照関係の違いについてです。別のオブジェクトと関連付けを行うときは主従関係もしくは参照関係の項目を用意して対応します。
似たような項目なのでとりあえず主従関係にしとこうとか、なんとなく参照関係にしようといった選択を行うケースがあると思います。基本的に親レコードが存在しているときにのみ作成されるレコードの場合は主従関係という考え方で大丈夫だと思います。
主従関係と参照関係の違いですが、主従関係を選択する大きなメリットがあります。
- 積み上げ集計項目が作れる
- 所有者を主オブジェクト側で一元管理できる
- 主オブジェクト側のレコードを削除すると従レコードもまとめて削除できる
他にもあるかもしれませんが主従関係は上記3つの便利な特徴を備えています。積み上げ集計項目はよく使われる便利な機能で特定の条件で従レコードの件数や合計値などの情報を取得できます。これにより関連レコードが何件といった条件のデータをビューやレポートなどでまとめることも可能です。
所有者を主オブジェクト側で一元管理できることは地味な部分ですが便利な機能です。所有者の移行などが必要になったとき主オブジェクト側を修正して従オブジェクト側を修正して・・とひとつひとつやらなくては行けませんが、主従関係にすれば一箇所の所有者を変更すれば対応が完了します。主と従で所有者を変更しなくてはいけないときには参照関係にする必要がでてきます。
主オブジェクト側のレコードを削除すると従レコードもまとめて削除できる機能は本当に便利です。Salesforceに登録したデータは永久にそのままというわけではなく必要のなくなったデータは削除されると思います。このとき参照関係にしておくと親レコードが削除されても関連する子レコードはそのままになってしまいます。意味のあるデータならそれでも良いのですが大抵の場合役に立たないデータとして残ることになると思います。主従関係ならこの問題を簡単に解決できるのでオススメです。
一度作成した主従関係と参照関係の項目ですが、後からデータ型を変更することも可能です。ですがその場合は所有者項目やレポートタイプに変更が入るので、既存のビューやレポートに影響が出てしまいます。
後から変更することは可能ですが、出来る限り最初に検討してどちらを利用するのか選択した方が良さそうです。
関連記事
↧
SFDC：ビューステートエラーとRemoteActionの送信上限の考慮について
Apexではpublic変数を用意することでページとクラス側で値のやりとりを簡単にできる変数を用意できます。ですが無制限に用意できるのではなく上限をオーバーするとビューステートエラーが発生します。
ビューステートエラーで気をつけなくては行けないのはファイルデータの扱いです。apex:inputFileタグをつかってファイルデータを保持した状態でreRenderなどで値のやりとりを行うと一発で発生します。ファイル添付画面→確認画面→アップロード処理実行というような機能を実装するときはJavaScriptRemotingなどで対応する必要があります。
またビューステートエラーが発生するからapexタグはダメだ。できるかぎりJavaScriptRemotingで対応する。という感じでRemoteActionを利用することがあると思います。実はRemoteActionにもApex側に値を渡すときに上限があります。
このようにJavaScriptRemotingで実装するときもいろいろ考慮する必要があります。
ビューステートエラーとRemoteActionの制限エラーが発生したときの一番の問題ですが、設計レベルで見直しが必要になることです。「NULLチェックが抜けていた」「保存処理がうまく実行できていなかった」という問題の場合はApex処理を修正して本番環境にリリースすれば修正できます。ですがビューステートエラーとRemoteActionの制限エラーの場合はデータの持たせ方から変更する必要がでてきます。場合によっては一から作り直す。オブジェクト構成から考え直すという状況にまでなる可能性があります。
組織に数万件のデータが溜まってきて動かなくなったということはあるかもしれませんが、数千件程度で動かなくなる処理というのは何かがおかしいので、運用が始まる前の開発フェーズで必ずチェックしておいた方が良いと思います。
関連記事
↧
SFDC：ID検証方法がユーザに追加されたときの流れ
ID検証方法がユーザに追加されたときの流れについて確認してみました。2要素認証有効化時の話です。次のように権限セットを用意してユーザに割り当てます。
以前試した時には気にしていなかったのですが、割り当てたタイミングでは特にメール通知等はありませんでした。対象ユーザがログインしたときに2要素認証の設定画面が表示される仕組みとなっているみたいです。(初回ログイン時は除く)
別の検証方法を選択リンクをクリックすることで、アプリ認証か確認コード認証かを選択できるようになっていました。
通知メールは届きませんでしたが、ログイン時に必ず目につくようにメッセージが表示される形となりました。またモバイルアプリを利用できない人のために認証コードを選択できるようにもなっています。
ID検証の利用状況はSummer'16からビューやレポート&ダッシュボードで確認できるようになったみたいです。
↧