怎样使用ebXML业务过程规范模式

时间：2023-10-16 百科知识版权反馈

【摘要】：实施业务合作的ebXML一致性软件应使用ebXML业务过程规范模式。如图6-25所示，在业务过程规范和ebXML核心组件规范的交叉处定义业务文件。业务过程规范和文件规范的结合成为贸易各方相互间开展电子业务达成协议的基础。另外一些业务交易如通知，则仅需要请求文件流。而业务信号总是具有相同的结构，可以作为ebXML业务过程规范体系的一部分。文件及其附件本质上构成了ebXML消息服务结构中有效负载的一个交易。

6.3.3　怎样使用ebXM L业务过程规范模式

实施业务合作的ebXML一致性软件应使用ebXML业务过程规范模式。这种软件的通用术语是业务服务接口(BSI)。ebXML业务过程规范模式用于规定配置BSI实施合作的相关设置参数的业务过程。

1.ebXM L业务过程规范模式如何与其他ebXM L规范相互应用

ebXML业务过程规范模式提供了定义业务合作所需的语义、元素和属性。合作包含一系列的角色，通过交换业务文件的一系列编排好的交易进行合作。如图6-25所示，在业务过程规范和ebXML核心组件规范的交叉处定义业务文件。业务过程规范将引用而不是定义一系列所需的业务文件。在ebXML中，业务文件可以由一些外部文件规范来定义，直接或间接地从较低层的信息结构即核心组件内集合而成。集成基于语境，其中有许多是由业务过程提供的，如在文件流中使用文件的合作。业务过程规范和文件规范的结合成为贸易各方相互间开展电子业务达成协议的基础。

图6-25　ebXML业务过程规范模式和其他ebXML规范

如图6-25所示，用户可以从现有的业务过程和信息模式中析取和转换必要的信息，相关的生成规则将有助于生成业务过程规范的XML版本。此外，用户也可以用基于XML的工具直接生成XML版本。生成规则可以辅助转换生成XML，因此，如果需要，可以载入到UML工具中。

在任何一种情况下，业务过程规范的XML版本都可以存储在ebXML数据库中，并且在ebXML中注册以便将来检索。业务过程规范可以用设计过程中产生的分类来注册。

当参与方想建立贸易伙伴CPP和CPA的业务过程规范的XML文件或相关部分时，可简单嵌入或者引用CPP和CPA的XML文件。ebXMLCPP和CPA文件可以只引用ebXML业务过程规范和它的XML版本。

在CPP和CPA规范的指导下生成的XML文件，成为一个或多个业务服务接口(实际管理合作中任一参与方软件)的配置文件。

2.怎样在设计阶段进行设计合作、交易和重用

这一部分通过建立一个完整的从下到上的多方合作描述了ebXML业务过程规范模式的建模关系。

(1)定义一个业务交易。

(2)定义业务交易的业务文件流。

(3)定义重用业务交易的两方合作。

(4)定义两方合作的编排。

(5)定义重用较低层级两方合作的较高层级的两方合作。

(6)定义重用两方合作的多方合作

3.设计业务交易及其业务文件流

图6-26是说明一个业务交易的UML类图。

业务交易是两个业务伙伴之间的贸易协定的基本单元。业务交易由请求业务活动、应答业务活动和它们之间的一个或两个文件流组成。业务交易可被另外一个或多个业务信号所支持，这些业务信号控制交易中的确认和相关事宜的使用和含义。

交易中隐含着请求业务活动的请求角色和应答业务活动的应答角色。当在两方合作的业务交易活动中使用交易时，这些角色就变得明确了。存在一个请求文件流，是否需要应答文件是业务交易定义的一部分。某些业务交易需要请求和应答这种模式，典型的例子是合同和协定的形成。另外一些业务交易如通知，则仅需要请求文件流。请求业务活动和应答业务活动共有的属性为高层类业务行动服务。下面是只有一个文件流的简单通知交易示例。

图6-26　一个业务交易的UML类图

＜BusinessTransaction name="Notify of advanceshipment"＞

＜RequestingBusinessActivity name=""＞

＜DocumentEnvelope

BusinessDocument name="ASN"/＞

＜/RequestingBusinessActivity＞

＜RespondingBusinessActivity name=""

＜/RespondingBusinessActivity＞

＜/BusinessTransaction＞

业务交易内可能的文件流和业务信号如图6-27所示。

图6-27　可能的文件流和信号及它们的序列

这些确认信号是指示业务交易当前状态的应用层文件。

接收确认和(或)接受确认信号是业务交易规定模式的必备部分。这些业务信号有具体的业务目的，与评价其业务条款之前的文件和文件封装的处理和管理相关，并从低层协议和传输信号中分离出来。

如果使用接收确认业务信号，表明消息已被接收。识别时，使用isIntelligibleCheckRequired特性。参与方认可接收确认的消息表示它通过了结构或者模式的有效性验证。在消息的业务文件或文件包封装中，对接收和消息的可识别(如果评估)的检查应先于应用任何业务规则的应用、条款评估和防护。

如果使用了接受确认业务信号，表明收到的消息被接受进行业务处理。消息的业务文件和文件封装的内容通过了业务规则有效性验证。

下面是一个稍微复杂点儿的交易示例，它包含两个文件流和三个业务信号。

请求需要接收和接受确认，应答仅需要接收确认。“P2D”是一个采用ISO8601标准的W3C模式语义，表示期限为2天。P3D表示期限为3天，P5D表示期限为5天。

这些期限都从源发送请求计算。＜BusinessTransaction name="Create Order"＞

＜RequestingBusinessActivity name=""

isNonRepudiationR equired="true"

timeToAcknowledgeReceipt="P2D"

timeToAcknowledgeAcceptance="P3D"＞

＜DocumentEnvelope BusinessDocument="Purchase Order"/＞

＜/RequestingBusinessActivity＞

＜RespondingBusinessActivity name=""

isNonRepudiationRequired="true"

timeToAcknowledgeReceipt="P5D"＞

＜DocumentEnvelope isPositiveResponse="true"

BusinessDocument="PO Acknowledgement"/＞

＜/DocumentEnvelope＞

＜/RespondingBusinessActivity＞

＜/BusinessTransaction＞

请求文件流和应答文件流包含有关业务交易的业务文件。如图6-28所示。业务文件具有变化的结构。而业务信号总是具有相同的结构，可以作为ebXML业务过程规范体系的一部分。

文件流不是直接模型化的，而是由一角色发送、另一方接收的文件封装，间接地模型化。文件封装总是与一个请求业务活动和一个应答业务活动建模的文件流有关。

对于一个请求活动，仅有一个已命名的文件封装。对于一个应答活动，可有零个、一个或多个独立已命名的文件封装。例如，订单交易的应答文件封装可被命名为订单接收、订单拒绝和订单部分接受。然而，在订单交易实际执行时，仅发送这些规定的应答之一。

文件封装表示了活动之间的文件流。每一个文件封装只携带一个主业务文件。文件封装可以有选择地携带和主业务文件相关的一个或多个附件。文件及其附件本质上构成了ebXML消息服务结构中有效负载的一个交易。

下面给出了具有请求和成功及失败两个可能的应答的业务交易示例。请求有一个附件。模式名称、适用于所有业务文件。

＜BusinessDocument name=" Purchase Order"

specificationLocation=" someplace"/＞

＜BusinessDocument name=" PO Acknowledgement"

图6-28　文件流的UML图

specificationLocation=" someplace"/＞

＜BusinessDocument name=" PO Rejection"

specificationLocation=" someplace"/＞

＜BusinessDocument name=" Delivery Instructions"

specificationLocation=" someplace"/＞

＜BusinessTransaction name=" Create Order"＞

＜RequestingBusinessActivity name=""

＜DocumentEnvelope isPositiveResponse=" true"

BusinessDocument=" ebXML1.0/PO Acknowledgement"＞

＜Attachmentname=" DeliveryNotes"

mimeType=" XML"

BusinessDocument=" ebXML1.0/Delivery Instructions"

specification="

isConfidential=" true"

isTamperProof=" true"

isAuthenticated=" rue"＞

＜/Attachment＞

＜/DocumentEnvelope＞

＜/RequestingBusinessActivity＞

＜RespondingBusinessActivity name=""

＜DocumentEnvelope

BusinessDocument=" ebXML1.0/POAcknowledgement"/＞

＜/DocumentEnvelope＞

＜DocumentEnvelope isPositiveResponse=" false"

BusinessDocument=" ebXML1.0/PO Rejection"/＞

＜/DocumentEnvelope＞

＜/RespondingBusinessActivity＞

＜/BusinessTransaction＞

图6-29所示是两个角色之间的合作。这两个角色被称为已认可的角色，因为它表示合作中已认可参与的角色。

两方合作由一个或多个业务活动组成。这些业务活动总是在两方合作的两个已认可的角色之间进行。对于每一项活动，两个角色中的一个被指定为发起方，另一方则为应答方。

业务活动可能是业务交易活动，也可能是合作活动。

业务交易活动是业务交易的体现。与业务交易活动有关，业务交易是可重用的。相同的业务交易可以被不同两方合作中的多个业务交易活动来执行，甚至可以被同一个两方合作中的多个业务交易活动来执行。

合作活动是两方合作的体现，也可能存在于另一个两方合作中。与合作活动有关的两方合作可以重用。相同的两方合作可由不同的两方合作中的多个合作活动执行，甚至是相同两方合作中多个合作活动执行。

在进行两方合作时，两个层级的角色之间有隐含关系。假设两方合作X正在通过合作活动Q实施两方合作Y。两方合作X已认可的角色为顾客和零售商。在合作活动Q中，我们指定顾客是发起方，零售商是应答方。两方合作X认可角色买方、卖方及一个交易活动，在这个交易活动中买方是发起方，卖方是答方。现在我们在顾客和买方之间建立起角色关系，因为它们在已经进行和正在进行的两方合作的活动中都是发起方。

图6-29　两方合作的UML图

通过电子业务交易活动进行的单个业务交易在本质上是最基本的。如果所需要的语义不是基本的，那么任务应该被分成多个交易。例如，如果需要多个部分的请求接受建模，那么请求应被建为两方合作的一个交易模型，和作为单独交易的部分接受。

CPA/CPP规范要求各方为了处理交易达成CPA。CPA本身与具体的两方合作相关。因此，两方之间进行所有业务交易应被包含在两方合作中的业务交易活动引用。

下面是使用前面所定义的某个业务交易的简单的两方合作示例:

＜BinaryCollaboration name="Firm Order" timeToPerform="P2D"＞

＜Documentation＞

timeToPerform=

Period: 2 days from start of transaction

＜/Documentation＞

＜InitiatingRole name="buyer"/＞

＜RespondingRole name="seller"/＞

＜BusinessTransactionActivity name="Create Order"

businessTransaction="Create Order"

fromAuthorizedRole="buyer"

toAuthorizedRole="seller"/＞

＜/BinaryCollaboration＞

图6-30是一个多方合作的UML图。

多方合作是两方合作的组合。多方合作由许多业务伙伴的角色组成。每个业务伙伴角色在一个两方合作或者多个两方合作中扮演一个认可的角色，通过使用相关元素来建模。业务伙伴角色和已认可的角色之间的连接是两方合作成为多方合作的合成体。多方合作隐含着业务伙伴角色作为认可角色的所有双方合作。每对贸易伙伴遵循一个或多个明确的CPAs。

在多方合作中，可以编排不同的两方合作中业务交易活动的转换。图6-31说明了一个编排。

编排是两方合作中的业务活动的排序。编排根据业务状态及业务状态之间的转换来确定。业务活动是一种抽象的业务状态，业务交易活动和合作活动是具体的业务状态。编排的目的是将两方合作或者多方合作中两方合作的业务交易活动和合作活动有序化。

业务状态有许多辅助种类，便于业务活动的编排。包括开始状态、完成状态(产生成功和失败)、分叉状态和同步状态。与UML活动图相同。

转换存在于在业务状态之间，由防护来控制。防护指引起转换作用的文件封装的状态、被发送文件的类型、文件的内容以及前一个状态的后续状况。

转换也可用在生成嵌套的业务交易活动中。嵌套的业务交易活动是第一个转换发生在第一个交易的请求接收后，第二个完整的交易发生在返回到第一个交易并将应答发送回给原始的请求方之前。转换中的标识“onInitiation”就是用于这个目的。嵌套的业务交易活动通常存在于多方合作中。本质上，两方合作中认可的角色收到一个请求，然后在第一个两方合作返回并在发送应答之前转到另一个两方合作，并成为它的请求方。

图6-30　一个多方合作的UML图

isConcurrent是控制交易流的参数，不同于安全和时间参数。它不能控制交易的内部流，而是决定交易类型的多个实例可否作为相同业务交易活动部分而同时打开。IsConcurrent是控制它的参数，处于业务交易活动的层级之中。

图6-31　序列的UML类图

图6-32用UML类图集中地展现了前面的语义，包含了ebXML业务过程规范模式的整个UML版本。

4.主要业务交易语义

业务交易的ebXML语义是可预先定义和实施的。任何业务服务接口(BSI)都可以按照这些语义来管理交易。

ebXML业务交易语义为拟订的电子业务交易提供了:

(1)相互可预定，即有明确的角色，明确的交易范围，明确的时间限定，明确的业务信息语义，明确的成功或失败的确定。

图6-32　UML类图表示的ebXML业务过程规范模式

(2)生成具有法律约束力合同的能力，即规范业务交易能够一致约束合作双方的能力。

(3)抗抵赖性，即规范人为的设置以维护和支持法律强制性。

(4)鉴别的安全性，即用来规定参与方履行角色所需要的鉴别。

(5)文件的安全性，即用来规定认可的、已鉴别的、机密性的、不可篡改的。

(6)可靠性，即规定业务文件和信号可靠传输的能力。

(7)运行时间阶段业务交易语义，即业务服务接口软件预定和执行ebXML业务交易所需的规则和配置参数。

主要的业务交易语义的图解如图6-33所示。

图6-33　主要的业务交易语义的图解

在ebXML模式中，业务交易有以下语义:

(1)业务交易是工作单元。业务交易的所有交互行动必须成功，或这个业务交易在交易初始前必须被返回到已定义的状态。

(2)业务交易是交易中两个业务伙伴角色之间进行的。通常包括请求角色和应答角色。

(3)业务交易定义规定了何时控制请求活动、何时控制应答活动，何时控制从一个活动到另一个活动的转换。在所有的交易中，控制从请求活动开始，然后转换到应答活动，最后返回到请求活动。

(4)交易总是从请求活动发送的请求开始。

(5)请求控制转换应答角色。

(6)接收请求文件流后，应答活动发送接收确认信号或者发送接受确认信号给请求角色。

(7)应答方进入应答活动。应答活动完成时，将发送一个或零个应答。

(8)如果需要接收确认、接受确认或应答，控制会返回到请求活动。接收确认(必要时)总发生在接受确认之前，接受确认总发生在应答之前。控制将返回到基于上述情况的最后需要的请求活动。如果没有需求，控制将不超出应答活动范围。

(9)交易的成功或失败取决于:

a.请求、应答和(或)业务信号接收与否;

b.发生超时;

c.发生业务异常;

d.发生控制异常;

e.接收的应答和防护表示转换解释的成功与否。

(10)交易成功或失败的确定是请求方基于对上述成功或失败的因素而建立的。一旦确定了成功或失败，与交易双方相关的业务交易就结束了。

(11)一旦接收到应答，请求活动就给应答角色发回一个接收确认信号。这仅是一个信号，并不使控制回到应答活动，也不改变业务交易的成败，交易成败是以接收应答为基础的。

(12)一旦确认交易处理超时或者异常，并且相应地结束交易，请求方就给应答方发送一个失败通知。这被认为是一个新的交易，但不改变已经建立的业务交易的结论。

业务交易规范规定请求文件是否需要应答的实体文件，从而完成“成功”结束的状态。另外，交易为完成时限规定了一个恰当的非零时间长度，规定了应答的时间底限。

此外，业务交易规范应指明，接收确认和接受确认请求是必备的，应答的接收确认是必备的。

必备的接收确认方法是为接收确认时间参数设置任何非零时限。如果这个参数被设置为恰当的非零时限，则isIntelligibleCheckRequired和NonrepudiationOfReceiptRequired参数或二者之一被设置为“yes”。

必备的接受确认的方法是为timeToAcknowledgeAcceptance设置一个合适的非零时限。

如果未接收到信号和交易超时的值，这两个确认参数用于决定是否需要把信号作为交易一部分的布尔值。

交易规范需要的上述信号与其他信号无关。不需要的信号，实际上就是被禁止的。因此存在组合的限定集。UMM为实际重用提供了表示这些组合的解释性的模式集。

贸易伙伴希望作为ebXML的一部分完成的交易有约束力。约束的关键是建立与亲笔签名具有同等法律效力的电子消息。用户之间可采用ebXML业务过程规范模式标准，或使用约定的标准(“isLegallyBinding”)。

在早期的电子应用中，贸易伙伴已经简单地采用了电子签名(例如以XML-DSIG为基础的标准)。然而，如果所谓的合同只不过是草案或者没有约束力，则仅仅依赖有签名的文件可能会被不正确地解释。

在ebXML中，电子签名的存在与否不能决定法律约束，因为XML-DSIG签名也用于其他用途，如可用于发送者身份和消息完整性验证。

IsLegallyBinding是交易活动层级的一个参数，它表示两方合作中的交易的完成是否具有法律约束。

在这个标准下运行时，用户间通过交换约定术语的约束性消息(例如offer和acceptance)形成约束协定。

参数“isLegallyBinding”是一个布尔值，缺省值是“true”。根据这个标准，业务活动不具有法律约束的唯一方法就是将这个交易活动的“isLegallyBinding”参数设定为“false”。就像在EDI中，ebXML标准假定交易与贸易参与方是约定的，除非有其他说明。

作为非标准的情况，参与方进行一些没有法律约束的交易，可能出于许多原因，例如测试，或者为了找到可能的共同遵循的术语集而在没有约束的基础上进行出价和还价之间的交换。当使用有形的签名文件时，交易各方通常通过拒绝亲笔签名或者是盖一个“草案”(DRAFT)戳记来达到使交易没有法律约束的目的。在ebXML中，贸易伙伴可通过使用“isLegallyBinding”参数来表示这个结果。

1)抗抵赖性

贸易伙伴希望在ebXML上进行具有法律保证的业务交易。一方可以选择使用抗抵赖性协议，以便产生法庭上有助于合同规定义务强制执行的文件，以免对方以后试图抵赖它的ebXML业务文件和消息。

抵赖一般是指贸易伙伴基于对交易中人为因素的坚持，在事后协商与交易中的不符辩解。理由可能是形成协定时回复文件没有发送，或者是没有被正确地发送，或者错误解释(根据适用的标准或者合作伙伴的业务规则)等。

可以采用两种抗抵赖协议。每个协议在一定程度上通过生成或申请一些附加人工设置来解决以后可能发生的抵赖问题，为用户提供附加的证据保证。但这些协议都不是绝对安全的。就像纸面交易中，生意伙伴总可以随意捏造一些新借口，而忽视明确可执行的陈述。这些参数只不过使抵赖更困难一些。

其中一个协议赋予了交易各方保存组成交易的所有业务文件和文件封装的备份责任，各方都是站在自己的角度，即请求方保存它的请求，应答方保存它的应答。这就是请求或者应答活动中的IsNonRepudiationRequired参数。在逻辑上它等同于请求，交易的另一方可保留这个参数作为核对线索。然而，不符合的请求不一定在运行时检测到，它也不能确定成功或失败的结束状态。

另一个协议要求应答方发送收据的签名复印件，然后请求方保存此复印件。它是请求业务活动的isNonRepudiationOfReceiptRequired参数。

接收的抗抵赖性是受接收确认约束的，因为它要求后者是数字签名。因此，如果没有要求接收确认，接收的抗抵赖性就没有意义，不符合接收抗抵赖性在运行时可被检测到的规则，并且不决定失败结束状态。如果距确认接收的时间用于请求消息中，接收的抗抵赖是true，那么只有数字签名接收满足规定的超时底限。因此，在距确认接收的时间内发送签名接收失败将使交易无效。

2)鉴别安全性

每个请求或应答可由与贸易伙伴有关的人、代表或者是自动系统发送。在某些情况下，贸易伙伴可能不止一个具有ebXML能力的业务服务接口，代表不同水平的权限。在这样的情况下，对企业而言，合作各方可以制订一些规则以确定可以信赖的接口。

为了调用那些规则，参与方可在请求或者应答活动中要求授权。这样做的结果是，只有当成功解释的参与方使活动的鉴别角色的身份与以前提供的许可值的列表匹配时，活动才被处理为有效。

IsAuthorizationRequired相应地在请求活动或应答活动中规定。

3)文件安全性

在同一消息中每个业务文件都传输下列安全特性，可被单独规定，或者集合到文件封装中进行定义:

文件封装中的isConfidential、isTamperProof、isAuthenticated的值适用于主要业务文件，它同样也适用于每个附件(除非在附件层的定义无效)。

把这些参数设置为YES(或TRUE)时，假定用持续的方式提供相应的安全特性。一致性要求文件定义的特性在业务服务的地方接收，并持续到文件完成或者持续到文件发送。

4)可靠性

业务交易层的参数表明是否需要交易的业务文件可靠传送。

需要指出的是，贸易伙伴必须使用唯一一个提供第三方传输保证的传输信道，在相关的交易中发送业务文件。

5) CPP/CPA所需参数

ebXML业务过程规范模式提供了用于定义层级的安全性和可靠性。ebXML业务过程规范模式在业务条款中提供了这些参数。这些参数是业务过程的基本需求，但对于实施ebXML，这些参数被专用于指示CPP和CPA来要求BSI，或者传输信道能力来完成规定的服务层。

CPP和CPA把这些转换成两种参数。一种参数用于确定适宜的安全性和可靠性参数的选择。安全性和可靠性参数适用于传输信道选择的决定性因素。另一种参数用来确定适宜服务层的选择或BSI本身的能力，以支持如下所列的运行时间阶段的业务交易语义。

5.运行时间阶段业务交易语义

业务交易的ebXML概念及其语义是预定义和实施业务的关键，根据这些语义，任何业务服务接口(BSI)都有能力管理交易。因此，BSI或者在ebXML合作中实现某一角色功能的任一软件至少支持下面的交易语义:

(1)交易开始的检测。

(2)控制转换的检测。

(3)交易成功完成的检测:确定成功的isPositiveResponse和转换ConditionGuard的业务规则的应用。

(4)交易失败的检测:

a.超时检测;

b.异常检测;

c.确定失败的isPositiveResponse和转换ConditionGuard的业务规则的应用。

(5)失败通知。

(6)失败通知的接收。

(7)失败后的回滚。

ebXML不规定这些交易语义是如何实施的，但是假定任何BSI都有能力在运行时间阶段支持这些基本的交易语义。下面讨论失败的两个原因:超时和异常。当其中任意一种现象发生时，两角色都有责任回滚，并退出交易。一般而言，如果失败发生在应答方，应答方将向请求方发送异常信号，而且两方将退出当前交易。如果失败发生在请求方，请求方将退出当前交易，并在一个独立的交易中向应答方提示失败。

1)超时

既然所有的业务交易都必须有明确的时间限制，那么就有与应答和每个确认信号相关的超时参数。如果超时发生在相应的应答或者是信号到达之前，那么交易为无效。只要请求合作者希望取得对业务文件请求的一个或多个应答，必须规定超时参数。请求合作者不必停留在无限等待的状态。

每一个超时参数的超时值都是绝对的，与其他参数无关。所有的定时器在起始请求业务文件被发送时开始启动。定时器的值必须符合定时器值的良构规则。

BSI需要遵从上面的参数来检测超时。为了保留业务交易的基本语义，请求方和应答方可根据超时采取不同的行为。

如果有超时发生，应答方就简单地终止，这会防止应答业务交易被无限地悬挂起来。如果有超时发生，作为单独交易的一部分，请求方终止并向应答方发出一个失败通知。

当执行一个活动的时间与确认收到的时间或确认业务接受的时间相同时，如果发起者撤回它们最初的业务文件，那么必须使用最高优先级的超时异常。执行异常时间的优先级低于确认收到的时间和确认业务接受的时间。

2)异常

在所有正常情况下，应答信息和超时决定业务交易的成败。然而，应答或请求角色在交易的业务处理时常发生错误。

控制异常表示业务交易管理中的出错条件。业务信号不是同步地返回请求的初始活动。出现这种异常必须终止业务交易。这些错误与消息交换机制有关，如检验、有效性、鉴别和真实性，出错会发生在消息接收环节。一般地，应用于消息的规则和约定仅处理结构、句法和消息元素值。

业务协议异常(或者流程异常)指出了业务活动的出错条件。这个业务信号异步地返回到源请求的初始角色，异常必须终止业务交易。这些错误与处理业务交易的机制有关，并发生在消息的检验和有效性之后。一般地，应用于消息的规则和约定将处理消息元素的语义和请求自身的有效性。与应答有关的业务规则有关，内容是无效的。这种类型的异常通常发生在接受确认返回之后。

业务协议异常终止业务交易。以下是业务协议异常情况:

——接收确认的否定

消息的结构或者模式无效。

——接受确认的否定

违反了业务规则。

——执行异常

请求的业务行为不能被执行。

——序列异常

业务文件或者业务信号的顺序或者类型不正确。

——句法异常

业务文件或者业务信号中有无效的标点符号、词汇和语法。

——鉴别异常