光看封面配图，这篇文章很容易被误认为在讲成都的美食之一：火锅。
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/compan...
尽管我们通过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的原创文章，请关注公众号"汪子熙":