在知行之桥中接收或发送的数据通常是EDI原始报文，知行之桥会对EDI原始报文进行格式转换，以方便用户后端系统的处理。因此，一般情况下，用户看到的都是转换后的数据结构，例如Json、XML或Excel等，无需直接查看原始EDI报文。但在以下特殊的业务场景下，用户需要查找到指定的原始报文：

1.对于接收方向的报文来说，例如订单，用户在查看转换后的数据结构后，对数据值存在疑问，需要向发送方求证，看是否存在数据值错误的情况，此时会需要提供EDI原始报文和订单编号，给发送方确认

2.对于发送方向的报文来说，例如发货通知，若是接收方验证报文失败，一般会通过EDI报文或以邮件等方式通知发送方，告知其发货通知单号和错误信息，此时发送方需内部排查，看是数据值错误还是EDI报文错误，若是EDI报文错误，为了确定具体错误信息，此时会提供原始的EDI报文，给接收方检查确认。

后端系统业务人员或交易伙伴提供的用于排查问题的信息，一般都是业务单号，如果传输的是订单，那提供的就是订单号；如果传输的是发货通知单，那就是发货通知单号；如果传输的是发票，那提供的就是发票号。那么，如何通过这些业务单据编号，在知行之桥EDI系统中准确查找到原始EDI报文呢？

在转换过程中对文件进行重命名

在收到交易伙伴或后端业务系统推送过来的数据时，文件名是多种多样的，此时需要对文件进行重命名处理，将业务单号放在文件名上，以便于后期运维查询。

在知行之桥中，文件重命名操作一般会在XML Map端口实现。

1.接收方向

以订单为例，在接收订单时，知行之桥中将会搭建如下工作流，我们在Markant_Map_ORDERS端口对文件名进行修改：

点击端口，在设置-目标文件中，新增代码脚本：

对代码脚本命名为Rename，并填入内容：

其中，[xpath(BGM/C106/1004) | def | trim]是获取订单编号，[ | snowflake]则是生成随机数，以确保文件名不会重复。

保存后进行测试，在 输出 中即可看到，订单号已被添加到文件名中：

2.发送方向

以发货通知单为例，在发送发货通知单时，知行之桥上的工作流如下，我们在Markant_Map_DESADV端口对文件名进行修改：

在端口中新增代码脚本，并填入内容：

其中，[xpath(ASNNumber) | def | trim]是获取发货通知单号，[_ | snowflake]则是生成随机数，以确保文件名不会重复。

保存后测试，即可在输出中看到，发货通知单号已经被添加到文件名中：

根据文件名查找原始报文

在实施过程中完成第一步对文件进行重命名后，在后续文件传输的过程中，所有业务单号将被写入到文件名上。此时，我们就可以根据使用业务单号在知行之桥上查找文件，具体操作如下：

进入日志页面，在搜索框中输入要查询的业务单号，进行搜索，然后找到对应的那行消息，点击查看详情：

待跳转到详情页面，找到MFT端口，即EDI报文的传输端口，例如AS2/OFTP等，在MFT端口，即可看到对应的原始EDI报文：

点击文件名称，即可下载原始EDI报文：

如果您希望了解有关EDI对接的相关信息，欢迎联系我们。

注：文案部分图片及内容来源于网络，版权归原创作者所有，如有侵犯到您的权益，请您联系我们进行删除，给您带来困扰，我们深感抱歉。