Siebel Financial Services Connector for ACORD P&C and Surety Guide > Siebel Connector for ACORD XML > ACORD XML Syntax and Rules >

ACORD XML Documents

Each XML document has three distinct parts:

The parts are presented as a hierarchy: the envelope is the root, which contains the header and the body. Elements of an ACORD XML document that contain other elements are called aggregates.

The envelope and header provide information required by the XML converter and by other components in the connector. The services identify the kind of business service affected by the information, and the messages provide the data that is being exchanged. There are elements that precede the message proper, which specify the versions of XML and ACORD.

Figure 4 shows a sample ACORD XML document.

Figure 4. Sample ACORD XML Document

Click for full size image

Envelope

The envelope is the root element of an XML document. For an ACORD XML document, it begins with <ACORD> and ends with </ACORD>.

The indicator <ACORD> is the only item in the envelope.

Header

Every message header has a sign-on element that authenticates the message, and it may have a sign-off element that ends a particular session.

The header has five possible elements (currently supported):

The header for a request has the header element <SignonRq>. The header for the response has the header element <SignonRs>. Similarly, the sign-off elements are specifically for requests and responses. The <Status> element provides status and error information.

NOTE:  ACORD XML messages must be either requests or responses. Requests and responses cannot be mixed in a single message. A request uses <SignonRq>. A response uses <SignonRs>.

Signon Information

The <SignonRq> or <SignonRs> header element provides a location for authentication information, date and time stamps, language preferences, and identification of the application that will use the data. You can find complete information in the ACORD specification.

Authentication Information

The initial <SignonRq> for any session must provide authentication information, typically the user name and password, or a certificate ID. When the server authenticates the user, using the information in the header, the server issues a session key in the <SignonRs>. Subsequent messages use the session key as a token. After a session has finished, any subsequent session must start with the authentication information again.

The following is an example of authentication information included in a <SignonRs> element. The response includes a session key for authentication, in the <SessKey> element, issued by the server after the initial request message was received.

<SignonRs>
<ClientDt>1001-10-02T19:21:06.9-07:00</ClientDt>
<CustLangPref>ENU</CustLangPref>
<ClientApp>
<Org>Siebel Systems, Inc.</Org>
<Name>Siebel Financial Services</Name>
<Version>7.0</Version>
</ClientApp>
<ServerDt>1001-10-02T19:21:06.9-07:00</ServerDt>
<SessKey>SNOVICEsnoviceadmin</SessKey>
<Language>ENU</Language>
<SignonRs>

Signoff Information

The <SignoffRq> and <SignoffRs> header elements are used to end a session. A typical time to end a session is at the close of business for the day.

The Signoff element, <SignoffRq> or <SignoffRs>, appears at the end of the message, just before the end of the envelope </ACORD>. The Signoff element may optionally contain a <custID> element.

<Status>

The <Status> header element may contain error codes and error messages. For additional information about the kind of information in a <Status> element, see Status Information and Error Codes.

NOTE:  Siebel Connector for ACORD XML does not at this time support the <SuppressNotificationInd>, <SuppressedNotificationInd>, and <PendingResponseInfo> header tags. Support for these tags is expected in the future, depending on customer need.

Body

The body of an ACORD XML document provides the content of the information request or response. The body serves as an aggregate containing services and messages. Services and messages, in turn, are aggregates that contain smaller elements.

Services

The basic body element is a service, for example <InsuranceSvcRq>, <BaseSvcRq>, or <SuretySvcRq>. <BaseSvcRq> is a request for the Base service, which all service providers can provide.

An ACORD body can include multiple services. A body almost always contains at least one service. A body with no service would provide only authentication.

The same service may be included in a body more than once, but each service must be for a different service provider.

The following is an example of a message with a single insurance service request.

<InsuranceSvcRq>
<RqUID>4C2D28D4-B7A5-11d 5-IC67-OOD0B77AB762</RqUID>
<SPName>com.siebel</SPName>
<PersAutoPolicyAddRq>
<RqUID>1-8XVX</RqUID>
<CurCd/>
<Producer>
<GenPartyInfo>
<NameInfo>
<CommlName>
<CommercialName>LOGONXNXN</CommercialName>
</CommlName>
</NameInfo>
</GenPartyInfo>
</Producer>
<InsuredOrPrincipal>
<GenPartyInfo>
<NameInfo>
<PersonName>
<Surname>Aaron</Surname>
<GiveName>Mary</GiveName>
</PersonName>
</NameInfo>
</GenPartyInfo>
<InsuredOrPrincipal>
<PersPolicy>
<PolicyNumber>1-21C2</PolicyNumber>
<LOBCd>Auto</LOBCd>
<ControllingStateProvCd>Auto</ControllingStateProvCd>
<CurrentTermAmt>
<Amt>100</Amt>
</CurrentTermAmt>
<RateEffectiveDt>02/14/2001 00:00:00</ RateEffectiveDt>
</PersPolicy>

. . .

<PersAutoPolicyAddRq>
<InsuranceSvcRq>

The service aggregate includes a universally unique identifier (UUID) to match responses to requests. The UUID is generated using an algorithm that makes it unique. It appears in the <RqUID> element. It is generated by the client (which sends out the request). It is stored at the client site, which then matches it to the UUID in the response message. The UUID generator can be a Siebel business service or an extension provided by a third party. In any case, the UUID generator is identified by a parameter to the FINS ACORD XML Converter.

Messages

Messages (sometimes called business messages) are contained in service aggregates. Each service can contain any number of messages.

The message tag identifies the business object that is affected by the message and a command operator. A business object can be a personal auto insurance policy, or a surety policy—anything on which an operation can be performed.

A message uses one of the following operations:

NOTE:  Additional operations—Modify, Cancel, and Delete—will be supported in future releases of Siebel Connector for ACORD XML, if future versions of the ACORD DTD supports them.

The business message name tag contains the object and the operation. For example, a business message called <PersAutoPolicyAddRq> identifies "personal auto policy" as the business object, and "add" as the operation. The details of the added policy are provided within the message.

A complete list of business messages for ACORD XML is provided in the ACORD XML implementation specification.

Data Elements

Within the business message are additional elements that identify the record that should be affected by the request or response and provide any other specifications, such as <PersonName>, <PolicyNumber>, <DriverInfo>, and <Coverage>.

The additional elements include field labels, field information, and tags that provide program access to the data.

The following illustrates data elements in an add personal auto policy request.

<PersVeh>
<ItemIdInfo>
<OtherIdentifier>
<OtherId>1-9XX1<?OtehrId>
</OtherIdentifier>
</ItemIdInfo>
<Manufacturer>Honda</Manufacturer>
<Model>Civic</Model>
<ModelYear>2000</ModelYear>
<VehBodyTypeCd>Private Passenger Vehicle</VehBodyTypeCd>
. . .
</PersVeh>

The information in the add personal auto policy request is sent to the external application, which performs the request and returns a response.


 Siebel Financial Services Connector for ACORD P&C and Surety Guide 
 Published: 18 April 2003