Actions

Actions provide client applications with a means of “mapping” profile data to target services. Actions store rules that instruct client applications how to perform that mapping.

A target service could be any function that takes profile data as input in order to perform some function. Some examples of target services could be pages or portions of Universal Desktop, like the air or hotel shopping pages, the activity panel, or the booking page. Or a target service could be a web service of Universal API. In the near future, the system could support actions for mapping to third-party web services.™™ 

Thus some likely actions could be:

• Move to Trip Record

• Move to Air Shop

• Move to Activity Panel

• Move to Create Air Reservation Request

Each action will be “triggered” by some event in the client application that applies the action in order to map data from the profile to a target. When an action is triggered, the data is mapped to endpoints in the target service. Endpoints could be, for example, an attribute on a web service request, or a field/control on a GUI page (e.g., an action could trigger a traveler's HomeAirport value to be populated in the Origin field (endpoint) on a flight search).
Note: When more than one data instance applies to a particular trigger, the client/agent must choose which data instance should be used.

Agencies will indirectly define how to map profile data to target services by assigning one or more actions and endpoints to template fields. Data within those fields will then be governed by the associated action/endpoint.

Action Messaging

There are two services available for actions:

• ProfileRetrieveAction is used get details of a specific action based on the action ID.
  Note: At this time, no modifiers/filters will be provided (for example, the request cannot retrieve a list of actions specific to a consuming service).

• ProfileSearchAction is used to list a summary of all actions available in the system.

Common Functions and Rules

• Actions and endpoints will be assigned to profile data indirectly, via template fields.

• Any user that is authorized to manage a given template will be authorized to manage the action/endpoint assignments on it (no separate authorization needed).

• A user must be authorized to retrieve an action and/or its endpoints.

Actions and Templates

• Actions are applied to template fields, both fixed fields and custom fields. Actions are not applied to template field groups (fixed or custom).

• Each template field can have 0 to many actions.

• If a template field is assigned an action, then it must be assigned 1 to many endpoints per action.

• Each template could have more than one field with the same action-endpoint association.

• System templates will have the default action(s)/endpoint(s) that Travelport has assigned to each template field.

• Agencies can modify default templates by adding or removing actions and endpoints from fields (fixed or custom).

• Template fields and endpoints must have compatible data types.  

• These conditions are permitted (barring the condition above) and will not result in a warning or error from the API:

• Mapping more than one template field to an endpoint that has a 0..* or 1:* cardinality.

• Mapping a given template field to more than one endpoint of a target service.

• Mapping a single template field that, on the template, has a cardinality of 1..* to an endpoint that has a 1:* cardinality.