(高清版)GBT 27926.3-2021 金融服务　金融业通 用报文方案　第3部分：建模导则VIP

GB/T27926.3—2021/ISO20022-3:2013代替GB/T27926.3—2011金融服务金融业通用报文方案第3部分：建模导则Part3:Modelling(ISO20022-3:2013,IDT)国家市场监督管理总局国家标准化管理委员会IGB/T27926.3—2021/ISO20022-3:2013 Ⅲ V 1 13术语和定义 1 1 3 5 9 ⅢGB/T27926.3—2021/ISO20022-3:2013本文件按照GB/T1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定起草。本文件是GB/T27926《金融服务金融业通用报文方案》的第3部分。GB/T27926已经发布了——第2部分：UML概况；——第3部分：建模导则； ——第6部分：报文传输特性；——第8部分：ASN.1生成。本文件代替GB/T27926.3—2011《金融服务金融业通用报文方案第3部分：建模导则》,与第1章、第2章、第3章、第4章、第5章、第6章);h)删除了附录A“示例”(见2011年版的附录A);i)增加了附录A“适用的UML图表”(见附录A)。本文件使用翻译法等同采用ISO20022-3:2013《金融服务金融业通用报文方案第3部分：建模与本文件中规范性引用的国际文件有一致性对应关系的我国文件如下：——GB/T27926.1—2021金融服务金融业通用报文方案第1部分：元模型(ISO20022-1:2013,IDT)——GB/T27926.2—2021金融服务金融业通用报文方案第2部分：UML概况(ISO20022-2:2013,IDT)本文件由中国人民银行提出。本文件由全国金融标准化技术委员会(SAC/TC180)归口。IVGB/T27926.3—2021/ISO20022-3:2013本文件及其所代替文件的历次版本发布情况为：GB/T27926.3—2021/ISO20022-3:2013GB/T27926定义了一个可伸缩的、系统的过程，以确保整个金融业的报文描述一ISO20022的产生是建立在开放技术标准的基础上，通常技术标准的发展速度比行业本身快。因此，该文件采用了模型驱动的方法，其中行业报文集模型能够从报文技术的发展中独立分离出来。ISO20022伴随万维网在商业上的广泛采用而出现。可扩展标记语言(XML)以Web上文档表示形式GB/T27926由以下部分构成：——第1部分：元模型；——第3部分：建模导则；——第5部分：反向工程； 第6部分：报文传输特性；与GB/T29726—2011相比修订其中5部分，新增3部分，新增部分为：——第2部分：UML概况； 第8部分：ASN.1生成。GB/T27926—2021《金融服务金融业通用报文方案》8个部分等同采用ISO20022:2013的8个支持并支持多层的抽象。根据本文件创建的模型是独立于技术的，因为它们不需要任何特定的物理表达式或实现。这些模型旨在描述报文交换的所有部分，构成了报文交换参与者之间协议的定义。本文——第1部分：元模型。在元对象工具(MOF)中描述所有模型和库的元模型，目的是介绍建模方各层到UML实现所涉及的元类属性，以便报文开发者更好地理解UML扩展集及其各层级——第3部分：建模导则。描述了为本文件产生模型的建模方法。目的是向建模人员说明报文模是针对第1部分、第2部分关于建模方面业务的具体实现。VV——第4部分：XMLSchema生成。目的是介绍XMLSchema生成规则，用于将逻辑层模型转换为语法描述的物理层。——第5部分：反向工程。涵盖了逻辑模型对齐和现有报文语法的反向工程。目的是介绍反向工——第6部分：报文传输特性。目的是介绍业务交易和报文定义所需要的报文传输系统的参数，明确报文不同传输模式下的参数差异。-—第7部分：注册。描述了管理模型注册和物理语法实现的过程。目的是说明申请机构和注册机构双方的职责和注册流程。——第8部分：ASN.1生成。该部分给出了ASN.1语法生成规则，以便通过ASN.1将逻辑层模型转换为物理层描述。1GB/T27926.3—2021/ISO20022-3:2013金融服务金融业通用报文方案第3部分：建模导则1范围本文件并不是规定提交给注册机构(RA)的资料或文件(这部分信息在ISO20022-7中)。2规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文本文件。ISO20022-1金融服务金融业通用报文方案第1部分：元模型(Financialservices—Universalfinancialindustrymessagescheme—Partl:Metamodel)ISO20022-2金融服务金融业通用报文方案第2部分：UML概况(Financialservices—Uni-versalfinancialindustrymessagescheme—Part2:UMLprofile)ISO20022-1和ISO20022-2界定的术语和定义适用于本文件。4工作流程活动概述决方案。对于特定业务场景下的信息交换问题，可开发出多个解决方案。本文件目的是向建模人员解释需要遵循的不同步骤，以确保对于ISO20022所有的项如业务组件/业务元素、报文组件类型/报文元素、业务交易和报文定义的一致性。ISO20022方法论由一系列活动构成。这些活动又分为以下几个层级：——范围层；——逻辑层；——物理层。——开始该项活动所需的条件(需要的输入);——该项活动应产生的结果(预期输出);——示例(如有必要);2GB/T27926.3—2021/ISO20022-3:2013——应遵循或者参考的建模规则和约束条件。范围层定义业务场景定义业务过程(Define定义业务过程(Definek目录(<<datastore>>Catalogue)业务角色(BusinessRoles)提炼refine概念层<<datastore>><<datastore>>数据字典(<<datastore>>业务概念(Define业务交易业务交易(DefineDefine转化transforms逻辑层生成createScopechanged?(Compose物理层转化transforms语法模式3GB/T27926.3—2021/ISO20022-3:20135范围层范围层的目的是为更好地理解业务领域和业务过程，并基于此制定符合ISO20022的业务交易和报文集。息交换问题。这些信息交换问题是进行下一阶段(概念层)的主要动因。b)识别业务领域中的业务信息也非常重要，因为在后续阶段设计的报文会包括与该业务概念有关的数据元素。明确业务概念和报文概念间的关系有助于互操作性、后续——确定待解决信息交换问题的业务场景； 范围层的主要活动是：——明确业务过程。范围层的交付内容应包括：——描述业务过程和其包含的业务信息及业务角色的模型(所有模型元素的详细文字说明，包含业定义业务场景应遵循以下步骤(见图2)。——确认业务场景中处理和/或使用的关键业务组件和业务元素。它们可分成输入信息(即影响业务过程，但是又不在业务场景控制范围内的信息)和输出信息(即在业务场景控制内且影响其他业务过程的信息)。4GB/T27926.3—2021/ISO20022-3:2013acivityacivityDeineBusinessContextDeineBusinessContexi选择业务领域定义业务目标业务过程目录存量业务领域业务概念假定新建存量本活动定义下列元素。a)从顶层节点(表示总体业务目标)开始给出业务过程的组织，可通过“include”关联和“extend”关联进行细化。b)对每个业务过程以及每个业务过程的活动进行描述：c)与所定义的业务过程相关的业务角色，该业务角色也同样适用本业务过程中通过扩展或包含产生的其他业务过程。5.3导则在信息交换问题，每个业务角色对任何业务过程中使用的信息具有充分的了解及访问权限。完善的业5GB/T27926.3—2021/ISO20022-3:2013务过程将会增加业务价值。义完毕后进行详细描述。业务角色应仅与最细的业务过程(即最低层次)关联。6概念层概念层的目的是定义并理解业务语义，同时定义在业务过程中由于业务角色物理分离导致的信息交换需求。概念层确定并详细说明业务过程和业务活动在协定范围内出现的所有信息交换需求。它确定谁、报文的实际定义。-—分析业务模型，以便发现相应的信息交换需求；——对待开发的业务交易和报文集预期属性进行准确定义；——确定解决方案的总体架构，即是采用端到端的解决方案还是采用集中协调的解决方案；—-—确定业务交易(不同的报文示例可按照经确认的多个报文流的方式进行交换)。——详细描述待开发业务交易和报文集的功能(即行为)需求；——详细描述待开发业务交易和报文集的约束条件(即硬性限制);——将业务过程(以用例表示)细化为具体的业务交易(以序列图表示);——确定解决方案的总体架构。——最终解决方案范围和边界的文字描述；——每个业务角色使用的信息的业务组件图(可通过相关业务规则进行补充);——带有业务交易描述的业务交易图。6GB/T27926.3—2021/ISO20022-3:2013易和报文集进行支持。本活动基于范围层已定义的业务过程图完成。业务组件图¹由用例中的“参数”构成，包括继承、关联和聚合关系。业务组件图可使用数据字典里业务组件图可包含关于多样性的信息，且应指明每个业务元素的类型(通过数据类型或业务组件表示)。——编码集比标识符集包含更多的语义；每个单独的值(即每个编码集字符)都对业务属性进行描●如果一个业务组件完全是另一个业务组件的组成部分，那么后者的业务关联端(即它的联系域)的聚合属性为“COMPOSITE”。真正的业务包容关系意味着在现实中，被包含元素(部分)不能脱离包含元素(整体)而存在。因此，业务组件图中聚合关系仅用于表示具有真正业务包含关系的情况。●如果一个业务组件是几个业务组件的组成部分，那么后者的业务关联端(即它的联系域)的聚合属性为“SHARED”。示例2:个人和金融机构都有地址。描述参与者实现用例的方式和该过程中需要的信息流(见图3)。业务交易应至少通过文字和序列图表示，给出参与者之间的信息流。业务交易的描述将提供下列——信息流发生的顺序；——与每个信息流相关的前置条件和后置条件。7GB/T27926.3—2021/ISO20022-3:2013[activityDefineBusinessTra定义参与者业务交易图是否有中央系统否是增加辅助参与者定义报文传输定义业务交易(被建模为时序图)与其相应的业务过程之间的踪迹。对于每个业务交易定义，适当地定义约束报文传输模式的参数——传送持续性保证；8GB/T27926.3—2021/ISO20022-3:2013——最大报文数；——报文传送顺序；——报文发送窗口；——报文验证层级；——报文验证开关；——报文验证结果；——接收端异步性；业务过程(用例)中的业务角色在业务交易(活动图)中被定义为参与者。在业务交易图中，每个参与者用一个泳道表示。-—对于穿过泳道的每个信息流，定义一个(<MessageTransmission>>的构造型UML报文。在逻放到一起),且在序列图(与每个信息流关联)中说明这些信息。报文内容可根据不同业务活动需要的和提供的信息加以确定。业务模型是对事物的定义，即事物的本质和业务语义。建模的原则和规则以及对于模型使用的偏好并不包含在业务模型之中。ISO20022中并不包括业务模型的建模原则。换言之，业务模型是现实9GB/T27926.3—2021/ISO20022-3:20137逻辑层逻辑层的目的是详细描述待开发的业务交易和报文集的细节。本阶段的重点是进行报文定义，用于在正确的时间从正确的参与者获取所需的信息。本阶段仅从业务视角看待业务交易和报文集，也就是说从语义的视角(即潜在的业务含义)而非语法的视角(即报文的表达及其规则)。所有的结论均源自概念层已确认和说明的需求(功能需求和约束)。逻辑层是从一个抽象的视角描述报文集，而不是从具体的、技术的视角。这种抽象的方法使其在不同的技术表示形式间保持互通性。逻辑层的关键主题包括：——从业务内容角度确定报文定义。交换的信息应具有业务价值，报文组件类型/报文元素应源自概念层确定的业务组件类型/业务元素并由之定义。——确定适用于各类报文定义规则及其作用范围。如果范围仅是报文定义，则规则仅针对报文的内容；如果范围是业务交易，规则将针对全部业务交易信息检验报文定义的内容。例如，前述报文实例中包含的信息。逻辑层的主要活动是：——定义报文集，用于将报文定义分组；——基于业务交易，确认与相关信息流对应的报文定义和约束规则；——设计报文定义，即确认业务内容、报文的整体结构和组织形式，以及适用于报文定义的约束规则；——确认合适的报文组件类型；——将上述内容合并成为报文定义图。逻辑层中应交付的内容是： 个报文集：——一个或多个报文定义；——用形式化语言书写的约束条件/规则，报文定义根据相关规则完成了规范化处理。基于定义业务交易时所识别的信息流，创建一个包含完成业务交易所需的所有报文定义的报文集。GB/T27926.3—2021/ISO20022-3:2013结合选定的(或新的)报文组件类型，在报文定义图(见ISO20022-1)中创建对应报文定义的最终本活动中创建的新报文组件类型会对字典进行更新。创建报文定义业务过程目录创建报文模块业务过程目录新建存在存在识别报文组件类型数据字典更新消息定义新建定义业务组件和业务元素轨迹构造型报文定义的类的名称在库中应是唯一的。“xxxx.nnn.aaa.bb”。bb是两位定长的数字编码，表示版本；确定报文定义类所使用的报文构件模块。首先应根据在逻辑层定义的结构来确定什么类型的信息应放置在一起。第一种(且最简单的)情况是一个业务组件需要多个业务元素。这种情况下，可通过搜索数据字典获得基于该业务组件的所有报文组件类型。如果存在一个报文组件类型包含了所有需要的业务元素，——使用包含更多元素的报文组件类型(如果多余的元素可接受);——使用对多样性和/或规则限制较少的报文组件类型(如果较宽松的验证可接受);——使用两个或两个以上的报文组件类型以得到所有需要的业务元素，宜在报文中将相关报文组方法使用多个报文组件类型。如果多个业务组件包含多个业务元素，并且户、账户拥有者和账户服务商之间的关联性),应通过数据字典获得基于已确定业务组件的所有报文组件类型。集中考虑那些已经表示了两个(或多个)业务组件之间关系的报文组件类型。业务组件中都不存在且仅在特定报文中有意义的附加元素。在此情况下，宜按照前述生成一个满足所需多样性和规则的报文组件类型，并追加所需的技术性报文元素(因为不存在与其对应的业务元素)。如果报文组件类型需要从多个业务组件中获取元素(由于需要表示业务组件之间的关系),可参考以下选项。——使用几个简单的报文组件类型(即报文组件类型基于单一业务组件),如有必要，在报文定义层员应表示出这些不同的报文组件类型同为一体，并且描述其必要的多样性将新报文组件类型提交至RA。GB/T27926.3—2021/ISO20022-3:2013——生成表示依赖关系的新报文组件类型(例如，新报文组件类型A1和报文组件类型B1有聚合件类型应包含报文组件类型B1所有的报文元素，还是不包含其报文元素)。使用该选项的一个原则是仅有一个报文元素来自报文组件类型B1。图5表示了上述两种选择(左边是“聚att1:Stringatt2:Stringatt1:String att2:Stringatt3:Stringatt3:Stringatt4:StringA1B1ISO20022用户自定义数据类型是基于数据类型的表现形式。数据类型表现形式能将用户自定义的数据类型分类，同时允许将具有一些公共参数的数据类型分组。ISO20022每个用户自定义数据类型都由一个数据类型表现形式通过构造型扩展的方法以UML数据类型表示。每个数据类型表现形式很多数据类型共有的参数被组合在一起。适用的UML图表见附录A。ISO20022的XSD数据类型被表现为UML数据类型，定义在Profile::TypeLibrary中。初始基本类型(例如字符串)和数据类型表现形式(例如金额)所允许的值域在扩展集中进行定义，每个表现形式都有对应的约束条件/规则。如果报文元素与业务元素或业务组件语义相关，那么该报文元素应被追溯至对应业务元素/业务组件。数据字典中定义了报文组件和其相关业务组件/元素间的追溯关系。该追溯关系使用构造型化的),在UML中体现为依赖关系(通过UML依赖标识线表示)。GB/T27926.3—2021/ISO20022-3:2013——如果报文元素是根据用户自定义的数据类型确定的，那么业务元素也应由同样的数据类型或限制较少的数据类型来确定。——如果由业务组件规定业务元素的类型，则应由报文组件类型规定报文元素的类型。该报文组件类型应基于限定业务元素的业务组件。——如果报文元素与业务元素/业务组件的语义完全相同，那么应继续使用业务元素/业务组件的——如果报文元素的语义比业务元素/业务组件的语义更为丰富或具体，则应对业务元素/业务组件的定义和名称进行修改以适应报文元素。——几个报文元素可定义并追溯至同一个业务元素/组件。技术性报文元素的“isTechnical”属性设定为“TRUE”。报文需要引用业务元素的特定要求(“最后”输入的日期而不是输入日期)或者引用已经计算出的数据。在此情况也可将整个报文组件类型追溯至一个业务组件。-—在数据字典中定义报文组件类型和其相关业务组件的追溯关系。该追溯关系用一个追溯依赖 几个报文组件类型可定义并追溯至同一个业务组件。定义场景中有意义。这些组件是“技术性的”,它们不源于任何业务组件。技术性报文组件类型的“isTechnical”属性应设定为“TRUE”。报文组件类型不应复制业务组件中的继承关系。如果一个报文元素可由其他报文元素通过计算(或其他方式)得到，那么这个报文元素就应被标记示例：在发票的报文定义中，应包含邮寄地址和账单地址。因为在某些发票中，邮寄地址和账单地址可能是一样当约束性元模型概念或非约束性元模型概念都可用来表示一个库概念时，优先选择最简洁的表达GB/T27926.3—2021/ISO20022-3:2013业务组件相应的业务元素或其内容之间的同级约束，以及报文组件类型相应的报文元素或其内容示例：如果邮政城市业务元素不存在，那么邮政地址业务组件需要邮政编码业务元素。这表示派生的业务元素或报文元素的“isDerived”属性值应被设定为“True”。每个派生的业务元素或报文元素都附带一条派生规则作为约束。如果报文定义的当前版本被弃用，就会创建一个新的版本。当前版本一旦从使用该版本的最后一如果属性没有设定为“COMPOSITE”,那么目标报文组件类型将包含一个“ID”类型的报文元素。注：一个业务交易仅是描述一组需求的一个可能的解决方案。针对同样的问题可能有多个解决方案。在此情况可以采取以下关于报文实例粒度的初始规定：令和报告的报文定义)。GB/T27926.3—2021/ISO20022-3:2013求并根据差异的要求程度生成在同一报文定义下的不同“变体”和/或覆盖多个市场行为需求——如果参与者是从一个“通用”业务角色而非其子类派生而来，则与市场行为遵循的原则类似。与者需求的报文定义。验证生成多个报文定义(有多个变体的)较生成单个报文定义是否有意义的有效方法，是考虑为了生成多个显式的报文，从报文定义中去掉一个特定组件或元素后所产生的影响。如果去掉组件或元素及验证层级的相应属性。当发送方不希望报文实例的接收方验证/处理报文时，处理内容的值才允许被设为“skip”。因为会将处理内容的值设定为“strict”会要求发送方发送出能被接收方验证的报文实例。即如果报文实宜用规范的形式为日期类(即用户自定义的以日期、时间、日期时间、年、月、天、年月和月日为表现2000-12-20T20:00:00.000Z2000-12-20T20:00:00ZGB/T27926.3—2021/ISO20022-3:2013物理层包含了一套从逻辑层向目标抽象语法(如ISO20022XMLSchema或ISO20022ASN.1结称该活动为物理性的是因为它处理的是目标技术环境中报文的物理表示形式。XML设计规则见ISO20022-4。ASN.1转换规则见ISO20022-8。物理层的关键主题是：——界定报文定义的XMLSchema表现形式或ASN.1模块并将结果打包。物理层的主要活动是：——生成包含有效语