现在最显而易见的答案是“这样你就可以在这些数据上释放现代人工智能的力量”……

然而，公平地说，虽然这在某种程度上可能是正确的，但现实往往要简单得多!

在SNP，我们看到两种客户案例:

• 第一种是单一集成场景，就像一个专门的应用程序来帮助用户处理供应链的单一方面。或者仪表盘。或者以高度选择性的方式向外部审计人员提供数据。

• 第二个是大规模的SAP集成，每个生产系统中几乎所有SAP应用程序表都需要对云中的数据湖可用。

用例是多重的，包括报告、指示板、审计、供应链优化、预测性维护、减少客户流失等等。显然，在SAP数据副本上实现这样的用例(其中一些个人数据可能因GDPR原因而匿名!)有许多优点，最明显的是避免对SAP的任何性能影响。其他优点是更容易混合来自多个数据源的数据，并为AI/ML使用云特定功能。

显然，当一项技术能够很好地扩展到第二种情况时，您也可以覆盖第一种情况。然而，考虑到SAP ERP的巨大范围，集成的技术需要非常强大。

这样的软件需要涵盖这些不同的方面和特性。最明显的是实现真正的可扩展性。SNP Glue可以将数以万计的SAP表从多个SAP生产系统复制到云中，从而使数据可用于广泛的用例。初始满载和增量，理想情况下以大规模并行的方式。使用SNP Glue, SNP客户完全可以实现这一点，例如，近乎实时地从一长串SAP系统(包括ERP和BW)中复制50,000个SAP表到云中的数据湖。

如果没有良好的CDC(更改数据捕获)，即增量复制，您将需要定期执行全负载。数据将不断过时。CDC可以针对不同的SAP数据源使用不同的技术来实现，例如，数据库触发器适用于ERP，但不适用于SAP BW。

为了获得良好的性能并最大程度地减少数据在必须经过的不同跃点链中的潜在“故障点”，您需要将目标定位在 SAP 数据源和数据存储（例如 Snowflake）之间建立直接的连接。通过减少中间人、潜在的故障点，从而使集成变得更加稳固。

根据数据源、SAP模块或应用程序以及场景，您需要区分“应用程序集成”和“数据集成”。应用程序集成将更多地在源端由事件驱动(例如通过SAP Business Events、SAP bapi)，而在接收端由事件代理驱动(例如Kafka)。对于数据集成场景，您需要考虑使用原始SAP表来扩展集成解决方案并覆盖尽可能多的领域。

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。