光看封面配图,这篇文章很容易被误认为在讲成都的美食之一:火锅。
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
以上四篇文章均围绕如何使用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=&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的原创文章,请关注公众号"汪子熙":