Emulation

Universal API allows clients to request transactions for another Branch within their Profile Hierarchy, provided that they are provisioned for that Branch. Some clients may also be provisioned under a Control Branch, which does not have any access credentials to a provider's systems. The provider credentials are held under Work Area Branches, so that the user can indicate which work Branch's credentials need to be used for all shopping and booking transactions.

Typically, Work Areas Branches contain all provider credentials for a client. Agents and Administrators are not directly provisioned with provider credentials. Therefore, to shop and book, Agents and administrators must emulate into a work area to gain provider credentials. When an Agent assumes an identity within a Branch, defined by the Branch Code, they gain access to the agency's host identifiers, bookings, settings, etc. In emulation mode, most services act as if the Agent is part of the given Branch. Based on their provisioned profile structure, the majority of clients will use emulation for their transactions with Universal API.  

Note: Branch Codes are the Universal API equivalent to the level of identifiers used in provider systems to identify targets for emulation, e.g., PCC in Galileo/Apollo and SID in Worldspan.

Emulation is also commonly used by:

• Travelport Support to troubleshoot a problem by acting as a travel provider.

• Travel providers, such as large agencies, that use multiple identifiers (Branch Codes) to organize their business to allow their agents to switch context.

• Service Bureaus, to service the traveler within the agency where they are normally booked.  

Types of Emulation

Emulation allows a Universal API client to assume another identity and function as that agency, travel provider, or agency subdivision. There are two types of emulation:

1. Emulation in Universal API using a TargetBranch. TargetBranch emulation is supported on any service, depending on your provisioning.

2. Emulation on the provider through Universal API using OverridePCC. OverridePCC emulation is supported on most transactions, depending on your provisioning.

   It is not supported by:

   • Air Fare Rules (1P only)
   • Currency Conversion (Util.xsd)
   • EMD Issuance
   • Security services (role management and creation)
   • ACH
   • RCS

Note::Emulation in this usage is distinct from native Terminal Emulation data used by Galileo and other host systems.

How to Emulate

Both emulation in Target branch and Override PCC can be used in a single request. The ability to emulate using Target Branch depends on Universal API provisioning. The ability to use Override PCC emulation depends on the provider's security relationship between the Target Branch’s default PCC and the Override PCC.

TargetBranch Emulation

TargetBranch emulation is available on the Galileo, Apollo, ACH, and Worldspan providers.

Emulation is accomplished by adding a Target Branch to the root node of the request that will be submitted under emulation. TargetBranch is an attribute of BaseReq in the Common service.

For example, the following Low Fare Search request emulates the 'XXBRCH' Branch, which the requestor is provisioned to emulate. The transaction response will be based on the profile and settings of 'XXBRCH' rather than the requestor's Branch profile settings.

<air:LowFareSearchReq AuthorizedBy? ="TEST" TargetBranch="XXBRCH" xmlns:air="http://www.travelport.com/schema/air_v36_0" xmlns:com="http://www.travelport.com/schema/common_v36_0">

....

</air:LowFareSearchReq>

OverridePCC Emulation

OverridePCC emulation is available on Galileo, Apollo, and Worldspan. It is not supported for other providers.

To emulate, the OverridePCC element in the base request or in the Header must be sent with:

• @Provider – 1P, 1G, or 1V.
• @PseudoCityCode – the PCC (SID) whom the user will emulate.

Both @PseudoCity and @Provider must be included in the request or an error messages is returned. Only users with an appropriate assigned role can use the element.

An emulated request is successful if appropriate Bridge Branch relationships are in place to allow emulation between defined Pseudo City Codes. If there is no provisioned bridge relationship between the Pseudo City Codes, the emulated request returns an error message. Note that Bridge Branch security is defined in the provider system and is an agreement between PCCs that allows emulation.

Note: Currently, Universal API does not support OverridePCC Emulation in CurrencyConversionReq for any GDS.

Emulation Hierarchy and Processing

Universal API considers the work area Branch to be an Agent's parent when the Agent is emulating. Although Agents are children of Control Branches, profile retrieve for logging on, and most agent transactions needs to consider the Work Area Branch as the parent.

The process of emulating into a new work Branch recomputes the Agents's profile hierarchy. This change can result in a completely different hierarchy, with more or fewer levels, depending on the location of the Branch that the Agent is emulating.

As a result of re-calculating the hierarchy, the Agent (subject to the Roles assigned to that Agent) has access to all of the elements that are owned or controlled by the various parties in the hierarchy, including, but not limited to:

• Universal Records

• Saved Trips

• Profiles

• Contents

• Templates

• Tags and Actions

• Traveler Hierarchy

• Reason Codes

• Provisioned Access and Privileges

Permissions for Emulating

Emulation is treated as a resource, and can be granted at a Bridge Branch, Agency, Branch, System, or Managed Entity level. Emulation rights can be granted at one of five levels, giving access to a different subset of Branches on the system. The levels map to the Agency hierarchy used in Profiles. Resources rights are granted through Roles, which are a collection of resources.

The level determines which Branch is treated as a valid target for emulation:

• For Bridge Branch, only Branches to which this agent is bridged can be emulated.

• For Agency, all Branches that share the same agency as this agent can be emulated.

• For System, all Branches available are valid targets.

• For Managed Entity, all Branches that are managed by the organization that this agent represents can be emulated.

• For Branch-level access, the only valid Target Branch is the agent's default Branch.

Emulation Process

Authorization before emulation consists of two steps:

• Primary Authorization validates that the agent has access rights to the desired function

• Secondary Authorization validates that the target specified in the request falls within the scope defined by the Access Level right specified for the resource in the role assigned to the agent.

Emulation processing, which takes place primarily between primary and secondary authorizations:

• Validates that the Agent has the right to emulate, and that the target is valid.

• Overrides the "Identity Context" of the agent, replacing the parent Branch and hierarchy with the emulated Branch and hierarchy.

The services now process this request as if the Agent was created as a child of the Target Branch, by getting the hierarchy data from the Identity Context.