回顾

ERP系统旨在成为现实的数字孪生。当产品在物理世界中运送给客户时，ERP的运送文档表示此操作的数据。在追求卓越的过程中，高防云服务器，ERP系统的用户自然倾向于添加更详细的信息，例如通过定制来存储额外的数据。

下一个逻辑步骤是整合外部信息，例如装运状态。没有火箭科学来调用船务代理的API和检索交货状态。但是，通过添加更多的数据，ERP系统的复杂性和总拥有成本会成倍增加。不同的系统和模块应该看起来和感觉像一个系统。一个紧密耦合的舞蹈协调工作-奇点。

过程的整合太僵化了。如果一切正常，系统就正常了。但是，如果现实给我们的工作注入了一把扳手，预定义的过程就会分崩离析，留下一连串的失败现实表现为数据结构→软件做出影响物理世界的决策用策略管理业务→实时业务如果这比那业务逻辑简单→考虑大量相关信息

查看这些变化，可以发现许多SAP主题，例如"Hana是实时业务的平台"、"自动化"、"预测性"等。在集成领域，客户可以做得更好。

API优先？顾客至上！

短语API首先意味着有一个定义良好的接口，其他人可以使用。如果每件事都有一个API，那么任何事情都是可能的。这个假设虽然很吸引人，但有许多明显的问题。

当API相互依赖时，事情变得更加糟糕。销售订单应用程序必须知道当前物料的列表，用户选择一些，对于每个物料，必须查询可用数量，家居智能化系统价格，创建生产订单等等。ECC系统的优点是，所有的工作都在一个数据库中完成，并且数据库事务很好地支持耦合这些深度嵌套的进程。随着外部系统的出现，事情变得更加复杂，淘客插件，结果变得不可靠，因此成本高昂。

请参阅microservice dependency hell

协调数据模型的一个项目使各种数据结构之间的转换变得容易–如果所有系统使用相同的结构，则无需进行任何转换。这是一个昂贵的选择，但由于这些费用由SAP承担，因此这里没有投诉。建议的解决方案不需要它，但在"一个数据模型"完美工作的情况下它会有所帮助。

来自状态机…

集成戏剧的关键原因是ERP系统的用途：作为一个黑匣子。有人执行一个操作：创建销售订单。ERP系统设置多个动态数据库更改，完成后返回。只有少数方法存在（使用频率更低），允许外部对内部状态变化进行操作。

在一个中央ERP只是管理业务的核心系统的世界里，不需要这样的东西。但这些时代早已过去。规则不再只是预定义的静态工作流。ERP是众多系统中最重要的一个，但仍然只是众多需要协作的系统中的一个。

协作意味着交流。

…对于一个团队成员

让我提个建议：

不要为每件事提供许多不同的API，消费者必须互相调用，相反，让ERP系统主动向外界传达所有状态变化。人们可以收听该流或有趣的子集，但这是消费者的选择。它不应该提供API开发人员认为有用的属性，而应该传达所有信息。与其告知有变化，不如提供变化。

这会让其他消费者感觉像社交媒体流："嘿，customerX刚买了100件productY！"。对于人类来说，这一信息流将是压倒性的，但将其与软件服务一起使用，甚至可能将来自多个数据流的数据组合在一起，确实可以轻松地实现强大的应用程序。

可行性和成本

随时保持知情的要求是当今社会和技术决定论的直接影响。两者都指向同一个结果——通信网络。换言之，在大数据领域，客户和技术都期望能够实现这一点。

对于大数据而言，与Netflix、LinkedIn和其他公司在同一时间间隔内生产的产品相比，即使是最大的ERP系统每秒所产生的变化量也是可笑的。需求的侧重点略有不同，例如数据的一致性变得更为重要，云服务器一年多少钱，但可以得到满足。

最后，使用ERP系统作为通信枢纽，大数据分析应用，不仅比单个流程集成步骤更强大，而且实施成本更低。

从技术上讲，该解决方案确实捕获了所有S/4Hana数据结构的所有更改，将它们移动到apachekafka中，并可供所有感兴趣的人使用，并且具有适当的权限。这为我们的同事ERP系统提供了一个对外交流的渠道，让每个人都知道它所做的每一个状态变化。

在卡夫卡，我们有所有的选择来实现更多的业务逻辑，而不影响ERP系统的成本的一小部分。

结果是双赢。ERP系统用于预订，一个单一的API—Kafka数据生产者—可以实时通知所有合作伙伴系统。我喜欢有计划的时候