sabre profiles technical user guide - sabre dev studio...

Sabre Profiles Technical User Guide

May 2015

© 2015, Sabre Inc. All rights reserved.

Document Revision: 20120711.4.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 May 2015 Confidential and Proprietary Sabre Inc. ii

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 ............................................................................................................................................... 3 Authentication ............................................................................................................................................. 4 Authorization .............................................................................................................................................. 4 Confidentiality ............................................................................................................................................. 4

Network Connectivity ....................................................................................................................................... 5 Web Services Sessions ................................................................................................................................... 5

SessionCreateRQ Request XML Example ................................................................................................. 5 The Envelope ............................................................................................................................................. 5 The SOAP Payload .................................................................................................................................... 6 The SOAP Envelope .................................................................................................................................. 6 Ending the Session ..................................................................................................................................... 7

Credit Card Data Security ............................................................................................................................... 9 Access ........................................................................................................................................................ 9 Storage and Internal Security Measures .................................................................................................... 9

Technical Support ......................................................................................................................................... 10 Email ........................................................................................................................................................ 10 Additional Support .................................................................................................................................... 10

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 1

Activation ....................................................................................................................................................... 11 Types of Web Services ................................................................................................................................. 12

Session Management Services ................................................................................................................ 12 Sabre Profiles Services ............................................................................................................................ 12

Message Structure ........................................................................................................................................ 16 Requesting Payload Content ......................................................................................................................... 16 Web Services Error Handling ........................................................................................................................ 18

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

Profile Types ................................................................................................................................................. 20 Traveler ......................................................................................................................................................... 21

Logic for specific schema elements/attributes within the Profile ............................................................... 21 Operational .................................................................................................................................................... 23 Corporate ...................................................................................................................................................... 23 Group ............................................................................................................................................................ 23 Agency .......................................................................................................................................................... 24

Sabre Profiles Technical User Guide May 2015 Confidential and Proprietary Sabre Inc. iii

Agent ............................................................................................................................................................. 24 Replication of Sabre Host EPRs into Agent Profiles ................................................................................. 24

Common attributes within the Payload .......................................................................................................... 27 ClientContextCode ................................................................................................................................... 27

Profile SubTypes ........................................................................................................................................... 28 How to Determine the Profile Data Needed .................................................................................................. 29 Use of Dictionary Control Table Values ......................................................................................................... 29 Use of Status codes ...................................................................................................................................... 31

Domain “Status”........................................................................................................................................ 32 Profile “Status” .......................................................................................................................................... 32

Profile Associations ....................................................................................................................................... 33 Common Rules and Elements across Profile Types ..................................................................................... 34

Single Entity ............................................................................................................................................. 38 Common Elements and Attributes ............................................................................................................ 39 Management of Non-standard English Characters ................................................................................... 40

Profile UniqueID ............................................................................................................................................ 40

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

Creating Profiles ............................................................................................................................................ 42 How to Create a Profile ............................................................................................................................ 42 Sample XML Create Profile Request ........................................................................................................ 42 Sample XML Create Profile Successful Response ................................................................................... 44 Sample XML Create Profile Error Response ............................................................................................ 44

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

Reading Profiles ............................................................................................................................................ 46 Sample XML Read Successful Response ................................................................................................ 47 Credit Card Tokenizer .............................................................................................................................. 47 xSample XML Read Error Response ........................................................................................................ 49

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

Updating Profiles ........................................................................................................................................... 51 How to Update a Profile using Full Replace ............................................................................................. 51 Sample XML Update Successful Response ......................................................................................... 5352 Sample XML Update Error Response .................................................................................................. 5352

S e a r c h S e r v i c e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4

Searching for Profiles .................................................................................................................................... 54 Online Profile Search ................................................................................................................................ 54 Credit Card Tokenizer .............................................................................................................................. 54 Offline Profile Search ................................................................................................................................ 62

Sabre Profiles Technical User Guide May 2015 Confidential and Proprietary Sabre Inc. iv

D e l e t e / R e s t o r e S e r v i c e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5 7 6

Deleting and Restoring Profiles ................................................................................................................. 7576 Sample XML Profile Delete Request .................................................................................................... 7576 Sample XML Profile Delete Successful Response ............................................................................... 7677 Sample XML Profile Delete Error Response ........................................................................................ 7677

Restore Profile Service .............................................................................................................................. 7778

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

Overview ................................................................................................................................................... 7879 Sample XML Profile History Request ........................................................................................................ 7879 Sample XML Profile History Successful Response ................................................................................... 7980 Sample XML Profile History Error Response ............................................................................................ 8384

D a t a S e r v i c e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5 8 6

Overview ................................................................................................................................................... 8586 Sample Retrieve Custom Field Codes XML Data Service Request .......................................................... 8586 Sample Create Custom Field Codes XML Data Service Request ............................................................. 8687 Sample Create Dictionary XML Data Service Request ............................................................................. 8788 Sample Read Dictionary XML Data Service Request ............................................................................... 8889 Sample Update Dictionary XML Data Service Request............................................................................. 8990 Sample Delete Dictionary XML Data Service Request .............................................................................. 9293 Sample Copy Dictionary XML Data Service Request ................................................................................ 9495 Data Service Error Response .................................................................................................................... 9596

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

Copying/Moving Profiles to a Branched Psuedo City Code ....................................................................... 9697 Moving a Profile to a Branched PCC .................................................................................................... 9697 Copying an AssociationID (Template) to a Branched PCC .................................................................. 9899 Shared Association objects .................................................................................................................. 9899

R o l e s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 0 3 1 0 2

Roles Overview ..................................................................................................................................... 103102 Roles Management .......................................................................................................................... 103102

Creating a Role ..................................................................................................................................... 108107 Reading a Role ..................................................................................................................................... 108107

Sample XML Read Role Error Response ......................................................................................... 108107 Updating a Role .................................................................................................................................... 108107 Searching for a Role.............................................................................................................................. 108107

Sample XML Search Roles Request ................................................................................................ 109108 Deleting a Role ...................................................................................................................................... 109108 Copying or Moving a Role to another Domain ....................................................................................... 109108

Sabre Profiles Technical User Guide May 2015 Confidential and Proprietary Sabre Inc. v

Assigning a Role to an Agent Profile ..................................................................................................... 109108

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

ProfileToPNR Service Overview ........................................................................................................... 110109 Moving Remarks to PNR Using A Filter ............................................................................................ 111110 Move Order Logic for Profiles with Associated Formats and Profiles ............................................... 112111

The Filter Path ....................................................................................................................................... 112111 Specifying the Profile ........................................................................................................................ 113112 Specifying the Filter .......................................................................................................................... 114113 Searching for a Filter ........................................................................................................................ 114113 Searching for a Default Filter ............................................................................................................ 115114 Filter’s Associated Profiles ............................................................................................................... 116115

Temporary Filter Path ............................................................................................................................ 118117 ProfileToPNR Service Response Message ........................................................................................... 120119 Shared objects in P2PNR ...................................................................................................................... 120119 Profile Index .......................................................................................................................................... 128123 PNR Profile Index display ...................................................................................................................... 128124

Display Profile using the Profile Index value ..................................................................................... 130125

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

Filter Overview ...................................................................................................................................... 131126 Creating Filters ...................................................................................................................................... 131126

How to Create a Filter ....................................................................................................................... 132127 Sample XML Create Filter Request .................................................................................................. 132127 Sample XML Create Filter Successful Response ............................................................................. 134129 Sample XML Create Filter Error Response ...................................................................................... 134129

Reading Filters ...................................................................................................................................... 135130 Sample XML Read Filter Successful Response ............................................................................... 135130 Sample XML Read Filter Error Response ........................................................................................ 136131

Updating Filters ..................................................................................................................................... 136131 Sample XML Filter Update Successful Response ............................................................................ 136131 Sample XML Filter Update Error Response ..................................................................................... 137132

Searching for Filters .............................................................................................................................. 137132 Deleting Filters ...................................................................................................................................... 138133

Sample XML Filter Delete Request .................................................................................................. 138133 Sample XML Filter Delete Successful Response ............................................................................. 139134 Sample XML Filter Delete Error Response ....................................................................................... 139134

Object inheritance scenario ................................................................................................................... 139134

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

Format Overview ................................................................................................................................... 141136 Identifying Format Types ....................................................................................................................... 141136 Creating Formats................................................................................................................................... 145141

Sabre Profiles Technical User Guide May 2015 Confidential and Proprietary Sabre Inc. vi

How to Create a Format ................................................................................................................... 145141 Sample XML Create Format Request ............................................................................................... 145141 Sample XML Create Format Successful Response.......................................................................... 147143 Sample XML Create Format Error Response ................................................................................... 148144 Using XPath Expressions for Formats .............................................................................................. 148144 Date Conversion Features ................................................................................................................ 150146 Conditional XPath Format Functions ................................................................................................ 151147

Read Formats ....................................................................................................................................... 153149 Sample XML Format Read Successful Response ............................................................................ 154150 Sample XML Format Read Error Response ..................................................................................... 154150

Updating Formats .................................................................................................................................. 154150 Sample XML Update Format Successful Response ......................................................................... 155151 Sample XML Update Format Error Response .................................................................................. 155151

Searching for Formats ........................................................................................................................... 155151 Deleting Formats ................................................................................................................................... 157153

Sample XML Format Delete Request ............................................................................................... 157153 Sample XML Format Delete Successful Response .......................................................................... 157153 Sample XML Format Delete Error Response ................................................................................... 158154

Processing Format Data ........................................................................................................................ 158154

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 5 9 1 5 5

Overview ............................................................................................................................................... 159155 Association Object................................................................................................................................. 160156

Creating an Association object ......................................................................................................... 161157 Attaching an Association to a profile ................................................................................................. 162158 Updating and Deleting Association Objects ...................................................................................... 163159

Shared Association Objects .................................................................................................................. 164160 Shared Association objects creation/update ..................................................................................... 164160 Shared Association Object Business Rules ...................................................................................... 165161 Branch Access Closed ..................................................................................................................... 167163

Validators .............................................................................................................................................. 168163 Sample Validator .............................................................................................................................. 169164 Sample Validator with multiple rules ................................................................................................. 170165

Validator Rules descriptions .................................................................................................................. 171165 Restriction ........................................................................................................................................ 171165 Occurrence Rule............................................................................................................................... 171166 Regexp Rule ..................................................................................................................................... 171166 Pre-defined Rule............................................................................................................................... 171166

Metadata ............................................................................................................................................... 172167

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

Bulk Read Service Overview ................................................................................................................. 174169 Bulk Read – Profiles – Request Message ............................................................................................. 174169

Bulk Read – Profiles – Response Message ..................................................................................... 175170

Sabre Profiles Technical User Guide May 2015 Confidential and Proprietary Sabre Inc. vii

Profile Bulk Read Error Scenarios .................................................................................................... 176171 Bulk Read – Associations – Request Message ..................................................................................... 176171

Bulk Read – Associations – Response Message ............................................................................. 177172 Associations Bulk Read Error Scenarios .......................................................................................... 179174

Bulk Read – Formats – Request Message ............................................................................................ 179174 Bulk Read – Formats – Response Message .................................................................................... 180175 Format Bulk Read Error Scenarios ................................................................................................... 180175

Bulk Read – Filters – Request Message ............................................................................................... 180175 Bulk Read – Filters – Response Message ........................................................................................ 181176 Filter Bulk Read Error Scenarios ...................................................................................................... 181176

N o t i f i c a t i o n S e r v i c e s ( E N S a n d P N S ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 8 2 1 7 7

Sabre Profiles ENS Overview ............................................................................................................... 182177 Event Notification Services ............................................................................................................... 182177

Sample Payload for Profile Event Create Notification ........................................................................... 182177 Sample Payload for Profile Event Update Notification........................................................................... 183178 Summary ............................................................................................................................................... 183178 Sabre Profiles Notification Service (PNS) ............................................................................................. 184179

Web Services Event Technology Overview ...................................................................................... 185180 About Profiles Notification Service .................................................................................................... 185180 Receiving and processing event notifications ................................................................................... 188183 Event Topic Notification Messages................................................................................................... 189184 Ordering and Registration Phase ..................................................................................................... 193188 Notification examples ....................................................................................................................... 194189 Outage email notification .................................................................................................................. 196191

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 9 8 1 9 3

A.1 Sections Pending Implementation ........................................................................................... 198193 A.1.1 PARTIAL UPDATE – Pending Implementation ................................................................ 198193 A.1.2. TPA Extensions ..................................................................................................................... 199194 A.1.3. ProfileToPNR Standard PNR Formats .................................................................................. 199194

Sabre Profiles Technical User Guide May 2015 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 ICE 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.

OpenTravel Alliance specification (http://www.opentravel.org) - used as the basis for the

profile request and response XML payloads.

Introduction 1

http://www.opentravel.org/


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

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:PartyId type="urn:x12.org:IO5:01">123123</eb:PartyId> </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: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>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

<?xml version="1.0" encoding="UTF-8"?> <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!ICESMSLB\/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 application 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'?> <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="2.0"> <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:Timestamp>2004-02-15T11:15:12Z</eb:Timestamp> <eb:TimeToLive>2004-02-15T11:15:12Z</eb:TimeToLive> </eb:MessageData> </eb:MessageHeader> <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/12/utility"> <wsse:BinarySecurityToken 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> </SOAP-ENV:Envelope>

Note: The following is the second multipart MIME part containing the Sabre XML message:

<?xml version="1.0" encoding="UTF-8"?> <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 attribute in the user’s IDM (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].

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.

mailto:[email protected]


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 ICE (Sabre’s Integrated Computing Environment).

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

Accessing Sabre Profiles Web

Services 3


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 particular 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 later in 2015. 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. If there is no timestamp in the request the

latest profile stored by Sabre is returned in the Sabre_OTA_ProfileReadRS XML response

message. If a timestamp is specified in the request, a historical profile is returned if the

timestamp matches a valid timestamp for the profile in the Sabre database. Historical

timestamps can be known by reading the latest profile which includes an XML <SabreAccess>

element containing all the historical timestamps related to a profile.

The Sabre_OTA_ProfileReadRQ message contains a <TPA_Idenity> 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 has the ability to 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. In this

case, the Profile read returns all subject areas except the subject areas mentioned in

<IgnoreReadSubjectAreas>.

A list of subject area names that can be used within PartialRead and IgnoreRead is found below:

STARData

CustomerValueScore

RelatedIndividual


CustLoyalty

PersonName

EnrollmentInfo

PaymentForm

Address

Email

Telephone

Login

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 entire profile is 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 a 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 or don’t have the

purge date at all. 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 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. Service supports move and copy of single profile or AssociationID

(Template) with all associated formats, filters, metadata, validators, associations (excluding

associated profiles), or move of entire domain profile data with all associations.

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. On the other hand, when

Temporary Filter path is used, the Profile data fields to be moved is specified in 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 the actions for the past 24 months which were performed on the

Profile.

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, while currently they 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.

When creating and updating Sabre Profiles objects (Profiles, Association Objects, Filters, and

Formats), the same DomainID (PCC) should be used.

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

However, if Branch access rights exist 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


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 type of errors occur within the Sabre Web Services infrastructure, and they are caused by faulty messages from the web client or problems with the Sabre Profiles Web Services. The infrastructure detects and generates these errors, and returns them as SOAP faults, with or without ebXML headers.

Business application errors – These errors are generated by the business application services that are called by the SWS infrastructure. The web client request, the network routing between the SWS infrastructure and the business application service, or the business application service can cause these types of errors. They are returned to clients in the ErrorRS XML response format.

System errors generated by web clients – These are caused by the web clients themselves and are external to the Sabre Profiles Web Services. They normally occur in the development environment, and are returned to the client.

When the response contains the <soap-env:fault> element, an HTTP status code of 500 is returned. If no SOAP fault exists, HTTP Status Code 200 is returned. Other codes depend on the request and are shown later in the document.

Any Sabre Profiles system errors returned will include an error code for each error message. The list

of exception message errors and their codes can be found on Sabre’s Dev Studio at

https://developer.sabre.com under Sabre Profile Services.

The general error message structure will be formatted as shown below in the xml response.

<ResponseMessage>

<Errors>

<ErrorMessage ErrorCode=”123”> </ErrorMessage>

</ResponseMessage>

Some common error messages are listed below, such as those returned by CreateSessionRQ when:

a) wrong values are passed in Organization / Domain

b) when the account has not been activated for SWS or

c) when the passcode is locked or invalid

i.e.

<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"/>

</soap-env:Header>

<soap-env:Body>

<soap-env:Fault>

<faultcode>soap-env:Client.AuthenticationFailed</faultcode>

https://developer.sabre.com/


<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=“ABC” 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 is

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.

Sabre Profile Types 4


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.

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

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 in order 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’.

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:

Preference Collections Element in Traveler Profile

If using RailStationInfo to store data, there is a connection between three attributes inside the

system. ContextCode attribute is needed to distinguish the coding standard (IBNR or IATA) for

Station Codes and allows the user to choose if he wants to see/use IBNR vs. IATA codes. The

mandatory RailStationCode attribute is used to store the station code preference.



IBNR Rail codes use the UIC station reference which always consists of 7 to 8 digits, beginning with a

2-digit UIC country code (the UIC Country Code is a two digit number used to identify member

countries of the International Union of Railways).

A sample of the RailStationInfo is shown below:

<RailStationPref PreferLevelCode="P"> <RailStationInfo RailStationCode="761385" LocationTypeCode="STA" ContextCode="IBNR" /> </RailStationPref>

IATA Rail codes use a 3-alpha station reference:

<RailStationPref PreferLevelCode="P"> <RailStationInfo RailStationCode="BZY" LocationTypeCode="APT" ContextCode="IATA" /> </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

http://en.wikipedia.org/wiki/International_Union_of_Railways


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.



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 the purpose of 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 of them, the GRP profile will reference the TVL profile in the association section and TVL profile will have GRP in the association section. NOTE: For current Profiles supported elements, attributes, and number of instances allowed of


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

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


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 if necessary. 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=”ABC”, 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.


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

EventNotification or ProfileNotification Services . 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 many examples of XML and additional examples are available in the Sabre

Dev Studio for Sabre Web Services for different profile types and objects available within Sabre

Profiles.

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

In order to maintain data standardization, Sabre Profiles has implemented a number of “dictionary

tables” for controlled table values. These controlled table values prevent the user from entering

incorrect or inconsistent values in the XML messages for profile data fields. There are a number of

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

SabreAPI Dev Studio at: https://developer.sabre.com. From there, you can select the Control Files

to download.



Note: An easy way to identify from 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 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 the majority of the operations are enabled in this state, it is considered that the Domain is in

validation mode.

In order 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 ”

Similar to 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 IN DL

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

DataSrvc OK OK X

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. 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 as well. 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 under which section of the document the details of those elements will be covered. That way, 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 AGT CRP AGY OPX GRP Description

Customer X

Parent element for Traveler under which

the rest of the traveler elements can be

found such as name, phone, 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.

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



EmergencyContactPerson 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

Information about where the individual is

employed including employee number, cost

centers, departments, etc.

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

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

Stores preferences by trip type, geographic

origin or destination and includes options

for Airport preferences, seats, cabin, meals,

preferred airlines, etc.

HotelPref



for Preferred hotel vendors, property, rates,

roomType, etc.

VehicleRentalPref



for Preferred rental car vendors, rates,

vehicle types, etc.

RailPref



for Rail stations, seats, cabin, meals,

vendors, upgrades, etc.

GroundTransportationPref



for Preferred bus or limo vendors, rates,

aggregators, etc.

TPAMarkertingPreference

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

Special Service Request information

including codes and descriptions (i.e. WHCR

- Wheelchair, etc.)

OSI X

X Other Service Request information including

codes and descriptions

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

BusinessSystemIdentityInfo 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

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

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)



ProfileAccessInfo X X X X X X

Read only fields to track profile usage

(create, update and access)

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.

SabreSecurityEntity

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.

EmploymentInfo

X X

X

Information on employment including

employee id, title, cost center, division,

department, company, business unit, etc.

S i n g l e E n t i t y

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.

While the PersonName element allows for multiple instances (up to 25), multiple instances of PersonName can only be used in combination with Language selection with the intent to illustrate a different representation of the same 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 in a web application or marketing material.)


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. 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 Travel Network. 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 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 the 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 be used when the user needs to specify the particular

order within an element that has 2 or more instances (i.e. 2 or more phone numbers, etc.)

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

if not specified, the Sequence Number is set automatically by the Sabre Profiles system. If the

LanguageIDCode is not specified, it will be set to the default value which is ‘EN-US’.

Please review carefully the “Traveler Profile” section below, as the majority 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

Sabre Profiles allows storage and management of double-byte characters and supports special

characters including Indian/Chinese Double Byte& Arabic ASCII characters in XML, and also for

special Sabre characters Such as the “Cross of Loraine”, “Change Key”, and “End Item”.

All Sabre special characters are stored as Unicode values:

Cross of Loraine ¥ : ¥

Change key ¤ : ¤

End item § : §

Entries Display in a web page

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

<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 the number 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 is what links profiles to PNRs and ties this data together. However, this profile

index does not include a reference to the PCC which owns the profile from where it was moved. The

UniqueID used for the Index is unique across all 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"

PrimaryLanguageIDCode="EN-US">

<TPA_Identity UniqueID="*" ProfileTypeCode="TVL" ClientCode="TN"

ClientContextCode=“ABC” ProfilePurgeNoOfDays="5" DomainID="A5BE" ProfileName="John123" ProfileStatusCode="AC" ProfileDescription="Travelr 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 the 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:

<?xml version="1.0" encoding="UTF-8"?> <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">

After this section is the element <Profile> with the following attributes: CreateDateTime,

UpdateDateTime and PrimaryLanguageIDCode. The first two of these attributes are required and the last

one 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=“ABC” ProfilePurgeNoOfDays="365" DomainID="A5BE"

ProfileName="John123" ProfileStatusCode="AC"

Create Service 5



ProfileDescription="Traveler sample" ProfileNameModifyIndicator="Y"> </TPA_Identity>

The following attributes: UniqueID, ProfileType, ClientCode, ClientContextCode and DomainID are

required. In the example above, the UniqueID has been set to “*” which means that the valid unique

identifier will be generated on the database side. The ProfileTypeCode has been set to “TVL” which means

that the profile to be created is of the 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

ProfileTypeCode.xml (as part of the Dictionary Control Table values referenced in the Sabre Dev Studio).

The ClientCode should be set to “TN” for Sabre Travel Network customers.

The ClientContextCode is mandatory and Sabre Travel Network customers should be using your own

ClientContextCode, or you can use the temporary code of “EXT” until your code is assigned. Other values

for other clients are specified in TPA_Identity_ClientContextCode.xml (as part of the Dictionary Control

Table values referenced in the 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>EXT</CLIENTCONTEXTCODE>

<DESCRIPTION>External TN Application</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.

It is recommended that a ProfileName be defined in the payload for CreateRQ for Sabre Travel

Network customers to support seamless transition of existing commands used to move the

Profile to PNR which is covered in a separate section.

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, as long as the ProfileStatus=”AC” it will

remain, but once the ProfileStatus=”DL” (Delete), it will be removed that same day the

ProfileStatus was changed to Delete. The status determines the action taken if removal is

requested on the Profile regardless of the number defined in the ProfilePurgeNoOfDays attribute.




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 appropriate error message.

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

The Response message contains a Profile section, which returns a subset of information about the newly created profile. 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> </Sabre_OTA_ProfileCreateRS> 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: <Sabre_OTA_ProfileCreateRS Version="1"> <ResponseMessage> <Errors>


<ErrorMessage ErrorCode=”123”>C:::PRF::Invalid TPA_Identity data</ErrorMessage> </Errors> </ResponseMessage>

<Profile ClientCode="TN" ClientContextCode=“ABC” UniqueID="*" ProfileTypeCode="TVL" ProfileName="ABCSTAR" DomainID=“A5BE” DomainID=“A5BE” ProfileStatusCode="AC">

<Login [email protected] PasswordHash="gra8EoFe8RBh+iBMY+04p8oLguQ4H7q6hJ4HXLEZnksbQ6rI+YqWdUfiv4JrWTZMfoo="/>

</Profile> </Sabre_OTA_ProfileCreateRS> In the example above the profile could not have been created because in the Sabre Profiles database a profile already exists with the same credentials (with the same Login section). The error message has been prefixed with “C:::PRF::”, which basically 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 which was supposed to be created. The only difference between 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 the Sabre Dev Studio under Sabre Profiles Services.




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

Profiles customer can retrieve a traveler profile in 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" xsi:schemaLocation="http://www.sabre.com/eps/schemas

schemas\Sabre_OTA_ProfileReadRQ.xsd" Version="1.0"> <Profile> <TPA_Identity UniqueID="4250" ProfileType="TVL" ClientCode="TN" DomainID=“A5BE” ClientContextCode=“ABC”> </TPA_Identity> </Profile> </Sabre_OTA_ProfileReadRQ>

If a profile has been updated multiple times, historical snapshots of the profile can be retrieved by

including the last modified date timestamp. If no timestamp is specified in the Read Request, then the

most recent snapshot of the profile is retrieved (refer to the examples above).


schemas\Sabre_OTA_ProfileReadRQ.xsd" Version="1.0" TimeStamp="2008-06-06T14:51:46.317"> <Profile> <TPA_Identity UniqueID="4256" ProfileType="TVL" ClientCode="TN" DomainID="TN" ClientContextCode=“ABC”> <Login LoginID="[email protected]" PasswordHash="gra8EoFe8RBh+iBMY+uQ4H7q6hJ4HXnksb ="/> </TPA_Identity> </Profile> </Sabre_OTA_ProfileReadRQ>

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

Read Service 6


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=“ABC” UniqueID="100001069" ProfileTypeCode="TVL" ProfileName="MIGR4GTTVL" DomainID="A5BE"/> <PartialReadSubjectAreas><SubjectAreaName>STARData</SubjectAreaName></PartialReadSubjectAreas> </Profile> </Sabre_OTA_ProfileReadRQ>

<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>. 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=“ABC” UniqueID="100001069" ProfileTypeCode="TVL" ProfileName="MIGR4GTTVL" DomainID="B0DE"/> <IgnoreReadSubjectAreas><SubjectAreaName>STARData</SubjectAreaName></IgnoreReadSubjectAreas> </Profile> </Sabre_OTA_ProfileReadRQ>

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 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 EPR Keywords of the agent which was used to create the session.

If the agent’s account (EPR) does not have the Keyword ‘CCVIEW’ assigned (or if the OSCCVIEW ICE attribute is not assigned) then the credit card number in 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 ICE attribute assigned, the CardNumber will be returned in the Read response: <PaymentForm DisplaySequenceNo="1" OrderSequenceNo="1" TripTypeCode="LS" ServiceUsageTypeCode="AL" InformationText="PaymentForm"> <PaymentCard CardTypeCode="CR" BankCardVendorCode="BA" CardNumber="371111111111111" MaskedCardNumber="1111" CCViewAccess="Y" EffectiveDate="012016" ExpireDate="012018" 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 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=“ABC” 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=“ABC” CreditBankIndicator="N" DomainID="A5CE" ProfileRelationTypeCode="AL"/> <AssociatedProfiles AssocFiltersInd="N" AssocProfileDescription="Profile desc" AssocProfileTypeCode="TVL" AssocUniqueID="101333344" ClientCode="TN" ClientContextCode=“ABC” DomainID="A5CE" ProfileRelationTypeCode="AL"/> <AssociatedProfiles AssocFiltersInd="Y" AssocProfileDescription="2008-06-06 profile" AssocProfileTypeCode="TVL" AssocUniqueID="101333332" ClientCode="TN" ClientContextCode=“ABC” DomainID="A5CE" ProfileRelationTypeCode="AL"/> <NumberOfAssocProfiles Traveler="3"/> </TPA_Extensions> </Traveler> </Profile> </Sabre_OTA_ProfileReadRS>

The <NumberOfAssocProfiles> element indicates the total number of associations attached to the profile. This includes all associations that the profile being Read is associated to and the number of profiles associated from another profile to that profile. The total count of Traveler, Travel Agent, Travel Agency, Corporation, Group and Operational profiles is included in this section.

x 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> <ErrorMessage ErrorCode=”123”>

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> </Sabre_OTA_ProfileReadRS> 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 completely updated by 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 method.

Timestamps are Profile system generated 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.

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

The full traveler profile update request is shown below: <?xml version="1.0" encoding="UTF-8"?> <Sabre_OTA_ProfileUpdateRQ Version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.sabre.com/eps/schemas

schemas\Sabre_OTA_ProfileUpdateRQ.xsd"> <ProfileInfo> <Profile CreateDateTime="2008-02-18T12:30:55.037" UpdateDateTime="2008-02-26T09:26:12.211" PrimaryLangIDCode="EN-US"> <TPA_Identity UniqueID="4259" ProfileTypeCode="TVL" ClientContextCode=“ABC”

ClientCode="TN" ProfileStatus="IN" DomainID=“A5BE” ProfileName="Updated Profile" ProfilePurgeNoOfDays="7"> <Login LoginID="[email protected]" 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>

Update Service 7


</ProfileInfo> </Sabre_OTA_ProfileUpdateRQ>

In order to successfully update the profile (Full Update), 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.

This section is optional but once provided, it will be validated. If the validation process does not succeed, an appropriate 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, whereas the second one is for saving the new profile data which was provided in the FullUpdateRQ.

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:<?xml version="1.0" encoding="UTF-8"?> <Sabre_OTA_ProfileUpdateRQ Version="1.0" IgnoreTimeStampCheck=”Y” xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.sabre.com/eps/schemas

schemas\Sabre_OTA_ProfileUpdateRQ.xsd"> <ProfileInfo> <Profile CreateDateTime="2008-02-18T12:30:55.037" UpdateDateTime="2008-02-26T09:26:12.211" PrimaryLangIDCode="EN-US"> <TPA_Identity UniqueID="4259" ProfileTypeCode="TVL" ClientContextCode=“ABC”

ClientCode="TN" ProfileStatus="IN" DomainID=“A5BE” ProfileName="Updated Profile" ProfilePurgeNoOfDays="7"> <Login LoginID="[email protected]" 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> </Sabre_OTA_ProfileUpdateRQ>


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 some 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> <ErrorMessage ErrorCode=”123”> U:::LoginID/Password was not specified for ABC profile </ErrorMessage> </Errors> </ResponseMessage>

<Profile ClientCode="TN" ClientContextCode=“ABC” UniqueID="34" ProfileTypeCode="TVL" ProfileName="NetCheck Profile" ProfileDescription="NetCheck Agency Test Profile" DomainID="ABC1" ProfileStatusCode="AC"/>

</Sabre_OTA_ProfileUpdateRS> In the above example the ABC profile could not be updated, because the Login section was not specified

in the incoming FullUpdateRQ.


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 specify the search criteria and to find the matching profiles in

the Sabre Profiles database. These are considered Online searches using 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’) or to ‘ALL’. In the second scenario, the user can search for profiles of each and every

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

the matching profiles. Otherwise, the user will get the TPA_Identity sections along with other profile data.

In the TPA_Identity Section there are two required attributes, which are the ClientCode (which is TN for

Sabre Travel Network clients) and the ClientContextCode (which identifies the calling system. Sabre Travel

Network customers should use their own ClientContextCode). The rest of the search criteria in this section

is optional, however, if any other qualifiers are added, they will narrow the results set.

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

A web service user can request credit card numbers returned in a Search 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.

Search Service 8


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" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.sabre.com/eps/schemas schemas\Sabre_OTA_ProfileSearchRQ.xsd"> <ProfileSearchCriteria ProfileNameOnly="Yes" SearchOperationType="AND"> <TPA_Identity DomainID=“A5BE” ClientCode="TN" ProfileTypeCode="TVL" ProfileName="MYS*" /> <Traveler Surname="Remik" GivenName="Smith"/> <Email EmailAddress="%" /> <CustomerReferenceInfo ReferenceID="123" Type="Ref" /> <AssociatedProfiles AssocProfileType="TVL" AssocProfileName="Greg123"/> </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. 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 preceeded 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

Apart from the SearchOperationType and the ProfileNameOnly, a user can specify the following two attributes: PageNumber and ReturnCount. These two attributes are used to do the Repetitive Search. This extra functionality has been added in order 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. Basically, this functionality covers the “Give me the next (n) profiles” scenario. To illustrate how this functionality actually 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. Now, when the next 20 profiles are retrieved, 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" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="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=“ABC” ProfileTypeCode="TVL"/> <Traveler Surname="Bear" GivenName="Vernon"/> <Email EmailAddress="Bear.vernon*" /> </ProfileSearchCriteria> </Sabre_OTA_ProfileSearchRQ>

Sample XML – Include Shared Association objects – Request/Response

When creating a profile user might want to perform a search to display all available association objects to him. By setting AssociationSearchCriteria/Association/@IncludeShared to “Y” user is requesting to include all shared Association objects he has access to. This way all local Association objects – from domain the user is AAA’d into - and all shared Association objects – from all branched domains – will be returned. By setting AssociationSearchCriteria/Association/@Shared to “Y”only shared Association objects are going to be returned. Example: Given the user is AAA’d into A5CE domain, and that domain is branched to A2FE and A3ZE and 4 association object exist (as per table below), 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

Profile1

…

Profile20

Profile21

Profile40

…

…

Profile60


Request (IncludeShared = “Y”): <Sabre_OTA_ProfileSearchRQ Version="6.21"> <AssociationSearchCriteria> <Association IncludeShared="Y" DomainID="*" ClientCode="TN" ProfileTypeCode="TVL"/> </AssociationSearchCriteria> </Sabre_OTA_ProfileSearchRQ> 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="MYS" ProfileTypeCode="TVL" /> <Association AssociationID="651825" DomainID="A5CE" Shared="Y" ClientCode="TN" AssociationName="Association_2" ClientContextCode="MYS" ProfileTypeCode="TVL" /> <Association AssociationID="651827" DomainID="A3ZE" Shared="Y" ClientCode="TN" AssociationName="Association_3" ClientContextCode="MYS" ProfileTypeCode="TVL" /> <Association AssociationID="651831" DomainID="A5CE" Shared="N" ClientCode="TN" AssociationName="Association_4" ClientContextCode="MYS" ProfileTypeCode="TVL" /> </AssociationList> </AssociationInfo> </Sabre_OTA_ProfileSearchRS> Request (Shared = “Y”): <Sabre_OTA_ProfileSearchRQ Version="6.21"> <AssociationSearchCriteria> <Association Shared="Y" DomainID="*" ClientCode="TN" ProfileTypeCode="TVL"/> </AssociationSearchCriteria> </Sabre_OTA_ProfileSearchRQ> 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="MYS" ProfileTypeCode="TVL" /> <Association AssociationID="651825" DomainID="A5CE" Shared="Y" ClientCode="TN" AssociationName="Association_2" ClientContextCode="MYS" ProfileTypeCode="TVL" /> <Association AssociationID="651827" DomainID="A3ZE" Shared="Y" ClientCode="TN" AssociationName="Association_3" ClientContextCode="MYS" ProfileTypeCode="TVL" /> </AssociationList>


</AssociationInfo> </Sabre_OTA_ProfileSearchRS>

Sample XML – Exclude domain Profile search – Request

Here is a sample request message in case results from single domain need to be excluded from the results: <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" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ProfileSearchCriteria ExcludeDomain="Y"> <TPA_Identity ClientCode="TN" ClientContextCode="MYS" DomainID="A2FE" ProfileTypeCode="TVL" ProfileName="TestProfile_2015-03-13_13:40:11_jeG"/> </ProfileSearchCriteria> </Sabre_OTA_ProfileSearchRQ>

Sample XML Profile Name Only Search List Response

Here is a sample Response message where the incoming Search request has the ProfileNameOnly 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>

<TPA_Identity UniqueID="4275" ProfileTypeCode="TVL" ClientCode="TN" ProfileName="MYPROFILE" DomainID="A5BE">

</TPA_Identity> </Profile> </ProfileList> </ProfileInfo> </Sabre_OTA_ProfileSearchRS>

The main part of the Response message is 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"?> <Sabre_OTA_ProfileSearchRS xmlns="http://www.sabre.com/eps/schemas" Version="1"> <ResponseMessage> <Success /> </ResponseMessage> <ProfileInfo> <Profile CreateDateTime="2013-03-03T12:08:03.19"

UpdateDateTime="2013-03-03T12:08:03.19" PrimaryLangIDCode="en-US"> <TPA_Identity UniqueID="4351" ProfileTypeCode="TVL" ClientCode="TN"

ProfileName="GEORGE" DomainID="A1B2" ProfileStatus="AC"> </TPA_Identity> <Traveler>

<!—All information about traveler--> </Traveler> </Profile> </ProfileInfo> </Sabre_OTA_ProfileSearchRS> One thing in the above example worth noting is despite the value of the ProfileNameOnly attribute, when only one profile matches the search criteria, all of the profile data is returned (similar to 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 each and 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"?> <Sabre_OTA_ProfileSearchRS xmlns="http://www.sabre.com/eps/schemas" Version="1">


<ResponseMessage> <Success /> </ResponseMessage> <ProfileInfo> <Message>Count: 2</Message> <ProfileList NumReturned="2" HaveMore="N"> <Profile> <TPA_Identity UniqueID="4277" ProfileTypeCode="TVL" ClientCode="TN" ProfileName="GREGPROFILE" DomainID="L3OB"> </TPA_Identity> <Traveler>

<!—-Profile information: PersonName, Telephone, Email, Address, Associated Profiles Customer Reference Info-->

</Traveler> </Profile> </ProfileList> <ProfileList> <Profile> <TPA_Identity UniqueID="4278" ProfileTypeCode="TVL" ClientCode="TN" ProfileName="GREGPROFILE1" DomainID="L3OB"> </TPA_Identity> <Traveler>


</Traveler> </Profile> </ProfileList> </ProfileInfo> </Sabre_OTA_ProfileSearchRS> As seen in the example above, along with TPA_Identity sections some other data is retrieved for each profile which matches 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 be changed 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 requested number of returned profiles, then the following Response message is returned: <xml version="1.0" encoding="utf-8"?> <Sabre_OTA_ProfileSearchRS xmlns="http://www.sabre.com/eps/schemas" Version="1"> <ResponseMessage> <Success /> </ResponseMessage> <ProfileInfo> <Message>Count: 20</Message> <ProfileList NumReturned="20" HaveMore="Y"> <Profile>


<TPA_Identity UniqueID="4277" ProfileTypeCode="TVL" ClientCode="EXT" ProfileName="GREGPROFILE" DomainID="L3OB"> </TPA_Identity> <Traveler>


</Traveler> </Profile> </ProfileList> <ProfileList> <Profile> <TPA_Identity UniqueID="4278" ProfileTypeCode="TVL" ClientCode="TN" ProfileName="GREGPROFILE1" DomainID="L3OB"> </TPA_Identity> <Traveler>

<!—-Profile information : PersonName, Telephone, Email, Address, Associated Profiles Customer Reference Info-->

</Traveler> </Profile> <-- Remaining profiles --> </ProfileList> </ProfileInfo> </Sabre_OTA_ProfileSearchRS> The only difference is that in this case 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> </Sabre_OTA_ProfileSearchRS>

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. The agency however often needs to perform extensive

searches scanning through the Sabre Profiles database to produce a report of profiles that match their

specific search criteria in order 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.

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 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 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 has not completed. 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, all 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

critieria, they will send as and 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 searc 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

In order to utilize 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

EPS_OfflineJobCreateRQ EPS_OfflineJobRetrieveRQ EPS_OfflineJobReadResultRQ

EPS_OfflineJobCreateRQ EPS_OfflineJobRetrieveRQ EPS_OfflineJobReadResultRQ

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

Develope Resource Center for the most current schema information.

OfflineJobCreateRQ

Used for creating a new job using 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):

<Sabre_OTA_OfflineJobCreateRQ Target="Production" 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">

<Job ClientCode="TN" JobName="ALEXANDER#475" DomainID="A2FE">

<OfflineSearch>

<Profile>

<Document>

<ExpireDate StartDate="2020-08-02" EndDate="2021-08-02"/>

</Document>

</Profile>

</OfflineSearch>

</Job>

</Sabre_OTA_OfflineJobCreateRQ>

You can also specify the BlankCriteria within the Document criteria, which searches for profiles that don’t

have Expire Date specified.

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

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

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





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

<Sabre_OTA_OfflineJobCreateRQ Target="Production" TimeStamp="2013-10-

23T10:57:46.236Z" 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">

<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 VendorCode in a given 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: <Sabre_OTA_OfflineJobCreateRQ Target="Production" TimeStamp="2013-10-23T10:39:28.084Z" Version="0.0"



<Job ClientCode="TN" JobName="IAN$710" DomainID="A2FE">

<OfflineSearch>

<Profile>

<Remark>

<OtherPNRText="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)











<Sabre_OTA_OfflineJobCreateRQ Target="Production" TimeStamp="2013-10-23T11:01:41.471Z"

Version="0.0" xsi:schemaLocation="http://www.sabre.com/eps/schemas



<Job ClientCode="TN" JobName="FRANKIE#324" DomainID="A2FE">

<OfflineSearch>

<Profile>

<CustomDefinedData>

<ValuesSearch CustomFieldCode="OTH" Value="Value_1"/>

</CustomDefinedData>

</Profile>

</OfflineSearch>

</Job>


CustomDefinedValues – searches for profiles matching the specified condition for both or any of the attributes: (Name, Value).





<Job ClientCode="TN" JobName="VAUGHN%697" DomainID="A2FE">

<OfflineSearch>

<Profile>

<CustomDefinedValues>

<ValuesSearch Name="Name_2" Value="Value_2"/>

</CustomDefinedValues>

</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 TimeStamp="2013-10-23T08:24:03.16Z" Version="6.15"


<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" TimeStamp="2013-10-23T10:52:49.233Z" Version="0.0"



<Job ClientCode="TN" JobID="1078131" DomainID="A2FE"/>

</Sabre_OTA_OfflineJobCancelRQ>

RESPONSE:

<Sabre_OTA_OfflineJobCancelRS TimeStamp="2013-10-23T08:52:51.342Z" Version="6.15"


<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" TimeStamp="2013-10-23T09:14:02.089Z" Version="0.0"



<Job ClientCode="TN" JobID="1078023" DomainID="A2FE"/>

</Sabre_OTA_OfflineJobDeleteRQ>

RESPONSE:

<Sabre_OTA_OfflineJobDeleteRS TimeStamp="2013-10-23T07:16:17.809Z" Version="6.15"


<ResponseMessage>

<Success/>

</ResponseMessage>

</Sabre_OTA_OfflineJobDeleteRS>

OfflineJobRetrieveRQ

Used for listing all of the jobs in a given domain along with their statuses: REQUEST:

<Sabre_OTA_OfflineJobRetrieveRQ Target="Production" TimeStamp="2013-10-23T10:52:49.233Z"




<Job ClientCode="TN" ActionType="OfflineSearch" DomainID="A2FE"/>

</Sabre_OTA_OfflineJobRetrieveRQ>

RESPONSE:

<Sabre_OTA_OfflineJobRetrieveRS TimeStamp="2013-10-23T08:52:50.491Z" Version="6.15"


<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" TimeStamp="2013-10-21T11:03:20.203Z"




<Job ClientCode="TN" JobID="12345" DomainID="A2FE">

<Page Number="4" ReturnCount="5"/>

</Job>

</Sabre_OTA_OfflineJobReadResultRQ>

RESPONSE:

<Sabre_OTA_OfflineJobReadResultRS TimeStamp="2013-10-23T09:10:14.985Z" Version="6.15"


<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 “Marking for Delete” functionality allows a user to mark a specified profile for deletion, so that it can

be removed from the Sabre Profiles database by the Sabre host Purge Service after the predetermined

time period. The user can specify only one profile in the ProfileDeleteRQ. The Purge Service looks for all

the “marked for delete” profiles that have either the same purge date as the current date and have a

ProfileStatus=”DL”. The profiles which satisfy 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 Mark Profile for Delete request looks like this:

<?xml version="1.0" encoding="UTF-8"?>  <Sabre_OTA_ProfileDeleteRQ Version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.sabre.com/eps/schemas \schemas\Sabre_OTA_ProfileDeleteRQ.xsd">

<Delete> <Profile PurgeDays="5"> <TPA_Identity UniqueID="1758" ProfileTypeCode="TVL"

ClientCode="TN" ClientContextCode=“ABC” 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 Mark For Delete engine in order to calculate a future date. At the calculated future date the Purge Service, once started, will permanently remove this profile from the Sabre Profiles database. Inside the <Profile> there is a TPA_Identity section. This section specifies a profile to be marked for delete. 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.

Delete/Restore Service 9

http://www.xmlspy.com/


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=“ABC”

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 Errors 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 message is shown below:

<Sabre_OTA_ProfileDeleteRS xmlns="http://www.sabre.com/eps/schemas"

TimeStamp="2013-10-04T12:33:41.142Z" Version="6.14">

<ResponseMessage>

<Errors>

<ErrorMessage ErrorCode="298">

D::NCERT502-1T20131004123341SD::No profile is found which match your selection criteria

(UniqueID = 3144924754, ClientCode = TN, ClientContextCode = EXT, DomainID = A5BE, ProfileTypeCode

= TVL)</ErrorMessage>

</Errors>

</ResponseMessage>

<Delete>

<Profile>


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” for Active status for profiles that are scheduled to be deleted from the

database on the same date the Restore action is requested.

If the ProfileStatus is set to delete with a PurgeDate indicator set to 0, it is considered an immediate

delete and this type of profile can be retrieved only in a search and can be restored using the restore

service before midnight U.S. Central Time.

If the Purge date is > 1 day, it is considered a future delete and this type of profile can be retrieved only in

a search and can be restored using the restore service before midnight U.S. Central Time of the purge

date.


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. Thanks to the Profile History service it is possible to track which

actions have been performed on which subject areas for Traveler, Operational, Corporation, Travel

Agency, Travel Agent and Group profiles.

Profile History can retrieve history of actions performed on the Profile up to 24 months ago.

NOTE: For current Profile History supported elements, attributes, and number of instances allowed of


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

In order 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,

there are optional History Criteria which can be specified in the request in order to retrieve only specific

historical information.

The sample Profile History request for a Traveler profile is shown below:

<Sabre_OTA_ProfileHistoryRQ Target="Production" TimeStamp="2001-12-17T09:30:47.0Z" Version="0.0" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.sabre.com/eps/schemas

\schemas\Sabre_OTA_ProfileHistoryRQ.xsd"> <Profile> <TPA_Identity ProfileTypeCode="TVL" ProfileStatusCode="AC" ClientContextCode="ABC" 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 Profile History request are: StartDateTime, EndDateTime,

MaxChangeCount and Action. All these criteria can be specified separately or in different combinations in

the Profile History request.

Profile History Service 10



StartDateTime and EndDateTime attributes indicate time frame of the actions performed on the profile.

For instance, if a user wants to retrieve history of the actions performed on the profile for the last three

weeks, then the appropriate values of the StartDateTime and EndDateTime attributes must be provided

in the Profile History request.

MaxChangeCount attribute indicates the maximum number of actions which will be retrieved in the

Profile History 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 Profile History 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 Profile History response.

The Action attribute if specified in the Criteria section, indicates which action will be retrieved in the

Profile History response. For instance, if Action specified in the request is Update, only Update actions

performed on the profile will be returned in the Profile History response.The Action attribute can contain

the following values: Create, Update, Delete and Restore.

The sample Profile History request with the Action criteria specified for a Traveler profile is shown below:

<Sabre_OTA_ProfileHistoryRQ Target="Production" TimeStamp="2001-12-17T09:30:47.0Z" Version="0.0" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.sabre.com/eps/schemas

\schemas\Sabre_OTA_ProfileHistoryRQ.xsd"> <Criteria Action="Update"/> <Profile> <TPA_Identity ProfileTypeCode="TVL" ProfileStatusCode="AC" ClientContextCode="ABC" 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 Profile History response contains the following information:

- User Id- who has performed the action,

- Action type- can be “Create”, “Add”, “Update”, “Delete”, “Restore”,

- Subject Area- which area of the Profile was updated/added/deleted,

Time Stamp- when an action was performed.

The sample Profile History response is shown below:

<Sabre_OTA_ProfileHistoryRS TimeStamp="2010-08-16T10:35:20.496Z" Version="4.3" xmlns="http://www.sabre.com/eps/schemas">

<ResponseMessage> <Success/> </ResponseMessage> <Profile>


<TPA_Identity ClientCode="TN" ClientContextCode="ABC" 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> <TravelerChangeHistory OldTimeStamp="2010-08-16T10:21:42.87Z"

NewTimeStamp="2010-08-16T10:30:12.292Z" Action="Delete"> <HistoryAccessInfo EPRDomainID="Employees" UserID="999999" LDAPDomain="Sabre"

LNIATA="0"/> </TravelerChangeHistory> <TravelerChangeHistory OldTimeStamp="2010-08-16T10:15:38.882Z"

NewTimeStamp="2010-08-16T10:21:42.87Z" Action="Update"> <HistoryAccessInfo EPRDomainID="Employees" UserID="999999" LDAPDomain="Sabre"

LNIATA="0"/> <SubjectArea Action="Add"> <TPA_Identity ClientCode="TN" ClientContextCode="ABC" UniqueID="105558095"

ProfileTypeCode="TVL" ProfileNameModifyIndicator="Y" ProfileDescription="SC96118" DomainID="A2FE" ProfileStatusCode="AC" ProfilePurgeNoDays="700"/>

</SubjectArea> <SubjectArea Action="Delete"> <TPA_Identity ClientCode="TN" ClientContextCode="ABC" UniqueID="105558095"

ProfileTypeCode="TVL" ProfileNameModifyIndicator="Y" ProfileDescription="ProfDesc64645645" DomainID="A2FE" ProfileStatusCode="AC" ProfilePurgeNoDays="700"/>

</SubjectArea> <SubjectArea Action="Add"> <Email EmailAddress="[email protected]"/> </SubjectArea> </TravelerChangeHistory> <TravelerChangeHistory NewTimeStamp="2010-08-16T10:15:38.882Z" Action="Create"> <HistoryAccessInfo EPRDomainID="Employees" UserID="999999" LDAPDomain="Sabre"

LNIATA="0"/> </TravelerChangeHistory> </Traveler> </Profile> </Sabre_OTA_ProfileHistoryRS>

The above example of the Profile History 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 Restore

the profile.

There is no distinction between the main Profile section, TPA_Extensions and PrefCollections in the Profile

History. All these elements are displayed as Subject Areas in the Profile History response.

If a profile contains Payment Form subject area, it can be shown in different ways in the Profile History

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 ICE attribute assigned,

then CardNumber, CardHolderFullName, and ExpireDate will not be shown and the value "NOACCESS"

will be returned.

A sample will look like this:

<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="NOACCESS" MaskedCardNumber="1111" CCViewAccess="N" EffectiveDate="102012" ExpireDate="NOACCESS" FirstRemark="N" ExtendedPaymentNumMonths="5"> <CardHolderName> <CardHolderFullName>NOACCESS</CardHolderFullName> <NamePrefix>MR</NamePrefix> <GivenName>JOHN</GivenName> <MiddleName>DALLAS</MiddleName> <SurName>DOE</SurName> <NameSuffix>II</NameSuffix> </CardHolderName> </PaymentCard> </PaymentForm>

In the case when the agent’s account (EPR) has the CCVIEW keyword assigned or the OSCCVIEW ICE

attribute assigned, then CardNumber, CardHolderFullName, and ExpireDate will be displayed and match

the 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" ExtendedPaymentNumMonths="5"> <CardHolderName> <CardHolderFullName>John Doe</CardHolderFullName> <NamePrefix>MR</NamePrefix> <GivenName>JOHN</GivenName> <MiddleName>DALLAS</MiddleName> <SurName>DOE</SurName> <NameSuffix>II</NameSuffix> </CardHolderName> </PaymentCard> </PaymentForm>

It is worth noticing how the update operation is represented in the Profile History response. If, for

example, 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 Profile History response. The

sample Profile History response below illustrates the FullPhoneNumber update operation:


<TravelerChangeHistory OldTimeStamp="2010-09-21T09:24:30.594Z" NewTimeStamp="2010-09-21T09:29:12.091Z" Action="Update">

<HistoryAccessInfo EPRDomainID="A2FE" DutyCd="000" UserID="9999999" LDAPDomain="AA" LNIATA="123456" AgentSine="AA1" AgentGivenName="Travelocity" AgentMiddleName="Inc" AgentSurName="Sabre"/>

<SubjectArea Action="Add"> <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" OrderSequenceNo="1">

<FullPhoneNumber>893262</FullPhoneNumber> <Contact ContactFirstName="John" ContactLastName="Smith"

ContactRemark="ContactEmail" ContactEffectiveDate="2009-10-01" ContactDiscontinueDate="2007-10-01" ContactEffectiveTime="16:00" ContactDiscontinueTime="10:00"/>

</Telephone> </SubjectArea> </TravelerChangeHistory>

For the AirlinePref, HotelPref, VehicleRentalPref, RailPref and GroundTransportationPref subject areas there are two additional actions ChildAdd and ChildDelete which can occur in the Profile History response. These two actions can be retrieved in the Profile History 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. The sample Profile History response with the ChildAdd and ChildDelete actions looks as follows:

<TravelerChangeHistory OldTimeStamp="2010-09-21T09:53:41.501Z" NewTimeStamp="2010-09-21T09:54:04.317Z" Action="Update">

<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"> <SeatInfo SeatPreferenceCode="SPCL"/> </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"> <SeatInfo SeatPreferenceCode="SPCL"/> </AirlineSeatPref> <AirlineSeatPref InformationText="WNDWASLE/NM-Susan E Smith"> <SeatInfo SeatPreferenceCode="SPCL"/> </AirlineSeatPref> <AirlineMealPref InformationText="CHKN/NM-Robert M Smith"> <MealInfo MealTypeCode="SPML"/> </AirlineMealPref> </AirlinePref> </SubjectArea> </TravelerChangeHistory>

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 profile history process. For the Sabre Profiles History Service, each Error message is prefixed with “H::”. An example error message is shown below: <Sabre_OTA_ProfileHistoryRS TimeStamp="2010-08-16T11:01:44.299Z" Version="4.3" xmlns="http://www.sabre.com/eps/schemas"> <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="ABC" UniqueID="105558094" ProfileTypeCode="TVL" DomainID="A2FE"/> </Profile> </Sabre_OTA_ProfileHistoryRS> If the Profile has been created, but no other actions were performed on the Profile, the following warning

message is returned:

<Sabre_OTA_ProfileHistoryRS TimeStamp="2010-08-16T10:58:06.856Z" Version="4.3" xmlns="http://www.sabre.com/eps/schemas">


<ResponseMessage> <Warnings> <WarningMessage>PRF::Profile Change History Data not Found, Profile has not been updated since creation.</WarningMessage> </Warnings> </ResponseMessage> <Profile> <TPA_Identity ClientCode="TN" ClientContextCode="ABC" UniqueID="105558097" ProfileTypeCode="TVL" DomainID="A2FE"/> <Traveler> <TravelerChangeHistory NewTimeStamp="2010-08-16T10:57:40.135Z" Action="Create"> <HistoryAccessInfo EPRDomainID="Employees" UserID="999999" LDAPDomain="Sabre" LNIATA="0"/> </TravelerChangeHistory> </Traveler> </Profile> </Sabre_OTA_ProfileHistoryRS>


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 a

description of the data and the actual data value stored within the profile. This feature allows clients to

expand the data model to accommodate for Profile data needs for elements 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 in order 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 the 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

In order 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 has been shown

below:

<Sabre_OTA_ProfileDataSrvRQ Version="1.0" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <RetrieveCustomFieldCodes DomainID="A5BE" ClientCode="TN" ClientContextCode=“ABC”/> </Sabre_OTA_ProfileDataSrvRQ>

Data Service 11


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 xmlns="http://www.sabre.com/eps/schemas" TimeStamp="2013-10-07T09:20:11.608Z" Version="6.14"> <ResponseMessage> <Success /> </ResponseMessage> <RetrieveCustomFieldCodes ClientCode="TN" ClientContextCode=“ABC” 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

In order 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" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <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> </Sabre_OTA_ProfileDataSrvRQ>

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>

</Sabre_OTA_ProfileDataSrvRS>



Note: it’s important to note that the added values will only be available for the DomainID (PCC)

for which it was defined, and for any others who are branched to this DomainID (PCC) via “Sabre

Branch Access”. All other clients will only have access to the globally available Dictionary control

table values.


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 which already exists. In order 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 are 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" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <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> </Sabre_OTA_ProfileDataSrvRQ>

A sample Create Dictionary response is structured as follows:

<Sabre_OTA_ProfileDataSrvRS TimeStamp="2010-08-05T10:01:08.863Z" Version="4.3" xmlns="http://www.sabre.com/eps/schemas"> <ResponseMessage> <Success/> </ResponseMessage> </Sabre_OTA_ProfileDataSrvRS>



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:

<Sabre_OTA_ProfileDataSrvRS TimeStamp="2010-08-16T07:59:33.622Z" Version="4.3" xmlns="http://www.sabre.com/eps/schemas"> <ResponseMessage> <Errors> <ErrorMessage ErrorCode="123"> SVC:: Duplicate dictionary code=A found</ErrorMessage> </Errors> </ResponseMessage> </Sabre_OTA_ProfileDataSrvRS> 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: <Sabre_OTA_ProfileDataSrvRS TimeStamp="2010-09-10T12:45:56.716Z" Version="5.1" xmlns="http://www.sabre.com/eps/schemas"> <ResponseMessage> <Errors> <ErrorMessage ErrorCode="123">SVC:: Invalid date range for Codes [H0GG, HO6]</ErrorMessage> </Errors> </ResponseMessage> </Sabre_OTA_ProfileDataSrvRS>

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

In order 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:

<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" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DictionaryOperation> <ReadDictionary Name="AirlineSeatPref" DomainID="A2FE" ClientCode="TN"/> </DictionaryOperation> </Sabre_OTA_ProfileDataSrvRQ>

A sample Read Dictionary response is structured as follows: <Sabre_OTA_ProfileDataSrvRS TimeStamp="2010-08-05T10:32:45.089Z" Version="4.3" xmlns="http://www.sabre.com/eps/schemas"> <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"/> <DictionaryEntry Code="AHKL" Description="DESC1" EffectiveDate="2010-05-05" DiscontinueDate="2010-09-09"/> </ReadDictionaryData> </Sabre_OTA_ProfileDataSrvRS>

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:

<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" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DictionaryOperation> <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> </DictionaryOperation> </Sabre_OTA_ProfileDataSrvRQ>



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:

<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" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DictionaryOperation> <UpdateDictionary> <PartialUpdate> <DictionaryIdentity ClientCode="TN" DomainID="A2FE" Name="AirlineSeatPref"></DictionaryIdentity> <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> </DictionaryOperation> </Sabre_OTA_ProfileDataSrvRQ>

All the 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. In order to delete custom Preference Codes, they must be specified as in the following sample request:

<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" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DictionaryOperation> <UpdateDictionary> <PartialUpdate> <DictionaryIdentity ClientCode="TN" DomainID="A2FE" Name="AirlineSeatPref"></DictionaryIdentity> <Deletions> <Delete Code="V4"></Delete> <Delete Code="KJU7"></Delete> </Deletions> </PartialUpdate> </UpdateDictionary> </DictionaryOperation>


</Sabre_OTA_ProfileDataSrvRQ>

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 message is shown below: <Sabre_OTA_ProfileDataSrvRS TimeStamp="2010-08-16T07:55:58.226Z" Version="4.3" xmlns="http://www.sabre.com/eps/schemas"> <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> </Sabre_OTA_ProfileDataSrvRS> 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. In order 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: <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" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DictionaryOperation> <UpdateDictionary> <PartialUpdate> <DictionaryIdentity ClientCode="TN" DomainID="A2FE" Name="AirlineSeatPref"></DictionaryIdentity> <Modifications> <Modify Code="H" Description="DESC2" EffectiveDate="2010-05-18"></Modify> <Modify Code="B00H" Description="DESC3" EffectiveDate="2010-05-20"></Modify> </Modifications> </PartialUpdate> </UpdateDictionary> </DictionaryOperation> </Sabre_OTA_ProfileDataSrvRQ>

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:

<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" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DictionaryOperation> <DeleteDictionary> <PartialDelete> <DictionaryIdentity Name="AirlineSeatPref" ClientCode="TN" DomainID=”A2FE"/> <DictionaryEntry Code="H"/> <DictionaryEntry Code="B00H"/> </PartialDelete> </DeleteDictionary> </DictionaryOperation> </Sabre_OTA_ProfileDataSrvRQ>

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:

<Sabre_OTA_ProfileDataSrvRS TimeStamp="2010-08-05T11:42:31.264Z" Version="4.3" xmlns="http://www.sabre.com/eps/schemas"> <ResponseMessage> <Success/> </ResponseMessage> <ReadDictionaryData> <DictionaryIdentity Name="AirlineSeatPref" DomainID="A2FE" ClientCode="TN"/> <DictionaryEntry Code="H" EffectiveDate="2010-08-05" DiscontinueDate="2010-08-04"/> <DictionaryEntry Code="B00H" Description="DESC1" EffectiveDate="2010-08-05" DiscontinueDate="2010-08-04"/> <DictionaryEntry Code="YYTR" EffectiveDate="2010-05-05" DiscontinueDate="9999-12-31"/> <DictionaryEntry Code="NBUY" EffectiveDate="2010-08-05" DiscontinueDate="2010-09-09"/> <DictionaryEntry Code="AHKL" Description="DESC1" EffectiveDate="2010-05-05" DiscontinueDate="2010-09-09"/> </ReadDictionaryData> </Sabre_OTA_ProfileDataSrvRS> 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:, <Sabre_OTA_ProfileDataSrvRS TimeStamp="2010-08-16T07:55:58.226Z" Version="4.3" xmlns="http://www.sabre.com/eps/schemas"> <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> </Sabre_OTA_ProfileDataSrvRS> A sample Full Delete Dictionary request is 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" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DictionaryOperation> <DeleteDictionary> <FullDelete ClientCode="TN" DomainID="A2FE" Name="AirlineSeatPref"></FullDelete> </DeleteDictionary> </DictionaryOperation> </Sabre_OTA_ProfileDataSrvRQ>

The Sabre Profiles system sets Discontinue Date of all the existing custom Preference Codes to a past date.A sample Read Dictionary response after aFull Delete operation is shown below. <Sabre_OTA_ProfileDataSrvRS TimeStamp="2010-08-05T11:56:17.317Z" Version="4.3" xmlns="http://www.sabre.com/eps/schemas"> <ResponseMessage> <Success/> </ResponseMessage> <ReadDictionaryData> <DictionaryIdentity Name="AirlineSeatPref" DomainID="A2FE" ClientCode="TN"/> <DictionaryEntry Code="H" EffectiveDate="2010-08-05" DiscontinueDate="2010-08-04"/> <DictionaryEntry Code="B00H" Description="DESC1" EffectiveDate="2010-08-05" DiscontinueDate="2010-08-04"/> <DictionaryEntry Code="YYTR" EffectiveDate="2010-05-05" DiscontinueDate="2010-08-04"/> <DictionaryEntry Code="NBUY" EffectiveDate="2010-08-05" DiscontinueDate="2010-08-04"/> <DictionaryEntry Code="AHKL" Description="DESC1" EffectiveDate="2010-05-05" DiscontinueDate="2010-08-04"/> </ReadDictionaryData> </Sabre_OTA_ProfileDataSrvRS>


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 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 the Sabre Dev Studio.

A sample Copy Dictionary request is 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" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DictionaryOperation> <CopyDictionary> <SourceDictionary Name="AirlineSeatPref" DomainID="A2FE" ClientCode="TN" /> <DestinationDictionary Name="AirlineSeatPref" DomainID="A5CE" ClientCode="TN" /> <DestinationDictionary Name="AirlineSeatPref" DomainID="A5BE" ClientCode="TN" /> </CopyDictionary> </DictionaryOperation> </Sabre_OTA_ProfileDataSrvRQ>

If all of 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: <Sabre_OTA_ProfileDataSrvRS TimeStamp="2010-08-16T08:31:18.992Z" Version="4.3"


<ResponseMessage> <Errors> <ErrorMessage ErrorCode="123"> SVC:: AirlineSeatPref Dictionary doesn't have active codes for DomainID=A2FE, ClientCode=TN</ErrorMessage> </Errors> </ResponseMessage> </Sabre_OTA_ProfileDataSrvRS> If the destination Dictionary already exists and contains custom Preference Codes, the following warning message is returned: <Sabre_OTA_ProfileDataSrvRS TimeStamp="2010-08-16T08:34:42.113Z" Version="4.3" xmlns="http://www.sabre.com/eps/schemas"> <ResponseMessage> <Warnings> <WarningMessage WarningCode="138">Destination dictionary AirlineSeatPref already exists for DomainID=A5CE, ClientCode=TN</WarningMessage> </Warnings> </ResponseMessage>



</Sabre_OTA_ProfileDataSrvRS>

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: <Sabre_OTA_ProfileDataSrvRS TimeStamp="2010-08-16T08:42:41.463Z" Version="4.3" xmlns="http://www.sabre.com/eps/schemas"> <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> </Sabre_OTA_ProfileDataSrvRS>


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 u e d o C i t y C o d e

This service allows the user to Copy or Move Profile data between two branch domains to which the user

has access.

The Move functionality allows the user to:

Move a Profile with or without associations

Move an Association Object (Template) with or without associations

The Copy functionality allows the user to copy an Association Object (Template) with or without

associations, as well as retrieve the status of the Domain Move operation.

To use this service, the user must be assigned the Unrestricted User Role of ADMINPPP. The following

provides a list of codes that determine user permissions when using the Roles service:

MVD – Call Move Domain

MVDOPRF – Move Profile

MVDOTPL – Move Template

CPDOTPL – Copy Template

Filters, formats, metadata, validators, and AssociationIDs 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=“ABC” UniqueID="12345"

ProfileTypeCode="TVL" DomainID="A2FE"/>

<Traveler>

<Customer>

…

</Profile

Profile Data Management Service

12



To move a Profile from Domain A2FE to Domain A5CE with all its associations, use following request:

<Sabre_OTA_ProfileDataMgmtRQ Version="1.0" xmlns="http://www.sabre.com/eps/schemas"

xmlns:xs="http://www.w3.org/2001/XMLSchema"


<MoveDomainObject DestinationDomainID="A5CE"> <Profile ClientCode="TN" ClientContextCode=“ABC” DomainID="A2FE" ProfileTypeCode="TVL" UniqueID="12345"/> </MoveDomainObject> </Sabre_OTA_ProfileDataMgmtRQ>

Notice that, by default, all associated Filters, Formats, and AssociationIDs of the Profile are copied to the

destination Domain; however, any associated Profiles are not copied.

The same logic applies to Association Objects. If a Profile has an AssociationID, it is copied to the

destination Domain along with their associated Filters and Formats. However, associated Profiles are not

copied.

If the Profile and/or Template have the same associated Filters and/or Formats, all of 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 or a Template(AssociationID), its UniqueID/AssociationID is saved in the new destination Domain (PCC).

When a user copies a Template (AssociationID), Filter, or Format, 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, specify the following

attribute: IgnoreAssociations=”Y.” For example:




<MoveDomainObject DestinationDomainID="A5CE" IgnoreAssociations=”Y”>

<Profile ClientCode="TN" ClientContextCode=“ABC” DomainID="A2FE" ProfileTypeCode="TVL"

UniqueID="12345"/>

</MoveDomainObject>

</Sabre_OTA_ProfileDataMgmtRQ>

As a result, none of the Profile associations are copied to the destination Domain. The Profile loses all

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


C o p y i n g a n A s s o c i a t i o n I D ( T e m p l a t e ) t o a B r a n c h e d P C C

The following is an example of moving an Association. The object for Association is named Template in

the ProfileDataMgmtRQ schema.

Association can be copied from one PCC to another with all associated objects. Both the newly created Association and all of its associated object are assigned new ids.

Association name uniqueness is enforced in the target domain.

Association copy is only allowed for users who have the required permissions or ICE attribute

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, metadata that existed in the initial AssociationID that was copied.

To copy a Template from Domain A2FE to Domain A5CE with all its associations, use the following

request:




<CopyDomainObject DestinationDomainID="A5CE">

<Association ClientCode="TN" ClientContextCode=“ABC” DomainID="A2FE"

AssociationID="12345"/>

</CopyDomainObject>


If the user does not want any associations to be copied to the destination Domain, specify the following attribute: IgnoreAssociations=”Y.” For example:




<CopyDomainObject DestinationDomainID="A5CE" IgnoreAssociations=”Y”>

<Association ClientCode="TN" ClientContextCode=“ABC” 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

The special cases occurs when Association objects that are shared 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 shared Association object to branched domain Assuming that the Association object that is requested to be copied is shared (see RQ example from Copying an Association ID… , AssociationID="12345") below 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” – copy is NOT going to be created in “A5CE”.

Moving a profile that is using shared Association object to branched domain. In this case Profile is being moved to branched domain but shared Association object is not copied. The “relation” (association) to the object remains in the profile in case IgnoreAssociations flag is not be included in a request or is set to “N”. In case IgnoreAssociations = “Y” the “relation” Association object does not remain on a profile in destination domain. Below are the examples of this behaviour:

o Moving a profile using shared Asssociation object with IgnoreAssociations = “N”

Profile ID: 10344778 is using shared Association object 691073:

<Profile …"> <TPA_Identity ClientCode="TN" ClientContextCode="MYS" UniqueID="10344778" ProfileTypeCode="TVL" DomainID="A5CE" …/> <Traveler> <Customer> <PersonName> <GivenName>VERN</GivenName> <SurName>BURNS</SurName> </PersonName> </Customer> </Traveler> <Association DomainID="A2FE" ClientCode="TN" ClientContextCode="MYS" AssociationID="691073" ProfileTypeCode="TVL"/> </Profile>

Profile ID: 10344778 is requested to be moved to A8VE branched domain:

<Sabre_OTA_ProfileDataMgmtRQ …> <MoveDomainObject DestinationDomainID="A8VE" IgnoreAssociations=”N”> <Profile UniqueID="10344778" ProfileTypeCode="TVL" DomainID="A5CE" …/> </MoveDomainObject> </Sabre_OTA_ProfileDataMgmtRQ> Profile ID: 10344778 is removed from domain A5CE and another profile based on that profile is created in A8VE domain. 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="MYS" UniqueID="10344779" ProfileTypeCode="TVL" DomainID="A8VE" …/> <Traveler> <Customer> <PersonName> <GivenName>VERN</GivenName> <SurName>BURNS</SurName> </PersonName>


</Customer> </Traveler> <Association DomainID="A2FE" ClientCode="TN" ClientContextCode="MYS" AssociationID="691073" ProfileTypeCode="TVL"/> </Profile> The reason for such system behavior is that Association object that is shared is available in branched domains – so there is no need to create a copy of that Association object as it is available to be used on a Profile.

o 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> </Sabre_OTA_ProfileDataMgmtRQ> Profile ID: 10344778 is removed from domain A5CE and another profile based on that profile is created in A8VE domain. Relation to Association ID 691073 is not present on that profile. Association ID 691073 remains in A2FE domain (is not copied to A8VE) Profile after the move is completed: <Profile …"> <TPA_Identity ClientCode="TN" ClientContextCode="MYS" UniqueID="10344780" ProfileTypeCode="TVL" DomainID="A8VE" …/> <Traveler> <Customer> <PersonName> <GivenName>VERN</GivenName> <SurName>BURNS</SurName> </PersonName> </Customer> </Traveler> </Profile>

Copying child Association object that is using shared Association object (parent) to branched domain. In this case child Association is being copied to branched domain but shared Association object is not copied. The “relation” (association) to the object remains in the child Association in case IgnoreAssociations flag is not be included in a request or is set to “N”. In case IgnoreAssociations = “Y” the “relation” Association object does not remain on a Association object (it is not considered as child anymore) in destination domain. Below are the examples of this behaviour:

o Copying a child Association object that is using shared Asssociation object (parent) with IgnoreAssociations = “N”

Child Association ID: 1234567 is using shared Association object (has 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> </Sabre_OTA_ProfileDataMgmtRQ> Child Association ID: 1234567 remains in domain A5CE and another child Association based on original child Association is created in B0DE domain. Relation to parent Association ID 1558953 remains. Association object after the move is completed:

<Association DomainID=" B0DE " AssociationID="1234568"…> <ParentAssociation AssociationID="1558953" DomainID="A2FE" ClientCode="TN"/>

</Association>

o Copying a child Association object that is using shared Asssociation object (parent) with IgnoreAssociations = Y”

Child Association ID: 1234567 is using shared Association object (has 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=”Y”> <Association AssociationID="1234567" DomainID="A5CE" ClientCode="TN"/> </CopyDomainObject>

</Sabre_OTA_ProfileDataMgmtRQ> Child Association ID: 1234567 remains in domain A5CE and Association based on original child Association is created in B0DE domain. New Association is not considered child as it is loosing Assocition to parent. Association object after the move is completed:

<Association DomainID=" B0DE " AssociationID="1234568"…> …

</Association>

o Moving a Profile that is using child Association object connected to parent with IgnoreAssociations = “N”

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. o Moving a Profile that is using child Association object connected to 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.


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, a number of 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.

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

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)

Roles 13


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 particular Domain, administrator should send ProfileAdminRQ, which is shown below: <Sabre_OTA_ProfileAdminRQxmlns="http://www.sabre.com/eps/schemas" Target="Production" TimeStamp="2008-05-05T09:28:40.289Z" Version="1.0"> <ModifyDomainStatusStatusCode="AC" ClientCode="TN" ClientContextCode=“ABC” 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 RolesManager or RolesExternalManager

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

MVDOMN PPP MOVE DOMAIN

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 Domain ADMINPPP, MVDOMN

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

Sabre owns the process to create, update, and delete Standard Roles and current permissions defined 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 exactly 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

Sabre owns the process to create, update, and delete Standard Roles and current permissions defined 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> </SOAP-ENV:Envelope> Apart from the Basic Search Criteria, which has been discussed earlier, each search criterion can contain a ‘*’ sign (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 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

Sabre owns the process to create, update, and delete Standard Roles and current permissions defined 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.


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: Similar to 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 of 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 coming from the host are passed in the service so that the client can determine how to proceed on fixing any incorrect data/formats. The user has the ability to 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. Then once it’s moved to the PNR, the PNR rules on 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 of these fields, please refer to the schema xml files located on the Sabre Dev Studio.

ProfileToPNR Service 14



FilterPath

TempFilterPath

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 OrderSequencNo and some do not, then those with OrderSequenceNo move 1st in 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.

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

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 Template/Association level which is inherited by the Profile when created from a 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 uppon OrderSequenceNumber , then Custom Formats from the Profile based upon the defined OrderSequenceNumber.

Note: The Template custom formats may have the same OrderSequenceNumbers as the Profile Custom

Formats, but first all the custom formats from the template need to be moved, then all the ones from the profile.

If no OrderSequenceNo is defined it will move in random order which can change with each move call.

If OrderSequenceNo exists but not for 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 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. 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 the 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=“ABC” DomainID="A5BE" ProfileTypeCode="TVL" UniqueID="1004903">

<Filter ClientCode="TN" ClientContextCode=“ABC” DomainID="A5BE" FilterID="12993" FilterName="Filter">

<AssociatedFormats ClientCode="TN" ClientContextCode=“ABC” 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 one identifies a

profile that is supposed to be moved to the PNR, whereas the second one 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 doesn’t have any associated profiles other than the

one specified in the <Profile> element, the Profile To PNR service doesn’t take any further steps and

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=“ABC”

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=“ABC”

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

used. 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 associated profile type only – using a generic placeholder in the Filter.<Profile

ClientCode="TN" ClientContextCode=“ABC” 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:

By using a FilterID, FilterName, and other attributes as shown in the following example:

<Filter ClientCode="TN" ClientContextCode=“ABC”

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

With the flag indicator for BlindMoveByProfName="Y", this indicator keys an orchestrated call

for multiple searches to get 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.

If a Filter with OrderSequenceNo=1 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 anAssociation 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.


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 following steps describe how to Search for a Default Filter:

1. Execute a Default Filter Seach 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 Seach 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 Seach 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 does have one or a number of 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. All of 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 go any deeper in

the filter to profile associations.


If there are some Profiles associated with Fltr4 and Fltr5, they are disregarded. This prevents the

ProfileToPNR service from entering into 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 taken into account. 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 under 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=“ABC” 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 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.

4. The response contains the error message:

<Sabre_OTA_ProfileCreateRS Version="1"> <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=“ABC” > </Profile> </Sabre_OTA_ProfileCreateRS>

5. System Reads the filter and its associated formats.

6. System asks the user for the input data.

7. System sends regular ProfileToPNR Filter path RQ, including the filter ID and user input data

for formats.

8. 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 similar to the Filter path in regards to 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 in ProfileToPNRRQ. Information contained in the filter body used is similar to a “mask”

for information from the profile. The user must include directly in the XML all the profile elements they

want to Move in to the PNR Move service (ProfileToPNRRQ) 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, TripTypeCodes, etc.


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" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <TemporaryFilterPath> <Profile ClientCode="TN" ClientContextCode=“ABC” DomainID="A2FE" ProfileTypeCode="TVL" UniqueID="101854748"/> <Filter> <Profile> <TPA_Identity ClientCode="TN" ClientContextCode=“ABC” 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"> <FullPhoneNumber>11111112</FullPhoneNumber> </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" OrderSequenceNo="1"> <AddressLine>ADRESSLINE1</AddressLine> <AddressLine>ADRESSLINE2</AddressLine> <AddressLine>ADRESSLINE3</AddressLine> <AddressLine>ADRESSLINE4</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> <NamePrefix>Mr</NamePrefix> <SurName>Smith</SurName> <GivenName>John</GivenName>



<MiddleName>K</MiddleName> <NameSuffix>Sr</NameSuffix> </DocHolder> </Document> <CustLoyalty MembershipID="00131265247" OrderSequenceNo="1" VendorCode="UA" VendorTypeCode="AL"> <GivenName>John</GivenName> <SurName>Smith</SurName> <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>

Note: A reference to ‘ProfilePath’ exists in the schema but will be sunset in the near future. Please use

TemporaryFilterPath as a replacement.

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 are consolidated, the Profile To PNR service sends it to the PNR and

waits for the response in a synchronous manner. When it gets the message back, it forms the XML Profile

To PNR Service 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>

On the other hand, when any problems are encountered moving the data to the PNR, anerror message is returned to the Profile To PNR 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 could be used in copying Profiles to PNR. In case Profile is using shared Association object, the system allows the user to copy shared content to PNR in two ways – using shared Filter that is part of shared Association object and resides in different domain than the Profile, or using local Filter:

- that is directly associated to Profile but is selecting objects from Association objects domain. - that is associated to child Assocition object the Profile is using but is selecting objects from parent

Assocition object domain. Please see most popular use cases on how shared objects behave in P2PNR:


Use case 1: Using Filter from different domain with branch access opened

The environement here is: Profile 10928218 in domain A5CE using shared Association object 104236 from domain A2FE. Filter 93356332 is associated to shared Association object. Filter is poiting to 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 Format and AssociatedProfile from A2FE domain. Example of message flow and setup: Profile: <Profile ..>

<TPA_Identity ClientCode="TN" ClientContextCode="MYS" UniqueID="10928218" ProfileTypeCode="TVL" DomainID="A5CE"/>

<Traveler> <Customer>

<NamePrefix>MRS</NamePrefix> <GivenName>VERONICA</GivenName> <SurName>BULLOCK</SurName>

</Customer> </Traveler>

<Association DomainID="A2FE" ClientCode="TN" ClientContextCode="MYS" AssociationID="104236" ProfileTypeCode="TVL"/> </Profile> Association: <Association Shared="Y" DomainID="A2FE" ProfileTypeCode="TVL" AssociationID="104236" ClientCode="TN" ClientContextCode="MYS" …>

<AssociatedProfiles AssocUniqueID="109282186" AssocProfileTypeCode="CRP" DomainID="A2FE" OrderSequenceNo="1">

<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="MYS" ...>

<Profile> <TPA_Identity ClientCode="TN" ClientContextCode="MYS" UniqueID="*" ProfileTypeCode="TVL" DomainID="A2FE"/>


<PersonName> <NamePrefix>*</NamePrefix> <GivenName>*</GivenName> <SurName>*</SurName>

</PersonName> </Customer>

</Traveler>


</Profile> <AssociatedProfiles AssocUniqueID="109282186" AssocProfileTypeCode="CRP"

OrderSequenceNo="1" DomainID="A2FE"> <PNRMoveInfo AssocProfileFilterID="93356330"/>

</AssociatedProfiles> <AssociatedFormats FormatID="90568720" DomainID="A2FE" SequenceNo="1"/>

</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 Filter from different domain with branch access lost In the case where branch access is lost there is no possibility to use Filter from other domain while copying a Profile to PNR. Following error response message is going to be returned when such attempt will be made and no data is copied to PNR (setup is identical as in case above, branch access is lost): <Sabre_OTA_ProfileToPNRRS TimeStamp="2015-03-13T10:13:29.921Z" Target="Production" Version="6.20" xmlns="http://www.sabre.com/eps/schemas">

<ResponseMessage> <Errors>

<Error ErrorCode="1014" ErrorMessage="PRF2PNR::NPTNHLP607-PROD1T20150313101329SPNR::Association DomainID attribute doesn't match DomainID attribute in Profile"/> </Errors>

</ResponseMessage> </Sabre_OTA_ProfileToPNRRS> Data copied to PNR: NONE Use case 3: Using Filter from local domain (directly associated to Profile) selecting shared objects from other domain – branch access

The environement here is: Profile 109282352 in domain A5CE using shared Association object 104254 from domain A2FE. Filter 93356442 is associated directly to Profile. Format 90568797 is associated directly to Profile. Filter is pointing to AssociatedProfile ID 109282350 and AssociatedFormat ID 90568796 from domain A2FE (this way local Filter is inheriting information from branched domain). Also the Filter is pointing to local Format ID: 90568797 from A5CE domain (this way shared content is extended by some local, domain specific information). 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 Formats and AssociatedProfiles from both A2FE and A5CE domains. Example of message flow and setup:- Profile: <Profile ...>



<PersonName>


<NamePrefix>MR</NamePrefix> <GivenName>STEVEN</GivenName> <SurName>GERRARD</SurName>


<TPA_Extensions> <AssociatedFilters FilterID="93356442" DomainID="A5CE"/> <AssociatedFormats FormatID="90568797" DomainID="A5CE"/>

</TPA_Extensions> </Traveler> <Association DomainID="A2FE" ClientCode="TN" ClientContextCode="MYS"

AssociationID="104254" ProfileTypeCode="TVL"/> </Profile> Association: <Association Shared="Y" DomainID="A2FE" ProfileTypeCode="TVL" AssociationID="104254" ClientCode="TN" ClientContextCode="MYS" …>


<PNRMoveInfo AssocProfileFilterID="93356440"/> </AssociatedProfiles> <AssociatedFilters FilterID="93356332" DomainID="A2FE"/> <AssociatedFormats FormatID="90568796" DomainID="A2FE"/>

</Association> Filter: <Filter UsedByShared="Y" FilterID="93356442" DomainID="A5CE" ClientCode="TN" ClientContextCode="MYS" FilterTypeCode="TVL" ...>

<Profile> <TPA_Identity ClientCode="TN" ClientContextCode="MYS" UniqueID="*"

ProfileTypeCode="TVL" DomainID="A5CE"/> <Traveler>

<Customer> <PersonName>

<NamePrefix>*</NamePrefix> <GivenName>*</GivenName> <SurName>*</SurName>


</Traveler> </Profile> <AssociatedProfiles AssocUniqueID="109282350" AssocProfileTypeCode="CRP"


</AssociatedProfiles> <AssociatedFormats FormatID="90568796" DomainID="A2FE"/> <AssociatedFormats FormatID="90568797" DomainID="A5CE"/>

</Filter> Data copied to PNR: Main Profile UniqueID="109282352" from domain A5CE


Format 1 UniqueID=”90568796” from domain A2FE Format 2 UniqueID=”90568797” from domain A5CE Associated Profile UniqueID="109282350" from domain A2FE Use case 4: Using Filter from local domain selecting shared objects from other domain with branch access

lost

In case where branch access is lost but local Filter is specified for the P2PNR – only local content is going

to be copied (eventhough the Filter is poining to content from other domain). In this case warning

message is going to be returned for each object that was not copied (setup is identical as in case above,

branch access is lost):

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

</Sabre_OTA_ProfileToPNRRS> Data copied to PNR: Main Profile UniqueID="109282352" from domain A5CE Format 2 UniqueID=”90568797” from domain A5CE Use case 5: Using Filter from different domain associated to parent Association object with branch access opened

The environement here is: Profile 10928218 in domain A5CE using child Association object 104236, te parent is Association object 104237 from domain A2FE. Filter 93356332 is associated to shared Association object (parent). Filter is poiting to 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 Format and AssociatedProfile from A2FE domain. Example of message flow and setup: Profile: <Profile ..>



<NamePrefix>MRS</NamePrefix> <GivenName>VERONICA</GivenName> <SurName>BULLOCK</SurName>

</Customer> </Traveler>


<Association DomainID=" A5CE" ClientCode="TN" ClientContextCode="MYS" AssociationID="104236" ProfileTypeCode="TVL"/> </Profile> Child Association: <Association DomainID="A5CE" ProfileTypeCode="TVL" AssociationID="104236" ClientCode="TN" ClientContextCode="MYS" …>

<ParentAssociation AssociationID="104237" DomainID="A2FE" ClientCode="TN"/> </Association> Parent Association: <Association Shared="Y" DomainID="A2FE" ProfileTypeCode="TVL" AssociationID="104237" ClientCode="TN" ClientContextCode="MYS" …>


<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="MYS" ...>

<Profile> <TPA_Identity ClientCode="TN" ClientContextCode="MYS" UniqueID="*" ProfileTypeCode="TVL" DomainID="A2FE"/>


<PersonName> <NamePrefix>*</NamePrefix> <GivenName>*</GivenName> <SurName>*</SurName>




</AssociatedProfiles> <AssociatedFormats FormatID="90568720" DomainID="A2FE" SequenceNo="1"/>

</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 6: Using Filter from different domain domain associated to parent Association object with branch access lost In the case where branch access is lost there is no possibility to use Filter from other domain while copying a Profile to PNR. Following error response message is going to be returned when such attempt will be made and no data is copied to PNR (setup is identical as in use case 5, branch access is lost): <Sabre_OTA_ProfileToPNRRS TimeStamp="2015-03-13T10:13:29.921Z" Target="Production" Version="6.20" xmlns="http://www.sabre.com/eps/schemas">

<ResponseMessage> <Errors>

<Error ErrorCode="1014" ErrorMessage="PRF2PNR::NPTNHLP607-PROD1T20150313101329SPNR::Association DomainID attribute doesn't match DomainID attribute in Profile"/> </Errors>

</ResponseMessage> </Sabre_OTA_ProfileToPNRRS> Data copied to PNR: NONE Use case 7: Using Filter from local domain (associated to child Association object) selecting shared objects from other domain – branch access

The environement here is: Profile 109282352 in domain A5CE using child Association object 104254. Parent Association object ID 104255 is from domain A2FE. Filter 93356442 is associated to child Association object. Format 90568797 is associated directly to Profile. Filter is pointing to AssociatedProfile ID 109282350 and AssociatedFormat ID 90568796 from domain A2FE (this way local Filter is inheriting information from branched domain). Also the Filter is pointing to local Format ID: 90568797 from A5CE domain (this way shared content is extended by some local, domain specific information). 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 Formats and AssociatedProfiles from both A2FE and A5CE domains. Example of message flow and setup:- Profile: <Profile ...>



<PersonName> <NamePrefix>MR</NamePrefix> <GivenName>STEVEN</GivenName> <SurName>GERRARD</SurName>


<TPA_Extensions> <AssociatedFormats FormatID="90568797" DomainID="A5CE"/>

</TPA_Extensions> </Traveler>


<Association DomainID="A5CE" ClientCode="TN" ClientContextCode="MYS" AssociationID="104254" ProfileTypeCode="TVL"/> </Profile> Child Association: <Association DomainID="A5CE" ProfileTypeCode="TVL" AssociationID="104254" ClientCode="TN" ClientContextCode="MYS" …>

<AssociatedFilters FilterID="93356442" DomainID="A5CE"/> <ParentAssociation AssociationID="104255" DomainID="A2FE" ClientCode="TN"/>

</Association> Parent Association <Association Shared="Y" DomainID="A2FE" ProfileTypeCode="TVL" AssociationID="104255" ClientCode="TN" ClientContextCode="MYS" …>


<PNRMoveInfo AssocProfileFilterID="93356440"/> </AssociatedProfiles>

</Association> Filter: <Filter UsedByShared="Y" FilterID="93356442" DomainID="A5CE" ClientCode="TN" ClientContextCode="MYS" FilterTypeCode="TVL" ...>

<Profile> <TPA_Identity ClientCode="TN" ClientContextCode="MYS" UniqueID="*"

ProfileTypeCode="TVL" DomainID="A5CE"/> <Traveler>

<Customer> <PersonName>

<NamePrefix>*</NamePrefix> <GivenName>*</GivenName> <SurName>*</SurName>




</AssociatedProfiles> <AssociatedFormats FormatID="90568796" DomainID="A2FE"/> <AssociatedFormats FormatID="90568797" DomainID="A5CE"/>

</Filter> Data copied to PNR: Main Profile UniqueID="109282352" from domain A5CE Format 1 UniqueID=”90568796” from domain A2FE Format 2 UniqueID=”90568797” from domain A5CE Associated Profile UniqueID="109282350" 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 and the Profile ID number. 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, 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

2.CORPID

CRP-123456789

3.TAGENCY

AGY-234567890

4.OPERATIONAL

OPX-111222334

5.GROUP

GRP-756432131

6.TVLNONAME

***TVLNN-756432132

***TVLNN is Traveler Profile Type with ProfileSubType=”NN” for a TVL profile

without a name field.

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.

Note: The PI field is based only on the Profile UniqueID. It does not have PCC information stored with

it in the PNR. This is one of the reasons why the Profile UniqueID must always be auto-

generated by the Sabre Profiles system to ensure uniqueness. External systems or applications

creating profiles cannot set a value for this UniqueID.


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.

*PI«

PROFILE INDEX DATA

1.TRAVELER 1.1 GOMEZ/JOSE ANTONIO MR I

*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. Assigning a Default Filter is particularly advantageous when multiple Filters are

associated to a specific Profile, or for Profiles created from a selected Template using the Template

Manager.

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 also add unique Filters using ProfileCreate or ProfileEdit mode. Multiple Filters can

exist. Filters can be created, modified, or deleted.

A Filter can contain the following data:

A number of 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.

NOTE: For current Filter supported elements, attributes, and number of instances allowed of these fields,


Filters 15



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

Assume the SessionCreateRQ has already returned the binary session token and conversation ID for the web client session being described.

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

Immediately following this entry is the <Filter> base element. It holds the following attributes:

FilterID

DomainID

ClientCode

ClientContextCode

FilterName

FilterDescription

CreateDateTime

UpdateDateTime

FilterStatus

FilterPurgeNoOfDays

With the exception of FilterDescription, FilterStatus, and FilterPurgeNoOfDays, all attributes are required.

A sample fragment of the <Filter> section is shown below:

<Filter FilterID="*" DomainID=”A5BE” ClientCode=”TN” ClientContextCode=“ABC” 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 really 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.”

NOTE: For current Filter supported elements, attributes, and number of instances allowed of these fields, please refer to the schema xml files located on the Sabre Dev Studio. See 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, AssociatedFilters, 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=“ABC”/>

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

Unique ID 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 attributes:

DomainID (Required)

FormatID (Required)

FormatName (Required)



SequenceNo (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: Having the Format associated only under the Profile sub-element is not indicative that it should be

moved to the PNR.

<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=“ABC”> </Filter> </Sabre_OTA_ProfileCreateRS>

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 Profile. Each Error message is prefixed with C:::. The following is a sample error message:

<Sabre_OTA_ProfileCreateRS Version="1"> <ResponseMessage> <Errors> <ErrorMessage ErrorCode=”123”> C:::FLT::Invalid Filter AssociatedProfiles data</ErrorMessage> </Errors> </ResponseMessage>

<Filter FilterID="*" FilterName=”Name” DomainID="A5BE" ClientCode=”TN” ClientContextCode=“ABC” >

</Profile> </Sabre_OTA_ProfileCreateRS>


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.


schemas\Sabre_OTA_ProfileReadRQ.xsd" Version="1.0"> <Filter FilterID="4250" ClientCode="TN" ClientContextCode=“ABC” DomainID="A5BE" </Filter> </Sabre_OTA_ProfileReadRQ>

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:

<Sabre_OTA_ProfileReadRS Version="3.4" xmlns="http://www.sabre.com/eps/schemas"> <ResponseMessage> <Success/> </ResponseMessage> <Filter FilterID="25347" DomainID="A5BE" ClientCode="TN" ClientContextCode=“ABC” 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=“ABC” UniqueID="a" ProfileTypeCode="TVL" DomainID="A5BE"/> <Traveler> <Customer> <PersonName OrderSequenceNo="1"> <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> </Sabre_OTA_ProfileReadRS> <!—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:

<Sabre_OTA_ProfileReadRS> <ResponseMessage> <Errors> <ErrorMessage ErrorCode=”123”> R:::FLT::No filters have been found that match search criteria </ErrorMessage> </Errors> </ResponseMessage> </Sabre_OTA_ProfileReadRS>

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.

The following is a sample Filter Update Request:

<Sabre_OTA_ProfileUpdateRQ xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.sabre.com/eps/schemas schemas\Sabre_OTA_ProfileUpdateRQ.xsd" Version="1.0">

<Filter ClientCode="TN" ClientContextCode=“ABC” 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=“ABC” ProfileTypeCode="TVL" ProfileStatusCode="AC" ProfileNameModifyIndicator="Y" ProfileName="TNTraveler6" ProfileDescription="ProfDesc" ProfilePurgeNoDays="7"> </TPA_Identity> </Profile> </Filter> </Sabre_OTA_ProfileUpdateRQ>

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.

<Sabre_OTA_ProfileUpdateRS xmlns="http://www.sabre.com/eps/schemas" Version="1"> <ResponseMessage>


<Success /> </ResponseMessage> <Filter FilterID="3821" FilterName=”Name” DomainID="IM08"> </Filter> </Sabre_OTA_ProfileUpdateRS>

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:

<Sabre_OTA_ProfileUpdateRS Version="1"> <ResponseMessage> <Errors> <ErrorMessage ErrorCode=”123”> U:::FLT::Filter not found</ErrorMessage>

</Errors> </ResponseMessage>

</Sabre_OTA_ProfileUpdateRS>

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

ClientContextCode

FilterTypeCode

All of these attributes are mandatory. With the exception of 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" TimeStamp="2008-08-28T05:02:22.079Z" Version="1.0">

<FilterSearchCriteria ClientCode="TN" ClientContextCode=“ABC”

DomainID="A5BE" FilterName="Super*" FilterTypeCode="TVL" />

</Sabre_OTA_ProfileSearchRQ>

A successful FilterSearchRS is shown below:

<Sabre_OTA_ProfileSearchRS Version="1"> <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> </Sabre_OTA_ProfileSearchRS>

A list of Filters that match the Search criteria displays. This is the only type of Search supported.

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:

<Sabre_OTA_ProfileSearchRS Version="1"> <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

The Mark for Delete functionality is available for Filters. By sending the appropriate request, a user can

mark a Filter for delete from the Sabre Profiles database by the Purge Service after a pre-determined time

period. The Purge Service automatically begins at midnight (U.S. Central time) and searches for all Filters

marked for delete that:

Have the same purge date as the current date

Do not have a purge date.

Filters that satisfy these conditions are permanently removed from the Sabre Profiles database.

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 Mark Filter for Delete request is shown below:

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


<Sabre_OTA_ProfileDeleteRQ Version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 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> </Sabre_OTA_ProfileDeleteRQ>

All of the <Filter> attributes are mandatory. The value in PurgeDays is used by the Sabre Profiles Mark-

for-Delete engine to calculate the date the Filter is permanently removed from the Sabre Profiles

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 Mark Filter for Delete response is shown below:

<Sabre_OTA_ProfileReadRS>

<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 marked for delete, 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:

<Sabre_OTA_ProfileReadRS> <ResponseMessage> <Errors>

<ErrorMessage ErrorCode=”123”>R:::D:: Cannot delete Filter : Not found in the database

</ErrorMessage> </Errors> </ResponseMessage> </Sabre_OTA_ProfileReadRS>

The Filter was not marked for delete 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

Special case occurs when we are dealing with shared objects. Inheritance scenario is allowed by ability for a Filter to select objects from different domains. Filter can be selecting:

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

It is recommened that any Format or Associated Profile that is being associated to Filter and is coming from other domain is also associated to Associtaion object in that other domain. Profile using the Filter should be using that shared Association object. Table below shows recommended setup for object inheritance scenario when branch access between domain A2FE and A5CE is opened:

Also, please see ProfiletoPNR service description for more details on how Filters with shared content work.


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

fields, please refer to the schema xml files located on the Sabre Dev Studio.

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

Formats 16



The table below illustrates the Format Types (pre-fixes) that are currently supported by the ProfileToPNR

service:

FormatType (Prefix) FormatTypeSuffix (Optional Qualifiers)

General Info – All Airlines (3) (BIKE) Bike

(BLND) Blind

(BSCT) Bassinet

(DEAF) Deaf

(DOCA) Document Information

(DOCO) Document Information

(DOCS) Document Information

(PSPT) Document Information

(EXST) Extra Seat

(FQTV) Frequent Traveler

(INFT) Infant in PNR

(AVIH) Live Animal in Cargo Hold

(PETC) Pet in Cabin

(OSI) Other Service Information

(OTHS) Other Service Information

(SPEQ) Sports Equipment

(SSR) Special Service Request

(STCR) Stretcher Assistance

(TKNM) Ticket Number Notification

(UMNR) Unaccompanied Minor

(WCHC) Wheelchair

(WCHR) Wheelchair

(WCHS) Wheelchair

General Info – AA (4) Same as above

Remarks (5) (A¥)-(Z¥) Alpha Coded Remarks

(/) Client Address

(C-CORP) Corporate Number Remark

(DL-) Delivery Address

(-) Form of Payment Remark

(Q-) Future Queue Placement Remark

(HR-) Hidden Remark

(H-) Historical Remark

(.) Invoice Remark

(¥) Invoice Remark

(*) Invoice Name Reference Remark

Received (6)

Ticketing (7) (T-) Already Ticketed

(TAW) Future Ticketing Date

Phone (9)

Credit Card Address Verification (CC/)


FormatType (Prefix) FormatTypeSuffix (Optional Qualifiers)

Customer Number (DK)

Frequent Flyer (FF)

GetThere Queueing (FNBTS)

Name Field (-)

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=“ABC”/>

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

CreateDateTime="2010-03-23T13:46:06.277" UpdateDateTime="2010-03-23T15:20:14.366"


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=“ABC”

As shown, there are already a number of 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

Assume the SessionCreateRQ has already returned the binary session token and conversation ID for the web client session being described. 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:


<?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:ConversationId>12345</eb:ConversationId> <eb:From> <eb:PartyId type="urn:x12.org:IO5:01">99999</eb:PartyId> </eb:From> <eb:To> <eb:PartyId type="urn:x12.org:IO5:01">123123</eb:PartyId> </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:Timestamp>2001-02-15T11:15:12Z</eb:Timestamp> <eb:TimeToLive>2001-02-15T11:15:12Z</eb:TimeToLive> </eb:MessageData> </eb:MessageHeader> <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/12/utility"> <wsse:BinarySecurityToken>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/@ContactFirs

tName)" CreateDateTime="2010-03-23T13:46:06.277" UpdateDateTime="2010-03-23T15:20:14.366"


</Sabre_OTA_ProfileCreateRQ> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

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"

UpdateDateTime="2010-03-18T23:27:16.095" FormatStatusCode="AC" ClientCode="TN"


<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=“ABC”/> </Sabre_OTA_ProfileCreateRS>

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:

<Sabre_OTA_ProfileCreateRS Version="1"> <ResponseMessage> <Errors> <ErrorMessage ErrorCode=”123”> C:::FMT::Invalid Format data</ErrorMessage> </Errors> </ResponseMessage>

<Format FormatID="*" FormatName=”Name” DomainID="A5BE" /> </Sabre_OTA_ProfileCreateRS>

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.

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 MiddleName is an attribute, the

format is:

(/Profile/Traveler/Customer/PersonName[*]/@MiddleName)

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 theTelephone). The format is:

(/Profile/Traveler/Customer/Telephone[@OrderSequenceNo=’1’]/@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

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(/Profile/ 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 now support validations, truncations, and substitutions within custom formats in

Sabre Profiles including nested conditions that have to be executed in a certain order.

Users will have the ability to 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 will support 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 such as spaces, special characters completely or

could "replace" with another set of characters. This XPath structure is now supported.

Explanation of nested conditions: Sometimes there is a need to evaluate a group of conditions before

moving on to validate a separate group of conditions to create a single format. Often this conditional

hierarchy for validation starts and ends with"()" and contains ")(" or "){" to know that a group of

validations has to occur as a single action before moving on to the next action in the string which might

include another set of validations that have to occur in a group single action. There also could be multiple

validations in a single group action before moving on to the next action. A user may define up to 10

conditions within a single format string. Sabre Profiles Web Services has a function for ‘substitution’

within the XPath and also increased the size of the allowed XPath to support the potential nested

conditions.

Existing profile data can also be re-formatted. The ability to take any stored Profile data value and define

that it should be moved to PNR in a specific format such as taking a FullPhone field which could include

dashes, extensions noted with X, spaces, or all run together and format it as 999-999-9999x999 when

moved to PNR. The user determines how the data should display in the format in the PNR. Sabre Profiles

supports re-formatting using pictograms noting acceptance of alpha=a-z, numeric =0-9, dates, times,

other characters and escaped characters copied as they are. Profiles Services has a function of

‘pictogram’ within the XPath to support this.


Pictogram Function

Users can now 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 actually 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:

Examples of pictogram evaluation:

Input Pictogram Result

123 0000 0123

123 9999 123

Sabre aaa Sab

Sabre aaaaaa Sabre

fox jumping aaaa jumping fox

123456 00-00-00 12-34-56

zzzzzz aaa\a\a\abbb zzzaaabbb

zzz \\aaa\\ \zzz\

1 \0\909 0901

1234 aaaa 1234

1234 000-000 001-234

Example of XPath using Pictogram

<EmployeeInfo>

<EmployeeId>123456</EmployeeId>

</EmployeeInfo>

"(p3:pictogram(xs:string(/Profile/Traveler/Customer/EmploymentInfo/EmployeeInfo/EmployeeId),'SG0000000'))"

Evaluates to “SG0123456”when EmployeeId stored value = 123456


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

Only the entire text (not a substring) is replaced.

Substitution is case-sensitive.

Having the following substitution table:

Stored Data Substitution

Data

ABC XYZ

BC 123

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

Stored Data Substitution

Data

ABC XYZ

abc abc

ABCD ABCD

BC 123

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

R e a d F o r m a t s

Web clients can retrieve formats by specifying:

FormatID


DomainID

ClientCode

ClientContextCode

<Sabre_OTA_ProfileReadRQ Target="Production" TimeStamp="2001-12-17T09:30:47.0Z" Version="0.0" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.sabre.com/eps/schemas \schemas\Sabre_OTA_ProfileReadRQ.xsd"> <Format FormatID="20991" DomainID="A5BE" ClientCode="TN" ClientContextCode="ABC”/> </Sabre_OTA_ProfileReadRQ>

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.

<Sabre_OTA_ProfileReadRS Version="3.4" xmlns="http://www.sabre.com/eps/schemas"> <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" UpdateDateTime="2010-03-23T13:44:26.096" FormatStatusCode="AC" ClientCode="TN" ClientContextCode=“ABC”/> </Sabre_OTA_ProfileReadRS>

The Format section contains all of 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:

<Sabre_OTA_ProfileReadRS> <ResponseMessage> <Errors> <ErrorMessage ErrorCode=”123”>R:::FMT::No formats have been found that match search criteria</ErrorMessage> </Errors> </ResponseMessage> </Sabre_OTA_ProfileReadRS>

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" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="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> </Sabre_OTA_ProfileUpdateRQ>

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:

<Sabre_OTA_ProfileUpdateRS xmlns="http://www.sabre.com/eps/schemas" Version="1"> <ResponseMessage> <Success /> </ResponseMessage> <Format FormatID="4567" FormatName=”Name” DomainID="A5BE"> </Format> </Sabre_OTA_ProfileUpdateRS>

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:

<Sabre_OTA_ProfileUpdateRS Version="1">

<ResponseMessage>

<Errors>

<ErrorMessage ErrorCode=”123”>U:::FMT::Format not found</ErrorMessage>

</Errors>

</ResponseMessage>

</Sabre_OTA_ProfileUpdateRS>

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

ClientContextCode

FormatName

FormatType

FormatTypeSuffix

DomainID and ClientCode are required attributes. With the exception of 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" TimeStamp="2008-08-28T05:02:22.079Z" Version="1.0">

<FormatSearchCriteria> <Format DomainID="A2FE" ClientCode="TN" ClientContextCode=“ABC” 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=“ABC” FormatType=”5.” /> <FormatID="1684" FormatName="Format 1" DomainID="A2FE" ClientCode="TN" ClientContextCode=“ABC” FormatType=” 5¥” />

</FormatInfo> </Sabre_OTA_ProfileSearchRS>

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 Mark for Delete functionality is available for Formats. By sending the appropriate request, a user can

mark a Format for delete from the Sabre Profiles database by the Purge Service after a pre-determined

time period. The Purge Service automatically begins at midnight (U.S. Central time) and searches for all

Formats marked for delete that:

Have the same purge date as the current date

Do not have a purge date.

Formats that satisfy these conditions are permanently removed from the Sabre Profiles database.

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 Mark Format for Delete request is shown below:

<?xml version="1.0" encoding="UTF-8"?>  <Sabre_OTA_ProfileDeleteRQ Version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.sabre.com/eps/schemas \schemas\Sabre_OTA_ProfileDeleteRQ.xsd">

<Delete> <Format FormatID="235" DomainID="A5BE"

PurgeDays="1" ClientCode="TN" ClientContextCode="TN"

</Format> </Delete>


All of the <Format> attributes are mandatory. The value in PurgeDays is used by the Sabre Profiles Mark-

for-Delete engine to calculate the date the Format is pernamanetly removed from the Sabre Profiles

database. 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 Mark Format for Delete response is shown below:

<Sabre_OTA_ProfileReadRS> <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 marked for delete, 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:

<Sabre_OTA_ProfileReadRS> <ResponseMessage> <Errors>

<ErrorMessage ErrorCode=”123”>R:::D:: Cannot delete Format : Not found in the database </ErrorMessage>

</Errors> </ResponseMessage>


The Format was not marked for delete because it was not found in the Sabre database. Each error

message is prefixed with R:::D::.

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 Formats. It holds a number of 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.


O v e r v i e w

This document covers the usage of Associations Element (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 because not all features are available with this

GUI. Please refer to the Appendix in this document for more details.

Note: The term “new templates” refers to the templates implemented with Association objects in version

6.4. The “old” templates, implemented with Template objects, was discontinued in 2013 and should not be

used in any new development.

A template is an entity that defines common characteristics for multiple (possibly very many) 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)

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

3. Association

Association can be used for the following purposes:

a. define related objects that participate in moving a profile to a PNR;

b. define metadata for a profile;

c. define validations for a profile;

d. define related profiles (e.g. corporate profile, agency profile);

e. identify a profile as a member of some group

Associations are implemented by the Association object.

Templates/Associations with Metadata 17


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.

All of the above entities are described in detail in the following sections.

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

Sabre Profiles has logic of associating one object to another, e.g.

filter to profile;

format to profile;

profile to filter etc.

These associations can be done in two ways: directly and through the Association object.

Direct association means that something is associated directly to a profile, such as a filter, and this means

that this filter applies only to that specific profile. If this filter is to be applied to other profiles, it has to be

explicitly associated to these profiles. Similarly, if you want to associate another filter to all these profiles,

you would need to change them one by one, updating their direct associations.

Association through the Association object means that multiple relationships are grouped in one

dedicated object called Association. One Association object can have associations to different object

types, i.e.

1. Profiles

2. Filters

3. Formats

4. Metadata

5. Validators

A profile inherits all of these associations when the Association object is attached to the profile.

This means that multiple profiles can share the associations (by having the same Association object

attached) and that a single change of the Association object (e.g. adding a new filter to it) can affect these

multiple profiles.

The logic of the Association object

Associations have types corresponding to profile types, e.g. Traveler (TVL), Corporation (CRP) etc. The

Association Object of TVL type can be attached only to TVL profiles (same for other types). The

Association Object of TVL type can contain only objects of TVL type. This applies to all object types, except

profiles.

Objects that can be associated to an Association object can be broken down into two groups:

1. Profiles, Filters, Formats

These objects can be also associated directly to a profile. They are associated to an Association

object in the same way they are to a Profile. The main purpose of having these objects associated

is to use them in the MoveToPNR process. Please refer to the Profile to PNR Service section in this

guide for more information on the Profile to PNR service and functionality. If a profile has objects


associated directly as well as by an Association object, the former take precedence over the latter

if there could be ambiguity.

2. Metadata and Validators

These two objects types cannot be attached directly to a profile, only by Association.

Metadata objects are not processed in any way by Sabre Profiles Services. They are only stored

and retrieved. Refer to the Metadata section for more details.

Validators are used to verify the contents of a profile against defined rules. This happens during

ProfileCreate and ProfileUpdate operations if the profile has an Association defined that contains

Validators. Please refer to the Validators section for details.

With the above elements defined, the Association object serves as a template that controls common

behavior (PNR, Validations, Metadata) for a group of profiles. For example, this group can be profiles that

represent travelers who are employees of one company. All these profiles can share the same Filters,

Formats, Validations, etc. So there could be one Association for CompanyA, another for CompanyB, etc.

Please note that the Association object doesn’t need to contain objects of all of types. It can have just a

few of them. The only rule is that if there are multiple object types used, they must always go in the same

sequence as in the example above (this is defined in XML schema).

For the attribute AssociationName, validation exists in Sabre Profiles to enforce uniqueness in the value

of this attribute within the same Domain/PCC.

NOTE: For current Associations supported elements, attributes, and number of instances allowed of these


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=“ABC” 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=“ABC” DomainID="A2FE" MetadataID="1234" OrderSequenceNo="1" DisplaySequenceNo="1" ProfileTypeCode="TVL"/>

<AssociatedValidators ClientCode="TN" ClientContextCode=“ABC” DomainID="A2FE" ValidatorID="5678" OrderSequenceNo="1" DisplaySequenceNo="1" ProfileTypeCode="TVL"/>

</Association>

</Sabre_OTA_ProfileCreateRQ>

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=“ABC” DomainID="A2FE" AssociationID="89537"

ProfileTypeCode="TVL"/>

</Sabre_OTA_ProfileCreateRS>

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=“ABC” UniqueID="*" ProfileTypeCode="TVL"

ProfileName="ProfileName" ProfileNameModifyIndicator="Y" DomainID="A2FE"

ProfileStatusCode="AC"/>

<Traveler>

<Customer>


<PersonName LanguageIDCode="EN-US" OrderSequenceNo="1">

<GivenName>John</GivenName>

<SurName>Smith</SurName>

</PersonName>

</Customer>

</Traveler>

<Association ClientCode="TN" ClientContextCode=“ABC” 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"/>

</ProfileSearchCriteria>


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" ClientContextCode=“ABC”/>

<Association AssociationName=”BigCorp”/>

</ProfileSearchCriteria>


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" xsi:schemaLocation="http://www.sabre.com/eps/schemas ..\schemas\Sabre_OTA_ProfileBulkReadRQ.xsd">

<Association ClientCode="TN" DomainID="A2FE" ClientContextCode=“ABC” AssociationID="89537"

ProfileTypeCode="TVL" AssociationName="SmallCorp">



</Association>

</Sabre_OTA_ProfileUpdateRQ>

<Sabre_OTA_ProfileDeleteRQ Version="1.0" xmlns="http://www.sabre.com/eps/schemas" xsi:schemaLocation="http://www.sabre.com/eps/schemas ..\schemas\Sabre_OTA_ProfileBulkReadRQ.xsd">

<Delete>

<Association ClientCode="TN" DomainID="A2FE" ClientContextCode=“ABC” 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 as long as 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="ABC" 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="ABC"

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

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="ABC" 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="ABC" 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 ICE Security Attribute on their EPR are allowed to

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 “used by shared”

- 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 “used by shared”

- Shared Association objects can be modified to be non-shared only when all Profiles this

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 “used by shared”

only when all of the Association objects it belongs to are non-shared

- Objects (Filter, Format, Metadata, Validator) that are “used by shared” can be used in an

Association object that is shared and that is non-shared

- Objects (Filter, Format, Metadata, Validator) that are not “used by shared” 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.

<Sabre_OTA_ProfileReadRS Version="6.20" xmlns="http://www.sabre.com/eps/schemas"> <Profile CreateDateTime="2014-11-17T13:41:53.162Z" UpdateDateTime="2014-11-17T13:41:53.162Z" PrimaryLanguageIDCode="EN-US"> <TPA_Identity ClientCode="TN" ClientContextCode="ABC" UniqueID="103086131" 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="ABC" 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="ABC" ProfileTypeCode="TVL" CreateDateTime="2014-11-17T13:41:52.67Z" UpdateDateTime="2014-11-17T13:41:52.67Z" Shared="Y"/> </Profile> </Sabre_OTA_ProfileReadRS>


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

<ParentAssociation AssociationID="1559129" DomainID="A2FE" ClientCode="TN"/>

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


<AssociationSearchCriteria>

<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 Assocition 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 as long as

it is considered as child

- An Association object specified as a parent Association for a child has to 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 responsefor 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.

<Sabre_OTA_ProfileReadRS Version="6.20" xmlns="http://www.sabre.com/eps/schemas"> <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> <Profile CreateDateTime="2014-11-17T13:41:53.162Z" UpdateDateTime="2014-11-17T13:41:53.162Z" PrimaryLanguageIDCode="EN-US"> <TPA_Identity ClientCode="TN" ClientContextCode="ABC" UniqueID="103086131" ProfileTypeCode="TVL" ProfileName="TestProfile_2014-11-17_14:41:52_ftY" ProfileNameModifyIndicator="Y" DomainID="A5CE" ProfileStatusCode="AC"/> <Traveler> </Traveler> <Association AssociationID="510339" DomainID="A2FE" ClientCode="TN" AssociationName="TestAssociation_2014-11-17_14:41:52_5hh" ClientContextCode="ABC" ProfileTypeCode="TVL" CreateDateTime="2014-11-17T13:41:52.67Z" UpdateDateTime="2014-11-17T13:41:52.67Z" Shared="Y"/> </Profile> </Sabre_OTA_ProfileReadRS>

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.

- 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" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<Validator DomainID="A2FE" ValidatorID="*" ClientCode="TN" ClientContextCode="ABC" ProfileTypeCode="TVL"

ValidatorDescription="TelephoneRequired">

<ValidatorRule XPath="//Profile/Traveler/Customer/Telephone">

<Restriction>RQ</Restriction>

</ValidatorRule>

</Validator>


This validator requires at least one Telephone to be included in a traveler profile. The detailed description

is below:


ClientCode, DomainID and

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

<ValidatorRule XPath="//Profile/Traveler/Customer/PersonName/GivenName">

<RegexpRule Regexp="[A-Z]{1}.*"/>

</ValidatorRule>

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 a Metadata that defines the following scope of profile data:

- Person Name

- One home telephone

- Two business telephones


<Metadata ClientCode="TN" ClientContextCode="ABC" DomainID="A2FE" MetadataID="*" MetadataName="Sample traveler" ProfileTypeCode="TVL">

<MetaTag XPath="//Profile/Traveler/Customer/PersonName" Accessibility="RW" NmbrOfElements="1"/>

<MetaTag XPath="//Profile/Traveler/Customer/Telephone[@LocationTypeCode='HOM']" Accessibility="RW"

NmbrOfElements="1"/>

<MetaTag XPath="//Profile/Traveler/Customer/Telephone[@LocationTypeCode='BUS']" Accessibility="RW"

NmbrOfElements="2" DefaultValue="+1 555 555" />

</Metadata>




ClientCode, DomainID and

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 Bulk Read service is designed to retrieve multiple objects with one service call.

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 700 <Profile> elements that identify

which Profiles are to be retrieved. A sample request to retrieve two Profiles is shown below:

<Sabre_OTA_ProfileBulkReadRQ ClientContextCode=“ABC” Target="Production" TimeStamp="2010-06-

30T12:47:22.299Z " Version="0.0" xsi:schemaLocation="http://www.sabre.com/eps/schemas

\schemas\Sabre_OTA_ProfileReadRQ.xsd" xmlns="http://www.sabre.com/eps/schemas"


<Profile> <Profile> <TPA_Identity ClientCode="TN" DomainID="A2FE" ProfileStatusCode="AC" ProfileTypeCode="TVL" UniqueID="101816926" /> </Profile> <Profile> <TPA_Identity ClientCode="TN" DomainID="A2FE" ProfileStatusCode="AC" ProfileTypeCode="OPX" UniqueID="101370096" /> </Profile> </Profile> </Sabre_OTA_ProfileBulkReadRQ>

Notes:

The service returns the entire content of each Profile (all subject areas).

The schema allows the following tags to control which subject areas are returned, but this functionality has not yet been implemented.

<PartialReadSubjectAreas>

<IgnoreReadSubjectAreas>

Web service caller can request credit card numbers returned in a BulkRead response to be tokenized. In order to receive a tokenized credit card number the web service caller has to include the ReturnPaymentCardToken attribute with a value of “Y” in a request message.

Bulk Read Services 18



When the Sabre_OTA_ProfileBulkReadRQ/@ReturnPaymentCardToken =”Y” is included in the request, a tokenized credit card number is returned each time PaymentForm/PaymentCard element is returned in the response.

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 the Profiles are successfully retrieved, the response contains the contents of the requested Profiles. A

sample response is shown below:

<Sabre_OTA_ProfileBulkReadRS Version="6.2" xmlns="http://www.sabre.com/eps/schemas"> <ResponseMessage> <Success /> </ResponseMessage> <Profile> <Profile CreateDateTime="2011-09-23T10:00:27.056Z"

UpdateDateTime="2011-09-23T10:00:27.056Z" PrimaryLanguageIDCode="EN"> <TPA_Identity ClientCode="TN" ClientContextCode=“ABC”

UniqueID="101816926" ProfileTypeCode="TVL" 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">

<NamePrefix>Mr</NamePrefix> <GivenName>JOHN</GivenName> </PersonName> </Customer> </Traveler> </Profile> <Profile CreateDateTime="2010-08-25T09:32:37.611Z"

UpdateDateTime="2010-08-25T09:34:33.638Z" PrimaryLanguageIDCode="EN-US">



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

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

If some (or all) of the requested profiles are not found, or if other problems arose during retrieval, an

error response is returned. If an error occurs only for some profiles, but some are read successfully, the

response contains both error messages and profile content. A sample error message response is shown

below:

<Sabre_OTA_ProfileBulkReadRS Version="6.2" xmlns="http://www.sabre.com/eps/schemas"> <ResponseMessage> <Errors> <ErrorMessage ErrorCode="123">NDEVT20110930140055SBR::No profile is found which match your selection criteria (UniqueID = 1101816926, ClientCode = TN, ClientContextCode = ABC, DomainID = A2FE, ProfileTypeCode = TVL, LoginID = null)</ErrorMessage> <ErrorMessage ErrorCode="123">NDEVT20110930140055SBR::No profile is found which match your selection criteria (UniqueID = 1101370096, ClientCode = TN, ClientContextCode = ABC, DomainID = A2FE, ProfileTypeCode = OPX, LoginID = null)</ErrorMessage> </Errors> </ResponseMessage> <Profile /> </Sabre_OTA_ProfileBulkReadRS>

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

elements that identify which Association IDs are to be retrieved. A sample request to retrieve two

AssociationIDs is shown below:


27T10:56:36.183Z" Version="0.0" xsi:schemaLocation="http://www.sabre.com/eps/schemas

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




<Associations>

<Association AssociationID="44541" ClientCode="TN" DomainID="A2FE"/>

<Association AssociationID="44543" ClientCode="TN" DomainID="A2FE"/>

</Associations>

</Sabre_OTA_ProfileBulkReadRQ>

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 including Formats, Filters, Associated Profiles, Metadata, and Validators. A sample response

is shown below:

<Sabre_OTA_ProfileBulkReadRS TimeStamp="2013-06-27T10:56:36.183Z" Target="Production"

Version="0.0" xmlns="http://www.sabre.com/eps/schemas">

<ResponseMessage>

<Success/>

</ResponseMessage>

<Associations>

<Association AssociationID="44541" DomainID="A2FE" ClientCode="TN"

AssociationName="TestAssociation_2013-06-27_10:56:36_s0C_1" ClientContextCode=“ABC”

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=“ABC”

ProfileRelationTypeCode="AL" AssocFiltersInd="N"/>





<AssociatedFilters DomainID="A2FE" FilterID="541577" SequenceNo="2"

DisplaySequenceNo="1" FilterName="TestFilter_2013-06-27_10:56:36_JbZ"/>



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




















</Association>

</Associations>

</Sabre_OTA_ProfileBulkReadRS>

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

If some (or all) of the requested AssociationIDs are not found, or if other problems occur during retrieval,

an error response is returned. If an error occurs only for some AssociationIDs, but some are read

successfully, the response contains both error messages and Association ID content.

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 500 <Format> elements that identify

which Formats are to be retrieved. A sample request to retrieve two Formats is shown below:





<Format> <Format FormatID="215458" DomainID="A2FE" ClientCode="TN" /> <Format FormatID="215471" DomainID="A2FE" ClientCode="TN" /> </Format> </Sabre_OTA_ProfileBulkReadRQ>


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 the Formats are successfully retrieved, the response contains the contents of the requested Formats. A


<Sabre_OTA_ProfileBulkReadRS Version="6.2" xmlns="http://www.sabre.com/eps/schemas"> <ResponseMessage> <Success /> </ResponseMessage> <Format> <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=“ABC” /> <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=“ABC” /> </Format> </Sabre_OTA_ProfileBulkReadRS>

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

If some (or all) of the requested formats are not found, or if other problems arose during retrieval, an

error response is returned. If an error occurs only for some formats, but some are read successfully, the

response contains both error messages and format content.

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 500 <Filter> elements that identify which

Filters are to be retrieved. A sample request to retrieve two Filters is shown below:





<Filter> <Filter ClientCode="TN" ClientContextCode=“ABC” DomainID="A2FE" FilterID="389498" /> <Filter ClientCode="TN" ClientContextCode=“ABC” DomainID="A2FE" FilterID="389499" /> </Filter> </Sabre_OTA_ProfileBulkReadRQ>


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 the Filters are successfully retrieved, the response contains the contents of the requested Filters. A


<Sabre_OTA_ProfileBulkReadRS Version="6.2" xmlns="http://www.sabre.com/eps/schemas"> <ResponseMessage> <Success /> </ResponseMessage> <Filter> <Filter FilterID="389498" DomainID="A2FE" ClientCode="TN" ClientContextCode=“ABC” 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=“ABC” UniqueID="*" ProfileTypeCode="AGT" DomainID="A2FE" /> <TravelAgent> <AgentName GivenName="dggg" SurName="sff" OrderSequenceNo="1" /> </TravelAgent> </Profile> </Filter> <Filter FilterID="389499" DomainID="A2FE" ClientCode="TN" ClientContextCode=“ABC” FilterName="AssociatedProfileFilter" FilterDescription="FDesc" CreateDateTime="2011-09-19T09:42:35.825Z" UpdateDateTime="2011-09-19T09:42:35.825Z" FilterStatusCode="AC" FilterTypeCode="TVL"> <Profile> <TPA_Identity ClientCode="TN" ClientContextCode=“ABC” UniqueID="*" ProfileTypeCode="TVL" ProfileName="TNTraveler6" ProfileDescription="ProfDesc" DomainID="A2FE" /> <Traveler> <Customer> <PersonName OrderSequenceNo="1"> <NamePrefix>XXX</NamePrefix> <GivenName>XXX</GivenName> <MiddleName>XXX</MiddleName> <SurName>XXX</SurName> <NameSuffix>XX</NameSuffix> </PersonName> </Customer> </Traveler> </Profile> </Filter> </Filter> </Sabre_OTA_ProfileBulkReadRS>

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

If some (or all) of the requested filters are not found, or if other problems arose during retrieval, an error

response is returned. If an error occurs only for some filters, but some are read successfully, the response

contains both error messages and filter content.


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

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)

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=“ABC” DomainID="XXXX"

ProfileName="Sample Profile Name" ProfileTypeCode="TVL" UniqueID="123456789"/>

</swse:ProfileEvent>

</swse:Sabre_OTA_EventNotification>

</soap-env:Body>

Notification Services (ENS and PNS) 19



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=“ABC” 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

ENS and Sabre Profiles 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



S a b r e P r o f i l e s N o t i f i c a t i o n S e r v i c e ( P N S )

Document Conventions

The following terms, which are used in Sabre Profiles Notification Service documentation, are described below:

This Naming Convention ... Is Used in Documentation as Follows ...

(event sync) application The application with the listener for the event sync, that handles the notifications. The subscribing entity creates this.

connection An open channel to the Sabre Web Services infrastructure

Sabre Dev Studio The private registry and repository of artifacts and information for Sabre APIs, and other resources for developers using Sabre products

outage email notification An email message that is sent to the subscribing entity’s administrator, advising the subscriber when attempts to deliver notifications to the endpoint are unsuccessful

subscribing entity This is the entity, such as an airline, loyalty system or other business that registers to use Sabre Profiles Notification Service and receives notifications of events.

Terminology

The following terms are related to Sabre Profiles Notification Service.

Term Description

delivery mode* The mechanism by which notifications are delivered from the source to the synchronization For Sabre Profiles Notification Service, this is a “push method”.

event sync * In this document, an event synchronization (event sync) is an application that receives the notifications on a URL.

It is an event listener on the system of the subscribing entity that waits for an event that will trigger the application code.

event source* According to the WS-Eventing specification, it is a Web service that sends notifications and accepts requests to create subscriptions.

In this document, an event source is the component of Sabre Profiles that produces messages for subscriptions.

event topic A type of event for which notification messages are sent.

Event types for Sabre Profiles Notification Service are:

New Profile

Changed Profile

Deleted Profile

Restored Profile

notification* The WS-Eventing specification uses the term notification and describes it as follows:


A one-way message sent to the event sync advising that an event has occurred. This document uses the terms notification and notification message.

push mode* The WS-Eventing specification describes this as a delivery mechanism where the source sends event messages [notifications] to the synchronization as individual, unsolicited, asynchronous SOAP messages.

Sabre Publishers Producer of messages for Profile change. This is the SabreProfiles system.

*The source of this information was taken from http://www.w3.org/Submission/2006/SUBM-WS-

Eventing-20060315/, submitted 15 March 2006. Copyright 1994-2007 W3C (Massachusetts Institute of

Technology, European Research Consortium for Informatics and Mathematics, Keio University), All Rights

Reserved.

W e b S e r v i c e s E v e n t T e c h n o l o g y O v e r v i e w

Events are actions that are initiated by users or systems which can be detected by software programs. Example of events is changes to profile. According to several industry experts who are jointly submitting a specification about eventing, events are being defined as real-world occurrences that trigger actions in software.

Additionally, they define Web services eventing, also referred to as WS-Eventing, as a technology that provides a common way to communicate events. WS-Eventing is a draft specification that basically allows a Web service to subscribe to and accept subscriptions for event topics generated by other Web services. Web services can send and receive information about events that have occurred, regardless of where the event originates. The proposed draft includes a set of protocols, message formats, and interfaces that enable a Web service to subscribe to events from another Web service.

WS-Eventing supports SOAP 1.1 and 1.2 Envelopes.

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

With Sabre Profiles Notification Service, subscribing entities receive notifications whenever events to which they subscribe occur. The events available in this release of the product are profiles:

- Create - Update - Delete - Restore

Profiles Notification Service is based on the public draft release of the Web Services Eventing Specification of August 2004. All notifications are OTA XML compliant.

Sabre Profiles Notification Service sends the notifications to the receiving URL of the subscriber, called the “event sync”, in nearly real-time after the events occur.

When an event is triggered that matches the parameters that were specified in a subscription, the event sync application receives the notification in structured XML format via the IP address or URL in the subscription. If the event does not match the specified parameter, the Event Source does not send the notification to the event sync.


The notifications are delivered as XML messages. Sabre Profile Notification Service uses the HTTP POST method to send the notifications.

Benefits

Using Profiles Notification Service reduces long-term IT costs due to the following:

Elimination of dedicated network connections to the Sabre® system

Reduction in application development and maintenance costs

A shortened development life cycle

Lower infrastructure costs because the infrastructure is reduced (Internet connectivity)

Platform and technology independence (interoperability)

Lower integration and deployment costs. Using open standards and Web Services Eventing standards enable the use of interoperable publish/subscribe systems

Reduces costs – alerting you of changes instead of you generating system inquiries

Product Features

High Reliability

Sabre Profiles Notification Service is designed to deliver messages with high reliability. The goal is for all components that comprise the infrastructure to be available 24x7, with the exception of scheduled maintenance. A window for maintenance activities will be established at a regular time and communicated to subscribing entities. When the need for maintenance arises, Sabre Profiles Notification Service will be unavailable during this maintenance window only, on an as needed basis.

Fast Delivery

The Profiles Notification Service infrastructure provides nearly real-time delivery of notifications. The notification is pushed when an event occurs.

Throttling of Notification Delivery per Endpoint

During configuration process the subscriber defines throttling limits for subscription. Profiles Notification Service guarantees to not exceed the agreed upon throttling limit to not flood the event sync application. How to define the parameters for the subscription is explained later.

Delivery Retry

If Sabre Profiles Notification Service cannot deliver the message because of communication issues, it retries delivery after the communication is established.

If a notification is delivered, but the business exception occurs (for example event sync application errors during storing the notification), the Sabre Profiles Notification Service will retry up to 5 times to send the notification. If all 5 attempts to deliver the notification fail because of an event sync application error, the event will be marked as failed and an error email notification will be sent with information that sending the notification for given UniqueID was not possible.


Failed Endpoints

If the system fails to deliver more than 10 notifications to the subscriber, Sabre Profiles Notification Service goes into a suspended state and stops trying to send notification for 120 seconds. The subscriber URL is marked as failed or not alive, and Sabre Profiles Notification Service stops attempting to deliver notifications (internal system circuit breaker is in the open state).

After 2 minutes, Sabre Profiles Notification Service tries to reconnect to the failed endpoint by sending one pending notification from the queue (the circuit breaker is in half-open state). Sabre Profiles Notification Service continues to try to reconnect every 2 minutes to ascertain whether the endpoint is alive.

If the communication is established (sending the one pending notification was successful) the delivery of notifications is resumed (the circuit breaker is in closed state).

Outage Email Notifications

Whenever the endpoint of the subscribing entity experiences an outage, Sabre Profiles Notification Service sends an outage email notification to the email address of the support team of the subscribing entity.

When the endpoint is marked as failed and notification sending is suspended, a retry email notification is sent, warning that notifications will stop being delivered to the endpoint. This email will inform: a communication exception has occurred and the system has been unable to deliver notifications after re-try attempts and that notification is now suspended. Notifications for profiles stored in queue will resume after communication has been restored. It will include the “time/date” stamp along with the domain ID and contact email for additional support.

If the communication issue still occurs, a retry email notification is sent every 5 minutes until the communication issue is resolved.

When communication has been established, end-retry email is sent. The message indicates that the connection has been restored and notification will resume with notifications pending in queue. It will include the “time/date” stamp along with the domain ID.

Examples of outage email notifications are shown later in this section.

Resume Delivery

When the endpoint of the event sync is alive again, delivery of queued and new notifications resumes.

Specifications and Standards the Product Meets

WS-Eventing, a public draft of the Web Services Eventing Specification, was released in August 2004. This is one of many “WS-“ proposals. It was offered by BEA Systems, Microsoft Corporation, Tibco Software, Inc., Computer Associates International, Inc., Sun Microsystems, and IBM Corp. It is a unified protocol proposed for Java and Microsoft .NET Framework “Events.”

The specification is published on the following sites:


http://www.w3.org/Submission/WS-Eventing/ - The proposed submission to the W3C of the specification

http://www-128.ibm.com/developerworks/library/specification/ws-eventing/ - From IBM’s link, you can download the WS-Eventing specification, and the WSDL and XML schema definition.

http://www.idevnews.com/IntegrationNews.asp?ID=99

Rules for Subscriptions

Subscribing entities can create subscriptions to event topics using any URL they wish. The receiving URLs must “listen” to Sabre Profiles Notification Service messages on HTTP port 80 or on HTTPS port 443.

In combination with providing the URL for receiving the notification messages, the customer should also ensure that the system they use to send any Profile Create or Update calls to Sabre Profiles (or any supporting partner systems) includes the dedicated assigned Profile>TPA_Identity>ProfileSubType> SubTypeCode provided by the Sabre Profiles team. This SubTypeCode will assist with the configuration of PNS to ensure the customer’s “listener” (or target system) is sent the requested event topics messages.

Requirements for “Event Sync”

The Sabre Profiles Notification Services infrastructure supports HTTP on port 80 and SLL connections on port 443. Your firewall must allow both inbound and outbound traffic.

All the Profile Notification Service requests will require synchronous response to immediately confirm delivery providing acknowledgement for the notification success. Your event sync must send a response to Sabre Event Notification Services in the prescribed format within 2 seconds after the delivery of every notification message. (For more information, see “Acknowledgements by the Event Sync”).

The event sync must respond with “Success” response to the “Test Request”. If your event sync fails to respond in this way, Sabre Profiles Notification Service interprets this as an inactive or failed endpoint and takes other action. For more information see “Responding to Pings”.

You can design your event sync application to verify that the notification messages it receives are not duplicates of the same message.

R e c e i v i n g a n d p r o c e s s i n g e v e n t n o t i f i c a t i o n s

After your subscription is activated, events that meet your criteria and includes the dedicated ProfileSubTypeCode is pushed in XML format to the URL you supplied. Your event sync application (customer’s receiving end) should parse the content and record the profile’s UniqueID and action for further processing.

However, any subsequent actions/processes to follow for the customer’s system to obtain the profile details calling existing Profile services via USG to Read the profile should not hold the notification services. These two must be handled separately and asynchronously.


E v e n t T o p i c N o t i f i c a t i o n M e s s a g e s

This section describes event notifications messages followed by a general description of the SOAP message header.

SOAP Header Format for Notification Messages

Sabre Profiles Notification Service obtains content from Production systems. Notifications are delivered using the HTTP POST method.

Notification messages are formatted as XML and are OTA XML compliant. They are delivered as SOAP envelopes with a header and body. The notification portion of the message is wrapped inside the body in a root element that is specific to the event topic.

Soap headers are optional, and determined by the client implementation of the event sync service.

The SOAP body includes the root element and payload, that is, the actual notification content.

Format of notification payload

Sabre Profiles Notification Service prepares the notification payload according to Sabre_OTA_EventNotification XML schema.

The diagrams below present an illustration of the request schema for the notification service:


Example of notification payload:

<Sabre_OTA_EventNotification xmlns="http://www.sabre.com/eps/schemas">

<ProfileEvent>

<Action Timestamp="2012-05-30T10:42:13.214Z" Type="CREATE"/>

<TPA_Identity ClientCode="TN" ClientContextCode=“ABC” DomainID="ABCD”

ProfileTypeCode="TVL" UniqueID="101873442"/>

<ProfileSubType SubTypeCode=”XXX”/>

</ProfileEvent>

</Sabre_OTA_EventNotification>

More samples of notifications you can find later in this section.

Request tracking identificator: RequestTrackingID

Profiles Notification Service generates a unique id (GUID) and sends it in a @RequestTrackingID attribute in an every notification message. This ID can be used for tracking/troubleshoot purposes. The event sync application should record data with RequestTrackingID in logs or database.

Event Sync Application Design

In order to manage subscriptions, you must use the schema documents for the notification you want to receive. The schemas show you the message formats, the optional and required data elements, and content that is included in the notifications. You design your application to parse the content you want, and then use the parsed content any way you wish.

When an event occurs that meets the criteria you specified in the subscription process, you automatically receive a notification as a structured XML message on the URL you supplied in the subscription.

Some of the facets of your design for the event sync application are discussed below:

Event sync acknowledgements

Duplicate delivery of a notification message


Responses to pings by Sabre Profiles Notification Service

Acknowledgements by the Event Sync

Your event sync must acknowledge receipt of all notifications. The purpose of the acknowledgement is to tell Sabre Profiles Notification Services that a specific notification was received.

You are advised to set confirmation to occur immediately after delivery, and to respond within 2 seconds.

Sabre Profiles Notification Service requires your event sync to response to notification in Sabre_OTA_EventNotificationRS schema. You can download the current xsd files for Sabre_OTA_EventNotification request and Sabre_OTA_EventNotificationRS from Sabre Dev Studio.

The diagram below presents an illustration of the response schema for the notification service (notice optional elements marked in dotted lines and required attributes/elements in continuous line):

Sample response that is returned if the notification message was received by the event sync:

<Sabre_OTA_EventNotificationRS RequestTrackingID="1245679" TimeStamp="2001-12-17T09:30:47Z" Version="6.7" xsi:schemaLocation="http://www.sabre.com/eps/schemas Sabre_OTA_EventNotificationRS.xsd" xmlns="http://www.sabre.com/eps/schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Success/> </Sabre_OTA_EventNotificationRS>



Duplicate Delivery of Notifications

If Sabre Profile Notification Service fails to receive an acknowledgement from an event sync, Sabre Profiles Notification Service tries to send the notification a second or third time, as usual. Because of this, it is possible that the event sync will receive duplicates of the same notification.

This can happen if the notification message is delivered to the event sync and the event sync sends an acknowledgement, but the acknowledgement is not delivered. This could be due either to a network outage, a connection time-out, or a component of the Sabre Profiles Notification Service architecture being unavailable. Because the acknowledgement is not received, Sabre Profiles Notification Service sends the same message a second time.

Delivery failures are usually the result of malfunctions, most often due to network problems. Subscribing entities are responsible for their network connections. If their networks are unreliable, they may receive duplicate messages often.

Sample Scenario of a Duplicate Delivery

In this scenario, Sabre Profiles Notification Service sends a notification twice.

1. Sabre Profiles Notification Service sends a notification to the event sync. 2. The event sync receives the notification and sends an acknowledgement. 3. A brief network outage occurs. 4. Sabre Profiles Notification Service does not receive the acknowledgement in the required format. 5. Sabre Profiles Notification Service sends the same notification to the event sync. 6. The event sync receives the notification and sends a second acknowledgement. 7. Sabre Profiles Notification Service receives the acknowledgement from the event sync.

Verifying the Uniqueness of a Message ID

When you design your event sync application, you can verify whether the @UniqueID and @Timestamp attribute in notification messages has been received, and thereby avoid handling duplicate data.

Every notification has a pair of @UniqueID and @Timestamp attributes. When the same message is sent multiple times, the pair of @UniqueID and @Timestamp attributes are the same.

Responding to Pings

Sabre Profiles Notification Service sends a test request to ping the endpoint of your event sync. The test request is the special version of the Sabre_OTA_EventNotification request with UniqueID = “NS_TEST”.


When Sabre Profiles Notification Service pings the endpoint of your event sync, you are required to respond and ignore this test notification on your side. All event syncs must support this. It is used to verify that the event sync is operational.

The flow is as follows:

1. Sabre Profiles Notification Service sends the test request 2. Event Sync response with “Success” response message and ignoring the notification (this

is only for test purpose) 3. Sabre Profiles Notification Service accepts the response, and ensures that the response is

“Success”.

O r d e r i n g a n d R e g i s t r a t i o n P h a s e

Information and values you provided to your Sabre account representative during the product set up phase affects your subscriptions, event sync application behavior, and the behavior of Sabre Profiles Notification Service.

You supply or confirm the following:

Profiles criteria for which the notification should be sent

You are able to configure notification events per Profile type, subtype and source system of the profile change. Thanks to that your event sync will receive notifications only when changes are originated from the selected system and for certain profile types/subtypes.

1. Profile type – Sabre Profiles supports the following profile types: a. Traveler b. Corporate c. Agency d. Agent e. Group f. Operational

2. Profile subtype - simply used as additional qualifiers to designate certain qualities in an individual’s profile. The following subtypes are available:

a. For Type= TVL (Traveler) Subtype =NN (TravelerNoName) and GT (GetThere) b. For all Types=TVL, OPX, AGY, AGT, GRP, CRP Subtype=XXX (dedicated Customer SubType

created and assigned by Profiles Services Team at time of implementation)

3. Client Context Code The Sabre Profiles system identifies the source of the profiles change, in order to trigger the notification only when the update is coming from configured source. For example you may want to get only notification when source of modification is from a Sabre system and do not send notification when action is coming from your system to avoid an infinite loop for replicating into one another. For this, Sabre Profiles uses the “ClientContextCode” field that is included in the “TPA_Identity” section of the schema. Each system that integrates with Sabre Profiles has a designated value/code that must be used in all web service transaction requests.


Connectivity settings

1. Transport level security: SSL or no encryption 2. Required SOAP headers - Soap headers are optional, and determined by the client

implementation of the event sync service. Customer needs to provide the example with all needed SOAP headers.

3. What security requirements does the supplier have? a. Require use of VPN tunneling for external system to connect. b. Require connections to originate from specific IP address in order to configure firewall

4. Does the supplier allow multiple connections from the same source IP? 5. What throttling requirements does the event sync have? 6. Event sync EndPoint IP Address for each environment 7. Event sync EndPoint URL for each environment 8. Credentials required for each environment, if applicable 9. Expected traffic

a. Transactions per second - Average b. Peak time of day

10. Please provide your consumer team contact information (name, email, role, phone) 11. A contact email address for Sabre Event Notification Services to send notices about failed delivery

of notifications and non-responding URLs

N o t i f i c a t i o n e x a m p l e s

Create


<ProfileEvent>

<Action Timestamp="2012-05-30T10:42:13.214Z" Type="CREATE"/>

<TPA_Identity ClientCode="TN" ClientContextCode=“ABC” DomainID="ABCDE”


<ProfileSubType SubTypeCode=”XXX”/>

</ProfileEvent>


Update


<ProfileEvent>

<Action Timestamp="2012-05-29T16:01:21.486Z" Type="UPDATE"/>

<TPA_Identity ClientCode="TN" ClientContextCode=“ABC” DomainID="ABCD"


<SubjectArea Name="ContactName"/>

</ProfileEvent>



Update sample 2


<ProfileEvent>

<Action Timestamp="2012-05-29T07:52:22.914Z" Type="UPDATE"/>



<SubjectArea Name="TPA_Identity"/>

<SubjectArea Name="GroupInfo"/>

<SubjectArea Name="ContactName"/>

<SubjectArea Name="Address"/>

<SubjectArea Name="Telephone"/>

<SubjectArea Name="Email" OrderSequenceNo="1"/>

<SubjectArea Name="PaymentForm"/>

<SubjectArea Name="AirlinePref" OrderSequenceNo="2">

<SubjectArea Name="AirlineSeatPref" OrderSequenceNo="1"/>

</SubjectArea>

</ProfileEvent>


Delete


<ProfileEvent>

<Action PurgeTimestamp="2012-05-29T16:01:33.067Z" Timestamp="2012-05-29T16:01:32.975Z"

Type="DELETE"/>



</ProfileEvent>


Restore

(within the same day of a delete, restore is possible)


<ProfileEvent>

<Action PurgeTimestamp="2012-05-29T16:01:33.067Z" Timestamp="2012-05-29T16:01:29.486Z"

Type="RESTORE"/>



</ProfileEvent>



Response:

All notifications should be given a synchronous response to complete the transaction acknowledging the

recipient of the notification:

Success response:

<Sabre_OTA_EventNotificationRS RequestTrackingID="1245679" TimeStamp="2001-12-17T09:30:47Z"

Version="6.7" xsi:schemaLocation="http://www.sabre.com/eps/schemas Sabre_OTA_EventNotificationRS.xsd"


<Success/>

</Sabre_OTA_EventNotificationRS>

Failure response:

<Sabre_OTA_EventNotificationRS RequestTrackingID="1245679" TimeStamp="2001-12-17T09:30:47Z"

Version="6.7" xsi:schemaLocation="http://www.sabre.com/eps/schemas Sabre_OTA_EventNotificationRS.xsd"


<Error ErrorCode=”SUBSCRIBER_INTERNAL_ERROR” />

</Sabre_OTA_EventNotificationRS>

O u t a g e e m a i l n o t i f i c a t i o n

Retry email

Profile Notification - A communication exception has occurred and the system has been unable to deliver

notification after re-try attemps. 2012-08-23 13:12:13 for Domain: XXXX

The notification is now suspended.

Notifications for profiles stored in queue will resume after communication has been restored.

Sabre Customer Profiles

Note: This email was sent from a notification-only address that cannot accept incoming email. Please do

not reply to this message. If you need additional assistance please contact [email protected]

End-retry email

Profile Notification - Profile Notification - Communication has been restored at 2012-08-23 14:14:22 for

Domain: XXXX

Pending profile notifications in queue will resume now.

Sabre Customer Profiles



Note: This email was sent from a notification-only address that cannot accept incoming email. Please do

not reply to this message. If you need additional assistance please contact [email protected]

Detailed email

Profile Notification - A communication exception occurred at 2012-08-23 14:14:22 for Domain: XXXX When sending notification for Profile UniqueID: 1234567 The system will attempt to re-send the notification. Sabre Customer Profiles Note: This email was sent from a notification-only address that cannot accept incoming email. Please do not reply to this message. If you need additional assistance please contact [email protected]




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

PartialUpdates/Delete/DeleteSubtree/MatchSubtree/Traveler/

EmergencyContactPerson

AirlinePref

HotelPref

VehicleRentalPref

CustomDefinedData

PartialUpdates/Delete/DeleteElement/MatchData/Traveler/

@ProfileStatus

@Description

PartialUpdates/Add/AddSubtree/Newsubtree/Traveler/

EmergeContactPerson

A – Sections Pending

Implementation

A


AirlinePref

HotelPref

VehicleRentalPref

CustomDefinedData

PartialUpdates/Add/AddElement/NewData/Traveler/

@MaritalStatus

@ProfileStatus

@LoginID

@Password

@Description

PartialUpdates/Modify/ModifySubtree/MatchSubtree/Traveler/ (same as NewSubtree/Traveler)

EmergeContactPerson

AirlinePref

HotelPref

VehicleRentalPref

CustomDefinedData

PartialUpdates/Modify/ModifyElement/MatchData/Traveler/ (same as NewData/Traveler)

@LoginID

@Password

@Description

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)


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

@LocationTypeCode

AGY

@InformationText

Full AGY Phone

@PhoneCityCode

KRK

@PNRTelephoneTagIndicator

Y/N

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

@PNRTelephoneTagIndicator

Y/N


Email

@EmailAddress

[email protected]

PE#@EmailAddress#@EmailUsageCode/@EmailRemark 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 1

st email address entered in host is the last

email displayed in the 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

@EmailUsageCode

FRM

@EmailRemark

Email Remark

Address

@Attention Attention

If @LocationTypeCode=AGY (Agency) then format is: W-@Attention#AddressLine1#AddressLine2#AddressLine3#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 5DL-Line3 5DL-Line4 5DL-CityName StateCode PostalCd 5DL-CountryCode Example: 5DL-ATTENTION

AddressLine1 Line 1

AddressLine2 Line 2

AddressLine3 Line 3

AddressLine4 Line 4

CityName Krakow

StateCode MA


PostalCd 30-348

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 Unknown

CountryCode PL

PaymentForm

@BankCardVendorCode

AX For CreditCard: (when ServiceUsageTypeCode=”AL” or “OT”) 5-*@BankCardVendorCode@CardNumber#@ExpireDate@InformationText 5-CH#CardHolderFullName Example: 5-*AXXXXXXXXXXXXX7551#01/15-XN 5-CH#MAT BEAR For Cash: 5-CASH@InformationText Example: 5-CASH FOP REMARK For Check: 5-@PNRCheckCode@InformationText Example: 5-CHECK FOP REMARK

@CardNumber

378302914317551

@ExpireDate 012015

@InformationText

-XN or FOP REMARK

CardHolderFullName

MAT BEAR

Cash

@PNRCheckCode

CHECK


@FirstRemark

Y/N

5-@PNRCheckCode@InformationText with FirstRemark="Y" Example: 50/-CHECK FOP REMARK If PaymentCard is in filter and ServiceUsageTypeCode=”CR” or “HL”:

5C¥/G@BankCardVendorCode@CardNumberEXP @expiredate = MM

YY-@CardHolderName>SurName

5H¥/G@BankCardVendorCode@CardNumberEXP @expiredate =

MM YY-@CardHolderName>SurName

Example:

5C¥/GCA543211234567890EXP 12 14-BEAR

5H¥/GCA543211234567890EXP 12 14-BEAR

PaymentForm>GovernmentWarrant

@FirstRemark

Y/N

IF GR:

5-

aymentForm>GovernmentWarrant>WarrantType)(PaymentForm>Go

vernmentWarrant>WarrantNumber)-

(PaymentForm>InformationText)

Example:

5-GR¥1234567890ABC-GOVT WARRANT INFORMATION

IF GGR:

5-

(PaymentForm>GovernmentWarrant>WarrantType)(PaymentF

orm>GovernmentWarrant>WarrantySubtype)(GovernmentWa

rrant>WarrantNumber)-(GovernmentWarrant>DebtorCd)-

(GovernmentWarrant>ObjectCd)-

(PaymentForm>InformationText)

Example:

5-GGRGOMABC1234567890-987654321XYZ-123ABC-GOM

FORM OF PAYMENT

If FGR:

5-(PaymentForm>GovernmentWarrant>WarrantType)REQ-

(PaymentForm>GovernmentWarrant>WarrantNumber)

WarrantType GR, GGR, FGR

WarrantSubtype

GOM, WPM, ATR

WarrantNumber

ABC123456789

DebtorCd 987654321XYZ

ObjectCd 123ABC

PaymentForm>@InformationText

Warrant Information


Example:

5-FGRREQ-19876543002

CustomerReferenceInfo

@BranchID 12 DK@BranchID@ReferenceID Example: DK123456 DK1234567 DK1234567890 @ReferenceI

D

3456, 34567, 34567890

Discounts

@VendorCode

AF

For SUB Discount: SC#/@VendorCode@ID Example: SC#/AF777710 For CID Discount: CID-@ID Example: CID-777710

@ID 777710

@TypeCode SUB/CID

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

r)

@VendorCode

UA FF@VendorCode@MembershipID/AssociatedVendorCode-SurName/LastName MiddleName Example: FFUA03111968186/AC-BEAR/VERNON VAN @Membershi

pID 03111968186

@AssociatedVendorCode

AC

GivenName Vernon

MiddleName Bear

SurName Van

SecureFlight

@IsSubjectToSecureFlightRule

Y If RedressNumber is not set: 4DOCS/DB/@BirthDate/@GenderCode/SurName NameSuffix/GivenName/MiddleName 3DOCS/DB/@BirthDate/@GenderCode/SurName NameSuffix/GivenName/MiddleName @BirthDate

2012-07-05


@GenredCode

M Example: 4DOCS/DB/05JUL12/M/BEAR SR/VERNON/VAN 3DOCS/DB/05JUL12/M/BEAR SR/VERNON/VAN If RedressNumber is set: 4DOCS/DB/@BirthDate/@GenderCode/SurName NameSuffix/GivenName/MiddleName 3DOCS/DB/@BirthDate/@GenderCode/SurName NameSuffix/GivenName/MiddleName 4DOCO//R/@RedressNumber///US 3DOCO//R/@RedressNumber///US Example: 4DOCS/DB/05JUL12/M/BEAR SR/VERNON/VAN 3DOCS/DB/05JUL12/M/BEAR 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 4DOCS/DB/@BirthDate/@GenderCode/SurName NameSuffix/GivenName/MiddleName 3DOCS/DB/@BirthDate/@GenderCode/SurName NameSuffix/GivenName/MiddleName

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

PersonName/GivenName

Tom

PersonName/MiddleName

Jimmy

PersonName/SurName

Trammel

DocHolder/SurName

Bear

DocHolder/GivenName

Vernon

DocHolder/MiddleName

Van

DocHolder/NameSuffix

SR

@RedressNumber

123456

@KnownTravelerNumber

45678901