Hospitality integrations for property management and point-of-sale

如何在開發期間存取 OPERA Cloud 執行個體？

1. 參加 Cloud Build 課程的 OPN 成員將有資格購買自己的 OPERA Cloud 執行個體，包括 UI 和介面 API 存取權。此選項即將發布，因此請在接下來的幾週留意相關資訊。
2. 整合合作夥伴可以從我們的專業服務團隊購買諮詢時間，然後使用該時間訪問諮詢實驗室。這僅用於 API 訪問，但與您合作的顧問可以協助滿足 UI 層級的需求。
3. Oracle Hospitality Integration Platform (OHIP) 將提供共用封閉測試環境。這將用於新 REST API 的 API 存取，不包括對 UI 或 OXI、OWS 等的存取。共用封閉測試環境的存取權並非獨佔，並將根據使用量收費，即您只需為所使用的呼叫付費。
4. 最後的選擇是與擁有 OPERA Cloud 非生產實例的酒店或其他合作夥伴進行交易。

如果我選擇不更新我的 Oracle 驗證將會怎樣？

現有安裝將不會停止運作。我們不會因此而關閉酒店。但是，如果您不續訂 OPN 會員資格，您的解決方案將不會列在 Oracle Cloud Marketplace 或已發布的介面清單上。這表示，如果酒店向我們詢問您的產品整合的事宜，銷售人員則會說：「我們沒有介面」。沒有人想要那樣。我們當然不希望這樣，客戶也不希望這樣，因此請確保您的 OPN 會員資格是最新的。如果您有任何問題，歡迎隨時與我們聯絡。您可以線上查看會員資格狀態，也可以透過 oracle.com/partnernetwork 聯絡 OPN 團隊。

我仍在努力解決驗證/認證方面的挑戰。具體來說，如果酒店客戶在 OWS 上安裝了未經認證的介面，一旦出現問題，他們將失去所有支援。是否有任何官方指南可供酒店分享，這樣就不必回想 Mike 所述的內容？

我相信我們未針對這個問題發布任何官方指南。多年來，對於未經驗證的介面支援什麼以及不支援什麼，一直存在一些混淆。對於這方面，如果它未經驗證，就完全不受支持，但這並不完全正確。當然，如果 Oracle 將軟體銷售給一家酒店，我們將為我們的軟體提供支援，而不是在安裝好軟體後就撒手不管。對於經過驗證的介面，Oracle 和合作夥伴保證我們已經對其進行了測試，並且我們知道其能夠在這種情況下運作，這就是我們進行測試的原因，因爲我們知道這個組態將在哪些參數下運作，並保證其能夠運作。我們將檢查 OPERA 組態是否與此特定介面的組態相符。這是技術支援文件的一部份，我們將會排除無法正常運作的内容。

對於未經驗證的介面，Oracle 僅支援其 Oracle 端。如果我們安裝了 OWS，並且酒店與合作夥伴建立了專用的自訂連線，那麼在我們看來，這是一個未經驗證的介面。這是客戶導向的組態，與 Oracle 幾乎沒有關係。我們一般都支援 OWS，所以如果酒店打電話告知我們其無法運作，我們肯定會查看一切的運行情況，但我們不會執行下一步行動並再次檢查訊息的格式是否正確，也不會查看哪些功能需要開啟或關閉。

供應商的 Oracle Cloud 存取權：我知道工作正在進行中，為供應商提供有限的 OPERA Cloud 酒店存取權，以滿足其測試/銷售示範需求。是否有「重設資料」功能？對於內部部署/開發測試，我們會定期重設資料或重新載入模式以進行測試執行或設定示範；對於雲端應用，可以考慮一下這些場景嗎？

我們正在構建雲端選項，並即將發布。但也可以在 OPERA 5 中使用內部示範系統，唯一的要求是擁有最新且有效的 OPN 會員資格以及授權與硬體組別。當然，獨自維護的成本可能會很高，但有些人卻做得很好。我們正在開發 OPERA Cloud 實驗室，并且很快就會推出。如果您有興趣購買 OPERA Cloud 實驗室，或者有興趣進一步瞭解該實驗室，請發送電子郵件至 mike.provost@oracle.com。

我們有許多客戶正在運行 OPERA 的當前版本，主要是內部部署解決方案。 我們目前正在使用以 SOAP 為基礎的 API。新平台是否允許這些現有客戶在無需升級 OPERA 的情況下使用新的 REST API？或者 REST API 是否不適用於內部部署的 OPERA？如果我不想使用 SOAP，我有什麼選擇可與内部部署的酒店 OPERA 資料庫連線？

新的 REST API 最初將可用於 OPERA Cloud 酒店，我們會將其擴展到我們的 OPERA 5 託管環境。目前，我們還沒有立即將該功能擴展到內部部署網站的計畫。您現有的介面 (例如 OXI 和 OWS) 將適用於這三個不同的部署方案，但目前，新的 REST API 和平台將僅連接到我們的雲端和託管執行處理。

我的開發人員非常希望能夠存取 OPERA 封閉測試環境。我們有哪些選擇？

我們實際上有一些不同的選項。您可以購買自己的 OPERA Cloud 環境。但這是您自己的持續性環境，而不是共用的封閉測試環境，所以這將是比較昂貴的選項。

我們也有一些較低成本的選項。我們將推出一個共用封閉測試環境，並透過 OHIP 開發人員入口網站提供。這並不是完整的 UI 存取權，而只是 API 存取權，當然我們會根據需要協助解決應用程式方面的問題。將按呼叫使用收取封閉測試環境的存取費用。如果您只需要偶爾進行存取，以測試一些呼叫，這是一個不錯的選擇。您只需為所需的交易付費，這將幫助我們抵消提供共用架構的成本，而且您不用花費金錢和時間來維護自己的環境。

另一種選擇是，只需花幾個小時的時間咨詢 Oracle Consulting 團隊，即可輕鬆使用實驗室。您可以根據需要的時間簽訂合同，然後使用實驗室並在此期間獲得一對一的幫助。您還可以與已經擁有 UAT 或其他非生產環境的酒店合作，與他們達成協議，以使用其實驗室。我們的一些合作夥伴在 OHIP 方案之外完成了這項工作，例如使用 OXI 或 OWS。這可能會有點複雜，但如果您有一些可能會密切合作的客戶，這是其中一個選擇。

如果我們有共用房間 — 同一房間預訂兩次，那麼每次預訂時，我們用於獲取預訂請求的預訂確認編號是否是唯一的？如果是這樣，則兩個預訂的確認編號將不同，resv_ID 也不同。

確認編號不是唯一的，原因在於 OPERA 中的航程編號。您可以在環境中針對不同日期和不同酒店進行行程預訂，這些預訂具有不同的航程編號，但確認編號相同。因此，航程 1、航程 2、航程 3 和航程 4 可以有 4 個確認編號。在這種情況下，確認編號不一定是唯一的。但是，resv_name_id 在每個環境中絕對是唯一的。如果是兩個不同的環境，則確認編號與 resv_name_ids 可能類似，因為它們是個別的資料庫。但在一個資料庫中，resv_name_id 絕對是唯一的。

建立雲端實驗室後，如何重設資料？

我們有幾個選項可以提供協助，這些選項將包含在我們推出的資訊中。我們仍在努力進行中。

是否可以在內部部署環境存取 REST API？

目前不可以。這是我們未來可以考慮的事情，但它不是我們首要關注的部分。部分原因僅僅是架構 — 這些 REST API 的架構存在於雲端 OPERA 版本中。若要在內部部署環境中取得所有這些 REST API，則必須在酒店内完成。有許多原因導致此問題有點複雜，其中最重要的一個原因是，成千上萬的酒店需要透過雲端層級系統進行單獨管理。

OPERA 是否有類似 Symphony 的 APIARY？

OPERA 實際上有 APIARY，但 APIARY 僅適用於我們的新整合平台 — Oracle Hospitality Integration Platform。此平台包含自助服務開發人員入口網站，您可以在其中註冊及瀏覽我們的 API 目錄。APIARY 已嵌入到此開發人員入口網站中，因此您無需單獨進入雲端；您將能夠從具有 APIARY 的外觀的開發人員入口網站瀏覽我們的 REST API 目錄。這僅適用於 OPERA Cloud 和 OPERA 5 託管環境，而非內部部署環境。對於內部部署 OPERA 部署，您需要使用現有介面 (例如 OXI 和 OWS)，其規格可在 docs.Oracle.com 上獲得。

我在哪裡可以找到上個月的支援專題講座的錄製內容？

您可以在我們的創新中心找到隨選培訓課程

我們可以有任何 OXI 業務活動在 OXI 設定檔消息中獲得舊值和新值嗎？例如，如果更新了賓客人地址，是否可以在 OXI 設定檔訊息中同時取得舊值和新值？

很抱歉，OXI 邏輯無法做到這一點。建立業務活動時，它確實包含舊值和新值，但當 OXI 去提取時，系統會按其設計，按原樣發送那個確切時間的資料 (新值)。

如何加入 OHIP 早期採用者計畫？

歡迎發送電郵至 fabricio.titiro@oracle.com

我想根據賓客姓名、入住的賓客或者今天預計抵達又未入住的賓客之類的條件搜索提取預訂 (OWS 介面)，但我在提供的此 URL 中找不到。

提取預訂呼叫僅會傳回單個預訂。一般而言，呼叫需要確認編號或內部 resv_id。如果您想查看所有預計抵達又未入住的賓客，那麼您要查找的功能可能位於預訂服務中。但是在未來的預訂摘要呼叫下，您可以呼叫並獲取所有當天預計抵達又未入住的賓客、入住的賓客、姓名等。您想要查找的功能稱為未來預訂摘要，位於預訂 Web 服務中。

OHIP 20.1 是否支援 Simphony，或是否會在較新版本中提供？

目前的藍圖是透過 OHIP 公開 Simphony API。為了實現這個目標，我們需要做一些事情。由於條款與條件和平台各有不同，因此我們需要調節所有這些專案。我們想要專注於推出 OPERA CLOUD API，因此 Simphony API 不在 20.1 發行版本中，但這是我們以後會考慮的事項。