• 咨询详情,请联系我们:177-8250-8152 / sales@kasoftware.cn

  • 咨询详情,请联系我们:177-8250-8152 / sales@kasoftware.cn

5 2021-03

如何使用知行之桥EDI系统实现CSV和XML相互转化

|2021-03-05T16:14:55+08:002021年3月5日|帮助文档, 操作指南|如何使用知行之桥EDI系统实现CSV和XML相互转化已关闭评论

本文主要介绍在EDI系统中CSV和XML如何进行相互转化,首先需要了解什么是CSV和XML? CSV的全称为:Comma-Separated Values(逗号分隔值),是最通用的一种文件格式,可以很容易的导入各种PC表格及数据库中。在CSV文件中,每一行数据分别对应数据表的一行。生成数据表字段用半角逗号隔开。CSV文件用最常见的记事本和Excel都能打开,两者的区别是,用记事本打开显示逗号,用Excel打开,则看不到逗号,因为逗号用来分列了。 XML文件最初设计便是为了EDI(电子数据交换),即为EDI提供一个标准数据格式。可以用于交换数据,共享数据,更加充分的利用数据。 通过以上的内容,我们对CSV和XML有了基础的认识。更多转换可以参考文章:CSV/PSV/TSV与XML互相转换 XML转CSV 在EDI系统中,要想实现和交易伙伴的业务数据传输,首先要和交易伙伴确定传输协议,比如AS2,然后建立EDI连接,然后进行数据的传输、转换。在知行EDI系统中将XML转换为CSV的工作流如下图所示: 1.以X12标准的830报文为例,将830报文转换成的标准XML,将其传入XML Map 端口,并在此步进行标准XML到特定XML的映射。 [...]

26 2020-04

CSV/PSV/TSV与XML互相转换

|2020-04-26T18:56:52+08:002020年4月26日|EDI, 帮助文档, 操作指南, 解决方案|CSV/PSV/TSV与XML互相转换已关闭评论

总览 XML 是知行之桥用于处理工作流中数据的主要格式。 因此,将{{ page.file_format }}文件转换为XML 是作为工作流中进一步处理的过渡步骤,或者在操作XML 之后将XML 转换为{{ page.file_format [...]

21 2020-04

工作流设计的最佳实践

|2020-04-21T17:15:28+08:002020年4月21日|帮助文档, 项目实施|工作流设计的最佳实践已关闭评论

本章节描述了用于知行之桥工作流设计的常见最佳实践。 从入口和出口开始 大多数工作流都有一个数据入口和一个数据出口。对于某些循环工作流,入口点和出口点可能是同一个端口。 例如,当外部贸易伙伴通过AS2发送业务文档时,数据可能在AS2端口处进入工作流。此业务文档中的数据可能需要导入到后端系统中,如数据库。在这种情况下,AS2端口是工作流的入口,而数据库端口是工作流的出口。 创建新的工作流时,通常最容易从这些入口和出口端口开始。然后,“向内工作”,向工作流中添加更多端口,填充入口和出口之间的步骤(例如,添加将AS2接收的数据转换为数据库插入数据的端口)。 文件传输端口因合作伙伴而异 通过网络发送或接收文件的端口(如AS2、AS4、FTP、SFTP、OFTP等)是双向的,但只为单个贸易伙伴(即单个远程方)配置。换句话说,一个单一的AS2端口可以通过亚马逊发送和接收AS2信息,但它不能通过沃尔玛发送或接收文件。 许多MFT(安全可控文件传输)端口需要通过配置来交换文件。“个人配置”页面用于为每个支持的协议配置应用程序范围。例如,在AS2个人配置中配置的信息用于所有AS2端口,而特定于合作伙伴的AS2连接详细信息在每个AS2端口中配置。 对端口使用命名约定 端口应始终被赋予一个描述性名称,以表明端口在工作流中的角色。 [...]

18 2020-03

XML Map端口实战

|2020-03-18T16:27:08+08:002020年3月18日|帮助文档, 示例工程|XML Map端口实战已关闭评论

Hello,大家好!欢迎大家来到小知课堂,我们这一篇要讲的是XML Map 端口的使用方法。顾名思义,XML Map 端口的主要功能就是完成两个不同XML文件的关系映射,为什么要实现这个功能呢?当然是为了实现神秘莫测的EDI标准XML文件和简单易懂的XML文件之间的相互转换,所以在很多EDI解决方案中,XML Map 端口都能发挥它举足轻重的作用。下面,就让我们一起来揭开XML Map 端口的神秘面纱。 扩展阅读: [...]

28 2020-02

为什么工作流中围绕XML做EDI报文数据解析/生成?

|2020-02-28T17:52:41+08:002020年2月28日|帮助文档, 知识库|为什么工作流中围绕XML做EDI报文数据解析/生成?已关闭评论

经常有客户问起,为什么在处理EDI文件时不一次到位,而需要使用多个端口来分次进行处理呢,是不是想要多占用几个端口好多卖钱呀? 实际上,在一开始的知行EDI产品中,功能还没有这么完善,当时只支持EDI常见的传输协议,那个时候我们在做报文翻译时,还不能仅通过简单的配置来实现,需要手写代码,去读取报文,然后获取每一行的数据,再逐一去读对应的业务值。参考之前的实施经验,觉得实施过程漫长、前期开发代码量大、后期维护成本也高,经过产品部门多次考量,在一次次的产品升级过程中,不停的进行功能新增、完善,才形成了现在这样的一套报文处理模式。 那么,到底是不是直接对报文进行处理更简单呢? 假设我们现在通过AS2传输,接收850采购订单EDI报文,采用自定义XML方案。 直接处理EDI报文 我们来回顾一下直接处理业务报文的步骤: 首先,通过AS2收到850采购订单后,要直接进行处理,完成报文翻译,我们的代码逻辑大约如下: 先读取当前850采购订单报文的内容 对内容进行分割,将850采购订单的内容按照节点分割,例如:ST节点,BEG节点等等,每个节点代表不同的信息 开始逐一读取节点,匹配节点所属的业务含义,并将每个节点中的详细业务数据读取出来 [...]

返回顶部