ApexCode Fundamentals ということで、ApexCodeの基礎的なセッションですが、きっと本場アメリカだから、知らない事も聞けるかなぁ~と期待していました。
結論から言うと、技術的には他のセッションも含めて概ね知っていることがほとんどでした。
ですが、改めて force.com を取り巻く技術要素が、整理されて確認できたのは良かったです。
さて、ApexCode Fundamentals で説明されていた内容をざっと紹介します。
ガバナ制限って?
クエリやデータ更新では、ガバナ制限と呼ばれる制限事項があります。
具体的には、Apexコード内でクエリを発行した時に処理可能な件数の制限やトリガーから呼び出し可能なクエリの回数制限とかがあります。
この制限ですが、force.com がマルチテナントなプラットフォームであるが故に、多くのユーザが好き勝手なコードを書いて、とんでもなくリソースを消費したりして、全体に悪影響を及ぼさないための策と想像できますが、コードの書き方によっては簡単にこの制限に引っかかってしまいます。
なので、この制限の具体的な数値はしっかり抑えておいた方が良いでしょう。
(気を付けないと、データ量の少ないSandBoxで問題なかったのに、本番に配備したらエラーが出る!なんて事になってしまいます。)
この制約、今後の強化で緩和されるようです。(どの程度かは判りませんが。)
期待しています!!
Apexコードってどういう時に使うの?
Trigger
→ データの更新(追加・修正・削除)の前後で独自のビジネスロジックを動かしたい
OracleとかSQLServerに備わる、Database Trigger と同じ概念ですね。
Email Services
→ メールの送信、または受信で独自のビジネスロジックを動かしたい
Plain/HTML形式どちらもの形式にも対応。
ApexWebServices
→ 独自のビジネスロジックを外部から呼び出したい
WSDLも作られます。(WSDLがつ)
これは、OracleやSQLServerに備わる、Stored Procedure をイメージするとわかり易いかも知れません。
Visualfoceのコントローラーからの利用として
→ Visualfoceのコントローラーから利用するビジネスロジック(クラス&メソッド)を用意する
ガバナ制限の数値メモ(Winter'09) ・・・ 良く制限に引っ掛かりそうなものの抜粋です。
実行される SOQL クエリの総数
- トリガー:20
- 匿名ブロックまたはWSDLメソッド:100
- RunTest:100
SOQL クエリで取得されるレコードの総数
- トリガー:1000
- 匿名ブロックまたはWSDLメソッド:10000
- RunTest:500
実行される DML ステートメント(insert、update、upsert、merge、delete)の総数
- トリガー:20
- 匿名ブロックまたはWSDLメソッド:100
- RunTest:20
DML ステートメントの結果として処理されるレコードの総数
- トリガー:100
- 匿名ブロックまたはWSDLメソッド:10000
- RunTest:100
コメントする