エンジニアの若葉です。10撰」という題目でネタを持ち寄ったので、とりあえず3つ程ご紹介しますね。標準ボタンによる画面リロードまず、標準のリストビューにビューの選択状態を保ったままリロードする方法をご紹介します。ような状態が遷移するオブジェクトがある場合、1各ステータスに応じたリストビューを設定してステータスごとにデータを管理する2一括で状態を更新するApexを書いて、リストビューにカスタムボタンを配置3カスタムボタンを実行したら、更新ボタンでリフレッシュして、現在のビューから当該のデータを追い出すなんてケースが良くあるかと思います。更新ボタンを押し忘れて、処理済みのデータを対象に再度更新処理を実行してしまう恐れが残ります。}}現在のビューを保ったままリロードができます。事故の防止、操作の簡易化が図れてとても便利ですね。Sitesで強制SSL次ですが、Sitesで公開WEBフォームを作る際、住所情報などを登録するのでSSLアクセスが必須となるケースが良くあります。設定によってSSLアクセスを強制できる助かるのですが、残念ながらその設定は無いようです。毎回リファレンスを見直しているので、この際整理してみました。使用するAPIプロトコルの確認URL.getProtcol()現在のセキュアなドメインの取得Site.getBaseSecureUrl()現在のPathの取得URL.getPath()Sitesのドメインはsand/prod間でドメインが異なるので、環境差分を吸収するのに一工夫必要です。このAPIを知るまでは、この環境違いへ対応するのにカスタム表示ラベルに切り出すなど、悲しい対応をしていました。Pathの取得はちょっと注意が必要で、取得できるPathは実際のURL中に現れない「/apex」が含まれてしまうので、リダイレクトさせるには、これを除外する必要あります。こんな感じで、現在のURLを取り扱うクラスを定義しておくと、コントローラからシンプルに呼び出せて、使いまわしが簡単になります。許可されていませんこの例外が原因となっているケースがたまにあります。}}これは、例えば上記のサンプルでいうと、User(1)とAccount(2)は、同一トランザクションでInsert/Updateできない、というような制限です。詳細は以下のリンクから確認できますが、制限の理由は、UserもAccountも、アクセスする側とされる側、としてレコードの共有情報を更新する必要があり、それは各々のDMLを直列に確定させないと正しく処理できない可能性があるためのようです。http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_dml_non_mix_sobjects.htm上記のサンプルのように、プロダクトコードのみでは該当しないけど、テストデータとしてUserを事前にInsertすることは多いので、この制限はテストコードでよく遭遇します。制限だから仕方いないかと思いきや、そこはちゃんとテストコード用に回避策が用意されています。ブロックで囲ってあげれば、それだけでOKです。アクセス制御に関するテストはどうなるんだろ?とか追加の調査の余地はありますが、とりあえずは回避策があるので良しとしておきます。(火)Apex一括メール送信の制限お久しぶりです、こころです。”アドレス重複を含んで1日1000通まで”というガバナ制限があります。1日で閾値ギリギリまでメール配信されそうな要件があり、閾値を超えるとどうなるのか試してみました。1回に75通Apexからメールを送るとして、13回送信すると975通になります。日の一括メール制限にカウントされます。エラーコードを受信します。あり、MASS_MAIL_LIMIT_EXCEEDEDの解釈が問題となりそうです。DeveloperEdition(配信制限数は10通/日)でテストしてみました。</apex:form></apex:page>ボタンを1回押すと3通の一括送信メールが送られます。DeveloperEdition組織の一括メール送信制限は10通です。3回ボタン押下で9通配信されますが、4回目で何が起こるでしょう。※一括メール送信はログインユーザで実行されます。[]のエラーになりました。[]4回目の一括配信メールは失敗して送信されませんでした。(もちろん最初の9通は届きましたが、それ以降は1通も届いていません。メールログをリクエストして確認すると、やはり9通です。いうわけで予想通り1でした。オブジェクトで返されるすべてのエラーは、メールが送信されなかったことを表します。文字をApexレファレンス中(P294)に見つけてしまって、検証するまでもなく1な気が限りなくしていたのですが、念のため確認してみました。Sandboxで1000通の制限に対してのテストをしてみましたが、同様に一括メール件数が閾値を超えるリクエストの場合は配信はされません^^Apexからの一括メール配信を設計する上で参考にしてみてください。同じロールに属するユーザが所有するレコードは参照できません。(営業部ロールにAさんとBさんが属していた場合、Aさんが所有するレコードをBさんは参照できない)一方で、「同じロールに属するユーザが所有するレコードは参照できるようにしたい(営業部の誰かが所有するレコードは、営業部全員で参照できるようにしたい)」という要望を頂くことは結構多いような気がします。この要望は、↓の共有ルールを作成すれば実現できます。この方法だと、このルールを適用するロールの数だけ共有ルールを作成しなければなりません。ロールの追加や変更の度に、共有ルールを追加・変更しなければなりません。下記で紹介する方法で、トリガからApex共有を使って、自動的に対応するロールにレコードを共有すると良いでしょう。理由表示ラベルと理由名を設定(どちらも任意の名称でOK)して、Apex共有の理由を作成します。理由名:OwnerRoleSharingReasonと設定します。トリガ作成オブジェクトに所有者のロールへレコードを共有するトリガを作成します。ここでは、Item__cというカスタムオブジェクトに作成する場合のソースコードを記載します。}}トリガ作成後に、レコードを追加・更新すると、所有者のロールにレコードが共有されるようになります。レコードの詳細画面で「共有」を押下すると、↓のように、所有者のロールへ共有されていることが分かります。(火)beforeトリガとafterトリガの違いは?beforeトリガとafterトリガの特徴をまとめてみました。○beforeトリガレコードがDBに保存される前に起動されます。updateトリガ)。○afterトリガレコードがDBに保存された後に起動されます。コミットはされていません(重要)。DBで設定された項目の値にアクセスできます。updateトリガ)。↓の順番で実行されます。・入力規則のチェックより前に実施したい場合には、beforeトリガを使う・DBで設定された値にアクセスしたい場合には、afterトリガを使うなど、両者の特徴を生かして、使い分けると良いと思います。最後に、特徴をまとめた表を載せておきます。sharingキーワードApexはデフォルトでシステムモードで動作するので、全オブジェクトに対して全レコードの編集が可能です。そのため、例えば、ユーザがVisualforceページでレコードを検索する場合、ユーザが参照権限を持たないレコードについても、検索できてしまいます。sharingキーワードを付与します。これによって、ユーザに適用されているレコードレベルの共有ルールを強制実行することができます(ユーザモードでの動作)。sharingキーワードを付与しても、オブジェクトのCRUD権限、項目のアクセス権限は、システムモードのままということです。ユーザがアクセスできないはずのオブジェクトや項目にアクセスできてしまいます。オブジェクトのCRUD権限、項目のアクセス権限は、Apexでは制御できないので、開発者が、ユーザから隠されているデータを公開しないように注意してApexコードを書く必要があります。sharingキーワードを付与します。sharingキーワードも付与しない場合は、呼び出し元のApexクラスの設定が有効となります。sharingキーワードが付与されたApexクラスから、キーワードなしのApexクラスを呼び出した場合、ユーザに適用されている共有ルールが強制実行されます。呼び出し位置が最上位レベルの場合(最初に呼ばれるApexクラスの場合)は、システムモードでの動作となります。動作モードを表にまとめるとこうなります。sharingキーワード付きのApexクラスを呼び出すことで、ユーザモードでの動作となります。匿名ブロックは、ユーザモードでの動作となります。前回、ApexのDMLステートメントと失敗時の挙動の説明で、ロールバックの話が出たので、今回はApexのトランザクション制御の特性を紹介します。トランザクションの開始Apexスクリプトの開始と同時にトランザクションが開始されます。明示的にトランザクションを開始することはできないので、注意が必要です。コミットApexスクリプトが正常終了すると、コミットされます。これも明示的にコミットすることはできないので、注意が必要です。セーブポイントDatabase.setSavePoint()をコールして、セーブポイントを設定できます。ロールバックApexスクリプトが異常終了すると、ロールバックされます。明示的にロールバックするには、Database.rollback(savepoint)をコールします(セーブポイントへのロールバックしかできません)。以上のように、明示的に制御できるのは、セーブポイントの設定とロールバックだけで、他はApexが正常終了したか異常終了したかによって、自動的に行われます。きめ細かく制御できないので、この特性を理解した上でプログラムを組む必要があります。最後に、トランザクション中での行ロックの取得方法と、Force.comプラットフォームでのトランザクションの分離レベルについて、紹介しておきます。Update」キーワードを付けて、行ロックを取得することができます。行ロックはトランザクションがコミットまたはロールバックされるまで持続されます。COMMITTED)で、変更することはできません。更新したがまだコミットされていないデータは、他のトランザクションからは読み取られません。あるトランザクションが更新中のレコードを他のトランザクションが読み取ろうとしたときは、更新中トランザクションが終了するまで一定時間待ちます。一定時間を過ぎた場合は待っている方のトランザクションが失敗します。・HerokuやAWSなどのクラウドプラットフォーム上でのWebアプリケーション開発エンジニア、マネージャーを募集中です。・認定デベロッパーが在籍している、セールスフォースパートナーです。partnersにも登録されています。Salesforce/Force.com導入支援サービス弊社の認定プロフェッショナルが支援致します。・Salesforceと連携するWebアプリ開発も承っております。セールスフォースご検討の際は、お気軽にお問合せください。参加レポートSalesforceはじめました。その4Salesforceはじめました。その3Salesforceはじめました。その2Salesforceはじめました。sharingキーワード)。