随笔-19  评论-22  文章-1  trackbacks-0

SOA 大赛设计文档

--- 参加 IBM 高校 SOA 创新应用大赛递交的主文件

超凡 904 代表队

程传慧 [1] 王嘉 [2] 熊晓菁 [2] 苏艳 [2] 陈莉 [2]

[1] 武汉理工大学博士生

[2] 湖北工业大学硕士生

2006 6 30 提交

1 章 项目综述

SOA 是指为了解决在Internet环境下业务集成的需要,通过连接实现的一种软件系统架构。其最高目标是实现所有数据、所有功能的完美整合。

SOA 观念的提出,实际宣布了分布式时代的来临。今后的系统建设可以不过于强调系统性与完整性,而更强调模块性与功能性,通过统一的SOA平台实现各个服务的整合与集成,必须具体解决如下问题:①每个服务都有由消息驱动的执行机制与规范的数据发布机制,能远程控制其调用,并将结果发送到网上被共享使用,将来才能供所有有权且需要的人调用。②采用分布式数据库或有良好安全性、扩展性与共享性的数据库,通过端对端的联接远程对数据库进行维护与调用,这将使得系统具有良好扩展性,可以适应千变万化的应用需要。③系统模块由通用且有自适应性的部件(或叫服务)构成,强化数据独立性,这样才能当数据结构改变后最大限度地提供共享。④通用部件应当是开源的或是可以在线调用的软件,设计规范、标准,容易学习,使得其他需要提供服务的人都能十分容易的按需要求服务。⑤接口简单,即插即用,使得集成操作简单、容易,且易学易用。⑥全系统的控制系统可以动态构成,组装与维护简便,使得能随意集成,让系统发挥最大的效益。

但是,目前正在运行中的系统普遍都不是如此构成的,例如凤凰公司的二个系统都是各自封闭的系统,数据彼此不共享,功能互相不调用。针对这样的系统进行集成,我们的目标是:数据尽可能根据需要达到共享;尽可能扩大各系统现


 

有功能的受益面;尽可能地获取数据集成的效益。

我们设计了一个通用的、具有即插即用特性的SOA平台,可以用在任意多个系统的整合中。它有如下功能:

1 )正确解决数据导入、导出问题,实现服务的开发与封装。提出导入导出规范,包括数据结构、导入或导出配合方法、数据存放位置、关于安全性与数据完整性的控制办法、导入导出的内容等。

当原有系统分别为:①有规范导入导出。②有导入导出但不规范。③没有导入导出等这样三类不同情况时,本设计分别提出了解决方案。

2 )当字段名不一致、内容不对应、代码不统一、表达方式不相同、数据完整性要求不一致时给出数据变换的解决办法。

3 )考虑了保证数据安全的措施。

4 )目前一个系统中已经生成的数据能根据需要通过网络提供给另一方,实现共享。

5 )提出数据进一步整合与集成的解决方案。

6 )在数据集成环境中研究进一步扩大系统功能、提高性能的可能与解决办法。

我们针对凤凰公司的问题具体研究了其数据构成、数据间关系、功能构成、业务流程,分析了为发展业务对系统整合的要求,说明如何利用我们所设计的通用平台实现整合,包括原有系统的重用、新的服务的提供、企业原有业务流程的重组等。

本设计具有强通用性,利用了我们已设计成功的具有自适应性的通用部件使得设计容易,适应面广泛,架构快捷,容易维护。


 

2 章 业务模型分析与展望

2.1 什么是 SOA?

SOA 是指为了解决在Internet环境下业务集成的需要,通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。

SOA 的三大基本特征:

1) 独立的功能实体

Internet这样松散的使用环境中,任何访问请求都有可能出错,因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。 SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术,如.NET RemotingEJBCOM或者CORBA,都需要有一个宿主 (Host或者Server)来存放和管理这些功能实体;当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候,在该宿主上运行的其它应用服务就会受到影响。

SOA 架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术,比如事务处理(Transaction),消息队列(Message Queue) ,冗余部署(Redundant Deployment)和集群系统(Cluster)SOA中都起到至关重要的作用。

2) 大数据量低频率访问

对于.NET RemotingEJB或者XML-RPC这些传统的分布式计算模型而言,他们的服务提供都是通过函数调用的方式进行的,一个功能的完成往往需要通过客户端和服务器来回很多次函数调用才能完成。在Intranet的环境下,这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计,但是在Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。因此SOA系统推荐采用大数据量的方式一次性进行信息交换。

3) 基于文本的消息传递

由于Internet中大量异构系统的存在决定了SOA系统必须采用基于文本而非二进制的消息传递方式。在COMCORBA这些传统的组件模型中, 从服务器端传往客户端的是一个二进制编码的对象,在客户端通过调用这个对象的方法来完


 

成某些功能;但是在Internet环境下,不同语言, 不同平台对数据、甚至是一些基本数据类型定义不同,给不同的服务之间传递对象带来的很大困难。由于基于文本的消息本身是不包含任何处理逻辑和数据类型的,因此服务间只传递文本,对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。

此外,对于一个服务来说,Internet与局域网最大的一个区别就是在Internet上的版本管理极其困难,传统软件采用的升级方式在这种松散的分布式环境中几乎无法进行。采用基于文本的消息传递方式,数据处理端可以只选择性的处理自己理解的那部分数据,而忽略其它的数据,从而得到非常理想的兼容性。

2.2 业务模型分析设计

随着企业规模的不断扩大,IT技术的不断进步,许多企业不断充实了管理信息系统,ERP系统,OA系统,CRM系统,而许多系统都是在企业发展的不同阶段根据不同的需求发展起来的。对于这些不同系统,如果想使用其他系统的数据,常常要从一个系统中打印出数据,再采用人工录入的方式录入到另一个系统中,这样做效率低,容易引发错误。因此,我们首先要做的是构建一个通用的服务平台,使其上任何一个系统都能和其他系统共享数据资源,一方面所需的数据如果在另外的系统中已经存放,就应当能提供一种通用的SOA中间件实现自动传送,将另外的系统中已经存放的数据传送到需要数据的系统中,免于手工录入从而实现两个系统的协同工作。

其次要做的是在此基础上进一步优化全系统,达到系统间整合的目标,发挥整体的最大作用。这又包括二方面问题:1)原来在一个系统中具有的功能,并且产生了结果(数据),但如果仅仅是传过去,在另一个系统中并不能被使用,因为另一个系统已经封闭,不提供显示的功能。虽然,设计传送再显示的工作不难,但我们需要的是通用模块,只需要提供数据的名字,不认是什么结构的数据,都能查询与显示,这才是需要达到的目标。

2 )二个系统的数据不可避免地有不相通之处,存在许多冗余,也有需要再添加的新功能,需要新数据,需要提供整合的方便,与扩展的方便,能轻而易举


 

的构成一个完整的新系统。

这些系统的整合都是通过二二整合实现的,下面我们研究任意二个独立系统之间的整合问题,通过一个系统与另一个系统进行整合的解决方案说明我们的解决方法。任意二个独立系统如图1所示,二系统间可以通过因特网建立联系。

我们认为,进行二个系统整合首先是要实现双方数据互通,其次是适当扩展,整体优化。

1) 数据互通

数据互通是系统整合的基本工作,可以使原先互相封闭的系统通过通讯按照实际需要实现数据传递。需要以下几个方面的约定或做以下工作。

(1 )要求两个系统都按同一协议生成供导出的数据,放在指定位置。两个系统都有将指点位置且符合同一协议的数据导入到自己系统中的程序模块(如图2-1所示)。

该协议应当包括以下8方面内容:

①规定供导入或导出用文件格式。考虑到XML文件格式灵活,可以在文件中表现数据结构,而且是任何系统都可以接受的文件,设计统一采用XML文件进行传送。

具体规定XML文件格式为:在本系统中,根据用友erp提供的xml示例文件,

 

2-1 有待整合的两个独立系统,设有按一定协议生成的导入导出数据及相应程序


 

我们可以得出应用xml文件,用之对erp数据库进行添加、删除、修改。如示例文件:<?xml version="1.0" encoding="gb2312"?>

<ufinterface autocontrast="C" billtype="bsdept" filename=" 部门样本数据文件.xml" isexchange="Y" operation="req" proc="add" receiver="yk" replace="Y" roottag="basdoc" sender="1101">

proc="add"中可以修改成自己想要的类型,例如删除、修改、查询等等。

erp 提供了一个接口,用于接受所发送的xml文件。当服务中间件发出服务请求时,服务中间件发送一个xml文件。文件中包含所要的信息,当发送到erp时,erp自动解析xml文件,并做出响应,也发送一个xml包含我们所需要的数据和信息,然后中间服务件解析该xml文件,做出相应的操作。

为了实现接口的通用性,我们规定XML结构要与表结构一致。目前TurboCrm提供的是TurboEAI企业应用集成。根据所给资料TurboEAI提供了一系列的接口方法,我们所看到的XML文件结构大部分就是表结构,和我们的要求一致,使得外部系统可以不关心TuboCRM的数据表结构和业务逻辑,只需将信息转换为符合系统标准的xml数据,发送到TurboEAI系统,就可以获取想要的数据了(具体而言,有些要加 NULL ,要考虑施加安全性与完整性约束,再放到指定位置去)。但有二个文件 销售订单 采购订单 各应当是二个表的数据,销售订单是销售订单与销售订单子表的数据、采购订单是采购订单与采购订单子表的数据,因此对这二个文件需要先将数据分解为各二个XML文件,再转换为符合系统标准的xml数据,发送到TurboEAI系统。

例如下例:

删除客户:

<Method>

<Name>DelCust</Name>

<Param>

<Code> 客户编码</Code>

<Name> 客户名称</Name>

</Param>

…………………………..


 

其中,DelCustcrm提供的接口方法。

ErpCrm发送XML数据时,由服务中间件的Servlet接口接收。

A 、如果XML里面的数据要经过业务过程,那么就要通过服务中间件的XML解析器来解析该XML文档。然后对数据进行唯一性检测(因为XML并不能保证数据的唯一性),再把数据实例对象化,再对这些数据进行业务操作。由业务操作得出的数据被服务中间件的XML生成器生成XML文档,并发送到ERPCRM(参照业务需求)

B 、如果XML里面的数据不用经过业务过程(定时更新),就通过XSLT进行转换。因为ERPCRMDTD格式不一样,我们设计通过数据字典进行变换。数据字典中存储了ERPCRMDTD格式,服务中间件的XSLT转换成和对方匹配的格式,然后再进行发送。

对于定时数据的具体操作一般有插入,删除,添加,修改,覆盖等不同方式。

C 、如果是添加方式,规定对于传来XML文件中标有NULL的数据变成非空值的空数据填入,即字符类数据填以空格,数值类数据填以0等。如果是更新方式,对于传来的XML文件中标有NULL的数据不予置理,即不修改原表中的数据。

对于每一条数据的每一列,相当于在XML中的一个tag,如果在原始数据库中有一条数据的一列值为null,那么在XML中就少了一个tag,在解析的时候就要在程序中捕获异常,那么程序就会很复杂,所以可以在生成的XML中那个对应的tag附上空格字符,那么对方系统在解析时候会在它的后台对应的位置插入空值,这是插入的情况。然后如果是修改情况的话,那么只能不要那个值为空的tag,在解析程序中捕获异常。

定时数据传输由erpcrm之间互通更新的数据。

覆盖方式对于SOA没有意义。

我们设计规定,定时传送的数据采用 添加与修改 方式:

比如服务中间件中中保存CRM系统从上次完成导入到当前时间的数据,以XML数据文档格式。当定时由服务中间件发送数据更新请求到ERP,对方系统就会传送一个XML文件(该文件包括整张表的数据)到服务中间件。服务中间件解析后,会解析并查阅CRM系统从上次完成导入到当前时间的数据(注意,要有一个文件记载导出时间的关键字值,在数据库中常常未存 时间 ,因此只能将本


 

次导出的最后一个关键字或记录号记下来,再导出时查到该记录,从下一条起是应当新导出的数据),当它当前表没有关键字相符的记录时,将该文件中数据完全导入到该系统数据表中;当CRM系统的当前表中有关键字相符的记录时,用该文件中数据根据关键字更新该系统数据表中数据。

②规定导入或导出配合方法,主要是导入或导出的时间。考虑到SOA的一个思想是大数据量低频率访问,目的是减少网络传输错误的可能并减轻网络通信负担,因此可以设计采用定时交互方式进行导入或导出,例如规定每天通信次数及固定的通信时间,或通过电信系统联系并约定后交互的方式。但考虑到更灵活互动的需要,可以添加实时通信的补充方式。

当采用定时交互方式时,由操作人员应用本系统提供的程序手工操作实现导入与导出。

如果是实时通信方式,一方面通过手机传递操作信息,同时通过向指定端口发送消息,接口程序监听该端口,当有消息时立即启动定时交互操作。

③我们需要完成的是一个通用SOA接口,使得在用于任何两个系统的整合时只需要做简单配置后插上就可用。为此,需要规定导入与导出文件存放位置。

存放位置可以是数据库服务器所在机器中的某个或某二个文件夹,也可以是网上的地址。前一种方法,存放数据容易,安全性好,但只能适应于同类操作系统平台的系统整合。我们设计采用第二种方法,可以适用于不同操作系统,但特别需要加强安全性控制。

我们设计:导入文件存放位置为:

导入文件和程序一样放在硬盘上,作为一个特定的文件夹。在程序中,我们可以编写函数,调用和存储导入文件到该文件夹。具体步骤如下:

当从erpcrm中传送来的导入文件被服务中间件接受后,由我们所编写的程序把该文件存储到一个特定名字和相对路径下的文件夹中。

导出文件存放位置为:和导入文件的存放位置一致.放在一个文件夹中.

将来取出数据需要利用由我们编写的程序从一个特定名字和相对路径下的文件夹中提取所需的导入文件。

④为实现通用性,需要规定导入与导出文件的内容。我们设计导入与导出文件内容除文件头外,对于定时传送方式,要求存放数据库中表的记录,每表一个


 

文件,文件名等同于表名。

⑤需要规定导入与导出文件添加方式。从对方传入的数据可以有添加、覆盖、修改、添加与修改、删除等不同方式,添加方式指在文件尾部添加送来的新数据,覆盖指先删除原有数据再在文件中填入送来的新数据,修改指对送来的新数据先分析其关键字,当另一个系统的当前表中有关键字相符的记录时,用传来文件中数据根据关键字更新另一个系统数据表中数据。上述各方式中,覆盖方式对于SOA没有意义。我们设计规定可以采用其它各种方式,定时传送的数据一般采用 添加与修改 方式:导出用文件中保存另一个系统从上次完成导入到当前时间的数据,当另一个系统的当前表没有关键字相符的记录时,将该文件中数据完全导入到该系统数据表中;当另一个系统的当前表中有关键字相符的记录时,用该文件中数据根据关键字更新该系统数据表中数据。使用该方式时,要求在XML文件的文件头中的<Method>句中用 New_Update + 表名的方式标志。例如对于emp表,采用该方式时,在文件头中有语句:<Method> New_UpdateEmp</Method>

也允许添加、修改、删除方式,分别在文件头中用下述格式标志:

添加,在<Method>句中用 New + 表名的方式标志。

修改,在<Method>句中用 Update + 表名的方式标志。

删除,在<Method>句中用 Del + 表名的方式标志。

要注意,原系统中导入数据的程序要能识别这些方式并做相应处理。使用后三种标志时,要求系统在进行这三种操作时,必须对操作内容进行记载。例如在做删除时,要另存删除内容或同时修改XML文件。否则,当导出时将无法获得已被物理删除的数据。

⑥对于传来XML文件中标有NULL的数据,规定:如果是添加进入,变成非空值的空数据填入,即字符类数据填以空格,数值类数据填以0等。如果是更新方式,即查到有关键字匹配记录,对于传来XML文件中标有NULL的数据不予置理,即不修改原表中的数据。

⑦在导入方,如果实施成功导入后,如果具有对该XML文件删除的权限,应当将文件清空,以作为成功完成导入的标志,其时间就将是前面提到的 上次完成导入 的时间;如果没有删除的权限,应当向接口程序发出导入成功的消息,由接口方程序将有关文件清空。在SOA通用接口程序的结构变换程序中,按时间


 

范围导出的数据在原XML文件不空情况下,将新数据添加到尾部;如果原XML文件为空,则加上文件头部后形成新文件。

⑧供导入的程序如果采用密钥方式,导入程序应有先解密再导入的功能。

(2 )实现导出、导入文件结构变换。不同系统的数据结构肯定是有所不同的,我们如果约定导出、导入文件结构都是原系统中完整数据表的结构,考虑到一个导出表中数据可能是导入表中的部分数据,也可能是多个表中部分数据。要设计出通用的通信接口,就必须完成导入、导出文件结构变换,这一变换程序要能适应任意系统的需要。

我们的设计是建立一个字典表(系统1名称,系统1表名,表1字段名,系统2名称,系统2表名,表2字段名,意义),再设计通用翻译程序完成导出、导入文件结构变换。

(3 )保证安全性与克服安全性屏障。

要保证系统的安全性,防止通过接口程序进行攻击或防止对通过接口程序实施对数据的攻击。关于后者,可以设计密钥方式,对数据加密后传送,解密后导入。

要赋与接口程序取得相应读取数据的权限,产生的供导入的文件要符合原有系统的安全性要求。考虑到安全性与实际数据不完全性(通常一个系统导出用文件的一条记录的数据只是导入表一条记录的部分数据),规定在字典表中填写了 1字段名 ,但没有填写 2字段名 的,转换时去掉该数据相关语句。在字典表中填写了 2字段名 ,但没有填写 1字段名 的,转换时改用空格填充其数据并添加相关语句。

(4 )保证数据完整性与克服完整性屏障。

导入时需要保证数据完整性。数据完整性包括:实体完整性(关键字是否为空,不重复)控制,参照完整性(子表中联系字段值在主表中要求有)控制,域完整性(数据在一定范围)控制。

我们设计重点是实现域完整性控制,具体实现办法是在字典表中增加如下字段: 最大值,最小值,限取值值集,约束条件表达式,是否允许重复值 。其中 约束条件表达式 用字段名加关系符加表达式构成。约定有一个特殊的约束条件表达式:用 c $ A-Z 表示值只由字符构成,或 c $ 0-9 表示值


 

只由数字、小数点、正负号构成,变换程序中应当有专门的方法,当查到这类约束条件时,调用专门的方法进行检验。修改结构后的字典表结构为:字典表(系统1名称,系统1表名,表1字段名,系统2名称,系统2表名,表2字段名,意义,最大值,最小值,限取值值集,约束条件表达式,是否允许重复值,是否需要代码变换,组合公式),在进行变换时要求先按该表中数据进行检验,再生成符合该表各控制要求的供导入的数据文件。 是否需要代码变换,组合公式 的内容见下面说明。该字典表中系统1名称,系统1表名,表1字段名等列中填导出方数据参数,后面11列都填写待导入数据有关参数。

(5 )统一代码问题。

管理信息系统大量数据采用代码表示,或者利用代码进行统计,在进行整合时如果能要求采用统一代码体系自然容易整合,但在很多情况下,这个要求不具备操作性,因此要求SOA接口程序解决代码变换问题。

我们可以设计一个 代码变换表 ,结构为:(系统1名称、系统1代码、系统1代码内容、系统2名称、系统2代码、系统2代码内容)。

其中代码内容指代码所代表的意义,例如用代码 X20020101 表示一款床旁移动X光机: 100KHZ 30KW功率Compact移动式X光机 ,将来在 系统1代码 一栏中填 X20020101 ,在 系统1代码内容 一栏中填 100KHZ 30KW功率Compact移动式X光机 ,系统2代码与系统2代码内容中则填同一型号规格的同一产品在第二系统中的代码与名称。

在接口程序中应当先看字典表中 是否需要代码变换 字段中是否标志为 ,如果标志为是,就查看 代码变换表 ,利用该表实现二个代码数据的变换。

(6 )数据组合与分解问题

在变换时,导入的数据可能是多个导入数据的组合,或者只是其组成的一部分。如果这种组合或分解可以用一个公式计算实现,可以在字典表中写入计算公式,在变换时按公式进行组合或分解。否则需要手工辅助操作完成该项工作。该计算公式由数据导出方的若干字段经连接符连接而成。变换程序中应当有专门的方法,当查到这类计算公式时,调用专门的方法进行处理后再导入。

以上设计的系统结构如图2-2所示。


 

通用SOA整合平台中需要有一个数据登记表,其内容包括:系统1名、系统1数据库名,系统1表名,导出XML文件名,系统2名、系统2数据库名,系统2表名,导入XML文件名,导出时间,导入时间,字典表名称,导出数据存放位置,导入数据存放位置。

导出时间必须早于导入时间。

该整合平台与原来系统采取端对端通信方式,包括如下组件:

          ① 数据变换程序:其功能是读取各导出的数据文件,根据数据登记表及每一组变换依据的字典表对数据重组,生成供另

 

 

2- 3 SOA 整合平台之数据变换程序流程图

 

2-2 通过 SOA 整合平台对系统整合


 

          一个系统导入的文件,并发到指点位置去。数据登记表引导数据变换程序作所有导入导出操作。该变换程序程序流程如图2-3所示。

          ② 对数据登记表进行维护(录入、修改、删除、查询)的组件。我们已经研制成功通用于任意数据结构的基于JAVA的数据维护部件(下文中将专门介绍),关于 通用部件库 项目于2005年经湖北省教委组织鉴定:达到国际先进水平。本处设计用该数据维护部件构成对数据登记表维护的组件。

          ③ 对各字典表进行维护的组件。用上述数据维护部件充当该组件。

          ④ 对各代码变换表进行维护的组件。用上述数据维护部件充当该组件。

 

在完成设计用于具体系统之前,需要做如下工作:

①确定二方数据的数据结构,确定所需对方数据的内容。

②思考如何抽取对方系统的数据填写字典表。

③研究原系统安全性与完整性要求,填写字典表。

④确定代码体系,填写代码变换表。

⑤确定数据发送与导入时机及其控制方式,填写数据登记表。

2) 如果两系统虽然具有数据的导入、导出功能,但导入、导出的文件格式不符合要求,无法按上述协议导入、导出,需要设计加有导入、导出数据格式变换功能的程序,此时SOA平台如图2-4所示。

其中两对导入、导出程序设计为4个组件外挂在原来的SOA平台的变换组件

 

2-4 导入、导出的文件格式不符合要求时的SOA平台


 

上。

目前导出的常见的文件格式有:纯文本、ExcelXMLHTTPSOAP等格式,需要统一变换为符合前述要求的XML文件格式。导入的文件格式也常为上述格式,需要由统一的XML格式变换为所需要的格式。

对数据登记表结构需要做一点修改,除原有内容 系统1名、系统1数据库名,系统1表名,导出XML文件名,系统2名、系统2数据库名,系统2表名,导入XML文件名,导出时间,导入时间,字典表名称,导出数据存放位置,导入数据存放位置 外,增加 导出文件类型,导入文件类型 ,用于记载原系统导出文件格式与原另一系统的导入文件格式。

导出数据格式变换程序程序流程图如图2-5所示:

导入数据格式变换程序程序流程图如图2-6所示。

3) 如果两系统没有数据的导入、导出模块,或导入、导出的文件格式无法按上述协议完成变换,需要设计导入、导出程序,如图2-7所示。

 

2- 6 导入数据格式变换程序流程图

 

2-5 导出数据格式变换程序流程图


 

其中两对导入、导出程序分别挂到原来二个系统中,独立操作。

其中导出程序需要有读数据库的权限,直接从数据库中按字典表读取数据,并变换成规范XML文件放到指定位置。导入程序要求有写数据库的权限,需要按XML数据导入的方式(添加_修改、添加、修改、删除)对数据库操作。XML文件生成后,数据通过双方接口协调密钥加密,再用BASE64编码,使用标准的RSA的加密算法加密。

在整合时可以添加新的功能。

 

2-7 添加导入导出程序接口的整合


 

3 章 服务模型分析设计

3.1 服务描述与发现

针对凤凰公司的情况,系统整合内容分为二快,如图3-1所示。一块实现数据变换并互传,另一块在数据集成基础上进一步扩展,寻求整体优化,追求系统整合的最大效益,二个不同系统间的无缝链接使资源更合理使用,减少冗余,同时增加一些为销售所需要的功能,使应用更方便,决策支持功能更强大。

3.1.1 CRM ERP双方数据互传

我们设计的SOA是多个系统整合的平台,此处只是基于SOA实现二个系统(一个ERP系统和一个CRM系统)的整合。凤凰公司在公司内部成功实施了某ERP系统,主要用于凤凰公司的财务管理,其中包括产品库存及订单管理等。随着业务需求, 凤凰公司采用客户关系管理系统(CRM)来进一步提高销售人员的工作效率,销售人员可以使用和管理客户及销售信息,包括客户信息,商机,业务机

 

3-1 扩展SOA平台实现系统整体优化


 

会,以及客户及销售信息分析图表等,这两个系统的数据结构许多地方不相容。对凤凰公司二个系统数据的分析如下:

CRM 方面有数据表:部门、业务员、客户、联系人、产品分类、产品、销售订单、销售订单子表、报价单、采购订单、采购订单子表、销售计划、销售机会、盘点单、反馈信息、收付款。

这些数据的结构与来源、去向如下:

1 )部门(nameRowset typearrayItem typestruct

结构包括以下内容:(部门编码,部门名称,特点,描述,电话,电子邮件,部门地址)。

该数据从ERP 部门档案 表传往CRMERP 部门档案 表结构包括以下内容 :(部门编码,部门名称,上级部门, 部门属性, 负责人, 电话, 地址, 自定义项1, 自定义项2, 自定义项3, 自定义项4,自定义项5, 备注,库存组织,组织类型属性,部门职责属性,部门是否撤消,部门撤消时间,部门成立时间,外系统来源标示)。

经比较不难发现,从ERP传往CRMXML文件中, 上级部门, 部门属性, 负责人,自定义项1, 自定义项2, 自定义项3, 自定义项4,自定义项5, 备注,库存组织,组织类型属性,部门职责属性,部门是否撤消,部门撤消时间,部门成立时间,外系统来源标示 等是CRM中部门表中所没有的,在准备导入的XML文件中要去掉这些项。同时,在CRM中, 特点,描述,电子邮件 等数据是ERP方面的XML文件中所没有的,应当在供导入的XML文件中相应位置加上三个空格数据的有关语句。

按照我们前面说明的处理方法,关于部门的字典表填写如下。

ERP dept  deptcode CRM dept  code 部门编码 > NOT

ERP dept  deptname CRM dept  name 部门名称 >

ERP dept  pk_fathedept CRM 上级部门

ERP dept  deptattr CRM 部门属性

ERP dept  pk_psndoc CRM 负责人

ERP CRM dept fax   传真

ERP CRM dept intro   描述

ERP dept  phone CRM dept  phone 电话

ERP CRM dept email   电子邮件


 

ERP dept  addr CRM dept  address 部门地址

ERP dept  def1 CRM 自定义项1

ERP dept  def2 CRM 自定义项2

ERP dept  def3 CRM 自定义项3

ERP dept  def4 CRM 自定义项4

ERP dept  def5 CRM 自定义项5

ERP dept  memo CRM 备注,

ERP dept  pk_calbody CRM 库存组织

ERP dept  orgtype CRM 组织类型属性

ERP dept  deptduty CRM 部门职责属性

ERP dept  canceled CRM 部门是否撤消

ERP dept  canceldate CRM 部门撤消时间

ERP dept  createdate CRM 部门成立时间

ERP dept  xtersysflag CRM 外系统来源标示

(说明:以上仅填写了 系统1名称,系统1表名,表1字段名,系统2名称,系统2表名,表2字段名,意义,……,约束条件表达式,是否允许重复值,…… 等栏目内容)。

注意,虽然XML是标记式语言,每个数据都标有名字,但从处理方便及避免错误考虑,导出字段名的顺序还是要尽可能和准备导入的表保持一致。

本例中只标志了 约束条件表达式,是否允许重复值 两个约束条件,对于其他表还要考虑其他约束条件的内容。

上述数据是为从一个系统将数据导入到另一个系统准备的,至于将 部门 数据导出存放到一个XML文件中供扩展系统使用的工作,应当由原系统自身功能完成,不在此讨论。

以下数据的结构与来源、去向详细内容请看交付件附件1:数据字典.doc(因篇幅关系,本文略)。

2 ) 业务员 :结构包括以下内容:(名称,编码,助记码,性别,出生日期,出生年,出生月,出生日,出生地,家庭电话,移动电话,部门名称,部门电话,办公电话,学历,寻呼,地址,备注)


 

该数据从ERP 部门档案 表传往CRMERP 部门档案 表结构包括以下内容:(公司主键,人员类别,人员编码, 姓名,部门主键,业务员标志,业务员编号,人员岗位,已转入档案标识,归属范围,助记码,身份证号,社会保障号,考勤卡号,性别,出生日期,民族,血型,婚姻状况,健康状况,到职时间,参加工作时间,离职时间,邮政编码,家庭住址,电子邮件,可办公电话,手机,BP,家庭电话)

3 ) 客户:涉及客户、合作伙伴与供应商管理。其结构包括以下内容:(客户编码,客户名称,客户分类名称,备注,客户订单数量,传真,国家,省,信用额度,电话,地址,电子邮件,邮政编码,城市,简码,合作单位,负责员工)

该表数据存在双向传送的需求:

该数据的原始数据除 信用额度 外从CRM 客户 传往ERP 客商档案 表,后者结构包括以下内容:(客商基本档案主键,公司,地区分类,公司编码,客商编号,客商名称,客商简称,外文名称,助记码,是否散户,是否DRP结点,是否渠道成员,客商总公司编码,客商类型,纳税人登记号,法人,信用额度,经济类型,营业地址,通信地址,邮政编码,电话1,电话2,电话3,传真1,传真2,联系人1,联系人2,联系人3,手机1,手机2,手机3,E-mail地址,Web网址)

ERP方面经核对修改后,加上 信用额度 的内容,再从ERP 客商档案 表发往CRM 客户 表,根据关键字 客户编码 客户 表进行修改。

4 ) 联系人:其结构包括以下内容:(名称,性别,职务,称呼(职务称呼),办公电话,省份,ICQ,备注,婚否,地址,传真,出生日期,家庭电话,邮编,传呼机,政治生活,城市,国家,电子邮件,所属客户名称,主联系人标志(1/0))

本表数据为CRM系统自用数据,目前尚不需要和ERP方面交互。

5 )产品分类编码(产品分类名称,产品分类编码),为产品管理中使用的代码表。

其数据从ERP 存货分类 表发往CRM 产品分类编码 表。

ERP 存货分类 表结构包括以下内容:(存货分类主键,存货分类编码,存货分类名称,公司主键,编码级次,末级标志,平均单价,平均成本,平均生产提前期,平均采购提前期)

6 )产品:结构包括以下内容:(成本价,产品描述,产品定价,产品名称,产品编码,简码,产品介绍,序列号标志(0:不作序列号管理,1:作序列号管理),批号管理(0:不批号管理,1:批号管理),可采购管理(0:不采购,1:采购),产品


 

分类名称,计量单位,产品分类编码,销售标志(0:不可销售,1:可销售),采购价格 ,单位成本,采购此刻价,组合产品消费周期,产品对应规格,子产品价格变动,等级产品,产品对应供应商,产品比较表,相关知识附件,产品销售机会)

其数据从ERP发往CRM 产品 表。ERP中产品管理有三个主要数据表:

存货基本档案,结构包括以下内容:(存货基本档案主键,存货分类主键,公司名称,存货编码,存货名称,外文名称,规格,型号,存货简称,条形码,助记码,税目税率,主计量单位名称,销售默认单位,采购默认单位,库存默认单位,生产默认单位,长度,高度,宽度,是否折扣,是否成套件,是否劳务,多少标准存储单位,多少标准运输单位,多少标准重量单位,备注,图号,品牌,单位重量,单位体积,是否辅计量管理)。

存货管理档案,结构包括以下内容:(存货管理档案主键,公司名称,存货基本档案主键,是否受托代销,计划价,参考成本,参考售价,ABC分类,存货主供应商,是否根据消耗结算,是否保质期管理,保质期天数,采购损耗率,保管损耗率,是否进行序列号管理,是否批次管理,封存标志,备注,是否辅币核算成本,最高限价,出库优先级,是否出库跟踪入库,是否允许负库存,是否可配置,是否特征项,默认库存组织,是否可采购,是否可销售,是否需求管理,是否虚项,是否允许无合同采购,采购策略,配额开始,配额结束,存货是否可退换,销售退货是否免检,销售退货是否根据检验结果入库,是否主条码管理,是否次条码管理)

存货生产档案,结构包括以下内容:(存货生产档案主键,公司名称,库存组织主键,存货基本档案主键,存货管理档案主键,废品系数,舍入值,最小乘数,是否关键件,倒冲标志,物料计划员,分管生产业务员,分管生产部门,物料类型,毛重量,净重量,计划属性,是否需求合并,生产方式,坯料制件数,坯料宽度,坯料长度,最小批量,批量增量,批量数量,批量规则,定额重量,委外类型,是否虚项,固定提前期,提前期系数,提前期批量,前段提前期,累计提前期,后段提前期,确认时界,需求时界,低层码,安全库存,供应类型,记价方式,最高库存,最低库存,最大周转天数,主仓库,是否生产线生产,是否最终产品,ABC分类,计划价,参考成本,参考售价,生产批量,再定货点,采购组织,主供应商,副供应商,预备供应商,供方物料编码,是否部件,是否


 

成本对象,ABC分类销售额角度,ABC分类毛利角度,ABC分类采购额角度,ABC分类库存资金占用角度,存货可用量计算方案字符串,存货可用量,现存量,工艺路线类型,转库批量,内部转移价,是否辅助服务,是否免检,是否必须依据检验结果入库,是否批次核算,可用量是否按自由项计算,是否可出入库,是否BOM父项,是否可计算存货成本,BOM类型,是否生成子生产订单,BOM类型,是否成套发料,发料基准量,是否发料,是否按基准量发料,物料分类,批量周期,是否受固定周期约束,固定周期起始日,物料形态)

经比较,CRM 产品 表的数据主要来自 存货基本档案 存货管理档案 两个表。要注意的是,有些数据需要进行组合或变换,例如, 产品描述 可能包括(公司名称,外文名称,规格,型号,存货简称)等内容。 产品介绍 可能包括(税目税率,主计量单位名称,销售默认单位,采购默认单位,库存默认单位,生产默认单位,长度,高度,宽度,是否折扣,是否成套件)等内容。我们可以在字典表的 产品描述 字段的 计算公式 栏中填入: 公司名称 + 公司名称+ 外文名称 + 外文名称+ 规格型号 + 规格+型号+ 存货简称 + 存货简称。在字典表的 产品介绍 字段的 计算公式 栏中填入: 税目税率 + 税目税率+ 主计量单位名称 + 主计量单位名称+ 长度,高度,宽度 + 长度+高度+宽度, 是否折扣 + 是否折扣+ 是否成套件 + 是否成套件。

7 )销售订单,结构包括以下内容:(付款日期,备注,交付日期,审核标志(0:不要审核,1:可审核),收款金额,退货单标志(0:销售,1:退货),订单日期,摘要,收款客户(custom/伙伴(bp),发货客户/伙伴,订单编号,部门编号,员工部门,部门名称,外币金额(外币币种),业务员编码,业务员名称,总金额(按订单子表含税金额累加),汇率,客户编码,客户名称,伙伴编码,伙伴

 

3-2 销售订单管理和其它模块间关系


 

名称,订单状态(0:为审核,1:已审核),订单关闭日期(非空:历史订单,空:活动订单))

订单子表(可重复) ,结构包括以下内容:(成本单价,摘要,外币金额,汇率产品金额,产品名称,产品编码,产品定价,折扣,产品价格,币种JD,税率,产品数量,产品单位,含税金额,协议终止时间,初收时间)

在用友ERPNC系统供应链管理操作手册中提到销售订单、采购订单、委外订单,它们和合同管理直接相关,如图3-2所示。

合同管理又和销售管理直接相关,如图3-3所示。

ERP中销售订单数据表的结构包括以下内容:(单据号,日期,客户,散户,部门,业务员,销售组织,库存组织,业务类型,收货单位,收货地址,开票单位,收款协议,整单折扣,整单税率,币种,折本汇率,发运方式,是否发运,予估运费,仓库,备注,予收款比例,予收款金额,收现款金额,制单人,制单日期,审批人,审批日期,ATP,现存量,打印次数)

销售订单子表数据表的结构包括以下内容:(行号,编码,名称,规格型号,产品线,合同号,合同存货类,辅单位,辅数量,单位,报价计量单位,报价计量单位数量,报价计量单位无税单价,报价计量单位含税单价,主计量单位,主计量单位数量,主计量单位无税单价,主计量单位含税单价,主计量单位无税净价,主计量单位含税净价,税率,金额,税款,价税合计,折扣额,发货日期,交货日期,配置单编号,仓库,批次,项目,项目阶段,自由项,缺货/补货,赠品,收货单位,收货地址,收货地区,收货地点,发货公司,发货库存组织,发货仓库)

8 )采购订单:

 

3-3 销售管理与其他模块间关系


 

采购订单和其它模块间关系如图3-4所示。

采购订单表结构包括以下内容:(订单编码,订单日期,供应商名称,部门编码,部门名称,外币金额,业务员名称,业务员编码,汇率,合计金额,付款日期,交付日期,利润,审核标志,备注)

采购订单子表结构包括以下内容:(产品编码,产品名称,计量单位,成交价,产品数量,产品金额,备注,成交价,汇率,折扣率,外币金额,产品定价,付款金额,汇率,币种ID

如果是完全的以销定购,不考虑已有的库存,或在采购时需要对库存可用量

 

3-4 采购订单与其它模块间关系


 

进行平衡,平衡后的结果产生请购单,都会实现销售订单转请购单再生成采购订单的操作。这时采购订单数据由ERP方面生成,可以发CRM方供查询。另外,也可能是手工录入,可以是在ERP方,也可以是在CRM方录入,这时采购订单数据由CRM方面生成,发ERP方存储。

ERP 方面采购订单结构包括以下内容:(采购订单(采购订单号,订单日期,版本号,是否补货,是否退货,是否发运,修订日期,供应商,供应商全称,采购组织,部门,业务员,库存组织,仓库,收货方,发票方,付款协议,币种,汇率,本币预付款限额,本币预付款,备注,行号,合同号,是否赠品)。采购订单子表结构包括以下内容:(存货编号,存货名称,规格,型号,产地,自由项,批次号,单位,最高限价,主计量单位,数量,换算率,扣率,净单价,含税单价,金额,税率,扣税类别,税额,价格合计,计划到货日期,项目,使用部门,仓库,收发货地区,收发货地址,供应商收发货地址,供应商收发货地区,供应商收发货地点,来源单据类型,来源单据号,来源单据行号,源头单据类型,源头单据号,源头单据行号)。

9 )销售计划,结构包括以下内容:(计划号,计划日期,部门编码,部门名称,业务员编码,业务员名称,产品编码,产品名称,产品分类编码,产品分类名称,计划数量,计划金额,计划利润,计划收款)

ERP文档中未见与本表有关的描述,姑且认为该表为CRM自身用表。

10 )销售机会,结构包括以下内容:(客户/伙伴关系,客户编码,客户名称,部门编码,部门名称,业务员编码,业务员名称,主管,简介,日期,年、月、日,销售日期,来源类型)

CRM发往ERP的销售机会,结构包括(业务类型,单据号,单据来源,单据状态,订货日期,失效日期,销售组织,库存组织,客户,收货单位,开票单位,收货地址,部门,业务员,收款协议,是否发运,发运方式,整单折扣,币种,折本汇率,折辅汇率,编码,单位,规格型号,报价计量单位,报价计量单位无税单价、报价计量单位含税单价,主计量单位无税单价、主计量单位含税单价,单品折扣,报价计量单位无税净价、报价计量单位含税净价,主计量单位无税净价、主计量单位含税净价,税率,金额,税额,价税合计,折扣额,仓库,批次,项目,项目阶段,自由项,备注,报价计量单位数量,主计量单位数量,辅单位数量,收货单位,收货地址,收货


 

地区/地点,发货公司,发货库存组织,发货仓库)

11 )盘点单,结构包括以下内容:(盘点单号,盘点日期,盘点年,盘点月,盘点日,仓库编码,仓库名称,创单人编码,创单人名称,审核编码,审核人名称,摘要)

盘点单子表,结构包括以下内容:(户品编号,产品助记码,户品名称,户品属性,规格,型号,账面数量,盘点数量,摘要)

数据来自ERP的库存的①仓库(存货编码,存货名称,规格,型号,主计量单位,最后存量,订货类,最低库存,经济批* 再定购买盘点周期,最大周转天数,是否参与erp技术,上次周期盘点时间)

②期初库存(单据号,单据日期,收发类别,仓库,库管理员,供应商,部门,生产员)

子表(存货编码,辅数- ,单价,全款,计划单价,计划金额,入库日期,项目)

③入库(单据号,单据日期,业务类型,库存组织,收发类别,仓库,库管员,供应商,部门,业务,是否退库)

子表(存货编码,辅计量单位,自由项,批次,失效日期,货位,数量,辅数量,单价,金额,计划单价,计划金额,入库日期,项目,订单号,来源单据类型,单据号)

④产品入库(单据号,单据日期,收发类别,仓库,库存组织,库管员,客户,部门,业务员)

(存货编码,辅计量,自由想,批次,失效日期,货位,数量,辅数量,单价,金额,计划单价,计划金额,入库日期,订单号)

⑤委托加工收货,其他入库,借入,来料加工入库,生产安度入库,调拨入库,-入库,等部分数据不发给crm参考。

等表

12 )反馈信息,结构包括以下内容:(反馈单日期,反馈单天,反馈单月,反馈单日,反馈单类型,修改业务员名称,修改日期,状态,部门名称,摘要,客户名称,电话,完成时间,xxxxxxx,反馈。。。业务员名称,联系人名称)

13 )收付款,结构包括以下内容:(客户/伙伴,客户名称,资金类型,收款


 

方式,订单编码,收款年,收款月,收款日,收款金额,业务员名称,业务员编码,币种ID,收款类型)

来自ERP的销售结算表(业务类型,单据类型,客户,单据号,单据日期,订单号,存货名称,规格型号,应发量,开票量,已结算量,本次结算量)

相关数据: 收款金额,结算金额 来源于销售订单行;

3.1.2 已经在一方系统中有的数据,可以传到另一方使用。

例如,ERP系统中关于渠道、发运、采购的结果与分析、存货生产档案、合同流转情况、收付存报表、返利、价保、质量情况、员工绩效分析……等数据都已生成,这些数据对于CRM方谈判交易或加强管理都很有意义。但在原来系统中这些数据未传到CRM中,业务人员也无法直接看到这些数据。需要扩展前面所述的SOA平台,使得双方资源得到进一步共享。

该扩展系统可以采取B/S模式,也可以采取C/S模式,甚至单机方式。采取B/S模式的优点是跨平台性好、无需专用通信通道、在客户方无须进行程序配置,但缺点是:一般需求主要是在CRM方需要尽可能多地获得ERP方面的数据,往往只需要在CRM系统的少数机器上开展查询操作,这样采取B/S模式投入反而变大;一般通过因特网的处理功能比较弱,程序自适应性目前还比较弱,如果要考虑下面进一步扩展的需要,开发工程比较大,且有些功能难以实现;B/S模式的安全性较差。采取C/S模式或单机方式的缺点是环境适应性差、在客户端也得安装程序组件并做环境配置,但B/S模式的缺点恰恰是它们的优点。

本次设计我们采取C/B/S模式方案,对于原有数据库中数据的操作,设计在原来二系统机器中利用我们已经开发成功的基于JAVA的通用部件实现扩展;对于为大家需要的生成数据,通过网络发布。如图8所示,在CRM系统所在机内建一个扩展系统,从原来二个系统导出的标准XML文件中取出数据,放到该扩展系统的数据库中,配置查询程序供业务员使用,CRM方业务员就能利用ERP系统功能加强自己的管理工作。同样,如果需要,也可以在ERP系统方添加扩展模块,就能看到原来CRM中有但ERP方看不到的数据,例如销售计划、联系人情况等。

该方案中 基于JAVA的通用部件 2005年研制成功,并由湖北省教育厅组织了鉴定。其原理,我们已通过中国水利水电出版社出版的 Visual FoxPro 应用基础及基于部件系统设计技术 一书的随书光盘发表, 部件库最小系统


 

20044月在网上公开发表,7月,改进的部件库最小系统将随清华大学出版社出版的 Visual FoxPro 程序设计 一书出版。这些公开发行的内容虽然只是基于VFP,但其思想、界面、功能、操作和基于JAVA的部件都大致相同,我们将只在下面对本设计中需要用到的部件做简单介绍。 管理信息系统通用部件 项目负责人为程学先教授,我组程传慧是该项目课题组成员。另外,我们已研制成功企业情报系统的基本程序,本次竞赛需要特别设计的只是 其它功能 的扩展组件的具体设计,将能迅速提交设计文件。

②如果将系统能收集但原来没有收集的数据收集回来,就更能发挥整体的作用,有利于整体效益的提高。例如,客户还可以带来大量的市场信息,对于上级领导的决策是有意义的,应当能加已收集并传到ERP方计算机中。又例如,目前CRM方对产品管理只到整件一级,没有到部件或零件一级,但如果能细化,必然有利于企业效益的提高,有利于销售业务的发展(请看以下图3-4)。因此在整合时可以考虑在这些方面加强。

③扩展更多的功能实现整体进一步优化。例如,添加企业情报系统,主动收集市场、对手、伙伴等新产品、价格、市场行情……等数据供企业最高领导层决策使用。

实现以上功能的服务流程如16页图3-1所示。

3.2 服务规约

1)配置

扩展系统操作系统选用Widows2000网络版,开发平台:J2EE,开发工具:Jbuilder,数据库:SQL SERVER

2)模块结构。SOA扩展系统模块高层结构如图3-5所示。

其中,单记录式维护子系统下可以挂多个数据维护模块,分别对应多个不同

 

3- 5 SOA 扩展系统模块高层结构图


 

的表及这些表的不同视图,这些模块实际都调用同一个部件程序:单记录数据维护部件,只是调用所使用的参数不同。

同样,表格式维护子系统、查询子系统下也各可以挂多个数据维护模块,分别对应多个不同的表,它们同样都调用通用部件开展工作,这些部件是:表格式自适应数据维护部件、单查询部件、组合查询部件。

这些部件各自采用独立的变量或临时表体系,因此可以保证在同时为多种用途所调用时彼此不产生冲突。也使得实现同样功能时,不需要在系统中进行重复设计,可以使得文件数减少,有利于管理与维护。

3)调用接口参数表

使用部件需要建立 调用接口参数表 ,其结构为:(部件名称,菜单项名称,数据库名称,数据表名称,关键字,选用字段号表,选用按钮号表,选用列表框字段号表,上二级表名称,上一级表名称,联系字段1,联系字段2,字典表名称,菜单列号,接口参数表名称)

每一行数据对应一次调用,实际相当于一般系统的一个模块。

各接口参数的意义:

菜单项名称 :系统根据 调用接口参数表 生成控制菜单的下一级菜单,每个 菜单项名称 对应一个菜单项, 菜单项名称 中填入内容是该菜单项的标签。

②每行 部件名称 中具体填入本行菜单项被选中时所欲调用与执行的部件的名称。本设计中将使用如下6个部件:单记录数据维护部件,分层多表数据维护部件,表格式数据维护部件,单条件查询部件,组合查询部件,XML文件导入部件。

③部件的每次调用都要具体实施对数据库中某个表的操作(添加数据、修改数据、查询数据……等, 数据库名称,数据表名称 中填该次调用时欲操作的数据库的名字与表的名字。

④当修改数据或执行删除操作时需要根据 关键字 来查找数据。 关键字 一栏用于填所操作的表的关键字,如果由多个字段组成,彼此间要用逗号分隔。

⑤部件每次调用时可以根据所选择的字段自动排版建立界面,