答网友问:如果用 OData 就能直接和 SAP 系统互通,BTP 和 CPI 这样的平台意义在哪里呢?

有朋友提问:

外部SaaS应用通过ODATA API访问SAP标准接口,直接从本方应用发起访问就可以,无需借助PI或者BTP类的平台吧?既然这样,通过BTP或CPI来构建应用相对比直接在第三方平台上构建应用的好处是什么呢?是因为这2个平台除了获取数据,有更多关于流程设计和类似扩展插件(不用重复造*)的功能,并可以发布到SAP应用市场吗?也就是如果我不需要这些插件辅助,不到应用市场发布,是可以绕过这些平台的。

答网友问:如果用 OData 就能直接和 SAP 系统互通,BTP 和 CPI 这样的平台意义在哪里呢?

关于 SAP 和第三方系统之间的集成,我写过一篇短文:SAP S/4HANA Cloud 系统集成的一些场景介绍

答网友问:如果用 OData 就能直接和 SAP 系统互通,BTP 和 CPI 这样的平台意义在哪里呢?

SAP On-Premises 和 SAP Cloud 产品,都可以将其业务,以 OData 服务的方式暴露出来,供第三方系统集成使用。

SAP Cloud 产品,更准确的说,SAP Public Cloud 产品,其 OData 服务可以直接通过公网访问。理论上,在第三方应用上,直接采用 Java,C#,nodejs,Python 或者其他编程语言,调用 OData API 即可。在同 SAP Public Cloud 集成的场景下,第三方应用既可以部署在 SAP BTP 上,也可以部署在任何其他服务器上,比如本地服务器,或者腾讯云,阿里云等等。

反观 SAP On-Premises 暴露的 OData API,因为 SAP On-Premises 通常部署在企业内网,因此其 OData API 无法直接被第三方应用访问到,需要使用 SAP Cloud Connector,实现内外网穿越,即下图中间的 Secure Tunnel. 在这种场景里,SAP BTP 是必须的。

答网友问:如果用 OData 就能直接和 SAP 系统互通,BTP 和 CPI 这样的平台意义在哪里呢?

SAP BTP 除了结合 SAP Cloud Connector 实现第三方应用访问企业内网 On-Premises 系统之外,本身的 Service Market Place 上也提供了很多开箱即用的服务,即包括应用程序层级的 Business Service,也有偏底层基础设施(infrastructure)层面的 Technical Service. 第三方应用部署到 SAP BTP 上之后,可以消费这些服务,避免重复造*。

答网友问:如果用 OData 就能直接和 SAP 系统互通,BTP 和 CPI 这样的平台意义在哪里呢?

当然,如果第三方应用不需要连接 SAP On-Premises 系统,也不需要使用 SAP BTP 服务市场这些服务,那么理论上,不将第三方应用部署在 SAP BTP 上,技术上也没有问题。

再说 CPI. 第三方系统通过同步 OData API 的方式同 SAP 系统集成,实现简单,代价小。而 SAP CPI 作为 第三方系统和 待集成 SAP 产品之间的中间件,两种方式各有优缺点。采用 OData API 直连 SAP 系统的方式,我们可以理解成广义上的消息通讯机制,这种机制缺乏消息的持久化,消息监控,消息发送出错后的重试机制等等。当第三方系统同 SAP 产品交换的场景趋于复杂时,比如下面这张图里展示的,外部系统同 SAP S/4HANA 服务场景的集成,第三方应用会主动向 S/4HANA 发送两条消息,并接收从 SAP S/4HANA 回复的一条异步消息。只有当这两发一收操作全部结束之后,一个场景才算完全处理完毕。如果采用 OData API 发送机制实现,这个场景的错误处理,边界条件控制等措施,需要在第三方应用内部实现,开发复杂度比较高。而这些正是 SAP CPI 作为中间件的强项和用武之地。

答网友问:如果用 OData 就能直接和 SAP 系统互通,BTP 和 CPI 这样的平台意义在哪里呢?

综上,第三方系统同 SAP 系统集成,是否选择 SAP BTP 或者 CPI,取决于集成所需实现的具体场景以及实现复杂度。

更多Jerry的原创文章,尽在:"汪子熙":
答网友问:如果用 OData 就能直接和 SAP 系统互通,BTP 和 CPI 这样的平台意义在哪里呢?

上一篇:使用SAP OData offline库实现Android应用的离线(offline)模式


下一篇:外包杯——一阶段验收总结