ACORD TXLife XML 标准剖析

保险行业主要 XML 标准内幕

ACORD Transactional/Business Wrapper (TXLife) XML 规范日渐成为寿险、养老金和健康保险行业内用于内部和外部数据集成的首选数据格式。该标准内涵宽泛且非常灵活,对实现者既有利也有弊。本文将介绍 ACORD TXLife 消息的结构、实现者面临的挑战,以及您可用于成功实现标准的工具和技术。

Jamie S. Mazur, 软件顾问, PilotFish Technology

Jamie Mazur 是一名自由 IT 顾问和 PilotFish Technology 的解决方案架构师。Jamie 专门研究数据集成、Java 和与 XML 相关的技术,拥有近 10 年使用 ACORD XML 的经验。他对寻找创新性技术解决方案在真实业务问题上的实际应用充满着激情。Jamie 在分布式计算技术方面拥有多项专利。在闲暇时,Jamie 还是一名干劲十足的水下摄影师和两个孩子的专职父亲。



2012 年 12 月 17 日

像许多其他商业领域一样,保险行业变得越来越依赖 XML 标准来进行内部和外部数据集成。在寿险、养老金和健康保险领域,合作运营研究与发展协会 (ACORD) 组织是标准的载体,ACORD Transactional/Business Wrapper (TXLife) 规范模式是该组织所选的语言。了解这项复杂的标准可能是一项艰巨的任务。在本文中,将了解 ACORD TXLife XML 消息中的基本结构,以及如何成功地导航标准文档。

ACORD 标准组织

常用缩写词

  • ACORD:合作运营研究与发展协会
  • ACORD TXLife:ACORD Transactional/Business Wrapper
  • GUID:全球统一标识符
  • XML:可扩展标记语言
  • XSD:XML 模式定义

ACORD 是保险行业标准开发的焦点。作为一个由保险运营商、代理、经纪人、服务提供商和供应商组成的会员组织,ACORD 在尽力通过协作开发相关标准来满足该行业不断演化的需要。在该协会的整个发展历程中,这些标准的性质已演化为包含各种不同的交付结果,比如电子数据交换 (EDI) 格式、纸张格式和 XML 模式。ACORD 还服务于 3 个不同的垂直领域的广泛受众:寿险、养老金和健康保险;财产和意外保险;再保险行业。

本文探讨寿险、养老金和健康保险垂直领域的 XML 标准,在 ACORD 行话中称为 ACORD TXLife 标准。TXLife 同时适用于各种行业系统间的内部和外部集成。

ACORD TXLife 标准的示例应用包括:

  • 向运营商提交保险申请
  • 发送和接收保险需求的顺序、状态和结果
  • 向经销商传达保险产品 “档案”
  • 传输佣金信息
  • 交换已生效或未决的保险单数据

访问 ACORD TXLife 标准文档

但是,在进一步探索该标准之前,请下载最新版的 ACORD TXLife XML 规范(参见 参考资料 获取链接)。请注意,在下载该文件时,可以单独选择会员非会员 选项。ACORD 标准的公共下载和会员下载之间有重大的区别:如果您为一家保险公司或其他行业实体工作,则有必要确定您的组织是否会员。会员公司的代表可以在 ACORD 网站上轻松注册,并访问增强的内容。

公共 ACORD 下载包含:

  • ACORD 寿险标准对象参考模型 (PDF)

    这是开始全面理解 TXLife 标准的结构的最佳位置。它提供了 ACORD TXLife 模式的主要组件的简图,可用作该模型中各种逻辑实体的总体路线图。

  • ACORD 寿险标准公共文档 (PDF)

    本文是与该标准相关的信息的最全面的公开来源。它提供了:

    • 标准用途的详细概述
    • 关于 TXLife 事务类型的信息
    • 逻辑实体和它们的字段级文档的 “字典”
    • “类型代码” 字段的允许的代码值(枚举)
  • ACORD TXLife XML 模式 (XSD)

    这是 XML 模式本身。

会员下载还提供了:

  • ACORD 寿险标准帮助文件 (CHM)

    本文包含与 ACORD 寿险标准公共文档中的信息类似的信息,但使用更易于导航的 Windows® 帮助文件格式表示。

  • ACORD 寿险标准元数据 (XML)

    这个 XML 文件以一种机器可读的格式提供关于 ACORD 模型的深入信息,包括文档和枚举。这可能是最常被忽略但最有价值的会员资产。

  • TXLife 模式的备用(枚举/备案的)版本

    会员下载中包含 TXLife 模式的 3 个版本,而只是一个:

    • 干净

      相当于公共模式

    • 枚举的

      包含每个 “类型代码” 字段的允许值

    • 备案的

      包含文档元素和类型代码值的 xsd:annotations


ACORD TXLife 消息剖析

现在您已有了使用 TXLife 标准所需的参考材料,让我们看看 typical TXLife 消息的框架结构(清单 1)。

清单 1. 清单 1. 一个典型的 TXLife 消息
<TXLife>
  <TXLifeXXX>
    [TXLife Header Section]
      <OLifE>
        [Top Level Objects, e.g., Party/Holding/PolicyProduct/Relation]
      </OLifE>
  </TXLifeXXX>  
</TXLife>

所有 ACORD TXLife XML 文档的根节点都是 <TXLife>。如果您正在浏览模式本身,请先查看一下这个元素。

第二个包装器元素位于 TXLife 根元素中。尽管还有其他一些选项可用,但大多数情况下该元素为 <TXLifeRequest><TXLifeResponse> 或(不太常用)<TXLifeNotify>

在提交初始请求或当初始化信息传输时,会使用 <TXLifeRequest>。在(通常异步地)响应 <TXLifeRequest> 时,您可以使用 <TXLifeResponse>。尽管可以创建一个 <TXLifeRequest> 标记,并且不需要任何 <TXLifeResponse>(例如,采用一种即触即忘的模式),但反之则不行。此结构的大部分内容应该比较简单。不太明显的是,<TXLifeRequest> 不必为信息的请求。相反,它可以表示一种简单的信息传输,比如一项保险申请的状态。<TXLifeNotify>(出于此用途,您可能胡假设它是正确的)实际上是一个很少使用的结构,用于通知请求者一些信息已在等待检索。

第二个标头的直系子标头是一组类似于标头的元素,用于描述事务本身。清单 2 提供了一个示例。

清单 2. 清单 2. 一个简单的 TXLife 事务
<?xml version="1.0" encoding="UTF-8"?>
<TXLife Version="2.25.00" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://ACORD.org/Standards/Life/2">
<TXLifeRequest>
         <TransRefGUID>C396EEB0-171B-11D4-AB93-009027E539F</TransRefGUID>
         <TransType tc="103">New Business Submission</TransType>
         <TransExeDate>2003-09-11</TransExeDate>
         <TransExeTime>10:48:40</TransExeTime>
         <OLifE>
         </OLifE>
</TXLifeRequest>
</TXLife>

TransRefGUID 是一个 GUID,用于唯一地标识请求。这个元素也可用作相应的 TXLifeResponse 消息上的关联 ID。尽管本示例在该字段中使用了一种标准的 GUID 格式,但标准情况下不会强迫这么做。因此,一些实现会基于消息中某些关键的数据元素生成更加自然的键。

TransType 是消息的事务类型。您可能已注意到,TXLife 模式是一个 XSD,没有任何特定于消息的数据元素。例如,没有 NewBusinessRequestMessage 元素的元素类型定义,相反,会由接收者确定从标头的 TransType 元素的 tc 数字属性收到的消息的类型。在接收者知道 TransType 之后,他或她可以对如何解释 XML 流中包含的业务数据做出假设。

常用的示例 TransTypes 包括:

  • 121. 一般需求顺序请求
  • 103. 新业务提交
  • 1125. 案例状态通知传输
  • 1206. 佣金报表传输

ACORD 公共 TXLife 标准文档提供了标准中每种事务类型的基本详细信息。这些详细信息包括消息的一般用途,以及一个具有指定的 TransType 的 XML 实例文档的预期内容。

一定要注意,目前 ACORD 没有发布特定于事务的子模式。TXLife 模式提供了您可在给定消息中使用的数据类型的一个可扩展的字典。在该模式内,大部分元素是可选的。标准文档提供了关于特定事务类型的上下文中需要哪些字段和数据聚合的基本指南。


使用 OLifE 表示业务数据对象

二级标头(比如 TXLifeRequest)中的 <OLifE> 元素是消息中的业务数据的容器。请查看 ACORD 寿险标准对象参考模型。在这个 PDF 中,您将看到 <OLifE> 元素的所有子元素。在 ACORD 方言中,这些子元素称为顶级对象。它们始终表示 TXLife 消息的主要角色或主体。

清单 3 提供了包含 OLifE 消息正文的完整 TXLife 消息的示例。

清单 3. 清单 3. 包含 OLifE 的完整 TXLife 消息
<TXLife Version="2.25.00">
  <TXLifeRequest PrimaryObjectID="Policy_1">
    <TransRefGUID>706D67C1-CC4D-11CF-91FB444554540000</TransRefGUID>
    <TransType tc="502">Holding Change</TransType>
    <TransExeDate>2006-11-19</TransExeDate>
    <TransExeTime>13:15:33-07:00</TransExeTime>
    <ChangeSubType>
      <ChangeTC tc="9">Change Participant</ChangeTC>
    </ChangeSubType>
    <OLifE>
      <Holding id="Policy_1">
        <HoldingTypeCode tc="2">Policy</HoldingTypeCode>
        <Policy>
          <PolNumber>1234567</PolNumber>
          <LineOfBusiness tc="2">Annuity</LineOfBusiness>
          <Annuity>        
          </Annuity>
        </Policy>
      </Holding>
      <Party id="Beneficiary_1">
        <PartyTypeCode tc="2">Organization</PartyTypeCode>
        <FullName>The Smith Trust</FullName>
        <Organization>
          <OrgForm tc="16">Trust</OrgForm>
          <DBA>The Smith Trust</DBA>
        </Organization>
      </Party>
      <Relation id="Relation_1" 
          OriginatingObjectID="Policy_1"
          RelatedObjectID="Beneficiary_1">
        <OriginatingObjectType tc="4">Holding</OriginatingObjectType>
        <RelatedObjectType tc="6">Party</RelatedObjectType>
        <RelationRoleCode tc="34">Primary Beneficiary</RelationRoleCode>
        <BeneficiaryDesignation tc="1">Named</BeneficiaryDesignation>
      </Relation>
    </OLifE>
  </TXLifeRequest>
</TXLife>

在此消息中,在保险单中添加或更改主要受益者。有两种顶级对象:<Holding><Party>。巧合的是,这些是 ACORD 模型中两个最常用的顶级对象。您可能遇到的其他顶级对象包括 <PolicyProduct><FormInstance><InvestProduct>

<Holding> 表示任何类型的金融控股公司。通常情况下,它是一个保险单,但也可以是一笔投资、贷款或抵押。<Party> 表示一个人或组织。

在此示例中,<Holding> 表示一个保险单。您可以通过存在的 <Policy> 子元素集合,以及通过 <HoldingTypeCode> 的值确定这是一个保险单。类似地,您可以看到,<Party> 实际上是一个组织,这从 <PartyTypeCode> 的值和存在 <Organization> 标记可以看出。这是 TXLife 中的一种常见设计模式。继承关系常常表示为表示子类型的子元素。清单 3 中的 XML 实例文档中至少会有一个相关的示例。请尝试找到它。


顶级对象之间的关系

您可能已注意到,我尚未讨论示例中的第三个顶级对象。<Relation> 元素是主要含义,定义两个顶级对象之间的关系。这个概念类似于数据库系统中一种 “多对多” 关系的概念。

<Relation> 元素拥有 表 1 中所示的组件。

表 1. 表 1. TXLife Relation 元素的核心组件
组件描述
@OriginatingObjectID关系中作为名词的对象的引用
@RelatedObjectID作为关系中的直接对象的对象的引用
OriginatingObjectType最初的顶级对象的类型
RelatedObjectType最初的顶级对象的类型
RelationRoleCode/@tc两个对象之间的关系的性质

使用此结构,TXLife 实现者可避免 XML 流中的数据出现重复,因为单个实体(比如一个人)可用于相同消息内的多个角色(例如保险的受保人和所有者)。

无需使用基于对象类型的不同的自然键,ACORD 使用 ID 和 ID 引用作为相关对象之间的指针。模型中的所有顶级对象有一个 id 属性。根据惯例,ID 通常通过串联对象的类型、一个下划线 (_) 和一个计数器(例如 “Party_1”、“Holding_2”)来创建。

id 属性的内容只能用于确定相同 TXLife 消息内的对象之间的关系。它们不能在 XML 流之间维护。也就是说,相同的逻辑实体在一个以后的 TXLifeRequest 或相关的 TXLifeResponse 中可能具有不同的 ID。

除了它们在 <Relation> 元素内的使用,对象 ID 属性还可在整个模型中与 ID 引用结合使用,只要一个对象直接引用了另一个对象。这种类型的 ID 引用也表示为属性,例如:

<RequirementInfo AppliesToPartyID="Party_1"
 PhysicianPartyID="Party_2" FulfillerPartyID="Party_3">

类型代码

ID 和 ID 引用是 ACORD TXLife XML 模式中的 XML 属性的两种主要用途之一。另一种用途是 ACORD 类型代码。类型代码是一种 TXLife 标准,表示标准中的允许值的任何标准化列表。

前面探讨的 <TransType> 标记是使用类型代码结构的字段的一个示例:

<TransType tc="502">Holding Change</TransType>

任何具有 tc 属性的标记表示一种类型代码字段。类型代码有一个枚举的整数值集合,您可以使用该集合作为属性。这些值对应于一组通常用作元素的文本正文的人类可读的描述。

ACORD 实现中的一种常见错误是编码为文本值,而不是编码为 tc 属性中。文本值的使用仅是为了易读,绝不应用于定义处理规则。另一个不太常见的问题是 “发明” 类型代码值,而不是使用在 ACORD 标准中枚举的值。

在 ACORD 没有定义特定的值为枚举类型代码列表中的选项时,实现者可以选择使用 “其他” 值:2147483647。此值与 “未知” 值不同:0。如果事实证明 “其他” 使用得太频繁了(就像在您需要在这个自定义值上执行处理时),您可以使用一个 ACORD 私有类型代码值 — 一个为自定义用途保留的整数范围。参考标准文档,了解此主题的具体细节。

如果您不是 ACORD 会员,您将需要参考 ACORD 寿险标准公共文档 PDF,了解有效的类型代码值和它们对应的文本。会员可以使用模式的备案版本、机器可读的元数据 XML 文件或帮助文件来查找此信息。


扩展

TXLife 模式的内涵非常宽泛和灵活,但您有时仍然需要扩展该模型。ACORD 提供了两种机制 —<OLifeExtension><KeyedValue>— 来支持自定义,而不会牺牲模式合规性。

TXLife 模式中的大部分集合都包含 OLifEExtension 元素。此元素使用类型 <xsd:any> 来定义,可用于持有任意、自定义、复杂的 XML 扩展。VendorCode 属性由 ACORD 定义,具有与命名空间类似的用途。它允许接收方确定是谁定义了扩展(清单 4)。

清单 4. 清单 4. OLifEExtension 示例
<OLifEExtension VendorCode="000">
  <CustomStuff>
    <CustomA>This is important</CustomA>
    <CustomComplexStuff>
      <CustomField>1.0</CustomField>
    </CustomComplexStuff>
  </CustomStuff>
</OLifEExtension>

另一种扩展机制是一个 KeyedValueKeyedValue 提供了一种向支持的集合添加简单字段的方式:

<KeyedValue VendorCode="000">
  <KeyName>CustomField</KeyName>
  <KeyValue>1.0</KeyValue>
</KeyedValue>

真实的 ACORD 实现挑战和解决方案

现在您已掌握了一条 ACORD TXLife 消息的主要组件,接下来考虑一下伴随真实实现的挑战。

ACORD 标准的灵活性是一把双刃剑

如果您已阅读了文档并在您选择的工具中加载了模式,您可能会对所定义的内容的丰富性印象深刻。考虑一个行业相关的消息,它可能可以使用 ACORD TXLife 模式表示。

但是,这种灵活性也带来了歧义性的负担。ACORD 没有发布特定于事务的模式。甚至给定事务类型的人类可读的文档也留下了许多可选的元素,其中许多都没有解释。结果,可能会向 “规范” 构建一个事务,甚至让它由 ACORD 本身 “认证”,而它还不能满足您尝试与其沟通的贸易合作伙伴或系统的需求。

当您充当着 ACORD TXLife 消息的发送者时,您的详细事务需求的第一个来源应该是接收者。许多供应商和服务提供商已创建了他们自己的 “实现指南”,常常包含示例 XML 负载。使用这些指南作为您的实现的起点,使用 ACORD 文档作为辅助性参考材料。

当您构建一个流程来接收 ACORD TXLife 消息时,请查阅 ACORD 事务文档、模式或任何由 ACORD 发布的相关实现指南。但是,另请考虑采用与其他处理相同事务的约定类似的约定。

ACORD TXLife 模式向传统的工具带来了挑战

ACORD TXLife 模式的性质和结构具有自己的挑战。首先,该模式本身非常庞大 — 大小大数 MB。这可能导致市场上许多通用的 XML 工具响应糟糕或一起崩溃。在与对象绑定技术(比如 Java™ XML 绑定架构 (JAXB))结合使用时,或者在一个 Web 服务描述语言 (WSDL) 文件(可能对其运行一个代码生成实用程序)中使用时,该模式的大小和范围也可能带来麻烦。

对模式进行 “切块” 或 “切片” 以仅包含您希望在事务或事务集中使用的数据元素,这种做法常常是明智之举。尽管您完全可以手动这么做,但这是一个痛苦的过程。ACORD 和多个 ACORD 感知供应商提供了实用程序来简化这些子模式的定义。

其次,在专用数据格式与 ACORD TXLife 结构之间映射和来回转换可能是一项艰巨的任务。主要的挑战源于对 Relation 结构的大量使用和对顶级对象的重用。大部分图形化转换工具在本质上都是线性的:您将源格式中的的一个字段连接到目标中的一个字段。但是,在 ACORD 中,相同的字段(比如在 “Party” 下)可用在多个不同的上下文中(保险运营商、代理、受保人、受益者等)。

想象映射到一个具体的事务的结构,而不是映射到整个 ACORD 模式。为此,考虑使用一种基于模板的转换语言,比如可扩展样式表语言转换 (XSLT)。使用 XSLT,您可以使用给定事务的一个示例 XML 文档作为转换的基础。从这里,可以将您的专用数据映射到给定的顶级对象的正确实例。

除了一些少见的异常,ACORD 模式会强制对元素排序。大部分内容都定义为许多可选元素的 <xsd:sequence>(顶级对象除外)。这需要在设计您的事务或选择为您处理它的工具时细心谨慎。

如果您选择一种语言(比如 XSLT)来生成您的映射,请注意您在构建事务时的元素顺序。大部分模式验证工具在 TXLife 元素的顺序不正确时提供的错误消息都不明确。给定集合中大量的可选元素可能使得很难确定哪些字段已处理。在构建消息时考虑到这一点,比在事后返回更正验证错误要容易得多。


结束语

ACORD TXLife 规范是一个强大并在寿险、养老金和健康保险行业广泛实现的 XML 标准。尽管该模式非常庞大,但在您理解了任何 TXLife 消息的基本结构之后,学习曲线就很容易管理。

XML 实例文档的开头是 <TXLife> 标头,其中定义事务类型和其他消息语义。TXLife 消息的核心是 OLifE 元素和填充它的顶级对象。<Party><Holding> 等顶级对象表示消息中的业务数据。这些对象之间的关系通过唯一的 <Relation> 结构来处理。

ACORD 模式的大小和特定于事务的模式的缺乏,为 ACORD 开发项目带来了特殊的考虑因素。这些因素应该在实现的设计和工具选择阶段考虑。幸运的是,ACORD 网站提供了众多实用程序和参考材料,将有助于您朝正确的方向发展。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=XML
ArticleID=852107
ArticleTitle=ACORD TXLife XML 标准剖析
publish-date=12172012