こんにちわ、ソリューション開発部の倉橋浩一です。今年もアップルWWDCの抽選に外れてしまいました。

今回の偏りポイント

Salesforceについての情報はインターネット上にたくさん公開されていますが、Sitesという技術についてはあまり見当たらないような気がします。しかし弊社のシステムでは機能の95%程度がSites上で製作されているため、避けては通れません。

ということで、Sitesについて見ていきましょう。

なおこの記事は、第一回にも記載した通り、Salesforceおよびforce.comの基礎知識を前提としています。

Sitesとは

Salesforce上に構築されるWebページおよびその管理機能です。

Sitesは通常のSalesforceページと大きく異なります。通常のSalesforceページはSalesforceに対して有償のアカウントでログインしなければアクセスすることができませんが、セキュリティはSalesforceによって保証されています。一方Sitesは、一応IP指定などの制限は可能ですが、URLを知っている者であれば誰でもアクセスすることができます。つまり、安全に守られたSalesforceと異なり、Sites上に業務アプリケーションを構築する場合には一般のJava等でのWebアプリと同様に自分の責任で認証やセッション管理を実装する必要があります。

さらにSites上で操作・表示する必要のない情報はセキュリティ設定で非公開にし、万一セッション管理に想定外の問題が生じたとしてもデータが見えないようにすべきです。後述しますが、Salesforceのセキュリティ設定は柔軟かつ強力で、仮にある情報をSOQLSQLみたいなもの)でfetchしてページ上に表示しようとしても、セキュリティ設定が非公開になっていれば表示されません。オブジェクト(テーブル)単位でのCRUD設定だけでなく、項目ごとに非公開、読み出しのみ、公開、の設定が可能です。

Sitesを使う、その前に

最低でもVisualforceページが必要です。用意しましょう。

Salesforceにログインし、右上の方にある「設定」で設定画面に入ります。クイック検索に「Visualforce」と入力し、「Visualforceページ」をクリックします。ちなみに「Visualforceコンポーネント」としてページの一部分を定義しパラメータを渡して再利用することができます。

「新規」ボタンをクリックします。表示ラベルに「デモ」、名前に「demo」と入力します。その下にVisualforce MarkupとしてHTMLっぽいソースが表示されていますね。最初の1行目を <apex:page sideBar=”false” showHeader=”false”> に変えて、「保存」ボタンをクリックします。Salesforce標準ページではヘッダーやサイドバーに多くの機能が含まれていますが、それらはSitesでは使えないものを含むので、それらをあらかじめfalseにしました。

VisualforceページはSalesforce画面を定義するものです。htmlが基本ですが、ダイナミックなタグは apex: で始まるタグによって定義されています。

Visualforceのページの編集画面

Sitesを使う

Salesforceにログインし、右上の方にある「設定」で設定画面に入ります。クイック検索に「サイト」と入力すると、ビルドの下の開発、その下に「サイト」と表示されますので、これをクリックします。

サイトのドメイン名を登録します(契約や使用環境によってはこの設定は省略されます)。一度登録すると変更できないので、慎重に決めましょう。なおURLとしては <登録したドメイン名>.force.com となります(本番環境の場合 / 開発者環境やサンドボックスなどでは少し変わります)。

新規ボタンをクリックして、表示ラベル名(日本語での名称)を「デモ」、サイト名(APIとしての名称を英数字で)「demo」、デフォルトWebアドレス「sitesdemo」、さきほど作ったVisualforceページ「demo」を「有効なサイトのホームページ」として選択、セキュアな接続(HTTPSが必要)をチェックし、「保存」ボタンをクリックします。

これでSitesページ「デモ」が登録されました。

Visualforceのサイトの編集画面

Sitesのセキュリティ設定

Salesforceでの基本的なセキュリティ設定の考え方は、「基本はすべて非公開、必要に応じて許可を与えていく」というものです。

初期状態のSitesでもpage not foundno sessionなどのエラーページしか許可されていません。ページ、クラス、データ、すべてが非公開の状態です。

Salesforceのセキュリティは主にプロファイルとロールによって決まります。プロファイルは機能ごとの権限をユーザに付与するもの、ロールはユーザに組織としての階層(たとえば、上司からは部下のデータが見えるが、部下は上司のデータを見られない等)としての権限を規定します。

Sitesの場合は、プロファイルとして権限を定義します(ユーザという概念がないのでロールもない)。上で「デモ」を登録しましたが、その「公開アクセス設定」ボタンから設定画面に入ることができます。

プロファイルデモ プロファイル画面では、非常に多くの設定項目がありますが、よく使うのは

  • ログインIPアドレスの制限
  • 有効なApexクラス
  • 有効なVisulaforceページ
  • カスタム項目レベルセキュリティ
  • カスタムレコードタイプの設定
  • カスタムオブジェクト権限
  • ログイン時間帯の制限

です。さきほど定義したdemo/デモは、Sitesを作る際にページとして登録したので自動的に「有効なVisualforceページ」として登録されており追加不要です。

Sitesにアクセスしてみる

さきほど登録した「デモ」の行を見ると「有効化」となっています。Sitesは定義されただけの状態だと無効で、ここで「有効化」リンクをクリックしないとアクセスすることができません。ワンタッチで有効無効を切り替えることができるので便利です。同じ行にサイトのURLが記載されていますので、これをクリックするとさきほどVisualforceのソースで見たように「Congraturations This is your new Page」のメッセージだけが入ったページが表示されると思います。

これで、ひとまずSalesforceアカウントなしでもアクセス可能なページが一つできました。お疲れ様です。

Sitesありがちな落とし穴

セキュリティ設定を忘れがちです。前述の通りSalesforceのセキュリティ設定は、「基本は非公開。公開するものを追加していく」という考え方なので、開発がある程度進んだ段階でページ、クラス、データ(オブジェクトおよび項目)を追加した後、ついセキュリティ設定で許可を与え忘れちゃうんですよね。追加したのに画面上にデータの項目名しか出てこなくて、「あれー、おかしいなー」とアホ化した後で気づきます。とほほ。

あと、「有効化」も忘れちゃうんですよね。どちらも気を抜くとやってしまう自己嫌悪ネタです。気をつけましょう。

次回予告

次回はログインページ、セッション管理あたりを実装してみます。なお、このブログで紹介するのは現実の実装をかなり簡略化したものです。特にセッションIDは非常に簡略化したものなので、そのまま使うとセキュリティホールになる可能性があります。決してそのまま使わないでください。

ではどうぞお楽しみに!

少し偏った用語解説

Force.com

SalesforceからSFA(営業支援)やCRM(顧客管理)の便利機能をばっさり取ったForce.com部分。基本的にコード+設定ベースでMVCモデルを構築できるのですが、その他にクリックベースで承認プロセスやワークフローを構築し、レポート(帳票)を作成することもできます。業務用アプリケーションを作る上で必要な機能は一通り揃っています。

オブジェクト

Salesforceではテーブルのことをオブジェクトと呼びます。標準オブジェクトとカスタムオブジェクトがありますが、標準オブジェクトはSFA, CRMなどに用いる最初から定義されたオブジェクト、カスタムオブジェクトは私ら開発者/ユーザが定義したオブジェクトです。Salesforceとの契約によってSites上で利用可能な標準オブジェクトの種類/権限が異なるので、詳細についてはSalesforce社の営業担当者に確認してください。なお、標準オブジェクトは、たとえば商談情報を記録するOpporutunityのようにオブジェクトの名前そのままですが、カスタムオブジェクトおよびカスタム項目については末尾に__cを付ける必要があります。標準オブジェクトとの名前空間衝突を防ぐ処置です。

SOQL

 SQLみたいなもの

Apex

 JavaみたいなScript言語。JavaScriptよりもJavaに近いのでオブジェクト指向言語としては非常に現実的に書けます。当然ですが、SOQLとの親和性が非常に高いので、データベースを処理するオブジェクト指向言語としての生産性はかなり高いです……もちろんNeXT社のEnterprise Object Frameworkを越えるほどではありませんが(※倉橋個人の見解です)。

Visualforce

 htmlを拡張したマークアップ言語。Salesforce標準画面っぽいものは比較的ラクですが、そこからちょっと外れたことをしようとすると制約の嵐があなたを襲います。標準画面っぽいものを作るならVisualforceタグ中心、ユーザのわがままままままな要望に答えるためにカラム数などを自由に配置したい場合にはダサさをかみ殺しつつTableレイアウトを使いましょう。div使うとSalesforceのスタイルシートに邪魔されて頭を抱えることが多いので。なお、最近はlightningという新しい要素もあるらしいです(不知)。

 開発環境

Developer’s Edition、無償でサインアップして使うことができる。SFA, CRMの標準的な機能とForce.comのほとんどの機能を使うことができるが、アカウント数やデータ量が制限されています。何より開発用以外の目的で利用することは禁止されているので注意する必要があります。開発環境では後述するサンドボックスは使えません。

サンドボックス

本番環境をコピーして開発環境等として使うことができます。利用可能なサンドボックスは契約によって異なりますが、たとえば弊社の環境では一つのPartial Copyと25個までのDeveloperを利用可能できます。通常は、本番環境で運用、Partial Copyにリリースのためのテスト環境、Developerで要素ごと/開発担当者ごとに開発を行います。開発できたものは、DeveloperからPartial Copy環境にリリースし、動作を検証した上で本番環境にリリースします。

Sandbox画面


Force.comの少し偏った教科書 連載一覧


 

この記事が気に入ったら
いいね!しよう

最新情報をお届けします

Twitter で「株式会社アークシステム」をフォローしよう!

Force.comの少し偏った教科書 : 2.Sitesを使おう!https://devlog.arksystems.co.jp/wp-content/uploads/2017/04/forcedotcom_site-1200x630.pnghttps://devlog.arksystems.co.jp/wp-content/uploads/2017/04/forcedotcom_site-150x150.pngk-kurahashiクラウド利用技術Java,Force.com,Salesforceこんにちわ、ソリューション開発部の倉橋浩一です。今年もアップルWWDCの抽選に外れてしまいました。 今回の偏りポイント Salesforceについての情報はインターネット上にたくさん公開されていますが、Sitesという技術についてはあまり見当たらないような気がします。しかし弊社のシステムでは機能の95%程度がSites上で製作されているため、避けては通れません。 ということで、Sitesについて見ていきましょう。 なおこの記事は、第一回にも記載した通り、Salesforceおよびforce.comの基礎知識を前提としています。 Sitesとは Salesforce上に構築されるWebページおよびその管理機能です。 Sitesは通常のSalesforceページと大きく異なります。通常のSalesforceページはSalesforceに対して有償のアカウントでログインしなければアクセスすることができませんが、セキュリティはSalesforceによって保証されています。一方Sitesは、一応IP指定などの制限は可能ですが、URLを知っている者であれば誰でもアクセスすることができます。つまり、安全に守られたSalesforceと異なり、Sites上に業務アプリケーションを構築する場合には一般のJava等でのWebアプリと同様に自分の責任で認証やセッション管理を実装する必要があります。 さらにSites上で操作・表示する必要のない情報はセキュリティ設定で非公開にし、万一セッション管理に想定外の問題が生じたとしてもデータが見えないようにすべきです。後述しますが、Salesforceのセキュリティ設定は柔軟かつ強力で、仮にある情報をSOQL(SQLみたいなもの)でfetchしてページ上に表示しようとしても、セキュリティ設定が非公開になっていれば表示されません。オブジェクト(テーブル)単位でのCRUD設定だけでなく、項目ごとに非公開、読み出しのみ、公開、の設定が可能です。 Sitesを使う、その前に 最低でもVisualforceページが必要です。用意しましょう。 Salesforceにログインし、右上の方にある「設定」で設定画面に入ります。クイック検索に「Visualforce」と入力し、「Visualforceページ」をクリックします。ちなみに「Visualforceコンポーネント」としてページの一部分を定義しパラメータを渡して再利用することができます。 「新規」ボタンをクリックします。表示ラベルに「デモ」、名前に「demo」と入力します。その下にVisualforce MarkupとしてHTMLっぽいソースが表示されていますね。最初の1行目を <apex:page sideBar='false' showHeader='false'> に変えて、「保存」ボタンをクリックします。Salesforce標準ページではヘッダーやサイドバーに多くの機能が含まれていますが、それらはSitesでは使えないものを含むので、それらをあらかじめfalseにしました。 VisualforceページはSalesforce画面を定義するものです。htmlが基本ですが、ダイナミックなタグは apex: で始まるタグによって定義されています。Sitesを使う Salesforceにログインし、右上の方にある「設定」で設定画面に入ります。クイック検索に「サイト」と入力すると、ビルドの下の開発、その下に「サイト」と表示されますので、これをクリックします。 サイトのドメイン名を登録します(契約や使用環境によってはこの設定は省略されます)。一度登録すると変更できないので、慎重に決めましょう。なおURLとしては <登録したドメイン名>.force.com となります(本番環境の場合 / 開発者環境やサンドボックスなどでは少し変わります)。 新規ボタンをクリックして、表示ラベル名(日本語での名称)を「デモ」、サイト名(APIとしての名称を英数字で)「demo」、デフォルトWebアドレス「sitesdemo」、さきほど作ったVisualforceページ「demo」を「有効なサイトのホームページ」として選択、セキュアな接続(HTTPSが必要)をチェックし、「保存」ボタンをクリックします。 これでSitesページ「デモ」が登録されました。Sitesのセキュリティ設定 Salesforceでの基本的なセキュリティ設定の考え方は、「基本はすべて非公開、必要に応じて許可を与えていく」というものです。 初期状態のSitesでもpage not foundやno sessionなどのエラーページしか許可されていません。ページ、クラス、データ、すべてが非公開の状態です。 Salesforceのセキュリティは主にプロファイルとロールによって決まります。プロファイルは機能ごとの権限をユーザに付与するもの、ロールはユーザに組織としての階層(たとえば、上司からは部下のデータが見えるが、部下は上司のデータを見られない等)としての権限を規定します。 Sitesの場合は、プロファイルとして権限を定義します(ユーザという概念がないのでロールもない)。上で「デモ」を登録しましたが、その「公開アクセス設定」ボタンから設定画面に入ることができます。 プロファイル - デモ プロファイル画面では、非常に多くの設定項目がありますが、よく使うのはログインIPアドレスの制限 有効なApexクラス 有効なVisulaforceページ カスタム項目レベルセキュリティ カスタムレコードタイプの設定 カスタムオブジェクト権限 ログイン時間帯の制限です。さきほど定義したdemo/デモは、Sitesを作る際にページとして登録したので自動的に「有効なVisualforceページ」として登録されており追加不要です。 Sitesにアクセスしてみる さきほど登録した「デモ」の行を見ると「有効化」となっています。Sitesは定義されただけの状態だと無効で、ここで「有効化」リンクをクリックしないとアクセスすることができません。ワンタッチで有効無効を切り替えることができるので便利です。同じ行にサイトのURLが記載されていますので、これをクリックするとさきほどVisualforceのソースで見たように「Congraturations This is your new Page」のメッセージだけが入ったページが表示されると思います。 これで、ひとまずSalesforceアカウントなしでもアクセス可能なページが一つできました。お疲れ様です。Sitesありがちな落とし穴 セキュリティ設定を忘れがちです。前述の通りSalesforceのセキュリティ設定は、「基本は非公開。公開するものを追加していく」という考え方なので、開発がある程度進んだ段階でページ、クラス、データ(オブジェクトおよび項目)を追加した後、ついセキュリティ設定で許可を与え忘れちゃうんですよね。追加したのに画面上にデータの項目名しか出てこなくて、「あれー、おかしいなー」とアホ化した後で気づきます。とほほ。 あと、「有効化」も忘れちゃうんですよね。どちらも気を抜くとやってしまう自己嫌悪ネタです。気をつけましょう。 次回予告 次回はログインページ、セッション管理あたりを実装してみます。なお、このブログで紹介するのは現実の実装をかなり簡略化したものです。特にセッションIDは非常に簡略化したものなので、そのまま使うとセキュリティホールになる可能性があります。決してそのまま使わないでください。 ではどうぞお楽しみに! 少し偏った用語解説 Force.com SalesforceからSFA(営業支援)やCRM(顧客管理)の便利機能をばっさり取ったForce.com部分。基本的にコード+設定ベースでMVCモデルを構築できるのですが、その他にクリックベースで承認プロセスやワークフローを構築し、レポート(帳票)を作成することもできます。業務用アプリケーションを作る上で必要な機能は一通り揃っています。 オブジェクト Salesforceではテーブルのことをオブジェクトと呼びます。標準オブジェクトとカスタムオブジェクトがありますが、標準オブジェクトはSFA, CRMなどに用いる最初から定義されたオブジェクト、カスタムオブジェクトは私ら開発者/ユーザが定義したオブジェクトです。Salesforceとの契約によってSites上で利用可能な標準オブジェクトの種類/権限が異なるので、詳細についてはSalesforce社の営業担当者に確認してください。なお、標準オブジェクトは、たとえば商談情報を記録するOpporutunityのようにオブジェクトの名前そのままですが、カスタムオブジェクトおよびカスタム項目については末尾に__cを付ける必要があります。標準オブジェクトとの名前空間衝突を防ぐ処置です。 SOQL  SQLみたいなもの Apex  JavaみたいなScript言語。JavaScriptよりもJavaに近いのでオブジェクト指向言語としては非常に現実的に書けます。当然ですが、SOQLとの親和性が非常に高いので、データベースを処理するオブジェクト指向言語としての生産性はかなり高いです……もちろんNeXT社のEnterprise Object Frameworkを越えるほどではありませんが(※倉橋個人の見解です)。 Visualforce  htmlを拡張したマークアップ言語。Salesforce標準画面っぽいものは比較的ラクですが、そこからちょっと外れたことをしようとすると制約の嵐があなたを襲います。標準画面っぽいものを作るならVisualforceタグ中心、ユーザのわがままままままな要望に答えるためにカラム数などを自由に配置したい場合にはダサさをかみ殺しつつTableレイアウトを使いましょう。div使うとSalesforceのスタイルシートに邪魔されて頭を抱えることが多いので。なお、最近はlightningという新しい要素もあるらしいです(不知)。  開発環境 Developer's Edition、無償でサインアップして使うことができる。SFA, CRMの標準的な機能とForce.comのほとんどの機能を使うことができるが、アカウント数やデータ量が制限されています。何より開発用以外の目的で利用することは禁止されているので注意する必要があります。開発環境では後述するサンドボックスは使えません。 サンドボックス 本番環境をコピーして開発環境等として使うことができます。利用可能なサンドボックスは契約によって異なりますが、たとえば弊社の環境では一つのPartial Copyと25個までのDeveloperを利用可能できます。通常は、本番環境で運用、Partial Copyにリリースのためのテスト環境、Developerで要素ごと/開発担当者ごとに開発を行います。開発できたものは、DeveloperからPartial Copy環境にリリースし、動作を検証した上で本番環境にリリースします。Force.comの少し偏った教科書 連載一覧Force.comの少し偏った教科書 : 1.黎明編 Force.comの少し偏った教科書 : 2.Sitesを使おう!(本記事) Force.comの少し偏った教科書 : 3.Sitesにセッションを実装するARK Solution Development Division Developers Blog.