OMS管理系统设计方案

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

OMS系统设计方案
Ver.1.0
变更履历
目录
1 概述 (4)
2 需求分析 (5)
2.1. 系统整体架构 (5)
2.2. OMS系统需求 (5)
1) 易用性和友好性 (5)
2) 数据集成与共享 (5)
3) 耦合度 (5)
3 总体规划 (6)
3.1. 系统架构设计方案 (6)
1) 三层B/S架构 (6)
2) 基于WebServices的统一数据交换技术 (6)
3) 面向MVC的实现路线 (7)
4) 系统扩展性 (7)
3.2. 软件整体设计方案 (7)
3.3. 系统安全性 (8)
3.4. 其他设计原则 (8)
4 系统功能规格 (10)
4.1. 数据定向分发 (10)
4.2. 数据标准化转换 (10)
4.3. 追溯查询 (11)
4.3.1 近期数据查询 (11)
4.3.2 历史数据查询 (11)
4.4. 跨系统查询 (12)
4.4.1 查询 (12)
4.4.2 配置 (12)
4.5. 系统管理 (14)
4.5.1 接口管理 (14)
4.5.2 规则集管理 (19)
4.5.3 基本属性设置 (22)
4.5.4 系统代码设置 (22)
4.5.5 日志管理 (23)
4.5.6 字典管理 (24)
1 概述
OMS管理系统的建设,是为了加强公司各系统平台之间的信息共享,减少各系统平台之间的数据不一致,提高各系统平台的信息利用效率等目标。

通过该系统可以提高用户的工作效率,减少数据的重复输入,降低成本以及减少人为错误。

在今年刚刚闭幕的中国共产党十八届三中全会上,中国政府提出提高社会和企业信息化水平,加强信息化的运用,加大信息化的整合,加快信息化的发展,大力加强信息化建设,统筹推进“四化”进程。

建设OMS管理系统,能进一步提高和强化企业的信息化管理水平,提高各个子系统平台的信息共享,提高工作效率及减少人为错误。

2 需求分析2.1.系统整体架构
2.2.OMS系统需求
根据前期需求调研,结合各个系统业务实际,OMS管理系统包含数据定向分发、数据标准化转换、追溯查询、跨系统查询和系统管理模块。

系统功能如下图所示:
1)易用性和友好性
系统具备可视化的工作界面,功能设计合理实用,易于操作使用,各类用户无须专业培训,即可快速掌握软件基本操作。

软件提供联机帮助说明,用户可个性化设置(如快捷方式、界面布局等)和深度应用。

2)数据集成与共享
系统采用SOA架构,可以高效、方便的为其他应用系统提供服务,同时也调用其他应用系统,使得数据在各个零散的系统中共享。

3)耦合度
OMS系统和各应用系统之间既独立又相互联系,OMS系统本身是一个独立的接口服务平台,系统上线后通过各种配置将其他应用系统关联起来。

3 总体规划3.1.系统架构设计方案
1)三层B/S架构
系统采用三层B/S(浏览器/服务器模式)架构,基于Web互联网技术,主要事务逻辑在服务器端实现,能有效地保护数据平台和管理访问权限,服务器数据库也很安全。

用户不必另外安装客户端软件,大大简化了客户端电脑载荷,减轻了系统维护与升级的成本和工作量,降低了用户的总体成本。

同时B/S架构已经逐渐成为目前信息化建设的默认标准,采用浏览器/服务器的体系机构将能够大幅度降低系统的使用和维护成本,更符合大多数用户的使用习惯。

采用三层体系结构的优点:
1、开发人员可以只关注整个结构中的其中某一层;
2、可以很容易的用新的实现来替换原有层次的实现;
3、可以降低层与层之间的依赖;
4、有利于标准化;
5、利于各层逻辑的复用。

2)基于WebServices的统一数据交换技术
采用面向管理、服务的方式来建设本系统,在数据交换服务、应用服务、资源汇集、重组、注册和发布服务是采用WebServices部署在网络上的对象(或组件)集合技术。

它采用对象/组件技术、使用标准的Internet协议、将功能展示在互联网和企业网内部。

它的基石是以XML为主的、开放的Web规范技术,因此具有比任何现有的对象技术更好的开放性。

OMS管理系统设计和建设是基于SOA的整体构架思想,采用XML的数据交换技术和基于WebServices服务进行业务系统整合和集成支持。

以XML数据交互引擎,实现异构系统间XML 数据的传输、迁移等服务,完成数据抽取、加载、发布和订阅模板以及数据格式的转换。

以WebServices技术进行业务集无缝集成和互操作的可信整合。

通过标准化接口、标准化服务描述、发布、发现等,解决了全局业务调用、集成,整合、个性服务等问题。

实现基于应用的业务协
作,为应用系统集成提供全新的应用集成手段,使得所有的业务应用系统,可以通过WebServices技术进行相互调用,并通过流程重组以及流程整合提供多种新型的、跨业务系统的应用,真正能够实现业务流互联互通、各类应用业务集成与发展。

3)面向MVC的实现路线
模型-视图-控制器(Model-View-Controller,MVC)体系结构模式将一个交互式应用程序分为三个组件。

模型包含应用问题的核心数据、逻辑关系和计算功能,它封装了所需的数据,提供完成问题处理的操作过程,还为视图获取显示数据提供访问其数据的操作;视图向用户显示信息;控制器以事件触发方式处理用户输入,并为每个输入事件提供了相应的操作服务。

视图和控制器共同构成了用户接口。

MVC模式是. NET应用程序开发中被广泛使用的一种体系结构,它将传统的输入、处理和输出模型转化为图形显示的用户交互模型。

.NET平台上,模型层负责表达和访问商业数据,执行商业逻辑和操作,同时控制层也可以访问其功能函数以完成相关的任务。

视图层负责显示模型层的内容,它从该层取得数据并指定这些数据如何被显示出来,它也会将用户的输入传送给控制器。

控制层负责定义应用程序的行为,它可以分派用户的请求并选择恰当的视图用于显示,也可以解释用户的输入并将它们映射为模型层可执行的操作。

4)系统扩展性
系统在设计时,充分考虑到系统的通用性、扩展性。

在选择技术实现时做到可配性强、配置灵活,以适应不同情况下用户的需求,使系统能够运行在多种不同的平台之上。

充分考虑应用以及今后业务的可能扩展,随着数据量的增加和运行节点的扩展,系统能够随着硬件和系统软件的升级或增加,具有良好的可扩展性。

应用软件应具有良好的开放性,遵循业界相关标准,支持开放的标准接口,使整个系统成为一个统一的整体。

应用支撑平台模块间相对独立,接口清晰,内部的业务流程升级和改造与其它模块无关,所有模块基于组件Web Services开发,可插拔。

3.2.软件整体设计方案
OMS管理系统采用基于SOA的分布式服务架构方案,通过该方案可以使OMS满足未来企业高速发展需要的高性能、高可靠性、高可扩展性的需要。

依据这套方案,我们将系统进行如下的划分(详细部署图见图):
Web服务集群基于SOA的服务组件,用于提供OMS的所有业务处理。

Web应用程序集群供用户管理和查询的用户友好的可视化界面。

数据库读写分离利用Oracle数据库的主从数据库热备功能,实现读写数据库的数据同步。

应用服务器在写数据时访问主数据库,主数据库通过主从复制机制将数据更新同步到从数据库。

分布式缓存(Memcached)加快数据访问速度,减轻后端应用和数据存储的负载压力。

负载均衡服务器利用开源的业界广泛使用的Nginx服务器实现负载均衡,以提升OMS的性能和可靠性。

3.3.系统安全性
系统支持SSL加密通讯协议,使用SSL可以对通讯内容进行高强度的加密,以防止数据在网络传输时被窃取。

3.4.其他设计原则
实用性和可行性:主要技术和产品具有成熟、稳定、实用的特点,实用性放在首位,既便于用户使用,又便于系统管理。

先进性和成熟性:系统设计采用超前思维,先进技术和系统工程方法,同时兼顾思维的合理性,技术的可行性,方法的正确性。

不但能反映当今的先进技术和理念,而且具有发展潜力,能保证未来若干年内占主导地位。

开放性与标准化原则:OMS接收和发送的数据都是基于标准的XML数据,J2EE、.NET等其他平台都是可以很方便的与OMS进行对接。

可扩充性及易升级性:适应应用不断拓展的需要,应用平台的软硬件环境有良好的平滑可扩充性。

安全性和保密性:充分考虑信息资源的共享,注意信息资源的保护和隔离,分别针对不同的应用和不同的网络通信环境,采取不同的措施,包括系统安全机制、数据存取的权限控制等。

系统架构中各层应采用成熟的、符合技术标准服务器、中间件、数据库产品。

系统应保证Window XP Professional客户端的正常使用,浏览器建议采用IE7.0以上版本,并在TT、Firefox 等主流浏览器上测试通过。

4 系统功能规格
本章将详细描述各个模块的需求功能规格,会给出具体的页面布局及页面所展示的信息内容,即Web应用开发中称为低保真页面的页面蓝图,更为精细的大小、位置由UI设计师在实际Web开发时给定。

对于后台数据处理模块给出详细的处理流程图。

4.1.数据定向分发
数据定向分发分为主动推送、定时轮询和客户上传数据资料三种方式。

各方式的系统活动图如下所示:
主动推送
定时轮询
客户上传数据资料
4.2.数据标准化转换
通过预先定义好的数据标准化转换规则进行数据转换,包括业务系统->物流系统、物流系统->业务系统双向转换。

其中还需要考虑异构数据库之间的数据类型、字段转义、字段位长等格式要求,对于没有定义转换规则的业务类型、转换异常的数据系统自动向数据发送方进行异常反馈,具
体流程如下:
4.3.追溯查询
为保障系统安全稳定运行,数据交换有据可查,提供接口服务流水记录查询功能。

可以查询业务名称、发送数据的时间、发送方的IP、发送方的基本信息、发送的数据内容、转换后的数据内容、接收方的基本信息、本次处理的状态等数据。

下图是追溯查询主界面:
追溯查询分为近期数据查询和历史数据查询。

1.1.1 近期数据查询
查询近期业务日志(查询即时数据表),默认查询当天数据,用户可自行查询近三天,近一周,近一月的数据(快捷查询天数,需要和日志保留时间匹配,只显示保留时间内的快捷查询)。

同时用户可自行设置其他的查询条件,如可根据用户,状态,数据接收方,数据发送发,操作时间段等信息进行查询过滤。

如果查询时间跨年了,需要单独处理。

点击查看,弹出页面(不覆盖原有页面),可查询对比转换前的数据和转换后的数据,如果不一样,则需要区分开(如:标红),同时,需要将部分基础信息带入到查看页面,如:操作用户,操作时间,数据发送发,数据接收方。

如下图:
1.1.2 历史数据查询
查询历史业务日志(查询历史数据表),默认查询历史数据表中最新一天的数据,用户可自行设置其他的查询条件,如可根据用户,状态,数据接收方,数据发送发,操作时间段等信息进行查询过滤。

数据段的查询不允许跨年。

只能查询同一年的数据。

如下图,主界面:
点击查看,弹出页面(不覆盖原有页面),可查询对比转换前的数据和转换后的数据,如果不一样,则需要区分开(如:标红),同时,需要将部分基础信息带入到查看页面,如:操作用户,操作时间,数据发送发,数据接收方。

(同近期数据查询中功能一致),如下图:
追溯查询是针对业务日志进行的查询,业务日志在数据库中分成两张表记录数据,一张即时数据表(业务日志保留时间内,保留时间可配置),和一张历史数据表。

两张数据表结构完全相同,历史表中采用分表方式,一年一张历史表,每张历史表有十二个分表,分别记录十二个月份的日志记录。

后台服务,按照系统设置的日志保留时间,从即时数据表中拿取保留时间外的数据添加到历史数据表中。

4.4.跨系统查询
1.1.3 查询
跨系统查询不涉及到界面,所以只给出基本处理流程,如下图:
1.1.4 配置
配置每个系统对外提供的查询服务,以及可以被那些系统可以调用,
下图是配置管理界面:
区域1位置是常规的查询区域。

区域2位置是查询结果区域,可以对数据进行新增、复制、修改、删除、恢复、导出、查看操作。

点击图标进行复制操作;点击图标进行修改操作;点击图标进行删除操作;点击图标进行恢复操作。

点击增加按钮进入新增配置页面,如下图所示:
服务名称必须填写,标识该服务的唯一名称。

服务提供方必须选择,下拉框的数据从系统配置表获取。

服务访问地址必须填写,为服务提供方的服务访问地址,如:https。

服务访问方式必须选择,采用IPHONE面板式的选择方式,取值范围为GET/POST。

请求参数非必填,一般用于传输权限验证信息,如数据提供方不需要验证则可不填写,可以增加多个参数。

数据访问方必须选择,标识该服务可以被那些系统访问,数据从系统配置表中获取,不能选择服务提供方本身。

点击导出按钮可以将满足查询条件的结果导出成excle文档(格式在详细设计时制定),便于共享给各个系统。

4.5.系统管理
1.1.5 接口管理
1)模板管理
为了提高系统的可用性,减少配置的复杂度,将公共的模块抽象出来,建立成单独的小模块,方便多系统间关联配置。

模板维护功能包括对模板的查询、修改、删除等操作,还提供便捷的复制功能,便于快速添加相似的模板。

如上图所示为模板维护主界面,区域1位置为查询条件,提供基本的查询条件,并提供灵活的高级查询功能。

查询条件中的状态值分为正常、已删除、未测试,未测试表示该模板未经过数据规则转换测试,在接口配置将不能选择未测试通过的模板信息。

区域2位置为查询结果区域,对于查询结果可以进行常规的操作,比
如点击模板名称可以进入模板详情查看页面;点击图标可以完成快速复
制模板的功能;点击图标可以进入编辑模板的页面;点击图标可以删除该模板;点击图标可以进行恢复操作。

点击添加模板按钮进入到添加页面,如下图所示:
添加模板共分为五个操作步骤(基本信息配置、交换字段配置、规则配置、保存配置、测试配置)。

第一步,基本信息配置,包括定义模板名称、选择传输方向、时效性、备注信息。

模板名称,定义一个本系统中唯一的名称,便于记忆。

传输方向需要动态生成,通过读取数据字典中系统类型的数据来生成。

比如系统类型有ERP、LMIS,则生成ERP->LMIS、LMIS->ERP,以此类推。

时效性通过数据字典读取。

第二步,配置数据交换的详细字段定义,如下图:
序号为本次交互字段的顺序编号,自动增长,从1开始,理论上无最大值限制。

数据发送方信息包含字段名称、类型、长度、数据接收方唯一编码,用于标识本接口发送的数据中每个字段的详细定义,比如商品资料下传接口需要交换37个字段,则需要对这37个字段分别进行定义。

其中类型抽象成整数、浮点数、字符串、日期、大数据类型。

数据接收方唯一编码为单选模式,必须选择,该字段用于传递数据接收方的唯一编码,系统通过解析该编码将数据发送到对应的数据接收方。

当字段被选中为唯一编码后,对应的数据接收方信息不填。

数据接收方信息和数据发送方一一对应,在此不做赘述。

字段描述为该交换字段的中文描述、说明信息。

操作栏的图标表示增加一个交换字段、图标表示删除一个交换字
段,至少保留一个交换字段;进行增加和删除操作时,需要保证序号的连续。

第三步,规则配置,对于各个系统间数据存在数据差异的字段指定转换规则,具体界面如下图:
系统自动将可能需要进行规则转换的字段突出显示(黄色背景标识),
以提示使用者注意。

其他没有提示的数据字段也可以设定转换规则,通过操作栏的图标设置。

转换规则大致可以分为四类,普通规则、日期规
则、数据字典规则、自定义规则,详情如下:
◆普通规则转换:主要涉及数值类型、字符类型的异构数据库之间的转
换。

转换规则见“系统功能——数据类型转换规则”。

◆日期规则转换:由于日期类型种类繁多,如有的系统采用毫秒数存
储,有的系统采用标准的时分秒格式存储,所以需要转换。

◆字典类数据转换:字典类数据在业务系统中的定义与物流系统中的定
义之间的转换,例如:药品大类在业务系统的字段中定义为汉字:一类精神品、二类精神品等,但在物流系统的字段中定义为数值:’1’表示一类精神品、’2’表示为二类精神品。

转换规则见“系统功能——字典数据转换规则”。

◆自定义规则:针对复杂的规则,支持自定义C#函数的形式。

若“数据发送方数据列”和“数据接收方数据列”之间无需进行转换,则不需要进行设置;当需要进行设置时,点击操作栏的图标进入设置界面,
如下图所示:
规则下拉框的数据从规则表中读取,必须选择,第一个下拉框表示规则类型,第二个下拉框表示转换规则。

选择后系统需要进行校验所选的规则是否能够满足转换要求,对于不满足的要给予提示;依次对需要进行规则转换的字段进行设置后,点击下一步进入最后一步完成配置,如下图所
示:
添加时间、统一访问地址系统自动生成。

第四步,确认各项数据无误后,点击保存配置按钮保存接口的配置。

第五步,测试配置是否正确,系统会先生成模板,用户按照模板填写数据后,通过系统上传,系统验证本次配置的正确性,界面如下:对于测试通过/不通过都需要给出提示,测试不通过时要详细给出那个字段不符合要求。

2)接口配置
为了减少配置管理员的工作量,可以批量为一些有共同之处的系统一次性配置接口信息。

数据发送方为多选模式,如下图:
数据发送方不能同时选择ERP和LMIS系统,当数据发送方选择完成
后,再点击数据接收方后面的选择按钮,弹出的选择对话框只能加载另一种类型的系统(如数据发送方为ERP,此时就只显示LMIS系统),对话框的标题也需要动态变成数据接收方,数据接收方为单选模式,只能选择一个系统。

数据交换模板为之前预定义好的接口模板,当选择数据发送方和数据接收方后加载对应类型的模板,通过选择的数据发送方和数据接收方自动判断需要加载那种类型的模板,可以多选。

选中的会用黄色突出提醒。

如果选择的数据接收方是通过Webservice的方式接收数据,则还需要填写Webservice的访问地址,每个系统只用填写一次,以后默认加载显示(如下图红色区域所示),如果数据接收方是通过数据库的方式接收数据,则需要填写数据库表名,如果是其他方式则不需要特殊处理。

点击添加前,需要先验证数据,如果已经存在相同的配置了,需要给出提示,让操作者选择覆盖还是返回修改。

保存数据时,需要将模板中抽象的数据类型转换成数据库标准的数据类型,并用测试模板进行测试,并输出状态,对于不能通过测试的要给予提示,便于操作者维护。

3)接口维护
接口维护功能包括对接口的查询、修改、删除、恢复、彻底删除、导出操作。

如上图所示为接口维护主界面,区域1位置为树形快速导航,数据从系统配置表中查询,点击公司名称默认查询出以该公司为数据发送方的所
有接口配置信息,如ERP同时向两个物流中心发送数据(ERP->物流系统1为7条接口、ERP->物流系统2为1条接口),则会显示8条数据。

区域2位置为查询条件,可以按照接口名称、数据接收方、状态(正常、已删除)进行查询。

数据接收方的下拉框数据,应该根据数据统计得来。

区域3位置为查询结果区域,对于查询结果可以进行修改、删除、彻底删除的操作,
点击接口名称可以进入接口详情查看页面;
点击图标可以进入编辑接口的页面;
点击图标可以删除该接口;
点击图标可以进行恢复操作;
点击导出可以将符合查询条件的接口信息导出成API文档;点击彻底删除按钮可以将选择的数据从数据库中完全删除,删除前必须弹出确认的对话框让操作者确认。

对于有特殊要求,模板满足不了的情况下,点击图标可以进入编辑的页面,该页面默认加载模板的信息,供用户在模板的基础上编辑,提高工作效率。

保存后不会修改到公共模板,而是新建为了一条私有的模板。

如下图,进入接口编辑页面:
编辑页面其他操作与创建模板时一直,编辑完成后,保存配置,提示用户保存成功,提示信息为:保存成功,生成新的版本,是否进行测试?
1.1.6 规则集管理
1)新增规则
该功能用于定义转换规则集。

用于支撑“新增接口✍转换规则配置”功能,共分为四种类型的规则(普通规则、日期规则、数据字典规则、自定义规则),如下图所示:
规则名称手工输入,为规则起一个方便记忆的名称,必须填写。

规则类型必须选择,选择类型后系统自动加载对应的区域以供填写信息,下面对每个区域进行说明。

◆普通规则区域
转换前字段类型,表示数据发送方发送数据的类型,下拉框的数据通过数据字典(抽象数据类型)读取。

转换后字段类型,表示数据接收方接收数据的类型,下拉框的数据从数据字典(抽象数据类型)读取。

◆日期规则区域
转换前字段类型和转换后字段类型同上,下拉框的数据从数据字典(抽象数据类型)读取。

转换前日期格式,如有的系统存储的是毫秒数,转换后日期格式,如有的系统存储的是标准的时分秒格式。

下拉框的数据从数据字典(日期规则数据格式)读取。

◆数据字典规则区域
转换前的值,必填,表示数据发送方系统存储的值,如:一类精神品。

转换后的值,必填,表示数据接收方系统存储的值,如:1。

字段说明,非必填,对该字段进行描述。

图标,增加一行。

图标,删除一行,至少保留一行记录。

自定义规则区域
一些通过常规规则无法转换的,可以通过编写C#自定义函数进行转换,下面对各个字段进行说明。

转换前字段类型,表示数据发送方发送数据的类型,下拉框的数据通过数据字典(普通规则数据类型)读取。

转换后字段类型,表示数据接收方接收数据的类型,下拉框的数据从数据字典(普通规则数据类型)读取。

自定义转换函数,编写一个标准的C#函数,输入值为转换前字段类型,输出值为转换后字段类型,内部逻辑算法自定义,保存时需要校验函数的准确性。

另外,还需要提供输出日志、发送消息的API,供操作者使用。

2)规则维护
规则维护功能如上图所示,用选项卡的方式代替查询,上图示例为日期规则的界面,普通规则和自定义规则参考该页面。

自定义规则页面需要提供查看图标进入自定义函数查看页面。

点击图标进入修改页面;点击图标进入删除页面,已经被使用的规则不允许,用户进行删除时需要给出提示。

由于数据字典的维护界面和普通规则有较大差别,所以单独描述,如下图所示:。

相关文档
最新文档