在WEB应用中产生定制商业报表的系统和方法

摘要

在WEB应用中产生定制商业报表的系统和方法，包括配置文件解析装置，数据逻辑处理装置和数据组织装置，其中配置文件解析装置的结果送给数据逻辑处理装置进行处理，数据逻辑处理装置包括一个数据准备装置，用于根据从XML配置文件解析装置来的输入生成适合进行数据库或文件查询的语言后送给数据组织装置并从数据组织装置返回查询结果，数据逻辑处理装置还包括一个数据显示组织装置，用于将从数据组织装置取回的数据组织成适合显示的数据。在该系统中，数据的存储、处理和显示是逻辑分离的，从而使得很容易进行报表改变。

说明书

技术领域

本发明涉及数据库应用领域，尤其涉及在WEB应用中利用数据库中的数据产生定制报表的系统。

背景技术

现有的非Web应用(主要为客户端/服务器体系)由于借助Windows自身的发展，报表开发工具基本上可以做到所见即所得。所以在开发这种项目过程中，报表在格式上有所修改，并非是很大的工作量。然而，在基于Web的系统中，由于浏览器/HTML页面的这种模式使得传统工具无法发挥其作用，这类项目的报表开发往往是既费时又费力，并且项目中实现报表的困难不在于报表本身，而在于报表经常在改变(包括它们的内容和格式)。例如IBM的Websphere Studio就具有报表生成器，但是在项目中所需要的不仅是生成报表，而且还需要只要较少的测试就容易地改变它们。通常在SOW(工作任务说明书)中定义报表的数量和类型，然后在项目的设计阶段对这些定义进行细化。然而，不幸的是，几乎每个项目都存在在UT(单元测试)/FAT(工厂验收测试)/SIT(系统集成测试)后，甚至在UAT(用户验收测试)后，报表的改变的问题。这样就产生了两个问题：一个是在频繁的改变之后如何控制报表生成模块的质量；另一个是如何控制这些改变的成本，通常在整个项目过程中我们都需要专门的资源来处理报表的变化，这会增加项目的成本。

虽然良好的项目变更管理可以降低上面两个问题的负面影响，对项目经理和程序员而言报表生成模块仍然是一个很难处理的部分，这是因为报表具有天生的易变性。在与网络相关的项目中，由于有了MVC(Model-View-Controller)模型，我们能够将报表格式从产生报表的商业逻辑中独立出来，这对报表生成模块是一个很大的帮助。然而MVC模型不能解决上面的两个问题，因为产生报表的商业逻辑本身变化频繁。

因此，本发明的在WEB应用中产生定制商业报表的系统(下面简称ReportGate)的思想是在网络环境中用MVC模型来开发一种可重复使用的系统结构。为了在一个项目中开发报表，系统设计员和程序员将报表的商业逻辑和工作流定义在一个或多个文件中例如XML文件中，并且该系统结构将根据这些XML定义来动作。这样对报表的大多数改变可以通过修改该系统结构中的XML定义来处理。这样做的优点是将变成工作转变为配置工作，显然后者需要更少的时间，更少的测试并且从而只需要更少的花费。甚至可以只需让项目的临时工作人员来处理对报表需求的变化。在优选的情况下，这个系统结构还支持用户定义的JAVA插件程序来处理某些特殊的要求。虽然在这种情况下有时可能需要一些编程工作，但因为核心的商业逻辑都已经被该系统结构所覆盖，所以相比现有技术而言，工作负担是大大降低了。

发明内容

因此，本发明的目标是提供一种定制商业报表的产生系统，它能将数据的存储、处理和显示恰当分离，从而使得容易对报表进行改变。

为此，本发明提供了一种定制商业报表的产生系统，包括配置文件解析装置，数据逻辑处理装置和数据组织装置，其中配置文件解析装置的结果送给数据逻辑处理装置进行处理，数据逻辑处理装置包括一个数据准备装置，用于根据从配置文件解析装置来的输入生成适合进行数据库或文件查询的语言后送给数据组织装置并从数据组织装置返回查询结果，数据逻辑处理装置还包括一个数据显示组织装置，用于将从数据组织装置取回的数据组织成适合显示的数据。

本发明还提供了一种在WEB应用中产生定制商业报表的方法，包括配置文件解析步骤，数据逻辑处理步骤和数据组织步骤，其中配置文件解析步骤的结果送给数据逻辑处理步骤进行处理，数据逻辑处理步骤包括一个数据准备步骤，用于将配置文件解析步骤的结果作为输入生成适合进行数据库或文件查询的语言后送给数据组织步骤并返回数据组织步骤的查询结果，数据逻辑处理步骤还包括一个数据显示组织步骤，用于将从数据组织步骤取回的数据组织成适合显示的数据。

附图说明

图1示出了一个可以应用本发明的符合MVC模型的报表产生系统；

图2示出了根据本发明的报表产生系统的结构框图；以及

图3示出了根据本发明的报表产生方法的流程图。

具体实施方式

XML是一种本领域的普通技术人员熟知的灵活的标记语言标准。以下以XML语言为例，说明本发明的具体实施方式。

如图1所示，ReportGate结构(核心部分用虚线标出)符合标准MVC模型，它既能用它自己的控制器以及XML定义来定义模型和视图之间的工作流，也可以被插入到其它MVC架构例如IBM Jade结构中。

本发明的一个要点是因为在大多数项目中，报告是从数据库中的数据来生成的，因此，在很低的层次上，每一次报告都需要从数据库检索数据。在发明的优选实施方式中用数据库查询语言例如SQL语句来描述这一过程。

大多数的报告是通过与用户的交互来完成的，因此，在本发明的优选实施方式中，用一个JSP(或其它表单)来从用户取得输入参数(这些参数在XML文件中被定义)。然后这些参数被送到ReportGate，ReportGate从XML配置文件中获得所定义的SQL并且将它们与这些参数相结合后从数据库检索数据。最后这些结果被送到结果JSP，结果JSP根据XML配置文件拾取数据并以预定的格式显示。

从本发明的工作流程可以看出，如果用户想要改变报表的内容，他/她只要简单地改变XML配置文件即可。例如，如果想要改变报表的格式，只要简单地改变结果显示页即可。使用本发明，大部分有关报表的工作就变为进行配置。并且因为本发明的系统与实际的报表是独立的并且可以预先进行系统的测试，配置更改后的就只需要更少的测试。采用本发明后就可以对报表模块的开发同时进行良好的质量和成本控制。

图2示出了根据本发明的ReportGate的结构框图。如图2所示，本发明的ReportGate主要包括四个组成部分，即XML配置文件解析模块A，外挂程序驱动模块B，数据逻辑处理模块C和数据组织模块D。下面我们对上图中A B C D四个模块及其间的控制流和数据流做介绍：

A.XML配置文件解析模块

通过将XML引入到ReportGate的定义文件，大大提高了定义文件的灵活性和可读性，使得使用者无需像使用其它报表工具那样须掌握一种新的脚本语言。在ReportGate的该模块中，我们将以XML格式定义的报表配置信息解析出来，供其它模块使用。

在该模块中的控制流1是系统或定期定义刷新时，由逻辑处理模块调用本模块。

数据流1是从XML定义文件中读出的原始定义数据流，在下面我们用一个简单的XML定义文件的例子来说明该数据流(为简明起见，下表中的XML是在浏览器中缩略模式的视图)：

　　＜？xml version＝″1.0″ encoding＝″GB2312″ ？＞　　- ＜ReportGateConfig＞　　- ＜preloadMethods＞　　+ ＜method identifer＝″ReportFieldConverter″classname＝″com.ibm.cn.report.ReportHelper″methodname＝″HttpRequestParameter″＞　　- ＜parameters＞　　＜parameter index＝″1″ type＝″String″/＞<!-- SIPO <DP n="4"> --><dp n="d4"/>　　 ＜/parameters＞　　 ＜/method＞　　 + ＜method identifer＝″PasswordGet″classname＝″com.ibm.cn.report.ReportHelper″methodname＝″PasswordGet″＞　　 -＜parameters＞　　＜parameter index＝″1″ type＝″String″/＞　　＜parameter index＝″2″ type＝″String″/＞　　＜/parameters＞　　＜/method＞　　＜/preloadMethods＞　　 -＜Database number＝″1″＞　　＜name＞jdbc:db2:ibmcncom＜/name＞　　＜user＞c5i2com＜/user＞　　＜password＞[$＝PasswordGet(ibmcncom，c5i2com)$]＜/password＞　　＜/Database＞　　 -＜Database number＝″2″＞　　＜name＞jdbc:oracle:thin:@10.10.20.10:1521:wms＜/name＞　　＜user＞db2inst2＜/user＞　　＜password＞[$＝PasswordGet(ibmshop，db2inst2)$]＜/password＞　　＜/Database＞　　 -＜Report reportName＝″GeneralInOutReport″＞　　＜reportDesc＞出入库情况表＜/reportDesc＞　　 -＜columns＞　　 +＜column index＝″1″＞　　＜columnName＞PN＜/columnName＞　　＜columnDesc＞产品序列号＜/columnDesc＞　　＜columnWidth＞12＜/columnWidth＞　　＜data＞[$＝1$]＜/data＞<!-- SIPO <DP n="5"> --><dp n="d5"/>　　 ＜/column＞　　 ＜/columns＞　　-＜datasource database＝″1″＞　　 ＜SQLStatement＞SELECT ...＜/SQLStatement＞　　+＜SQLParams＞　　-＜param index＝″1″＞　　 ＜SQLParamName＞LocationID＜/SQLParamName＞　　 ＜SQLParamFrom＞[$＝HttpRequestParameter([$＝SQLParamName$])$]＜/SQLParamFrom＞　　 ＜SQLParamType＞Set＜/SQLParamType＞　　 ＜/param＞　　-＜param index＝″2″＞　　 ＜SQLParamName＞City＜/SQLParamName＞　　 ＜SQLParamFrom＞[$＝HttpRequestParameter([$＝SQLParamName$])$]＜/SQLParamFrom＞　　 ＜SQLParamType＞Set＜/SQLParamType＞　　 ＜/param＞　　-＜param index＝″3″＞　　 ＜SQLParamName＞ResellerCode＜/SQLParamName＞　　 ＜SQLParamFrom＞[$＝HttpRequestParameter([$＝SQLParamName$])$]＜/SQLParamFrom＞　　 ＜SQLParamType＞Set＜/SQLParamType＞　　 ＜/param＞　　-＜param index＝″4″＞　　 ＜SQLParamName＞Date＜/SQLParamName＞　　 ＜SQLParamFrom＞SysDate＜/SQLParamFrom＞　　 ＜SQLParamType＞Replace＜/SQLParamType＞　　 ＜/param＞　　-＜param index＝″5″＞<!-- SIPO <DP n="6"> --><dp n="d6"/>　　 ＜SQLParamName＞BrandID＜/SQLParamName＞　　 ＜SQLParamFrom＞[$＝HttpRequestParameter([$＝SQLParamName$])$]＜/SQLParamFrom＞　　 ＜SQLParamType＞Set＜/SQLParamType＞　　 ＜/param＞　　-＜param index＝″6″＞　　 ＜SQLParamName＞PN＜/SQLParamName＞　　 ＜SQLParamFrom＞[$＝HttpRequestParameter([$＝SQLParamName$])$]＜/SQLParamFrom＞　　 ＜SQLParamType＞Set＜/SQLParamType＞　　 ＜/param＞　　-＜param index＝″7″＞　　 ＜SQLParamName＞FromToWhom＜/SQLParamName＞　　 ＜SQLParamFrom＞[$＝HttpRequestParameter([$＝SQLParamName$])$]＜/SQLParamFrom＞　　 ＜SQLParamType＞Set＜/SQLParamType＞　　 ＜/param＞　　 ＜/SQLParams＞　　 ＜/datasource＞　　 ＜/Report＞　　 ＜/ReportGateConfig＞

可以看到，该定义文件中定义了两个外挂程序(HttpRequestParameter和PasswordGet)、定义了报表要用到的数据源(此例中是两种不同类型的数据库)、定义了一个报表(出入库情况表)并在其中定义了该报表的数据组织方式(带有参数的一条SQL语句)和显示组织方式(结果按列提交给显示JSP)。关于这两个定义的作用，我们会在后文中在相应的数据流中解释。

数据流2是经过XML解析引擎分析后的定义数据流，在这时，定义数据流被转变为DOM树的形式存储在内存中。当然，本领域的普通技术人员将能够明白，XML的解析有两种标准方式：SAX和DOM。当通过DOM来操作一个XML文件的时候，DOM读取该文件，然后把它分割成单个的对象(比如元素，属性和注释等等)，然后在内存中创建一个关于该文档的树结构。使用DOM的好处是可以引用和操作每一个对象。其缺点是为一个文档创建一个树结构，尤其当文档尺寸很大的时候，需要大量的内存空间。但由于ReportGate的配置文件不会有这么大的尺寸，所以没有这个问题。而由于SAX方式不是把XML文档全部读到内存中，而是通过事件驱动在需要时读取相应部分。因为整个文档并没有放到内存中，所以它不能随机的到达文档的某一部分，同时也因为整个文档不在内存中，开发人员必须在处理过程中按顺序处理信息。在本发明中，这两种方式都可以采用。甚至还可以采用其它合适的方式而不会脱离本发明的范围。

B、外挂程序驱动模块。

ReportGate提供外挂程序的接口，即：使用者可以自己编制程序并将其“挂”至整个ReportGate框架之中，由ReportGate驱动运行。这使得用户可以在不改动ReportGate的情况下实现一些特殊的定制功能。如：在报表生成前对数据进行预处理，和在报表生成后对格式进行后处理等等。在ReportGate的该模块中，我们实现了驱动外挂程序的控制接口和数据接口，使得数据可以在框架的控制下由外部程序处理。

在ReportGate中，我们使用两种方式实现程序的外挂：对于Java的外挂程序，我们通过java的Class.forName()的形式由java虚拟机直接调用。对于其它代码编制的外挂程序，则可以通过本领域的普通技术人员都熟悉的JNI(Java Native Interface)接口调用。当然，ReportGate也可以通过操作系统调用直接运行可执行程序。

在该模块有两个控制流流入，它们代表了调用外挂程序的两个时刻，即上述的预处理(控制流2)和后处理(控制流5)。下面我们用上面的例子中的预处理定义来解释相应的数据流。

-＜method identifer＝″PasswordGet″classname＝″com.ibm.cn.report.ReportHelper″methodname＝″PasswordGet″＞　　-＜parameters＞　　 ＜parameter index＝″1″ type＝″String″/＞　　 ＜parameter index＝″2″ type＝″String″/＞　　 ＜/parameters＞　　 ＜/method＞　　-＜Database number＝″1″＞　　 ＜name＞jdbc：db2：ibmcncom＜/name＞　　 ＜user＞c5i2com＜/user＞　　 ＜password＞[$＝PasswordGet(ibmcncom，c5i2com)$]＜/password＞　　 ＜/Database＞

这个例子中外挂程序PasswordGet的目的是避免将报表的数据源(数据库)的密码明文写于定义文件中，而是通过程序调用的方式在运行中动态得到(当然，这只是预处理的一个例子，实际中可能有多种外挂程序实现不同的功能)。因此，在传入本模块的数据流3中包含了外挂程序的定位信息(所处的程序包)和参数。经过定位后，本模块将参数信息(两个字符串变量)和当前参数值(ibmcncom数据库的c5i2com用户)置于数据流4中通过class.forName()传入运行的程序，而后从数据流5中取得该程序的运行结果，置于数据流6中返回给控制模块并由后者提交给相应的需求者。

后处理的数据流(13/14/15/16)在类型和流转方式上与预处理的数据流一致。值得一提的是：后处理数据流的存在可以为报表增加很大的灵活性，例如一个员工人事报表，控制模块从数据库中取得所有员工的数据后，将这些数据交给一个后处理程序过滤，我们可以在该程序将当前用户的权限和他能看到的数据列联系起来(例如普通员工不能看他人的工资等)，这样我们可以实现一张报表对不同的用户体现不同的信息。当然，灵活的后处理还可以实现很多种其它功能(如数据字典的翻译：数据源中可能是用数字1表示“已批准”，数字0表示“已拒绝”，我们可以在后处理中实现这种对应关系，而使前台JSP的逻辑更加简化)，等等。

C、数据逻辑处理模块。

该部分是ReportGate的核心处理模块，数据在这里根据XML配置文件中的定义被处理和格式化。并按照Model-View-Controller框架的接口方式将数据组织能够为前端JSP页面表现的报表形式。通过将该部分和下一部分(数据组织模块)的分离，我们在Model-View-Controller框架上进一步地做到了数据的存储、处理和显示分离，提高了系统的灵活性。

这一模块是所有控制流的发起者，以上面的XML报表为例，下面我们介绍这一部分的数据流转情况(为简明起见，我们仅列出部分定义)：

　　-＜Report reportName＝″GeneralInOutReport″＞　　 ＜reportDesc＞出入库情况表＜/reportDese＞　　-＜columns＞　　-＜column index＝″1″＞　　 ＜columnName＞PN＜/columnName＞　　 ＜columnDesc＞产品序列号＜/columnDesc＞　　 ＜columnWidth＞12＜/columnWidth＞　　 ＜data＞[$＝6$]＜/data＞　　 ＜/column＞　　＜/columns＞　　-＜datasource database＝″1″＞　　 ＜SQLStatement＞SELECTsaleinout.inouttag，psglocationLAC.name，psglocationCTY.name，psgreseller.companyName，psgbrand.brandname，saleinout.pn，saleinout.sn，psgreseller.category，psgreseller.category，saleinout.fromtowhom，<!-- SIPO <DP n="10"> --><dp n="d10"/>saleinout.date，saleinout.price from saleinout，psglocation psglocationLAC，psglocation psglocationCTY，psgbrand，psgreseller，psgpn where(saleinout.ResellerCode in(select psgreseller.ResellerCode from psgresellerwhere(psgreseller.locationid in？)and(psgreseller.city in？)))and(saleinout.ResellerCode in？)and(saleinout.Date＜？)and(saleinout.PN in(select PN from psgPN where BrandID in？))and(saleinout.PN in？)and(saleinout.FromToWhom in？)and(psglocationLAC.locationid＝psgreseller.locationid)and (psgreseller.resellercode＝saleinout.resellercode)and(psglocationCTY.locationid＝psgreseller.city)and(psgbrand.brandid＝psgpn.brandid)and(psgpn.pn＝saleinout.pn)＜/SQLStatement＞　　 -＜SQLParams＞　　 -＜param index＝″1″＞　　＜SQLParamName＞LocationID＜/SQLParamName＞　　＜SQLParamFrom＞[$＝HttpRequestParameter([$＝SQLParamName$])$]＜/SQLParamFrom＞　　＜SQLParamType＞Set＜/SQLParamType＞　　＜/param＞　　-＜param index＝″4″＞　　 ＜SQLParamName＞Date＜/SQLParamName＞　　 ＜SQLParamFrom＞SysDate＜/SQLParamFrom＞　　 ＜SQLParamType＞Replace＜/SQLParamType＞　　＜/param＞　　＜/SQLParams＞　　＜/datasource＞

本模块通过数据流2得到该报表的数据源定义后，控制流3通过数据流7将这些定义交给数据准备部分(SQL语句解析或者文件定位)。在此例子中，这个数据源定义是一个类SQL语句，而这个类SQL语句的运行参数也是通过一个外挂预处理程序HttpRequestParameter获得的(这个例子的含义是系统根据最终用户在网页上提交的查询条件生成相应报表)。数据准备部分则将所有这些数据整合为可以为数据组织模块可以理解的数据(本例中是SQL语句)。

而后，我们将这些数据由控制流4通过数据流9提交给数据组织模块。在从数据流12得到了该报表的数据结果集后，控制流6会将这些结果集通过数据流17交给数据显示组织模块(控制流5和对应的数据流是做数据后处理的，我们在上文已有叙述，这里不再重复)。数据显示组织模块会根据XML定义中的相应定义(如下例)组织数据为散列表的形式：

-<columns>

-   <column index＝″1″>

       <columnName>PN</columnName>

       <columnDesc>产品序列号</columnDesc>

       <columnWidth>12</columnWidth>

       <data>[$＝6$][$＝7$]</data>

 </column>

</columns>

这里我们定义了若干“列”，此例中给出了“产品序列号”这一列的定义。包括它的名称，最大长度以及如何从数据组织模块提交的数据流中组织该列([$＝6$][$＝7$]是一个简单的例子，即从数据流17中取第6组数据和第7组数据拼接而成)。而前端JSP报表在显示“产品序列号”时，既可以将该列数据完全以列的形式列出，也可以灵活地通过自己的逻辑将其置于交叉表或嵌套表中的表头中。换而言之，在数据显示组织模块中产生的数据“列”，就是前端JSP报表显示的直接数据源。

可以看出，这种“列”的定义是区别于数据库或数据文件中的列的意义的，它也不同于最终显示的JSP报表中的列的定义(当然，在最简单的报表中，这三者可能相同)。我们引入这种数据显示组织方式是为了更好地将上层逻辑和底层存储方式分离，因为在很多项目实施中，制作JSP页面的美工和程序人员往往很难理解底层数据逻辑(比如为什么要将产品序列号以一定规律拆分存储)，他们在制作报表时希望得到的是有直观意义的数据。而ReportGate通过在系统的框架中定义这些“列”，在数据的直观意义和数据的存储方式上建立了一种可由用户调整的联系。另外，这些“列”的定义可以系统的主要设计人员(如架构师)在项目设计时实现(并在实施中动态调整)，因此可以减低系统的一般程序员的工作量和对他们的技术能力的要求。

综上所述，通过这一部分，我们可以做到将数据存储方式(例如：在数据库中还是在文件系统中？或在数据库中存于哪张表中？)和上层的逻辑(例如：数据的查询方式是用户交互式还是系统定时生成？月销售报表需要哪些数据和统计参数？是交叉表还是嵌套表？)的分离，以达到提高报表系统的灵活性的目的。

D、数据组织模块。

该部分是ReportGate和底层数据存储交互的部分。依据XML配置文件中的定义，该模块将分布在数据库或文件系统中的数据取得后交给逻辑处理模块进行进一步的计算和处理。该模块的作用是屏蔽上层逻辑和具体的数据存储位置，降低数据结构、访问方式对报表生成的限制。

报表的数据源可以是多种形式的，可以是数据库，也可以是数据文件，而这些数据源的存储位置可能是在报表系统的本地机器，也可能存于网络中。所以本模块通过解析数据流9中的数据组织信息(在上例中是一条SQL语句)，查找到相应的数据结果集返回。在本文的例子中，我们定义了两种数据库(一个Oracle、一个DB2)作为数据源(如下所示)，而“出入库情况报表”中的数据存储于DB2中。ReportGate通过JDBC接口和DB2数据库连接，并执行查询，获得结果集合。

　　-＜Database number＝″1″＞　　 ＜name＞jdbc:db2:ibmcncom＜/name＞　　 ＜user＞c5i2com＜/user＞　　 ＜password＞[$＝PasswordGet(ibmcncom，c5i2com)$]＜/password＞　　 ＜/Database＞<!-- SIPO <DP n="13"> --><dp n="d13"/>　　-＜Database namber＝″2″＞　　 ＜name＞jdbc:oracle:thin:@10.10.20.10:1521:wms＜/name＞　　 ＜user＞db2inst2＜/user＞　　 ＜password＞[$＝PasswordGet(ibmshop，db2inst2)$]＜/password＞　　 ＜/Database＞

在这个例子中，本模块为了使上层模块只得到相应的数据而不关心存储方式实现了以下一些功能：数据库定位，数据库连接(包括身份验证机制，连接缓冲池的实现)，数据查询(SQL语句执行)，异常处理，释放资源等等。这样一些处理被封装在本模块中后，在数据流12中所返回的就只是上层模块关心的符合报表数据定义的数据列了。当然，在实际的复杂报表中，ReportGate还实现了其它功能，例如：出于系统性能要求考虑从数据库中一次读到内存中数据限制、数据更新操作、对文件系统的访问处理等等。总之，在这一层的逻辑中实现的是与底层存储有关的各种处理，它的封装可以使用户更专注于报表的逻辑而不是陷于数据访问编程和调试中。

根据本发明，对报表的改变的一种最直接的方式当然是重写或直接修改一个XML配置文件。但根据本发明的一种优选实施方式，通过XML配置文件中的“？”部分，实现了一种更加简单的对XML配置文件的改变。例如，首先假设用户输入如下的XML配置文件：

　　＜databaseList＞　　＜database sequence＝″1″＞　　＜！--the sequence in the above database list--＞　　＜dbName>jdbc:db2:PSG＜/dbName＞　　＜dbuser＞db2inst2＜/dbuser＞　　＜dbpassword＞db2inst2＜/dbpassword＞　　 ＜/database＞　　＜/databaseList＞　　＜ReportList＞<!-- SIPO <DP n="14"> --><dp n="d14"/>　　＜Report name＝″GeneralSaleInOut″＞　　＜DataSource DBSequence＝″1″＞　　＜ReqParamList＞　　＜！--Parameters need to be got from the HTTP request--＞　　＜paramFromRequest sequence＝″1″＞　　＜ParamName＞resellerCode＜/paramName＞　　＜/paramFromRequest＞　　＜/ReqParamList＞　　＜SQL＞Select inOutTag，resellerCode from SaleInOut whereresellerCode＝？＜/SQL＞　　＜/DataSource＞　　………

在上面的XML配置文件中，首先指出了报表中所用的数据源以及数据库中的列。“<SQL>”部分中的“？”给最终用户提供了一个通过前端页来指定这些参数的机会。这样对报表的定制就变成可行的了。在SQL中可以有多个“？”，并且在SQL参数和HTTP请求中的参数之间的顺序和对应关系在<paramFromRequest>部分中定义。虽然本实施方式中是用“？”来指定参数，但显然本领域的普通技术人员知道可以选用其它特定的标记，甚至还可以采用多个不同的特定的标记，来对不同的参数进行标记。

图3示出了根据本发明的报表产生方法的优选实施方式。如图3所示，根据本发明的产生定制商业报表的方法基本包括3个步骤，即配置文件解析步骤301，数据逻辑处理步骤302和数据组织步骤303，其中配置文件解析步骤301的结果送给数据逻辑处理步骤302进行处理。另外，配置文件解析步骤包括对配置文件中的某些特定标记作为特殊的参数进行解释。数据逻辑处理步骤303包括一个数据准备步骤，用于将配置文件解析步骤的结果作为输入生成适合进行数据库或文件查询的语言后送给数据组织步骤并返回数据组织步骤的查询结果，数据逻辑处理步骤还包括一个数据显示组织步骤，用于将从数据组织步骤取回的数据组织成适合显示的数据。数据显示组织步骤对取回的作为数据组织步骤的结果的数据进行拼装，使得拼装后的数据适合作为前端报表显示的直接数据源。在本发明的该优选实施方式中，所述的配置文件解析是对XML配置文件进行解析。但本领域的普通技术人员将会明白，本发明的要点并不在于配置文件的类型，为了实现本发明的目的，还可以采用其它已有的或将来出现的任何合适的配置文件。在优选实施方式中，数据逻辑处理步骤还包括一个用来调用外挂程序的外挂程序驱动步骤。该外挂程序驱动步骤利用下列三种方式之一来实现对外挂程序的调用：1)通过java的Class.forName()的形式由java虚拟机直接调用；2)通过JNI接口调用；3)通过操作系统直接调用。被调用的外挂程序可以包括例如一个密码获取程序。

另外，根据本发明的优选实施方式，本发明最好利用java语言来开发，并且在数据流转过程中把数据封装为Data Bean，即把将在本发明的各模块之间传送的数据封装为Data Bean。

另外，根据本发明的优选实施方式，还对数据是在数据库层面进行处理还是在将数据取回来后在前端进行处理进行了基本上按如下三种方式进行了划分：

A、有些数据的后处理在数据库层面难以实现。比如假如要将数据库中的1/0状态位根据用户的登录语言偏好解释为(Yes/No，是/否，はい·いぇ)中日英三种语言(有时甚至更多)，而当前的数据库由于存储内码的限制，往往无法在同一数据库同时存储三种以上语言的信息。这样的处理在本发明的优选实施方式中是通过引入后处理程序来进行操作处理的。

B、对大规模的数据字典的查找和翻译一般利用数据库处理。比如这样一个例子：一台机器包含若干个零件，在数据库中的描述记录中存储它所包有含零件的编号，但如果报表要求体现这些零件的名称，产地等信息，我们必须到对应的零件表去根据零件编号查找。在本发明的一个例子中，这样的零件表中包含了30万条记录，这样的处理显然适合用数据库的连接处理，以充分利用数据库的性能。

C、两者都可以处理的小规模的数据，则根据实际对系统的可维护性和开发难度来处理，例如我在上面提到的员工人事报表的例子。如果想在数据库层面做到，则在程序中必须为不同权限的报表查阅者写出不同的SQL查询语言(选择不同的列进行显示)，比较于可以在后处理程序中调用用户权限模块中的现有程序来实现，显然后者更方便。

以上参照优选实施方式描述了本发明，但显然可以在本说明书所教导的范围内对上述具体的实施方式做各种修改、改进和变化。