在數字化轉型潮流席捲各大行業的今天,越來越多的企業開始重視 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 的相關內容,可以查看下方內容: