# Overview ### Technology overview The HCD XML Update Interface is a JAX-Document Literal based web service, utilizing SOAP over HTTP/HTTPS with 2005B OTA XML as the message payload. The WSDL can be found here: [https://webservices-uatprod.rategain.com/OTAHotelDescriptiveContentNotif/web\_services?WSDL](https://webservices-uatprod.dhisco.com/OTAHotelDescriptiveContentNotif/web_services?WSDL) Clients can use this WSDL to generate client-side stub code that will be incorporated into their application and calls against this code will appear to be made locally. Refer to Appendix C for additional information on client application generation using WSDL tools. ### Open travel alliance The Open Travel Alliance (OTA) is a standards body made up of various travel-related industry leaders. Their purpose is to develop and maintain a set of XML message structures that travel companies can use to communicate their business data. RateGain has adopted the 2005B OTA’s message structure and codes for the HCD XML Update Interface. ### SOAP/XML/HTTP SOAP over HTTP(S) with XML as the payload has been adopted as the standard for web services communication because of its platform and language independence. RateGain’ HCD XML Update Interface follows this same standard. For secured (HTTPS) access to resources, clients must include the appropriate root level CA certificate. RateGain uses Comodo as its certificate authority, and the root level CA can be found here: [https://support.comodo.com/index.php?\_m=downloads&\_a=viewdownload\&downloaditemid=11\&nav=0,1](https://support.comodo.com/index.php?_m=downloads\&_a=viewdownload\&downloaditemid=11\&nav=0%2C1) Also, clients must import RateGain’s public certificate as well. This can be obtained by: · Navigating to the WSDL in Internet Explorer · Double-click on the lock icon in the bottom right corner of the browser window · Click the “Details” tab · Click the “Copy to File…” button · Save the file as the appropriate type for the keystore into which the certificate will be imported. Once the root level CA certificate and public certificates are imported into a keystore, this keystore can be utilized by tools such “wscompile” to generate client stubs for resources protected by SSL. The public certificate is hostname specific, so for each environment (UAT/Production), a new public certificate is needed for the specific hostname. ### ebXML ebXML (Electronic Business using eXtensible Markup Language) is a modular suite of specifications that enable enterprises of any size to conduct business over the Internet. It creates standard methods to exchange business messages and communicate data in common terms. RateGain makes use of the ebXML Header element in the SOAP Header of transactions to the HCD XML Update Interface. ### System overview The HCD XML Update Interface will allow a user to submit XML transactions to the HCD Update web service for maintaining property information. Some of the types of information that can be maintained are: · Basic Property Information · Image links · Amenity Information · Bookable status The following diagram illustrates the boundaries of all systems involved in this interface. ### Transaction list The following table provides a brief summary of each of the OTA messages that may be submitted to the HCD XML Update Interface. Additional information about these messages is located in later sections of this document.


Message Type	Description
OTA_HotelDescriptiveContentNotifRQ	2005B OTA message used to publicize detailed descriptive information about a hotel property by standardized data categories.

### Typical transaction flow A typical transaction flow to the HCD XML Update Interface consists of a request transaction, verification process, database update, and success or failure response. ### Batch processing RateGain allows the XML update messages to be sent as single transactions, or the messages can be collected and sent as a batch. Customers who wish to utilize a batch method of accessing the HCD XML Update Interface will FTP files to RateGain for processing. RateGain will process the batch file by separating the messages into individual transactions, validating its structure and content, and applying the update. Each property record in a batch file is autonomous, meaning that if one record in the batch is invalid, processing will still be attempted on the remaining records in the batch. Each batch can contain a variety of data combinations. The batch can be as structured as: Only “Add” messages for a brand, or Only “Deletes” for a chain, or “Adds and Updates” for all brands, or A complete refresh of properties for the chain This is left up to the supplier to determine the data combinations. ### Batch file format An inbound batch file consists of one OTA XML messages, wrapped with a SOAP envelope and then the entire file wrapped with a batch header and trailer tag. The SOAP header contains the action for the XML message. Each OTA XML message contains a specific language code that identifies the language of the data within the message. Therefore, each action per language must be sent in a separate SOAP / XML message. The following example shows separation of action, language, and the use of the Header and Trailer within a single batch. **Inbound Batch File Example** ``` Customer RateGain ODDUpdateInterface SIHtoODD1 ODDUpdateInterface UPSERT IDTPAPA 2024-10-15T13:01:31 RateGain assigned interface email address RateGain assigned password . . . ``` **Outbound Batch File Examples** ```

Unable to authenticate and authorize user: username@supplier.com. Error: Authentication failed for user: username@supplier.com

The proximity value for HAC.143 was changed to '2' to ensure content integrity.

City code {STT} will be ignored because it can only be provided for Attractions with a category of City

``` ### File naming convention Since all inbound batch files will be placed into a supplier specific directory. The supplier must ensure that the inbound batch files are uniquely named to prevent lost or overwriting of files. To help facilitate the unique naming of the files the inbound batch files must support the following naming standard. · The filename must include a datestamp (20241015), followed by a sequence number of three digits (\_000) and ending with ‘.xml’ Example: 20241015\_001.xml Note: The .xml is case sensitive and must be provided to RateGain in lower case only. RateGain will process the batch files by the datestamp and then sequence number if more than one file is found with the same datestamp. For those clients needing to further identify their files, RateGain will allow the file to begin with a 10 character identifier. This identifier can be used by the client to help identify what the file contains. RateGain determination on processing will not include this extra identifier. Therefore the sequence number must be unique per datestamp. The following are examples: · XXfile\_20241015\_001.xml (XX can represent Chain or Brand code) · XXXXXXXXXX\_20241015\_002.xml (X represent the PID, Chain name or Brand name as long as under 10 bytes) · AllBrands\_20241015\_003.xml · Vendor\_20241015\_004.xml A single response file will be created to contain the processing errors and/or the success responses. The outbound batch file will support the following naming standard. · The filename will mimic the inbound file but ending with ‘.rpt'. Example: 20241015\_001.rpt For those clients who provide the additional identifier, the file name will be retained and delivered back with the appended '.rpt'. ### Multi-lingual capabilities The HCD allows for content to be stored in both single byte languages and multi byte languages. A property must first exist in English before any additional languages can be provided. All multi-lingual content can be sent in either the batch or transactional format to the HCD XML Update Interface. Once a property has been established in English, additional languages can be added to HCD by submitting an Update or Upsert message for the next language to be added. The minimum required data to add an additional language is as follows:


Element	Attribute
OTA_HotelDescriptiveConten tNotiflRQ
	Version
	PrimaryLangID
HotelDescriptiveContents


Element	Attribute
HotelDescriptiveContent
	BrandCode
	HotelCode
	HotelName
ContactInfos
ContactInfo
Addresses
Address
	UseType
AddressLine
Cityname
StateProv
	StateCode
Countryname
	Code

All multi-lingual fields are identified under section 4.2. All multi-lingual fields are optional with the exception of the element/attributes identified above. When the maximum size is indicated in the Usage column in section 4.2, all languages must adhere to this size limit. The size is provided in both characters and bytes. The number of characters will not vary by language. However, multi-byte languages have been taken into account and the delivering system must ensure the maximum number of bytes is not exceeded when sending multi-byte characters within the text. ### Associating media to textual content Media is made up of all different content types like still images, virtual tours, steaming video and more. RateGain allows the association of Media to the properties textual content. Media can be tied to descriptive text found within the HCD XML Update Interface message. The following data types (represented below by the OTA message element IDs) can have different media types specifically linked to them: · HotelInfo (for property images such as exterior, lobby, etc.) · Service/@Code (for hotel amenities such as pool) · MeetingRoom · GuestRoom · Restaurant · Attraction · Recreation Media is linked to data types via a shared code called a ContentID, which is sent using the attribute ContentID within the Description element. If a data type has media to be associated, a ContentID should be created for that data type. It is up to the supplier to create the ContentID they want to use (must be unique per property). That same ContentID then needs to be referenced when providing the media types and media metadata in order to create the linkage. For example, the property may have two restaurants, each with one or more photos. Each restaurant would then be assigned a unique ContentID. All media for the first restaurant would reference the ContentID assigned to that first restaurant and so on.
It is also possible to associate a single media type to more than one ContentID. For example, a property might have 2 guest rooms that are basically the same with the exception of the view. In this case, both rooms could utilize the same type like photo. Each guest room would have a unique ContentID assigned and the shared photo would then reference both ContentIDs. If a media type is submitted and does not have a ContentID assigned, it will only be linked to the property and not tied to any specific property attribute, e.g. room, restaurant or guest room. Absence of a linkage between a media type and the textual content in HCD will not prohibit return or display of that media type. *NOTE: Only still images may be provided by the supplier using this interface specification. All other media types must be delivered by a certified media provider.* ### Managing images RateGain allows the submission of image links via the MultimediaObjects elements and attributes within the XML message. RateGain also receives image links and meta data from these Digital Asset Managers: ICE Portal and Leonardo. ### Content manager Suppliers have the option to VIEW their Images via the Content Manager GUI (CMGUI). ### HCD XML update interface Suppliers can provide the Image Meta data within the MultimediaObjects element of the XML Update Interface message along with the other descriptive content. The MultimediaObjects element includes: image URL, image caption text, image category (OTA PIC codes), content ID, and display order. ### GDS content updates Suppliers who subscribe to RateGain’s ContentConnect service use HCD as a single point of entry for distributing hotel descriptive content to both ADS (online) and GDS channels. No extra processing is needed by the supplier. However, the rules associated to the specific GDS fields must be followed in order to have a successful update to the GDSs. Warnings will be returned when elements or attributes required for GDS updating are not provided. The updates will still be applied to HCD, but the data will not be published to the GDSs until the missing fields are provided. For those suppliers who do not subscribe to ContentConnect, the specific GDS business rules can be ignored. Any GDS- specific information will be ignored if supplied for a property that does not subscribe to GDS content updating via HCD. ### Office of Foreign Assets Control (OFAC) RateGain will enforce U.S. Sanctions as required by the U.S. Office of Foreign Assets Control (OFAC). OFAC prohibits U.S. companies and citizens from doing business with certain sanctioned countries (such as Cuba, Iran, North Korea and Syria), organizations, and individuals deemed to be acting on behalf of, or located in, certain sanctioned countries, terrorism sponsoring organizations and individuals, and international narcotics traffickers. \ As a result, RateGain is prohibited from storing (or allowing any of its customers to store) information in any of its systems if doing so would violate any OFAC sanction. By using any RateGain system, the customer acknowledges and agrees that RateGain may delete any customer information in its systems without prior notice if the storage of such customer information would violate any OFAC sanction. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://developer.rategain.com/content/content-update/overview.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.