金融服务报文设计

金融服务报文设计

一、间接

1、目的

报文设计的目的是提炼解决方案的逻辑模型，以使具规范化（即精确无误）并确

定可重用的报文组件。

2、关键主题

—将使用哪些已有的报文组件？

——必须生成哪些新的报文组件？

3、主要活动

—规范报文内容；

一确定合适的报文组件；

—将上述内容合并成为报文定义图。

4、交付内容

—报文定义图；

—用形式化语言书写的完成逻辑模型规范化的文本规则。

二、规程概览

下图给出在本阶段开展的不同活动（以椭圆形表示）和必要的输入输出（以矩形

表示）。这些活动在下文中有详细描述。

三、活动：定义报文组件

理解报文中可包含什么样的组件非常重要。下述报文元模型图给出了报文中允许

包含的组件、组件间的关系、数据类型等。任何报文都应根据该元模型图构建。

如何阅读元模型图：

报文由多个报文构建块构成，各个报文构建块表示的信息彼此具有逻辑关系。报

文构建块的内容和结构通过报文组件定义。

报文组件由报文元素构成。报文元素或者引用其他报文组件（通过使用聚合或做

为一个属性建模）,或者拥有某种数据类型（做为一个属性建模）。数据类型可

为《Quantity》、《Identifier》、《Code》、《Amount》等。

表示报文组件的类具有«MessageComponent»（指出报文元素的顺序）或《C

hoiceComponent^构造型（指出报文元素间的某一选择）。

1、通用导则

（1）报文组件由业务组件导出

大部分报文组件由业务组件导出，大部分报文元素由业务元素导出久数据字典

中定义了报文组件/元素和其相关业务组件/元素间的追溯关系。几个报文组件/

元素可定义并追溯至同一个业务组件/元素。

报文定义中的某些报文组件或报文元素可能是由于"报文特定的"的原因（例如，

页码、特定引用等）而出现的，这些组件或元素是“技术性的"，它们不源于任

何业务组件或业务元素。

（2）如何为报文选取/生成正确的报文组件

a）首先应根据在逻辑分析阶段定义的结构来确定什么类型的信息应放置在一起；

b）第一种（且最简单的）情况是一个业务组件需要多个业务元素。这种情况下，

可以通过搜索数据字典获得基于该业务组件的所有报文组件。如果存在一个报文

组件包含了所有需要的业务元素，而且报文组件包含正确的多样性与规则，则该

报文组件就是所要选择的报文组件；

c）如果不存在准确匹配需求的报文组件，则：

•使用包含更多元素的报文组件（如果多余的元素可接受）；

•使用对多样性和/或规则限制较少的报文组件（如果较宽松的确认可接受）；

・使用两个或两个以上的报文组件以包含所有需要的业务元素。可以：

・在报文中将相关报文组件相邻放置；

•建议RA生成一个新的组合报文组件。

d）如果多个业务组件包含多个业务元素，并且不需表示不同业务组件之间的联系，

则根据以上描述的方法使用多个报文组件；

e）如果多个业务组件包含多个业务元素，并且需要表示不同业务组件之间的联系

（例如，需要表示账户、账户拥有者和账户服务商之间的关联性），应通过数据

字典获得基于已确定业务组件的所有报文组件。

集中考虑那些已经表示了两个（或多个）业务组件之间关系的报文组件。找出包

含了所有所需元素并且表示了所需关系的报文组件。如果该报文组件不存在，可

以找出包含了多于所需元素的报文组件，或者将多个报文组件合并。如果不能接

受该解决方案，可建议生成一个或多个新的报文组件。

（3）如何定义新的报文组件

—如果报文组件仅涉及单一业务组件中的业务元素，建议生成一个基于该业

务组件的、包含所需报文元素的报文组件，该报文组件应同时满足所需多样性和

规则的要求（见4.3.1.4）;

—另外，报文组件可能包含"技术性"报文元素（见4.3.1.4）,这些"技术

性〃报文元素是在任何业务组件中都不存在且仅在特定报文中有意义的附加元素。

在此情况下，建议按照前述生成一个满足所需多样性和规则的报文组件，并追加

所需的技术性报文元素一因为不存在与其对应的业务元素；

—如果报文组件需要从多个业务组件中获取元素（因为必须表示出业务组件

之间的关系），可参考以下选项：

•使用几个“简单”报文组件（即报文组件基于单一业务组件），如有必要，在

报文层增加规则来说明彼此的联系；

把"简单”报文组件聚合成为一个“父"报文组件，通过这种方式,所有简单

报文组件则成为子报文组件（例如，新组件包含三个报文组件A、B和C）。在

此情况下，建模人员应指巳这些不同的报文组件同属某项功能，并且描述其必要

的多样性信息和/或规则。将新报文组件提交至注册机构；

•生成表示依赖关系的新报文组件（例如，新报文组件A1和报文组件B1有聚合

关系，其中A1基于业务组件A,Bl基于业务组件B）,在此情况下可能有两种

选择，或者保持明确的聚合关系，或者从所依赖的报文组件"导入"报文元素到

父报文组件（即使用属性代替聚合关系）。后者应谨慎使用，因为它表达的依赖

关系有限例如，它不能表示新报文组件应包含报文组件B1的所有的报文元素，

还是不包含其报文元素）。使用该选项的一个原则是仅有一个报文元素来自报文

组件BL下图表示了上述两种选择（左边是"聚合关系"，右边是"导入"兀

《报文级件》《报文组件》

A1A1B1

O

（4）什么是报文元素

报文元素可以是基于业务元素的报文元素或技术性报文元素。

1）基于业务元素的报文元素

这类报文元素是对特定业务组件中业务元素的一种"拷贝"，且具有以下特性：

—如果规定了业务元素的数据类型，则也应规定报文元素的数据类型。该数

据类型必须相同，或者数据类型相同且具有更严格的限制。在需要对报文元素的

允许值进行限制时（例如，定义用于业务元素的代码列表的子集），在保持相同

数据类型的条件下应使用相应的限制；

—如果由业务组件规定业务元素的类型，则应由报文组件规定报文元素的类

型。该报文组件应基于限定业务元素的业务组件；

―如果报文元素和业务元素在语义上完全一致,则应继续使用业务元素的定

义和名称；

―如果报文元素的语义比业务元素更加丰富和具体，则应对业务元素的定义

和名称进行修改以适应报文元素。

示例：报文需要引用业务元素的特定要求（"最后”进入的日期而不是进入日期）

或者引用已经计算出的数据。在此情况下，报文元素的定义和名称必须表达出特

定的语义（例如，LastEntryDate）。

2）技术性报文元素

技术性的报文元素仅在报文背境下有意义，没有对应的业务元素，因此也没有可

追溯的业务元素与之关联。

下面从业务组件中导出报文组件的例子描述了这些原则。

《业务组件》

Financiallnstrument

^^IsinJdcntificr：Isinldcntifier

^>Descnptionlcxt：DescriptionText

A

《报文组件》

FinaciallnstrumentDetails

Isinldentifier：Isinldentifier

DescnptionText：DescriptionText

NoFinancjallnstaimcntlD：TureFalselndicator

a）生成报文组件"FinanciallnstrumentDetails”，并将其与相对应的业务组件

,,FinancialInstrument,,建立可追溯的关联；

b）拷贝属性wIsinIdentifierH和"DescriptionText”,不修改名称和类型;

c）仅为"FinanciallnstrumentDetails”生成°NoFinancialIdentification,,报

文组件。该信息也可以根据报文中该报文组件的存在/不存在得到。

2、高级导则

1）如何聚合两个报文组件

当两个报文组件相关联时，它们的关系可以通过两种形式表示，一种是使用两个

组件间的聚合关系直接表示，另外一种是使用属性间接表示。

―当报文组件为聚合关系时,两个组件之间的联系可明确表示。建模人员可

以给聚合关系的"角色名称和定义"附加背景信息。这种表示形式可视性较好,

但是会使报文图很快变得很繁杂；

―当使用属性表示报文组件关系时，一个组件的属性指向其他的报文组件。

在此情况下，建模人员可以给属性的"名称和定义"附加背景信息。属性的名称

等同于前述步骤中聚合关系（角色名称）的名称。该方法可视性较差（关联是隐

含的），但思寸于复杂的报文，较之聚合关系而言报文图看起来较简洁。这种建

模方法在UML中称为"外键"使用属性。

2）如何处理抽象类

报文组件不应基于"抽象”的业务组件之上开发。当业务组件不能实例化时，就

将其定义为抽象的。某种程度上，报文组件是业务组件的实现。因此报文组件作

为抽象业务组件的实现是没有意义的。

由于抽象业务组件没有可追溯的联结,其追溯性将存在于具体化该抽象业务组件

的业务组件。

3）如何处理双向关系

如果两个业务组件间的关联是“双向的"，需要引入多个报文组件以描述该关联

的每个方向。这是分层报文定义的结果。

例如符合GB/T27926的业务组件关系是通过嵌套相关的报文组件来描述的。

两个报文组件的嵌套是指一个组件的定义包含另外一个组件的定义。

所以，如果业务组件"Financiallnstrument”包含业务组件”Market",而"M

arketM包含“Financiallnstrument"，这意味着报文实例中包含一个无限循环。

在这样的报文组件中，我们仅需通过“被引用”方向进行单向描述关联即可。解

决方案是定义一个报文组件，例如，称做"FinanciallnstrumentDetail"z它

包含所需信息"Financiallnstrument”标识和其引用位置的标识。

4）如何处理关系循环

假设一个例子中包含三个业务组件A、B、C,其中A关联于B,B关联于C,C

关联于A,则需要引进多个报文组件以避免递归。原因是报文定义本质上支持分

层关系（树状描述），而建模允许定义网状关系。

5）继承

报文组件不应复制业务组件中的继承关系，业务建模中的继承关系允许建模人员

将业务概念进行分类。报文组件是为实现需求而开发的，具有有限的可视性。

6）如何优化报文组件

假设业务组件A与业务组件B相关联，报文组件的两种基本定义方式如下：

a）定义报文组件A和报文组件B,通过定义一个A到B的聚合关系来表示两者

之间的联系；

b）在报文组件A中追加B所需的报文元素。这个过程称为反向规范化（denorma

）应谨慎对待这些“被移动的"报文元素的命名。

lizationo

由于报文元素"背景敏感"，强烈推荐在"被移动的"报文元素的新名称中包含

该报文元素的背景信息。

下面的例子说明了，如果将属于报文组件"Account"（关联到报文组件"Set

tlementDetailslw）的报文元素"Id",移到报文组件"SettlementDetails2"

时，报文元素"Id"应当重新命名为"Accountld"。

四、活动：构建报文

对于序列图中确认的每个报文，组合选定的（或者新的）报文组件以生成报文定

义图中对应报文的最终结构。

对于符合GB/T27926的报文定义,其数据结构主要为树状，树的每个分支由

对应的组件定义。定义报文组件时规定的原则也适用于设计报文。

为确保所有的报文都以同样的方式构建，应遵守报文元模型中规定的约束条件和

规则（见活动”4.3定义报文组件〃）。

1、通用导则

当将报文组件构建成为报文时，基本原则是将报文组件按照“非破坏"的方式联

结。如果组件A和组件B需要联结，在构件报文时，应实现这种关系且不能影

响A或者B的定义，除非它们总是被联合使用。

应将报文建模为构造型《Message》类。

报文应由报文组件构成。

报文组件建模为构造型《Messagecomponent》类。表文组件在构建成为报文

时不能被修改。这意味着《Messagecomponent》类中不能加入任何属性和聚

合关系。

如有必要，应追加关于多样性、选择性、限定性（例如，元素的允许结构）、操

作（例如，检查币种代码的存在）和规则（例如，清算日期必须滞后于订单日期）

方面的信息（见GB/T27926.4语法