EDI项目实施-技术规格说明书



#### (一)EDI概述

##### EDI介绍

EDI (Electronic Data Interchange) ,即电子数据交换,旨在实现两个企业之间业务系统数据的交换。比如,一家公司可以通过电子数据交换平台,向另一家公司发送订单、查询库存、通知发货等信息。 通过降低成本、提高速度、精度和企业效益,EDI继续证明其重大的商业价值,帮助企业整合供应链、降低库存、实现精益生产。

EDI系统主要功能:

* EDI报文传输
* EDI报文转换
* 业务系统集成

##### EDI报文标准

* ANSI ASC X12

1979年,美国国家标准学会(ANSI)特许公认标准委员会(ASC)X12为行业间电子交换商业交易开发统一的标准,即为电子数据交换。原先设想的ANSI X12支持跨在北美的的不同行业的公司,但今天有超过300,000家公司在日常业务交易使用X12的EDI标准。X12也对UN/EDIFACT作出过贡献,广泛用于美国以外的数据交换。

* UN/EDIFACT

由联合国主导开发制定的国际通用EDI标准。EDIFACT标准提供了一套语法规则的结构、互动交流协议,并提供了一套允许多国和多行业的电子商业文件交换的标准消息。在欧洲,很多企业很早就采纳了EDIFACT,所以应用广泛。已经在ASPAC地区开始EDIFACT的应用,亚太地区使用基于XML的标准较多。

* VDA

该组织为德国汽车行业内企业的需求开发标准和最佳实践,VDA已开发超过三十种报文,以满足如大众、奥迪、博世、大陆和戴姆勒公司的需要。

* VICS

自发跨产业商务标准用于在北美的一般商品零售行业。这是一个ANSI ASC X12国家标准的子集。VICS的EDI正在被数以千计的公司、部门和专业的零售商店、量贩店和各自的供应商采用。GS1美国在1988年成为VICS的电子数据交换的管理和行政机构。GS1美国还管理着ASC X12衍生的统一通信标准(UCS),用于食品行业、工业/商业(I/C)的管理。

* EANCOM

EANCOM标准最初是由EAN大会1987年设想,并提出,是根据当时新兴的 UN / EDIFACT 标准开发。相比 TRADACOM 消息集,EANCOM更详细。EANCOM由GS1维护。EANCOM最初为零售业开发,并随后发展成为使用最广泛的UN / EDIFACT的子集,已经推广到一些其他行业,如医疗、建筑和出版等。

* HIPAA

由美国国会于1996年颁布的健康保险可移植性和责任法案。HIPAA的一个关键组成部分是为电子医疗交易、国家认证供应商、健康保险计划和雇主建立国家标准。建立该标准是为了通过鼓励广泛使用美国卫生保健系统的EDI标准,提高北美卫生保健系统的效率和效益。HIPAA EDI交易集基于 X12 建立的。

* ODETTE

在欧洲,远程传输的数据交换组织是代表在欧洲的汽车行业的利益。他们相当于美国汽车工业行动集团(AIAG)之于北美。该组织开发工具和建议,以改善整个汽车价值链的货运、服务产品数据和商业信息。ODETTE一直致力于开发通讯标准,例如 OFTP 与 OFTP2.0,不断改善流程,如物料管理原则/物流评估(MMOG / LE的)和汽车业的具体文件标准等。

* RosettaNet

RosettaNet是一个包含主要的计算机、消费类电子产品、半导体制造商、电信和物流公司,共同创造和实现全行业的开放的电子商务流程标准的组织。这些标准形成了一个共同的电子商务语言,在全球基础上保持供应链合作伙伴之间一致的进程。RosettaNet的文档标准基于XML定义消息指引、业务流程接口和公司之间的相互作用的实施框架。使用RosettaNet合作伙伴接口流程(PIPs),可以连接各种规模的贸易伙伴,以电子方式处理交易和移动信息到扩展的供应链。

* SWIFT

环球银行金融电信协会(SWIFT)成立于1973年,总部设在布鲁塞尔。SWIFT经营一个世界性的金融通讯网络,银行和金融机构之间的消息交换。SWIFT还向金融机构销售软件和服务,在SWIFTNet的网络上使用它。 SWIFTNet是交换SWIFT文件、FIN、InterAct和FileAct的基础设施,用于编码这些文件以便传输。大部分银行同业拆息的消息使用SWIFT网络。截至2008年11月,SWIFT联接了209个国家8740个金融机构。SWIFT文档标准分为四个方面:付款、服务贸易、证券和交易。

* Tradacoms

这是一个早期的EDI标准,主要是在英国零售业。它最初在1982年推出,作为UN/GTDI的执行,EDIFACT的前身之一。因为它的开发在1995年停止了,并支持EDIFACT EANCOM的子集,尽管在英国的零售业EDI领域仍然广泛使用。

##### EDI传输协议

* AS1

Applicability Statement(AS)1是由IETF(Internet Engineering Task Force)开发的,旨在通过SMTP和S/MIME实现安全可靠的传输。它是第一个可开发、使用签名、加密和MDN回执的AS协议(MDN涉及到消息处理通知或提供“接收返回”的能力)。基于AS文件传输的特点,文件交换的双方需要通过SSL加密认证、并且具有特定的交易伙伴名称。

* AS2

Applicability Statement(AS)2,和最初的AS1协议一样,使用签名、加密和MDN回执。一般通过网络使用HTTP或HTTPS协议发送AS2消息,AS2以点对点连接的方式被广泛的部署。基于HTTP标准,AS2具有很多优势,包括增加的验证,和通过数字签名实现的安全。AS2的交易和确认是实时发生的,增加了文件传输的效率。通过零售行业,沃尔玛是第一个使用并推动AS2发展的公司。

* AS3

Applicability Statement(AS)3是由IETF开发的,用于实现通过FTP协议传输的安全性和可靠性。AS3是基于FTP协议的安全版本,而不是HTTP。相对于AS2采用的点对点的模式,AS3协议传输采用的是由S/MIME通过FTP实施的。AS3和AS2一样,使用MDN回执(送达回执)。AS3是个双向协议,客户端不需要接收实时信息的侦听器(AS2总是需要)。在FTP脚本、应用和安全方面,AS3特别适合于银行,以及其他投资量大的产业。

* AS4

Applicability Statement(AS)4是由OASIS ebXML消息传递服务技术委员会开发的。在Web服务领域,AS4提供了安全的B2B文件交换。AS4依旧处于草案定义格式阶段。AS4配置文件提供了一个市场的入门级解决方案,其允许公司利用他们内部的基于SOA平台外部B2B消息进行传递,同时承担一些较为复杂的Web服务。欧洲航空航天行业建议使用AS4作为与其贸易伙伴发送ebXML相关的B2B文档的通讯标准。

* ebMS

ebXML消息传递服务提供了一个安全可靠的SOAP/Web服务,并按照ebXML规范定义的服务的打包、路线规划和传输协议。ebMS是开放性标准,因此是中性的通信协议,尽管最常见的底层协议是HTTP和SMTP。在使用SOAP/Web服务之间的各种业务应用之间,ebMS实际上提供了一种基于ebXML的交换B2B文档的方法。

* FTP

文件传输协议是一个标准的网络协议,其通过基于TCP/IP的网络(如Internet)交换和操作文件。FTP是以客户端-服务器的架构建立的,并在客户端和服务器之间独立的控制数据连接。为了实现程序的内部功能,FTP也常被用于自动传输文件的应用组件。FTP可以用于基于用户的密码身份认证或匿名用户访问。

* FTPS

FTPS(File Transfer Secure Protocol)是对FTP的扩展,其增加了支持传输层安全性(TLS)和安全套接层(SSL)加密协议。FTPS不同于SFTP,不可混淆。一个使用SSH协议的不兼容的安全文件传输子系统。它也不同于安全的FTP,是通过SSH连接FTP的。

* HTTP

HTTP(又称:HyperText Transfer Protocol)用于请求和发送文件,特别是通过Internet或其他网络的web页面和web页面组件。在HTTP中,web浏览器作为客户端,同时在电脑上运行的应用程序将托管网页视为一个服务器。HTTP通常是在TCP/IP实现的,然而它也可以通过互联网上的其他协议或者其他网络实现。

* HTTPS

HTTPS(全称:HyperText Transfer Protocol Secure)是超文本传输协议和SSL/TLS协议的结合,它提供了服务器的加密和安全识别。HTTP连接通常用于互联网上的支付交易,和企业业务系统之间的敏感信息的交换。

* OFTP

OFTP(又称:Odette File Transfer Protocol)的开发提供了适用于欧洲汽车行业的标准通信平台,并且在20世纪80年代中期已经开始使用。OFTP也被零售、政府、制造商等所采用。OFTP协议非常易于使用,而且非常高效,它允许传输窗口被利用的同时将文件重新启动、数据压缩和安全。OFTP使企业之间通过点对点连接更容易通信。

* OFTP 2.0

OFTP 2.0(全称:Odette File Transfer Protocol version 2.0)是OFTP标准的最新版本,从一开始被设计用于在互联网上。相比于OFTP,OFTP2提供了一系列的便利,包括数据压缩、文件加密和企业合作伙伴间的数字证书的交换。它还支持处理超大文件(通常是GB大小),并提供额外的字符集支持,如中文和日语。至今,OFTP主要在欧洲应用广泛,然而,OFTP2被设计应用与整个互联网,它可以帮助全球的业务合作伙伴进行连接。自2008年以来,很多欧洲汽车制造商已经开始运行OFTP2试点项目,预计在未来的几年,在全球汽车行业广泛部署该标准通信协议。

##### EDI电子数据交换流程

大多数基于EDI方式的事务处理与传统手工处理文档方式是类似的,唯一的不同之处在于,借助EDI方式时,收发的消息是电子数据包裹形式。以下对EDI处理过程进行概述。

EDI处理步骤:

* 发送方从后端业务或会计电算化系统中提取数据
* 发送方将数据映射为适用于传输的EDI格式
* 完成EDI文档格式转化以备传输
* 发送方向接收方发送数据
* 接收方解析EDI文档,返回Ack消息给发送方

发送EDI文档给交易伙伴: 读取企业系统数据→生成EDI格式文档→生成报文、准备传输→发送EDI文档→处理/调用Ack

接收交易伙伴发送的EDI文档: 接收EDI文档→报文解析/验证EDI文档→生成Ack并发送给交易伙伴→生成指定格式文档→数据导入企业系统

EDI电子数据交换主要步骤:

* 映射 —— EDI文档转换为XML、Flat file等格式,或是XML、Flat file等格式文档转换为EDI格式。
* 报文转换 —— 解析入站数据,生成出站数据。
* 通讯 —— 涉及EDI事务集的传输,有直连和非直连方式。

##### 汽车行业EDI应用

EDI在汽车行业的应用已有四十年的历史了。今天汽车行业生产线的稳定运行主要依赖汽车制造商和他们的供应链之间无缝的业务文件的交换。 目前,用于汽车制造业的很多业务流程起源于由日本丰田设计的一个生产系统。围绕日本丰田生产系统发展的最佳实践有很多,例如实时生产方式(JIT)和精益制造等。JIT和精益制造流程是全球很多生产线稳定运行的核心,并且为了支持这些类型的生产流程,EDI提供了快速有效的传输业务文档的途径。使得JIT和精益制造流程成功的关键是,提高库存水平的可视度或通知货物何时抵达生产线。 汽车工业的全球化特性意味着,对于汽车制造商来说,不管在哪儿,最重要的就是要尽快的导入供应商。很多汽车制造商都已建立了生产基地,比如在东欧、巴西和中国等。最重要的是,确保那些地区的供应商能够和他们尽可能顺利的交换EDI文件。由于低成本或新兴市场的ICT技术相对比较落后,因此,汽车制造商必须提供简单易用的EDI工具,甚至确保可与最小的供应商进行电子化交易。 由于汽车行业的全球化特性 ,出现了今天无数的通信和文档标准,以及地区专用EDI网络。以下详述汽车供应链的结构和通信协议的描述,以及文档标准。

供应链结构

汽车行业形成了一个“分层”的供应链结构。一级供应商是汽车制造商或OEM。这些公司会提供一些最大的汽车配件或相关子系统,例如悬挂装置或变速箱。下面的第二级供应商,则提供一级供应商所需的配件,有可能是马达、泵或者轴承组件。再往下是第三级供应商,他们为二级供应商提供任何所需东西,比如托架、密封胶以及机器零件等等。 由于一级供应商对汽车制造商来说,至关重要。为支持JIT类型生产过程,他们在汽车制造商附近都设立了工厂。二级之后制造商可能分布在全球各地,这个领域的很多公司选择在中国、印度等低成本国家建立工厂。除了各级供应商,还有原材料供应商,例如直接向汽车制造商提供钢板的钢铁厂。 OEM厂商下的第三方(3PL)供应商把已生产完毕的车辆分配运输到全球各地的存放点或汽车销售中心,并在需要时把那些汽车运输至经销商。

通讯协议

汽车工业使用了很多标准的通讯协议例如FTP,但是在欧洲目前主要使用的通信协议是OFTP,ODETTE文件传输协议。自二十世纪八十年代中期起,OFTP广泛用于欧洲汽车行业,大多数汽车制造商都使用OFTP协议和他们的业务合作伙伴进行通信。随着互联网的出现,许多汽车供应商与ODETTE合作推行OFTP,随即出现了新版的OFTP v2.0,于2010年引入汽车市场。OFTP的新版本,一开始设计时考虑到互联网因素,它依靠加密功能和数字证书的交换,提供安全的文档交换。OFTP2也支持大文件的轻松交换如计算机辅助设计(CAD)文件。由于CAD文件容量大、信息敏感,因此CAD文件的发送是汽车行业最常见的问题。 文档标准 除了传统的EDI文档(如ANSI X12和EDIFACT)之外,许多区域性标准已被用于支持欧洲的汽车行业。举个例子,法国的ODETTE标准已得到了PSA Peugeot Citroen等汽车制造商的广泛使用,而在德国VDA组织结构也开发了一套适用BMW、Daimler AG和VW Group的标准。互联网EDI解决方案在汽车行业很常见,因为它支持小型业务合作伙伴与汽车制造商交换业务文件。为了防止汽车制造商建立界面各异的互联网EDI门户网站,对于如何在网页上编排EDI形式欧洲ODETTE机构开发了一套标准。“ODETTE形式第二版”是目前使用最广泛的标准,而且互联网EDI解决方案若要得到ODETTE组织的认可,通常就需要符合这种形式标准。

行业协会

很多行业协会都在为汽车行业服务,这些协会的主要任务是提供企业间如何以电子形式交换信息的标准。由于近年来全球扩展,世界各地的行业协会彼此之间紧密合作,以支持汽车公司尽快建立新工厂及导入新的业务合作伙伴。 汽车行业协会位于全球主要制造业中心,例如北美、欧洲和日本。在各自的区域积极工作,希望让汽车公司成为他们协会的成员,并为各个小组以及所实施的项目作出贡献。其中典型的项目包括物流管理操作指南、物流评价(MMOG/LE)、OFTP2、海外采购材料(MOSS)等项目。在部署整个汽车工业生产之前,行业协会会提供理想的环境来测试这些项目。 一些主要的行业协会包括ODETTE在内都服务于欧洲汽车行业的。其中,VDA组织主要服务于德国汽车公司,且Galia服务于法国汽车公司。还有汽车行业行动小组(AIAG)服务于北美的汽车行业,而日本汽车制造商协会(JAMA)则服务于日本汽车行业。

行业专用网络

除了传统的EDI VAN供应商,许多地区的专用网络亦服务于汽车行业。最流行的网络是American Network eXchange(ANX),European Network(ENX)和Japanese Network eXchange(JNX)。这些网络为信息交换提供一个非常安全的方式。比如在欧洲,ENX用于快速交换工程设计或计算机辅助设计文件。尽管网络最初是服务汽车行业的需求,但全球的扩展意味着有必要为这些独立的网络提供互相连接的能力。

#### (二)RSSBus Connect EDI系统介绍

##### 系统主要界面

* Status界面

显示系统传输记录。Transaction Log:记录系统每个port通信细节,及通信过程种出现的错误;Application Log:记录应用程序资源请求及错误信息,通用错误日志和访问日志可以帮助排除在发送和接收时配置错误的问题;Access Log:记录应用程序处理的所有HTTP请求信息。 以上记录信息可按照时间、处理状态、名称等进行查询排序并下载log文件,便于用户操作及问题处理。

* PORTS界面

添加&配置Port/交易伙伴。Port/交易伙伴可用于传输或报文格式转换,分为传输Port和开发Port。传输port支持AS2、AS4、OFTP(2)、FTP、FTP/s、SFTP、SAP(IDoc)、Database、SCP、RNIF、OpenPGP、SOAP等类型传输功能,开发Port支持PDF、Excel、EDIFACT、X12、PIP、Script等类型开发功能。 Send页面用于显示待发送的文件列表,Receive页面用于显示已收到的文件列表,Settings页面用于配置Port类型的传输参数或开发功能参数,Advanced页面用于配置一些较为复杂高级的传输或是开发要求,Events页面用于编写处理收发文件的代码,对待发送或是已收到的文件进行后续处理。

* PROFILE界面

配置自己的传输参数,支持AS2、AS4、OFTP(2)、RNIF、SFTP Server。

* HELP界面

系统相关知识介绍,操作指导以及系统主要功能等介绍。

* ABOUT界面–激活

系统ABOUT界面,点击“Install New License”激活已购买license,使用付费版;或是点击“Active 30-Day Trail”激活试用版,在购买前进行产品试用,便于您了解产品功能,进行选择。

##### 系统操作配置指导

* AS2配置指导

* AS4配置指导

* OFTP (2.0)配置指导

* SFTP配置指导

* FTP配置指导

* OpenPGP配置指导

* SAP(IDoc)配置指导

##### 免费试用

* 参见链接

#### (三)EDI系统实施_内部IT系统技术规格要求

##### 部署最低要求

###### Windows

* XP Service Pack 3/2003 Service Pack 2或更高
* .NET Framework 2.0或更高 500 MB RAM, 推荐1GB或1GB以上
* 足够的磁盘空间存放日志和写入的文件

注:可以使用较早的Windows版本,但需加载IIS中的应用程序。对于Windows Server 2008来说,只有Windows Server 2008 R2支持把应用程序当作一个服务。

###### Unix/Mac

* Java Runtime Environment (JRE) 1.6或更高
* Java Servlet 3.0 API或更高 500 MB RAM, 推荐1GB或1GB以上
* 足够的磁盘空间存放日志和写入的文件

###### Internet Connection

* 网络持久连接
* 固定的外部IP地址,用于运行RSSBus集成服务器的系统
* 防火墙/代理服务器与外部系统可进行通信

##### 项目实施准备

实施EDI项目,前期需要明确以下内容:

* 明确与贸易伙伴之间的业务需求 确认开发EDI的业务类型(如,订单、发票等)
* 确定EDI传输协议(如, AS2/ OFTP/ SFTP/ FTP)
* 确定EDI报文标准(如, EDIFACT/ X12/ VDA/ ODETTE)
* 网络服务类型(Internet/ISDN)
* 其他网络资源,如服务器、固定IP、域名、证书(视不同传输协议而定)

#### (四)EDI系统实施概述

EDI(Electronic Data Interchange),即电子数据交换。主要用于企业业务管理系统之间的数据传输,通过将文档进行数字签名、加密,使得整个文件传输过程安全可靠。 RSSBus Connect通过AS2/OFTP/SFTP/FTP Port实现数据传输,借助于Excel/EDIFACT/X12 Port实现报文格式转换,系统只需简单配置,即可实现安全可靠的自动化文件传输。

Sending Company(发送方)

* 整理和收集数据,准备需要发送的文件
* 翻译文件,生成EDI标准格式文件
* 建立连接,传输EDI文件至交易伙伴

Receiving Company(接收方)

* 建立连接,接收交易伙伴发送的EDI文件
* 翻译EDI文件,生成其他格式文件(如,XML、IDoc等)
* 整理和收集数据,提供给业务人员

EDI文件转换过程分为解析和生成两部分,系统可结合实际业务需求,完成EDI系统与企业数据库集成,RSSBus SQLServer Port就提供了一种简单高效的集成方式,实现了数据库中的业务数据与EDI标准格式的自动转换。以下就几种RSSBus ConnectTM EDI解决方案简要介绍:

###### RSSBus ConnectTM SQL Server解决方案

SQLServer方案提供了一种与数据库简单高效的集成方式,实现了数据库数据与EDI标准格式的自动转换,适用于ERP系统较完善的中小型企业。

参考链接:

EDI文件解析

* AS2 Port:接收来自交易伙伴的EDI文件。
* EDIFACT Port:将客户传来的EDI文件自动转换为最原始的XML格式,更易读取EDI数据。
* Script Port:通过定制开发,将最原始的XML格式转换为符合SQLServer Port Schema要求的XML格式。
* SQLServer Port:连接数据库,通过配置Schema文件,将XML格式中的数据映射到Database。

EDI文件生成

* SQLServer Port:连接数据库,通过配置Schema文件,从数据库读取数据,生成SQLServer Port定义的XML格式。
* Script Port:通过定制开发,将数据库定义的XML格式转为符合EDI规范XPath的XML。
* EDIFACT Port:将符合EDI规范XPath的XML自动转为EDI标准格式。
* AS2 Port:将生成的EDI文件发送至交易伙伴。

###### RSSBus ConnectTM Excel解决方案

Excel方案是主要针对于不具备ERP或其他业务管理系统的企业制定的,使得这类企业也可以通过EDI与交易伙伴进行数据交换。中间文件格式是Excel,便于业务人员识别,但是实际业务应用中并不推荐使用,真正意义上的EDI还是需要建立在较为完善的企业业务管理系统之上的。Excel方案仅作为一种临时解决方案,对于具备完善业务系统的企业仍建议采用SQLServer或是其他方案。

参考链接:

EDI文件解析

* OFTP Port:接收到交易伙伴发送的EDI文件,并将文件自动转发至EDIFACT Port。
* EDIFACT Port:将收到的EDI文件自动转换为XML格式,并自动转发至Excel Port。
* Excel Port:通过定制开发,将收到的XML文件自动转换为Excel格式,并交由业务人员。

EDI文件生成

* Excel Port:通过定制开发,将Excel文件自动转换为XML文件,并自动转发至EDIFAT Port。
* EDIFACT Port:将收到的XML文件自动转换为EDI格式,并自动转发至OFTP Port。
* OFTP Port:将收到的EDI文件,自动发送至交易伙伴EDI系统。

###### RSSBus ConnectTM SAP解决方案

借助于RSSBus ConnectTM IDoc Port可实现与SAP系统连接,IDoc Port解决方案为SAP系统用户提供了直连方式,实现与SAP业务系统集成。

参考链接:

EDI文件解析

* AS2 Port:接收来自交易伙伴的EDI文件。
* EDIFACT Port:将客户传来的EDI文件自动转换为XML格式,更易读取EDI数据。
* Script Port:通过定制开发,将XML格式转换为IDoc文档格式。
* IDoc Port: 通过配置SAP相关信息连接SAP系统,发送XML IDoc或Raw IDoc至SAP系统。

EDI文件生成

* IDoc Port:通过配置SAP相关信息连接SAP系统,接收XML IDoc和Raw IDoc文件。
* Script Port:通过定制开发,将IDoc文档转换为XML格式。
* EDIFACT Port:将符合EDI规范XPath的XML自动转为EDI标准格式。
* AS2 Port:将生成的EDI文件发送至交易伙伴。

###### RSSBus ConnectTM WebService解决方案

在RSSBus Connect和企业业务管理系统均提供WebService接口情况下,用户可以选择 WebService集成方式实现EDI系统与业务系统集成。

向SAP/其他业务系统发送数据

* AS2 Port:接收来自交易伙伴的 EDI 文件。
* EDIFACT Port:将接收到的EDI文件自动转换为XML格式,易于后续数据读取。
* Script Port:通过定制开发,将XML格式转换为自定义XML或业务系统指定的某种文件格式。
* Script Port:通过Soap ops调用业务系统提供的WebService接口,主动向SAP或其他业务系统发送数据。

从SAP/其他业务系统获取数据

* Soap Port:配置WSDL地址,当信息系统发起Request时,接收业务系统数据。
* Script Port:通过定制开发,将接收的文档转换为XML格式。
* EDIFACT Port:将符合EDI规范XPath的XML自动转为EDI标准格式。
* AS2 Port:将生成的EDI文件发送至交易伙伴。

###### RSSBus Connect™ API解决方案

RSSBus Connect™ API以OData协议方式暴露, OData是一种REST接口的包装方式。 RSSBus Connect™默认遵循OData V4协议,其内容均以JSON方式传输。用户可以通过调用API的方式,获取RSSBus Connect接收到的数据,反之,亦可以将数据发至RSSBus Connect。

调用API请求RSSBus发送业务数据

* AS2 Port: 接收来自交易伙伴的EDI文件。
* EDIFACT Port:将接收到的EDI文件自动转换为XML格式,易于读取EDI数据。
* Script Port:通过定制开发,将XML格式转换为自定义XML或业务系统指定的某种文件格式。
* 调用API:业务系统定期调用API,请求RSSBus Connect发送业务数据。

调用API向RSSBus发送数据

* 调用 API:业务系统定期调用API,主动向RSSBus Connect发送文件。
* Script Port:通过定制开发,将接收的文档转换为XML格式。
* EDIFACT Port:将符合EDI规范XPath的XML自动转为EDI标准格式。
* AS2 Port:将生成的EDI文件发送至交易伙伴。

综上,RSSBus Connect具有5中EDI解决方案,分别适用于以下情况:

* 对于不具备完善的业务系统的中小型企业,建议选择“RSSBus Connect™ Excel解决方案”。
* 对于具备完善的业务系统的大中型企业,建议选择“RSSBus Connect™ SQLServer解决方案”、“RSSBus Connect™ WebService解决方案”或是“RSSBus Connect™ API解决方案”。WebService方式是由EDI系统来完成调用接口的开发,而API方式是由业务系统来完成调用接口开发工作。
* 对于具备SAP等大型业务系统的企业,建议选择“RSSBus Connect™ SAP解决方案”。

###### 会话加密(TLS/SSL)

TLS允许基于客户端证书的客户端认证方式,OFTP2不强制要求TLS客户端认证,但是建议使用。任何兼容的软件解决方案必须具备客户端身份验证TLS的能力。 在OFTP2协议中,TLS加密会话是强制要求的,但是TLS本身可提供禁用会话加密功能。

###### 证书选择

OFTP2使用加密技术来提供较高层次的安全功能,加密依赖于密钥,通过交换证书可以实现密钥的交换。 证书分为三类:(安全级别由低至高,依次为)

* 自签名证书:若证书主题(Subject)和发行人(Issuer)一致且同为域名(DN),则这个证书即为自签名证书。自签名证书不能防止网络中第三方的恶意攻击,在这种情况下,它们不能提供对所有者的身份的保证,因此安全性较差。

* 双方签署的证书:双方签署的证书可以由两个合作伙伴轻松实现,如果签名请求安全交换,那么就可以避免网络中第三方的恶意攻击。如果双方签署的证书用于在线传输,那么这个证书被视为一个CA证书,因此需要具有一个CA标志或设置为“ True”,否则,证书信任链验证可能会失败。

* 证书颁发机构签名证书:由第三方证书机构签发,信任链由根证书和签发方证书构成,较之前者,安全性更高。

以上三类证书可以在OFTP2传输中使用,交易双方可以协商选择一种证书类型,为确保数据传输安全,推荐使用相关证书机构签发的证书。