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