Inside Trailhead - APIを使ったLeaning Platform

  • 10
    いいね
  • 0
    コメント
この記事は最終更新日から1年以上が経過しています。

Trailhead、皆さんやってますか?
なんか今日あたりモジュールクリアすればクリスマスバッジとかもらえるのかなと思ってやってみましたが、貰えませんでした。
Trailhead はSalesforceが提供しているオンライントレーニングサービスです。初めての方はアドベントカレンダー10日目の Salesforce Trailhead 事始め から見ると良いと思います。
本日はTrailheadがどんな風に動いているのか紹介します。

API Base Platform - Salesforce

Meta.jpg
まずTrailheadの動作を知る前の前提知識として、Metadata APIなどにもに明るい兄者たちならもうお馴染みの話ですがSalesforceはプラットフォームの中に入っているほぼ全ての情報をAPI経由で取得することが可能だ、という点がキーとなってきます。

例えばSalesforceの中には顧客や商談、ユーザ情報や在庫商品など、利用者ごとに様々データが入っているわけですが、これらの実データ以外にもSalesforceにはメタデータと呼ばれるものがあり、例えば以下のような物を指します。

  • テーブル(オブジェクト)の構造
  • 記述されているApexプログラムのコード、クラス構造
  • 標準で自動生成されるUIのレイアウト定義
  • 保存されている静的なリソースファイル
  • データの共有範囲やセキュリティ情報
  • などなど

Salesforceの中では全てがこの「実データ + 定義(メタ)データ」の組み合わせを取ることによってシステムを構成しています。
例えば何気なくSalesforce上にデータベースオブジェクトを作成して画面を開けば自動的に生成されたUIがサクッと表示されますが、この際には「実際のデータ + テーブル構造(メタデータ) + 権限・セキュリティ(メタデータ) + 表示画面のレイアウト定義(メタデータ)」といったデータを取得し、それを組み合わせた上で最終的に画面を生成しています。

ここら辺の詳しい話はちょっと古いですがメタデータアーキテクチャあたりに書いてあったりします。
ここでは本題ではないので概要だけですが、Salesforceは記述したソースコード、画面レイアウトなども含め、全てAPIで取得が可能となっている点が大きなキーポイントです。

Trailheadは何をしているのか

では、話をTrailheadに戻しましょう。TrailheadにはChallengeと呼ばれる演習形式の仕組みを採用しており、実際に利用者が内容を理解し正しいコードが書けているかどうかをテストする仕組みを用意しています。ここでは、どのようにそれが実現されているかを見てみましょう。

パターンA : 実データの場合 (Web Service REST API)

例えば データのインポート という単元では、CSVファイルから手軽に複数のデータをSalesforceへロードする手法が説明されていますが、確認テストであるChallengeにはCSVファイルからウィザードを使ったデータをインポートしろと書いてあります。(残念ながら現状英語のみです)

import.png

ここで実際自身のSalesforceに繋げばその演習ができたかどうかをチェックしてくれるわけですが、このChallengeの裏側、Trailheadの中身に置いてある定義ファイルをちょっと見てみましょう

{
    "title":"Import data using the Data Import Wizard.",
    "description":"This challenge requires you to import contact data using a CSV (comma separated values) file. Use all columns in the CSV file, each of which corresponds to a contact field.",
    "requirements": [
               "(中略)"
    ],

    "assessment": [
        {
            "action": "Find the data from the CSV file",
            "endpoint": "/services/data/v30.0/query/?q=",
            "parameter": "SELECT Name, Id from Contact where Email LIKE '%example.com'",
            "confirm": "result.size >= 20",
            "success": "The Contact data has been imported successfully",
            "error": "All the contact records from the CSV file were not found in the Org."
        },
        {
            "action": "Find a specific record from the CSV file",
            "endpoint": "/services/data/v30.0/query/?q=",
            "parameter": "SELECT Name, Id from Contact where Salutation = 'Dr.' AND LastName = 'Dapper'",
            "confirm": "result.size >= 1",
            "success": "The specific Contact was found",
            "error": "One of the contact records from the CSV file could not be found in the Org."
        }    

        ]
}

このassessment定義ファイルには、
/services/data/v30.0/query/?q=」というAPIエンドポイントに対して 「SELECT Name, Id from Contact where Email LIKE '%example.com」というクエリを投げ、そのデータサイズが20以上であれば、さらには特定のデータ(Dr.Dapper)が入っていればきちんとデータがインポートできているという験算をおこなっているわけです。
この場合には Salesforceの持つ実データを取得するREST APIを叩いて、データを取得しています。

パターンB : メタデータの場合 (Metadata API)

では、別のケースを見てみましょう。
今度は Apex 単体テストの開始の単元を見てみましょう。
こんどは実際のデータではなく、ApexプログラムをテストするUnitテストクラスが正常に記述できているかどうかがChallengeの内容とっています。

ApexTest.png

この場合のTrailhead内部の定義ファイルを見てみましょう

{
    "title":"Create a unit test for a simple Apex class.",
    "(中略)":"",

    "assessment": [
        {
            "action": "Finding the class 'VerifyDate'",
            "endpoint": "/services/data/v30.0/tooling/query/?q=",
            "parameter": "SELECT Name from ApexClass where Name = 'VerifyDate'",
            "confirm": "result.size > 0",
            "success": "The Apex class was found",
            "error": "No Apex class named 'VerifyDate' was found"
        },
        {
            "action": "Finding the class 'TestVerifyDate'",
            "endpoint": "/services/data/v30.0/tooling/query/?q=",
            "parameter": "SELECT Id, Name from ApexClass where Name = 'TestVerifyDate'",
            "confirm": "if !result.first.nil?\n held = result.first.Id; \nend\n result.size > 0;",
            "success": "The Apex class was found",
            "error": "No Apex test class named 'TestVerifyDate' was found"
        },
        {
            "action": "Running Unit Tests in 'TestVerifyDate'",
            "endpoint": "/services/data/v30.0/tooling/runTestsSynchronous/?classnames=",
            "parameter": "VerifyDate",
            "confirm": "true;",
            "success": "The Apex class 'VerifyDate' worked as expected",
            "error": "The test methods in 'VerifyDate' could not be run"
        },
        {
            "action": "Checking Coverage",
            "endpoint": "/services/data/v30.0/tooling/query/?q=",
            "parameter": "SELECT NumLinesUncovered from ApexCodeCoverageAggregate WHERE ApexClassorTrigger.Name = 'VerifyDate'",
            "confirm": "if !result.first.nil? \n result.first.NumLinesUncovered == 0; \nend\n",
            "success": "The Apex class was covered",
            "error": "The 'VerifyDate' class did not achieve 100% code coverage via your test methods. Make sure that you run the test in the Developer Console at least once before attempting to verify this challenge"
        }
    ]
}

ここではメタデータAPIの一種で、Apexなどのメタデータを確認するのに特化したTooling APIというものを利用して、演習を行ったSalesforceの中身をチェックしています。
ここでは「 /services/data/v30.0/tooling/query/?q= 」というエンドポイントに対して特定のクラスやメソッドが存在しているかや、テストのカバレッジ率を確認することで、プログラミングが正常に行えているかを確認しています。
また「 /services/data/v30.0/tooling/runTestsSynchronous/?classnames= 」というエンドポイントから、実際に対象となる組織のテストコードを実行してその結果をチェックするといったことも行っているのです。

TrailheadはAPI Base Platformだから実現できる学習プラットフォーム

このようにTrailheadは「学習コンテンツとそれをテストするための定義ファイル」の組み合わせを用意することで、確認Challenge付きの演習を作成することのできる学習プラットフォームとして捉えることができます。
本来クラウド上で動作しているプログラムコード自体をAPI経由で取得するのはなかなか大掛かりな仕組みを構築する必要がありますが、Salesforceは利用者一般ユーザから開発者、管理者まで全てのIdentityを一括で管理し、定義情報などの全てがAPIでアクセス可能なプラットフォームのためこのようなことが可能なのです。
th2.jpg

Trailehadは今後どうなるか?

長文をここまで読んだ兄者たちはもう気付いているかもしれませんが、上記の定義情報は今の所Salesforce内部の人間にしか追加・編集することはできませんが、ちょっと描き方のパターンさえ覚えてしまえば誰でも確認テスト付きのオンライントレーニンングコースが作れてしまうのです。(現状は誰もが追加できるには少々荒削りなので、もう少し整備が必要でしょうが)

これはForward Looking Statementsですが、将来的にはSalesforceだけでなく、外部のパートナーやユーザがトレイルやモジュールを追加できるようにすることも技術的には不可能ではありません。
オレオレトレイルとかオレオレモジュールとか胸熱ですね。

今後もTrailheadはAPI PlatformであるSalsforceの利点によって益々進化していきます。
ぜひTrailheadのコンテンツだけでなく、Trailheadという新しい学習プラットフォームの今後にもご注目ください。