3Siebel Connector for ACORD XML

Siebel Connector for ACORD XML

This chapter describes the methods, input arguments, and output arguments for configuring the components of a Siebel Connector for ACORD XML.

The Siebel Connector for ACORD XML consists of the following components:

• Transaction manager

• Transformation engine

• Converter

• Dispatcher

• Transport adapter

The following image shows the connector components.

The connector components are Siebel business services, which are configured in the Workflow view. The integration objects are created using the FINS ACORD Wizard, and they are configured using the Data Map editor.

Note: For information about Siebel integration objects, converter elements, and XML, see XML Reference: Siebel Enterprise Application Integration.

ACORD XML Syntax and Rules

ACORD P&C and Surety is an insurance-industry version of XML. It is used for messages that are appropriate for Property and Casualty (P&C) and Surety forms of insurance.

The ACORD standard defines the required structure and format of an XML message for use in a Siebel connector. The definition is in the ACORD DTD, and the ACORD DTD is incorporated by the Siebel connector to construct messages.

This section provides a summary of the ACORD XML syntax and rules, and provides the appropriate vocabulary for discussing ACORD XML messages. This section supplies knowledge that is basic for any troubleshooting you may need to do.

ACORD XML Documents

Each XML document has three distinct parts:

• Envelope

• Header

• Body

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.

The following image shows a sample ACORD XML document.

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

• SignonRq

• SignonRs

• SignoffRq

• SignoffRs

• Status

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>Oracle/Org>

                  <Name>Siebel Financial Services</Name>

                  <Version>8.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 <cust ID> 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.

• Service. A service identifies the kind of service being requested or delivered, and identifies the business function that will be affected. For example <InsuranceSvcRq> is a request for an insurance service.

• Message. A message identifies the business object affected by the message and the operation that is to be performed on the data. For example, <PersAutoPolicyAddRq> is a request to add a personal automobile policy.

• Data Element. A data element identifies the business component or fields affected by an operation defined in the message. For example, <PersVeh> is a data element that contains information about a vehicle.

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:

• Add

• Inquiry

• Submit

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

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

Status Information and Error Codes

Status information is information about the current status of a message. It appears only in response documents. It can appear in a response header or in any body element. In the header, it appears in a <Status> tag. In messages in the body, it appears in a <MsgStatus> tag.

Status information in the header applies to the entire ACORD XML document. Status information in a service applies to that service. Status information in a message applies to that message.

The external server generates status information after processing the document. If the processing is satisfactory, status information may or may not be generated. If there is a problem in the processing, the status information identifies the problem.

For details of status codes, see the ACORD XML Business Message specification, which describes the status codes.

The following is an example of status information in a message. Note that it uses the <MsgStatus> tag.

		<MsgStatus>
							<MsgStatusCd>Error</MsgStatusCd>
							<MsgErrorCd>FINS IXML Transaction Manager: Multiple matches found
							for instance of integration component ‘Ins Policy_Position’ using
							search specification ‘[Active Login Name]=”VSILVER”’ in the 
							business component ‘Position’, based on user key ‘User Key:1’.
							</MsgErrorCd>
		</MsgStatus>

The <MsgStatusCd> information, such as “Error,” “Rejected,” or “Success,” shows the result of processing. If the value of <MsgStatusCd> is “Error,” <MsgErrorCd> provides additional details.

FINS ACORD Wizard

Siebel Business Applications provide wizards to guide you through the process of building integration objects and updating dispatcher maps.

You can use the FINS ACORD Wizard to build integration objects for Siebel Connector for ACORD XML. The wizard guides you through the process of selecting objects (from the Siebel repository or from an external system) on which you can base your new Siebel integration object. The wizard builds a list of valid components from which you choose the specific components to be included in your Siebel integration object.

You access Siebel wizards within Siebel Integration Object Builder in Siebel Tools. Use the FINS ACORD XML Wizard to create an appropriate elements hierarchy that works with the ACORD DTD. The wizard:

• Creates a set of integration objects to handle outbound and inbound messages and to handle internal and external integration.

• Updates the dispatcher map, which is later used by the dispatcher.

Integration Objects

Siebel integration objects allow you to represent integration metadata between a Siebel business object and an external XML standard, using the FINS ACORD XML Data Transformation Engine (DTE). The integration object represents a common structure that the EAI infrastructure can understand.

Because these integration objects adhere to a set of structural conventions, they can be traversed and transformed programmatically, using Oracle’s Siebel eScript objects, methods, and functions, or transformed declaratively using Siebel Data Mapper.

To use Siebel Connector for ACORD XML to integrate data, you need to build three different integration objects:

ACORD Envelope Integration Object. An envelope integration object provides envelope and header information for an ACORD XML document.

User properties in an ACORD envelope provide flexibility to the connector. For example, when a user sends an initial ACORD request, the ACORD document uses a <SignonRq> header that is different from subsequent <SignonRq> headers. Two different integration component user properties, initsignon and sessionsignon, can be used to construct different headers under the same envelope. See Configuration Roadmap for an example of creating an envelope integration object.

ACORD Internal Integration Object. An internal integration object represents the Siebel business object hierarchy for a particular Siebel business object. See Configuration Roadmap for an example of creating an internal integration object.

ACORD External Integration Object. An external integration object represents the ACORD XML hierarchy for a particular ACORD message. See Configuration Roadmap for an example of creating an external integration object.

FINS ACORD XML Dispatcher Map

The dispatcher map is used by the FINS ACORD XML Dispatcher. The dispatcher map is an integration object that provides a rule set for handling incoming ACORD XML messages. The dispatcher map is created and updated by the FINS ACORD Wizard during the process of creating external and internal integration objects.

The map contains information that associates message instances with the appropriate internal and external integration objects for incoming and outgoing messages. It associates each incoming or outgoing message with all the Siebel Connector for ACORD XML elements that are necessary to translate it into Siebel data.

The map contains DTE map names, the internal integration object names, the external integration object names, and transaction manager operations. These elements make up the translation scheme for the message instance. The dispatcher map allows the dispatcher to associate the proper translation scheme with each message instance.

All the mapping information is stored in the user property part of the dispatcher map integration object.

FINS ACORD XML Transaction Manager

The FINS ACORD XML Transaction Manager is responsible for data transactions with a Siebel database. It may invoke the Siebel adapter or another business service configured in its user properties. It is an adapter that resides logically between the Siebel object manager and the rest of the connector. It executes operations specified in an XML message instance as Siebel database transactions.

The transaction manager translates XML command elements into Siebel Adapter operations. The transaction manager either carries out the operation or finds another business service to carry out the operation.

The transaction manager combines return results as a single property set. A property set is an intermediate data store that can be used in subsequent operations within the connector.

For inbound processing, the transaction manager accepts an ACORD XML property set, which may contain multiple integration object instances for multiple transactions. It pairs each individual transaction request with an integration object instance and invokes methods in Siebel EAI Adapter.

For outbound processing, the transaction manager pairs a transaction request with an integration object instance and sends an ACORD XML property set to the FINS ACORD XML DTE.

Transaction Manager User Properties

The following table describes the user properties for the FINS ACORD XML Transaction Manager.

Name	Value	Description
IgnoreSvcMethodArgs	true, false	To enable the runtime input arguments, use false.
SaveInFileForRollback	<filename>	The file name in which to save the current record for future rollback.
SaveInMemForRollback	<session key>	The session key to set or look up in memory.
XXX (Operation) such as SAUpsert, SAQuery, and so forth.	ServiceName/MethodName/Argument, such as “EAI Siebel Adapter/Delete/RollbackOnSame;”	Indicates the operation to be executed. Format is ServiceName/MethodName/Arguments.

Transaction Manager Methods and Arguments

The ACORD XML transaction manager methods and arguments are explained in the following tables. The following table describes the transaction manager methods.

Method	Display Name	Function
Execute	Execute Transaction	Can be used for inbound or outbound messages when the integration object instance is provided. When only Row_Id is available, use the Execute Outbound method.
ExecuteOutbound	Execute Outbound	Executes an outbound operation specified in input arguments.
ExecuteSave	Execute and Save	Executes an outbound operation specified in input arguments and saves the transaction result in memory or in a file.

The Method Arguments for the following table describes the arguments for the FINS ACORD XML Transaction Manager.

Argument	Value	Description
OnlyIOI	true, false	For an inbound message, the integration object instance for request may contain header, body, and envelope portions. When the transaction manager takes the proper operation against the Siebel database, the integration object instance for response is generated as well. If this value is set to “true,” all non-message information from the request message is dropped so the converter and the DTE do not need to deal with, for example, header information. If this value is set to “false,” all request information is carried over.
XMLHierarchy	< Input/Output XML Property Set>	The property set holder for input and output hierarchies.
RollbackInError	true, false	Indicates whether the operation will be rolled back for recovery if an error condition exists.
IXMLMapPath	<Entry key for the dispatcher map>	Stores the key value for the dispatcher map. The transaction manager uses it to look up the value for the integration object instance.
PrimaryRowId	<RowID of a Siebel object>	The primary row ID of the Siebel object that is used by the Siebel adapter to execute a query operation on the Siebel database.
SiebelFINS OperationOut	<Operation name from user property>	The operation to be used by the transaction manager, which is predefined in the user properties of the transaction manager.
SearchSpec	<Search spec>	The search specification for a query that is used by the Siebel adapter to execute a query operation on the Siebel database.
ReportErrorInMsg	true, false	The default value is “false.” If it is set to “true,” the transaction manager generates an error object within the output hierarchy.

The following table provides specifications for the Execute method arguments.

Argument	Display Name	Data Type	Type	Optional
OnlyIOI	Produce only an integration object instance	String	Input	Yes
XMLHierarchy	XML Property Set	Hierarchy	Input or Output	No
RollbackInError	Rollback In Error	String	Input	Yes
ReportErrInMsg	Report Error In Message	String	Input	Yes

The following table provides specifications for the Execute Outbound method arguments.

Name	Display Name	Data Type	Type	Optional
IXMLMapPath	IXML Map Path	String	Input	No
PrimaryRowId	Primary Row Id	String	Input	Yes
SiebelFINS OperationOut	Outbound Operation	String	Input	No
SearchSpec	Search Specification	String	Input	Yes
XMLHierarchy	XML Property Set	Hierarchy	Output	No

The following table provides specifications for the Execute Save method arguments.

Name	Display Name	Data Type	Type	Optional
IXMLMapPath	IXML Map Path	String	Input	No
PrimaryRowId	Primary Row Id	String	Input	Yes
SiebelFINS OperationOut	Outbound Operation	String	Input	No
SearchSpec	Search Specification	String	Input	Yes
RollbackInError	Is Rollback in Error	String	Input	Yes
PlaceToSave	Place To Save	String	Input	No
XMLHierarchy	XML Property Set	Hierarchy	Output	No

FINS ACORD XML Data Transformation Engine (DTE)

The FINS ACORD XML DTE transforms property sets in a Siebel internal integration hierarchy to an external integration object hierarchy, and vice versa. This function allows the FINS ACORD XML Converter to exchange data between two systems with different data models. The transformation map is defined at run time from Siebel Administration views.

For inbound processing, the DTE accepts a property set from the FINS ACORD XML Converter and transforms it into a property set to be used by the FINS ACORD Transaction Manager. The incoming property set is made up of one or more external integration object instances. If there are multiple instances, the DTE parses them into individual instances and transforms them. The DTE then packages the returned transformed instances as an output property set as internal integration object instances.

For outbound processing, the DTE accepts a property set from the transaction manager and transforms it into a property set to be used by the converter. The outgoing property set is made up of one or more internal integration object instances. The DTE then packages the returned transformed instances as an output property set as external integration object instances.

DTE Methods and Arguments

The FINS ACORD XML DTE methods and arguments are described in the following tables. The following table describes the DTE methods.

Method	Display Name	Function
ToExternal	Transform To External Hierarchy	Transforms a Siebel hierarchy into an external hierarchy.
ToInternal	Transform To Siebel Hierarchy	Transforms an external hierarchy into a Siebel hierarchy.

The following table describes the arguments for the DTE methods.

Argument	Value	Description
XMLHierarchy	XML Property Set	For ToExternal, takes as input the output of the Execute outbound method of the transaction manager. Sends an output hierarchy that contains the XML document in Siebel external integration object format. For ToInternal, takes as input the output of the XMLPropetySetToPropertySet method of the converter. Sends an output hierarchy that contains the ACORD document in Siebel internal integration object format.
MapArgs>		Run-time input arguments that can be used by DTE maps when a map is called from a workflow. See the explanation in the following section.

The following table provides specifications for the ToExternal method argument.

Name	Display Name	Data Type	Type	Optional
XMLHierarchy	XML Property Set	Hierarchy	Input or Output	No

The following table provides specifications for the ToInternal method argument.

Name	Display Name	Data Type	Type	Optional
XMLHierarchy	XML Property Set	Hierarchy	Output	No

Using <MapArgs>

<MapArgs> is a runtime input argument used by the DTE map to match an integration map argument of an integration object map. The FINS ACORD XML DTE can take as many <MapArgs> as needed as long as each name is unique among all the <MapArgs> that are passed to the FINS ACORD XML DTE at the same time.

For example, suppose that the output integration object instance has some fields mapping to a workflow process property, such as an ID field.

1. Using the Data Map view, select the integration map to edit in the Integration Object Map applet.

2. In the Integration Map Argument applet, create the map and set the following values:

   1. Name = CompId

   2. Data Type = “DTYPE_TEXT”

   3. Display Name = Component ID

3. In the Integration Field Map applet, set the following values:

   1. Target Field Name = [Id]

   2. Source Expression = [&CompId]

4. In the workflow, set the data transformation engine input argument as follows:

   1. Input Argument = CompId

   2. Type = Process Property

   3. Property Name = Object Id

At runtime, the DTE replaces [&CompId] with the value of the Object ID.

For some mappings, if the DTE cannot find the source field value, the DTE creates empty tags by default. To remove the empty tags, add IgnoreEmptyTag as the map argument.

For complete information, see Business Processes and Rules: Siebel Enterprise Application Integration.

FINS ACORD XML Converter

The purpose of the FINS ACORD XML Converter is to generate and process ACORD-specific elements, such as the <SignonRq> aggregate and the <SignonRs> aggregate.

The FINS ACORD XML Converter receives hierarchy output and converts it into a property set or an XML string.

Converter User Properties

The following table describes the FINS ACORD XML Converter user properties.

Name	Value	Description
PI_Parameter:PI_Name	<PI_Value>	PI_Parameter: is a constant prefix. PI_Name=PI_Value would be a PI name-value pair included in ACORD PI. Zero or more pairs can be defined. Examples: PI_Parameter:newfileuid PI_Parameter:oldfileuid PI_Parameter:version
PI_Type	ACORD	Process instruction type
XMLEnvIntObjectName	<Integration object name>	Integration object name that defines the ACORD envelope.

Converter Methods and Arguments

The FINS ACORD XML Converter methods and arguments are described in the following tables. The following table describes the FINS ACORD XML Converter methods.

Method	Display Name	Description
PropSetToXML	PropSetToXML	Generate the XML message to be sent.
PropSetToXMLPropSet	PropSetToXMLPropSet	Prepare the DOM structure of the XML message to be sent.
XMLPropSetToPropSet	XMLPropSetToPropSet	Convert the XML message received into hierarchical property sets.
XMLToPropSet	XMLToPropSet	Prepare the hierarchical property sets from the DOM structure of the XML message received.
ErrorHandler	ErrorHandler	Generate a response ACORD message with detailed error information for an operation error.

The following table describes the arguments common to FINS ACORD XML Converter methods.

Argument Name	Value	Comments
ClientApplicationOrganization	<Client application organization name>	The value for <Org> in <ClientApp>
ClientApplicationName	<Client application name>	The value for <Name> in <ClientApp>
ClientApplicationVersion	<Client application version>	The value for <Version> in <ClientApp>
IsClient	true, false	“True” if Siebel FINS is behaving as an ACORD client. “False” if Siebel FINS is behaving as an ACORD server.
IsSignoff	true, false	If “true,” the converter generates a SignoffRq aggregate for the current ACORD document. If “false,” the converter does not generate a SignoffRq aggregate.
ServiceProviderName	<ACORD service provider name>	The value will be used as the value of <SPName> in <SignonRq> aggregate.
XMLEnvIntObjectName	<Name of the envelope integration object>	Name of the integration object that defines ACORD envelope.
SignonRsEcho	Property Set storing echo values from <SignonRq>	Those echo values are used by SignonRs header.
initsignon	<Integration component user property of envelope integration object>	Determine which user property in envelope integration object will be used to construct initial SignonRq header.
sessionsignon	<Integration component user property of envelope integration object>	Determine which user property in envelope integration object will be used to construct subsequent SignonRq header.
signonRs	<Integration component user property of envelope integration object>	Determine which user property in envelope integration object will be used to construct SignonRs header.
signoffRq	<Integration component user property of envelope integration object>	Determine which user property in envelope integration object will be used to construct SignoffRq header.
signoffRs	<Integration component user property of envelope integration object>	Determine which user property in envelope integration object will be used to construct SignoffRs header.
ErrorCode	<Error code value>	The error code during operation to be set in the ACORD Status header.
ErrorMessageText	<Error message text>	The actual error message during operation to be set in the ACORD Status header.
GeneralErrorMessageText	<Error message text>	The generic error text to be pre-appended to the actual error text. For example, “The error happens before the transaction manager.”

The following table provides specifications for the PropSetToXML method arguments.

Name	Display Name	Data Type	Type	Optional
ClientApplicationOrganization	Client Application Organization	String	Input	Yes
ClientApplicationName	Client Application Name	String	Input	Yes
ClientApplicationVersion	Client Application Version	String	Input	Yes
IsClient	Is Client	String	Input	Yes
IsSignoff	Is Signoff	String	Input	Yes
ServiceProviderName	Service Provider Name	String	Input	Yes
XMLHierarchy	XML Property Set	Hierarchy	Input	No
<Value>	XML Document	String	Output	No
XMLEnvIntObjectName	XMLEnvIntObjectName	String	Input	Yes
SignonRsEcho	SignonRsEcho	Hierarchy	Input	Yes
initsignon	initsignon	String	Input	Yes
sessionsignon	sessionsignon	String	Input	Yes
signoffRq	signoffRq	String	Input	Yes
signonRs	signonRs	String	Input	Yes
signoffRs	signoffRs	String	Input	Yes

The following table provides specifications for the PropSetToXMLPropSet method arguments.

Name	Display Name	Data Type	Type	Optional
ClientApplicationOrganization	Client Application Organization	String	Input	Yes
ClientApplicationName	Client Application Name	String	Input	Yes
ClientApplicationVersion	Client Application Version	String	Input	Yes
IsClient	Is Client	String	Input	Yes
IsSignoff	Is Signoff	String	Input	Yes
ServiceProviderName	Service Provider Name	String	Input	Yes
XMLHierarchy	XML Property Set	Hierarchy	Input/output	No
XMLEnvIntObjectName	XMLEnvIntObject Name	String	Input	Yes
SignonRsEcho	SignonRsEcho	Hierarchy	Input	Yes
initsignon	initsignon	String	Input	Yes
sessionsignon	sessionsignon	String	Input	Yes
signoffRq	signoffRq	String	Input	Yes
signonRs	signonRs	String	Input	Yes
signoffRs	signoffRs	String	Input	Yes

The following table provides specifications for the XMLPropSetToPropSet method argument.

Name	Display Name	Data Type	Type	Optional
XMLHierarchy	XML Property Set	Hierarchy	Input/Output	No

The following table provides specifications for the XMLToPropSet method arguments.

Name	Display Name	Data Type	Type	Optional
<Value>	XML Document	String	Input	No
XMLHierarchy	XML Property Set	Hierarchy	Input/Output	No

The following table provides specifications for the ErrorHandler method arguments.

Name	Display Name	Data Type	Type	Optional
ErrorCode	ErrorCode	String	Input	No
ErrorMessageText	ErrorMessageText	String	Input	No
GeneralErrorMessageText	GeneralErrorMessageText	String	Input	Yes
XML Hierarchy	ErrXMLHierarchy	Hierarchy	Input/Output	Yes

FINS ACORD XML Dispatcher

The FINS ACORD XML Dispatcher handles inbound XML hierarchy instances. It provides the necessary information for subsequent modules to perform their operations, such as the integration objects to be used.

The dispatcher identifies incoming messages and parses them into header and envelope sections. It also analyzes incoming message body sections, walking through each command. Using the dispatcher map, the dispatcher associates each message with the appropriate external integration object so that the FINS ACORD XML Converter can use it. It also associates the message with the DTE map so that the FINS ACORD XML DTE can use it.

Dispatcher User Properties

The following table shows the user properties for the dispatcher.

Name	Value	Comments
DispatcherMapName	<Integration Object name>	Name of an integration object that details the dispatching rules and syntax for the ACORD XML standard. This map is usually created along with all the other integration objects needed by the wizard. The default map name is ACORDDispMap.
XMLEnvIntObjectName	<Integration Object name>	Name of an integration object that defines the content and hierarchy for the envelope and header sections of the ACORD message.
XMLFaultObject_X, such as XMLFautlObject_0, XMLFaultObject_1, and so forth.	<path to fault section or element>	Location for fault object. For example, //IOI/MsgStatus/MsgErrorCd. This allows the dispatcher to identify a fault section through the path. Extra fault objects can be added by incrementing the name with _1, _2, and so on.

Dispatcher Methods and Arguments

The FINS ACORD XML Converter methods and arguments are described in the following tables. The following table describes the FINS ACORD XML Dispatcher method.

Method	Display Name	Description
DispatchMessage	DispatchMessage	Validates the incoming XML message. If the message conforms to the dispatching rules, the integration object names and other necessary information will be attached to the message. It also checks for the envelope, header, and fault sections of the message and identifies them.

The following table describes the argument for the DispatchMessage method.

Argument	Value	Description
XMLHierarchy	Hierarchy name.	Property set in external integration object XML hierarchy.

The following table provides specifications for the DispatchMessage method argument.

Name	Display Name	Data Type	Type	Optional
XMLHierarchy	XML Hierarchy	Hierarchy	Input/Output	No

Transport Adapter

The transport adapter is a Siebel business service that provides the interface between the outside data source and the Siebel connector. The connector can use any of the following standard transport mechanisms:

• MQSeries

• MQSeries AMI

• HTTP

• MSMQ

For details about the transport adapter, see Transports and Interfaces: Siebel Enterprise Application Integration.