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

Summer '11とJavaScript Remoting for Apex Controller

Summer '11のリリースが迫ってきました。

日本のユーザが利用するAP0インスタンスでは、日本時間で6月12日(日) 午前2時～7時にリリースされます。例によって、インスタンスごとにリリース日時は違いますので、AP0インスタンス以外のリリース日時は、ここで確認してください。

リリースノートはこちら

さて、Summer '11では、JavaScriptからApexコントローラを呼べるようになります。
ソースコードはこんな感じ↓

Apex

global class MyController {
  @RemoteAction
  global static String satHello(String helloTo) {
    return 'Hello ' + helloTo + '!';
  }
}

JavaScriptから呼ばれるメソッドはglobalで定義し、RemoteActionアノテーションを付けておきます。

JavaScript

functionはApexコントローラのメソッド実行後に呼ばれるコールバック関数、resultはApexコントローラのメソッドの戻り値となります。

SOQLインジェクションとXSSへの対策方法

○SOQLインジェクション

Salesforceでは、一般のWebサイトと同様に、SOQL内でバインド変数を使用することで、SOQLインジェクションの対策が可能です。

// :name がバインド変数
result = [Select Id From Contact Where Name Like :name];

動的にSOQLを記述する必要がある場合は、StringのescapeSingleQuotesメソッドで、シングルクォーテーションをエスケープして対策します。

// OK
String query = 'Select Id From Contact Where Name Like \'' + String.escapeSingleQuotes(name) + '\'';
result = Database.query(query);

// NG
String query = 'Select Id From Contact Where Name Like \'' + name + '\'';
result = Database.query(query);

○XSS

Salesforceでは、<apex>タグで記述した部分はXSS対策がされます。
<apex>タグのescape属性がデフォルトでtrueに設定されているため、自動的にHTMLエスケープされます。
※ escape属性をfalseに指定した場合は、XSS対策がされなくなります。

<apex>タグで記述していない部分のHTMLやJavaScriptについては、一般のWebサイトと同様の方法で、自分でXSS対策を行う必要があります。

＜参考＞
Developerforce 「Security Tips for Apex and Visualforce Developers」

beforeトリガとafterトリガの違いは？

beforeトリガとafterトリガの特徴をまとめてみました。

○beforeトリガ
レコードがDBに保存される前に起動されます。
レコードがDBに保存される前のため、Trigger.newを直接変更することができます
（before insert、before updateトリガ）。

○afterトリガ
レコードがDBに保存された後に起動されます。
但し、まだコミットはされていません（重要）。

DBに保存された後のため、
・Id
・自動採番
・作成者
・作成日時
・更新者
・更新日時
などのDBで設定された項目の値にアクセスできます。

DBに保存された後のため、Trigger.newを直接変更することはできませんが、
DML操作で元レコードの更新・削除を行うことができます
（after insert、after updateトリガ）。

○実行順序
beforeトリガ、afterトリガ、必須、入力規則のチェックは、
↓の順番で実行されます。

1. beforeトリガ
2. 必須、入力規則のチェック
3. afterトリガ

○使い分け

開発時には、
・入力規則のチェックより前に実施したい場合には、beforeトリガを使う
・DBで設定された値にアクセスしたい場合には、afterトリガを使う
など、両者の特徴を生かして、使い分けると良いと思います。

最後に、特徴をまとめた表を載せておきます。

	beforeトリガ	afterトリガ
起動タイミング	レコードがDBに保存される前	レコードがDBに保存された後
DBで設定する項目へのアクセス	不可	可
Trigger.newの項目の値の変更	可 ※1	不可 ※2
元レコードのDML操作（更新・削除）	不可 ※1	可 ※2
実行順序	必須、入力規則のチェックの前	必須、入力規則のチェックの後

※1 before insert、before updateの場合
※2 after insert、after updateの場合

パートナーポータル有効後のロールの指定方法

共有ルールや公開グループなどの作成時にロールを指定することができますが、パートナーポータルを有効化すると、選択できるロールのカテゴリが変化します。

有効化前

・ロール
・ロール ＆ 下位ロール

有効化後

・ポータルロール
・ポータルロール ＆ 下位ロール
・ロール
・ロール ＆ 内部下位ロール
・ロール、内部 ＆ ポータル下位ロール

「ポータルロール」「ポータルロール ＆ 下位ロール」はパートナーポータルのロールを、
「ロール」「ロール ＆ 内部下位ロール」「ロール、内部 ＆ ポータル下位ロール」は通常のロールを指定します。

「ロール ＆ 内部下位ロール」と「ロール、内部 ＆ ポータル下位ロール」が混同しやすいですが、前者はポータルロールを含まず、後者は含むという違いがあります。

例えば、以下のようなロール階層を設定しており、XYZ株式会社の取引先の所有者のロールが「パートナー管理部」である場合、

通常のロール階層

ABC株式会社
┗ CEO
　 ┗ パートナー管理部

パートナーポータルのロール階層

XYZ株式会社 パートナー エクゼクティブ
┗ XYZ株式会社 パートナー マネージャ
　 ┗ XYZ株式会社 パートナー ユーザ

「ロール ＆ 内部下位ロール ： CEO」は、「CEO」「パートナー管理部」が対象となります。

「ロール、内部 ＆ ポータル下位ロール ： CEO」は、「CEO」「パートナー管理部」「XYZ株式会社 パートナー エクゼクティブ」「XYZ株式会社 パートナー マネージャ」「XYZ株式会社 パートナー ユーザ」が対象となります。

パートナーポータルのロール階層

パートナーポータルでもロールを利用することが可能ですが、通常のロールとは仕様が異なります。

パートナーポータルでは、取引先毎に
・「＜取引先名＞ パートナー エクゼクティブ」
・「＜取引先名＞ パートナー マネージャ」
・「＜取引先名＞ パートナー ユーザ」
の3種類のロールが自動的に作成されます。

この3種類のロールは下記のロール階層で定義されており、このロール階層を変更することはできません（ロールの追加/削除はもちろん、名称変更もできません）。

少し不便ではありますが、このロール階層にパートナー内で表現したい階層構造を当て込んで、設計する必要があります。

チャネルマネージャ（パートナー取引先の所有者）のロール
┗ ＜取引先名＞ パートナー エクゼクティブ
┗ ＜取引先名＞ パートナー マネージャ
  ┗ ＜取引先名＞ パートナー ユーザ

「＜取引先名＞ パートナー エクゼクティブ」の上位ロールが、チャネルマネージャ（パートナー取引先の所有者）のロールであるため、チャネルマネージャは配下のパートナーのユーザが所有するレコードにアクセスすることができます。

チャネルマネージャが属するロールがバラバラだと、アクセス権限の管理が煩雑になるので、可能であれば、チャネルマネージャが属するロールは統一し、シンプルなロール階層とすることをお勧めします。

項目セット

Spring '11から「項目セット」という項目をグループ化する機能が利用可能になりました（ベータ版）。

Visualforceページから項目セットを呼び出すようにしておくと、項目セットの設定を変更するだけで、Visualforceページに表示する項目の種類や並び順を変更することができます。Visualforceページのコードを変更しなくて済むのがポイントです。

○項目セットの利用方法

各オブジェクトの設定画面で、「項目セット」の新規作成画面を開きます。

セットにしたい項目を、一番左の「＜オブジェクト名＞ オブジェクト項目」で選択して、一番右の「項目セットで（翻訳が微妙ですが。。。）」まで移動して、保存します。

項目セットを呼び出すVisualforceコードと画面イメージはこんな感じ↓
$ObjectType.＜オブジェクト名＞.FieldsSet.＜項目セット名＞ で、項目セットを呼び出せます。

  
    {!$ObjectType.Sokutei__c.Fields[f].label}
    ({!$ObjectType.Sokutei__c.Fields[f].type}):
    
  

public class SokuteiController {
    public Sokutei__c record {get; set;}

    private final Apexpages.Standardcontroller stdController;

    public SokuteiController(
               ApexPages.StandardController controller) {
        stdController = controller;
        
        record = 
            [Select 
                Shintyou__c, 
                Taijuu__c, 
                Kyoui__c, 
                Zakou__c 
            From 
                Sokutei__c 
            Limit 1];
    }
}

散布図

Spring '11から散布図がグラフで利用できるようになりました。

散布図を利用するには、レポートビルダーをアップグレードする必要があります。

レポートビルダーをアップグレードするには、[設定] → [カスタマイズ] → [レポート＆ダッシュボード] → [ユーザインタフェース設定]で、「レポートビルダーのアップグレード」セクションの「有効化」ボタンを押下します。

○レポートビルダーをアップグレードする際の注意点

・アップグレード後は元に戻せません

・アップグレード後は、全ユーザがレポートビルダーを利用する設定となります
※ アップグレード前は、プロファイルでレポートビルダー権限を与えられているユーザは「レポートビルダー」を、与えられていないユーザは「レポートウィザード」を利用する設定になっています。

・アップグレード後は、[設定] → [個人設定] → [私の個人情報] → [個人情報]で、「アクセシビリティモード」をONにすることで「レポートウィザード」を利用できますが、詳細のフロート表示などのユーザインタフェース機能が利用できなくなります。

レポート作成に、レポートウィザードを利用したい方が多い場合は、アップグレードしない方が良さそうです。

○散布図の利用法

レポートビルダーをアップグレードすると、グラフの選択画面の一番右に「散布図」が表示されるようになります。使い方は、他のグラフと同様のため、迷うことはないでしょう。

条件ベースの共有ルール

Spring '11がリリースされたので、条件ベースの共有ルールを早速使ってみました。

条件ベースの共有ルールを利用できるのは、
・取引先
・ケース
・取引先責任者
・商談
・カスタムオブジェクト
です。
利用できないオブジェクトもあるので、ご注意を。

[設定] → [セキュリティのコントロール] → [共有設定]で、共有ルールの新規作成画面を開くと、以前と比べて「ルールタイプの選択」というセクションが増えています。ここで「条件に基づく」を選択すると、↓のような画面となります。

試しに、取引先の評価が「Hot」だったら、営業部ロールに共有するという共有ルールを作ってみます。

早速、評価が「Hot」の取引先を作成すると、営業部ロールに共有されました。

評価を「Hot」以外にして保存すると、営業部ロールへの共有が外れました。

上記のように、共有ルールの条件を満たさなくなった場合は、共有を外してくれます。

SOQLのサブクエリの結果の取得方法

今回はSOQLのサブクエリの結果の取得方法をご紹介。

そんなの知ってるよ、という方が多いかもしれませんが、Web上にサンプルが少ないようなので紹介しておきます。

下記は、指定した取引先番号の取引先に紐付く取引先責任者情報を取得するサンプルApexコードです。

例のように、サブクエリの結果セットは、「.子リレーション名」で取得できます（ac.Contactsの部分）。

Account[] accounts = 
    [
    Select 
        AccountNumber,
         (Select LastName, FirstName From Contacts) 
    From 
        Account 
    Where 
        AccountNumber = '10001'
    ];

List＜Contact＞contactList = new List＜Contact＞();
for(Account ac : accounts) {
    for(Contact c : ac.Contacts) {
        Contact contact = new Contact();
        contact.LastName = c.LastName;
        contact.FirstName = c.FirstName;
        contactList.add(contact);
    }
}

Spring '11 新機能

Spring '11のリリースが迫ってきました。

日本のユーザが利用するAP0インスタンスでは、日本時間で2月13日(日) 午前3時～8時にリリースされます。例によって、インスタンスごとにリリース日時は違いますので、AP0インスタンス以外のリリース日時は、ここで確認してください。

リリースノートはこちら

というわけで、今日はガバナ制限の緩和以外で、Spring '11の気になった機能をご紹介。

条件ベースの共有ルール

共有ルールに、オブジェクトの項目値の条件を指定することが可能になります。
この機能によって、例えば、選択リストで「Hoge」が選択されたレコードのみ、「Foo」ロールに共有する、といったことが可能になります。

今までは、この手の要件はApexで開発するしかなかったので、嬉しい機能ですね。

Google Chromeサポート

Google Chromeが公式にサポートされます。

Visualforce関連

・Dynamic Binding
　↓のような、動的なバインディングが可能になります。

・インライン編集
　インライン編集が可能なフィールドを開発可能になります。

トランスレーションワークベンチ インポート/エクスポート

トランスレーションワークベンチで、インポート/エクスポートが可能になります
トランスレーションワークベンチは、動作が重かったので、これで快適に翻訳作業ができるようになります。

Scatter Chart

レポートで、新しいグラフ形式として、「散布図」が選択可能になります。

Chatter関連

・ダッシュボードがChatterに対応
　ダッシュボードにもChatter投稿できるようになります。
　また、ダッシュボードのスナップショットを投稿できるようになります。

・Chatterトリガ
　Chatter投稿時に起動するトリガを開発できるようになります。

電子メールアラートの制限導入

最後に残念なニュース。ワークフローや承認プロセスで送信する電子メールアラートは、これまで送信数の制限が設けられていませんでしたが、悪用を防ぐために、Spring '11から、1日の送信数に制限が設けられます。制限は↓の通り。

・1000通/ユーザ・日
・200万通/組織・日