Salesforce內建：在架構層面上需要考慮的5個問題

無論是将 Salesforce 中其他部門的資料和舊系統（SAP、Oracle、Microsoft 等無所不包）中的資料實時合并為 Salesforce 對象，還是系統內建背景其他辦公系統、社群等，你都需要一個內建工具。而一個統一的、面向未來的平台，可以實作多種類型的內建，包括 API 內建、資料內建、業務邏輯內建和使用者界面內建。

如何從您的Salesforce內建解決方案中獲得最大收益？盡管所有組織和應用程式都是不同的，但是建議您在設計Salesforce內建解決方案時在架構層面上考慮以下幾個問題。

1.牢記Org政策

“Org”是我們所稱的Salesforce的一個特定執行個體。在許多組織中，跨不同業務部門有多個Orgs在使用，并且許多Orgs之間需要連接配接。雖然從技術上講，這可以通過各種方式實作，但從戰略角度來看，了解Salesforce Orgs 本身的整合或持續分離的長期計劃是值得的。我們稱之為“Org政策”。

在大多數情況下，漫長的映射是不可行的，但是，花時間去考慮Org政策是值得的，因為它促使我們思考一些關鍵性的問題，例如：

• 對于Org我們的政策是什麼?目前的結構是否支援或阻礙了我們的業務？內建工作是否掩蓋了更根本的問題？

• 當有更好的業務用例用于在Salesforce平台上尋找內建的AppExchange解決方案時，我們是否正在解決內建問題？

• 通過啟動Org整合過程實作更大的業務收益時，我們是否正在執行一項重要的內建項目？

2.将Governor Limits因素納入您的體系結構

Governor Limits是Salesforce用來確定所有租戶在其多租戶體系結構中表現良好的護欄。它們為Salesforce應用程式在一個Org内的資源消耗提供了界限，例如每個事務的查詢數量，長時間API調用，和API請求總數。

由于違反Governor Limits通常會導緻業務流程失敗，關鍵是要了解與給定的內建相關的Governor Limits，以便對各種場景進行模組化以了解可能的違反情況。非功能性要求運用針對Governor Limits的潛在解決方案，是以，關鍵是所采用的體系結構方法要适時地捕獲它們。

Anypoint Platform可以促進多種應對政策。例如，在Salesforce外部緩存或複制資料可以減輕Governor Limits對于流量大的應用程式(如移動app)的阻礙 。使用節流政策保護組織可能是另一種方法。

在某些情況下，需要購買額外容量以擴充限制，但是對于整體解決方案而言，這些額外的成本是需要考慮的一個因素。

3.請記住，Apex不是中間件

Apex是一種類似于Java的程式設計環境，使組織能夠使用自定義業務邏輯擴充其 Orgs的功能，而開箱即用的配置不滿足需求。它是一組強大的功能，允許組織在其Salesforce Orgs中建立自定義APIs，并調用第三方APIs擷取額外資料。是以，許多開發人員傾向于将Apex擴充到其預期用途之外，并使用它來編寫類似中間件的功能，而不是使用像Anypoint Platform這樣的專業內建和API平台。

Apex既沒有針對中間件應用程式通常所需對複雜的處理進行優化的設計，并且局限于Governor Limits定義了它的真正目的。如果您使用的是Apex而不是AnypointPlatform或其他中間件來解決以下問題，那麼您應該重新考慮您的設計：

• 在Salesforce和第三方系統的專有格式之間進行資料轉換。

• 在不同的第三方端點之間路由或擴充。

• 跨多個系統的服務的複雜編排。

• 在應用程式之間提供消息隊列功能。

特别是Salesforce和其他雲端應用內建時，應盡量避免直接基于Apex代碼方式去內建。因為這種方式apex代碼需要負責資料轉換、接口出錯處理、重試等工作（而這些工作通常是由中間件完成的），需要花費大量時間在內建開發、問題查找以及維護。建議通過Integration-as-a-Service雲的內建方式。很多供應商提供了雲應用和雲應用的內建服務，如Mulesoft。

4.了解何時将資料遷移至Salesforce

與Salesforce內建時的另一個考慮因素是資料從源應用程式到Org的移動（或其他方式）。從監管到資料流通，有許多影響此考慮的商業因素。從表面上看，Salesforce提供了在Org中建立記錄或通過OData通路遠端系統的選項，您可以使用Anypoint Platform完成這兩項。 此外，還有一些需要注意的問題。

• Org内的資料容量是根據版本或許可證數量配置設定的。您可以購買額外的存儲，但是強烈建議您進行容量規劃和歸檔政策。如果将重要資料移至Salesforce，則這一點尤其重要。

• 如果該用例涉及Salesforce中的大量記錄（數百萬條記錄），請遵循大資料量部署的最佳實踐，如通過報告、查詢或視圖提取資料。

• 如果用例主要是使用Salesforce中的外部資料進行報告，并且儀表闆和資料量很重要，請考慮使用諸如Einstein Analytics之類的輔助工具。（Einstein Analytics 連接配接器為 Sales Cloud Einstein Analytics、Service Cloud Einstein Analytics、Marketing Cloud Einstein Analytics 以及核心 Salesforce 平台 Einstein Analytics 系統提供內建，支援跨核心應用程式使用這些資料見解。）除了提供更豐富的業務分析功能外，它還具有旨在支援分析用例的資料移動功能，并且可以與Org中的“實時”資料內建。

• 當資料流通性很重要且資料不穩定時，通過Salesforce Connect和OData 通路遠端資料可能是一個不錯的選擇。例如，庫存或訂單狀态。盡管“外部對象”看起來與“自定義對象”相似，但是遠端連接配接中固有的額外延遲意味着，根據您的用例，它們的使用可能會對使用者體驗産生影響。

5.了解您的配置選項

還值得記住的是，Salesforce提供了開箱即用的內建選項，而無需編寫代碼。對于簡單的內建需求來說，這些都是很好的選擇，而且如果它們滿足內建需求可以可以節省大量時間，成本和精力。

從Salesforce到Salesforce，可以通過已配置的連結将記錄從一側複制到另一側，進而在兩個單獨的Orgs之間共享記錄。這在與同樣使用Salesforce的合作夥伴一起工作時非常有用。盡管沒有能力進行複雜的轉換以緩解明顯不同的資料結構，但仍可以進行某些字段映射。因為這種方法建立遠端對象的本地副本，是以将消耗接收Org中的資料配置設定。

Salesforce Connect的 Cross-Org Connector具有類似的效果，即可以通過遠端通路資料而不是進行複制來提取來自另一個Org的資料。這類似于使用OData。請注意，這種方法消耗了提供者Org上的API調用，是以，如前所述，根據所涉及的容量，Governor Limits可能會起作用。

最好的Salesforce架構設計，不是簡單采用最新的技術，而是考慮該架構設計是否能帶來業務上的價值。也就是說架構設計時除了上面提到的幾點，需要綜合考慮目前的技術能力和業務政策，充分考慮業務需求、業務藍圖，并且能夠平穩的支援未來3-5年的業務發展。可以說，Anypoint Platform和Salesforce是解決需要複雜內建以支援豐富的客戶和賣方體驗的完美伴侶。借助正确的體系結構，組織可以最大化從工具中實作的價值，并建立一種可以随企業的雄心和期望而擴充的內建方法。

轉載請注明出處：怡海軟體（

https://www.frensworkz.com/

）