有朋友提问：
关于 SAP 和第三方系统之间的集成，我写过一篇短文：SAP S/4HANA Cloud 系统集成的一些场景介绍
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 是必须的。
SAP BTP 除了结合 SAP Cloud Connector 实现第三方应用访问企业内网 On-Premises 系统之外，本身的 Service Market Place 上也提供了很多开箱即用的服务，即包括应用程序层级的 Business Service，也有偏底层基础设施(infrastructure)层面的 Technical Service. 第三方应用部署到 SAP BTP 上之后，可以消费这些服务，避免重复造轮子。
当然，如果第三方应用不需要连接 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 作为中间件的强项和用武之地。
综上，第三方系统同 SAP 系统集成，是否选择 SAP BTP 或者 CPI，取决于集成所需实现的具体场景以及实现复杂度。
