スーパーバッジ攻略 Advanced Apex Specialist 日本語訳

認定上級取得のためのスーパーバッジ取得最後の砦となる
Advanced Apex Specialistです。

まだ、Advanced Apex Specialistの日本語訳が見当たらなかったので、こちらは自力で翻訳しています。
例によってGoogle先生の手助けがメインです。
以下、トレイルヘッドAdvanced Apex Specialistの翻訳です。
太字はラベル名やクラス名などであえて翻訳していない部分です。

長いので何個かに分けようかとも思ったんですが、やっぱり問題文は1つにした方が見やすいと思うので、1つに纏めます。
長文になりますがご了承ください。

このスーパーバッジを稼ぐためにするべきこと

1. Apexコードのデバッグとトラブルシューティング
2. 大規模データセットに対応するApexコードを開発する
3. Visualforceを使用してカスタムインターフェースを開発する
4. コードの品質を保証するテスト戦略を設計する

このスーパーバッジでテストするコンセプト

• Apexコードのカスタムメタデータ
• Apex共有
• Apexトランザクション実行
• SOQLクエリの集計
• 複雑なSOQLクエリ
• ConnectAPIネームスペース
• Visualforceの開発
• VisualforceのApexクラスとのデータバインディング
• Visualforceのパフォーマンス最適化
• コードのリファクタリングと再利用性
• 定数とラベルの使い方
• ApexとVisualforceのテスト
• Apexのトラブルシューティング

所要時間：12時間 – 16時間

Apex+Visualforceの総合的な復習となります。
連携やLightning周りがない分、個人的にはまだやりやすいと思います。

前処理と注意

• Salesforceには、Lightning ExperienceとSalesforce Classicの2つの異なるデスクトップユーザインターフェースがあります。このモジュールはSalesforce Classic用に設計されています。ここTrailheadのLightning Experienceの基本モジュールで、インターフェイス間の切り替え、Lightning Experienceの有効化などについて学ぶことができます。
• 要件を読みながらメモを書き留めたいと思うでしょう（写真の記憶がない限り）。だから今ペンと紙（または電子代替）を用意します。
• このSuperbadge用に新しいTrailhead Playgroundを作成してください。既存の組織を使用している場合は、課題の検証に問題がある可能性があります。
• このunmanaged Superbadge packageをインストールしてください。このパッケージには、課題を解決するために必要なスキーマとコードが含まれています。 AppExchangeから管理パッケージまたは未管理パッケージまたはアプリをインストールできない場合は、Trailhead Playground Managementモジュールの手順に従ってください。
• Product and Schedule Objects ERDの準備をしてください。
• 次の値のみを持つようにProduct2オブジェクトのProduct Familyフィールドを更新します。Entree, Side, Dessert, Beverage
• Productページのレイアウトを更新して、Initial Inventory, Quantity Ordered, Quantity Remainingの各フィールドを追加します。
• Accountページのレイアウトを更新して、Orders関連リストを表示します。
• OrderページレイアウトからContract Numberフィールドが現在ある場合は削除します。
• 名前や署名を変更せずに、アンマネージパッケージで提供されているメソッドを使用してください。

使用事例

Renee LaFleurが料理学校に通っていたとき、彼女は屋外ポップアップ席を備えた彼のグルメフードトラックで有名な、世界で最も尊敬されているシェフの一人にインタビューしました。卒業後、この経験はレニーに自分のフードトラック事業を始めるよう促しました。ニューミレニアムフードトラック – 大きな味を出す小さなフードオペレーションです。

数年間の努力と長い時間をかけて、Reneeは1台から5台のフードトラックに事業を拡大しました。この成功は彼女が情熱のプロジェクトを追求するために資金を調達することを可能にしました：「前払い」モデルのビジネス。開始するのが大変だったことを思い出して、彼女は新しいシェフに彼らの顧客基盤を確立するより簡単な方法を提供するために彼女の新しいビジネスを使いたいと思います。

レニーは、新しいミレニアム・デリバリーを創設して、新人や新進のシェフが自分たちのために自分たちの名前を付けることができるようにしました。見返りに、顧客は電話で食事を注文できます。その後、新しいMillennium Deliveryの担当者が注文を配信し、幸せな顧客の写真を撮ります。その写真は、ソーシャルメディア投稿のためにシェフに提供されます。

ApexやVisualforceなどのSalesforceのプラットフォームは、New Millennium Deliveryのビジネスを推進するテクノロジです。以前、Reneeは自分のSalesforceアプリケーションの構築を手伝うために開発者を雇いました。今、あなたは前の開発者が中断したところから拾い上げている幸運な開発者です。

レニー氏は、地元のフード＆ワインフェスティバルでデビューできるようにするために、前の開発者がほんの数週間でアプリケーションの初期バージョンを作成することを要求しました。レニーは、開発者がこのような厳しいスケジュールに陥ると、「速い」の「良い」を失うことを知っていました。これらのベストプラクティスを無視すると、残りの開発プロセスにも影響がありました。レニーはこれを修正してほしいと願います。

現在のアプリケーションのレガシコードを確認して理解してから、プログラミングとアプリケーション設計のベストプラクティスを使用してコードの修正と新しい機能を実装するように依頼しました。

標準オブジェクト

New Millennium Deliveryは、次のような標準のSalesforceオブジェクトにデータを保存します。

• Accounts – 食品を注文する新しいMillennium Deliveryのお客様
• Products – 購入可能なさまざまな食事項目
• Pricebook – 食事項目の価格
• Orders – 配達する食事の注文
• Order Items – 顧客の注文に含まれる商品

製品に関連する標準オブジェクトのデータモデルに慣れていない場合は、ここで確認してください。

New Millennium Deliveryのビジネスロジックでは、新しいカスタムフィールド、リレーションシップ、またはカスタムオブジェクトは必要ありません。

ビジネス要件

予備試験データ

チャレンジ1を完了したら、Trailheadのプレイグラウンドで作成される次の新しいMillenium Delivery Productsを確認してください。

定数を使用してデータを格納する

Dreamforceでは、値を時間の経過とともに変化させることができますが、その目的は一定のままであるデータを格納するために定数を使用することをお勧めします。 あなたは定数を作成することによってこのベストプラクティスを実装したいです。これらの定数のいくつかはカスタムラベルを利用します。

念のため、以下の有効値のみを持つように製品ファミリ選択リストを変更しておく必要があります。

Entree, Side, Dessert, Beverage

次の属性を持つ2つのカスタムラベルを作成します。

注：最初にラベルを作成するときに間違えた場合は、ラベルを削除して最初から作成し直すことをお勧めします。

次の定数を定義して、Constantsという名前のApexクラスを作成します。

カスタムメタデータ型を使用する

在庫管理者は、在庫が少なくなってきたことを知りたいとReneeに言いました。 たとえば、在庫に残っているデザートの種類が15種類しかない場合は、警告を表示します。つまり、特定の商品の在庫レベルが、その商品に関連付けられている商品ファミリのしきい値まで低下すると、通知が必要になります。

過去数ヶ月間の注文データの分析に基づいて、Reneeは各製品ファミリの在庫しきい値を決定しました。 彼女は各製品ファミリの在庫しきい値を保存したいのですが、売上が伸び続けるにつれてこれらのしきい値を簡単に変更したいと考えています。 慎重に検討した後、カスタムメタデータ型がこれらの要件を満たすための請求書に適していると判断しました。

以下の属性を使用してカスタムメタデータ型を作成します。

次に、新しいメタデータ型に新しいフィールドを作成します。

Manage Inventory Settingsをクリックして、次のカスタムメタデータレコードを作成します。

在庫数量を正しく計算する

営業担当者のSamに話しかけることから、Reneeは新しい顧客注文を入力する際に​​問題があることを知りました。サムは次の問題を述べた。

1）Quantity Orderedフィールドの値が正確ではありません
2）システムエラーのため、新しい注文を保存することが不可能な場合が多い
3）ドラフト注文（処理中であるがまだアクティブになっていない注文）は、使用可能在庫を時期尚早に減少させます。

Samが提起した問題を調査した後、あなたはこれらの問題を解決することについてのメモをしました：

• Quantity Orderedフィールドの値を導き出すためのビジネスロジックは、誤っているだけでなく、非効率的です。システムは、リーンコードを使用して効率的に計算を行い、正しく注文された数量を集計します。
• Samは、ドラフト注文が時期尚早に在庫レベルを減少させることを正しく識別しました。あなたは前の開発者がこれを直そうとしたが、それから決して終わらなかったことを見ることができます。今度は、正常にアクティブ化されたオーダーのみが在庫レベルに影響を与えるようにビジネスロジックを修正する必要があります。
• Quantity Orderedフィールドの値を決定するためのロジックは、単一の営業担当者に表示される注文だけでなく、システム内にあるすべての有効化された注文を考慮に入れるように更新する必要があります。
• OrderTriggerは、Apex Triggerのベストプラクティスに従うように更新する必要があります。これにより、ビジネスロジックがモジュール式で再利用可能になります。さらに、トリガー定義には必要なトリガーイベントのみをリストする必要があります。

** FYI **通常、このロジックはUpdate、Delete、Undeleteに適用され、ステータスの変更をDraftに戻しますが、時間の都合上、繰り返しのタスクを実行しないようにするため、Updateにのみ焦点を当てます。

商品と価格表のエントリを追加できるVisualforceページを修正する

Reneeの以前のプログラマーは、Product2New Visualforceページを作成しました。このページの目的は、在庫管理者が一度に複数の新製品と関連するPricebookEntryレコードを迅速に入力できるようにすることです。ただし、在庫管理者は、このページではデータ入力が遅くなり、必要な情報や必要な情報がすべて提供されていないというフィードバックを寄せています。

これを解決するには、Productオブジェクトの標準のAddボタンとNewボタンを、更新されたProduct2Newバージョンで上書きする必要があります。

更新されたページでは、在庫管理者が一度に複数の商品を作成し、各商品に関連付けられた単価を入力できるようになります。次に、在庫管理者がSaveボタンをクリックすると、入力された各製品について、標準価格表に関連するPriceBookEntryが作成されます。すべてのフィールドが入力されているページのエントリのみを保存する必要があります。他のエントリは保存しないでください。保存中にエラーが発生した場合は、セーブポイントをロールバックし、わかりやすいエラーメッセージを画面に表示する必要があります。在庫管理者は必要なだけ商品を入力でき、ページのAddボタンをクリックするたびに複数の行をテーブルに追加できるはずです。

将来ビジネス要件が変化したときに、ReneeはProduct2NewページやProduct2Extensionクラスを変更したくはありません。このニーズを満たすために：

• 各列ヘッダーに現在のフィールドラベルが表示されるようにVisualforceページを更新します。
• AddRowsメソッドがDEFAULT_ROWS定数を使用するようにApexクラスを更新します。
• ページ上のFamily選択リストで使用するためのGetFamilyOptionsという名前の新しいメソッドを作成します。 GetFamilyOptionsメソッドは、選択リストオプションを生成するためにSELECT_ONEとPRODUCT_FAMILYの両方の定数を使用する必要があります。

ProductレコードとPriceBookEntryレコードを互いに関連付ける必要があるため、ProductWrapperという名前の内部クラスを次の属性で実装して使用します。

• Product2型のproductRecord
• PriceBookEntry型のpricebookEntryRecord

Productsのリストへの現在の参照がProductWrapperのリストへの参照に置き換えられていることを確認します。

在庫管理者は、New Millennium Deliveryの製品の需要と供給のバランスを取ろうとします。彼らは、横棒グラフをVisualforceページに追加するよう要求しました。彼らはチャートに彼らにそれぞれの製品ファミリーの残りの量を示すことを望みます。マネージャがAddをクリックすると、チャートはうまくレンダリングされるはずです。

このチャートデータは他の目的にも役立つので、ChartHelperという名前の独自のApexクラスから生成されます。 ChartHelperを更新して、内部のコードが常にシステムとして実行されるようにします。 ChartHelperのGetInventoryメソッドを完成させて、正の残量を持つアクティブ商品の集計を正しく計算し、結果がすべてのユーザーに対して正しいことを確認します。 Reneeは、このメソッドもLightningコンポーネントで使用できるようにしたいと考えています。

テストデータファクトリを生成する

調査の結果、前のプログラマがTestDataFactoryクラスを使用して、ユニットテスト用のテストデータをモジュール式かつ効率的に生成することを決定したと判断しました。 しかし、クラスはまだ完成していないことにも気付くでしょう。メソッド名はありますが、実際のロジックはありません。 TestDataFactoryクラスを完成させて、アプリケーションの単体テストに適用できるサンプルビジネスデータをモデル化する効率的な方法を提供します。 各メソッドがテストクラスのユーティリティメソッドとして使用できること、およびそれらがインスタンスメンバ変数の値に依存しないことを確認してください。

** FYI **通常、TestDataFactoryクラスで@isTestアノテーションを使用しますが、ビジネスロジックからメソッドを呼び出すことはできず、それらが正しく機能するようにメソッドを呼び出すこともできません。

orderTriggerのロジックを検証する

まず、注文が有効化されたときに数量注文フィールドが商品で正しく更新されることを確認するためのテストメソッドで使用できるメソッドを作成します。 TestDataFactory Apexクラスに戻り、次のシグネチャを使用して新しいメソッドを作成します。

VerifyQuantityOrdered(Product2 originalProduct, Product2 updatedProduct, Integer qtyOrdered)

このメソッドは、updatedProductのQuantity_Ordered__cフィールドがoriginalProductのQuantity_Ordered__cフィールドとqtyOrderedの値の合計に等しいことを検証するアサーションを実行する必要があります。

次に、orderTestsクラスに戻り、そのテストメソッドが実際のデータを使用していない（そして使用できない）ことを確認します。 OrderTestsのすべての単体テストのテストデータを生成するために使用されるSetupTestDataという名前の新しいメソッドを作成します。このメソッドはTestDataFactoryクラスのInsertTestDataメソッドを呼び出すだけです。

最後に、OrderTestsにOrderUpdate_UnitTestという新しいテストメソッドを作成します。このメソッドは、ACTIVATED_ORDER_STATUS定数を使用してSetupTestDataメソッドで作成されたOrdersをアクティブにしてから、VerifyQuantityOrderedメソッドを使用してProductsのQuantity Orderedフィールドがトリガーによって増加したことを確認する必要があります。

** FYI ** VerifyQuantityOrderedのような方法は、すべての単体テストにわたって一貫してロジックがテストされるようにするのに役立ちます。また、あなたがこのチャレンジを適切に完了したと私たちが判断するのをずっと簡単にします！コードベースが大きくなるにつれて、これらのタイプのメソッドをもっと作成することができます。もしそうなら、あなたはそれらをTestDataFactoryとは異なるクラスに移動したいでしょう。

製品のロジックを検証する2新しいページ

Product2TestsでProduct2Extension_UnitTestを完成させます。この単体テストでは、ユーザーがProduct2Newページにアクセスして対話するのをシミュレートし、予想通りに動作することをテストする必要があります。ユーザーが最初にそのページにアクセスすると、画面に複数の行が表示されます。 productsToInsertリストのサイズがDEFAULT_ROWS定数と等しいことをアサートします。 Addボタンをクリックすると、追加の行のセットを追加する必要があるため、ボタンを1回クリックした後でproductsToInsert **リストのサイズが2倍になることをアサートします。テスト方法が実際のデータを使用しない（使用できない）ことを確認することを忘れないでください。

次に、保存ボタンをテストします。移入された行が保存され、移入されていない行が保存されていないことを確認します。 productsToInsertリストの行をループして最初の5レコードの値を入力し、Saveボタンをクリックしてシミュレートします。 5つの商品だけが保存されたと主張してボタンが機能したことを確認します。

テストが失敗することなく合格するように、テストが完了したら必ずテストを実行してください。

在庫が少ないときに内部告知を自動化する

New Millennium Deliveryのスタッフは、在庫が不足している在庫を把握しておく必要があります。前の開発者はこれを失敗しました。 Reneeは、前の開発者のロジックの問題を修正し、特定の製品をフォローしている従業員だけでなく、適切なすべての従業員に通知することを選択できるようにしたいと考えています。

Chatterグループは、従業員がこれらの通知を受け取ることをオプトインするための簡単な方法であると判断しました。 Inventory Announcementsという名前のChatterグループを作成し、このグループに次の説明を入力します。このグループは、New Millennium Deliveryの従業員が在庫アナウンスを受け取るためのものです。自動的にアーカイブされず、すべてのユーザーがアクセスできるようにするために、必ずグループを作成してください。

ConnectAPIについて読んだ後、Chatter AnnouncementはFeedItem投稿よりも適していることがわかります。これは、お知らせはタイムリーで期限切れになるという点で、アラートのように動作するためです。インベントリの値が低いと、発表がInventory Announcements Chatterグループに投稿されるように促すため、Apexトリガを使用する必要があります。レガシーコードを確認した後、前のプログラマがこのビジネスロジックをProduct2Triggerに書き込もうとしたことに気付きましたが、そのロジックには問題があります。

投稿はDML操作としてカウントされるため、大量のアナウンスを投稿する必要がある場合を含め、一括操作によってすべてのアナウンスが投稿されるようにするには、Queueableインターフェイスを実装する必要があります。前任者がSalesforce開発者フォーラムでコードを見つけ、従来のAnnouncementQueueable Apexクラスを作成しました。このクラスを使って始めましょう。 AnnouncementQueueableおよびProduct2Helperクラスは、製品レベルが指定されたしきい値を下回ったときに自動的にChatter Announcementを投稿するためにConnectAPI名前空間を使用する必要があります。

Queueableインターフェースを実装するようにAnnouncementQueueableを変更し、そのpostAnnouncementsメソッドを呼び出します。制限を超えて投稿する発表がある場合は、必ず自分自身を再度キューに入れます。

product2Helperクラスの既存のコードを確認した後、それも定数クラスの恩恵を受けられることがわかります。アプリ内の一貫性を確保するために、 “グループ名”の代わりにINVENTORY_ANNOUNCEMENTS定数を使用するようにProduct2Helperを変更します。

Chatterグループ用にAnnouncementQueuable Apexクラスで使用するための新しいAnnouncementInputsを構築するには、Product2HelperのPostAlertsメソッドを完成させます。

次に、ProductのQuantity_Remaining__cフィールドが、以前に作成したカスタムメタデータレコードに記録されているしきい値を下回ったと判断したときにPostAlertsメソッドを使用するように、AfterUpdateメソッドを完成させます。

ベストプラクティスでは、ビジネスロジックコードを再利用可能にし、テストを容易にし、デバッグを容易にするために、Apexクラスに格納する必要があります。更新後のイベントでのみ実行されるようにProduct2Triggerを変更し、Product2Helperのロジックを呼び出します。

** FYI **多くの開発者（私たちを含む）はテスト駆動開発を使用することを好み、最初にテストから始めます。現実の世界ではうまく機能しますが、プログラムによる評価はそれほど簡単ではありません。したがって、これらの課題を示された順序で実行することに固執してください。

迅速な注文入力を可能にするためのVisualforceページのコントローラ拡張の完成

New Millennium Deliveryの顧客はいくつかの食品が大好きで、製品はすぐに売り切れます。 個別の顧客メニューを利用できるように、各顧客が最も注文した食品を在庫管理者が簡単に判断できるようにするのがあなたの仕事です。

New Millennium Deliveryで注文を受けた従業員には、注文と注文商品を保存するための合理化されたプロセスを提供するページが必要です。 前の開発者はこれを容易にするためにVisualforceページOrderEditを作成しましたが、そのコントローラ拡張を完成させることができませんでした。

※画像はトレイルヘッド のページから引用してきました

図1.1：OrderEditのVisualforceページ

在庫管理者が注文を作成または編集するときにこのページが使用されるようにする必要があります。 OrderExtensionクラスを完成させて、ページに注文の詳細、注文商品と注文金額を要約した円グラフ、およびアクティブな商品のリストを表示できるようにします。

円グラフには、注文内の各アイテムのウェッジが表示されます。ウェッジの値は、数量に単価を掛けた値に等しくなります。 OnFieldChangeメソッドを完了して、QuantityフィールドまたはUnit Priceフィールドの値に対する変更を追跡します。この方法でも、円グラフとOrder Totalのデータにこれらの変更が反映され、画面上で更新されるようになります。

このページで使用できる製品は、Millennium Deliveryが販売するすべてのアクティブ製品の全セットです。商品リストに一度に表示される行数を制限するには、DEFAULT_ROWS定数を使用します。在庫管理者が商品をより早く見つけることができるようにするには、SelectFamilyメソッドを実行して、表示される商品を選択された商品ファミリの商品に限定します。ユーザーが商品を商品ファミリでフィルタするときに、入力した数量と単価の値が保持されるようにします。

StandardSetControllerメソッドを使用して、提供されているページ付けメソッドを完成させ、ユーザーが使用可能な製品の複数ページを移動できるようにします。ユーザーがページ番号を付けたときに、入力された数量と単価の値が保持されるようにします。

彼女がproduct2Newページで要求したのと同じように、Reneeは将来ビジネス要件が変わったときにOrderEditページやOrderExtensionクラスを変更したくはありません。 GetFamilyOptionsメソッドを完成させるには、Product2Extensionクラスで使用されているGetFamilyOptionsメソッドをコピーします。

ユーザーがCancelボタンをクリックした場合は、変更内容を保存しないでください。

ユーザーがSaveをクリックすると、注文と注文商品が保存されます。数量が0より大きい注文商品のみを保存する必要があります。他の人はいけません。既存の注文を編集するときは、数量がゼロになるように変更された注文アイテムをすべて削除する必要があります。保存中にエラーが発生した場合は、セーブポイントをロールバックし、わかりやすいエラーメッセージを画面に表示する必要があります。

単体テストを作成する

テストは長期開発を成功させる鍵であり、開発プロセスの重要な要素であることをApexテストモジュールから思い出してください。品質保証に不可欠であることに加えて、Apex単体テストはApexを展開および配布するための要件でもあります。レニーはあなたに新しいユニットテストを作成するように依頼しました。

OrderExtensionクラスのすべてのメソッドをテストするOrderTestsで、OrderExtension_UnitTestという名前の新しいメソッドを作成します。 Product2Testsのコードをテンプレートとして使用してください。

Product2TestsでProduct2Trigger_UnitTestという名前の新しいメソッドを作成し、ProductのQuantity Ordered値が更新されたときにロジックをテストします。

開発者コンソールで、すべてのテストデータを消去してからすべてのテストを実行します。

Product2TriggerおよびOrde​​rTriggerトリガーで75％以上のテストカバレッジがあることを確認してください。

Product2ExtensionクラスとOrderExtensionクラスに75％以上のテスト適用範囲があることを確認してください。

Constants、ChartHelper、Product2Helper、OrderHelper、およびTestDataFactoryクラスを90％以上カバーするようにしてください。

** FYI **テストカバレッジはデプロイメントの要件であり、コードが失敗しないことを保証するための優れた方法です。以前のバッジで説明したように、単体テストの目的は一定の割合を達成することではなく、ビジネスロジックが期待どおりに動作することを確認することです。