报表引擎规范说明

报表引擎规范说明
报表引擎标准
作者：胡春国
创建日期：2004-09-17
网站：
邮件地址：kevin1915@
Report Engine Specification Version: 1.0 目录
1. 目的 (8)
2. 概述 (8)
3. 假设 (9)
4. 远景 (9)
5. 引擎内部结构 (9)
5.1 总体结构 (10)
5.2 报表引擎接口 (13)
5.2.1 客户应用接口 (14)
5.2.2 应用程序接口 (14)
5.2.3 管理监视接口 (15)
5.2.4 报表引擎定义接口 (15)
5.2.5 报表格式定义接口 (16)
5.2.6 报表引擎协同接口 (16)
5.2.7 策略引擎接口 (16)
5.3 技术框架 (17)
5.3.1 什么是总线 (17)
5.3.2 总线的优点与缺点 (17)
5.3.3 系统总线结构 (18)
6. 报表格式定义语言(RFDL) 20 6.1.1 通用结构 (20)
6.1.1.1 颜色 (20)
6.1.1.2 字体 (20)
6.1.1.3 显示格式 (20)
6.1.1.4 函数 (20)
6.1.1.5 线条 (20)
6.1.1.6 图片 (20)
6.1.1.7 链接 (20)
6.1.1.8 引用数据 (20)
6.1.1.9 扩展属性 (20)
6.1.2 页头 (20)
6.1.3 页尾 (20)
6.1.4 标题栏 (20)
6.1.5 组头 (20)
6.1.6 组尾 (20)
6.1.7 明细栏 (20)
6.1.8 内嵌报表 (20)
6.1.9 报表格式定义例子 (20)
6.1.9.1 销售报表 (20)
6.1.9.2 订单报表 (20)
7. 报表引擎定义语言(REDL) 20
7.1 通用结构 (22)
7.1.1 扩展属性（ExtendedAttribute） (22)
7.1.2 形式参数（FormalParameter） (22)
7.1.3 外部参考(ExternalReference) 22
7.1.4 例子 (22)
7.2 包结构 (23)
7.2.1 报表包（ReportPackage） (24)
7.2.2 报表包头(PackageHeader) 25
7.2.3 可重定义包头(RedefinableHeader) 25
7.2.4 包外部参考（ExternalPackage） (26)
7.2.5 例子 (26)
7.3 参与者 (29)
7.4 应用程序 (29)
7.4.1 应用程序（Application） (30)
7.4.2 例子 (30)
7.5 报表过程 (31)
7.5.1 报表过程（ReportProcess） (31)
7.5.2 报表过程头（ProcessHeader） (32)
7.5.3 可重定义报表过程头（RedefinableHeader） (33)
7.6 算法集 (33)
7.6.1 算法集（ActivitySet） (33)
7.7 算法 (33)
7.7.1 算法(Activity) 33
7.7.2 路径算法（Route Activity） (34)
7.7.3 块算法(Block Activity) 34
7.7.4 运行控制属性 (34)
7.7.5 运算的替代执行方式(Implementation) 35 7.7.5.1 No Implementation. 35
7.7.5.2 Tool 35
7.7.5.3 SubFlow.. 35
7.7.5.4 Statement 36
7.7.6 转移约束(Transition Restriction) 36
7.7.6.1 Join. 36
7.7.6.2 Split 36
7.8 转移信息 (37)
7.8.1 转移信息（Transition） (37)
7.8.2 转移条件(Condition) 37
7.9 相关数据 (38)
7.9.1 相关数据（DataField） (38)
7.9.2 数据类型（DataType） (38)
7.9.3 基本数据类型(Basic Type) 39
7.9.4 数据类型(Schema Type) 39
7.9.5 数据类型(Record Type) 39
7.9.6 数据类型(Union Type) 39
7.9.7 枚举类型（Enumeration Type） (40)
7.9.8 数组类型（Array Type） (40)
7.9.9 列表类型（List Type） (40)
7.9.10 开发者声名的数据类型（Type Declaractions） (40)
7.9.11 声明类型(Declared Type) 40
7.10 数据操作集 (41)
7.10.1 数据操作（Statement） (41)
7.11 报表引擎定义例子 (42)
7.11.1 销售报表 (42)
7.11.2 订单报表 (47)
8. 格式定义器 (47)
9. 引擎定义器 (47)
10. 引擎运行器 (47)
11. 策略引擎 (49)
12. 引擎监控器 (49)
13. 报表生成器 (49)
14. 总结 (49)
15. 参考文档 (49)
1. 目的
这篇文章主要是规范报表引擎整体结构、报表引擎的定义语言、报表引擎的报表格式语言。

只要报表引擎按照规范化的接口进行设计，报表引擎的各个部分就可以相互独立地实现与进化，减弱彼此之间的耦合关系；并且，各公司设计的报表引擎都可以协同工作，相互之间进行数据、格式的交换；更利于将来形成一个报表引擎网络，从而，各报表引擎的在安全管理下组成一个虚拟的网络，企业可以从这个虚拟的网络中，搜索到对企业本身有益的数据，更益于企业的宏观决策。

在文章中，主要是定义报表引擎的总体结构及它的定义语言；报表引擎包括它的元素及属性、报表引擎要实现的算法、与其它系统进行交互、与其它报表引擎的交互方式。

2. 概述
报表引擎起源于流行的工作流引擎的原理、报表格式的定义、报表内容的各种算法，产生报表引擎的思想。

它主要是引用工作流引擎的流程运转原理，在原始数据的基础上，定义报表的格式、报表的算法，根据定义的算法自动执行计算，并输出计算后的结果，再根据定义的报表格式显示报表的内容。

报表引擎根据定义的报表主题及它的算法，在人工或日程安排的触发下，自动运行。

报表引擎根据报表主题，从数据库的原始数据的基础上，提取原始的数据，依据定义的报表算法，进行自动计算；在提取报表主题及算法运算的过程中，，报表引擎依据定义各种参数，实现所需的运算。

报表引擎输出的数据信息，经报表解释接口实现它的解释，并生成相应的报表展示给用户。

用户也可以根据实际需求，随时调整报表主题及算法的定义语言，再重新运行报表引擎时，报表引擎立即根据定义后的内容进行处理，产生经过改变后的报表数据。

这样，报表引擎可以跟随用户的需求变化，而所需求的维护量非常少，也非常简单，灵活。

对于报表的输出格式，在报表引擎的输出接口中，定义要求的报表格式；当用户打印报表时，报表引擎根据定义的格式打印所需的报表；同时，如果用户需要改变报表的样式时，可以非常即时、灵活的重新定义，以满足用户的各种需求。

3. 假设
报表引擎是在业务系统已经运行之后，有原始数据的基础上，进行运算的；因此，在这里，我们假设用户的业务系统已经建成，报表引擎在已有的系统上，扩充已有的系统功能，用非常少的成本，非常少的时间，及时地满足用户对各种报表的需求。

4. 远景
当前报表引擎的解决方案，主要是针对每一个项目在报表这一方面花费大量的人力、物力，而且效果并非理想。

在这里，在工作流引擎流行的基础上，提出解决当前报表设计与实现的困难的方案，帮助IT企业或应用企业非常讯速地、低廉的成本建立各个企业的决策分析系统。

在将来，报表引擎有一定规模之后，各个企业、政府、机关等对整个业务管理成为一整体化
之后，可以组成一个报表虚拟网络。

在报表虚拟网络的管理下，企业、政府、机关等可以在网络中发布自己的报表数据；同时，在报表引擎原有的数据基础上，企业可以从虚拟网络中，搜索自己感兴趣的内容，以协作企业、政府、机关等进行宏观决策。

由于报表引擎网络是虑构的网络，所有的运算也是通过对算法的定义进行计算，从而可以扩张这种网络，让它包容整个企业系统（特别是跨地区、跨国际的企业），对各种企业系统进行集成，集成方法是对某个网络中的节点连接企业应用系统，以扩展报表引擎的功能。

5. 引擎内部结构
报表引擎从整体上划分为：报表请求部分、格式定义部分、引擎定义部分、引擎运行部分、策略引擎部分、引擎监控部分、引擎输出部分，下面对各个部分进行简单的介绍。

各部分相互协调工作，从而满足用户的各种需求；把各部分组合成一个整体系统。

5.1 总体结构
报表引擎的总体结构分为七个部分进行介绍，每一部分都是独立运行的一个模块。

它们之间经过相互协调工作，共同完成整个报表从定义、请求、执行、监控、分派、显示功能。

同时，它也是分布式计算的服务器。

如全省的业务信息系统，分成三级：省级---地市级---区县级。

各级有自己的报表引擎，当省级要对报表进行统计时，在省级报表引擎根据路由信息向下级发出请求，下属各级根据请求起动报表引擎并返回计算的结果（可以设置为异步或同步方式），省级报表引擎根据返回的结果进行计算并生成输出界面。

如果报表引擎定义了日程安排，那么报表引擎在日程事务的触发下，自动进行计算并保存计算后的结果信息；当其他业务请求报表计算时，系统可以立即响应请求，返回计算的结果，从而提高系统的负载、性能、响应能力。

下面是它的网络拓扑图：
在每一个省级、地市级报表引擎中，都包含着报表请求器、报表引擎运行器、策略引擎器、报表引擎监控器、报表引擎定义器、报表格式定义器、报表生成器。

下面是这几个模块的组成图：
整个报表引擎的核心的部分是报表引擎运行器、策略引擎器以及报表生成器。

其它几是报表引擎的辅助部分，协调报表引擎的运作。

报表请求器：主要是实现对报表请求参数的封装，实现统一的入口。

并负责对请求及响应的集中控制、分配。

报表格式定义器：在这一部分中，主要的功能是实现报表的输出格式的定义、报表栏位中输出的格式（包括字体、颜色、框线、显示样式等），输出的内容（主要是从输出的对象、输出对象的比较简单的计算、页头、分组、页尾等）。

引擎定义器：主要是指当报表引擎运行时，它的每个算法、算法执行次序、是否循环或分解、引用的外部应用接口、路由等信息。

算法包括从数据库中读取原始的数据信息、对各种参数进行的计算的算法。

算法的形式参数、实际参数、数据类型。

引擎运行器：这也是报表引擎中比较重要的部分，这一部分的性能影响到整个报表引擎的性能。

它根据在报表引擎定义部分定义的报表主题、各种算法、次序等信息，进行计算，并返回计算后的结果。

对于分布式的报表引擎，路由信息比较重要；当定义了路由信息之后，引擎运行到该处后，将定义在路由表中的引擎起动，并从相应的步骤处开始运行，并返回运行的结果。

策略引擎器：主要是针对用户的定义的算法，根据所需的参数进行计算，并生成计算后的结果返回给调用者。

这也是报表引擎比较重要的部分。

它也可以适用于业务系统，在策略引擎的协同下，满足业务需求的变动要求，灵活配置业务处理中的业务逻辑。

这一部分，对整个引擎的性能也是有巨大的影响，包括从数据库中提取数据信息、各种信息的计算。

引擎监控器：这一部分是辅助功能，主要是监控报表引擎的运行过程，如有些地方需求用户处理的，引擎会等待着用户的处理后，再执行后一个算法。

也可以监控引擎在运行过程中的出错信息，以便对引擎的错误进行跟踪；这些错误有可能是系统的、引擎本身的、算法定义的错误等。

在监视中，可以查看已在运行的报表，也可以对运行的报表进行暂停、中止、恢复、保存、载入等操作。

引擎输出器：主要是根据报表格式定义的内容，以及引擎运行部分运行的结果，生成输出界面，以比较直观的形式展示给用户浏览。

在生成的输出界面中，应该支持常用的几种：HTML，EXCEL，WORD等。

首先，在报表引擎定义器中，定义报表引擎的主题信息、计算策略，并根据定义的内容，生成报表引擎的定义文件（XML文件）。

在报表引擎运行器运行时，自动根据系统的配置信息，导入定义好的格式文件；并解释成报表引擎能操作的对象。

当用户请求报表引擎执行报表计算时，传入起动参数及报表的ID，报表引擎在配置文件中查找要计算的报表。

找到报表定义文件后，实例化报表的定义对象，并根据算法的执行次序，起动整个报表的执行过程。

在报表的每一个算法中，根据定义的形式参数从系统环境中读取实际参数值。

如果算法是一个表达式，系统起动策略引擎器进行计算，再返回运算的结果；如果算法是调用外部的应用程序或过程，系统会自动根据定义的内容及参数，调用相应的应用程序或过程进行运算，并保存运行的结果。

在整个报表引擎运行过程中，报表引擎监控器可以跟踪报表的执行过程，并记录它的执行过程；也可以对运行的报表执行暂停、中止、恢复、保存、载入等操作。

用户可以根据报表的运行情况，分析报表的各种性能及调整报表的执行过程，优化报表引擎的性能。

当报表引擎运行结束后，返回运算结果，报表生成器根据用户在报表格式定义器中定义的报表格式，生成相应的报表，再展示给用户浏览。

在对引擎有一定了解后，下面再介绍每一部分的组成及相互接口。

5.2 报表引擎接口
报表引擎的接口部分是描述整个报表引擎运行时，各个部分之间的相互关系及与外部应用的调用关系的体现。

下面是它的关系图：
用户从工作站进行系统后，向“报表请求器”申请打印报表，“报表请求器”根据用户传入的数据封装成一个报表参数对象，传入到“引擎运行器”中。

“引擎运行器解释报表参数对象，并从引擎定义器中读取报表运算的过程信息，起动引擎运行。

在运行的过程中，与应用程序及策略引擎进行数据的交互，数据的主要运算在策略引擎中完成；如果在策略引擎中不能完成或需要利用现有的应用程序，读取实际参数调用应用程序，返回处理的结果。

在引擎运行过程中，可能存在用户参与的运算、出错信息、运算的进度等信息，引擎监控器随时对“引擎运行器”进行监控，用户可以通过监视器查看引擎的运行情况，也可以调整引擎的运行过程。

如在运行的过程中，需求其它的报表引擎协同工作，那么起动另一个报表引擎，并传入相关的参数；再根据另一个报表引擎返回的结果信息进行下一步的运算。

“引擎运行器”进行一系列的运算后，返回运算的结果信息，传入到“报表生成器”中，“报表生成器”根据运算的结果信息、以及用户在报表格式定义器中定义的报表格式，生成相应的报表内容。

“报表生成器”执行完毕后，返回报表的URL信息，从而在“报表请求器”中，定位URL位置，显示最后的真实报表内容。

在整个报表引擎的体系结构中，存在着几个主要的接口信息：客户应用接口、应用程序接口、管理维护接口、报表引擎定义接口、报表格式定义接口、外部数据管理接口、报表引擎协同接口、用户管理接口。

5.2.1 客户应用接口
客户应用接口是客户参与运算的一处接口信息，当运算过程中要求客户输入一些相关资料参与运算时或客户决定下一个过程转向时，引擎起动这一算法后，就处于等状态，等候客户对它进行处理；客户处理之后，运算过程才继续执行。

由于引擎计算过程中，由客户参与运算过程，从而使用系统变得复杂。

为了减少系统的复杂度，所有与客户有关的操作，提供统一的接口进行管理。

当客户进行系统后，引擎根据客户的帐号及角色情况，返回客户所有的工作列表；客户可以直接选择要处理的工作列表，直接执行要处理的工作。

当客户处理完工作之后，再次触发引擎继续执行下一步运算。

在处理过程中，可能存在调用外部应用程序一起解决要处理的问题。

客户也可以运算过程执行中断、暂停、恢复等操作。

5.2.2 应用程序接口
应用程序接口是引擎与应用程序之间进行交互的接口。

当定义报表算法时，有部分功能不能在策略引擎实现或已经存在的系统，引擎通过调用外部的应用程序执行算法的实现，从而集成企业的外部应用程序。

引擎调用外部应用程序时，首先建立与外部应用程序的连接，在保持连接的状态下，通过实际的参数传入应用程序API中，由外部应用程序实现算法，并返回计算的结果信息。

在运算结束后，引擎再断开与外部应用程序的连接。

它分为本地过程调用、SHELL脚本的调用、远程执行调用、消息传递、事务处理。

本地过程调用：引擎根据定义的接口信息，创建本地连接器并传入调用的过程名称及它的实际参数。

在本地连接器中，执行本地过程计算并返回计算结果。

SHELL脚本的调用：引擎根据定义的脚本（可以是本地文件或在定义格式中直接写入的脚本信息，起动脚本运行器；并根据返回的结果再执行下一步骤的运算。

远程执行调用：引擎根据路由信息，创建远程连接器并起动远程连接，再根据远程连接的参数信息，调用远程过程计算；远程过程计算后，返回计算结果信息；再断开远程的连接。

消息传递：主要是指通过消息服务器，起动消息运算，可以是同步方式或异步方式进行运算。

如果同步，创建消息连接后，发送参数信息后，等待消息另一消息的触发后，再处理返回的结果，再继续运算；如是异步方式，引擎等待消息返回，就直接执行下一步运算。

事务处理：主要是对整个计算过程中，起动事务管理。

在起动事务后，暂存相关参数；当调用结束后，如发生错误，恢复被改变的参数；如没有发生错误，继续执行下一步运算。

5.2.3 管理监视接口
这一部分主要是对用户权限、引擎日志、运行情况进行监视，并可以随时调整引擎的执行步骤、更改用户的实际权限。

同时，在系统日志的记录下，分析引擎的执行情况、性能瓶颈等；并根据分析的结果，调整引擎的执行步骤，优化引擎的执行过程。

同时，也包括对引擎的运算过程进行中断、暂停、恢复等操作。

5.2.4 报表引擎定义接口
报表引擎定义接口，是对报表的整个算法及算法过程的定义。

定义之后，可以输出报表引擎定义的描述文档。

引擎的执行完全是依据这份文档的内容，有关定义的内容见报表引擎定义语言。

5.2.5 报表格式定义接口
报表格式定义接口，是定义报表的输出界面的样式、报表输出界面与运算最终结果的相互关系。

它是一种描述性的语言，只要符合规范，就可以在各个报表生成器中被解释。

在格式语言中，也规范了输出参数的描述方式。

输入参数只要符合规范，就可以被报表生成
器解释，并依据报表格式定义中的内容，生成输入报表页面。

报表格式语言的详细情况见REDL描述。

5.2.6 报表引擎协同接口
报表引擎的协同接口，是对多个报表引擎的一起工作，才能完成的报表运算。

如跨地区的报表计算、分布式的报表计算等。

这时，报表引擎分布在多个地点上，通过Internet连接起来，在定义引擎执行步骤时，设置它的路由信息、进入的报表算法节点信息。

当报表引擎运行时，引擎本身会起动对其他引擎的连接，并保持连接，通过报表引擎的接口，传入调用的参数，起动外部引擎进行运算；当外部引擎运行完毕后，返回运算结果，再断开引擎的连接。

报表引擎根据返回的结果再继续运算其他的算法。

在启动外部的报表引擎时，有两种起动方式：异步与同步。

异步：是指启动外部引擎后，不等外部引擎运行完毕，就继续执行下一个报表算法的运算。

同步：是指启动外部引擎后，暂停报表引擎的运行，一直到外部引擎执行完毕并返回后，再执行下一步骤的运算。

5.2.7 策略引擎接口
策略引擎的接口，也是比较重要的一个环节，它分离了运行与计算之间的耦合关系；从而可以彼此独立的进行设计与实现。

只要根据规范的定义，就可以透明的相互协作。

当引擎执行运行时，由引擎起动策略引擎并保持它的连接；然后传入计算的算法及相应的参数信息。

策略引擎根据输入的算法表达式及参数进行运算，再返回运算后的结果信息。

5.3 技术框架
由于报表引擎的外部环境难预测并且多种多样，很难定义每一种接口交互协议，因此，在这里采用了类似于硬件的数据总线的方式来实现各种系统的集成。

5.3.1 什么是总线
总线，在计算机硬件中，是两个模块以上的进行数据通讯、数据交换的公共通路。

这是一种十分熟悉的内容，而在报表引擎的系统中，对于总线的定义也是类似的，不同之处在于：一个是硬件中的数据通讯与数据交换；而在这里，是指系统通过一种发布——订阅的方式，对系统中的数据交换过程进行控制，以一种比较灵活的方式，实现系统中复杂的数据结构的数据交换。

5.3.2 总线的优点与缺点
无论对于什么事物，总是有优点也存在着缺点。

在上面的描述中，已经涉及到了一点总线的优点。

对于硬件的优点，众所周知：减少系统的复杂度、提高系统的兼容性、扩展性。

对于软件的总线，也是一种相似的形式：隔离了系统之间的耦合度、提高了兼容性、扩展性、易维护性。

只要满足总线接口的标准，就可以接入到系统中，随时对系统进行扩展。

对于易维护性，应该更加明显，由于系统的耦合度非常低，每一个业务都可以独立的加以变化，而不
会影响到系统的整个结构；同时，有完善的日志功能，可以随时加入监听功能，从而记录出错情况、运行情况。

由于采用了总线结构及接口标准，因而对于安全方面来说，可以在监听器中加入安全机制，可以完全不修改任何程序，即可对系统的安全进行管理。

它的原理是：在监听器中，吸收没有权限的消息，从而接口不能接收到消息请求，也不能发布自己的消息请求。

从另一种方面来说，类似于AOP方式（面向切面编程）。

由于采用了总线结构及接口标准，从而可以使用类似于硬件的即插即用的方式组织系统。

当有一个接口接入系统中后，系统的控制部件可以感觉到有异物进入了。

系统马上对这种接入的新的“异物”进行检验，如不符合接口标准，系统提示异常信息；否则系统将插入的插件加入到系统中，扩展整个系统的功能。

同时，监控器也开始对它的运行进行监视。

总线的缺点也是明显的：加入总线后，再整个系统的复杂程度加大了，消息的管理也提高了系统的开销，处理的复杂度增加。

如果监控器性能不好，会严重影响到系统的整个性能；所以整个系统的瓶颈是在监控器的处理上面。

如果多个用户同时访问报表引擎，对系统的性能也是一种隐藏的隐患；对于这种问题可以采用线程池的模式解决。

下面详细介绍系统的总线结构。

5.3.3 系统总线结构
图中蓝色部分线，就是报表引擎整个系统的交互通道；所有的数据信息、控制信息、状态信息都通过数据总线进行交互。

在圆中的引擎监控器，对整个数据的交互过程都进行监控；每一个模块发出信息时，必须带有接受者的地址信息，每一种模块都监听总线上的信息，一旦发现是自己要处理的信息，就直接接收并处理。

在这里，对信息的处理有两种方式：点对点、广播。

点对点：是某一个模块发出请求信息，其中带有接受者的标识符；接收者发现自己的信息后，直接取走，并删除取走的信息，从而避免被其他模块处理。

广播：是某一个模块对所有的监听者发送请求信息，每一个模块都接受后，再根据自己的方式处理请求。

在圆环中的所有消息，统一由系统监控器进行维护；如是广播方式的消息，当所有模块都接收后，监听器删除这一种信息；如是点对点的方式，监听器不处理它的删除方法，由接收者负责删除。

由于整个系统中，所有的消息都由监听器处理，因而对于日志管理比较简单，可以直接把监听到的信息记录下来即可。

在每一个模块接入数据总线之前，有一种接口处理部件，它负责监听自己的消息，并接收、删除由自己负责的消息。

并对收到的消息进行一定的处理后，再传入到相应的模块中进行处理；也负责对数据进行处理后，再发送到数据总线中。