Conversation IDs
Learn how to format the conversation ID to track shop-to-book conversions.
Introduction
A conversation ID allows you to identify the number of shops that result in a booking. If you specify this conversation ID throughout your workflow, we can match shop-to-book conversions.
We recommend you create an in-house programming logic to create a unique conversation ID using the following best practices.
Best practices in SOAP APIs
ConversationId
is a field in the SOAP header that is meant to tie together the messages within the context of the same “conversation” – a logical user session.
Here is an example of a message header with the field ConversationId
.
<eb:MessageHeader SOAP-ENV:mustUnderstand="1 eb:version="2.0">
<eb:ConversationId >280b16ec-5eac-46c0-893f-c88f8e8cb632</eb:ConversationId>`
<eb:From>
<eb:PartyId type="urn:x12.org:IO5:01">ABC</eb:PartyId>
</eb:From>
<eb:To>
<eb:PartyId type="urn:x12.org:IO5:01">ABC</eb:PartyId>
</eb:To>
<eb:CPAId/>
<eb:Service eb:type="OTA">BargainFinderMaxService</eb:Service>
<eb:Action>BargainFinderMax_ADRQ</eb:Action>
<eb:MessageData>
<eb:MessageId>1919</eb:MessageId>
<eb:Timestamp>2016-08-12T08:34:43</eb:Timestamp>
<eb:TimeToLive>2016-08-13T08:34:43</eb:TimeToLive>
</eb:MessageData>
</eb:MessageHeader>
<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/12/utility">`
<wsse:BinarySecurityToken valueType="String" EncodingType="wsse:Base64Binary">Shared/IDL:IceSess\/SessMgr:1\.0.IDL/….</wsse:BinarySecurityToken>`
</wsse:Security>
</SOAP-ENV:Header>
Until now, Sabre was not enforcing nor using ConversationId
value in any special way, leaving the decision on using the field to the to API users.
As an attempt to standardize and improve the internal analytical capabilities, Sabre is proposing a particular design pattern for the usage of ConversationId
- it is a part of a SOAP header and should be sent together with all the Sabre Web Services requests within a customer session (Shopping, Booking, Pricing, Reservation Management, etc.).
The remaining part of the document contains usage suggestions that need to be implemented on the API consumer part.
Typical usage scenarios
In a typical interaction, end customer opens an agency Web page and is assigned a Web application session. Within that Web application session, he/she makes multiple Shopping requests followed by Booking request of one of the returned itineraries. Within the same session, there might be subsequent Sabre Web Services requests (e.g. AddRemarks
or AddPsgDetails
).
Format of the field
ConversationId
attribute is used to pass SessionId
, TrxId
and RefToTrxId
values, where
SessionId
is unique for a logical end user session.TrxId
is unique for each transaction.RefToTrxId
is not used in Shopping transactions, but in Booking transaction to designate the Shopping transaction that returned the itinerary we are trying to book.
SessionId
is not associated in anyway with the technical Sabre Web Services session.
The format of the ConversationId
is Version+”@”+SessionId+”@”+TrxId+”@”+ RefToTrxId
- where all the components are optional. Version
is to be set to V1
currently. SessionId
and TrxId
are generated by agency, and TrxId
should be unique across all agency requests, not just within the session.
Examples:
V1@280b16ec-5eac-46c0-893f-c88f8e8cb632@310b16ec-5dad-46c0-893f-c88f8e8cb643@
V1@280b16ec-5eac-46c0-893f-c88f8e8cb632@310b16ec-5dad-46c0-893f-c88f8e8cb643@780b16ec-5eac-46c0-893f-c88f8e8cb699
Additional considerations
Multiple shopping requests for single customer shop
When an OTA sends multiple BargainFinderMax
(BFM) requests triggered by single-end traveler requests, and if those requests return overlapping itineraries, the subsequent booking request might use any of the TrxId
for booking the itinerary that is shared between the responses.
Scenario:
Traveler A shops on OTA; OTA sends two BFM requests to Sabre.
ShoppingReq1(SessionId=1, TrxId=1)
Returns: Itin1
, Itin2
, Itin3
ShoppingReq2(SessionId =1, TrxId=2)
Returns: Itin2
, Itin4
To book
Itin1
: we need to sendBookingReq(SessionId =1,TrxId=3,RefToTrxId=1)
Itin4
: we need to sendBookingReq(SessionId =1,TrxId=3,RefToTrxId=2)
Itin2
: we can sendBookingReq(SessionId =1,TrxId=3,RefToTrxId=2)
orBookingReq(SessionId =1,TrxId=3,RefToTrxId=1)
Caching on agency side
Within OTA cache, there is a need to store the TrxId
of the shopping request that populated the cache and use it on the subsequent Booking transaction.
Scenario:
Traveler A charges the cache with his Shopping transaction. The cached results are later used by Traveler B to perform the booking.
Traveler A shops:
ShoppingReq1(SessionId =A, TrxId=1)
Returns: Itin1
, Itin2
, Itin3
These three itineraries are stored into the cache.
Traveler A stops shopping on OTA; Traveler B starts its session:
ShoppingReq2(SessionId =B, TrxId=2)
Returns: Itin4
, Itin5
, Itin6
Then he executes the shop that returns Itin1
, Itin2
, and Itin3
from the OTA cache.
When Traveler B wants to book
Itin1
: we need to sendBookingReq1(SessionId =B, TrxId=3,RefToTrxId=1)
Itin4
: we need to sendBookingReq2(SessionId =B, TrxId=4,RefToTrxId=2)
Usage of Sabre Shopping Cache is not impacting the way ConversationId
is to be used – the customer using Sabre Cache should treat such requests as a standard BFM request in this context.
Working with Meta search sites
If OTA is able to associate redirected customers with initial meta search, it will be beneficial to use the same SessionId
on both Meta initiated request and the request that are sent after the redirect. If such an association is not possible, keeping separate SessionIds
or not using SessionId
on Meta requests is acceptable.
The following diagram assumes meta requests cannot be identified as belonging to the same traveler session. The alternative situation will allow OTA to combine XYZ and ABC sessions into one.
Long running customer sessions
For OTA WebApp session spanning longer periods (e.g. days), there is no need to maintain the same SessionId
on Shopping transactions across multiple days.
Blind sells
For blind sells, we might or might not have a SessionId
; but we will not have RefToTrxId
, so the Booking transaction will be executed with an empty RefToTrxId
attribute.
Benefits
Enhancing OTA’s end-to-end flow by adding ConversationId
will benefit both customers and Sabre.
The key benefit for customers includes improvement in conversion management by
- Intelligent airline polling control
- Support in customer A/B testing capabilities
- Analyzing conversion parameters per product/service
- Shopping Cache fine tuning
- Accurate failure rate management (identifying blind sells/cache issues)