金融服務報文設計

一、間接

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語法