Como muitos outros segmentos comerciais, o segmento de mercado de seguros tornou-se mais dependente dos padrões XML para integração de dados interna e externa. No mundo dos seguros de vida, saúde e anuidades, a organização Association for Cooperative Operations Research and Development (ACORD) é a detentora dos padrões, e o modelo da Especificação ACORD Transactional/Business Wrapper (TXLife) é o dialeto escolhido. Começar a utilizar esse padrão complexo pode ser uma tarefa intimidante. Neste artigo, conheça as estruturas básicas em uma mensagem XML do ACORD TXLife, e a maneira de navegar com sucesso na documentação dos padrões.

A organização de padrões ACORD

ACORD é o ponto focal para o desenvolvimento de padrões no segmento de mercado de seguros. Uma organização de associação composta por seguradoras, corretores, agência, provedores de serviços e fornecedores, a ACORD esforça-se para atender as necessidades em evolução do segmento de mercado através do desenvolvimento cooperativo de padrões relevantes. Ao longo da história da associação, a natureza desses padrões evoluiu para incluir uma diversidade de distribuíveis, como formatos de intercâmbio de dados eletrônicos (EDI), formatos em papel e esquemas XML. A ACORD também atende a um público amplo em três setores distintos: Vida, Saúde e Anuidades, Propriedade e Perdas, e Resseguro.

Este artigo explora o padrão XML para o setor de Vida, Saúde e Anuidades — conhecido no jargão da ACORD como o padrão ACORD TXLife. O TXLife é usado para integração interna e externa entre os sistemas do segmento de mercado.

Exemplos de aplicações do padrão ACORD TXLife incluem:

• Envio de requisição de seguro a uma operadora
• Envio e recebimento de pedidos, status e resultados de solicitações de seguro
• Comunicação de "perfis" do produto do seguro a distribuidores
• Transmissão de informações de comissão
• Troca de dados de apólice vigente ou pendente

Voltar para parte superior

Acesso à documentação de padrões da ACORD

Antes de explorar o padrão mais a fundo, porém, faça o download da versão mais recente da especificação XML da ACORD TXLife (consulte Resources para obter um link). Observe que há opções separadas para membro e não membro quando você faz o download do arquivo. Há diferenças significativas entre os downloads público e para membros do padrão ACORD: se você estiver trabalhando para uma empresa de seguros ou outro participante do segmento de mercado, vale a pena determinar se sua organização está associada. Representantes de empresas membro podem facilmente registrar-se no Web site da ACORD e obter acesso ao conteúdo aprimorado.

O download público da ACORD contém:

• O Modelo de Referência do Objeto de Padrões de Vida da ACORD (PDF)

  Esse é o melhor lugar para começar a obter um entendimento geral de como o padrão TXLife é estruturado. Fornece uma visão em diagrama dos principais componentes do esquema ACORD TXLife, servindo como um roteiro de alto nível para várias entidades lógicas no modelo.

• A Documentação Pública dos Padrões de Vida da ACORD (PDF)

  Esse documento é a fonte de informações mais abrangente disponível ao público sobre o padrão. Ele oferece:

  • Uma visão geral detalhada do uso do padrão
  • Informações sobre os tipos de transação TXLife
  • Um "dicionário" das entidades lógicas e sua documentação no nível de campo
  • Os valores de código permitidos para os campos "código de tipo" (enumerações)
• O esquema XML da ACORD TXLife (XSD)

  Esse é o esquema XML em si.

O download para membros fornece ainda:

• O Arquivo de Ajuda dos Padrões de Vida da ACORD (CHM)

  Esse documento contém informações similares às que estão disponíveis na Documentação Pública dos Padrões de Vida da ACORD, mas é apresentado em um formato de arquivo de ajuda do Windows® mais fácil de navegar.

• Os Metadados dos Padrões de Vida da ACORD (XML)

  Esse arquivo XML fornece informações detalhadas sobre o modelo ACORD, incluindo documentação e enumerações, em um formato legível por máquina. Esse é talvez o ativo mais negligenciado, mas mais valioso, e está disponível apenas para membros.

• Versão alternativa (enumerada/documentada) do esquema TXLife (XSD)

  Três versões do esquema TXLife são incluídas no download para membros, em vez de apenas uma:

  • Clean

    Idêntica ao esquema público

  • Enumerada

    Inclui os valores permitidos para cada tipo de campo de código

  • Documentada

    Inclui xsd:annotations para elementos do documento e valores de código de tipo

Voltar para parte superior

Anatomia da mensagem ACORD TXLife

Agora que você tem os materiais de referência de que precisa para trabalhar com o padrão TXLife, observe o esqueleto da estrutura de uma mensagem TXLife típica (Listagem 1).

	
<TXLife>
  <TXLifeXXX>
    [TXLife Header Section]
      <OLifE>
        [Top Level Objects, e.g., Party/Holding/PolicyProduct/Relation]
      </OLifE>
  </TXLifeXXX>  
</TXLife>

O nó-raiz de qualquer documento XML da ACORD TXLife é <TXLife>. Olhe este elemento primeiro se estiver navegando no esquema em si.

Um segundo elemento wrapper está dentro do elemento-raiz TXLife. Embora várias opções diferentes estejam disponíveis, ele costuma ser <TXLifeRequest>, <TXLifeResponse> ou (com menos frequência) <TXLifeNotify>.

Você usa <TXLifeRequest> ao enviar uma solicitação inicial ou ao começar uma transmissão de informações. Você usa <TXLifeResponse> ao responder — normalmente de forma assíncrona — a uma <TXLifeRequest>. Embora seja possível criar uma identificação <TXLifeRequest> para a qual nenhum <TXLifeResponse> é esperado (por exemplo, em um padrão de sistema de mensagens disparar e esquecer), o inverso não é comum. A maior parte dessa estrutura deve ser intuitiva. O que não é óbvio é que uma <TXLifeRequest> não necessariamente precisa ser uma solicitação de informações. Em vez disso, pode representar uma simples transmissão de informações, como o status de uma solicitação de seguro. <TXLifeNotify>, que você pode presumir que esteja correto para este fim, na verdade, é uma construção raramente usada para notificar um solicitante de que alguma informação está pronta aguardando recuperação.

Os filhos imediatos do cabeçalho secundário são um conjunto de elementos semelhantes ao cabeçalho e que descrevem a transação em si. Listagem 2 fornece um exemplo.

	
<?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>

O operador TransRefGUID é um GUID usado para identificar de maneira exclusiva a solicitação. Esse elemento também é usado como um ID de correlação em um TXLifeResponse relacionada correspondente. Embora esse exemplo use um formato padrão UID neste campo, o padrão não impõe isso. Como resultado, algumas implementações geram uma chave mais natural baseada em certos elementos de dados cruciais na mensagem.

O operador TransType é o tipo de transação da mensagem. Você deve ter observado que o esquema TXLife é um único XSD sem qualquer elemento de dados específicos na mensagem. Por exemplo, não há definição de tipo de elemento NewBusinessRequestMessage . Em vez disso, o destinatário determina o tipo de mensagem sendo recebida a partir do atributo numérico tc do elemento TransType no cabeçalho. Depois que o destinatário conhece o TransType, ele pode fazer pressuposições sobre como interpretar os dados de negócios contidos no fluxo XML.

O exemplo TransTypes frequentemente usado inclui:

• 121. Solicitação de ordem de requisitos gerais
• 103. Envio de novo negócio
• 1125. Transmissão de notificação de status do caso
• 1206. Transmissão da instrução de comissão

A documentação dos padrões ACORD Public TXLife fornece detalhes básicos para cada tipo de transação no padrão. Esses detalhes incluem o objetivo geral da mensagem junto com o conteúdo esperado de um documento de instância XML com o TransType.

É importante observar que atualmente a ACORD não publica subesquemas específicos de transação. O esquema TXLife fornece um dicionário amplo de tipos de dados que podem ser usados em uma determinada mensagem. Dentro do esquema, a maioria dos elementos é opcional. A documentação dos padrões fornece uma orientação básica quanto a quais agregados de dados e campos tornam-se obrigatórios no contexto de um tipo específico de transação.

Voltar para parte superior

Representação de objetos de dados de negócios com OLifE

O operador <OLifE> dentro do cabeçalho de segundo nível (por exemplo, TXLifeRequest) é o contêiner para os dados de negócios na mensagem. Veja o Modelo de Referência de Objeto dos Padrões de Vida da ACORD. Nesse PDF, você verá todos os filhos do elemento <OLifE> . No vernáculo do ACORD, esses filhos são chamados de objetos de nível superior. Eles invariavelmente representam os atores ou sujeitos principais da mensagem TXLife.

a Listagem 3 oferece um exemplo de uma mensagem TXLife completa com um corpo de mensagem OLifE.

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

Nessa mensagem, o principal beneficiário está sendo adicionado ou alterado em uma apólice. Há dois objetos de nível superior: <Holding> e os <Party>. Coincidentemente, esses são os dois objetos de nível superior mais usados no modelo ACORD. Outros objetos de nível superior que você provavelmente encontrará incluem <PolicyProduct>, <FormInstance>e o <InvestProduct>.

Um <Holding> representa qualquer tipo de participação financeira. Com mais frequência, será uma apólice, mas também pode ser um investimento, empréstimo ou hipoteca. Um <Party> representa uma pessoa ou organização.

Neste exemplo, <Holding> representa uma apólice de seguro. Isso é possível determinar pela presença do agregado filho <Policy> , bem como através do valor de <HoldingTypeCode>. De maneira similar, é possível ver que <Party> é na verdade uma organização, dado o valor de <PartyTypeCode> e pela presença da tag <Organization> . Esse é um padrão de design comum em todo o TXLife. Relacionamentos de herança são representados com mais frequência como elementos filhos, indicando subtipos. Há pelo menos um outro exemplo disso no documento da instância XML na a Listagem 3. Tente encontrá-lo.

Voltar para parte superior

Relacionamentos entre objetos de nível superior

Você pode ter observado que ainda não discutimos o terceiro objeto de nível superior neste exemplo. O operador <Relation> é o meio principal para definir o relacionamento entre dois objetos de nível superior. O conceito é similar àquele de uma tabela de relacionamento de "muitos para muitos" no sistema de banco de dados.

O operador <Relation> tem os componentes mostrados na Tabela 1.

Usando essa estrutura, os implementadores do TXLife podem evitar a duplicação de dados no fluxo XML, como uma única entidade (por exemplo, uma pessoa) que pode atuar em várias funções dentro da mesma mensagem (por exemplo, o segurado e o proprietário de uma apólice de seguro).

Ao invés de usar chaves naturais diferentes baseadas no tipo de objeto, a ACORD usa IDs e referências de ID como ponteiros entre objetos relacionados. Todos os objetos de nível superior no modelo têm um atributo ID . Por convenção, os IDs são tipicamente criados concatenando o tipo de objeto, um sublinhado (_) e um contador (por exemplo, "Party_1", "Holding_2").

O conteúdo do atributo ID somente pode ser usado para determinar os relacionamentos entre objetos dentro da mesma mensagem TXLife. Eles não são feitos para serem mantidos entre fluxos XML. Ou seja, a mesma entidade lógica pode ter um ID diferente em uma TXLifeRequest posterior, ou em uma TXLifeResponse relacionada.

Além do seu uso dentro de elementos de <Relation> , os atributos ID do objeto são usados junto com referências de ID em todo o modelo, sempre que um objeto faz referência diretamente a outro. Referências de ID desse tipo também são representadas como atributos — por exemplo:

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

Voltar para parte superior

Códigos de tipo

IDs e referências de ID são um dos dois principais usos dos atributos XML no esquema XML da ACORD TXLife. O outro uso são códigos de tipo ACORD. O código de tipo é o mecanismo do TXLife para representar qualquer lista padronizada de valores permitidos no padrão.

A identificação discutida anteriormente <TransType> é um exemplo de um campo que usa a estrutura de código de tipo:

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

Qualquer identificação com um atributo tc representa um campo de código de tipo. Códigos de tipo têm um conjunto enumerado de valores inteiros que podem ser usados como atributo. Esses valores correspondem a um conjunto de descrições legíveis por pessoas e normalmente usadas como o corpo de texto do elemento.

Um erro comum na implementação da ACORD é codificar para o valor de texto, não o atributo tc dos microdados. O valor de texto está presente apenas para legibilidade e nunca deve ser usado na definição das regras de processamento. Outro problema menos comum é "inventar" valores de código de tipo, em vez de usar os valores enumerados no padrão ACORD.

Nesses casos em que ACORD não tem um valor definido em particular como uma opção na lista de código de tipo enumerado, os implementadores têm a opção de usar o valor "Outro": 2147483647. Esse valor é diferente e distinto do valor "Desconhecido": 0. Se o uso de "Outro" se mostrar amplo demais (como no caso em que você precisa realizar o processamento nesse valor customizado), é possível usar um valor de código de tipo privado do ACORD — uma variedade de números inteiros reservados para uso customizado. Consulte a documentação dos padrões para as especificidades sobre este tópico.

Se você não for membro da ACORD, precisará consultar o PDF com a Documentação Pública dos Padrões de Vida da ACORD para obter os valores de código de tipo válido e seus equivalentes de texto. Os membros podem usar a versão documentada do esquema, o arquivo XML de metadados legível por máquina ou o arquivo de ajuda para encontrar essas informações.

Voltar para parte superior

Extensões

O esquema TXLife é excepcionalmente amplo e flexível, mas ocasionalmente há momentos em que é preciso ampliar o modelo. ACORD oferece dois mecanismos — <OLifeExtension> e <KeyedValue> — para acomodar a customização sem sacrificar a conformidade do esquema.

A maioria dos agregados no esquema TXLife inclui o elemento OLifEExtension . Esse elemento é definido com o tipo <xsd:any> e pode ser usado para reter extensões XML complexas, customizadas e arbitrárias. O operador VendorCode é definido pela ACORD e serve a um objetivo similar ao namespace. Permite que a parte recebedora determine quem definiu a extensão (4).

	
<OLifEExtension VendorCode="000">
  <CustomStuff>
    <CustomA>This is important</CustomA>
    <CustomComplexStuff>
      <CustomField>1.0</CustomField>
    </CustomComplexStuff>
  </CustomStuff>
</OLifEExtension>

O outro mecanismo de extensão é um KeyedValue. KeyedValues fornecem um meio de adicionar um campo simples a um agregado de suporte:

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

Voltar para parte superior

Desafios e soluções de implementação do ACORD na vida real

Agora que você realizou um tour sobre os principais componentes de uma mensagem ACORD TXLife, considere os desafios que acompanham a implementação na vida real.

aA flexibilidade do padrão ACORD apresenta riscos e benefícios

Se você percorreu as páginas da documentação ou carregou o esquema na sua ferramenta de escolha, provavelmente está impressionado com a amplitude do que foi definido. Pense em uma mensagem relevante para o segmento de mercado e ela provavelmente pode ser representada com o esquema ACORD TXLife.

Entretanto, essa flexibilidade também apresenta ambiguidade. ACORD não publica esquemas específicos de transação. Mesmo a documentação legível por pessoas para um determinado tipo de transação deixa muitos elementos opcionais e muita abertura para interpretação. Como resultado, é possível desenvolver uma transação "para a especificação" e inclusive tê-la "certificada" pelo próprio ACORD, e ainda falhar em atender os requisitos do parceiro comercial ou sistema com o qual você está tentando se comunicar.

Quando você estiver atuando como um remetente de uma mensagem ACORD TXLife, sua primeira origem para os requisitos detalhados da transação deve ser o recebedor. Muitos fornecedores e provedores de serviço criaram os próprios "guias de implementação", frequentemente contendo cargas úteis de amostra XML. Use esses guias como pontos iniciais para a sua implementação, com a documentação ACORD como o material de referência de apoio.

Quando você está desenvolvendo um processo para receber uma mensagem ACORD TXLife, consulte a documentação da transação ACORD, o esquema ou qualquer guia de implementação relevante publicado pelo ACORD. Entretanto, também considere adotar convenções similares a outras que funcionam com a mesma transação.

O esquema ACORD TXLife apresenta desafios ao conjunto de ferramentas tradicional

A natureza e a estrutura do esquema ACORD TXLife apresentam seus próprios desafios. Em primeiro lugar, o esquema em si é enorme — vários megabytes de tamanho. Isso pode fazer muitas ferramentas XML genéricas no mercado responderem de maneira insatisfatória ou simplesmente travar. O tamanho e o escopo do esquema também podem causar problemas quando usados junto com tecnologias de ligação de objetos, como Java™ Architecture for XML Binding (JAXB) ou quando usados dentro de um arquivo Web Services Description Language (WSDL) com relação a um utilitário de geração de código que pode ser executado.

Frequentemente é aconselhável "afinar" ou "fatiar" o esquema para incluir apenas os elementos de dados que você usará na sua transação ou conjunto de transações. Embora seja possível fazer isso manualmente, o processo é meticuloso. ACORD e vários fornecedores que atuam de acordo com ACORD oferecem utilitários para facilitar a definição desses subesquemas.

Em segundo lugar, mapear e transformar formatos de dados proprietários de e para as estruturas ACORD TXLife podem ser tarefas intimidantes. O principal desafio vem do amplo uso da estrutura Relation e da reutilização dos objetos de nível superior. A maioria das ferramentas de transformação gráfica é linear por natureza: você conecta um campo no formato de origem para um campo no destino. Entretanto, no ACORD, o mesmo campo (por exemplo, sob "Parte") pode ser usado em vários contextos diferentes (a seguradora, o agente, o segurado, o beneficiário, e assim por diante).

Pense sobre mapear a estrutura de uma transação específica, não para todo o esquema ACORD. Para esse fim, considere usar uma linguagem de transformação com base em modelo, como Transformação de Linguagem de Folha de Estilo Extensível (XSLT). Usando XSLT, é possível usar um documento XML de amostra para uma determinada transação como a base da sua transformação. A partir daí, é possível mapear os dados proprietários para a instância correta de um objeto de nível superior específico.

Com algumas raras exceções, o esquema ACORD impõe ordem ao elemento. A maioria é definida como uma <xsd:sequence> de muitos elementos opcionais (objetos de nível superior são uma exceção). Isso requer muito cuidado ao manipular sua transação ou selecionar o conjunto de ferramentas que a manipula por você.

Se você escolher uma linguagem como XSLT para gerar os mapeamentos, preste atenção à ordem do elemento conforme desenvolve sua transação. A maioria das ferramentas de validação de esquema fornece mensagens de erro vagas quando os elementos TXLife não estão na ordem correta. O grande número de elementos opcionais em um determinado agregado pode tornar irritantemente difícil determinar quais campos foram transpostos. É muito mais fácil desenvolver sua mensagem com isso em mente e então voltar e corrigir os erros de validação após o fato.

Voltar para parte superior

Conclusão

A especificação do ACORD TXLife é um padrão XML eficiente e amplamente implementado no segmento de mercado de seguros de vida, saúde e anuidades. Embora o esquema seja imenso, a curva de aprendizado é gerenciável depois de entender a estrutura básica de qualquer mensagem TXLife.

Os documentos de instância XML começam com o cabeçalho <TXLife> , em que o tipo de transação e outras semânticas da mensagem são definidos. O centro de uma mensagem TXLife está no elemento OLifE e nos objetos de nível superior com os quais ele é preenchido. Objetos de nível superior como <Party> e <Holding> representam os dados de negócios na mensagem. Os relacionamentos entre esses objetos são manipulados através da estrutura exclusiva <Relation> .

O tamanho do esquema ACORD e a ausência de esquemas específicos da transação criam considerações especiais para projetos de desenvolvimento ACORD. Esses fatores devem ser considerados durante a fase de design e seleção de ferramentas de uma implementação. Felizmente, o Web site do ACORD oferece vários utilitários e materiais de referência que o ajudarão a iniciar na direção certa.

Recursos

Aprender

• Visite a seção ACORD Standards Organization .
  
  
• Explore os produtos da implementação do ACORD e os materiais de referência.
  
  
• Valide mensagens do ACORD com o recurso de certificação e teste ACORD.
  
  
• Iniciante em XML? Obtenha os recursos necessários para aprender XML.
  
  
• Descubra mais recursos do developerWorks relacionados a este artigo na zona Segmento de Mercado do developerWorks. .
  
  
• No assistente área de XML do developerWorks, encontre os recursos necessários para ampliar suas habilidades na área de XLM. Consulte o Biblioteca técnica de XML para obter um intervalo amplo de artigos técnicos e dicas, tutoriais, padrões e IBM Redbooks.
  
  
• Fique por dentro dos developerWorks com foco em uma variedade de produtos IBM e assuntos do segmento de mercado de TI.
  
  
• Siga o developerWorks no Twitter hoje para acompanhar os tweets do developerWorks.
  
  
• Confira o Podcasts do developerWorks e escute entrevistas e discussões interessantes para desenvolvedores de software.
  
  

Obter produtos e tecnologias

• Acesse os arquivos de padrões ACORD.
  
  
• Versões de avaliação de produto IBM: Faça o download ou explore as versões de teste on-line no IBM SOA Sandbox e entre em contato com as ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2®, Lotus®, Rational®, Tivoli®eWebSphere®.
  
  

Discutir

• Participe de qualquer uma das várias discussões relacionadas a XML nos Fóruns de discussão da zona de XML.
  
  
• Participe da comunidade do My developerWorks . Entre em contato com outros usuários do developerWorks e explore os blogs, fóruns, grupos e wikis voltados para desenvolvedores.
  
  

Sobre o autor

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• A organização de padrões ACORD
• Acesso à documentação de padrões da ACORD
• Anatomia da mensagem ACORD TXLife
• Representação de objetos de dados de negócios com OLifE
• Relacionamentos entre objetos de nível superior
• Códigos de tipo
• Extensões
• Desafios e soluções de implementação do ACORD na vida real
• Conclusão
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais