Help us understand the problem. What is going on with this article?

Apex開発で押さえておきたいポイント

More than 3 years have passed since last update.

Salesforce App Cloud Advent Calendar 2015の18日目の記事ということでApex開発で押さえておきたいポイントについて投稿したいと思います。

はじめに

Apex開発ですがいくつか押さえておきたいポイントがあり、それを対応しておかないとデータ移行で動かないトリガができたり、バッチサイズ1じゃないとエラーになるバッチができたり、保守がしずらいクラスになったりします。

今回はそういったよくハマる落とし穴の回避方法について紹介したいと思います。

for loopとSOQLクエリ

まずはfor loopとSOQLクエリについてです。Apexでは一度の処理で実行できるクエリは100件までとなっています。そのため次のようにループ処理の中でクエリを実行しようとすると『Too many SOQL queries: 101』のエラーが発生してしまいます。

for(Integer i = 0; i < 101; i++) {
    Account acc = [SELECT Id,Name FROM Account
                      WHERE Id =: accIds[i] LIMIT 1];
    // 何か処理・・・
}

スクリーンショット 2015-12-17 23.49.38.png

この問題はループ内で1件ずつ取得しながら処理するのではなく、クエリで取得した結果をループ内で処理するようにすれば回避できます。

List<Account> accounts = [SELECT Id,Name FROM Account WHERE Id IN: accIds];
for (Account a : accounts) {
    // 何か処理・・・
}

INSERTやUPDATEなどのDML処理もループ内で1件ずつ実行するとガバナ制限のエラーに引っかかります。

for (Integer i = 0; i < 151; i++) {
    Account acc = new Account(
        Name = accName[i]
    );
    insert acc;
}

ApexのDML処理はList型にセットしてから実行することで一括実行できます。これを活用すればループ処理内でDML処理を実行しなくて済むようになります。

List<Account> accounts = new List<Account>();
for (Integer i = 0; i < 151; i++) {
    Account acc = new Account(
        Name = accName[i]
    );
    // Add List
    accounts.add(acc);
}

// ループの処理で一括実行
insert accounts;

ループ内でのクエリやDML処理はこのように一括で実行するようにしましょう。

ロールバックとID項目

ロールバック処理の注意点です。INSERTやUPDATEなどのDML処理で作成/更新/削除したレコードを処理の前まで戻してくれるロールバックですが、1つ注意点があります。

それはINSERT時にsObject変数のID項目にセットされた値がクリアされないことです。その結果、再度DML処理を実行しようとしたさいに存在しないIDに対して処理を行おうとしてエラーとなってしまいます。

これを回避するには登録用の変数を用意してcloneで値をセットしてから、そっちの変数で処理を行えば回避できると思います。

Account upsertAccount = this.objAccount.clone(true, false, true, true);
upsert upsertAccount;

詳しくはこちらにまとめてあります。

SFDC:ロールバックについて
http://tyoshikawa1106.hatenablog.com/entry/2013/03/20/231909

スケジュールバッチの開発

Apexバッチはスケジュールに登録して一定のタイミングで処理を行うことが可能です。このスケジュールバッチにも1つ注意点があります。

それはスケジュールに登録したApexバッチは編集できなくなるということです。
20150629201724.png

この問題は海外の開発者が調べて公開してくれたスケジュールバッチ開発のデザインパターンを導入することで回避できます。
20150629202518.png

メンテナンスするたびにスケジュールの登録を解除したり、元に戻したりするのは保守性が下がるのでぜひ導入しましょう。

詳細はこちらです。

SFDC:スケジュールバッチ開発のデザインパターン
http://tyoshikawa1106.hatenablog.com/entry/2015/06/29/202657

ApexTestとSystem.runAs

ApexテストではSystem.runAsを宣言することで実行ユーザを指定することができます。宣言しない場合はログインユーザの権限になるのですが、このSystem.runAsを宣言することで回避できるトラブルがあります。

それは『MIXED_DML_OPERATION』のエラーです。
20140423233603.png

発生してから対象のテストクラスにSystem.runAsを宣言していくのは大変なので最初から宣言しておくといいと思います。

詳しくはこちらです。

SFDC:How to Test - System.runAs と MIXED DML OPERATION
http://tyoshikawa1106.hatenablog.com/entry/2014/04/24/003139

HTTP Calloutsのテスト

Apexでは外部サービスのAPIを実行するときなどにHTTP Calloutsの処理を実装することがあります。コールアウト処理は通常テストクラスで実行できないようになっています。
20130908204018.png

そのため、テストクラスでのテストは諦めなければならないと考えてしまいたくなりますが、"implements HttpCalloutMock"を宣言したクラスを用意することでテストクラス内で擬似的なコールアウトを実行できるようになり、テストが可能になります。

Test.setMock(HttpCalloutMock.class, new MockHttpResponseGenerator());

詳しくはこちらです。

SFDC:HTTP Calloutsのテスト
http://tyoshikawa1106.hatenablog.com/entry/2013/09/08/213715

CSVファイルの取込テスト

ApexでCSVファイルを読み込み処理を実行するといったことがあると思います。テストクラスではCSV読み込みの操作をしたりできないので、テストできないように思えますが、静的リソースにアップロードしたものをSOQLで取得して対応することが可能です。
スクリーンショット 2015-12-18 7.55.43.png

静的リソースにテスト用のデータをアップしておくとどういったデータが必要かも確認しやすくなるのでおすすめです。

マスタ系データのテストデータ作成

テストクラス内でマスタ系のデータを作成していくのはとても大変です。場合によってはINSERTの実行制限に引っかかってしまう可能性もあります。

こういった問題を回避するためにApexにはTest.loadというメソッドが用意されています。Test.loadを使うとテストクラス内で静的リソースのファイルを読み込みテストデータを作成することができます。

List<sObject> accountsList = Test.loadData(Account.sObjectType, 'AccountsTest');

作成数の制限はありますが、テストクラス内でテストする分には十分なはずです。マスタ系のテストデータを作成する際にはぜひ利用しましょう。

詳しくはこちらです。

SFDC:Test MethodのTest.loadについて
http://tyoshikawa1106.hatenablog.com/entry/2013/07/04/222428

VisualforceとCSV読込み処理

VisualforceでCSVファイルを読み込んでデータ登録を行うというケースはよくあると思います。このとき処理件数が多くなると、処理に時間がかかり画面が固まってしまったように見えてしまいます。

特定の件数(400件ぐらい)を超えるような場合は普通にINSERTするのではなく、Apexバッチに切り替えてしまいましょう。
スクリーンショット 2015-12-18 8.05.34.png

System.debugの使い方

ApexにはSystem.debugで実行ログを出力できます。開発者コンソールのDebug Onlyを使えばそれ以外のログを非表示にもできます。
スクリーンショット 2015-12-18 8.06.22.png

このSystem.debugですが、使い終わったらなるべく削除するようにしましょう。Apexトリガなどでそのままにしておくと、デバッグが必要になった際に、その他の機能のログが一緒に出力されてで確認しづらくなります。

開発者コンソールにはブレークポイントを配置して値を確認する機能もついています。(ステップの一時停止はできませんが..)何か障害が発生したときはこちらの機能で対応できると思います。
20151128234251.png

ブレークポイントの詳細についてはこちらです。

SFDC:開発者コンソールとブレークポイント
http://tyoshikawa1106.hatenablog.com/entry/2015/11/28/234827

Apexトリガの無限ループ

よくApexトリガと項目自動更新が複雑に絡んで無限ループのような動きをしてしまうことがあります。どうしても回避できないようなケースもあるかもしれませんが、Updateトリガで1つ判定を追加するだけで、大抵回避できると思います。

それは新/旧の値の比較です。ApexトリガではTrigger.oldに更新前の値が格納されています。これをつかって新/旧の値の比較ができます。

例えば取引先番号に登録された値を別の項目にセットするような処理があるとします。Updateが実行されるたびに毎回この処理を実行すると状況によってはトリガが何度も実行されてしまいます。

次のように判定を行い、値が変更されたときのみ処理を行うようにすればこの問題を回避できると思います。

public Map<Id, List<Contact>> getAccountIdMap(List<Contact> contacts, Map<Id, Contact> contactOldMap) {
    Map<Id, List<Contact>> accountIdKeyMap = new Map<Id, List<Contact>>();
    for (Contact contact : contacts) {
        // 変更前の取引先ID
        if (contactOldMap.containsKey(contact.Id)) {
            Id oldAccountId = contactOldMap.get(contact.Id).AccountId;
            Contact oldContact = contactOldMap.get(contact.Id);
            // 取引先IDが変更されたか
            if (contact.AccountId != oldAccountId) {
                // [New Contact] accountIdKeyMapにセットするContactListを取得
                List<Contact> contactNewList = this.getContactListByAccountIdKeyMap(contact, accountIdKeyMap);
                // Add Map
                accountIdKeyMap.put(contact.AccountId, contactNewList);

                // [Old Contact] accountIdKeyMapにセットするContactListを取得
                List<Contact> contactOldList = this.getContactListByAccountIdKeyMap(oldContact, accountIdKeyMap);
                // Add Map
                accountIdKeyMap.put(oldAccountId, contactOldList);
            }
        }
    }

    return accountIdKeyMap;
}

詳しくはこちらです。
- ContactTrigger
- ContactTriggerHandler
- ContactTriggerHelper

Updateトリガのテスト

上記で紹介したようにトリガ内で新・旧の値の比較を行う処理を実装することがあると思います。以外と落とし穴なのがその処理のテストの方法です。

実際にUpdateを実行してテストを通す方法があると思いますが、ビジネスロジックの判定処理部分をテストする為だけに毎回Updateして他の処理を経由させるのは大変です。

そういった場合はcloneをつかって対応するのがおすすめです。ふたつ目の引数をfalseにすれば値のみコピーできるのでこれで新・旧の擬似的なテストデータを用意できると思います。

// テストデータ作成
Account account = CommonTester.createAccount(true);
Contact contact = CommonTester.createContact(account, true);

// 変更後取引先
Account accountOther = CommonTester.createAccount(true);

// パラメータ
List<Contact> contacts = new List<Contact>();
contacts.add(contact);

// OldMap
Contact oldContact = contact.clone(true, false, true, true);
oldContact.AccountId = accountOther.Id;
update oldContact;

Map<Id, Contact> contactOldMap = new Map<Id, Contact>();
contactOldMap.put(oldContact.Id, oldContact);

// 取引先判定
System.assertNotEquals(contact.AccountId, oldContact.AccountId);

これからApex開発を始めたい人向けに

Apex開発をどのように進めていくかイメージしやすいように動画をつくってみました。もしかすると参考になるかもしれません。
https://www.youtube.com/playlist?list=PLFSi-6JPTf9glvEZhBJNYouZPXfd4PVIi

動画内のサンプルコードはこちらです。
https://github.com/tyoshikawa1106/salesforce-live-coding

まとめ

Apex開発はいくつか落とし穴があってやりずらく感じることもあるかもしれませんが、上記のように押さえるべきポイントを押さえておけば大抵の問題は解決できると思います。

今回紹介したポイント以外にも落とし穴が見つかると思います。最後にそういった問題点をできるかぎりチームで把握できる方法を紹介したいと思います。

Chatterをつかった情報共有

情報の共有にはChatterが便利です。Chatterにはコードを挿入したりする機能はないので、詳細なコードレビューには向きませんが、こういったナレッジの共有では活躍してくれると思います。
スクリーンショット 2015-12-18 8.35.40.png

トピック

Chatterに投稿するときトピックを紐つけることが可能です。これで最近話題になっている情報を確認しやすくなります。
スクリーンショット 2015-12-18 8.39.19.png

トピックページではその分野に詳しい人を支持する機能もあります。スキル機能を活用することで社内で誰が知っていそうかを確認しやすくなります。
スクリーンショット 2015-12-18 8.42.22.png

質問機能

便利なのに以外と使われていないと思うのが質問機能です。Chatterでかなり便利な機能だと思います。
スクリーンショット 2015-12-18 8.50.12.png

質問機能には最良の回答を選択する機能があります。この機能により複数のコメントがついた場合でも回答部分を強調表示して確認しやすくできます。
スクリーンショット 2015-12-18 8.51.11.png

ファイルやリンクの共有

Chatterにはファイルをアップロードしたりリンクを共有したりする機能もついています。
スクリーンショット 2015-12-18 8.45.29.png

これらを活用することでより解決方法がまとめられたブログやGitHubのサンプルコードなどをよりわかりやすく共有できます。

Chatterグループ

Chatterにはグループ機能も付いています。これを活用することで特定の情報のみをまとめることができます。リストに記載しないグループ機能を使えば関係の無い人には見えないグループも作成できます。
スクリーンショット 2015-12-18 8.47.42.png

Chatterフィードの検索

Chatterといえばせっかく投稿しても流れていってしまうイメージがありますが、そんなときはフィードの検索機能が以外と活躍してくれます。
スクリーンショット 2015-12-18 8.53.21.png

Chatterには他にもブックマーク機能があったりもするので検索、トピック管理と一緒に活用していけばナレッジ管理として活躍してくれる機能です。ひとつひとつの投稿はそれほど大きな価値はないかもしれませんが、こういった社内ナレッジを溜めていくことで、自分がハマった落とし穴や失敗を他のメンバーに共有していくことができると思います。

以上、Apex開発で押さえておきたいポイントについてでした。

追記

Apex開発と多言語化対応についてまとめた『Apex開発で押さえておきたいポイント - その2』を書きました。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした