Siebel eFinance for Teller Connector to IBM WebSphere Business Component Composer Guide > Teller IFX XML Connector > IFX XML Syntax and Rules >

IFX XML Documents

Each IFX 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 IFX 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 IFX.

Sample IFX XML Document

<?xml version="1.0" encoding="UTF-8" ?>
<?ifx version="1.0.1" oldfileuid="00000000-0000-0000-0000- 000000000000" newfileuid="11111111-1111-1111-1111-111111111111"
?>
<IFX>
<SignonRq>
<SessKey>ABCDEFGHIJKLMNOPQRSTUVWXYZYXWVUTSRQPONML</ SessKey>
<ClientDt>2001-10-10T17:04:33.0-07:00</ClientDt>
<CustLangPref>ENU</CustLangPref>
<ClientApp>
<Org>Customer Organization</Org>
<Name>Siebel FINS</Name>
<Version>7.0</Version>
</ClientApp>
</SignonRq>
<PaySvcRq>
<SPName>IFX Service Provider</SPName>
<RqUID>7796AAAA-685E-47b0-9C2F-27FB475B05FA</RqUID>
<PmtAddRq>
<RqUID>83DA5F9C-7781-4ebb-BB62-311B8B9C6AD7</RqUID>
<PmtInfo>
<RemitInfo>
<CustPayeeId>SibelCustomerBank</CustPayeeId>
<CurAmt>
<Amt>500</Amt>
<CurCode>US</CurCode>
</CurAmt>
</RemitInfo>
<DepAcctIdFrom>
<AcctId>2547-86392</AcctId>
<AcctType>CDA</AcctType>
<BankInfo>
<Name>SiebelCustomerBank</Name>
</BankInfo>
</DepAcctIdFrom>
<DueDt>2001-12-24</DueDt>
</PmtInfo>
<DupChkOverride>1</DupChkOverride>
</PmtAddRq>
</PaySvcRq>
</IFX>

Envelope

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

The indicator <IFX> 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 four terms:

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.

NOTE:  IFX 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 status information, 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 IFX 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 an initial SignonRs authentication element.

<SignonRq>
<SignonPswd>
<CustId>
<SPName>com.siebel</SPName>
<CustLoginId>RLIU</CustLoginId>
</CustId>
<CustPswd>
<CryptType>NONE</CryptType>
<Pswd>DROWSSAP</Pswd>
</CustPswd>
<GenSessKey>1</GenSessKey>
</SignonPswd>
<ClientDt>2001-11-16T16:56:39.0-08:00</ClientDt>
<CustLangPref>ENU</CustLangPref>
<ClientApp>
<Org>Siebel FINS</Org>
<Name>Siebel FINS Application</Name>
<Version>7.0</Version>
</ClientApp>
</SignonRq>

Additional elements may be included in a <Signon> element. You can find complete information in the IFX specification.

Status information, which includes error codes, may also appear in the <Signon> element. Status information is discussed in Status Information and Error Codes.

<Signoff> Information

The <Signoff> header element is 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 </IFX>. The <Signoff> element may optionally contain a <custID> element.

Body

The body of an IFX 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 <PaySvcRq>, <BaseSvcRq>, or <BankSvcRq>. <BaseSvcRq> is a request for the base service, which all service providers can provide.

An IFX 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 payment service request.

<PaySvcRq>
<SPName>Partner IFX Middleware</SPName>
<RqUID>50DBF4F7-7888-480b-927E-333652FEBF87</RqUID>
<PmtAddRq>
<RqUID>BD620AC4-53E7-4UIL-588C-YOR8D6224FE9</RqUID>
<PmtInfo>
<RemitInfo>
<CustPayeeId>0VF-VEBQ</CustPayeeId>
<CurAmt>
<Amt>2500</Amt>
<CurCode>USD</CurCode>
</CurAmt>
</RemitInfo>
<CardAcctIdFrom>
<AcctId>2574-86392</AcctId>
<AcctType>Savings/MMA</AcctType>
</CardAcctIdFrom>
<DueDt>2001-11-13</DueDt>
</PmtInfo>
<DupChkOverride>1</DupChkOverride>
</PmtAddRq>
</PaySvcRq>

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 IFX Converter.

Messages

Messages (sometimes called business messages) are contained in Service aggregates. Each service can contain one or more business messages. 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 payment or a cash drawer or anything on which an operation can be performed.

A message uses one of the following operations:

  • Add
  • Modify
  • Delete
  • Audit
  • Cancel
  • Synchronize
  • Inquiry

 

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

A complete list of business messages for IFX XML is provided in the IFX 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 <CustName>, <PostAddr>, <FirstName>, and <LastName>.

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

The following sample shows data elements for the add payment request.

<PmtAddRq>
<RqUID>BD620AC4-53E7-4UIL-588C-YOR8D6224FE9</RqUID>
<PmtInfo>
<RemitInfo>
<CustPayeeId>0VF-VEBQ</CustPayeeId>
<CurAmt>
<Amt>2500</Amt>
<CurCode>USD</CurCode>
</CurAmt>
</RemitInfo>
<CardAcctIdFrom>
<AcctId>2574-86392</AcctId>
<AcctType>Savings/MMA</AcctType>
</CardAcctIdFrom>
<DueDt>2001-11-13</DueDt>
</PmtInfo>
<DupChkOverride>1</DupChkOverride>
</PmtAddRq>

The information in this request is sent to the external application, which performs the request and returns a response.


 Siebel eFinance for Teller Connector to IBM WebSphere Business Component Composer Guide 
 Published: 18 April 2003