「BTP·集成」链接一切的隐性之手

在上一篇「BTP·战略」的结尾我们留下了一个问题Clean Core告诉我们“为什么要把创新放在外面”但放在外面的东西怎么连起来今天这一篇就来回答这个问题。本系列的第二篇「BTP·方法」讲的是BTP的通用方法论——三层架构、五步开发法那是一张适用于所有BTP项目的“总地图”。而今天要讲的集成是这张总地图上最核心的一块——它是BTP所有横向能力中使用频率最高、覆盖场景最广、也最能体现Clean Core思想落地的领域。一个总论一个分论。在进入具体的方法论和工具之前我查阅了下SAP集成的发展史尝试理清SAP集成是怎么一步步走到今天的。我相信理解了这段演进逻辑可以帮助我们理解SAP为什么要推出ISA-M这套方法论以及为什么Integration Suite这个工具箱里会有那么多看似不同但又互相配合的产品。1. SAP集成简史从点对点到统一集成平台SAP的同行对RFC、IDoc、BAPI这些名词一定都不陌生。它们代表的是SAP集成最早期的形态——点对点直连。两个系统需要对话就写一个接口一对一接通。后来系统越来越多网状结构越来越复杂SAP推出了PI/PO作为统一中间件——所有系统不再彼此直连而是通过一个中央Hub来交换消息。这是一次重要的架构升级。再到今天企业IT架构变成了“云本地第三方SaaS”的混合模式。传统的PI/PO面对这种新格局出现了两个根本性的挑战一是紧耦合导致升级困难二是异构系统增多导致接口数量爆炸。于是SAP推出了BTP Integration Suite——一个基于云的统一集成平台把流程编排、API管理、事件驱动整合在同一套架构下。用一张表来对比这五个阶段的演进逻辑会一目了然另外再做了一个图直观对比记忆这张图和这张表的共同叙事就一句话集成的演进本质上是从“能连就行”到“连得好、管得住、变起来不慌”的过程。理解了这段演进逻辑我们就能大致明白两件事第一为什么SAP要推出ISA-M这套方法论——因为集成已经不只是“选什么工具”的问题而是“怎么规划、怎么设计、怎么治理”的问题第二为什么Integration Suite这个工具箱里会有那么多看似不同但又互相配合的产品——因为它要应对的是整个混合云时代复杂多变的集成需求。那么ISA-M到底是一套什么样的方法论它怎么帮我们解决“怎么规划集成”这个难题接下来我们就从ISA-M开始看看SAP是怎么回答这个问题的。2. ISA-M集成的核心不是“用什么”而是“怎么想”很多时候工作中在遇到集成需求时我们第一反应可能是“用什么工具PI还是CPI”这种思维方式是过去几十年点对点集成模式留下的惯性。但ISA-M要纠正的正是这个惯性。在展开ISA-M的具体框架之前我们先探讨一个你我都熟悉的场景。2.1 一个场景讲清三个核心概念想象我们正在为一个客户规划系统对接。客户说“我们想把S/4HANA和SuccessFactors连起来。”如果我们上来就问“那用Cloud Integration还是API Management”我们其实已经跳过了最重要的一步。我们应该先问自己三个问题第一个问题这两个系统分别在哪 S/4HANA在客户的私有云里SuccessFactors在SAP的公有云上。这不是一个On-Premise到On-Premise的集成而是一个Cloud到Cloud的集成。搞清楚这一点你才知道需要经过什么网络通路、要不要Cloud Connector。这就是集成域Integration Domains要回答的问题——它解决的是“物理边界”问题系统部署在哪里决定了网络通路和技术约束。第二个问题这次集成本质上是在做什么 你是想把SuccessFactors里的员工主数据同步到S/4HANA里数据集成还是想在员工入职审批通过后自动创建供应商记录流程集成还是想让HR主管在一个界面上同时看到两个系统的待办事项用户集成不同类型的集成对时效性、数据一致性、接口设计的要求完全不同。这就是集成风格Integration Styles要回答的问题——它解决的是“逻辑分类”问题这次集成本质上是什么类型的事决定了技术的侧重点。第三个问题这个场景业界有没有成熟的套路 SAP在API Business Hub里已经有大量预构建的集成方案。SuccessFactors到S/4HANA的员工主数据同步本身就是一个标准用例你不需要从零设计直接参考已有的最佳实践即可。这就是用例模式Use Case Patterns的价值——它解决的是“实例化”问题把抽象的评估结果匹配到具体的业务场景中让你不用重复造轮子。这三个概念之间是层层递进的先确定物理边界再判断逻辑类型最后匹配实例化方案。 搞清楚这三件事你才能回答“用什么工具”——而且答案往往是自然而然的员工主数据同步有标准的OData API用Cloud Integration做定时复制即可如果是审批流程联动可能需要加入事件驱动。2.2 ISA-M四步法从“想清楚”到“做出来”ISA-M 的全称是 SAP Integration Solution Advisory Methodology。上面的三件事其实正是ISA-M第一步Assess评估要回答的核心问题。而整个ISA-M方法论把集成的完整决策过程拆成了四个递进的步骤Assess评估→ Design设计→ Define定义→ Enable启用。我们用一个“城市规划”的比喻来理解这四步的整体关系。想象我们是一座城市的规划局长。我们不能一上来就修路我们得先搞清楚这座城市的现状——有多少条路、多少辆车、高峰时段堵在哪。对应到集成就是刚才那三个问题系统在哪集成域、干什么事集成风格、有没有现成方案用例模式。这一步就是Assess评估。搞清楚现状之后我们开始画设计图——主干道怎么规划、立交桥建在哪、公共交通怎么覆盖。对应到集成就是做技术映射、集成场景发现、接口选择。这一步就是Design设计。设计图画好了我们得制定交通规则——红灯停、绿灯行、限速多少。对应到集成就是制定开发规范、架构蓝图、集成模板和操作指南。这一步就是Define定义。光有规则不行我们得建立交警队——有人执行、有人监督、有人培训。对应到集成就是建立集成能力中心明确角色职责用分级治理来确保方案不跑偏。这一步就是Enable启用。ISA-M的核心理念用一句话概括就是方法论不是让我们变慢而是让我们不再拍脑袋做决策。这四步中第一步Assess是根基也是很多顾问最容易跳过的一步。过去我们习惯了“需求来了就动手”很少花时间去系统性评估。但正是这一步决定了后续所有技术选型的方向。如果连“谁和谁要连、为什么连、有没有现成方案”都没搞清楚后面的设计画得再好看也是空中楼阁。当然ISA-M只是告诉我们“怎么想”。真正动手的时候你需要具体的工具来落地。接下来我们就来看看SAP Integration Suite这个工具箱这工具箱里的工具很多我们着重讨论最核心的三件套——我认为可以称之为集成的“三叉戟”。四步法的详细框架我整理在文末附录中感兴趣的朋友可以对照查阅。集成的“三叉戟”BTP集成工具箱核心三件套真正动手的时候需要具体的工具来落地。SAP把这些工具打包在一个叫 SAP Integration Suite 的产品套件里。SAP Integration suite的核心产品罗列及简单概述如下今天我们聚焦其中三个最核心的产品。我称之为集成的“三叉戟”——Cloud Integration大脑、API Management门面、Event Mesh神经。为什么是这三个因为它们在集成场景中承担的角色完全不同但又经常协同作战。搞清楚了它们的区别和联系你就掌握了BTP集成能力的最核心矩阵。Cloud Integration流程编排中枢大脑如果只用一个工具来理解BTP集成那就是Cloud Integration。它解决的是“流程怎么编排”的问题——把跨系统的API、消息、数据流串成一个完整的业务流程。它的核心工作方式是集成流iFlow。我们可以把一个iFlow想象成一条自动化流水线数据从某个系统的入口Sender进来经过转换、路由、映射等一系列加工再从另一个出口Receiver出去。这条流水线可以处理各种协议——OData、SOAP、IDoc、RFC——把不同系统之间“语言不通”的问题解决掉。举个例子。一个客户的销售订单在S/4HANA里创建后需要自动同步到第三方CRM系统。我们用Cloud Integration搭建一条iFlow从S/4HANA的OData API取出订单数据转换成CRM系统能识别的JSON格式再通过REST API推送过去。整个过程不需要写一行代码拖拽配置即可完成。当然关于iFlow的创建和配置说起来简单实际操作中还是有不少坑。我计划在后续的尝试写一个“BTP集成实战”系列用独立的篇幅来记录每一个实操场景的完整步骤和踩坑经验。这篇我们先把核心概念和工具全景搭建起来。API Management服务治理平台门面如果说Cloud Integration是后台的“大厨”——负责把各种食材加工成一道道菜那API Management就是餐厅门口的“迎宾员”——负责接待顾客、检查预订、引导入座。它解决的是“服务怎么开放”的问题。当你的系统能力需要暴露给外部消费者时——不管是内部的开发团队、外部的合作伙伴、还是第三方应用——你不能直接把后台接口裸奔出去。你需要一个“门面”来统一管理这些API的访问权限、流量控制、安全策略和版本管理。API Management的核心能力包括API设计定义接口规范、API安全OAuth 2.0、API Key等认证机制、流量控制防止单个消费者过度调用、API门户让开发者能自助发现和订阅API、以及全生命周期的分析和监控。一个常见的协同场景是API Management接收外部请求并完成安全校验后将请求转发给Cloud Integration的iFlow进行复杂的流程编排。两者不是替代关系而是前后台协同的关系。Event Mesh异步事件网格神经Cloud Integration解决的是“流程怎么编排”API Management解决的是“服务怎么开放”。但还有一个场景是它们不擅长处理的当一件事发生的时候怎么让所有关心这件事的系统立刻知道这就是Event Mesh要解决的问题。它解决的是“状态怎么同步”的问题——当一个系统里发生了一件事比如订单创建、客户主数据变更它能自动把这个消息推送给所有订阅了这个事件的系统。Event Mesh已经深度集成到SAP生态中。S/4HANA中的业务事件如订单创建、客户变更可以自动发布到Event MeshBTP上的扩展应用订阅这些事件后做出响应。这种松耦合的架构恰好是Clean Core策略在“连接”维度上的最佳实践。小结这三个产品不是各自为战而是在同一个业务场景里协同作战。回到刚才那个例子一个客户订单从S/4HANA同步到第三方CRM。完整的流程可能是这样的API Management负责接收外部请求并做安全校验门面然后把请求转发给Cloud Integration的iFlow大脑iFlow处理完订单数据同步后通过Event Mesh发布一个“订单已同步”的事件神经通知下游的物流和财务系统各自响应。大脑想流程门面管进出神经传消息。三者合在一起构成了BTP集成能力的最核心矩阵。当然Integration Suite这个工具箱里还有很多其他工具——比如用来快速连接第三方SaaS应用的Open Connectors用来管理B2B贸易伙伴的Trading Partner Management。它们各有各的用途但对于建立BTP集成的整体认知来说抓住了“三叉戟”就抓住了核心。接下来还有一个问题已经用了十几年的PI/PO这些怎么办全部扔掉重来吗旧世界的资产怎么保护PI/PO迁移的完整路径SAP给我们准备了两座“桥”——一座负责“搬家”一座负责“留守”。第一座桥半自动化迁移工具Migration Tool——把能搬的搬到云上针对标准的场景SAP提供了一整套半自动化的迁移工具。这套工具的工作方式分为两步。第一步是评估Migration Assessment它会连接到你现有的SAP PO系统自动扫描所有接口生成一份评估报告告诉你能哪些接口能直接搬、哪些需要调整、哪些必须重写。第二步是半自动迁移Migration Tool对于能直接搬的接口工具会基于预置模板自动生成新的iFlow和相关配置。这就像是搬家公司的“标准化打包服务”——标准尺寸的家具直接装箱特殊形状的需要单独定制包装。第二座桥Edge Integration CellEIC——把搬不走的留在本地但用云端统一管理如果部分接口涉及敏感数据——比如银行流水、医疗记录、政府监管信息——合规要求明确规定这些数据不能离开本地数据中心。传统的PI/PO时代这类接口只能留在本地系统里跑。但如果把整个集成架构都留在本地又享受不到云端的统一管理和持续创新。Edge Integration Cell正是为解决这个两难而设计的。但需要特别强调它的本质不是一个临时的“迁移桥梁”而是一个长期的、正式的本地运行时环境。它像一个“云端中央厨房的本地分店”。菜谱iFlow设计、卫生标准安全策略、食材调配配置管理都由总部统一管理但实际烹饪过程完全在你的本地厨房里完成。数据从始至终没有离开你的防火墙但你用的是和总部一样先进的工具和流程。这个“本地分店”不是临时过渡——它会一直经营下去。只要业务场景需要数据留在本地EIC就是一个永久性的混合集成组件。它和云端Integration Suite长期共存SAP会同时对两者进行持续更新和维护。典型的迁移策略是先用评估工具盘点所有旧接口再根据评估结果分类处理——能搬的用迁移工具搬到云上搬不走的用EIC在本地安顿好少数必须重写的再手动开发新的iFlow。这个过程也和我们上一节讲的ISA-M一脉相承迁移本身也需要先评估再执行。写在最后集成不是孤立存在的能力。回到本系列第三篇「BTP·战略」的框架里Clean Core是SAP的统一设计哲学而集成是这套哲学在“连接”这个维度上的具体落地——它是Clean Core得以成立的“必要条件”。没有集成Side-by-Side扩展就无法和核心系统对话Clean Core只是一个无法落地的美好愿景。在这一篇我们用一条清晰的时间线串起了SAP集成的完整版图从PI/PO到Integration Suite的演进是“过去”ISA-M四步法教你怎么规划集成是“现在”三叉戟工具箱帮你落地执行是“未来”PI/PO迁移方案保护你的历史投资是“过去→未来”的桥梁。四者合在一起构成了BTP集成能力的完整闭环。但闭环从来不意味着终点。集成把散落在各处的系统连接起来了但连接起来之后呢数据在系统之间怎么流动起来我们能从中提炼出什么能怎么让它产生真正的商业价值下一篇「BTP·数据」我们继续探讨。更多文章见WX “日行一步”附录整理好的ISA-M 四步法框架