Salesforce Platform 是成功的雲計算平台和應用程式生态系統的傑出範例。每天，數十萬家企業和數百萬使用者使用由 Salesforce Platform 提供支援的應用程式在雲中開展業務。
據統計，基于Salesforce Platform建構應用程式，IT成本可以降低 25%。
其良好的架構架解決方案具備這些特性：
- 可信的（Trusted）
- 簡單的（Easy）
- 适應性的（Adaptable）
使用 Salesforce Platform建立解決方案：
● 支撐了Salesforce預制的通用解決方案如銷售雲、營銷雲、服務雲等。
● 支撐垂直行業解決方案例如金融和醫療保健等。
● 可以擴充 Salesforce 提供的預建解決方案如銷售雲、服務雲、行業雲等）。
● 根據企業特定需求，完全自定義新的應用程式。
為什麼Salesforce平台如此成功？它為企業提供了哪些獨特優勢？這些都依賴于 Salesforce Platform獨特的雲計算軟體架構和強大的底層資料模型。
一、Salesforce的資料模型
Salesforce Platform 具有獨特的軟體架構，支援易于建構、使用、定制和擴充的應用程式，具有卓越的性能和可靠性。其軟體架構的核心是其多租戶、中繼資料驅動的設計：
1、多租戶支援
同時支援多個不同租戶（組織、業務部門等）的不同需求，并實作租戶間資料的隔離。
為了支援這種高度可定制和可擴充的架構，Salesforce Platform 的單個執行個體使用：
● 一個共享的多租戶資料庫，具有存儲特定于租戶的中繼資料和資料的單一架構。
● 一個多租戶核心（應用程式運作時），它讀取中繼資料和資料以在運作時為每個租戶的使用者動态提供特定于租戶的應用程式、業務邏輯和 API。
Salesforce 管理的核心與租戶管理的中繼資料的這種明确分離使得 Salesforce、租戶和 ISV 可以獨立地發展他們的系統部分而不受幹擾。
2、中繼資料驅動
允許每個租戶使用中繼資料、描述使用者界面 (UI) 和業務邏輯等元素的資料，輕松快速地定制租戶自己的應用程式和使用者體驗。
當使用 Salesforce Platform 建立新的應用程式對象或編寫一些代碼時，Salesforce平台不會在資料庫中建立實際表或編譯任何代碼。Salesforce平台隻是存儲一些中繼資料，然後它可以在運作時使用這些中繼資料來動态具體化虛拟應用程式元件。
Salesforce平台確定每個租戶的中繼資料都是私有的，并且無需任何鎖定或停機即可輕松更新，是以每個租戶都可以單獨建構和自定義應用程式。
Salesforce Platform 使用相同的中繼資料來提供自定義 API、RESTful 和 Web 服務（基于 SOAP）接口，可以使用這些接口将應用程式與其他應用程式和自動化流程內建。
二、多租戶資料模型
1、 多租戶共享資料庫表和資料隔離
Salesforce Platform 的應用程式運作時（runtime）和創新的資料層共同完成了每個租戶的資料、schema自定義和業務邏輯的安全隔離。
在架構層，schema設計支援多租戶的場景：
● 建立或定制應用程式時，平台會将相關中繼資料存儲在共享資料庫表中，這些表維護所有租戶的中繼資料。
● 應用程式讀寫資料時，平台會将資料存儲在共享資料庫表中，這此表存儲了所有租戶的資料。
● 此外，平台還維護許多其它内部中繼資料，用來優化運作時的請求延遲。
但是，單個共享資料庫和資料模型如何保證每個租戶的資料隔離呢？
平台上的每個租戶都被稱為一個組織（Organization），簡稱org 。共享資料庫表中的每個組織特定記錄都有一個OrgID。當程式通路資料庫時，它使用這個唯一辨別符來確定每個組織的活動都是私有的。
2、 按租戶進行資料分區
資料分區是資料庫系統提供的一種經過驗證的技術，可将大型邏輯資料結構實體地劃分為更小、更易于管理的部分。
Salesforce平台的資料、中繼資料和資料透視表結構，包括底層資料庫索引，都使用原生資料庫分區機制按 OrgID 進行實體分區。
分區還有助于提高大型資料庫系統（例如多租戶環境）的性能、可伸縮性和可用性。
在多租戶場景下，每次查詢都針對特定組織的資訊，是以查詢優化器隻需要考慮通路包含組織資料的資料分區，而不是整個表或索引。
3、 多租戶的資料隔離和保護
為防止共享的多租戶系統資源遭到惡意或無意的壟斷或獨占，Salesforce平台具有大量與平台代碼執行相關的調控器和資源限制。例如，平台密切監控代碼腳本的執行并限制它可以使用多少 CPU 時間、可以消耗多少記憶體、可以執行多少查詢和 DML 語句、可以執行多少數學計算、可以執行多少它可以發出的出站 Web 服務調用等等。
對于執行成本太高而無法執行的個别查詢，平台優化器會向調用方抛出運作時異常，這有助于保護所有相關應用程式的共享資料庫系統的整體可伸縮性和性能。
三、基于中繼資料的資料模型
中繼資料允許使用者建立獨特的資訊結構，以擴充或自定義 Salesforce應用。中繼資料還可以引用頁面布局和安全設定。
當使用者檢視 Salesforce 頁面時，系統會從中繼資料緩存中提取資訊以建立頁面，并在每次加載頁面時重新編譯超文本标記語言 （HTML）。
1、 中繼資料（Metadata）
特定組織（租戶）的對象（認為是傳統關系資料庫用語中的表）、字段、存儲過程、資料庫觸發器等，都是由中繼資料描述的虛拟結構，存儲在通用資料字典 (UDD) 的資料庫表中。
（1）MT_Objects
用于存儲有關應用程式定義的對象的中繼資料的表，包括
○ 對象的唯一辨別符 (ObjID)
○ 組織 (OrgID)
○ 對象指定的名稱 (ObjName)
（2）MT_Fields
用于存儲為每個對象聲明的字段（列）的中繼資料的表，包括
○ 字段的唯一辨別符（FieldID）
○ 組織（OrgID）
○ 包含該字段的對象（ObjID）
○ 字段 （FieldName）
○ 字段的資料類型（DataType）
○ 訓示字段是否需要索引的布爾值 (IsIndexed)
○ 字段在對象中相對于其他字段的位置 (FieldNum)
由于中繼資料是關鍵要素，平台必須優化對中繼資料的通路；否則，頻繁的中繼資料通路會阻止服務擴充。考慮到這一潛在的瓶頸，Salesforce平台使用大量複雜的中繼資料緩存來維護記憶體中最近使用的中繼資料，避免降低性能的磁盤 I/O 和代碼重新編譯，并縮短應用程式響應時間。
2、 資料（Data）
MT_Data系統表存儲映射到所有組織特定表及其字段的應用程式可通路資料，如 MT_Objects 和 MT_Fields 中的中繼資料所定義。
MT_Data表的每行包括：
(1) 辨別字段，全局唯一辨別符 (GUID)
(2) 擁有該行的組織 (OrgID)
(3) 包含的對象辨別符 (ObjID)
(4) 每一行還有一個 Name 字段，用于存儲相應記錄的“自然名稱”；例如，客戶記錄可能使用“客戶名稱”，案例記錄可能使用“案例編号”，等等。
(5) Value0 ... ValueN彈性（flex）列，也稱為槽，存儲應用程式資料，這些資料分别映射到 MT_Objects 和 MT_Fields 中聲明的表和字段。所有彈性列都使用可變長度字元串資料類型，以便它們可以存儲任何結構化類型的應用程式資料（字元串、數字、日期等）。
如下圖所示，
● 同一對象的兩個字段不能映射到MT_Data中的同一個slot進行存儲；
● 單個槽可以管理多個字段的資訊，隻要每個字段源自不同的對象即可。
MT_Fields 可以使用多種标準結構化資料類型中的任何一種，例如文本、數字、日期和日期/時間，以及特殊用途的豐富結構化資料類型，例如選擇清單（枚舉字段）、自動編号（自動遞增、系統生成的序列号）、公式（隻讀派生值）、主從關系（外鍵）、複選框（布爾值）、電子郵件、URL 等。
MT_Fields 可以設定是否允許不為空，并設定自定義驗證規則（例如，一個字段必須大于另一個字段）。
當聲明或修改一個對象時，平台會在 MT_Objects 中管理一行定義該對象的中繼資料。同樣，對于每個字段，平台在 MT_Fields 中管理一行，包括将字段映射到 MT_Data 中特定彈性列的中繼資料，用于存儲相應的字段資料。
因為Salesforce平台将對象和字段定義作為中繼資料而不是實際的資料庫結構來管理，是以系統可以容忍線上多租戶應用程式模式維護活動，而不會阻止其他組織和使用者的并發活動。相比之下，傳統關系資料庫系統的線上表重新定義通常需要臨時鎖，并且通常需要費力、複雜的過程和計劃的應用程式停機時間。
如上圖 MT_Data 的簡化表示所示，flex 列是一種通用資料類型（可變長度字元串），這使得平台可以在使用各種結構化資料類型（字元串、數字）的多個字段之間共享單個 flex 列、日期等）。
Salesforce平台使用規範格式存儲所有彈性列資料，并在應用程式從彈性列讀取資料和向彈性列寫入資料時，根據需要使用底層資料庫系統資料類型轉換函數（例如，TO_NUMBER、TO_DATE、TO_CHAR）。
MT_Data 還包含有四列來管理審計資料，包括
● 哪位使用者建立了一行以及該行的建立時間
● 哪位使用者最後修改了一行
● 最後修改了該行的時間
● IsDeleted列，平台使用該列來訓示行何時被删除。
Salesforce平台支援将字段聲明為字元大對象 (CLOB)，以允許存儲最多 32,000 個字元的長文本字段。對于 MT_Data 中具有 CLOB 的每一行，平台将 CLOB 存儲在名為MT_Clob 的表中，系統可以根據需要将其與 MT_Data 中的相應行連接配接。
注意：Salesforce平台還在資料庫之外以索引形式存儲 CLOB，以便進行快速文本搜尋。
3、 索引（Indexes）
Salesforce平台自動索引各種類型的字段以提供可擴充的性能。
傳統的資料庫系統依靠原生資料庫索引來快速定位資料庫表中具有與特定條件比對的字段的特定行。
但是，為 MT_Data 的 flex 列建立原生資料庫索引是不切實際的，因為Salesforce平台使用單個 flex 列來存儲具有不同結構資料類型的許多字段的資料。相反，Salesforce平台通過将标記為索引的字段資料同步複制到MT_Indexes資料透視表中的适當列來管理 MT_Data 的索引。
MT_Indexes 包含強類型索引列，例如 StringValue、NumValue 和 DateValue，平台使用這些列來定位相應資料類型的字段資料。例如，平台會将 MT_Data 彈性列中的字元串值複制到 MT_Indexes 中的 StringValue 字段，将日期值複制到 DateValue 字段，等等。
MT_Indexes 的底層索引是标準的、非唯一的資料庫索引。當内部系統查詢包含引用對象中結構化字段的搜尋參數時，平台的自定義查詢優化器使用 MT_Indexes 來幫助優化關聯的資料通路操作。
注意：Salesforce平台可以處理跨多種語言的搜尋，因為系統使用大小寫折疊算法将字元串值轉換為通用的、不區分大小寫的格式。MT_Indexes 表的 StringValue 列以這種格式存儲字元串值。在運作時，查詢優化器自動建構資料通路操作，以便優化的 SQL 語句過濾相應的 case-folded StringValue，這又對應于搜尋請求中提供的文字。
Salesforce平台允許設定對象中的字段何時必須包含唯一值（區分大小寫或不區分大小寫）。考慮到 MT_Data 的排列和字段資料的值列的共享使用，為對象建立唯一的資料庫索引是不切實際的。（這種情況類似于上一節中針對非唯一索引讨論的情況。）
為了支援自定義字段的唯一性，Salesforce平台使用 MT_Unique_Indexes 資料透視表。該表與 MT_Indexes 表非常相似，除了 MT_Unique_Indexes 的底層原生資料庫索引強制唯一性。當應用程式試圖将重複值插入到需要唯一性的字段中，或者管理者試圖對包含重複值的現有字段強制執行唯一性時，平台會向應用程式傳回适當的錯誤消息。
在極少數情況下，平台的外部搜尋引擎可能會過載或不可用，并且可能無法及時響應搜尋請求。Salesforce平台不會向最終使用者傳回令人失望的錯誤，而是回退到二級搜尋機制以提供合理的搜尋結果。回退搜尋作為直接資料庫查詢實作，搜尋條件引用目标記錄的名稱字段。
為了優化全局對象搜尋（跨表搜尋）而不必執行可能昂貴的聯合查詢，Salesforce平台維護了一個MT_Fallback_Indexes資料透視表，該表記錄了所有記錄的名稱。
MT_Fallback_Indexes 的更新在事務修改記錄時同步發生，是以回退搜尋始終可以通路最新的資料庫資訊。
MT_Name_Denorm表是一張精益資料表，存儲了MT_Data中每條記錄的ObjID和Name。當應用程式需要提供涉及父/子關系的記錄清單時，平台使用 MT_Name_Denorm 表執行一個相對簡單的查詢，檢索每個引用記錄的名稱以顯示在應用程式中，例如作為超連結。
4、 關系（Relations）
Salesforce平台支援關系資料類型，組織可以使用這些類型來聲明表之間的關系（參照資料完整性）。
當你聲明一個對象的字段為關系類型時，平台将該字段映射到MT_Data中的一個Value字段，然後使用該字段存儲相關對象的ObjID。
為了優化連接配接操作，Salesforce平台維護了一個MT_Relationships資料透視表。該系統表有兩個底層資料庫唯一複合索引，可根據需要在任一方向上進行高效的對象周遊。
四、内部資料處理
Salesforce平台Salesforce提供了非常好的性能和擴充性，因為 Salesforce 在建構它時考慮了兩個重要原則：
● 提供高效、大規模的基礎平台能力。
● 幫助開發人員盡可能高效地完成所有工作。
Salesforce平台将這些原則融入到平台獨特的處理架構中，包括：
1、 查詢（Queries）
大多數現代資料庫系統通過采用查詢優化器來确定最佳查詢執行計劃，該優化器考慮有關目标表和索引資料的相關統計資訊。
然而，傳統的、基于成本的優化器統計資訊是為單租戶應用程式設計的，無法考慮在多租戶環境中執行查詢的任何給定使用者的資料通路特征。例如，對于以具有大量資料的對象為目标的給定查詢，對于具有高可見性的使用者（可以檢視所有行的經理）和具有低可見性的使用者（銷售人員可以看到隻看到與自己相關的行）。
為了提供足夠的統計資料來确定多租戶系統中的最佳查詢執行計劃，Salesforce平台為每個組織的對象維護了一套完整的優化器統計資料（租戶、組和使用者級别）。
統計資訊反映了特定查詢可能通路的行數，仔細考慮了整體特定于組織的對象統計資訊（例如，整個組織擁有的總行數），以及更精細的統計資訊（例如，特定權限組或最終使用者可能通路的行數）。
Salesforce平台還維護其他類型的統計資料，證明對特定查詢有幫助。例如，Salesforce平台維護所有自定義索引的統計資訊以顯示相應字段中非空值和唯一值的總數，以及顯示每個清單值基數的選擇清單字段的直方圖。
當現有統計資訊不存在或被認為沒有幫助時，平台的優化器會使用一些不同的政策來幫助建構合理優化的查詢。例如，當查詢過濾對象的名稱字段時，優化器可以使用 MT_Fallback_Indexes 表有效地查找請求的行。在其他情況下，優化器将在運作時動态生成缺失的統計資訊。
Salesforce平台的優化器與優化器統計資料一起使用，還依賴于内部安全相關表（Groups、Members、GroupBlowout 和 CustomShare），這些表維護有關組織使用者安全域的資訊，包括給定使用者的組成員身份和自定義通路權限對于對象和行。此類資訊對于确定基于每個使用者的查詢過濾器的選擇性非常寶貴。
下圖中的流程圖說明了當平台處理超大資料（例如 MT_Data中的資料）的請求時會發生什麼。請求可能來自任意數量的來源，例如 API 調用或存儲過程。
● 首先，Salesforce平台執行考慮多租戶感覺統計資料的“預查詢”。
● 然後，根據預查詢傳回的結果，該服務建構一個最優的底層資料庫查詢以在特定設定中執行。
如下表所示，平台可以根據送出查詢的使用者和查詢過濾條件的選擇性，以四種不同的方式執行同一個查詢。
2、 搜尋（Searches）
使用者期望互動式搜尋功能能夠掃描應用程式資料庫的全部或標明範圍，并以亞秒級響應時間傳回排名結果。
為此，Salesforce平台使用了與其事務引擎分離的搜尋引擎。當使用者更新記錄時，事務引擎會更新核心資料庫，并将相關資料轉發給搜尋引擎進行索引。當使用者搜尋記錄時，搜尋引擎使用其索引快速處理查詢并傳回帶有相關資料庫記錄連結的排名結果。
當應用程式更新文本字段（CLOB、名稱等）中的資料時，稱為索引伺服器的背景程序池負責異步更新相應的索引，搜尋引擎在核心事務引擎之外維護這些索引。
為了優化索引過程，平台在事務送出時将修改後的文本資料塊同步複制到内部“待索引”表，進而提供相對較小的資料源，最大限度地減少索引伺服器必須從磁盤讀取的資料量. 搜尋引擎自動為每個組織維護單獨的索引。
根據索引伺服器的目前負載和使用率，文本索引更新可能滞後于實際事務。為避免源自陳舊索引的意外搜尋結果，Salesforce平台還維護一個 MRU 緩存，其中包含系統在具體化全文搜尋結果時考慮的最近更新的行。Salesforce平台在每個使用者和每個組織的基礎上維護 MRU 緩存，以有效支援可能的搜尋範圍。
Salesforce平台的搜尋引擎使用多種方法優化搜尋結果中記錄的排名。例如，系統會考慮執行搜尋的使用者的安全域，并将更多權重放在目前使用者可以通路的行中。系統還可以考慮特定行的修改曆史，并将更活躍更新的行排在相對靜态的行之前。使用者可以根據需要選擇對搜尋結果進行權重，例如，更加強調最近修改的行。
3、 批量操作（Bulk Operations）
批量執行重複操作時性能更好。例如，對比應用程式可能加載許多新行的兩種方式。一種低效的方法是使用帶有插入單獨行的循環的例程，為插入的每一行進行一次又一次的 API 調用。一種更有效的方法是建立一個行數組，并讓例程通過單個 API 調用插入所有行。
使用Salesforce平台進行高效的批量處理對于開發人員來說很簡單，因為它被嵌入到 API 調用中。在内部，Salesforce平台還批量處理與顯式批量操作相關的所有内部步驟。
Salesforce平台的批量處理引擎會自動解決在此過程中任何步驟中遇到的孤立故障。當批量操作以部分儲存模式啟動時，引擎會識别一個已知的開始狀态，然後嘗試執行流程中的每個步驟（批量驗證字段資料、批量觸發預觸發、批量儲存記錄等）。如果引擎在任何步驟中檢測到錯誤，引擎将復原違規操作和所有副作用，删除導緻錯誤的行，然後繼續，嘗試批量處理剩餘的行子集。此過程周遊每個連續的階段，直到引擎可以送出行的子集而沒有任何錯誤。
注意：使用者可以使用全有或全無模式進行批量操作。批量操作期間觸發器的執行受制于限制工作量的内部調控器。
4、 Schema修改
對對象定義的某些類型的修改需要的不僅僅是簡單的 UDD 中繼資料更新。在這種情況下，Salesforce平台使用有效的機制來幫助減少對整個雲資料庫服務的整體性能影響。
● 示例1，将列資料類型從選項清單修改為文本。Salesforce平台首先為列的資料配置設定一個新槽，批量複制與目前值關聯的選擇清單标簽，然後更新列的中繼資料，使其指向新槽。雖然所有這些都發生了，但對資料的通路是正常的，應用程式繼續運作而沒有任何明顯的影響。
● 示例2，将彙總字段添加到對象。平台使用高效的批量操作在背景異步計算初始彙總。當背景計算正在進行時，檢視新字段的使用者會收到訓示：平台目前正在計算字段值。
五、基于平台的應用開發
開發人員如何建立架構的基礎中繼資料，然後建構管理資料的應用程式。該中繼資料和資料存儲在上一節中描述的平台資料層中。
1、 無代碼和低代碼
Salesforce平台提供了可視化界面，用于支援應用程式建構過程的所有方面，包括建立應用程式的資料模型（包括對象及其字段以及關系）、安全和共享模型（包括使用者、檔案和角色層級）、使用者界面（包括頁面布局、資料輸入表單和報表）、建立工作流和程式設計邏輯（存儲過程和觸發器）。
例如，Salesforce Flow 可以輕松實作各種用例的自動化，Flow Builder UI（如下所示）能夠以圖形方式設計和實施與使用者互動的工作流，通過按計劃時間或事件觸發自動啟動工作流。
低代碼平台可以使使用者輕松開發和自定義應用程式，而無需（或很少）代碼。例如：
● 無需任何代碼即可輕松建構平台原生 UI。
● 為包含敏感資料的對象定義文本字段時，支援加密機制。
● 支援聲明字段驗證規則，比如以確定 LineItem 對象的 Quantity 字段始終大于零。
● 支援計算公式字段，并可以輕松地将計算字段添加到對象。例如，使用者可以向 LineItem 對象添加一個字段來計算 LineTotal 值。
● 支援彙總字段，其是一個跨對象字段，可以輕松聚合父對象中的子字段資訊。例如，使用者可以根據 LineItem 對象的 LineTotal 字段在 SalesOrder 對象中建立一個 OrderTotal 彙總字段。
注意：在實作上，平台使用原生資料庫功能實作公式和彙總彙總字段，并在運作時重新計算值。
2、 APIs
Salesforce平台提供了開放的、基于标準的 API，開發人員可以使用它們來建構應用程式，包括RESTful 和 Web 服務（基于 SOAP）API 。使用這些不同的 API，應用程式可以：
● 操縱描述應用程式模式的中繼資料
● 建立、讀取、更新和删除 (CRUD) 業務資料
● 批量加載或異步查詢大量記錄
● 以安全且可擴充的方式公開近乎實時的資料流
3、 查詢語言
（1）Salesforce 對象查詢語言 (SOQL)
應用程式可以使用Salesforce 對象查詢語言 (SOQL)建構簡單但功能強大的資料庫查詢。類似于結構化查詢語言 (SQL) 中的 SELECT 指令，SOQL 使使用者能夠指定源對象、要檢索的字段清單以及在源對象中選擇行的條件。例如，以下 SOQL 查詢傳回名稱等于字元串“Acme”的所有客戶記錄的 ID 和名稱字段的值。
SELECT Id, Name FROM Account WHERE Name = 'Acme'
（2）Salesforce 對象搜尋語言 (SOSL)
平台還包括一個全文、多語言搜尋引擎，可以自動索引所有與文本相關的字段。應用程式可以通過使用Salesforce 對象搜尋語言 (SOSL)來執行文本搜尋，進而利用這個預內建的搜尋引擎。
與一次隻能查詢一個對象的 SOQL 不同，SOSL 使使用者能夠同時搜尋多個對象的文本、電子郵件和電話字段。例如，以下 SOSL 語句在 Lead 和 Contact 對象中搜尋姓名字段中包含字元串“Joe Smith”的記錄，并從找到的每條記錄中傳回姓名和電話号碼字段。
FIND {"Joe Smith"} IN Name Fields RETURNING lead(name, phone), contact(name, phone)
4、 Apex 和 Pro-Code 應用程式開發
Apex在許多方面與 Java 相似，是一種功能強大的開發語言，開發人員可以使用它來将過程邏輯集中在他們的應用程式模式中。Apex代碼可以聲明程式變量和常量，執行傳統的流程 控制語句（if-else、循環等），執行資料操作操作（insert、update、upsert、delete），執行事務控制操作（setSavepoint、rollback）。
可以使用兩種不同的形式将 Apex 程式存儲在平台中：
● 作為應用程式在必要時執行的帶有方法（類似于傳統資料庫用語中的存儲過程）的命名 Apex 類；
● 作為在特定資料庫之前或之後自動執行的資料庫觸發器操縱事件發生。
無論采用哪種形式，平台都會編譯 Apex 代碼并将其作為中繼資料存儲在 UDD 中。組織第一次執行 Apex 程式時，平台的運作時解釋器将程式的編譯版本加載到該組織的 MRU（最近使用的）緩存中。此後，當來自同一組織的任何使用者需要使用相同的例程時，平台可以通過共享已在記憶體中的準備運作程式來節省記憶體并避免再次重新編譯程式的開銷。
通過在各處添加一個簡單的關鍵字，開發人員可以使用 Apex 來支援許多獨特的應用程式需求。例如，開發人員可以将方法公開為自定義 RESTful 或基于 SOAP 的 API 調用，使其可異步排程，或将其配置為批量處理大型操作。
Apex 不僅僅是“另一種程式語言”。它是一個不可或缺的平台元件，可幫助系統提供可靠的多租戶。例如，Salesforce平台會自動驗證類中所有嵌入的 SOQL 和 SOSL 語句，以防止代碼在運作時失敗。然後，Salesforce平台為有效類維護相應的對象依賴資訊，并使用它來防止中繼資料發生更改，進而會破壞相關代碼。
許多标準 Apex 類和系統靜态方法為底層系統功能提供簡單的接口。例如，插入、更新和删除等系統靜态 DML 方法有一個簡單的布爾參數，開發人員可以使用它來訓示所需的批量處理選項（全部或全部，或部分儲存）；這些方法還傳回一個結果對象，調用例程可以讀取該對象以确定哪些記錄未成功處理以及原因。Apex 和平台功能之間直接聯系的其他示例包括内置電子郵件類和 XmlStream 類。
·
六、小結
作為 Sales Cloud 和 Service Cloud 等應用程式的基礎，Salesforce 是一個經過驗證的應用程式開發平台，來自全球的企業和服務提供商已經建構了數百萬個業務應用程式，包括供應鍊管理、計費、會計、商務、合規性跟蹤、人力資源管理等等。
Salesforce平台獨特的多租戶、中繼資料驅動的架構專為雲設計，可靠、安全地支援關鍵任務、網際網路規模的應用程式。
使用基于标準的 API 和原生開發工具，平台開發人員可以輕松建構現代 Web 或移動應用程式，包括應用程式的資料模型（包括對象和關系）、業務邏輯（包括工作流和驗證）等等。
Salesforce 通過托管方式部署生産應用程式，可確定依賴Salesforce平台的所有應用程式具有出色的性能、可擴充性和可靠性。同時，Salesforce 持續監控和收集來自平台應用程式的操作資訊，以幫助改進現有應用程式和指導建立新的應用程式。
（資料來源于Salesforce.com）
關注公衆号領取大禮包