GB T 19256.6-2006 基于XML的电子商务.第6部分 业务过程规范模式.pdf

1、res 35. 240 L 67 GB 中华人民共不日国国家标准GB/T 19256.6-2006 基于XML的电子商务第6部分：业务过程规范模式Electronic business eXtensible Markup Language (ebXML）一Part 6 : Business process specificatin schema (UN/CEFACT: ebXML business process specification schema vl. 10, MOD) 2006-09-18发布中华人民共和国国家质量监督检验检查总局中国国家标准化管理委员会2007-03-01实施发布

2、GB/T 19256.6-2006 目次前言。，. 四引言，.,. . N 1 范围2 规范性引用文件，3 术语和定义.4 设计目标.3 4. 1 目的目标需求问题描述.,. 3 4. 2 ebXML BPSS与UMM之间的关系5 BPSS语言概述5. 1 BPSS的UML表示法 -. 6 5. 2 BPSS的XMLSchema表示法. . . 6 5.3 UMM业务过程交互模式-. 6 5 4 业务信号定义 . . . . . . . . . . . . . 7 5. 5 生成规则.,- . . . . . . . . . . . 7 5. 6 与CPP/CPA的关系- . . 7 5. 7

3、 与业务文档的关系.E . 7 5.8 与ebXML消息服务规范的关系. 7 5. 9 ebXML BPSS的主要概念，. 7 5. 10 如何使用ebXMLBPSS 5. 11 ebXML BPSS如何与其他ebXML规范一起使用. 9 5. 12 如何在设计阶段设计并重用协同和交易. . 10 5. 13 核心业务交易语义,. - . . 30 5. 14 运行阶段业务交易语义- . 34 5. 15 运行阶段的协同语义.385. 16 何处实施ebXMLBPSS .,- - 38 5. 17 BSJ互操作性指南., .,. . . . . . . . . . . . . . 38 5.

4、18 协同和交易的格式规范性规则E , 38 6 ebXML业务过程规范模式- . 39 6. 1 模式文档.钮， . 39 6. 2 BPSS的XML表示和UML表示的相互关系. . 69 6. 3 名称引用的范围.，.70 6. 4 业务过程规范XML文挡示例.E司717 业务信号结构，- - 71 7. 1 信号模式.，. . . . . . . 71 7. 2 接收确认信号模式，- . 75 7. 3 接受确认信号模式 - . 76 GB/T 19256.6-2006 7.4 异常信号模式. 77 8 EDI支持. . . . . . . . . . . . . . . . . . .

5、 . . . . . . . . . . . . . . . . . . . . . . . 79 9 生成规则.E. . . . . . . . 79 附录A（资料性附录）业务过程规范模式实例 . . 80 附录职资料性附录）XML 信号样例 86 Il GB/T 19256.6-2006 前言GB/T 19256基于XML的电子商务目前分为下列9个部分：一第1部分技术体系结构；第2部分协同规程轮廓与协议规范；第3部分：消息服务规范；第4部分：注册系统信息模型规范；一二第5部分注册服务规范；一第6部分z业务过程规范模式；一一一第7部分：业务过程构件设计规则；一一第8部分：报文设计规则；第9部

6、分z核心构件和业务信息实体规范。将来还可能增加新的部分。本部分为GB/T19256的第6部分。本部分修改采用联合国贸易使利与电子商务中心（UN/CEFACT）制定的基于XML的电子商务业务过程规范模式1.10版本。本部分与UN/CEFACT制定的基于XML的电子商务业务过程规范模式1.10版本的主要差异如下按照标准的格式对原文的一些章节做了适当的调整；按照ebXML系列标准的术语增加了属于本部分的术语。本部分的技术内容与UN/CEFACTBPSSl. 1的技术内容对应关系如下：一前言。引言。对应于BPSSl.1中的“3Introduction”和“4.2 Caveats and Assumpt

7、ions”。范围。对应于BPSSl.1中“5”和“5.9 1)业务协同”中的内容。规范性引用文件。对应于BPSSl.1中的“3Related Documents”。术语和定义。对应于UN/CEFACT和OASIS于2001年发布的ebXMLGlossary中的部分术语和定义。一一设计目标。对应于BPSSl.1中的气DesignObjectives”（除4.2 Caveats and Assumptions）。BPSS语言概述。对应于BPS弓1.I中的5Language Ovie飞，. ebXML业务过程规范模式。对应于BPSSl.1中的“6ebXML business process spec

8、ificat10n schema 本部分的附录A和附录B为资料性附录。本部分由中国标准化研究院提出。本部分由全国电子业务标准化技术委员会归口。本部分起草单位：中国标准化研究院、交通部水运所、中国国际电子商务中心、中科院软件所。本部分主要起草人：章建方、刘碧松、魏宏、胡涵景、刘颖、任冠华、孙文峰、陈煌。皿GB/T 19256.6-2006 51 言本部分定义了一种标准语言，通过把该语言应用于业务系统以便实现由业务交易组成的业务协同。本部分以先前的UN/CEFACT工作为基础，尤其参考了“UMM元模型Rl2”规范中定义的UMM元模型。本部分支持业务交易以及业务交易组成业务协同的规范。每个业务交易能

9、通过使用可用的标准模式之一来实现。UMM规范定义了这些模式。模式是不能执行的，它只规定应用到给定业务交易的消息交换（请求、响应和信号）类型。这是定义业务交易类别的一种方法。这些模式与电子商务交易的不同类别可能布潜在的关系。本部分描述了两个参与方之间的协同（二元协同），但暂不考虑多个业务伙伴的协同（多元协同）。本部分旨在规定业务协同的实施运行方面。建议生成ebXMLBPS（业务过程规范）的苔选方法是UMM。ebXMLBPSS本身并不定义业务文档结构。其目的是与现存的业务文档定义以及和UN/CEFACT核心构件规范定义的文档元模型联合进行工作。0. 1 内容概述本部分描述了BPSSO本部分以UML

10、形式描述了BP恼，并且给出了每个BPSS实例必须遵循的相应的XMLSchema (XML模式）。本部分首先介绍基本概念和语义，然后应用这些语义对模型的每个部分进行详细讨论。本部分接着先后采用UML形式和XML形式规定所有元素。0.2读者本部分的主要读者是ebXML的技术实施者。将使用UMM的人称为业务过程分析师，UMM方法定义了以面向业务人员为中心的过程。本部分的其他读者是业务过程定义工具的设计人员，他们需要将用户输入到工具中的内容转化为BPSS的XML表示。0.3 前提条件假设读者熟悉或了解下列技术a) 按照UMM中所定义的业务过程建模技术和原则，b) UML(Unified Modelin

11、g Language，统一建模语言）语法和语义，c) XML(Extensible Markup Language，可扩展置标语言）。N 基于XML的电子商务第6部分：业务过程规范模式1 范围本部分规定了描述电子商务业务过程规范的语言。本部分适用于电子商务领域。GB/T 19256.6-2006 本部分目前只支持二元协同，对于多元协同所涉及的概念还在试验中，暂时不予考虑。2 规范性引用文件下列文件中的条款通过GB/T19256的本部分的引用而成为本部分的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成的协议的各方研究是否可使用

12、这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。GB/T 7408一2005数据元和交换格式信息交换日期和时间表示法（！SO8601: 2002, IDT) GB/T 19256. 1 2003基于XML的电子商务第1部分z技术体系结构（UN/CEFACTOASIS: ebXML technical architecture specification vl. 0. 4,MOD) GB/T 19256. 2 2006 基于XML的电子商务第2部分：协同规程轮廓和协同规程协议(ISO/TS 15000 I : 2004, MOD) GB/T 19256. 3 2006 基于X

13、ML的电子商务第3部分3消息服务规范WhenSing # endWhmString # prnConditino St,ing # po1ConditionString 。bnineTmn,.olionString# bnineTmnaotion!DREF GUIDREF # iConmLeogl,BindingBook # timeToPerlon dumtion 13 GB/T 19256.6-2006 5. 12. 3. 1 业务交易的主要语义业务交易是两个业务伙伴之间贸易环节中的最小工作单元。一个业务交易由个请求业务活动、一个响应业务活动以及它们之间的一个或两个文档流所组成。业务交易还

14、可以支持一个或多个业务信号，这些业务信号决定了确认的用法和含义。业务交易中隐含着一个执行请求业务活动的请求角色和一个执行响应业务活动的响应角色。当该交易用于二元协同的业务交易活动中时，这些角色就明确了。没有必要把这些角色明确为诸如买方、卖方这样的角色。特别对于某些业务交易，如“CancelPurchaseOrder（取消订购单）”可以作为两个不同的业务交易活动用在同一个二元协同中。业务交易中总是存在一个请求文档流。业务交易规定了是否需要响应文档。业务交易的类型通常取决于合同或协议。只有一个请求业务活动的业务交易通常用作通知。业务动作（BusinessAction）作为一个抽象超类，具有请求业务

15、活动相响应业务活动共有的属性。由于该元素是抽象类，因此它并不在BPSS实例中出现。5. 12. 3. 2 语法示例下面给出了只具有一个请求文档流和一个响应文档流的简单业务交易定义。确认文档流的业务信号可以与每个文档流相关联。虽然没有明确规定这些确认信号，但是两个业务交易参数规定了是否需要这些信号。图10表示了业务交易中可能的文挡流和业务信号。请草接收确认信号请接曼确认信号响求应活应注意，根据W3C的XMLSchema规范中的持续时间类型来表示时间长度。例如，“PlD”表示周期为1天。5. 12. 3. 4 业务文档流的说明请求文档流和响应文档流包含了关于业务交易请求和响应的业务文档。文档流模型

16、如图11所示b业务文档有多种结构。而业务信号总是具有相同的结构，并且定义为ebXMLBPSS一部分。本部分没有直接对文档流建模，确切地说，它被间接地建模为由一个角色发送并由另一个角色接收的文档信封。文档信封总是与规定文档流的请求业务活动或响应业务活动相关联。16 GB/T 19256.6-2006 应对文档信封命名。对于请求活动，总是只有一个己命名的文档信封。对于响应活动，可以有零个、一个或多个相互独立的、已命名的文档信封。例如，用于订单交易的响应文档信封可以命名为PurchaseOrder Acceptance （接受订单）、PurchaseOrderDenial（拒绝订单）或Partial

17、PurchaseOrder Accep tance（部分接受订单）。然而，在实际执行订单交易时，仅发送一个已定义的响应。每个文档信封只携带一个主业务文挡。文档信封还可以有选择地携带与主业务文档相关的一个或多个附件。本质上，主业务文档及其附件作为ebXML消息服务的消息结构中的负载构成一个交易。条件表达式 oxprn,;onLaoguagStte汉白ponseBool 文档安全参数参见5.13. 5, 5. 12. 4 二元协同的描述用UM！，类图表示二元协同的元模型如图12所示。GB/T 19256.6-2006 19 GB/T 19256.6-2006 业务吏屠 .String narne!

18、D GJlD ，阴阳盯anyURJ isGuarnnteedlleliveryRequid:Boolean 5. 12. 4. 1 二元协同的主要语义二元合作pattemonyU阳timeToPerlomdwcotion inistingRolelDREF GUIDREf iinnColahmatio Boolean 。nomeSuing nametD GUJD beginWhen St,ing ptCm世lionString 业务主易活动 timeToPerlo mdurntion frntriRoe: S让ring frotriRolelDREF:GUlDREF busineTaction

19、 String businrnTrnnsaionOREF:GJlD iConourrentBoon isLegallyBinding:Booean 国12二元协同的UML类图二元协同总是在两个角色之间定义。一个角色发起该协同，也正是该角色发送第一个业务交易活动的第一个消息（即请求）。initiatingRoleIDREF属性把内部协同活动的角色与其父二元协同角色绑定在一起。即使直到运行阶段才知道该角色，仍然可以规定一个“逻辑”发起角色。此时，父二元协同的发起角色与内部二元协同的发起角色绑定在一起。即使两个二元协同中的角色名称相同，对于一个二元协同而言，角色的name!D（名称标识符）属性应具有

20、唯一性。这意味着两个二元协同没有相同的物理角色，但是可以共享“逻辑”角色。二元协同由一个或多个业务活动组成。这些业务活动总是在二元协同的两个角色之间进行。对每个活动而言，两个角色中的个角色被指定为initiatingRole（发起角色），另一个角色被指定为respondingRole（响应角色），而与谁发起该二元协同元关。业务活动可以是业务交易活动，也可以是协同活动。业务交易活动指业务交易的执行。业务交易可以与任意多个业务交易活动元素相关联。这意味着同一个业务交易可以由不同的二元协同中的多个业务交易活动来执行，也可以由相同二元协同中的多个业务交易活动来执行，有时还可以有相反角色。例如J取消订单

21、”业务交易可以由两个业务交易活动所使用，而这两个业务交易活动分别由各自的参与方执行。这意味着订单被接受后任意一个参与方都20 GB/T 19256.6-2006 可以使用同一个业务文挡交换来取消订单（在某一时间期限内）。协同活动指一个二元协同在另一个二元协同中的执行。相对于协同活动，二元协同是可重用的。同一个二元协同可以由不同二元协同中的多个协同活动所执行，也可以由同一个二元协同中的多个协同活动所执行。一个二元协同只能通过islnnerCn I la bora ti on布尔型属性来限定为一个“内部协间”。此时，该二元协同仅可以作为协同活动的一部分被发起，而不能由其自身发起。业务交易活动和协同

22、活动可以使用beginsWhen （何时开始） ends When （何时结束）, precondit10n （前提条件）和postCondition（后置条件）属性来定义业务规则。本部分并没有规定这些属性的特定语法，因而当前这些属性类型为字符串。由于这些表达式通常不能由ebXML基础设施来执行，因此在本部分当前版本中认为他们是一个文档。尤其是，它们不能用来规定编排协同的任何部分。在将来的BPSS版本中，这些表达式将与转移和伪状态一起发挥作用。何时开始和何时结束的语义指出，一旦属性表达式的值为真，则相应的业务活动就必须开始或结束。前提条件和后置条件指出，只有在相应的表达式为真时，对应的业务活动

23、才可以开始。当在一个二乒协同中执行另一个二元协同时，两个层次的角色间有隐含的关系。假设二元协同X通过协同活动Q正在执行元协同Y二元协同X有下列角色：客户和供应商。在协同活动Q中，假定客户为发起方，供应商为响应方。二元协同Y有下列角色z买方和卖方。二元协同Y还有一个业务交易活动，其中买方作为发起方，卖方作为响应方。因为客户和买方都是正在执行和已执行的二元协同中相关活动的发起方，所以此时客户和买方之间建立了一种角色关系。由于业务交易实际上是最小单元，因此通过业务交易活动的单个业务交易的执行实际上也是最小单元。如果在语义上任务不是最小单元，则可以将其切分成多个交易。例如，如果需要对一个请求规定多个部

24、分接受，则该请求应规定为二元协同中的一个交易，并且把这些部分接受规定为独立的交易。CPP/CPA规范允许参与方商定一个CPA来处理业务。CPA可以将自身与一个具体的二元协同相关联。因此，两个参与方之间执行的所有业务交易应该通过二元协同中的业务交易活动来引用。5. 12. 4. 2 语法示例下面给出了按上述定义的一个业务交易的简单二元协同。5. 12. 5 多元协同的描述图13给出了多元协同的元模型。22 O n 业务伙伴角色name String name!D GUID 0 n 执行.,me!DGUID mle5t,ing rnle!DREF GUIDREF 特事 e!DGUID # oIoi

25、tiation,Boolean 。fromBUioessStatelDREFGUIDREF# fromBUinessStateString o o I # toBuinessState Strig 。toBuinessStatelDREPGUIDREF# 二Transit10nfromBusinessState= Check Credit” toBus inessSta te二”CreditPayment”/ 23 GB/T 19256.6-2006 应注意角色值把对应的二元协同和多元协同相联接。5. 12. 6 编排的描述图14给出了编排的元模型。转莓，百画面百可顶百一1 . onintia

26、tionBnnln 广mBu叫te!DREFGUID町#fromBu,ine咽StateString #toBulnne.Ccllabncation,Boolean O 任意值当达到timeT oPedocm属性值时，汇合发生转移可以源于二元协同中的业务交易活动或协同活动，也可以源于多元协同中的二元协同。守卫能控制转移。守卫指的是发起转移的业务交易活动的状态。守卫值包括，ProtocolSuccess （协议成功人AnyProtocolFailure（任意协议失败）、RequestRecei ptFail ure （请求接收失败）、RequestAcceptanceFailure（请求接受失败

27、）、ResponseReceiptF ail ure（响应接收失败）、ResponseAcc叩tanceFailure（响应接受失败，SignalTimeOut（信号超时）、ResponseTimeOut（响应超时人Failure（失败）、BusinessSuccess （业务成功）、BusinessFailure（业务失败）和Success（成功）。转移还可以有个ConditionExpressi时l（条件表达式）元素。ConditionExpression元素有一个expressionLanguage（表达式语言）属性，该属性规定了判定条件所采用的语言。本部分并不限制BS！可以支持的语言的

28、类型和数量。然而，为了致性，BS！要求至少支持Xpath语言和DocumentEnvelopeNotation（文档信封符号）。在当前二元协同实例中，Xpath表达式可以包括在转移之前所接收的任意文档信封的内容。DocumentEnvelopeNotation简单定义为文档信封的名称或ID,Success或Failure元素表示了一个状态和到该状态的转移的聚合。象通常的转移一样，该转移可以由condi tionGuard （条件守J1.）来守卫。通过最后的业务交易活动响应的业务文档类型或响应的内容，conditionGuard指出二元协同以成功状态或失败状态结束。需要注意的是，协同的成功或失败

29、并不会影响组成二元协同的单个业务交易活动的成功或失败。尤其是，当该协同以一个特定状态结束时，承诺的本质并不改变。协同的成功或失败确切地说是一个指示口J以被报告或遵照该指示来发起其他的协同。如果在协同中规定了几个完成状态，一旦达到其中一个完成状态，则业务协同运行实例的状态就此“结束”。设计者的责任是确保所有的完成状态相互独立，并且一旦达到其中某个状态，就没有进一步的业务活动。在这种情况下，应由BS！生成超时异常。转移也可以用来创建嵌套的业务交易活动CBTAJ。当转移从父BTA到嵌套的BTA，并且该转移的onlnitiation标记为“true”时，则嵌套的BTA可以进行。在这种情况下，只要接收到

30、父交易中的请求，转移就可以进行，而无须等到该请求被适当（如果有）确认后再进行。此时，第二个活动在响应返回25 GB/T 19256.6-2006 给初始请求者之前执行。本部分没有规定“返回”转移。如果要执行多个交易.IJ!必须在一个协同活动中进行规定。只有嵌套的活动与个异常相关联时，流出转移才能出现。如果活动正常终止，则控制线程传回给父活动。转移中的标i己“onlnitiation”正是用于此目的。嵌套的业务交易活动经常出现在多元协同中。从本质上讲，一个二元协同中的一个角色收到请求后，便转变为另一个二元协同中的请求者，然后再返回到第一个二元协同中并以响应者的身份返回响应。lsConcurren

31、t（是否可以同时发生）是控制交易流的参数。该参数与安全和计时参数不同，它并不控制交易的内部流而是决定任意两个伙伴间执行的协同实例中的多个业务交易活动实例在运行阶段是否可以同时发生。因此，当isConcurrent设置为false时，每个参与方的B.il负责排列这些业务交易活动。512.6.2语法示11J下面是前面用过的一个二元协间，只不过在其结尾处增加了一个编排。在该协同的一个开始和两个可能的结果成功或失败）之间存在一个转移。saction!DREF=”122A39CA4fromRole= seller fromRole!DREF=”122A38DA3 toRole=”buyer toRole

32、!DREF二”122A380A3”isConcurrent二”trueisLegallyBinding=”false GB/T 19256. 6-2006 t1meT0Perform”P20” 应注意，该二元协同的所有完成状态都是相互独立的。带条件表达式的转移还I可以用XPath判定条件来表示。27 GB/T 19256.6-2006 类似地，转移可以在一个多元协同中的不同业务活动之间定义。e O/ Rn ro e- 卫时1r r a0 3b dh sl eo nC EVJ ut nu田/DA initiation,Boolean # fromBuine,StatelDRffGUIDREF e

33、仕omBuininmState!DREF GUIDREF # ocnditionG=d NM下OKEN主坐坐坐旦旦旦开始。toBuineSta能Stting# toBu,in,JDREF GUIDREF 主盛盐查# oonditionCuatd NMTOKEN # from Bu,inmSta能String#fro nBu,inmStatelDREF GUIDREF 业务主品 namg #namemGUID #pattern YURI # GWrnntoedDeliveRequinod BoolOn # attlntelligib1ChkRequited8oolean # iAuthctial

34、tonRequited,Boole 立档安圭#name String 。mimeTypeString# name ID GUID # timeToAeknowledgeReeeiptdurntioo # iNonRepodiationRequited.Beolean 。iNonRepudiationofReceiptR叫uitedBoolean # timeToAeknuwl国geAeeeptanee.durntion#attribute String 业务主档#name String # namelDGUID # buvine,illocumentS!ting 。peei臼tionLocal

35、tonnyURI# vpecifiealtonIDyURI # bimvnocumentlDREF GUIDREF # peeificationanyURI # nampacePtefix国NMTOKENS# atttibute Siting 。”meToPerlonndurntion# iConeurrentBooloan 。iLegallyBindingBooloan# bu,ine,TrnmaetionJDREF GUIDREF # buSTamperProof xsd, NMTOKEN 文档实体相关的数字签名（发送者的数字证书和加密的消息摘要）（参见文档安全章节）40 GB/T 192

36、56.6-2006 源代码I 6. 1. 2 AttributeSubs“tution元素图！？吧川命名空间http, I/ www. untmg. org/ downloads/General/ approved/BPSS v I pt! 0. xsd 说明规定应使用个属性值来代替现有的过程规范中的某些属性值于元素Documentation 用于SubstitutionSet元素名称类型用法缺省值备注属性attributeName xsd, string 必备型被替代元素的属性名称value xsd, stnng 必备型替代该属性当前值的值二xod,sequence 41 GB/T 1925

37、6.6-2006 6. 1. 3 BinaryCollaboration元素图命名空间说明于元章用于属性42 工旦旦立工L段广.，Documo凶；占7飞I ；句，,. I .，4r，代咱机非商l。回, E - Bu,;n,Trn ty , 守V也川.咔j旷7;,LllyB;nd;ng ;, be;ng dopnckd CollabnrnhonA,t;v;ty 一叶飞、何， Ff http,/ /www. untmg org/downloads/General/approvediBPSS vlpt!O. xsd 定义两个角色之间交互的协议。个角色必须是发起角色，另一个角色必须是响应角色。二元协同

38、是协同角色之间状态的编排集合。执行业务交易的活动或执行其他协同的活动都是一种状态。二元协同编排两个角色之间的个或多个业务交易活动。二元协同不是最小的交易。二元协同通过协同活动可以用于另一个二元协同中Documentation Role Start Busine I ransactionActivity CollaborationActivity Succe5 Failure T rans;uon Fork Join Decision Package ProcessSpecification元素名称类型na1e d, stnng name ID GUID pattern xsd,anyURI b

39、egins When xsd, stnng ends When xsd,stnng 用法缺省值必备型备注定义附件的名称名称的GUID表示可选引用二元协同所基于的模式通常引起协同开始的外部事件的描述通常引起协同结束的外部事件的描述属性源代码p;eCnndiuon Xd, stnng pcstConditton Xd. nng time T oPecfo;m xed, durnton tmtiattngRole!DREF I GUIDREF 可选型rnlnne;ollaborntion I Xd boolean 二xsd,choice maxOccud,choice d,elernent ref”

40、Traniuon minOccurs”。”maxOccurs”unbounded”xsdelement refDecision”minOccurs ”。”maxOccurs”unbounded”d,attribute name begins When type”xod, string I dattnbute name -”ends When“type xod, string”/tnng cbtring”d attnbute name”time lolerform type xsd. duration”/二Xrl,attribute oam町”initiatingRolclDREFtype ”

41、GUIDId, rnmplex I ype 43 GB/T 19256.6-2006 6. 1. 4 BinaryCollaboration/Role元素图I Roe Fll-J旦一了I耳pe一产一Documenta：但n一：L一一一一一一一一一命名空间http,/www.untmg.org/downloads/General/apprnved/BPSS vlpt!O. xsd 类型Role Type 说明规定二元协同的角色名称子元素Documentation 名称类型用法备注name xsd, string 必备型角色的名称属性与角色关联的GUID.应注意无论二元协name ID GUID

42、必备型同是否使用了相同的角色名称，所有二元协同的name!D必须是唯一的源代码rion和specifcation!D两者使用其中一个如果适用的话规定引用系列由模式所使用的Namespace元素 S10n mmOccucs”。”GB/T 19256.6-2006 源代码I 三乌兰正k旦旦i主6. 1. 6 BusinessPartnerRole元素 ”：，币品，i飞.t函了，亏了。吧i电i飞飞+ 。，图I字号三日十云是乏善飞币r：；，可椅卜！命名空间http,/ /www.untmg.org/downloads/General/approved/BPSS-vlptlO. xsd 业务伙伴角色是由

43、多元协同中的业务伙伴所扮演的角色。业务伙伴角色在构成多元协同的每个二元说明协同中最多扮演个角色。规范性规则参与万一定不能在一个给定的业务活动中扮演两个角色子元素Documentation Performs Transition 用于MultiPartyCollaboration元素名称类型用法缺省值备注定义整个多元业务协同中参与属性name xsd,stnng 必备型方所扮演角色的名称，如，害户或供应商name ID xsd Jl) 名称的GUID表示注释Documentation暂不于以考虑on 源代码ition rninOccurs”。”maxOccursunbounded/ 45 GB/

44、T 19256.6-2006 6. 1. 7 BusinessTransaction元素广：；，丰，D巾00叫，；lat巾 -I 0. co 图 pondingBu引Activity性l且，u飞F- _, 吨.U咱J命名空间http,/ !www. untmg. org/download,/Genernl/apprnved/BPSS-v 1 ptlO. xd 业务交易是在两个商业伙伴之间，以商定的格式、顺序和时间间稿发生的业务信息和业务信号交换的说明集合。如果违反了这些协议，则交易终止，并且放弃所有的业务信息相业务信号交换。业务交易在形成在线发盘受盘商业合同时可以是正式的，在发布产品声明时可以是非正式的。业务交易可以由多个业务交易活动来执行。业务交易有个请求业务活动和个响应业务活动于元素Documentation RequestingBusine5Activity RespondmgBusinessActivity 用于Pack