共计 1389 个字符，预计需要花费 4 分钟才能阅读完成。
有敌人发问：
内部 SaaS 利用通过 ODATA API 拜访 SAP 标准接口，间接从本方利用发动拜访就能够，无需借助 PI 或者 BTP 类的平台吧？既然这样，通过 BTP 或 CPI 来构建利用绝对比间接在第三方平台上构建利用的益处是什么呢？是因为这 2 个平台除了获取数据，有更多对于流程设计和相似扩大插件（不必反复造轮子）的性能，并能够公布到 SAP 利用市场吗？也就是如果我不须要这些插件辅助，不到利用市场公布，是能够绕过这些平台的。
对于 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，取决于集成所需实现的具体场景以及实现复杂度。
更多 Jerry 的原创文章，尽在：” 汪子熙 ”:
