Sabre Profiles

Sabre Profiles
Technical User Guide
February 2019
© 2019, Sabre Inc. All rights reserved.
Document Revision: 201928002.1.0
This documentation is the confidential and proprietary intellectual

property of Sabre Inc. Any unauthorized use, reproduction,
preparation of derivative works, performance, or display of this
document, or software represented by this document, without the
express written permission of Sabre Inc. is strictly prohibited.
Sabre and the Sabre logo design are trademarks and/or service
marks of an affiliate of Sabre Inc. All other trademarks, service
marks, and trade names are owned by their respective
companies.
Table of Contents
Introduction ........................................................................ 1
About this Guide ....................................................................................................................................... 1

Standards and Specifications ................................................................................................................... 1
About Sabre Profiles Web Services ......................................................................................................... 2
Security .................................................................................................................................................... 3
Line Security ........................................................................................................................................ 4
Authentication ...................................................................................................................................... 4
Authorization ....................................................................................................................................... 5
Confidentiality ...................................................................................................................................... 5
Network Connectivity................................................................................................................................ 5
Web Services Sessions............................................................................................................................ 5
SessionCreateRQ Request XML Example .......................................................................................... 5
The Envelope ...................................................................................................................................... 5
The SOAP Payload ............................................................................................................................. 6
The SOAP Envelope ........................................................................................................................... 7
Ending the Session.............................................................................................................................. 8
Credit Card Data Security ........................................................................................................................ 9
Access ................................................................................................................................................. 9
Storage and Internal Security Measures ........................................................................................... 10
Technical Support .................................................................................................................................. 10
Email ................................................................................................................................................. 10
Additional Support ............................................................................................................................. 11
Accessing Sabre Profiles Web Services .................................. 12
Activation................................................................................................................................................ 12
Types of Web Services .......................................................................................................................... 13
Session Management Services ......................................................................................................... 14
Sabre Profiles Services ..................................................................................................................... 14
Domain Access Rules ............................................................................................................................ 17
Message Structure ................................................................................................................................. 17
Requesting Payload Content .................................................................................................................. 18
Sabre Profile Access validation by PCC................................................................................................. 20
Web Services Error Handling ................................................................................................................. 21
Sabre Profile Types ............................................................ 24
Profile Types .......................................................................................................................................... 24

Traveler .................................................................................................................................................. 24
Logic for specific schema elements/attributes within the Profile ........................................................ 25
Operational............................................................................................................................................. 27
Corporate ............................................................................................................................................... 27
Sabre Profiles Technical User Guide February 2019 Confidential and Proprietary Sabre Inc. iii
Group ..................................................................................................................................................... 27
Agency ................................................................................................................................................... 28
Agent ...................................................................................................................................................... 28
Replication of Sabre Host EPRs into Agent Profiles .......................................................................... 28
Audit information tracking using AccessInfo in the API .......................................................................... 30
Common attributes within the Payload ................................................................................................... 31
ClientContextCode ............................................................................................................................ 31
Profile SubTypes ............................................................................................................................... 32
How to Determine the Profile Data Needed ........................................................................................... 33
Use of Dictionary Control Table Values.................................................................................................. 33
Use of Status codes ............................................................................................................................... 35
Domain “Status”................................................................................................................................. 35
Profile “Status” ................................................................................................................................... 36
Profile Associations ................................................................................................................................ 36
Common Rules and Elements across Profile Types .............................................................................. 37
Common Elements and Attributes ..................................................................................................... 41
Management of Non-standard English Characters ............................................................................ 42
Profile UniqueID ..................................................................................................................................... 43
Create Service ................................................................... 44
Creating Profiles ..................................................................................................................................... 44

How to Create a Profile ..................................................................................................................... 44
Sample XML Create Profile Request ................................................................................................. 44
Sample XML Create Profile Successful Response ............................................................................ 46
Sample XML Create Profile Error Response ..................................................................................... 46
Read Service ..................................................................... 48
Reading Profiles ..................................................................................................................................... 48

Sample XML Read Successful Response ......................................................................................... 52
Credit Card Tokenizer ....................................................................................................................... 52
Sample XML Read Error Response .................................................................................................. 54
Update Service .................................................................. 56
Updating Profiles .................................................................................................................................... 56

How to Update a Profile using Full Replace ...................................................................................... 62
How to Update a Profile ignoring time stamp check .......................................................................... 63
Sample XML Update Successful Response ...................................................................................... 64
Sample XML Update Error Response ............................................................................................... 64
Search Service .................................................................. 66
Searching for Profiles ............................................................................................................................. 66

Online Profile Search......................................................................................................................... 66
Sabre Profiles Technical User Guide February 2019 Confidential and Proprietary Sabre Inc. iv
Offline Profile Search......................................................................................................................... 75
Delete/Restore Service ........................................................ 90
Deleting and Restoring Profiles .............................................................................................................. 90

Sample XML Profile Delete Request ................................................................................................. 90
Sample XML Profile Delete Successful Response ............................................................................ 91
Sample XML Profile Delete Error Response ..................................................................................... 91
Restore Profile Service........................................................................................................................... 92
Profile History Service ........................................................ 93
Overview ................................................................................................................................................ 93
Sample XML Profile History Request ..................................................................................................... 93
Sample XML Profile History Successful Response ................................................................................ 94
Sample XML Profile History Error Response ......................................................................................... 98
Profile Data Management Service ......................................... 100
Copying/Moving Profiles to a Branched Pseudo City Code .................................................................. 100

Moving a Profile to a Branched PCC ............................................................................................... 100
Copying an Association to a Branched PCC ................................................................................... 101
Shared Association objects ............................................................................................................. 102
Profile Merge Service ........................................................ 107
Merging Profiles ................................................................................................................................... 107

How to Merge a Profile .................................................................................................................... 107
Merge process flow ......................................................................................................................... 109
Sample XML Profile Merge Request ............................................................................................... 109
System Access Permissions ........................................................................................................... 111
ProfileToPNR Service ......................................................... 112
ProfileToPNR Service Overview .......................................................................................................... 112

Moving Remarks to PNR Using a Filter ........................................................................................... 113
Move Order Logic for Profiles with Associated Formats and Profiles .............................................. 114
The Filter Path ...................................................................................................................................... 115
Specifying the Profile ....................................................................................................................... 115
Specifying the Filter ......................................................................................................................... 116
Searching for a Filter ....................................................................................................................... 117
Searching for a Default Filter ........................................................................................................... 117
Filter’s Associated Profiles .............................................................................................................. 118
Temporary Filter Path........................................................................................................................... 121
ProfileToPNR Service Response Message .......................................................................................... 122
Shared objects in P2PNR..................................................................................................................... 123
Sabre Profiles Technical User Guide February 2019 Confidential and Proprietary Sabre Inc. v
Profile Index ......................................................................................................................................... 130
PNR Profile Index display..................................................................................................................... 131
Display Profile using the Profile Index value .................................................................................... 132
Filters ............................................................................. 133
Filter Overview ..................................................................................................................................... 133

Creating Filters ..................................................................................................................................... 133
How to Create a Filter...................................................................................................................... 134
Sample XML Create Filter Request ................................................................................................. 134
Sample XML Create Filter Successful Response ............................................................................ 136
Sample XML Create Filter Error Response ..................................................................................... 137
Reading Filters ..................................................................................................................................... 137
Sample XML Read Filter Successful Response .............................................................................. 137
Sample XML Read Filter Error Response ....................................................................................... 138
Updating Filters .................................................................................................................................... 138
Sample XML Filter Update Successful Response ........................................................................... 139
Sample XML Filter Update Error Response .................................................................................... 139
Searching for Filters ............................................................................................................................. 140
Deleting Filters ..................................................................................................................................... 141
Sample XML Filter Delete Request ................................................................................................. 141
Sample XML Filter Delete Successful Response ............................................................................ 142
Sample XML Filter Delete Error Response ...................................................................................... 142
Object inheritance scenario .................................................................................................................. 142
Formats ...........................................................................144
Format Overview .................................................................................................................................. 144

Identifying Format Types ...................................................................................................................... 144
Creating Formats.................................................................................................................................. 148
How to Create a Format .................................................................................................................. 148
Sample XML Create Format Request.............................................................................................. 148
Sample XML Create Format Successful Response......................................................................... 151
Sample XML Create Format Error Response .................................................................................. 151
Using XPath Expressions for Formats ............................................................................................. 151
Date Conversion Features ............................................................................................................... 153
Conditional XPath Format Functions ............................................................................................... 154
Processing Format Data....................................................................................................................... 157
Read Formats ...................................................................................................................................... 158
Sample XML Format Read Successful Response ........................................................................... 158
Sample XML Format Read Error Response .................................................................................... 158
Updating Formats ................................................................................................................................. 159
Sample XML Update Format Successful Response ........................................................................ 159
Sample XML Update Format Error Response ................................................................................. 159
Searching for Formats .......................................................................................................................... 160
Deleting Formats .................................................................................................................................. 161
Sabre Profiles Technical User Guide February 2019 Confidential and Proprietary Sabre Inc. vi
Sample XML Format Delete Request .............................................................................................. 161
Sample XML Format Delete Successful Response ......................................................................... 162
Sample XML Format Delete Error Response .................................................................................. 162
Templates/Associations with Metadata ................................. 163
Overview .............................................................................................................................................. 163

Association Object................................................................................................................................ 164
The logic of the Association object .................................................................................................. 164
Creating an Association object ........................................................................................................ 165
Attaching an Association to a profile................................................................................................ 166
Updating and Deleting Association Objects ..................................................................................... 167
Shared Association Objects ................................................................................................................. 168
Shared Association objects creation/update .................................................................................... 168
Shared Association Object Business Rules ..................................................................................... 168
Attaching an Association to another Association (child/parent functionality) ................................... 170
Child Association Object Business Rules ........................................................................................ 171
Branch Access Closed .................................................................................................................... 171
Validators ............................................................................................................................................. 172
Sample Validator ............................................................................................................................. 172
Sample Validator with multiple rules ................................................................................................ 173
Validator Rules descriptions ................................................................................................................. 174
Restriction ....................................................................................................................................... 174
Occurrence Rule.............................................................................................................................. 174
Regexp Rule .................................................................................................................................... 174
List Rule .......................................................................................................................................... 175
Pre-defined Rule.............................................................................................................................. 175
Metadata .............................................................................................................................................. 175
Bulk Read Services ............................................................ 177
Bulk Read Service Overview ................................................................................................................ 177

Bulk Read – Profiles – Request Message ............................................................................................ 177
Bulk Read – Profiles – Response Message ......................................................................................... 178
Bulk Read Error Scenarios ................................................................................................................... 179
Error response ................................................................................................................................. 179
Warning response ........................................................................................................................... 180
Bulk Read – Associations – Request Message .................................................................................... 181
Bulk Read – Associations – Response Message ................................................................................. 181
Bulk Read – Formats – Request Message ........................................................................................... 182
Bulk Read – Formats – Response Message ........................................................................................ 182
Bulk Read – Filters – Request Message .............................................................................................. 183
Bulk Read – Filters – Response Message ........................................................................................... 183
Bulk Read – Metadata objects – Request Message ............................................................................. 184
Bulk Read – Metadata Objects – Response Message ......................................................................... 184
Bulk Read – Validators – Request Message ........................................................................................ 185
Sabre Profiles Technical User Guide February 2019 Confidential and Proprietary Sabre Inc. vii
Bulk Read – Validators – Response Message ..................................................................................... 185
Profile Data Service .......................................................... 187
Overview .............................................................................................................................................. 187

Sample Retrieve Custom Field Codes XML Data Service Request ..................................................... 187
Sample Create Custom Field Codes XML Data Service Request ........................................................ 188
Sample Create Dictionary XML Data Service Request ........................................................................ 189
Sample Read Dictionary XML Data Service Request .......................................................................... 190
Sample Update Dictionary XML Data Service Request........................................................................ 191
Sample Delete Dictionary XML Data Service Request ......................................................................... 194
Sample Copy Dictionary XML Data Service Request ........................................................................... 196
Data Service Error Response ............................................................................................................... 197
Roles............................................................................... 198
Roles Overview .................................................................................................................................... 198

Roles Management ......................................................................................................................... 198
Creating a Role .................................................................................................................................... 203
Reading a Role .................................................................................................................................... 203
Sample XML Read Role Error Response ........................................................................................ 203
Updating a Role ................................................................................................................................... 203
Searching for a Role............................................................................................................................. 203
Sample XML Search Roles Request ............................................................................................... 204
Deleting a Role ..................................................................................................................................... 204
Copying or Moving a Role to another Domain ...................................................................................... 204
Assigning a Role to an Agent Profile .................................................................................................... 204
Notification Services (ENS) ................................................ 205
Sabre Profiles ENS Overview .............................................................................................................. 205

Event Notification Services .............................................................................................................. 205
Sample Payload for Profile Event Create Notification ...................................................................... 205
Sample Payload for Profile Event Update Notification ..................................................................... 206
Summary ......................................................................................................................................... 206
A – Sections Pending Implementation ................................... 207
A.1 Sections Pending Implementation .......................................................................................... 207

A.1.1 Partial Update – Pending Implementation ......................................................................... 207
A.1.2. TPA Extensions .................................................................................................................... 214
A.1.3. ProfileToPNR Standard PNR Formats ................................................................................. 214
Sabre Profiles Technical User Guide February 2019 Confidential and Proprietary Sabre Inc. viii
Introduction 1
About this Guide
This guide is for architects and developers to learn how to compose XML formatted requests and
responses to consume Sabre Profiles Web Services.
The information in this guide is intended to help architects and developers accomplish the following:
• Incorporate into a client program the composition of the XML request and response formats
to acquire appropriate Sabre Integrated Computing Environment (ICE) authentication and
authorization security credentials represented by a unique token found in the response.
• Incorporate into a client program the composition of the XML to include the unique
tokenized security credential in subsequent Sabre Profiles Web Service requests.
• Consume Sabre Profiles Web Services by learning the different request types, their
corresponding responses and the different protocols and standards involved.
Note: This guide focuses on functions and elements that are intended exclusively for the
use of Sabre Travel Network clients.
Standards and Specifications
The following specifications govern the format of profile data, the packaging format of the
messages, and the transport mechanisms.
• HTTP 1.1 [RFC2616] – used for transport protocol
• MIME specifications [RFC2045], [RFC2046], and [RFC2387] – used for the SOAP message
headers and instructions
• SOAP 1.1, Electronic Business using XML [ebXML], and W3C XML standards – used to define
and describe the SOAP messages
• SOAP Messages with Attachments specification [SOAPAttach] – used for the ebXML
messages that include header and payload containers
• WS-Security standards – partially adopted for some security elements in the SOAP header
• W3C XML 1.0 – used for both Sabre XML message specifications and Sabre XML messages
put into the payload container of the SOAP message.
Sabre Profiles Technical User Guide February 2019 Confidential and Proprietary Sabre Inc. 1
• OpenTravel Alliance specification (http://www.opentravel.org) - used as the basis for the
profile request and response XML payloads.
• SOAP – Simple Object Access Protocol
• Character Specifications
• ISO 10646/Unicode, Basic Latin and Latin 1 Supplement
• UCS Transformation Format 8 (UTF-8 Encoding)
• ISO 8859 Latin 1 Character Set
• Sabre Character Set
About Sabre Profiles Web Services
Web clients access the content and functionality of the Sabre Profiles web application by accessing
the Web Services exposed through the Sabre Web Services (SWS) infrastructure. An exchange of
messages between a web client and a business application, such as one of the Sabre Profiles Web
services, follows. The Sabre Web Services infrastructure provides security, sessions, logging, and
routing to the Sabre Profiles web business services. A Web Services session is created when a
correctly formatted SessionCreateRQ request is sent to the Sabre Web Services infrastructure, and a
binary security token is returned in the SessionCreateRS message. This unique conversation ID and
binary security token identify the session and are used together throughout the duration of the
session.
In a given Web Services session, all request messages include the same unique conversation ID and
binary security token. Only one conversation ID must exist per business process work flow. Once
again, often the URL of the web client website plus a timestamp is used for the conversation ID.
If activity has not occurred within the session time out limit, which is approximately 20 minutes, the
business process flow represented by the session is not guaranteed to be alive.
A simplified flow of a Web Services session is as follows:
1. The web client first requests access, a connection, and a session by sending a
SessionCreateRQ XML request to the Sabre Web Services infrastructure which does the
following:
a. Validates the user security credentials and message format
b. Authenticates the message
c. Authorizes access
d. Preserves the requestor-composed unique conversation ID
I. Security credentials in the SessionCreateRQ message consist of the

wsse:Username, wsse:Password, Organization, and Domain elements. In
addition to these credentials, the client generates a unique conversation ID.
Often the conversation ID achieves uniqueness by including a timestamp and
the URL of the client website as part of the conversation ID.
II. This is the only request message that includes the client security credentials
provided by Sabre.The web client stores the session data represented as a
conversation ID and security token, and includes them with each subsequent
SOAP request until the conversation is closed. This avoids the overhead of re-
authentication that would occur if this process needed to happen for every type
of Sabre Profiles service request.
2. The SWS infrastructure uses the security token and conversation ID to locate the Web
Services session, and, if granted access, routes each of the subsequent Service requests to
the appropriate Sabre Profiles Web Service and returns the response to the Web Client.
3. The web client and the Sabre Profiles services exchange messages that represent a business
workflow.The web client sends subsequent Sabre Profiles Web Service requests
incorporating the returned SWS security token as well as the unique conversation ID sent
with the initial SessionCreateRQ request.
4. The Web Services session ends when the web client sends the SessionCloseRQ XML request
with the same unique conversation ID and security token of the session it is closing, or the
session time out expires before the next Sabre Profiles Service web request is received.
The web client delivers requests to the Sabre Profiles Web Services using the HTTPS protocol.
All requests are sent to a URL that is the single access point to Sabre Web Services.
Security
Sabre Web Services has implemented multiple layers of security for client applications. These layers
include line security, authentication, authorization, and confidentiality.
Line Security
Line security is the layer that secures the data traveling on the line over the Internet between
external systems Sabre data centers and responds back to the external systems. Sabre Profiles Web
Services support point-to-point synchronous transport HTTPS using SSL with 128-bit encryption.
Clients who consume Sabre Web Services must implement line security with a secure sockets layer,
and they must secure the envelopes and payloads with HTTPS.
Authentication
Authentication is the layer that allows web client access to the Sabre Profiles Web Services. Security
credentials are found in the wsse:Username, wsse:Password, Organization, and Domain elements
present in the SOAP envelope in the SessionCreateRQ request message. The user receives the values
for the security credentals when set up by Sabre to use the Sabre Profiles Web Services.
The Sabre Web Services infrastructure authenticates the service requestor using the security
credentials found in the envelope of the request.
An XML fragment of the security credentials from the SOAP SessionCreateRQ message envelope
follows:
<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"
xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/12/utility">
<wsse:UsernameToken>
<wsse:Username>USERNAME</wsse:Username>
<wsse:Password>PASSWORD</wsse:Password>
<Organization>USERORGANIZATION</Organization>
<Domain>USERDOMAIN</Domain>
</wsse:UsernameToken>
</wsse:Security>
Note: The following is the second multipart MIME part containing the Sabre XML payload
message:
<SessionCreateRQ>
<POS>
<Source PseudoCityCode="IM07"/>
</POS>
</SessionCreateRQ>
Authorization
The authorization layer gives web clients access to specific web services. When a web client sends a
request, the Sabre Web Services infrastructure authorizes access to all services in the product
packages to which an organization has subscribed. Currently, all Sabre Profiles Services are
authorized as a package.
Confidentiality
The confidentiality layer maintains the privacy of the data in a payload during its transmission. Sabre
Profiles Web Services use HTTPS with 128-bit encryption.
Network Connectivity
Access to the Sabre Profiles Web Services for web client applications is available through the
Internet. Consequently, resources used to develop and deploy production applications must have
Internet access.
If the system is behind a corporate firewall, information about the user’s proxy server is required so
that the applications can access the Internet.
Web Services Sessions
SessionCreateRQ Request XML Example
The web client establishes a SWS session by sending security credentials and a unique conversation
ID as shown in the following example.
The Envelope
<?xml version="1.0" encoding="UTF-8"?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:eb="http://www.ebxml.org/namespaces/messageHeader"
xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Header>
<eb:MessageHeader SOAP-ENV:mustUnderstand="1" eb:version="1.0">
<eb:From>
<eb:PartyId type="urn:x12.org:IO5:01">999999</eb:PartyId>
</eb:From>
<eb:To>
</eb:To>
<eb:ConversationId>2007-12-15T11:15:12@clientURL.com</eb:ConversationId>
<eb:CPAId> SabreSuppliedDomain </eb:CPAId>
<eb:Service eb:type=" sabreXML">Session</eb:Service>
<eb:Action>SessionCreateRQ</eb:Action>
<eb:MessageData>
<eb:MessageId>99999999</eb:MessageId>
<eb:Timestamp>2007-12-15T11:15:12Z</eb:Timestamp>
<eb:TimeToLive>2007-12-15T11:15:12Z</eb:TimeToLive>
</eb:MessageData>
</eb:MessageHeader>
<wsse:UsernameToken>
<wsse:Username>SabreSuppliedUserName</wsse:Username>
<wsse:Password>SabreSuppliedPassword</wsse:Password>
<Organization>SabreSuppliedOrganization</Organization>
<Domain>SabreSuppliedDomain/Domain>
</wsse:UsernameToken>
</wsse:Security>
</SOAP-ENV:Header>
<eb:Manifest SOAP-ENV:mustUnderstand="1" eb:version="1.0">
<eb:Reference xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="cid:rootelement"
xlink:type="simple"/>
</eb:Manifest>
<SOAP-ENV:Body>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
The SOAP Payload
<SessionCreateRQ>
<POS>
<Source PseudoCityCode="SabreSuppliedPseudoCity"/>
</POS>
</SessionCreateRQ>
A typical response is shown below.
<SessionCreateRS xmlns="http://www.opentravel.org/OTA/2002/11" version="1" status="Approved">

<ConversationId>2007-02-15T11:15:12@clientURL.com</ConversationId>
</SessionCreateRS
The SOAP Envelope

<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Header>
<eb:MessageHeader xmlns:eb="http://www.ebxml.org/namespaces/messageHeader"
eb:version="1.0" soap-env:mustUnderstand="1">
<eb:From>
<eb:PartyId eb:type="URI">123123</eb:PartyId>
</eb:From>
<eb:To>
<eb:PartyId eb:type="URI">999999</eb:PartyId>
</eb:To>
<eb:CPAId> SabreSuppliedPseudoCity</eb:CPAId>
<eb:ConversationId>2007-12-15T11:15:12@clientURL.com</eb:ConversationId>
<eb:Service eb:type="sabreXML">Session</eb:Service>
<eb:Action>SessionCreateRS</eb:Action>
<eb:MessageData>
<eb:MessageId>97d9da35-3a36-4092-a934-99ba554ac712@73</eb:MessageId>
<eb:Timestamp>2006-12-28T18:34:16</eb:Timestamp>
<eb:RefToMessageId>99999999</eb:RefToMessageId>
</eb:MessageData>
</eb:MessageHeader>
<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
<wsse:BinarySecurityToken valueType="String"
EncodingType="wsse:Base64Binary">Shared/IDL:IceSess\/SessMgr:1\.0.IDL/Common/!ICESMS\/STSB!ICESMSL
B\/STS.LB!-4617338326250370976!113241!0</wsse:BinarySecurityToken>
</wsse:Security>
</soap-env:Header>
<soap-env:Body>
<eb:Manifest xmlns:eb="http://www.ebxml.org/namespaces/messageHeader" eb:id="Manifest"
eb:version="1.0">
<eb:Reference eb:id="SessionCreateRS" xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="cid:SessionCreateRS">
<eb:Description xml:lang="en-US">Session Create Response Message</eb:Description>
</eb:Reference>
</eb:Manifest>
</soap-env:Body>
</soap-env:Envelope>
Ending the Session
Once the web client establishes a SWS session, one or more profile requests are made by the user.
For example, an aapplication might need to retrieve several customer profiles and update those
profiles all in one session.
The SWS session ends in one of two ways: The user sends the SessionCloseRQ message populated
with session data, or the SWS infrastructure ends the session when the session timeout has
occurred.
Note: If the web client user intends to send only a single profile service request, the
SessionCreateRQ and SessionCloseRQ messages must still pack in the single request.
The SessionCloseRQ message for the example follows:
<?xml version=”1.0” encoding='UTF-8'?>

xmlns:eb="http://www.ebxml.org/namespaces/messageHeader"
xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Header>
<eb:ConversationId>2007-02-15T11:15:12@clientURL.com </eb:ConversationId>
<eb:From>
<eb:PartyId type="urn:x12.org:IO5.01">clientURL</eb:PartyId>
</eb:From>
<eb:To>
<eb:PartyId type="urn:x12.org:IO5.01">webservices.sabre.com</ eb:PartyId>
</eb:To>
<eb:CPAId>IPCC</eb:CPAId>
<eb:Service eb:type="sabreXML">Session</eb:Service>
<eb:Action>SessionCloseRQ</eb:Action>
<eb:MessageData>
<eb:MessageId>mid:20001209-133003-2333@clientURL</eb:MessageId>
</eb:MessageData>
</eb:MessageHeader>
<wsse:BinarySecurityToken xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/12/utility"
wsu:Id="SabreSecurityToken" valueType="String"
EncodingType="wsse:Base64Binary">
Shared/IDL:IceSess\/SessMgr:1\.0.IDL/Common/!ICESMS\/STSB!ICESMSLB\/STS.LB!-
4617338326250370976!113241!0
</ wsse:BinarySecurityToken>
</wsse:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<eb:Manifest SOAP-ENV:mustUnderstand="1" eb:version="2.0">
<eb:Reference xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="cid:SessionCloseRQ"
xlink:type="simple"/>
</eb:Manifest>
</SOAP-ENV:Body>
Note: The following is the second multipart MIME part containing the Sabre XML message:
<SessionCreateRS xmlns="http://www.opentravel.org/OTA/2002/11" version="1" status="Approved">
<ConversationId>2007-02-15T11:15:12@clientURL.com </ConversationId>
</SessionCreateRS>
Credit Card Data Security
Sabre has implemented a number of measures to ensure Credit Card data security and compliance
with PCI (Payment Card Industry) standards.
The following sections refer to measures that Sabre Profiles protects credit card data at several
levels to ensure the security of data.
Access
• All incoming and outgoing transmission of Credit Card (CC) data is through a secure channel.
In Web Services, this is HTTPS; in batch files, this is SFTP + file encryption.
• SSH keys for SFTP are exchanged in a secure way and fixed for each transition channel.
• Control of IP address is implemented for each customer that tries to use Sabre Profiles Web
Services with Credit Card data.
• Security keywords must be requested and approved for each customer who wants to read
Credit Card data.
• Access requires a Sabre Host EPR CCVIEW keyword (Host/PSS access) or OSCCVIEW (Web
Services only) security permission in the user’s SIM (Sabre Identity Manager) account which
is used to access Sabre Web Services.
• Credit Card data is encrypted before it is stored in the database.
Storage and Internal Security Measures
• Encryption keys are stored on separate boxes. Access to obtain the keys is secured by other
security certificates.
• Credit Card data is never recorded in any log file. Only a “masked version” is available with
the last four digits exposed.
• The Sabre’s Development team does not have access to the database and application boxes.
• Detailed application logging tracks the user account for every access request for credit card
data, even in the encryption form, to the user.
• The account used by the application to access the database controls access to enable only
connections from Sabre Profiles Application boxes, thereby preventing access by any
unauthorized source.
• The Password used by the application to access the database is stored in hashed form, so it
cannot be read from configuration files and used by another application.
• Prior to any application release, system security audits are conducted to ensure continuous
compliance.
Technical Support
There are several ways to obtain technical support. Please note that a Pseudo City Code, or PCC, is
required.
Note: When reporting production or other critical issues, it is best to contact support by phone. Do
not send an email.
Telephone Support is available 24 x 7
800-678-9460 (USA)
682-605-5570 (Canada)
598-2-518-6020 (International)
Or call your regional Sabre software help desk
Email
Send an email to the following address: webservices.support@sabre.com.
Email is monitored Monday through Friday during extended business hours.
Additional Support
Sabre maintains a Product Support Desk that is staffed 24 hours a day, 7 days a week to receive and
resolve user-reported problems with various Sabre products. If you have questions, please contact
the Product Support Desk.
Accessing Sabre Profiles Web
Services
3
The following table includes URLs and IP addresses that shall be used to access Sabre Profiles Web
Services. Recently Sabre introduced new URLs for use with Sabre APIs to improve Sabre`s High
Availability (HA) infrastructure. These new HA URLs require TLS 1.2 and support HTTP
compression.
Please note that the current URLs will be retired in June of 2018, and will be coordinated with the
Payment Card Industry (PCI) TLS v1.2 security deadlines. It is recommended that API customers
begin planning their migration to these new High Availability URLs as soon as possible.
Production
Current URLs Current IP New URLs New IP
Addresses Addresses
webservices.sabre.com 151.193.160.91
webservices2.sabre.com 151.193.160.105 151.193.4.55
webservices.havail.sabre.com
webservices3.sabre.com 151.193.51.17 151.193.0.56
webservices.lp.sabre.com 151.193.51.15
Certification
Addresses Addresses
151.193.109.22
sws-crt.cert.sabre.com 151.193.52.22 sws-crt.cert.havail.sabre.com
151.193.105.24
Test
Addresses Addresses
151.193.109.30
sws-sts.cert.sabre.com 151.193.52.23 sws-sts.cert.havail.sabre.com
151.193.105.33
Activation
In order to consume Sabre Web Services, including access to Sabre Profiles, the user must first have
a Sabre Web Services account typically assigned as an iPCC (internet Pseudo City Code) and have
user credentials, which are either set as a TPF (host) user in case he needs to access Sabre host
functionality like PNR or Move profile information into a PNR, or a non-TPF account, which is set up
in SIM (Sabre Identity Manager tool).
Additionally, the web service order needs to include a request to access Sabre Profiles. Processing
this request will result in adding the corresponding attributes that manage the permissions to these
services. To perform operations in the Sabre Profiles system, it is also necessary that the Domain
(known as Pseudo City Code) is enabled in the Sabre Profiles system.
Please contact your Sabre account representative to process the request. Upon completion of this
activation process, Sabre will send a confirmation email indicating that the PCC/Domain has been
activated and is ready to consume Sabre Profiles web services.
The ICE attributes which are required are listed below:
• USGSessionUser (typically assigned to an individual user or Employee Profile Record/EPR)

o Required to be able to create webservices session
• EPSExternalUser (assigned at a PCC/Domain level)
o Required to consume Sabre Profiles web services for ProfileCreate, ProfileRead,
ProfileBulkRead, ProfileUpdate, ProfileDelete, ProfileSearch, ProfileDataSrv,
ProfileDataMgmtSvc, ProfileHistory services.
• PnrMoveUser (assigned at a PCC/Domain level)
o Required to use the ProfileToPNR service to move profile data into a Sabre PNR
• RolesExternalManager (assigned at the individual user/EPR level)
o Required if User Roles are implemented to further control/restrict access to Sabre
Profiles functions and allows the user the ability to create and assign Roles.
• RolesManager (assigned at the individual user/EPR level)
o Required if using Sabre Roles User Interface within Agency eServices. User Roles are
implemented to further control/restrict access to Sabre Profiles functions and
allows the user the ability to create and assign Roles.
• RolesReadOnlyExternalUser (assigned at the PCC/Domain level)
o Required if User Roles are implemented to further control/restrict access to Sabre
Profiles functions
• RolesReadOnlyUser (assigned at the PCC/Domain level)
o Required if using Sabre Roles User Interface within Sabre Red Workspace. User
Roles are implemented to further control/restrict access to Sabre Profiles functions
Types of Web Services
A web client that consumes Sabre Profiles Web Services typically uses two basic types of messages:
session management messages and Sabre Profiles Service request messages.
Session Management Services
Web Services messages have been created to open and close sessions. Session services do not
request profile-related content from Sabre Profiles, and they do not contain business logic. Session
services allow for greater efficiency when processing client requests because time consuming
security data retrieval overhead is avoided by maintaining that data in the session and representing
the session in a security token returned to the client.
The SessionCreateRQ request contains a client composed unique conversation ID and a Sabre
supplied security credential to initiate a connection, a session, authentication and authorization to
access Sabre services such as the Sabre Profiles Web Services.
The SessionCreateRS response returns to the web client the unique conversation ID and a unique
security token for use in subsequent Sabre Profiles related requests. The session lasts either until
the client sends a SessionCloseRQ request or the session time out is exceeded.
The establishment of the session for Sabre Profiles services includes granting access only to the
“owner” of the profiles stored by Sabre. This limited access is accomplished with the security
configuration represented by the security credentials presented by the web client in the
SessionCreateRQ.
Sabre Profiles Services
Sabre Profiles web clients can request via the internet the following external profile services (which
are defined to include _EXT_ within the schema name):
• EPS_EXT_ProfileCreate – the web client sends profile data to Sabre to create a profile to be
stored by Sabre on behalf of an agency. The client sends the Sabre_OTA_ProfileCreateRQ XML
request message and gets the Sabre_OTA_ProfileCreateRS XML response message back
indicating success or failure and some profile-related information.
• EPS_EXT_ProfileUpdate – the web client sends updated profile data to Sabre to modify an
existing profile of an agency. The client sends the Sabre_OTA_ProfileUpdateRQ XML request
message and gets the Sabre_OTA_ProfileUpdateRS XML message response indicating success or
failure and some profile ID related information.
The Sabre_OTA_ProfileUpdateRQ XML request can be composed to perform a full data update.
Note: Partial Profile Update will be available in the future. This User Guide will be updated when
that functionality becomes available.
When a full profile data update takes place, the updated profile data provided replaces the
Sabre stored profile if successful. The web client must read (retrieve) the profile prior to
updating a full profile. The retrieved profile contains a timestamp that must be inserted into the
profile update message or the profile will be rejected. The returned timestamp provides a
means to guarantee data integrity. If another web client has updated the profile prior to this
client returning the update, an error response message “SIMULTANEOUS_ERROR” results due to
the timestamp mismatch. If this update error is returned, the client must retrieve the profile
again, update the profile with the newer timestamp, and update the profile with the client
updates.
• EPS_EXT_ProfileRead – the web client sends a request to retrieve a profile using the
Sabre_OTA_ProfileReadRQ XML request message. The latest profile stored by Sabre with the
UniqueID defined in the request message is returned in the Sabre_OTA_ProfileReadRS XML
response message.
The Sabre_OTA_ProfileReadRQ message contains a <TPA_Identity> element with attributes to

specify the profile ID, the profile type, the agency or “owner” code, etc. Therefore, the same
message format is used to retrieve any of the profile types such as traveler, corporate, travel
agency, travel agent, or group.
Sabre_OTA_ProfileReadRQ also can read specified subject areas and ignore other subject
areas. The <PartialReadSubjectAreas> element under <Profile> indicates which subject areas are
of interest in the profile. If a profile has subject areas specified in <PartialReadSubjectAreas>,
then the Profile read request returns only that subject area(s). It ignores all other subject areas
in the profile. If a profile does not have corresponding subject area specified in
<PartialReadSubjectAreas>, then the Profile read request returns an error message.
<IgnoreReadSubjectAreas> tells what subject areas are not of interest in the profile read. This
feature is only available for Traveler (TVL) Profile types. Additional Profile Types will be
supported in the future. In this case, the Profile read returns all subject areas except the subject
areas mentioned in <IgnoreReadSubjectAreas>.The Sabre_OTA_ProfileReadRS message
contains all the profile data retrieved or an error message indicating a problem was
encountered while reading the profile.
• EPS_EXT_ProfileBulkRead – the web client sends search criteria for a profile contained in the
Sabre_OTA_ProfileBulkReadRQ XML request message. This service is designed to retrieve
multiple objects with one service call. These objects can be:
o Profiles (up to 10)
o Associations/Template (up to 10)
o Metadata (up to 10)
o Validators (up to 10)
o Filters (up to 10)
o Formats (up to 10)
• EPS_EXT_ProfileSearch – the web client sends search criteria for a profile contained in the
Sabre_OTA_ProfileSearchRQ XML request message. This is considered an “online” search with
the application of an immediate execution of search criteria within the Profiles system and
should be used when expecting a smaller amount of profile results. If there is only one profile
that matches the search criteria, the full profile details are returned to the web client in the
Sabre_OTA_ProfileSearchRS XML response message. Otherwise, if the ProfileNameOnly
attribute (in the Sabre_OTA_ProfileSearchRQ XML) is set to “true”, a list of TPA_Identity
sections of profiles that match the criteria is returned. If this attribute is set to “false”, the user
will get a list of TPA_Idenity sections along with some additional profile data. The search criteria
entered depends on the type of profile as does the response data returned.
• EPS_EXT_ProfileDelete – the web client sends a request to mark an existing profile for delete in
the Sabre_OTA_ProfileDeleteRQ XML request message. When the profile is marked for delete,
it will be permanently removed from the database using an internal Purge Service. The Purge
Service starts automatically at midnight (US Central standard time) and removes all the “marked
for delete” profiles that either have the same purge date as the current date (no matter what
status of the Profile is) or don’t have a purge date defined (if Profile status is “DL” – Deleted).
o Note: There is an approximate 2-hour window for deletion requests processed on

the same day which will not be included in the nightly purge service batch.
Example: If profile deletion request is submitted at 10pm CT, it may not be
included in the nightly batch processed at midnight that same day and will likely
be included in the purge service executed the following day.
This service also supports the ability to restore a profile that is set to purge on a given date.
• EPS_EXT_ProfileDataSrv – the web client sends a request to either retrieve or create Customer
Field Codes in the Sabre_OTA_ProfileDataSrvRQ XML request message. Having specified Client
Code, Client Context Code and Domain ID, the web client can retrieve up to 250 previously
created, using the same web service ”Customer Field Codes” in the
Sabre_OTA_ProfileDataSrvRS XML response message. Customer Field Codes are codes that the
client/user can define per DomainID (PCC) to cover the need to identify and store data elements
that have not been previously defined in the available profile fields.
• EPS_EXT_ProfileDataMgmt – the web client sends a request to copy or move profiles from one
domain to a branched domain. This service supports move and copy of single profile or
AssociationID (Template) with all associated formats, filters, metadata, and validators (excluding
associated profiles).
• EPS_EXT_ProfileToPNR – the web client sends a request to move profile data to the PNRMove
service using the Sabre_OTA_ProfileToPNRRQ XML message. There are two methods which can
be used to move to the PNR service: Filter Path or Temporary Filter Path. When Filter Path is
used, a FilterID is used to specify which data should be moved. When the Temporary Filter path
is used, the Profile data fields to be moved are specified within the request. The filtered-out
profile data is then forwarded to the PNRMove service to copy the data into the “AAA host
session –work area”.
• EPS_EXT_ProfileHistory - the web client sends a request for changes made to the profile data
using the Sabre_OTA_ProfileHistoryRQ XML message. The Profile History service allows the
customer to retrieve history of any actions taken on a profile over the previous 13 months.
• EPS_EXT_OfflineJobCreate, EPS_EXT_OfflineJobCancel, EPS_EXT_OfflineJobRetrieve,

EPS_EXT_OfflineJobReadResult, and EPS_EXT_OfflineJobDelete - the web client sends a
request using one of these services which currently supports “offline” search for specific profile
data using (as one example) the Sabre_OTA_OfflineJobCreateRQ XML message. These services
allow the customer to search profile data which could return larger profile results based upon
specific search criteria. This requires the search job to be executed offline (asynchronously).
These services, which currently only support offline search functionality, will be used in the
future to support other offline job executions such as offline import/export of profile data.
Domain Access Rules
When creating and updating Sabre Profiles objects (Profiles, Association Objects, Filters, and
Formats), the same DomainID (PCC) should be used.
A Format in DomainID=”X” cannot be associated to an Association Object, Filter, or Profile in a

different DomainID. For example, a user cannot create an Association Object with DomainID=”X”
and associate it to a Profile or Filter with DomainID=”Y.” All associated objects must exist in the
same Domain. (Exception to this rule is if Share Templates are used, then you can associate Child
Templates in another Domain to a Parent Template in Domain X).
However, if Branch access exists between two domains (PCCs), the ProfileToPNR service can be
called to move profile data from DomainID=X to DomainID=Y into a PNR. The user can also Create,
Search, Read, and Update a profile from DomainID=X in DomainID=Y, provided:
• Associated profile objects use the same DomainID
• Appropriate branch access rights exist between DomainID (PCC) X and Y.
Message Structure
Messages for the Sabre Profiles Web Services conform to the following two specifications:
• The ebXML part of the SOAP envelope conforms to SOAP with Attachments
• The content of the payload attachments conforms to Sabre Profiles XML which is based on, but
not 100% compatible, with the published OTA profile related schemas.
The structure of the message is based on Internet standards such as HTTP, HTTPS, and the MIME
mail extensions. HTTPS is the communication protocol.
The SOAP with Attachments protocol is a MIME multipart message with the following MIME parts:
• The header container – This is a SOAP envelope, which is an XML document.
• The payload container – This is the application payload, and it is formatted as Sabre
Profiles XML.
The SOAP with Attachments protocol is used to format messages for Java clients, and the payload is
sent as an attachment. Instead of sending the payload as an attachment, however, it can be
included inside the SOAP wrapper. Java Axis clients include the payload inside the SOAP wrapper. If
WSDL and Microsoft .NET Framework are used to format messages, the payload is included inside
the SOAP wrapper.
Requesting Payload Content
Payload content is requested by including the action code that corresponds to the service being
called. Service Names will not match Action codes but will be similar in naming convention. All
Profiles Web Service customers should use the external schemas noted within the Action code as
EPS_EXT_…. unless otherwise instructed by the Profiles support team.
A unique action code identifies the request and response payloads for each of the Sabre Profiles
Web Services.
The action codes, represented by the eb:Action element in the SOAP header, are the following:
Service Name Action code
Profile Create EPS_EXT_ProfileCreateRQ
Profile Read EPS_ EXT_ProfileReadRQ
Profile Bulk Read EPS_EXT_ProfileBulkReadRQ
Profile Update EPS_ EXT_ProfileUpdateRQ
Profile Delete EPS_ EXT_ProfileDeleteRQ
Profile Search EPS_ EXT_ProfileReadRQ
Profile History EPS_EXT_ProfileHistoryRQ
Profile To PNR Service EPS_ EXT_ProfileToPNRRQ
Offline Job Create - Search EPS_EXT_OfflineJobCreate
Offline Job Cancel - Search EPS_EXT_OfflineJobCancel
Offline Job Retrieve - Search EPS_EXT_OfflineJobRetrieve
Offline Job Read Result - Search EPS_EXT_OfflineJobReadResult
Offline Job Delete - Search EPS_EXT_OfflineJobDelete
Profile Data Service EPS_ EXT_ProfileDataSrvRQ
Profile Data Management Service EPS_EXT_ProfileDataMgmtRQ
Sabre Profile Access validation by PCC
Below is a table showing when the session PCC and/or the AAA PCC must be activated for Profiles
and Sabre Security attributes enabled to access Profiles through web services. If the customer does
not AAA to the Profiles domain before sending the call, then the session PCC regardless of branch
access, needs to be enabled for Profiles.
Login AAA Login PCC Sabre AAA PCC Sabre Access to Remarks
PCC PCC Security Security profile
Attribute Attribute Services
A Yes Yes User did not perform an

AAA operation using host
command
A No No User did not perform an

AAA operation using host
command
A B Yes No Yes User logs in with pcc A and

AAA to pcc B before sending
profile request
A B Yes Yes Yes User logs in with pcc A and

profile request
A B No Yes Yes User logs in with pcc A and

profile request
A B No No No User logs in with pcc A and

profile request
There are two ways to access Profiles inside a PCC via web services:
• the session must be established with the profiles PCC and its then sent as the domain in the
Profiles WS call
• the customer must AAA to the PCC that is active on Profiles after the session is established
and the AAA PCC is the domain sent in the Profiles WS call for action.
For your information, user can change AAA by executing the "AAA{new PCC}" green screen
command via Sabre API SabreCommandLLSRQ, or by using the dedicated Sabre API
ContextChangeLLSRQ.
Sabre Profiles Web services allows an Agent to access a Profile if his home city that is configured in
the internal Sabre Security Manager tool matches the Profile DomainID (PCC). In the case that
branch access exists, an Agent will have access to Profiles that are in the PCC that is branched to the
home city.
Sabre Profiles Web Services will be changing this logic in the future so that access to a branched PCC
will be based on a PCC that an Agent AAA into, not his home city.
Web Services Error Handling
Several error categories are possible.
• Sabre Web Services errors – These types of errors occur within the Sabre Web Services
infrastructure, and they are caused by faulty messages from the web client or problems with the
Sabre Profiles Web Services. The infrastructure detects and generates these errors, and returns
them as SOAP faults, with or without ebXML headers.
• Business application errors – These errors are generated by the business application services
that are called by the SWS infrastructure. The web client request, the network routing between
the SWS infrastructure and the business application service, or the business application service
can cause these types of errors. They are returned to clients in the ErrorRS XML response
format.
• System errors generated by web clients – These are caused by the web clients themselves and
are external to the Sabre Profiles Web Services. They normally occur in the development
environment, and are returned to the client.
When the response contains the <soap-env:fault> element, an HTTP status code of 500 is
returned. If no SOAP fault exists, HTTP Status Code 200 is returned. Other codes depend on the
request and are shown later in the document.
Any Sabre Profiles system errors returned will include an error code for each error message. The list
of exception message errors and their codes can be found on Sabre’s Dev Studio at
https://developer.sabre.com under Sabre Profile Services.
The general error message structure will be formatted as shown below in the xml response.
<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode=”123”> </ErrorMessage>
</ResponseMessage>
Some common error messages are listed below, such as those returned by CreateSessionRQ when:
a) wrong values are passed in Organization / Domain
b) when the account has not been activated for SWS or
c) when the passcode is locked or invalid
i.e.
<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"/>
</soap-env:Header>
<soap-env:Body>
<soap-env:Fault>
<faultcode>soap-env:Client.AuthenticationFailed</faultcode>
<faultstring>Authentication failed</faultstring>
<detail>
<StackTrace>com.sabre.universalservices.base.security.AuthenticationException:
errors.authentication.USG_AUTHENTICATION_FAILED</StackTrace>
</detail>
</soap-env:Fault>
</soap-env:Body>
</soap-env:Header>
<soap-env:Body>
<soap-env:Fault>
<faultcode>soap-env:Client.InvalidSecurityToken</faultcode>
<faultstring>Invalid or Expired binary security token: {0}</faultstring>
<detail>
<StackTrace>com.sabre.universalservices.base.security.AuthenticationException:
errors.session.USG_INVALID_SECURITY_TOKEN</StackTrace>
</detail>
</soap-env:Fault>
</soap-env:Body>
The example below illustrates the error response when DomainID/PCC has not been set up as
“Active” (status AC) and therefore is not allowed to perform transactions in the Sabre Profiles
system.
<soap-env:Body>
<Sabre_OTA_ProfileCreateRS
TimeStamp="2010-03-16T15:40:27.142" Version="3.4"
xmlns="http://www.sabre.com/eps/schemas">
<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode-“123”>C:::PRF::Domain Status is not allowed to do this
operation.</ErrorMessage>
</Errors>
</ResponseMessage>
<Profile
ClientCode="TN" ClientContextCode=“TMP” DomainID="BADPCC"
ProfileNameModifyIndicator="Y" ProfileStatusCode="AC"
ProfileTypeCode="OPX" UniqueID="*"/>
</Sabre_OTA_ProfileCreateRS>
</soap-env:Body>
Sabre Profile Types 4
Profile Types
Sabre Profiles offers 6 profile types including Traveler (TVL), Corporate (CRP), Group (GRP), Travel Agency
(AGY), Travel Agent (AGT) and Operational (OPX) profiles. Each of these profile types are described in
more detail in the following sections. Each Profile Type contains elements in the schema referred to as
“subject areas”. Some examples of elements defined as subject areas would be Telephone, Email,
Address, CustomerReferenceInfo, Discounts, etc.
Traveler
Sabre Profiles clients use the Traveler (TVL) profile type to store data applicable to an individual person,
and could contain information such as name, address, contact information, customer loyalty programs, or
discount programs. The Traveler profile can contain data for one or more of these purposes.
NOTE: For current Profiles supported elements, attributes, and number of instances allowed of these
fields, please refer to the schema xml files located on the Sabre Dev Studio.
Logic for specific schema elements/attributes within the Profile
PersonName
Note: PersonName should be used to identify the single individual/entity.
The multiple instances of PersonName can only be used in combination with Language selection with the
intent to illustrate a different representation of the same person’s name (single individual/entity
referenced in the Profile) in different languages (i.e. a Chinese name in English to be used in the Sabre
host vs. the Chinese character representation to be displayed on a web application or marketing
material.) The InformationText attribute can also be specified in the PersonName to add additional
information to this section.
Note: If the IsSubjectToSecureFlight attribute is set to ‘Yes’ in the Customer section, GivenName and
Surname attributes of the PersonName section as well as BirthDate and Gender attributes of the
Customer section are validated by the Sabre Profiles system. An error message is returned in the
response if any of these four attributes are not present in the profile Create request.
If the LanguageIDCode is not specified, it will be set to the default code which is ‘EN-US’.
PaymentForm
If the Cash sub-element is not specified, the Payment form is treated as the Payment Card form.
Alternatively, if the user provides the Cash sub-element with the Indicator attribute set to ‘False’, it will
be also treated as the Payment Card. A sample Payment Card is shown below:
<PaymentForm OrderSequenceNo="1" TripTypeCode="AZ" ServiceUsageTypeCode="CR">

<PaymentCard BankCardVendorCode="AX" CardNumber="12341234123412340000"
MaskedCardNumber="0000" CCViewAccess="U" ExpireDate="122016" FirstRemark="N">
<CardHolderName>John Smith</CardHolderName>
</PaymentCard>
</PaymentForm>
Preference Collections Element in Traveler Profile
If using RailStationInfo to store data, there is a connection between three attributes inside the system.
The ContextCode attribute is needed to distinguish the coding standard (IBNR, IATA or SNCF) for Station
Codes and allows the user to choose if he wants to see/use IBNR, IATA or SNCF codes. The mandatory
RailStationCode attribute is used to store the station code preference.
IBNR Rail codes use the UIC station reference which always consists of 7 to 8 digits, beginning with a 2-
digit UIC country code (the UIC Country Code is a two digit number used to identify member countries of
the International Union of Railways).
A sample of the RailStationInfo is shown below:
<RailStationPref PreferLevelCode="P">
<RailStationInfo RailStationCode="761385" LocationTypeCode="STA" ContextCode="IBNR" />
</RailStationPref>
IATA Rail codes use a 3-alpha station reference:
<RailStationInfo RailStationCode="BZY" LocationTypeCode="APT" ContextCode="IATA" />
</RailStationPref>
SNCF Rail codes example:
<RailStationInfo RailStationCode="FRAAC" LocationTypeCode="STA" ContextCode="SNCF" />
</RailStationPref>
If the RailStationCode is related to IATA and ContextCode is not specified in the CreateRQ/UpdateRQ - it
will default to the "IATA" value.
If the RailStationCode has stations that exist both in IATA and IBNR, the ContextCode="IATA" will be
stored if not specified otherwise.
OrderSequenceNo Uniqueness based upon predefined Subject Area ‘Types’
While the OrderSequenceNo attribute is optional in all locations in the Profile schemas, it is highly
recommended that customers use this attribute in the service calls when creating and updating Profiles.
In most cases, subject areas in the schemas within each profile type support the ability for the user to
store multiple instances of data. When multiple instances are stored for the same subject area, there is a
need to identify each instance with an OrderSequenceNo. This helps the user to ensure that when
updates to the profile are made, the correct instance of that subject area is updated. It also helps point of
sale tools with their display logic to group the data together for easier interpretation and execution for
any needed action by a user.
Sabre Profiles system enforces uniqueness across all subject areas for the OrderSequenceNo. This ensures
there is no duplication of updates when the same OrderSequenceNo is sent to the system for a given
action (create, update, delete, search). In some subject areas, we also validate uniqueness of the
OrderSequenceNo based upon certain ‘TypeCode’ attributes in that subject area.
Example:
Unique OrderSequenceNo is validated for PaymentForm considering the ServiceUsageTypeCode by itself,
or considering the combination of the ServiceUsageTypeCode along with the TripTypeCode.
1. If user wants to store a credit cards as TripTypeCode of Business and a 2 credit cards as
TripTypeCode of Leisure, all instances of credit cards stored under each Trip Type would have
unique OrderSequenceNo validation at time of a Create or Update action.
2. If same user wants to store credit cards for Trip Type of Business, but also for
ServiceUsageTypeCode of CAR and one for Hotel, uniqueness in the OrderSequenceNo would be
applied considering both types of cards to be used for Business Car and Business Hotel.
For most subject areas that contain an attribute with a label of TypeCode or TripTypeCode, this validation
will apply.
Note: Please do not use OrderSequenceNo=”0”. The suggested use for data value of this attribute is “1”,
“2”, “3”, etc.
Operational
The Operational (OPX) profile is used for various purposes including the storage and management of
relevant information to assist the user in the booking process, contract information, or any other
information that needs to be shared by the agency, such as a list of phone numbers. They can be used to
store vendor references or contracts, information about their agent(s), or as a reference to different
agency processes. Operational profiles share many of the available elements and attributes found in
other profile types, such as Travelers, Agency, or Corporation.
fields, please refer to the schema xml files located on Sabre Dev Studio.
Corporate
Sabre Profiles clients use the Corporate (CRP) profile type to store and manage information about a
corporation with whom the Agency has a relationship or serves as a customer to provide business travel
services. Traveler profiles can be associated to Corporate profiles to establish a relationship between the
two.
Group
Sabre Profiles clients use the Group (GRP) profile type to store common data that multiple travelers may
share for traveling in a group. For example, a Group profile may contain a common address or discount
information for a meeting that multiple travelers may be attending, or a Group profile could be created
for a family. While each person will have their own Traveler Profile (TVL) with their own personal data
and loyalty numbers, their TVL profile can be associated to a Group profile that contains common data for
information purposes to the agency or the PNR relevant to the traveling group.
One difference for GRP profiles is the way they relate to associations, in that GRP profiles may be associated
in both directions to a TVL profile, e.g. TVL to GRP or GRP to TVL. This means that when a TVL profile is
associated to a GRP profile and you try to read both, the GRP profile will reference the TVL profile in the
association section and TVL profile will have GRP in the association section.
Agency
Sabre Profiles clients use the Agency (AGY) profile type to store and manage information about the
Agency and related agency branches. This can include Agency data such as contact numbers, emails,
addresses as well as vendor preferences and discount programs, etc.
Agent
Sabre Profiles clients use the Agent (AGT) profile type to manage data about travel agents authorized to
handle travel through the travel agency and store user roles. Typically, the travel agent profile is related
to a Sabre Profiles travel agency profile. The travel agency can be enrolled in an airline incentive
program. The travel agent is either an employee of the travel agency or has a working relationship with
the travel agency. The Agent profile can be linked to the Sabre host EPR via synch using a Profiles system
generated AuxiliaryID, but users can also create a general Agent profile without this EPR link. When
reading one of these profiles, this is how the user can distinguish that the Agent Profile was created
based upon an EPR is the presence of the AuxiliaryID within the ReadRS.
For the most up-to-date elements, please refer to the schema xml files located on the Sabre Dev Studio.
Replication of Sabre Host EPRs into Agent Profiles
For Sabre Travel Network customers, the Sabre Profiles system has implemented an automated process
that obtains information on EPRs (Sabre GDS Employee Profile Records) and replicates basic information
to automatically create the corresponding “Agent profile”.
These synchronized “EPR-Agent profiles“ share the following elements/sections:
• ProfileName (using same value as EPR Number)

• Agent GivenName,
• Surname
• AgentGDSIdentity AgentID (using same value as EPR-id)
• GDSCode (set as 1S-Sabre) and
• Sabre Security Entity Attributes (including CCVIEW, NOSTAR, etc.)
The “Sabre Security Entity Attributes” included are only those which play a role with the Profile and/or
Corporate Travel Policy (CTP) related functionality like CCVIEW, NOSTAR, etc. (which are EPR security
keywords).
This process allows the Sabre Profiles system to determine specific user security rights for example view
Credit Card number information and other sensitive information can be obtained or if the number should
only be presented in its “masked” (****) representation.
The replication process runs in a close to real time basis, meaning that if an EPR is created in an Agency
PCC, within 2 minutes time the corresponding Agent profile will be created for the same PCC/DomainID in
Sabre Profiles system.
At this point, all TN PCCs are set up to automatically replicate EPRs into Agent Profiles.
This Sabre Profiles service will:
• Create a new Travel Agent Profile
o When an EPR is created in Sabre host, a corresponding Agent Profile is created for the
same DomainID (PCC) in the Sabre Profiles system
• Update an existing Travel Agent Profile
o When an EPR is updated, the corresponding Sabre Profiles Agent profile will be updated
(only the synchronized fields listed above will be updated. Any other section of an Agent
Profile not coming from the synch EPR will remain as is)
• Delete an existing Travel Agent Profile
o Sabre Profiles web services won’t allow deletion of an Agent Profile that was generated
by EPR synchronization. It can only update and delete other sections of the profile
o To delete the profile, the user should delete the EPR and the synchronization service will
take charge to delete the corresponding Agent Profile
Below is a Sample Read response of an EPR converted to Agent Profile response.
<soap-env:Body>
<Sabre_OTA_ProfileSearchRS TimeStamp="2010-03-08T20:19:32.973" Version="3.3"
<ResponseMessage>
<Success/>
</ResponseMessage>
<ProfileInfo>
<Profile CreateDateTime="2009-04-13T11:35:12.159" UpdateDateTime="2010-03-08T12:26:00.578"
PrimaryLanguageIDCode="EN-US">
<TPA_Identity ClientCode="TN" ClientContextCode=“ABC” UniqueID="1040213" ProfileTypeCode="AGT"
ProfileName="222333" DomainID="A4VE" ProfileStatusCode="AC"/>
<TravelAgent>
<AgentName GivenName="Adam" SurName="Sandler"/>
<AgentGDSIdentity AgentID="222333" GDSCode="1S"/>
<SabreSecurityEntityAttribute AttributeName="CCVIEW" OrderSequenceNo="0"/>
</TravelAgent>
</Profile>
<Association ClientCode="TN" ClientContextCode=“ABC” DomainID="A4VE" AssociationID="14663"

ProfileTypeCode="AGT"/>
</ProfileInfo>
</Sabre_OTA_ProfileSearchRS>
</soap-env:Body>
If User Roles are assigned, these will take precedence over the “Sabre Security entity attributes” inherited
from the EPR-Agent Profile synchronization. This means that if Roles are assigned to the Agent Profile,
instead of using these EPR security attributes, the permissions set in roles will determine the functions
available to the user. If User Roles are not used, then the Sabre Security attributes are used to dictate
any restrictions in the Profile functionality.
Audit information tracking using AccessInfo in the API
Information about the user accessing each Profile is recorded for auditing purposes. By default, the
information about the web services user who performs the web services call is recorded. If the web service
request is made with a system’s functional user account, and the call is performed on behalf of another
real user such as a travel agent (EPR or AGT profile ID), <ReadAccessInfo> element should be included in
the request sent in the service to allow for including the end user information in the audit trail, rather than
information about the functional account.
Example of a request using AccessInfo in a ProfileBulkReadRQ is shown below:
<Sabre_OTA_ProfileBulkReadRQ ClientContextCode=“TMP" Target="Production" TimeStamp="2016-12-

16T11:52:15.551Z" Version="6.28" xmlns="http://www.sabre.com/eps/schemas">
<Profiles>
<Profile ProfileTypeCode="TVL">
<Identity ClientCode="TN" DomainID="A2FE">
<UniqueID>1160045043</UniqueID>
</Identity>
</Profile>
</Identity>
</Profile>
</Profiles>
<Associations>
<Association AssociationID="4354085" ClientCode="TN" DomainID="A2FE"/>
</Associations>
<ReadAccessInfo EPRDomainID="A2FE" UserID="123456"/>
</Sabre_OTA_ProfileBulkReadRQ>
Note: Only access to Profiles is tracked in the audit trail. Access to all other objects is not tracked, and for
these objects the data passed in the AccessInfo is ignored.
Common attributes within the Payload
The following attributes are available for every Profile Type:
ClientContextCode
During the implementation to Sabre Profiles, the customer will be provided a dedicated
ClientContextCode for each system that consumes our services. This attribute acts as an identifier for any
action made by the system, however it does not act as an “owner” of the object identified in the service
call.
As an example, an agency may have an external third party they use to support afterhours reservations
which is not part of their agency. If both the agency and the third party are sending service calls for any
action on profiles (Create, Update, Delete, Read, etc.) each system will be provided a dedicated
ClientContextCode that should be included in the payload as an identifier. Agency “ABC” can create the
profile sending a ClientContextCode=“TMP”, but the Afterhours Support system (if external to that
agency) would be assigned their own code (ClientContextCode=”DEF”) to send in any calls to Sabre
Profiles Services. The latest received ClientContextCode value is stored inside a Profile.
Important Note: If you did not receive a dedicated ClientContextCode and you have a system consuming
Sabre Profiles APIs, please contact your Sabre Account Director to obtain a dedicated Sabre Profiles
ClientContextCode.
Profile SubTypes
A SubType is an optional element under the TPA_Identity section of the Profile node that can be used by
consuming applications.
These subtypes are simply used as additional qualifiers to designate certain qualities or functions for
consuming applications and/or Sabre Profiles system in an individual’s profile including Event Notification
Service. The consuming application can use these qualifiers to implement business logic on their end.
The following subtype is currently used to support Sabre Travel Network agencies:
Profile Type= TVL (Traveler)
a. “NN” No Name - Used by the Sabre Profiles system to allow moving a Traveler Profile Type to
a PNR without a name field format (-LastName/FirstName). This generates a special Profile
Index Format in the PNR and bypasses the name validation required for Traveler profile types
when moving Traveler data.
b. If a customer chooses to use Event Notification or Profile Notification Services, the Sabre
Profiles implementation team will assign a dedicated ProfileSubType Code for that customer
which should be included in any Profile Create or Update service calls made by the
customer’s system or their partner systems.
How to Determine the Profile Data Needed
This document contains several XML examples and additional examples are available for different profile
types and objects supported within Sabre Profiles on Sabre Dev Studio for Sabre Web Services.
Most likely a Travel Agency new to the Sabre Profiles system will have data requirements that will be a
smaller subset of all the hundreds of possible data types. You will find that most sections in the different
profiles are optional, and therefore each client can decide which sections and elements are needed for
their business needs.
Here are some tips to make the use of this document a little easier:
1. Go to the session management section and understand the composition and use of the
SessionCreateRQ request and SessionCreateRS response.
2. Go to the section of the document discussing the Profile Types.
3. Look at a typical subset of data for a profile type and determine if it is a good match for your
business requirements.
4. Look at the create sample XML for the profile type and review the additional data types available
and include those data types, if desired.
5. Compose create, update, retrieve, and search XML messages that represent the subset of data
types chosen.
6. In case you have any questions or issues, you can contact Sabre for support at
webservices.support@sabre.com and review the set of composed XML messages.
7. Setup CAT testing with Sabre.
Use of Dictionary Control Table Values
To maintain data standardization, Sabre Profiles has implemented a few “dictionary tables” for controlled
table values. Instead of enumeration in the Sabre Profiles XML Schema, the control data are published as
additional XMLs. These controlled table values prevent the user from entering incorrect or inconsistent
values in the XML messages for profile data fields. There are many Control Data values that are used in
the profiles services and these include, for example:
• the profile Type Codes (i.e. “TVL” for Traveler, “CRP” for Corporate, etc.)
• Credit Card Type codes to differentiate between credit cards, debit cards
• Airport and City codes, etc.
Examples of this type of data include:
CardTypeCode.xml
<CARDTYPECODE>CR</CARDTYPECODE>
<DESCRIPTION>Credit</DESCRIPTION>
or
<CARDTYPECODE>DB</CARDTYPECODE>
<DESCRIPTION>Debit</DESCRIPTION>
Etc.
ProfileTypeCode.xml
<PROFILETYPECODE>TVL</PROFILETYPECODE>
<DESCRIPTION>Traveler</DESCRIPTION>
or
<PROFILETYPECODE>CRP</PROFILETYPECODE>
<DESCRIPTION>Corporation</DESCRIPTION>
etc.
VehicleRate_CurrencyCode.xml
<CURRENCYCODE>CAD</CURRENCYCODE>
<DESCRIPTION>CanadianDollar</DESCRIPTION>
<DECIMALPOSITION>2</DECIMALPOSITION> … etc.…
HotelPrefGEODestinationCode.xml
<GEODESTINATIONTCODE>LAX</GEODESTINATIONTCODE>
<DESCRIPTION>Los Angeles International Apt</DESCRIPTION>… Etc.
HotelPref_GeoRegionCode.xml
GEOREGIONCODE>AFR</GEOREGIONCODE>
<DESCRIPTION>Africa</DESCRIPTION>
<GEOREGIONCODE>EUR</GEOREGIONCODE>
<DESCRIPTION>Europe</DESCRIPTION>… etc.
The complete list of XML / XSD files on control table (dictionary data) can be obtained from the Sabre API
Dev Studio at: https://developer.sabre.com. They are available under each ‘Action’ tab for Sabre
Profiles. (Example: ‘Create Profile Objects’ Resources, ‘Delete Profile Objects’ Resources, etc.) From there,
you can select the Control Files to download. Each Profile ‘Action’ Resources tab will include repeated
support documentation.
Note: An easy way to identify within an XML message which values are controlled by these Control
Tables is to look for the suffix “Code” at the end of the string.
i.e.:
… ProfileStatusCode="AC"
ProfileTypeCode="CRP"
…
<PriorityRemarks CategoryCode="ACC" Text="Pr remark1"/>
<Remark CategoryCode="ACC” …. Etc.
These Dictionary/Control table files often, but not always, follow the same naming convention as the
respective elements in schema. For example, under the subject area Telephone, the element
LocationTypeCode is controlled by the values set in Telephone_LocationTypeCode.xml, under
FormOfPayment-->PaymentCard the attribute CardTypeCode is controlled by the values set in
CardTypeCode.xml, The ProfileStatusCode attribute is controlled by the values set in
ProfileStatusCode.xml, etc., etc.
Use of Status codes
Access to Sabre Profiles for different clients is controlled by the “Domain”.
For Sabre Travel Network clients, the domain is referenced by the PCC (Pseudo City Code) for example:
A5BE, A2FE, etc.
Domain “Status”
A Domain can have different accessibility states. This state regulates how a Domain can be accessed by an
end-user. There are 3 states that can apply to an entire Domain:
- NA (Not activated)
- MP (Migration in Progress)
- AC (Active)
When a Domain is in status NA, no activity is permitted in Sabre Profiles.
MP (Migration in Progress) is used to determine the state when data migration is being performed. While
most of the operations are enabled in this state, it is considered that the Domain is in validation mode.
For a Domain to be available to process service requests, for example to create and view Profiles, it is
necessary that the Domain status be set as “Active” AC (or Migration in Progress).
Profile “Status”
Like Domain Status, Profiles have their own Status element that determines the actions that are available.
The table below illustrates enabled and disabled functions according to the status of the profile.
Valid status for each operation below
AC (Active) IN (Inactive) DL (Delete)
Create OK OK X
Update OK - (controlled
by “Ignore Status
Check” attribute. If
attribute is not
included, the
profile in ‘IN’
OK status can not be X
updated.
Read OK OK X
Search OK – (controlled by
OK OK ExcludeDeleted attribute)
Delete/Restore OK (set status DL) OK (set status DL) OK (Restore)
Profile2PNR OK X X
DataSrv OK OK X
There is an additional attribute @IgnoreStatusCheck available for Create/Update/Read operations which

allows to skip the Profile status validation step if set to “Y”.
Profile Associations
Sabre Travel Network customers previously used STARs (Special Traveler Account Records) which are GDS
based/PSS files, to store information about customers (corporation and individual traveler profile
information, as well as reference information).
Sabre STARs were hierarchical and therefore could store information in 3 levels (Level 0, held information
about the agency, level 1 could have held information about a corporation or individual traveler, and level
2 could have held information about the individual traveler associated to the level 1 client.
Sabre Profiles are not hierarchical, but rather all profiles can be viewed at the same level. However,
Profiles can be associated to one another to indicate a relationship. The type of relationships can vary
according to the customer’s business needs. For example, 2 or more traveler profiles (TVL) can be
associated, or linked, to one another as they may be members of the same family, or travelers often
traveling together, etc. A Traveler profile can be associated to a Corporate profile as the Traveler may
work for the corporation or perform travel on their behalf and you can have the same Traveler associated
to more than one corporation (for example if the same traveler works or has a relationship with various
corporations). A Traveler Profile can also be associated to one or more Operational Profiles. It is possible
to create a PNR using several profile sources according to a variety of circumstances.
You can associate profiles to other profiles based on the following hierarchy:
FROM Profile Allows Associations TO Profile

Type Type
TVL TVL, CRP, GRP, AGT, AGY, OPX
AGT AGT, TVL, CRP, GRP, AGY, OPX
CRP CRP, GRP, AGY, OPX, AGT
AGY AGY, OPX, AGT, GRP
OPX OPX, GRP, AGT, AGY, CRP
GRP CRP, AGY, OPX, AGT, TVL
Common Rules and Elements across Profile Types
The table below illustrates the high-level elements that are common across profile types and therefore
also indicates the section of the document the details of those elements are available. When the same
element is used in a subsequent profile type, rather than duplicating all the information, the reader is
asked to reference the corresponding profile type and section where these details have already been
covered.
Common high-level elements across profile types

AGY
OPX
AGT
GRP
CRP
TVL
Element Description
Parent element for Traveler under which the rest of the

traveler elements can be found such as name
(PersonName), phone (Telephone), email (Email), address
Customer X (Address), etc.
PersonName X Title, First name, middle name, last Name, etc.
All the components for telephone, for full phone or parsed

Telephone X X X X X X phone number (Country code, area code, number, etc.)
Email X X X X X X Email address, usage, etc.
Address X X X X X X Address lines, city, country, zip, etc.
AGY
OPX
AGT
GRP
CRP
TVL
Element Description
PaymentForm X X X X X X Form of payment type including Credit/Debit cards,

checks, cash, accounts receivable etc.
Contact data (names, etc.) for individuals related to the

RelatedIndividual X traveler profile
EmergencyContactPerso Contact information including names, phone numbers,

n X X X X X email, address for contacting in case of emergency
Document X X Information such as passport, visas, driver licenses, etc.
Information on Loyalty programs per vendor such as

airline frequent traveler programs, hotel or car rental
CustLoyalty X X frequent traveler or loyalty programs
X
Information about where the individual is employed
including employee number, cost centers, departments,
EmploymentInfo X X X etc.
AgencyContactName X X Title, First name, middle name, last name, etc.
Agency details including name, description, URL and other

AgencyInfo X identifiers (also Tax and credit info, etc.)
Corporation details including name, description, nature of

business, and other identifiers (also Tax and bank info,
CorporateInfo X etc.)
Group details including name, Meeting Id or Group Id (also

GroupInfo X Tax and bank info, etc.)
Contains basic information about contact (name Prefix,

GivenName, MiddleName, Surname(required),
NameSuffix, PreferredFirstName, PreferredLastName,
ContactName X X X OrderSequenceNo, and LanguageIdCode)
AgentName X Agent name title, first name, middle name, last name, etc.
Agent information such as date of birth, marital status,

AgentInfo X gender, etc. Also includes tax info.
AGY
OPX
AGT
GRP
CRP
TVL
Element Description
Data to identify other individuals related to the agent

AgentRelatedIndividuals X including their names and relationship type
AgentGDSIdentity X Includes Agent sine, ID, GDS-code, etc.
This section is divided by Air, Hotel, VehicleRental, Rail,

PrefCollections X X X X X X etc.
Stores preferences by trip type, geographic origin or

destination and includes options for Airport preferences,
AirlinePref X X X X X X seats, cabin, meals, preferred airlines, etc.

destination and includes options for Preferred hotel
HotelPref X X X X X X vendors, property, rates, roomType, etc.

destination and includes options for Preferred rental car
VehicleRentalPref X X X X X X vendors, rates, vehicle types, etc.

destination and includes options for Rail stations, seats,
RailPref X X X X X X cabin, meals, vendors, upgrades, etc.

GroundTransportationPr destination and includes options for Preferred bus or limo
ef X X X X X X vendors, rates, aggregators, etc.
Includes notification preferences, consent for notifications

TPAMarkertingPreferenc and agreement for campaigns and consent for terms and
e X X X X X X conditions, etc.
Priority Remarks X X X X X X Important notes/information
Remarks X X X X X X Other notes/remarks
X
Special Service Request information including codes and
SSR X X X descriptions (i.e. WHCR - Wheelchair, etc.)
X
Other Service Request information including codes and
OSI X X X descriptions
AGY
OPX
AGT
GRP
CRP
TVL
Element Description
Reference to 3rd party systems such as accounting

systems including branch and account ID's for DK-
CustomerReferenceInfo X X X X X X customer storage
BusinessSystemIdentityIn Information on other systems (i.e. back office system

fo X X X X X references) includes system name, Id, description, etc.
To reference other profiles associated to the current

profile (includes, profile ID, profile associated type codes,
DomainID (PCC), and information on whether the
associated profile data should move into a PNR before or
Associated Profiles X X X X X X after the main profile
References Filters indicating which data is pre-selected to

be used in the Profile to PNR move service (includes filter
Associated Filters X X X X X X name, id, DomainID (PCC), etc.)
References Formats (Host/emulator string entries

constructed by the user with text and profile data
Associated Formats X X X X X X (includes, name, ID, DomainID (PCC), etc.)
Discount information by vendor for Air, Hotel, Car Rental

discounts, etc. (includes vendor type and code, discount
Discounts X X X X X X number, descriptions, effective and expiration dates, etc.)
Value pair data including codes, descriptions and data

values to allow customers to define their own data
beyond the existing data model. Validation applied by the
Profiles System for codes sent against those pre-defined
CustomDefinedData X X X X X X for domain via DataSrvRQ
String values defined by customer to define their own data

beyond existing data model. No validation applied by the
CustomDefinedValues X X X X X X Profiles system for content.
Tax Info X Tax information corresponding the entity in the Profile
Reference to the Role assigned (grouping of lower level

permissions) to enable/restrict profile functions such as
Roles X Create, Read, Update, Delete, etc.
AGY
OPX
AGT
GRP
CRP
TVL
Element Description
Reference to Sabre Corporate Travel Policy records

(CTP/Flex edits) and Sabre Travel Policy Engine (future
Travel Policy X X X X X product)
Reference to the Sabre STAR data from which the profile

STARData X X X X X X originated (for migrated profiles)
Customer value score assigned by a system to segment

customers (includes, score, effective/discontinue dates,
CustomerValueScore X vendor types and codes)
Information of the Global distribution system referenced

GDS X X X X to this profile (I.e. 1S=Sabre)
Queue assignment including queue number, DomainID

QueueAssignments X X (PCC) Prefatory instruction, etc.
Commission data including: commission measure code,

Commissions X X value, trip type, vendor, effective/discontinue date, etc.
SabreSecurityEntityAttrib Attributes (i.e. Sabre GDS security attributes assigned to

ute X the EPR such as CCVIEW, etc.)
information on incentives including: supplier code,

Incentives X service, incentive ID, value, effective/expiration dates, etc.
Read only fields to track profile usage (create, update and

ProfileAccessInfo X X X X X X access)
A Traveler profile in Sabre Profiles is intended to represent a single entity. Any data stored within that
profile should be data related to the primary traveler.
Common Elements and Attributes
All Profile CreateRQ requests require the following elements and attributes: UniqueID, ProfileType,
ClientCode, ClientContextCode and DomainID.
For the UniqueID, a value of “*” should be set and a valid unique identifier will be generated on the
database side (from database sequence). See more on this topic below. ProfileTypeCode (TVL for
Traveler, CRP for Corporate, AGT for Agent, AGY for Agency, GRP for Group, or OPX for Operational) is a
mandatory element. The ClientContextCode is also mandatory and is used to define the application that is
creating the profile. (i.e. MYS for Sabre Red Workspace Point of Sale-created profiles, SVT for Sabre
Virtually There, etc.) However, when authorized developer customers are using Sabre Profiles services to
create profiles, they should use their own Client Context Code “nnn” as assigned by Sabre Profiles. The
values for this attribute are managed by the dictionary of control values XML. A temporary value of
“TMP” (Temporary) can be used until your dedicated Client Context Code is assigned.
However, the values of the ClientCode and the ClientContextCode are related to each other and they
cannot be set separately. The matching ClientCode for the ClientContextCode is also specified on Sabre
Dev Studio in the STNDRDPRFRLS_CLIENTCNTXTCD.xml.
The DomainID should be set as the 4-digit alpha numeric Pseudo City Code (PCC) for Sabre Travel
Network customers.
The element “OrderSequenceNo” should always be included to support interoperability.
Transactional Data – You will find that most sections/elements in the schema include a section for
“Transactional Data”. This element is not currently in use but is planned for managing transactional
related data in future.
Various sections of the schema require an attribute OrderSequenceNo and a LanguageIDCode. If the
LanguageIDCode is not specified, it will be set by the Sabre Profiles system to the default value of ‘EN-US’.
Please review carefully the “Traveler Profile” section below, as many of the rules and elements available
will also apply to other profile types, but details will be covered only under this section to avoid
duplication of information.
Note: Any time the content of the elements for a profile need to include special characters that
are used in XML formatting, you need to replace these characters with their corresponding
value as shown in the table below:
< <
& &
> >
" "
‘ '
Management of Non-standard English Characters
The Sabre Profiles database allows storage and management of double-byte characters in the APIS and
supports special characters including Indian/Chinese Double Byte& Arabic ASCII characters in XML, and
for special Sabre characters Such as the “Cross of Loraine”, “Change Key”, and “End Item”.
All Sabre special characters are stored as Unicode values:
• Cross of Loraine ¥: ¥
• Change key ¤: ¤
• End item §: §
Entries Display in a web page
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8”?>

<Test> <Test>
<Test1>ఢ</Test1> <Test1>ఢ</Test1>
<Test1>§</Test1>
<Test1>§</Test1>
<Test1>乖</Test1>
<Test1>乖</Test1>
<Test1>ڄ</Test1>
<Test1>‫<ڄ‬/Test1>
</Test>
</Test>
Profile UniqueID
In Sabre Profiles, all profile types include an attribute under TPA_Identity, called “UniqueID”. This ID
uniquely identifies the profile and cannot be changed.
The Profile UniqueID is automatically generated by the Sabre Profiles system to ensure uniqueness across
all Agency PCCs/branches. This UniqueID is entered into the PNR when a Profile is moved to create a PNR
in a section called “Profile Index” (PI).
The PI field of the PNR links profiles to PNRs and ties this data together. This profile index also includes a
reference to the owning agency PCC from where it was moved. The UniqueID used for the Index is unique
across all Sabre Travel Network Agency PCCs. The generation of the profile UniqueID by the profile
system ensures not only uniqueness, but also that the generated ID is not larger than the PI field can
accept. The Profile Index only accepts up to 20 characters.
Since the Profile UniqueID is auto-generated, no specific value should be provided for this field when
creating a profile. The value of “*” should be provided for this attribute in the CreateRQ. To generate the
UniqueID automatically, the profile create request should look like this:
<Profile CreateDateTime="2001-12-17T09:31:47.0Z"
UpdateDateTime="2001-12-17T09:30:47.0Z"
<TPA_Identity UniqueID="*" ProfileTypeCode="TVL" ClientCode="TN"
ClientContextCode=“TMP” ProfilePurgeNoOfDays="5" DomainID="A5BE"

ProfileName="John123" ProfileStatusCode="AC"
ProfileDescription="Traveler sample"
ProfileNameModifyIndicator="Y">
</TPA_Identity>
Create Service 5
Creating Profiles
Sabre Profiles web services clients create a customer profile over the web interface using the
Sabre_OTA_ProfileCreateRQ request.
Also refer to Sabre Dev Studio for a detailed payload illustrating the data elements and attributes
available in xml files. Each file is annotated to explain data restrictions, whether optional or required
data, and other detailed explanations.
The following sections describe the most typical subset of data currently in use.
How to Create a Profile
The below information uses Traveler profile as an example in the xml.

Assume the SessionCreateRQ has already returned the binary session token and conversation ID for the
web client session being described.
Sample XML Create Profile Request
The Create XML request begins with the following boilerplate:

<Sabre_OTA_ProfileCreateRQ TimeStamp="2001-12-17T09:30:47.0Z" Version="0.0" Target="Production"
xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.sabre.com/eps/schemas
..\schemasWSDL\Sabre_OTA_ProfileCreateRQ.xsd">
The next section is the element <Profile> with the following attributes: CreateDateTime, UpdateDateTime
and PrimaryLanguageIDCode. The first two attributes are required and the last attribute is optional. If the
value of the PrimaryLanguageIDCode is not set, it will be set to “EN-US” by default. The
PrimaryLanguageIDCode can hold one of the values specified in the Dictionary Control Value XML files.
The xml file name for the control table values available is PRIMARYLANGUAGEIDCODE.xml.
<Profile CreateDateTime="2001-12-17T09:31:47.0Z"
UpdateDateTime="2001-12-17T09:30:47.0Z"
Now define the unique identification for this profile.
<TPA_Identity UniqueID="*" ProfileTypeCode="TVL" ClientCode="TN"

ClientContextCode=“TMP” ProfilePurgeNoOfDays="365" DomainID="A5BE"
ProfileName="John123" ProfileStatusCode="AC"
ProfileDescription="Traveler sample"
ProfileNameModifyIndicator="Y">
</TPA_Identity>
The following attributes: UniqueID, ProfileType, ClientCode, ClientContextCode and DomainID are
required. In the example above, the UniqueID has been set to “*” which means that the valid unique
identifier will be generated on the database side. The ProfileTypeCode has been set to “TVL” which means
that the profile to be created is a Traveler type. Apart from ‘TVL”, the ProfileTypeCode can be set to one
of the following values: “AGT”, “AGY”, “CRP”, “GRP” or “OPX”. They can be defined respectively as: Agent,
Agency, Corporate, Group and Operational types of profiles. These values are stored in the
ProfileTypeCode.xml (as part of the Dictionary Control Table values referenced in Sabre Dev Studio).
The ClientCode should always be set to “TN” for Sabre Travel Network customers.
The ClientContextCode is mandatory and Sabre Travel Network customers should be using your own
dedicated ClientContextCode, or you can use the temporary code of “TMP” until your code is assigned.
These values are specified in TPA_Identity_ClientContextCode.xml (as part of the Dictionary Control
Table values referenced in Sabre Dev Studio)
However, the values of the ClientCode and the ClientContextCode are related to each other and they
cannot be set separately. The matching ClientCode for the ClientContextCode is stored in
TPA_Identity_ClientContextCode.xml
<CLIENTCONTEXTCODE>TMP</CLIENTCONTEXTCODE>
<DESCRIPTION>Temporary</DESCRIPTION>
<APPLICATION>TN</APPLICATION>
The DomainID should be the 4-digit alpha/numeric PCC (Pseudo City Code) for which the Profile operation
is performed.
The rest of attributes (ProfileName, ProfileNameModifyindicator, ProfileDescription, ProfileStatusCode

and ProfilePurgeNoOfDays) are optional. The attribute @InvalidInd is read only, it should not be sent in
the request.
• It is recommended that a ProfileName be defined in the payload for the CreateRQ for Sabre
Travel Network customers to support seamless transition of existing commands used to move the
Profile to PNR.
• Once the ProfileNameModifyIndicator value is defined with the initial profile CreateRQ call, it can
be updated one time if the original CreateRQ value was defined as “Y” (Yes) with a change to “N”
(No). The default value for this attribute, if not defined in the initial CreateRQ call, is “Y” (Yes).
o If ProfileNameModifyIndicator is set to “N” (No) with the initial profile CreateRQ, the user
will not be able to update or change this value in the future to allow modifications to the
ProfileName.
o If this value is set to “Y” (Yes) with the initial profile CreateRQ, the user can update the
profile for this attribute to “N” (No) one time to restrict modifications to the ProfileName.
• If ProfilePurgeNoOfDays=”0” is defined in the profile, regardless of the ProfileStatus, it will be
removed that same day. This attribute drives the purge mechanism. The ProfileStatus is
additional information which supports profile access restrictions.
If the value of any of the mandatory attributes is set as an empty string, or not set at all, the user will
receive an error message and the request will fail.
Sample XML Create Profile Successful Response
When a profile is successfully created, the following response message is returned:
<Sabre_OTA_ProfileCreateRS xmlns="http://www.sabre.com/eps/schemas"
Version="1.0">
<ResponseMessage>
<Success />
</ResponseMessage>
<Profile UniqueID="4056" ProfileType="TVL" ClientCode="ABC"
ProfileName="GREG" DomainID="IM17">
</Profile>
The Response message contains a Profile section, which returns a subset of information about the newly
created profile. The generated UniqueID of newly created Profile is included in response for a future
reference. This information is sufficient to retrieve this profile from the Sabre Profiles database.
Sample XML Create Profile Error Response
When a profile cannot be created for some reason, an error message is returned. Each error message
contains an Errors section with an Error Code and a short description of the problem which was
encountered during the profile creation. For the Sabre Profile Create Service each Error message is
prefixed with “C:::”.
A sample error message is shown below:
<Sabre_OTA_ProfileCreateRS Version="1">
<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode=”123”>
C:::Invalid XML (not compliant with Schema):
cvc-enumeration-valid: Value 'XXL' is not facet-valid with respect to enumeration '[TVL,
AGT, AGY, CRP, OPX]'. It must be a value from the enumeration.
cvc-attribute.3: The value 'XXL' of attribute 'ProfileTypeCode' on element
'TPA_Identity' is not valid with respect to its type, 'ProfileTypeInfo'.
</ErrorMessage>
</Errors>
</ResponseMessage>
In the example above, the Profile was not created because the incoming Profile Create request was not
compliant with the XML schema.
Now let’s focus on an example where the incoming request is compliant with the XML schema (it passes
the schema validation), but the input data violates some of the Sabre Profiles internal constraints. The
sample response message looks like this:
<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode=”123”>C:::PRF::Invalid TPA_Identity data</ErrorMessage>
</Errors>
</ResponseMessage>
<Profile ClientCode="TN" ClientContextCode=“TMP” UniqueID="*" ProfileTypeCode="TVL"
ProfileName="ABCSTAR" DomainID=“A5BE” DomainID=“A5BE” ProfileStatusCode="AC">
<Login LoginID=greg.stepien026@sabre.com
PasswordHash="gra8EoFe8RBh+iBMY+04p8oLguQ4H7q6hJ4HXLEZnksbQ6rI+YqWdUfiv4JrWTZMfoo="/>
</Profile>
In the example above the profile could not have been created because a profile already exists with the
same credentials (with the same Login section) in the Sabre Profiles database. The error message has
been prefixed with “C:::PRF::”, which means that the problem was encountered not during the XML
schema validation, but while saving the profile data. Moreover, the error message has been enriched
with the Profile section which contains crucial information about the Profile to be created.
A difference between the Error Read Responses for the various Profile types is that the error messages
are prefixed with “R:::TVL” , “R:::CRP “R:::OPX”, “R:::GRP” “R:::AGT or “R:::AGY”.
For example, of Error Exception Messages, see Sabre Dev Studio under each Sabre Profiles Action tab.
Read Service 6
Reading Profiles
Sabre Profiles customers can retrieve a traveler profile by specifying the Profile UniqueID,
ClientContextCode, ClientCode, DomainID and ProfileType.
A sample Profile Read Request looks like this:
<Sabre_OTA_ProfileReadRQ xmlns="http://www.sabre.com/eps/schemas"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
schemas\Sabre_OTA_ProfileReadRQ.xsd"
Version="1.0">
<Profile>
<TPA_Identity UniqueID="4250" ProfileType="TVL"
ClientCode="TN" DomainID=“A5BE”
ClientContextCode=“TMP”>
</TPA_Identity>
</Profile>
</Sabre_OTA_ProfileReadRQ>
The most recent snapshot of the profile is returned when performing a Read Request (refer to the
examples above).
A Sabre Profiles customer can also retrieve a traveler profile by specifying the Profile AuxiliaryID (which
represents a 3rd party system Profile ID), ClientContextCode, ClientCode, DomainID and ProfileType.
A sample Profile Read Request with a customer’s dedicated system AuxiliaryID looks like this:
Version="1.0">
<Profile>
<TPA_Identity UniqueID="*" ClientCode="TV" ClientContextCode=“TMP"
DomainID="A5BE" ProfileTypeCode="TVL">
<AuxiliaryID IDTypeCode=" TRIPCASE" Identifier="T42398"/>
</TPA_Identity>
</Profile>
Sabre_OTA_ProfileReadRQ also has the capability of reading specified subject areas and ignore specified
subject areas.
The <PartialReadSubjectAreas> element under <Profile> tells what subject areas are of interest in the
profile. If a profile has subject area(s) specified in <PartialReadSubjectAreas>, then the Profile read
response returns only that subject area(s). It ignores all other subject areas in the profile. If the profile
does not have a corresponding subject area specified in <PartialReadSubjectAreas>, then the Profile read
returns an error message in response. Here is the Sample Profile read request with
<PartialReadSubjectAreas>
<Sabre_OTA_ProfileReadRQ xmlns="http://www.sabre.com/eps/schemas" Version="1.4">

<Profile>
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP” UniqueID="100001069"
ProfileTypeCode="TVL" ProfileName="MIGR4GTTVL" DomainID="A5BE"/>
<PartialReadSubjectAreas><SubjectAreaName>STARData</SubjectAreaName></PartialReadSubjectAreas>
</Profile>
<IgnoreReadSubjectAreas> tells what subject areas are not of interest in the profile read response. In this
case, the Profile read returns all subject areas except subject areas mentioned in
<IgnoreReadSubjectAreas>. This feature is currently only fully applicable to TVL Profiles. Here is a Sample
Profile read request with <IgnoreReadSubjectAreas>
<Sabre_OTA_ProfileReadRQ xmlns="http://www.sabre.com/eps/schemas" Version="1.4">

<Profile>
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP” UniqueID="100001069" ProfileTypeCode="TVL"
ProfileName="MIGR4GTTVL" DomainID="B0DE"/>
<IgnoreReadSubjectAreas><SubjectAreaName>STARData</SubjectAreaName></IgnoreReadSubjectAreas>
</Profile>
A list of subject area names that can be used within PartialRead and IgnoreRead for each Profile Type
is found in table below. Supported subject areas are marked with “X”.
Important Note: Currently, this is only fully supported for TVL Profiles. The remaining profile types
will be available for full use in the future.
SubjectAreaName TVL AGY AGT CRP OPX GRP
Address X X X X X X
AgencyContactName X
AgencyInfo X
AgentGDSIdentity X
AgentInfo X
AgentName X
AgentRelatedIndividuals X
AirlinePref X X X X X X
AnalyticalInfoGroup X X X X X X
AssociatedFilters
AssociatedFormats X X X X X X
AssociatedProfiles X X X X X X
AssociatedTemplates X X X X X X
Association X X X X X X
Branding X X X
BusinessSystemIdentityInfo X X X X X
BusinessTravelerSetting X X
Commissions X X
Consent X X X X X X
ContactName X X X
CorporateInfo X
CustLoyalty X X
CustomDefinedData X X X X X X
CustomDefinedValues X X X X X X
CustomerReferenceInfo X X X X X X
CustomerValueScore X
CustomProfileRoles X
DirectlyAssociatedFilters X X X X X X
Discounts X X X X X X
Document X X
Email X X X X X X
EmergencyContactPerson X X X X X
EmploymentInfo X X X X X X
EnrollmentInfo X
GDS X X X X
GroundTransportationPref X X X X X X
GroupInfo X
HotelPref X X X X X X
Incentives X
Login X X X X X X
Login/@LoginID X X X X X X
Login/@PasswordHash X X X X X X
MergedProfiles X
NotificationPref X X X X X X
NumberOfAssocProfiles X X X X X X
OSI X X X X
ParentTemplateAssociatedFilters X X X X X X
PaymentForm X X X X X X
PersonName X
PriorityRemarks X X X X X X
PsychographicCategory X X X X X X
QueueAssignments X X
RailPref X X X X X X
RelatedIndividual X
Remark X X X X X X
SabreCorporateTravelPolicy X X X X X
SabreSecurityEntityAttribute
SabreTravelPolicy X X X X X
SabreTravelPolicyEngine X X X X X
SocialMedia X X X X X X
SSR X X X X
StandardProfileRoles X
STARData X X X X X X
TaxInfo X
Telephone X X X X X X
TemplateAssociatedFilters X X X X X X
VehicleRentalPref X X X X X X
Sample XML Read Successful Response
When a profile is successfully retrieved, the following response is returned.
<Sabre_OTA_ProfileReadRS xmlns="http://www.sabre.com/eps/schemas">
<ResponseMessage>
<Success />
</ResponseMessage>
<Profile CreateDateTime="2008-02-28T08:46:45.524"
UpdateDateTime="2008-02-28T08:46:45.524" PrimaryLangID="EN-US">
<TPA_Identity UniqueID="4245" ProfileType="TVL"
ClientCode="EXT" ProfileName="MyPro" DomainID="L3OB"
ProfileStatus="AC">
<Login LoginID="stepien222@abc.com"
PasswordHash="gra8EoFe8RBh+iBMY+04p8oLguQ4 =" />
</TPA_Identity>
</Profile>
</Sabre_OTA_ProfileReadRS>
The most important section is the Profile section which contains the retrieved Profile. If the Profile was
successfully created, but there were no updates on this profile, then the CreateDateTime and the
UpdateDateTime attributes contain the same timestamp.
Credit Card Tokenizer
Web service users can request credit card numbers returned in a ProfileReadRS response to be tokenized.
In order to receive a tokenized credit card number, the web service call has to include the
ReturnPaymentCardToken attribute with a value of “Y” in the request message.
When Sabre_OTA_ProfileReadRQ/@ReturnPaymentCardToken ="Y" is included in the request, a

tokenized credit card number is returned in the response and is placed in the following attribute in the
response messages whenever a credit card is returned as a payment form:
PaymentForm/PaymentCard/@CardToken.
This attribute is optional and can contain alphanumeric characters.
If the retrieved profile contains credit card data in the Payment Form subject area, it can be shown in
different ways depending on the agent’s EPR Keywords used to create the session. If the agent’s account
(EPR) does not have the Keyword ‘CCVIEW’ assigned (or if the OSCCVIEW permission is not assigned) then
the credit card number in the Payment Form within the retrieved profile will contain
CardNumber="NOACCESS" and CCViewAccess="N" .
A sample response looks like this:
<PaymentForm DisplaySequenceNo="1" OrderSequenceNo="1" TripTypeCode="LS"

ServiceUsageTypeCode="AL" InformationText="PaymentForm">
<PaymentCard CardTypeCode="CR" BankCardVendorCode="BA" CardNumber="NOACCESS"
MaskedCardNumber="1111" CCViewAccess="N" EffectiveDate="012010" ExpireDate="012015" FirstRemark="N"
ExtendedPaymentNumMonths="5">
<CardHolderName>
<CardHolderFullName>JOHN DOE</CardHolderFullName>
<NamePrefix>MR</NamePrefix>
<GivenName>JOHN</GivenName>
<MiddleName>DALLAS</MiddleName>
<SurName>DOE</SurName>
</CardHolderName>
<CardIssuerName IssueNumberText="1234" IssuerName="DALLAS"/>
</PaymentCard>
</PaymentForm>
If the agent’s account (EPR) has the ‘CCVIEW’ Keyword or the OSCCVIEW permission assigned, the
CardNumber will be returned in the Read response:

ServiceUsageTypeCode="AL" InformationText="PaymentForm">
<PaymentCard CardTypeCode="CR" BankCardVendorCode="BA" CardNumber="371111111111111"
MaskedCardNumber="1111" CCViewAccess="Y" EffectiveDate="012016" ExpireDate="012018" FirstRemark="N"
<CardHolderName>
<CardHolderFullName>JOHN DOE</CardHolderFullName>
</CardHolderName>
<CardIssuerName IssueNumberText="1234" IssuerName="DALLAS"/>
</PaymentCard>
</PaymentForm>
If the request is sent with Sabre_OTA_ProfileReadRQ@ReturnPaymentCardToken = “Y” then the

response message returns an encrypted card number in PaymentCard/@CardToken attribute.
<PaymentCard CardTypeCode="CR" BankCardVendorCode="BA" CardNumber="371111111111111"

MaskedCardNumber="1111" CardToken="444P104AVMT1111" CCViewAccess="Y" EffectiveDate="012016"
ExpireDate="012018" FirstRemark="N" ExtendedPaymentNumMonths="5">
If the profile contains any Associated Profiles, they are returned in the Profile Read response as well. A
sample Read response with Associated Profiles is shown below:
<Sabre_OTA_ProfileReadRS Version="5.1" xmlns="http://www.sabre.com/eps/schemas">

<ResponseMessage>
<Success/>
</ResponseMessage>
<Profile
CreateDateTime="2010-09-14T11:21:36.294Z"
PrimaryLanguageIDCode="EN-US"
UpdateDateTime="2010-09-14T11:21:36.294Z">
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP” DomainID="A5CE" ProfileDescription="9 associated
profiles" ProfileNameModifyIndicator="Y" ProfileStatusCode="AC" ProfileTypeCode="TVL"
UniqueID="101333348"/>
<Traveler>
<TPA_Extensions>
<AssociatedProfiles AssocFiltersInd="N" AssocProfileDescription="Oksana profile" AssocProfileTypeCode="TVL"
AssocUniqueID="101333340" ClientCode="TN" ClientContextCode=“TMP” CreditBankIndicator="N"
DomainID="A5CE" ProfileRelationTypeCode="AL"/>
<AssociatedProfiles AssocFiltersInd="N" AssocProfileDescription="Profile desc" AssocProfileTypeCode="TVL"
AssocUniqueID="101333344" ClientCode="TN" ClientContextCode=“TMP” DomainID="A5CE"
ProfileRelationTypeCode="AL"/>
<AssociatedProfiles AssocFiltersInd="Y" AssocProfileDescription="2008-06-06 profile"
AssocProfileTypeCode="TVL" AssocUniqueID="101333332" ClientCode="TN" ClientContextCode=“TMP”
DomainID="A5CE" ProfileRelationTypeCode="AL"/>
<NumberOfAssocProfiles Traveler="3"/>
</TPA_Extensions>
</Traveler>
</Profile>
The <NumberOfAssocProfiles> element indicates the total number of associations directly attached to
the profile. This includes all bidirectional associations: all profiles that the Primary Profile is associated to
and the number of profiles associated to the Primary profile. The total count of Traveler, Travel Agent,
Travel Agency, Corporation, Group and Operational profiles is included in this section.
Sample XML Read Error Response
When a profile cannot be read for some reason, an error message is returned. Each error message
contains an <Errors> section with an Error Code and a short description of the problem which was
encountered during the profile reading process. For the Sabre Profiles Read Service, each Error message
is prefixed with “R:::”. A sample error message is shown below:
<Sabre_OTA_ProfileReadRS>
<ResponseMessage>
<Errors>
R:::TVL::No profiles are found which match your selection criteria (UniqueID=766, ClientCode=TN,
DomainID=IM07, ClientContextCode=EXT, ProfileType=TVL, LoginID=null, Password=null)
</ErrorMessage>
</Errors>
</ResponseMessage>
In the above example, the Profile which was supposed to be retrieved, does not exist in the Sabre Profiles
database.
Update Service 7
Updating Profiles
A profile can be updated using a full replacement of the data.
To fully update a traveler profile, values of UpdateDateTime and CreateDateTime are needed. Those can
be retrieved in a ProfileReadRS. See How to Update a Profile ignoring time stamp check section to find
out about alternative methods.
Timestamps are generated by the Profile system using the date and time on the platform contained in the
Sabre Profiles database. Once the web client merges the changed data with the unchanged data that was
retrieved, the web client sends the merged data back to Sabre Profiles using the timestamp from the
retrieval. The Sabre Profiles application uses the timestamp to maintain data integrity. If another web
client updates the profile prior to the receipt of the update from this client, the timestamp would not
match the timestamp in the Sabre Profiles database and an error response would be returned indicating a
SIMULTANEOUS_UPDATE error. The web client needs to retrieve the profile again, merge the changes
again, and resend the update.
Sabre_OTA_ProfileUpdateRQ also has the capability of ignoring specified subject areas during update
operation.
<IgnoreSubjectArea> tells what subject areas are not of interest in the profile update and shall remain
unchanged. In this case, all subject areas of the profile are updated except subject areas mentioned in
<IgnoreSubjectArea>. This feature is currently only fully applicable to TVL Profiles. Here is a Sample
Profile update request with <IgnoreSubjectArea>
<Sabre_OTA_ProfileUpdateRQ Target="Production" TimeStamp="2016-10-06T09:24:11.393Z" Version="1.0"

xsi:schemaLocation="http://www.sabre.com/eps/schemas \schemas\Sabre_OTA_ProfileUpdateRQ.xsd"
xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ProfileInfo>
<Profile CreateDateTime="2016-10-06T09:24:11.393Z" UpdateDateTime="">
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP" UniqueID="" ProfileTypeCode="TVL"
DomainID="ABFE" ProfileName="TestProfile_2016-10-06 " ProfileStatusCode="AC" ProfilePurgeNoDays="797"
ProfileNameModifyIndicator="Y"/>
<Traveler>
<Customer CountryOfResidence="US" BirthDate="2016-10-06" ChildIndicator="Y" SeniorIndicator="Y"
LapInfantIndicator="N" IsSubjectToSecureFlightRule="N" NationalityCode="US">
<PersonName DisplaySequenceNo="1" OrderSequenceNo="1" InformationText="Info"
VIT_LineType="A" VIT_OrderNmbr="1" VIT_SecondaryQualifier="F">
<NamePrefix>MISS</NamePrefix>
<GivenName>JUDE</GivenName>
<MiddleName>JUDE</MiddleName>
<SurName>STEWARD</SurName>
</PersonName>
</Customer>
</Traveler>
<IgnoreSubjectArea>
<SubjectAreaName>Discounts</SubjectAreaName>
</IgnoreSubjectArea>
</Profile>
</ProfileInfo>
</Sabre_OTA_ProfileUpdateRQ>
A list of subject area names that can be used within Update with IgnoreSubjecArea for each Profile Type
is found in table below. Supported subject areas are marked with “X”.
Important Note: Currently, this is only fully supported for TVL Profiles. The remaining profile types will be
available for full use in the future.
Address X X X X X X
AirlinePref X X X X
AnalyticalInfoGroup X
AssociatedFilters X
AssociatedFormats X
AssociatedProfiles X
Association X
BusinessSystemIdentityInfo X
Consent X
CustLoyalty X X
CustomDefinedData X
CustomDefinedValues X
CustomerReferenceInfo X
CustomerValueScore X
DeclaredTravelHistory X
Discounts X
Document X
Email X X X X X X
EmergencyContactPerson X
EmploymentInfo X
EnrollmentInfo X
GroundTransportationPref X X
HotelPref X X
LoungePref X
NotificationPref X
OSI X
PaymentForm X X X X X
PersonName X
PriorityRemarks X
ProfileSubType X
PsychographicCategory X
RailPref X X
RelatedIndividual X
Remark X
SabreCorporateTravelPolicy X
SabreTravelPolicy X
SabreTravelPolicyEngine X
SocialMediaAccounts X
SSR X
STARData X X X X X X
TaxInfo X
Telephone X X X X X X
VehicleRentalPref X X
Type SubjectAreaName XPath
AirlinePref /Traveler/PrefCollections/AirlinePref
HotelPref /Traveler/PrefCollections/HotelPref
VehicleRentalPref /Traveler/PrefCollections/VehicleRentalPref
RailPref /Traveler/PrefCollections/RailPref
GroundTransportationPref /Traveler/PrefCollections/GroundTransportationPref
LoungePref /Traveler/PrefCollections/LoungePref
NotificationPref /Traveler/PrefCollections/TPA_MarketingPreference/NotificationPre
ference
Consent /Traveler/PrefCollections/TPA_MarketingPreference/Consent
PsychographicCategory /Traveler/PrefCollections/TPA_MarketingPreference/Psychographic
Category
DeclaredTravelHistory /Traveler/PrefCollections/TPA_MarketingPreference/DeclaredTravel
HistoryPreference
PriorityRemarks /Traveler/TPA_Extensions/PriorityRemarks
TRAVELER
Remark /Traveler/TPA_Extensions/Remark
SSR /Traveler/TPA_Extensions/SSR
OSI /Traveler/TPA_Extensions/OSI
CustomerReferenceInfo /Traveler/TPA_Extensions/CustomerReferenceInfo
AssociatedProfiles /Traveler/TPA_Extensions/AssociatedProfiles
AssociatedFilters /Traveler/TPA_Extensions/AssociatedFilters
AssociatedFormats /Traveler/TPA_Extensions/ AssociatedFormats
TaxInfo /Traveler/TPA_Extensions/ TaxInfo
BusinessSystemIdentityInfo /Traveler/TPA_Extensions/ BusinessSystemIdentityInfo
Discounts /Traveler/TPA_Extensions/ Discounts
CustomDefinedData /Traveler/TPA_Extensions/CustomDefinedData
CustomDefinedValues /Traveler/TPA_Extensions/CustomDefinedValues
SabreTravelPolicyEngine /Traveler/TPA_Extensions/TravelPolicy/SabreTravelPolicyEngine
SabreCorporateTravelPolicy /Traveler/TPA_Extensions/TravelPolicy/SabreCorporateTravelPolicy
SabreTravelPolicy /Traveler/TPA_Extensions/TravelPolicy/SabreTravelPolicy
STARData /Traveler/TPA_Extensions/STARData
CustomerValueScore /Traveler/TPA_Extensions/CustomerValueScore
EnrollmentInfo /Traveler/TPA_Extensions/EnrollmentInfo
PersonName /Traveler/Customer/PersonName
Telephone /Traveler/Customer/Telephone
Address /Traveler/Customer/Address
Email /Traveler/Customer/Email
PaymentForm /Traveler/Customer/PaymentForm
RelatedIndividual /Traveler/Customer/RelatedIndividual
EmergencyContactPerson /Traveler/Customer/EmergencyContactPerson
Document /Traveler/Customer/Document
CustLoyalty /Traveler/Customer/CustLoyalty
EmploymentInfo /Traveler/Customer/EmploymentInfo
Association /Association
SocialMediaAccounts /SocialMediaAccounts
AnalyticalInfoGroups /AnalyticalInfoGroups
ProfileSubType /TPA_Identity/ProfileSubType
Telephone /TravelAgency/Telephone
Email /TravelAgency/Email
TRAVEL AGENCY
Address /TravelAgency/Address
PaymentForm /TravelAgency/PaymentForm
AirlinePref /TravelAgency/PrefCollections/AirlinePref
STARData /TravelAgency/STARData
Type SubjectAreaName XPath
Telephone /Corporation/Telephone
CORPORATION
Email /Corporation/Email
Address /Corporation/Address
STARData /Corporation/STARData
Telephone /GroupProfile/Telephone
Email /GroupProfile/Email
Address /GroupProfile/Address
PaymentForm /GroupProfile/PaymentForm
GROUP PROFILE
AirlinePref /GroupProfile/PrefCollections/AirlinePref
HotelPref /GroupProfile/PrefCollections/HotelPref
VehicleRentalPref /GroupProfile/PrefCollections/VehicleRentalPref
RailPref /GroupProfile/PrefCollections/RailPref
GroundTransportationPref /GroupProfile/PrefCollections/GroundTransportationPref
STARData /GroupProfile/STARData
Telephone /TravelAgent/Telephone
Email /TravelAgent/Email
Address /TravelAgent/Address
TRAVEL AGENT
CustLoyalty /TravelAgent/CustLoyalty
PaymentForm /TravelAgent/PaymentForm
AirlinePref /TravelAgent/PrefCollections/AirlinePref
STARData /TravelAgent/STARData
Telephone /OperationalProfile/Telephone
OPERATIONAL PROFILE
Email /OperationalProfile/Email
Address /OperationalProfile/Address
PaymentForm /OperationalProfile/PaymentForm
STARData /OperationalProfile/STARData
How to Update a Profile using Full Replace
This is the recommended standard best practice for Sabre Profiles Updates.
The full traveler profile update request is shown below:

<Sabre_OTA_ProfileUpdateRQ Version="1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.sabre.com/eps/schemas"
schemas\Sabre_OTA_ProfileUpdateRQ.xsd">
<ProfileInfo>
UpdateDateTime="2008-02-26T09:26:12.211"
PrimaryLangIDCode="EN-US">
<TPA_Identity UniqueID="4259" ProfileTypeCode="TVL"
ClientContextCode=“TMP”
ClientCode="TN" ProfileStatus="IN"
DomainID=“A5BE” ProfileName="Updated Profile"
ProfilePurgeNoOfDays="7">
<Login LoginID="greg222@abc.com"
PasswordHash="gra8EoFe8RBh+iBMY+ =" />
</TPA_Identity>
<Traveler>
<!—NOTE: the contents of the Profile sub tree are the same as can be seen in the
Sabre_OTA_ProfileCreateRQ traveler section above. -->
</Traveler>
</Profile>
</ProfileInfo>
To successfully update the profile, it is necessary to use proper values in the UpdateRQ. The following
attributes are crucial: CreateDateTime, UpdateDateTime, UniqueID, ProfileTypeCode, ClientCode,
ClientContextCode and DomainID. The UniqueID, ProfileTypeCode, ClientCode, ClientContextCode and
DomainID identify a specific profile, whereas the CreateDateTime and UpdateDateTime – a specific
historical snapshot of a profile.
Profiles customer can also update a profile by specifying the Profile AuxiliaryID (3rd party system Profile
ID), ClientContextCode, ClientCode, DomainID and ProfileType.
<Sabre_OTA_ProfileUpdateRQ Version="1.0"
<ProfileInfo>
<Profile CreateDateTime="2016-11-10T15:01:03.378Z" UpdateDateTime="2016-11-
10T14:01:03.681Z">
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP" UniqueID="*" ProfileTypeCode="TVL"
DomainID="A5BE" ProfileName="TestProfile_2016-11-10 ">
<AuxiliaryID IDTypeCode="AGTLOGIN" Identifier="8732879280ca3"/>
</TPA_Identity>
</Profile>
</ProfileInfo>
This section is optional, but once provided it will be validated. If the validation process fails, an error
message is returned.
Within the Full Update process there are two main stages. The first one is responsible for the deletion of
the old profile data. The second stage saves the new full profile data provided in the ProfileUpdateRQ.
Note: Similarly, profile updates can be done to other ProfileTypes by simply replacing the Profile Type
Code with the corresponding value (i.e. ProfileTypeCode="TVL" , vs. “CRP”, “AGT”, “AGY”,”GRP” or
“OPX”)
How to Update a Profile ignoring time stamp check
UpdateDateTime and CreateDateTime attributes can be ignored by passing the

Sabre_OTA_ProfileUpdateRQ/@IgnoreTimeStampCheck = “Y” attribute. In this case the update request is
not going to run the time stamp check validation. This should only be used when you are updating from
another master profile system, as any changes that may have been made to the profile by another user or
system will be overwritten by this UpdateRQ. NOTE: Profile/@CreateDateTime and
Profile/@UpdateDateTime still need to be passed as they are required attributes. Dummy values could be
used here. Example request:
<Sabre_OTA_ProfileUpdateRQ Version="1.0" IgnoreTimeStampCheck=”Y”

<ProfileInfo>
UpdateDateTime="2008-02-26T09:26:12.211"
PrimaryLangIDCode="EN-US">
ClientContextCode=“TMP”
ClientCode="TN" ProfileStatus="IN"
DomainID=“A5BE” ProfileName="Updated Profile"
ProfilePurgeNoOfDays="7">
<Login LoginID="greg222@abc.com"
PasswordHash="gra8EoFe8RBh+iBMY+ =" />
</TPA_Identity>
<Traveler>
<!—NOTE: the contents of the Profile sub tree are the same as can be seen in the
Sabre_OTA_ProfileCreateRQ traveler section above. -->
</Traveler>
</Profile>
</ProfileInfo>
Sample XML Update Successful Response
A successful update result is shown in the following response. Note the <Success> element:
<Sabre_OTA_ProfileUpdateRS xmlns="http://www.sabre.com/eps/schemas"
Version="1">
<ResponseMessage>
<Success />
</ResponseMessage>
<Profile UniqueID="3821" ProfileType="TVL" ClientCode="EXT"
ProfileName="Updated Profile Name" DomainID="IM08">
</Profile>
</Sabre_OTA_ProfileUpdateRS>
Sample XML Update Error Response
When, for any reason, a profile could not be fully updated, an error message is returned. Each error
message contains an <Errors> section with an Error Code and a short description of the problem which
was encountered during the profile update process. For the Sabre Profiles Update Service, each Error
message is prefixed with “U:::”. A sample error message is shown below:
<Sabre_OTA_ProfileUpdateRS Version="1">
<ResponseMessage>
<Errors>
U:::LoginID/Password was not specified for ABC profile
</ErrorMessage>
</Errors>
</ResponseMessage>
<Profile ClientCode="TN" ClientContextCode=“TMP” UniqueID="34" ProfileTypeCode="TVL"
ProfileName="NetCheck Profile" ProfileDescription="NetCheck Agency Test Profile" DomainID="ABC1"
ProfileStatusCode="AC"/>
In the above example the ABC profile could not be updated, because the Login section was not specified
in the incoming Full ProfileUpdateRQ.
For ProfileUpdate that include an AuxiliaryID, the following errors can be returned
AuxiliaryID/@IDTypeCode does not exist:
<Sabre_OTA_ProfileUpdateRS TimeStamp="2016-10-17T15:59:53.808Z" Version="6.28"

<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode="920">U::NPPPTN-INT2T20161017155953SU::Invalid auxiliary id type code:
WRONGAUXID</ErrorMessage>
</Errors>
</ResponseMessage>
<Profile ClientCode="TN" ClientContextCode=“TMP" UniqueID="114996792" ProfileTypeCode="TVL"
ProfileName="2016-07-08T17:01:03.112Z" DomainID="A2FE">
<AuxiliaryID IDTypeCode="WRONGAUXID" Identifier="0000000000"/>
</Profile>
Search Service 8
Searching for Profiles
Profile search functionality allows a user to search for profiles in a PCC/Domain using specific search
criteria. These are considered Online searches using the Sabre_OTA_ProfileSearchRQ service and are
executed immediately as the call is sent to the Profiles system. In another section we will cover Offline
searches using various OfflineJob services. These offline searches involve specific scenarios for larger
search jobs that can take a longer time to process and return results and are executed in the order
submitted via a system queue.
Online Profile Search
The most crucial attributes specified in the ProfileSearchRQ are: SearchOperationType and
ProfileNameOnly. The first defines the logical operator between search criteria (there is only one
operator: “AND” – if not provided, it will be automatically set to ‘AND’). Along with these attributes, a
user can specify two additional attributes: PageNumber and ReturnCount. These two attributes are used
for the Repetitive Search.
Note: For all searches, the maximum result count is set to 250. If the number of matches exceeds this
count, the user will need to further refine the search parameters. In the absence of a specified count
number, the default value is set to return 25. In case of ProfileNameOnly=’Y’ the default can be set to 50.
The Basic Search Criteria must be specified in the incoming ProfileSearchRQ.
The ProfileTypeCode can be set either to the specific profile type (in case of traveler profiles it should
be set to ‘TVL’), the list of profile types (“TVL,AGY”), or to ‘ALL’. In the third scenario, the user can
search for profiles of each type (‘TVL’, ‘AGY’, ‘CRP’, ‘AGT, ‘GRP’ and ‘OPX’). The DomainID can be set
to a specific value or it can be set to ‘*’. The Sabre Profiles search engine will retrieve a list of all user-
specific DomainIDs from the Session (this is the equivalent of searching across PCCs for which the
user has Branch Access rights.), and then it will search for profiles with a DomainID from that list.
If the ProfileNameOnly is set to true (Y), in the ProfileSearchRS, the user will get only the TPA_Identity
section of the matching profiles. Otherwise, the user will get the TPA_Identity section along with the
profile(s) meeting the defined search criteria.
In the TPA_Identity Section there are two required attributes, the ClientCode (which is TN for Sabre Travel
Network clients) and the ClientContextCode (this is the dedicated identifier value assigned to external
systems calling the Sabre Profiles APIs). The remaining search criteria in this section is optional, however
if any other qualifiers are added, they will narrow the results set.
The online profile search allows a Sabre Profiles customer to search for profiles:
• By ProfileName
• By Traveler (GivenName, SurName, BirthDate, NamePrefix)
• By TravelAgency (AgencyName, TravelAgencyIdentifier)
• By TravelAgent (GivenName, SurName, BirthDate, NamePrefix)
• By Corporation (CorporationName, CorporationTypeCode)
• By GroupProfile (GroupName, GroupIdentifier)
• By EmailAddress
• By Telephone (AnyPhone, FullPhoneNumber, ParsedPhoneNumber)
• By TaxInfo
• By Address
• CustLoyalty
• CustomerReferenceInfo
• BusinessSystemIdentityInfo
• AssociatedProfiles
• PaymentForm
• Remark
• Document
• AssociatedTemplate
• Association
• SortPreference (SortByUniqueID, SortByProfileName, SortByCreateDate)
• Search Criteria (@PageNumber, @ReturnCount, @HaveMore)
• Deleted Profiles
• Searching for many Profiles
Credit Card Tokenizer
A web service user can request credit card numbers to be returned in a Search response as tokenized. In
order to receive a tokenized credit card number the web service call has to include the
ReturnPaymentCardToken attribute with a value of “Y” in the request message.
When Sabre_OTA_ProfileSearchRQ/@ReturnPaymentCardToken =”Y” is included in the request, a

tokenized credit card number is returned each time the PaymentForm/PaymentCard element is returned
in the response.
Sample XML Search Request
<Sabre_OTA_ProfileSearchRQ xmlns="http://www.sabre.com/eps/schemas"
schemas\Sabre_OTA_ProfileSearchRQ.xsd">
<ProfileSearchCriteria ProfileNameOnly="Yes"
SearchOperationType="AND">
<TPA_Identity DomainID=“A5BE” ClientCode="TN"
ClientContextCode=“TMP” ProfileTypeCode="TVL" ProfileName="MYS*" />
<Traveler Surname="Remik" GivenName="Smith"/>
<Email EmailAddress="remik.smith@sabre.com" />
<CustomerReferenceInfo ReferenceID="123" Type="Ref" />
</ProfileSearchCriteria>
</Sabre_OTA_ProfileSearchRQ>
In the above example, the ProfileNameOnly attribute has been set to ‘Y’, which means that only the
TPA_Identity of matching profiles will be returned.
There is a possibility to provide multiple search criteria in request. Although, regardless of how many
search criteria are defined in the ProfileSearchRQ query, only the first 2 (based on the list below) are
active and used during actual search operations. The sequence of subject areas criteria applied in the
profile search according to importance is as follows:
• Name
• TravelAgency
• Corporation
• Email
• Telephone
• Address
• TaxInfo
• CustLoyalty
• CustomerReference
• BirthDate
• PaymentCard
• BusinessSystemIdentity
• Remark
• Document
• AssociatedTemplate
• Group
• Association
Because of this rule, in the above example, search criteria for CustomerReferenceInfo will be silently
ignored.
Apart from the Basic Search Criteria, which has been discussed earlier, each search can contain an ‘*’ sign
to serve as a “wildcard”:
• Search Criterion = ‘*’ – all values of Search Criterion satisfy this condition
• Search Criterion = ‘ABC’ – this is an exact match
• Search Criterion = ‘AB*’ – this condition is satisfied only by these values that start from ‘AB’, which
is followed by zero or more characters ABXXX, ABC123, ABC, etc.
Note: the “*” as wildcard is supported only at the end of the string, but is not supported as a prefix
(i.e. =’*AB’ to search for any values that are preceded by letters AB is not supported)
By defining the SortPreference sub-element, a user can specify the order profiles are returned in the
response message which matches the search criteria. Profiles can be sorted in three ways:
• by ProfileName
• by their creation dates
• by their UniqueID
Repetitive Search and the Sample XML Search Request
With exception for the SearchOperationType and the ProfileNameOnly, a user can specify the following
two attributes: PageNumber and ReturnCount. These two attributes are used to execute the Repetitive
Search. This additional functionality has been added to provide a mechanism to retrieve only a sub-set of
matching profiles (the exact number of matching profiles the Sabre Profiles search engine is supposed to
return is determined by the ReturnCount) starting from a specific profile, which is determined by the
PageNumber. This functionality covers a request for “Give me the next (n) profiles” scenario.
To illustrate how this functionality works, assume there are 60 profiles which match the search criteria
and the user sets the ReturnCount to 20 and the PageNumber to 2.
Profile1
…
Profile20
Profile21
… Profiles returned in RS
Profile40
…
Profile60
The profiles returned appear in blue. To retrieve the next 20 profiles the user must increase the
PageNumber.
A sample Search request that includes the Repetitive Search is shown below:
<Sabre_OTA_ProfileSearchRQ xmlns="http://www.sabre.com/eps/schemas"
schemas\Sabre_OTA_ProfileSearchRQ.xsd" Version="1.0">
<ProfileSearchCriteria PageNumber="2" ReturnCount="20" >
<TPA_Identity DomainID="A5BE" ClientCode="TN" ClientContextCode=“TMP” ProfileTypeCode="TVL"/>
<Traveler Surname="Bear" GivenName="Vernon"/>
<Email EmailAddress="Bear.vernon*" />
Sample XML – Include Shared Association objects – Request/Response
When creating a profile, the user might want to perform a search to display all available association
objects to a profile. By setting AssociationSearchCriteria/Association/@IncludeShared to “Y” user is
requesting to include all shared Association objects that are linked to the Profile. This way all local
Association objects – from the PCC/domain that the user is AAA’d into - and all shared Association
objects – from all branched PCCs/domains – will be returned.
By setting AssociationSearchCriteria/Association/@Shared to “Y”, only shared Association objects are
going to be returned.
Example:
Given the user is AAA’d into A5CE domain, and that domain is branched to A2FE and A3ZE, and 4
association objects exist (as per table shown), below is how those 2 different attributes will work.
Association object Domain ID Shared

Association_1 A2FE Y
Association_2 A5CE Y
Association_3 A3ZE Y
Association_4 A5CE N
Request (IncludeShared = “Y”):
<Sabre_OTA_ProfileSearchRQ Version="6.21">
<AssociationSearchCriteria>
<Association IncludeShared="Y" DomainID="*" ClientCode="TN" ProfileTypeCode="TVL"/>
</AssociationSearchCriteria>
Response:
<Sabre_OTA_ProfileSearchRS Version="6.21">
<ResponseMessage>
<Success/>
</ResponseMessage>
<AssociationInfo>
<AssociationList NumReturned="4" HaveMore="N" PageNumber="1">
<Association AssociationID="651823" DomainID="A2FE" Shared="Y" ClientCode="TN"
AssociationName="Association_1" ClientContextCode=“TMP" ProfileTypeCode="TVL" />
<Association AssociationID="651825" DomainID="A5CE" Shared="Y" ClientCode="TN"
<Association AssociationID="651827" DomainID="A3ZE" Shared="Y" ClientCode="TN"
<Association AssociationID="651831" DomainID="A5CE" Shared="N" ClientCode="TN"
</AssociationList>
</AssociationInfo>
Request (Shared = “Y”):
<Sabre_OTA_ProfileSearchRQ Version="6.21">
<Association Shared="Y" DomainID="*" ClientCode="TN" ProfileTypeCode="TVL"/>
</AssociationSearchCriteria>
Response:
<Sabre_OTA_ProfileSearchRS Version="6.21">
<ResponseMessage>
<Success/>
</ResponseMessage>
<AssociationInfo>
<AssociationList NumReturned="4" HaveMore="N" PageNumber="1">
<Association AssociationID="651823" DomainID="A2FE" Shared="Y" ClientCode="TN"
<Association AssociationID="651825" DomainID="A5CE" Shared="Y" ClientCode="TN"
<Association AssociationID="651827" DomainID="A3ZE" Shared="Y" ClientCode="TN"
</AssociationList>
</AssociationInfo>
Sample XML – Exclude domain Profile search – Request
DomainID (PCC) is required in a ProfileSearchRQ. To search for Profiles in more than one PCC, an
additional attribute – ExcludeDomain can be used. If ExcludeDomain=”Y” in the ProfileSearchRQ then
Sabre Profiles will search for the Profile(s) in the PCC sent in the request as well as all branched PCCs.
Only a single PCC is searched if ExcludeDomain=”N” or ExcludeDomain is not used.
Below is a sample request message for a profile search scenario for domain A2FE to include all domains
branched to A2FE in the response message:
<Sabre_OTA_ProfileSearchRQ Target="Production" TimeStamp="2015-03-13T13:40:11.363Z" Version="0.0"

xsi:schemaLocation="http://www.sabre.com/eps/schemas \schemas\Sabre_OTA_ProfileSearchRQ.xsd"
<ProfileSearchCriteria ExcludeDomain="Y">
<TPA_Identity ClientCode="TN" ClientContextCode="ABC" DomainID="A2FE" ProfileTypeCode="TVL"
ProfileName="TestProfile_2015-03-13_13:40:11_jeG"/>
Sample XML Profile Name Only Search List Response
Below is a sample Response message where the incoming Search request contains the ProfileNameOnly
as set to ‘Yes’:
<Sabre_OTA_ProfileSearchRS xmlns="http://www.sabre.com/eps/schemas"
Version="1">
<ResponseMessage>
<Success />
</ResponseMessage>
<ProfileInfo>
<Message>Count: 2</Message>
<ProfileList>
<Profile NumReturned="2" HaveMore="N">
<TPA_Identity UniqueID="4267" ProfileTypeCode="TVL" ClientCode="TN"
ProfileName="MYPROFILE" DomainID="A5BE">
</TPA_Identity>
</Profile>
</ProfileList>
<ProfileList>
<Profile>
ProfileName="MYPROFILE" DomainID="A5BE">
</TPA_Identity>
</Profile>
</ProfileList>
</ProfileInfo>
The primary profile results of the Response message is found in the ProfileInfo section. The following
information is found in this section:
• The number of profiles that matched the search criteria

• The TPA_Identity sections of all the profiles that matched the search criteria
Sample XML Search Single Response
If there is only one profile which matches the search criteria, the response message looks like this:
<?xml version="1.0" encoding="utf-8"?>

Version="1">
<ResponseMessage>
<Success />
</ResponseMessage>
<ProfileInfo>
UpdateDateTime="2013-03-03T12:08:03.19" PrimaryLangIDCode="en-US">
ProfileName="GEORGE" DomainID="A1B2" ProfileStatus="AC">
</TPA_Identity>
<Traveler>
<!—All information about traveler-->
</Traveler>
</Profile>
</ProfileInfo>
One thing in the above example worth noting is that despite the value of the ProfileNameOnly attribute,
when only one profile matches the search criteria, all the profile data is returned (like a ProfileReadRQ)
from the Sabre Profiles database (not only the TPA_Identity section).
Sample XML Full Information Search List Response
If the ProfileNameOnly is set to False (N), for every profile that matches the search criteria, the following
information is retrieved from the Sabre Profiles database:
• TPA_Identity
• PersonName
• Telephone
• Email
• Address
• AssociatedProfiles
• Customer Reference Info
A sample Response message looks like this:
<xml version="1.0" encoding="utf-8"?>

Version="1">
<ResponseMessage>
<Success />
</ResponseMessage>
<ProfileInfo>
<ProfileList NumReturned="2" HaveMore="N">
<Profile>
ProfileName="GREGPROFILE" DomainID="L3OB">
</TPA_Identity>
<Traveler>
<!—-Profile information: PersonName, Telephone, Email, Address, Associated Profiles Customer Reference Info-->
</Traveler>
</Profile>
</ProfileList>
<ProfileList>
<Profile>
ProfileName="GREGPROFILE1" DomainID="L3OB">
</TPA_Identity>
<Traveler>
<!—-Profile information: PersonName, Telephone, Email, Address, Associated Profiles Customer Reference Info-->
</Traveler>
</Profile>
</ProfileList>
</ProfileInfo>
As seen in the example above, along with TPA_Identity section additional data is returned for each profile
that matched the search criteria.
Sample XML Has More Results Response Message
If the user sets the ProfileNameOnly to ‘Y’ (Yes), then the maximum number of profiles that can be
retrieved from the Sabre Profiles database is set to 250. By default, the number of profiles returned is set
to 25, but it can support up to the maximum value in the Search Request. On the other hand, if the
ProfileNameOnly is set to ‘No’, the maximum number of profiles is set to 250. If the number of profiles
matching the search criteria exceeds the requested number of returned profiles, then the following
Response message is returned:
Version="1">
<ResponseMessage>
<Success />
</ResponseMessage>
<ProfileInfo>
<ProfileList NumReturned="20" HaveMore="Y">
<Profile>
ProfileName="GREGPROFILE" DomainID="L3OB">
</TPA_Identity>
<Traveler>
<!—-Profile information: PersonName, Telephone, Email, Address,
Associated Profiles Customer Reference Info-->
</Traveler>
</Profile>
</ProfileList>
<ProfileList>
<Profile>
ProfileName="GREGPROFILE1" DomainID="L3OB">
</TPA_Identity>
<Traveler>
<!—-Profile information : PersonName, Telephone, Email, Address,
Associated Profiles Customer Reference Info-->
</Traveler>
</Profile>
<-- Remaining profiles -->
</ProfileList>
</ProfileInfo>
In this case, the only difference is that the HaveMore attribute is set to ‘Y’ instead of ‘N’.
Sample XML No Results Response Message
If there are no profiles in the Sabre Profiles database that match the search criteria, then the following
Response message is returned:
<ResponseMessage>
<Success />
</ResponseMessage>
<ProfileInfo>
<Message>
No profiles are found which match your selection criteria
</Message>
</ProfileInfo>
</ResponseMessage>
Sample XML Search Error Response
When a search operation cannot be performed for some reason, an error Response message is returned.
Each error message contains an <Errors> section with an Error Code and a short description of the
problem which was encountered during the profile search process. A sample error message is shown
below:
For the Sabre Profiles Search Service, each Error message is prefixed with “S:::”. An example error
message is shown below:
<Sabre_OTA_ProfileSearchRS Version="1">
<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode=”123”>S:::Invalid XML (not compliant with Schema):
cvc-complex-type.4: Attribute 'ClientContextCode' must appear on element
'TPA_Identity'.</ErrorMessage>
</Errors>
</ResponseMessage>
Offline Profile Search
Currently the Sabre Profiles system offers profile search capability that is mainly used during the
reservation process (booking path). This is when an agent intends to look for a single profile or a limited
number of profiles in order to make a reservation in the Sabre GDS and producing a PNR with the
reservation details while servicing their client. However, the agency often needs to perform extensive
searches scanning through the Sabre Profiles database to produce a report of profiles that match their
specific search criteria to consult with their customers and action the list of profiles for a number of
reasons. While the booking path searches need to be performed immediately online (synchronously) and
they are lightweight operations, the report searches might take longer than what the agency expects and
also can be very resource demanding operations. Thus some scenarios which could return larger profile
results, based upon specific search criteria, will be performed offline (asynchronously).
Online searches: Offline searches:

1. Are performed mainly by agents during 1. Are performed by an agency in order to
the reservation process. produce reports.
2. Use tight criteria, that involve very 2. Use filtering criteria that may be very
selective fields with smaller amounts of profile inclusive.
results returned.
3. Are online (synchronous) operations that 3. Are offline (asynchronous) operations that
return profiles within seconds. can produce results within a 24 hour time frame
4. Return single or a small list of profiles in 4. Could return a large list of profiles in the
the search response. search response.
The offline profile search allows a Sabre Profiles customer to search for profiles:
• OfflineSearch (9 scenarios):
o By Document
o By CustLoyalty
o By PrefCollections
o By Remarks
o By EmployeeInfo
o By CustomDefinedData
o By CustomDefinedValues
o By Discounts
o By PaymentCard
• OfflineSearch by AssociatedProfiles (9 scenarios):
o By Document
o By CustLoyalty
o By PrefCollections
o By Remarks
o By EmployeeInfo
o By CustomDefinedData
o By CustomDefinedValues
o By Discounts
o By PaymentCard
How Offline Search Works
The design is based on the idea of using a search job scheduler. The Scheduler accepts requests for
executing searches, but it delays the actual execution of the search until the system resources which
perform the search are available. The inner mechanism is that the scheduler maintains the queue (first in
- first served) of search requests (or “jobs”) and runs them against the database sequentially (one after
the other). Once the search has been executed, the resulting list of matching profiles found is available
for the user to retrieve.
Actions of submitting searches, querying search job statuses, retrieving results, deleting search jobs, and
cancelling search jobs are all performed by the 5 available Sabre Profiles Web Services using a dedicated
schema for each type of message. Each call returns immediately, and none of the calls perform the actual
search.
1. The initial call submits the request for the search along with the search scenario name and search
parameters. The response sends back ACK message, acknowledging that the search request was
accepted and awaits its execution.
2. Then the user can send a message querying the scheduled search list. The response lists all of the
active jobs belonging to a certain agency (PCC), each with its current status of NEW,
PROGRESSING, SUCCESS, or FAILED.
3. Once the job is completed the user sends the request that retrieves the list of profiles matching
the search criteria. Since the list may contain a large number of Profiles, the list can be retrieved
by ‘pages’, meaning that the user retrieves only a certain number of Profiles in one request and
then sends a follow-up request for next batch (or ‘page’) of profiles until all are returned to the
client.
4. Additionally two more types of messages are available.
a. One allows the user to cancel a job already submitted, but not started or in progress.
Example: The user finds that the request is a duplicate and wishes to stop the incomplete
request.
b. The other is for removing a completed job for which the results have already been
retrieved and are no longer needed for tracking.
5. Additional rules apply:
a. The job wait time can be up to 24 hours.
b. Completed Search results are stored for 7 days. After 7 days from completion, the results
are automatically purged by the Profiles system.
c. The search results contain the list of Profiles matching the initial search criteria and each
item contains only the profile summary which consists of the UniqueID, ProfileTypeCode,
DomainID (PCC) and the ProfileName.
d. The number of profile items that can be retrieved in one message is limited to 250.
6. Within the initial job create request, the user has the option to receive an email notification once
the offline search job has completed. If this option is utilized, the Sabre Profiles System will send
an email to the email address the user defined during the initial job create request advising that
the offline job has completed and if it was successful or if it failed. If the job failed, the user will
be provided an error code within the email notification at which time they can send a service call
request to read the job results to get more details on the error(s) causing the job failure.
7. The functionality also exists to return profiles where either the data specified in the search
request contains a stored value of “NULL” or space “ “, or the desired attribute is missing
completely in the profile.
a. If the specified search scenario contains attributes which are defined in the schema to
use a control table (pre-defined values for user selection) or are specifically formatted for
dates, the functionality to search for NULL, space, or missing attributes does not apply.
b. In some scenarios wild card searches are allowed (if the attribute is not required in the
schema or supported by a control table). Example: “*” and “AB*” are supported wild card
searches. In these cases, aall search results will include profiles that have any value
stored which would include “NULL” and space “ “ for the designated search criteria.
c. The addition of the BlankCriteria element was introduced in some search scenarios to
return any profiles which do not contain the requested search criteria within the profile.
For example, the profile may not contain the specified attribute submitted in the job
request search criteria. If the user wants to know which profiles do not contain the search
criteria, they will send as an example BlankCriteria=”ExpireDate” in the service call to
achieve this. This will return profiles that do not contain the attribute ExpireDate for the
defined subject area within the offline search job create request service call.
Supported Offline Job Search Scenarios
Customers have the ability to execute the following offline searches.
1. Expired credit cards in PaymentForm subject area, or search on the expiration date for a
future date or range of dates.
2. Expired documents in the Documents subject area, or search on the expiration date for a
future date or range of dates.
3. Expired discounts (all vendor types such as Air, Car, Hotel, Rail, etc.) and discount type in the
Discounts subject area, or search on the expiration date for a future date or range of dates.
4. Specific loyalty vendor codes (Air, Car, Hotel, etc.) in the CustyLoyalty Subject area. This
search provides the ability to search on two data elements; VendorTypeCode and
VendorCode.
5. Specific vendor preferences (air vendors, car vendors, hotel vendors, etc.) in the Air
Preferences, Car Preferences, Hotel Preferences, Rail Preferences subject areas.
6. Search for a specific data string in Remark>Text where Remark>TypeCode=”PNR” and
CategoryCode=”OT”. (This is known as the ‘Other PNR Move Data’ within the Sabre Profiles
GUI within Sabre Red Workspace).
• The use of wildcard searches “*” and “AB*” are allowed in this scenario.
7. Specific data string in the CustomDefinedData and CustomDefinedValues subject areas.
• The use of wildcard searches “*” and “AB*” are allowed in these scenarios.
8. Specific data string in the EmploymentInfo subject area for Cost Center, BusinessUnit,
DepartmentID, or ProjectName.
• The use of wildcard searches “*” and “AB*” are allowed in these scenarios.
Offline Job Search Services
The five message types reflect the five Sabre Web Services:
1. Create Job
Actions: EPS_OfflineJobCreateRQ, EPS_EXT_OfflineJobCreateRQ
Schema: Sabre_OTA_OfflineJobCreateRQ
2. Read Job Result
Actions: EPS_OfflineJobReadResultRQ, EPS_EXT_OfflineJobReadResultRQ
Schema: Sabre_OTA_OfflineJobReadResultRQ
3. Retrieve Jobs
Actions: EPS_OfflineJobRetrieveRQ, EPS_EXT_OfflineJobRetrieveRQ
Schema: Sabre_OTA_OfflineJobRetrieveRQ
4. Cancel Job
Actions: EPS_OfflineJobCancelRQ, EPS_EXT_OfflineJobCancelRQ
Schema: Sabre_OTA_OfflineJobCancelRQ
5. Delete Job
Actions: EPS_OfflineJobDeleteRQ, EPS_EXT_OfflineJobDeleteRQ
Schema: Sabre_OTA_OfflineJobDeleteRQ
The Offline Job Lifecycle
During its lifecycle the job goes through a number of states. The below state diagram illustrates the
transitions between states along with the message types that trigger the transitions.
Roles and Permissions related to Offline Job Search
To utilize the Offline Job Search Services, the user’s Agent Profile, which was synced from their EPR in the
Sabre GDS, should have the necessary Standard Role assigned as defined below.
1. Within an agency, only users with “Agency Administrator” and “Super User” assigned roles can
access the offline search functionality.
2. Users with the assigned role of “Agency Administrator” can submit new jobs and have visibility to
all jobs within all branched domains/PCCs for that agency. They can only delete the jobs they
created themselves.
3. Users with the assigned role of “Super User” have the same privileges as “Agency Administrators”
and they can delete jobs created by other users within their authorized branched domains/PCCs.
other
user domain branched domains
domains
EPS_OfflineJobCreateRQ EPS_OfflineJobCreateRQ
EPS_OfflineJobRetrieveRQ EPS_OfflineJobRetrieveRQ
owned jobs EPS_OfflineJobReadResultRQ EPS_OfflineJobReadResultRQ none
EPS_OfflineJobCancelRQ EPS_OfflineJobCancelRQ
Admin EPS_OfflineJobDeleteRQ EPS_OfflineJobDeleteRQ
other users’ EPS_OfflineJobRetrieveRQ EPS_OfflineJobRetrieveRQ
none
jobs EPS_OfflineJobReadResultRQ EPS_OfflineJobReadResultRQ
owned jobs EPS_OfflineJobReadResultRQ EPS_OfflineJobReadResultRQ none
EPS_OfflineJobDeleteRQ EPS_OfflineJobDeleteRQ
SuperUser
other users’
EPS_OfflineJobReadResultRQ EPS_OfflineJobReadResultRQ none
jobs
EPS_OfflineJobDeleteRQ EPS_OfflineJobDeleteRQ
Sample XML Offline Job Search Messages
Sample xmls for supported offline search scenarios are offered below. Please always refer to the
Developer Resource Center for the most current schema information.
Note: The dedicated ClientContextCode assigned to the external system calling Sabre Profiles should
always be included in the service call in the < Sabre_OTA_OfflineJobCreateRQ element.
Sample:
<Sabre_OTA_OfflineJobCreateRQ Target="Production" ClientContextCode=“TMP” TimeStamp="2013-10-

23T09:14:02.089Z" Version="0.0" xsi:schemaLocation="http://www.sabre.com/eps/schemas
\schemas\Sabre_OTA_ProfileCreateRQ.xsd" xmlns="http://www.sabre.com/eps/schemas"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
OfflineJobCreateRQ
Used for creating a new job with specific search criteria. Currently there are 8 types of search criteria:
• Document – searches for profiles with expired Documents. Parameters: range of dates (StartDate and
EndDate) or just the EndDate (in which case the start date is today):

<Job ClientCode="TN" JobName="ALEXANDER#475" DomainID="A2FE">
<OfflineSearch>
<Profile>
<Document>
<ExpireDate StartDate="2020-08-02" EndDate="2021-08-02"/>
</Document>
</Profile>
</OfflineSearch>
</Job>
</Sabre_OTA_OfflineJobCreateRQ>
You can also specify the BlankCriteria within the Document criteria, which searches for profiles that don’t
have Expire Date specified.

<Job ClientCode="TN" JobName="ALEXANDER#475" DomainID="A2FE">
<OfflineSearch>
<Profile>
<Document>
<BlankCriteria CriteriaType="ExpireDate"/>
</Document>
</Profile>
</OfflineSearch>
</Job>
• CustLoyalty – searches for profiles matching the provided VendorCode and VendorTypeCode. Possible
values for VendorTypeCode are: (AL, HL and CR)

<Job ClientCode="TN" JobName="BOBBY!488" DomainID="A2FE">
<OfflineSearch>
<Profile>
<CustLoyalty>
<Vendor VendorTypeCode="AL" VendorCode="UA"/>
</CustLoyalty>
</Profile>
</OfflineSearch>
</Job>
• PrefCollections – searches for profiles that match provided PreferenceCategory and

PreferredVendorCode. Possible values for PreferenceCategory are: Airline, Hotel, VehicleRental, Rail,
GroundTransportation.
<Job ClientCode="TN" JobName="MITZI 874" DomainID="A2FE">
<OfflineSearch>
<Profile>
<PrefCollections>
<PreferredVendor PreferenceCategory="Airline" PreferredVendorCode="UA"/>
</PrefCollections>
</Profile>
</OfflineSearch>
</Job>
Note: You can also use the BlankCriteria within PrefCollection, which searches for profiles that are
missing the VendorCode in each section. There are two possible values for the type: VehicleRental and
PreferredVehicleRentalVendorCode

<Job ClientCode="TN" JobName="MITZI 874" DomainID="A2FE">
<OfflineSearch>
<Profile>
<PrefCollections>
<BlankCriteria CriteriaType="PreferredHotelVendorCode"/>
</PrefCollections>
</Profile>
</OfflineSearch>
</Job>
• Remark – searches for profiles hat contain the given text in the field @Text. You can use wildcards:

<Job ClientCode="TN" JobName="IAN$710" DomainID="A2FE">
<OfflineSearch>
<Profile>
<Remark>
<OtherPNRText Text="EMAIL_TEST@*"/>
</Remark>
</Profile>
</OfflineSearch>
</Job>
• EmployeeInfo – searches for profiles that contain the given value in the Value field for:
EmployeeCostCenter, BusinessUnit, ProjectID and Department. This is an example for
EmployeeCostCenter, other cases are analogous.

<Job ClientCode="TN" JobName="BEATRICE$376" DomainID="A2FE">
<OfflineSearch>
<Profile>
<EmployeeInfo>
<EmployeeCostCenter Value="1111"/>
</EmployeeInfo>
</Profile>
</OfflineSearch>
</Job>
• CustomDefinedData – searches for profiles matching the specified condition for both or any of the
attributes: (CustomFieldCode, Value)

<Job ClientCode="TN" JobName="FRANKIE#324" DomainID="A2FE">
<OfflineSearch>
<Profile>
<CustomDefinedData>
<ValuesSearch CustomFieldCode="OTH" Value="Value_1"/>
</CustomDefinedData>
</Profile>
</OfflineSearch>
</Job>
• PaymentCard – searches for attributes that have an expired date in payment card. Similarily as for
Documents, you can specify a range of dates (StartDate and EndDate) or just the EndDate (in which
case the start date is the current date).

<Job ClientCode="TN" JobName="TONY#415" DomainID="A2FE">
<OfflineSearch>
<Profile>
<PaymentCard>
</PaymentCard>
</Profile>
</OfflineSearch>
</Job>
• Discount – searches for profiles with expired Discounts. Similarily to Documents and PaymentForm
you can specify a range of dates or just the end date. Additionally you have to provide attributes for
VendorTypeCode and DiscountTypeCode, which are required parameters and that narrows the search
criteria.

<Job ClientCode="TN" JobName="LEE!110" DomainID="A2FE">
<OfflineSearch>
<Profile>
<Discount>
<ExpireDate StartDate="2020-08-03" EndDate="2020-09-02" VendorTypeCode="AL"
DiscountTypeCode="UNK"/>
</Discount>
</Profile>
</OfflineSearch>
</Job>
RESPONSE:
<Sabre_OTA_OfflineJobCreateRS ClientContextCode=“TMP” TimeStamp="2013-10-23T08:24:03.16Z"

Version="6.15" xmlns="http://www.sabre.com/eps/schemas">
<ResponseMessage>
<Success/>
</ResponseMessage>
<Job JobID="1078113" DomainID="A2FE" JobName="ALEXANDER#475" JobOwner="207175"
OwnerDomainID="AAS" JobStatus="NEW" ActionType="OfflineSearch"/>
</Sabre_OTA_OfflineJobCreateRS>
OfflineJobCancelRQ
Used for cancelling an offline job that has not yet been processed and is waiting in the queue (with a
status of NEW). Parameters: Job ID and Domain.
REQUEST:
<Sabre_OTA_OfflineJobCancelRQ Target="Production" ClientContextCode=“TMP” TimeStamp="2013-10-

<Job ClientCode="TN" JobID="1078131" DomainID="A2FE"/>
</Sabre_OTA_OfflineJobCancelRQ>
RESPONSE:
<Sabre_OTA_OfflineJobCancelRS ClientContextCode=“TMP” TimeStamp="2013-10-23T08:52:51.342Z"
<ResponseMessage>
<Success/>
</ResponseMessage>
</Sabre_OTA_OfflineJobCancelRS>
OfflineJobDeleteRQ
Used for deleting a job that has already been processed (with a status other than NEW). Parameters: Job
ID and Domain:
REQUEST:
<Sabre_OTA_OfflineJobDeleteRQ Target="Production" ClientContextCode=“TMP” TimeStamp="2013-10-

<Job ClientCode="TN" JobID="1078023" DomainID="A2FE"/>
</Sabre_OTA_OfflineJobDeleteRQ>
RESPONSE:
<Sabre_OTA_OfflineJobDeleteRS ClientContextCode=“TMP” TimeStamp="2013-10-23T07:16:17.809Z"

<ResponseMessage>
<Success/>
</ResponseMessage>
</Sabre_OTA_OfflineJobDeleteRS>
OfflineJobRetrieveRQ
Used for listing all the jobs in each domain along with their statuses:
REQUEST:
<Sabre_OTA_OfflineJobRetrieveRQ Target="Production" ClientContextCode=“TMP” TimeStamp="2013-10-

<Job ClientCode="TN" ActionType="OfflineSearch" DomainID="A2FE"/>
</Sabre_OTA_OfflineJobRetrieveRQ>
RESPONSE:
<Sabre_OTA_OfflineJobRetrieveRS ClientContextCode=“TMP” TimeStamp="2013-10-23T08:52:50.491Z"

<ResponseMessage>
<Success/>
</ResponseMessage>
<Jobs>
<Job JobID="1048617" DomainID="A2FE" JobName="EMMITT!420" JobOwner="207175"
OwnerDomainID="AAS" JobStatus="SUCCESS" ActionType="OfflineSearch" StartTime="2013-10-
17T09:36:11.59Z" ExpirationTime="2013-10-24T09:36:13.007Z"/>
<Job JobID="1048835" DomainID="A2FE" JobName="KELVIN$870" JobOwner="217430"
<Job JobID="1068805" DomainID="A2FE" JobName="SANTOS%457" JobOwner="207175"
<Job JobID="1049007" DomainID="A2FE" JobName="Job2_131017_173433 RunInTestMode(Rslt=Success,
ExecTime=1000, RsltErr=, Rspns=1)" JobOwner="217430" OwnerDomainID="A2FE" JobStatus="SUCCESS"
ActionType="OfflineSearch" StartTime="2013-10-17T15:36:01.152Z" ExpirationTime="2013-10-
24T15:36:03.141Z"/>
</Jobs>
</Sabre_OTA_OfflineJobRetrieveRS>
OfflineJobReadResultRQ
Used for displaying job results which contain the list of profile summaries for the profiles matching the
search criteria. Parameters: Job ID and Domain. The optional Page section can be specified, which
controls the number of profile items returned and also the page number. The example below specifies:
display 5 profiles on each page and show the page number 4. The default is display first page with 125
items on the page:
REQUEST:
<Sabre_OTA_OfflineJobReadResultRQ Target="Production" ClientContextCode=“TMP” TimeStamp="2013-10-

<Job ClientCode="TN" JobID="12345" DomainID="A2FE">
<Page Number="4" ReturnCount="5"/>
</Job>
</Sabre_OTA_OfflineJobReadResultRQ>
RESPONSE:
<Sabre_OTA_OfflineJobReadResultRS ClientContextCode=“TMP” TimeStamp="2013-10-23T09:10:14.985Z"

<ResponseMessage>
<Success/>
</ResponseMessage>
<JobResult NumReturned="5" HaveMore="Y" PageNumber="4" TotalCount="500" JobStatus="SUCCESS">
<OfflineSearchResults>
<ProfileList>
<Profile UniqueID="16" ProfileTypeCode="TVL" DomainID="A2FE" ProfileName="ProfName16"/>
</ProfileList>
</OfflineSearchResults>
</JobResult>
</Sabre_OTA_OfflineJobReadResultRS>
Email Notification for Job Completion
As described earlier, within the initial job create request, the user has the option to receive an email
notification once the offline search job has completed. If this option is utilized, the Sabre Profiles System
will send an email to the email address the user defined during the initial job create request advising that
the offline job has completed and if it was successful or if it failed. If the job failed, the user will be
provided an error code within the email notification at which time they can send a service call request to
read the job results to get more details on the error(s) causing the job failure.
Sample XML Email Notification

<Job ClientCode="TN" JobName="My Search Job" DomainID="A2FE">
<OfflineSearch>
<Profile>
<PaymentCard>
</PaymentCard>
</Profile>
</OfflineSearch>
<Notification EmailAddress="joe.agent@agency.com" />
</Job>
Sample Emails
Successful Offline Search Job Completion

From: sabreprofiles@sabre.com [mailto:sabreprofiles@sabre.com]
Sent: Friday, November 08, 2013 4:58 PM
To: Agent, Joe
Subject: The Sabre Profiles offline job has completed
**** Please do not reply as this is a system generated email notification ****
The Sabre Profiles Search Job ID # 1203753 named My Search Job was successfully completed. This Job ID
will be available for review until 2013-11-15 15:58:05.254 GMT.
Failed Offline Search Job Completion

From: sabreprofiles@sabre.com [mailto:sabreprofiles@sabre.com]
Sent: Friday, November 08, 2013 4:58 PM
To: Agent, Joe
Subject: The Sabre Profiles offline job has completed
**** Please do not reply as this is a system generated email notification ****
The Sabre Profiles Search Job ID # 1203755 named My Search Job failed due to error code 500. Please
refer to the Job Details Response for cause of failure.
Error Messaging
Please refer to the Sabre Dev Studio for a current list of error codes and descriptions related to Offline
Job Searches.
Delete/Restore Service 9
Deleting and Restoring Profiles
The Delete functionality allows a user to delete a specified Profile, that will be permanently removed
from the Sabre Profiles database by the Sabre host Purge Service after the predetermined time. The user
can specify only one profile in the ProfileDeleteRQ. The Purge Service looks for all the deleted Profiles
that have the same purge date as the current date. The Profiles which meet these conditions will be
permanently removed from the Sabre Profiles database at midnight U.S. Central Time.
Sample XML Profile Delete Request
A sample Delete request looks like this:
<Sabre_OTA_ProfileDeleteRQ Version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema"

\schemas\Sabre_OTA_ProfileDeleteRQ.xsd">
<Delete>
<Profile PurgeDays="5">
ClientCode="TN" ClientContextCode=“TMP”
DomainID="A5BE”
</TPA_Identity >
</Profile>
</Delete>
</Sabre_OTA_ProfileDeleteRQ>
The <Profile> sub-element holds the PurgeDays attribute, which is mandatory. The value of this attribute
is used by the Sabre Profiles Delete engine to calculate a future date. On the calculated future date, the
Purge Service will permanently remove this Profile from the Sabre Profiles database. Inside the <Profile>
is a TPA_Identity section. This section specifies a profile to be deleted.
There is no set limit for the number of days in advance for the PurgeDays attribute, so you can enter for
example PurgeDays=30 to indicate that you want the profile to be deleted 30 days from today’s date.
Note: Profiles are not automatically deleted from Sabre Profiles system regardless of their activity or
creation date. Therefore, the user must run the Sabre_OTA_ProfileDeleteRQ if any Profiles need to be
deleted.
ProfileDeleteRQ allows the user to delete a Profile without changing its status to “DL”. To support this
scenario the following attribute should be included to retain the active status:
Sabre_OTA_ProfileDeleteRQ/Delete/Profile/@StatusCode=”AC”. After such operation, the Profile will still
be purged from the database when the designated PurgeDay is reached, but until then, it will be available
for use in Sabre Profiles.
Profiles can also be deleted by specifying the Profile AuxiliaryID (3rd party system Profile ID),
<Sabre_OTA_ProfileDeleteRQ xsi:schemaLocation="http://www.sabre.com/eps/schemas
\schemas\Sabre_OTA_ProfileDeleteRQ.xsd" Version="1.0" xmlns="http://www.sabre.com/eps/schemas"
<Delete>
<Profile PurgeDays="0" StatusCode="DL">
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP" DomainID="A5BE" ProfileTypeCode="TVL"
UniqueID="*">
<AuxiliaryID IDTypeCode="AGTLOGIN" Identifier="8732879280ca3"/>
</TPA_Identity>
</Profile>
</Delete>
Sample XML Profile Delete Successful Response
A sample successful ProfileDeleteRS looks like this:
<Sabre_OTA_ProfileDeleteRS xmlns="http://www.sabre.com/eps/schemas"
TimeStamp="2013-10-04T12:38:53.008Z" Version="6.14">
<ResponseMessage>
<Success />
</ResponseMessage>
<Delete>
<Profile>
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP”
UniqueID="72995785973" ProfileTypeCode="TVL" DomainID="A5BE" />
</Profile>
</Delete>
</Sabre_OTA_ProfileDeleteRS>
In case of successful responses, the <ResponseMessage> holds the <Success/> sub-element.
Sample XML Profile Delete Error Response
If a profile cannot be marked for delete for some reason, an error message is returned. Each error
message contains an ErrorMessage section with an Error Code and a short description of the problem
which was encountered during the profile delete or restore process. A sample error message is shown
below:
For the Sabre Profiles Delete Service, each Error message is prefixed with “D::”. An example error
<Sabre_OTA_ProfileDeleteRS xmlns="http://www.sabre.com/eps/schemas"
<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode="298">
D::NCERT502-1T20131004123341SD::No profile is found which match your selection criteria (UniqueID
= 3144924754, ClientCode = TN, ClientContextCode = ABC, DomainID = A5BE, ProfileTypeCode =
TVL)</ErrorMessage>
</Errors>
</ResponseMessage>
<Delete>
<Profile>
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP”
UniqueID="3144924754" ProfileTypeCode="TVL" DomainID="A5BE" />
</Profile>
</Delete>
</Sabre_OTA_ProfileDeleteRS>
In the example above, the profile could not have been deleted, because it was not found in the Sabre
Profiles database.
Restore Profile Service
Within the ProfileDeleteRQ Service there is also the option to Restore a Profile. This action changes the
ProfileStatus from “DL” to “AC” and removes ProfilePurgeNoDays attribute if is defined for a Profile that
has not yet purged.
If the ProfileStatus is set to “DL” with a ProfilePurgeNoDays indicator set to 0, it is considered an

immediate purge. This type of profile can be retrieved only in a SearchRQ and can be restored using the
restore service before midnight U.S. Central Time.
If the ProfileStatus is set to “DL” with the ProfilePurgeNoDays is > 1 day, it is considered a future purge.
This type of profile can be retrieved only in a SearchRQ and can be restored using the restore service
before midnight U.S. Central Time of the purge date.
If the ProfileStatus is set to “AC” with the ProfilePurgeNoDays is > 1 day, it is also considered a future
purge, but this type of profile can be accessed by any Profile service (Read, Update, etc.). It can be
restored using the restore service before midnight U.S. Central Time of the purge date, otherwise it will
be purged.
Profiles can also be restores by specifying the Profile AuxiliaryID (3rd party system Profile ID),
Profile History Service 10
Overview
Profile History service allows a customer to retrieve a history of the actions which were performed on the
Profile since the Profile was created
ProfileHistory can retrieve up to 12 months of historical actions for a Profile.
NOTE: For current Profile History supported elements, attributes, and number of instances allowed of
these fields, please refer to the schema xml files located on Sabre Dev Studio.
Sample XML Profile History Request
To retrieve the history of the Profile, the user must issue Sabre_OTA_ProfileHistoryRQ against the Sabre
Profiles EPS_EXT_ProfileHistoryRQ. Appropriate values of Unique ID, ClientCode, ClientContextCode,
DomainID and ProfileTypeCode attributes must be provided in the <TPA_Identity> section in the request,
and other attributes are optional. Apart from the required TPA_Identity section, optional History Criteria
can be specified in the request to retrieve only specific historical information.
The sample ProfileHistory request for a Traveler profile is shown below:
<Sabre_OTA_ProfileHistoryRQ
Target="Production" TimeStamp="2001-12-17T09:30:47.0Z" Version="0.0"
\schemas\Sabre_OTA_ProfileHistoryRQ.xsd">
<Profile>
<TPA_Identity
ProfileTypeCode="TVL" ProfileStatusCode="AC" ClientContextCode=“TMP" ClientCode="TN"
DomainID="A2FE" ProfileDescription="DESC1" ProfilePurgeNoDays="7" ProfileName="Profile Test 1"
UniqueID="105558095" ProfileNameModifyIndicator="Y"/>
</Profile>
</Sabre_OTA_ProfileHistoryRQ>
Additional criteria which can be specified in the ProfileHistory request are: StartDateTime, EndDateTime,
MaxChangeCount and Action. All these criteria can be specified separately or in different combinations in
the Profile History request.
StartDateTime and EndDateTime attributes indicate the time frame of the actions performed on the
profile. For instance, if a user wants to retrieve history of the actions performed on the profile for the last
three weeks, then the appropriate values of the StartDateTime and EndDateTime attributes must be
provided in the ProfileHistory request.
MaxChangeCount attribute indicates the maximum number of actions which will be retrieved in the
ProfileHistory response. If only this attribute is specified in the <Criteria> section, then the number of last
actions performed on the Profile will be retrieved in the ProfileHistory response. If the MaxChangeCount
attribute is specified along with the Action attribute, then the number of last specific actions performed
on the profile will be returned in the ProfileHistory response.
The Action attribute, if specified in the Criteria section, indicates which action will be retrieved in the
ProfileHistory response. For instance, if the Action specified in the request is Update, only Update actions
performed on the profile will be returned in the ProfileHistory response. The Action attribute can contain
the following values: Create, Update, Delete and Restore.
The sample ProfileHistory request with the Action criteria specified for a Traveler profile is shown below:
<Sabre_OTA_ProfileHistoryRQ
\schemas\Sabre_OTA_ProfileHistoryRQ.xsd">
<Criteria Action="Update"/>
<Profile>
<TPA_Identity
ProfileTypeCode="TVL" ProfileStatusCode="AC" ClientContextCode=“TMP" ClientCode="TN"
DomainID="A2FE" ProfileDescription="DESC1" ProfilePurgeNoDays="7" ProfileName="Profile Test 1"
UniqueID="105558095" ProfileNameModifyIndicator="Y"/>
</Profile>
</Sabre_OTA_ProfileHistoryRQ>
Sample XML Profile History Successful Response
A ProfileHistory response contains the following information:
- User Id- who performed the action

- Action type- can be “Create”, “Add”, “Update”, “Delete”, “Restore”
- Subject Area- which area of the Profile was actioned
- TimeStamp- when an action was performed
The sample ProfileHistory response is shown below:
<Sabre_OTA_ProfileHistoryRS TimeStamp="2010-08-16T10:35:20.496Z" Version="4.3"

<ResponseMessage>
<Success/>
</ResponseMessage>
<Profile>
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP" UniqueID="105558095"
ProfileTypeCode="TVL" DomainID="A2FE"/>
<Traveler>
<TravelerChangeHistory OldTimeStamp="2010-08-16T10:30:12.292Z" NewTimeStamp="2010-08-
16T10:30:37.363Z" Action="Restore">
<HistoryAccessInfo EPRDomainID="Employees" UserID="999999" LDAPDomain="Sabre"
LNIATA="0"/>
</TravelerChangeHistory>
16T10:30:12.292Z" Action="Delete">
LNIATA="0"/>
16T10:21:42.87Z" Action="Update">
LNIATA="0"/>
<SubjectArea Action="Add">
ProfileTypeCode="TVL" ProfileNameModifyIndicator="Y" ProfileDescription="SC96118" DomainID="A2FE"
ProfileStatusCode="AC" ProfilePurgeNoDays="700"/>
</SubjectArea>
<SubjectArea Action="Delete">
ProfileTypeCode="TVL" ProfileNameModifyIndicator="Y" ProfileDescription="ProfDesc64645645" DomainID="A2FE"
ProfileStatusCode="AC" ProfilePurgeNoDays="700"/>
</SubjectArea>
<Email EmailAddress="a@maul.com"/>
</SubjectArea>
<TravelerChangeHistory NewTimeStamp="2010-08-16T10:15:38.882Z" Action="Create">
LNIATA="0"/>
</Traveler>
</Profile>
</Sabre_OTA_ProfileHistoryRS>
The above example of the ProfileHistory response indicates that the Traveler Profile has been updated
with the new email address “a@maul.com”, then the Profile was deleted, and the last action was to
Restore the Profile.
There is no distinction between the main Profile section, TPA_Extensions and PrefCollections in the
ProfileHistory. All the elements are displayed as Subject Areas in the ProfileHistory response.
If a profile contains the PaymentForm subject area, it can be shown in different ways in the ProfileHistory
response depending on the agent’s account (EPR) which was used to create the session (refer to the
section explaining the Read Service).
If the agent’s account (EPR) does not have the keyword CCVIEW or OSCCVIEW permission assigned, then
CardNumber, CardHolderFullName, and ExpireDate will not be shown and the value "NOACCESS" will be
returned.
A sample will look like this:

ServiceUsageTypeCode="AL" InformationText="PaymentForm" VIT_LineType="A"
VIT_SecondaryQualifier="F" VIT_OrderNmbr="1">
<PaymentCard CardTypeCode="CR" BankCardVendorCode="AX" CardNumber="NOACCESS"
MaskedCardNumber="1111" CCViewAccess="N" EffectiveDate="102012" ExpireDate="NOACCESS" FirstRemark="N"
<CardHolderName>
<CardHolderFullName>NOACCESS</CardHolderFullName>
<NameSuffix>II</NameSuffix>
</CardHolderName>
</PaymentCard>
</PaymentForm>
In the case when the agent’s account (EPR) has the CCVIEW keyword assigned or the OSCCVIEW
permission assigned, then the CardNumber, CardHolderFullName, and ExpireDate will be displayed and
match the stored profile values.
<PaymentForm DisplaySequenceNo="1" OrderSequenceNo="1" TripTypeCode="LS" ServiceUsageTypeCode="AL"

InformationText="PaymentForm" VIT_LineType="A" VIT_SecondaryQualifier="F" VIT_OrderNmbr="1">
<PaymentCard CardTypeCode="CR" BankCardVendorCode="AX" CardNumber="371111111111111"
MaskedCardNumber="1111" CCViewAccess="N" EffectiveDate="102012" ExpireDate="012014" FirstRemark="N"
<CardHolderName>
<CardHolderFullName>John Doe</CardHolderFullName>
<NameSuffix>II</NameSuffix>
</CardHolderName>
</PaymentCard>
</PaymentForm>
It is worth noticing how the Update operation is represented in the ProfileHistory response. For example,
if the value of the FullPhoneNumber element is changed during the Update, it will be displayed as Delete
Telephone Subject Area (with the old value of the FullPhoneNumber) and Add Telephone Subject Area
(with the new value of the FullPhoneNumber element). Delete Subject Area and Add Subject Area are
presented within the TravelerChangeHistory- Update action in the ProfileHistory response. The sample
ProfileHistory response below illustrates the FullPhoneNumber update operation:

<HistoryAccessInfo EPRDomainID="A2FE" DutyCd="000" UserID="9999999" LDAPDomain="AA"
LNIATA="123456" AgentSine="AA1" AgentGivenName="Travelocity" AgentMiddleName="Inc"
AgentSurName="Sabre"/>
<Telephone LocationTypeCode="HM2" DeviceTypeCode="MO" LanguageIDCode="CV"
ServiceProvider="Provider" DeviceVendor="Buzz Mobile" DeviceBrand="Brand" DeviceModel="Model"
OrderSequenceNo="1">
<FullPhoneNumber>1123255356126</FullPhoneNumber>
<Contact ContactFirstName="John" ContactLastName="Smith"
ContactRemark="ContactEmail" ContactEffectiveDate="2009-10-01" ContactDiscontinueDate="2007-10-01"
ContactEffectiveTime="16:00" ContactDiscontinueTime="10:00"/>
</Telephone>
</SubjectArea>
<SubjectArea Action="Delete">
<Telephone LocationTypeCode="HM2" DeviceTypeCode="MO" LanguageIDCode="CV"
ServiceProvider="Provider" DeviceVendor="Buzz Mobile" DeviceBrand="Brand" DeviceModel="Model"
<Contact ContactFirstName="John" ContactLastName="Smith"
ContactRemark="ContactEmail" ContactEffectiveDate="2009-10-01" ContactDiscontinueDate="2007-10-01"
ContactEffectiveTime="16:00" ContactDiscontinueTime="10:00"/>
</Telephone>
</SubjectArea>
For the AirlinePref, HotelPref, VehicleRentalPref, RailPref and GroundTransportationPref subject areas
there are two additional actions of ChildAdd and ChildDelete which can occur in the ProfileHistory
response. These two actions can be retrieved in the ProfileHistory response if one or more attributes of
the child elements of these subject areas were modified and all the attributes of the top-level elements
remained unchanged. A sample of a ProfileHistory response with the ChildAdd and ChildDelete actions
follows:

<HistoryAccessInfo EPRDomainID="A2FE" DutyCd="000" UserID="9999999" LDAPDomain="AA"
LNIATA="123456" AgentSine="AA1" AgentGivenName="Travelocity" AgentMiddleName="Inc"
AgentSurName="Sabre"/>
<SubjectArea Action="ChildAdd">
<AirlinePref TripTypeCode="AZ">
<AirlineSeatPref
InformationText="11NSSANSSW/NM-Robert M Smith">
<SeatInfo SeatPreferenceCode="SPCL"/>
</AirlineSeatPref>
<AirlineSeatPref
InformationText="232WNDWASLE/NM-Susan E Smith">
</AirlineSeatPref>
<AirlineMealPref
InformationText="11CHKN/NM-Robert M Smith">
<MealInfo MealTypeCode="SPML"/>
</AirlineMealPref>
</AirlinePref>
</SubjectArea>
<SubjectArea Action="ChildDelete">
<AirlinePref TripTypeCode="AZ">
<AirlineSeatPref
InformationText="NSSANSSW/NM-Robert M Smith">
</AirlineSeatPref>
<AirlineSeatPref
InformationText="WNDWASLE/NM-Susan E Smith">
</AirlineSeatPref>
<AirlineMealPref
InformationText="CHKN/NM-Robert M Smith">
<MealInfo MealTypeCode="SPML"/>
</AirlineMealPref>
</AirlinePref>
</SubjectArea>
The above example indicates that the InformationText attributes of the AirlineSeatPref child elements
were modified and the TripTypeCode attribute of the top AirlinePref element remained unchanged.
Sample XML Profile History Error Response
If for some reason a Profile cannot be found in the Sabre Profiles system or Profile History doesn’t exist,
an error message is returned. Each error message contains an <Errors> section with an Error Code and a
short description of the problem which was encountered during the request for the profile history.
For the Sabre Profiles History Service, each Error message is prefixed with “H::”. An example error

<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode=”123”>H::PRF::Profile may not exist, or Profile History/Audit Information may
not be found for Profile.UniqueID=105558094, ClientCode=TN, DomainID=A2FE, ClientContextCode=ABC,
ProfileTypeCode=TVL,</ErrorMessage>
</Errors>
</ResponseMessage>
<Profile>
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP" UniqueID="105558094" ProfileTypeCode="TVL"
DomainID="A2FE"/>
</Profile>
If the Profile has been created, but no other actions were performed on the Profile, the following warning
message is returned:

<ResponseMessage>
<Warnings>
<WarningMessage>PRF::Profile Change History Data not Found, Profile has not been updated since
creation.</WarningMessage>
</Warnings>
</ResponseMessage>
<Profile>
DomainID="A2FE"/>
<Traveler>
<TravelerChangeHistory NewTimeStamp="2010-08-16T10:57:40.135Z" Action="Create">
<HistoryAccessInfo EPRDomainID="Employees" UserID="999999" LDAPDomain="Sabre" LNIATA="0"/>
</Traveler>
</Profile>
Profile Data Management Service 11
Copying/Moving Profiles to a Branched Pseudo City Code
This service allows the user to Copy Validators, Metadata and Associations and Move Profiles, Validators,
and Metadata between two branch domains to which the user has access.
Filters, Formats, Metadata, Validators, and Associations are copied with the initial profile. Associated
profiles are not copied/moved, and the association is removed from the profile which was copied/moved
to the new domain (PCC).
NOTE: For current Profile Data Management Service supported elements, attributes, and number of
instances allowed of these fields, please refer to the schema xml files located on the Sabre Dev Studio.
Moving a Profile to a Branched PCC
The following is an example of moving a Profile:
<Profile>
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP” UniqueID="12345"
ProfileTypeCode="TVL" DomainID="A2FE"/>
<Traveler>
<Customer>
…
</Profile
To move a Profile from Domain A2FE to Domain A5CE with all its associations, use the following request:
<Sabre_OTA_ProfileDataMgmtRQ Version="1.0" xmlns="http://www.sabre.com/eps/schemas"

xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance">
<MoveDomainObject DestinationDomainID="A5CE">
<Profile ClientCode="TN" ClientContextCode=“TMP” DomainID="A2FE"
ProfileTypeCode="TVL" UniqueID="12345"/>
</MoveDomainObject>
</Sabre_OTA_ProfileDataMgmtRQ>
Notice, by default all associated Filters, Formats, and Associations of the Profile is copied to the
destination Domain; however, any associated Profiles directly linked to the Primary Profile are not copied.
The same logic applies to Association Objects. If a Profile has an Association (Template), it is copied to the
destination Domain along with its associated Filters, Formats, Validators and Metadata. However,
associated Profiles linked to the Association(Template) are not copied.
If the Profile and/or Association has the same associated Filters and/or Formats, these associations are
copied to the destination Domain only once. All associations in the destination Domain are the same as
they were in the origin Domain.
There are two rules that should always be followed:
• When a user moves a Profile, its UniqueID/AssociationID is saved in the new destination Domain
(PCC).
• When a user copies an Association (AssociationID), they are assigned new IDs in the destination
Domain (PCC).
If the user does not want any associations to be copied to the destination Domain, the following attribute
should be specified: IgnoreAssociations=”Y.”
For example:
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<MoveDomainObject DestinationDomainID="A5CE" IgnoreAssociations=”Y”>
<Profile ClientCode="TN" ClientContextCode=“TMP” DomainID="A2FE" ProfileTypeCode="TVL"
UniqueID="12345"/>
</MoveDomainObject>
Because of this request, none of the Profile associations are copied to the destination Domain. The Profile
loses all associated object data.
If a Login section is specified for a Profile that is going to be moved, then the destination Domain must
not contain another Profile with the same LoginID as the moving Profile.
Remember: To move a Profile, the user must have branch access to all Domains/PCCs included in the
request.
Copying an Association to a Branched PCC
To copy an Association (Template) from Domain A2FE to Domain A5CE use the following request:

<CopyDomainObject DestinationDomainID="A5CE">
<Association ClientCode="TN" ClientContextCode=“TMP” DomainID="A2FE" AssociationID="12345"/>
</CopyDomainObject>
• Association can be copied from one PCC to another PCC with all associated objects. Both the newly
created Association and all its associated objects are assigned new UniqueIds.
• Association name uniqueness is enforced in the target domain.
• Association copy is only allowed for users who have the required Admin permissions
• Association copy is only allowed if user has access to both source and target PCC.
• When an AssociationID is copied to the new domain, it does not include any associated profiles. It
only includes associated filters, formats, validators, and metadata that existed in the initial
AssociationID that was copied.
If the user does not want any associations to be copied to the destination Domain, specify the following
attribute: IgnoreAssociations=”Y.” As all associated objects are the needed content of the Association ID,
this type of Copy will only generate an Association object shell with a UniqueID- no data content. For
example:

<CopyDomainObject DestinationDomainID="A5CE" IgnoreAssociations=”Y”>
<Association ClientCode="TN" ClientContextCode=“TMP” DomainID="A2FE" AssociaitonID="12345"/>
</CopyDomainObject>
Shared Association objects
This special case occurs when shared Association objects are requested to be copied.
It is not allowed to copy Association objects from one domain to another. Below are 3 cases involving
shared Association objects:
• Attempting to copy a shared (also known as Parent) Association object to a branched domain
Assuming that the Association object requested to be copied is shared (see RQ example from Copying
an Association ID… , AssociationID="12345"). This is the response that the application is going to
return:
<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode="1183">MC::NPPPTN-DEV1T20150311141653SMC::Shared Association
object cannot be copied to another domain.</ErrorMessage>
</Errors>
</ResponseMessage>
AssociationID=”12345” is going to remain in domain “A2FE” – a copy will NOT be created in “A5CE”.
• Moving a profile that is using shared Association object to a branched domain.
In this case, the Profile is being moved to a branched domain, but the shared Association object is not
copied. The “relation” (association) to the object remains in the profile when the IgnoreAssociations
flag is not included in the request or is set to “N”.
If the IgnoreAssociations = “Y”, the “relation” Association object does not remain within profile in the
destination domain.
Below are the examples of this behavior:
❖ Moving a profile using shared Association object with IgnoreAssociations = “N”
Profile ID: 10344778 is using shared Association object 691073:
<Profile …">
<TPA_Identity ClientCode="TN" ClientContextCode="ABC" UniqueID="10344778" ProfileTypeCode="TVL"
DomainID="A5CE" …/>
<Traveler>
<Customer>
<PersonName>
<GivenName>VERN</GivenName>
<SurName>BURNS</SurName>
</PersonName>
</Customer>
</Traveler>
<Association DomainID="A2FE" ClientCode="TN" ClientContextCode="ABC" AssociationID="691073"
ProfileTypeCode="TVL"/>
</Profile>
Profile ID: 10344778 is requested to be moved from A5CE to A8VE branched domain:
<Sabre_OTA_ProfileDataMgmtRQ …>
<MoveDomainObject DestinationDomainID="A8VE" IgnoreAssociations=”N”>
<Profile UniqueID="10344778" ProfileTypeCode="TVL" DomainID="A5CE" …/>
</MoveDomainObject>
Profile ID: 10344778 is removed from source domain A5CE and moved to destination domain A8VE.
Relation to Association ID 691073 remains.
Association ID 691073 remains in A2FE domain (is not copied to A8VE)
Profile after the move is completed:
<Profile …">
<TPA_Identity ClientCode="TN" ClientContextCode="ABC" UniqueID="10344779" ProfileTypeCode="TVL"
DomainID="A8VE" …/>
<Traveler>
<Customer>
<PersonName>
</PersonName>
</Customer>
</Traveler>
<Association DomainID="A2FE" ClientCode="TN" ClientContextCode="ABC" AssociationID="691073"
</Profile>
Since the Association object is shared and is available in branched domains, there is no need to
create a copy of that Association object. It can still be associated to profile if the profile exists in a
branched domain.
❖ Moving a profile using shared Association object with IgnoreAssociations =”Y”
Profile ID: 10344778 is using shared Association object 691073 (see example above)
Profile ID: 10344778 is requested to be moved to A8VE branched domain:
<Sabre_OTA_ProfileDataMgmtRQ …>
<MoveDomainObject DestinationDomainID="A8VE" IgnoreAssociations=”Y”>
<Profile UniqueID="10344778" ProfileTypeCode="TVL" DomainID="A5CE" …/>
</MoveDomainObject>
Profile ID: 10344778 is removed from the source domain A5CE and moved to destination domain
A8VE. The relation to Association ID 691073 is not present in that profile.
Association ID 691073 remains in the domain A2FE(it is not copied to A8VE)
Profile after the move is completed:
<Profile …">
ProfileTypeCode="TVL" DomainID="A8VE" …/>
<Traveler>
<Customer>
<PersonName>
</PersonName>
</Customer>
</Traveler>
</Profile>
• Copying a Child Association object (Template) that is using shared Association object (Parent) to a
branched domain.
In this case, a Child Association is being copied to a branched domain, but the shared Parent Association
object is not copied. The “relation” (association) to the object remains in the child Association in case the
IgnoreAssociations flag is not included in the request or is set to “N”. In the case that the
IgnoreAssociations = “Y”, the “relation” of the Association object does not remain in the Association
object (it is not considered a Child Association/Template anymore) in the destination domain. Below are
the examples of this behavior:
❖ Copying a Child Association object that is using a shared Association object (Parent) with
IgnoreAssociations = “N”
Child Association ID: 1234567 is using shared Association object (parent) 1558953:
<Association DomainID="A5CE" AssociationID="1234567"…>

<ParentAssociation AssociationID="1558953" DomainID="A2FE" ClientCode="TN"/>
</Association>
Child Association ID: 1234567 is requested to be copied to B0DE branched domain:
<Sabre_OTA_ProfileDataMgmtRQ ...>
<CopyDomainObject DestinationDomainID="B0DE" IgnoreAssociations=”N”>
<Association AssociationID="1234567" DomainID="A5CE" ClientCode="TN"/>
</CopyDomainObject>
Child Association ID: 1234567 remains in domain A5CE and a new “copy” of the Child Association is
created in B0DE domain. Relation to the parent Association ID 1558953 remains.
Association object after the move is complete:
<Association DomainID=" B0DE " AssociationID="1234568"…>

</Association>
❖ Copying a Child Association object that is using a shared Association object (Parent) with
IgnoreAssociations = Y”
Child Association ID: 1234567 is using a shared Association object (Parent) 1558953:
<Association DomainID="A5CE" AssociationID="1234567"…>

</Association>
Child Association ID: 1234567 is requested to be copied to B0DE branched domain:
<Sabre_OTA_ProfileDataMgmtRQ ...>
<CopyDomainObject DestinationDomainID="B0DE" IgnoreAssociations=”Y”>
<Association AssociationID="1234567" DomainID="A5CE" ClientCode="TN"/>
</CopyDomainObject>
Child Association ID: 1234567 remains in domain A5CE and the copy of the Association Child object is
created in B0DE domain. The new Association object is not considered a child as it is loses the
Association to the Parent.
Association object after the move is complete:
<Association DomainID=" B0DE " AssociationID="1234568"…>

…
</Association>
❖ Moving a Profile that is using a Child Association object connected to a Parent with
IgnoreAssociations = “N”
If the profile that is using the Child Association object is copied, the following logic applies:
- Profile is moved as per regular process

- Child Association object is copied according to rules described above.
❖ Moving a Profile that is using a Child Association object connected to a Parent with
IgnoreAssociations = “Y”
In case the profile that is using child Association object is copied following logic applies:
- Profile is moved as per regular process

- Child Association object is copied according to rules described above.
Profile Merge Service 12
Merging Profiles
Sabre Profile Web Services consumers can Merge duplicate profiles using the service
Sabre_OTA_ProfileMergeRQ . Profile Merge is an orchestrated web service that handles the merging of
duplicate profiles and offers an optional Sabre Profiles configuration which updates the Profile Index
information in the corresponding active Sabre PNRs of the duplicate profile. The action code that should
be used by Sabre Profile Web Service customers when calling this service is: EPS_EXT_ProfileMergeRQ
This service does not identify duplicate profiles, but rather allows customers to merge any duplicate
profiles. After a customer has identified the existence of one or more duplicated profiles for the same
individual, they have the option to merge those profiles. The Merge operation consists of adding a
reference (link) to the identified duplicate Profile. No other data is added, modified or combined in the
profiles during the Merge process. This service will not combine data or overwrite data from the
“duplicate” profile within the “Master” profile, but it will link the “duplicate” profiles and show them as
Associated Profiles within the “Master” profile for reference.
If Sabre Profiles are merged, the Profile Index within any active PNRs for the identified “duplicate” profile
can be updated through configuration to reference the new “Master” profile index. The PCC in which
Profiles are merged must interface with Sabre PNRs. The Profile Index changes in the active PNRs,
because of a Profile Merge, are not reversible.
How to Merge a Profile
The ProfileMergeRQ call supports the merge of one profile identified as “Master” and one profile
identified as “duplicate”. However, the service can be called as many times as needed if additional
duplicate profiles need to be merged into the identified “Master” profile. This merge operation is only
applicable to Profiles that are stored in the same PCC and are in an active status
(ProfileStatusCode=”AC”). The Profiles merged should be identified by their Sabre Profiles UniqueID
(Login and AuxiliaryID are not supported for this operation).
Merging Profiles results in the following changes:
• The “duplicate” profile is disabled for access (Read/Search/Update) by assigning a “Merged”

status to the duplicate Profile (ProfileStatusCode=”MG”). However, the profile is retained in the system
for further reference and can be read by the consuming application if the additional attribute
@IgnoreStatusCheck, which is available within the ProfileReadRQ, is set to “Y”. The merged Profile can
also be restored to active status by applying a ProfileDeleteRQ/Restore API call.
• The “Master” profile is updated with a reference/link to the “duplicate” profile which is defined
as an AssociatedProfile:
<TPA_Extensions>
<AssociatedProfiles AssocUniqueID="121" AssocProfileTypeCode="TVL" DomainID="A2FE"

ClientCode="TN" ClientContextCode=“TMP" ProfileRelationTypeCode="MG"
ProfileRelationStatusCode="AC" CreditBankIndicator="N" AssocFiltersInd="N"/>
<NumberOfAssocProfiles Traveler="1"/>
</TPA_Extensions>
No other data is added, modified or combined in the profiles during the Merge process.
The Profile Merge service can update, in real-time, active PNRs for the designated duplicate profile. This
additional action can be applied if the PCC is configured to interface with Sabre PNR. Customers should
contact their Account Director if interested in this added feature. Sabre Profiles support can then add the
necessary configuration to enable the ability to auto-update the active PNRs for the duplicate profiles.
Archived PNRs are not updated. If for any reason the Profile Index update attempt within the PNR fails,
the Profile merge will be stopped, and no changes will be made to the profiles, therefore allowing the
user to re-try the Profile Merge later.
The customer may request the list of active PNRs that were updated because of Profile merge by setting
the ActivePNRListIndicator=”Y” in the ProfileMergeRQ call, (this attribute is set to “N” by default).
The diagram below provides a graphical illustration of the schema for Sabre_OTA_ProfileMergeRQ.
Merge process flow
The diagram below illustrates the merge process where the web service is invoked by the consuming
application after identifying the duplicate profile to be merged. The web service request is processed via
Sabre USG (Universal Service Gateway) to the Sabre Profiles system. Sabre Profiles connects with Sabre
TDS (Trip Data Services) to apply the Profile Index changes mentioned previously in the corresponding
active PNRs. This allows cross referencing of the trip transactions to the proper profile.
Sample XML Profile Merge Request
Example 1: ActivePNRListIndicator=”N” (If this attribute is not set it means by default “N”)
<Sabre_OTA_ProfileMergeRQ Target="Production" TimeStamp="2010-09-30T13:10:41.531Z"

Version=“6.32” xmlns="http://www.sabre.com/eps/schemas" ActivePNRListIndicator="N">
<MasterProfile>
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP" DomainID="A2FE"
</MasterProfile>
<DuplicateProfile>
</DuplicateProfile>
</Sabre_OTA_ProfileMergeRQ>
<Sabre_OTA_ProfileMergeRS TimeStamp="2011-04-05T22:19:11.02Z" Version=“6.32”

<ResponseMessage>
<Success/>
</ResponseMessage>
<ResponseData>
<MasterProfile>
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP"
UniqueID="1000000303" ProfileTypeCode="TVL" DomainID="A2FE"/>
</MasterProfile>
<MergedProfile>
</MergedProfile>
</ResponseData>
</Sabre_OTA_ProfileMergeRS>
Example 2: ActivePNRListIndicator=”Y” – means – return list of updated active PNRs
<Sabre_OTA_ProfileMergeRQ Target="Production" TimeStamp="2010-09-30T13:10:41.531Z"

Version=“6.32” xmlns="http://www.sabre.com/eps/schemas" ActivePNRListIndicator="Y">
<MasterProfile>
<!—This section identifies the Profile that will be retained as Master and to
which an association will be added to reference merged Duplicate Profile -->
</MasterProfile>
<DuplicateProfile>

</DuplicateProfile>
</Sabre_OTA_ProfileMergeRQ>
<Sabre_OTA_ProfileMergeRS TimeStamp="2011-04-05T22:19:11.02Z" Version=“6.32”

<ResponseMessage>
<Success/>
</ResponseMessage>
<ResponseData>
<MasterProfile>
</MasterProfile>
<MergedProfile>
<ActivePNR>
<PNR RecordLocator="RMT33W "/>
<PNR RecordLocator="KZVGX5"/>
</ActivePNR>
</MergedProfile>
</ResponseData>
Example 3: Successful Profile merge response, when no Active PNRs were found that had been
Indexed (PI) with the ID of the “Duplicate Profile”
<Sabre_OTA_ProfileMergeRS TimeStamp="2011-08-25T18:53:10.397Z" Version="6.32"

<ResponseMessage>
<Warnings>
<WarningMessage WarningCode="500524">No PNRs for given
profile</WarningMessage>
</Warnings>
</ResponseMessage>
<ResponseData>
<MasterProfile>
</MasterProfile>
<MergedProfile>
</MergedProfile>
</ResponseData>
System Access Permissions
The Profile Merge service shares the same web service permission attributes used by other Sabre Profiles
Web Services.
To execute a Profile Merge, the user must have the session set up with the PCC where the PNRs exist or
with the PCC that is branched to the PCC where the PNRs exist.
For example, to update Agency A2FE PNRs the session must use the security token from the “A2FE”
partition/domain.
ProfileToPNR Service 13
ProfileToPNR Service Overview
The Profile To PNR service can be used to specify which profile data should be moved in to a PNR,
therefore resulting in the population of the AAA work area with the corresponding PNR related data
obtained from the profile (or profiles) involved in the transaction. This service abstracts the complexity of
the connectivity and greatly simplifies the operation of formatting and moving profile data to create a
PNR (Passenger Name Record) in the Sabre GDS.
There are two ways of providing this information:

• Filter Path
• Temporary Filter Path
Note: Like moving STAR data into the PNR, the move of any profile or combination of profiles into the
PNR is considered as a single Scan. This method presents obvious advantages in terms of savings to the
number of “scans” (transactions against the Sabre GDS) vs. using separate services to create and pass
separate strings for each host entry to populate the PNR.
Both methods are described and explained in detail in the subsequent paragraphs. Once all the necessary
data is Read from the Sabre Profiles database, the Profile To PNR service forwards it to the PNR system
and returns either a successful or error response. Another important advantage of this service, is that
when an invalid piece of data is sent (rejected by the GDS PNR existing format rules), the service
continues moving the remaining Profile data which complies with the host PNR rules. The corresponding
error messages returned by the host GDS are passed in the service response so that the client can
determine how to proceed to address any incorrect data/formats.
The user can define specific profile elements to move into the PNR. There is one exception: if a Profile
contains the element TravelPolicy and the sub-element SabreCorporateTravelPolicy, this element will
always move to the Sabre PNR. Once it’s moved to the PNR, the PNR rules of the Sabre Corporate Travel
Policy/Flex Edits will apply and the user with the appropriate rights can enable/disable from the Sabre
host/TPF functionality.
The graphics below illustrates the two paths mentioned above for this service.
NOTE: For current Filter Path or Temporary Filter Path supported elements, attributes, and number of
instances allowed for these fields, please refer to the schema xml files located on Sabre Dev Studio.
FilterPath
TemporaryFilterPath
Moving Remarks to PNR Using a Filter
There is a subject area within each Profile Type that has special circumstances for moving data to PNR
when including in any of the paths in ProfileToPNRRQ. The Remark subject area allows a user to store
general information text which can be designated in both paths to move to PNR “AS STORED”.(In the
Sabre Profiles GUI, this area is called ‘Other PNR Move Data’.)
An example use case for this would be if a user wanted to add a general comment in their PNR of
“5¥PASSENGER PREFERS HOTEL ROOM ON FLR WITH ICE MACHINE” using Remark>Text and including the
values in any of the filter paths, it will move to PNR as entered in that value field. Format Validation by
the host will still apply to these commands, so if it’s not a valid format for the Sabre GDS, the user will
receive the normal host error response noting the invalid command. If you stored the Text as
“PASSENGER PREFERS HOTEL ROOM ON FLR WITH ICE MACHINE” and did not include the PNR instruction
command of “5¥(¥)” as part of the Text, when this value is included in any of the filter paths, it will
fail when moved to Sabre as the host would not know where to place this data in the PNR.
<Remark Text="5¥PASSENGER PREFERS HOTEL ROOM ON FLR WITH ICE MACHINE"

CategoryCode="PNR" OrderSequenceNo="1" TypeCode="OT">
The Move Order logic applied to Remarks that are designated to move in a filter considers the defined
value in OrderSequenceNo (OSN). If no OrderSequenceNo exists, then Remarks will move in
unknown/undetermined order to PNR. If some Remark formats have OrderSequenceNo and some do not,
then those with OrderSequenceNo move 1st in a defined order, then those that do not have an OSN will
move following in no certain order. If for some reason more than 1 Remark exists with same
OrderSequenceNo, then order will be unknown/undetermined as to which will move 1st. Sabre Profiles
web services does not support an OrderSequenceNo value =”0”.
Move Order Logic for Profiles with Associated Formats and Profiles
Within ProfileToPNR there is logic applied as to what order objects move into the PNR. While the
OrderSequenceNo is the governing factor within each group of elements that move to the PNR, there is
additional logic to assist with ordering standard formats associated to the Profiles directly within the
Filter and those that are associated at the AssociationID/Template level which is inherited by the Profile
when created from an AssociationID/Template.
Also, when a Filter for a Profile contains other associated Profiles, that move order is defined based upon
the value order for Filter>MainProfileOrderSeqNo which is designated for the “Primary” or “Master”
profile in the Filter. If you want the Primary Profile that you are creating the Filter for to always move 1st,
then the value in the Filter would be MainProfileOrderSeqNo=”1”. The other profiles included in the Filter
as Associated Profiles would move in the order defined in the Filter for
AssociatedProfiles>OrderSequenceNo with each defined AssocUniqueID. These move to PNR as a whole
object, so all of Profile1 moves including its associated Formats, then Profile2 moves with its own filter
and any defined associated formats, and so on. They are a stacked move behind the scenes.
Within each Profile Filter move, the logic is to move Standard Formats first, then all Custom Formats from
the associated Template/AssociationID (if one exists) based upon OrderSequenceNumber , then Custom
Formats from the Profile based upon the defined OrderSequenceNumber.
Note: The Template custom formats may have the same Order Sequence Numbers as the Profile Custom
Formats, but default logic exists to move all the custom formats from the template first, then all the
formats from the profile move following.
If no OrderSequenceNo is defined, it will move in random order which can change with each move call.
If an OrderSequenceNo exists, but not applied to all custom formats in the filter, the standard Template
formats move first, then the Template custom formats which have a defined sequence, then the
remaining Template custom formats in a random order (without a defined OSN). Then the Profile
standard formats are moved, followed by the Profile custom formats with a defined OrderSequenceNo,
then the remaining profile custom formats without a defined sequence in random order.
The same logic applies to all associated profiles in the move call.
The Filter Path
The Filter path, refers to the mechanism of using a “Filter” which is an object in the Sabre Profiles system
that allows the user to define a subset of Profile data to be pre-selected in the Move to PNR function. The
user can assign a name, description, ID, etc. to one or more Filters and associate such Filter(s) to a
particular profile or an AssociationID/Template. Once a profile has been associated to a Filter, the Profile
To PNR service can use the “Filter path”, simply indicating which Filter should be used in the Profile to
PNR Move operation.
NOTE: For current Filter supported elements, attributes, and number of instances allowed in these fields,
please refer to the schema xml files located on Sabre Dev Studio.
When the Filter Path is used, the incoming XML message looks like this:
<Sabre_OTA_ProfileToPNRRQ xmlns="http://www.sabre.com/eps/schemas" TimeStamp="2008-06-

27T13:43:48.713Z" Target="Production" Version="1">
<FilterPath> <Profile ClientCode="TN" ClientContextCode=“TMP” DomainID="A5BE"
ProfileTypeCode="TVL" UniqueID="1004903">
<Filter ClientCode="TN" ClientContextCode=“TMP” DomainID="A5BE" FilterID="12993"

FilterName="Filter">
<AssociatedFormats ClientCode="TN" ClientContextCode=“TMP” DomainID="A5BE"

FormatID="12993" /> <FormatString>5C\u2628TOUR CONFIRMED</FormatString>
</Filter> </Profile>
</FilterPath>
</Sabre_OTA_ProfileToPNRRQ>
In this scenario the user must provide the Profile and the Filter sub-elements. The first line example
identifies a profile that is supposed to be moved to the PNR, whereas the second line identifies a filter
which is to be used during this transaction. The Filter contains information about which data in the
corresponding Profile will be moved to the PNR. If the provided filter does not contain any associated
profiles, other than the one specified in the <Profile> element, the Profile To PNR service moves data only
from the <Profile> based on the <Filter>.
Specifying the Profile
The Profile to be moved can be specified in three ways:
• By using a UniqueID and other attributes as shown in the following example:
<Profile ClientCode="TN" ClientContextCode=“TMP”

DomainID="A5BE" ProfileTypeCode="TVL" UniqueID="1004903">
The Profile is distinctly identified.
Note: There cannot be more than one Profile with the same UniqueID.
• If the UniqueID of the profile is unknown, it can be identified by using the ProfileName with the
flag BlindMoveByProfName=”Y”and other attributes as shown in the following example:
<Profile ClientCode="TN" ClientContextCode=“TMP”

DomainID="A5BE" ProfileTypeCode="TVL" UniqueID="*" ProfileName="John Smith"
BlindMoveByProfName=”Y” >
In this example, the ProfileName (“John Smith“) is searched. If only one profile is found, it is
returned in the response. If more than one Profile is found with the same ProfileName, an error
message is returned indicating that no unique profile was found.
• By specifying the associated profile type only – using a generic placeholder in the Filter.<Profile
ClientCode="TN" ClientContextCode=“TMP” DomainID="A5BE" ProfileTypeCode="CRP">
In case the Filter selected for the PNR Move service contains a placeholder for a profile type
(meaning the AssociatedProfiles section of the Filter doesn’t have @AssocProfileID specified)
then the system is going to look for Profiles associated to a Profile (directly or through an
AssociationID) that is being moved and:
o In case there is a single profile of the given type found – that profile is moved to PNR with
the main profile
o In case there is more than one profile of the given type found – no associated profile is
moved to PNR based on that filter. The user is presented with a Warning message.
o In case there are no profiles of the given type found – no associated profile is moved to
PNR based on that filter
Specifying the Filter
The Filter can be specified in two ways in the ProfileToPNR API:
• By using a FilterID, FilterName, and other attributes as shown in the following example:
<Filter ClientCode="TN" ClientContextCode=“TMP”

DomainID="A5BE" FilterID="12993" FilterName="Filter">
The Filter is uniquely identified.
Note: There cannot be more than one Filter with the same FilterID. This method should be used
whenever possible if the FilterID is known. Otherwise, an error message is returned.
• By using a FilterName and including the flag BlindMoveByProfName="Y" as well as other
attributes as shown in the following example:

DomainID="A5BE" FilterID="*" FilterName="Filter1">
The flag indicator BlindMoveByProfName="Y keys an orchestrated call for multiple searches to
obtain the IDs for the filter and profile. The system attempts to locate the filter using the
specified name and OrderSequenceNo=1 (Filter1). The system first searches Filters that are
directly associated to the Profile. It then searches Filters that are associated via an Association
Object/Template as a secondary query.
If a Filter with OrderSequenceNo=1 (used as a ‘default’ indicator) cannot be found, the system
attempts to locate the filter with the specified name by searching for filters associated to the
profile. It then searches Filters associated via an Association Object/Template.
Searching for a Filter
The following steps describe how to Search for a Filter:
1. Execute a Filter Search by using a specific name and OrderSequenceNo=1 among Filters
associated with a Profile.
• If exactly one Filter is found, it is used.
• If more than one Filter is found with the same FilterName, an error message is returned:
Multiple Default Filters with Same name (Filtername here) exist for this Profile (Profile
name here).
2. Execute a Filter Search by using a specific name and OrderSequenceNo=1 among Filters
associated via Association Object/Template.
• If multiple Profiles are found, an error message is returned:
Multiple Default Filters with Same name (Filtername here) exist for this Profile
(Profile/Template name here).
3. Execute a Filter Search by using a specific name associated to the Profile.
If exactly one Filter is found, it is used.

4. Execute a Filter Search by using a specific name associated to the Profile via Template.
• If a Filter is not found, an error message is returned.
• By not specifying a FilterName (using a wildcard “*”).

DomainID="A5BE" FilterID="*" FilterName="*">
In this example, the system attempts to locate the default Filter using OrderSequenceNo="1". The
system searches Filters that are directly associated to the Profile, then it searches Filters that are
directly associated via an Association ID/Template. If no default filter is found, the system
attempts to locate any filter among the associated filters and then filters associated via an
Association ID/Template.
Searching for a Default Filter
The Default Filter is identified when assigned OrderSequenceNo=”1” in the association area of
the Profile or Template/AssociationID. The following steps describe how to Search for a Default
Filter:
1. Execute a Default Filter Search associated to a Profile.
• If one Default Filter (with @OrderSequenceNo = "1") is found, it is used.
• If more than one Default Filter is found, an error message is returned:
Multiple Default Profile Filters exist for this Profile (Profile name here).
2. Execute a Default Filter Search associated to the Profile via association object (If child/parent
association object functionality is used – this is the child Association object step).
• If one Default Filter is found, it is used.
Multiple Default Template Filters exist for this Profile (Template name here).
3. Execute a Default Filter Search associated to the Profile via parent Association object (This
step is only executed when child/parent association object functionality is used).
• If one Default Filter is found, it is used.
Multiple Default Template Filters exist for this Profile (Template name here).
Notes:
• If there is exactly one Filter associated to the Profile, use this Filter.
• If there are no Filters associated to the Profile and there is exactly one Filter associated via an
Association ID/Template (child or parent), use this Filter.
• If none of these instances apply, the following error is returned:
No Default Filter exists for this Profile
Filter’s Associated Profiles
If the Filter does not have any associated Profiles other than the one specified in the <Profile> element,
the ProfileToPNR service does not take any further action. It moves data only from the <Profile> based
on the <Filter>.
However, when the Filter provided in the <Filter> sub-section includes one or more associated Profiles,
the situation becomes a bit more complicated.
Let’s assume the Fltr-1 holds associations to three Profiles (Prf-1, Prf-2, Prf-3) other than the one
provided in the <Profile> section. These profiles in turn are associated with the following filters: the Prf-2
and Prf-3 associate with the Fltr3, whereas the Prf-1 associates with the Fltr2. The Profile To PNR service
in this scenario will move the following data:
• The profile’s data (from the incoming XML request) is based on Filtr1
• The Prf-1’s data based on the Fltr2
• The Prf-2’s and the prf3’s data based on the Fltr3
If the Fltr2 and Fltr3 holds associations to other profiles, the same scenario will be applied to those
profiles. However, this would be the last iteration and the Profile To PNR service will not validate any
deeper in the filter for profile associations.
If there are Profiles associated with Fltr4 and Fltr5, they are disregarded. This prevents the ProfileToPNR
service from entering an endless loop.
Filters can have associated Formats. (Please refer to the “Format” section later in this document for
details on Formats) If in the incoming XML request there is <AssociatedFormat> sub-element specified
in the <Filter> section, only that format will be considered. Otherwise, all associated formats to the filter
provided in the <Filter> section will be applied to the profile’s data.
Note: To pass Formats in to the ProfileToPNRRQ using the “Filter path”, it is necessary that the Formats
are included either in the Filter (AssociatedFormats section) or directly into the request in
ProfileToPNRRQ (again under AssociatedFormats section). Having the Format associated only to the
Profile is not indicative that they should be moved to the PNR.
At the lower levels of the Filters to Profile associations, all the corresponding Formats will be applied to
profiles.
Each Associated Format can hold an optional Format Data element. This element consists of XPath
expressions and format’s parameter values. A user can pass values to these parameters in the Profile To
PNR XML request via the <UserInputData> sub-elements of the <AssociatedFormat>. There can be up to
100 such elements. Each <UserInputData> has two attributes as shown below:
<AssociatedFormats ClientCode="TN" ClientContextCode=“TMP” DomainID="A5BE" FormatID="12993">

<UserInputData FieldName="F1" FieldValue="Val1"/>
<UserInputData FieldName="F2" FieldValue="Val2"/>
</AssociatedFormats>
In ProfileToPNR Filter Path, if a filter contains associated formats with <UserInputData>, and at least one
of the formats that contains <UserInputData> is not included in the ProfileToPNR request, an error
response is returned which indicates the need for user input data. This alerts the external system that
there is data needed which should be prompted to the end user for input.
1. System sends a blind move RQ using FilterPath in ProfileToPNR service.

2. Sabre Profiles system checks if there are any formats with user input data, not
specified in the request.
3. The response contains the error message:
<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode=”123”> C:::FLT:: Filter contains
Format(s) with UserInputData: FormatID=(0)
FieldName=(1)</ErrorMessage>
</Errors>
</ResponseMessage>
<Filter FilterID="*" FilterName=”Name” DomainID="A5BE"
ClientCode=”TN” ClientContextCode=“TMP” >
</Profile>
4. System Reads the filter and its associated formats.
5. System asks the user for the input data.
6. System sends regular ProfileToPNR Filter path RQ, including the filter ID and user
input data for formats.
7. Sabre Profiles proceeds along the regular Filter path.
The Format must contain a minimum of one parameter with a value defined in the Profiles database for
Profiles to attempt to move that command into the Sabre host. If there are multiple parameters and no
values are present in the profile for that attribute, the command will not be created /moved into the
PNR.
Apart from the associated formats in the incoming XML request, a user can specify a
<FormatString> element, which holds a Sabre host/green screen command (or TPF command).
Temporary Filter Path
Temporary filter path is designed to work like the Filter path regarding validation of data. Using this path,
there is no need to create a filter in advance as a separate action, then associate the filter to a Profile and
define it in the ProfileToPNRRQ. Information contained in the filter body used is like a “mask” for
information from the profile. The user must include all the profile elements they want to Move in to the
PNR Move service (ProfileToPNRRQ) directly in the XML resulting in the creation of a Temporary filter ID
to populate a PNR in the Sabre host. This temporary ID then is called behind the scenes and then
validation takes place and logic follows the same path as if a Filter was created first then included in the
ProfileToPNRRQ.
All rules, which are applicable for the filter path, are valid here as well, such as OrderSequenceNo
validation and validation by special ‘Types’ like LocationTypeCode, TripTypeCode, etc. Sabre Profiles does
not support an OrderSequenceNo value=”0” in Formats.
NOTE: For current Filter supported elements, attributes, and number of instances allowed of these fields,
The XML request is shown below:
<Sabre_OTA_ProfileToPNRRQ xsi:schemaLocation="http://www.sabre.com/eps/schemas
\schemas\Sabre_OTA_ProfileToPNRRQ.xsd" Version="1.0" xmlns="http://www.sabre.com/eps/schemas"
<TemporaryFilterPath>
<Profile ClientCode="TN" ClientContextCode=“TMP” DomainID="A2FE" ProfileTypeCode="TVL"
UniqueID="101854748"/>
<Filter>
<Profile>
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP” DomainID="A2FE" ProfileTypeCode="TVL"
UniqueID="*"/>
<Traveler>
<Customer>
<PersonName OrderSequenceNo="1">
<NamePrefix>Mr</NamePrefix>
<GivenName>John</GivenName>
<MiddleName>K</MiddleName>
<SurName>Smith</SurName>
<NameSuffix>Sr</NameSuffix>
</PersonName>
<Telephone LanguageIDCode="PL" LocationTypeCode="AGY" OrderSequenceNo="1">
</Telephone>
<Email EmailAddress="TEST_WILD4515@GMAIL.COM" LanguageIDCode="EN-US"
EmailTypeCode="UNK" EmailUsageCode="BCC" OrderSequenceNo="1" PurposeCode="EMG"
DisplaySequenceNo="1" EmailRemark="remark"/>
<Address AddressUsageTypeCode="BIL" Attention="ATTN" LocationTypeCode="ADM"
<AddressLine>ADRESSLINE1</AddressLine>
<CityName>ODESSA</CityName>
<PostalCd>999</PostalCd>
<StateCode>21</StateCode>
<CountryCode>UA</CountryCode>
</Address>
<PaymentForm OrderSequenceNo="1" TripTypeCode="FM" ServiceUsageTypeCode="AL">
<PaymentCard BankCardVendorCode="VI" CardTypeCode="CR" CardNumber="9999999999991111"
ExpireDate="082014" FirstRemark="Y">
<CardHolderName>
<CardHolderFullName>Smith</CardHolderFullName>
</CardHolderName>
</PaymentCard>
</PaymentForm>
<Document DisplaySequenceNo="2" OrderSequenceNo="1" >
<DocHolder>
<MiddleName>K</MiddleName>
<NameSuffix>Sr</NameSuffix>
</DocHolder>
</Document>
<CustLoyalty MembershipID="00131265247" OrderSequenceNo="1" VendorCode="UA"
VendorTypeCode="AL">
<AssociatedVendors VendorTypeCode="AL" VendorCode="TK"/>
</CustLoyalty>
</Customer>
<TPA_Extensions>
<Remark Text="5HREMARKTEXT" TypeCode="AL" CategoryCode="ACC" OrderSequenceNo="1" />
<Discounts ID="CF045" OrderSequenceNo="1" VendorCode="CE" />
</TPA_Extensions>
</Traveler>
</Profile>
</Filter>
</TemporaryFilterPath>
</Sabre_OTA_ProfileToPNRRQ>
ProfileToPNR Service Response Message
Once all the necessary profile data is consolidated, the Profile To PNR service sends it to the PNR and
waits for the response in a synchronous manner. When the response is received, the service forms the
XML ProfileToPNR Response Message. If everything moved successfully, the response message looks like
this:
<Sabre_OTA_ProfileToPNRRS xmlns="http://www.sabre.com/eps/schemas">
<ResponseMessage>
<Success />
</ResponseMessage>
</Sabre_OTA_ProfileToPNRRS>
If any problems were encountered moving the data to the PNR, an error message is returned to the
ProfileToPNR service, which in turn will add that error message to the XML response.
Shared objects in P2PNR
Shared objects can be used when copying Profiles to a PNR. If the Profile is using a shared Association
object (Template), the system allows the user to copy the shared content to PNR in two ways – using a
shared Filter that is part of the shared Association object (Parent Template) and resides in a different
domain than the Profile, or using a local Filter:
- that is directly associated to the Profile, but is selecting objects from the Association object’s
Domain.
- that is associated to a Child Association object (Child Template) that the Profile is using, but is
selecting objects from the parent Association object’s domain.
Please see the use cases on how shared objects behave in P2PNR:
Use case 1: Using a Filter from a different domain with branch access opened
A Profile 10928218 in domain A5CE is using a shared Association object 104236 from domain A2FE. A
Filter 93356332 is associated to the shared Association object. The Filter is pointing to the
AssociatedProfile ID: 109282186 and AssociatedFormats ID: 90568720 (from domain A2FE). When the
Profile is copied to PNR using that Filter and branch access is opened between domain A2FE and A5CE, all
information from the Filter is being copied along with the Format and AssociatedProfile from the A2FE
domain. Example of message flow and setup:
Profile:
<Profile ..>
DomainID="A5CE"/>
<Traveler>
<Customer>
<NamePrefix>MRS</NamePrefix>
<GivenName>VERONICA</GivenName>
<SurName>BULLOCK</SurName>
</Customer>
</Traveler>
<Association DomainID="A2FE" ClientCode="TN" ClientContextCode=“TMP" AssociationID="104236"
</Profile>
Association:
<Association Shared="Y" DomainID="A2FE" ProfileTypeCode="TVL" AssociationID="104236" ClientCode="TN"
ClientContextCode=“TMP" …>
<AssociatedProfiles AssocUniqueID="109282186" AssocProfileTypeCode="CRP" DomainID="A2FE"
<PNRMoveInfo AssocProfileFilterID="93356330"/>
</AssociatedProfiles>
<AssociatedFilters FilterID="93356332" DomainID="A2FE" SequenceNo="1" DisplaySequenceNo="1"/>
<AssociatedFormats FormatID="90568720" DomainID="A2FE" SequenceNo="1"/>
</Association>
Filter:
<Filter UsedByShared="Y" FilterID="93356332" DomainID="A2FE" ClientCode="TN" ClientContextCode=“TMP" ...>
<Profile>
DomainID="A2FE"/>
<Traveler>
<Customer>
<PersonName>
<NamePrefix>*</NamePrefix>
<GivenName>*</GivenName>
<SurName>*</SurName>
</PersonName>
</Customer>
</Traveler>
</Profile>
<AssociatedProfiles AssocUniqueID="109282186" AssocProfileTypeCode="CRP" OrderSequenceNo="1"
DomainID="A2FE">
</Filter>
Data copied to PNR:

Main Profile UniqueID="10928218" from domain A5CE
Format UniqueID=”90568720” from domain A2FE
Associated Profile UniqueID="109282186" from domain A2FE
Use case 2: Using a Filter from a different domain that does not have branch access
If branch access is not open, it is not possible to use a Filter from another non-branched domain while
copying a Profile to PNR. The following error response message will be returned and no data is copied to
a PNR (setup is identical as in case above, but branch access does not exist):
<Sabre_OTA_ProfileToPNRRS TimeStamp="2015-03-13T10:13:29.921Z" Target="Production" Version="6.20"

<ResponseMessage>
<Errors>
<Error ErrorCode="1014" ErrorMessage="PRF2PNR::NPTNHLP607-
PROD1T20150313101329SPNR::Association DomainID attribute doesn't match DomainID
attribute in Profile"/>
</Errors>
</ResponseMessage>
Data copied to PNR: NONE
Use case 3: Using Filter from local domain (directly associated to Profile) selecting shared objects from
another domain with branch access
A Profile 109282352 in domain A5CE is using a shared Association object 104254 from domain A2FE. A
Filter 93356442 is associated directly to the Profile. A Format 90568797 is associated directly to the
Profile. The Filter is pointing to the AssociatedProfile ID 109282350 and AssociatedFormat ID 90568796
from domain A2FE (local Filter is inheriting information from a branched domain). Also, the Filter is
pointing to a local Format ID: 90568797 from A5CE domain (shared content is extended by some local,
domain specific information). When the Profile is copied to PNR using that Filter and branch access exists
between domain A2FE and A5CE, all information from the Filter is copied to the PNR along with Formats
and AssociatedProfiles from both A2FE and A5CE domains. Example of message flow and setup:-
Profile:
<Profile ...>
DomainID="A5CE"/>
<Traveler>
<Customer>
<PersonName>
<GivenName>STEVEN</GivenName>
<SurName>GERRARD</SurName>
</PersonName>
</Customer>
<TPA_Extensions>
<AssociatedFilters FilterID="93356442" DomainID="A5CE"/>
<AssociatedFormats FormatID="90568797" DomainID="A5CE"/>
</TPA_Extensions>
</Traveler>
<Association DomainID="A2FE" ClientCode="TN" ClientContextCode=“TMP" AssociationID="104254"
</Profile>
Association:
<AssociatedFilters FilterID="93356332" DomainID="A2FE"/>
<AssociatedFormats FormatID="90568796" DomainID="A2FE"/>
</Association>
Filter:
<Filter UsedByShared="Y" FilterID="93356442" DomainID="A5CE" ClientCode="TN" ClientContextCode=“TMP"
FilterTypeCode="TVL" ...>
<Profile>
DomainID="A5CE"/>
<Traveler>
<Customer>
<PersonName>
</PersonName>
</Customer>
</Traveler>
</Profile>
DomainID="A2FE">
</Filter>
Data copied to PNR:

Format 1 UniqueID=”90568796” from domain A2FE
Format 2 UniqueID=”90568797” from domain A5CE
Use case 4: Using a Filter from a local domain selecting shared objects from another domain with no
branch access
If branch access does not exist, but the local Filter is specified in the ProfileToPNRRQ – only the local
content is going to be copied (even though the Filter is pointing to content from another domain). In this
case, a warning message is returned for each object that was not copied (setup is identical as in case
above, branch access does not exist):
<Sabre_OTA_ProfileToPNRRS ...>
<ResponseMessage>
<Warnings>
<Warning WarningMessage="Format(s) were found in a domain that is not branched to
A5CE. Those Formats were not applied during the copy to PNR action."/>
<Warning WarningMessage="Profile(s) were found in a domain that is not branched to
A5CE. Those Formats were not applied during the copy to PNR action."/>
</Warnings>
...
</ResponseMessage>
Data copied to PNR:

Use case 5: Using Filter from a different domain associated to a parent Association object with branch
access
A Profile 10928218 in domain A5CE is using a child Association object 104236. The parent is Association
object 104237 from domain A2FE. A Filter 93356332 is associated to a shared Association object (parent).
Filter is pointing to the AssociatedProfile ID: 109282186 and AssociatedFormats ID: 90568720 from
domain A2FE. When the Profile is copied to PNR using that Filter and branch access exists between
domain A2FE and A5CE, all information from the Filter is copied to a PNR along with the Format and
AssociatedProfile from A2FE domain. Example of message flow and setup:
Profile:
<Profile ..>
DomainID="A5CE"/>
<Traveler>
<Customer>
<NamePrefix>MRS</NamePrefix>
<GivenName>VERONICA</GivenName>
<SurName>BULLOCK</SurName>
</Customer>
</Traveler>
<Association DomainID=" A5CE" ClientCode="TN" ClientContextCode=“TMP" AssociationID="104236"
</Profile>
Child Association:
<Association DomainID="A5CE" ProfileTypeCode="TVL" AssociationID="104236" ClientCode="TN"
</Association>
Parent Association:
<AssociatedFilters FilterID="93356332" DomainID="A2FE" SequenceNo="1" DisplaySequenceNo="1"/>
</Association>
Filter:
<Filter UsedByShared="Y" FilterID="93356332" DomainID="A2FE" ClientCode="TN" ClientContextCode=“TMP" ...>
<Profile>
DomainID="A2FE"/>
<Traveler>
<Customer>
<PersonName>
</PersonName>
</Customer>
</Traveler>
</Profile>
DomainID="A2FE">
</Filter>
Data copied to PNR:

Format UniqueID=”90568720” from domain A2FE
Use case 6: Using a Filter from a different domain associated to a parent Association object- branch
access does not exist.
If branch access is not open, it is not possible to use a Filter from another domain while copying a Profile
to PNR. The following error response message is returned and no data is copied to a PNR (setup is
identical as in use case 5, branch access does not exist):
<Sabre_OTA_ProfileToPNRRS TimeStamp="2015-03-13T10:13:29.921Z" Target="Production" Version="6.20"

<ResponseMessage>
<Errors>
<Error ErrorCode="1014" ErrorMessage="PRF2PNR::NPTNHLP607-
PROD1T20150313101329SPNR::Association DomainID attribute doesn't match DomainID
attribute in Profile"/>
</Errors>
</ResponseMessage>
Data copied to PNR: NONE
Use case 7: Using a Filter from a local domain (associated to a child Association object) selecting shared
objects from another domain – branch access exists
A Profile 109282352 in domain A5CE is using a child Association object 104254.A Parent Association
object ID 104255 is from domain A2FE. A Filter 93356442 is associated to the child Association object. A
Format 90568797 is associated directly to the Profile. The Filter is pointing to the AssociatedProfile ID
109282350 and AssociatedFormat ID 90568796 from domain A2FE (local Filter is inheriting information
from a branched domain). Also, the Filter is pointing to the local Format ID: 90568797 from A5CE domain
(shared content is extended by some local, domain specific information). When the Profile is copied to
PNR using that Filter and branch access exists between domain A2FE and A5CE, all information from the
Filter is copied to a PNR along with Formats and AssociatedProfiles from both A2FE and A5CE domains.
Example of message flow and setup:-
Profile:
<Profile ...>
DomainID="A5CE"/>
<Traveler>
<Customer>
<PersonName>
<GivenName>STEVEN</GivenName>
<SurName>GERRARD</SurName>
</PersonName>
</Customer>
<TPA_Extensions>
</TPA_Extensions>
</Traveler>
<Association DomainID="A5CE" ClientCode="TN" ClientContextCode=“TMP" AssociationID="104254"
</Profile>
Child Association:
<Association DomainID="A5CE" ProfileTypeCode="TVL" AssociationID="104254" ClientCode="TN"
<AssociatedFilters FilterID="93356442" DomainID="A5CE"/>
</Association>
Parent Association
</Association>
Filter:
<Filter UsedByShared="Y" FilterID="93356442" DomainID="A5CE" ClientCode="TN" ClientContextCode=“TMP"
FilterTypeCode="TVL" ...>
<Profile>
DomainID="A5CE"/>
<Traveler>
<Customer>
<PersonName>
</PersonName>
</Customer>
</Traveler>
</Profile>
DomainID="A2FE">
</Filter>
Data copied to PNR:

Format 1 UniqueID=”90568796” from domain A2FE
Profile Index
Although the Profile Index (PI) is not a specific Sabre Profiles system feature, it is a Sabre host/TPF PNR
function. Because of its relationship with the Profile functionality in Sabre Profiles, some basic
information for this PNR field is described below.
Profile Index is a field available within a Sabre PNR that provides details of all Profiles copied into the
PNR. A banner is visible within the PNR display as a reminder that Profile Index Data is present. The
banner also provides the Sabre command that is available to display the data.
PROFILE INDEX DATA EXISTS *PI TO DISPLAY ALL
Each profile type copied into the PNR is represented by a Profile tag. Profile tags are either name
associated or apply to all names in the PNR. A name associated tag applies to only one name in the PNR.
The profile tags currently available are:
Profile Tag Profile Type Name Associated?

TAGENCY AGENCY NO
TAGENT AGENT NO
CORPID CORPORATE NO
TRAVELER TRAVELER YES
TVLNN TRAVELER- NO NAME NO
OPERATIONAL OPERATIONAL NO
GROUP GROUP NO
The elements of the Profile Index include the Profile tag, the Profile ID number and a profile's owning
Agency PCC (DomainID). For a name-associated tag, the name, number, and traveler name are also
shown.
PNR Profile Index display
Below are examples of how the Profile Index, which contains the Profile UniqueID and the owning
Domain/PCC of the profile data, is displayed in the PNR. Display logic exists for this move process as
noted below.
*PI«
PROFILE INDEX DATA
1.TRAVELER 1.1 GOMEZ/JOSE ANTONIO MR I
TVL-00000103
OWNING AGENCY-B4T0
2.CORPID
CRP-123456789
OWNING AGENCY-B4T0
3.TAGENCY
AGY-234567890
OWNING AGENCY-B4T0
4.OPERATIONAL
OPX-111222334
OWNING AGENCY-B4T0
5.GROUP
GRP-756432131
OWNING AGENCY-B4T0
6.TVLNONAME
***TVLNN-756432132
OWNING AGENCY-B4T0
***TVLNN is a Traveler Profile Type with ProfileSubType=”NN” used if a TVL profile

does not have name information stored when moved into a PNR.
• Only one instance (the last instance if multiples of same type is moved) of Agency, Agent,
Operational, Group, and Corporate profile tags are allowed per PNR.
• If the user copies another profile of the same type into the PNR, the last Profile ID moved
populates the PI field.
• Any previous existing PI tags are copied into the Profile Index history in the PNR if the record
was ended after the transaction.
• If the same Profile is moved more than once into the same record, the selected profile data is
copied, but a Single Item field error is generated.
• Multiple instances of the Traveler Profile tag can exist, but only one is allowed per name in
the PNR.
• The user can return to the Traveler Profile to copy additional information into the PNR. The
selected Profile data is copied, but a Single Item field error displays to the user for the Profile
Index field.
Display Profile using the Profile Index value
Using the Sabre Red Workspace Classic View, the user can scroll up in the response and simply add/pre
append “*PI- “ and press “END” key (so the start of response should be in position 4) to move to end of
line and press ENTER to send the request. Sabre Red Workspace will intercept the command (not send to
host) and launch the Sabre Profiles GUI with the parameters to display the corresponding profile.
Note: This command is only available via Sabre Red Workspace and is not processed through the host. It
also can only be used for to display profiles that are stored in the same Domain/PCC that was established in
the Session or sent as an AAA command.
*PI«
PROFILE INDEX DATA
1.TRAVELER 1.1 GOMEZ/JOSE ANTONIO MR I
OWNING AGENCY-B4T0
*PI-TVL-00000103«
Filters 14
Filter Overview
Filters are used to store information about which Profile data elements, Associated Profiles and Formats
are copied into the Sabre GDS PNR. Users can pre-define Filters, and then determine which Filter is
considered the Default (identified with stored value OrderSequenceNo=”1”). Assigning a Default Filter is
particularly advantageous when multiple Filters are associated to a specific Profile, or for Profiles created
from a selected Template/AssociationID.
For Associated Profiles, a Filter can contain the Unique IDs of specific profiles to move, or it can contain a
generic placeholder for a ‘type’ of Associated Profile. When the placeholder is used, the Filter would look
through Profiles directly associated to the main Profile being moved to PNR and select one based on the
profile type specified by the filter. Example: A Traveler Profile has a Corporate Profile and Agency Profile
directly attached. The placeholder in the Filter will look for the Corporate Profile and Agency Profile and
copy those to the PNR without having to define the Profile Unique ID numbers for these respective
profiles. Users can add unique Filters to a Profile using ProfileCreate or ProfileUpdate services . Multiple
Filters can exist. Filters can be created, modified, or deleted.
A Filter can contain the following data:
• Many attributes, such as CreateDateTime, UpdateDateTime, FilterStatusCode,

FilterPurgeNoOfDays, and FilterTypeCode or FilterID, DomainID, ClientCode, ClientContextCode,
FilterName, and FilterDescription (optional).
• A Profile (one instance) that can identify any of the available profile types (TVL, CRP, AGY, AGT, or
OPX)
• Up to 500 Associated Profiles
• Up to 500 Associated Formats
• Up to 6 Placeholders for Associated Profiles, e.g. – AssociatedProfiles element without

AssocUniqueID specified. Only one placeholder per profile type is permitted.
Creating Filters
Sabre Profiles web clients create a Filter using the OTA_ProfileCreateRQ request. The following sections
describe the most typical aggregation of data currently in use.
How to Create a Filter
The Filter data sent from the web client is usually a small subset of all possible data. The first task is to
determine which XML layout represents the Filter data required by the web client.
The following section illustrates a typical filter.
Sample XML Create Filter Request
The Create Filter XML request begins with the following boilerplate:
<Sabre_OTA_ProfileCreateRQ TimeStamp="2001-12-17T09:30:47.0Z" Version="0.0" Target="Production"

..\schemasWSDL\Sabre_OTA_ProfileCreateRQ.xsd">
Immediately following this entry is the <Filter> base element. It holds the following attributes:
• FilterID
• DomainID
• ClientCode
• ClientContextCode
• FilterName
• FilterDescription
• CreateDateTime
• UpdateDateTime
• FilterStatusCode
• FilterPurgeNoOfDays
• FilterTypeCode
• UsedByShared
Except for FilterDescription, FilterStatusCode, and FilterPurgeNoOfDays, the UsedByShared all attributes
are required.
A sample fragment of the <Filter> section is shown below:
<Filter FilterID="*" DomainID=”A5BE” ClientCode=”TN” ClientContextCode=“TMP”

FilterName=”BusinessFilter” FilterDescription=”To Move business profile data to PNR”
CreateDateTime=”2001-12-17T09:30:47.0Z”
UpdateDateTime=”2001-12-17T09:30:47.0Z” FilterTypeCode=”ADM”
The <Filter> base element contains the following sub-elements:
• Profile (Required)
• Associations (Optional)
• AssociatedFormats (Optional)
Since the Profile section under Filter is used to indicate which elements are used for the ProfileToPNRRQ
service to move Profile data into the Sabre PNR, the data content of these elements is not relevant.
Elements under the <Profile> node in Filters must contain data as a placeholder to comply with the
schema validation.
For example, in most cases, the user can enter “X” as the content in fields that are defined as text strings.
However, the user must enter a valid value for those fields using the Dictionary Control Table values.
These values are identified by the word “Code” following the field name, such as
LocationTypeCode="HOM", VendorCode="Q5", TripTypeCode="AZ", DocTypeCode="PSPT" and so on. In
addition, a valid number or date format must be defined for those fields in the schema as
“NumericStrings” or “Date.”
please refer to the schema xml files located on Sabre Dev Studio. See the appendix for a list of standard
formats available by subject area. This means that there is a corresponding mapping to the Sabre GDS
PNR standard entries. Therefore, it is not necessary to create custom Formats to move these elements
into the PNR using the ProfileToPNRRQ service.
AssociatedProfiles and AssociatedFormats must contain the actual values for their corresponding
elements, unless the placeholder for AssociatedProfiles is used.
The Profile sub-element is followed by AssociatedProfiles. Up to 500 elements can be defined. The
following illustrates an XML example for AssociatedProfiles:
<AssociatedProfiles AssocUniqueID="5900"
AssocProfileTypeCode="TVL" AssocProfileName="GregCorp123" OrderSequenceNo="1"

DomainID="A5BE" ClientCode="TN"
ClientContextCode=“TMP”/>
Up to 6 placeholders can be added for Associated Profiles (AssociatedProfiles element without the
AssociatedProfiles@AssocUniqueID value specified) within a Filter. Each placeholder needs to specify a
different profile type (e.g. a Filter cannot have 2 placeholders for the type “CRP”) In case a Filter contains
a placeholder for a single type, then that filter cannot contain other AssociatedProfiles (placeholder or
not) elements with the same type. Example: You cannot have a Corporate Profile associated by UniqueID
and a placeholder for a Corporate Profile.
The following illustrates an XML example for a placeholder for an Associated Profile for a Corporation:
<AssociatedProfiles AssocProfileTypeCode="CRP" OrderSequenceNo="1" DomainID="A5BE" ClientCode="TN"
AssociatedProfiles are followed by AssociatedFormats. Up to 500 such elements can be specified. Each
AssociatedFormat consists of the following:
• DomainID (Required)
• FormatID (Required)
• FormatName (Required)
• SequenceNo (Optional)
• TemplateInheritInd (Optional)
To pass Formats into the ProfileToPNRRQ using the Filter path, the Formats must be included in the Filter
(under the AssociatedFormats section) or directly into the request in ProfileToPNRRQ (also under the
AssociatedFormats section).
Note: Format associated within a Profile or AssociationID does not indicate that it should be moved to
the PNR. The Filter governs what formats move to pnr therefore the Filter must include the
AssociatedFormats.
<AssociatedFormats FormatID="5900" DomainID="A5BE" SequenceNo="1"/>
The AssociatedFormat is valid only if there is a corresponding format in the Sabre Profiles database with
the same FormatID and DomainID.
Sample XML Create Filter Successful Response
When a Filter is successfully created, the following message displays:
<Sabre_OTA_ProfileCreateRS xmlns="http://www.sabre.com/eps/schemas"
Version="1.0">
<ResponseMessage>
<Success />
</ResponseMessage>
<Filter FilterID="4056" FilterName="Intl Tvl Filter" DomainID="A5BE"
ClientCode="TN" ClientContextCode=“TMP”>
</Filter>
The response message contains the Filter information about the newly-created filter. It is placed in the
Filter section, and is sufficient to retrieve this Filter from the Sabre database.
Sample XML Create Filter Error Response
If the Filter could not be created, an error message is returned. Each Error Message and Error Code
displays in the <Errors> section with a short description of the problem encountered when attempting to
save the Filter. Each Error message is prefixed with C:::. The following is a sample error message:
<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode=”123”> C:::FLT::Invalid Filter AssociatedProfiles data</ErrorMessage>
</Errors>
</ResponseMessage>
<Filter FilterID="*" FilterName=”Name” DomainID="A5BE"
ClientCode=”TN” ClientContextCode=“TMP” >
</Profile>
Reading Filters
Web clients can retrieve the Filter by specifying the FilterID, ClientContextCode, ClientCode, and
DomainID.
Version="1.0">
<Filter
FilterID="4250" ClientCode="TN"
ClientContextCode=“TMP” DomainID="A5BE"
</Filter>
Sample XML Read Filter Successful Response
When a Filter is successfully retrieved, the following response message is returned:

<ResponseMessage>
<Success/>
</ResponseMessage>
<Filter FilterID="25347" DomainID="A5BE" ClientCode="TN" ClientContextCode=“TMP”
FilterName="LEISURE" CreateDateTime="2010-03-18T23:27:22.817" UpdateDateTime="2010-03-
18T23:27:22.817" FilterStatusCode="AC" FilterTypeCode="TVL">
<Profile>
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP” UniqueID="a"
ProfileTypeCode="TVL" DomainID="A5BE"/>
<Traveler>
<Customer>
<GivenName>X</GivenName>
<SurName>X</SurName>
</PersonName>
<Telephone LocationTypeCode="HOM" OrderSequenceNo="1">
<FullPhoneNumber>XX</FullPhoneNumber>
</Telephone>
<Email EmailAddress="xyz@xyz.com" OrderSequenceNo="1" EmailTypeCode="BUS"/>
<Email EmailAddress="xyz@xyz.com" OrderSequenceNo="1"
EmailTypeCode="HOM"/>
<Email EmailAddress="xyz@xyz.com" OrderSequenceNo="2" EmailTypeCode="HOM"/>
</Customer>
</Traveler>
</Profile>
<AssociatedFormats DomainID="A5BE" FormatID="20843" FormatName="ITINERARY
REMINDER TEXT REMARK" SequenceNo="1"/>
<AssociatedFormats DomainID="A5BE" FormatID="20845" FormatName="PASSPORT
REMARK" SequenceNo="2"/>
</Filter>
<!—NOTE: the contents of the Profile, Associated Profiles and Formats sub tree are the same as for the
OTA_ProfileCreateRQ →
The Filter section contains information about the retrieved Filter. If the Filter was created, but there were
no updates to this filter, then the CreateDateTime and the UpdateDateTime attributes hold the same
time-stamp.
Sample XML Read Filter Error Response
If a Filter could not be retrieved, the following error message is returned:
<ResponseMessage>
<Errors>
R:::FLT::No filters have been found that match search criteria
</ErrorMessage>
</Errors>
</ResponseMessage>
Updating Filters
As with Profiles, Filters can also be updated. There is only one type of update available: Full Update.
Filters cannot be partially updated. The Full update of Filters works in the same way as it does for Profiles.
The old Filter data is deleted and replaced with the new data specified in the FullUpdateRQ. Systems
should Read the Filter content first, then apply all the data into an UpdateRQ with any applicable changes
so that all content is passed vs. just applicable changes.
The following is a sample Filter Update Request:
<Sabre_OTA_ProfileUpdateRQ xmlns="http://www.sabre.com/eps/schemas"
schemas\Sabre_OTA_ProfileUpdateRQ.xsd"
Version="1.0">
<Filter ClientCode="TN" ClientContextCode=“TMP” FilterID="130"
FilterName="FilterName123" DomainID="ABC124" CreateDateTime="2008-06-06T13:59:33.754"
UpdateDateTime="2008-06-06T13:59:33.754" FilterDescription="Filter description"
FilterPurgeNoOfDays="6" FilterStatus="AC">
<Profile CreateDateTime="2001-12-17T09:30:47.0Z" UpdateDateTime="2001-12-
17T09:30:47.0Z">
<TPA_Identity UniqueID="*" DomainID="ABC123" ClientCode="TN"
ClientContextCode=“TMP” ProfileTypeCode="TVL" ProfileStatusCode="AC"
ProfileNameModifyIndicator="Y" ProfileName="TNTraveler6"
ProfileDescription="ProfDesc" ProfilePurgeNoDays="7">
</TPA_Identity>
</Profile>
</Filter>
Sample XML Filter Update Successful Response
A successful update results in the following response.
Version="1">
<ResponseMessage>
<Success />
</ResponseMessage>
<Filter FilterID="3821" FilterName=”Name” DomainID="IM08">
</Filter>
Sample XML Filter Update Error Response
If a Filter could not be updated, the following error message is returned:
<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode=”123”> U:::FLT::Filter not found</ErrorMessage>
</Errors>
</ResponseMessage>
The update failed because the filter was not found in the Sabre Profiles database.
Searching for Filters
The Filter Search functionality allows the user to provide Search criteria to find matching Filters in the
Sabre Profiles database.
In the ProfileSearchRQ, the user must specify the following attributes to narrow the results set:
• DomainID
• FilterName
• ClientCode
• FilterTypeCode
These attributes are mandatory. Only DomainID and FilterName search criterion can contain the ‘*’
(wildcard symbol):
• Search Criterion = ‘AB*’ – this condition is satisfied only by the values that start from ‘AB’
followed by zero or more characters, such as ABXXX, ABC123, ABC, etc.
In addition to above FilterTypeCode search criterion accepts the following values:
• the list of values e.g. "TVL,AGY"

• "ALL” that indicates all types.
An example of a ProfileSearchRQ is shown below:
<Sabre_OTA_ProfileSearchRQ xmlns="http://www.sabre.com/eps/schemas" Target="Production"

<FilterSearchCriteria ClientCode="TN" ClientContextCode=“TMP”
DomainID="A5BE" FilterName="Super*"
FilterTypeCode="TVL" />
A successful FilterSearchRS is shown below:
<ResponseMessage>
<Success />
</ResponseMessage>
<FilterInfo>
<FilterList FilterID="1685" DomainID="AB5E" FilterName="Filter 1" ClientCode="TN"
ClientContextCode="TN" />
<FilterList FilterID="1684" DomainID="AB5E" FilterName="Filter 2" ClientCode="TN"
ClientContextCode="TN" />
</FilterInfo>
A list of Filters that match the Search criteria is returned. Repetitive Search is not available for Filters.
When there is only one filter that satisfies the Search criteria, the entire Filter is returned in the response.
If there are no Filters that match the Search criteria, the following response is returned:
<ResponseMessage>
<Success />
</ResponseMessage>
<FilterInfo>
<Message>No Filters Found with Search Criteria</Message>
</FilterInfo>
Deleting Filters
Delete functionality is available for Filters. By sending the appropriate request, a user can delete a Filter
from the Sabre Profiles database. If ProfileDeleteRQ is sent, the Filter is instantly deleted and purged
from the database. The Restore feature is not supported for Filters. Historical tracking of changes is not
supported for Filters.
Note: PurgeDays attribute is ignored for Filter delete.
Sample XML Filter Delete Request
An example of a Filter Delete request is shown below:


xsi:schemaLocation="http://www.sabre.com/eps/schemas \schemas\Sabre_OTA_ProfileDeleteRQ.xsd">
<Delete>
<Filter FilterID="1235" DomainID="A5BE" PurgeDays="1" ClientCode="TN"
ClientContextCode="TN"</Filter>
</Delete>
All the <Filter> attributes are mandatory. The value in PurgeDays is ignored for a Filter delete by Sabre
Profiles as it is an immediate Delete in the database. The remaining attributes (FilterID, ClientCode,
ClientContextCode, and DomainID) are used to identify a Filter that is marked for delete.
Sample XML Filter Delete Successful Response
A successful Filter Delete response is shown below:
<ResponseMessage>
<Success />
</ResponseMessage>
The <ResponseMessage> displays the <Success /> sub-element.
Sample XML Filter Delete Error Response
If a Filter is not deleted, an error message is returned. The <Errors> section contains a brief description of
a problem that was encountered during that process.
The sample error message is shown below:
<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode=”123”>R:::D:: Cannot delete Filter : Not found in the
database
</ErrorMessage>
</Errors>
</ResponseMessage>
The Filter was not deleted because it was not found in the Sabre database. Each error message is prefixed
with R:::D::.
Object inheritance scenario
A special case occurs when we are dealing with shared objects. An inheritance scenario is supported for a
Filter to select profile objects from different branched domains. A Filter can select:
- Formats from different domain when:
o Format it is selecting is marked as UsedByShared = “Y”
o Branch access is opened between 2 domains
- Associated Profiles from different domain when:
o Branch access is opened between 2 domains.
It is recommended that any Format or Associated Profile, that is being associated to a Filter and is coming
from another branched domain, is also associated to the AssociationID/object in the other domain. A
Profile using the Filter should be using the shared Association object as well. The table below shows the
recommended setup for an object inheritance scenario when branch access exists between domain A2FE
and A5CE:
Also, please see ProfiletoPNR service description for more details on using Filters with shared content.
Formats 15
Format Overview
A Format is an object in Sabre Profiles that allows the user to determine which data elements are
selected to become part of the ProfileToPNR service request. It also allows the user to determine how
these data elements are delivered to the PNR service to populate the GDS PNR.
Custom formats are those that are not regulated by Sabre or the Sabre PNR. They are defined by
individual agencies and users; however, the Sabre PNR does regulate the types (prefixes) of PNR entries
that can be used.
A Format is a stand-alone object that is created with the Sabre_OTA_ProfileCreateRQ service. It can be
associated to a Profile, AssociationID, and/or Filter to populate a Sabre PNR (in the GDS) with specific
entries. These entries document a reservation according to specific rules and standards set by each
agency client.
NOTE: For current Format supported elements, attributes, and number of instances allowed of these
Identifying Format Types
There are a limited number of FormatTypes (PNR- valid prefix entries). Each custom Format the user
creates must conform to one of these valid entry types. In most cases, once the Formats are compliant
with the PNR standards, there is little or no further regulation by Sabre or the Sabre PNR.
Custom formats would be added to the GDS PNR service by indicating the PNR entry type, accompanied
by the custom string constructed by the user. It is recommended, however, to always consult Format
Finder for specific grammar, structure, and rules for Sabre accepted PNR entries.
The table below illustrates the Format Types (pre-fixes) that are currently supported by the ProfileToPNR
service:
FormatType (Prefix) FormatTypeSuffix (Optional Qualifiers)
General Info – All Airlines (3) (BIKE) Bike

(BLND) Blind
(BSCT) Bassinet
(DEAF) Deaf
(DOCA) Document Information
(DOCO) Document Information
(DOCS) Document Information
(PSPT) Document Information
(EXST) Extra Seat
(FQTV) Frequent Traveler
(INFT) Infant in PNR
(AVIH) Live Animal in Cargo Hold
(PETC) Pet in Cabin
(OSI) Other Service Information
(OTHS) Other Service Information
(SPEQ) Sports Equipment
(SSR) Special Service Request
(STCR) Stretcher Assistance
(TKNM) Ticket Number Notification
(UMNR) Unaccompanied Minor
(WCHC) Wheelchair
(WCHR) Wheelchair
(WCHS) Wheelchair
General Info – AA (4) Same as above
Remarks (5) (A¥)-(Z¥) Alpha Coded Remarks

(/) Client Address
(C-CORP) Corporate Number Remark
(DL-) Delivery Address
(-) Form of Payment Remark
(Q-) Future Queue Placement Remark
(HR-) Hidden Remark
(H-) Historical Remark
(.) Invoice Remark
(¥) Invoice Remark
(*) Invoice Name Reference Remark
(FOP) FOP*VCN Virtual Payment
Received (6)
Ticketing (7) (T-) Already Ticketed

(TAW) Future Ticketing Date
Phone (9)
Credit Card Address Verification (CC/)
Customer Number (DK)
Frequent Flyer (FF)
GetThere Queueing (FNBTS)
Name Field (-)
FormatType (Prefix) FormatTypeSuffix (Optional Qualifiers)
Email (PE¥)
Queue Sort (QSORT)
Agency Address (W-)
A user can create a Format using these FormatTypes (PNR valid prefix entries). The rest of the string entry
can be structured using either fixed text, data elements from the Profile, user input, or a combination of
each.
Common examples of these Formats include different types of Remarks. For example, an Agency often
includes fixed text remarks to provide reminders or comments to their customers in the form of itinerary
remarks or invoice remarks.
For example:
5¥ CHECK IN AT THE AIRPORT 3 HOURS PRIOR TO YOUR INTL FLIGHT

or 5P¥ PASSPORT NO 123469789012 WILL EXPIRE ON 2016-03-25
or 5.UD2-FARE SAVINGS COST CENTER 999123 TRAVEL REASON CODE 99
or 6RECEIVED BY JOHN (preferred name from contact phone)
The following are custom PNR strings that can be entered in the PNR that agencies can use to store
information to be used at the time of booking.
A simple example could include only fixed text:

5 Remark prefix
¥ Suffix for Itinerary remark or could use fixed text with the Unicode value representation for a Cross
of Lorraine = ¥
CHECK IN AT THE AIRPORT 3 HOURS PRIOR TO YOUR INTL FLIGHT (Fixed text)
The corresponding XML for creating this format is shown below:
<Format FormatID="*" DomainID="A5BE" FormatName="ITINERARY REMINDER TEXT REMARK"

FormatType="5" FormatTypeSuffix="¥" FormatData="PLEASE CHECK 3 HOURS PRIOR YOUR INTL FLIGHT"
CreateDateTime="2010-03-18T23:27:13.054" UpdateDateTime="2010-03-18T23:27:13.054"
FormatStatusCode="AC" ClientCode="TN" ClientContextCode=“TMP”/>
These entries can also be broken down into components and used in combination with fixed text and
profile elements:
5 Remark pre-fix
P¥ Suffix for Alpha coded remark (P Cross of Loraine “a Sabre special character that must be
represented in its Unicode representation = ¥”)
PASSPORT NO Fixed text

1234567890123 Fixed text or the DocID value store in Document attributes
WILL EXPIRE ON Fixed text
2016-03-25 Fixed text or ExpireDate value store in Document attributes
<Format FormatID=”*“ DomainID="A5BE" FormatName="PASSPORT REMARK" FormatType="5"
FormatTypeSuffix="P¥" FormatData="PASSPORT NO
(/Profile/Traveler/Customer/Document[@DocTypeCode="PSPT" and
@OrderSequenceNo="1"]/@DocID) WILL EXPIRE ON
@OrderSequenceNo="1"]/@ExpireDate)" CreateDateTime="2010-03-18T23:27:16.095"
UpdateDateTime="2010-03-18T23:27:16.095" FormatStatusCode="AC" ClientCode="TN"
Another example:
6 Received field entry

RECEIVED BY Fixed text
John Preferred name from contact phone field
<Format FormatID="*" DomainID="A5BE" FormatName="Received filed 6 with profile preferred name"

FormatType="6" FormatData="RECEIVED BY
(/Profile/Traveler/Customer/Telephone[@OrderSequenceNo="1"]/Contact/@ContactFirstName)"
Another alternative would be to create the same Format, but pass “user input” from a POS graphical
interface so the user can manually enter information if additional data might be necessary.
For example:
<Format FormatID="*" DomainID="A5BE" FormatName="Received from with user input" FormatType="6"

FormatData="RECEIVED BY <ENTER CALLER NAME>" CreateDateTime="2010-03-23T13:28:31.328"
UpdateDateTime="2010-03-23T13:44:26.096" FormatStatusCode="AC" ClientCode="TN" ClientContextCode=“TMP”
As shown, there are already many elements that can be stored in the Sabre Profiles database. By using
Formats, the user can also store a string on how an entry would be built to populate the PNR.
This brings vast potential to the system because a user can create a single format referencing profile
elements and apply it to multiple profiles, such as contact names, or account information from each
profile. In addition, the user can still maintain a standard structure of how the PNR is documented
according to the business rules set by each agency client.
When storing the instructions for how agency-defined data is moved into the PNR, the user must do two
things:
• Identify the Sabre PNR entry type to be used to move data into the PNR
• Construct the string (Format) using a combination of constants, fields, and user input values.
Remember:
When creating Formats, it is important that the user consider the length restrictions indicated by the
elements in the schema. Formats sent via ProfileToPNR service must pass standard Sabre PNR rules for
the correct grammar, structure, and valid length or the format will fail during the move request.
For example:
If the length in a remark format is exceeded, but it stores successfully in Sabre Profiles, this could present
a problem when the Format is moved to the PNR. The Sabre GDS will return an error message and
prevent the entry if it does not comply with the PNR host rules.
Creating Formats
Sabre Profiles web clients can create a Format using the OTA_ProfileCreateRQ request. The following
sections describe the most typical aggregation of data currently in use.
How to Create a Format
The Format data sent from the web client is usually a small subset of all possible data. The first task would
be to determine which XML layout represents the Format data required by the web client.
The following section shows a typical format.
Sample XML Create Format Request
The Create Format XML request begins with the following boilerplate:
xmlns:eb="http://www.ebxml.org/namespaces/messageHeader" xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Header>
<eb:ConversationId>12345</eb:ConversationId>
<eb:From>
</eb:From>
<eb:To>
</eb:To>
<eb:CPAId>ABC</eb:CPAId>
<eb:Service eb:type="OTA"> Profile Format Create</eb:Service>
<eb:Action>EPS_ProfileCreateRQ</eb:Action>
<eb:MessageData>
<eb:MessageId>mid:20001209-133003-2333@clientofsabre.com</eb:MessageId>
</eb:MessageData>
</eb:MessageHeader>
<wsse:BinarySecurityToken>Shared/IDL:IceSess\/SessMgr:1\.0.IDL/Common/!ICESMS\/STSA!ICESMSLB\/STS.LB!-
4423856196987151328!1223888!0</wsse:BinarySecurityToken>
</wsse:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<Sabre_OTA_ProfileCreateRQ xmlns="http://www.sabre.com/eps/schemas"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" TimeStamp="2001-12-17T09:30:47.0Z" Version="0.0"
Target="Production" xsi:schemaLocation="http://www.sabre.com/eps/schemas
\schemas\Sabre_OTA_ProfileCreateRQ.xsd">
<Format FormatID="*" DomainID="A5BE" FormatName="6 with profile preferred name from contact
phone" FormatType="6" FormatData="RECEIVED BY
(/Profile/Traveler/Customer/Telephone[@OrderSequenceNo="1"]/Contact/@ContactFirstName)"
</Sabre_OTA_ProfileCreateRQ>
</SOAP-ENV:Body>
Following the common general section is the <Format> base element. It holds the following attributes:
• FormatID (Required)
• DomainID (Required)
• FormatName (Required)
• FormatType (Required)
• FormatTypeSuffix (Optional)
• FormatData (Optional)
• CreateDateTime (Required)
• UpdateDateTime (Required)
• FormatStatusCode (Optional)
• FormatPurgeNoOfDays (Optional)
• ClientCode (Required)
• ClientContextCode (Required)
Another sample fragment of the <Format> section is shown below:
<Format FormatID="20845" DomainID="A5BE" FormatName="PASSPORT REMARK" FormatType="5"

FormatTypeSuffix="P¥" FormatData="PASSPORT NO
@OrderSequenceNo="1"]/@DocID)WILL EXPIRE ON
@OrderSequenceNo="1"]/@ExpireDate)" CreateDateTime="2010-03-18T23:27:16.095"
<Format> does not contain any sub-elements. Within the Format CreateRQ the user can specify up to
100 <Format> sections.
Note: All Sabre special characters are stored as Unicode values:
• ¥ stored as &#x00A5
• ¤ stored as &#x00A4
• § stored as &#x00A7
A Format with the Secure Flight data is created based on the DocHolder sub-section in the Document
element of a Profile. The only required attributes for the Profile and Filter path to be moved to the PNR
are:
• SurName (Required)
• GivenName (Required)
It holds the following attributes:
• NamePrefix (Optional)
• MiddleName (Optional)
• NameSuffix (Optional)
Below is a Sample Format using Secure Flight data:
4DOCS/DB/25APR08/MI/JONES/EDWARD/PAUL-2.1
Sample Format Using the Optional NameSuffix Attribute
4DOCA/DB/13AUG72/M/SMITH JR/JOHN/WAYNE
Note: To properly move Secure Flight data to a PNR, the IsUsedForSecureFlightRules attribute must be
set to Yes in the Document section in the Profile. It is valid for both Profile and Filter path.
Sample XML Create Format Successful Response
When a Format is successfully created, the following response message is returned:
<Sabre_OTA_ProfileCreateRS TimeStamp="2010-03-23T15:47:57.085" Version="3.4" CreateDateTime="2010-

03-23T15:47:57.085" xmlns="http://www.sabre.com/eps/schemas">
<ResponseMessage>
<Success/>
</ResponseMessage>
<Format FormatID="21047" FormatName="6 with profile preferred name from contact phone"
DomainID="A5BE" ClientCode="TN" ClientContextCode=“TMP”/>
The Response message contains the Format section. Primary information about the newly-created
Format is placed in this section, which is sufficient to retrieve this Format from the Sabre Profiles
database.
Sample XML Create Format Error Response
If a Format could not be created, an error message is returned. The Error Message section contains an
Error Code and a brief description of a problem that was encountered during the Format saving process.
Each Error message is prefixed with C:::. The following is a sample error message:
<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode=”123”> C:::FMT::Invalid Format data</ErrorMessage>
</Errors>
</ResponseMessage>
<Format FormatID="*" FormatName=”Name” DomainID="A5BE" />
Using XPath Expressions for Formats
• XPath is a language for addressing parts of an XML document designed for use by both XSLT and
XPointer. Sabre Profiles system supports Xpath 2.0 functions and expressions.
• All XPaths are stored within parentheses (“ & “ ). The expression can also contain additional
parentheses and nested brackets [].
• All XPaths begin with /Profile.
• Customers/Systems that want to utilize xpath formats in their service calls are responsible for the
creation and maintenance of all xpath formats. The Sabre Helpdesks and Sabre Profiles Product
team will not support any xpath inquiries post migration to Sabre Profiles.
Sample Scenarios Containing a Valid XPATH
Reading an Element
To read an element, such as a Person’s MiddleName, the XPATH format is:
(/Profile/Traveler/Customer/PersonName[*]/MiddleName)
[*] is the occurrence count of the sequence since there might be more than one instance of the
element(s) in the profile, such as multiple names.
If PersonName is a sequence, then * must be populated with a value, otherwise, if left as * the first
occurrence is selected.
If the node is not a sequence, the format is:
(/Profile/Traveler/Customer/PersonName/MiddleName)
Read an Attribute
To read an attribute, the structure is /@attributename. For example, if Address City is an attribute, the
format is:
(/Profile/Traveler/Customer/Address/@CityName)
Reading an Additional Qualifier
In this scenario, the selection is done by adding a qualifier and not by occurrence, such as
PersonName[*]. For example, select a Telephone device vendor where the telephone OrderSequenceNo
is 1 (the OrderSequenceNo is within the BusinessTelephone). The format is:
(/Profile/Traveler/Customer/Telephone[@OrderSequenceNo=”1” and
LocationTypeCode=”BUS”]/@DeviceTypeCode)
The full path of the additional qualifier is used if the attribute is not at the same level.
Example 1
Select CardNumber from PaymentCard where PaymentForm OrderSequenceNo is 1. The XPath in this
scenario is:
(/Profile/Traveler/Customer/PaymentForm[@OrderSequenceNo=’1’]/PaymentCard/@CardNumber)
Example 2
Select CardNumber from Traveler PaymentForm where the TripTypeCode is AZ, BankCardVendorCode is
MC, and OrderSequenceNo is 1. The XPath in this scenario is:
(/Profile/Traveler/Customer/PaymentForm[@TripTypeCode='AZ' and
@OrderSequenceNo='1']/PaymentCard[@BankCardVendorCode='MC']/@CardNumber)
Example 3
Using an OR clause, select CardNumber from Traveler PaymentForm where the TripTypeCode is AZ or
BankCardVendorCode is MC, and OrderSequenceNo is 1. The XPath in this scenario is:
(/Profile/Traveler/Customer/PaymentForm[@TripTypeCode=’AZ’ and
@OrderSequenceNo=’1’]//PaymentCard/@CardNumber |
/Profile/Traveler/Customer/PaymentForm[@OrderSequenceNo=’1’]/
PaymentCard[@BankCardVendorCode=’MC’]/@CardNumber)
Date Conversion Features
Data conversion features are described in the following sections.
Date Objects
For Date objects formatting there are two additional XPath functions:
• p3:format-date
• p3:format-mmyyyy
To show the date in MMYYYY format, such as PaymentCard/@ExpireDate, the syntax is:
(p3:format-mmyyyy(xs:string(<MMYYYY>), <formatString>))
The following is an example with MMYYYY:
(p3:format-myyyy(xs:string(/Profile/Traveler/Customer/PaymentForm[1]/PaymentCard/@ExpireDate),
‘yyyy MMM’))
Example 1
122012 converts to 2012 DEC
MMYYYY can also use the day of month. It will be 1.
For example, “d-MMM-yyyy” converts to 1-DEC-2012
Example 2
Using xs:date format, such as Document/@ExpireDate, the syntax is:
(p3:format-date(xs:date(<date>), <formatString>))
The following is an example with xs:date:
(p3:format-date(xs:date(/Profile/Traveler/Customer/Document[1]/@ExpireDate),’d/MMM/yyyy’))
2009-12-05 converts to 5/DEC/2009
Example 3
<formatString> is processed by SimpleDateFormat java class, where all possible symbols can be found.
http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html
The following is a more complex example combining fixed text, profile elements, and user input:
(/Profile/ Traveler
/Customer/PersonName/SurName[@OrderSequenceNo=’1’])4567<UserInputFirstName> ¤4890956789(/Pr
ofile/ Traveler /Customer/CustLoyalty[@VendorCode=’AA’]/@MembershipID) ¤ (/Profile/ Traveler
/Customer/EmergencyContactPerson[1]/SurName)<UserInputData>¥
(/Profile/Traveler/Customer/PaymentForm[@TripTypeCode=’AZ’ and @OrderSequenceNo=’1’]/
/PaymentCard/@CardNumber | /Profile/Traveler/Customer/PaymentForm[@OrderSequenceNo=’1’]/
PaymentCard[@BankCardVendorCode=’MC’]/@CardNumber)123456(/Profile/ Traveler
/Customer/CustLoyalty[@VendorCode=’AA’ and @OrderSequenceNo=’1’]/@MembershipID)
Conditional XPath Format Functions
Profiles Services can support validations, truncations, and substitutions within custom formats in Sabre
Profiles including nested conditions that have to be executed in a certain order.
Users can create a profile with custom formats which evaluate strings, and configure conditions which
evaluate the existence of a data field(s) using AND/OR logic, the specific value of data field(s), and based
on the existence of data or value in a field, can include any replacement text or characters via a
substitution object within the string itself or can limit the character count in the database field value used
in the format that moves to PNR.
Profiles supports a limited set of REGEX rules to search/replace data using substitutions. A rule can be
configured to validate data "equal to", "not equal to", "contains", "starts with specific character and has x
amount of characters", "has X amount of characters and ends with a specific character", "removes" a
specific character or set of characters where they exist (spaces, commas, @, apostrophes) completely or
could “translate” or "replace" with another set of characters.
Explanation of nested conditions: Sometimes there is a need to evaluate a group of conditions before
moving on to validate a separate group of conditions to create a single format. Often this conditional
hierarchy for validation starts and ends with"()" and contains ")(" or "){" to know that a group of
validations has to occur as a single action before moving on to the next action in the string which might
include another set of validations that have to occur in a group single action. There also could be multiple
validations in a single group action before moving on to the next action. A user may define up to 10
conditions within a single format string. Sabre Profiles Web Services has a function for ‘substitution’
within the XPath and also increased the size of the allowed XPath to support the potential nested
conditions.
Existing profile data can also be re-formatted. The ability to take any stored Profile data value and define
that it should be moved to PNR in a specific format such as taking a FullPhone field which could include
dashes, extensions noted with X, spaces, or all run together and format it as 999-999-9999x999 when
moved to PNR. The user determines how the data should display in the format in the PNR. Sabre Profiles
supports re-formatting using pictograms noting acceptance of alpha=a-z, numeric =0-9, dates, times,
other characters and escaped characters copied as they are. Profiles Services has a function of
‘pictogram’ within the XPath to support this.
Pictogram Function
Users can use the pictograms function within an XPath expression. The Pictogram pattern is completed
with ‘0’, ‘a’ or ‘9’ characters. A zero (‘0’) represents the next available decimal digit in the field whereas a
nine (‘9’) represents the next available decimal digit with removal of leading zeros. The letter ‘a’
represents the next letter in the field although it can allow numbers too such as in an address. The letter
‘a’ in the pictogram will not pass through an underline.
Any non-pictogram character is inserted into formatted output string. If one of the pictogram characters
is a value that you want to insert then precede the item with a backslash.
• Null or empty node set parameter returns an empty result (iterator over zero elements). No error
exception is thrown.
• Numbers are formatted according to patterns involving ‘0’ and ‘9’ and leading zeros are
considered in the evaluation.
• Texts are formatted according to the pattern involving ‘a’ characters. Sequence of ‘a’ characters,
in the case the string parameter is longer, is equivalent to the substring function.
• Text pattern (sequence of ‘a’ characters) is included with number parameters as well.
• Underline in text parameter is not passed to the output.
• Non-special characters are copied to output.
• Special characters can be escaped.
• Double backslash (“\\”) is copied as single backslash (“\”).
Examples of pictogram evaluation:
Input Pictogram Result

123 0000 0123
123 9999 123
Sabre aaa Sab
Sabre aaaaaa Sabre
fox jumping aaaa jumping fox
123456 00-00-00 12-34-56
zzzzzz aaa\a\a\abbb zzzaaabbb
zzz \\aaa\\ \zzz\
1 \0\909 0901
1234 aaaa 1234
1234 000-000 001-234
Example of XPath using Pictogram
<EmployeeInfo>
<EmployeeId>123456</EmployeeId>
</EmployeeInfo>
"(p3:pictogram(xs:string(/Profile/Traveler/Customer/EmploymentInfo/EmployeeInfo/EmployeeId),'SG0000000'))"
Evaluates to “SG0123456”when EmployeeId stored value = 123456
Substitution Function
Two XPath functions are supported for the manipulation of profile data in the XPath format.
XPath follows an If-Then-Else conditional logic, but the XPath expressions pointing to fields in the Sabre
Profiles schema using this feature can be large strings. So, if there are e.g. 50 alternatives, then the
expression would be very long, hence a substitution function makes the XPath shorter and easier to
parse.
• Entire text or substring can be replaced.
• Substitution is case-sensitive.
Having the following substitution table:
Substitution
Stored Data
Data
ABC XYZ
BC 123
‘ <space>
The substitution should have the following effect for the specified texts. Red means no substitution was
applied.
Substitution
Stored Data
Data
ABC XYZ
abc abc
ABCD ABCD
BC 123
O‘Mally O Mally
Examples of XPath using Substitution
The below supports substituting the text “Male” for the data field value of “M” in the resulting format.
Xpath will support up to 100 pairs of substitutions.
substitute(/Profile/Traveler/Customer/@GenderCode, “M”, “Male”, “F”, “Female”)
An optional "default" value can also be used.
substitute(matchData, “M”, “Male”, “F”, “Female”, "Unknown")
• if matchData is null then an empty string is returned (even if default is provided)

• if matchData doesn't match any value, then the default provided is returned
• if matchData doesn't match any value and a default is not provided, then original data is
returned
Scenario: Using Substitutions to remove special characters from a stored value if Sabre doesn’t support
such characters in a PNR format.
Removing all special character from a Business Address City Name stored in the profile and replacing
the & symbol with the word AND.
if ((concat((//Profile/Traveler/Customer/Address[@LocationTypeCode="BUS" and
@OrderSequenceNo="1"]/CityName), ())) != "") then concat("*U9-",
replace(replace(translate(string(//Profile/Traveler/Customer/Address[@OrderSequenceNo="1" and
@LocationTypeCode="BUS"]/CityName), "+[({])}/='.,*#_",""), "&", "AND"), '"', ''), ()) else ()
Processing Format Data
Format Data is a required element of a Format. It holds several XPath expressions and values for format
parameters, among other Unicode characters. All XPath expressions are in parentheses, so that they can
be easily extracted from Format data. When a Format is created or updated, each XPath expression is
validated. There are two stages to the validation process. In the first stage, the Sabre Profiles software
ensures that the expression being analyzed is a valid XPath expression. In the second stage, the XPath
expression is validated against Sabre Profiles schema. The format parameters are in brackets [ ]. The
Format Data syntax is shown below:
(/Profile/Traveler/Customer/PersonName[1]/Surname) <MiddleName>
Before the Format data is saved, the Sabre Profiles software validates the XPath expression. If the XPath
expression does not pass the validation process, the Format is not created or updated, and an error
response displays. All XPath expressions are generated by a client application, such as a GUI based on the
information provided by the end-user. Apart from the simple XPath expressions (as shown in the above
example), Sabre Profiles software also accepts and validates compound XPath expressions:
(/Profile/Traveler/Customer/PersonName[1]/Surname |
/Profile/Traveler/Customer/PersonName[2]/SurName)
This is a compound XPath expression that consists of two simple XPath expressions and a union (“|”)
operator between them.
Read Formats
Web clients can retrieve formats by specifying:
• FormatID
• DomainID
• ClientCode
<Sabre_OTA_ProfileReadRQ
xsi:schemaLocation="http://www.sabre.com/eps/schemas \schemas\Sabre_OTA_ProfileReadRQ.xsd">
<Format FormatID="20991" DomainID="A5BE" ClientCode="TN" ClientContextCode=“TMP”/>
Sample XML Format Read Successful Response
When a Format is successfully retrieved, the following response message is returned.

<ResponseMessage>
<Success/>
</ResponseMessage>
<Format FormatID="20991" DomainID="A5BE" FormatName="Received from" FormatType="6"
FormatData="RECEIVED BY <ENTER CALLER NAME>" CreateDateTime="2010-03-23T13:28:31.328"
The Format section contains all the information about the retrieved Format. If the Format was created
but no updates were performed on this format, the CreateDateTime and the UpdateDateTime attributes
hold the same time-stamp.
Sample XML Format Read Error Response
If a format could not be retrieved, the following error message is returned:
<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode=”123”>R:::FMT::No formats have been found that match search
criteria</ErrorMessage>
</Errors>
</ResponseMessage>
Updating Formats
As with Profiles, Formats can also be updated. There is only one type of update available: Full Update.
Formats cannot be partially updated. A Full update of Formats works in the same way as it does for
Profiles. The old Format data is replaced with the new data specified in the FullUpdateRQ. A sample
Format Update Request is shown below:
<Sabre_OTA_ProfileUpdateRQ xmlns="http://www.sabre.com/eps/schemas"
schemas\Sabre_OTA_ProfileUpdateRQ.xsd"
Version="1.0">
<Format FormatID="4567" FormatName="Format Name Updated" DomainID="ABC123"
CreateDateTime="2001-12-17T09:30:47.0Z" FormatType="TVL"
UpdateDateTime="2001-12-17T09:30:47.0Z" FormatData="AW Format90 Data"
FormatPurgeNoOfDays="1" FormatStatus="AC">
</Format>
Sample XML Update Format Successful Response
A successful update results in the following response:
Version="1">
<ResponseMessage>
<Success />
</ResponseMessage>
<Format FormatID="4567" FormatName=”Name” DomainID="A5BE">
</Format>
Sample XML Update Format Error Response
If a Format could not be updated, the following error message is returned:
<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode=”123”>U:::FMT::Format not found</ErrorMessage>
</Errors>
</ResponseMessage>
The update failed because the format was not found in the Sabre Profiles database.
Searching for Formats
The Format Search functionality allows the user to provide Search criteria to find matching Formats in the
Sabre Profiles database.
In the ProfileSearchRQ, the user can specify the following attributes to narrow the results set:
• DomainID
• ClientCode
• FormatName
• FormatType
• FormatTypeSuffix
DomainID and ClientCode are required attributes. Except for ClientCode and ClientContextCode, each
search criterion can contain the ‘*’ (wildcard symbol):
• Search Criterion = ‘AB*’ – this condition is satisfied only by the values that start from ‘AB’
followed by zero or more characters, such as ABXXX, ABC123, ABC, etc.
An example of a ProfileSearchRQ is shown below:
<Sabre_OTA_ProfileSearchRQ xmlns="http://www.sabre.com/eps/schemas" Target="Production"

<FormatSearchCriteria>
<Format DomainID="A2FE" ClientCode="TN" ClientContextCode=“TMP”
FormatName="Format 1"/>
</FormatSearchCriteria>
A successful FormatSearchRS is shown below:
<Sabre_OTA_ProfileSearchRS Version="6.13" xmlns="http://www.sabre.com/eps/schemas">

<ResponseMessage>
<Success/>
</ResponseMessage>
<FormatInfo>
<FormatList NumReturned="2" HaveMore="N">
<FormatID="1685" FormatName="Format 1" DomainID="A2FE" ClientCode="TN"
ClientContextCode=“TMP” FormatType=”5.” />
<FormatID="1684" FormatName="Format 1" DomainID="A2FE" ClientCode="TN"
ClientContextCode=“TMP” FormatType=” 5¥” />
</FormatInfo>
A list of Formats that match the Search criteria displays. This is the only type of Search supported. When
there is only one Format that satisfies the Search criteria, the entire Format is returned in the response.
If there are no Formats that match the Search criteria, the following response is returned:
<Sabre_OTA_ProfileSearchRS Version="6.13" xmlns="http://www.sabre.com/eps/schemas">

<ResponseMessage>
<Success/>
</ResponseMessage>
<FormatInfo>
<Message>No Formats Found with Search Criteria</Message>
</FormatInfo>
Deleting Formats
The Delete functionality is available for Formats. By sending the appropriate request, a user can delete a
Format from the Sabre Profiles database. If ProfileDeleteRQ is sent, the Format is instantly deleted and
purged. Restore feature is not supported for Formats. Historical tracking of changes is not supported for
Formats.
Note: PurgeDays attribute is ignored for Formats delete.
Sample XML Format Delete Request
An example of a Format Delete request is shown below:


\schemas\Sabre_OTA_ProfileDeleteRQ.xsd">
<Delete>
<Format FormatID="235" DomainID="A5BE"
PurgeDays="1" ClientCode="TN"
ClientContextCode="TN"
</Format>
</Delete>
All the <Format> attributes are mandatory. The value in PurgeDays is ignored for Formats delete by Sabre
Profiles. The remaining attributes (FormatID, ClientCode, ClientContextCode, and DomainID) are used to
identify a Format that is marked for delete.
Sample XML Format Delete Successful Response
A successful Format Delete response is shown below:
<ResponseMessage>
<Success />
</ResponseMessage>
The <ResponseMessage> displays the <Success /> sub-element.
Sample XML Format Delete Error Response
If a Format is not deleted, an error message is returned. The <Errors> section contains a brief description
of a problem that was encountered during that process.
The sample error message is shown below:
<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode=”123”>R:::D:: Cannot delete Format : Not found in the
database
</ErrorMessage>
</Errors>
</ResponseMessage>
The Format was not deleted because it was not found in the Sabre database. Each error message is
prefixed with R:::D::.
Templates/Associations with Metadata 16
Overview
This document covers the usage of the Associations object (Templates) in Sabre Profiles at the services
level. If these templates are to be used with the Sabre Profiles Graphical User Interface (GUI) that is part
of the Sabre Red Workspace, additional rules will apply as not all features are available within the GUI.
Please refer to the Appendix in this document for more details.
A template is an entity that defines common characteristics for multiple profiles. It can be created and
modified by the client (the owner of the profile data).
Templates have the following functionality:
- Defining metadata
- Defining validators
Defining relationships (associations)
To make use of templates in Sabre Profiles, the Association object should be utilized. It contains multiple
objects (has them associated) and can be attached to a profile to make these associations available to the
profile.
o define related objects that participate in moving a profile to a PNR;

o define metadata for a profile;
o define validations for a profile;
o define related profiles (e.g. corporate profile, agency profile);
o identify a profile as a member of some group
Associations are implemented by the AssociationID object.
Objects linked to the AssociationID object can be used for the following purposes:
1. Metadata
Metadata can be used to define the scope of data that is presented to a user in a UI
application. It is implemented as an entity named Metadata.
2. Validator
Validator can be used to check if the data sent by a GUI or any other client meets the
conditions defined by the data owner/administrator. It is implemented as a Validator object.
All of the above entities are described in detail in the following sections.
Association Object
Sabre Profiles includes logic for associating one object to another, e.g.
• filter to profile;
• format to profile;
• profile to filter, etc.
These associations are supported in two ways: directly associated with a Profile and through the
Association object which is associated to a Profile.
Direct association means that something is associated directly to a profile, such as a filter, and this means
that this filter applies only to that specific profile. If this filter is to be applied to other profiles, it has to be
explicitly associated to these profiles. Similarly, if you want to associate another filter to all these profiles,
you would need to change them one by one, updating their direct associations.
Association through the Association object means that multiple relationships are grouped in one
dedicated object called Association. One Association object can have associations to different object
types, i.e.
1. Profiles
2. Filters
3. Formats
4. Metadata
5. Validators
A profile inherits all of these associations when the Association object is attached to the profile.
This means that multiple profiles can share the associations (by having the same Association object
attached) and that a single change of the Association object (e.g. adding a new filter to it) can affect these
multiple profiles.
The logic of the Association object
Associations have types corresponding to profile types, e.g. Traveler (TVL), Corporation (CRP) etc. The
Association Object of TVL type can be attached only to TVL profiles (same for other types). The
Association Object of TVL type can contain only objects of TVL type. This applies to all object types, except
profiles.
Objects that can be associated to an Association object can be broken down into two groups:
1. Profiles, Filters, Formats

These objects can be also associated directly to a profile. They are associated to an Association
object in the same way they are to a Profile. The main purpose of having these objects associated
is to use them in the MoveToPNR process. Please refer to the Profile to PNR Service section in this
guide for more information on the Profile to PNR service and functionality. If a profile has objects
associated directly as well as by an Association object, the former take precedence over the latter
if there could be ambiguity.
2. Metadata and Validators
These two objects types cannot be attached directly to a profile, only by Association.
Metadata objects are not processed in any way by Sabre Profiles Services. They are only stored
and retrieved. Refer to the Metadata section for more details.
Validators are used to verify the contents of a profile against defined rules. This happens during
ProfileCreate and ProfileUpdate operations if the profile has an Association defined that contains
Validators. Please refer to the Validators section for details.
With the above elements defined, the Association object serves as a template that controls common
behavior (PNR, Validations, Metadata) for a group of profiles. For example, this group can be profiles that
represent travelers who are employees of one company. All these profiles can share the same Filters,
Formats, Validations, etc. So there could be one Association for CompanyA, another for CompanyB, etc.
Please note that the Association object doesn’t need to contain objects of all of types. It can have just a
few of them. The only rule is that if there are multiple object types used, they must always go in the same
sequence as in the example above (this is defined in XML schema).
For the attribute AssociationName, validation exists in Sabre Profiles to enforce uniqueness in the value
of this attribute within the same Domain/PCC.
NOTE: For current Associations supported elements, attributes, and number of instances allowed of these
Creating an Association object
Associations are created with the ProfileCreateRQ request. A sample request is provided below:
<Sabre_OTA_ProfileCreateRQ Version="1.0" xmlns="http://www.sabre.com/eps/schemas"

xsi:schemaLocation="http://www.sabre.com/eps/schemas ..\schemas\Sabre_OTA_ProfileBulkReadRQ.xsd">
<Association ClientCode="TN" DomainID="A2FE" ClientContextCode=“TMP” AssociationID="*"

ProfileTypeCode="TVL" AssociationName="BigCorp">
<AssociatedProfiles ClientCode="TN" DomainID="A2FE" AssocUniqueID="110845394"

OrderSequenceNo="2" AssocProfileTypeCode="TVL"/>
<AssociatedFilters DomainID="A2FE" FilterID="52284" SequenceNo="1"/>
<AssociatedFormats DomainID="A2FE" FormatID="631480" SequenceNo="2"/>
<AssociatedMetadata ClientCode="TN" ClientContextCode=“TMP” DomainID="A2FE"

MetadataID="1234" OrderSequenceNo="1" DisplaySequenceNo="1" ProfileTypeCode="TVL"/>
<AssociatedValidators ClientCode="TN" ClientContextCode=“TMP” DomainID="A2FE"

ValidatorID="5678" OrderSequenceNo="1" DisplaySequenceNo="1" ProfileTypeCode="TVL"/>
</Association>
Elements Description
ClientCode, DomainID and The same as in all other requests.

ClientContextCode
AssociationID The Identifier of the Association. In the Create request, it should be set to
“*” which means Sabre Profiles will assign a unique identifier and return it in
the response.
ProfileTypeCode The profile type for which the Association is intended (see below)
AssociationName For example naming the Association as “BigCorp” may mean that this
Association is used as a template for all travelers that are employees of
BigCorp company.
AssociatedFilters, Objects grouped by this Association. Same rules apply as when associating
objects directly to a profile.
AssociatedFormats etc.
This is a sample response to the request presented above:
<Sabre_OTA_ProfileCreateRS TimeStamp="2012-08-30T08:45:08.968Z" Version="6.8" CreateDateTime="2012-08-

30T08:45:08.968Z" xmlns="http://www.sabre.com/eps/schemas">
<ResponseMessage>
<Success/>
</ResponseMessage>
<Association ClientCode="TN" ClientContextCode=“TMP” DomainID="A2FE" AssociationID="89537"
The AssociationID attribute contains the unique identifier that can be later used to update or delete this
Association or attach it to a profile.
Attaching an Association to a profile
For the Association to be effective for a given profile, it should be attached to that profile. This can be
done during the ProfileCreate or the ProfileUpdate operation. Only one Association object can be
attached to a profile at any time. Below is a snippet of a ProfileCreate request that attaches the
Association object created above to a profile being created:
<Sabre_OTA_ProfileCreateRQ xmlns="http://www.sabre.com/eps/schemas" TimeStamp="2012-05-

10T09:39:43.236Z" Version="6.4">
<Profile CreateDateTime="2011-10-20T16:00:24.346Z" UpdateDateTime="2011-10-20T16:00:24.346Z"
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP” UniqueID="*" ProfileTypeCode="TVL"
ProfileName="ProfileName" ProfileNameModifyIndicator="Y" DomainID="A2FE"
<Traveler>
<Customer>
<PersonName LanguageIDCode="EN-US" OrderSequenceNo="1">
</PersonName>
</Customer>
</Traveler>
<Association ClientCode="TN" ClientContextCode=“TMP” DomainID="A2FE"
AssociationID="89537"
</Profile>
When the Association object is attached to a profile, it can be used to search for profiles that have this
Association attached. Below is a sample Search request that does this:
<Sabre_OTA_ProfileSearchRQ xmlns="http://www.sabre.com/eps/schemas" TimeStamp="2011-12-

01T10:27:03.439Z" Target="Production" Version="5.5">
<ProfileSearchCriteria>
<TPA_Identity ProfileTypeCode="TVL" DomainID="A2FE" ClientCode="TN"/>
<Association AssociationID="89537"/>
When a profile has an Association attached, it can be updated to have another Association attached
instead of the original one. It is also possible to detach the Association from the profile. This can be done
with a regular ProfileUpdate request: if it contains a new Association, it means the old one is replaced; if
it doesn’t contain an Association, it means the Association should be detached from the profile.
In above Search example, if you don’t have the AssociationID, you can search by AssociationName to get
the ID, then send the Update or Create request to link the profile to the AssociationID as shown above.
<ProfileSearchCriteria>
<TPA_Identity ProfileTypeCode="TVL" DomainID="A2FE" ClientCode="TN"
<Association AssociationName=”BigCorp”/>
Updating and Deleting Association Objects
The Update and Delete operations for an Association object follow general logic for other object types,
with one exception: an Association cannot be deleted if it is attached to any profile.
Sample requests are shown below:
<Sabre_OTA_ProfileUpdateRQ Version="1.0" xmlns="http://www.sabre.com/eps/schemas"

<Association ClientCode="TN" DomainID="A2FE" ClientContextCode=“TMP” AssociationID="89537"
ProfileTypeCode="TVL" AssociationName="SmallCorp">

</Association>
<Sabre_OTA_ProfileDeleteRQ Version="1.0" xmlns="http://www.sabre.com/eps/schemas"

<Delete>
<Association ClientCode="TN" DomainID="A2FE" ClientContextCode=“TMP”
AssociationID="89537"
</Delete>
Shared Association Objects
Shared Association objects creation/update
The general rule for attaching an Association object to a Profile is that both the Profile and the
Association object exist in the same domain. The exception for this rule are Association objects that are
shared – they can be used with Profiles in different domains if those domains are branched. A shared
Association object needs to be flagged as “shared” in a Create or Update request by using the Shared=”Y”
value:
<Association Shared="Y" ClientCode="TN" ClientContextCode=“TMP" DomainID="A2FE" ProfileTypeCode="TVL"

AssociationID="*" AssociationName=" SmallCorp_Shared"/>
The objects (Filters, Formats, Metadata and Validators) that can be associated to Association objects
need to be flagged as “UsedByShared” in a create or update request:
<Format UsedByShared="Y" FormatID="*" DomainID="A2FE" ClientCode="TN" ClientContextCode=“TMP"

FormatName="Format_1 " FormatType="PI" CreateDateTime="2014-11-17T13:16:59.299Z"
UpdateDateTime="2014-11-17T13:16:59.299Z" FormatStatusCode="AC"/>
<Filter UsedByShared="Y" CreateDateTime="2014-11-17T13:19:16.775Z" UpdateDateTime="2014-11-

17T12:19:17.349Z" FilterID="1220398" DomainID="A2FE" ClientCode="TN" ClientContextCode=“TMP"
FilterName="Filter_1" FilterTypeCode="TVL">
<Validator UsedByShared="Y" ProfileTypeCode="TVL" CreateDateTime="2014-11-17T13:20:30.586Z"

UpdateDateTime="2014-11-17T13:20:30.586Z" ClientCode="TN" ClientContextCode=“TMP" DomainID="A2FE"
ValidatorID="*">
<Metadata UsedByShared="Y" ProfileTypeCode="TVL" CreateDateTime="2014-11-17T13:21:34.680Z"

UpdateDateTime="2014-11-17T13:21:34.680Z" ClientCode="TN" ClientContextCode=“TMP" DomainID="A2FE"
MetadataID="*">
Shared Association Object Business Rules
Below are the business rules that concern create, modify, use and delete operations for shared
Association objects:
- Only users with the EPSSharedAdmin Security permission on their EPR can create, update or
delete shared and “used by shared” objects
- A shared Association object can be created only when all its Filters, Formats, Metadata and
Validators are flagged as “UsedByShared”
- A non-shared Association object (object with @Shared=”N” or without a value set) can be
modified to be shared only when all its Filters, Formats, Metadata and Validators are flagged
as “UsedByShared”
- Shared Association objects can be modified to be non-shared only when all Profiles the
Association object is attached to are in the same domain as the Association object
- Objects (Filter, Format, Metadata, Validator) can be modified to be non “UsedByShared ” only
when all the Association objects it belongs to are non-shared
- Objects (Filter, Format, Metadata, Validator) that are “UsedByShared ” can be used in an
Association object that is shared and that is non-shared
- Objects (Filter, Format, Metadata, Validator) that are not “UsedByShared ” can be used in an
Association object that is non-shared
Below are the business rules for using shared Association objects:
- A user can associate an Association object with shared flag "Y" to Profiles from different
domains only when the user has branch access to both of those domains
- It is recommended that the shared Association object domain is branched to every domain in
which the Profiles using this Association object will reside
- It is recommended that all branches in the structure that use shared Association objects are
setup both ways
Recommended setup is shown in a diagram below:
When Profiles 1, 2 and 3 are using a shared Association object from PCC1, each profile PCC needs to be
branched to PCC1. PCC1 needs to be branched to each profile PCC (branching needs to be done in both
directions).
When a profile is using a shared Association object from a different domain, it means that it can be
moved to PNR using the filter that is coming from another domain and every other service (e.g. Read,
BulkRead, Search etc.) is supported unless branch access is not open.
Below is an example of a ProfileReadRS response for a Profile in domain ID = A5CE that is using a shared
Association object from domain ID A2FE. This shared Association object has a Filter associated. Branch
access is open between A5CE and A2FE.

ProfileTypeCode="TVL" ProfileName="TestProfile_2014-11-17_14:41:52_ftY" ProfileNameModifyIndicator="Y"
DomainID="A5CE" ProfileStatusCode="AC"/>
<Traveler>
<TPA_Extensions>
<AssociatedFilters FilterID="1220411" FilterName="TestFilter_2014-11-
17_14:46:46_K95" ClientCode="TN" ClientContextCode=“TMP" DomainID="A2FE" CreateDateTime="2014-11-
17T13:46:47.595Z" UpdateDateTime="2014-11-17T13:46:47.595Z" TemplateInheritInd="Y"/>
</TPA_Extensions>
</Traveler>
<Association AssociationID="510339" DomainID="A2FE" ClientCode="TN"
AssociationName="TestAssociation_2014-11-17_14:41:52_5hh" ClientContextCode=“TMP" ProfileTypeCode="TVL"
CreateDateTime="2014-11-17T13:41:52.67Z" UpdateDateTime="2014-11-17T13:41:52.67Z" Shared="Y"/>
</Profile>
Attaching an Association to another Association (child/parent

functionality)
For the Association to be the child of another Association object (parent), it should be attached to that
Association object. This can be done during the ProfileCreate or the ProfileUpdate operation. Only one
Parent Association object can be attached to a Child Association object at any time. Below is a snippet of
a ProfileCreate request that attaches the Association object created above to a child Association object
being created:
<Sabre_OTA_ProfileCreateRQ xmlns="http://www.sabre.com/eps/schemas" TimeStamp="2012-05-

10T09:39:43.236Z" Version="6.4">
<Association ProfileTypeCode="TVL" DomainID="A5CE" AssociationID="*"
AssociationName="TestChildAssociation " CreateDateTime="2015-05-25T11:26:58.775Z" UpdateDateTime="2015-
05-25T11:26:58.775Z" ClientCode="TN" ClientContextCode=“TMP">
</Association>
When a Child Association object is attached to another Association object, it can be used to search for
Association objects that have this Association attached. Below is a sample Search request that does this:

<ParentAssociation AssociationID="89537"/>
</AssociationSearchCriteria >
When a Child Association has a Parent Association attached, it can be updated to have another
Association attached instead of the original one. It is also possible to detach the Association from the
child Association object (it is not considered a child anymore). This can be done with a regular
ProfileUpdate request: if it contains a new Association, it means the old one is replaced; if it doesn’t
contain an Association, it means the Association should be detached from the child Association object.
Child Association Object Business Rules
Below are the business rules that concern creating updating and using child Association objects:
- Users that have access to Association objects can create/modify or delete child Association
objects.
- Child Association objects cannot contain any Metadata objects and/or Validators. Metadata
and Validators from the Parent Association object level are always used. This means that:
o Regular non-child Association object can be updated to be child only if it doesn’t
contain any Metadata or Validators
o Metadata and/or Validators cannot be associated to an Association object if it is
considered as child
- An Association object specified as a Parent Association for a child must be shared (Shared =
“Y”)
- Child Association objects cannot be shared. This means that only one level of inheritance of
Metadata and Validators is permitted.
- A parent Association object may reside in the same domain or in a different branch domain
from the child Association object.
Branch Access Closed
When branch access between a Profile domain and Association objects domain (or Child Association and
Parent Association object) is not open (e.g. Profile was created when branch access was open and later it
was closed) it is possible to read and modify a Profile that is using a shared Association object (or child
Association and parent Association object), however:
- The shared Association object itself will not be read due to insufficient branch access rights.
- Any objects associated to the shared Association object (thus associated to the Profile
indirectly) will not be returned in a ProfileReadRS when a Profile is subject to a ProfileRead.
- A Profile cannot be moved to PNR using the Filter that belongs to this shared Association
object (even through blind move)
- A warning message informing that the branch access is not open is returned in the
ProfileReadRS. See example below for warning message wording and code.
Example of a ProfileReadRS response for a Profile in domain ID = A5CE that is using a shared Association
object from domain ID A2FE. This shared association object has a Filter associated. Branch access is
closed between A5CE and A2FE.

<ResponseMessage>
<Warnings>
<WarningMessage WarningCode="34">Profile ID: 103086131 is using Association ID: 510339
from domain that is not branched to your domain</WarningMessage>
</Warnings>
</ResponseMessage>
ProfileTypeCode="TVL" ProfileName="TestProfile_2014-11-17_14:41:52_ftY" ProfileNameModifyIndicator="Y"
DomainID="A5CE" ProfileStatusCode="AC"/>
<Traveler>
</Traveler>
AssociationName="TestAssociation_2014-11-17_14:41:52_5hh" ClientContextCode=“TMP" ProfileTypeCode="TVL"
CreateDateTime="2014-11-17T13:41:52.67Z" UpdateDateTime="2014-11-17T13:41:52.67Z" Shared="Y"/>
</Profile>
Validators
The purpose of Validators is to run simple user-defined validations against the profile payload. These
validations are executed only when they are part of an Association attached to profile. A Validator can be
used, for example, to ensure data consistency if data is coming from several sources, e.g. a GUI and some
automated tools. No matter from which source the data comes, it will be validated against the same set
of rules.
Examples of validations are:
- Validating content vs. PNR requirements (e.g. max length of fields)

- Validating min/max number of elements (e.g. per corporate policy)
- Validating specific fields with restricted format (e.g. date, serial numbers, etc.)
The following Validator Rules are available:
- Restriction: This is a simple rule that defines if the given element is required or not allowed.
- OccurenceRule: This is a more flexible rule that defines minimum and/or maximum number
of occurrences of a given element.
- RegexpRule: This rule validates the content of an element/attribute using regular
expressions.
- ListRule: This rule validates the content of an element/attribute against the list of allowed
values.
- Predefined rule: (see below for detailed description).
A Validator consists of a number of Validator Rules. Each rule contains two elements
1. XPath that denotes an element of XML. It can point to a subject area or an attribute.
2. Set of rules that apply to that element.
NOTE: For current Validator supported elements, attributes, and number of instances
allowed of these fields, please refer to the schema xml files located on the Sabre Dev Studio.
Sample Validator
A Validator is created with a ProfileCreate request. Below is a sample request to create a Validator:
<Sabre_OTA_ProfileCreateRQ Target="Production" TimeStamp="2012-01-23T09:10:08.535Z" Version="0.0"

xsi:schemaLocation="http://www.sabre.com/eps/schemas \schemas\Sabre_OTA_ProfileCreateRQ.xsd"
<Validator DomainID="A2FE" ValidatorID="*" ClientCode="TN" ClientContextCode=“TMP"
ProfileTypeCode="TVL"
ValidatorDescription="TelephoneRequired">
<ValidatorRule XPath="//Profile/Traveler/Customer/Telephone">
<Restriction>RQ</Restriction>
</ValidatorRule>
</Validator>
This validator requires at least one Telephone to be included in a traveler profile. The detailed description
is below:
ClientCode, DomainID and The same as in all other requests.

ClientContextCode
ProfileTypeCode The Profile type for which this validator is meant. In this case TVL = Traveler
ValidatorName A name of the validator
Xpath XPath expression that specifies the XML element/attribute to be validated. It

should always start with //Profile. XPath 2.0 is supported.
Restriction The restriction rule. RQ means ‘Required’
The following steps are required to use this validator:
1. Create an Association object that contains this Validator (refer to the Associations section)
2. Create a Traveler profile that has this Association attached.
If this profile doesn’t have a Telephone, an error will be returned and the profile won’t be
created.
Note: when a Validator has multiple elements and/or rules or when there are multiple Validators defined
in an Association, only the first validation error is returned.
Sample Validator with multiple rules
One Validator can validate multiple elements. Each element can be validated by multiple rules. Below is
an example of a Validator that is checking the following rules:
1. Given name is required;

2. Given name must start with an upper case letter;
3. One Home telephone, and no more than one, is required.

<Validator DomainID="A2FE" ValidatorID="*" ClientCode="TN" ClientContextCode="ABS"
ProfileTypeCode="TVL" ValidatorName="Validator Example">
<ValidatorRule XPath="//Profile/Traveler/Customer/PersonName/GivenName">
<RegexpRule Regexp="[A-Z]{1}.*"/>
</ValidatorRule>
<ValidatorRule XPath="//Profile/Traveler/Customer/Telephone[@LocationTypeCode='HOM']">
<OccurrenceRule MinOcc="1" MaxOcc="1"/>
</ValidatorRule>
</Validator>
Validator Rules descriptions
In the following sections all possible validation rules are described.
Restriction
Defines if a specified element is required, not allowed or optional.

</ValidatorRule>
Occurrence Rule
Occurrence gives more flexibility in controlling the allowed number of occurrences of a specified element.
It can define the minimum and maximum number of occurrences.

</ValidatorRule>
In one Validator rule there can be either one Restriction or one Occurrence Rule defined (or none). Both
of them cannot be present at the same time.
Regexp Rule
Regexp rule defines a regular expression that the content is validated against. There can be up to 5
different RegexpRules for one element (XPath).
<RegexpRule Regexp="[A-Z]{1}.*"/>
</ValidatorRule>
List Rule
The list rule provides a possibility to define a custom enumeration restriction for particular
element/attribute. If a field is validated by synch rule, the ListRule shall include all supported and allowed
values for that field.
<ValidatorRule XPath="//Profile/Traveler/Customer/PersonName/NamePrefix ">

<!—AllowedValue element is dedicated to store the single supported valued -->
<ListRule>
<AllowedValue>Mrs</AllowedValue>
<AllowedValue>Ms</AllowedValue>
<AllowedValue>Dr</AllowedValue>
</ListRule>
</ValidatorRule>
The list rule validator can be also used to narrow the list of values allowed by the Sabre Profiles control
data.
Pre-defined Rule
The Predefined rule is an extension point that allows implementing new Validator functionality in the
future without introducing changes to the schema. Currently, one validation is implemented as a
Predefined Rule. It is called DATE_FORMAT and can be used to validate a date format. This could be
useful if date information is stored in fields that are designed to store general information. An example
would be custom defined data or general-purpose fields like InformationText.
Below is an example for CustomDefinedData:
<ValidatorRule
XPath="//Profile/Traveler/TPA_Extensions/CustomDefinedData[@CustomFieldCode='ENR']">
<PredefinedRule ValidatorCode="DATE_FORMAT">

<RuleParam Name="dateFormat" Value="MMMyyyy"/>
</PredefinedRule>
</ValidatorRule>
Metadata
Metadata provides a way to define the scope of profile data. This can be used in a GUI to define which
portions of profile data an end user should be able to view or edit. This way, the GUI administrator can
define specifics sets of data in different association objects, and different profiles can be associated to
those objects, i.e. you can have Association object 1 with only a Business Address displayed in the GUI,
and Association object 2 can be configured to only have Home Addresses.
Contrary to Validators, Sabre Profile Services are not processing Metadata in any way– it just stores and
retrieves this data.
Metadata can be associated to a profile through the Association object. Each metadata object is designed
for a specified profile type, e.g. Traveler.
NOTE: For current Metadata supported elements, attributes, and number of instances allowed of these
The example shows Metadata that defines the following scope of profile data:
- Person Name
- One home telephone
- Two business telephones

<Metadata ClientCode="TN" ClientContextCode=“TMP" DomainID="A2FE" MetadataID="*"

MetadataName="Sample traveler" ProfileTypeCode="TVL">
<MetaTag XPath="//Profile/Traveler/Customer/PersonName" Accessibility="RW"

NmbrOfElements="1"/>
<MetaTag XPath="//Profile/Traveler/Customer/Telephone[@LocationTypeCode='HOM']"
Accessibility="RW"
NmbrOfElements="1"/>
<MetaTag XPath="//Profile/Traveler/Customer/Telephone[@LocationTypeCode='BUS']"
Accessibility="RW"
NmbrOfElements="2" DefaultValue="+1 555 555" />
</Metadata>
ClientCode, DomainID and The same as in other requests.

ClientContextCode
ProfileTypeCode The Profile type for which this Metadata is intended. In this case TVL =
Traveler
MetadataName A name for the metadata
Xpath XPath expression that specifies the XML element/attribute. It should always
start with //Profile. XPath 2.0 is supported.
Accessibility Access level for the given element:
• RW = read/write
• RO = read only
• NA = not available
NmbrOfElements Number of instances of the element to be presented (optional)
DefaultValue The default value for the given element (optional)
Bulk Read Services 17
Bulk Read Service Overview
The Sabre_OTA_ProfileBulkRead service is designed to retrieve multiple objects with a single web service
call, and can be used as an alternative to multiple individual calls to Sabre_OTA_ProfileRead service
Different types of objects can be retrieved together. Up to 10 Profiles, 10 Filters, 500 Formats, 10 Metadata
objects, 10 Validators and 10 Association objects can be retrieved all at once.
NOTE: For current BulkRead supported elements, attributes, and number of instances allowed of these
Bulk Read – Profiles – Request Message
The Request message for Bulk Read of Profiles can contain up to 10 <Profile> elements that identify
which Profiles are to be retrieved. Profiles of any type can be read, and different types can be mixed in
the same request. A sample request to retrieve two Profiles is shown below:

<Profiles>
</Identity>
</Profile>
<Profile ProfileTypeCode="OPX">
</Identity>
</Profile>
</Profiles>
Notes:
• By default, the service returns the entire content of each Profile (all subject areas except the
External Subject Area) – same as ProfileRead service.
• User can control which subject areas are returned by using <PartialReadSubjectAreas> or
<IgnoreReadSubjectAreas> elements. Different subject areas can be chosen for each Profile. See
Error! Reference source not found. chapter for details.
• Profiles can be read based on their:
o UniqueID
o Login (if this option is enabled for a domain)
o Login and password (if this option is enabled for a domain)
o Auxiliary ID
Additional options:
• ReturnPaymentCardToken option can be used to request credit card numbers to be tokenized.

When /Sabre_OTA_ProfileBulkReadRQ/@ReturnPaymentCardToken="Y" is included in the
request, a tokenized credit card number is returned for each PaymentForm/PaymentCard element
in the response – under an additional attribute @CardToken. This option does not affect returning
any other credit card details, so returned information may also contain credit card numbers in
cleartext if the user has CCVIEW or OSCCVIEW security attribute assigned.
• IgnoreStatusCheck can be used to read Profiles that have ProfileStatusCode that typically prevents
them from being returned (for example Profiles that have been deleted but not purged yet). To use
this option, send /Sabre_OTA_ProfileBulkReadRQ/@IgnoreStatusCheck="Y" in the request.
• ReturnAssociatedProfileStatus can be used to retrieve information about the Profile status of each
Profile that is associated to Profiles being read. Additional attributes @AssocProfileStatusCode and
@AssocProfilePurgeNoDays will be returned for each AssociatedProfiles element in the response.
You can enable this option by sending the following flag in the request:
/Sabre_OTA_ProfileBulkReadRQ/@ReturnAssociatedProfileStatus="Y".
• ReturnOnlyActiveAssociatedProfiles can be used to hide information about any inactive Profiles
associated to the Profiles being read (AssociatedProfiles element in the response). Inactive Profiles
are defined as Profiles that have @ProfileStatusCode="DL" and/or have @PurgeNoDays set. Send
/Sabre_OTA_ProfileBulkReadRQ/@ReturnOnlyActiveAssociatedProfiles="Y" in the request to
enable this option. Caution is advised when using this option with a subsequent ProfileUpdate call
in mind – sending a ProfileUpdate request based on a payload containing partial information will
cause missing information to be removed from the Profile.
Bulk Read – Profiles – Response Message
If all Profiles are successfully retrieved, the response contains the contents of the requested Profiles. A
sample response is shown below:
<Sabre_OTA_ProfileBulkReadRS Version="6.28" xmlns="http://www.sabre.com/eps/schemas">

<ResponseMessage>
<Success/>
</ResponseMessage>
<Profiles>
PrimaryLanguageIDCode="EN">
ProfileName="PRF20030220130016229" ProfileNameModifyIndicator="Y" ProfileDescription="Sample Full Traveler
Profile 1" DomainID="A2FE" ProfileStatusCode="AC" ProfilePurgeNoDays="700">
<Login LoginID="PRF19971228130016245" PasswordHash="orchprf" IsHashed="N">
<SecurityInfo SecurityQuestionCode="001" SecurityAnswerHash="asd"/>
</Login>
<ProfileSubType SubTypeCode="WEB"/>
</TPA_Identity>
<Traveler>
<Customer CountryOfResidence="US" BirthDate="1967-08-13" MaritalStatusCode="M" GenderCode="M"
AgeRange="30-45" RedressNumber="40" KnownTravelerNumber="6473" ChildIndicator="Y" SeniorIndicator="Y"
CitizenCountryCode="US" CurrencyCode="USD" LapInfantIndicator="N" IsSubjectToSecureFlightRule="N"
NationalityCode="US">
<PersonName LanguageIDCode="EN" VIT_LineType="A" VIT_SecondaryQualifier="F" VIT_OrderNmbr="1"
DisplaySequenceNo="1" OrderSequenceNo="1" InformationText="info">
<SurName>SMITH</SurName>
</PersonName>
</Customer>
</Traveler>
</Profile>
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP" UniqueID="101370096" ProfileTypeCode="OPX"
ProfileNameModifyIndicator="Y" ProfileDescription="SC96528OPX" DomainID="A2FE" ProfileStatusCode="AC"/>
<OperationalProfile>
<Address LocationTypeCode="AGY" AddressUsageTypeCode="BUS" Attention="Attnb" DisplaySequenceNo="7"
OrderSequenceNo="5" NewAddress="N">
<AddressLine>Downing St.</AddressLine>
<CityName>London</CityName>
<PostalCd>12345</PostalCd>
<StateCode>21</StateCode>
<CountryCode>UK</CountryCode>
<StreetNmbr>13</StreetNmbr>
<BldgRoom FloorWing="13sd"/>
</Address>
</OperationalProfile>
</Profile>
</Profiles>
</Sabre_OTA_ProfileBulkReadRS>
Bulk Read Error Scenarios
Error response
An error response is returned if Bulk Read operation fails completely. A sample error message is shown
below:
<Sabre_OTA_ProfileBulkReadRS Target="Production" TimeStamp="2016-12-16T12:40:02.254Z" Version="6.28"

<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode="338">NPDCTNT20161216124002::Invalid XML (not compliant with Schema): In
content of element <Identity>: Empty content is not allowed. The following elements would be valid here, all in
namespace http://www.sabre.com/eps/schemas: Login, AuxiliaryID, UniqueID. One or more validation errors
were reported</ErrorMessage>
</Errors>
</ResponseMessage>
Warning response
In case the problem applies to one or more of the objects being retrieved, rather than to the whole
transaction, the problem information is returned in the form of warnings. If a problem occurs only for some
of the objects, but some are read successfully, the response will contain both the warnings and the content
of successfully retrieved objects.
Returned <WarningMessage> elements contain attributes that help identify objects from the request that
each warning message applies to, such as @DomainID and – in case of a Profile – @UniqueID.
Sample response in the case where retrieval of all Profiles failed:
<Sabre_OTA_ProfileBulkReadRS TimeStamp="2016-12-16T11:52:15.551Z" Target="Production" Version="6.28"

<ResponseMessage>
<Warnings>
<WarningMessage WarningCode="298" DomainID="A2FE" UniqueID="1160045043">R::NPPPTN-
INT1T20161216124754SR::No profile is found which match your selection criteria (UniqueID = 1160045043,
ClientCode = TN, ClientContextCode = ABC, DomainID = A2FE, ProfileTypeCode = TVL, LoginID =
null)</WarningMessage>
INT1T20161216124754SR::Branch access is not allowed</WarningMessage>
</Warnings>
</ResponseMessage>
Sample response in the case where retrieval of one of the Profiles failed, but the other was retrieved
successfully:

<ResponseMessage>
<Warnings>
INT2T20161216125543SR::No profile is found which match your selection criteria (UniqueID = 1160045043,
ClientCode = TN, ClientContextCode = ABC, DomainID = A2FE, ProfileTypeCode = TVL, LoginID =
null)</WarningMessage>
</Warnings>
</ResponseMessage>
<Profiles>
ProfileName="TestProfile_2016-12-16_11:52:15.535_0Xau" ProfileNameModifyIndicator="Y" DomainID="A2FE"
<Traveler>
<Customer>
<PersonName LanguageIDCode="EN-US">
<GivenName>ELTON</GivenName>
<SurName>SMITH</SurName>
</PersonName>
</Customer>
</Traveler>
</Profile>
</Profiles>
Bulk Read – Associations – Request Message
The Request message for Bulk Read of Associations (Templates) can contain up to 10 <Association>
elements that identify which Association IDs are to be retrieved. A sample request to retrieve two
Association objects is shown below:

<Associations>
</Associations>
Bulk Read – Associations – Response Message
If the Associations are successfully retrieved, the response contains the contents of the requested
Associations. A sample response is shown below:

<ResponseMessage>
<Success/>
</ResponseMessage>
<Associations>
AssociationName="TestAssociation_2013-06-27_10:56:36_s0C_1" ClientContextCode=“TMP"
ProfileTypeCode="TVL" CreateDateTime="2013-06-27T09:03:36.139Z" UpdateDateTime="2013-06-
27T09:03:36.139Z">
<AssociatedProfiles AssocUniqueID="102052170" AssocProfileTypeCode="TVL"
AssocProfileName="TestProfile_2013-06-27_10:56:36_AAe" DisplaySequenceNo="1" OrderSequenceNo="2"
DomainID="A2FE" ClientCode="TN" ClientContextCode=“TMP" ProfileRelationTypeCode="AL" AssocFiltersInd="N"/>
<AssociatedFilters DomainID="A2FE" FilterID="541577" SequenceNo="2" DisplaySequenceNo="1"
FilterName="TestFilter_2013-06-27_10:56:36_JbZ"/>
<AssociatedFormats DomainID="A2FE" FormatID="518249" FormatName="TestFormat_2013-06-
27_10:56:36_4L3" DisplaySequenceNo="1" SequenceNo="1" CreateDateTime="2013-06-27T08:56:52.56Z"
UpdateDateTime="2013-06-27T08:56:52.56Z"/>
<AssociatedMetadata DomainID="A2FE" ClientCode="TN" MetadataID="154755" ClientContextCode=“TMP"
ProfileTypeCode="TVL" MetadataName="TestMetadata_2013-06-27_10:56:36_ygR" OrderSequenceNo="1"
DisplaySequenceNo="1"/>
<AssociatedValidators DomainID="A2FE" ValidatorID="67375" ClientCode="TN" ClientContextCode=“TMP"
ProfileTypeCode="TVL" ValidatorName="TestValidator_2013-06-27_10:56:36_bQI" OrderSequenceNo="1"
DisplaySequenceNo="1"/>
</Association>
AssociationName="TestAssociation_2013-06-27_10:56:36_s0C_2" ClientContextCode=“TMP"
ProfileTypeCode="TVL" CreateDateTime="2013-06-27T09:03:53.667Z" UpdateDateTime="2013-06-
27T09:03:53.667Z">
</Association>
</Associations>
Bulk Read – Formats – Request Message
The Request message for Bulk Read of Formats can contain up to 10 <Format> elements that identify
which Formats are to be retrieved. A sample request to retrieve two Formats is shown below:

<Formats>
<Format FormatID="215458" DomainID="A2FE" ClientCode="TN"/>
<Format FormatID="215471" DomainID="A2FE" ClientCode="TN"/>
</Formats>
Bulk Read – Formats – Response Message
If all Formats are successfully retrieved, the response contains the contents of the requested Formats. A
<ResponseMessage>
<Success/>
</ResponseMessage>
<Formats>
<Format FormatID="215458" DomainID="A2FE" FormatName="FMT2" FormatType="5" FormatData="2"
CreateDateTime="2010-07-21T10:17:24.697Z" UpdateDateTime="2010-07-21T10:17:24.697Z"
FormatStatusCode="AC" ClientCode="TN" ClientContextCode=“TMP"/>
<Format FormatID="215471" DomainID="A2FE" FormatName="FMT1" FormatType="5" FormatData="1"
CreateDateTime="2010-07-21T11:05:52.294Z" UpdateDateTime="2010-07-21T11:05:52.294Z"
FormatStatusCode="AC" ClientCode="TN" ClientContextCode=“TMP"/>
</Formats>
Bulk Read – Filters – Request Message
The Request message for Bulk Read of Filters can contain up to 10<Filter> elements that identify which
Filters are to be retrieved. A sample request to retrieve two Filters is shown below:

<Filters>
<Filter ClientCode="TN" DomainID="A2FE" FilterID="389498"/>
<Filter ClientCode="TN" DomainID="A2FE" FilterID="389499"/>
</Filters>
Bulk Read – Filters – Response Message
If all Filters are successfully retrieved, the response contains the contents of the requested Filters. A

<ResponseMessage>
<Success/>
</ResponseMessage>
<Filters>
<Filter FilterID="389498" DomainID="A2FE" ClientCode="TN" ClientContextCode=“TMP"
FilterName="FilterName4" FilterDescription="FDesc" CreateDateTime="2011-09-19T08:58:22.24Z"
UpdateDateTime="2011-09-19T08:58:22.24Z" FilterStatusCode="AC" FilterTypeCode="AGT">
<Profile>
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP" UniqueID="*" ProfileTypeCode="AGT"
DomainID="A2FE"/>
<TravelAgent>
<AgentName GivenName="dggg" SurName="sff" OrderSequenceNo="1"/>
</TravelAgent>
</Profile>
</Filter>
<Filter FilterID="389499" DomainID="A2FE" ClientCode="TN" ClientContextCode=“TMP"
FilterName="AssociatedProfileFilter" FilterDescription="FDesc" CreateDateTime="2011-09-19T09:42:35.825Z"
UpdateDateTime="2011-09-19T09:42:35.825Z" FilterStatusCode="AC" FilterTypeCode="TVL">
<Profile>
ProfileName="TNTraveler6" ProfileDescription="ProfDesc" DomainID="A2FE"/>
<Traveler>
<Customer>
<NamePrefix>XXX</NamePrefix>
<GivenName>XXX</GivenName>
<MiddleName>XXX</MiddleName>
<SurName>XXX</SurName>
<NameSuffix>XX</NameSuffix>
</PersonName>
</Customer>
</Traveler>
</Profile>
</Filter>
</Filters>
Bulk Read – Metadata objects – Request Message
The Request message for Bulk Read of Metadata objects can contain up to 10 <Metadata> elements that
identify which objects are to be retrieved. A sample request to retrieve two Metadata objects is shown
below:

<Metadatas>
<Metadata MetadataID="1625177" ClientCode="TN" DomainID="A2FE"/>
<Metadata MetadataID="1625179" ClientCode="TN" DomainID="A2FE"/>
</Metadatas>
Bulk Read – Metadata Objects – Response Message
If Metadata objects are successfully retrieved, the response contains the contents of the requested
Metadata objects. A sample response is shown below:

<ResponseMessage>
<Success/>
</ResponseMessage>
<Metadatas>
<Metadata DomainID="A2FE" ClientCode="TN" MetadataID="1625177" ClientContextCode=“TMP"
ProfileTypeCode="TVL" MetadataName="TestMetadata_2016-12-16_14:28:14.649_rJjo" CreateDateTime="2016-
12-16T13:28:21.291Z" UpdateDateTime="2016-12-16T13:28:21.291Z">
<MetaTag XPath="//Profile/Traveler/Customer/PersonName/GivenName" Accessibility="RW"
DefaultValue="Value">
<AdditionalData Version="VERSION 3.0">Data_1</AdditionalData>
</MetaTag>
</Metadata>
<Metadata DomainID="A2FE" ClientCode="TN" MetadataID="1625179" ClientContextCode=“TMP"
ProfileTypeCode="TVL" MetadataName="TestMetadata_2016-12-16_14:28:14.649_rJjo" CreateDateTime="2016-
12-16T13:28:32.343Z" UpdateDateTime="2016-12-16T13:28:32.343Z">
<MetaTag XPath="//Profile/Traveler/Customer/PersonName/SurName" Accessibility="RW"
DefaultValue="Value">
<AdditionalData Version="VERSION 3.0">Data_2</AdditionalData>
</MetaTag>
</Metadata>
</Metadatas>
Bulk Read – Validators – Request Message
The Request message for Bulk Read of Validators can contain up to 10 <Validator> elements that identify
which Validators are to be retrieved. A sample request to retrieve two Validators is shown below:

<Validators>
<Validator ValidatorID="2172685" ClientCode="TN" DomainID="A2FE"/>
<Validator ValidatorID="2172687" ClientCode="TN" DomainID="A2FE"/>
</Validators>
Bulk Read – Validators – Response Message
If Validators are successfully retrieved, the response contains the contents of the requested Validators.
A sample response is shown below:

<ResponseMessage>
<Success/>
</ResponseMessage>
<Validators>
<Validator DomainID="A2FE" ValidatorID="2172685" ClientCode="TN" ClientContextCode=“TMP"
ProfileTypeCode="TVL" ValidatorName="TestValidator_2016-12-16_14:33:24.915_oGfT"
NonBlockingValidationInd="Y" CreateDateTime="2016-12-16T13:33:54.189Z" UpdateDateTime="2016-12-
16T13:33:54.189Z">
</ValidatorRule>
</Validator>
<Validator DomainID="A2FE" ValidatorID="2172687" ClientCode="TN" ClientContextCode=“TMP"
ProfileTypeCode="TVL" ValidatorName="TestValidator_2016-12-16_14:33:24.915_oGfT"
NonBlockingValidationInd="N" CreateDateTime="2016-12-16T13:33:59.897Z" UpdateDateTime="2016-12-
16T13:33:59.897Z">
<ValidatorRule XPath="//Profile/Traveler/Customer/PersonName/SurName">
</ValidatorRule>
</Validator>
</Validators>
Profile Data Service 18
Overview
Custom Defined Data allows a customer to define their own data based on value pairs of a code and
description of the data and the actual data value stored within the profile. This feature allows customers
to expand the data model to accommodate for Profile data fields that do not currently exist in the Sabre
Profiles system.
For example, if a customer needs to store information in a profile about the preferred restaurants for his
travelers, he can set up a custom defined data field, using an existing code, or by defining his own code
(i.e. RST) and then adding a description for the field (i.e. PREFERRED RESTAURANTS) and associating
values (i.e. “BestFood ABC restaurant”). To do this we use the Data Services.
Data Service can be also used to define custom Preference Codes in addition to the globally available
control table values. A customer can create their own Airline Seat Preference Codes and Hotel Room Type
Preference Codes by using the Dictionary Operations of Data Service.
The Data Service can be used to carry out the following actions:
• Retrieve a list of Custom Field Codes for the given DomainID. The list has room for up to 250
Custom Field Codes.
• Create up to 50 new Custom Field Codes in a single request.
• Create up to 250 Preference Codes in a single request.
• Read, Update, Delete and Copy Preference Codes.
The Custom Field Code is a part of Custom Defined Data which can be added to any profile regardless of
the profile type.
NOTE: For current Profile Data Service supported elements, attributes, and number of instances allowed
of these fields, please refer to the schema xml files located on Sabre Dev Studio.
Sample Retrieve Custom Field Codes XML Data Service

Request
To retrieve a list of Custom Field Codes, the user must issue the Sabre_OTA_ProfileDataSrvRQ request
against the Sabre Profiles EPS_EXT_ProfileDataSrvService. The sample request is shown below:
<Sabre_OTA_ProfileDataSrvRQ Version="1.0" xmlns="http://www.sabre.com/eps/schemas"

<RetrieveCustomFieldCodes DomainID="A5BE" ClientCode="TN" ClientContextCode=“TMP”/>
</Sabre_OTA_ProfileDataSrvRQ>
All the attributes of <RetrieveCustomFieldCodes> are mandatory. The Custom Field Codes are pulled
from the Sabre Profiles database based on a value of DomainID.
A sample ‘Retrieve Custom Field Codes’ XML response is shown below:
<Sabre_OTA_ProfileDataSrvRS
<ResponseMessage>
<Success />
</ResponseMessage>
<RetrieveCustomFieldCodes ClientCode="TN" ClientContextCode=“TMP” DomainID="A5BE">
<CustomFieldCode>OOO</CustomFieldCode>
<CustomFieldCode>OTH</CustomFieldCode>
</RetrieveCustomFieldCodes>
</Sabre_OTA_ProfileDataSrvRS>
Sample Create Custom Field Codes XML Data Service

Request
To create multiple CustomFieldCodes, the user must issue the ProfileDataSrvRQ using the Sabre Profiles
EPS_EXT_ProfileDataSrvService. A sample request has been shown below:
<Sabre_OTA_ProfileDataSrvRQ Version="1.0" xmlns="http://www.sabre.com/eps/schemas"

<CreateCustomFieldCode>
<CategoryCode CustomFieldCode="XXX" CustomFieldCodeDescription="Desc1"
CustomFieldDataType="Data Type" DomainID="A5BE" CustomFieldMinSize="1" CustomFieldMaxSize="10" />
<CategoryCode CustomFieldCode="YYY" CustomFieldCodeDescription="Desc2" CustomFieldDataType="Data Type"
DomainID="A5BE" CustomFieldMinSize="1" CustomFieldMaxSize="10" />
</CreateCustomFieldCode>
A sample ‘Create Custom Field Code’ XML response is structured as follows:
<Sabre_OTA_ProfileDataSrvRS
xmlns=http://www.sabre.com/eps/schemas TimeStamp="2013-10-07T09:27:43.646Z" Version="6.14">
<ResponseMessage>
<Success />
</ResponseMessage>
<CreateCustomFieldCode>
<CategoryCode CustomFieldCode="XXX" DomainID="A5BE" />
<CategoryCode CustomFieldCode="YYY" DomainID="A5BE" />
</CreateCustomFieldCode>
Note: The added values will only be available for the DomainID (PCC) for in which they are defined, and
for any others who are branched to this DomainID (PCC) via Branch Access. All other customers will only
have access to the Global Dictionary control table values.
Note: For current Profile Data Service supported elements, attributes, and number of instances allowed
of these fields, please refer to the schema XML files located on the Sabre Dev Studio.
Sample Create Dictionary XML Data Service Request
A Dictionary with custom Preference Codes can be created only once for a given Client Code, Client
Context Code, and DomainID. Once a Dictionary is created, its Codes can be modified, but it is not
possible to delete a Dictionary.
To create a Dictionary, a valid Name in the <Dictionary Identity> section must be provided. There are two
possible Dictionary Names that can be used: “AirlineSeatPref” and “HotelRoomTypePref”.
Effective Date and Discontinue Date attributes define the time frame when the Dictionary Codes are
active.
All the attributes of the <Dictionary Identity> section is mandatory. Code is the only required attribute of
the <Dictionary Entry> section; other attributes are optional.
A sample Create Dictionary request has been shown below:
<Sabre_OTA_ProfileDataSrvRQ TimeStamp="2001-12-17T09:30:47Z" Version="a" Target="Production"

xsi:schemaLocation="http://www.sabre.com/eps/schemas Sabre_OTA_ProfileDataSrvRQ.xsd"
<DictionaryOperation>
<CreateDictionary>
<DictionaryIdentity Name="AirlineSeatPref" DomainID="A2FE" ClientCode="TN"></DictionaryIdentity>
<DictionaryEntry Code="H"></DictionaryEntry>
<DictionaryEntry Code="B00H" Description="DESC1"></DictionaryEntry>
<DictionaryEntry Code="YYTR" EffectiveDate="2010-05-05"></DictionaryEntry>
<DictionaryEntry Code="NBUY" DiscontinueDate="2010-09-09"></DictionaryEntry>
<DictionaryEntry Code="AHKL" Description="DESC1" EffectiveDate="2010-05-05" DiscontinueDate="2010-09-
09"></DictionaryEntry>
</CreateDictionary>
</DictionaryOperation>
A sample Create Dictionary response is structured as follows:
<Sabre_OTA_ProfileDataSrvRS TimeStamp="2010-08-05T10:01:08.863Z" Version="4.3"

<ResponseMessage>
<Success/>
</ResponseMessage>
Note: If Effective Date is not provided in the request, it is set to the current date by the system. If
Discontinue Date is not provided in the request, it is set to the 9999-12-31 date by the Sabre Profiles
system.
Creating more than one of the same custom Preference Codes in the Create Dictionary request is not
permitted. If more than one of the same Codes exists in the request, the following error message is
returned:

<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode="123"> SVC:: Duplicate dictionary code=A found</ErrorMessage>
</Errors>
</ResponseMessage>
Effective Date and Discontinue Date specified in the request cannot be the same. There must be at least
one-day difference between Effective and Discontinue Date. The Discontinue Date cannot be a date in
the past in the Create Dictionary request. In both cases the following error message is returned:

<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode="123">SVC:: Invalid date range for Codes [H0GG, HO6]</ErrorMessage>
</Errors>
</ResponseMessage>
Sample Read Dictionary XML Data Service Request
To retrieve custom Preference Codes a user must issue Sabre_OTA_ProfileDataSrvRQ against the Sabre
Profiles EPS_EXT_ProfileDataSrvService. The Read Dictionary service allows reading all active and inactive
Custom Preference Codes which exist in a Dictionary. A sample Read Dictionary request has been shown
below:

<ReadDictionary Name="AirlineSeatPref" DomainID="A2FE" ClientCode="TN"/>
A sample Read Dictionary response is structured as follows:
<ResponseMessage>
<Success/>
</ResponseMessage>
<ReadDictionaryData>
<DictionaryIdentity Name="AirlineSeatPref" DomainID="A2FE" ClientCode="TN"/>
<DictionaryEntry Code="H" EffectiveDate="2010-08-05" DiscontinueDate="9999-12-31"/>
<DictionaryEntry Code="B00H" Description="DESC1" EffectiveDate="2010-08-05" DiscontinueDate="9999-12-
31"/>
<DictionaryEntry Code="YYTR" EffectiveDate="2010-05-05" DiscontinueDate="9999-12-31"/>
<DictionaryEntry Code="NBUY" EffectiveDate="2010-08-05" DiscontinueDate="2010-09-09"/>
09"/>
</ReadDictionaryData>
Sample Update Dictionary XML Data Service Request
The Full Update Dictionary operation allows replacing all the exiting Preference Codes in the Dictionary
with different Codes. All the Preference Codes in the existing Dictionary are deactivated by the Sabre
Profiles system and the Preference Codes specified in the Full Update request are added to the
Dictionary. The Sabre Profiles system deactivates all the Preference Codes in the Dictionary by setting the
Discontinue Date to a past date.
of these fields, please refer to the schema XML files located on the Sabre Dev Studio.
A sample Full update Dictionary request is shown below:

<UpdateDictionary>
<FullUpdate>
<DictionaryIdentity ClientCode="TN" DomainID="A2FE"
Name="AirlineSeatPref"></DictionaryIdentity>
<DictionaryEntry Code="HYTG" EffectiveDate="2010-09-09"
DiscontinueDate="2010-09-10"></DictionaryEntry>
<DictionaryEntry Code="B6" EffectiveDate="2010-09-09" DiscontinueDate="2010-09-12"></DictionaryEntry>
<DictionaryEntry Code="BBHY" EffectiveDate="2010-09-09" DiscontinueDate="2010-09-12"></DictionaryEntry>
<DictionaryEntry Code="AVY" EffectiveDate="2010-09-09" DiscontinueDate="2010-09-12"></DictionaryEntry>
<DictionaryEntry Code="BNNN" EffectiveDate="2010-09-09" DiscontinueDate="2010-09-12"></DictionaryEntry>
</FullUpdate>
</UpdateDictionary>
The Partial Update Dictionary operation allows a user to add, delete, and modify existing custom
Preference Codes in the Dictionary.
A customer can add up to 250 new custom Preference Codes to the existing Dictionary with the following
sample request:

<UpdateDictionary>
<PartialUpdate>
<Additions>
<Add Code="V1S" Description="desc" DiscontinueDate="2010-09-09" EffectiveDate="2010-07-07"></Add>
<Add Code="OBNA" DiscontinueDate="2010-09-09" EffectiveDate="2010-07-07"></Add>
</Additions>
</PartialUpdate>
</UpdateDictionary>
All attributes of the <DictionaryIdentity> are mandatory. Code is the only required attribute of the <Add>
section; the other attributes are optional.
Note: Rules for specifying Effective and Discontinue Date as well as unique Preference Codes in the
Partial Update Additions request are the same as in the Create Dictionary request.
The Partial Update Deletions operation allows a user to delete (deactivate) custom Preference Codes
from the existing Dictionary. To delete custom Preference Codes, they must be specified as in the
following sample request:

<UpdateDictionary>
<PartialUpdate>
Name="AirlineSeatPref"/>
<Deletions>
<Delete Code="V4"/>
<Delete Code="KJU7"/>
</Deletions>
</PartialUpdate>
</UpdateDictionary>
It is important to specify existing and active custom Preference Codes in the Partial Update Deletions
request.
If the Code does not exist in the Dictionary or is expired, an error message is returned. Each error
message contains an <Errors> section with an Error Code and a short description of the problem which
was encountered during the profile data service process.
For the Sabre Profiles Data Service, each Error message is prefixed with “SVC::”. An example error

<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode="123"> SVC:: Codes [X] may not exist or be inactive in AirlineSeatPref
Dictionary for DomainID=A2FE, ClientCode=TN</ErrorMessage>
</Errors>
</ResponseMessage>
The Partial Delete Dictionary operation sets the Discontinue Date of the Preference Codes specified in the
request to a past date. Codes are still available in the Read Dictionary response, but cannot be used any
longer in addition to the globally available Dictionary values.
The Partial Update Modifications operation makes it possible to modify the Description, Effective Date,
and Discontinue Date of the existing custom Preference Codes in the Dictionary.
To modify existing custom Preference Codes, the appropriate Codes and their attributes must be
specified in the request. A sample Partial Update Modification request has been shown below:

<UpdateDictionary>
<PartialUpdate>
<Modifications>
<Modify Code="H" Description="DESC2" EffectiveDate="2010-05-
18"></Modify>
<Modify Code="B00H" Description="DESC3" EffectiveDate="2010-05-20"></Modify>
</Modifications>
</PartialUpdate>
</UpdateDictionary>
Note: The Partial Update Modifications operation replaces values of all the attributes of the Preference
Codes specified in the request with the existing values in the Dictionary. If Code “H” has some value of
Discontinue Date specified in the Dictionary, but Discontinue Date is not provided in the Partial Update
Modification request for the same Code, the Sabre Profiles system will automatically set a 9999-12-31
value for Discontinue Date for this Preference Code.
Sample Delete Dictionary XML Data Service Request
Custom Preference Codes can be deleted from a Dictionary by Full Delete or Partial Delete operations.
Full Delete operation allows deleting all the existing Codes in the Dictionary while Partial Delete can be
used to delete up to 250 certain custom Codes. Deleting process deactivates custom Preference Codes in
the Dictionary by setting Discontinue Date to the past date. Inactive Codes are still available in the Read
Dictionary response, but cannot be used in addition to globally available Dictionary control data.
A sample Partial Delete Dictionary request looks as follows:

<DeleteDictionary>
<PartialDelete>
<DictionaryIdentity Name="AirlineSeatPref" ClientCode="TN" DomainID=”A2FE"/>
<DictionaryEntry Code="H"/>
<DictionaryEntry Code="B00H"/>
</PartialDelete>
</DeleteDictionary>
Codes “H” and “BOOH” have been deactivated in the AirlineSeatPref Dictionary. Discontinue Date of
these two Codes has been set to a date from the past. Below is the sample Read Dictionary response after
Partial Delete operation:

<ResponseMessage>
<Success/>
</ResponseMessage>
04"/>
09"/>
Preference Codes provided in the Partial Delete Dictionary request must exist and must be active. If the
Code does not exist in the Dictionary or is expired, an error message is returned. Each error message
contains an Errors section with an Error Code and a short description of the problem which was
encountered during the profile data service process.
For the Sabre Profiles Data Service, each Error message is prefixed with “SVC::”. An example error
message is shown below:,

<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode="135"> SVC:: Codes [X] may not exist or be inactive in AirlineSeatPref Dictionary
for DomainID=A2FE, ClientCode=TN</ErrorMessage>
</Errors>
</ResponseMessage>
A sample Full Delete Dictionary request is shown below:

<DeleteDictionary>
<FullDelete ClientCode="TN" DomainID="A2FE" Name="AirlineSeatPref"></FullDelete>
</DeleteDictionary>
The Sabre Profiles system sets Discontinue Date of all the existing custom Preference Codes to a past
date. A sample Read Dictionary response after a Full Delete operation is shown below.

<ResponseMessage>
<Success/>
</ResponseMessage>
04"/>
04"/>
Sample Copy Dictionary XML Data Service Request
Copy Dictionary operation allows a user to copy custom Preference Codes from one source Dictionary to
up to 50 destination Dictionaries. The Copy Dictionary operation is only allowed between branched
Domain IDs. Values of Client Code and Name attributes must be the same in the source and destination
Dictionaries. Only active Codes are copied from the Source Dictionary to the Destination Dictionaries.
Codes which are expired are not moved to the Destination Dictionaries.
of these fields, please refer to the schema xml files located on Sabre Dev Studio.
A sample Copy Dictionary request is shown below:

<CopyDictionary>
<SourceDictionary Name="AirlineSeatPref" DomainID="A2FE" ClientCode="TN" />
<DestinationDictionary Name="AirlineSeatPref" DomainID="A5CE" ClientCode="TN" />
<DestinationDictionary Name="AirlineSeatPref" DomainID="A5BE" ClientCode="TN" />
</CopyDictionary>
If all the custom Preference Codes are inactive in the source Dictionary, an error message is returned.
Each error message contains an <Errors> section with an Error Code and a short description of the
problem which was encountered during the profile data service process. For the Sabre Profiles Data
Service, each Error message is prefixed with “SVC::”. An example error message is shown below:

<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode="123"> SVC:: AirlineSeatPref Dictionary doesn't have active codes for
DomainID=A2FE, ClientCode=TN</ErrorMessage>
</Errors>
</ResponseMessage>
If the destination Dictionary already exists and contains custom Preference Codes, the following warning
message is returned:

<ResponseMessage>
<Warnings>
<WarningMessage WarningCode="138">Destination dictionary AirlineSeatPref already exists for
DomainID=A5CE, ClientCode=TN</WarningMessage>
</Warnings>
</ResponseMessage>
Data Service Error Response
When the Data Service operation cannot be performed, an error message is returned. Each error message
contains an <Errors> section with an Error Code and a short description of the problem which was
encountered during the profile data service process. For the Sabre Profiles Data Service, each Error
message is prefixed with “SVC::”. An example error message is shown below:
A sample Data Service error Response message:

<ResponseMessage>
<Errors>
<ErrorMessage ErrorCode=”123”>SVC:::Invalid XML (not compliant with Schema):
Validating DictionaryEntry/@Code: Value "RT00V" contravenes the maxLength facet "4" of the type
StringLength1to4</ErrorMessage>
</Errors>
</ResponseMessage>
Roles 19
Roles Overview
In Sabre Profiles, a Role defines a group of permissions assigned to a user via their AGT profile that are set
for a specific DomainID. Within the DomainID, several roles can be defined and subsequently stored in
the CUSTM_USER_RL table.
Roles Management
Roles Management is a separate set of services that allows individual permissions to be grouped into a
Role that controls the types of Profile-related functions a user can perform in a specified Domain/PCC.
For example, users require permissions to Create, Read, Update, or Delete objects such as Profiles,
Templates, Filters, Formats, etc.
Sabre owns the process to create, update, and delete Standard Roles and current permissions defined
under those Roles.
A user Role can be assigned to the AGENT profile which is auto-generated from the EPR during PCC
activation for Sabre Profiles. This role will allow certain functions to be performed within the Sabre
Profiles system. However, Role assignment is optional, and can also limit what a user can and cannot do
within the system.
In some situations, the absence of a designated Role can also signify a Super User, which grants a user
access to all Profile-related functions, except Roles Management functions.
The following table is a sample of User Roles that can be created.
Name of
STANDARD
Role Codes Role Description
Super User ADMINPPP can display Profiles, Filters, and Formats; can create, display, edit and
(Unrestricted delete Profiles and Filters; can move Profiles between Branch PCCs;
User) can create, display, edit and delete Associations (Templates), Filters
and Formats; can copy and move Associations (Templates) between
Branch PCCs; can assign Roles to Agents, can create, retrieve, read,
cancel, and delete Offline Search Jobs
Admin User RFMT, CRUDFLT, RTPL, can display Profiles, Filters, and Formats; can create, display, edit and
MVDOMNPRF, RASC, delete Profiles and Filters; can move Profiles between Branch PCCs
CRUDPRF, RVAL,
RMTD,
Name of
STANDARD
Role Codes Role Description
Regular User RFMT, CRUDFLT, RTPL, can display Profiles, Filters, and Formats; can create, read, edit and
MVDOMNPRF, RASC, delete Profiles and Filters; can move Profiles between Branch PCCs
CRUDPRF, RVAL,
RMTD
Restricted User RPRF, RFLT, RFMT, can display Profiles, Filters, Formats, and Associations (Templates)
RMDT, RVAL, RASC
• A set of Roles is retrieved from the Sabre Profiles database based on the DomainID from the user
request. Standard Roles are defined and available for all TN Domains.
• These Roles are collected in one request, which is sent to the external system (User Roles
Services)
• Based on the response from the external system, Sabre Profiles validates user permissions.
Roles management functionality is a separate set of services that allows grouping of individual
permissions into a “role” that controls what “profile related” function a user can or can’t do, i.e.
create, read, update, delete, for the different objects = Profiles, templates, filters, formats, etc.The Role is
assigned to the Agent Profile which is auto-generated by the Profiles System using the existing EPR within
the domain when that domain is activated for Sabre Profiles.
In the absence of a designated “role”, the Sabre Profiles GUI in Sabre Red Workspace allows a user access
to all profile related functions to Create, Update, Move and Delete Profiles, bbut not to Roles
Management functions or the ability to Create, Update, Move or Delete Templates (AssociationIDs).
To enable roles validation for Domain, administrator should send ProfileAdminRQ, which is shown below:
<Sabre_OTA_ProfileAdminRQxmlns="http://www.sabre.com/eps/schemas" Target="Production"
<ModifyDomainStatusStatusCode="AC" ClientCode="TN" ClientContextCode=“TMP” DomainID="ZXCV"
IgnoreAgentPermissionsCheck="N"/>
</Sabre_OTA_ProfileAdminRQ>
The attribute IgnoreAgentPermissionsCheck should be set to “N” for Roles and permissions validation on
the Agent Profile which is created from the agent’s EPR. If the value is set to “Y”, Roles services will be
disabled within the Domain. The default setting for this attribute is “N” which enables Roles validation
automatically when the Domain is activated to use Profiles Services.
Roles are divided into two groups: custom roles and standard roles. Standard Roles are the only roles
available for assignment to AGENT EPR Profiles at this time and the only ones used in the Sabre Profiles
GUI. Future development may fully support Custom Roles. The pre-defined Standard Roles exist for all
Domains and can be assigned to user by any user that contains the RolesManager or
RolesExternalManager permission. To have RolesManager or RolesExternalManager authorization, the
update will need to be requested via Agency eServices activation pages through your Sabre Account
Manager.
The AssociatedPermissions element has the following attributes: PermissionCode and ApplicationCode, of
which both are required. PermissionCode attribute specifies the set of actions that are allowed for the role.
The attribute ApplicationCode specifies for which application the role will work. List of permissions which
can be assigned to roles is below:
PermissionCode ApplicationCode Description of permission
CRUDPRF PPP ALL OPERATIONS ON PROFILES
DPRF PPP DELETE PROFILES
CFMT PPP CREATE FORMATS
UFMT PPP UPDATE FORMATS
DFMT PPP DELETE FORMATS
RFMT PPP READ FORMATS
CRUDFMT PPP ALL OPERATIONS ON FORMATS
ADMINPPP PPP ALL OPERATIONS ON SABRE PROFILESSYSTEM
UPRF PPP UPDATE PROFILE
RPRF PPP READ PROFILE
CFLT PPP CREATE FILTER
UFLT PPP UPDATE FILTER
RFLT PPP READ FILTER
DFLT PPP DELETE FILTER
CRUDFLT PPP ALL OPERATIONS ON FILTERS
CPRF PPP CREATE PROFILES
CASC PPP CREATE ASSOCIATION
CRUDASC PPP ALL OPERATIONS ON ASSOCIATION
MVDOMNPRF PPP MOVE DOMAIN PROFILES
DASC PPP DELETE ASSOCIATION
RASC PPP READ ASSOCIATION
UASC PPP UPDATE ASSOCIATION
CRUDVAL PPP ALL OPERATIONS ON VALIDATOR
CVAL PPP CREATE PROFILE VALIDATOR
DVAL PPP DELETE VALIDATOR
RVAL PPP READ VALIDATOR
UVAL PPP UPDATE VALIDATOR
MVDOMNVAL PPP MOVE DOMAIN VALIDATOR
CPDOMNVAL PPP COPY DOMAIN VALIDATOR
CRUDMTD PPP ALL OPERATIONS ON METADATA
CMTD PPP CREATE METADATA
DMTD PPP DELETE METADATA
RMTD PPP READ METADATA
UMTD PPP UPDATE METADATA
CPDOMNMTD PPP COPY DOMAIN METADATA
MVDOMNMTD PPP MOVE DOMAIN METADATA
Below you can see a mapping of Sabre Profiles actions to Roles privileges:
Action Privileges
Delete/Restore Domain ADMINPPP
Delete Domain Objects (eg. Templates,

Filters, etc.) ADMINPPP
Create Profile ADMINPPP, CRUDPRF, CPRF
Delete Profile ADMINPPP, CRUDPRF, DPRF
Update Profile ADMINPPP, CRUDPRF, UPRF
Read profile ADMINPPP, CRUDPRF, RPRF
Create Association ADMINPPP, CRUDASC, CASC
Create Filter ADMINPPP, CRUDFLT, CFLT
Create Format ADMINPPP, CRUDFMT, CFMT
Create Metadata ADMINPPP, CRUDMTD, CMTD
Create Validator ADMINPPP, CRUDVAL, CVAL
Copy Metadata ADMINPPP, CPDOMNMTD
Copy Validator ADMINPPP, CPDOMNVAL
Move Metadata ADMINPPP, MVDOMNMTD
Move Profile ADMINPPP, MVDOMNPRF
Move Template or Association Object ADMINPPP, MVDOMNTPL
Delete Association ADMINPPP, CRUDASC, DASC
Delete Filter ADMINPPP, CRUDFLT, DFLT
Delete Formats ADMINPPP, CRUDFMT, DFMT
Delete Metadata ADMINPPP, CRUDMTD, DMTD
Delete Validator ADMINPPP, CRUDVAL, DVAL
History ADMINPPP, CRUDPRF, RPRF
Read Association ADMINPPP, CRUDASC, RASC
Read Filter ADMINPPP, CRUDFLT, RFLT
Read Format ADMINPPP, CRUDFMT, RFMT
Read Metadata ADMINPPP, CRUDMTD, RMTD
Read Profile ADMINPPP, CRUDPRF, RPRF
Read Validator ADMINPPP, CRUDVAL, RVAL
Search/Count Association ADMINPPP, CRUDASC, RASC
Search/Count Metadata ADMINPPP, CRUDMTD, RMTD
Search/Count Validator ADMINPPP, CRUDVAL, RVAL
Search/Count Template ADMINPPP, CRUDTPL, RTPL
Count Filter Is not currently supported by Sabre Profiles
Search Filter ADMINPPP, CRUDFLT, RFLT
Search/Count Profile ADMINPPP, CRUDPRF, RPRF
Search/Count Format Is not currently supported by Sabre Profiles
Update Association ADMINPPP, CRUDASC, UASC
Update Filter ADMINPPP, CRUDFLT, UFLT
Update Format ADMINPPP, CRUDFMT, UFMT
Update Metadata ADMINPPP, CRUDMTD, UMTD
Update Profile ADMINPPP, CRUDPRF, UPRF
Update Validator ADMINPPP, CRUDVAL, UVAL
Creating a Role
under those Roles. Future enhancements may support creation and update of custom roles.
Reading a Role
Sabre Profiles web clients read a customer profile over the web interface using the
Sabre_OTA_RolesReadRQrequest.The retrieval of Roles looks the same as retrieval of Profiles,
Templates, Filters, etc. A sample of a successful Read response looks like this:
<ResponseMessage>
<Success/>
</ResponseMessage>
<Roles>
<RolesIdentity
DomainID="A2FE" RoleName="TestRole1999" RoleStatusCode="AC"/>
<AssociatedPermissionsApplicationCode="PPP" PermissionCode="CASC"/>
<AssociatedPermissionsApplicationCode="PPP" PermissionCode="RASC"/>
<AssociatedPermissionsApplicationCode="PPP" PermissionCode="CRUDASC"/>
<AssociatedPermissionsApplicationCode="PPP" PermissionCode="UASC"/>
<AssociatedPermissionsApplicationCode="PPP" PermissionCode="DASC"/>
</Roles>
</Sabre_RolesReadRS>
Sample XML Read Role Error Response
<ResponseMessage>
<Errors>
<ErrorMessageErrorCode="123">R::NROLESTN-DEV5T20120813094218SR::Role with Name=GSTestRole2dd
and Domain=A2FE does not exist</ErrorMessage>
</Errors>
</ResponseMessage>
<Message>Failed</Message>
</Sabre_RolesReadRS>
Updating a Role
under those Roles. Future enhancements may support creation and update of custom roles. Partial
update for Roles is not supported by the Sabre Profiles system
Searching for a Role
Sabre Profiles web clients can search any of the 4 pre-defined Standard Roles over the web interface
using the Sabre_OTA_RolesSearchRQ request. Roles search functionality works the same way as
described for Profiles. The difference is that for Roles, you can specify the “RoleName” (instead of
PersonName used in Traveler).
Sample XML Search Roles Request
A sample Roles Search RQ looks like this:
<Sabre_RolesSearchRQ
Target="Production" TimeStamp="2001-12-17T09:30:47-05:00"
Version="3.1415926535897932384626433832795"
xmlns="http://www.sabre.com/UserRoles/schemas">
<RolesSearchCriteria
DomainID="A2FE" RoleName="*"/>
</Sabre_RolesSearchRQ>
</SOAP-ENV:Body>
Apart from the Basic Search Criteria, which has been discussed earlier, each search criterion can contain a
‘*’ sign (wildcard):
• Search Criterion = ‘AB*’ – this condition is satisfied only by values that begin with ‘AB’, which is
followed by zero or more characters ABXXX, ABC123, ABC, etc.
Deleting a Role
under those Roles.
Copying or Moving a Role to another Domain
Copy/move of Role(s)to different domain (PCC) is not supported by the Sabre Profiles system.
Assigning a Role to an Agent Profile
A Roles User Interface exists within Sabre Red Workspace and can be accessed via Agency eServices. It
provides the ability to assign one of the 4 pre-defined Standard Roles to an AGENT profile which was
generated from the EPR in a specific domain.
Notification Services (ENS) 20
Sabre Profiles ENS Overview
Sabre Profiles utilizes Sabre Event Notification Service (ENS) for notifying 3rd party systems about Profile
changes. For more details about Sabre ENS and information how to subscribe please see: ENS Developer
Guide (PDF updated MAR-2018) that can be found on Sabre Dev Studio.
Event Notification Services
Event Notification Services are an optional set of services available to Sabre Profiles web service
subscribers. It is a data publisher that informs subscribers of an event or change to a Sabre Profile in near
real-time. Customers who subscribe to Event Notification Services are notified about changes to a Profile
associated with a Pseudo City Code (PCC). The service schema is Sabre_OTA_EventNotification.xml.
For example, when a profile is created or modified, ENS sends a brief alert message that includes details
about the new profile or changes to an existing profile (profile ID number, action, timestamp, and subject
area) to the subscribing application.
Notifications are generated for the following event types:
• Create Profile
• Update Profile
• Delete Profile
• Restore Profile
• Move Profile from one PCC to another (future release)
The system receiving the notification may choose to act on the notification and, for example, perform a
ProfileReadRQ or ProfileHistoryRQ web service call to retrieve the up-to-date content of the Profile, or to
find out more about the changed data.
Sample Payload for Profile Event Create Notification
<soap-env:Body>
<swse:Sabre_OTA_EventNotification xmlns="http://www.sabre.com/eps/schemas">
<swse:ProfileEvent>
<swse:Action Timestamp="2011-06-15T18:43:38.728Z" Type="CREATE"/>
<swse:TPA_Identity ClientCode="TN" ClientContextCode=“TMP” DomainID="XXXX"
ProfileName="Sample Profile Name" ProfileTypeCode="TVL" UniqueID="123456789"/>
</swse:ProfileEvent>
</swse:Sabre_OTA_EventNotification>
</soap-env:Body>
The Profile consists of Subject Areas like Email, Address, and Payment Form.
Payloads for Profile Update and Profile Move contain information about Subject Areas that were
changed.
Sample Payload for Profile Event Update Notification
<soap-env:Body>
<swse:Sabre_OTA_EventNotification xmlns="http://www.sabre.com/eps/schemas">
<swse:ProfileEvent>
<swse:Action Timestamp="2011-06-15T18:43:38.728Z" Type="UPDATE"/>
<swse:TPA_Identity ClientCode="TN" ClientContextCode=“TMP” DomainID="XXXX"
ProfileName="Sample Profile Name" ProfileTypeCode="TVL" UniqueID="123456789"/>
<swse:SubjectArea Name="PersonName" />
<swse:SubjectArea Name="Telephone" />
<swse:SubjectArea Name="Email" />
<swse:SubjectArea Name="Address" OrderSequenceNo="1" />
</swse:ProfileEvent>
</swse:Sabre_OTA_EventNotification>
</soap-env:Body>
Summary
Sabre Profiles ENS provides:
- Knowledge about your customer data – as it happens

- Events and changes in status or creating a new profile
Benefits:
- Continuous polling is no longer needed

- Reduces scan charges
A – Sections Pending Implementation A
A.1 Sections Pending Implementation
The list below illustrates the elements or sections of the schema which are not yet implemented or fully
functional, and therefore their use should be avoided
AirlinePref/AirlineSeatPref/@Exclude
TransactionalData (is not supported in any element)
VIT_LineType, VIT_SecondaryQualifier, VIT_OrderNmbr attributes – are not supported in:

PersonName
Telephone
Email
Address
PaymentForm
Document
CustLoyalty
SSR
OSI
The sections in Data Services for Restore Password and Validate Security Answers, are not yet
implemented.
A.1.1 Partial Update – Pending Implementation
The Partial Update operation is not fully supported in current version of Sabre Profiles Web Services.
The <PartialUpdates> element under <ProfileInfo> tells which Profile and what data shall be updated.
The PartialUpdate includes the following elements:
• Delete – to remove existing profile data

• Add – to add new profile data
• Modify – to modify existing profile data
Each of the above has a dedicated structure for managing specific profile information.
If a PartialUpdate is performed, only selected subject area(s) of the Profile are updated. It ignores all
other subject areas in the profile. Here is the Sample Profile update request with <PartialUpdate>.
<Sabre_OTA_ProfileUpdateRQ Target="Production" TimeStamp="" Version="1.0"

xsi:schemaLocation="http://www.sabre.com/eps/schemas \schemas\Sabre_OTA_ProfileUpdateRQ.xsd"
<ProfileInfo>
<PartialUpdates>
<TPA_Identity ClientCode="TN" ClientContextCode=“TMP" UniqueID="" ProfileTypeCode="TVL"
DomainID="A5BE"/>
<Add>
<AddSubtree child="/Profile/Traveler/Customer/Email">
<NewSubtree>
<Traveler>
<Email EmailTypeCode="HOM" EmailAddress="test@email.com" >
</Email>
</Traveler>
</NewSubtree>
</AddSubtree>
</Add>
</PartialUpdates>
</ProfileInfo>
A list of subject area names that can be used within PartialUpdate is found in tables below. Supported
subject areas are marked with “X”. This feature will be enhanced in the future to support more subject
areas.
Profile schema
Subtree
Subtree
Subtree
Modify
Delete
Add
/Profile/AnalyticalInfoGroups/AnalyticalInfoGroup X
/Profile/Corporation/Address
/Profile/Corporation/AssociatedFilters
/Profile/Corporation/AssociatedProfiles
/Profile/Corporation/AssociatedTemplate
/Profile/Corporation/ContactName
/Profile/Corporation/CorporateInfo
/Profile/Corporation/CustomDefinedData
/Profile/Corporation/CustomerReferenceInfo
/Profile/Corporation/Discounts
/Profile/Corporation/Email
/Profile/Corporation/EmergencyContactPerson
/Profile/Corporation/PaymentForm X
/Profile/Corporation/PrefCollections/AirlinePref/AirlineMealPref
Profile schema
Subtree
Subtree
Subtree
Modify
Delete
Add
/Profile/Corporation/PrefCollections/AirlinePref/AirlineSeatPref
/Profile/Corporation/PrefCollections/AirlinePref/AirportOriginPref
/Profile/Corporation/PrefCollections/HotelPref/HotelChainPref
/Profile/Corporation/PrefCollections/HotelPref/HotelMealPref
/Profile/Corporation/PrefCollections/TPA_MarketingPreference/Consent
/Profile/Corporation/PrefCollections/TPA_MarketingPreference/NotificationPreferenc
e
/Profile/Corporation/PrefCollections/TPA_MarketingPreference/PsychographicCatego
ry
/Profile/Corporation/PrefCollections/VehicleRentalPref/VehicleVendorPref
/Profile/Corporation/PriorityRemarks
/Profile/Corporation/Remark
/Profile/Corporation/SalesManager
/Profile/Corporation/Telephone
/Profile/Corporation/TravelPolicy/SabreTravelPolicy/Policy X X X
/Profile/Corporation/TravelPolicy/SabreTravelPolicy/Preference X X X
/Profile/GroupProfile/PaymentForm X
/Profile/GroupProfile/TravelPolicy/SabreTravelPolicy/Policy X X X
/Profile/GroupProfile/TravelPolicy/SabreTravelPolicy/Preference X X X
/Profile/OperationalProfile/PaymentForm X
/Profile/OperationalProfile/TravelPolicy/SabreTravelPolicy/Policy X X X
/Profile/OperationalProfile/TravelPolicy/SabreTravelPolicy/Preference X X X
/Profile/SocialMediaAccounts/SocialMediaAccount X
/Profile/TPA_Identity/Login X X
/Profile/TPA_Identity/ProfileSubType
/Profile/TPA_Identity/SecurityInfo X X X
/Profile/TravelAgency/Address
/Profile/TravelAgency/AgencyContactName
Profile schema
Subtree
Subtree
Subtree
Modify
Delete
Add
/Profile/TravelAgency/AgencyInfo
/Profile/TravelAgency/AssociatedFilters
/Profile/TravelAgency/AssociatedProfiles
/Profile/TravelAgency/AssociatedTemplate
/Profile/TravelAgency/Branding
/Profile/TravelAgency/CustomDefinedData
/Profile/TravelAgency/CustomerReferenceInfo
/Profile/TravelAgency/Discounts
/Profile/TravelAgency/Email
/Profile/TravelAgency/EmergencyContactPerson
/Profile/TravelAgency/GDS
/Profile/TravelAgency/OtherSystemIdentityInfo
/Profile/TravelAgency/PaymentForm X
/Profile/TravelAgency/PrefCollections/AirlinePref/AirlineMealPref
/Profile/TravelAgency/PrefCollections/AirlinePref/AirlineSeatPref
/Profile/TravelAgency/PrefCollections/AirlinePref/AirportOriginPref
/Profile/TravelAgency/PrefCollections/HotelPref/HotelChainPref
/Profile/TravelAgency/PrefCollections/HotelPref/HotelMealPref
/Profile/TravelAgency/PrefCollections/TPA_MarketingPreference/Consent
/Profile/TravelAgency/PrefCollections/TPA_MarketingPreference/NotificationPreferen
ce
/Profile/TravelAgency/PrefCollections/TPA_MarketingPreference/PsychographicCateg
ory
/Profile/TravelAgency/PrefCollections/VehicleRentalPref/VehicleVendorPref
/Profile/TravelAgency/PriorityRemarks
/Profile/TravelAgency/Remark
/Profile/TravelAgency/Telephone
/Profile/TravelAgency/TravelPolicy/SabreTravelPolicy/Policy X X X
Profile schema
Subtree
Subtree
Subtree
Modify
Delete
Add
/Profile/TravelAgency/TravelPolicy/SabreTravelPolicy/Preference X X X
/Profile/TravelAgent/Address
/Profile/TravelAgent/AgentInfo
/Profile/TravelAgent/AgentName
/Profile/TravelAgent/AgentRelatedNames
/Profile/TravelAgent/AssociatedFilters
/Profile/TravelAgent/AssociatedProfiles
/Profile/TravelAgent/AssociatedTemplate
/Profile/TravelAgent/CustLoyalty
/Profile/TravelAgent/CustomDefinedData
/Profile/TravelAgent/CustomerReferenceInfo
/Profile/TravelAgent/Discounts
/Profile/TravelAgent/Document
/Profile/TravelAgent/Email
/Profile/TravelAgent/EmergencyContactPerson
/Profile/TravelAgent/EmploymentInfo
/Profile/TravelAgent/GDS
/Profile/TravelAgent/OtherSystemIdentityInfo
/Profile/TravelAgent/PaymentForm X
/Profile/TravelAgent/PrefCollections/AirlinePref/AirlineMealPref
/Profile/TravelAgent/PrefCollections/AirlinePref/AirlineSeatPref
/Profile/TravelAgent/PrefCollections/AirlinePref/AirportOriginPref
/Profile/TravelAgent/PrefCollections/HotelPref/HotelChainPref
/Profile/TravelAgent/PrefCollections/HotelPref/HotelMealPref
/Profile/TravelAgent/PrefCollections/TPA_MarketingPreference/Consent
/Profile/TravelAgent/PrefCollections/TPA_MarketingPreference/NotificationPreferenc
e
Profile schema
Subtree
Subtree
Subtree
Modify
Delete
Add
/Profile/TravelAgent/PrefCollections/TPA_MarketingPreference/PsychographicCatego
ry
/Profile/TravelAgent/PrefCollections/VehicleRentalPref/VehicleVendorPref
/Profile/TravelAgent/PriorityRemarks
/Profile/TravelAgent/Remark
/Profile/TravelAgent/Telephone
/Profile/Traveler/Customer/Address X X X
/Profile/Traveler/Customer/CustLoyalty X X X
/Profile/Traveler/Customer/Document X X X
/Profile/Traveler/Customer/Email X X X
/Profile/Traveler/Customer/EmergencyContactPerson X
/Profile/Traveler/Customer/EmploymentInfo X X X
/Profile/Traveler/Customer/PaymentForm X X X
/Profile/Traveler/Customer/PersonName X X X
/Profile/Traveler/Customer/RelatedTraveler X X X
/Profile/Traveler/Customer/Telephone X X X
/Profile/Traveler/PrefCollections/AirlinePref/AirlineCabinPref X X X
/Profile/Traveler/PrefCollections/AirlinePref/AirlineMealPref X X X
/Profile/Traveler/PrefCollections/AirlinePref/AirlineSeatPref X X
/Profile/Traveler/PrefCollections/AirlinePref/AirlineUpgradePref X X X
/Profile/Traveler/PrefCollections/AirlinePref/AirportPref X X X
/Profile/Traveler/PrefCollections/AirlinePref/PreferredAggregator X X X
/Profile/Traveler/PrefCollections/AirlinePref/PreferredAirlines X X X
/Profile/Traveler/PrefCollections/HotelPref/PreferredAggregator
/Profile/Traveler/PrefCollections/HotelPref/PreferredHotel
/Profile/Traveler/PrefCollections/LoungePref X X X
/Profile/Traveler/PrefCollections/TPA_MarketingPreference/Consent X X X
Profile schema
Subtree
Subtree
Subtree
Modify
Delete
Add
/Profile/Traveler/PrefCollections/TPA_MarketingPreference/NotificationPreference X X X
/Profile/Traveler/PrefCollections/TPA_MarketingPreference/PsychographicCategory X X X
/Profile/Traveler/PrefCollections/VehicleRentalPref/PreferredAggregator
/Profile/Traveler/PrefCollections/VehicleRentalPref/PreferredVehicleVendors
/Profile/Traveler/TPA_Extensions/AssociatedFilters X X
/Profile/Traveler/TPA_Extensions/AssociatedProfiles X X X
/Profile/Traveler/TPA_Extensions/AssociatedTemplate X X X
/Profile/Traveler/TPA_Extensions/CustomDefinedData X X X
/Profile/Traveler/TPA_Extensions/CustomerReferenceInfo X X X
/Profile/Traveler/TPA_Extensions/CustomerValueScore X X X
/Profile/Traveler/TPA_Extensions/Discounts X X X
/Profile/Traveler/TPA_Extensions/OSI X X X
/Profile/Traveler/TPA_Extensions/PriorityRemarks X X X
/Profile/Traveler/TPA_Extensions/Remark X X X
/Profile/Traveler/TPA_Extensions/SSR X X X
/Profile/Traveler/TPA_Extensions/TravelPolicy/SabreTravelPolicy/Policy X X X
/Profile/Traveler/TPA_Extensions/TravelPolicy/SabreTravelPolicy/Preference X X X
Profile schema Delete Elements Add Elements Modify Elements
Traveler AgeRange X X X
BirthDate X X X
CitizenCountryCode X X X
DomainID
Gender X X X
LoginID X X X
MaritalStatus X X X
Password X X X
PasswordIsHashed X X
ProfileDescription X X X
ProfileName X X X
ProfilePurgeNoDays X X X
ProfileStatus X
ProfileSubTypeCode X X X
AuxiliaryID Identifier X X
IDTypeCode X X
SabreTravelPolicy EntityID X X X
A.1.2. TPA Extensions
TPA_Extensions/ProfileAccessInfo
It is read-only, but not updated in Read as well
TPA_Extentions/CustomerValueScore/ValueScoreUpdateInfo
A.1.3. ProfileToPNR Standard PNR Formats
Below is the matrix showing when specific subject areas and attributes are defined to move to PNR using
the ProfileToPNR service. Instead of user creating individual Formats to move data to PNR, we supply a
standard PNR Format for specific subject areas and attributes.
Elements and
Subject Area Name Attributes which are Sample Data Format in P2PNR Response (Application)
moved to PNR
NamePrefix MR -SurName NameSuffix/GivenName
GivenName VERNON MiddleName NamePrefix*InformationText
MiddleName TOM Example:
PersonName -BEAR JR/VERNON TOM MR*123-456-789
SurName BEAR
NameSuffix JR
@InformationText 123-456-789
351- 9CityCodeFullPhoneNumber-
FullPhoneNumber
609154207 @LocationTypeCode @InformationText
@LocationTypeCode AGY Example:
Full Telephone Full AGY 9KRK351-609154207-A FULL AGY PHONE (-A if
@InformationText @PNRTelephoneTagIndicator=Y)
Phone
@PhoneCityCode KRK
Elements and
moved to PNR
9KRK351-609154207 FULL AGY PHONE (no –A
if @PNRTelephoneTagIndicator=N)
Note: The order moved to PNR is based upon

the defined LocationTypeCode. Phones are
moved in order below. If you have multiple
instances within a specific LocationTypeCode,
then the OrderSequenceNo determines what
order the phones are moved within that
LocationTypeCode.
@PNRTelephoneTagIn
Y/N Agency -A
dicator
Business -B
Company -B
Cell -C
Mobile -M
Home -H
Second home -H
Emergency -E
Fax -F
Unknown -U
Pager -P
351- 9CityCode@CountryCode-@AreaCode-
@PhoneNumber
609154207 @PhoneNumberX@Extension-
@AreaCd 11 @LocationTypeCode @InformationText
Example:
@CountryCode 011
9DFW011-11-351-609154207X048-A PASED
@Extension 048 HOM PHONE (-A if
Parsed Telephone @LocationTypeCode AGY @PNRTelephoneTagIndicator=Y)
Parsed HOM 9DFW011-11-351-609154207X048 PASED
@InformationText HOM PHONE (no –A if
Phone
@PNRTelephoneTagIndicator=N)
@PhoneCityCode DFW
@PNRTelephoneTagIn
Y/N
dicator
PE#@EmailAddress#@EmailUsageCode/@Em
TestEmail@s ailRemark
@EmailAddress Example:
abre.com
PE#TESTEMAIL@SABRE.COM#FR/EMAIL
REMARK
Email Note: The order moved to PNR is based upon

@EmailUsageCode FRM
the defined EmailTypeCode. Email Addresses
are moved in order below but please consider
that unlike Phone ordering which moves
exactly as entered in a PNR, the 1st email
@EmailRemark Email Remark address entered in host is the last email
displayed in the PNR.
Elements and
moved to PNR
If you have multiple instances within a specific
EmailTypeCode, then the OrderSequenceNo
determines what order the Email Addresses
are moved within that EmailTypeCode.
• Unknown
• Delivery
• Billing
• Agency
• Administrator
• Company
• Business
• Emergency
• Second Home
• Home
If @LocationTypeCode=”AGY” (Agency) then

@Attention Attention format is:
W-
@Attention#AddressLine1#AddressLine2#Add
ressLine3#AddressLine4#CityName StateCode
AddressLine1 Line 1 PostalCd#CountryCode
Example:
W-ATTENTION#LINE 1 LINE 2 LINE 3 LINE
4#Krakow MA 30-348#PL
AddressLine2 Line 2
If @LocationTypeCode=”BIL” (Billing) then

format is:
AddressLine3 Line 3 CC/N/@Attention
CC/A/AddressLine1 AddressLine2
Address AddressLine3 AddressLine4
CC/C/CityName, StateCode, CountryCode
AddressLine4 Line 4 CC/Z/PostalCd
Example:
CC/N/ATTENTION
CityName Krakow CC/A/LINE 1 LINE 2 LINE 3 LINE4
CC/C/KRAKOW, MA, US
CC/Z/30-348
StateCode MA If @LocationTypeCode=”DEL” (Delivery)then

format is:
5DL-@Attention
5DL-Line1
PostalCd 30-348
5DL-Line2
Elements and
moved to PNR
5DL-Line3
5DL-Line4
5DL-CityName StateCode PostalCd
5DL-CountryCode
Example:
5DL-ATTENTION
5DL-LINE 1
5DL-LINE 2
5DL-LINE 3
5DL-LINE 4
5DL-KRAKOW MA 30-348
5DL-PL
If @LocationTypeCode is different than three

above:
5/@Attention
5/AddressLine1
5/AddressLine2
5/AddressLine3
5/AddressLine4
5/CityName StateCode PostalCd (if
@CountryCode is inside US)
5/PostalCd CityName StateCode (if
@CountryCode is outside US)
CountryCode PL
5/CountryCode
Example:
5/ATTENTION
5/LINE 1
5/LINE 2
5/LINE 3
5/LINE 4
5/KRAKOW MA 30-348
5/PL
Note: For General 5/ Address formats, the

order moved to PNR is based upon the defined
LocationTypeCode. Addresses are moved in
order below. If you have multiple instances
within a specific LocationTypeCode, then the
OrderSequenceNo determines what order the
Addresses are moved within that
LocationTypeCode.
• Administrator
• Business
• Company
• Emergency
• Home
• Second Home
Elements and
moved to PNR
• Unknown
@BankCardVendorCod 1) For Payment Card (when

AX
e ServiceUsageTypeCode=”AL” or “OT”):
37830291431 5-
@CardNumber *@BankCardVendorCode@CardNumber#@Ex
7551
pireDate@InformationText
@ExpireDate 012015 5-CH#CardHolderFullName
Example:
-XN or FOP
@InformationText 5-*AXXXXXXXXXXXXX7551#01/15-XN
REMARK
5-CH#MAT BEAR
CardHolderFullName MAT BEAR
2) For PaymentCard with
ServiceUsageTypeCode=”CR” or “HL”:
Cash
5C¥/G@BankCardVendorCode@CardNumber
EXP @expiredate = MM YY-
@PNRCheckCode CHECK
@CardHolderName>SurName
5H¥/G@BankCardVendorCode@CardNumber
EXP @expiredate = MM YY-
@CardHolderName>SurName
Example:
PaymentForm
5C¥/GCA543211234567890EXP 12 14-BEAR
5H¥/GCA543211234567890EXP 12 14-BEAR
3) For Cash (except

ServiceUsageTypeCode=”CR” and “HL”):
5-CASH@InformationText
Example:
@FirstRemark Y/N 5-CASH FOP REMARK
4) For Check (except

ServiceUsageTypeCode=”CR” and “HL”):
5-@PNRCheckCode@InformationText
Example:
5-CHECK FOP REMARK
When @FirstRemark=”Y”:
5-@PNRCheckCode@InformationText with
FirstRemark="Y"
Example:
50/-CHECK FOP REMARK
For GR:
@FirstRemark Y/N 5- (GovernmentWarrant/WarrantType)(
PaymentForm>Gover
GovernmentWarrant/WarrantNumber)-
nmentWarrant
(InformationText)
Example:
WarrantType GR, GGR, FGR
Elements and
moved to PNR
GOM, WPM, 5-GR¥1234567890ABC-GOVT WARRANT
WarrantSubtype
ATR INFORMATION
ABC1234567
WarrantNumber
89 For GGR:
987654321XY 5-( GovernmentWarrant>WarrantType)(
DebtorCd
Z GovernmentWarrant>WarrantySubtype)(Gov
ObjectCd 123ABC ernmentWarrant>WarrantNumber)-
(GovernmentWarrant>DebtorCd)-
(GovernmentWarrant>ObjectCd)-
(InformationText)
Example:
5-GGRGOMABC1234567890-987654321XYZ-
123ABC-GOM FORM OF PAYMENT
PaymentForm>@Infor Warrant
mationText Information For FGR:
5-(GovernmentWarrant>WarrantType)REQ-(
GovernmentWarrant>WarrantNumber)
Example:
5-FGRREQ-19876543002
Depending on domain and PNR configuration

@FirstRemark Y/N
Virtual Payment can be moved to PNR in two
possible ways:
1) As a Remark
5-
*VCN(VirtualPayment/@CustomerAccountCd
)
PaymentForm/Virtual Example:
Payment IBM1234567 5-*VCNIBM12345678
@CustomerAccountCd
8
2) As a FOP
FOP*VCN(VirtualPayment/@CustomerAccoun
tCd)
Example:
FOP*VCNIBM12345678
DK@BranchID@ReferenceID
@BranchID 12
Example:
CustomerReferenceIn DK123456
fo 3456, 34567, DK1234567
@ReferenceID
34567890 DK1234567890
For SUB Discount:

@VendorCode AF SC#/@VendorCode@ID
Example:
Discounts SC#/AF777710
@ID 777710
For CID Discount:
Elements and
moved to PNR
CID-@ID
@TypeCode SUB/CID Example:
CID-777710
@Text
Example:
5DL-SABRE 5DL-SABRE DRIVE DT 12345
Remarks @Text DRIVE DT
12345
PGM.-PCC-@CTPName
@CTPName TEST Example:
Corporate PGM.-A2FE-TEST
TravelPolicy
@PCC A2FE
FF@VendorCode@MembershipID/Associated
@VendorCode UA
VendorCode-SurName/LastName
MiddleName
@MembershipID 03111968186 Example:
FFUA03111968186/AC-BEAR/VERNON VAN
@AssociatedVendorCo
AC
CustLoyalty de
(FrequentFlayer)
GivenName Vernon
MiddleName Bear
SurName Van
@IsSubjectToSecureFli If RedressNumber is not set:

Y
ghtRule 4DOCS/DB/@BirthDate/@GenderCode/SurN
ame NameSuffix/GivenName/MiddleName
@BirthDate 2012-07-05 3DOCS/DB/@BirthDate/@GenderCode/SurN
ame NameSuffix/GivenName/MiddleName
@GenredCode M Example:
4DOCS/DB/05JUL12/M/BEAR
PersonName/GivenNa
Tom SR/VERNON/VAN
me
PersonName/MiddleN SR/VERNON/VAN
SecureFlight Jimmy
ame
If RedressNumber is set:
PersonName/SurName Trammel
4DOCS/DB/@BirthDate/@GenderCode/SurNa
me NameSuffix/GivenName/MiddleName
DocHolder/SurName Bear
DocHolder/GivenNam me NameSuffix/GivenName/MiddleName
Vernon 4DOCO//R/@RedressNumber///US
e
3DOCO//R/@RedressNumber///US
DocHolder/MiddleNa
Van Example:
me
Elements and
moved to PNR
DocHolder/NameSuffix SR
SR/VERNON/VAN
SR/VERNON/VAN
4DOCO//R/123456///US
3DOCO//R/123456///US
If LapInfantIndicator=”Y” and BirthDate is
less than 2 years from current date
3DOCO//R/123456789///US/I
4DOCO//R/123456789///US/I
If KnownTravelerNumber is set
@RedressNumber 123456
3DOCO//K/123456789
4DOCO//K/123456789
If LapInfantIndicator=”Y” and BirthDate is
less than 2 years from current date
3DOCO//K/45678901////I
4DOCO//K/45678901////I
@KnownTravelerNum
45678901
ber

Sabre Profiles

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sabre Profiles

Uploaded by

Copyright:

Available Formats

Sabre Profiles

Technical User Guide

Document Revision: 201928002.1.0

This documentation is the confidential and proprietary intellectual

About this Guide ....................................................................................................................................... 1

Accessing Sabre Profiles Web Services .................................. 12

Sabre Profile Types ............................................................ 24

Profile Types .......................................................................................................................................... 24

Create Service ................................................................... 44

Creating Profiles ..................................................................................................................................... 44

Read Service ..................................................................... 48

Reading Profiles ..................................................................................................................................... 48

Update Service .................................................................. 56

Updating Profiles .................................................................................................................................... 56

Search Service .................................................................. 66

Searching for Profiles ............................................................................................................................. 66

Delete/Restore Service ........................................................ 90

Deleting and Restoring Profiles .............................................................................................................. 90

Profile History Service ........................................................ 93

Profile Data Management Service ......................................... 100

Copying/Moving Profiles to a Branched Pseudo City Code .................................................................. 100

Profile Merge Service ........................................................ 107

Merging Profiles ................................................................................................................................... 107

ProfileToPNR Service ......................................................... 112

ProfileToPNR Service Overview .......................................................................................................... 112

Filters ............................................................................. 133

Filter Overview ..................................................................................................................................... 133

Format Overview .................................................................................................................................. 144

Templates/Associations with Metadata ................................. 163

Overview .............................................................................................................................................. 163

Bulk Read Services ............................................................ 177

Bulk Read Service Overview ................................................................................................................ 177

Profile Data Service .......................................................... 187

Overview .............................................................................................................................................. 187

Roles Overview .................................................................................................................................... 198

Notification Services (ENS) ................................................ 205

Sabre Profiles ENS Overview .............................................................................................................. 205

A – Sections Pending Implementation ................................... 207

A.1 Sections Pending Implementation .......................................................................................... 207

Standards and Specifications

• HTTP 1.1 [RFC2616] – used for transport protocol

• SOAP – Simple Object Access Protocol

• ISO 10646/Unicode, Basic Latin and Latin 1 Supplement

• UCS Transformation Format 8 (UTF-8 Encoding)

• ISO 8859 Latin 1 Character Set

• Sabre Character Set

About Sabre Profiles Web Services

A simplified flow of a Web Services session is as follows:

a. Validates the user security credentials and message format

b. Authenticates the message

I. Security credentials in the SessionCreateRQ message consist of the

Web Services Sessions

SessionCreateRQ Request XML Example

<?xml version="1.0" encoding="UTF-8"?>

The SOAP Payload

A typical response is shown below.

<SessionCreateRS xmlns="http://www.opentravel.org/OTA/2002/11" version="1" status="Approved">

The SOAP Envelope

<?xml version="1.0" encoding="UTF-8"?>

The SessionCloseRQ message for the example follows:

<?xml version=”1.0” encoding='UTF-8'?>

Credit Card Data Security

• Credit Card data is encrypted before it is stored in the database.

Telephone Support is available 24 x 7