适用于：
- Microsoft Cloud for Sustainability
- Microsoft Cloud for Financial Services
- Microsoft Cloud for Healthcare
- Microsoft Cloud for Retail
行业数据模型是各个Microsoft Industry Cloud 的基础。 根据数据资产成熟度级别，将这些解决方案与其他系统集成可能必不可少。
选择适当的集成模式是确保 Microsoft Industry Cloud 解决方案和外部系统之间成功实施的一个关键方面。 本文介绍与集成相关的集成模式、工具和技术，以及在做出决定时需要考虑的因素。
集成需求
第三方系统可能有单独的流程，甚至有不同的业务逻辑。 如果第三方系统使用相同的底层 Industry Cloud common data model (CMD)；将无需通过数据传输、同步和编程来转换数据。
我们在以下场景中使用数据集成模式：
- 不是单个连续管理流程的核心部分的主数据或事务数据。 数据在一个系统中的进程与 Microsoft Industry Cloud 之间同步。
- 在系统之间共享或交换数据（计算需要时）。
- 数据在系统之间共享或交换，因此在一个系统中发生的操作将反映在另一个系统中。
- 来自具有详细数据级别的系统的聚合数据被交换到具有更高级别数据表示的系统。
如何选择正确的集成模式
集成开发有很多技术选项，每个选项有自己的优缺点。 要确定正确的集成扩展模式，可以考虑以下因素，将其放在各个选项之间逐一权衡考虑：
| 决定因素 | 说明 |
|---|---|
| 数据类型和格式 | 要集成的数据类型和格式是什么？ |
| 数据波动性 | 从低波动性/缓慢变化到高波动性/快速变化。 |
| 数据量 | 从少量数据到大量数据。 |
| 数据可用性 | 您希望数据何时准备好（从源到目标）？ 需要实时准备好，还是只需要在一天结束时收集所有数据，然后按计划批次发送到目标？ |
| 服务保护与限制 | 通过应用限制，确保每个人都能获得一致的可用性和性能。 这些限制不应影响执行特殊请求的仅普通用户的客户端。 联机服务的通用模式应用于在发出过多请求时提供错误代码。 |
| 所需的数据转换级别 | 要求将源数据转换或聚合到目标。 |
| 触发器和触发器操作 | 哪个操作会触发将数据从源发送到目标？ 数据到达目标后，哪些特定操作会自动执行？ |
| 错误处理 | 为检测接口是否有任何问题进行监视。 |
| 扩展性 | 处理当前、短期和长期的预期交易量。 |
| 记录系统 | 考虑哪个系统是信息的记录系统或负责人。 |
| 数据流方向 | 目标系统是否需要拉取或源系统是否需要推送？ |
根据这些因素，您可以确定集成模式，并选择正确的工具或技术进行实现。
集成模式
在本节中，我们将探讨可以在与 Dataverse 集成时使用的以下集成模式。
- 实时/同步集成
- 近实时/异步集成
- 批量集成
- 表示层集成
在每个模式中，将呈现唯一结构，此结构可以通过使用一个或多个模式来实现。 后面几节提供对这些模式如何使用特定技术实现的深入了解，以及注意事项和应用模式的适当场景。
实时/同步集成
在源系统需要对其发送的数据做出即时或最小延迟响应的情况下，实时集成必不可少。 当业务用例要求源系统和目标系统始终保持同步，从而确保两个实体之间不间断的数据一致性时，这一要求变得至关重要。 当目标系统需要立即响应以无缝执行正在进行的流程，从而能够及时执行后续操作时，同步集成就变得至关重要。
这种形式的集成通常与同步集成同义。 下图说明了同步集成的常见模式，其中应用程序 A 向应用程序 B 发起请求，然后立即收到响应，从而确保及时且反应迅速的数据交换。
上述技术选择中的一些可以扩展为包含一个中介系统，作为促进交易过程的中继。 此中继选项通过代表源和目标应用程序管理请求和响应的通信，将其有效分离。
您可以使用我们行业云解决方案中提供的不同技术来实现这些同步数据集成模式。 下表提供了关于何时使用它们的最佳做法模式。
| 技术选项 | 数据方向 | 目的 | 使用场景 |
|---|---|---|---|
| Dataverse Web API | 从外部向 Dataverse 拉取/推送数据 | 使用一组标准接口提供 CRUD 操作的 OData v4 实现，提供一个向广泛的技术受众开放的接口。 | 主要用于需要离散 CRUD 操作时的事务应用集成。 还可以用于任何自定义集成，但它具有因限制、并行和重试逻辑导致的复杂性，尤其是在数据量高时。 |
| Microsoft 行业云发布的 API | 从外部向 Dataverse 拉取/推送数据 | 由 Microsoft 行业云创建的自定义 API，用于支持特殊操作，如访问与 Azure 使用相关的排放数据。 | Microsoft 行业云发布的特定操作。 在创建您自己的自定义 API 之前，优先考虑使用这些自定义 API。 |
| 自定义 Dataverse API | 从外部向 Dataverse 拉取/推送数据 | 在 Dataverse 中创建您自己的 API。 | 在一个或多个操作需要合并为单个操作，或者需要公开新类型的触发器事件时。 |
| 虚拟表 | 从 Dataverse 向外部拉取/推送数据 | 连接到外部数据源，将其视为本地 Dataverse 实体。 | 拉取参考数据和少量 CRUD 场景。 |
| 连接器 | 双向 | 支持 Microsoft 服务与外部系统、应用程序和数据源之间无缝交换数据。 | Microsoft 发布的连接器用于常见集成，如将 Microsoft 服务彼此连接以及与第一方应用程序连接。 部署经过验证的已发布连接器来与第三方应用程序专门集成，确保兼容性和可靠性。 当 Microsoft 或合作伙伴连接器不能满足客户的业务需求时，可以使用自定义连接器。 |
近实时/异步集成
在业务流程或操作中不立即要求实时响应的情况下，建议使用异步集成。 通常，当应用程序和系统之间存在大量的消息通信时，将使用异步集成。 异步集成模式确保系统之间的通信不会阻止或减慢进程，从而允许每个系统独立异步地工作。 实现异步集成的一些最常见的方法是使用消息队列、发布-订阅和批处理集成。 您可以根据要求单独使用或组合使用这些集成。 它们通常统称为事件驱动的体系结构 (EDA)。
在以下消息队列模式中，发送方采用事件驱动框架，使用者直接创建与事件的绑定。 发送消息时，接收方将直接收到通知并接收事件消息中包含的数据。
在下面的发布-订阅模式中，发布者以标准发布格式生成消息，然后将其传输到专用的发布/订阅渠道，该渠道可以有一个或多个订阅者。 每个订阅者都会订阅特定渠道或主题，从而可以根据需要接收和处理发布的消息（事件）。 发布-订阅模式是为一对多通信场景选择的，因为多个订阅者可以独立接收和处理消息（事件）。
这些异步数据集成模式可以用不同的选项实现，下表为您提供了可用选项以及何时使用它们的最佳做法。
| 技术选项 | 事件驱动或发布-订阅 | 目的 | 注意事项 | 使用场景 |
|---|---|---|---|---|
| Power Automate | 两个 | 有低代码自动化需求。 | 遵守 Power Automate 和每个连接器限制，如限制。 | 用于 Dataverse 触发流，或者当您希望按计划运行 Power Automate 流时使用。 |
| 基于逻辑应用的自定义连接器 | 事件驱动 | 为解决方案构建数据连接器以从 ISV 解决方案获取数据。 | 在进入生产之前，必须经过隐私、安全和合规性审查。 | 在不存在本机连接器的情况下使用 ISV 集成场景。 |
| 逻辑应用和 Azure 服务总线 | 发布-订阅 | 发布者将消息接收到服务总线和逻辑应用会消耗发送给订阅者应用程序的消息。 | 注意逻辑应用配置和执行限制。 | 用于逻辑应用连接器中的本机触发器以及与多个订阅者进行自定义集成的场景。 |
| Azure Functions、Azure 应用服务的 Web 应用功能和 Azure 服务总线 | 发布-订阅 | 使用消息队列实现应用程序和使用者服务实例之间的通信渠道。 | 考虑消息排序和其他设计注意事项。 | 大量和波动场景：无法使用低代码选项（Power Automate 或逻辑应用）开发集成。 |
| 服务终结点 | 两个 | 将上下文信息发送到队列、主题、webhook 或事件中心。 | 不适用于长期运行的事务。 | 当主要通过直接向目标发送 Dataverse 上下文来满足集成要求时，消息的排序并不重要。 |
批量集成
批处理是在一个批次中收集和传输一组消息或记录以限制话语和开销的做法。 批处理收集一段时间内的数据，然后批量进行处理。 当处理大量数据或处理需要大量资源时，此方法非常有用。 此模式还适用于将主数据复制到用于分析目的的副本存储。
| 技术选项 | 数据方向 | 目的 | 注意事项 | 使用场景 |
|---|---|---|---|---|
| Azure 数据工厂 | 双向 | 创建数据流，转换从 Dataverse 接收或在引入到 Dataverse 之前接收的数据 | 数据工厂服务限制 | 具有复杂、多阶段转换的大量引入或数据导出场景。 |
| Power Automate | 不可用 | 自动化 Microsoft 的工作流和任务 | 可扩展性有限，处理时间长 | 当您需要自动化重复任务、根据事件触发操作以及集成应用程序而不需要大量代码开发时，使用 Power Automate。 |
| Power Query 数据流 | 从外部系统到 Dataverse | 允许您将数据引入、转换和加载到 Dataverse 环境中的数据准备工具。 | 限制 | 目标为 Dataverse 且现有连接器不适合的基本场景以及其他给定 Power BI 场景。 |
| Azure Synapse 管道 | 双向 | 创建管道，转换从 Dataverse 接收或在引入到 Dataverse 之前接收的数据 | 不可用 | 分析和数据仓库场景。 |
| Azure Synapse Link for Dataverse | 从 Dataverse 到 Azure Synapse Analytics 或 Azure Data Lake Storage v2 (ADLS) | 将 Dataverse 数据复制到 Azure Synapse Analytics 或 ADLS v2，让您能够对数据运行分析、商业智能、机器学习和自定义报告场景。 | 不支持的表。 | 数据分析和自定义报告。 同时作为数据导出的中间阶段。 |
| Azure 逻辑应用 | 不可用 | 创建具有强大集成功能的工作流。 | 复杂的批处理操作可能需要大量的配置和编排。 未针对专门的批处理场景进行优化。 | Azure 逻辑应用适用于编排业务流程和集成服务。 |
| SQL Server Integration Services | 双向 | 使用第三方连接器从 Dataverse 拉取数据/向其中推送数据。 | 由于它不是 PaaS 解决方案，所以应该评估缩放、内存使用情况、性能和成本。 | 云提取、转换和加载 (ETL) 工具可能不是选项时的任何限制。 |
表示层集成
表示形式或 User Interface Integration 位于系统最上层，是用户会看到以及与之交互的部分。 在某些用例中，需要合并来自不同系统或数据源的信息并将其显示在单个用户界面中，从而在此级别进行集成。 模型驱动应用程序是其中的一个组件，它通过实现数据驱动交互和促进集成环境中的无缝导航，有助于实现全面的用户体验。 当需要维护现有的业务逻辑或应用程序结构，同时轻松实现数据聚合、用户界面自定义或用户体验增强时，就需要进行表示形式集成。 相反，它确实具有固有的限制，包括集成和维护的复杂性、集成系统之间的显著相互依赖性、潜在的性能影响以及数据一致性方面的考虑。
- 启用数据聚合
- 用户界面自定义
- 增强的用户体验
相反，它具有固有约束，包括：
- 集成和维护的复杂性
- 集成系统之间存在重要的相互依存关系
- 可能有性能影响
- 需要考虑数据一致性问题
| 技术选项 | 目的 | 注意事项 | 使用场景 |
|---|---|---|---|
| 第一方本机 UI 集成 | 使用 Microsoft 必应地图、Microsoft Teams 和其他第一方本机 UI 集成。 | 大多数情况下不可自定义。 | 本机 UI 集成支持的特定场景。 |
| 自定义页面 | 将画布应用嵌入到模型驱动应用。 | 已知限制 | 首选低代码集成方法，适合使用画布应用时。 |
| Power Apps component framework (PCF) | 一个自定义的可重复使用控件，用于显示或与最终用户交互，同时保持响应式设计。 | Power Apps 组件限制框架。 | 在没有画布应用的情况下，在模型驱动下开发自定义 UI 的首选方法。 |
| Power BI 磁贴 | 在模型驱动应用窗体中显示 Power BI 磁贴。 | Power BI 许可，Power BI 数据的授权。 | 在模型驱动应用中显示 Power BI 磁贴 |
| Power BI embedded 仪表板 | 在模型驱动应用中显示 Power BI embedded 仪表板。 | Power BI 许可，Power BI 数据的授权。 | 显示在 Power BI 中托管的分析。 |
| 作为 HTML iFrame 嵌入 | 将其他系统 UI 嵌入模型驱动应用。 | 单一登录 (SSO)、跨源资源共享 (CORS) 配置和响应式设计。 | 没有可用服务的复杂 UI 场景。 |
| 自定义 Web 资源 | 在模型驱动应用中创建自定义 UI 布局。 | 评估自定义 UI 的辅助功能和响应式设计。 | 其他 UI 集成不是选项的场景。 |
集成模式摘要
在软件集成的世界里，有不同模式和机制可用于在不同的系统之间交换数据。 每个模式各有优缺点，选择正确的模式会极大地影响集成系统的性能和效率。
下表汇总了以下集成模式：实时或同步集成、异步集成、批处理集成和表示层集成。 您可以探索每个模式的机制、触发器、优点、缺点和用例，以帮助您在为系统选择集成方法时做出明智的决定。
| 集成模式 | 机制 | 触发器 | 优点 | 缺点 | 使用场景 |
|---|---|---|---|---|---|
| 实时或同步 | 数据将同步交换，通过点对点集成或使用中继调用操作。 | 用户操作或系统事件。 | 快速请求和响应往返行程。 实时值和信息。 | 一般来说，这不是最佳做法，因为会存在流程卡住以及导致紧密耦合集成的风险。 因暂时性错误产生连锁反应的风险。 对延迟敏感。 | 在实时信息至关重要时使用。 |
| 异步 | 数据按照定期计划或作为使用消息模式的稀疏源在无人参与的情况下进行交换或引入。 | 计划一段时间或由源系统发布的新消息触发。 | 系统的松散耦合使解决方案更加可靠。 基于时间和资源进行负载均衡。 它可以非常接近实时。 及时处理错误。 | 跨系统更改的响应和可见性有延迟。 | 低数据量或中等数据量的几乎实时的数据同步需求。 |
| 批处理 | 批处理是在一个批次中收集和传输一组消息或记录以限制话语和开销的做法。 | 计划或手动触发器。 | 非常适合用于消息服务和其他异步集成模式。 单个包更少，消息流量更少。 | 数据新鲜度降低。 如果在消息到达时执行业务逻辑，接收系统中的加载可能会受影响。 | 大量或波动场景（以批处理方式收集和传输一组消息或记录可行），数据复制场景。 |
| 表示层 | 来自一个系统的信息被无缝地集成到另一个系统的 UI。 | 不可用 | 消除了数据同步的复杂性，因为数据保留在原始系统中。 在某些行业中，由于监管要求，它消除了与数据驻留相关的障碍。 | 很难将数据用于处理计算，更复杂的是要满足单一登录、跨源资源共享和授权对齐。 | 当通过直接显示源系统或 UI 而不需要在源系统和目标系统之间同步数据来满足要求时。 |