Sabre Profiles Technical User Guidefiles.developer.sabre.com/doc/providerdoc/PPP/... · • SOAP – Simple Object Access Protocol • Character Specifications • ISO 10646/Unicode,

Sabre Profiles

Technical User Guide

April 2018

© 2018, Sabre Inc. All rights reserved.

Document Revision: 20172002.5.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.

Sabre Profiles Technical User Guide April 2018 Confidential and Proprietary Sabre Inc. iii

Table of Contents

I n t r o d u c t i o n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

A c c e s s i n g S a b r e P r o f i l e s W e b S e r v i c e s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2

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

S a b r e P r o f i l e T y p e s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 4

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

Logic for specific schema elements/attributes within the Profile ........................................................ 25 Operational ............................................................................................................................................. 27 Corporate ............................................................................................................................................... 27

Sabre Profiles Technical User Guide April 2018 Confidential and Proprietary Sabre Inc. iv

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

C r e a t e S e r v i c e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4

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

R e a d S e r v i c e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8

Reading Profiles ..................................................................................................................................... 48 Sample XML Read Successful Response ......................................................................................... 52 Credit Card Tokenizer ....................................................................................................................... 52 Sample XML Read Error Response .................................................................................................. 54

U p d a t e S e r v i c e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6

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

S e a r c h S e r v i c e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6

Searching for Profiles ............................................................................................................................. 66 Online Profile Search ......................................................................................................................... 66

Sabre Profiles Technical User Guide April 2018 Confidential and Proprietary Sabre Inc. v

Offline Profile Search ......................................................................................................................... 75

D e l e t e / R e s t o r e S e r v i c e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 0

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

P r o f i l e H i s t o r y S e r v i c e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3

Overview ................................................................................................................................................ 93 Sample XML Profile History Request ..................................................................................................... 93 Sample XML Profile History Successful Response ................................................................................ 94 Sample XML Profile History Error Response ......................................................................................... 98

P r o f i l e D a t a M a n a g e m e n t S e r v i c e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 0 0

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

P r o f i l e M e r g e S e r v i c e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 0 7

Merging Profiles ................................................................................................................................... 107 How to Merge a Profile .................................................................................................................... 107 Merge process flow ......................................................................................................................... 109 Sample XML Profile Merge Request ............................................................................................... 109 System Access Permissions ........................................................................................................... 111

P r o f i l e T o P N R S e r v i c e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 2

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 April 2018 Confidential and Proprietary Sabre Inc. vi

Profile Index ......................................................................................................................................... 130 PNR Profile Index display ..................................................................................................................... 131

Display Profile using the Profile Index value .................................................................................... 132

F i l t e r s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3 3

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

F o r m a t s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 4 4

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 April 2018 Confidential and Proprietary Sabre Inc. vii

Sample XML Format Delete Request .............................................................................................. 161 Sample XML Format Delete Successful Response ......................................................................... 162 Sample XML Format Delete Error Response .................................................................................. 162

T e m p l a t e s / A s s o c i a t i o n s w i t h M e t a d a t a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 6 3

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

B u l k R e a d S e r v i c e s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 7 7

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 April 2018 Confidential and Proprietary Sabre Inc. viii

Bulk Read – Validators – Response Message ..................................................................................... 185

P r o f i l e D a t a S e r v i c e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 8 7

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

R o l e s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 9 8

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

N o t i f i c a t i o n S e r v i c e s ( E N S ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 0 5

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 – S e c t i o n s P e n d i n g I m p l e m e n t a t i o n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 0 7

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 April 2018 Confidential and Proprietary Sabre Inc. 1

A b o u t t h i s G u i d e

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.

S t a n d a r d s a n d S p e c i f i c a t i o n s

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.

Introduction 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

A b o u t S a b r e P r o f i l e s W e b S e r v i c e s

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

http://www.opentravel.org/


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.

S e c u r i t y

Sabre Web Services has implemented multiple layers of security for client applications. These layers

include line security, authentication, authorization, and confidentiality.


L i n e S e c u r i t y

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.

A u t h e n t i c a t i o n

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>


A u t h o r i z a t i o n

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.

C o n f i d e n t i a l i t y

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.

N e t w o r k C o n n e c t i v i t y

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.

W e b S e r v i c e s S e s s i o n s

S e s s i o n C r e a t e R Q R e q u e s t X M L E x a m p l e

The web client establishes a SWS session by sending security credentials and a unique conversation

ID as shown in the following example.

T h e E n v e l o p e

<?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:[email protected]</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>

T h e S O A P P a y l o a d

<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:[email protected]</ConversationId>


</SessionCreateRS

T h e S O A P E n v e l o p e


<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:[email protected]</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>


E n d i n g t h e S e s s i o n

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:[email protected] </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:[email protected] </ConversationId>

</SessionCreateRS>

C r e d i t C a r d D a t a S e c u r i t y

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.

A c c e s s

• 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 and HTTPS 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.


S t o r a g e a n d I n t e r n a l S e c u r i t y M e a s u r e s

• 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.

T e c h n i c a l S u p p o r t

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

E m a i l

Send an email to the following address: [email protected].

mailto:[email protected]


Email is monitored Monday through Friday during extended business hours.

A d d i t i o n a l S u p p o r t

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.


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

Addresses

New URLs New IP

Addresses

webservices.sabre.com

webservices2.sabre.com

webservices3.sabre.com

webservices.lp.sabre.com

151.193.160.91

151.193.160.105

151.193.51.17

151.193.51.15

webservices.havail.sabre.com 151.193.4.55

151.193.0.56

Certification


Addresses

New URLs New IP

Addresses

sws-crt.cert.sabre.com

151.193.52.22 sws-crt.cert.havail.sabre.com 151.193.109.22

151.193.105.24

Test


Addresses

New URLs New IP

Addresses

sws-sts.cert.sabre.com

151.193.52.23 sws-sts.cert.havail.sabre.com 151.193.109.30

151.193.105.33

A c t i v a t i o n

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).

Accessing Sabre Profiles Web

Services

3


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

T y p e s o f W e b S e r v i c e s

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.


S e s s i o n M a n a g e m e n t S e r v i c e s

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.

S a b r e P r o f i l e s S e r v i c e s

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.

D o m a i n A c c e s s R u l e s

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.

M e s s a g e S t r u c t u r e

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.

R e q u e s t i n g P a y l o a d C o n t e n t

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


S a b r e P r o f i l e A c c e s s v a l i d a t i o n b y P C C

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

PCC

AAA

PCC

Login PCC Sabre

Security

Attribute

AAA PCC Sabre

Security

Attribute

Access to

profile

Services

Remarks

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.

W e b S e r v i c e s E r r o r H a n d l i n g

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:

https://developer.sabre.com/


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>


P r o f i l e T y p e s

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.

T r a v e l e r

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.

Sabre Profile Types 4


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.

L o g i c f o r s p e c i f i c s c h e m a e l e m e n t s / a t t r i b u t e s w i t h i n t h e P r o f i l e

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).


http://en.wikipedia.org/wiki/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.

O p e r a t i o n a l

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.

C o r p o r a t e

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.



G r o u p

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.



A g e n c y

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.



A g e n t

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.



R e p l i c a t i o n o f S a b r e H o s t E P R s i n t o A g e n t P r o f i l e s

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.

A u d i t i n f o r m a t i o n t r a c k i n g u s i n g A c c e s s I n f o i n t h e A P I

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.


C o m m o n a t t r i b u t e s w i t h i n t h e P a y l o a d

The following attributes are available for every Profile Type:

C l i e n t C o n t e x t C o d e

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.


P r o f i l e S u b T y p e s

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.


H o w t o D e t e r m i n e t h e P r o f i l e D a t a N e e d e d

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

[email protected] and review the set of composed XML messages.

7. Setup CAT testing with Sabre.

U s e o f D i c t i o n a r y C o n t r o l T a b l e V a l u e s

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.

U s e o f S t a t u s c o d e s

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.

D o m a i n “ S t a t u s ”

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).


P r o f i l e “ S t a t u s ”

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

OK - (controlled

by “Ignore Status

Check” attribute. If

attribute is not

included, the

profile in ‘IN’

status can not be

updated. X

Read OK OK X

Search OK OK

OK – (controlled by

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”.

P r o f i l e A s s o c i a t i o n s

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

Type

Allows Associations TO Profile

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

C o m m o n R u l e s a n d E l e m e n t s a c r o s s P r o f i l e T y p e s

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

Element

TVL

AG

T

CR

P

AG

Y

OP

X

GR

P

Description

Customer X

Parent element for Traveler under which the rest of the

traveler elements can be found such as name

(PersonName), phone (Telephone), email (Email), address

(Address), etc.

PersonName X

Title, First name, middle name, last Name, etc.

Telephone X X X X X X

All the components for telephone, for full phone or parsed

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.



Element

TVL

AG

T

CR

P

AG

Y

OP

X

GR

P

Description

PaymentForm X X X X X X Form of payment type including Credit/Debit cards,

checks, cash, accounts receivable etc.

RelatedIndividual X

Contact data (names, etc.) for individuals related to the

traveler profile

EmergencyContactPerso

n X X X X

X

Contact information including names, phone numbers,

email, address for contacting in case of emergency

Document X X

Information such as passport, visas, driver licenses, etc.

CustLoyalty X X

Information on Loyalty programs per vendor such as

airline frequent traveler programs, hotel or car rental

frequent traveler or loyalty programs

EmploymentInfo X X

X

X

Information about where the individual is employed

including employee number, cost centers, departments,

etc.

AgencyContactName X X Title, First name, middle name, last name, etc.

AgencyInfo

X

Agency details including name, description, URL and other

identifiers (also Tax and credit info, etc.)

CorporateInfo

X

Corporation details including name, description, nature of

business, and other identifiers (also Tax and bank info,

etc.)

GroupInfo X Group details including name, Meeting Id or Group Id (also

Tax and bank info, etc.)

ContactName

X

X X

Contains basic information about contact (name Prefix,

GivenName, MiddleName, Surname(required),

NameSuffix, PreferredFirstName, PreferredLastName,

OrderSequenceNo, and LanguageIdCode)

AgentName

X

Agent name title, first name, middle name, last name, etc.

AgentInfo

X

Agent information such as date of birth, marital status,

gender, etc. Also includes tax info.



Element

TVL

AG

T

CR

P

AG

Y

OP

X

GR

P

Description

AgentRelatedIndividuals

X

Data to identify other individuals related to the agent

including their names and relationship type

AgentGDSIdentity

X

Includes Agent sine, ID, GDS-code, etc.

PrefCollections X X X X X X

This section is divided by Air, Hotel, VehicleRental, Rail,

etc.

AirlinePref X X X X X X

Stores preferences by trip type, geographic origin or

destination and includes options for Airport preferences,

seats, cabin, meals, preferred airlines, etc.

HotelPref X X X X X X


destination and includes options for Preferred hotel

vendors, property, rates, roomType, etc.

VehicleRentalPref X X X X X X


destination and includes options for Preferred rental car

vendors, rates, vehicle types, etc.

RailPref X X X X X X


destination and includes options for Rail stations, seats,

cabin, meals, vendors, upgrades, etc.

GroundTransportationPr

ef X X X X X X


destination and includes options for Preferred bus or limo

vendors, rates, aggregators, etc.

TPAMarkertingPreferenc

e X X X X X X

Includes notification preferences, consent for notifications

and agreement for campaigns and consent for terms and

conditions, etc.

Priority Remarks X X X X X X Important notes/information

Remarks X X X X X X Other notes/remarks

SSR X

X

X

X

Special Service Request information including codes and

descriptions (i.e. WHCR - Wheelchair, etc.)

OSI X

X

X

X

Other Service Request information including codes and

descriptions



Element

TVL

AG

T

CR

P

AG

Y

OP

X

GR

P

Description

CustomerReferenceInfo X X X X X X

Reference to 3rd party systems such as accounting

systems including branch and account ID's for DK-

customer storage

BusinessSystemIdentityIn

fo X X X X

X

Information on other systems (i.e. back office system

references) includes system name, Id, description, etc.

Associated Profiles X X X X X X

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

after the main profile

Associated Filters X X X X X X

References Filters indicating which data is pre-selected to

be used in the Profile to PNR move service (includes filter

name, id, DomainID (PCC), etc.)

Associated Formats X X X X X X

References Formats (Host/emulator string entries

constructed by the user with text and profile data

(includes, name, ID, DomainID (PCC), etc.)

Discounts X X X X X X

Discount information by vendor for Air, Hotel, Car Rental

discounts, etc. (includes vendor type and code, discount

number, descriptions, effective and expiration dates, etc.)

CustomDefinedData X X X X X X

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

for domain via DataSrvRQ

CustomDefinedValues X X X X X X

String values defined by customer to define their own data

beyond existing data model. No validation applied by the

Profiles system for content.

Tax Info X

Tax information corresponding the entity in the Profile

Roles

X

Reference to the Role assigned (grouping of lower level

permissions) to enable/restrict profile functions such as

Create, Read, Update, Delete, etc.



Element

TVL

AG

T

CR

P

AG

Y

OP

X

GR

P

Description

Travel Policy X

X X X X

Reference to Sabre Corporate Travel Policy records

(CTP/Flex edits) and Sabre Travel Policy Engine (future

product)

STARData X X X X X X

Reference to the Sabre STAR data from which the profile

originated (for migrated profiles)

CustomerValueScore X

Customer value score assigned by a system to segment

customers (includes, score, effective/discontinue dates,

vendor types and codes)

GDS

X X X

X

Information of the Global distribution system referenced

to this profile (I.e. 1S=Sabre)

QueueAssignments

X

X

Queue assignment including queue number, DomainID

(PCC) Prefatory instruction, etc.

Commissions

X

X

Commission data including: commission measure code,

value, trip type, vendor, effective/discontinue date, etc.

SabreSecurityEntityAttrib

ute

X

Attributes (i.e. Sabre GDS security attributes assigned to

the EPR such as CCVIEW, etc.)

Incentives

X

information on incentives including: supplier code,

service, incentive ID, value, effective/expiration dates, etc.

ProfileAccessInfo X X X X X X Read only fields to track profile usage (create, update and

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.

C o m m o n E l e m e n t s a n d A t t r i b u t e s

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:

< <

& &

> >

" "

‘ '

M a n a g e m e n t o f N o n - s t a n d a r d E n g l i s h C h a r a c t e r s

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


<Test>

<Test1>ఢ</Test1>

<Test1>§</Test1>

<Test1>乖</Test1>

<Test1>ڄ</Test1>

</Test>

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

<Test>

<Test1>ఢ</Test1>

<Test1>§</Test1>

<Test1>乖</Test1>

<Test1>ڄ</Test1>

</Test>

P r o f i l e U n i q u e I D

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>


C r e a t i n g P r o f i l e s

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.

H o w t o C r e a t e a P r o f i l e

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.

S a m p l e X M L C r e a t e P r o f i l e R e q u e s t

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"

Create Service 5



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.

S a m p l e X M L C r e a t e P r o f i l e S u c c e s s f u l R e s p o n s e

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.

S a m p l e X M L C r e a t e P r o f i l e E r r o r R e s p o n s e

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 [email protected]

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.




R e a d i n g P r o f i l e s

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>


Read Service 6


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


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




TaxInfo X


TemplateAssociatedFilters X X X X X X

VehicleRentalPref X X X X X X

S a m p l e X M L R e a d S u c c e s s f u l R e s p o n s e

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="[email protected]"

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.

C r e d i t C a r d T o k e n i z e r

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.

S a m p l e X M L R e a d E r r o r R e s p o n s e

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.


U p d a t i n g P r o f i l e s

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>

Update Service 7


</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


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


TaxInfo X


VehicleRentalPref X X


Type SubjectAreaName XPath

TRA

VEL

ER

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

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

TRA

VEL

AG

ENC

Y

Telephone /TravelAgency/Telephone

Email /TravelAgency/Email

Address /TravelAgency/Address

PaymentForm /TravelAgency/PaymentForm

AirlinePref /TravelAgency/PrefCollections/AirlinePref

STARData /TravelAgency/STARData


Type SubjectAreaName XPath

CO

RP

OR

ATI

ON

Telephone /Corporation/Telephone

Email /Corporation/Email

Address /Corporation/Address

STARData /Corporation/STARData

GR

OU

P P

RO

FILE

Telephone /GroupProfile/Telephone

Email /GroupProfile/Email

Address /GroupProfile/Address

PaymentForm /GroupProfile/PaymentForm

AirlinePref /GroupProfile/PrefCollections/AirlinePref

HotelPref /GroupProfile/PrefCollections/HotelPref

VehicleRentalPref /GroupProfile/PrefCollections/VehicleRentalPref

RailPref /GroupProfile/PrefCollections/RailPref

GroundTransportationPref /GroupProfile/PrefCollections/GroundTransportationPref

STARData /GroupProfile/STARData

TRA

VEL

AG

ENT

Telephone /TravelAgent/Telephone

Email /TravelAgent/Email

Address /TravelAgent/Address

CustLoyalty /TravelAgent/CustLoyalty

PaymentForm /TravelAgent/PaymentForm

AirlinePref /TravelAgent/PrefCollections/AirlinePref

STARData /TravelAgent/STARData

OP

ERA

TIO

NA

L P

RO

FILE

Telephone /OperationalProfile/Telephone

Email /OperationalProfile/Email

Address /OperationalProfile/Address

PaymentForm /OperationalProfile/PaymentForm

STARData /OperationalProfile/STARData


H o w t o U p d a t e a P r o f i l e u s i n g F u l l R e p l a c e

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">


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”)

H o w t o U p d a t e a P r o f i l e i g n o r i n g t i m e s t a m p c h e c k

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">


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>


S a m p l e X M L U p d a t e S u c c e s s f u l R e s p o n s e

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>

S a m p l e X M L U p d a t e E r r o r R e s p o n s e

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>

http://www.sabre.com/eps/schemas


<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>



S e a r c h i n g f o r P r o f i l e s

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.

O n l i n e P r o f i l e S e a r c h

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)

Search Service 8


• 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="[email protected]" />

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

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.

Profile1

…

Profile20

Profile21

Profile40

…

…

Profile60

Profiles returned in RS


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>


O f f l i n e P r o f i l e S e a r c h

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

the reservation process.

1. Are performed by an agency in order to

produce reports.

2. Use tight criteria, that involve very

selective fields with smaller amounts of profile

results returned.

2. Use filtering criteria that may be very

inclusive.

3. Are online (synchronous) operations that

return profiles within seconds.

3. Are offline (asynchronous) operations that

can produce results within a 24 hour time frame

4. Return single or a small list of profiles in

the search response.

4. Could return a large list of profiles in the

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.


user domain branched domains other

domains

Admin

owned jobs

EPS_OfflineJobCreateRQ

EPS_OfflineJobRetrieveRQ

EPS_OfflineJobReadResultRQ

EPS_OfflineJobCancelRQ

EPS_OfflineJobDeleteRQ






none

other users’

jobs







none

SuperUser

owned jobs











none

other users’

jobs











none

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">

http://www.sabre.com/eps/schemas%20/schemas/Sabre_OTA_ProfileCreateRQ.xsd



http://www.w3.org/2001/XMLSchema-instance






<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="[email protected]" />

</Job>


Sample Emails

Successful Offline Search Job Completion

From: [email protected] [mailto:[email protected]]

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: [email protected] [mailto:[email protected]]

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.



D e l e t i n g a n d R e s t o r i n g P r o f i l e s

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.

S a m p l e X M L P r o f i l e D e l e t e R e q u e s t

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

Delete/Restore Service 9


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>


S a m p l e X M L P r o f i l e D e l e t e S u c c e s s f u l R e s p o n s e

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.

S a m p l e X M L P r o f i l e D e l e t e E r r o r R e s p o n s e

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"

http://www.sabre.com/eps/schemas%20/schemas/Sabre_OTA_ProfileDeleteRQ.xsd

http://www.sabre.com/eps/schemas%20/schemas/Sabre_OTA_ProfileDeleteRQ.xsd





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

R e s t o r e P r o f i l e S e r v i c e

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),



O v e r v i e w

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.

S a m p l e X M L P r o f i l e H i s t o r y R e q u e s t

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

Profile History Service 10



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>

S a m p l e X M L P r o f i l e H i s t o r y S u c c e s s f u l R e s p o n s e

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="[email protected]"/>

</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 “[email protected]”, 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.

S a m p l e X M L P r o f i l e H i s t o r y E r r o r R e s p o n s e

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>



C o p y i n g / M o v i n g P r o f i l e s t o a B r a n c h e d P s e u d o C i t y C o d e

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.

M o v i n g a P r o f i l e t o a B r a n c h e d P C C

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.

Profile Data Management Service

11



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.

C o p y i n g a n A s s o c i a t i o n t o a B r a n c h e d P C C

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>


S h a r e d A s s o c i a t i o n o b j e c t s

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.


M e r g i n g P r o f i l e s

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.

H o w t o M e r g e a P r o f i l e

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:

Profile Merge Service 12


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


M e r g e p r o c e s s f l o w

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.

S a m p l e X M L P r o f i l e M e r g e R e q u e s t

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>


S y s t e m A c c e s s P e r m i s s i o n s

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.


P r o f i l e T o P N R S e r v i c e O v e r v i e w

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.

ProfileToPNR Service 13



FilterPath

TemporaryFilterPath

M o v i n g R e m a r k s t o P N R U s i n g a F i l t e r

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”.

M o v e O r d e r L o g i c f o r P r o f i l e s w i t h A s s o c i a t e d F o r m a t s a n d P r o f i l e s

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.

T h e F i l t e r P a t h

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

S p e c i f y i n g t h e P r o f i l e

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

S p e c i f y i n g t h e F i l t e r

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.


S e a r c h i n g f o r a F i l t e r

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.

S e a r c h i n g f o r a D e f a u l t F i l t e r

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

F i l t e r ’ s A s s o c i a t e d P r o f i l e s

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).


T e m p o r a r y F i l t e r P a t h

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="[email protected]" 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>

P r o f i l e T o P N R S e r v i c e R e s p o n s e M e s s a g e

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.

S h a r e d o b j e c t s i n P 2 P N R

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



P r o f i l e I n d e x

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.

P N R P r o f i l e I n d e x d i s p l a y

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.

D i s p l a y P r o f i l e u s i n g t h e P r o f i l e I n d e x v a l u e

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«


F i l t e r O v e r v i e w

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.

C r e a t i n g F i l t e r s

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.



Filters 14



H o w t o C r e a t e a F i l t e r



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.

S a m p l e X M L C r e a t e F i l t e r R e q u e s t

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.

S a m p l e X M L C r e a t e F i l t e r S u c c e s s f u l R e s p o n s e

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.


S a m p l e X M L C r e a t e F i l t e r E r r o r R e s p o n s e

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>


R e a d i n g F i l t e r s

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>


S a m p l e X M L R e a d F i l t e r S u c c e s s f u l R e s p o n s e

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="[email protected]" OrderSequenceNo="1" EmailTypeCode="BUS"/>

<Email EmailAddress="[email protected]" OrderSequenceNo="1"

EmailTypeCode="HOM"/>

<Email EmailAddress="[email protected]" 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.

S a m p l e X M L R e a d F i l t e r E r r o r R e s p o n s e

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>


U p d a t i n g F i l t e r s

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>


S a m p l e X M L F i l t e r U p d a t e S u c c e s s f u l R e s p o n s e

A successful update results in the following response.


Version="1">

<ResponseMessage>

<Success />

</ResponseMessage>

<Filter FilterID="3821" FilterName=”Name” DomainID="IM08">

</Filter>


S a m p l e X M L F i l t e r U p d a t e E r r o r R e s p o n s e

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.


S e a r c h i n g f o r F i l t e r s

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>


D e l e t i n g F i l t e r s

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.

S a m p l e X M L F i l t e r D e l e t e R e q u e s t

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.


S a m p l e X M L F i l t e r D e l e t e S u c c e s s f u l R e s p o n s e

A successful Filter Delete response is shown below:


<ResponseMessage>

<Success />

</ResponseMessage>


The <ResponseMessage> displays the <Success /> sub-element.

S a m p l e X M L F i l t e r D e l e t e E r r o r R e s p o n s e

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::.

O b j e c t i n h e r i t a n c e s c e n a r i o

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.


F o r m a t O v e r v i e w

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


I d e n t i f y i n g F o r m a t T y p e s

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:

Formats 15



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.

C r e a t i n g F o r m a t s

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.

H o w t o C r e a t e a F o r m a t



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.

S a m p l e X M L C r e a t e F o r m a t R e q u e s t

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:[email protected]</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.


S a m p l e X M L C r e a t e F o r m a t S u c c e s s f u l R e s p o n s e

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.

S a m p l e X M L C r e a t e F o r m a t E r r o r R e s p o n s e

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" />


U s i n g X P a t h E x p r e s s i o n s f o r F o r m a t s

• 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)

D a t e C o n v e r s i o n F e a t u r e s

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)

C o n d i t i o n a l X P a t h F o r m a t F u n c t i o n s

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

http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html


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:

amples 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:

Stored Data Substitution

Data

ABC XYZ

BC 123

‘ <space>

The substitution should have the following effect for the specified texts. Red means no substitution was

applied.

Stored Data Substitution

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 ()

P r o c e s s i n g F o r m a t D a t a

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.


R e a d F o r m a t s

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”/>


S a m p l e X M L F o r m a t R e a d S u c c e s s f u l R e s p o n s e

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.

S a m p l e X M L F o r m a t R e a d E r r o r R e s p o n s e

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>



U p d a t i n g F o r m a t s

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>


S a m p l e X M L U p d a t e F o r m a t S u c c e s s f u l R e s p o n s e

A successful update results in the following response:


Version="1">

<ResponseMessage>

<Success />

</ResponseMessage>

<Format FormatID="4567" FormatName=”Name” DomainID="A5BE">

</Format>


S a m p l e X M L U p d a t e F o r m a t E r r o r R e s p o n s e

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.


S e a r c h i n g f o r F o r m a t s

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>


D e l e t i n g F o r m a t s

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.

S a m p l e X M L F o r m a t D e l e t e R e q u e s t

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.


S a m p l e X M L F o r m a t D e l e t e S u c c e s s f u l R e s p o n s e

A successful Format Delete response is shown below:


<ResponseMessage>

<Success />

</ResponseMessage>


The <ResponseMessage> displays the <Success /> sub-element.

S a m p l e X M L F o r m a t D e l e t e E r r o r R e s p o n s e

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::.


O v e r v i e w

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.

Templates/Associations with Metadata 16


A s s o c i a t i o n O b j e c t

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.

T h e l o g i c o f t h e A s s o c i a t i o n o b j e c t

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


C r e a t i n g a n A s s o c i a t i o n o b j e c t

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

ClientContextCode

The same as in all other requests.




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,

AssociatedFormats etc.

Objects grouped by this Association. Same rules apply as when associating

objects directly to a profile.

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.

A t t a c h i n g a n A s s o c i a t i o n t o a p r o f i l e

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”/>



U p d a t i n g a n d D e l e t i n g A s s o c i a t i o n O b j e c t s

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>


S h a r e d A s s o c i a t i o n O b j e c t s

S h a r e d A s s o c i a t i o n o b j e c t s c r e a t i o n / u p d a t e

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="*">

S h a r e d A s s o c i a t i o n O b j e c t B u s i n e s s R u l e s

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>


A t t a c h i n g a n A s s o c i a t i o n t o a n o t h e r A s s o c i a t i o n ( c h i l d / p a r e n t

f u n c t i o n a l i t y )

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.


C h i l d A s s o c i a t i o n O b j e c t B u s i n e s s R u l e s

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.

B r a n c h A c c e s s C l o s e d

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>


V a l i d a t o r s

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.

S a m p l e V a l i d a t o r

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:



ClientContextCode

The same as in all other requests.

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.

S a m p l e V a l i d a t o r w i t h m u l t i p l e r u l e s

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>


V a l i d a t o r R u l e s d e s c r i p t i o n s

In the following sections all possible validation rules are described.

R e s t r i c t i o n

Defines if a specified element is required, not allowed or optional.





</ValidatorRule>

O c c u r r e n c e R u l e

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.

R e g e x p R u l e

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>


L i s t R u l e

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.

P r e - d e f i n e d R u l e

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>

M e t a d a t a

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>




ClientContextCode

The same as in other requests.

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)



B u l k R e a d S e r v i c e O v e r v i e w

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


B u l k R e a d – P r o f i l e s – R e q u e s t M e s s a g e

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

Bulk Read Services 17



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.

B u l k R e a d – P r o f i l e s – R e s p o n s e M e s s a g e

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>

B u l k R e a d E r r o r S c e n a r i o s

E r r o r r e s p o n s e

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>


W a r n i n g r e s p o n s e

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>


B u l k R e a d – A s s o c i a t i o n s – R e q u e s t M e s s a g e

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>


B u l k R e a d – A s s o c i a t i o n s – R e s p o n s e M e s s a g e

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>


B u l k R e a d – F o r m a t s – R e q u e s t M e s s a g e

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>


B u l k R e a d – F o r m a t s – R e s p o n s e M e s s a g e

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>


B u l k R e a d – F i l t e r s – R e q u e s t M e s s a g e

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>


B u l k R e a d – F i l t e r s – R e s p o n s e M e s s a g e

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>


B u l k R e a d – M e t a d a t a o b j e c t s – R e q u e s t M e s s a g e

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>


B u l k R e a d – M e t a d a t a O b j e c t s – R e s p o n s e M e s s a g e

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>


B u l k R e a d – V a l i d a t o r s – R e q u e s t M e s s a g e

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>


B u l k R e a d – V a l i d a t o r s – R e s p o n s e M e s s a g e

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>



O v e r v i e w

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.

S a m p l e R e t r i e v e C u s t o m F i e l d C o d e s X M L D a t a S e r v i c e

R e q u e s t

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>

Profile Data Service 18


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>

S a m p l e C r e a t e C u s t o m F i e l d C o d e s X M L D a t a S e r v i c e

R e q u e s t

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.

S a m p l e C r e a t e D i c t i o n a r y X M L D a t a S e r v i c e R e q u e s t

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>


S a m p l e R e a d D i c t i o n a r y X M L D a t a S e r v i c e R e q u e s t

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>


S a m p l e U p d a t e D i c t i o n a r y X M L D a t a S e r v i c e R e q u e s t

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.

S a m p l e D e l e t e D i c t i o n a r y X M L D a t a S e r v i c e R e q u e s t

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"/>




S a m p l e C o p y D i c t i o n a r y X M L D a t a S e r v i c e R e q u e s t

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>


D a t a S e r v i c e E r r o r R e s p o n s e

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>



R o l e s O v e r v i e w

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.

R o l e s M a n a g e m e n t

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

(Unrestricted

User)

ADMINPPP can display Profiles, Filters, and Formats; can create, display, edit and

delete Profiles and Filters; can move Profiles between Branch PCCs;

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,

MVDOMNPRF, RASC,

CRUDPRF, RVAL,

RMTD,

can display Profiles, Filters, and Formats; can create, display, edit and

delete Profiles and Filters; can move Profiles between Branch PCCs

Roles 19


Name of

STANDARD

Role Codes Role Description

Regular User RFMT, CRUDFLT, RTPL,

MVDOMNPRF, RASC,

CRUDPRF, RVAL,

RMTD

can display Profiles, Filters, and Formats; can create, read, edit and

delete Profiles and Filters; can move Profiles between Branch PCCs

Restricted User RPRF, RFLT, RFMT,

RMDT, RVAL, RASC

can display Profiles, Filters, Formats, and Associations (Templates)

• 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


C r e a t i n g a R o l e


under those Roles. Future enhancements may support creation and update of custom roles.

R e a d i n g a R o l e

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>

S a m p l e X M L R e a d R o l e E r r o r R e s p o n s e

<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>

U p d a t i n g a R o l e


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

S e a r c h i n g f o r a R o l e

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).

S a m p l e X M L S e a r c h R o l e s R e q u e s t

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.

D e l e t i n g a R o l e


under those Roles.

C o p y i n g o r M o v i n g a R o l e t o a n o t h e r D o m a i n

Copy/move of Role(s)to different domain (PCC) is not supported by the Sabre Profiles system.

A s s i g n i n g a R o l e t o a n A g e n t P r o f i l e

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.


S a b r e P r o f i l e s E N S O v e r v i e w

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.

E v e n t N o t i f i c a t i o n S e r v i c e s

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.

S a m p l e P a y l o a d f o r P r o f i l e E v e n t C r e a t e N o t i f i c a t i o n

<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>

Notification Services (ENS) 20



</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.

S a m p l e P a y l o a d f o r P r o f i l e E v e n t U p d a t e N o t i f i c a t i o n

<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>

S u m m a r y

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 . 1 S e c t i o n s P e n d i n g I m p l e m e n t a t i o n

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 P a r t i a l U p d a t e – P e n d i n g I m p l e m e n t a t i o n

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"


A – Sections Pending Implementation A


<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="[email protected]" >

</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 De

lete

Sub

tree

Ad

d

Sub

tree

Mo

dify

Sub

tree

/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 De

lete

Sub

tree

Ad

d

Sub

tree

Mo

dify

Sub

tree

/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 De

lete

Sub

tree

Ad

d

Sub

tree

Mo

dify

Sub

tree

/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 De

lete

Sub

tree

Ad

d

Sub

tree

Mo

dify

Sub

tree

/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 De

lete

Sub

tree

Ad

d

Sub

tree

Mo

dify

Sub

tree

/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 De

lete

Sub

tree

Ad

d

Sub

tree

Mo

dify

Sub

tree

/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 . T P A E x t e n s i o n s

TPA_Extensions/ProfileAccessInfo

It is read-only, but not updated in Read as well

TPA_Extentions/CustomerValueScore/ValueScoreUpdateInfo

A . 1 . 3 . P r o f i l e T o P N R S t a n d a r d P N R F o r m a t s

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.

Subject Area Name

Elements and

Attributes which are

moved to PNR

Sample Data Format in P2PNR Response (Application)

PersonName

NamePrefix MR -SurName NameSuffix/GivenName

MiddleName NamePrefix*InformationText

Example:

-BEAR JR/VERNON TOM MR*123-456-789

GivenName VERNON

MiddleName TOM

SurName BEAR

NameSuffix JR

@InformationText 123-456-789

Full Telephone

FullPhoneNumber 351-

609154207

9CityCodeFullPhoneNumber-

@LocationTypeCode @InformationText

Example:

9KRK351-609154207-A FULL AGY PHONE (-A if

@PNRTelephoneTagIndicator=Y)

@LocationTypeCode AGY

@InformationText Full AGY

Phone

@PhoneCityCode KRK


Subject Area Name

Elements and


moved to PNR


@PNRTelephoneTagIn

dicator Y/N

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.

Agency -A

Business -B

Company -B

Cell -C

Mobile -M

Home -H

Second home -H

Emergency -E

Fax -F

Unknown -U

Pager -P

Parsed Telephone

@PhoneNumber 351-

609154207

9CityCode@CountryCode-@AreaCode-

@PhoneNumberX@Extension-

@LocationTypeCode @InformationText

Example:

9DFW011-11-351-609154207X048-A PASED

HOM PHONE (-A if

@PNRTelephoneTagIndicator=Y)

9DFW011-11-351-609154207X048 PASED

HOM PHONE (no –A if

@PNRTelephoneTagIndicator=N)

@AreaCd 11

@CountryCode 011

@Extension 048

@LocationTypeCode AGY

@InformationText Parsed HOM

Phone

@PhoneCityCode DFW

@PNRTelephoneTagIn

dicator Y/N

Email

@EmailAddress TestEmail@s

abre.com

PE#@EmailAddress#@EmailUsageCode/@Em

ailRemark

Example:

PE#[email protected]#FR/EMAIL

REMARK

Note: The order moved to PNR is based upon

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

address entered in host is the last email

displayed in the PNR.

@EmailUsageCode FRM

@EmailRemark Email Remark


Subject Area Name

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

Address

@Attention Attention

If @LocationTypeCode=”AGY” (Agency) then

format is:

W-

@Attention#AddressLine1#AddressLine2#Add

ressLine3#AddressLine4#CityName StateCode

PostalCd#CountryCode

Example:

W-ATTENTION#LINE 1 LINE 2 LINE 3 LINE

4#Krakow MA 30-348#PL

If @LocationTypeCode=”BIL” (Billing) then

format is:

CC/N/@Attention

CC/A/AddressLine1 AddressLine2

AddressLine3 AddressLine4

CC/C/CityName, StateCode, CountryCode

CC/Z/PostalCd

Example:

CC/N/ATTENTION

CC/A/LINE 1 LINE 2 LINE 3 LINE4

CC/C/KRAKOW, MA, US

CC/Z/30-348

If @LocationTypeCode=”DEL” (Delivery)then

format is:

5DL-@Attention

5DL-Line1

5DL-Line2

AddressLine1 Line 1

AddressLine2 Line 2

AddressLine3 Line 3

AddressLine4 Line 4

CityName Krakow

StateCode MA

PostalCd 30-348


Subject Area Name

Elements and


moved to PNR


CountryCode PL

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)

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


Subject Area Name

Elements and


moved to PNR


• Unknown

PaymentForm

@BankCardVendorCod

e AX

1) For Payment Card (when

ServiceUsageTypeCode=”AL” or “OT”):

5-

*@BankCardVendorCode@CardNumber#@Ex

pireDate@InformationText

5-CH#CardHolderFullName

Example:

5-*AXXXXXXXXXXXXX7551#01/15-XN

5-CH#MAT BEAR

2) For PaymentCard with

ServiceUsageTypeCode=”CR” or “HL”:

5C¥/G@BankCardVendorCode@CardNumber

EXP @expiredate = MM YY-

@CardHolderName>SurName

5H¥/G@BankCardVendorCode@CardNumber

EXP @expiredate = MM YY-

@CardHolderName>SurName

Example:

5C¥/GCA543211234567890EXP 12 14-BEAR

5H¥/GCA543211234567890EXP 12 14-BEAR

3) For Cash (except

ServiceUsageTypeCode=”CR” and “HL”):

5-CASH@InformationText

Example:

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

@CardNumber 37830291431

7551

@ExpireDate 012015

@InformationText -XN or FOP

REMARK

CardHolderFullName MAT BEAR

Cash

@PNRCheckCode CHECK

@FirstRemark Y/N

PaymentForm>Gover

nmentWarrant

@FirstRemark Y/N

For GR:

5- (GovernmentWarrant/WarrantType)(

GovernmentWarrant/WarrantNumber)-

(InformationText)

Example: WarrantType GR, GGR, FGR


Subject Area Name

Elements and


moved to PNR


WarrantSubtype GOM, WPM,

ATR

5-GR¥1234567890ABC-GOVT WARRANT

INFORMATION

For GGR:

5-( GovernmentWarrant>WarrantType)(

GovernmentWarrant>WarrantySubtype)(Gov

ernmentWarrant>WarrantNumber)-

(GovernmentWarrant>DebtorCd)-

(GovernmentWarrant>ObjectCd)-

(InformationText)

Example:

5-GGRGOMABC1234567890-987654321XYZ-

123ABC-GOM FORM OF PAYMENT

For FGR:

5-(GovernmentWarrant>WarrantType)REQ-(

GovernmentWarrant>WarrantNumber)

Example:

5-FGRREQ-19876543002

WarrantNumber ABC1234567

89

DebtorCd 987654321XY

Z

ObjectCd 123ABC

PaymentForm>@Infor

mationText

Warrant

Information

PaymentForm/Virtual

Payment

@FirstRemark Y/N Depending on domain and PNR configuration

Virtual Payment can be moved to PNR in two

possible ways:

1) As a Remark

5-

*VCN(VirtualPayment/@CustomerAccountCd

)

Example:

5-*VCNIBM12345678

2) As a FOP

FOP*VCN(VirtualPayment/@CustomerAccoun

tCd)

Example:

FOP*VCNIBM12345678

@CustomerAccountCd IBM1234567

8

CustomerReferenceIn

fo

@BranchID 12 DK@BranchID@ReferenceID

Example:

DK123456

DK1234567

DK1234567890 @ReferenceID

3456, 34567,

34567890

Discounts

@VendorCode AF

For SUB Discount:

SC#/@VendorCode@ID

Example:

SC#/AF777710

For CID Discount: @ID 777710


Subject Area Name

Elements and


moved to PNR


@TypeCode SUB/CID

CID-@ID

Example:

CID-777710

Remarks @Text

5DL-SABRE

DRIVE DT

12345

@Text

Example:

5DL-SABRE DRIVE DT 12345

Corporate

TravelPolicy

@CTPName TEST

PGM.-PCC-@CTPName

Example:

PGM.-A2FE-TEST

@PCC A2FE

CustLoyalty

(FrequentFlayer)

@VendorCode UA FF@VendorCode@MembershipID/Associated

VendorCode-SurName/LastName

MiddleName

Example:

FFUA03111968186/AC-BEAR/VERNON VAN

@MembershipID 03111968186

@AssociatedVendorCo

de AC

GivenName Vernon

MiddleName Bear

SurName Van

SecureFlight

@IsSubjectToSecureFli

ghtRule Y

If RedressNumber is not set:

4DOCS/DB/@BirthDate/@GenderCode/SurN

ame NameSuffix/GivenName/MiddleName

3DOCS/DB/@BirthDate/@GenderCode/SurN

ame NameSuffix/GivenName/MiddleName

Example:

4DOCS/DB/05JUL12/M/BEAR

SR/VERNON/VAN


SR/VERNON/VAN

If RedressNumber is set:

4DOCS/DB/@BirthDate/@GenderCode/SurNa

me NameSuffix/GivenName/MiddleName



4DOCO//R/@RedressNumber///US

3DOCO//R/@RedressNumber///US

Example:

@BirthDate 2012-07-05

@GenredCode M

PersonName/GivenNa

me Tom

PersonName/MiddleN

ame Jimmy

PersonName/SurName Trammel

DocHolder/SurName Bear

DocHolder/GivenNam

e Vernon

DocHolder/MiddleNa

me Van


Subject Area Name

Elements and


moved to PNR


DocHolder/NameSuffix SR 4DOCS/DB/05JUL12/M/BEAR

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





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

@RedressNumber 123456

@KnownTravelerNum

ber 45678901