用友NC语义模型红皮书-2011-07
【用友NC供应链管理】学员手册-合同管理

1.1业务内容 (2)1.2企业困惑 (3)1.3目标价值 (3)2基础数据准备设置 (4)2.1供应商设置 (4)2.2物料设置 (5)2.3结算信息 (5)2.4合同信息 (6)2.5交易类型 (7)3采购合同 (9)3.1业务描述 (9)3.2系统操作步骤 (12)4销售合同 (18)4.1业务描述 (18)4.2系统操作步骤 (20)5其他收付合同 (23)5.1其他付合同进行付款 (23)5.1.1业务描述 (23)5.1.2系统操作步骤 (24)5.2其他收合同进行收款 (24)5.2.1业务描述 (24)5.2.2系统操作步骤 (25)6常见应用 (25)6.1.1业务描述 (25)6.1.2系统操作步骤 (25)6.2合同预警 (27)6.3合同对业务的控制 (29)6.3.1交易类型 (29)6.3.2物料属性 (29)6.3.3集采控制规则 (30)6.4半结构化输出 (31)7业务演练习题 (33)1整体业务概述1.1业务内容合同是当事人或当事双方之间设立、变更、终止民事关系的协议。
依法成立的合同,受法律保护。
合同在NC产品有三个含义:1)与合作方签订的具有法律约束力的合同;2)不具有法律约束力的意向合同或协议等,但作为双方进行业务往来的参照依据;3)辅助业务操作的单据,或约束、控制规则,作为控制后续业务的参照标准。
合同在一般企业中存在有对采购合同、销售合同、其他合同等。
签署的合同对合同覆盖的业务具有约束、控制等作用,并具备法律效力。
1.2企业困惑企业在履行合同时对合同内容的要求项必须严格执行,往往因为疏忽和遗漏合同约定项使企划蒙受巨大损失。
企业在各项业务活动中会签署和履行大量合同,且有很多合同是具有延续性的。
对合同本身的整理,汇总和保存的工作也是企业一项繁琐的工作。
企业需要全面掌握企业合同管理的现状。
只能建立合同台账,要求各部门和下属各单位以报表形式上报合同签署和履行情况、履行结果。
NC学员手册-组织建模索引

培训教材手册-财务领域-组织建模索引用友软件股份有限公司2014年版权版权所有:用友软件股份有限公司©2014。
保留所有权利。
没有用友软件股份有限公司的特别许可,任何人不得以任何形式或为任何目的复制或传播本文档的任何部分。
此外,本文档及其内容仅供您自己使用,没有用友软件股份有限公司的明确许可,不得出租、转让或出售本文档及其内容。
本文档包含的信息如有更改,恕不另行通知。
目录1业务概述及基础概念 (3)1.1总体概述 (3)1.2概念 (3)2、业务场景及系统操作 (4)2.1全局 (4)2.2集团 (5)2.3管控范围 (5)2.4业务单元 (6)2.5部门 (6)2.6财务核算账簿 (7)2.7责任核算账簿 (7)2.8组织体系 (8)2.9会计科目 (8)2.10会计平台 (9)2.10.1影响因素定义 (9)2.10.2单据影响因素关联 (10)2.10.3平台设置 (10)2.10.4科目对照表 (11)2.10.5分类定义 (11)2.10.6转换模板 (12)2.10.7单据生成 (12)1业务概述及基础概念1.1总体概述随着国内外大型高端企业的成长,企业为了适应市场变幻或引领行业发展。
企业在产品经营,市场细分等发展策略的指引下,进行着管理模式,组织模型的不断调整。
使得企业多元化产业经营、专业分工日趋明显,随之组织数量越来越多、形态也各不相同、关系错综复杂;同时国际、国内形势风云变幻、市场竞争环境日趋激烈残酷、转型、升级、并购等管理模式变化也十分频繁常见,这些对于高端集团企业的整体管理水平都是一个极大的挑战。
为了配合和支持企业的不断变革, NcV63 秉承客户经营思想,深化产品四化理念,通过动态建模平台,支持全球化、多集团、多组织应用的企业动态建模,满足中国集团企业成长性要求。
1.2概念全局:在系统管理上是NC 系统的客户安装环境,技术上指一个NC 数据源,跨越系统内所有集团的一个范围;我们将各种星系比喻为集团,那么不论有多少星系,总是不能超出“宇宙”的范围。
语义模型扩展方案

语义模型扩展⽅案语义模型扩展⽅案By 边传猛⽬录1语义函数扩展 (2)1.1接⼝ (2)1.2实现 (3)1.3配置⽂件 (4)2脚本规则扩展 (5)2.1接⼝ (6)2.2实现 (7)2.3配置⽂件 (7)2.4使⽤ (8)3语义提供者扩展 (9)3.1接⼝ (9)3.2实现 (11)3.3配置⽂件 (13)3.4使⽤ (14)4数据加⼯使⽤ (15)4.1概念 (15)4.2定位 (15)4.3执⾏原理 (16)4.4使⽤ (16)4.5常见问题 (18)5元定义驱动扩展 (18)5.1接⼝ (19)5.2实现 (20)5.3配置⽂件 (20)5.4使⽤ (21)1语义函数扩展语义模型⽀持对其函数进⾏扩展,⽤户可以根据业务需求扩展⾃定义函数。
⾃定义函数和预置函数在使⽤上相同,可⽤于字段表达式、语义脚本、筛选表达式、关联表达式等处。
1.1接⼝根据函数接⼝(nc..nticCommand)实现⾃定义函数。
类图⽰意如下:接⼝中API如下:1.2实现对于⼀般函数,可直接实现nc..nticCommand。
对于数据库类型函数,可继承nc..eCommand,实现以下三个接⼝⽅法:public abstract String getMSSQLValue(Object[] params);public abstract String getOrclValue(Object[] params);p ublic abstract String getDB2Value(Object[] params);1.3配置⽂件默认配置⽂件路径为${NC_Home}/resources/smart/function_。
为⽅便各模块扩展函数,在开发环境下,配置⽂件存放位置为各模块resources下的smart ⽬录:${NC_Project}/resources/smart/function_${模块号}.xml如总帐项⽬扩展配置⽂件路径为:gl/resources/smart/function_gl.xml这样在安装盘中,各模块的扩展配置⽂件将都在NC_HOME/resources/smart/⽬录中。
语义模型扩展方案

语义模型扩展方案By 边传猛目录1语义函数扩展 (2)1.1接口 (2)1.2实现 (3)1.3配置文件 (4)2脚本规则扩展 (5)2.1接口 (6)2.2实现 (7)2.3配置文件 (7)2.4使用 (8)3语义提供者扩展 (9)3.1接口 (9)3.2实现 (11)3.3配置文件 (13)3.4使用 (14)4数据加工使用 (15)4.1概念 (15)4.2定位 (15)4.3执行原理 (16)4.4使用 (16)4.5常见问题 (18)5元定义驱动扩展 (18)5.1接口 (19)5.2实现 (20)5.3配置文件 (20)5.4使用 (21)1语义函数扩展语义模型支持对其函数进行扩展,用户可以根据业务需求扩展自定义函数。
自定义函数和预置函数在使用上相同,可用于字段表达式、语义脚本、筛选表达式、关联表达式等处。
1.1接口根据函数接口(nc..nticCommand)实现自定义函数。
类图示意如下:接口中API如下:1.2实现对于一般函数,可直接实现nc..nticCommand。
对于数据库类型函数,可继承nc..eCommand,实现以下三个接口方法:public abstract String getMSSQLValue(Object[] params);public abstract String getOrclValue(Object[] params);p ublic abstract String getDB2Value(Object[] params);1.3配置文件默认配置文件路径为${NC_Home}/resources/smart/function_。
为方便各模块扩展函数,在开发环境下,配置文件存放位置为各模块resources下的smart 目录:${NC_Project}/resources/smart/function_${模块号}.xml如总帐项目扩展配置文件路径为:gl/resources/smart/function_gl.xml这样在安装盘中,各模块的扩展配置文件将都在NC_HOME/resources/smart/目录中。
用友NC-OA平台API参考手册

用友N C-O A平台A P I参考手册© 2006 UFida Co., Ltd.All rights reserved.This document contains information that is proprietary and confidential to UFida., which shall not be disclosed outside the recipient's company or duplicated, used or disclosed in whole or in part by the recipient for any purpose other than to evaluate this file. Any other use or disclosure in whole or in part of this information without the express written permission of Ufida. is prohibited. Date: 2009-02-26Author: 王文友Version: V1.0用友NC-OA平台API参考手册 (1)修改记录 (6)1.服务参考 (7)1.1概述 (7)1.1.1配置开发环境 (7)1.1.2开始编码(Java) (7)1.1.2.1生成ADB Client Stub (7)1.1.2.2编写客户端代码 (7)1.1.3开始编码(C#) (8)1.1.3.1添加服务引用 (8)1.1.3.2编写客户端代码 (11)1.1.4服务列表 (11)1.1.5服务公共实体 (12)1.1.5.1服务响应实体(ServiceResponse) (12)1.1.5.2服务异常(ServiceException) (13)1.2验证服务 ............................................................................. .. (13)1.2.1登录验证 (13)1.2.1.1身份验证令牌实体(UserToken) (13)1.2.1.2身份验证 (13)1.3组织模型管理 (14)1.3.1单位管理 (14)1.3.1.1取得单位ID (14)1.3.2人员管理 (15)1.3.2.1人员实体(PersonInfoParam_All) (15)1.3.2.2方法列表 (16)1.3.2.3创建人员 (16)1.3.2.4修改人员信息(按人员ID) (17)1.3.2.5修改人员信息(按人员登录名) (18)1.3.2.6删除人员(按人员ID) (19)1.3.2.7删除人员(按登录名) (20)1.3.2.8启用/停用人员(按人员ID) (20)1.3.2.9启用/停用人员(按人员登录名) (21)1.3.2.10修改人员密码(按人员ID) (22)1.3.2.11修改人员密码(按人员登录名) (22)1.3.3部门管理 (23)1.3.3.1部门实体(DepartmentInfoParam_All) (23)1.3.3.2方法列表 (23)1.3.3.3创建部门 (24)1.3.3.4更新部门(按部门ID) (25)1.3.3.5更新部门(按部门路径名称) (25)1.3.3.6删除部门(按部门ID) (26)1.3.3.7删除部门(按部门名称) (27)1.3.3.8删除部门(按部门名称及父部门名称) (27)1.3.3.9删除部门(按部门路径名称) (28)1.3.3.10启用/禁用部门(按部门ID) (28)1.3.3.11启用/禁用部门(按部门名称) (29)1.3.3.12启用/禁用部门(按部门名称及父部门名称) (30)1.3.3.13启用/禁用部门(按部门路径名称) (30)1.3.3.14移动部门(按部门ID) (31)1.3.3.15移动部门(按部门名称) (32)1.3.4岗位管理 (32)1.3.4.1岗位实体(OcupationInfoParam_A8_All) (32)1.3.4.2方法列表 (32)1.3.4.3创建岗位 (32)1.3.4.4更新岗位(按岗位ID) (33)1.3.4.5更新岗位(按岗位名称) (34)1.3.4.6删除岗位(按岗位ID) (35)1.3.4.7删除岗位(按岗位名称) (36)1.3.4.8启用/禁用岗位(按岗位ID) (36)1.3.4.9启用/禁用岗位(按岗位名称) (37)1.3.5职务级别管理 (38)1.3.5.1职务级别实体(OtypeInfoParam_A8_All) (38)1.3.5.2方法列表 (38)1.3.5.3创建职务级别 (38)1.3.5.4更新职务级别(按职务级别ID) (39)1.3.5.5更新职务级别(按职务级别名称) (40)1.3.5.6删除职务级别(按职务级别ID) (41)1.3.5.7删除职务级别(按职务级别名称) (41)1.3.5.8启用/禁用职务级别(按职务级别ID) (42)1.3.5.9启用/禁用职务级别(按职务级别名称) (43)1.4组织模型数据管理 (44)1.4.1方法列表 (44)1.4.2导出人员信息 (44)1.4.3导出部门信息 (46)1.4.4导出岗位信息 (48)1.4.5导出职务级别信息 .................................................................... 错误!未定义书签。
NC总体介绍

分析集中
跨单位查询
预警集中
… 下级单位 库存情况 下级单位 收入情况 下级单位预算 执行情况
上级领导
NC产品特点
集成的、完整的ERP 个性化应用:工作流技术 友好性:菜单、界面风格、待办事务…
先进性:B/S结构
开放性:数据交换平台、二次开发平台… 安全性:权限设置、上机日志… 国际化:多语言、多币种
集中管理的优势
!保证集团严格贯彻相关管理制度与政策,加强统一管理 !保证信息的真实、完整、及时,为集团决策提供有利数据 !加强对分子公司监控,降低管理成本 !…
NC的多组织架构
合并账套 账套 公司 部门 公司 部门 责任中心 库存组织 仓库 库存组织 仓库 账套
A
B
C D E
F
G H
销售组织
采购组织
存货管理档案
集团
分公司 生产控制信息
存货生 产档案
分公司
工厂 工厂 (库存组织) (库存组织)
控制集中
参数可以选择在任一级进行控制,上级单位控制下级单位的参数
集团公司
财务核算政策、 资产折旧政策
子公司
子公司
子公司
销售政策
孙公司
孙公司
孙公司
工资政策
控制集中
可选择是否对下级单位进行控制 可定义对下级单位控制的程度
企业信息化高端解决方案
用友ERP-NC
企业信息化的五个层次
1. 面向事务的信息化 2. 面向职能的信息化 3. 企业管理信息化 4. 企业信息化
5. 国民经济和社会信息化
国家经贸委综合司邓志雄副司长
大型企业管理信息化存在的问题及对信息系统的要求
机构庞大 分支众多 地域宽广
用友NC系统模块功能说明及应用介绍

基础设置 客户管理
项目 CRM 信息维护:参照房地产公共模块中项目档案后进一步维护项目的 CRM 信息,例如 该项目所包含的业态信息、项目推广名、计划开盘日期等资料。 楼栋档案:建立车位及别墅前也要建立虚拟的楼栋,依据该虚拟楼栋建立车位及别墅,项目公 司可引用项目档案建立的项目后建立本项目所属的楼栋。 户型类别:设置房产户型所属类别资料,集团统一制定后各项目公司销售时引用。 户型档案:由项目人员录入该项目的户型档案,户型类别可参照集团维护的户型类别档案,房 产资料会引用此户型档案,已被引用的户型档案不能被删除。 朝向档案:集团维护朝向档案,各项目公司录入房产资料中的朝向信息时引用此档案。 销售状态:集团统一维护销售状态,项目公司参照此档案,可定义每种状态的名称、显示颜色 和类型。 快速建房:项目公司采用一定的房号生成模式,快速建立房产档案,并可对房产进行批量删除、 修改。 房产资料:查询房产详细信息,批量维护房产资料,基本操作与“ 快速建房” 相同,并能对房 产进行拆分和合并。 投诉分类:投诉分类档案是投诉登记单上投诉类别的依据。在员工填写单据时候选取相关的投 诉类别。投诉类别便于使用者确定相关责任部门、责任人,并且规定相关的解决时间限制。支 持多极分类,新增、修改、删除。 装修标准:维护各项目使用的装修标准信息,签约时引用当前房产使用的装修标准、装修单价 途径分类:维护营销策划业务中认知途径分类信息,由集团统一制定,集团制定后各项目引用, 在已有分类基础上维护各项目的认知途径信息 途径档案:维护各项目客户认知途径信息,依据认知途径统计客户认知来源情况 销售分组:维护销售业务中置业顾问及销售主管分组信息,用于设置各组组长及其与组内成员 数据权限关系;目前规划分组属于项目,即一个项目有一套分组,销售岗位中指定相应业务员 所属分组 销售岗位:维护销售业务中涉及的岗位信息,项目公司销售部人员属于其中某一岗位;岗位都 有相应角色,角色分为:置业顾问、销控人员、销售主管、销售经理;角色由系统内置;目前 规定为项目设立岗位 销售进程:自定义签约时所使用的付款方式以及依据该付款方式房产销售进程模版,认购及签 约时指定付款方式,并依据该付款方式更新房产销售进程 款项类型:用来维护款项类型的档案,输入的款项类型都会被“ 款项设置” 所引用 款项设置:树卡形档案:以树形结构展示款项类型与款项之间的关系 推盘:维护房产历次推盘信息 房产传物业:把已签约的房产和业主的客户信息传给物业 客户管理规则:维护客户录入校验规则及物业可看信息规则,项目公司进行维护 客户反馈:设置客户反馈信息,制定后录入客户跟踪信息时参照;树表型档案。 个人客户:项目公司在此维护个人客户信息。提供个人客户的新增、修改、删除、填写问卷、 客户分配操作。 企业客户:项目公司在此维护企业客户信息。提供企业客户的新增、修改、删除、填写问卷、
用友NC企业应用解决方案白皮书

用友N C企业应用解决方案白皮书提供先进的软件和专业的服务,帮助我们的企业在全球化竞争中获取优势,并且与我们的客户一起分享他们的成功经验。
这就是用友NC。
©版权所有1989-2001用友软件,保留所有权利2001年11月∙V1.2未经用友软件公司书面许可,本白皮书任何部分的内容不得被复制或抄袭用于任何目的。
本白皮书的内容在未经通知的情形下可能会发生改变,敬请留意。
本白皮书提及的一些产品或技术可能是其它产品供应商的权益。
I B M、V i s u a l A g e、W e b S p h e r e、M Q S e r i e s、C I C S、E n c i n a、D B2、U D B、I A A、A I X、O S/400、O S/390、R S/6000、A S/400是I B M公司的注册商标。
M i c r o s o f t、W i n d o w s、W i n d o w s N T、W i n d o w s2000、W i n d o w s X P、.N e t、C O M、D C O M、C O M+、D N A、M T S、A S P、M S M Q、S Q L S e r v e r、I E是M i c r o s o f t公司的注册商标。
S u n、S u n O N E、S o l a r i s、J a v a、J a v a B e a n s、J2S E、J2E E、J2M E、E J B、J S P、A p p l e t s、S e r v l e t是S u n公司的注册商标。
B E A、W e b L o g i c、T u x e d o是B E A公司的注册商标。
i P l a n e t、i P l a n e t A p p l i c a t i o n s S e r v e r是i P l a n e t公司的注册商标。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
用友软件股份有限公司高级分析平台语义模型红皮书版本:V6.0.0.20100924目录一、前言 (3)1.概念 (3)2.定位 (3)二、结构 (3)1.应用模型 (3)2.语义模型 (4)a) 定义形态 (4)b) 执行流程 (6)c) 数据形态 (7)3.语义提供者 (7)a) 接口 (7)b) 扩展 (10)4.函数 (14)a) 函数解析 (14)b) 函数扩展 (14)5.参数 (17)a) 参数定义 (17)b) 参数引用 (17)c) 参数设置 (18)6.宏变量 (19)7.描述器 (20)8.数据加工 (22)9.物化策略 (24)10.复合语义模型 (25)11.语义上下文 (29)三、语义模型的管理 (32)1.对象管理 (32)2.环境配置 (35)四、功能扩展 (36)1.扩展语义提供者 (37)2.扩展业务函数 (37)3.使用数据加工 (37)4.自定义执行策略 (37)五、附录 (38)1.入门 (38)2.语义模型API (43)3.语义函数 (45)4.其他函数 (45)5.脚本引擎 (47)6.针对查询引擎的改进 (47)一、前言1.概念SMART,即Semantic Modeling for Analysis Report Toolkit, 分析报表语义建模工具。
2.定位二、结构1.应用模型上图为语义模型应用结构图。
语义模型通过语义提供者,可以将多个数据源的数据进行整合。
2.语义模型a)定义形态下图展示了语义模型的内部结构,a)元数据元数据是指描述数据的数据,是为了外界使用数据而对数据本身含义的阐述。
拿我们最常见的二维数据(行列结构)举例来说,如果只有这些行列结构的数据,对我们来说这将毫无意义。
因为我们无法知道哪一列的数据代表什么含义,无法知道如何操作这些数据,更别提由这些数据分析出有用的信息。
反过来,如果针对这些数据指定了元数据,我们就可以了解哪一列代表的业务含义,并且知道该列的数据类型、长度、精度等。
这样,我们就能对这些数据进行加工处理,分析提取出有价值的信息。
同理,语义模型的元数据是对执行语义模型后获取的二维数据的描述。
元数据针对结果数据的每一列都提供了下列信息:数据类型、字段显示名、字段名、备注、长度、精度等。
有了这些信息,我们就能知道在业务应用中该如何使用语义模型。
b)语义提供者语义提供者,表述了一类取数方式,或者说如何提供数据的方式。
在语义模型中,语义提供者负责把一类业务取数过程以语义脚本的形式描述出来。
为了能更好的理解这个概念,我们可以打这样一个比方:NC元数据、数据仓库、报表数据、总账数据等这些可提供数据的对象好比“数据水源”,而语义提供者好比“水泵”,语义模型好比“抽水机”。
每种“数据水源”只支持特定的“水泵”来抽取数据。
我们有了一种语义提供者“水泵”,就能抽取其对应的“数据水源”里的数据。
语义模型中能指定多个语义提供者,就相当于“抽水机”挂接了多个“水泵”,我们就能从多个不同类型的“数据水源”来抽取数据。
语义提供者负责抽取数据,同时对外提供元数据来描述这些数据。
语义提供者的元数据一般是在语义模型内部使用。
更多细节以及语义提供者的扩展说明参见章节《语义提供者》。
c)描述器描述器是指对数据操作的描述,例如:过滤、排序、分页、汇总等。
在语义模型中,描述器表述了对语义提供者抽取的数据的加工处理过程。
更多细节参见章节《描述器》。
d)首选项语义模型中的首选项包括三类数据:参数、宏变量、配置项。
下面将分别介绍:i.参数参数是模型中代表动态信息的元素,用于响应用户的输入。
参数给用户提供了控制模型执行过程的机会。
更多细节参见章节《参数》。
ii.宏变量宏变量与参数类似,区别是,参数在模型执行时需要用户输入值;而宏变量不需要与用户交互,系统后台会根据上下文计算该值。
更多细节参见章节《宏变量》。
iii.配置项配置项用于控制语义模型的执行方式。
b)执行流程语义模型的执行流程如下图所示:语义提供者:NC元数据QDI元数据业务数据语义模型...语义函数:nc_metadata()smart()report()parameter()macro()...语义模型执行过程可分为以下步骤:第一步:语义模型脚本化语义模型中的对象结构将转变为字符串形式的语义脚本。
第二步:脚本对象化通过脚本引擎把语义脚本解析为脚本模型,即把字符串形式的脚本对象化。
第三步:脚本模型翻译为SQL基于脚本模型,处理其中的语义函数,把脚本模型翻译为标准SQL语句。
运行态描述器会在这一步被处理。
第四步:执行sql,把结果集封装为DataSet,返回DataSet。
由于运行态描述器的存在,每次执行语义模型时获取的最终sql都是不同的,但是,语义模型本身对应的脚本模型是相同的。
基于性能考虑,我们可以把语义模型对应的脚本模型缓存起来。
这样一来,只有第一次执行语义模型时,我们需要完整执行上述四个步骤,接下来的每次执行,我们只需取得该缓存的脚本模型,再做第三、四步的处理即可。
c)数据形态语义模型提供的数据可以以两种形态存在:数据集DataSet、数据表DbTable。
从数据流转的角度来说,语义模型代表了一种取数管道,数据可以从管道中抽取出来。
数据集DataSet 代表了内存中的数据,或者说,数据在内存中以数据集DataSet为载体。
数据表DbTable代表了数据库中的数据,或者说,数据在数据库中以数据表DbTable为载体。
语义模型、数据如果把数据集中的当前数据持久化到数据库中,数据就以数据表的形式存在;把数据从数据库中加载到内存中,就完成了数据表到数据集的转换;数据表可以以语义提供者的形式构成语义模型,完成数据从数据表到语义模型的流转;并且,语义模型经由视图化执行,最终的结果集将以数据表的形式呈现。
数据在不同形态间流转时,改变的是数据载体,不变的数据本身的结构,即元数据。
3.语义提供者语义提供者,表述了一类取数方式,或者说如何提供数据的方式。
在语义模型中,语义提供者负责把一类业务取数过程以语义脚本的形式描述出来。
a)接口语义提供者包括NC元数据、DW元数据、以及语义脚本和业务代码扩展提供者。
提供总帐、HR、供应链、报表等业务数据扩展。
其整个体系结构可由下图表示:SQL 的应以提供二维其中,Provider 是语义提供者的接口;SemanticProvider 是基础扩展抽象类,对能把取数过程以脚本形式描述的语义提供者可继承此类;SemanticDataProvider 是语义数据扩展抽象类,对不能以脚本形式描述取数过程,只能提供二维数据的提供者,可继承此类。
SemanticSqlProvider 适用于提供者在运行时根据执行环境context 返回不同取数sql 与SqlProvider 的区别在于:SqlProvider 的sql 结构在定义态已经确定;SemanticSqlProvider 是在运行时,经过一系列业务处理,返回最终取数sql.上述图中,蓝色代表具体实现类。
通过以上的介绍我们可以得知,Provider 定义了语义提供者的接口规范,SemanticProvider 、SemanticDataProvider 、SemanticSqlProvider 则是我们具体实现提供者时要继承的抽象类。
现对这四个类的主要接口做重点介绍。
Provider●SemanticProvider●SemanticDataProviderSemanticSqlProviderb)扩展前面介绍了语义提供者的整个体系结构,现在我们拿一个具体例子来讲解如何实现一个语义提供者。
我们以比较简单的“数据表”这类取数方式来做示例。
扩展语义提供者可分为以下三步:i.实现语义提供者类由前文介绍,我们知道实现一个提供者有三种方式:1.继承SemanticProvider:能把取数过程以脚本形式描述的语义提供者可继承此类我们现以数据表提供者为例来讲解如何以此种方式实现语义提供者。
数据表提供者对应的实现类为:DbTableProvider,该类继承于SemanticProvider,实现了接口provideMetaData(SmartContext context) ,provideScript(SmartContext context)。
数据表提供者,是把NC元数据底层数据模型中的一张表作为操作对象,从中抽取数据。
其在语义模型中的操作是这样的:在上级“模块”目录上选中模块“平台”,展开后在子节点上选中“sm_user”这张表。
在数据表提供者DbTableProvider中,我们只需要存储一条信息:表名。
这些信息可以看做取数过程的业务描述,接下来我们做的就是把这些业务描述转换为以语义模型中的概念来进行描述。
实现provideMetaData(SmartContext context)接口:有了表名信息,我们就可以把其列信息拿到,列Column解析为字段Field,每列对应一个字段,多个列对应的多个字段就组合为元数据MetaData。
实现provideScript(SmartContext context)接口:数据表提供者比较简单,直接返回表名即可。
到此,我们的数据表语义提供者类就实现完毕。
2.继承SemanticDataProvider:不能以脚本形式描述取数过程,只能提供二维数据的提供者,可继承此类例如,供应链中有些查询并不能直接通过一条sql就能查出,中间可能经过一系列复杂的代码运算逻辑来构造这个结果数据,这时我们就可以继承SemanticDataProvider来实现语义提供者。
继承此类只需要实现provideData(SmartContext context)接口:在该方法中,我们编写运算逻辑,构造最终的结果数据DataSet,返回之即可。
在此我们有必要介绍下DataSet的结构。
DataSet主要包含两部分:元数据MetaData,数据容器Object[][](即二维数组)。
Object[][]即是最终的结果数据,MetaData是对数据的描述信息,包含对应字段信息:字段名、数据类型、数据精度等。
3.继承SemanticSqlProvider:应用方式与SemanticDataProvider类似,不同在于,SemanticDataProvider最终返回二维数据,而SemanticSqlProvider返回sql语句。
ii.实现语义提供者设计向导类有了语义提供者类,我们还需要一个设计器来设计语义提供者。
每个设计器都需要实现接口IProviderDesignWizard。
该接口只有一个方法:/***@param parent父窗口。
为ProviderStepPanel,藉此可获得SmartModelWizardShareObject(向导模型,包含向导共享数据)*@param provider待修改的语义提供者*@param context上下文*@return设计完成后的语义提供者*/public Provider design(Container parent,Provider provider, SmartContext context);当设计语义提供者时,会调用此方法,调用完成返回提供者实例。