The objective is to migrate the responsibilities of the EventShort endpoint to the Event endpoint, ensuring that all services depend exclusively on the latter. To enable this transition, it was necessary to align and adapt the EventShort APIs to make them fully compatible with the Event APIs.

EventShort endpoint :

https://tourism.api.opendatahub.com/v1/EventShort/

Event endpoint :

https://tourism.api.opendatahub.com/v1/Event/

In the EventShort endpoint, events can contain multiple values for the RoomBooked field. This allows a single event to take place in different rooms on different dates. The web component would retrieve an event from the EventShort endpoint and, for each RoomBooked value, create a record which was then displayed. This resulted in multiple records being displayed for the same event. To avoid this, HTTP requests were made to the EventShort/GetbyRoomBooked endpoint, which created the various records separately so that, with the correct query parameters, it returned only one record, which was then displayed correctly.

In the Event endpoint we have the same situation. Intead of multiple RoomBooked entries, there are multiple EventDate. To obtain only the required record, the query parameter denormalize was added. When the query parameter denormalize=true is used, an event with multiple EventDates is taken, and one Event is created for each EventDate record. The data model remains the same, except that only one record is present in EventDates. The web component uses only the record filtered by the query parameters. The concept applied through denormalize can be extended to any array-based structure, thus offering greater portability.

The Event and EventShort entities have different data structures and use different field names. In order to reuse the existing structure, it was necessary to update the code to accommodate the new field names. Most fields are now mapped into nested structures.

Some fields are no longer stored as simple values, but as arrays:

• EventDate
• VenueRoomDetailsIds

Note: The EventShortTypes Endpoint is also deprecated so all Tags which were located in TechnologyFields and CustomTagging all now shifted to TagIds (where only the Ids are saved) and also to Tags (where more detailed info on the Tag is available). The Tag itself contains more detailed Infos about the added Tags.

The complete Tag Information is available in the Tags Endpoint
v1/Tag?types=customtagging Custom Tags
v1/Tag?types=technologyfields Technology Fields
v1/Tag?types=eventlocation EventLocation

The Event Endpoint can be filtered by TagIds:

By using the tagfilter
v1/Event?tagfilter=digital
By default when passing multiple tags, they are combined with a OR v1/Event?tagfilter=digital,techtransfer is equal to v1/Event?tagfilter=or(digital,techtransfer) And AND is done this way v1/Event?tagfilter=and(digital,techtransfer)

By using the rawfilter v1/Event?rawfilter=in(TagIds.[],'digital')
OR
v1/Event?rawfilter=in(Tags.[].Id,'digital')
v1/Event?rawfilter=in(Tags.[].Name,'Digital')
AND/OR
v1/Event?rawfilter=or(in(TagIds.[],'digital'),in(TagIds.[],'techtransfer'))
v1/Event?rawfilter=and(in(TagIds.[],'digital'),in(TagIds.[],'techtransfer'))

In the EventShort endpoint, specifically in EventShort/GetbyRoomBooked, rooms were stored in the fields SpaceDesc and SpaceDescList. In the Event endpoint, rooms were stored only in EventData.VenueRoomDetailsIds. In the Event endpoint, the room ID is stored as an alphanumeric string. By sending an HTTP request to the Venues collector, it is possible to retrieve the room name corresponding to that ID.

The Event endpoint also introduces different query parameters. The parameters that have changed are:

To retrieve the current events, a request is sent to the endpoint :

"https://tourism.api.opendatahub.com/v1/Event?"

To obtain the room name of an event, a request is sent to the endpoint:

"https://tourism.api.opendatahub.com/v1/Venue?"

As the room is stored as an alphanumeric id, this call ensures that the actual room name can be retrieved dynamically.

There was a function called fetchRoomMapping that allowed linking a room name to a URL displaying the room on a map of the NOI building. This functionality also depended on the EventShort endpoint. For the Event endpoint, the process was more complex. It was necessary to retrieve the venues from another API and create a similar structure to the previous one. To achieve this, a request is sent to the following endpoint:

"https://tourism.api.opendatahub.com/v1/Venue?idlist=urn:venue:noi:6b3f0a14-3c5b-5d09-81f3-3ebe5b7885ea&denormalize=true&fields=RoomDetails.[*].Shortname,RoomDetails.[*].Mapping.maps.roommapping"