信息传递是通向干净和原始核心的门户？

对于使用S/4 HANA和SAP云平台的客户来说，事情即将变得有趣。对于许多组织来说，可以将所有主要系统"松散耦合"在一起的想法是一个难以捉摸的目标，如果不是白日梦的话。但你为什么要松散地结合呢？为了什么目的？当然，最明显的答案是降低一个系统中的更改在其他系统或应用程序中造成意外更改的风险，但对我来说，物联网协议，这个体系结构设计原则最有趣的方面是，大数据怎么看，您可以完全抽象您的ERP系统，目标是保持一个原始、干净的核心。不幸的是，这可能是不可能实现的，但我们有能力接近这个理想。

我得到你的注意了吗？虽然我喜欢用大色块来思考，喜欢用概括来帮助解释话题，但很难让每件事都完美契合。因此，让我们通过关注云平台在使用通过SCP交付的扩展（而不是直接在核心内交付的扩展）维护尽可能干净的核心方面可以发挥的作用，来深入研究松耦合这一主题。那么如何才能真正抽象出一个扩展呢？这个问题的答案在于手机、Fiori、IoT、UI5、消息或预测的扩展类型，例如，物联网企业，人工智能本科，对于这个博客，我将放大消息。让我们来看看为什么我认为消息传递扩展可以在我称之为"轻度抽象"的过程中扮演重要角色，这是我自己创造的一个有用的表达方式！

在我们继续之前，让我快速定义pub-sub方法。在"发布和订阅"的世界中，源系统和目标系统不是紧密耦合的。事实上，当源系统发布消息（例如，描述生产订单状态的事件）时，它不知道其他系统、服务或应用程序将订阅该事件或从中受益，因此这是1:many场景。源系统与订阅这些事件的目标系统（如CRM服务、web门户或应用程序）分离。如下图所示，发送方将消息"发布"到消息队列。从那里，一个或多个订阅者现在可以使用生产订单消息，无论他们认为合适与否。如果其中一个消费系统关闭或可用，则不会影响其他两个消费系统。

让我们看看两个消息传递场景：

场景1：当客户的新车从生产线推出时，客户希望得到通知。（我从最近的拉斯维加斯TechEd主题演讲中借用了这个例子。）

场景并不牵强：高端汽车制造商通过提供新车购买状态的定期更新，提供真正身临其境的客户体验。这是一个很好的例子，说明了当组织数字化时，客户如何从中受益。

使这种沉浸式体验成为现实的古老方法是定制制造系统，并在供应链系统和最终客户系统之间建立联系。第二个连接将终端客户系统与客户可以访问的移动应用程序和/或网站连接起来。即使是在使用您最喜欢的集成技术（如SAP流程集成）时，这也是一种混乱的方法，因为源系统和目标系统通常是链接在一起的，因此会产生一种"紧耦合"的场景，具有难以重用的1:1集成关系。

进入消息传递的世界，即使用SAP云的发布子体系结构平台企业消息传递（是的，SCP在云中提供消息传递！）很容易介绍。制造系统可以创建触发器来发布生产订单事件、状态更新等，而不是定制连接。一旦发布了事件，唯一的限制就是您的想象力，因为源系统和目标系统不再紧密耦合。任何支持订阅这些事件的语言都可以被提醒访问已发布的信息。因此，如果客户应用程序在移动设备上运行，这些发布的事件会触发设备调用源系统上的API来检索新车的相关详细信息。

需要注意的是，移动应用程序没有轮询，但会收到状态更改的通知。它本质上是"戳"检索相关细节。用于检索事件详细信息的api基本上是核心系统的数字构建块，可以由任何应用程序调用，而不是专门构建或绑定到移动应用程序，这当然会鼓励重用。（如果您想了解更多有关使用SCP创建api的详细信息，请查看我的车库系列，德国云服务器，第3集）。

哇—一个使用企业消息传递的完全解耦的场景！

在这个例子中，如果我想更新另一个关于产品订单状态变化的主要系统，也许我想通知销售代表，以便他可以打电话给客户？同样，考虑到松散耦合的场景，CRM系统或应用程序将订阅接收警报，而发布或源系统仍然完全不受影响。

场景2。组织希望为需要实时访问销售线索的销售代表创建自定义应用程序。

大多数应用程序不基于发布子架构。事实上，我今天看到的大多数应用程序都是使用push-pull架构构建的—我们将新记录推入数据库，当我们希望按需查看记录时，我们将其拉出。CRM系统通常是这样设置的，移动应用程序提供对CRM对象（如客户信息、销售订单和潜在客户信息）的访问。因此，在我们的示例中，销售代表会打开他们的lead应用程序，然后下拉他们想要查看的信息，这会导致一个显著的延迟，销售代表在他们认为打开应用程序并检查通知之前不会看到新的lead。