1、ICS 3524060L 70a目中华人民共和国国家标准GBT 148053-2007IS0 97353：2002代替GBT 1480531999行政、商业和运输业电子数据交换(EDIFACT) 应用级语法规则(语法版本号：4，语法发布号：1)第3部分：交互式电子数据交换专用的语法规则Electronic data interchange for administration，commerce andtransport(EDIFACT)-Application level syntax rules(Syntax versionnumber：4Syntax release number：1)一n
2、In 3：Syntax rules specific to int嘲ctive EDI(ISO 97353：2002，IDT)中纠坠瞳娑塑国国塞质量监督检验检疫总局告士中国国家标准化管理妻剪签发币GBT 148053-2007ISO 9735-3：2002目 次前言”IsO前言“目l言”1范围2一致性3规范性引用文件4术语和定义5 I-EDI交换结构6交易中的I-EDI报文7对话管理一附录A(资料性附录)说明段顺序的示例附录B(资料性附录)I-EDI功能、状态和事件B1 I-EDI功能B2数据需求B3 I-EDI功能的顺序B31概：述B32状态-B33事件附录C(资料性附录)I-EDI过程模型
3、C1 I-EDI概述C2 I-EDI的业务需求C3支持业务需求的功能需求C4业务模型C5功能模型”C6最小的通信需求一C7数据需求I，1112235777888他地地他nM前 言GBT 148053-2007ISO 9735-3；2002GBT 14805(行政、商业和运输业电子数据交换(EDIFACT)应用级语法规则(语法版本号：4，语法发布号：1)由下列部分组成：第i部分：公用的语法规则，第2部分：批式电子数据交换专用的语法规则；第3部分：交互式电子数据交换专用的语法规则第4部分：批式电子数据交换语法和服务报告报文(报文类型为CONTRI)；第5部分：批式电子数据交换安全规则(真实性、完整
4、性和源抗抵赖性)；第6部分：安全鉴别和确认报文(报文类型为AUTACK)；第7部分：批式电子数据交换安全规则(保密性)；第8部分：电子数据交换中的相关数据；第9部分：安全密钥和证书管理报文(报文类型为KEYMAN)；第10部分：语法服务目录。将来还有可能增加新的部分。本部分为GBT 14805的第3部分。本部分等同采用ISO 97353：2002UIT) C nUIB M 1开始对话确认(UIHUIT) C n开始对话拒绝 UIR M l传送数据 (UIHUIT) M请求状态 UIR M l报告状态 UIR M 1放弃对话 UIR M 1(UIHUlT) C nUIT) C n结束对话确认U1
5、Z M 1UNA C lUIB M 1完成对话请求(UIHUIT) M nUIZ M 1UIB M l完成对话确认 (U1HUIT) M nUIZ M 1B3 I-EDI功能的顺序B31概述在下列图表中，I EDI协议通过协议所处的状态和引起状态转移的事件来描述。当这些事件出现时，协议“机器”自动地从一个状态转移到另一个状态。I-EDI协议能够处于有效状态的数目是有限的。对话状态图(图B1)给出了Y-EDI协议的状态、影响IEDI协议的事件和从一个状态到另一个状态的转移。这些内容被进一步形式化为状态一事件矩阵(表B4)，即IEDI协议机的二维表示。其中一维是状态，另一维是事件。状态和事件的交叉
6、部分给出该特定事件所导致的下一状态，所有其他事件均为出错条件。B32状态在任一时刻，I-EDI协议都可能处于有限个状态中的某一状态。表B2列出了I-EDI协议的有效状态，并描述了这些状态的含义。GBT 148053-2007ISO 9735-3 z2002注I符号(FUI)(L)后缀_I后缀一R含义第一个或中间报文最后一个报文发起方应答方图B1对话状态图9GBT 148053-2007iso 9735-3：2002衰B2状态状 态 描 述IDLE 不存在联系且无未完成的应答STARTI 等待从应答方到发起方的“开始对话确认”DATAI 等待从应答方到发起方的“传送数据”DATAR 等待从发起方
7、到应答方的“传送数据”REPoRTI 等待从应答方到发起方的“报告状态”REPORTR 等待从发起方到应答方的“报告状态”STOP I 等待从应答方到发起方的“结束对话确认”CMPLI 等待从应答方到发起方的“完成对话确认”B33事件表B3列出了I-EDI协议的有效事件，并描述了与这些事件有关的条件。这些事件通常由通过协议操作者传送的数据对象或控制对象引发。表B3事件事 件 功 能 方 向SD_REo_i 开始对话请求 从发起方到应答方SD二CNF_R 开始对话确认 从应答方到发起方SDREJR 开始对话拒绝 从应答方到发起方TR。DATAI 传输数据 从发起方到应答方TRDATAR 传输数据
8、 从应答方到发起方EDLREO_I 结束对话请求 从发起方到应答方EI)-CNF_R 结束对话确认 从应答方到发起方ABORT_I 放弃对话 从发起方到应答方A130RTR 放弃对话 从应答方到发起方REQUEST_I 请求状态 从发起方到应答方REQUEST-R 请求状态 从应答方到发起方REP-ST_1 报告状态 从发起方到应答方REP Sr-R 报告状态 从应答方到发起方CD_REQ_1 完成对话请求 从发起方到应答方CI)-CNF-R 完成对话确认 从应答方到发起方衰B4状态一事件矩阵状 态事件)LE START I DATAI DATA R STOPI CPML I REPORT_I
9、 REPORTRSD_REqLI STARTjSr)_CNF_R DATA-RSD-REJR IDI。E IDLETRDATA_I(FU I) DATA_R裹B4(续)GBT 148053-2007ISO 9735-3：2002状 态事件IDLE sTART_I DATAI DATAR STOP-I CPML-I REPORT I REPORT-RTRDATAI(L) DATAJTR-DATAR(FU I) DATAITRDATAR(L) DATAREDREqLI STOPjEDCNFR IDLEABORT_I IDLE IDI。E。 IDLE 1DLEI IDLE IDLE 1DLEABoR
10、TR lDLE 1DLEI IDLE IDLE IDLEREQUEST_1 REPORT一】REQUEST-R REPOR，r-RREPSTI DATAR DATA IREPSTR DATA一1 DATARCr)-REqLI CMPL_ICDCNFR IDLE8 如果通信介质为半双工的，则不可能出现此状态一事件矩阵。1lGBT 148053-2007ffi0 9735-3：2002附录C(资料性附录)I-EDI过程模型C1卜EDI概述IEDI是在独立的参与方的应用之间为完成共同任务而进行的一系列的信息交换，其中后续的交换可能取决于先前交换的结果，通常有严格的时间限制。交互式应用包括民航订票系统
11、，保健药店、索赔提交和合格性审核，银行的远程自动柜员机。起初，I-EDI着重于发起方向应答方发送数据且应答方以应答的形式发回数据的应用。迄今为止，由发起方控制的交替的数据交换是交互式应用之间最通用的工作方式。但是，I-EDI语法并不排斥其他工作方式。I-EDI的定义取决于通用的EDI的定义。在本部分中所采用的EDI的方法是以ISOIECJTCl下设的EDI特别工作组编制的“关于开放式EDI概念模型的报告”为基础的。“开放式EDI概念模型”的特征包括：使超出贸易领域的EDI更加通用化I把EDI定义为“开放式”(适合于所有参与方，遵从标准，并不需要专门的双边协议)；协调EDI与通信、建模和开放环境
12、领域的其他国际标准的关系。EDI业务语境的两个主要因素促使I-EDI的开发很有必要。第一个因素是来自很多组织(不仅仅是民营部门)的市场压力，它们要求在市场上更具竞争性和更高的快速反应能力。因此，很多基本的过程必须被重新模型化，以对付这种压力。第二个因素是对标准解决方案的期望与当前情况(即“非开放式EDI”)有较大差异。在定义I-EDI需求中采用了下列指导原则：用户容易实施是第一位的，标准应相应地定义其要素，IEDI的机制应与EDI的其他形式完全兼容，在可能的情况下应完全相同；无论采用何种通信方法，都可得到所需的功能，只要在低层通信协议(如x25、OSI交易处理)中可得到等同的功能，都可以使用它
13、们；EDI标准应与所有其他相关的国际标准充分协调。为了独立于低层体系结构表示I-EDI的特征和需求，下面描述了业务和功能模型以及I-EDI服务段所需的信息内容。建议而非强制采用相关的ISO协议传送I-EDI数据。C2 I-EDI的业务需求使在两个或多个业务伙伴之间进行的单一的业务交易能够连贯一致地完成必须支持交互式的对话活动以及时的方式提供对大业务量信息的处理I为在业务伙伴之间安全地传递业务信息提供方法。C3支持业务需求的功能需求在业务交易中应能够：12GBT 148053-20071150 9735-3：2002使应用之间合作；进行多个双边对话；双边对话协调；进行分级双边对话在双边对话中进行
14、双向交换I-EDI报文；为在一秒钟内作出应答提供有效的机制；通过减少开销而支持大业务量交易应由通用的UNEDIFACT安全标准或其他标准提供安全。C4业务模型I-EDI对话既分离于又独立于在其他ISO文件中作为术语使用的对话。如图C1所示，剧本是为完成特定的业务目标而在各参与方之间发生的一组业务活动的形式规范。它建立了参与方之间的关系和相互作用的模型。圈C1类型和实例概貌交易是剧本的实例。当剧本中的角色被扮演以执行实际的业务交易时，交易便被建立。在这里刻画交易仅仅是为了明确对话的语境，。为了执行交易，参与业务交易的不同的参与方要使用该交易的I-EDI部分的对话进行双边通信。交易具有将对话成组的
15、潜能。但是，许多剧本可被模型化为在双方；af-1只包含单一的对话类型，其实例便是在两个参与方之间只包括单一对话的交易。在同一交易中可将对话成组，在同一对参与方或不同对的参与方之间可发生多个对话(见图C2)。GBT 148053-2007SO 9735-3 t2002C5功能模型功能模型见图C3所示。图C2业务交易示例圈C3通过对话实现的功能模型c6最小的通信需求通信必须：无差错按原来传输的顺序投递数据；允许双向的数据流；提供检测和报告丢失的逻辑联系I在应用之间提供稳定的逻辑联系(如会话、对话等)。因此每个I-EDI对话应有其自身的唯一的逻辑联系。如果不能满足这种需求，则实现者必须处理与分隔符和
16、字符集识别有关的问题。GBT 148053-2007ISO 9735-3：2002C7数据需求下列清单试图给出执行已命名的功能所需的数据清单。该清单曾用于建立服务段的模型，但是，在这里存在的一个功能不一定保证存在唯一的服务段，因为某些服务段执行多个功能。开始对话请求(UNA、UIB和可选的报文)分隔符；字符集；语法标识符对话参考业务交易参考剧本标识符I对话标识符I发送方标识符接收方标识符f日期和时间，重复指示符i测试指示符；安全信息。开始对话确认(，和可选的曩文)语法标识特I，对话参考4。业务交囊誉考I剧本标识狩，对话标识符，发送方标识符I接收方标识符日期和时间f重复指示符；测试指示符；应答信
17、息安全信息。发送数据(报文一UIH、查询或命令、UIT)报文标识符或类型报文参考对话参考；传送状态日期和时间l测试指示符。接收数据(报文一UIH、应答、UIT)报文标识符或类型；报文参考对话参考；传送状态；15GBT 1480532007ISO 9735-3：2002日期和时间；测试指示符。请求状态(UIR)对话参考；功能(一查询)；日期和时间。报告状态(UIR)对话参考功能(=报告)；原因代码；源于出错报文的其他信息；日期和时间。开始对话拒绝(uIR)对话参考；功能(一开始对话拒绝)；原因代码；源于出错对话的其他信息日期和时间。暂停对话(UIR)对话参考功能(一暂停)原因代码；日期和时间。继续对话(UIR)对话参考；功能(一继续)；日期和时间。放弃对话(UIR)对话参考f功能(一放弃对话)I原因代码；。源于出错报文的其他信息日期和时间。结束对话请求(可选的报文和UIZ)对话参考；已发送报文的控制计数；重复指示符。结束对话确认(可选的报文和UIZ)对话参考I已发送报文的控制计数。
