SAP十项正在退场的开发技术盘点与迁移指南

上个月帮一家老牌制造企业做升级前的技术评估我打开他们的开发对象清单满屏的Web Dynpro、LSMW、一堆经典接口旁边项目组用红笔标了一行字这些未来怎么办这大概是每一个还在维护老系统的人早晚要面对的问题。SAP生态每年都有技术悄悄退场没有人专门跑来通知你只有等你升级或合云的时候才在兼容性列表里发现它已经不在推荐队列里了。这篇盘点就是基于我自己做评估和迁移时的观察整理的。我按“官方明确不再发展、进入维护模式、战略上被新架构替代、事实上没人再使用”四种口径挑出了十个最典型的开发技术。它们不一定都立刻消失但都进入了“可运行但不可依赖”的阶段。如果你还在用其中任何一项这篇文章会给到你一个具体判断它死到什么程度了替代方向在哪什么时候该动。1. 先给这十项技术画个全景免得越看越糊涂盘点之前先把口径说清楚。我列出来的这十项不是SAP官方某张“废弃清单”的逐字搬运而是结合多年系统升级和接口改造项目里碰到的真实情况总结的。它们有一个共同特征新项目里基本不会再被推荐官方文档正逐步下架培训市场几乎没有新课社区讨论热度也在明显下降。技术当前状态核心替代方向Web DynproJava版基本停摆仅存量维护SAPUI5 / FioriWeb DynproABAP版进入维护模式SAPUI5 / Fiori ElementsVisual Composer早已停止发展SAP Build / SAPUI5BSPBusiness Server Pages事实弃用SAPUI5 / 自定义服务器端接口经典Dynpro / Screen Painter新开发不再推荐Fiori / UI5RFC / BAPI作为新建接口新接口建议改用OData/RAPOData / RAPIDoc / ALE保留但不再作为新集成主选OData / 事件驱动集成PI/PO传统映射与适配器开发云集成战略下逐步边缘化Cloud IntegrationCPINetWeaver BPM / BRM不再主推等待迁移SAP Build Process AutomationLSMW / BDC手工批导事实弃用仅在迁移场景应急Migration Cockpit / Data ServicesWeb AS Java / NWDI整套技术栈退出主线BTP Cloud Foundry / Kyma这里需要留个心表中说的“状态”在不同行业和不同版本里表现不完全一样。比如在用传统ECC的老客户那RFC和IDoc还是绝对主力没有人会要求你马上拆掉。但这不是因为它们被官方保驾护航而是系统本身的演进周期还没走到那一步。1.1 我在评估时通常先问的三个问题面对任何一项旧技术我先不急着搜官方终止维护日期而是问三个更实际的问题第一它是否阻碍当前系统升级到S/4或合云第二它是否已经缺少新功能支持导致业务需求只能靠硬编码绕路第三团队里是否还有能力继续维护它。这三个问题只要有一个明确打勾我就把它列入“需要处理”的清单而不仅仅是“也许以后再说”。老技术的麻烦在于它平时不吭声等你真正需要它帮忙的时候才会发现周围已经没人修它了。这也是为什么我认为盘点比忍耐更重要提前知道未来三五年技术方向好过年年纠结“到底要不要换”。1.2 这十项是怎么选出来的选择标准上我刻意排除了那些虽然老但仍然活跃的技术。举例来说ABAP语言本身依然保有主流地位函数模块也仍然能跑这些不叫弃用只是“不新鲜”。能被放进这份名单的要么有明确的官方退场信号要么在S/4和云架构下已经找不到新用武之地要么已经连社区都懒得讨论了。另外我补充一点有些被点名的技术比如SAP GUI还不是弃用只是在新开发中逐渐退居幕后。真正的“弃用”要更严重是连官方都劝你不要再用它去构建新东西。下面我会按这个标准逐个展开。2. “弃用”背后的四种真实状态别被一句话带偏“被弃用”这个词特别容易让人误解为“马上不能用了”。实际根本不是这么回事。我在第一个项目时听到某技术停止维护第一反应是赶紧替换结果顾问按住我说还能再跑五六年。这里面的关键差别是弃用的程度和阶段完全不同。2.1 官方终止开发连补丁都懒得等这是最严重的一级。某种技术被官方明确终止开发意味着它不仅没有新功能连主流维护期的修复补丁都不再保证。Visual Composer就是这种典型它消失得干干净净你几乎找不到任何新的部署实例。这类技术一旦遇到底层平台升级或安全漏洞处境会非常尴尬因为补丁得自己打标准支持已经没了。如果评估清单里出现这类技术我给企业的建议通常是列入强制迁移队列时间窗口按一到两年安排。拖得越久后面升级遇到的兼容性风险就越大。2.2 进入维护模式能修但不治进入维护模式的技术官方依然会修复严重bug和安全问题但不会再投入新功能研发。Web Dynpro ABAP版就是比较典型的例子原有应用继续维护没问题但你不可能指望它发展出新交互模式也不可能在移动端上玩出花来。这种状态最迷惑人因为系统看起来很好用一直没出事。但一旦业务部门提出新需求比如要在界面加一个拖拽交互或实时协同功能你立刻会发现技术边界非常硬要么绕路要么推翻。维护模式不等于安全它只是把问题从“马上要坏”变成了“以后每次需求都很难办”。2.3 战略替代没人说它死了但新项目里没位置若干旧技术并没有明确宣布终止只是在新架构里被悄悄换了角色。RFC和BAPI作为接口技术的地位就是这么变化的它没有关门但所有新项目都被建议走OData和RESTful API。在云端环境里传统RFC通道天然受到网络和认证模型限制连打通都不太容易。这类技术最难盘点因为你找不到一纸“废弃通知”。但仔细观察新项目规范、官方推荐架构图和年度技术趋势就能发现它已经被边缘化。对待它们的理性做法不是立即推翻而是划一条线存量系统继续用新增接口一律走新标准。2.4 事实弃用文档还在社区已经走了最后一类叫事实弃用。没有官方声明没有正式替代流程但整个开发者社区都已经不再讨论它招聘市场上几乎找不到对应岗位新教材里也不再出现。BSP就属于这一类。它还能运行但当你遇到棘手问题想找人问社区里翻半天都找不到有价值的答案。我有个判断技巧打开技术论坛看近半年新增帖子的数量如果一个技术版块几乎没有新讨论只有零星“有没有人还在用这个”的考古帖它基本已经进入事实弃用状态。这个信号比官方的生命周期表更灵敏也更贴近实际维护难度。3. UI与前端四个被Fiori浪潮顶掉的老伙计前端技术在这十年里变化最快。每次做系统界面改造都像在看一部压缩的行业进化史。从桌面客户端到浏览器页面从服务端渲染到前端组件化节奏非常快。我盘点的十个技术里有四个都倒在UI这个战场上。3.1 Web Dynpro曾经的“未来”现在的历史我第一次接触Web Dynpro时教材里的定位是“下一代企业Web UI标准”。它分Java和ABAP两个版本分别对应不同技术栈。当时它为SAP填补了严重的网页交互缺口很多企业基于它做了采购审批、报表查询、设备管理页面一度部署规模非常大。后来情况急转直下。SAPUI5和Fiori出现后Web Dynpro在交互体验、响应式布局、移动适配上的劣势被无限放大。Java版基本停在原地ABAP版转入维护模式官方在新项目里几乎不再推荐。我见过不少项目还挂着Web Dynpro页面运行稳定维护的人却越来越少新入职的年轻人根本不愿意学这门“老手艺”。如果你手头有Web Dynpro应用我的建议是分两步走先做一份使用量和业务重要性清单把高频、核心、业务复杂的页面挑出来作为Fiori迁移的优先级第一梯队低频页面可以继续跑着等升级到某版本实在撑不住再说别一次性全替换没必要。3.2 Visual Composer可视化建模的先行者一句话也没留下Visual Composer在当年算很有想象力拖拖拽拽就能组合出企业应用界面不需要写太多代码。我认识的那批老顾问里真有不少人靠它快速给客户搭原型。但它的生命周期实在太短还没等到主流市场接受就被新战略取代了。更关键的是用它构建的应用在底层代码可维护性上非常差后期稍微复杂一点的需求就转不动。现在回过头看Visual Composer给人最大的教训是低代码建出来的东西必须保证底层模型能迁移否则平台一停应用也跟着陪葬。它的技术遗产几乎为零当年建的应用基本都需要完全重建没有平滑升级路径。如果你在老文档里看到它不用犹豫直接按重写处理。3.3 BSP被遗忘的网页时代BSP全名Business Server Pages思路和早期的JSP、ASP类似在ABAP服务器里直接写网页脚本。放在当时看确实给ABAP开发者打开了一扇Web大门不少企业用它做了简单报表页面或内部工具。但它的架构限制非常明显页面逻辑和后端代码混在一起前端体验粗糙浏览器兼容性也一般。随着Fiori和SAPUI5成熟BSP基本被扫进历史角落。官方没有大张旗鼓宣传终止只是在新文档里不再提起仿佛它从未存在过。这就是典型的事实弃用。BSP应用现在还在跑的系统多半是那种“没人敢动”的角落系统。我的处理原则是能关就关不能关就包一层Fiori外壳把入口收编把底层页面彻底隐藏起来减少维护暴露面。3.4 经典Dynpro / Screen Painter还在跑但不再有新应用说到经典屏幕编程很多老ABAP开发都是靠Screen Painter画界面起步的。它跟ABAP完美绑定事务代码配一套PBO/PAI事件流做了几十年企业业务界面。你现在打开老系统看到的那些查询、维护、过账界面绝大多数都是这个技术体系的作品。但S/4时代经典Dynpro的新开发已经被放到很低优先级。官方没有废除它可Fiori体验标准已经摆在那再来一套新屏幕程序等于知错犯错。我见过不少项目明明要建设新审批流却因为团队熟悉Dynpro顺手又建了经典屏幕最后只能再为移动端补一套UI5成本直接翻倍。我的意见很直接新界面一律FioriDynpro只用来维护存量年轻人不要再在这上面投入太多学习精力。4. 集成与中间件接口老路越来越窄如果说UI的变迁是“看得见的变化”集成层的弃用就是“看不见的慢性病”。接口技术往往埋在业务深处不升级不出事一出事就是经济命脉级别的问题。这些年集成侧被替换掉的技术数量不比前端少。4.1 RFC / BAPI作为新建接口不是不能用而是方向不对RFC是SAP系统间和系统内外通信的经典协议BAPI是基于RFC封装的标准业务接口。过去做任何集成第一反应都是“这个业务有没有对应BAPI”没有就自己写一个FM暴露成RFC。这种模式如此普及以至于大量外围系统都是通过RFC批量同步主数据、过账业务单据。问题出在云和API时代。RFC是强耦合、面向函数调用的协议交互模型偏老云端环境里网络策略和认证方式让它处处受限。新架构推荐的OData/RAP本质是资源化、标准化的RESTful API更适合作服务化转型。我最近一个项目里外围系统改造时坚持要求提供标准API结果发现旧RFC能完成的事情新API虽然也能完成但数据模型和错误处理方式完全不同等于推倒重建。这里我给个务实建议已经稳定运行多年的RFC接口别为了“新”去拆拆它需要不小的业务回归成本但一切新建接口尤其是涉及云平台、移动端或外部协同的直接按OData标准来做别再开新RFC的口子。4.2 IDoc / ALE不是不能用而是方向不对IDoc和ALE曾经是企业系统间数据交换的主力。主数据分发、订单同步、财务会计凭证传输靠的都是IDoc背上千个Segment字段。我在老项目里维护过几十种IDoc消息类型调起错误处理来一个报文一个报文地查工作量非常大。IDoc的问题在于它更像一个“数据信封”对消息语义、校验规则、实时性的支持都很原始。S/4的新集成推荐走标准API和事件驱动模型实时性和可观测性都更可控。IDoc在存量系统里依然大规模存在尤其是大企业间供应链协同不太可能一夜之间全换。我的判断是IDoc不会死得很快但它的角色会逐渐收缩成“历史数据交换通道”。新建集成场景优先选API除非对方伙伴系统只认IDoc。同时要做好接口体检把那些半年都没有一条消息的僵尸IDoc清掉省得升级时还得为它们准备兼容环境。4.3 PI/PO传统映射与适配器开发云集成战略下的边缘化SAP PIProcess Integration和POProcess Orchestration承载了无数企业ESB级别的集成场景。做映射、配适配器、写Java增强是集成顾问的标准工作。不可否认PI/PO在很长一段时间里是企业系统集成的事实标准。但云战略起来后Cloud IntegrationCPI逐步成为新推荐。它不是简单的PI上云而是在架构理念上做了调整更强调轻量、可配置、API优先查日志和监控也都更直观。传统PI/PO的原地开发和运维模式与云的弹性架构相比显得越来越重。对还在大量使用PI/PO的企业我的看法是不要恐慌性迁移而是按接口重要性分批次处理核心交易链路优先改造堆了几百个小映射的闲散接口找时间一次性下线。同时新集成项目不要再用PI/PO开新接口直接上集成套件否则两三年后又要二次迁移。4.4 NetWeaver BPM / BRM流程自动化的旧战场NetWeaver BPM和BRM业务规则管理在当年是SAP对流程编排和规则引擎的重磅押注。基于BPMN建模画流程跑审批配规则算价钱我见过不少企业把它当流程中台用。后期它们的发展明显放缓官方重心转向了云端流程自动化和工作流管理。替代方向是SAP Build Process Automation集成了工作流、机器人流程自动化和规则处理更贴合云原生。它把业务用户直接拉进了流程构建过程降低了对底层BPM专业开发者的依赖。老BPM流程迁移到新平台通常不是简单平移因为建模范式从“系统编排”向“人机协同自动化”转变了。如果你维护着大量NetWeaver BPM流程建议先梳理流程目录区分“还在大规模运营的”和“历史遗留但没停掉的”。前者要规划迁移后者直接归档关闭。最怕的是不管什么流程都往新平台搬最后搬过去一堆僵尸流程运维成本一点没少。5. 数据迁移与工具链顺手的老工具正在退场UI变了接口变了连日常开发维护用的工具也在悄悄变。数据迁移和批导工具看起来不起眼却牵动着每个项目最枯燥、最易出错的环节。5.1 LSMW / BDC手工批导应急仍在但不再是正路LSMW被太多顾问当万能钥匙用了。录屏、录BDC、写映射把Excel里的数据灌进系统速度快的时候一晚上就能导几万条主数据。我早期做数据迁移时也依赖它。它的问题在于录屏对字段位置变化极度敏感系统一升级就重新录映射规则很难做版本化校验和纠错基本靠人工盯。新一代迁移场景中官方主推Migration Cockpit数据校验规则内建错误报告更清晰迁移对象也更贴合S/4的数据模型。对于大批量复杂数据迁移SAP Data Services和第三方ETL工具依然是更稳的选择。我的建议很简单新的迁移项目不要再新建LSMW录屏能用Migration Cockpit或ETL解决的问题别在LSMW上花额外精力。老的LSMW在现有系统里继续用可以但要清楚它已经不适合作为长期可持续工具。5.2 Web AS Java / NWDI一个被裁掉的完整技术栈最后要说的不是单个工具而是整整一个技术栈。NetWeaver时代的Java应用服务器Web AS Java和配套开发环境NWDI曾经支持了大量Java EE应用。那时候很多企业选了Java栈来做扩展应用觉得比ABAP更开放。后来S/4明确回到以ABAP应用服务器为主线的架构Java技术栈在本地部署里几乎失去了位置。这对团队的冲击不小。我认识几位当年专职做Java扩展开发的顾问后来都得转型学云平台开发否则项目都不需要这个角色了。它让人意识到押注一套技术栈的前提是它必须跟核心平台战略一致一旦你选的支线跟主线脱节最终只能被裁掉。如果你还在维护Java栈的旧应用请一定优先规划迁移因为它现在不仅缺新功能连环境组件都越来越难配齐。5.3 被顺带遗忘的周边项十项名单之外还有一些“沾边”技术也跟着退场了比如SAP Query、QuickViewer和InfoSet这类老式报表查询工具。它们严格说没有被官方彻底放弃但新一代报表普遍被前端分析工具替代。它们出现在这里是想说明一点弃用常常不是单点发生的而是一个技术簇连坐。你做迁移规划时眼光要放宽一点别只盯着“名单”逐项处理要按业务能力和技术簇整体评估。6. 对老系统怎么下手才不亏我的决策与行动路线盘点完这十项技术最要紧的问题是知道了又能怎么样我见过不少企业从“完全不知道有风险”直接跳到“明天就要全换”结果项目预算爆炸业务部门怨声载道。成熟的做法是把这件事当成一次资产盘点然后按风险和收益排优先级分步推进。6.1 第一步给遗留技术建档先别急着动手替换。找齐系统里所有相关清单把每个技术对应的应用、负责人、业务频率、依赖组件找出来。建一份简单的表技术名称、应用数量、活跃用户数、最近一年变更次数、对接系统、是否影响升级。这一步做完你对“家底”会有一个清晰的数后面所有决策都基于这张表不再靠拍脑袋。建档时有个细节容易被忽略查一下这些应用的“最后维护人”是否还在公司。很多老技术能一直跑靠的是某个资深顾问的个人记忆。一旦这个人退休或离职系统就成了没主的孩子。这个信号比技术本身的寿命更真实。6.2 第二步按阻碍度排优先级不是所有弃用技术都值得马上处理。我一般把技术分成三个档第一档是直接阻碍升级或合规的比如影响S/4迁移、影响安全补丁、影响云连接的必须进一年计划第二档是运维风险中等但业务还能跑比如Web Dynpro ABAP版和IDoc通道安排未来两到三年逐步替换第三档是还在但基本闲置比如几个月才会跑一次的LSMW脚本先不做任何投入等系统升级时顺便清理。优先级公式我会这样用风险度乘以业务影响度除以改造成本。分数高的先做分数低的存档。别被“所有旧技术都危险”这种吓唬人的言论带节奏投入产出比永远是第一位。6.3 第三步分批迁移别搞“大爆炸”迁移最忌讳一次性全部推倒。以UI迁移为例我操作过的项目基本是“业务线试点—流程推广—全面替换”三步走先挑一条业务流程完整但复杂度可控的路径用Fiori做出来给核心用户用收集反馈再扩展到其他模块。接口迁移同理先选一条数据量适中、对账清晰的接口做试点验证新API的服务水平再逐步扩大范围。每批迁移完成后保留新旧并行一段时间形成数据对账机制。我见过一次大爆炸式迁移上线当天外围系统全部连不上业务停摆最后花了一个多月才回滚干净这个经验值得牢记。6.4 踩过坑才懂的小提醒有几个经验属于平时文档里不会专门写、但实操特别容易踩的。第一接口迁移不能只关心“能连上”还要验证数据语义。同一个字段在新API里的编码含义可能不同典型例子是状态字段、负责组织、单位编码不做数据规则比对上线后才发现处理逻辑全变了。第二老界面迁移到Fiori不要只看视觉效果要关注角色权限和审批链路的重新映射最稳妥的方式是先梳理现有角色和菜单再对照设计。第三团队技能转型要提前启动别等迁移到一半才让ABAP工程师现学前端让项目和质量双双翻车。我个人体会最深的一条是技术弃用从来不是开发者个人意愿的结果而是企业架构演进的自然选择。越是主流平台越会定期清理自己不再需要的技术。你能做的不是抗拒变化而是保持对技术生命周期的敏感度把“什么时候该动”的权力握在自己手里。每次评估清单出现时先深呼吸然后按建档、排序、分批的节奏来事情就不会失控。