BTP Event Mesh

https://learning.sap.com/courses/discovering-event-driven-integration-with-sap-integration-suite-advanved-event-mesh

https://learning.sap.com/courses/sap-integration-suite/understanding-the-event-mesh-capability-in-sap-integration-suite_a436e2ab-c040-412f-b05a-9f2f7b9d5cf2

先了解事件驱动架构，四三二一

事件驱动架构 = "有事就广播，谁关心谁接"，而不是"我一个个去问"。

四要素：

事件 Event：一件值得通知的事
事件源 / 生产者 Producer：一开始喊事情的人
事件代理 Broker：中转站 / 快递分拣中心
事件消费者 Consumer：收到通知干活的人

多个中转站连起来形成的网络，就叫 Event Mesh（事件网格），像快递公司全国的转运中心网络。

核心好处就是两个字：解耦

三个类型：

通知事件：只发一个核心信息，谁要详细谁再去调取
数据事件：能带的都带上，都发布出来，谁要不用再调二次
决策事件：折中方案，多点一些关键数据，订阅着不用再去查详细就知道事

SAP 的事件格式遵循 CloudEvents 开放标准（CNCF 牵头，SAP 参与制定），好处是不同平台都能看懂同一张"信封"。

两种传输模式：

发布/订阅（Pub/Sub）：像群消息------发出去推给所有人，读完即焚，不能回看。
事件流（Event Streaming）：像视频回放------事件存在中转站里，新加入的消费者也可以从头开始看历史事件。

一句话总结：SAP Integration Suite 里的 Advanced Event Mesh 就是干这个的 SaaS 平台：管事件的流转（Mission Control）、管事件的目录和设计（Event Portal）、管监控（Insights），让 S/4HANA 等系统产生的事件实时流到任何需要它的地方。

再看下有哪些典型的应用场景，加上个"五"

五个蓝图

蓝图 1：主数据分发

主要特征：

实时更新主数据信息。
基于推送/订阅的方法。

蓝图 2：带转换能力的数据分发器
主要特征：
下游系统无需轮询，事件会自动实时推送过来
采用了 SAP Integration Suite 来进行数据丰富和事件处理

蓝图 3：实时通知功能
主要特征：
事件本身很小，只包含绝对必要的数据
基于 API 的数据访问功能还受到后端端的身份验证和授权机制的保护。

蓝图 4：跨越供应商网络

主要特征：

多样化的事件来源和不同的消费方
利用 SAP 集成套件进行事件调解

蓝图 5：高峰缓冲器
主要特征：
缓冲和解耦
跨越不同的供应商界限

五个实战案例

案例 1：事件驱动的 HR 集成

场景：一家公司的 HR 主系统是 SAP SuccessFactors，但周围还挂着一堆非 SAP 的 SaaS 应用（考勤、薪酬、背调、IT 开户......）。

痛点：新员工入职，HR 在 SuccessFactors 录完人，还得挨个系统手动开通账号、同步数据，慢且易错。

EDA 做法：SuccessFactors 有个现成的"智能服务事件"机制------员工一创建，自动广播"新员工入职"事件。各个 SaaS 系统订阅这个事件，自动建账号、补数据。全程没人手动操作。

为什么用 EDA：不用改 SuccessFactors 标准功能（贴近标准 = 升级不痛苦），第三方系统即插即用。招人快、入职顺，在抢人才的市场里这是竞争力。

对应蓝图 3（实时通知）：事件只带最少信息（员工 ID），各系统收到后用 API 去查详情------这就是上节课说的"通知事件"模式，安全且轻量。

案例 2：减震器（Shock Absorber）------ 我最推荐的入门案例

场景：零售商搞黑五促销、发新品，订单量瞬间暴涨几十倍。

痛点：如果用同步方式------网站每下一单就直接调 ERP 等它确认------高并发会把 ERP 压垮。后果：网站卡死、订单丢失，或者被迫花大钱把后端系统扩容到平时根本用不到的规模。

EDA 做法：网站只管把订单事件"扔"给事件代理（Broker），扔完就告诉用户"下单成功"。Broker 像水库一样把洪峰拦住，ERP 按自己的节奏慢慢消化。

为什么叫"减震器"：就像汽车的避震器------路面（流量）再颠簸，车身（后端系统）感觉平稳。而且 Broker 服务可以只在促销期间临时开起来，平时不用多花钱。

对应蓝图 5。这个模式在电商大促、银行秒杀里极其常见，Kafka 就是这么用的。

案例 3：跨厂商事件网格（Across Vendor Event Mesh）

场景：跨国企业，各国分公司用本地系统管订单（有的用 Kafka，有的用 Azure 的事件服务），总部用 SAP S/4HANA。

痛点：本地数据要经过好几层 ETL 汇总才能进总部系统，延迟超过 24 小时，中间环节冗余、成本高。

EDA 做法：用 Advanced Event Mesh 把各地已有的"子事件网格"（Kafka、Azure）连成一张大网，事件本地一产生，实时流到总部 S/4HANA。

收益：24 小时延迟变成秒级；汇总层级砍掉，成本大降；各地保持自主权的同时，总部获得全局实时可见性。

对应蓝图 4。这个案例最能体现"Event Mesh"这个词的价值------不是一个 Broker，而是一张跨厂商、跨地域的 Broker 网络。

案例 4：主数据分发（Master Data Distribution）

场景：SAP MDG（主数据治理）是全集团的主数据中心，物料、客户、供应商数据改一处，要同步到十几个 SAP 和非 SAP 系统。

痛点：传统点对点接口------MDG 和每个目标系统都要建专用接口，任何一个系统改版都可能影响其他集成，耦合严重。

EDA 做法：MDG 里主数据一变，推一个事件出去；目标系统各取所需（有的推、有的拉），MDG 完全不用关心谁在消费。

收益：MDG 开发和目标系统开发彻底解耦，各干各的；所有目标用统一的标准接口和监控。

对应蓝图 1。这是最常见的 EDA 入口场景------主数据分发天然适合"发布/订阅"：一个源头、N 个听众。

案例 5：数据转换分发者（Transforming Distributor）

场景：S/4HANA 是核心，但周围有 SAP ECC、SAP ByDesign、各种异构系统，数据格式五花八门，进出 S/4HANA 的数据都要清洗转换。

EDA 做法：Advanced Event Mesh 负责实时路由事件，SAP Integration Suite 负责在传输途中做数据富化和格式转换（event mediation）。不用轮询，事件来了就处理，洪峰还能缓冲。

对应蓝图 2。要点是分工：Mesh 管"运"，Integration Suite 管"改"------路由和转换各用对的工具。

每个案例的"死穴"和核心点

HR 集成 ------ 痛点：人工串联，流程断点多
不用 EDA 会怎样：新员工入职，HR 要手动在 N 个系统里重复操作，慢、漏、错。
核心点：事件是"扳机"------一个事件发生，自动扣动后面一连串流程。本质是流程自动化，事件在这里只是发令枪（通知事件，细节靠 API 补）。
关键词：自动化、贴近标准、事件驱动流程。
减震器 ------ 痛点：流量洪峰会压垮后端
不用 EDA 会怎样：黑五订单洪峰同步打到 ERP，要么系统崩、要么丢单、要么花大钱扩容。
核心点：Broker 是"水库"------削峰填谷。前端拼命往里倒，后端按自己的节奏喝。本质是异步缓冲，保护后端。
关键词：削峰、缓冲、异步。
跨厂商网格 ------ 痛点：系统孤岛 + 数据迟到
不用 EDA 会怎样：各国数据层层 ETL 汇总，24 小时延迟，中间环节冗余烧钱。
核心点：Mesh 是"胶水/桥梁"------把已经存在的、不同厂商的事件网络（Kafka、Azure）缝成一张网。本质是连通性，事件在这里是实时数据的搬运工。
关键词：跨边界、实时汇聚、打破孤岛。
主数据分发 ------ 痛点：点对点接口，耦合死
不用 EDA 会怎样：MDG 跟十几个系统两两建接口，任何一个系统改版牵一发动全身。
核心点：一次发布、N 方订阅------MDG 只管喊，谁爱听谁听。本质是解耦，把"一 source 对多 target"的依赖彻底松绑。
关键词：解耦、推送、标准接口。
转换分发者 ------ 痛点：数据格式鸡同鸭讲
不用 EDA 会怎样：异构系统（ECC、ByDesign、第三方）格式各异，每个接口都要单独写转换逻辑。
核心点：传输途中完成"翻译"------Mesh 管路由，Integration Suite 管富化和格式转换。本质是数据调和（mediation）。
关键词：格式转换、富化、免轮询。

SAP 的事件驱动生态系统

event broker 只是引擎，如果没有事件源、事件消费者以及配套的知识赋能，broker 本身毫无用处。整个生态系统才是主体。

这张图就是课程中提到的 SAP 智能企业事件驱动架构（Intelligent Enterprise Event-Driven Architecture）的整体示意图，底部一句话点明了主题："横跨 SAP 与非 SAP 解决方案的混合、异构客户环境"。它展示了事件源、事件基础设施、事件消费者之间如何连接。

左侧（事件源 / Event Sources）------两类 SAP 后端：

SAP 云解决方案（Cloud solutions from SAP）：提供可扩展的标准事件、基于 ABAP RESTful 编程模型（RAP）的自定义事件，以及面向 SAP 云应用的 Event Broker。
SAP 本地部署解决方案（SAP on-premises solutions）：同样提供可扩展标准事件、RAP 自定义事件，另有自定义事件的加载项（Add-on）。

中间（事件基础设施与消费）------核心是 SAP Integration Suite：
SAP Integration Suite：包含 SAP Event Mesh、事件中介（Event mediation）和编排（Orchestration）。
Advanced event mesh：位于其下方，负责流式传输与动态消息路由（Streaming and dynamic message routing）、网格管理（Mesh management）和事件门户（Event portal）。
顶部是 SAP Business Technology Platform（BTP），作为整个架构的平台底座。

右侧：第三方软件（3rd-party software）------强调可以"顺畅跨越供应商边界"（Smooth crossing of vendor boundaries），即非 SAP 系统也能接入这个事件网络。

箭头关系值得注意：所有箭头都是双向的，说明事件可以双向流动------事件源发布事件、集成套件路由/消费事件，第三方软件也直接连到 Integration Suite 和 Advanced event mesh；其中 SAP 本地解决方案还有一条斜线直接连到 Advanced event mesh，体现混合部署场景。

总结：SAP 云端和本地的后端系统作为事件源，SAP Integration Suite（含 Event Mesh 和 Advanced event mesh）作为事件基础设施，BTP 作为平台底座，第三方软件也可无缝接入，从而构成一个跨越 SAP 与非 SAP、云端与本地的统一事件驱动架构。

SAP Integration Suite, advanced Event Mesh in the Event-Driven Architecture

两者的消息模型本质上是一样的，上一章讲的 producer → event broker → consumer 是事件驱动架构的通用模式，SAP Event Mesh 和 advanced event mesh 都是这个模式的实现，消息本身并没有什么不同。

消息层面：也没有区别

都是发布者发布消息到 broker，再由 broker 分发给订阅者；

都有主题（topic ）和 队列（queue） 这些目的地概念；

消息类型都是事件消息、查询、命令这几类，结构也都是 Header / Properties / Body。

整体差不多，对比一下

	SAP Event Mesh	SAP Integration Suite, advanced event mesh
定位	轻量、低门槛、按量付费的"broker 即服务"	完整的企业级通用事件网格
部署	只部署在 SAP BTP 上	可跨多个公有云、私有云部署，还能把多个 broker 连成一个分布式网格（mesh）
规模	有既定的容量限制	企业级性能，可扩展到非常大的用例
高级功能	基础的发布/订阅	事件流（streaming）、动态消息路由、细粒度过滤、网格管理、事件门户（Event Portal）

打个比方：两者的"信件格式"（消息）是一样的，区别在"邮局"的能力------普通 Event Mesh 是一家本地邮局，advanced event mesh 则是一个覆盖多云环境、能智能分拣路由、企业级可靠的邮政网络。

ps：为了供离线客户端使用，该套件采用了可持久存储和不可持久存储的队列来保存消息。

一个技术方面

high level的对比

组成

一句话总结：AEM = Event Portal（设计治理）+ Mission Control（broker 与 mesh 的运行管理）+ Insights（监控洞察），三者统一在 Cloud Console 里，覆盖事件从设计、发布、发现到运行、监控的完整生命周期------这正是它区别于普通 SAP Event Mesh 的"advanced"所在。

SAP Integration Suite Event Mesh

可以理解这个是集成在SAP Integration suite中的Event Mesh，查看subaccount的entity assignments如下：

查看Instances：

进到Integration Suite有两个event mesh的菜单：

如果没有这两个菜单就是没有添加相关capability，参考下面前四步操作

一个实例：

挑其中重要的步骤记录：

Step2:激活integration suite中的Business event 功能

然后就有了这个Capability

Step3:在 SAP Integration Suite 中启用云集成功能

这个激活后，SAP S/4HANA Cloud 触发的相关事件才会被从 Event Mesh 中读取出来。

这一步需要两个权限Integration_Provisioner 和 Subaccount Administrator

然后和step2一样通过add capability来添加

step4是加权限：

下面几个是相关权限

Step5创建一个message-client instance，也就是消息客户端实例

Step6 下一步创建service key

这里有了clientd/client secret/tokenurl，可以生成一个 bearer token，从而访问 URI 所对应的端点，也就是Oauth访问。

可以通过以下方式和event mesh通信：

step7就该在这个message client中创建一个queue了

Step8 登陆公有云，它是事件发生者Event Producer

打开APP 'Maintain Business Users ' 确认你这个用户有BR_ADMINISTRATOR这个role。

Step9 在公有云建communication arrangement

为了使 SAP S/4HANA Cloud Public Edition 能够将事件发送到 Event Mesh，必须在 SAP S/4HANA Cloud Public Edition 内部建立相应的通信安排。

很重要的三块信息：

scenario : SAP_COM_0092
Communication user: 可以为event mesh单独建一个用户放在这
Service key: 这里就是刚创建的service key ,注意这里要加一个namespace，必须由三个segements

应该是在这个位置加一段"namespace": "demo/s4hc/e4l",它的作用就是隔离，因为Event Mesh是一个多租房的消息平台，Namespace就是划给你的那块"专属地盘"的名字。你建的所有队列，所有主题订阅，都必须以这个namespace开头，Event Mesh会强制校验，这样哪怕别人的主题名和你一模一样，也互不干扰。
下面那个Arrangement Name也要改一下，不能以"SAP"开头