4.7 ActivityData¶
If the action parameter is OTA_HotelPostEventNotif:EventReports the client intends to send information about hotel internal activities made available to their guests.
4.7.1 Exchange of hotel activities¶
The request parameter contains an OTA_HotelPostEventNotifRQ document.
Here is the global structure of the document:
|
|
Each document contains one EventReports element which MUST contain at least one and at most 99 EventReport elements. Each EventReport element contains two elements EventSites and GeneralEventInfo, both mandatory.
EventSites requires exactly one EventSite element.
For the attributes HotelCode and HotelName, inside the EventSite element, the rules are the same as for room availability notifications (section 4.1.1). While it is possible to send more than one EventReport element, AlpineBits® requires that all EventReport elements refer to the same hotel. Hence exactly one hotel can be dealt with in a single request.
An AlpineBits® server must return an error if it receives a request referring to more than one hotel.
The mandatory Event_ID element has no content and three attributes, all mandatory:
-
Type must have the value
18. -
ID an identifier of the activity as set by the provider.
-
ID_Context the context referring to the ID. Usually it’s the name of the provider for the activity.
The pair ID,ID_Context is the unique identifier of the activity: it MUST appear only once in a single message and MUST be used as reference for further synchronization messages.
An AlpineBits® server must return an error if the same activity (i.e. multiple conflicting Event_ID elements) are sent in the same message.
The GeneralEventInfo holds the information about the activity. It contains the following attributes:
-
Type.
-
URL. Optional, a URL where the activity can be accessed in the providing system.
-
Acronym. Optional, an acronym of the activity. If specified, it must be comprehensible for humans.
Further, the GeneralEventInfo element contains the following 4 elements:
-
EventContacts. Optional. It must contain at least one EventContact sub-element.
-
AttendeeInfo. Optional. See below for explanation.
-
Dates. Optional. It must contain at least one and at most 99 Date sub-elements.
-
Comments. Mandatory. See below for explanation.
An example of the complete structure of the EventContact element is the following:
|
|
Each EventContact element describes one contact that pertains to the activity. Its optional attribute Role, due the fact that of not being localized, must be agreed upon by the AlpineBits® partners and is used to transmit the Role of this person with regard to this activity (The same person might have different roles in different activities, for instance the "Guide" in an Hiking activity and "Instructor" in a skiing activity).
Further, the EventContact element contains the following elements:
-
The optional PersonName element describes the referer person for the activity, surname and first name are sent using the mandatory Surname element and the optional GivenName element respectively.
-
The optional URL element with the mandatory Type attribute set to
Image, contains a link to a picture of the contact. -
The optional EmployeeInfo element contains in the mandatory EmployeeId is used to assign a unique Identifier to the contact person. This could be useful for further synchronization. (Be aware that this attribute is limited to a maximum length of 16 character)
The optional element AttendeeInfo contains the TotalQuantity attribute that is used to specify the maximum number of guests that can participate to the activity. The attribute PreRegisteredQuantity contains the number of slots that are already busy, hence if the two attributes hold the same value the activity can be considered "sold out". Please note that AlpineBits® currently does not specify a way to book or reserve a slot for activities.
The Dates element contains at least one and up to 99 Date elements, which are the dates when the activity is scheduled. The main structure of the Date element is the following:
|
|
The attributes Start and End define the beginning and the end of the activity, both may also contain time information if available. The Start attribute is mandatory, the End attribute is optional and its absence means that the event is open-ended. The optional EndDateWindow element contains the mandatory LatestDate attribute: the deadline by which guests SHOULD subscribe to the activity.
The optional LocationCategories element is used to describe the meeting place / location where the activity is planned to happen. The optional Location element allows the exchange of a unique identifier for the meeting place through its mandatory AreaID attribute. At least one Category element must be specified and contain the mandatory Language attribute set to a two-letter lowercase language abbreviation according to ISO 639-1. At most one Category element is allowed for each Language. Each Category element is used to transmit the localized name of the location.
The Comment section is the part where descriptive elements are defined.
Here is a sample:
|
|
Inside the Comments element there are up to 4 Comment elements.
The Comment element with the attribute Name set to Title is mandatory and it contains at least one Text element with the mandatory attribute Language set to a two-letter lowercase language abbreviation according to ISO 639-1. Multiple Text elements can be specified, but each must specify a different Language: these are the title of the activity in the different languages.
The Comment element with the attribute Name equal to Category is mandatory and it contains at least one Text element with the optional attribute Language set to a two-letter lowercase language abbreviation according to ISO 639-1. Multiple Text elements can be specified, but each must specify a different Language: These are the categories of the activity in the different languages. At most one Text element can be specified without the Language attribute: this holds a unique identifier for the category, not meant for displaying to humans.
The Comment element with Name equal to Gallery is optional and it contains at least one Image element without attributes. Each Image element contains a valid url to an image that can be used to display the activity.
The Comment element with Name equal to Description is optional and it contains at least one Text element with the mandatory attribute Language set to a two-letter lowercase language abbreviation according to ISO 639-1. Multiple Text elements can be specified, but each must specify a different Language: These are the descriptions of the activity in the different languages.
4.7.2 ActivityData: Synchronization and deletion¶
Upon receiving an activity (identified by the given Event_ID) an AlpineBits® server MUST replace the previous activity stored with the same identificative in its entirety. This means that in case of rescheduling or cancellation of specific dates of an activity the whole activity must be sent again with up to date information.
In case of the complete cancellation of an activity, with all its dates, a client can notify to the server a deletion sending one EventReport element formed according to the following rules:
-
The EventSites element MUST contain the same data of the original message for new activity.
-
the GeneralEventInfo element MUST be empty (self closed tag).
Here is an example:
|
|
4.7.3. Server response¶
The server will send a response indicating the outcome of the request. The response is a OTA_HotelPostEventNotifRS document. Any of the four possible AlpineBits® server response outcomes (success, advisory, warning or error) are allowed. See Appendix A for details.
Here is an example:
|
|