CSDN博客

img olony

浅述EDI--验证导入(2)

发表于2004/9/17 13:16:00  1210人阅读

分类: EDI

第一篇里我们简单的介绍了,接收EDI报文的通用方法,那么怎么才能知道接收的数据的正确性,和可用性哪?这就需要我们来仔细的验证数据的有效性,并导入我们自己的系统中了。

上一篇我们讲到,要把数据接收到一些“数据库表”中,那么这些表,应该怎么设计哪?是不是就是系统中正在使用的表哪?

据我的实践总结出:应该建立一些中间表存储这些数据。这主要是因为

1.你不知道要接收的数据的长度

2.中间表与系统无关,不影响现有系统的运行

3.便于扩展

最简单的设计是:

CREATE TABLE(

COL1???? VARCHAR2(255),

COL1???? VARCHAR2(255),

COL1???? VARCHAR2(255),

COL1???? VARCHAR2(255),

COL1???? VARCHAR2(255),

......

)

这可能会浪费空间,但是,我们不得不承认,这的确是什么数据都可以接进来的表。一种灵活的设计是,我可以动态的增加删除,修改这些中间表的结构。但是,我们最好是把字段的类型都设置为字符类型,因为这样,我们接收的时候几乎是可以接收所有数据的,这也是为了便于扩展

但是我们知道,每个计算机系统的设计都是不一样的,尤其是数据库中,表的结构也是千差万别,每个字段的定义及其类型也是千变万化。那么如何将中间表的数据正确的导入现有系统中哪?这就需要验证和导入的设计了。

根据上图可知一种简单的设计是,根据给远洋提运单设计一个中间表,给陆路清单设计一个中间表,然后设计两个验证过程,分别对提运单表和清单表进行数据有效性验证,倒入系统。如果来了新的(例如:交通部提运单标准),我们只要在[浅述EDI--验证模型(1)]中增加这个定义导入中间表便可以了,不用重新编写程序。因为验证导入过程是针对中间表的验证导入,而接收是可以定义写入那个中间表的那个字段的,也就是针对中间表的接收,两者没有必然的联系。

但是,我们可以看出,尽管前台的工作是自由的,但是验证和导入,因为是写死的,仍然限制了其,扩展的可能性!

当,来了一种新的报文,远洋联合国船图标准哪?我们可以定义一个中间表接收,但是针对这个中间表的验证,和导入我们仍然需要修改程序,当然,如果只是把这个验证和导入的过程放在后台,工作量将小很多,但是,只要有修改增加,那也是限制了它的功能。

你也许会说,可以定义一批规则,根绝这些规则,验证中间表的每个字段!

是的,完全可以这样做。

可是这儿有一个问题仍然限制了这种扩展,就是数据转换的问题。

比如:原始报文

LA123'1'123'

LA123'2'100'

我们知道了,这个报文中LA123代表车号,1(2)代表序号,123(100)代表海关货物代码

那么我们可以接收到中间表T_TEMP中???

车号?????序号 货物代码

LA123? 1??????? 123

LA123? 2??????? 100

系统中

车号????序号 货物代码 货物名称

LA123 1???????? AA??????????? 煤炭

LA123 2???????? BB???????????? 铁矿砂

那么从123到AA,从100到BB的转换,就是一个数据转换的问题,即我们的系统中可能使自己定义的一批代码规则,与海关或其他的都不一样

而验证,就是要验证,是不是能够与我们的代码对应上

你又说了,可以做一个转换表,来处理这种情况,是的,这样做很好。可是仍然无法处理这种新的报文,远洋联合国船图标准哪?因为我不能预见所有的可能会导入报文,那些代码需要转换?如果定义规则,给他一个转换标志,但是用户又不知道,它对应我们系统中的那个表的代码(况且用户是非计算机专业的)。

而以上所叙述的,是我不做到通用的验证导入的原因

但是,我们应该朝着通用前进。

做了一个接口,前台的界面是一样的,只是验证导入不一样了,有什么不一样哪?我可以轻松的挂接一个后台的验证导入过程。只要判断一下,用户要验证那个报文,然后取得验证的中间表,。。。(一个单独的验证都过程)。

如果又来了一个联合国的进口清单,我只要在这个接口里再添加一针对进口清单中间表的验证导入过程,而无需修改前台。

0 0

相关博文

我的热门文章

img
取 消
img