技術をかじる猫

適当に気になった技術や言語、思ったこと考えた事など。

Salesforce開発の基礎編1

Salesforce 日記 勉強

教科書はコレ。

trailhead.salesforce.com

問題となるのは、この勉強用プラットフォームの翻訳を信用できないという所（汗
日本語だと正解選択肢が出ないとかいうバグもちらほらある。

加えて単語の訳が微妙過ぎて、同じページで同じ単語の訳が一貫してないとかいうクソ仕様まであるので、改めて先頭から見ようかと。

プラットフォーム開発の基礎 | Salesforce Trailhead

超ざっくり要約：

  1. プラットフォーム開発の開始
    Trailhead Playground という環境の作成チュートリアル。
    忘れてはいけないのは、環境作成直後に「英語」に変更しておくこと。
    多分それ以外に注意点はない。
    Salesforce では、環境一つ一つを「組織」と呼んでる。「Trailhead Playground」で作成された環境も「組織」と呼ぶことがあるので注意。
  2. コーディング不要の開発
    OSS 開発でブイブイ言わせてた人のためには基本的に読み替えが出来れば理解しやすいと思う。
    • メタデータ = テーブルに関連した表示設定などの周辺設定情報
    • オブジェクト = テーブル、またはテーブルスキーマ
    • 項目 = カラム定義
    • レコード = レコード 注意点「オブジェクト」と紹介しているくせに、後述でオブジェクト操作のUIを「スキーマビルダー」とか言い出してるところ。 オブジェクトの定義内には、データの形状のほかに見せ方の定義（レイアウト、検索条件などのメタデータ）が含まれてるのが重要な点かと。
  3. Salesforce 言語によるコーディング
    開発する際によく使うフレームワーク/言語の紹介。
    • Lightning コンポーネント Salesforce は過去のアップデートで Lightning というインターフェースに移行してて、その際出てきたフレームワーク。
      Lightning インターフェースに沿った画面が作れたり、Lightning 特有のコンポーネントを組み合わせることで、リッチな画面を作成しようというもの。 XML + JavaScript で書くことになるが、独自仕様と制限が多いので嫌われ気味。
    • Apex
      Salesforce で開発するとなったときの大体の場合の第一言語。
      Java ライクを目指したといいつつ、Generics は実質利用不可能で、リフレクション関連も利用できない。
      Java 1.4 にかろうじて List に型が宣言できる程度だと思っておくと良いかもしれない。
      コード中に SOQL というオブジェクトにのみ適用できるクエリが書ける。
    • Visualforce
      画面作成や、外部公開ページ(非Salesforce組織ユーザ向け画面)を作る際に良く使われる候補。
      ASP や JSP の流れを持った奴だと思うと分かりやすい。 尚、Visualforce のバックエンドは Apex 一択で、static 変数は JSP と違ってセッション単位にインスタンスができる。 つまり、他のユーザと static 変数の共有はしない所は勝手が違う。
  4. Salesforce Platform の拡張
    Salesforce は外部からアクセスする手段をそこそこ沢山持ってる。
    また、Heroku が Salesforce 傘下なので、Heroku 上の Postgres ←→Salesforce object をリンクするなんてこともできる。

Apex と .NET の基本 | Salesforce Trailhead

因みに .NET と聞くと Microsoft の .NET を連想しそうだが、正直忘れないと地獄を見る。
これはやればやるほど分かるが「どこが .NET じゃ」と暴れるレベル。

  1. .NET の概念の Lightning プラットフォームへの対応付け
    ざっくり概要：
    • Apex はオブジェクト指向で、C# ライクな構文形態してますよ
    • データ型は大体似てますよ
    • リスト/セット/マップ 位のデータ構造は似た感じで使えますよ
    • ASP.NET と Visualforce は似てますよ（←個人的に絶対にNOと言いたい。良いところ ASP 止まりでしょう…）
    • Apex はデータと密接に連携してるので、LINQ っぽいクエリ書くけど、これはレコード専用だよ。
    • 設計パターンが互換しない（フレームワーク構造と使い方は1から慣れてね）
    • 単体テストコードで 75% 以上カバーしない場合、本番環境にリリース禁止ね♪ (← 個人的には良い仕様)
    • ソリューションファイル、プロジェクトファイル、設定ファイルがない
      （組織アップロード時にコンパイルだから）ローカルコンパイルしないし、何処に何を置くかの構造も決まってるので、こうした設定の類はありません。
      …ということにしておきましょう。厳密には sfdx というのが最近の主流で、これには設定が結構含まれる。
    • クラスライブラリがはるかに小さい…というか実質無い。
    • セキュリティの処理...サーバ上で、しかも特定組織でしか起動しなかったり、ユーザ単位でのアクセス権などが全部 Salesforce 上で完結するので、データベースの接続文字列とか不要です
    • インテグレーションについて 外部からの接続アプリが作れます。
  2. 実行コンテキストの理解
    コンテキストは「文脈」とか「状況」みたいに考えると理解しやすいです。
    Apex コードの呼び出し方（呼び出される状況）は複数パターンありますという話。
    ここでは演習として、データベーストリガを書きます。
    レコードの Insert 直前、Insert 後、更新直前…といったレコード処理の前後でコードを実行し、関連データ更新だったり保存値の変更だったり、入力チェックだったりできます。
  3. 非同期 Apex の使用
    非同期というとあれですが、別スレッドで処理を実行することを意味します。
    ケースの説明で
    • 処理するレコード件数が非常に多い
      バッチを使いましょう。
      Salesforce には ガバナ制限 という悪名高い制限があり、Apex 処理中でアクセス/更新するなどの回数/量に制限があります。
      バッチでなら一部回避できます。
    • 外部 Web サービスへのコールアウトを行う
      外部の REST API を呼んだりすることを「コールアウト」と呼んでます。
      この操作は、データベースの更新処理（update/delete/insert）後に実行できないという制限があるので、このような状況だけ非同期にするという手段を取ります。
    • Queueable Apex
      future より制限薄い実装

多分 Queable とか非同期周りは以下を見た方が良いかもしれない

keneloper.com