Hospitality integrations for property management and point-of-sale

如何访问 OPERA Cloud 实例以在开发过程中使用？

1. 参加“云构建”课程的 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 可以有确认编号 1234。在这种情况下，确认编号不一定是唯一的。但是，resv_name_id 在每个环境中肯定是唯一的。如果是两个独立的环境，则确认编号和 resv_name_id 可能类似，因为它们是独立的数据库。但在一个数据库中，一个环境的 resv_name_id 肯定是唯一的。

拥有云实验室后，如何重置数据？

我们有几个关于如何提供帮助的选项，这些选项将包含在我们推出的信息中。我们仍在努力解决此问题。

是否可以在本地访问 REST API？

目前无法访问。这是我们未来可以考虑的事情，但不是我们的首要关注点。部分原因仅仅是架构——这些 REST API 的架构存在于云端 OPERA 版本中。必须基于酒店完成在本地获取所有这些 REST API 的操作。有许多原因导致此问题有点复杂，其中最重要的一个原因是，成千上万的酒店需要通过云级别系统进行单独管理。

OPERA 是否具有类似 Simphony 的 APIARY？

OPERA 确实有 APIARY，但 APIARY 仅适用于我们的新集成平台——Oracle Hospitality Integration Platform。该平台随附一个自助式开发人员门户，您可以在其中注册和浏览我们的 API 目录。APIARY 已嵌入到此开发者门户中，因此您不必单独进入云；您将能够从具有 APIARY 外观的开发者门户本身浏览 RESTAPI 目录。这将仅适用于 OPERA Cloud 和 OPERA 5 托管环境，而非本地 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 发行版中，但这是我们以后会考虑的事项。