数据交换平台顾名思义是一个为不系统间提供数据交流、转换功能从而达到数据资料共享的软件产品。其处理
的主要对象就是各类业务数据,其使用者为各类参与交换的系统或数据源。
市面上的数据交换产品其功能很丰富,也很全,但就其核心功能而言不外乎是针对数据的四个加工过程:获取、
转换、传输及最后加载数据。
- o数据获取。数据交换的第一步,要进行数据的交换,首先要获取被交换的数据,否则交换就无从谈起。
- 应用场景
- 业务系统向数据交换平台提供数据,这个是建立在业务系统可以为交换平台提供集成服务的前提下。
- 由交换平台直接从业务系统的数据源中获取数据,在业务系统无法为交换平台提供数据服务的情况下只能采取这种办法。
- 业务系统可以按交换平台的标准提供数据。
- 业务系统只按自身标准提供数据。
- 解决方案
- 在数据获取方面,完全放开,由用户自定义数据应用适器实现。项目也提供了一些现成的数据获取方式:如SQL适配器、任务调度器等。
- 其原则是只要数据可以解析成XML就可以被支持。项目提供一个可扩展的数据解析框架,以支持将各类数据解析成XML,现支持的数据类型有:SQL(关系数据库)、EXCEL、CSV、LDAP及XML等。
- 应用场景
- o数据转换。参与数据交换双方在数据结构的定义及其所代表的业务意义是会有差异的,必要时须进行数据转换,也即是将一方所提供的数据转换成另一方所能识别的数据。
- 应用场景
- 数据结构差异转换。例如有两个单位的OA系统A和B,各自都对公文进行了数据结构的定义,对于公文中文件标题这个属性在A中表示为title,在B中表示为biaoti,这们两者间就在公文的数据结构定义中存在差异了,交换平台必须提供这种数据结构的转换。
- 业务意义上的转换 。如A公文中对密级的业务值以“0”表示机密,“1”代表秘密,而在B公文中密级中的机密是以“JM”来表示,秘密是以“MM”来表示,这样交换平台必须提供这种业务级换算转换,例如前面提到的将“0”转换成“JM”,将“1”转换成“MM”。
- 数据类型转换。支持异数据类型转换,如将XML转换成EXCEL或反之。
- 数据结构差异转换。例如有两个单位的OA系统A和B,各自都对公文进行了数据结构的定义,对于公文中文件标题这个属性在A中表示为title,在B中表示为biaoti,这们两者间就在公文的数据结构定义中存在差异了,交换平台必须提供这种数据结构的转换。
- 解决方案
- 支持数据结构差异转换。项目统一将各类数据转换成XML,通过XSLT引擎进行转换,支持任意数据结构。
- 通过业务转换插件框架支持业务义意转换。
- 数据类型支持上,只要能解析成XML的数据都可以被支持。
- 应用场景
- o数据加载。这是数据交换工作过程的最后一个环节,对于数据的需求方是需要加载利用这些被交换的数据的,可能会将其保存在自己的数据源中,也有可能只是在自己的业务运算中使用。
- 应用场景
- 业务统提供服务或协议加载数据。
- 交换平台直接操作业务系统数据源加载数据。
- 业务系统可以加载交换平台标准的数据。
- 业务系统只能加载自己标准的数据。
- 解决方案
- 加载数据上与数据的获取一样完全放开,通过实际应用中开发业务适配器加载。
- 在数据标准的支持上,只要数据能解析成XML就可以被支持。
- 加载数据上与数据的获取一样完全放开,通过实际应用中开发业务适配器加载。
- 应用场景
- o数据传输。由于数据交换平台的布署运行有可能是分布式,也即是数据获取、转换、加载可能分别在不同的机器上,数据需要在这些机器间进行传输,另外平台为外部系统也要为外部系统提供数据传输的服务,如接收被交换数据及发送被加载的数据等。这就要求平台必具备支持常用网络协议(TCP/IP、HTTP、HTTPS、FTP、EMAIL等)的数据传输功能,这不仅是平台内部的需要(分布式布署)也是外部系统集成的需要(接收或发送外部数据)。
- o数据安全。数据交换的实现在底层网络实现上需要利用现有的Internet网络设施,数据将会在公开的网络上传输,这就涉及到一个数据的安全性的问题了。平台必须确保数据的保密性,真实性、来源合法性。