| Bookshelf Home | Contents | Index | PDF | |
|
Siebel Financial Services Connector for IFX XML Guide > Siebel Connector for IFX XML > IFX XML Syntax and Rules > IFX XML DocumentsEach 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. The following example shows a sample IFX XML document: <?xml version="1.0" encoding="UTF-8" ?> EnvelopeThe 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. HeaderEvery 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 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 InformationThe <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 InformationThe 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. Following is an example of an initial SignonRs authentication element. <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 IFX XML Status Information and Error Codes. Signoff InformationThe 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. BodyThe 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.
ServicesThe 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. Following is an example of a message with a single payment service request. <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. MessagesMessages (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—anything on which an operation can be performed. A message uses one of the following operations: 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 ElementsWithin the business message are additional elements that identify the record that will 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. Following is an example of data elements for the add payment request. <PmtAddRq> The information in this request is sent to the external application, which performs the request and returns a response. |
 |
|
| Siebel Financial Services Connector for IFX XML Guide | Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices. | |