基于UBL和纯XML数据库的EDI系统设计与实现

基于UBL和纯XML数据库的EDI系统设计与实现

摘要本文在总结原有EDI系统建设中存在的问题基础上，引入了UBL和NativeXMLDB两种新技术，最后，提出了构建EDI系统所需实现的基本功能框架。本文可以为正兴起的地方电子口岸的EDI系统建设起到一个指导作用。关键词电子数据交换EDIUBL纯XML数据库1EDI简述及现状电子数据交换（ElectronicDataInterchange，EDI）就是将数据的信息规范化和格式化，并通过计算机网络进行联通处理。EDI系统在很多领域有广泛的应用，如医疗、零售、海运等，主要用来做组织机构间相互交换信息。传统贸易中是使用各种单据、单证、票据通过人工或半人工的方式来实现贸易相关方之间的信息流转。将传统贸易模式过渡到EDI贸易模式，那将可以大大提高交易效率，简化交易流程，减少错误，降低成本。特别是在外贸物流行业，贸易所涉及到环节繁多，人工出错率大，数据需要反复确认等许多不利因素。EDI系统将有效帮助解决这类因素，从而加快物流通关速度，节约物流通关成本。因此，国家也在大力推行各地方电子口岸的建设。传统的基于增值网络的EDI系统造价昂贵，需要租用线路，可扩展性不强。如今Internet是如此的普及和方便，各贸易实体当然希望能够通过Internet的方式实现和EDI系统进行信息交换，但是Internet上传输的数据存在很大的不安全性，这就需要增加物理链路的安全性和数据本身的安全性。EDI系统间传输的报文可以采用国际标准，如UN/EDIFACT等，而这种国际标准往往是为了支持全球EDI系统，报文结构复杂，可读性不强，程序处理也不方便。我们如果针对于区域化贸易数据流转，可以不采用结构复杂的UN/EDIFACT报文格式，而采用自定义报文格式，如定长或分隔符区分字段或元素。只要收发双方统一好格式，实现起来比较简单。但是，自定义报文格式也有一些限制，如数据中出现格式上的保留符号就比较难处理，报文结构不适合加密，报文解析程序不能灵活适应格式修改，报文格式正确性难以校验。因此，我们用XML报文进行传输数据能克服以上不足，并能利用和发挥XML的优势和许多成熟的技术。在将来的EDI系统中，将有越来越多的行业基于XML框架。2UBL的定义及在EDI系统中的应用国际上有许多组织根据自己的需求定义了特定的XML格式报文，这样不同组织间要进行报文交换就很困难。2004年9月，OASIS技术委员会定义了和发布了UBL(UniversalBusinessLanguage)1.0，称为通用商业语言。UBL提供让许多的商业文档可以用一种普遍地可理解和可识别的商业语法合理的组装而成，也是商业间的信息交互运行在一个标准的业务框架下，就如ISO15000(ebXML)。UBL可以通过扩展来满足不同行业的需要，从而试图解决现有存在的大量不同XML格式报文的问题。发布的UBL1.0提供了如下内容：⑴XMLSchema描述的可重用的数据组件库，如“地址”、“条款”、“付款”——这些每天商业上都要使用的数据元素。⑵通用商业文档如“订单”、“发票”、“发货通知”等可以从UBL组件库抽取出需要的构件称特定的XMLSchemas集。⑶在特定的贸易关系中，支持UBL的个性化定制。如一个订舱报文（bookingmessage），里面有船舶名称、发货人名称、收货人名称、货物名称、港口、备注等信息（参见下图），图1订舱报文UBL组件模型这些信息单元都是基于UBL中定义的基本商业信息实体（BasicBusinessInformationEntity）。我们也可以把几个相关的基本业务信息实体组成一个集合商业信息实体（AggregateBusinessInformationEntity），如订舱货物信息可以由货物名称、包装类型、件数、体积、毛重、净重这六个基本业务信息实体组成一个集合业务信息实体，称CargoLineItem。最后一个订舱报文的形成就可以通过把有关的基本商业信息实体或集合商业信息实体按一定顺序拼在一起。同时，这些基本/集合商业信息实体都是可以在其他报文中重用的。只要我们建立起了这些组件库，我们的中间XML报文格式定义就像拼装零件一样简单，这样我们的报文格式也易于管理和维护。在UBL1.0版本中也给出了许多可重用的基本组件库，下图（图2）是以XMLSchema形式给出的Party信息实体，图2Party信息实体的Schema定义在实际的报文中如发货人、收货人、通知人等的定义都是以Party信息实体为基础，并进行定制而成的，我们也可以把自己定制而成的信息实体根据需要放入自己的基本组件库。图3实际中Shipper_Party信息实体的构成图另外，我们把每一个基本信息实体当作一个小模块，用XSL语言把每个小模块定义好在WEB上的显示方式。当我们要以WEB方式显示一个报文时，可以把用到的信息实体对应的XSL模块重新在jsp或asp中构建一起，根据需要调整各模块间的顺序或格式大小，这样一个报文就可以方便以WEB方式展现给客户。报文交换平台需要提供给客户报文查询功能，按照这样方式，客户查询出的报文可以直接以WEB方式显示，而且实现简单，可以达到显示风格统一。我们需要在EDI系统中建立一套UBL定义的报文格式标准，作为EDI系统中的中间报文格式，利用UBL的特性，我们建立和维护这套报文标准就方便许多。用户的报文格式都转换成中间的报文格式，然后再把中间的报文格式转换成接收方可以接收的格式。3NativeXMLDB在EDI存储系统中的应用NativeXMLDB又称纯XML数据库，它把一个XML文档作为基本的逻辑存储单元。如现在的Oracle10g就支持NativeXML数据库，并且定义XMLType作为一种数据类型，它使数据库可以理解含有XML的列或表，就像DATE数据类型使数据库可以理解含有日期的列，它可以同其它数据类型一样使用。NativeXMLDB的简单使用可以按照下面操作：首先把某个报文类型相应的XMLSchema报文标准（用UBLSchema定义的），注册到NativeXMLDB，Oracle可以通过调用DBMS_XMLSCHEMA.REGISTER_SCHEMA()的PL/SQL过程来注册Schema。当基于该Schema的实际报文存储入库时，可以用XMLType数据类型提供的方法isSchemaValid()和schemaValidate()来验证报文是否满足报文标准的定义。然后创建表，类似其他建表的方法，SQL>createtableXML_DOCUMENT_TABLE2(3FILENAME

varchar2(50)，4XML_DOCUMENT

XMLType5)或者，当有XMLSchema已经向数据库注册后，可以用以下方法来创建表，对于XML报文的存储，NativeXMLDB具有非常鲜明的优势，因此我们把EDI系统的中间格式报文直接存入NativeXMLDB。从而可以不需要为了建立关系数据模型花费大量的时间；可以保持报文中数据间的树型结构层次关系而不是二维数据关系；也可以通过SQL函数语句直接从报文中提取数据。4EDI系统参考功能框架根据对原有EDI系统的研究和现有建设EDI系统的需求，提出了如下的EDI系统的功能模型，包含如下：(1)

EDI系统建设的前提条件要使各贸易实体间信息放心地通过EDI系统进行流转，就必须保持EDI系统的中立性，保证数据传输的安全性，同时要保证数据不随意对外泄漏、未授权的人不能看到存储的数据信息。(2)

提供多种接收通道允许客户端从多种通道发送报文到EDI系统，包括FTP、FTP/s、EMAIL、HTTP、HTTP/s、WebServices、MQ等。(3)

病毒检查对所有接收进来的报文要进行病毒检查，可以通过防火墙或杀毒软件检查实现。(4)

支持数据加密和数据签名随着我国电子签名法的颁布，数字签名具有法律效力，使得无纸化贸易成为可能，所以EDI要支持一套统一的CA认证系统。发送方可以把数字签名放入报文中，从而使报文具有原始不可以抵赖性。当用户和EDI系统都是采用了同一套CA认证体系，报文发送进来时，检查报文是否经过数据加密，如果数据经过加密，则EDI系统采用自己平台的私钥对报文先解密，然后再进行格式转换；当发送方不希望EDI系统看到相关的业务数据时，发送方可以采用接收方的公钥进行加密报文体或某些关键字段，此时EDI系统就不需要对此段报文进行解密。当EDI系统把报文格式转换成接收方的格式后，可以用接收方的公钥进行加密，然后把加密后的报文发送给接收方。更复杂的，如果有多个不同CA系统间进行报文交换，那在系统内要支持不同CA系统之间的数据签名换签。(5)报文间格式转换EDI系统要提供的一个重要的功能，就是为发送和接收双方做格式转换。由于报文格式有很多种，假如有n种报文格式，如果我们在任意两种格式间做一个转换，那就有n*(n-1)对转换；另一种方式，如果我们把n种报文格式转换成一个中间的格式，然后再把中间报文格式转换成n种报文格式，这样我们仅需要做2*n对转换就可以实现任意两报文格式间的格式转换。这就很有效地减少了工作量和维护量。中间报文格式我们定义成UBL格式，这样我们可以充分利用XML及UBL的技术优势，例如可以用XSL直接展现报文内容，编程处理方便性等。(6)报文存储功能经过EDI系统的报文需要一式三份进行存储。第一，存储刚接收进来的原始报文，作为原始报文的存证；第二，原始报文统一转为成平台定义的中间报文格式，此中间格式的报文都放入NativeXMLDB中，可以用作以后数据查询、显示和基于上面开发应用系统；第三，所有已转换好接收方可以接收的报文格式在发送的同时进行存储入库，作为发送报文的存证。第一和第三份报文也可以用文件方式存储。在把原始报文转成中间XML报文格式时，再入库的同时可以对报文用XMLSchema进行格式校验，如报文是否完整，必选字段是否缺少，字段是否超长等。(7)报文数据继承功能一个完善的EDI系统应该更多的为客户考虑，为客户提供个性化和便捷功能。如报文发送方可以指定EDI系统把他原来发送过的或接收到的报文重新发送一遍；或者，把他原来发送过的或接收到的报文提取出数据组装成一个新报文，再发给指定的接收方。总之，基于已有的报文数据我们可以开发许多客户化系统，系统提供的功能越多，对用户就会有更多的吸引力。(8)报文查询和显示功能客户可以根据需要，在EDI系统上查询出自己已经发送的报文和接收到报文，可以跟踪报文所处的状态，这些查询可以基于时间段、接收方、报文类型等条件。客户可以查看报文内容，并最好能提供友好的展现方式，而不是报文格式的再现。(9)发送回执报文功能当发送方把报文发送到EDI系统，系统需要给发送方一个已接收到报文回执；接着系统做格式校验和格式转换，这其中发现错误，需要给发送方一个错误回执，并有错误代码和错误描述；若报文没有错误就转成接收方可以接收的报文格式，再发送出去，同时给发送方一个已发送报文回执。(10)提供测试环境上生产环境前，当然要有一个测试环境，让客户进行联调测试、发现问题。当测试环境通过后，相关方签定协议后，就可以方便地切换到生产环境。5结束语对EDI系统的建设，本文仅是抛砖引玉，描述了一个大体框架，其中用到的UBL和NativeXMLDB两种新技术可供参考，具体的实现读者可以参考相关资料完善。参考文献1．UcheOgbuji.ThinkingXML:通用商业语言（UBL）./developerworks/cn/xml/rdf/part16/2．UBLTC.cd-UBL-1.0./ubl/cd-UBL-1.0/3．江代有.电子数据交换——EDI.现在电子技术，20034．SeanDillon.Wh