用友NC报表开发教程全Word格式.docx
《用友NC报表开发教程全Word格式.docx》由会员分享，可在线阅读，更多相关《用友NC报表开发教程全Word格式.docx（148页珍藏版）》请在冰豆网上搜索。
NC于2002年开始研发数据字典，最开始只用于自定义查询，后来经过功能强化和逐步推广，成为现在的DDC（DataDictionaryControl）。
其功能包括数据库对象的管理与编辑、数据字典的解析生成等。
（4）数据仓库：
NC的一个独立产品，能够按照指定的入仓规则从多个业务数据库抽取数据，并通过入仓服务定期把数据加载到数据仓库。
产品的需求背景如下所述。
（1）复杂查询报表的需求：
在实际的业务查询中，开发人员经常会遇到以下一些棘手的问题复杂的SQL，从不同的查询条件得到完全不同的查询结果，查询结果的复合，业务逻辑代码和大量数据加工算法的介入，各种各样的数据交叉和数据处理手段等等；
在展现格式方面，通常要求灵活、友好、可视化、个性化的设计界面，丰富的展现控件和统计图表，依据数据对单元格、列表头和行表头的格式进行设置，表单控件之间的连动等等。
这一切都对早期的查询报表工具提出了艰巨的要求。
（2）二次开发的需求：
随着NC对行业用户的拓展，由业务组程序员在通用软件中针对每个查询报表需求进行开发的方案已经变得不太现实，一线人员越来越频繁的面临来自用户的个性化报表实施压力。
实施团队迫切要求一个强大而且易用的二次开发工具，尽管功能的强大和易用往往存在着一些矛盾。
（3）工具整合的需求：
自定义查询在推出后，在实施中得到了一定的应用，但局限于出复杂程度不太高的查询报表。
IUFO是公司的传统报表产品，它更偏重于报表的管理方面，比如报表的发布、审核、校验等等。
数据仓库使查询的应用由单数据源拓展到了多数据源，并且提供定时同步业务数据的功能。
为了有效地实现资源共享，结合发挥各个工具的优势，NC决策层一直在推动相关产品的整合。
（4）查询分析软件发展潮流的需求：
近几年来，查询分析、数据挖掘、商业智能的研究不论在企业应用还是在学术领域都成为热点，ERP软件的数据建模和查询建模功能已经成为代表产品水平的重要指标。
2.入门入门现在让我们来看一个最基本的查询样例，作为入门，我们知道在任何ERP系统中都存在公司和用户的概念，下面我们做一个查询某公司下用户的查询。
1.进入客户化自定义查询查询引擎管理界面图一12.在“查询设计”树下新建一个目录，“jl测试用例”，并在这个目录下面创建一个查询对象用户查询。
图一23.选择参数定义，这里我们定义一个名为corp,显示名为“公司”的参数，注意这里的数据类型选择编码参照，枚举项中选择这个编码参照的类型，我们将根据这个参数选取的值来确定待选公司，并且在查询中根据这个参数选取的值来进行结果筛选。
图一34.制作查询定义，制作一个查询定义的具体流程实际上就是为了生成一条SQL语句，查询数据源去获取数据，但是这个生成SQL语句的过程被我们用图形化界面代替了，用户只需要了解基本的SQL规则就可以了，无需亲自手动去写纷繁复杂的SQL语句，同时我们也支持手工SQL。
图一4用户可以通过增加表来增加数据字典中的数据表，也可以点击临时表引用前面做好的查询定义对象，引用查询定义对象相当于设计了一个复合查询，关于复合查询的定义参见第二章第六节查询集成。
这里我们选择增加表来增加一个sm_user表，这张表里面存储的是NC系统的用户信息。
图一5在选择字段页签下选择“用户名”等字段，这里的字段表达式可以是某表的字段，也可以是字段的运算或者函数处理表达式，例如：
len（sm_user.user_name），就是代表user_name这个字段的字符串长度。
显示名可以是用户自定义的字符串，将来显示在报表的列表头区域。
图一6前面我们提到这个查询必须按照公司为条件，过滤查询出来的用户，实际上就是为SQL语句生成一个where条件，我们支持两种条件，固定和待定，顾名思义固定条件写好之后就不能变化，而待定条件是跟参数设置相关的，可以根据用户输入参数变化。
我们在这里选取待定条件，用户表的公司编码字段等于前面我们设置过的corp。
关于查询定义的设计后面的章节将有更详细的论述，这里只介绍最基本的功能。
5.制作格式设计图一7新建格式设计文件夹以及对象的方式与新建查询对象的方法一样，这里略去不讲。
生成新的格式设计对象之后可点菜单中的界面模型引用查询，来绑定我们刚才做好的查询设计对象“用户查询”。
图一8选取刚才做好的查询之后我们在点击界面模型格式设计，这里可以选取我们预置的几种界面模型之一，例如这张表我们选取表头+表体格式。
图一9最后点菜单中的浏览，让我们浏览一下制作出的第一张报表，图一10点浏览之后我们会看到一个选择参数的对话框，在这个参数对话框中我们可以设置自己的参数值，比如我们选取sunny_corp这个公司，点确定，则可以浏览这个公司下的所有用户，如下图。
图一11选择表头区域的公司参照，我们可以浏览不同公司下的用户。
至此一个最简单的自定义查询已经制作完毕，我们可以将做好的查询作为独立节点发布到NC系统下供用户使用。
3.小结小结在本章中我们介绍了查询引擎的发展历史以及产品的需求背景，通过一个入门样例，让用户初步了解了查询引擎的基本功能，在后面的章节中我们将详细介绍查询引擎的各项功能，并通过一些样例使得用户能够使用本产品进行快速便捷的二次开发。
下图是对查询引擎开发流程的一个示意：
图一12查询建模体系第二章第二章对象管理对象管理1.对象树对象树查询引擎的管理调度功能由主界面完成，主界面左侧为一棵对象树，树上挂有代表查询对象和界面对象的节点，右侧为显示当前选中对象基本属性的属性框。
图二1管理调度主界面对象树（ObjectTree）：
对象树是一个支持层次管理的数据结构，它维护自身的加载、存储和节点的目录管理，每个节点的信息主体存储在数据库的一个BLOB字段中。
对象树上的节点通常分为目录（Folder）和对象两类，并支持快速定位（在树获得焦点时用ctrl-f快捷键可弹出查找对话框，支持按编码或名称来模糊查找）。
属性框（ObjectInspector）：
一个自动显示对象的属性和取值的控件，取值部分会根据属性的数据类型采用不同的渲染器来展示，不同的编辑器来编辑。
1.1对象编辑对象编辑目录的编辑操作如下：
（1）增加/删除/修改：
在根节点或目录节点之下可以增加目录，删除目录时会删除目录下的所有对象。
目录的可修改属性为目录名称。
同一目录下的目录和对象不能重名。
（2）复制/剪切/粘贴：
在查询子树或格式子树下，可以将一个目录及其下属内容从某位置拷贝或移动到另一个位置。
对象分为查询对象和格式对象，其编辑操作如下：
在根节点或目录节点之下可以增加查询对象或者界面对象。
前者的属性为编码、名称和数据源，后者的属性为编码和名称，其中编码一经使用，就不再建议作任何修改，因为此编码可能被其它对象引用。
请注意对象的唯一标识是编码而不是显示名称，一个查询对象或是格式设计对象可以有多个显示名称但是只能有唯一的编码。
在查询或格式子树下，可以将一个对象从某位置拷贝或移动到另一个位置。
请注意这里的复制粘贴都是在同一棵树下的，如果复制格式设计对象到查询对象树下则会出错。
1.2对象导入导出对象导入导出
（1）导出：
选中某个对象，可将其导出为XML文件，文件里描述了对象的所有信息；
也可选中某个目录，将该目录下所有的子目录和对象都导出到指定位置（保持原有的目录级次）。
（2）导入：
在选中某个目录之后，导入功能可用。
导出的XML文件，可以导入到当前目录下。
此功能可用于对象的跨数据库复制。
导入时，我们可以选择单个文件，也可以选择一组文件或目录，导入后会保留原目录的级次结构。
需要注意的是：
在导出查询对象或界面对象时，需将其引用的查询对象一并导出才有意义；
导入不能违反对象主键及名称的唯一性约束。
下图显示了某查询对象所导出的XML文件。
图二2导出XML文件（3）在导入导出的过程中需要注意的一个问题是数据源的问题，在实际应用中经常出现这样的场景：
实施人员在自己的环境（数据源为home）下做了一对查询模型设计和格式设计，然后导出这一对设计对象为xml文件，然后到用户的环境（数据源为customer）下执行导入，发现无法查出数据，并且提示“找不到查询所用数据源”，这是因为导出成XML文件的时候，记录在XML文件中的执行数据源是home，而客户的数据源名称是customer，与查询模型设计中的数据源不符合，这样查询模型就无法到正确的数据源下去取数，可以在弹出的提示框“是否修改执行数据源为当前数据源”，选择“是”，则该查询设计模型的数据源被修改为当前账套的数据源，这样就可以在客户的数据源中正确取数了。
2.数据源数据源查询引擎的数据源关系如下图所示：
图二3查询引擎数据源关系模型图多数据源运作机制：
查询引擎支持这样的模式NC业务在数据源A下运行，查询引擎的定义放在数据源B，通过引擎定义的查询可以到数据源C去执行。
注：
只有数据仓库下的查询引擎有切换定义数据源和跨库查询的功能，客户化下的查询引擎只能查询当前账套数据源的数据。
图二4切换定义数据源各种数据源的概念区分：
业务数据源（上面说的A）通常指当前登录账套的数据源，是NC运行所需要的业务数据源。
定义数据源（上面说的B）是指查询引擎自身的系统表所在的数据源，执行切换功能后，主界面上的对象树的内容会作相应改变。
请注意查询引擎自身的系统表可以和当前的业务数据源不是同一个数据源，例如当前登陆账套是Account1，数据源是datasource1，而查询引擎的系统表可以不在该数据源下，而在另一个数据源datasource2下，datasource2可能是账套Account2的数据源，也可能是任何其他的数据源。
但是前提是该数据源中必须含有查询引擎自身的系统表。
图二5切换定义数据源效果执行数据源（上面所说到的C）是指该查询定义取数的数据源，我们知道查询定义设计的最终目的还是去特定的数据源查取用户所需的数据，执行数据源就是存储这些用户所需数据的数据源，查询引擎本身的系统表所在数据源可以跟这个取数数据源不同，也就是说定义数据源和查询数据源可以分离。
图二6执行数据源3.首选项首选项QE数据源的配置在V5.0版本中统一放在查询引擎环境变量设置（又称首选项）这个节点里面，该节点位于客户化二次开发工具自定义查询下，界面如图2-6所示：
图二7查询引擎首选项管理这个节点存放查询引擎运行所需要的环境变量或者首选项变量，这些变量被存储在后台queryengine.xml中，位于nchome/ierp/bin目录下，由于本文下面的章节中还有需要涉及到环境变量设置的地方，所以这里只提及数据源环境变量的设置。
有效数据源：
启动中间件时的所有能够连接的合法数据源，实际上也就是prop.xml文件中的所有定义过并且能够
升级会员 