PilotFish Interface Exchange (PIE)

OpenTravel Validation Server automates the process of validation and certification of trading partners' messages to standardize initial and ongoing information exchange. For example, a company that is receiving the same messages from multiple trading partners (an OTA_AirAvailRQ) can "publish" their message formats and rules to enable their trading partners to test their message transactions before going "live".

The OpenTravel-specific features include:

Submission

A trading partner wishing to validate their messages may submit those messages in any of a variety of different ways. For instance, a developer wishing to test an OTA 2010B OTA_AirAvailRQ Air Availability Request transaction may alternatively:

• Send an email with "OpenTravel OTA_AirAvailRQ Transaction Test" in the subject line

• Post the XML to test.yourcompany.com/OTA2010B/OTA_AirAvailRQ

• Select "OpenTravel 2010B OTA_AirAvailRQ" from a drop-down on a web page

• FTP a file to the "OpenTravel/2010B/OTA_AirAvailRQ" directory on test.yourcompany.com

Validation

Validation models can be "layered", where a number of different models are applied to the same instance document. For example, the same document may be validated against:

• OpenTravel 2010B OTA_AirAvailRQ Schema Validation

• OpenTravel 2010B OTA_AirAvailRQ Certification Rules

• OpenTravel 2010B OTA_AirAvailRQ Your Company-Specific Implementation Rules

• OpenTravel 2010B OTA_AirAvailRQ Trading Partner-Specific Implementation Rules for another Trading Partner

OpenTravel can provide the "standard" validation rules. Your company and other partners in the Travel and Hospitality value chain can also submit validation requirements to be deployed to the transaction Validation Server. Using this feature, a trading partner can ensure that their messages are not only OpenTravel certifiable, but that they can be consumed by your company. This approach also adds the benefit of exposing areas where partners' interpretations are at odds with yours, or with the OTA standard itself.

Response

Validation results can be produced as XML, or as a human-readable HTML report. This report enumerates the rules executed against a particular OpenTravel Document, the success or failure of the aforementioned rules, and any relevant details in the case of a failure. The report is returned to the submitter through the appropriate transport protocol (email, HTTP, web page, FTP, etc).