企业官网建设流程全解析

江西科技学校网站建设,wordpress分类目录在,网站木马诊断,wordpress head优化昨天我转载了 ERP 大师的一篇文章#xff1a;《被 SAP 弃用的十大开发技术盘点》之后#xff0c;有朋友问我#xff1a; SAPUI5 Tools for Eclipse 和 ABAP Development Tool#xff0c;这两个 IDE 都基于 Eclipse#xff0c;但一个被 SAP 抛弃了#xff0c;另一个仍然是…昨天我转载了 ERP 大师的一篇文章《被 SAP 弃用的十大开发技术盘点》之后有朋友问我SAPUI5 Tools for Eclipse 和 ABAP Development Tool这两个 IDE 都基于 Eclipse但一个被 SAP 抛弃了另一个仍然是 SAP 主推的开发工具甚至地位还高于 SAP 自研的亲儿子 SAPGUI.二者同源同宗为什么 SAPUI5 Tools 被弃用而 ABAP Development Tool 仍然是 SAP 的宠儿本文笔者从这个问题出发来谈谈自己的看法。在 SAP 官网针对 SAP UI5 开发工具的版块SAP 明确宣布不再提供 SAPUI5 Tools for Eclipse 的支持也不提供下载。https://tools.hana.ondemand.com/#sapui5SAP UI5 开发工具经历了从 SAPUI5 Tools for Eclipse 到 SAP WebIDE到现在主推的 SAP Business Application Studio/Visual Studio Code 的迁移路线。这一演进路线背后反映出的是 SAP 在前端开发领域拥抱「开放与多云支持」的转型。在 SAP UI5 发展的洪荒时代SAPUI5 Tools for Eclipse 几乎是当时 SAP UI5 开发的唯一选择。通过给 Eclipse 安装相应的 SAP UI5 插件提供 SAP UI5 项目创建本地预览以及部署到 ABAP 服务器的基本功能。本地开发需要解决本地启动并运行在 localhost 上的 SAP UI5 应用连接远端 SAP ABAP 系统 OData 服务所引起的跨域问题。SAP 为了解决这一本地开发的跨域问题引入了 ResourceServlet其实就是一个简单的本地代理。我对 SAPUI5 Tools for Eclipse 的第一印象很差。作为一个 IDE连最基础的开箱即用的 SAP UI5 XML 视图和 JavaScript Controller 里的代码补全和提示功能都没有需要繁琐的人工配置。并且生态圈封闭因为除了 SAP 之外没有第二家公司用这个工具遇到问题网上几乎查询不到任何资料。比如我曾经遇到和 ResourceServlet 相关的问题公司内也没找到可以问的同事最后只能死磕它的源代码把工作原理彻底搞透彻之后才得以解决。完事之后趁热打铁写了一篇博客没想到阅读量很高看来不止我一个人遇到类似的问题。https://community.sap.com/t5/technology-blog-posts-by-sap/explore-the-com-sap-ui5-resource-resourceservlet/ba-p/131166142014 年底时SAP 成都 Fiori 开发团队成立我加入了这个团队。2015 年 1 月陆续有从外面招聘的新同事加入我协助一位同事花费整整一周的时间才完成他电脑上 SAPUI5 Tools for Eclipse 开发环境的搭建。期间出现各种幺蛾子同样的配置在我电脑上运行正常在他电脑上就无法工作。我当时刚刚从 SAPGUI 这种服务器端开发范式迁移过来才一两个月这种需要本地搭开发环境的做法让我一度非常不适应。后来 SAP HANA Cloud Platform 诞生(就是今天 SAP BTP 的前身)出现了 Neo 环境以及运行在 Neo 环境上的 SAP WebIDE.SAP WebIDE 的出现是 SAP 前端开发工具演进的一个重要里程碑因为它标志着 SAP 开发范式从「本地插件」转向「云端服务」的架构迁移。从此SAP UI5 开发者从浏览器即用即连项目构建链、预览运行环境、与后端 ABAP 系统的连接通过 Neo 的 Destination 与相关服务统一承载。这种集中式和服务器端托管的运行形态天然避免了本地环境不一致带来的干扰并把 SAP UI5 的多个 SDK 版本供给、内容分发与维护策略交由平台统一托管。这让我再次找回了一丝丝当初使用 SAPGUI 的爽快感觉。由此SAP WebIDE 在很长一段时间成为了 SAP UI5 开发当仁不让的主力也间接将 SAPUI5 Tools for Eclipse 送进了坟墓。随着 SAP Cloud Platform 更名为 SAP BTP这个 SAP 重量级的 PaaS 解决方案其发展战略也从「自建数据中心」的单一环境转向面向主流 Hyperscaler 的多云架构(Multi-Cloud Environment).这一战略也为 SAP BTP 上的 Neo 环境敲响了丧钟。Neo 是 SAP BTP 早期的运行环境主要在 SAP 自建的数据中心提供 PaaS 能力支持 HTML5、Java 与 SAP HANA XS 等应用类型并且天然贴合 SAPUI5 前端开发与企业集成场景。SAP WebIDE 以及滋养其发展的土壤SAP Neo 环境在那个 SAP 自建数据中心的时代称职地完成了其历史使命。多云时代的开发范式意味着在同一平台下自然地接入 Node.js、支持容器化工作负载、Serverless、事件驱动、以及第三方云服务的原生接入。Neo 的原生特性与服务边界决定了它无法胜任多云时代的开发需求。图片出处https://btp.udina.de/overview/multicloud.html笔者认为 SAP WebIDE 被弃用的最主要原因并非其榜错了 Neo 这根大腿而是其自身能力的缺陷。大家不妨跟着我简单梳理一下前端开发领域发展的时间线。在 2009 年之前前端主要依赖浏览器内的脚本标签与手工拼接。拐点来自 2009 年 Ryan Dahl 发布的 Node.js它把高性能事件循环与 V8 带到命令行与服务器给前端世界第一次提供了可编程的本地运行时。Node.js 是后续一切前端工程化能力的地基。2010 年Isaac Schlueter 创建了 npm极大降低了模块化复用与依赖分发的成本。此后 npm 成为 JavaScript 生态的事实标准包管理器。面向浏览器的模块化尝试在 2011 年加速Browserify 允许把 Node 风格的 require 模块打包进浏览器由此把 Node 风格的模块与前端代码连接到了一起。进入 2012–2014 年前端社区的工作方式发生整体迁移Grunt2012与 Gulp2013把任务自动化引入前端日常工作Yeoman2012把脚手架规范化Webpack2014确立了模块打包器的中心地位这几件事共同宣告了基于 Node.js / npm 的工具链成为主流。与此同时框架层也完成现代化AngularJS 在 2010 年发布React 在 2013 年公开前者验证了浏览器端应用的可行性后者推动了组件化范式与配套工具链的成熟。语言层面ECMAScript 2015 在 2015 年正式定稿Babel 在 2015 年由 6to5 正式更名成为把新语法编译到旧环境的关键基础设施进一步巩固了「书写现代语法 → 通过工具向下兼容」的工作方式。2016 年 Yarn 发布解决了安装一致性与性能问题同年 React 团队推出 Create React App默认就把开发者带进了 Node.js / npm 打包 本地 Dev Server 的流水线。2017 年之后tree-shaking、code splitting 等优化在打包器中成为标配npm v5 引入 package-lock.json 落实可复现安装传统的 Bower 在 2017 年明确给出迁移指引可以视为旧式前端包管理的谢幕。2020 年Vite 以原生 ES Modules 的开发服务器思路让即时启动、极速热更新成为新基线标志着现代前端工具从「重打包」走向「按需转译 轻打包」的新阶段。以上啰里啰嗦说了这么多最后一句话所有这些都和 SAP WebIDE 无缘它压根也无法跟上 npm 与 Node.js 主导的前端迭代节奏。因此SAP 才会推出基于Eclipse Theia 这个开源 IDE 框架对多云环境开发范式支持更好更开放的 Business Application Studio.架构基座的升级基于行业主流开源的云端 IDESAP Business Application Studio 的底层技术路线采用了以 Eclipse Theia 为代表的开源 IDE 框架带来与 Visual Studio Code 相似的交互范式与强扩展性。由此即使是原本来自 SAP 生态圈之外的开发者其熟悉的工程与插件生态也可以轻松自然延展到 SAP Business Application Studio而不必被 SAP WebIDE 封闭的「私有插件体系」所束缚。下图展示的是 SAP Business Application Studio 里可以根据实际项目需要轻松安装生态圈丰富的各种扩展一键扩展器功能。面向多云的开发空间、一键即配、内置终端与 GitSAP Business Application Studio 引入了 Dev Space 的概念即按场景预置工具链与运行时例如 SAP Fiori elements、移动开发、工作流等带来「开箱即用但可按需扩展」的体验。每个 Dev Space 都包含集成终端、Git、问题视图、命令面板等现代 IDE 的标配能力既满足可视化也不牺牲脚本化与自动化。Fiori tools 原生整合丰富的模板、建模器、引导式开发与适配项目BAS 对 SAP Fiori tools 做了深度集成包括向导式创建、页面建模器、引导式开发、模拟与部署管线等并在 Visual Studio Code 与 BAS 双端共同提供扩展包。这使得 Fiori elements 的最佳实践可以连同工具链一起落地显著降低团队在 OData、元数据、UI5 版本协同上的工作量。针对企业最常见的二次开发诉求BAS 还提供了基于 Adaptation Project 的应用变体开发与部署流程覆盖创建、适配编辑器、以及向 ABAP 仓库或 Cloud Foundry 的交付路径。以上 SAP Business Application Studio 对于现代前端开发工具链的原生支持以及对于 SAP Fiori 家族开发方式的深度整合等能力和 SAP WebIDE 来说就是妥妥的降维打击。是时候给 SAP Neo 和 SAP WebIDE 说 farewell 了。二者将于 2028 年 12 月 31 日终止服务。https://community.sap.com/t5/technology-blog-posts-by-sap/farewell-neo-sap-btp-multi-cloud-environment-the-deployment-environment-of/ba-p/13560080终于说到 ABAP Development Tool 了该开发工具也基于 Eclipse为什么命运和 SAPUI5 Tools for Eclipse 截然相反成功挤掉了 SAP 的亲儿子 SAPGUI 的一哥地位并且越活越滋润笔者认为最主要的原因就是二者服务的领域不同。2015 年我和组内同事聊天时曾经调侃前端开发领域也遵循「摩尔定律」即每隔 18 个月前端需要学习的新东西比之前增加一倍。大家看我前面梳理从 2009 年至今的前端开发时间线是否能感觉到前端工程领域的快速发展新的名词技术理念层出不穷。实际上我做 SAP UI5 开发那段时间看国内大厂开发工程师的技术博客心里就犯嘀咕每篇博客总有很多我没听说过的新概念新术语。而且感觉那段时间国内的前端开发生态圈很浮躁很多前端开发都以争先使用最新的工具和技术为荣仿佛这样就能证明自己在开发领域的价值。而 SAP 后端开发特别是 ABAP 这块远远没有前端那么卷。ABAP 作为 SAP 主力的后端开发语言其服务端编译与对象生命周期始终在 ABAP 应用服务器之内走的是一条和 Node.js 截然不同的发展道路也就牢牢保持了自己的特色其发展更不会被 Node.js 生态所影响。在很长一段时间里SAPGUI 是 ABAP 开发者的日常入口SE80、SE11、SE38 的蓝底灰框承载了全球无数 SAP 客户信息系统的构建与演进。SAPGUI 作为一个基于专有协议与传统客户端技术的经典 IDE其通信内核建立在 NI 与 DIAG 协议之上这是 SAP ABAP 服务器经典三层架构里连接表示层与应用层的专有通道默认以 TCP 承载、以压缩为主而非默认加密运维上通常还要借助 SAProuter 与特定端口开放。https://help.sap.com/docs/ABAP_PLATFORM_NEW/e245703406684d8a81812f4c6334eb2f/486ca3b66c0707dce10000000a42189d.html这套封闭的技术体系对企业内网非常友好但对跨互联网的云网隔离、零信任与标准 HTTP(S) 网关并不天然贴合。SAPGUI 作为 Rich Client 的代表不可避免的深度依赖本地操作系统控件。例如 SAP GUI for Windows 使用 Microsoft Controls 技术本机注册控件、集成本地浏览器控件。这种模式在跨平台开发场景下有天然的局限性即便有 SAP GUI for Java、SAP GUI for HTML 作为补充功能与一致性也存在差异与限制。https://help.sap.com/docs/sap_gui_for_windows/1ebe3120fd734f67afc57b979c3e2d46/78cb9f653b1c465c9f1b7009c515c94e.html经典的 ABAP 开发围绕 SE80 里的 ABAP 对象展开ABAP 报表、Function Group 和 Function Module、透明表、ABAP 数据字典、ABAP 类ABAP Webdynpro / BSP 应用等等。这些 ABAP 开发对象与 SAPGUI 的 SE80/SE11/SE38 深度绑定。进入云开发时代ABAP 开发模型迁移到 ABAP Cloud RAP用 CDS 建模、用 Behavior Definition/Implementation 定义事务语义、用 Service Definition/Binding 暴露服务、用 IAM 与 Restriction Type 做访问控制、用 ATC 做质量门禁。而这些核心开发对象的创建与维护都选择了 ABAP Development Tool 作为唯一入口。ADT 的架构是 Eclipse 客户端通过 HTTP(S) 访问后端 ICF 服务 /sap/bc/adt所有开发对象的创建、编辑、激活、链接跳转都走标准 Web 通路甚至可以直接分享一个开发对象的 HTTP 链接给同事在浏览器渲染其元数据。这种通路天生适配云端 WAF、反向代理与标准证书体系也便于统一接入与审计。从网络协议与客户端形态两端看ADT 与 SAPGUI 已经走上了两条截然不同的岔路ADT 拥抱标准 HTTP(S) 与 Eclipse 生态而 SAPGUI 固守私有协议与 Rich 客户端。笔者认为二者并不存在孰优孰劣之说而是适配对象服务领域不同。在我心中SAPGUI 就是传统 ERP 时代的生产力工具ADT 则是面向多云与 ABAP Cloud 的基础开发设施。值得一提的是ADT 并非一夜之间上位它和 SAPGUI 的 PK 持续了很长时间。在 ABAP NetWeaver 后期SAP 就开始把现代 ABAP 语言的诸多特性迁移到 Eclipse例如更强的代码导航、重构、ABAP Doc 文档、单元测试、ATC 集成、HANA 对象集成等。笔者清楚地记得2012 年时我还在做 SAP CRM 的标准开发当时 ADT 还只是 SAP 一个内部项目名叫 「ABAP in Eclipse」简称 AIE.笔者也算是 SAP 成都最早试用 ADT 的开发者之一当时只觉得很新鲜原来 ABAP 还能在 Eclipse 里编写但也仅仅是试用因为多年养成的 SAPGUI 使用习惯很难习惯 ADT 那种 Eclipse 式的使用风格。后来 2015 年去 SAP 德国总部出差见到了 ADT 的开发团队和团队的很多同事闲聊了很久。对方得知我正式开发中不用 ADT 后怂了怂肩然后问我为啥不用。我回答「ABAP 老司机根深蒂固的使用习惯」后他们也点头承认说ADT 对于德国刚毕业入职的大学生来说更具吸引力因为他们还是白纸一张没有被 SAPGUI 所洗脑。如果说此时 SAPGUI 和 ADT 还地位相当开发者可以二选一的话那么随着 S/4HANA Cloud 与 BTP ABAP environment 上线ABAP Cloud 成为规范开发模型RAP 成为事务型应用的核心Clean Core 成为企业级可升级性的治理原则此时 ADT 已经不再只是和 SAPGUI 相提并论的 ABAP 代码编辑器而是云时代 ABAP 「唯一的」基础开发设施与合规工具链入口。ABAP Cloud 是在 BTP ABAP environment 与 S/4HANA 上统一的开发模型目标就是云就绪与升级稳定而 ADT 就是让这一开发模型落地的唯一工具。ADT 在 HANA 对象集成、OData 服务生成、Fiori 元数据驱动开发方面提供了大量向导与视图切实提高了 ABAP 开发者的生产率。另一方面SAP BTP 的多云战略决定了平台落地在多家 Hyperscaler 上开发、运维、服务绑定、证书与接入管理都以标准 HTTP(S) 与平台控制面为核心ADT 与之匹配。云时代提倡 ATC 质量门禁、单元测试覆盖、Git 流程、CI/CD 等理念。这些理念如今在 ADT 里均由了完善成熟的实现ATC 集成、ABAP Unit 一键运行与覆盖率、abapGit for ADT 插件、gCTS 与管道集成。这一切的一切 SAPGUI 都无法做到。一句话SAPGUI 并没有做错什么只是时代变了。