https://learning.sap.com/courses/discovering-event-driven-integration-with-sap-integration-suite-advanved-event-meshhttps://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 SuiteSAP Integration Suite包含 SAP Event Mesh、事件中介Event mediation和编排Orchestration。Advanced event mesh位于其下方负责流式传输与动态消息路由Streaming and dynamic message routing、网格管理Mesh management和事件门户Event portal。顶部是 SAP Business Technology PlatformBTP作为整个架构的平台底座。右侧第三方软件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 MeshSAP 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 Controlbroker 与 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 功能然后就有了这个CapabilityStep3:在 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_0092Communication user: 可以为event mesh单独建一个用户放在这Service key: 这里就是刚创建的service key ,注意这里要加一个namespace必须由三个segements应该是在这个位置加一段namespace: demo/s4hc/e4l,它的作用就是隔离因为Event Mesh是一个多租房的消息平台Namespace就是划给你的那块“专属地盘”的名字。你建的所有队列所有主题订阅都必须以这个namespace开头Event Mesh会强制校验这样哪怕别人的主题名和你一模一样也互不干扰。下面那个Arrangement Name也要改一下不能以“SAP”开头到里面就是体现在这个topic space这里Step10为该communication channel配置一个outbound topic上一步把communication arrangement建好了也就是通道打通了但还没规定什么事能走这个通道这一步就是来做这个规定。每个Event必须被分配到一个具体的topic后它才可以被订阅者收到和处理。公有云打开APP“Enterprise Event Enablement ”注意这里能搜到两个APP上面那个是Monitor下面这个才是配置找到刚才配置的Channel(就是上面那个communication arrangement)创建一个outbound topic binding下面是真实场景为物料的创建和修改以及Inbound Delivery的增删改创建了outbound topic bindingStep11接下来要在Integration Suite中创建一个Topic的订阅这里有一个关键点要在要建的Event前加namespace(就是在service key中增加的那个)然后加分隔符ce比如下面这个Eventsap/s4/beh/inbounddelivery/v1/InboundDelivery/Created/v1就要加上namespace 和 cedemo/s4hc/e4l/ce/sap/s4/beh/inbounddelivery/v1/InboundDelivery/Created/v1这三部分拼起来才是完成的订阅主题Step12 为Inbound Adapter创建credentialInbound是针对SAP Integration Suite来说的。“前提”先准备好用户role collectionsPI_Integration_Developer和PI_Administrator以及开通Cloud Integration这个capability这个前面步骤中有。建一个OAuth2 认证Step13 创建一个 iFlow来读取云事件只说关键先放一个Groovy脚本直接接受建议就行这个脚本其实什么都不做就是原样透传然后配置一个AMQP inbound adapter选完类型AMQP再先WebSocket协议然后是Connection的配置 Host,Port,Path,Credential。主机名的格式是以wss://开头路径要以/开头然后processing里写上要读取的queue的名字Queue Name然后Deploy即可。接下来可以到s4hana公有云里做一两个例子比如创建和修改BP然后再到APP ‘Enterprise Event Enablement’(这次进第一个Event Monitor而不是下面那个配置 )里查看日志也可以去Integration Suite里去看日志。下面图上Adapter的地下可以看出来刚才iFlow的配置信息