再讲EDI之三

昨天说到Oracle脑子有没有瓦特。

答案嘛当然是么瓦特！！觉得瓦特的小伙伴赶快放下手上的工作去医院哦亲，身体可是上线的本钱哦亲。

为什么这么说呢？

假设，我们已经收到了EDI中间商传输过来的鬼一样的报文，下一步就是读。首先每个客户可能用的都是不同的EDI标准，发送的文件类型也不止一种。如果人肉解析的话....

其次，既然是数据交换，那就不只是接收数据，还要发送数据，比如当我们对客户的订单进行了发运之后，通常客户都需要我们返回ASN（Advanced Shipment Notice），表示我们发出了货物，

因此我们还需要对不同的客户生成不同格式的报文。

第三，客户发送的数据可能发生变更，比如某C汽车公司，今天做计划的时候说12/18号要480个A，明天说12/18只要360个A，后天说还是要480个，结果到了12/18号发货前两小时，说只需要240个。因此对于我们来说，存在着新数据替换旧数据的逻辑。

好吧，听起来似乎是必须要用ECE和RLM了。那这两个模块就能直接对原始报文进行翻译和进一步的分析处理么？

嘿嘿，不能。

这两个模块使用的前提就是需要一个EDI Translator把标准格式的报文转换成Oracle可以识别的Flat File，大概长这样：

下面这张图是ASC X12与EDIFACT两种报文标准对不同文件的命名：

F公司和客户之间进行了这些文件的对接：

Purchase Order, Planning Schedule和Shipping Schedule都是由F公司的客户发送的，可以简单粗暴的理解成：

来自客户的850/ORDERS：进入到Oracle之后就是我们的销售订单

来自客户的830/DELFOR：进入到Oracle之后就是我们的预测（FOR就是forecast的意思）

来自客户的862/DELJIT：进入到Oracle之后对应Sales Agreement Release(JIT就是Just in Time的意思)

Ship Notice则是F公司在发运后返回给客户的文件，返回我们的实际发运信息。

I公司收到这些原始报文之后，会将客户的报文解析为Flat File后发送给我们，反过来，也会接收Oracle发送的Flat File并生成报文传递给客户。而ERP和I公司间文件的传输则是通过SFTP来完成的。

即，I公司负责把翻译后的文件放到服务器上，Oracle端开发请求抓取服务器上的文件，并且把这些文件存放在Oracle的服务器上。反向流程大家可以自行脑补。

对于收到的文件，Oracle是怎么处理的呢？ECE和RLM到底扮演了什么角色呢？

我们下期再说咯，白白~