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

第一篇里我们简单的介绍了，接收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的转换，就是一个数据转换的问题，即我们的系统中可能使自己定义的一批代码规则，与海关或其他的都不一样

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

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

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

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

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

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