tyoshikawa1106のブログ

- Force.com Developer Blog -

SFDC:Salesforce導入の流れ - Part 5

Salesforce導入の流れのPart5です。前回はLightningページの設定を行い、画面の見た目を整えました。今回はURLの見た目を整えます。

マイドメインの設定 [私のドメインの設定]

Salesforceにはマイドメインの設定という機能が用意されています。この機能を有効化することで自社のドメインであることを示せるようになります。

f:id:tyoshikawa1106:20200930081216p:plain


デフォルトのドメインは「login.salesforce.com」となりますが「 <マイドメイン>.my.salesforce.com」という形に設定可能です。この機能により汎用的なログインページの利用を終了して専用のログインページを用意するといったことが可能になります。

f:id:tyoshikawa1106:20200930081534p:plain


またログインページ右側の領域はifreamとなっていて、マイドメイン有効化後は任意のWebページを差し替えることができます。
f:id:tyoshikawa1106:20200930081730p:plain


例えば下記のような感じです。
f:id:tyoshikawa1106:20200930082052p:plain


注意点として下記の2つがあります。

  • ポータルサイトなどログインが必要な画面は差し込み不可 (JSエラーになります。)
  • スクロール不可


基本的には見た目を整えるように表示する用途となります。差し込んだWebサイト本来の機能は使えないと思っていいと思います。

マイドメイン有効化の注意点

マイドメインとして指定したドメインは基本的には変更不可となります。会社名が変更になったなどどうしても変更が必要になった場合はサポートに問い合わせして修正という流れになると思います。(Salesforceで困ったことがあればサポートに相談しましょう。)

マイドメイン有効化作業時にちょっと注意すること

マイドメインを有効化した後ですが、Lightning Experienceの場合、短時間ですがログインがうまくできなくなったことがありました。おそらく前回のログイン情報のキャッシュなどの情報が干渉したりしているのではないかなと思います。(ブラウザのキャッシュをクリアしたら解決しました。)


マイドメイン有効化の作業はユーザがすぐにログインする必要が無い時間帯に行うと予期せぬトラブルに遭遇することはないと思います。ただし、こうした現象に遭遇したというレベルの話なので、マイドメインの有効化作業自体は特別危険が伴う作業ではありません。


Part 5の話は以上となります。

SFDC:Salesforce導入の流れ - Part 4

Salesforce導入の流れのPart4です。前回はアプリケーション周りを準備してユーザにとって必要なタブが表示されるところまでやりました。今回も見栄えに関する設定を行います。

Lightningページの設定

オブジェクトに項目を追加したりページレイアウトを設定する前にLihtningページの設定を行い見栄えを整えます。初期の設定では下記のようになっています。

デフォルト設定のレコードページ

f:id:tyoshikawa1106:20200924083125p:plain


デフォルトでは関連リストがメインで表示されていますが、ユーザが一番確認したいのはレコードの詳細情報ですので、下記のように設定を変更するのが良いと思います。

カスタマイズ後のレコードページ

f:id:tyoshikawa1106:20200924084142p:plain


画面左側に詳細情報、画面右側に活動と関連リストそしてChatterフィードを表示します。詳細情報を参照しながら活動やChatterのやりとりを行えるように方向付けしておきます。


尚、関連リストに関しては関連リストのクイックビューを画面上部に配置してそちらからアクセスするを基本とするのが良いと思います。下記のようにマウスを当てるとポップアップでデータ一覧が表示されます。より詳細に確認したい場合はすべて表示のリンクからアクセスできます。

f:id:tyoshikawa1106:20200924084529p:plain


商談など他のオブジェクトも同様のレイアウト設定を行います。パスの表示やオブジェクトによってはベースから離れすぎないようにコンポーネントを追加すると良いと思います。

f:id:tyoshikawa1106:20200924085001p:plain


オブジェクトによっては活動や関連リストの情報がなく、詳細情報のみのレコードがあると思います。そうした場合は無理に2列のレイアウトにこだわらず見やすい形に表示します。例えば商談商品オブジェクトの場合などです。
f:id:tyoshikawa1106:20200925084806p:plain


オブジェクトごとに詳細情報の位置が大きく変わったりするとユーザが使い慣れるまでに負担が大きいので、可能な範囲で共通の配置になるようにすると良いと思います。ただし、リードやケースなどで業務的な使いやすさを優先すべきときにはそちらを優先しましょう。

ホームのレイアウトについて

ホームのレイアウトの忘れずに設定しましょう。個人的なオススメは下記のような配置です。
f:id:tyoshikawa1106:20200925085012p:plain


画面左側にChatterフィード、右側に行動、ToDo、未承認申請一覧を配置します。この形をベースに必要なコンポーネントを配置していくのが一番綺麗だと思います。特にChatterフィードについてはログイン時点で表示されるようにします。基本的にはChatterタブからやりとりを確認していきますが、ユーザがChatterタブに優先してアクセスすることはあまり多くないと思います。ログイン時点で気軽に直近のやりとりを確認できるようにすると使われやすくなる印象です。
※ホームのタブ切り替えも必要にならない限りは積極的に使われないと思います。(..自分で使っててもそうでした。)

モバイルアクセスの考慮について

Lightningページの設定ですが、PC環境だけでなくモバイル環境からのアクセスも考慮しましょう。2つの環境をそれぞれ用意しておくおことで必要になったタイミングにスムーズに検討を進められます。(検討開始時に未整頓のレイアウトだと使いづらい印象を植え付けてしまいます。)


あくまで現時点では...ですが、個人的にはメインの詳細情報はデフォルトで表示されつつ、関連リストやChatterフィードはタブコンポーネントの中にセットしておくのがキレイじゃないかなと思っています。

f:id:tyoshikawa1106:20200925184741p:plain


モバイルレイアウトも考慮することでコンパクトレイアウトやページレイアウトの並び順について自然と意識できるようになります。

まとめ

今回のPart 4ではLightningページの設定について紹介しました。「プロファイル」「アプリケーション」「Lightningページ」の設定を行い、見た目を整える部分から手を付けました。業務に合ったシステムにするための設計を始める前に画面をキレイにすることでSalesforceの利用イメージが持ちやすくなり、どのように設定していくかの話し合いがスムーズになると思います。

SFDC:Salesforce導入の流れ - Part 3

Salesforce導入の流れのPart 3です。前回のPart2ではプロファイルの暫定版を作成して管理者アカウントと一般ユーザで動作検証をできる用意をしました。その続きの話となります。

アプリケーションを用意する

Salesforceのアプリケーションはタブをグルーピングしたものと考えて頂くとイメージがしやすいと思います。業務に合わせて複数のタグをひとまとめにしたり、不要なタブはアプリケーションから除外することでユーザが操作で迷うのを防止します。

f:id:tyoshikawa1106:20200920155218p:plain


デフォルトでは標準アプリケーションが用意されていますが、そちらは基本的には利用不要です。業務に合わせて設定していくアプリケーションを一つ作成しましょう。最終的に部署ごとなど業務に合わせてアプリケーションを複数作成していくことになると思いますが、現時点ではベースとなる一つのアプリケーションがあれば問題ありません。(細かく設定していくのはシステムが形になってからの対応となります。)

f:id:tyoshikawa1106:20200920155612p:plain

タブの表示と並び順について

もし表示に悩む場合は下記の内容がオススメです。(Sales Cloud版)

  1. ホーム
  2. Chatter
  3. ToDo
  4. カレンダー
  5. グループ
  6. 売上予測
  7. リード
  8. 取引先
  9. 商談
  10. レポート
  11. ダッシュボード
  12. メモ
  13. ファイル
  14. ケース
  15. キャンペーン
  16. 価格表
  17. 商品
  18. 契約
  19. 承認申請

f:id:tyoshikawa1106:20200922173802p:plain


前の方の位置に配置した「Chatter」「ToDo」「カレンダー」「グループ」「売上予測」ですが、ユーザがよく使用する機能もしくは見てもらいたい機能という理由がありますが、それ以外にもモバイルアプリからアクセスした際に先頭のタブがトップに表示されるという理由があります。


下記のような感じです。
f:id:tyoshikawa1106:20200922174743p:plain:w200


もし運用上、モバイルアプリの利用をしない場合でも、設計時にモバイルだとどのように表示されるかはチェックするようにしておくといろいろと設計や設定のアイデアがでやすくなると思います。また運用後にモバイル利用が必要となった際に慌てる必要がなくなります。


それ以外のタブの件ですが、「取引先責任者」については取引先レコードの関連リストからアクセスすることを前提としています。可能な範囲で表示するタブは少なくできた方がユーザが使い方を覚える際の負担を減らせると思います。


尚、アプリケーションの一部タブについては、管理者のみのアクセスを目的としたものがあります。一般ユーザがアクセスする必要のないタブについてはプロファイル設定から「タブを隠す」などで非表示にしてしまうのが良いと思います。

f:id:tyoshikawa1106:20200922175701p:plain

不要なアプリケーションの非表示設定

ベースとなるアプリケーションを用意できたら続いて不要なアプリケーションを非表示にします。プロファイルの設定から変更できます。

f:id:tyoshikawa1106:20200922182150p:plain


この対応をしておくことでユーザが関係無いアプリケーションに切り替えてしまったり、不要な操作をせずに済むなどのメリットがあります。
f:id:tyoshikawa1106:20200922183254p:plain


先程のタブの表示設定と合わせて関係のないものを非表示化することでユーザが操作を覚える負担を減らし、アクセス不可となることで思わぬ操作が起きるのを防止できます。その他にも動作検証の負担を削減し、画面がスッキリすることで設計の検討がスムーズになります。


このようにアプリケーション設定については最初の内に実施しておくとメリットが大きい作業となります。

SFDC:Salesforce導入の流れ - Part 2

Salesforce導入の流れのPart 2です。今回はSalesforce導入決定後の初期設定について紹介します。Part 1で書いたとおり、導入後の業務に合わせたカスタマイズについては技術的な知見のある開発会社の方に依頼するのが良いと思います。依頼後は開発会社の方が運用開始に向けて何をどのスケジュールで進めていくか提案してくれるのでおまかせしてしまうのが良いと思いますが、セールスフォースには設定があるか知りたい方向けに自分の考える初期設定について紹介していきます。(多少知っておくと要件定義や機能追加依頼の際の参考になるかもしれません。)

プロファイルを用意する(暫定バージョン)

プロファイルとは権限周りの設定を管理する仕組みです。ユーザに対して機能の利用を許可したり、禁止したりする権限を設定します。

f:id:tyoshikawa1106:20200920154850p:plain


プロファイルの設定をきちんと行うのはある程度システムが出来上がってきたタイミングでやれば問題ありませんが、作業開始時点で下記の2つを用意しておきます。

  • システム管理者プロファイル
  • 一般ユーザプロファイル ※名称は仮です


開発者/管理者が利用するシステム管理者プロファイルは標準プロファイルをそのまま利用します。支障があれば権限セットによる権限拡張やカスタムプロファイルの作成など対処しますが特別な理由がなければ標準プロファイルをそのまま運用で利用して問題ないと思います。


重要なのは通常の従業員ユーザが利用する一般ユーザプロファイルの方です。こちらは標準プロファイルではなくカスタムプロファイルを用意しましょう。標準プロファイルはあくまで設定のベースとなるもので、ユーザに割り当てて使用するのはカスタムプロファイルとなります。


最終的に部署ごとに細かく権限を設定していくことになり、それぞれプロファイルを用意することになりますが、プロファイルが増えれば増えるほど設定作業に時間がかかってしまいます。導入時の作業を効率良く行うために一旦は汎用的に使える一般ユーザのプロファイルを用意してそちらで一般ユーザがどのようにセールスフォースを利用できるかを確認するのが良いと思います。(わかりやすいところですべての編集権限や開発の権限は除外したプロファイルとなります。)

※一般ユーザプロファイル作成のタイミングはユーザが使用感の確認などでログインするタイミングで用意できていればいいので、もう少し後でも問題ありません。(ユーザの使用感確認時にログインする際にシステム管理者プロファイルで行うのは避けたほうが良いです。)

プロファイルの設計について

一般ユーザプロファイルですが下記の権限は付与しないように考慮するのがオススメです。

  • すべての編集権限
  • すべての削除権限
  • 取引先や商談重要なオブジェクトの削除権限


すべての編集権限とすべての削除権限はシステム管理者向けの権限なので付与すべきではありません。これを付与する前提としてしまうと見せたくないデータを非表示にできなくなるなど権限設定がまともにできない組織となってしまいます。


今回大事なのは「オブジェクトの削除権限」の方です。これは可能であれば一般ユーザには付与しない方が良いと思っています。カスタムオブジェクトなどデータの内容によってはもちろん削除権限を付与する設計もしますが、取引先やリード、商談などは基本削除できないようにするのが望ましい気がしています。


これはユーザの「見込みなしリードだったので削除しました。」や「途中で中止となった商談のため削除しました。」といった作業を防止するためです。


リードが見込みなしの場合はその記録を残すことで、他の人が再度連絡せずに済むようになりますし、途中で中止となった商談の情報も中止理由によっては再度コンタクトするきっかけとなるなど基本的には業務の記録は正しく残しておくことでメリットがあります。(上記設定の場合は、誤登録など本当に削除が必要なデータの場合は管理者に依頼して削除の流れになります。)

一般ユーザプロファイルには不要な権限の無効化

基本的には「設定・定義を参照する」の権限は除外しましょう。これを除外することで歯車アイコンが非表示になり、通常ユーザには不要な管理者向け設定メニューがアクセス不可となります。

f:id:tyoshikawa1106:20200922155700p:plain


「設定・定義を参照する」の権限がなかればこのように歯車アイコンが非表示になります。ユーザとしても不要な機能のことを意識せずに済むので利用が楽になると思います。
f:id:tyoshikawa1106:20200922155934p:plain:w300


合わせて関係のない権限は無効にできるように準備するといいと思います。権限は付与しているものを除外する場合は影響範囲の検証が少し大変ですが、追加する分にはできることが増えるだけなので多少は簡単だと思います。まずは最小限の権限を付与して必要な機能が出てきたタイミングで追加を検討する流れが良いと思います。

IPアドレスの考慮

導入のための初期設定フェーズ時点ではまだ設定は不要と思いますが、もしアクセスできるIPアドレスを制限したい場合はプロファイルの設定で追加できます。
f:id:tyoshikawa1106:20200922161023p:plain


IPアドレスは開始から終了までの範囲を指定する形となっていますので、自社IPアドレスの範囲を確認して設定作業者に依頼できるように準備しておくと良いと思います。
f:id:tyoshikawa1106:20200922161247p:plain


尚、IPアドレスを制御する運用となる場合はシステム管理者はカスタムプロファイル版を一つ作成してそちらにIPアドレス制限を追加して管理者ユーザに割り当てるのが良いと思います。標準プロファイルについてはIPアドレス制限を一切つけずに最低一人の管理者ユーザに割り当てるようにしておきます。理由としては何らかの理由で社内ネットワークのIPアドレスが変更されたり、開始と終了の範囲が正しく設定者に伝わっていない、もしくは設定漏れがあったなどの状況が発生すると、その組織に誰もログインできなくなるためです。これを防止するために最低一つのユーザはIPアドレスに関わらずログインできるようにしておくと良いと思います。


誤って全ユーザがIPアドレス制限で弾かれてログイン不可となった場合はサポートに連絡してなんとかしてもらうことになると思いますが、管理者ユーザもログインできないと解除するための手続きに時間がかかる可能性があります。(なりすまし対策などなど当然の対応ですけど)

まとめ

プロファイルの本格的な検討は設定がある程度完了してきたタイミングに実施するのが望ましいのですが、管理者プロファイルと一般ユーザプロファイルの二種類は用意して検証で利用できるようにしておくと良いと思います。

SFDC:Salesforce導入の流れ - Part 1

自分の考えるSalesforce導入の流れについて紹介します。今回のPart1では導入検討時についての話となります。

f:id:tyoshikawa1106:20200916074142p:plain

Salesforceとは? | セールスフォース・ドットコム

導入検討時に最初に考慮しておくこと

Salesforceを導入しようと考える理由はいろいろあると思います。Salesforceで何をしたいのか熟考すべきという話を聞いたりもしますが、基本的には下記に関するしっかりとした仕組みを社内に構築したいという前提があればSalesforceを導入するメリットがあると思います。

  • 顧客情報を管理する仕組みが必要である。
  • 営業案件の情報を管理する仕組みが必要である。


※Salesforceを正しく活用するにはしっかりした設計とカスタマイズが必要になります。業務に役立つシステムの導入と意識して予算やリソースなどしっかりと準備することが大切だと思います。

導入製品について意識する

Salesforceは各分野に合わせた機能ごとに製品が用意されています。会社にとって必要な製品の名称について事前にチェックしておくと、セールスフォース社の営業の方との導入時のやりとりがスムーズに進めやすくなると思います。

Salesforceの製品について
  • Sales Cloud : 顧客管理と営業案件管理の仕組み構築のための製品★
  • Service Cloud : 製品やサービスの問い合わせ管理の仕組み構築のための製品
  • Community Cloud : 顧客やパートナーに提供できるシステムを構築する製品
  • Marketing Cloud : マーケティング管理の仕組みを構築するための製品
  • Analytics Cloud : データ分析に特化した機能を使うための製品


まずは「Sales Cloud」を導入して顧客管理と営業案件管理の仕組みの構築から開始することでSalesforce導入による効果を得られやすいと思います。各製品ごとにシームレスなデータ連携が可能となっているため、Sales Cloudで構築した仕組みをベースに他の製品を追加していくことで業務に合わせたシステムづくりを進めていけるようになっています。

セールスフォース社に問い合わせ

セールスフォースのWebサイトに問い合わせフォームがあります。そちらから製品導入について相談したいことを連絡すると担当の方から今後の流れなどについての返信があると思います。(この部分の対応はしたことがないので推測です)

f:id:tyoshikawa1106:20200916082450p:plain


f:id:tyoshikawa1106:20200916082623p:plain

無料トライアルについて

Webサイトから無料トライアルを申し込んで実際にSalesforceを試しに動かしてみることも可能です。もし社内のシステム部門などで動作の確認をしたい場合などはこのトライアル環境でさわってみると良いと思います。


ただし、有識者がいない状態でさわってもせっかくのトライアル期間の日数を消費するだけになってしまう可能性が高いと思いますので、ひとまずはセールスフォース社に製品導入検討についての問い合わせを行い、製品についての説明を受けるところから始めると良いのではと個人的には思います。

セールスフォース社の方とのミーティング

問い合わせ後に細かいやりとりは発生すると思いますが、最終的にセールスフォース社の担当営業の方に製品紹介と導入に向けた相談をする場を設けてもらう形になると思います。


過去に製品導入の検討などでミーティングに参加したことがありますが、担当営業の方はしっかりとサポートしてくれるので不明点や実現したいことを含めていろいろと相談できると思います。(セールスフォース社の方からの説明を聞くだけの受け身の体制だとせっかくの場がもったいないので導入に向けて積極的に話をすると有意義な場になると思います)


基本的に導入検討時に確認が必要な不明点は営業の方とのやりとりで解決できると思います。実際のデモを見た後に必要であればトライアル環境をさわってみたりするのもいいと思います。システム化に向けて実現できないと困ることがあれば相談しておきましょう。

導入が決まったら

Salesforceの製品自体に関する不明点についてはセールスフォース社の営業の方やサポートチームに相談に乗ってもらえますが、社内の業務に合わせた要件定義やカスタマイズ対応は自分たちで対応する必要があります。


知見の無い人が手探りで対応してもある程度は形になると思いますが、拡張性を落とさずしっかりしたシステム構築のためには下記のようなカスタマイズできる人を確保するのが望ましいです。

  • ① Salesforceの開発とカスタマイズのノウハウがある社内エンジニア
  • ② Salesforce導入支援のノウハウがある開発会社


①のSalesforce開発のノウハウがある社内エンジニアを確保できれば要件定義やフィードバックを受けての改修作業などのやりとりが多少スムーズになると思います。ただ導入のタイミングでSalesforce開発をやっている社内エンジニアを確保するのはちょっとむずかしいと思いますので、基本は②の開発会社に依頼するのが良いと思います。


10年以上様々な企業のSalesforce導入支援に携わってきた企業も多数ありますのでそうした企業に依頼すればノウハウを活かして適切に導入時のカスタマイズを進められると思います。(極少数ですがやっつけ対応されてしまう場合もあるので、きちんと支援してもらえるかはよく相談した方が良いと思います。)

ライセンスの購入について

Salesforceの利用にはライセンスが必要になります。1人のユーザ(従業員)に対して1ライセンスを割り当てて使っていく形となっています。


1ライセンスを複数ユーザで使う方法はSalesforce社の規約に違反するなどの理由でNGとなっていますが、規約がなかったとしても1ライセンスを複数の従業員で使用することはデメリットが多く発生します。


Salesforceを活用していく上で重要なのは業務に関するデータが格納されていくだけではなく誰が/いつ/何をやったかが記録されていくことにあります。仕事が順調な人がいれば進め方を参考にしたり、問題に悩んでいる人が記録を確認して課題の解決に協力したりと、そういった情報共有が気軽に実施できるようになるのがSalesforceのメリットだと思います。


作業者が不明な形で運用するとこうした情報共有が発生せず逆にトラブル発生時の犯人探しのようなことが起きてしまい健全な業務の妨げになってしまいます。(Salesforceに関わらず、すべての業務システム/ツールで言えることだと思います。)


Salesforceライセンスの購入時にはもう一つ考慮が必要です。利用する従業員用のライセンスとは別に最低1つ、システムアカウントのためのライセンスを用意しましょう。このアカウントの用途はバッチ処理やシステム連携処理などの個人に依存しないシステムが自動実行する際のユーザとして利用します。


システム管理者の役割を持つ従業員も当然1ライセンス1ユーザの割当で運用します。日常業務はそのユーザで実施するのが望ましいのですが、定期的に自動実行で動かすデータの一括更新処理のをそうした個人のユーザアカウントで実行してしまうと、トラブル発生時にその人が更新作業を実施したのか、夜間バッチでシステムが一括実行したかの切り分けができなくなってしまいます。その他にも個人の管理者ユーザに割り当てているとその方のユーザが無効になったりした際にバッチ実行処理がエラーとなって止まってしまう懸念が発生します。


上記のとおり、ライセンスは1ユーザ1ライセンスの割り当てで運用し、従業員用とは別にシステム用のライセンスも追加で用意してバッチ実行ユーザに割り当てて運用するのがオススメです。

開発会社の方へのライセンス付与

導入支援を行ってくれる開発会社の方へも管理者権限を持つライセンスを用意するのが望ましいです。基本的には1社につき最低1ライセンス付与しておく体制にしておくのが良いと思います。Salesforceではデータの登録作業以外だけではなく設定変更の記録も残るようになっているので、作業者にもきちんとライセンスを用意して機能追加の記録を正しく残せるようにしておくと健全なシステム開発が進められると思います。

まとめ

Salesforce導入の流れのPart 1は以上となります。Salesforceの導入についてはセールスフォース社に問い合わせすることで検討時に確認が必要な不明点はだいたい解決できると思います。導入後の業務に合わせたカスタマイズ作業や技術的な課題は開発会社に依頼して進めていくのが良いと思います。

SFDC:Apex開発とPardot API - Part 2

Apex開発とPardot API - Part 2です。Part1ではVisualforceとApexでシンプルなAPI処理の書き方について記載しました。今回はApexバッチによる大量データ処理の場合について紹介します。前回の内容はこちら。

Apexバッチの処理内でAPIを実行する場合は『Database.AllowsCallouts』の宣言が必要になります。

f:id:tyoshikawa1106:20200915084041p:plain


あとは通常のバッチ処理の開発と同じ流れで実装を進められます。

  1. コンストラクタ: 最初に実行される処理。
  2. startメソッド : コンストラクタの次の処理。対象レコード取得クエリを実行。
  3. executeメソッド : メインの処理。レコード件数分繰り返し実行される。
  4. finishメソッド : 一番最後に実行される処理。


ですが、何も考えずに実装すると不要なAPI消費が発生してしまうのでひと手間加えるといいと思います。下記のような感じです。

コンストラクタ

コンストラクタは処理の一番はじめに実行される処理です。ここでカスタム設定に必要な値が存在しているかなどのエラー判定を行います。
f:id:tyoshikawa1106:20200915084140p:plain

コンストラクタでチェックすること
  1. カスタム設定の値チェック
  2. 対象データの存在チェック★
  3. Pardot APIキーの取得(Salesforce APIの実行)
  4. 実行結果を変数にセット

特に重要と考えているのは対象データの存在チェックです。バッチ処理ではstartメソッド内でクエリを実行して0件の場合は処理がスキップされますので通常は気にしなくていいのですが、API処理の実行がある場合、0件で処理を実行しても無意味なため、一度対象が0件がどうかはチェックを行い、処理対象となるデータが存在しない場合は以降の処理をスキップする判定を行っておくと良いと思います。


カスタム設定の存在チェックやPardot APIキーの取得処理でエラー発生した際にはStirng型変数(errorMessage)に原因のテキストを格納してreturnで処理を終了します。このエラーメッセージを格納した変数は以降の処理に引き継いで使用します。


尚、Apexバッチ開発の注意点としてコンストラクタ内でreturn処理を実行して処理を途中で終了しても必ずstartメソッドの処理が実行されます。(Exceptionエラーになれば別です)。そのことを考慮して実装をすすめる必要があります。

startメソッド

startメソッドではバッチ処理の対象となるレコード取得を行います。
f:id:tyoshikawa1106:20200915084901p:plain


startメソッド内でSOQLクエリを実行する際ですが、コンストラクタで用意したエラーメッセージのチェックと対象レコード0件かどうかのSkipフラグの値を確認します。


続きの処理を実行する必要がなければ「LIMIT 0」でバッチ処理をクローズします。
f:id:tyoshikawa1106:20200915085133p:plain

executeメソッド

executeメソッドはバッチ処理のメイン処理です。実行時に指定したバッチサイズの数にレコードを分割して処理を行ってくれます。
f:id:tyoshikawa1106:20200915190540p:plain


基本的に更新用リストに格納して一括更新する処理が望ましいのですが、実行するPardot APIの処理内容によっては一括更新用のAPIが用意されていない場合があります。そうした場合はバッチサイズを制御して処理をするといいと思います。(バッチサイズ200で処理してエラーになるものが、50に設定すると負荷なく処理が実行されるといったケースがありました。ただしバッチサイズ「1」は可能な限り避けたほうが良いと思います。)

finishメソッド

finishメソッドはバッチ処理の一番最後に実行される処理です。エラーが発生している場合などにメール送信処理を実行したりといった使い方ができます。
f:id:tyoshikawa1106:20200915190937p:plain



上記のような感じでPardot APIのバッチ処理による実行が開発可能となっていました。

Pardot APIとスケジュールバッチ

定期的にバッチ処理を実行するにはスケジュールバッチの処理で実現できます。ただし、API処理を含むApexバッチはスケジュールバッチから呼び出すことができません。確か下記のエラーとなります。

callout from scheduled apex not supported


@futureによる非同期処理が回避策としてあったと思いますが、バッチ処理で非同期処理を呼び出すのはあまり適切ではなさそうです。(finish処理の順序も担保されなくなりそう。)


そこで取れる回避策が「Queueable」インターフェースをつかった処理です。


implements Queueableを宣言することで利用できるようになります。

f:id:tyoshikawa1106:20200915192536p:plain

クラスの構成はコンストラクタとexecuteメソッドの2つだけとなります。バッチと似たような感じで開発することになりますが、大量件数の処理には向いていません。


尚、Queueableインターフェースのクラスは下記のような処理で実行します。

System.enqueueJob(new PardotRelationQueueable());


以上がPardot APIでのApexバッチによる大量データの処理とQueueableインターフェースによるスケジュール実行の開発例です。API処理は一日の実行回数に上限がありますので対象データが無い場合は処理スキップするなどひと手間加えて考慮することでトラブルや拡張性の低下を防止することができます。

SFDC:Apex開発とPardot API - Part 1

Apex開発とPardot APIについてです。

f:id:tyoshikawa1106:20200628121242p:plain

Overview - Pardot API Documentation

Pardot APIの基本的な使い方

Apexでの開発どうこうの前に、Pardot APIへの認証方法からデータの取得まで基本的な使い方がわからなかったのでどうしたものかなと悩んでいたところ、次のブログ記事を見つけて問題が解決しました。


InsomniaというツールをつかってPardot APIによる認証からデータの取得→更新まで開発に必要なAPI処理の使い方について解説がされていました。自分の環境で試してみてPardot API自体が正しく実行できることの動作確認ができました。

Pardot APIを使った機能の再開発の流れ

最終的なゴールはAPIをつかったデータの更新処理でしたが、基本もわからず手探りでそのゴールを目指すのはシンドかったので下記の手順で対処しました。

  1. InsomniaをつかってPardot APIの基本操作を確認
  2. ApexとPardot APIによるデータ取得 ★今回の記事でも使うサンプル機能
  3. ApexとPardot APIによるデータ更新 ★最終的なゴール

サンプルコード

今回の記事で使うサンプルコードです。(classとpageのフォルダにサンプルコードが入っています。)


Pardot APIでPardotキャンペーンの情報を取得してリスト表示するVisualforceページとなります。
f:id:tyoshikawa1106:20200628123511p:plain

はじめに

開発前に下記の2つを用意します。

カスタム設定の用意

認証情報をApexに直接埋め込むとメンテナンス性を下げてしまいます。こうした情報はカスタム設定で管理するべきなので今回もそのように準備します。

f:id:tyoshikawa1106:20200628124429p:plain


登録する認証情報はこんな感じ。カスタム設定の値登録をプロファイルに紐付けて登録しているのを見かけることがありますが、プロファイルごとに登録内容を分ける必要がなければ、組織に紐付けて登録しておく方が利用用途が広がった際に一部のユーザだと動かないというトラブルを回避できて便利だと思います。

f:id:tyoshikawa1106:20200628124643p:plain

リモートサイトの用意

Salesforce内から外部システムのAPIを実行する場合はリモートサイトへの登録が必要となります。
f:id:tyoshikawa1106:20200628124841p:plain


これが登録されてないと次のようなエラーになります。
f:id:tyoshikawa1106:20200628124913p:plain

Apex処理の流れ

PardotAPIによる認証処理とPardotキャンペーンの情報を取得する処理をApexで行うと下記の流れとなります。

  1. カスタム設定からPardot認証情報取得
  2. カスタム設定取得結果でエラー判定★
  3. Pardot認証処理を実行
    • 認証に成功するとAPIキーを取得できます。
    • APIキーの利用期限は1時間です。
  4. API実行時のステータスコードでエラー判定★
  5. API実行結果の値の受け取り。(APIキー取得処理)
    • 結果はXML形式で返ってきます。
    • 値の受け取りはDom.Document型変数などを利用します。
  6. APIキーの値の有無でエラー判定★
  7. Pardotキャンペーンの取得
    1. 認証処理で取得したAPIキーがあればデータの取得処理を実行できます。
  8. API実行時のステータスコードでエラー判定★
  9. API実行結果の値の受け取り。(Pardotキャンペーン取得処理)
    • 結果はXML形式で返ってきます。
    • 値の受け取りはDom.Document型変数などを利用します。


処理としては上記のとおりです。ざっくりまとめると認証→データ取得になりますが実際に開発するときに意識すると結構細かい処理の実装が必要になるはずです。


★のついているのがエラー判定処理です。外部システムとのAPI連携の場合、様々な理由で連携処理が適切に動作しなくなる可能性があるので細かくエラーチェックをしていくのが良いと思います。

Pardot APIの連携失敗で考えられるケース

  1. カスタム設定に保持した認証情報を誤った情報に更新してしまった。
  2. Pardot側に用意された認証用アカウントの情報を別の値に更新してしまった。
    • パスワード変更など
  3. Pardot側の権限周りの設定に変更が発生した。
    • IPアドレスの制限追加など
  4. Salesforce側の権限周りの設定に変更が発生した。
  5. Pardot APIの仕様が変更されて今までの実装方式が使えなくなった。
  6. Apexの仕様が変更されて今までの実装方式が使えなくなった。


ざっくり想定しただけでも上記のケースが考えられます。細かくエラーチェックをすることでトラブル発生時に原因の調査をスムーズに進められるはずです。

Apexでの実装コード

カスタム設定からPardot認証情報取得

カスタム設定の情報はApexの機能として用意されているものをそのまま使って取得できます。
f:id:tyoshikawa1106:20200628133003p:plain


エラーチェックはこんな感じ。
f:id:tyoshikawa1106:20200628133217p:plain

※エラー発生した場合はerrorMessage変数に格納すると画面にメッセージが表示される処理となっています。(これ以降にも共通の挙動となる部分です。)

APIキーの取得

PardotAPiをつかった認証処理です。
f:id:tyoshikawa1106:20200628133316p:plain

f:id:tyoshikawa1106:20200628133441p:plain


認証処理のPOSTは「multipart/form-data」形式で行えば良いことが最初にリンクを貼ったブログ記事で把握することができました。問題はApexクラスでPOSTする際の書き方がわからなかったことですが、これについては過去に別の問題で調査が必要だったときに人に教わっていたのでなんとかなりました。

APIキーの取得結果の格納(ステータスコード)

まずはAPI実行自体がうまく行ったかをステータスコードからチェックします。Apexでは「getStatus」などの処理が用意されているのでそれで取得できます。

f:id:tyoshikawa1106:20200628134147p:plain


ステータスコードのチェック処理は別メソッドに分けておくとテストクラスの開発時に引数を渡してテストできるようになって開発が楽になると思います。

f:id:tyoshikawa1106:20200628134303p:plain

APIキーの取得結果の格納(APIキー)

APIの実行結果はXML形式で返ってきます。ここがやり方がわからなかったところで、手探りの試行錯誤でアレコレ試して動く方法を見つけたという感じの場所です。

f:id:tyoshikawa1106:20200628134813p:plain

f:id:tyoshikawa1106:20200628134915p:plain



手探りといっても流石に開発者ガイドはチェックしながら調査しました。「salesforce apex xml」という感じにそれっぽいキーワードで検索すると対象のページがヒットします。
f:id:tyoshikawa1106:20200628135052p:plain

Pardotキャンペーン取得

取得したAPIキーを使ってPardotのデータを取得する処理を実行できます。取得対象はなんでもよかったのですが、とりあえずの動作確認用であればキャンペーンデータへのアクセスぐらいがちょうど良いかなと選択しました。

f:id:tyoshikawa1106:20200628135311p:plain

f:id:tyoshikawa1106:20200628135350p:plain

Pardotキャンペーンの取得結果判定

認証処理と同じでステータスコードなどのチェックを行います。チェック処理は認証処理の際に使ったものをそのまま適用できると思います。

f:id:tyoshikawa1106:20200628135617p:plain

Pardotキャンペーンの取得結果を変数にセット

APIキーの取得処理ではシンプルなXML結果で取得できましたが、キャンペーンなど複数データの取得はXMLの形式も入れ子になっていたりして複雑になっています。

f:id:tyoshikawa1106:20200628135830p:plain


このXMLの中から対象のリスト情報を取得する部分がさっぱりわからず時間を持っていかれたのですが、最終的に海外のブログ記事で参考になる記事が見つかり下記の処理で値の取得に成功しました。

f:id:tyoshikawa1106:20200628140215p:plain


参考になった海外のブログ

Infallible Techie: Simple REST API for XML response in Salesforce


以上の処理でPardot APIからキャンペーンリストを取得するところまで動作するはずです。

Apexテストクラスの作成

Pardot APIの基本操作を確認するこのサンプル機能の開発ではもう一つチェックしておくべき箇所があります。テストクラスの作成についてです。Apexクラスの開発だけやってテストクラスはやっつけ対応するケースを見かけることがありますが、それをやってしまうと後続の追加開発時に支障が発生します。そういった不要なトラブル回避のため、テストクラスが正しく実装できるかも調査をしました。


Pardot APIの実行といったコールアウト処理を実装する場合のテストクラスですが、「implements HttpCalloutMock」で呼び出すモック処理を用意する必要があります。ただ、今回のように複数のエンドポイントを対象に処理を用意する場合のテスト処理はどう書くのがキレイかなと調べたところ、StackExchangeに良いやり方が紹介されていました。

f:id:tyoshikawa1106:20200628142544p:plain

apex - How to create mock class for multiple Callouts in single class - Salesforce Stack Exchange


意味としては下記のとおり。

  1. テストクラス内のインナークラスとしてHttpCalloutMockクラスを用意する。
  2. Endpointの値をチェックしてif文判定で戻り値を切り替える。


これを参考に実装した結果がこちらです。このやり方でスムーズにテストクラスを実装できました。
f:id:tyoshikawa1106:20200628142835p:plain


また、コールアウトモック処理で返す結果はBodyにセットする形で返すことができます。PardotAPIの処理はXML形式となっているため、テストデータでもXMLの形式にしておく必要があります。このときに普通のString文字列として頑張って用意するケースを見かけることがありますが、Apexに用意されているXmlStreamWriter関数を利用することでメンテナンス性を下げずにXML形式の文字列を用意することが可能です。

f:id:tyoshikawa1106:20200628143250p:plain


以上がApex開発とPardot APIについてです。この方法でApexでのPardot API処理の実装を行えると思います。