XX1 Client Development Concepts
This chapter discusses important base concepts that apply to all client libraries and interfaces.
Methods
XX1 Server always provides only 3 interface methods
- GetSession
- Transaction
- ReleaseSession
Method Parameters
All method parameters are expected to be in XML format. The parameters for the Transaction method are
- Transaction Control Data (TC)
- Request Message
- Response Message
GetSession and ReleaseSession usually only take Transaction Control Data parameters. The use of GetSession and ReleaseSession is optional and should be applied only when it becomes necessary to lock a session context or resource of the provider system.
Transaction Control Data (TC)
The transaction control data (TC) XML is part of each transaction, is located in the SOAP header and allows you to control the underlying provider the message is to be routed to. It is also used for user authentication on transaction level.
<tc>
<iden u="YOURUSERNAME" p="YOURPASSWORD"/>
<provider session="AB12_PROD" group="XY89">SabreWS</provider>
<requestID>9ABD-4D9D-80C7-02AF85C822A8</requestID>
<trace>YOURTRACENAME</trace>
</tc>
| Element/Attribute | Description |
|---|---|
| /tc/iden | User authentication. Required if security filter is configured on XX1. |
| /tc/iden/@u | User ID |
| /tc/iden/@p | User Password |
| /tc/provider | Identifies provider system by logical system name as configured on XX1. Example: AmadeusWS |
| /tc/provider/@session | Logical session name as configured within provider adaptor set-up on XX1. Not needed for transactions which do not require resources on provider systems. Example: ABCD_PROD |
| /tc/provider/@system | In addition to the provider name this attribute can be used to identify the provider by its code. As a provider adapter can be used with more than one provider system in some cases (e.g. GalileoWS adapter can be used for ApolloWS and GalileoWS systems) this attribute is required to clearly identify the actual system. Handling could be however implementation specific - contact XX1-Team for details. |
| /tc/provider/@group | Used to specify target PCC/OfficeID/SID for emulation in case the transaction should be executed in a different agency environment than the one that is currently used as configured by /tc/provider/@session |
| /tc/provider/@reset | Identifier flag. If set to 'yes' causes server to send an "ignore" or in general refresh a context on the target before execution of the payload message. Except if you know what you aim for you should not set this attribute but rely on the default settings that are set for each message in the transactionmaps for each adapter. |
| /tc/POS | This structure and its subelements can be necessary for some adapters e.g. to override the default configuration or to specify required details for point of sale definition. |
| /tc/requestID | An optional identifier created by the client application to identify a specific request or series of requests to XX1. The requestID is part of the records written to the transaction log file (if configured) or CSV-logs and can be a very helpful tool to identify client workflow and requests. We definitly recommend to set this parameter. It is in the responsibility to set values, that are unique. We recommend to generate GUIDs here. The maximum length for this value can be 32 chars. |
| /tc/correlationID | An optional identifier created by the client application to identify the coherency of a series of requests to XX/1. The correlationID is part of the records written to the transaction log file (if configured) or CSV-logs and can be a very helpful tool to identify client workflow and requests that belong together within a longer workflow. We definitly recommend to set this parameter. It is in the responsibility to set values, that are unique. We recommend to generate GUIDs here. The maximum length for this value can be 32 chars. |
| /tc/trace | XXTraceConsole identification key. Is used to identify the XX1 traffic that should be shown in the XXTraceConsole. |
Request Message
XML document with request data and parameters. The root node of the request XML identifies the message, and hence the business function or procedure to be invoked.