Apex Specialist Super Badge 日本語訳

オリジナルはこちらです： https://trailhead.salesforce.com/ja/superbadges/superbadge_apex

本資料はスーパーバッジ取得のための参考資料です。各カスタマイズ要素のラベル部分には補足として日本語を記述していますが、正解チェックは英語のラベルを元に行われるため、実際のチャレンジは英語表記のみを使用して行って下さい。

このスーパーバッジを取得するには何をすれば良いのか？

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

所要時間: 推定 8 時間 - 12 時間

事前作業と説明

ユースケース

世界には2種類の人間がいます : レジャーカー(RV車)で旅行をする人と、しない人です。RV車のコミュニティは世界中で指数関数的に広がっています。世界最大のRVレンタル会社であるHowWeRoll Rentalsは、過去数年間に渡り世界中のビジネス範囲とキャンピングカーの数を10倍に増やしました。

HowWeRollは旅行者に対して、優れたRVレンタルとロードサービスを提供しています。彼らのスローガンは”サービスには自信があります。これが私達のスタイルです!” で、彼らのレンタルサービスには特大のサイズから車輪の付いたラグジュアリーな家のようなスタイル、最小構成のもの、レトロなウィネベーゴなど、様々なスタイルのキャンピングカーが用意されており、あなたの旅行熱を満足させることができます。

あなたは主任Salesforce開発者としてHowWeRollの自動化と業務領域拡大のために雇われました。旅行者にとって全ての旅が豪華で素晴らしいもの(champagne wishes and caviar dreams)ではありません。残念ながら、道程の所々に跳ねあがるようなコブが存在します。HowWeRollには何処でもどのような保守要求にでも対応できる素晴らしいRV修理チームがいます。修理では壊れた車軸から腐敗したタンクの引き伸ばし工作など応急処置的なものまで、様々な技術的困難に対処しています。

会社が成長するにつれて、HowWeRollのレンタルサービスも同様に成長します。ビジネス的には素晴らしいことですが、現在のメンテナンスサービスおよびプロセスでは拡大する事が困難です。故障や機器不全に対するサービスリクエストに加え、車両の定期メンテナンスリクエストは急激に増加しています。しかし日々のメンテナンスチェックを怠れば、レンタル車両は不可避な故障を起こしてしまう可能性が高まります。

そこであなたの出番となります!  HowWeRoll はSalesforceベースの定期メンテナンスシステムを自動化する為にあなたを必要としています。

車両が亀裂や不必要な損害に陥ったり、さらには顧客を危険に晒すわけにはいきません！ またSalesforceとHowWeRollのバックオフィスシステムと統合し倉庫の在庫を追跡します。この完全に分離されたシステムは、サービスリクエスト時に使用可能なスペアパーツの数を正確に把握し、機器部品を再注文する必要がある場合に警告します。

標準オブジェクト

あなたは以下の標準オブジェクトで作業をします:

カスタムオブジェクト

エンティティ相関図

業務用件

このセクションはHowWeRollの主要関係者との会議の成果を表しています。彼らのビジネスにおけるサポートとメンテナンスをプログラムによって自動化するための設計書となります。

メンテナンスリクエストの自動化

HowWeRollはRVの人気が世界規模で急激に高まり、世界中に高級車からエコノミー車を供給しています。このレンタル在庫の増加に伴って機器の故障も必然的に増加します。HowWeRollはこの障害に対応するための既存のプロセスを持っていますが、しかし彼らの定期メンテナンスの自動化を構築する必要があります。 一つの難しい事実として、全ての部品はいずれサービスを必要とするという事です。あなたは機器や部品が導入された日付に基づいて定期点検を自動スケジュールするプログラミングによるプロセスを構築します。

Type (種別) がRepair (リペア) か Routine Maintenance (定期メンテナンス) の既存メンテナンスリクストがクローズされた際、将来の定期メンテナンスのための新しいメンテナンスリクストを作成します。この新しいリクエストは元のクローズされたサービスリクエストを元に同じ車両および同じ機器に紐づけられます。新しいリクエストの種別はRoutine Maintenance (定期メンテナンス) に設定される必要があります。Subject (件名) はnullであってはならず、Date Reported (報告日) 項目はリクエストが生成された日を反映します。別の側面として、部品は全て異なる寿命を持っている点があります。したがって関連するWork Part (作業部品) レコードに定義されているメンテナンスサイクルから計算し次の期日を設定する必要があります。もし複数のWork Part (作業部品)をメンテナンスリクエストで使用されている場合には、最も短いメンテナンスサイクルをサービス日に設定します。

この自動化プロセスは単体のメンテナンスリクエストと一括リクエストの両方に対応するようデザインします。一緒にインポート予定の約300行のオフラインメンテナンスリクエストを正常に処理するためにシステムを一括化します。当面の間は Equipment (機器) レコード自体の変更については考慮する必要はありません。

このロジックは組織内の別の場所で使用されるため、トリガ(名称 : MaintenanceRequest) をハンドラ内のアプリケーションロジック (名称 :  MaintenanceRequestHelper) と分離します。この設定によりアクションを委譲し、今後アプリケーションを拡張するのがより簡単になります。

在庫管理の同期

機器のメンテナンスに加えて、HowWeRollのサービス部品倉庫にある外部システムの在庫データとの同期も自動化します。本社オフィス全体でSalesforceを利用していますが、倉庫チームはまだ依然として別のレガシーシステムを利用しています。このインテグレーションで、倉庫から車両にサービスを提供した後、Salseforceの在庫が更新されます。

更新が必要な 機器リスト を取得するために、RESTコールアウトを外部の倉庫システムへ行うクラスを記述します。コールアウトの JSON レスポンスはSalesforceにupsertする機器レコードを返却します。在庫以外にも、他の潜在的な倉庫の変更を　Salesforce へ引き継ぐようにします。
クラスは以下の項目に対応します : replacement part (部品交換) (常にtrue), cost (コスト), current inventory (現在の在庫), lifespan (寿命), maintenance cycle (メンテナンスサイクル), および warehouse SKU (倉庫SKU)。 warehouse SKU (倉庫SKU)を外部IDとして使用して、Salesforce上の更新するレコードを識別します。HowWeRollは国際的な会社ですが、リモートオフィスは本社の勤務時間に沿っています。したがって全てのメンテナンスリクエストは本社の通常の営業時間中に処理されます。Salesforceデータの更新は営業時間外(PSTで午前1時)に行う必要があります。このロジックは日時で実行されるので、本社の在庫は毎朝最新となっています。

ユニットテストの作成

世の優れた開発者達に習って、あなたも本番環境にデプロイする前にコードをテストして安全性を確保します。

最初にテストするのはトリガが期待通りに動作するかです。繰り返しますが、ポジティブなユースケース(トリガが起動する必要がある場合)とネガティブなユースケース(トリガが起動してはならない場合)の両方をテストするというベストプラクティスに従います。もちろん、テストをパスしたとしても全てが正しいとは限りません。そこでアサーションをコードに追加して、誤検査をしないようにします。ポジティブテストでは、vehicle (車両) と equipment(機器) の関連や期日など、全てが正しく作成されていることを確認します。ネガティブテストでは、作業レコードが作成されないことを確認します。前述の通り、多くのメンテナンスリクエストの波が一度に読み込まれる可能性があります。数はおそらく200前後となりますが、急増する可能性を考慮するためにクラスが少なくとも300レコードを正しく処理できるように実装します。これをテストするには、ポジティブユースケースで300のメンテナンスリクエストに対して、予測通りに処理がされたことを確認します。トリガおよびハンドラの100%のコードカバレッジには、コールアウトおよびスケジュールApexクラスのテストケースを記述します。組織内の全てのApexクラスに対して100%のコードカバレッジを必要とします。

コードが例外なくTest.stopTest()の後でバリデーションを行い、スケジュールされたコンテキストで期待通りに実行されていることを確認します。また、スケジュールされた非同期ジョブがキューにあることを検証します。コールアウトサービスおよびスケジュール済み処理のテストにも100%のテストカバレッジが必要です。

ハンズオン

スキーマおよびApexクラス&トリガのスタブコードの含まれた非管理パッケージをインストールします。ケースおよび商品をHowWeRollのスキーマに合うように名称変更し、全てのプロファイルにそれらのオブジェクトのカスタムHowWeRollページレイアウトをアサインします。パッケージに含まれるコンテンツを利用して、Type(種別)がRepair (修理)もしくは Routine Maintenance (定期メンテナンス)のmaintenance request (メンテナンスリクエスト)がクローズされる際に、毎回自動的に定期メンテナンスリクエストを作成します。仕様や命名規則は業務要件に従います。

Apexクラス(WarehouseCalloutService)を実装し、 @future アノテーションを使用して、倉庫の在庫管理を行う外部サービスに対してコールアウト処理を行います。このサービスは外部システムからの更新値を受け取り、Salesforce内の関連レコードを更新します。このセクションのチェックを行う前に、WarehouseCalloutService.runWarehouseEquipmentSync() メソッドを最低一回は呼び出してください。それが期待通りに動作しているかを確認します。

コールアウトおよびコードを日次で実行するスケジュールロジックを作成します。このスケジュールサービスを業務要件に合わせて指定して下さい。

業務要件にある全てのケース (ポジティブ, ネガティブ, および一括処理)のテストを作成します。このチャレンジをパスするには100% のテストカバレッジとロジックが期待通りに動作する事を確実にするためのアサーションが必要です。このセクションをチェックする前に最低でも一度は開発者コンソールからRun All でテストを実行して下さい。チャレンジのチェックプロセスは10-20秒程度かかりますので、気長に待っていて下さい。

コールアウト処理を取り込み済のコールアウトMockのStabコード(WarehouseCalloutServiceMock)を使ったテストをパッケージ内のクラス(WarehouseCalloutServiceTest)に記述します。このチャレンジをパスするには100% のテストカバレッジとロジックが期待通りに動作する事を確実にするためのアサーションが必要です。

スケジュール処理をパッケージ中の取り込み済みのスケジュールクラス(WarehouseSyncSchedule)のStabコードのテストを記述します。このチャレンジをパスするには100% のテストカバレッジとロジックが期待通りに動作する事を確実にするためのアサーションが必要です。