1. 一个点击背后的“语法”为什么Fiori的导航不写成普通URL刚接触SAP Fiori的顾问总会在某一天盯着浏览器地址栏发出灵魂拷问https://myhost:44300/sap/bc/ui2/flp#Employee-display?EmployeeID1000001前面半截/sap/bc/ui2/flp还好理解后面这个#Employee-display是什么鬼没有路径、没有页面名连个.html都看不到。更让人费解的是点击不同的磁贴URL前半部分完全一样变的只有#后面的内容。这就是SAP Fiori中Intent-based Navigation基于意图的导航的外在表现。它和传统的三层架构Web应用完全不是一个思路。传统Web应用里URL表达的是“资源的位置”比如/user/detail.jsp?id1000001服务器拿到这个地址就知道要渲染哪个页面、查哪条数据。而Fiori的Intent导航表达的是“用户想做什么”——Employee-display翻译过来就是“我想看员工”至于具体由哪个应用来处理这个意图、显示哪个界面那是启动板Fiori Launchpad的事。这个设计理念在Fiori体系里极其重要。它把“导航请求”和“目标应用”彻底解耦了。应用A要跳转到某个员工详情不需要写死“跳到应用X的第3个标签页”只需要说“我要display一个Employee参数是1000001”系统会自动找到注册了Employee-display这个Intent的应用把这个请求交给它。将来你换了底层的UI应用、重写了界面只要Intent不变所有调用方都不用改。所以说理解Intent-based Navigation不是“学会拼一个URL”这么简单它是理解整个Fiori架构如何支撑跨应用体验、如何让应用之间像积木一样自由组合的钥匙。这篇文章我就从#Employee-display这个最常见的Intent出发把语法结构、底层机制、跨应用跳转的完整玩法、以及我实际项目里踩过的那些坑一次性讲透。适合谁来读如果你是Fiori实施顾问、ABAP技术顾问、或者正在做S/4HANA系统集成需要从外部系统跳转到Fiori应用的开发这篇值得你从头看到尾。就算你刚入行Fiori只要理解了我说的几个关键点至少能少走一个月弯路。2. 拆解 #Employee-display语义对象、动作与导航参数2.1 一段Hash背后隐藏的三个要素Intent-based Navigation的URL结构其实远没有它的命名那么高深。以#Employee-display?EmployeeID1000001为例整个#后面的内容可以拆成三部分# Employee - display ? EmployeeID 1000001 ├─语义对象 ├─动作 ├─导航参数 (Semantic Object) (Action)语义对象Semantic Object描述的是“业务对象是什么”动作Action描述的是“要对这个对象做什么”导航参数则是这次业务操作需要携带的输入条件。在这个例子里Employee是语义对象display是动作合在一起构成一个完整的Intent。注意Hash后面、?之前语义对象和动作之间用的是连字符-不是斜杠/这一点很多人第一次看Fiori URL时都会懵。为什么不是#/Employee/display这样符合直觉的路径格式因为FLP的URL空间里#/被保留给了应用内部路由。如果intent写成#/Employee-display启动板会把后面这串当作用户打开某个特定应用的内部路由通常结果就是白屏或“应用未找到”。导航参数部分则是标准的键值对。多个参数用连接#Employee-display?EmployeeID1000001CompanyCode1010这一整套东西就是Intent在URL层面的完整语法。2.2 语义对象和动作的命名逻辑语义对象看起来像英文单词但它的设计是有讲究的。它不应该是一个页面名称、一个应用代号而是业务领域里一个真实存在的业务对象。比如Employee员工SalesOrder销售订单Material物料PurchaseRequisition采购申请CostCenter成本中心动作则更像是“业务操作”的抽象。常见的动作有display查看详情/显示列表manage管理通常指列表增删改查create新建approve审批print打印组合起来Material-display、SalesOrder-manage、CostCenter-approve一看就知道用户在干嘛。你会发现这套命名逻辑非常接近自然语言。这不只是为了好看而是Fiori设计哲学的一种体现导航URL对运维人员、对监控平台、对集成开发都应该具备可读性。你看到一条#PurchaseRequisition-approve?RequisitionNo4500000123的链接哪怕没打开过这个界面也能猜到用户在做“采购申请审批”。2.3 参数不是“页面参数”而是“业务输入”在传统Web开发里URL参数通常带着一堆页面状态和查询条件。但Fiori Intent里的导航参数应该尽量保持“业务纯度”。什么意思就是说如果你要展示一个具体的员工参数给EmployeeID就够了不要试图通过参数传递“当前列表的排序方式”“表格滚动到第几行”“筛选器选了什么值”这类UI状态。原因有二第一URL会落在浏览器历史记录、访问日志乃至监控系统里带太多无关信息既暴露用户操作细节又造成噪音。第二Intent的设计初衷是让接收方能够“独立完成一项业务任务”。它应当携带的是让目标应用可以直接定位业务对象的业务Key而不是执行上下文。你把UI状态塞进去等于强迫目标应用理解来源应用的内部数据结构跨应用之间的耦合度瞬间就上去了。我自己的惯例是只传能唯一定位业务对象的关键字段最多再带一个来源标识比如从哪里跳过来的。多了不放。2.4 FLP在这里面扮演的角色#Employee-display到了Fiori Launchpad那里FLP做的事实际上是一次“意图路由”解析出语义对象Employee、动作display然后在配置库里面找出所有注册了Employee-display这个Intent的Tiled应用。这里有个关键机制一个Intent可以被多个应用注册。比如标准应用和一个客户自研应用都声明了自己能处理Employee-displayFLP里就有两个不同的Tiled对应同一个Intent。用户在启动板上看到的可能是两个不同的磁贴但URL是一样的。这对调用方是透明的——调用方不需要知道最终落到哪个应用这是FLP在背后完成的“应用解析”。反过来一个应用也可以注册多个Intent。比如员工明细页可能同时注册Employee-display和Employee-show两个入口或者把不同状态的员工跳转到不同页面。这在把老的SAP GUI事务改造为Fiori应用时非常常见。理解了这个路由模型你就能理解为什么说Intent-based Navigation不是简单的前端Hash变化——它背后是一套完整的“请求-解析-匹配-分发”链路。3. 构造和调试Intent URL从URLHelper到外部系统跳转3.1 在代码里生成Intent URL用URLHelper而不是手工拼讲完了语法我们来点能直接落地的。在Fiori/UI5前端代码里如果你需要从一个应用跳转到另一个应用最忌讳的写法就是自己拿字符串拼URL// 不推荐手工拼接容易漏编码、写错格式 var sUrl https://host/sap/bc/ui2/flp#Employee-display?EmployeeID oEmployeeId;正确的做法是走SAP官方提供的统一API——URLHelper。它属于sap.ushell.services命名空间是FLP shell环境下专门用来生成Intent URL的工具。var oURLHelper sap.ushell.services.URLHelper.getInstance(); var sUrl oURLHelper.getUrlForIntent(Employee, display, { EmployeeID: 1000001, CompanyCode: 1010 }); // 然后跳转 window.location.href sUrl;调用getUrlForIntent时你只需要传语义对象、动作和一个参数对象它会在内部帮你完成编码、拼装、加上正确的FLP前缀。为什么必须用它有两个理由第一URLHelper知道当前系统的FLP入口地址不需要你硬编码/sap/bc/ui2/flp这一大段。将来系统前端路径调整、网关地址变化你的代码不用跟着改。第二参数值中的特殊字符会自动编码。比如员工姓名里带个、ID里带个#你手工拼接出来的URL直接就是错的而URLHelper会转成%26、%23这种合法形式。这个坑我后面还会细说。如果你的应用跑在旧版本SAPUI5上找不到sap.ushell.services.URLHelper也可以走老的CrossApplicationNavigation服务原理一样var oCrossAppNav sap.ushell.Container.getService(CrossApplicationNavigation); var oUrl oCrossAppNav.hrefForExternal({ target: { semanticObject: Employee, action: display }, params: { EmployeeID: 1000001 } });不过在当前的SAPUI5版本里URLHelper是更主流的方式新代码优先用这个。3.2 从外部系统跳转手动拼接完整URL如果说在Fiori应用内部跳转推荐用API那么从非Fiori系统跳进来就只能手工拼URL了。典型的场景包括外部HR门户跳转到S/4HANA员工详情、报表工具里的超链接、或者SharePoint页面上放一个”查看SAP单据“的按钮。这时候你需要一个可以被外部访问的完整FLP入口https://host:port/sap/bc/ui2/flp#Employee-display?EmployeeID1000001如果系统配置了Web Dispatcher或反向代理域名改成外部可访问的域名https://flp.example.com/sap/bc/ui2/flp#Employee-display?EmployeeID1000001有几个细节要单独提醒客户端client问题。大多数SAP系统是有多客户端的。如果你不指定?sap-client100用户会默认落到系统默认客户端。稳妥的做法是把client参数也拼上去https://flp.example.com/sap/bc/ui2/flp?sap-client100#Employee-display?EmployeeID1000001注意client参数放在Hash之前作为查询参数而Intent自己的导航参数放在Hash之后。这两段别搞混了。放在Hash后面的sap-client很多时候也能生效但放在前面更符合FLP自己生成URL的惯例。参数编码问题。外部系统拼URL时参数里的特殊字符必须做URL编码。比如你想按员工姓名跳转而姓名是Brown Sons你需要把编码成%26否则FLP会认为这是一个新的参数分隔符把URL的语义完全改变。类似的中文、空格、#、?都建议通过encodeURIComponent一类的函数处理一遍。3.3 用浏览器直接调试Intent URL一个非常实用的经验在开发环境里你完全不需要每次都在FLP里点磁贴来测试导航。直接在浏览器地址栏输入完整的Intent URL回车就能看到效果。调试时有一些技巧先在FLP里正常点击一次目标磁贴确认能进入目标应用复制当时的URL作为baseline。然后手动修改#后面的Intent部分用这种方法测试不同的参数组合。如果跳转结果不符合预期按F12打开浏览器开发者工具在Console里看有没有CrossApplicationNavigation相关的报错。有一点要注意如果在浏览器地址栏直接输入FLP URL你的登录会话Logon Ticket / SAML断言可能不会被自动携带——这取决于系统的认证配置。如果遇到打开FLP后没登录或跳到登录页说明外部直接访问时的认证流程还没配置好这是另一个层面的问题跟Intent导航本身无关。3.4 多样的导航媒介在实际项目中“跳转”不一定都是当前标签页整体刷新。常见的有三种同一标签页整体跳转window.location.href url用户感觉是在“切换应用”。FLP会把这个新应用压入导航栈用户依然能通过FLP的返回按钮回到上一个应用。新标签页打开window.open(url, _blank)。适合“需要在不同系统间对比查看”的场景比如从员工列表同时打开两个人的详情做对比。代价是用户可能会忘记关标签页导致导航栈不可预期。弹出对话框内嵌Fiori里也有用Dialog内嵌一个外部Intent的方式比如在审批界面直接预览物料主数据。实现上会用到sap.m.Dialog的content加载一个IFrame或者用FLP的AppViewer控件。这种方式最适合“需要用户做完主流程、只看一眼辅助信息”的场景。三种方式没有绝对的对错关键看业务场景对操作连续性的要求。我的经验是默认用同一标签页跳转只有在用户需要同时参照两个应用时才开新标签页。弹窗内嵌要考虑的内容更复杂安全、性能、布局谨慎使用。4. 从一个列表到组织架构跨应用导航的完整业务场景4.1 场景设计员工主数据相关的多个应用为了讲清楚跨应用导航的实际动作我设计一个连贯的业务场景。假设公司S/4HANA环境上有这么几个Fiori应用应用语义对象动作说明了什么员工清单自研List ReportEmployeedisplay显示员工列表员工详情自研Object PageEmployeeshow展示单个员工详细资料组织架构图标准/自研Organizationdisplay展示组织单元和上级人员调动审批自研Employeeapprove发起/执行调动审批用户从启动板点击“员工清单”磁贴走的Intent是Employee-display。这一步是最基础的“磁贴到应用”的导航连代码都不用写——磁贴自带的Intent配置就完成了。4.2 从列表进入详情同一语义对象、不同动作的切换用户看到员工列表后需要点击某个员工查看完整档案。此时员工详情页是一个独立的应用或者严格说是独立的路由我们要从“列表应用”跳到“详情应用”。我建议的写法是仍然用URLHelper生成目标Intent// 列表行点击事件 /数字 onRowPress: function(oEvent) { var oCtx oEvent.getSource().getBindingContext(); var sEmployeeId oCtx.getProperty(EmployeeID); var oURLHelper sap.ushell.services.URLHelper.getInstance(); var sUrl oURLHelper.getUrlForIntent(Employee, show, { EmployeeID: sEmployeeId }); window.location.href sUrl; }这里有一个很多人第一次接触时会困惑的点同样是“看员工”列表和详情为什么要用不同的动作displayvsshow直接都用display不行吗在设计上display通常对应“打开对象集合的浏览界面”show对应“打开单个对象的详情界面”。一个Intent应该让目标应用明确知道用户处于哪一层业务语义。如果都用display,FLP在匹配多个注册应用时可能撞车——尤其当列表和详情恰好注册了同一个Intent时系统不知道你要去哪个应用。用不同的动作区分开路由逻辑会干净很多。目标应用员工详情如何拿到EmployeeID呢如果你的详情应用是Fiori Elements的Object Page通常在manifest.json的crossNavigation.inbound里声明参数映射框架自动完成。如果是自由式UI5应用则在Component的Controller里读取onInit: function() { var oComponent this.getOwnerComponent(); var oStartupParams oComponent.getComponentData().startupParameters; if (oStartupParams oStartupParams.EmployeeID) { // startupParameters 里每个参数都是一个数组 this._sEmployeeId oStartupParams.EmployeeID[0]; } }如果startupParameters拿到的是undefined十有八九是manifest.json里没有配置inbound的参数声明或者FLP磁贴配置的Intent里根本没带这个参数。4.3 员工详情跳转到组织架构跨应用的真正考验再看一个更有代表性的场景用户在看员工详情这样一个价值场景让你“点击”查看其在组织中的位置。从业务上讲从员工详情跳到组织架构需要做两件事一是把当前员工的直属主管或所属组织单元传给目标应用二是目标应用Organization-display要能识别这些参数并直接定位。跳转端代码依然简单var sManagerId oCtx.getProperty(ManagerEmployeeID); var sUrl oURLHelper.getUrlForIntent(Organization, display, { ManagerID: sManagerId }); window.location.href sUrl;但这里暴露了一个跨应用导航中绕不开的问题你传过去的参数目标应用认不认识ManagerID这个名字是我在源应用里定义的但组织架构应用接收的参数也叫ManagerID吗这就需要在目标应用的manifest.jsoncrossNavigation.inbound参数声明中保持一致。例如sap.app: { crossNavigation: { inbound: { orgDisplay: { semanticObject: Organization, action: display, parameters: { ManagerID: { type: string, required: true } } } } } }如果目标应用只声明了OrgUnitID而你传了ManagerID那这个参数就会被丢弃用户打开的是一个空空如也的组织架构页。这种问题排查起来往往很隐蔽——代码没报错就是效果不对。所以这里有必要引出团队协作层面的一个习惯每个应用在开发跨应用跳转之前先核对目标应用对外开放的Intent清单确认参数名和参数含义。这个核对动作不是可选的。4.4 从外部系统发起Intent一个真实的外部集成示例假设公司的人事系统非SAP要在“员工离职办理”的流程页面里放一个按钮“在S/4HANA中查看该员工”点击后要直达Fiori的员工详情。外部系统侧的逻辑通常就是这样一段拼URL的代码以Java为例String baseUrl https://flp.example.com/sap/bc/ui2/flp; String intent #Employee-show?EmployeeID URLEncoder.encode(employeeId, UTF-8); String url baseUrl ?sap-client100 intent; // 输出: // https://flp.example.com/sap/bc/ui2/flp?sap-client100#Employee-show?EmployeeID1000001这里最需要注意的是字段映射关系。人事系统里的employeeId可能对应S/4HANA的EmployeeID也可能对应PersonnelNumber还可能要转换一下比如前面补0。这个转换往往不是纯前端处理而是通过一个中间服务OData/API在拼URL之前把工号翻译成SAP内部的员工UUID或人员编号。别把两个系统里同名但含义不同的字段当成同一个这是外部集成里最容易翻车的地方。4.5 返回逻辑怎么处理跨应用跳转多了就必然会面对返回导航的问题。用户从员工列表 → 员工详情 → 组织架构然后点返回他会回到哪里在FLP里如果是同一标签页内的跳转导航栈会记住“进入当前应用之前的上一个Intent”。用户点FLP自带的返回按钮通常会回到列表页。但有一个例外如果用户是从外部URL直接进入组织架构应用的没有上一个FLP应用返回按钮可能直接回到FLP首页或者变成一个刷新按钮。这一点在做跨应用体验设计时要想清楚。我见过不少项目功能链路很完善但跳着跳着用户就“回不去了”体验断崖式下跌。一个经验是在跳转前明确用户的“回退预期”。如果这是一条单向链路比如外部系统跳进来就不必纠结返回按钮行为如果是在Fiori内部的多跳链路尽量依赖FLP导航栈避免在新标签页里跳来跳去把返回栈搞乱。5. 踩坑实录五类最常见的Intent导航问题与排查顺序5.1 Hash后面多了一个斜杠白屏的罪魁祸首第一个坑也是最常见的坑。很多人第一次拼Intent URL时习惯性地写成https://host/sap/bc/ui2/flp#/Employee-display?EmployeeID1000001注意#和Employee之间多了一个/。这个URL在FLP里的解析结果是完全不同的FLP会认为你要导航到某个应用内部的/Employee-display路由而不是一个Intent。结果通常是页面空白、报“应用未找到”、或者进入一个完全不对的界面。排查方法非常简单复制地址栏URL对比一下当前要打开的Intent确认#后面直接就是语义对象语义对象和动作之间是-。这个细节真的值得反复强调因为不管是我带的开发还是我自己都曾经在这上面浪费过时间。5.2 参数值里的特殊字符没编码第二个坑隐藏在业务数据里。比如员工姓名是Brown Sons你在外部系统拼URLhttps://host/sap/bc/ui2/flp#Employee-show?EmployeeNameBrown Sons系统按拆参数最终收到的是EmployeeNameBrown和Sons两个字段后者因为没有直接被忽略或报错。数据显示不出来的同时你还可能把客户端、会话参数搞乱。解决方式无非是在拼URL前对参数值做一次完整的URL编码。前端JS用encodeURIComponentJava用URLEncoder.encode其他语言也都有对应标准库。唯一要注意的是编码的时机要对参数值单独编码而不是对整个URL一股脑编码否则#、?、这些URL结构字符也会被转掉整个URL就废了。5.3 大小写不匹配语义对象和动作是区分大小写的。我在一个项目里遇到过FLP磁贴配置的语义对象是PurchaseOrder但开发在代码里写的是Purchaseorder跳转后FLP压根找不到匹配的应用。因为语义对象的匹配是精确匹配大小写不一致等于完全不同的字符串。这个问题排查起来特别隐蔽因为很多时候你看到的URL格式是对的、参数是对的唯独大小写差了一个字母。建议在写Intent的时候先到FLP的磁贴配置里去复制原始值而不是凭记忆手敲。5.4 目标应用没有注册对应的inbound第三个坑更隐蔽。假设你的目标应用确实是一个合法的Fiori应用在FLP里也有磁贴。但它的manifest.json里crossNavigation.inbound只声明了Employee-display没有声明Employee-show。这时候你用Employee-show?EmployeeIDxxx去跳转会发生什么结果是FLP能找到Intent的语义对象但找不到有权限处理这个“语义对象动作”组合的应用。通常表现为页面提示“未找到应用”或“无法完成请求”但你在FLP里明明看到过这个应用。这种问题的根因是“有界面”不等于“有开放Intent入口”。应用对外开放的Intent必须显式声明而且要在FLP配置中得到认可。排查思路是打开目标应用的manifest.json确认inbound列表里有没有对应的semanticObjectaction再去FLP的磁贴属性里看它绑定的Intent是否一致。5.5 客户端和认证相关的坑最后一个坑属于环境配置。外部系统拼好了一个完整Intent URL用户点开后要么没登录跳到了登录页要么进了错误的客户端。客户端问题通常在URL上加sap-client100能解决。但要注意有些环境里client参数的正确位置在#之前的查询串有些环境在#之后也能生效还有的环境两端都可以。稳妥起见按FLP自己生成的习惯来——放在#之前的查询串里。认证问题需要分情况。如果FLP和外部系统在同一个SSO域里浏览器会自动携带会话票据直接打开没问题。如果不通你又不想每次都让用户额外登录一次那得单独配置Trusted RFC、SAML或反向代理层面的单点登录。这块内容本身能单独写几篇文章了这里先提个醒别把认证问题误判为Intent配置问题。5.6 一套高效的排查顺序如果你遇到Intent导航异常我建议按下面的顺序排查不要在Config和代码之间来回瞎找先用一个最简单的URL直接访问排除参数影响。比如只保留#Employee-display不带任何参数。如果还是进不去问题大概率在Intent定义或环境层面。检查Hash格式特别注意#后面有没有多余的/、-还是_。检查语义对象和动作的大小写跟FLP磁贴配置逐字对比。带参数再访问一次。这次重点看目标应用有没有收到参数。在Controller里打个断点或者console.log一下startupParameters。查看浏览器Network和Console确认没有跨域、404、会话过期之类的低级问题。最后检查目标应用manifest.json的inbound声明确认Intent与FLP磁贴配置完全匹配。这套链路基本能覆盖我遇到过的95%以上的问题。6. 给新项目定一套“导航语言”命名、参数与维护习惯6.1 语义对象的命名要像建数据模型那样认真很多项目一开始兴致勃勃做跨应用跳转等应用多起来以后最痛苦的居然是当时拍脑袋定的语义对象名。比如有的团队用中文拼音当语义对象结果外国顾问看着一头雾水有的把应用名当语义对象比如FioriEmployeeList将来应用重写、改名整个调用链都得跟着崩还有的团队把动作定义得极其随意一个display既能打开列表又能打开详情时间长了根本不敢动FLP配置因为一改就全乱。我比较推荐的做法是参考SAP Fiori Apps Reference Library的命名习惯来定自己的Semantic Object使用业务领域通行的英文名词尽量和CDS视图、后端表格的语义保持一致。用单数形式Employee而不是Employees。动作词尽量收敛在一个小的集合里比如display、show、manage、create、approve。如果一个动作出现“既可以A也可以B”的情况拆分动作哪怕新增一个displayOverview也不要让原有动作语义膨胀。6.2 参数设计坚持最小化与类型清晰参数是Intent的输入接口接口越清晰跨应用协作成本越低。我在设计时一般遵循三条铁律只传业务Key不传UI状态。比如要展示一张销售订单传SalesOrderID就够了。排序、筛选、展开状态这些目标应用自己根据业务规则确定或者提供默认值。参数类型尽量简单。字符串、数字、日期都是URL参数能承载的。不要试图传JSON结构、数组、或者大段文本。如果真的需要复杂结构改成传一个后台临时存储的会话ID目标应用拿ID去后端读取真正的内容。参数名要跟业务对象属性名一致。员工ID就叫EmployeeID不要在这里叫staffId、那里叫personNumber。建立一份参数命名对照表新开发先查表再定名。6.3 维护一份“Intent注册表”到了这一步要说一个项目级的经验。一个成熟一点的Fiori项目里应用数量少则十几个多则上百。如果不维护一个统一的Intent清单会出现什么局面A应用和B应用都定义了一个Employee-display但参数集S不同C应用跳转时照着A的参数写却发给了B应用过了半年B应用重命名了参数D应用还在用老参数默默报错。所以我强烈建议在项目启动阶段就建立一份Intent注册表至少包含以下字段字段示例Semantic ObjectEmployeeActionshow业务描述打开单个员工详情参数及类型EmployeeID: string (required)默认处理应用员工详情应用App ID是否有其他应用竞争该Intent无维护联系人XXX这个表不需要做成多复杂的系统一张共享Wiki表格就够了。关键是团队要形成一个习惯任何应用对外开放Intent之前先注册再开发最后在FLP里挂磁贴。只要这个顺序不颠倒跨应用导航的混乱局面基本不会出现。6.4 回头看Intent-based Navigation对项目的真实价值把这一套东西想透了以后你会意识到Intent-based Navigation不仅是Fiori的一个技术特性更是一种架构习惯。它逼着你在做应用设计的时候去思考这个应用在业务世界里到底服务哪个对象它向外提供哪些能力别的应用怎么称呼它这些问题想清楚应用之间互相调用的边界就会自然清晰。反过来说如果跳过一个应用的Intent设计直接写页面路由短期内开发速度可能更快但等应用多起来每一个“快速方案”都会变成后续维护的债。所以我的个人体会是第一次接触Fiori的人可以先把Intent-based Navigation当成一个拼URL的规则来学但真正把一个大型项目交付下来你应该把它当成一套应用之间的“通信协议”来敬畏。协议定得好不好决定的是项目后半程所有人加班少加班的差别。最后再分享一个小技巧在项目早期把测试环境里所有应用的Intent URL收集起来按语义对象归档共享给整个团队。新人上手时让他们从这些URL出发去熟悉每个应用比从ADMIN菜单一项项点高效得多。我后来带的每一个Fiori项目都是从这份URL清单开始的。