Admin Web Services Overview

The Universal Policy Admin Web Services allow any CBT to configure and retrieve policy data without using the Policy Admin Portal. This section details the Admin Web Services accessed through the Admin Web Services endpoints. The Admin Web Services Transactions section lists all transactions used, provides examples of request and response code, discusses any considerations for the request and responses, and lists the example files for that transaction that are in the file available on the Downloads page.

All examples were created using a set of Travelport test credentials (uAPI1380138875-c2b9265e) and target branch (P7025697) and were run against the Travelport pre-production system.

The pre-production Policy Admin Portal can be accessed at

https://policyadmin.pp.travelport.com/PolicyEngineAdminUI/login.action

WSDLs for the Admin Web Services are included in the zip file on the Downloads page.

See the Codes page for the codes used in configuring geographic areas and policy details such as vehicle sizes and categories.

Using Admin Web Services

The Admin Web Service requests are used to configure and retrieve policy data. Everything that can be done through the Universal Policy Admin Portal can also be done through the Admin Web Services. Admin Web Service requests are processed purely within the Universal Policy service; there is no equivalent in Universal API.

Policy groups, policies, and reason codes are associated with a uProfile account. The Universal API credentials used to make the Admin Web Service calls are associated with an agency, which in turn usually has a hierarchy of accounts and traveler groups underneath it. The account you are making the web service calls against must exist on the hierarchy associated with your credentials.

Note: If the supplied accountId is not part of the uProfile hierarchy associated with the credentials being used to make the request you will error messages similar to the following:

<ns2:AdditionalMessage iD="0" name="Policy Group" status="Failure">
            <ns2:Element iD="0" name="Policy Group" status="Failure">
                    <ns2:SubElement iD="0" name="Policy Group" status="Failure">Account invalid to LIST policy</ns2:SubElement>
            </ns2:Element>
</ns2:AdditionalMessage>

<ns4:AdditionalMessage iD="0" name="Policy" status="Failure">
     <ns4:Element iD="0" name="Policy" status="Failure">
          <ns4:SubElement iD="0" name="Policy" status="Failure">Account invalid to READ policy</ns4:SubElement>
     </ns4:Element>
</ns4:AdditionalMessage>

Similar messages are returned on create, update, and delete:

<ns4:SubElement iD="0" name="Policy" status="Failure">Account invalid to CREATE policy</ns4:SubElement>
<ns4:SubElement iD="0" name="Policy" status="Failure">Account invalid to UPDATE policy</ns4:SubElement>
<ns4:SubElement iD="0" name="Policy" status="Failure">Account invalid to DELETE policy</ns4:SubElement>

If you are not sure of the uProfile IDs associated with your accounts, see the uProfile sections UProfile Retrieve, UProfile Account Search, and UProfile Traveler Group Search.

When performing create and/or update requests for specific policy groups, policies, or reason codes, if the supplied name already exists in the Policy DB you will get errors similar to the following:

<ns2:AdditionalMessage iD="0" name="SandboxAdminPG9" status="Failure">
     <ns2:Element iD="0" name="Policy Group" status="Failure">
          <ns2:SubElement iD="104" name="Policy Group" status="Failure">PolicyGroup Name must be unique</ns2:SubElement>
     </ns2:Element>
</ns2:AdditionalMessage>

<ns4:AdditionalMessage iD="0" name="SBAirCreateTest2" status="Failure">
     <ns4:Element iD="0" name="Profile|Vendor Criteria" status="Failure">
         <ns4:SubElement iD="200" name="Profile|Vendor Criteria" status="Failure">The Policy already exists</ns4:SubElement>
     </ns4:Element>
</ns4:AdditionalMessage>

When performing create and update requests for policy groups, policies, or reason codes, if required elements are missing (e.g., the Profile element is missing or a policy name is not supplied), you will get errors similar to the following:

<ns4:AdditionalMessage iD="0" name="Policy" status="Failure">
           <ns4:Element iD="0" name="Policy" status="Failure">
               <ns4:SubElement iD="10" name="Policy" status="Failure">Unable to process request</ns4:SubElement>
            </ns4:Element>
</ns4:AdditionalMessage>

When performing read and/or delete requests for specific policy groups, policies, or reason codes, if the supplied Policy DB ID does not exist or is not associated with the accountId provided in the request, you will get errors similar to the following:

<ns2:AdditionalMessage iD="1100372" status="Failure">
       <ns2:Element iD="0" name="Policy Group" status="Failure">
          <ns2:SubElement iD="101" name="Policy Group" status="Failure">Policy groups were not found or does not exists for this request</ns2:SubElement>
       </ns2:Element>
</ns2:AdditionalMessage>

<ns4:AdditionalMessage iD="1100611" name="" status="Failure">
         <ns4:Element iD="0" name="Policy" status="Failure">
               <ns4:SubElement iD="201" name="Policy" status="Failure">Policy not found or do not exist for this request</ns4:SubElement>
         </ns4:Element>
</ns4:AdditionalMessage>

Notes about the Example Code in this Section

In all the examples in this section of the help, the request / response data has been truncated for readability but still shows all the relevant fields. The full sample request / response for each Admin Web Service function can be found in the zip file on the Downloads page.

The example data included in the document have had the soap envelope, header, and body tags removed. All requests start with the performCRUDRQ tag and all responses start with the performCRUDRS tag.

The namespaces used for a given request / response are noted in each section but are not shown in the soap envelope or performCRUDRS.

All Admin Web Service requests start with the following two tags:

performCRUDRQ – wrapper element for the whole request

BasePolicyRequestHeader – standard header element for all Admin Web Service requests
attribute: source – optional field for future enhancements – currently only accepts Web in this field
attribute: requestorId – accepts a userId that will be written to the Policy DB Audit Log
attribute: accountId – uProfile ID of the account (or agency) the request is being made against
attribute: requestCategory – type of request being made (List / Read / Create / Update / Delete)

All Admin Web Service responses start with the following two tags:

performCRUDRS – wrapper element for the whole response

BasePolicyResponseHeader – standard header element for all Admin Web Service responses
attribute: accountId – uProfile ID of the account (or agency) the request was made against
attribute: requestorId – reflection of requestorId passed in request

For all end dates (Travel / Booking / Check In / Pick Up) a value of 2099-12-31 indicates an open ended date range.

State codes are only supported for the following country codes US (United States), AU (Australia), CA (Canada).

For Air / Hotel / Vehicle / Reason Code / Email Communication policies:

The specified Policy (Reason Code) name must be unique within the specified account. The name can repeat in different accounts under the same agency but not within an account.
Policies (Reason Codes) are added at the account level; they cannot be added at the traveler group level. An account that has traveler groups underneath it can attach the policies to the traveler group through a policy group but cannot create policies specific to the traveler group.
Policies (Reason Codes) cannot be shared across accounts but can be shared by policy groups within the same account.
The specified Policy (Reason Code) name can contain only alphanumeric characters and spaces.
In the create and update responses, the SubElement often contains an action attribute:
Action:51=Add, 52=Delete, 53=Update