|
Enterprise Access for Customers on OPERA Cloud Identity
Management
|
OPERA Cloud Services users
with multiple chain level access can now select the chain they want
to administer while logging in to the Oracle Hospitality Integration
Platform customer portal. This also allows the user to switch between
chains in the customer portal without the need to log in again. For
more information, see Signing In to the Oracle Hospitality
Developer Portal in the Oracle Hospitality Integration Platform
User Guide.
|
|
Migration Feature for Seamless Transition from SSD Environments
to OPERA Cloud Identity Management Environments
|
Provides a seamless transition
for Oracle Hospitality Integration Platform customers by migrating
their existing partner connections, applications, streaming configurations,
API access, and analytics in the developer portal when migrating from
SSD to OCIM. This also provides a pre-migration capability that enables
customers and partners to prepare for migration by allowing them to
regenerate client credentials in advance of the actual migration date,
thereby reducing the time needed to switch to a client credentials-based
authentication. For more information, see Migrating to Client Credentials-Based
Authentication Scheme in the Oracle Hospitality Integration
Platform User Guide.
|
|
OPERA Cloud Services Property APIs
|
The OPERA Cloud Services
property APIs have been updated to OPERA Cloud Services version 23.5.
New and Updated API Operations
New
operations:
-
stayRecords Asynchronous Operation —
A new asynchronous operation called stayRecords is available in a
new CRM Asynchronous API. This allows you to import stay records into
OPERA Cloud, for example when moving from another Property Management
System.
-
blockAllocationProcess Asynchronous Operation — A new asynchronous operation called BlockAllocationProcess is
available in the Block Asynchronous API. This allows you to update
a block's room grid, including inventory and rates. Using this operation
ensures that updates for large blocks with multiple room types have
time to process and update OPERA Cloud efficiently.
-
blockChangesByTimeDate — A blockChangesByTimeDate
operation is added to the Block API. You can search for blocks created,
updated, and/or deleted within a maximum 3-day date range. The response
includes block id, block code, array of external system and external
system id, block start date, block end date, room status, catering
status (if applicable), and last change date and time. If a block
was created and deleted in the time period of your search, the query
does not return this information. If a block is created and updated,
the create information is returned. If a block is updated only, it
returns the update. If a block is updated and deleted, it returns
the delete.
-
get/put/removeCutoffSchedule — Three
new operations are added to the Block (BLK) API: getCutoffScheduleDetails,
putCutoffScheduleCode, and removeCutoffScheduleCode. Use these operations
to fetch details about a blocks cutoff schedule, or to update the
cutoff Schedule, or delete the cutoff Schedule.
-
vacantRoomStatus — The following operations
are available in the Room Configuration API:
-
getVacantRoomStatus — You can use this
to fetch vacant room status configuration.
-
postVacantRoomStatus — You can use this
to create new vacant room status configuration. This can be for specific
room types for a defined date range, number of days, or both date
range and number of days together.
-
putVacantRoomStatus — You can use this
to update an existing vacant rooms status configuration.
-
deleteVacantRoomStatus — You can use
this to delete existing vacant room status configuration.
Updated operations:
-
getBlockAllocationSummary — When calling
the getBlockAllocationSummary operation in the Block Asyncronous API,
with request parameters startLastModifiedDate and endLastModifiedDate,
block change log entries are also considered along with the block
header update date. This ensures that all block changes are considered
when calling this operation.
-
getBlocks and putBlocks — The getblocks
and putblocks operations in Block (BLK) API are updated with an autoloadForecastGrid
element.
-
getProfileMembershipStatistics and getMembershipIssueAwardsList — The getProfileMembershipStatistics operation in the Customer Relationship
Management API is updated with new query parameters (transactionDate,
hotelId, confirmationNumber, limit, offset) and response body parameters
(totalPages, offset, limit, hasMore, totalResults, count). This allows
you to search membership transactions based on the transactionDate,
hotelId, and confirmationNumber, along with paginations.
-
getRoomKeys — The getRoomKeys operation
in the Front Office API now includes a query parameter called includeInactiveRoomKeys.
Setting this to True allows any inactive room key details to be included
in the response.
-
getInventoryItems and postInventoryItems — The getInventoryItems and postInventoryItems operations in the
Inventory API include a TracesPerDay element. Setting TracesPerDay
to true creates the traces for all inventory days in the reservation.
-
Get, Post, Put, and deleteActivityBookings — In the Leisure Management API (LMS), the following operations
are now available for use:
-
getActivityBookings
-
postActivityBooking
-
putActivityBooking
-
deleteActivityBooking
-
getHotels — The getHotels operation
in the Price Availability Rate (PAR) API is updated with a websiteAddress
element in the response. This new element is within the hotelSummaryInfoType
definition.
-
getRoomsSummary — The getRoomsSummary
operation in the Room Configuration API now includes Room Status,
Component Room Info, and Component Suite Info in the response.
-
copyRatePlans — The copyRatePlans operation
in the Rate API includes an approvalStatus element that allows rate
code approval should the property have the Rate Code Approval OPERA
Cloud Control activated.
-
getHotelReservations — The getHotelReservations
operation in the Reservation API allows you to research by the externalReferenceLegId
query parameter. This is useful when searching for itinerary reservations
as they have the same confirmation number (external reference number)
but different leg numbers.
-
Reservation — The postReservationLinksByChain,
postReservationLinks, and postReservationLinksByExtId operations in
the Reservations API provide a new, optional request attribute for
hotelId to define the property where a given reservationIdList belongs.
A new optional query parameter hotelId is added to the getReservationIndicators
operation to define the property where a given reservationId belongs.
The hotelid is needed when the reservationId is no longer unique across
properties in a multi-tenant environment.
|