用好 DIV 和 API，在前端系统中轻松嵌入数据分析模块

在数字化转型潮流席卷各大行业的今天，越来越多的企业开始重视 BI（商业智能）技术的部署和应用，期望从不断增长的数据资源中获得更多业务价值，从而提升利润、控制风险、降低成本。BI 能整合、组织和分析数据，将数据转化为有价值的信息，为企业管理和决策提供支持，成为企业迎接变革和商业创新的决胜因素。

由于 BI 技术的重要性，企业更希望在现有的业务平台和系统中按需集成 BI 能力，从而在各类场景中充分发挥数据分析带来的优势，满足企业日益多样化的数据分析诉求，使 BI 能力与企业业务深度融合。然而，市面上常见的 BI 工具大都是独立、打包的整体方案，很难与前端的业务系统集成在一起，在实践中常常无法满足需求。在这样的背景下，嵌入式 BI 应运而生。

所谓嵌入式 BI，就是在企业现有业务系统中按需集成各种类型的数据分析能力。这种集成工作一般需要考虑两个要点：一方面，它本质上是现有业务系统的一次升级过程，需要关注升级内容与原系统的兼容性、稳定性、安全性等指标；另一方面，业务侧一般希望深度集成专业的数据分析组件，而不是任意挂载一个简单的模块应付了事。这两个要点为开发团队提出了更高的要求和挑战，需要团队认真对待。

嵌入式数据分析模块架构探索

对于很多中小企业而言，软件开发团队并不具备独立开发 In-House 嵌入 BI 方案的能力，需要寻求外部第三方供应商的支持。行业中也出现了很多专业的外部供应商，他们探索出了一些经过市场验证的嵌入式 BI 最佳实践。在这里我们一起探讨数据分析模块应该如何嵌入现有业务系统：

如上所示，对于业务人员来说，应用功能层的数据分析仪表板、图表、设计器、门户等模块，就是嵌入式 BI 方案展现出来的最终效果。其中，模块的内容和形态一般是根据业务需求决定的，例如为某个销售看板集成一些销售数据动态图表，实时反映各地区的当前销售状况。由于业务需求往往比较多样化，嵌入模块的内容和形态也非常多变，这就要求前端技术层具备更强的适应能力。前端技术层在过去普遍采用 URL iFrame 架构来实现模块嵌入，如今更复杂的需求更多用 DIV 方式打造解决方案。API 层对于嵌入式 BI 方案是非常重要的。例如，API 允许根据用户类型打开和关闭工具栏，只允许根据使用规则显示指定的数据源，并支持创建具有不同过滤器和选项的仪表板。专业的嵌入式 BI 可以通过调用 API，在应用软件内对仪表板/报表进行权限管理、分类管理、重命名、删除等深度集成操作，而应用软件和 BI 软件之间的接口对最终用户是完全透明的。当然，对于较为简单的业务需求而言，嵌入式 BI 架构中取消 API 层，或者只有简单的 API 层也是可以接受的。主流实现方案对比如上所述，对于开发团队而言，嵌入式 BI 方案的技术选型关键在于 DIV 和 IFrame 架构的选择，以及是否加入强大的 API 层。IFrame 架构在早期的嵌入式 BI 市场非常流行，因其原理简单、实现方便、开发周期较短，使企业能够快速实现初期的嵌入式 BI 需求。但这种方式虽然简单，局限性也是很大的。例如，使用 IFrame 就很难在系统中深度集成数据分析模块。IFrame 更像曾经的 Flash 元素，是一种相对独立的模块。它与页面的其他元素很难融合和互动，即便可以实现也需要付出大量努力和代价。如上所示，对于业务人员来说，应用功能层的数据分析仪表板、图表、设计器、门户等模块，就是嵌入式 BI 方案展现出来的最终效果。其中，模块的内容和形态一般是根据业务需求决定的，例如为某个销售看板集成一些销售数据动态图表，实时反映各地区的当前销售状况。由于业务需求往往比较多样化，嵌入模块的内容和形态也非常多变，这就要求前端技术层具备更强的适应能力。前端技术层在过去普遍采用 URL iFrame 架构来实现模块嵌入，如今更复杂的需求更多用 DIV 方式打造解决方案。此外，以 Wyn 商业智能为例，其 BI 模块还可以同泛微、用友 U8+、企业微信和钉钉等常用的企业信息系统集成，增强它们的数据分析能力。API 层对于嵌入式 BI 方案是非常重要的。例如，API 允许根据用户类型打开和关闭工具栏，只允许根据使用规则显示指定的数据源，并支持创建具有不同过滤器和选项的仪表板。专业的嵌入式 BI 可以通过调用 API，在应用软件内对仪表板/报表进行权限管理、分类管理、重命名、删除等深度集成操作，而应用软件和 BI 软件之间的接口对最终用户是完全透明的。当然，对于较为简单的业务需求而言，嵌入式 BI 架构中取消 API 层，或者只有简单的 API 层也是可以接受的。

主流实现方案对比

如上所述，对于开发团队而言，嵌入式 BI 方案的技术选型关键在于 DIV 和 IFrame 架构的选择，以及是否加入强大的 API 层。IFrame 架构在早期的嵌入式 BI 市场非常流行，因其原理简单、实现方便、开发周期较短，使企业能够快速实现初期的嵌入式 BI 需求。但这种方式虽然简单，局限性也是很大的。例如，使用 IFrame 就很难在系统中深度集成数据分析模块。IFrame 更像曾经的 Flash 元素，是一种相对独立的模块。它与页面的其他元素很难融合和互动，即便可以实现也需要付出大量努力和代价。

相比之下，基于 JavaScript 的 DIV 层级的无缝嵌入方案，可以利用原生的 JavaScript 将整个仪表板等以 DIV 的方式集成到项目中。嵌入的图表元素具有高度开放的接口，能够与其他元素进行数据交互。甚至 BI 软件整体都可以通过 DIV 架构直接嵌入到现有系统中，确保了无缝和直观的用户体验。即便当前的业务需求仅仅停留在简单的图表展示层面，考虑到未来的升级和扩展潜力，开发团队还是最好选择 DIV 架构来设计 BI 嵌入方案。另一方面，API 层能够大大简化业务人员对嵌入式 BI 模块的操作，往往是开发团队需要重点实现的功能目标。GraphQL API 可以让所有界面操作均可通过 API 调用简单完成。下图就是一个简单的 API 调用示例：

GraphQL API 不需要为不同的对象操作提供不同的 URL。不同对象的不同操作均通过一个统一的 URL 调用，只是各类操作提交的数据不同。可以看到，GraphQL API 的操作非常易于上手，可以大大方便开发团队和业务团队，满足各类复杂的业务需求。下面来看 Wyn 商业智能提供的一个数据查询 API 的操作示例，从中可以体会 API 的低门槛与便利性：

当我们需要调用某个数据集，可以通过该 API 以 POST 或 GET 两种方式完成操作。（示例 URL 为http://10.32.5.7:51980/api/v1... *from Categories&token=27487CA0BE14CF599444E8553E5E07F78D5D1AB8646302A2715E4802FCB95F08&format=json；调用数据集的 URL 格式为 POST/GET api/v1/dataset/{document id}/query。）

POST 方式，有效负载格式：

GET 方式，查询参数

option1, option2 ...为选项参数，前缀 $表示数据集参数，多个值通过多次重复一个参数来表示。Option 选项参数具体信息如下：

只需几行简单的代码即可完成数据集的调用操作，这对嵌入式 BI 场景而言无疑是非常有价值的。API 层与 DIV 嵌入结合，可以为嵌入式 BI 场景需求提供令人满意的解决方案。总体而言，虽然 iFrame 架构在入门门槛、开发成本和周期方面具有一定优势，但随着企业数据分析需求愈加复杂，DIV 架构很快就能表现出更强的扩展能力和适应性。团队可以在初期选择 iFrame 实现，并在需求提升后迁移到 DIV 方案。与此同时，开发团队往往在一开始就要考虑 API 层的实现，为业务团队带来更多便利，并为后期的开发工作打好基础。

嵌入式 BI 选型：如何挑选最适合自己的方案？

开发团队在选择嵌入式 BI 方案时，除了关注方案的开发周期、开发难度外，一般还要考虑定价模型、云端支持、业务系统集成支持等要素：

• 成本。不仅要考虑初期的开发成本，还要考虑长期的总体拥有成本，将未来的功能扩展、安全性增强等需求纳入成本计算。

• 定价模型。第三方提供的嵌入式 BI 方案常常有多种定价模型可选，例如按用户/服务器/CPU 定价，或者按照真实使用量、使用时间定价等。一般来说，相对固定的定价模型更有利于企业用户一方。

• 云端支持和业务系统集成支持。嵌入式 BI 能否支持公有云、私有云、本地部署、混合部署等多种模式，在云计算时代也是很重要的考虑因素。此外，与其他流行第三方企业系统（ERP、CRM、OA 等）集成的能力可以大大扩展嵌入式 BI 方案的应用范围。

• 授权管理/安全性。嵌入式 BI 模块经常会与企业机密数据互动，这就要求嵌入式 BI 方案具备良好的授权管理能力和安全性，避免模块本身成为企业安全性防线的薄弱环节，造成敏感数据的意外泄露事件。

考虑到以上要素，实践中中小企业和开发团队更适合选择成熟的第三方嵌入式 BI 方案来满足自身需求。以 Wyn 的嵌入 BI 方案为例，其不仅提供了完善的功能、基于 GraphQL 的便捷 API 集成，还支持强大的授权管理、增强安全特性，兼容多种云端部署模式，且能够方便地集成到用友、企业微信等系统中。该方案既可以嵌入部署也可以独立使用，具备良好的伸缩能力。想要进一步了解关于嵌入式 BI 的相关内容，可以查看下方内容：

- 嵌入式BI- 与SaaS应用集成