セールスフォースの豆知識

集計関数

Spring '10から集計関数が利用できるようになりました。
APIバージョン18以上で使用可能のようです。

利用できる集計関数は以下の6種類。

関数名	結果
Avg	平均値
Count	レコード件数
Count_Distinct	nullと重複値を除いたレコード件数
Max	最大値
Min	最小値
Sum	合計値

こんな感じで↓使用します。

Select Count(Id) From Account Where Name Like 'a%'

グループ化したい場合は、Group By句と共に利用します↓

Select Name, Max(BudgetedCost) From Campaign Group By Name

Apexではクエリ結果を、
AggregateResult（複数の場合はList<AggregateResult>）で受け取り、AggregateResultオブジェクト.get('名称')で値を取得します。

集計関数の名称は↓のように付けます（maxNumが名称）。

Select Name, Max(Num__c) maxNum From Order__c Group By Name

集計関数の結果取得部分のソースコードはこんな感じ。

List<AggregateResult> aggregateList = 
[
	Select 
		Name, 
		Max(Num__c) maxNum 
	From 
		Order__c 
	Group By 
		Name
];

for(AggregateResult a : aggregateList) {
	Integer maxNum = Integer.valueOf(a.get('maxNum'));

	// 処理
}

SOQLでのリレーションの辿り方

SQLでは動的に列を指定して表を結合することができますが、SOQLでは動的に結合することはできません（そもそも結合ができない）。

SOQLではオブジェクト間に予めリレーションを設定しておくことにより、リレーションを辿ってのデータ参照が可能となります。

ということで、今日はSOQLでのリレーションの辿り方をご紹介。

子オブジェクトから親オブジェクトへのリレーションの辿り方

子オブジェクトから親オブジェクトへは、リレーション名を使用してリレーションを辿ります。

リレーション名は、参照/主従関係のカスタム項目名 + __r となります（標準項目のリレーション名は予め設定されています）。

SOQLのFrom句には必ず基点となるベースオブジェクトを指定しますが、ベースオブジェクトから最大5段階まで親のリレーションを辿ることができます。

●親リレーションを辿るサンプル

Select 
  c.Name, 
  a.Name,
  u.Name 
From 
  Contact c, ★ベースオブジェクト
  Contact.Account a, 
  Contact.Account.CreatedBy u

親オブジェクトから子オブジェクトへのリレーションの辿り方

親オブジェクトから子オブジェクトへは、 子リレーション名を使用してリレーションを辿ります。

以前は、子リレーション名を特に指定しない場合、自動的にランダムな名称が設定されてしまい、Select Id From R00NA0000001a2bkoko ・・・などと、かなり分かりづらいSOQLを書くハメになったりもしましたが、Summer '10からは、子リレーション名が必須項目となり、そのようなこともなくなりました。

子リレーション名は自オブジェクトの複数形で付けることが一般的なようです（分かりやすいですしね）。例えば、ContactからAccountへリレーションを結ぶ場合は、子リレーション名をContactsにします。

SOQLでは、メインクエリのFrom句にベースオブジェクト名を、サブクエリのFrom句に子リレーション名を指定して、データを取得します。

ここで重要なのは、親から子へは1段階しかリレーションを辿ることはできない、ということ。指定したベースオブジェクトの子オブジェクトのみリレーションを辿ることが可能です。子の子や親の子などはアクセス不可です。

●子リレーションを辿るサンプル（ContactsがAccount→Contactへ辿る子リレーション名）

Select 
  a.Name, 
  (Select c.Name From Contacts c) 
From 
  Account

●ベースオブジェクトから親5段階、子1段階の範囲であれば、同時にデータ取得が可能

Select 
  a.Name, 
  u.Name, 
  (Select c.Name From Contacts c), 
  (Select n.Title From Notes n) 
From 
  Account a, 
  Account.Owner o, 
  Account.Owner.CreatedBy u

●下記のように、From句にベースオブジェクトを2つ指定することは不可

Select 
  a.Name, 
  u.Name 
From 
  Account a, 
  User u

親から子へ1段階しか辿ることができないというのは、かなり大きな制約です。データモデルの設計時には必ず覚えておきましょう。

と言いつつ、もうそろそろ、2段階、3段階と子リレーションを辿れるようになるんじゃないか？と淡い期待もしてたりします（集計関数も使えるようになりましたしね）。

連結オブジェクト

データモデルを検討していると、多対多の関係にしたい場合がでてきます。

多対多の関係の例

「学生と講座」
・学生は複数の講座を受講する
・講座は複数の学生が受講する

リレーショナルデータベースでは、多対多の関係を表せないので、
連結テーブルを間に挟んで、「1対多」と「多対1」の関係にします。

学生 ―1対多― 受講 ―多対1― 講座

上記のデータモデルにすることで、学生が受講している各講座の成績などを受講テーブルで管理できるようになります。

さて、これをSalesforceで実現するにはどうするかというと、
RDBと同じように連結テーブルならぬ連結オブジェクトを
多対多の関係にしたいオブジェクトの間に挟みます。

このときに重要なのは、連結オブジェクトから親オブジェクトへのリレーションは主従関係で結ぶということ。

上記の例で言うと、「受講 ⇒ 学生」「受講 ⇒ 講座」と2つの主従関係を結びます。
片方でも参照関係で結んでしまうと、連結オブジェクトになりませんので、注意してください。

前回の記事で、主従関係は2つまでしか結べないという制限をご紹介しましたが、この制限内で多対多のリレーションを実現することができます。

連結オブジェクトのデータモデルにすると、
通常は子オブジェクトの項目しか表示できない関連リストに、
連結先のオブジェクトの項目を表示できて、とても便利です。

上記の例で言うと、学生オブジェクトの受講関連リストに、受講オブジェクトの項目（受講番号、評価）だけでなく、講座オブジェクトの項目（講座名、区分、分類、担当、単位数）を表示できます（↓の画像を参照のこと）。

この機能によって、まさに多対多の関係を実現できていることが分かるかと思います。

もちろん同様に連結先からも連結元のオブジェクトの項目を表示できます。
上記の例で言うと、講座オブジェクトの受講関連リストに学生オブジェクトの項目（学生名、性別、生年月日、入学日）を表示できます（↓の画像を参照のこと）。

最後に、連結オブジェクトの注意点ですが、
連結オブジェクトを主とした主従関係は結べないようになっています。

なので、連結オブジェクトで子オブジェクトの積み上げ集計項目を作ったりはできません。この制限が無くなれば、より便利になるんですけどね。

参照関係と主従関係

リレーションには、参照関係と主従関係があります。

データモデルの検討の際に、親オブジェクトが必須か否かを吟味して、
どちらかを選ぶことになりますが、両者の特性の違いは重要なので、表にまとめてみました。

	参照関係	主従関係
親オブジェクトの必須	必須でない	必須
段階制限	何段階でも可能	最大3段階まで可能（親-子-孫-曾孫）
1つの子オブジェクトからリレーションを結べる親オブジェクトの数の制限	いくつでも参照関係を結ぶことが可能	2つまで可能
親オブジェクトの削除に対する挙動	子オブジェクトは削除されない	子オブジェクトは削除される ※
積み上げ集計	不可	可能
標準オブジェクトを子オブジェクトとするリレーション	可能	不可
カスタムオブジェクトを子オブジェクトとするリレーション	可能	可能
ユーザオブジェクトを親オブジェクトとするリレーション	可能	不可

※ 3段階で主従関係を結んでいる場合、親オブジェクトの削除により、子、孫、曾孫オブジェクトも削除される。

主従関係は、積み上げ集計やカスケード削除ができて便利ですが、最大3段階までしかリレーションを結べなかったり、標準オブジェクトを子オブジェクトとするリレーションを結べなかったりと、参照関係より制限が厳しくなっています。

データモデルで主従関係を利用する場合には、この表を参考にしてみてください。

Summer '10 新機能

6月22日（火）にSummer '10がリリースされました。
今回のリリースのメインはChatterですが、その他で気になった機能をご紹介。

リリースノートはこちら

連動ルックアップ（ベータ）

参照関係/主従関係の項目を作成する時の「ステップ 3」で、↓の画面が出てくるようになり、ルックアップ項目に表示されるレコードの条件を指定できます。今後使う機会が多そうな機能です。

承認フローダイアグラム図（Pilot）

承認プロセスの上に「ダイアグラムの表示」ボタンが追加されています。↓

これを押下すると、このようなダイアグラム図が表示されます↓。印刷もできます。承認フローのドキュメントはこれで代替できそうですね。

Force.com Sites周りで気になった機能追加

「URLリライト」
分かりづらいURLを簡単なURLに変換できる機能です。 urlRewriterインターフェースを実装したURL書き換えクラスを作成して変換します。実装方法はリリースノートを参照のこと。

「Cookieのサポート」
Cookieクラスのget/setCookiesメソッドでCookieにアクセスできるようになります。

「ビューステート インスペクタ（ベータ）」
VisualforceのPage Editorでビューステートを参照できるようになります。
但し、この機能を利用するには、Salesforceへの連絡が必要です。

Chatterを使ってみた

Summer '10でβリリースされるChatterを、Developer Editionで使ってみました。

まず有効化します↓

すると、ホームが↓のような画面になります。

こんな感じでコメントできます。

すべてのタブを表示すると、「人」「プロファイル」「グループ」というタブが増えています。

「人」タブでは、ユーザを検索して、フォロー／フォロー解除を指定できます。

「プロファイル」タブでは、写真、自己紹介を更新でき、自分をフォローしている人と自分がフォローしている人が表示されます。

「設定」→「Chatter」→「フィード追跡」で、フィード追跡の有効化と追跡する項目をオブジェクト毎に選択できます。
フィード追跡を有効化したオブジェクトの詳細画面では、上部にChatterが表示され、追跡する項目が更新されると、Chatterにその旨が表示されます。コメントも投稿できます。もちろん、カスタムオブジェクトもフィード追跡可能です。

レコードをフォローすると、追跡項目の更新状況やコメントが自分のChatter上に表示されます。

「グループ」タブでは、非公開／公開のグループを作って、グループの中で情報共有ができます。

もちろん、加入しているグループのコメントは自分のChatter上に表示されます。

主要な機能はこんな感じ。
レコード毎にフォローできたり、簡単にチームを作れて情報共有できるのは、結構便利かも。

使う前は、Chatterという社内Twitter機能がリリースされるというくらいの認識でしたが、使ってみると、Chatterがアプリケーションの広範囲に関わっており、Chatterによって、Salesforceの使い方が大きく変わりそうな感じがしました。
パートナーポータルやカスタマーポータルと連動して使えるようになると、さらに便利になりそうです。

Save to ServerとDeploy to Serverの違い

Force.com IDEには、ローカルで開発したコードを組織にアップロードするメニューとして、「Save to Server」と「Deploy to Server」が用意されています。

似たような機能で紛らわしいので、挙動を表にまとめてみました。
「Save to Server」でも「Deploy to Server」でもテストは実施されるんですね。
前回の記事の「組織の種類と開発環境／デプロイ方法」と合わせて、整理して理解しておきたいところです。

                                                                                               

	Save to Server	Deploy to Server
デプロイ先	Force.com Projectで設定した組織	実行時に指定
テスト	実施される	実施される
エラーの詳細表示	なし	あり
バックアップ	不可	可能
デプロイ前の検証	不可	可能

↓のように、開発用組織と連動するForce.com Projectを作成し、
開発用組織に保存する時に使うのが「Save to Server」。
運用組織等の他の組織にデプロイする時に使うのが「Deploy to Server」という位置付けのようです。

ちなみに、Force.com IDEで保存ボタンを押下すると（Ctrl + Sも同様）、
「Save to Server」が実行されてしまいますが、
組織に毎回保存したくない場合もあるかと思います。

その場合は、プロジェクトを右クリックして、
「Force.com」⇒「Work Offline」（「オフラインで作業」）を選択すればＯＫ。
オフラインモードで作業することができます。
運用組織と連動して使用する場合等に使える豆知識です。

単体テストのコードを書かなくてもデプロイできる？

開発者の方はDeveloper EditionやSandboxで開発を行うことが多いのではないでしょうか。

DEだと単体テストのコードを書かなくてもデプロイできますし、ブラウザ上でApexコードを書いて保存して、すぐ動かせるのでとても便利です。

そのせいで、運用組織を利用せずに、DEやSandboxに慣れ過ぎてしまうと、
「単体テストのコードを書かなくてもデプロイできる」
と勘違いしてしまいがちです。

しかし、そうではありません。
運用組織へのApexのデプロイは、Force.com IDE か Migration Toolからしかできず（※）、やはり単体テストのカバレッジ率が75%以上であることが必須となります。ブラウザ上からはApexコードを作成することも、削除することもできないので、注意が必要です。

※リリース接続機能やパッケージ機能を利用してリリースすることも可能

DEでは、ブラウザ上でApexクラスの作成ができます（新規ボタン、編集、削除のリンクがある）↓

運用組織では、ブラウザ上でApexクラスの作成ができません（新規ボタン、編集、削除のリンクがない！）↓

とはいえ、なかなか気軽に運用組織を扱える機会が少ないというのも事実です。運用組織の扱いに慣れるには、無料で利用できる「Force.com Free Edition」がお薦めです。CRM機能は利用できないものの、デプロイに関してはEEやUEと同様の挙動を示します。

○組織の種類と開発環境／デプロイ方法

組織の種類	Developer Edition、Sandbox	運用組織（EE、UE、Force.com Free Edition等）
開発環境	ブラウザ上 Force.com IDE	Force.com IDE
デプロイ方法	ブラウザ上 Force.com IDE Migration Tool	Force.com IDE Migration Tool
テストコード	なくてもOK	必須

カスタマーポータルユーザの無効化

前回、カスタマーポータルユーザの作成方法を説明したので、今日は無効化の方法をご紹介。

画面上で無効化する方法

画面上で無効化する方法は

1. カスタマーポータル取引先の無効化
2. カスタマーポータルユーザの無効化
3. ユーザの無効化

の3つの方法があります。

それぞれの手順と特徴は以下の通り。

1. カスタマーポータル取引先の無効化

＜手順＞
取引先詳細画面の 「ポータルの使用」⇒「カスタマーポータル取引先の無効化」を選択

＜特徴＞

• 取引先配下の全てのカスタマーポータルユーザが無効化される
• 再度、「ポータルの使用」→「カスタマーポータルの有効化」から有効化すると、別のユーザが新たに作成される（無効化前のデータを引き継ぐことはできないので注意！）
• 無効化されたカスタマーポータルユーザは「無効ユーザ」となり、ユーザ名の先頭にアンダーバーが付与される

2. カスタマーポータルユーザの無効化

＜手順＞
取引先責任者詳細画面の 「ポータルの使用」⇒「カスタマーポータルユーザの無効化」を選択

＜特徴＞

• 選択したカスタマーポータルユーザのみが無効化される
• それ以外の特徴は「カスタマーポータル取引先の無効化」と同様

3. ユーザの無効化

＜手順＞
ユーザ設定画面で、「有効」のチェックを外して保存

＜特徴＞

• ユーザを再び有効にすることにより無効化前の状態に戻る

Web Service APIから無効化する方法

APIから無効化する方法は

1. カスタマーポータル取引先の無効化
2. ユーザの無効化

の2つの方法があります。

それぞれの手順は以下の通り（特徴は画面上での方法と同じ）。

1. カスタマーポータル取引先の無効化

＜手順＞
無効化対象の取引先（Account） のIsCustomerPortalをFalseに設定する

PHPで書くと、ソースコードはこんな感じ↓

try {
	$account = new SObject();
	$account->Id = $accountId;	// IDを指定
	$account->fields = array(
		'IsCustomerPortal' => false, 
	);
	$account->type = 'Account';
	$result = $client->update(array($account), 'Account');
} catch(Exception $e) {
	echo $e->faultstring;
}

2. ユーザの無効化

＜手順＞
無効化対象のユーザ（User） のIsActiveをFalseに設定する

カスタマーポータルユーザの作成方法

今日はカスタマーポータルユーザの作成方法をご紹介。

画面上で作成する方法

画面上でカスタマーポータルユーザを作成するには、以下の手順を踏みます。

1. 「セルフサービスユーザの編集」の権限を持つユーザでログイン

2. カスタマーポータルユーザにしたい取引先責任者の詳細画面を開く

3. 「ポータルの使用」→「カスタマーポータルの有効化」を押下

4. ユーザの編集画面でユーザ情報を入力して、「保存」を押下

3.では、取引先責任者に対応する取引先の所有者にロールが設定されていないと、エラーとなってしまうので、注意してください。

Web Service APIで作成する方法

Web Service APIでカスタマーポータルユーザを作成するには、
ログイン後、下記の項目を設定して、Userオブジェクトを作成します。

・ContactId ： カスタマーポータルユーザにしたい取引先責任者のID
・ProfileId ： 「Custmer Portal Manager」のプロファイルのID

UserTypeを指定して作成するのではなく、
ProfileIdにカスタマーポータルユーザに割り当てるプロファイルを指定して作成するところがポイント。
「Custmer Portal Manager」の代わりに「High Volume Portal」を割り当てることもできます。

PHPで書くと、ソースコードはこんな感じ↓

try {
	$user = new SObject();
	$user->fields = array(
		'LastName' => '山田', 
		'FirstName' => '太郎', 
		'Alias' => '山田', 
		'Username' => 'y-taro@test.co.jp', 
		'EmailEncodingKey' => 'ISO-2022-JP', 
		'Email' => 'y-taro@test.co.jp', 
		'ContactId' => '003A0000008F9Xy', 
		'ProfileId' => '00eA0000000rBJN', 
		'TimeZoneSidKey' => 'Asia/Tokyo', 
		'LanguageLocaleKey' => 'ja', 
		'LocaleSidKey' => 'ja_JP'
	);
	$user->type = 'User';
	$result = $client->create(array($user), 'User');
} catch(Exception $e) {
	echo $e->faultstring;
}