輕鬆實現報表整合

報表工具作為資訊管理、決策分析系統不可或缺的部分，在專案中經常用到，市面上的報表工具各式各樣，在整合策略上，每個產品也都有自己特有的開啟方式。不過，從門派上看，常見的無外乎中介軟體，servlet 應用兩大門派。一般開源的報表，大都作為中介軟體產品提供給開發者，整合方法也比較統一，通常都是嵌入到系統中自行呼叫 API 開發與整合，但開源的幫助文件或全或不全，都靠自己找資料，就要拼學習能力了。在商用收費報表中，潤乾報表也採用的是中介軟體方式，下面我們以潤乾報表為例來進一步瞭解一下：

潤乾報表為了方便開發者使用，在滿足大多數通用的需求的同時，實現零程式設計，潤乾報表利用 tag 標籤進行了封裝，如下就是一個釋出潤乾報表的 jsp 檔案：

<%@ taglib uri=”/WEB-INF/raqsoftReport.tld” prefix=”report” %>

<report:html name=”report1″ srcType=”file” reportFileName=”wangge.rpx”…/>

可以看到，在這個 jsp 中用到一個 <prefix: html > 標籤來發布 html 報表，與 struts 標籤使用類似，其中 reportFileName 就是需要釋出的報表檔名，釋出報表的同時，實現了匯出，分頁，列印功能

如果把 WEB 應用比作一臺機器，那報表就是這臺機器諸多功能模組裡的一塊，tag 標籤就是一個個小零件，你把這個小零件扣在哪個 jsp 檔案中，報表就在哪裡展現。

報表作為中介軟體整合到其他應用系統裡，與這個應用系統就成為了一個整體，但也有分家的做法，比如業界比較常見的 servlet 應用——

在這裡，報表應用是一個獨立的應用，在其他應用頁面裡嵌入一個 JFrame，然後透過 url 請求報表的 servlet，報表名作為引數傳遞給報表應用，報表應用將計算以後生成的 html 報表返回。

那這個時候，我們的程式猿要問了，瀏覽報表明白了，那如果報表需要傳參呢？ 彆著急，我們再來模擬一下兩種整合方式在給報表傳參上有啥區別：

中介軟體方式

我們還是拿潤乾報表的 tag 標籤來看：

<%@ taglib uri=”/WEB-INF/raqsoftReport.tld” prefix=”report” %>

<report:html name=”report1″ srcType=”file” reportFileName=”wangge.rpx”

params= “ arg1=123;arg2=abc;…… “

…

/>

Tag 標籤中有個 params屬性，可以透過這個屬性給引數賦值，如果引數值靈活變化，當然屬性值也可以透過變數傳遞，這個不多說，程式猿都懂的。

Servlet 的方式

JFrame 中請求報表 servlet 的 URL 就要改成：

http: //ip:port/report/reportservlet ? 引數 = 報表 &arg1=123&arg2=’abc’&…

這時，我知道我們經驗豐富的程式猿又要質疑了：首先，引入了 JFrame 來載入報表，多一次資料請求；再次，引數在 url 裡都是明文顯示的，安全報警啊，特別整合許可權時會比較麻煩！除此之外，web 服務與報表服務在不同的程式裡，不管是不是在同一臺物理伺服器，都會多佔用硬體資源，當應用出現異常時，排錯也麻煩，增加運維難度。所以，潤乾報表雖然也支援 servlet 釋出報表的方式，但我們也不建議大家這樣使用。

前面我們講了潤乾報表作為中介軟體整合，那麼這個中介軟體到底整合了什麼到應用系統中？很簡單，就是 jar 包，xml 配置檔案及 jsp 的 tag 描述檔案 tld。

Jar 包引入到應用程式中，不僅提供了 tag 標籤零程式碼計算展示、列印報表，也為開發者在自己的專案中自行呼叫報表 API 介面實現報表的計算，分頁，匯出，列印等過程提供了方便，例如使用程式碼計算釋出一個報表：

// 讀報表

String reportFile = “ C:/reportFiles/wangge.rpx ” ;// 絕對路徑或相對當前程式啟動路徑

ReportDefine rd = (ReportDefine)ReportUtils.read(reportFile);

// 計算報表

Context cxt = new Context(); // 構建報表引擎計算環境

//…………………….. // 其它輔助程式碼，例如往報表引擎傳遞引數，傳遞資料庫連線引數等
ReportDefine rd = (ReportDefine)ReportUtils.read(reportFile);

Engine engine = new Engine(rd, cxt); // 構造報表引擎

IReport iReport = engine.calc(); // 運算報表

// 輸出到網頁，展現報表

String htmlText = ReportUtils.toHTMLString(iReport,”report1″,request); // 生成 html 語法

request.setAttribute(“htmlText”, htmlText);// 儲存到 request 裡，方便頁面上顯示

當然，這裡只是講一個簡單例子，API 屬於進階整合，更深入的學習請參考潤乾的《程式設計師參考》文件。這例子雖然簡單，但我相信大家已經體會到了她的靈活性、輕量性，而單一的 servlet URL 方式整合如果要二次開發，僅兩個系統的資料通訊就是一大難題。 所以基於這種方式整合的報表，要麼由開發者想辦法解決，要麼就是把報表服務做成了一個平臺——囊括了資料決策展示、許可權管理、報表管理等等看起來牛叉，但跟自己業務系統相結合時又是雞肋的一堆子業務系統。

便利、靈活、輕量為報表開發節約成本提供了基礎，隨著業務的提升，高效、高可用性也是考核報表系統的重要部分。因此叢集也是整合部署的一個重要環節，那接下來我們繼續來看，這兩種整合方式在叢集上又有啥區別，先上兩個結構圖——

中介軟體嵌入到 web 應用裡，與 web 應用是一個整體，所以 web 應用做完叢集，那麼報表也就做完了叢集。

而 Servlet URL 的方式，那叢集就相當於分成了兩套，各自做自己的叢集，也就是報表是一個叢集，web 應用是一個叢集。

從以上的部署結構可以看出，中介軟體的方式在叢集上更簡單些。所需要的配置及硬體資源都要少不少。

到此報表的整合基本就講完了，優缺點都做了一個比較，您的應用需要哪一種呢？