光看封面配图，这篇文章很容易被误认为在讲成都的美食之一：火锅。

SAP成都研究院坐落在被联合国教科文组织授予过“美食之都”称号的成都，所在的天府软件园，半径1公里左右星罗棋布着很多闻名的火锅美食店。

那么火锅和本文主题，SAP云平台同第三方CRM解决方案互联有何关联？

HubSpot是一个微型的CRM解决方案，麻雀虽小，五脏俱全。大家可以使用邮箱免费注册然后体验。

从登录进去后的主页菜单能看出，一个CRM系统的三大核心模块Sales，Service和Marketing，HubSpot都具备。

而Jerry写这篇文章时，不断地把HubSpot敲成HotPot，罪过罪过。。。

之前Jerry陆陆续续介绍过一些SAP系统同第三方解决方案集成的技术：

一些SAP Partners能够通过二次开发实现打通C/4HANA和S/4HANA的方法介绍：通过C4C的Event Notification功能，每当C4C的销售订单创建时，都会通过事件通知机制，调用S/4HANA注册的事件处理函数，把这个订单同步到S/4HANA去。

WordPress，SAP Kyma和微信三者的集成
从ABAP Netweaver的SICF到SAP Kyma的Lambda Function
周伯通的空明拳，米诺斯的星尘傀儡线，SAP Kyma的Serverless
还在用ABAP进行SAP产品的二次开发？来了解下这种全新的二次开发理念吧
以上四篇文章均围绕如何使用Kyma Lambda Function来扩展SAP产品或者客户的legacy系统来介绍的。

SAP云平台上的ABAP编程环境里如何消费第三方服务：这篇文章的标题就已经很好的诠释了文章内容了。

给用过SAP CRM中间件的老哥老姐们讲讲SAP CPI：通过SAP Cloud Platform Integration调用第三方OData.

本文介绍另一种集成方式同第三方应用进行集成：SAP API Management Service + SAP Open Connector. 第三方应用选择的是HubSpot. 我们将开发一个SAP UI5应用，通过这种新介绍的方式在UI5应用里显示HubSpot系统里的Company数据。

大家也许会问，这个常规需求，我直接在UI5应用里编程，直接调用HubSpot的Restful API，不是一样也能实现么？

SAP官网给出了使用Open Connector能享受到的收益，比如借助SAP在云平台上预置的连接器，能够减少集成的开发时间，降低集成复杂度，提高开发效率等等。

而SAP云平台上的API Management Service，对通过Open Connector连接的API提供了企业级的API操作方式和统一的生命周期管理。

下面是集成的具体步骤。

进入SAP Open Connector首页，点击Connectors：

这个列表里就是SAP官网上介绍的pre-built的第三方CRM应用的连接器。

我们从列表里找到火锅，哦不对，找到HubSpot：

点击Authenticate, 建立SAP Cloud Platform同HubSpot的安全连接：

创建一个HubSpot的连接器实例，这里需要填一个API key：

到HubSpot的settings页面创建一个API key：

实例创建完毕后，就能在SAP云平台环境里通过这个实例消费HubSpot的Restful API了。

Open Connector的控制台里，还有这种叫做Common Resources的模型，有什么用处？

看帮助文档："提供了一个预先配置好映射关系的通用数据接口，能够将通过Connector连接的不同CRM服务的数据通过简化的模型返回"。

看具体的例子。我在HubSpot里创建了两个Companies:

如果直接消费HubSpot的API，请求的url如下：
https://api.hubapi.com/companies/v2/companies/paged?hapikey=<your API key>&properties=name&properties=website

尽管我们通过url参数只请求了name和website两个字段，从响应数据结构中可以发现，HubSpot除了返回这两个字段的值以外，还包含了一些控制字段信息，比如timestamp, source, sourceId等字段，而我们对这些字段不感兴趣。

现在就是Common Resources派上用场的时候了：

这个Common Resources起的作用好比ABAP里的simple transformation，可以根据预定义好的mapping规则，对HubSpot API返回的数据进行一些“变形”，移除一些我们应用不关心的字段。

点击Send按钮，从Transformed Response里观察到通过Common Resources处理后的数据：

现在这个数据看起来是不是清爽多了？这也就是我们UI5应用期望消费的数据。

如果对标准的Common Resources预置的映射处理规则不满意，还可以把标准的Resource克隆出来，然后在上面做修改。下图是我自己修改过的两个Resources模型。

Connectors至此就开发完毕了，实际上我们连一行代码都没写，准确地说是配置完毕了，这也证实了SAP官网提到的Open Connector给集成开发人员带来的便利。

有了Connectors，但我们还没有生成可供SAP UI5应用消费的endpoint，这部分工作交由API Management Service完成。

登录API portal，将这个API tenant同之前创建的Open Connector连接起来，这个连接取名叫jerry_openconnector_provider:

需要填的Organization Secret和User Secret在Open Connector控制台里获得：

回到API界面，创建一个新的API provider：

从下拉菜单里选择刚才创建的jerry_openconnector_provider,

点击Discover按钮：

就能自动检测出之前创建的Open Connector实例了。

点击Deploy进行部署：

Deploy之后，可以在API portal里根据swagger风格的操作方式来浏览通过Open Connector连接的HubSpot API了：

现在我们已经有了一个可用的API endpoint，通过它，我们的
SAP UI5应用就可以访问HubSpot的Restful API了：

在浏览器里测试，确保通过这个url能够返回我们期望的数据：

最后一步，就是常规操作了，新建一个SAP UI5应用，在里面通过JSON Model访问之前API provider暴露出来的url:

为了解决跨域问题，上面第12行使用了指向API provider的相对路径，通过neo-app.json里声明的Destination指向实际的完整路径：

在SAP Cloud Platform上创建这个名为api_portal的Destination：

一切就绪后，打开UI5应用，就能看到通过API provider，经由Open Connector从HubSpot取回来的数据了。

这种通过Open Connector和API Management Service同第三方应用进行集成的方式，同Jerry文章开头回顾的几种方式，并无孰优孰劣之说。在实际的工作中，我们需要根据自己企业的实际情况，比如现有系统架构，开发部门的技术水平，项目预算等，灵活选择适合自己企业的集成方案。如果非要寻找一些通用的最佳实践，可以参考SAP CTO在各大会议上介绍的SAP云端编程模型(Cloud Application Programming Model)技术选型的决策树，来制定适合自己企业集成方案选型的决策树。

感谢阅读。

要获取更多Jerry的原创文章，请关注公众号"汪子熙":