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

[GrapeCityChina]

在数字化转型潮流席卷各大行业的今天，越来越多的企业开始重视 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 应用集成