Salesforce 平台集成架构设计注意事项

无论是将 Salesforce 中其他部门的数据和旧系统（SAP、Oracle、Microsoft 等无所不包）中的数据实时合并为 Salesforce 对象，还是系统集成后台其他办公系统、社区等，你都需要一个集成工具。而一个统一的、面向未来的平台，可以实现多种类型的集成，包括 API 集成、数据集成、业务逻辑集成和用户界面集成。

如何从您的Salesforce集成解决方案中获得最大收益？尽管所有组织和应用程序都是不同的，但是建议您在设计Salesforce集成解决方案时在架构层面上考虑以下几个问题。

1.牢记Org策略

“Org”是我们所称的Salesforce的一个特定实例。在许多组织中，跨不同业务部门有多个Orgs在使用，并且许多Orgs之间需要连接。虽然从技术上讲，这可以通过各种方式实现，但从战略角度来看，了解Salesforce Orgs 本身的整合或持续分离的长期计划是值得的。我们称之为“Org策略”。

在Orgs之间交换数据或信息时，Salesforce提供了Salesforce2Salesforce的方式；也可以通过RESTful WebService来交换数据；也可以通过Hub/Spoke的方式（一种非常高效只读的Orgs之间数据交换方式）。

在大多数情况下，漫长的映射是不可行的，但是，花时间去考虑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/）