最近笔者由于项目需要，又得学习一个新工具：SAP Cloud Platform Integration，简称 CPI，以前又叫做HCI - HANA Cloud Platform Integration Service.

![](https://img-blog.csdnimg.cn/img_convert/cb41e22aac15ea4c1ceafb91e4a9fb4c.png)

笔者想通过本文，把使用这个工具的第一手体会，分享给曾经用过SAP CRM中间件，但尚未有机会接触到CPI的朋友们。

之所以本文标题里把SAP CRM中间件和SAP CPI关联在一起，是因为二者同广义上说，扮演的都是系统集成里中间件的角色。

SAP ERP和CRM通过qRFC进行业务数据同步，而中间件能够提供队列机制，错误处理，重试，传输监控等功能。

![](https://img-blog.csdnimg.cn/img_convert/3dec5e646f5bfadddb152d99622f29dd.png)

而SAP CPI顾名思义，则是云时代下SAP推荐的SAP产品同第三方云产品进行集成的云端中间件解决方案。

![](https://img-blog.csdnimg.cn/img_convert/3d5a051ea4ba8e12c4b7df8a7bef0c4b.png)

SAP CPI（Cloud Platform Integration）是一种通过云端集成不同系统的解决方案。它是 SAP Cloud Platform Integration Suite 的一部分。 CPI 能够连接系统、服务、人员、数据、人工智能、物联网。

尽管云应用在很长一段时间内被业界广泛讨论，但在企业管理软件领域，不少公司仍然更愿意使用本地解决方案，或者至少是混合解决方案(Hybrid Solutions)。 近些年来 SAP 在公有云和私有云解决方案上做出了巨大的投资，发布 S/4 HANA 的云版本以及后续活动则充分证明了 SAP 向云端转型的决心。

而 SAP CPI 则是 SAP 本地解决方案，SAP 云端解决方案和第三方系统之间互联的重要工具和手段之一，旨在完成关于数据的协议、结构、类型和格式的转换。其用于建模 IFlow 的技术是 Java、JavaScript 或 Groovy Script.

作为学习笔记，Jerry这里把我学习SAP CPI时做的一个Hello World级别的练习步骤记录下来。

这个练习的场景是，假设有一个部署在第三方云平台上的OData服务，提供了产品主数据查询的功能。我们需要在SAP系统里消费这个OData服务。SAP开发人员不希望直接去消费第三方云平台上的OData服务，而是期望SAP CPI能暴露一个更加容易访问的API endpoint出来，例如通过postman传一个Product ID给CPI，CPI拿到这个ID后，由CPI向第三方云平台发起OData请求，拿到请求响应后，CPI把结果返回给位于SAP产品的消费端。

![](https://img-blog.csdnimg.cn/img_convert/2385cc1b26114b134ce3c5eab210ccea.png)

用于这个场景的OData服务地址：https://espmrefapps.hana.ondemand.com/espm-cloud-web/espm.svc/$metadata

![](https://img-blog.csdnimg.cn/img_convert/984ef2dfd73c787a3509e660f951f502.png)

SAP CPI是一个SaaS应用，在SAP云平台控制台的Subscriptions面板里订阅和访问。点击Go to Applications进入主操作页面。

![](https://img-blog.csdnimg.cn/img_convert/0ce035515f95b22d09fa203f6c489e88.png)

我们为了实现这个集成场景需要在CPI里开发一个集成流 - integration flow(下文简写为iFlow), 用于定义当其收到消费者传入的product ID后，应该进行何种处理。
和ABAP里的程序需要存储在一个开发包里一样，iFlow也需要存储在一个包里，称为Content package.

进入CPI后在此处创建一个Content package：

![](https://img-blog.csdnimg.cn/img_convert/111feb2d555688ff21838614af02138c.png)
![](https://img-blog.csdnimg.cn/img_convert/8205d83cce00f386d98c3bb43aaf39e8.png)

然后点击上图的Artifacts进入iFlow创建界面：

![](https://img-blog.csdnimg.cn/img_convert/dcd351e4e9868c2e5513193c81c2b85f.png)

取名Jerry first integration flow, 再点击就能进入iFlow的图形化编辑界面了。

![](https://img-blog.csdnimg.cn/img_convert/445bb5de3553a31afea9594914a7d478.png)

一个新的iFlow创建之后的默认界面如下：

![](https://img-blog.csdnimg.cn/img_convert/ba3da2edf81eae7b0ca0b24cc0691ecf.png)

点击上图最左边的Sender图标，将其拖拽到上图中间integration process矩形框内的Start图标内，这个动作会帮助我们创建一个inbound adapter，类型我们选择HTTPS，意思是这个iFlow期望其被消费的方式是HTTPS.

![](https://img-blog.csdnimg.cn/img_convert/5b804e356405fb7c313e2e8a8d77d35c.png)

在Adapter的Address里维护一个url片段/CloudIntegrationTrials, 等到最后该iFlow正式部署后，生成的endpoint就是以该片段结尾，届时我们可以在postman等工具里使用该endpoint消费这个iFlow.

![](https://img-blog.csdnimg.cn/img_convert/93aaeef430b742d110af3ed25bb2868c.png)

考虑到现在流行的Restful API实现都期望其消费者以JSON格式传输请求内容，我们也沿用这个最佳实践，因此首先拖拽一个JSON to XML Converter到iFlow integration process建模区域的矩形框里，将JSON 格式的用户输入转换成XML格式：

![](https://img-blog.csdnimg.cn/img_convert/9527b9e38a28c4816303f89be3b104c5.png)

然后再使用Content Modifier，将XML格式里的product ID的值提取出来。

![](https://img-blog.csdnimg.cn/img_convert/3f072a3e9b82dd879caf78dbc800fba4.png)

下图展示了Content Modifier通过XPath将XML格式的输入里的productIdentifier这个字段的值提取出来。

![](https://img-blog.csdnimg.cn/img_convert/49b280f0a1440b7d74474c7a2ad5f5c3.png)

有了product ID，可以进行OData调用了。从iFlow建模的工具箱里拖拽一个External Call出来：

![](https://img-blog.csdnimg.cn/img_convert/57ac7488463eb71d8f3643d47e727093.png)

类型选择成OData V2：

![](https://img-blog.csdnimg.cn/img_convert/9888d947d7bd4e6854f444b91e4b978f.png)

指定前面提过的OData服务的url：

![](https://img-blog.csdnimg.cn/img_convert/f1c2cf6368c530c7c9dfa25b659d8304.png)

选择该OData服务的Products节点作为消费的对象：

![](https://img-blog.csdnimg.cn/img_convert/4153944422854a6b5710f78fc34d3416.png)

将OData Product节点的ProductId字段绑定到前一步骤通过Content Modifier解析出来的包含了用户输入的productIdentifier字段。

![](https://img-blog.csdnimg.cn/img_convert/9caa92f4a12451d157e0edc8cba63626.png)

就像小朋友们搭积木一样，我们把iFlow工具箱里提供的元素，通过拖拽的方式组合成了一个图形化的流程。点击Deploy进行部署：

![](https://img-blog.csdnimg.cn/img_convert/8e83e5ba509fa9453353020d8c2d3fbf.png)

部署成功之后，抄下这个生成的endpoint：

![](https://img-blog.csdnimg.cn/img_convert/f904813448505c85f4d2a6d8d48b8c29.png)

在Postman里向这个endpoint发送一个GET请求：

![](https://img-blog.csdnimg.cn/img_convert/b7ac27da3cf169a80e24c2e5f04d1623.png)

部署在SAP Cloud Platform上的CPI iFlow接收到了请求后，就会按照我们维护好的逻辑，解析出Product ID，调用OData服务，将该ID对应的Product明细数据作为结果返回给消费端。

![](https://img-blog.csdnimg.cn/img_convert/60f41669054652e2ef65de1ccb2232ad.png)

和SAP CRM中间件有各种通过事务码比如SMW01访问的监控应用一样，SAP CPI也有类似的监控程序：

![](https://img-blog.csdnimg.cn/img_convert/f9c3d656234065e9f89b83bf3bcb1a58.png)
![](https://img-blog.csdnimg.cn/img_convert/47389387fc05c16a534657b42d293e5f.png)

希望这个最简单的例子能让还没有接触过SAP CPI的朋友对其作用有个最直观的了解，感谢阅读。

# 总结

本文首先将 SAP Cloud Platform Integration 同 SAP On-Premises 解决方案下的 CRM 中间件进行了对比，接着阐述了 SAP CPI 在 SAP 向云端转型过程中扮演的重要角色，最后通过一个具体的 iFlow 开发例子，力求给没有使用过 CPI 的开发者一个最直观的印象。

ITPub博客

通过一个具体的例子，讲解 SAP Cloud Platform Integration(CPI) 的使用方法

最新文章