Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1475158
  • 博文数量: 931
  • 博客积分: 10
  • 博客等级: 民兵
  • 技术积分: 10198
  • 用 户 组: 普通用户
  • 注册时间: 2011-07-08 12:28
个人简介

测试

文章分类

全部博文(931)

文章存档

2020年(134)

2019年(792)

2018年(5)

我的朋友

分类: 架构设计与优化

2019-12-19 11:22:47

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

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如下:
&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的原创文章,请关注公众号"汪子熙":

阅读(574) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~