SalesForceってなに?-Lightning Platformの基礎

SalesForce資格勉強

SalesForceってなに?何ができるの?

一言でいうとSFはビジネスをするうえで必要なソリューションを提供しています
※ソリューション = 課題解決、業務効率化

具体例として下記のような業務管理するアプリを簡単に作れます。
・顧客管理
・社員管理
・商談のスケジュール管理
・決済管理

SalesForce社の思想
ドリルを買うのはドリルが欲しいからドリルを買うわけではない、穴が欲しいから
穴を作る仕組みさえ低コストにできれば、自社サーバーや自社開発アプリなど必要ないです。SFの提供するLightning Platformを使えば企業側からすれば開発コストを少なく、
業務を管理する仕組み(ビジネスツール)ができてしまいます。

 

ビジネスソリューションからアプリ開発の流れ

顧客と商談について管理するという業務(ビジネス)があるとしましょう。

昔は下記の情報を書類に書いて管理していました。
・顧客リスト
・顧客の詳細情報
・その顧客にどの社員
・どのような商談
・見積書
・請求書

商談が終わった後に、その商談について手動で消す。
その顧客がいなくなった場合手動でその顧客情報を消す。
そのような作業も紙で手作業で行っていました。

エクセルが生まれた後では紙媒体よりもデータにした方が修正や管理が簡単なので
PCで行いますが、データの管理(登録、更新、削除)などは手動で行います。
(エクセルマクロについてはここでは触れません)

もちろん紙よりかは楽になりましたがヒューマンエラーも起きますし、労力もかかります。

そこで多種多様なデータに関する紐づけを考え、
データを管理するためにDataBaseと紐づいたアプリケーション開発します。

アプリケーションで情報を管理することは、
一つの作業を行うことで紐づいたデータが一瞬で自動に管理できます。
一度作ってしまえば、ミスも少なく高効率です。

しかしWebアプリですとサーバー(インフラ)を用意したり、
アプリ自体の開発コストが膨大にかかります。

そこでインフラやアプリの開発(内部の処理)自体はSFのLightning Platformが提供して
処理ではなく、問題解決をするための仕組みづくりに時間がさけるようにしています。

SFのLightning Platformを使えば簡単にデータベースが作れて
簡単に情報を処理する仕組みをソースコードを書かずにつくれます。

 

ローコードと機能拡張について

SalesForceは基本的にソースコードを書かずに、UIのみでビジネスに必要なアプリが作れます。
つまり、ビジネスを行う上で問題解決に必要な機能が網羅されています。
このUIのみで開発されたアプリのことをローコードアプリといいます。

加えてSFは拡張性も確保していて、UIで実現できない機能に関しては
コーディングによる機能拡張ができます。

ローコード開発 = SF宣言的開発といいます。
プログラマでなくてもアプリが作れるという思想があります。

 

SFの基礎知識、用語

世界各地にSFのデータセンターがあります。

各データセンターにはアプリケーションを稼働させるために必要な機能を
一まとめにしたPod(Point of Deployment)というものでインスタンスごとに分けられています。
各Podの中には論理的に区切られた組織と呼ばれる環境が稼働しています。

どこかの組織の中で開発者は開発をしています。
例えばPodにはアメリカだとNA01、ヨーロッパだとEU01、アジアではAP01などの名前がついています。今から開発をしようとしている組織はどのPod上で動いているのかが分かります。

SFは年に3回アップデートを行いますが、Podごとに何時行うかが違います。
なので、自分がどのPodに所属するのかは重要ですので理解しておくようにしてください。

SFには複数エディションというものがあります。
組織に入る際にエディションというものを選ぶ必要があります。
エディション毎に利用できる機能の制限が決まります。
例えば、コードを書いての開発をするためには、エンタープライズエディション以上のものが必要になります。

ユーザとは
組織の製品や機能やデータへのアクセスを可能にするための単位です。
ユーザとは必ずしも人とは限りません。
例えばシステム連携を行う特別なAPIユーザを作成することもあります。
公開サイトの不特定多数のページアクセスなどを一つのテストユーザとして管理することもあります。
全てのユーザには必ずライセンスプロファイルが割り当てられています。

ライセンスとは
製品や機能を利用するための権利です。

プロファイルとは
ユーザの責任範囲や用途に応じて権限を制限若しくは、制御するものです。

ライセンスでそのユーザの権限を与えて、詳細の権利はプロファイルで閉じていくといったように使われます。

 

データセンター = SFのサービスを提供するサーバー。ここにアクセスして開発や利用ができるからクラウド型ビジネスソリューションサービスと呼ばれる

Pod(Point of Deployment) = アプリケーションを稼働させるために必要な機能を一まとめにしたにしたもの。

組織 = Podを論理的に区切った環境

エディション = SFの製品のグレード

ユーザ = 組織の製品や機能やデータへのアクセスを可能にするための単位。
※人とは限らない
ライセンス = 製品や機能を利用するための権利
プロファイル =ユーザの責任範囲や用途に応じて権限を制限若しくは、制御するもの

 

利用者も開発者も、共通のログイン・共通の画面

一般的なクラウド環境での開発というのは上記画像の左にあるように、
開発者はまずコンソールにログインしてアプリケーションを稼働させるための認証設定を行います。
一方、利用者には別途アプリケーションを構築して提供します。
なので利用者はそのアプリケーションに導入された認証設定でログインをしてアプリを利用します。

ここで興味深いのはSFのLightning Platformでは、アプリの開発も利用もその組織内で完結します。
開発者も利用者も組織で同様に入り同じようにユーザとして管理されてアプリを開発します。
SFでは開発者も利用者も同じ認証の仕組みでログインをしてLightning Platformを利用し、その上でそれぞれの作業を行います。

Lightning Platform アプリケーションとナビゲーション

実際にLightning Platformの見え方を解説します。

下記の画面が基本的な画面です。今回は例として「セールス」というアプリを使います。
下記の画像で赤い囲いのところにアプリケーション名。
オレンジ色の囲いには「セールス」アプリの中に入っているオブジェクトがナビゲーションという形で参照できるようになっています。
※SFではテーブルのことをオブジェクトと言います。

 

そのアプリケーションは緑色の囲いにアプリケーションランチャーで選択をすることができます。
そして、参照したいオブジェクトも追加することができます。

 

レイアウトとLightning コンポーネント

◆レイアウトについて

下記の様にレイアウトもカスタマイズできます。

 

◆Lightning コンポーネントについて

標準LightningコンポーネントとはSFが提供している既に作りこまれた画面です。

カスタムLightningコンポーネントは開発者がコードを書いて作るもの(拡張するもの)です。

AppExchangeという他の開発者が作ったものをSFにダウンロードして使うという選択肢もあります。

 

◆Lightning アプリケーションのレイヤーについて

ファンデーションとして一番下に「Lightning アプリケーション、ナビゲーションアイテム」というものがあります。

その上に「Lightning ページ」があります。複数の「Lightningページ」があって「Lightning アプリケーション」を形成しています。

「Lightning ページ」の機能でレイヤーを指定できます。
そして指定されたレイヤーの中で、「Lightning コンポーネント」を配置できます。

Lightning Platformのアプリケーション開発というものは基本的にこの構成となります。
なので、構成としてはUIのオリジナリティは出しずらいものとなっております。

開発者がUIをカスタマイズするというのは、一番上のレイヤーである「Lightning コンポーネント」です。
その下の「Lightningページ・テンプレート」、「Lightning アプリケーション、ナビゲーションアイテムは設定ベースとなり、宣言的な開発(ローコード)で作っていくことになります。

 

Lightning Platformのデータモデル

基本的にはRDBをと同じ仕組みです。

一般的なRDBで使われる用語とSFのデータモデルで使われる用語で大きく異なります。
テーブル = オブジェクト
カラム(列) = 項目
レコード(行) = レコード
物理名 = API名

SFがデフォルトで提供するものを標準オブジェクト、標準項目といいます。
例:ビジネスに必要な取引先、商談、ケースなど
ID、名前、取引先名

開発者が必要に応じて作る(拡張する)オブジェクトや項目を
カスタムオブジェクト、カスタム項目といいます。
カスタムオブジェクト、カスタム項目には生成した物理名に「__c」が自動的に付属されます。
例:Expence__c

APIはプログラムなどからオブジェクトや項目を参照するための識別子です。
一般的なRDBですと、物理名に当たります。

 

一般的なRDBにはIDのような主キーがあると思いますが、SFにはすべてのオブジェクトのレコードにIDという標準項目があります。
このIDはレコードが作られるときにSFに自動採番され、どういったIDを持つといった指定はできません。
加えてLightning Platformのオブジェクトマネージャーでも参照ができないです。
下記の機能を使って参照することをお勧めします。
オブジェクト定義書自動生成

 

オブジェクトのリレーション

◆リレーション項目について
親と子の関係とは1:Nで構築するものです。
リレーション関係の仕組みとしては、上記のように「取引先責任者」オブジェクトの項目に親である「取引先」オブジェクトのレコード(AccountId)のIDを保持しているだけです。
このように、親が子を参照する時、子が親を参照する時の項目をリレーション項目と呼びます。

別の言い方をすると
リレーション項目は必ず子のオブジェクトが持つ項目です。
その項目は親をユニークに参照することができます。

◆リレーション項目の種類
参照関係:リレーション項目が必ずしも親のレコードが存在しなくても定義可能。
主従関係:必ず親のレコードがなければならない関係。

◆特殊なリレーション
多態的なリレーション項目とは、いくつかのオブジェクトへの参照を許す項目で
N:Nの関係ができます。
こちらは標準項目しかないので、自分で作ることはありません。
しかし、SFを使ってく上でいつか出くわすリレーションなので覚えておいてください。

複数項目とは、UI上で参照している項目が実は複数のオブジェクトからなる場合があります。
一般的なRDBでVIEWという概念です。

プログラムでクエリを作成しているときに、子供を基準としたときに、ある項目が何のオブジェクトを参照しているか分からないというケースに当たることがあります。
こういった場合に多態的なリレーションではないのか?という目線で問題解決をすると謎が解けるかもしれません。

 

 

オブジェクトのレコードタイプ

取引先中にも「顧客取引先」や「協力取引先」というような種類があるとします。
そういった場合に単純にオブジェクトを二つに分けるのではなく、一つのオブジェクトにレコードタイプという項目を持たせて、Aタイプは「顧客取引先」、Bタイプは「協力取引先」という風に定義します。

これを行うことでUIとして、レコードタイプ毎にページレイアウトの割り当てが可能になります。
取引先だけど、レコードタイプによって顧客取引先のみを見せるというような特化した見せ方ができます。

見せ方としては特化していますが、一つのオブジェクトなので色々な種類のタイプを分析することもできます。

単純に種類が違うからといってオブジェクトをたくさん作ってしまうのではなく、
レコードタイプという考え方を使ってより効率の良いデータ構造を作ることに意識をしてください。

より内部的な話をしますと、取引先オブジェクトはレコードタイプという項目を持っていて、
左のレコードタイプというマスタテーブルを参照して、データ構造をシンプルにしています。

 

次回はLightning Platformでのアプリ開発方法を解説します。

 

 

コメント