直通-酒店v1

描述

Hotel Services Direct Connect为Travel用户提供了一种访问酒店库存的方法。

一旦酒店供应商开发并通过SAP Concur开发并认证了他们的界面，他们的库存将在酒店搜索中开始出现在酒店搜索旅行者。

此标注与入站SAP Concur web服务的不同之处在于:

• 它使用出站消息，Travel在其中调用酒店供应商提供的面向公共的API端点。
• 供应商配置和维护公共web服务接口。本指南指定SAP Concur所需的请求和响应格式。

使用这些SAP Concur产品

• 旅行同意专业/溢价
• 旅行对于Concur标准

产品的限制

此直接连接仅适用于旅行供应商提供酒店库存。SAP Concur移动应用程序不支持此直接连接。

SAP Concur产品是高度可配置的，并不是所有客户都可以访问所有特性。

在应用程序审查过程之前，合作开发人员必须确定解决方案需要哪些配置。

酒店过程概述

配置过程具有以下步骤：

1. 酒店供应商在他们的系统上创建应用程序，该应用程序将接受来自SAP Concur的请求并返回适当的响应。
2. 酒店供应商在他们的系统上创建终端，SAP Concur使用该终端访问他们的库存。
3. SAP Concur为酒店供应商创建了一个生产公司。
4. 酒店供应商通过登录到他们的生产公司在SAP Concur中注册他们的应用程序。
5. SAP Concur和酒店供应商验证申请:
   • 酒店供应商开发SAP Concur API并提供测试系统。
   • 酒店供应商向SAP Concur提供他们的测试系统的uri和凭据。
   • SAP Concur在认证系统中设置供应商，并运行一系列测试来验证两个系统之间的交互。
   • 一旦认证通过，Hotel供应商将向SAP Concur发送生产uri和凭据。
   • SAP Concur通过供应商的生产数据更新生产服务器，并进行测试预订。成功完成后，供应商将在SAP Confor中居住，以便任何客户启用。
6. Travel客户端选择进入Hotel callout(在Travel Configuration中)，以允许其用户查看和预订可用库存。

配置完成后，callout使用以下过程:

1. 用户在Travel中创建行程时搜索酒店。
2. 旅行将搜索请求发送到端点，使用POSTLESEARCE。
3. 供应商返回属性。
4. 旅行使用Post HotelAvail请求向某些属性提供税率的请求。属性的数量可配置，最大值为25.可以在每个Post HotelAvail请求中指定多个属性。
5. 如果用户选择预订酒店房间，Travel将发送Post HotelBookingRule，并向用户显示预订和取消策略。
6. 如果用户接受策略，则旅行会发送POST HOTERRES。
7. Travel将发送Post HotelItin请求，显示用户的预订。每当用户查看他们的行程时，就会发生这种情况。

这个标注也可以用来执行以下功能:

• 在原始请求中不得定价的酒店获得酒店可用的酒店
• 获取预订详情
• 修改酒店预订
• 取消酒店预订

酒店URL结构

酒店直接连接将相关信息发送到旅游供应商维护的URL。

推荐的URL结构是:https:// {servername} /同意/酒店/ v1 /

该URL由供应商在注册合作伙伴应用程序时提供。

您可以为每个消息类型使用所有消息的一个端点，或者为每个消息类型使用一个专用。在这种情况下，您必须遵循这些规则：

端点url之间唯一允许的区别是消息名(不包括OTA_和RQ/RS):

https：// {servername} / concur / hotel / v1 / v1 / pustyearch https：// {servername} / concur / hotel / v1 / hotelavail

变量部分不需要在最后：

https:// {servername} /同意/酒店/ HotelSearch / v1 / https:// {servername} /同意/酒店/ HotelAvail / v1 /

安全

SAP Concur将使用SSL调用应用程序连接器的端点。在配置期间，SAP Concur将连接到应用程序连接器以验证其主机名和访问凭据是否有效。

SAP Concur将无法连接到应用程序连接器，直到应用程序连接器中安装了证书颁发机构（CA）的证书。如果您托管应用程序连接器，则需要在SAP Concur访问连接器之前安装签名证书。

SAP Concur将使用Http Basic身份验证。酒店供应商将需要提供SAP Concur将为每条消息发送到供应商系统的凭据。

出站消息

SAP Confor出站消息格式基于OTA2011B酒店标准的子集。有关请求和响应格式的详细信息，请参阅下面的函数链接。

请注意以下关于这种格式的一般信息:

• 所有消息都是无状态的;没有会话，消息可能来自不同的旅行IP地址。
• 在所有请求中将发送首选语言。酒店供应商应尽最大努力回报用户偏爱的语言。如果不支持用户的首选语言，则可以使用默认语言。
• 客户标识符将在所有请求中发送。这样做的目的是提供客户特定的数据，如酒店优惠和特殊的客户折扣或政策。
• 请求和响应支持Gzip压缩。这是通过正常的http gzip协议控制的，并不是必需的。
• 所有的响应将被限制在未压缩的5MB大小，并且必须在30秒内返回。
• 对于生产系统，当前IP地址范围（您需要启用所有IP地址范围）：
  • 12.129.29.0/24和12.129.32.0/22(美国数据中心)
  • 84.14.175.224/27和62.23.83.128/25(欧盟数据中心)

功能

• 发布可用性搜索
• 预订规则搜索
• 酒店搜索后
• 发布新的预订
• 后预订取消
• 预订后更新
• 后预订查询

附加信息

• 酒店直通电话号码

同意旅行配置

差旅客户使用差旅配置中的设置选择酒店库存。客户端必须联系SAP Concur以激活该设置。

版本控制

在大多数情况下，Hotel Services的新版本将涉及在OTA标准中添加对各种可选节点和属性的支持。这些更改将向后兼容，不应要求任何强制性更改，酒店供应商将自动升级。在实现的更改不能向后兼容的情况下，供应商将需要通过并提供一组新的酒店uri来升级Hotel Services接口。SAP Concur建议接口版本作为酒店供应商提供的酒店URI的一部分。

认证

认证过程将在供应商完成与SAP Concur认证系统的集成后开始。认证包括在认证服务器上运行多个用例，并验证在每个场景中发送了正确的响应。通常，大多数潜在的问题都在集成过程中被解决，认证可以在一两天内完成。认证期间用例的一个例子是，用户在几个月后搜索并预订一个酒店，查看行程，更改酒店的日期，然后取消预订。

反应和错误

对于错误处理，我们不使用任何特殊的消息。只需要返回适当的响应，将Success节点替换为Errors并提供一些错误描述。错误码请参考OTA代码表。请提供尽可能多的描述性错误文本。这将使双方更容易追踪问题。

一般要求

有关在此处包含在多个端点中使用的格式或值要求的信息。

代码

酒店直接连接使用的所有代码都记录在其中酒店直通电话号码．

企业标识符

公司标识符将作为RequestorID节点传递。这些值将在安装时配置。请保持类型与ID类型代码一致。

<源ISOCountry =“我们”ISOCurrency =“美元”>< RequestorID类型=“4”ID =“7777777”ID_Context =“MyHotel”/>< / POS >

如果供应商需要客户端系统的额外标识(所有对供应商的调用都有相同的值)，你可以提供第二个RequestorID:

<源ISOCountry =“我们”ISOCurrency =“美元”>< RequestorID类型=“4”ID =“7777777”ID_Context =“MyHotel”/>< RequestorID类型=“7”ID =“8172927”ID_Context =“WholeTravel”/>< / POS >

请保持类型与ID类型代码一致。请求者ID类型支持的代码是:1,2,3,4,5,7,9,13,18,21

ID类型代码表