每天,數以萬計的企業和數百萬的使用者使用 Salesforce Platform 提供的應用程式在雲端中營運業務。為什麼平台如此成功?為什麼您可以 Trust 支援您的業務?平台為您類似的公司提供哪些獨特好處?

此技術簡報說明 Salesforce Platform 如何使用其獨特的雲端計算軟體結構,為一般使用者提供可靠、可調整且易於自訂的體驗。閱讀本簡要說明後,您將更瞭解讓 Salesforce Platform 成為您業務應用程式引人注目的選擇的基礎技術。

Salesforce Platform 是成功的雲端計算平台和相關應用程式生態系統的重要範例。自千禧年開始,此平台一直是下列項目的基礎:

• 許多常見使用個案 (例如銷售和客戶服務) 的熱門業務應用程式
• 適用於更專業使用個案 (例如財務和醫療照護) 的 產業特定應用程式
• 數百萬個唯一使用個案的 自訂應用程式和應用程式擴充

在很大程度上,Salesforce Platform 非常成功且受歡迎,因為其獨特的軟體結構支援易於建立、使用、自訂和擴充的應用程式,具有卓越的效能和可靠性。平台的軟體結構核心是其多租戶中繼資料驅動的設計。

Salesforce Platform 的軟體結構為:

• 多租戶—區隔並同時支援許多租戶 (組織、業務單位等) 的不同需求。
• 中繼資料驅動—可讓每個租戶使用中繼資料、描述使用者介面 (UI) 和業務邏輯等元素的資料,輕鬆快速地自訂其應用程式和使用者體驗。

當您使用 Salesforce Platform 建立新應用程式物件或撰寫程式碼時,平台不會在資料庫中建立實際表格或編譯任何程式碼。平台只會儲存一些中繼資料,然後在執行階段使用這些資料,以動態將虛擬應用程式元件具體化。此平台可確保每個租戶的中繼資料為專用,且易於更新,而不需要任何鎖定或停機時間,讓每個租戶可以個別建立和自訂應用程式。Salesforce Platform 使用相同的中繼資料來提供自訂 API、RESTful 和 Web 服務 (SOAP 型) 介面,您可以用來將您的應用程式與其他應用程式和自動化程序整合。

現成的解決方案也適用於平台的廣泛應用程式市集 AppExchange。AppExchange 封裝由受信任合作夥伴和獨立軟體廠商 (ISV) 的廣泛生態系統所建立,是協力廠商的中繼資料,描述可用於符合特定業務需求的免費或付費應用程式擴充和完整應用程式。

若要支援此高度可自訂且可擴充的結構,Salesforce Platform 的單一例項會使用:

• 單一共用的 多租戶資料庫,其中包含單一結構描述,可儲存租戶特定的中繼資料與資料。
• 多租戶核心 (應用程式執行階段),可讀取中繼資料和資料,以在執行階段為每個租戶的使用者動態提供租戶特定應用程式、業務邏輯和 API。

此明確區隔 Salesforce 管理的核心與租戶管理的中繼資料,可讓 Salesforce、租戶和 ISV 獨立開發其系統部分,而無須干擾。

為了建立此概觀,此文章的後續章節提供更多關於平台獨特功能的詳細資料,這些功能源自其設計的重要層面,包括:

• 平台資料層
• 平台應用程式開發
• 內部平台處理
• 平台基礎結構

Salesforce Platform 的應用程式執行階段與創新的資料層可以安全地隔離租戶特有的資料、結構描述自訂項目和業務邏輯。在高層級上,結構描述支援各種使用個案:

• 當您建立或自訂應用程式時,平台會將相關中繼資料儲存在共用資料庫表格中,以維護所有租戶的中繼資料。
• 當您使用應用程式讀取或寫入資料時,平台會將您的資料儲存在共用資料庫表格中,以維護所有租戶的資料。
• 在背景中,平台也會在多個表格中維護內部中繼資料,該表格的核心用於最佳化執行階段的要求延遲。

但單一共用資料庫與結構描述如何將每個租戶的資料保持為私人?平台上的每個租戶都稱為一個組織,或簡稱「組織」。共用資料庫表格中的每個組織特定記錄都有 組織識別碼。當核心存取資料庫時,它會使用此唯一識別碼來確保每個組織的活動為專用。

組織特定物件 (以傳統關聯式資料庫說話方式思考表格)、欄位、儲存程序、資料庫觸發等等,都是由平台儲存在少數名為「通用資料字典」(UDD) 的資料庫表格中所描述的虛擬建構。

• MT_Objects 是資料庫表格,其中儲存您為應用程式定義之物件的相關中繼資料,包括物件的唯一識別碼 (ObjID)、您的組織 (OrgID),以及您為物件提供的名稱 (ObjName)。
• MT_Fields 系統表格會儲存您針對每個物件宣告之欄位 (欄) 的相關中繼資料,包括欄位的唯一識別碼 (FieldID)、您的組織 (OrgID)、包含該欄位的物件 (ObjID)、欄位的名稱 (FieldName)、欄位的資料類型、布林值來指示欄位是否需要索引 (IsIndexed),以及欄位在物件中的相對於其他欄位的位置 (FieldNum)。

由於中繼資料是關鍵元件,因此平台必須最佳化對中繼資料的存取權,否則頻繁的中繼資料存取會防止服務調整規模。考慮到此潛在瓶頸,平台會使用大量且複雜的 中繼資料快取,以在記憶體中維護最近使用的中繼資料、避免效能損耗的磁碟 I/O 和程式碼重新編譯,並改善應用程式回應時間。

MT_Data 系統表格會儲存應用程式可存取的資料,該資料會對應至所有組織特定的表格及其欄位,如 MT_Objects 和 MT_Fields 中的中繼資料所定義。每個資料列皆包含識別欄位,例如全域唯一識別碼 (GUID)、擁有資料列的組織 (OrgID),以及包含的物件識別碼 (ObjID)。MT_Data 表格中的每一列也有一個「名稱」欄位,該欄位會儲存對應記錄的「自然名稱」;例如,「帳戶」記錄可能會使用「帳戶名稱」、「個案」記錄可能會使用「個案號碼」等等。

Value0 ...ValueN 彈性資料欄 (也稱為時段) 會儲存應用程式資料,分別對應至在 MT_Object 和 MT_Fields 中宣告的表格和欄位。所有彈性資料欄都使用變數長度字串資料類型,以便儲存任何結構化類型的應用程式資料 (字串、數字、日期等)。如下圖所示,同一個物件的兩個欄位無法對應至 MT_Data 中的相同時段以進行儲存;不過,只要每個欄位源自不同的物件,單一時段即可管理多個欄位的資訊。

MT欄位可以使用數個標準結構化資料類型中的任何一個,例如文字、數字、日期和日期/時間,以及特殊使用的 _rich 結構化資料類型,例如選項清單 (列舉欄位)、自動編號 (自動增量、系統產生的序號)、公式 (唯讀衍生值)、主要-詳細資料關係 (外部金鑰)、核取方塊 (布林值)、電子郵件、URL 等。MT_Field 也可以是必要欄位 (非空值),且具有自訂驗證規則 (例如,一個欄位必須大於另一個欄位),這兩者皆由平台強制執行。

當您宣告或修改物件時,平台會在 MT_Object 中管理一列定義該物件的中繼資料。同樣地,對於每個欄位,平台會在 MT_Fields 中管理列,包括將欄位對應至 MT_Data 中特定彈性資料欄的中繼資料,以儲存對應的欄位資料。由於平台會將物件和欄位定義管理為中繼資料,而非實際資料庫結構,因此系統可以容忍線上多租戶應用程式結構描述維護活動,而不會封鎖其他組織和使用者的同時活動。相較之下,傳統關聯式資料庫系統的線上表格重新定義通常需要暫時鎖定,且通常需要繁琐且複雜的程序和排程的應用程式停機時間。

如先前圖中的簡化表示 MT_Data 所示,彈性資料欄屬於通用資料類型 (變數長度字串),可讓平台在使用各種結構化資料類型 (字串、數字、日期等) 的多個欄位之間共用單一彈性資料欄。

平台使用標準格式儲存所有彈性資料欄資料,並視需要在應用程式讀取資料並寫入資料以彈性資料欄時,使用基礎資料庫系統資料類型轉換函數 (例如 TO_NUMBER、TO_DATE、TO_CHAR)。

MTData 也包含未顯示在上圖中的資料欄。例如,有四個欄可管理稽核資料,包括哪些使用者建立列以及建立該列的時間,哪些使用者上次修改列以及上次修改該列的時間。MT_Data 也包含 _IsDeleted 欄,平台用來指出列何時遭到刪除。

平台也支援將欄位宣告為 字元大物件 (CLOB),以允許儲存最多 32,000 個字元的長文字欄位。針對 MT Data 中具有 CLOB 的每一列,平台會將 CLOB 儲存在名為 _MT_Clob 的表格中,系統可以視需要將其與 MT_Data 中的對應列聯結。

**備註:**平台也會將 CLOB 以索引格式儲存在資料庫之外,以進行快速文字搜尋。如需有關平台文字搜尋引擎的詳細資訊,請參閱 搜尋。

平台會自動索引各種類型的欄位,以提供可調整的效能。

傳統資料庫系統依賴原生資料庫索引,可在資料庫表格中快速找到符合特定條件的欄位特定列。然而,為 MT資料的彈性資料欄建立原生資料庫索引並不實用,因為平台使用單一彈性資料欄來儲存具有不同結構化資料類型之許多欄位的資料。平台會改為透過同步地將標記為索引的欄位資料複製到 _MT_Indexes 樞紐分析表中的適當欄,以管理 MT_Data 的索引。

MT_Indexes 包含強大類型的索引欄,例如 StringValue、NumValue 和 DateValue,平台用來尋找對應資料類型的欄位資料。例如,平台會將 MT_Data Flex 欄中的字串值複製到 MT_Indexes 中的 StringValue 欄位、將日期值複製到 DateValue 欄位等。MT_Indexes 的基礎索引是標準、非唯一的資料庫索引。當內部系統查詢包含參照物件中結構化欄位的搜尋參數時,平台的自訂查詢最佳化程式會使用 MT_Indexes 來協助最佳化相關聯的資料存取作業。

備註:平台可以處理跨多種語言的搜尋,因為系統使用可將字串值轉換為通用且不區分大小寫的格式的個案折疊演算法。MT_Indexes 表格的 StringValue 欄會以此格式儲存字串值。在執行階段,查詢最佳化程式會自動建立資料存取作業,讓最佳化 SQL 陳述式會篩選對應的大小寫折疊的 StringValue,這會對應到搜尋要求中提供的文字表示值。

平台可讓您指出物件中的欄位何時必須包含唯一值 (區分大小寫或不區分大小寫)。考慮到 MT_Data 的配置以及欄位資料的「值」欄共用使用情況,為物件建立唯一的資料庫索引並不實用。(此情況與在上一節中針對非唯一索引的情況類似。)

為支援自訂欄位的唯一性,平台使用 MT_Unique_Indexes 樞紐分析表;此表格與 MT_Indexes 表格非常類似,但 MT_Unique_Indexes 的基礎原生資料庫索引強制執行唯一性。當應用程式嘗試將重複值插入需要唯一性的欄位,或管理員嘗試在包含重複值的現有欄位上強制執行唯一性時,平台會將適當的錯誤訊息傳回給應用程式。

在極少數情況下,平台的外部搜尋引擎 (如 搜尋 中所述) 可能會過載或以其他方式無法使用,且可能無法及時回應搜尋要求。平台會回復次要搜尋機制,以提供合理的搜尋結果,而不是將令人失望的錯誤傳回給一般使用者。

系統會將 回復搜尋實作為直接資料庫查詢,其中包含參照目標記錄其「名稱」欄位的搜尋條件。為了最佳化全域物件搜尋 (跨表格的搜尋),而不需要執行潛在昂貴的聯合查詢,平台會維護記錄所有記錄名稱的 MT_Fallback_Indexes 樞紐分析表。MT_Fallback_Indexes 的更新會在交易修改記錄時同步進行,因此回復搜尋一律可存取最新的資料庫資訊。

MT_Name_Denorm 表格是一種精簡資料表格,會將每個記錄的 ObjID 和名稱儲存在 MT_Data 中。當應用程式需要提供與父系/子系關係有關的記錄清單時,平台會使用 MT_Name_Denorm 表格來執行相對簡單的查詢,此查詢會取用每個參照記錄的名稱,以在應用程式中顯示,例如作為超連結的一部分。

平台提供組織可用來在表格之間宣告關係 (參照完整性) 的關係資料類型。當您使用關係類型宣告物件的欄位時,平台會將該欄位對應至 MT_Data 中的「值」欄位,然後使用此欄位儲存相關物件的 ObjID。

為了最佳化聯結作業,平台會維護 MT_Relationships 樞紐分析表。此系統表格有兩個基本資料庫唯一的複合索引,可視需要在兩個方向進行有效的物件周遊。

只要按幾下滑鼠,平台即可為任何欄位提供歷程記錄追蹤。當組織啟用特定欄位的稽核時,系統會使用內部樞紐分析表作為稽核追蹤,非同步記錄對欄位進行的變更 (舊值與新值、變更日期等) 相關資訊。

所有平台資料、中繼資料和樞紐分析表結構 (包括基本資料庫索引) 都會由 OrgID 使用原生資料庫分割機制進行實際分割。資料分割是資料庫系統提供的已驗證技術,可實際將大型邏輯資料結構分成較小的可管理部分。分割也可以協助改善大型資料庫系統 (例如多租戶環境) 的效能、擴充性和可用性。依定義,每個平台查詢都鎖定特定組織的資訊,因此查詢最佳化程式只需要考慮存取包含組織資料的資料分割,而非整個表格或索引。此常見最佳化有時稱為「分割」。

本節涵蓋應用程式開發人員如何建立結構描述的基本中繼資料,然後建立管理資料的應用程式。該中繼資料與資料會儲存在上一節所述的平台資料層中。

開發人員可以使用平台的瀏覽器型開發環境 (通常稱為平台 設定 畫面) 以宣告的方式建立伺服器端應用程式元件。設定的點選使用者介面支援應用程式結構描述建立流程的所有層面,例如建立應用程式的資料模型 (包括物件及其欄位以及關係)、安全性和共用模型 (包括使用者、設定檔和角色階層)、使用者介面 (包括畫面版面配置、資料輸入表單和報告)、陳述性邏輯 (工作流程) 和程式設計邏輯 (已儲存程序和觸發)。例如,Salesforce 流程可讓您輕鬆自動化各種使用個案。設定的 Flow Builder UI (如下所示) 可讓您以圖形方式設計和實作與使用者互動的工作流程,或根據排程或事件觸發時自動啟動。

「設定」畫面可讓任何人無需 (或極少量) 程式碼,輕鬆開發和自訂應用程式。例如:

• 平台原生 UI 無須任何程式碼即可輕鬆建立。在背景中,原生應用程式 UI 支援所有常見的資料存取作業,包括查詢、插入、更新和刪除。由原生平台應用程式執行的每個資料操作都可以一次修改一個物件,並自動認可個別交易中的每個變更。
• 為包含敏感資料的物件定義文字欄位時,您可以輕鬆地設定欄位,讓平台加密對應的資料,並選擇性地使用輸入遮蔽來隱藏畫面資訊。
• 陳述性 驗證規則是一種簡單的方法,讓組織無須任何程式設計就能強制執行網域完整性規則。例如,您可能會宣告驗證規則,以確保 LineItem 物件的「數量」欄位一律大於零。
• 公式欄位是平台的陳述性功能,可讓您輕鬆將已計算欄位新增至物件。例如,您可以將欄位新增至 LineItem 物件以計算 LineTotal 值。
• 累計摘要欄位是跨物件欄位,可讓您輕鬆彙總父系物件中的子系欄位資訊。例如,您可以根據 LineItem 物件的 LineTotal 欄位,在 SalesOrder 物件中建立 OrderTotal 摘要欄位。

**備註:**在內部,平台會使用原生資料庫功能實作公式和累計摘要欄位,並有效地同步重新計算值作為進行中交易的一部分。

此平台提供數個開放、以 標準為基礎的 API,開發人員可用來建立應用程式。RESTful 和 Web 服務 (SOAP 型) API 皆可存取平台的許多功能。使用這些各種 API,應用程式可以:

• 操作描述應用程式結構描述的中繼資料
• 建立、讀取、更新和刪除 (CRUD) 業務資料
• 大量載入或非同步查詢大量記錄
• 以安全且可調整的方式公開近乎即時的資料串流

應用程式可以使用 Salesforce 物件查詢語言 (SOQL) 建構簡單但強大的資料庫查詢。與結構化查詢語言 (SQL) 中的 SELECT 指令類似,SOQL 可讓您指定來源物件、所要的欄位清單,以及用於在來源物件中選取列的條件。例如,下列 SOQL 查詢會傳回所有「名稱」等於字串「Acme」的「帳戶」記錄其「識別碼」和「名稱」欄位的值。

SELECT Id, Name FROM Account WHERE Name = 'Acme'

平台也包含完整文字的多國語言搜尋引擎,可自動編製所有文字相關欄位的索引。應用程式可以使用 Salesforce 物件搜尋語言 (SOSL) 來執行文字搜尋,以使用此預先整合搜尋引擎。不同於 SOQL,其一次只能查詢一個物件,SOSL 可讓您同時搜尋多個物件的文字、電子郵件和電話欄位。例如,下列 SOSL 陳述式會在名稱欄位中搜尋包含「Joe Smith」字串的「商機」和「連絡人」物件中的記錄,並從找到的每個記錄傳回名稱和電話號碼欄位。

FIND {"Joe Smith"} IN Name Fields RETURNING lead(name, phone), contact(name, phone)

Apex 在許多方面與 Java 類似,是強大的開發語言,開發人員可以用來在應用程式結構描述中集中程序邏輯。Apex 程式碼可以宣告程式變數和常數、執行傳統流程控制陳述式 (若為其他,迴圈等)、執行資料操作 (插入、更新、更新插入、刪除),以及執行交易控制作業 (setSavepoint、 rollback)。

您可以使用兩種不同的形式將 Apex 程式儲存在平台中:作為具名 Apex 類別,其中包含應用程式在必要時執行的方法 (如同傳統資料庫說話中的已儲存程序),或作為在特定資料庫操作事件發生前後自動執行的 資料庫觸發。在任一格式中,平台會編譯 Apex 程式碼,並將其儲存為 UDD 中的中繼資料。當組織第一次執行 Apex 程式時,平台的執行階段解譯器會將編譯的程式版本載入該組織的 MRU (最近使用) 快取。之後,當同一個組織中的任何使用者需要使用相同的例行程序時,平台可以儲存記憶體,並避免透過共用已存在於記憶體中的可執行程式來再次重新編譯程式。

隨著在這裡和在這裡新增簡單的關鍵字,開發人員可以使用 Apex 來支援許多獨特的應用程式需求。例如,開發人員可以將方法公開為自訂 RESTful 或 SOAP 型 API 呼叫、使其可非同步排程,或將方法設定為以批次方式處理大型作業。

Apex 不只是「另一個程序語言」。這是一個整合平台元件,可協助系統提供可靠的多租用。例如,平台會自動驗證類別內所有內嵌 SOQL 和 SOSL 陳述式,以防止程式碼在執行階段失敗。接著,平台會針對有效類別維護對應的物件相依性資訊,並使用該資訊來防止對中繼資料的變更會中斷相依程式碼。

許多標準 Apex 類別和系統靜態方法提供基本系統功能的簡易介面。例如,系統靜態 DML 方法 (例如 insert、update 和 delete) 有簡單的布林值參數,開發人員可以用來指出所需的大量處理選項 (全部或無,或部分儲存);這些方法也會傳回呼叫例項可讀取的結果物件,以判斷哪些記錄未成功處理以及原因。Apex 與平台功能之間的直接連結其他範例包括內建的電子郵件類別和 XmlStream 類別。

在很大程度上,平台的效能與規模良好,因為 Salesforce 以以下兩個重要原則為基礎來建立平台:

• 提供高效率、大規模的基礎平台功能。
• 協助開發人員盡可能有效率地完成所有工作。

平台將這些原則納入平台的獨特處理結構,包括:

• 查詢
• 搜尋
• 大量作業
• 結構描述修改
• 多租戶隔離
• 資源回收筒

大多數現代資料庫系統會使用以成本為基礎的查詢最佳化程式,以考量關於目標表格與索引資料的相關統計資料來決定最佳查詢執行計畫。不過,傳統以成本為基礎的最佳化程式統計資料是針對單一租戶應用程式所設計,無法考慮在多租戶環境中執行查詢的任何指定使用者的資料存取特性。例如,鎖定具有大量資料之物件的特定查詢最有可能會使用不同的執行計畫,針對高可視性的使用者 (可看見所有資料列的管理員),而針對低可視性的使用者 (銷售只能看見自己相關資料列的人員),以更有效率地執行。

為了提供足夠的統計資料來決定多租戶系統中最佳的查詢執行計畫,平台會為每個組織的物件維護一組完整的 最佳化工具統計資料 (租戶、群組和使用者層級)。統計資料會反映特定查詢可能存取的列數,並仔細考量整體組織特定物件統計資料 (例如,整個組織擁有的總列數),以及更精確的統計資料 (例如,特定權限群組或使用者可能存取的列數)。

平台也會維護對特定查詢有幫助的其他類型的統計資料。例如,平台會維護所有自訂索引的統計資料,以顯示對應欄位中非空值和唯一值的總數,以及顯示每個清單值基數的選項清單欄位直方圖。

當現有統計資料不適用或視為沒有幫助時,平台的最佳化工具會使用一些不同的策略來協助建立合理最佳化的查詢。例如,當查詢篩選物件的「名稱」欄位時,最佳化程式可以使用 MT_Fallback_Indexes 表格有效地尋找要求的資料列。在其他情況下,最佳化程式會在執行階段動態產生遺漏的統計資料。

與最佳化工具統計資料一起使用,平台的最佳化程式也依賴內部安全性相關表格 (群組、成員、GroupBlowout 和 CustomShare),以維護組織使用者安全性網域的相關資訊,包括指定使用者的群組成員資格和物件和列的自訂存取權限。此類資訊在決定每位使用者的查詢篩選條件選擇性時十分重要。如需有關平台內嵌安全性模型的詳細資訊,請參閱 平台開發人員基本概念 Trailhead。

下圖中的流程圖說明當平台處理其中一個大型堆疊表格 (例如 MT_Data) 中資料的要求時會發生的狀況。要求可能來自任何數量的來源,例如 API 呼叫或儲存程序。首先,平台會執行考量多重租戶認知統計資料的「預先查詢」。接著,根據預先查詢傳回的結果,服務會建立最佳的基礎資料庫查詢,以在特定設定中執行。

如下表所示,平台可根據提交查詢的使用者和查詢篩選條件的選擇性,以四種不同方式執行相同的查詢。

使用者預期互動式搜尋功能會掃描應用程式資料庫的所有或所選範圍,並傳回含子秒回應時間的排名結果。為了為平台應用程式提供此功能,平台會使用與其交易引擎分開的搜尋引擎。當您更新記錄時,交易引擎會更新核心資料庫,並將相關資料轉送至搜尋引擎進行索引編製。當您搜尋記錄時,搜尋引擎會使用其索引快速處理查詢,並傳回含相關資料庫記錄連結的排名結果。

當應用程式更新文字欄位中的資料 (CLOB、名稱等) 時,稱為索引伺服器的背景流程集區會負責非同步更新對應的索引,搜尋引擎會在核心交易引擎之外維護這些索引。為了最佳化索引流程,平台會在交易認可時,同步地將修改後的文字資料區塊複製到內部「待編製索引」表格,從而提供相對較小的資料來源,將索引伺服器必須從磁碟讀取的資料量最小化。搜尋引擎會自動為每個組織維護個別的索引。

視目前的索引伺服器負載和利用率而定,文字索引更新可能會落後於實際交易。為了避免產生來自過時索引的非預期搜尋結果,平台也會維護最近更新列的 MRU 快取,系統在具體化完整文字搜尋結果時會將這些資料列納入考量。平台會根據每位使用者和每個組織來維護 MRU 快取,以有效支援可能的搜尋範圍。

平台的搜尋引擎使用數種方法最佳化搜尋結果內記錄的排名。例如,系統會考量執行搜尋的使用者其安全性領域,並將較大的權重放在目前使用者可存取的資料列中。系統也可以考慮特定資料列的修改歷程記錄,並將更常更新的資料列排名在相對靜態資料列之前。使用者可以選擇視需要加權搜尋結果,例如,更強調最近修改的列。

交易密集型應用程式在大量結合和執行重複的作業時,產生負擔較少,且執行效能較佳。例如,對應應用程式可能載入許多新列的方式。使用具有插入個別資料列迴圈的例行方法,並在每個資料列插入後執行一個 API 呼叫,是不有效率的方法。更有效率的方法是建立列陣列,並透過單一 API 呼叫來進行例行插入。

透過平台進行有效率的大量處理對開發人員而言很簡單,因為其已填入 API 呼叫。在內部,平台也會大量處理與明確大量作業相關的所有內部步驟。

平台的大量處理引擎會自動考慮在過程中發生任何步驟的個別錯誤。在部分儲存模式中開始大量作業時,引擎會識別已知的開始狀態,然後嘗試在流程中執行每個步驟 (大量驗證欄位資料、大量觸發預先觸發、大量儲存記錄等)。如果引擎在任何步驟期間偵測到錯誤,則引擎會回復違規作業和所有副作用、移除負責故障的資料列,然後繼續嘗試大量處理剩餘的資料列。此流程會迭代每個連續的階段,直到引擎可以認可列子集而不會發生任何錯誤為止。應用程式可以檢查傳回物件,以識別哪些資料列失敗,以及這些資料列所造成的例外狀況。

**備註:**您可以決定是否可以使用全部或無所有模式進行大量作業。此外,在大量作業期間執行觸發會受到限制工作量內部管理員的約束。

物件定義的某些類型的修改需要簡單 UDD 中繼資料更新以外的內容。在此情況下,平台會使用有效的機制,協助降低對整體雲端資料庫服務的整體效能影響。

例如,考量當您將欄的資料類型從選項清單修改為文字時,背景會發生的情況。平台會先為資料欄分配新的時段、大量複製與目前值相關聯的選項清單標籤,然後更新資料欄的中繼資料以指向新的時段。雖然這一切都會發生,但資料的存取權是正常的,且應用程式會繼續運作,而不會有任何明顯的影響。

作為另一個範例,請思考您將累計摘要欄位新增至物件時會發生的狀況。在此情況下,平台會使用有效的大量作業,在背景中非同步計算初始摘要。背景計算進行時,檢視新欄位的使用者會收到指示,表示平台目前正在計算欄位的值。

為了防止惡意或無意中獨占共用的多租戶系統資源,平台擁有與平台程式碼執行相關聯的一組管理員和資源限制。例如,平台會密切監控程式碼指令檔的執行,並限制其可使用的 CPU 時間、可使用的記憶體、可執行的查詢和 DML 陳述式數量、可執行的數學計算數量、可進行的輸出 Web 服務呼叫數量等等。平台最佳化工具認為執行成本過高的個別查詢會將執行階段例外投放給呼叫者。雖然這類限制可能聽起來有些限制,但對於所有相關應用程式而言,這些限制是保護共用資料庫系統整體延展性和效能所必需的。長期而言,這些措施有助於在開發人員中推廣更好的編碼技巧,並為使用平台的每個人建立更好的體驗。例如,開發人員一開始嘗試編碼一次無法有效地更新一列數千列的迴圈,會因為資源限制而收到執行階段例外,然後開始使用平台高效率的大量處理 API 呼叫。

為了進一步避免寫作不良應用程式導致的潛在系統問題,部署新的生產應用程式是嚴格管理的程序。在組織能夠將新應用程式從開發轉換為生產狀態之前,Salesforce 需要單元測試來驗證應用程式平台程式碼例項的功能。提交的單元測試必須涵蓋至少 75% 應用程式的來源程式碼。

Salesforce 會在平台的 Sandbox 開發環境中執行提交的單元測試,以判斷應用程式程式碼是否會對整體多租戶族群的效能和延展性造成負面影響。個別單元測試的結果會指出基本資訊,例如執行的總行數,以及測試未執行之程式碼的特定資訊。

在 Salesforce 驗證應用程式代碼以供生產時,應用程式的部署流程會包含單一交易,該交易會將所有應用程式的中繼資料複製到生產平台例項,並重新執行對應的單元測試。如果流程的任何部分失敗,平台只會回復交易並傳回例外,以協助疑難排解問題。

**備註:**Salesforce 會在平台的每個開發版本中,針對每個應用程式重新執行單元測試,以主動瞭解新系統功能和增強功能是否會中斷任何現有的應用程式。

生產應用程式上線後,平台的內建效能設定檔會自動分析生產應用程式,並為管理員提供相關聯的回饋意見。效能分析報告包含關於緩慢查詢、資料操作和子路由的資訊,您可以檢閱並用來調整應用程式功能。系統也會記錄並將執行階段例外的相關資訊傳回給管理員,以協助他們除錯應用程式。

當應用程式刪除物件中的記錄時,平台只需在 MT資料中修改資料列的 IsDeleted 欄位,即可將資料列標記為要刪除。此動作有效地將資料列放入稱為 _Recycle Bin。此平台可讓您從資源回收筒還原所選資料列,最多 15 天,然後從 MT_Data 永久移除這些資料列。平台會根據該組織的儲存空間限制,限制其針對組織維護的記錄總數。

當作業刪除「主要 - 詳細資料」關係中涉及的父系記錄時,平台會自動刪除所有相關子系記錄,前提是這樣做不會違反任何參照完整性規則。例如,當您刪除 SalesOrder 時,平台會自動將刪除串連至從屬 LineItems。如果您後續從資源回收筒還原父系記錄,系統也會自動還原所有子系記錄。

相反地,當您刪除參照的父系記錄涉及對應關係時,平台會自動將所有從屬金鑰設定為 null。如果您後續還原父系記錄,平台會自動還原先前空值的對應關係,但刪除與還原作業之間已重新指派的關係除外。

「資源回收筒」也會儲存捨棄的欄位及其資料,直到組織將其永久刪除或經過設定天數為止 (視何者先發生)。在此之前,整個欄位及其所有的資料都可供還原。

敏捷是企業在現代世界中成功的關鍵。Salesforce Platform 的基礎層級可協助您的業務應用程式快速適應新的挑戰,讓您可以繼續專注於業務,而非基礎結構。

隱藏的 基礎結構 (例如基礎服務和運算資源),這是 Salesforce Platform 中支援上層的基礎技術。Hyperforce 是 Salesforce Platform 基礎結構,以 100% 可再生能源和 Net-Zero 為基礎,可解決重要客戶挑戰,包括合規性、 Trust 和延展性

在多個地理位置營運的企業必須遵循資料管理的新、不斷發展和不斷變化的法規。由於 Salesforce 正在數量不斷增加的國家/地區部署 Hyperforce,因此目前以 AWS 區域可用性為基礎,平台應用程式和使用者可以以符合嚴格資料儲存或資料保護標準的方式執行其敏感工作量。例如,透過 Hyperforce 技術支援的 Salesforce 歐盟 (EU) 作業區域,歐盟企業可以輕鬆將資料保留在歐盟。

安全性、可靠性和可用性是非功能需求,每個業務應用程式都必須考量,才能將 Trust 承諾提供給其使用者。透過 Hyperforce,Salesforce Platform 可讓企業輕鬆地提供信任的業務應用程式。

• 安全性— Hyperforce 擁有原生端對端加密靜態與傳輸中客戶資料。Hyperforce 的 Zero Trust 結構會強制執行嚴格的身分驗證流程,以確保沒有資源的隱含存取權。Hyperforce 也使用最低權限的 原則,確保作業在正確時間內獲得批准,且存取權量正確。
• 可靠性— Hyperforce 的每個例項都使用多個雲端可用性區域和現代化方法,以加速事件回應,以提供高可用性和彈性的平台。
• 可用性— Hyperforce 的現代 CI/CD 管道與藍色/綠色應用程式版本可將應用程式維護期間降到每年一分鐘。

Salesforce 是如 Sales Cloud 和 Service Cloud 等應用程式的基礎,是一個經過驗證的應用程式開發平台,個別企業和服務提供者可在其中建立數百萬個業務應用程式,以用於各種使用個案,包括供應鏈管理、帳單、會計、商務、合規性追蹤、人力資源管理和索賠處理。平台的獨特、多租用、中繼資料驅動的結構是針對雲端專門設計,並可靠且安全地支援任務關鍵、網際網路規模的應用程式。平台開發人員可以使用標準型 API 和原生開發工具,輕鬆建立現代 Web 或行動應用程式的所有元件,包括應用程式的資料模型 (包括物件和關係)、業務邏輯 (包括工作流程和驗證)、與其他應用程式的整合等等。

自成立以來,Salesforce 的工程師已針對多重租賃最佳化此平台,其中包含可讓平台應用程式調整規模以符合不斷變化的業務需求的功能。整合式系統功能 (例如大量資料處理 API、Apex、完整文字搜尋引擎和獨特的查詢最佳化程式) 可協助讓從屬應用程式高效率且可調整,而開發人員僅需少量或無需任何努力。

Salesforce 用於部署生產應用程式的受管理方法,可為依賴該平台的所有應用程式確保卓越的效能、延展性和可靠性。Salesforce 會持續監視並收集平台應用程式的作業資訊,以協助推動增量改善和系統新功能,以立即使現有和新應用程式受益。

Steve Bobrowski 是一位成功的企業家和技術領導者,自 2008 年起曾在許多領先的企業軟體公司工作,包括在整個 Salesforce 中的各種角色。Steve 目前在 Salesforce 的 CTO 辦公室工作,協助公司制定技術結構策略。

Tom Leddy 是 Salesforce 的建築師福音師。他透過協助建立資源、工具和指引來協助讓結構設計師執行其最佳工作,來支援全球 Salesforce 結構設計師社群。在 Twitter 上與 Tom 連線。