1. 为什么“分享应用”和“书签 Tile”总被当成两个孤立功能在 SAP Fiori launchpad 里，“分享应用”和“创建书签 Tile”这两个入口，绝大多数用户其实都点过，但很少有人会认真想它们之间到底是什么关系。我自己最早接触这个场景，是被业务部门一个很具体的问题逼出来的：财务团队每天早晨打开系统，第一件事就是进入某张报表，把公司代码、利润中心、期间三个筛选条件重新选一遍，再看结果。这个过程大概要花两分钟，但他们有五个人，每天就是十到十五分钟的重复劳动。当时有人提出来说，能不能让系统记住筛选条件？答案是可以，而且 SAP Fiori launchpad 本来就有这个能力，只是入口藏得比较深。真正把我引到“把一次筛选变成团队共识”这个思路上的，是后来我发现“共享应用”按钮和“书签 Tile”这两个看似独立的功能，其实组合在一起，就是一套从个人效率到团队协作的完整闭环。先说“共享应用”按钮。Fiori launchpad 的应用页右上角，通常在用户头像下拉菜单或者应用卡片菜单里，有一个“Share”或“分享”入口。点开之后会出现几个选项，其中最常用的有两种：一种是通过邮件发送一个指向该应用的链接，另一种是复制当前应用的当前状态链接。注意“当前状态”这四个字，它意味着你分享的不只是应用本身，还包括你当前打开这个应用时带入的参数。换句话说，如果我在我的界面上把报表跑成了“公司代码 1000，利润中心 P001，期间 2025.01”，我复制出来的这个链接，别人点开时看到的直接就是同一个筛选状态下的数据。而“创建书签 Tile”的逻辑也非常相似。它做的是把当前应用连同当前状态一起钉回到 launchpad 的某一个分组里，生成一个新的 Tile。这个 Tile 的标题可以自定义，比如“月度利润中心快查”之类的。之后任何人只要点击这个 Tile，就会直接进入你保存的那个筛选状态。看到这里你就明白了：两者本质上都在做同一件事——把“一次操作后的应用状态”变成一个可以被反复访问的入口。区别只是承载方式不同，一个是链接，一个是 Tile。如果我们把“分享链接”发给团队，再把“书签 Tile”挂到公共分组里，那效果就完全不一样了。团队不需要知道筛选条件怎么选、不需要打开应用后再点几下，只需要点一个入口，就进入了大家约定好的那个视角。这就是标题里说的，把一次筛选，变成团队的共识入口。这篇文章我主要想聊三件事：第一，哪些 Fiori 应用可以走“分享当前状态”这条路，哪些不能，边界在哪里；第二，创建书签 Tile 需要什么样的前置条件，有哪些坑是配置的时候特别容易踩的；第三，从管理员或者超级用户的角度，怎么把这两个功能组合起来，做成业务团队真正愿意每天都用的入口。内容偏向实操，所有步骤我都按最常见的 SAP Fiori launchpad 版本（以 SAP S/4HANA 搭配 Fiori Frontend Server 的常规配置为准）来写，个别菜单名称在不同版本里可能略有差异，各位对照自己的环境微调即可。2. 分享功能先搞清楚：可共享的链接是什么、能做多少定制2.1 “共享链接”背后的原理：不是所有分享都是“当前状态”Fiori 应用为什么能做到“把当前状态分享出去”？这要归结到 SAP Fiori 应用导航机制里一个叫“Intent”的概念。Intent 由两部分组成：语义对象（Semantic Object）和动作（Action），再加上一组可选的参数（Parameters）。我拿一张报表举例，比如它的语义对象是“CostReport”，动作是“display”，参数是“companyCode=1000&profitCenter=P001”。一个完整的应用链接，其实就是把 Intent 编码进 URL 里。当你打开一个 Fiori 应用以后，应用本身会把用户的筛选操作映射到 URL 参数上。有的应用是自动映射——你改一个筛选条件，地址栏的 URL 参数就同步更新，我用 Chrome 按 F12 看网络请求的时候，经常能直接抓到完整的 Intent 参数。有的应用则是“半自动映射”——你改完条件之后，需要手动点什么按钮（一般是刷新、搜索或者一个“生成链接”的功能）才会把当前状态写回到 URL 里。还有些应用是彻底不支持的，后面我会专门讲这一类。搞清楚这个原理，你就能理解为什么“分享”出来的链接，有时候别人点了能用，有时候点了却没反应——大概率就是 URL 参数没有被正确地携带过去。2.2 Fiori launchpad 里分享入口的常规操作路径以最常见的标准 Launchpad 配置为例，分享入口的路径大致是这样的：打开目标应用，把筛选条件设置好，让界面处于你想要分享的状态。找到右上角的用户菜单或应用工具栏菜单。不同系统里位置可能有细微差别，有些版本是齿轮图标旁边的“分享”按钮，有些版本是把“分享”收进了“更多选项”（也就是那个“三个点”的图标）里。点击“Share”，菜单展开后会出来几个选项，常见的有：Share Link in E-Mail：通过邮件客户端发送链接。Copy Link：把链接复制到剪贴板。Create Tile：这一步在部分版本里也会出现在分享菜单里，点击之后就是保存书签 Tile 的入口。这里我特别强调一个小技巧：对于比较老的 Fiori 版本，如果你在应用界面里面找不到“Share”菜单，回退到 launchpad 页面，找那个应用卡片右上角的“书签/分享”图标（通常是一个类似链条或者分享箭头的图标），从那个入口一样可以操作。本质上都是调用同一个底层服务，但路径更直观。还有一个很容易被忽略的小细节：复制链接的时候，有的环境复制的是一长串带完整 Intent 的 URL，有的环境复制的是经过短地址服务加工后的短链接。短链接的好处是发邮件不臃肿，但坏处是你没法直接看出来它里面包含哪些参数，排查问题的时候很绕。如果你是在配置阶段做测试，建议优先使用“Copy Link”，然后自己放浏览器里对比一下长链接和短链接在打开时是否完全等价。2.3 哪些应用能分享“当前状态”，哪些不能分享当前状态能不能成功，核心取决于应用本身对 URL 参数的支持程度。我自己的经验可以用一个象限来划分：应用类型是否支持状态分享典型例子备注基于 SAP Fiori Elements 的列表报表/分析页绝大多数支持标准 Fiori 报表应用、带筛选条件的分析页面筛选条件自动映射到 URL 参数，分享最稳定自由开发的 Fiori App（SAPUI5 自编码）取决于开发者是否实现了参数读取逻辑自定义应用很多自开发应用压根没有“根据参数初始化界面”的逻辑，分享过去等于打开了一个空白应用传统 SAP GUI 事务的 Web 封装（例如通过 Fiori 启动 SAP GUI for HTML）基本不支持“当前状态”某些老事务代码可能支持最简单的导航参数，但复杂筛选状态不可能完整映射第三方集成的 OData 应用不一定支持通过自定义 Card 或第三方应用框架接入的页面要验证才知道对第 2、3 类应用，我不建议硬推“分享当前状态”给业务用户，否则他们会觉得这个功能不好用。更务实的做法是把这类应用包在一个“带默认参数的启动配置”里，后面我会讲到怎么通过其他手段实现类似效果。2.4 链接分享给团队的三个适用场景和两个禁忌分享链接适合什么样的场景？我按使用频率排一下：临时转达：同事问我某个报表你是不是跑出来了，让我看一眼数据。我直接把当前状态的链接发过去，对方点开就能看到同款数据，沟通效率大幅提升。跨地沟通：我和另一个城市的分公司同事对账，双方进入同一个筛选状态，讨论的就不是“你在哪儿选的这个数”，而是“你那个数有没有问题”。内部培训/带教：老员工带新人熟悉某项业务报表时，先把一个精心筛选好的链接发过去，新人打开就是正确的筛选模板，少走很多弯路。禁忌也有两个：一是不要传播包含敏感数据的深链接。如果这个链接直接指向“公司代码 1000”的数据视图，那它携带的数据范围就已经固化在 URL 里了。分享到群里或者邮件里，收件人如果权限不匹配，打开时要么报错，要么就只能看到一部分数据，容易造成误解。更稳妥的做法是先确认对方的数据权限范围和你分享的状态是一致的，再发链接。二是不要把链接当成正式的知识资产来管理。链接会过期吗？在大多数环境里不会，但如果 backend system 被刷新、OData 服务的路径发生调整，或者语义对象名称因为传输导入出了变化，那这些旧链接就会失效。你如果把它长期放在 wiki 里当唯一入口，迟早有一天会翻车。链接适合“聊天的即时引路”，长期入口还是交给书签 Tile 更靠谱。3. 创建书签 Tile 前，先确认这五个前置条件3.1 为什么同一套代码，有人能存 Tile，有人找不到入口“创建书签 Tile”这个功能，并不是所有用户所有环境都能用的。它受三个层面影响：Fiori 前端版本、应用是否启用了相关功能开关、用户是否有对应的角色权限。Fiori 前端版本层面， SAP 在标准的 Fiori launchpad 里加入“书签/分享”功能是相对早期的版本就有的事，但是真正稳定支持“自定义 Tile 保存并在下次登录后仍然存在”的体验，是在某一版之后的 Fiori foundation 上才完善的。如果你的系统还跑着非常古老的版本，某些安全策略默认是禁止用户自定义 Tile 的。功能开关层面， Fiori 前端配置里有两个跟分享相关的配置项，分别是 SAP UI5 的“enableShare”相关参数和控制“Pinning”行为的参数。如果管理员在 Fiori Launchpad Designer 或对应 catalog 里把这些行为禁掉了，用户界面上就不会出现“Create Tile”入口。这个是排查“怎么找不到入口”的时候第一个要查的方向。用户权限层面，标准角色模板里通常会包含“SAp_UI_FLEX”相关的权限对象，这个权限对象控制的是界面的“灵活性”修改，书签 Tile 本质上也属于一种用户界面调整的一部分。如果权限配置得太严，用户只能浏览、不能自定义任何 UI，那书签保存也会一并被禁掉。3.2 官方支持的范围从哪里确认因为在 SAP 生态里，“配置是否正确”最终要看激活的 UI technology 版本。最直接的确认方法，是打开应用之后，F12 打开浏览器开发者工具，在 Console 里看有无报错，或者在 Network 里看“/sap/bc/ui2/...”相关的请求是否正常返回。凡是“书签保存”能正常工作，系统一定会有一个“个人化数据持久化”的接口被调用，比较典型的是“sap/ushell/repository”开头的请求或者“personalization”相关的服务。如果发现这个请求返回 404 或者 401，那就说明当前环境根本没有激活个人化数据持久化后端。这时候不是在 launchpad 层面能解决的问题，需要你的 Basis 或者实施团队的顾问去检查前端的 web.xml 和 ICM 配置里是否挂载了对应服务。3.3 后端联动：OData 注释和语义对象名称必须干净还有一个经常被忽略但真实存在的前置条件：Tile 创建之后，点击它能否正确打开应用，取决于语义对象和动作的名称是否与应用 catalog 里注册的 target mapping 完全匹配。如果当初应用配置时有多个 target mapping 或同语义对象有多个 action，系统会弹出一个选择对话框，或者直接进入默认配置。这种“多对一”的情况会让书签 Tile 的体验变得很分裂。从实践角度，我给自己定了一条规矩：生产环境做书签 Tile 之前，先把应用的 Target Mapping 查一遍，确认 Intent 是唯一可解析的。如果发现同一个 Semantic Object + Action 被映射到了多个 Target 上，先让配置管理员清理干净，再去保存书签。不然你存下来的 Tile，过两天点开可能打开的是一个完全不相干的页面。3.4 版本差异：Chapter UI2 的“旧版个人化”与新版行为差异如果你们用的是很老的 Gateway 版本，书签 Tile 的持久化机制和现在的版本是不同的。老版本里，用户的个人化数据是存在用户主数据表里（比如 A 表和 B 表里面），新版本是走统一的前端个人化后端服务。如果你负责维护的系统一直接受升级，注意在升级前后做一次书签 Tile 的回归测试——我自己就遇到过升级之后，老书签 Tile 的 URL 里多了一串兜底参数，导致打开应用直接报错的情况。不过对于大多数读者来说，你们接触的标准版本已经足够稳定，我提版本差异只是想说明：书签 Tile 不是一层不变的静态链接，它背后是一套个人化数据持久化机制，这决定了它“能存、能同步、能跨端”。我建议新实施项目直接按照新版机制配置，没必要走老路。4. 一步步实操：建立“团队共识入口”需要做的事4.1 明确要固化的筛选状态是哪一个在动手创建书签 Tile 之前，首先要和业务方问清楚一个问题：“你们说的快捷入口，到底要固定哪一组筛选条件？”这个问题听起来很基础，但在现实里往往是最耗时的环节。因为很多人是“大概印象”，并没有真的把自己常用的筛选条件列出来。我通常的做法是要求业务方提供三个版本的筛选角度：最常用的日常默认（比如：本期间、当前公司代码、所有利润中心）；每月初做报表时用的期初快查（比如：上月期末数、结转差异、特定利润中心）；老板或者跨部门核对时用的汇总视角（比如：所有公司代码、全财年、只看合计数）。每个版本走一遍“打开应用→设置条件→确认结果正确”，再进入下一步。这一步做得越扎实，后面保存的 Tile 就越有复用价值，而不是存了一个没人用的花架子。4.2 从应用到书签 Tile 的完整操作路径具体操作步骤我按标准路径写一遍，你们照着点就行：进入目标应用，在 Fiori launchpad 的“应用”分组里找到它。在应用界面里把第一步确定好的筛选条件逐一设置好，确保表里的数据是你希望别人第一眼看到的内容。点击右上角分享菜单（或启动面板上的“更多”菜单），找到“Create Tile” / “Add to Home” / “Add Bookmark”之类入口。系统会弹出一个对话框，里面有几个可编辑字段：Tile 标题、副标题（部分版本有）、目标分组。标题我建议写成业务可读的名称，比如“本月财务利润中心快查”，不要叫“Report 1”。副标题可以写“已固定期间=当前月、利润中心=P001”，方便其他人判断里面是什么数据范围。选择目标分组。如果你只是给自己用，放“我的主页/我的分组”都可以。但要作为团队共识入口，就必须先确定一个公共分组，这个问题后面会专门讲。点击保存。保存成功后，返回 launchpad，去看新的分组里有没有出现这个 Tile，点击验证能否正确打开、筛选条件是否自动带上。4.3 验证的四个维度：本人、他人、权限、跨端保存之后不要以为万事大吉，标准化验证流程至少要覆盖四个方面：本人用普通点击走一遍：确认 Tile 能从 launchpad 正常打开、筛选条件正确、无报错。模拟无权用户或不同数据权限的用户：用另一个测试账号打开同一 Tile，看是不是能正常渲染。不能正常穿权限的时候，系统可能拦截数据，也可能直接白屏。这个测试一定要做，否则共享出去会让同事一头雾水。移动端（Fiori Client / 浏览器）：如果团队有用移动端的习惯，还要确认 Tile 在移动端打开时布局不混乱。筛选条件是同一个，但响应式渲染差异会导致部分表格在手机上很难看。清缓存场景：换一个浏览器或开无痕窗口再点一次 Tile，排除客户端缓存把旧界面状态带进来的干扰。我自己见过最典型的翻车现场：Tile 保存时某业务用户是在 A 测试机点开的，应用带了一个临时 URL 参数，结果这个参数被书签持久化了，换到正常笔记本上打开就报“无效参数”。所以验证一定要在“干净环境”里做，不要用带着异常参数、调试模式或者测试专用的会话去保存书签。4.4 配置失败的常见对话框和对应的处理方式现象可能原因处理方式点击 Create Tile 无反应前端分享功能被禁用联系管理员检查 Fiori Launchpad Designer 的配置及权限对象保存后 Tile 出现在 Home 但点开是空白页应用不支持 URL 参数初始化放弃书签方案，改用“启动配置”或自开发入口页保存后打开提示“无权限”目标应用绑定的角色未授予给所有使用人把应用对应的 PFCG 角色挂到相关人员的账号上Tile 显示正常，但筛选值变成了全空应用启动时没有读取书签里的 Intent 参数升级应用版本或联系应用开发团队补参数读取逻辑4.5 分享链接的通用打开方式：从邮件到群公告分享链接还有一种典型的用法，就是配合群公告类工具使用。你把一个已经验证好的、代表“团队共识状态”的链接放到团队的公告栏目里，队友点开直接看到同款数据。这与书签 Tile 属于互补关系，链接适合“在聊天软件里转”，Tile 适合“在 Fiori launchpad 里放”。我日常的做法是：链接负责“活水”，当筛选条件经常变化、临时性强时，大家都可以自己拉一个状态发给别人；Tile 负责“定海神针”，当筛选条件是长期稳定的共识时，就固化到公共分组里。两者互不冲突，甚至可以用同一个验证流程管理。5. 从“个人的书签”变成“团队的共识入口”，需要管理员再走两步5.1 公共分组怎么建：在 Fiori Launchpad Designer 里的配置思路个人保存的书签 Tile，默认只对本人可见。要让整个团队打开 launchpad 就看到同一个 Tile，你需要把 Tile 放到一个“公有” 的分组里，或者用管理员的方式把分组配置分配给一拨人。在 SAP Fiori launchpad 的标准配置里，展示哪些分组，取决于登录用户被分配了哪些目录、角色以及组。实施顾问在 Fiori Launchpad Designer（也就是“组配置”界面）里可以创建组，然后把应用 Tile 和“外部链接” Tile 放进去，再把这个组分配到对应的业务角色上。保存书签 Tile 的行为，本质是用户自己在“我的组”里加入了一个私有 Tile，它并没有自动进入公有组。所以“团队的共识入口”要想成立，管理员通常做的是把这些常用的“带筛选状态”的 Tile 想办法做成公有 Tile。这条路在标准功能里有几个不同做法，取决于你得实现什么程度：如果只是固定筛选参数的单独页面，可以直接在自定义应用目录（Catalog）里配置一个 Target Mapping 带固定参数，然后放到一个公共组里；如果想要“用户自己保存但大家可见”，标准功能本身不支持把个人书签一键转公有，常见做法是让管理员提取出书签的 Intent，手动在 Catalog 里建一个对应参数的应用 Tile。这条路径从技术上是干净的，只是不再依赖用户的个人化数据，而是变成正式配置——这个恰恰才是真正的“共识入口”。5.2 建“带默认参数的 Tile”的配置实操管理员在 Fiori Launchpad Designer 里新建应用 Tile 时，可以通过配置参数的方式，让 Tile 指向一个固定 Intent。具体来说：打开 Fiori Launchpad Designer。在“目录”模块里新建一个目录规则，或者进入现有目录。新建一个“应用”类型的 Tile，填入目标映射（Target Mapping）信息。在“参数”配置里，把你要固定的筛选值以“name=value”的形式写入。比如参数名为 companyCode，值是 1000；保存目录，然后把目录分配到一个组。把这组分配给需要使用的业务角色。做完这一步，团队打开 launchpad，看到的这个 Tile 就已经天然带有筛选条件，不需要用户自己保存书签。它的稳定性比“用户书签”高得多，因为它是正式配置，不会因为个人化数据丢失而消失。5.3 权限模型怎么匹配：共享 Tile 前的三个检查列表在把任何带固定筛选状态的 Tile 做成共享入口之前，建议权限管理员过一遍三个检查：有权访问该 Tile 的所有用户，是否都分配了目标应用本身的授权？否则点开还是没数据。数据的行级/字段级权限是否一致？固定筛选只是设定一个初始视角，但用户最终能看到多少数据，仍然受后端授权对象控制。如果 A 同事能看 1000 公司代码，B 同事不能，那你们都点同一个 Tile，看到的数据范围也不同，这要提前和业务方说明白。如果 Tile 带的是 OData 服务地址，确认服务是全局可用而不是绑定到某个特定客户端或机器名。否则换一台服务器登录，Tile 就指向错误地址了。5.4 业务落地话术：怎么说服业务方用这个功能给业务方讲这个功能，不要从技术术语讲起。我最常引用的一句话是：这个功能可以把你们每天重复的两分钟，变成每天都零操作的一键直达。实际对话过程中，可以用这样几个场景打动他们：对财务：月底结账时要对多个口径的数据，现在不用每天手动切筛选，点一个“本月结账快查”就行。对销售：全国大区经理看各自区域销售，不必教他们去哪找报表，一个 Tile 解决。对领导层：领导不看复杂的筛选器，给他一个“本周汇总”Tile，点开即所见。业务方一旦理解了“入口=固定的视角”这个逻辑，接受度往往高于预期。他们不会关心你用的是书签还是 Catalog 参数，他们只关心每天是不是少点了几次鼠标。6. 配置实践中踩过的坑与排查思路6.1 书签 Tile 保存后神秘消失的排查链路书签 Tile 保存后，理论上会在用户的 launchpad 个人化数据里持久化。如果消失了，排查链路一般长这样：先确认是不是登录到了其他客户端或服务器。Fiori 的 bookmarks 是和 frontend session 关联的，一旦你切换了系统的 client 或 gatewayserver，那很可能看不到原来保存的 Tile，因为个人化数据存储在不同后端上。检查浏览器存储和 local storage。有的轻量级实现把部分 Tile 数据放在浏览器里，清缓存就会被清掉。看 Fiori launchpad 的用户个性化设置里，是否开启了“重置为默认布局”之类功能。一旦重置，所有个人 Tile 都会被抹掉。最后查 Fiori 前端的 gateway 日志中个人化服务请求状态。如果是 500 错误，那就是后端持久化出了问题，要 BASIS 介入。我遇到过一次“书签 TiLe 消失”的排查，最后发现原因是某位用户另建了一个新的前端客户端，还是通过“共享链接”方式进入应用的，结果所有操作都发生在另一个 session 里，自然看不到自己原来组的 Tile。所以就出现了一个很反直觉的结论：你通过什么 URL 进入 launchpad，也影响你能不能看到自己的书签。6.2 带参数 Tile 打开后报“页面找不到”的根因分析这个报错对顾问来说应该很亲切，其实绝大多数不是 Tile 的问题，而是你给的参数名和应用解析参数的代码不匹配。Fiori Elements 列表应用读取 URL 参数时，解析规则是基于 manifest.json 里的 routing 配置和 OData 注释做映射的。如果你在 Tile 配置里随意给参数起名（比如把 standard 的 param 写成缩写），那应用自然不知道你在说什么，等到加载完成找不到 filter 字段，就报页面异常了。所以配置带参数的 Tile 之前，一定要先从应用开发文档里找到“该应用接受哪些 URL 参数”，或者用 F12 观察正常操作时 URL 里的参数结构，抄下来，再放到 Tile 配置里。6.3 分享链接不同人点开结果不一致的现象解释结尾处我再补充一种情况：同一个分享链接，发给不同的人，他们打开时界面可能完全不一样。这不是功能 bug，而是环境差异导致的。常见变量有三个：第一，接收者是否已经登录过同一个前端服务器？如果没登录，链接会先带你到登录页，登完再跳转到目标应用。如果登录的是另一个 client，数据范围和前端配置都可能不同。第二，接收者的语言和时区设置也会影响显示格式，但数据范围不变。部分日期类的筛选参数用的是“YYYYMMDD”这种标准格式，时区差异不会改变底层数据，但日期选择器上显示的值可能不一样。第三，接收者的 Fiori 前端主题是自定义过的，如果自定义主题里调整了组件的默认行为，可能导致部分字段默认值不同。如果出现多人点同一个链接看到不同结果，你不要先怀疑“链接没有带参数”，而是让几个人把地址栏的 URL 发出来对比。如果 URL 完全一致，那就是接收者环境差异；如果 URL 里本来就被截断或附加了各自的东西，那才是传递过程中的问题。6.4 长期维护的一种务实做法：把“共识入口”沉淀成配置库用书签 Tile 解决了当下的问题之后，我建议团队把这类“带固定筛选条件的入口”统一登记到一张配置清单里，记录内容包括：业务场景、应用名称、语义对象/动作、参数键值、目标角色、大概多久需要更新一次。以后再有人问你“那谁谁谁分享的那个入口怎么做的”，你直接翻记录就行，不用每次从零开始排。这种配置库不用做得特别复杂，Excel 都够用。但它的价值在于：让“分享一个入口”从一次偶然的个性操作，变成团队的一种规范流程。这也呼应了标题那句话——一次筛选，真正变成了团队的共识入口。我自己在项目里把这件事做完之后，业务部门的反馈很简单：“终于不用天天教新人怎么选条件了。” 这大概就是这组功能最好的回报。
1. 为什么“分享应用”和“书签 Tile”总被当成两个孤立功能在 SAP Fiori launchpad 里，“分享应用”和“创建书签 Tile”这两个入口，绝大多数用户其实都点过，但很少有人会认真想它们之间到底是什么关系。我自己最早接触这个场景，是被业务部门一个很具体的问题逼出来的：财务团队每天早晨打开系统，第一件事就是进入某张报表，把公司代码、利润中心、期间三个筛选条件重新选一遍，再看结果。这个过程大概要花两分钟，但他们有五个人，每天就是十到十五分钟的重复劳动。当时有人提出来说，能不能让系统记住筛选条件？答案是可以，而且 SAP Fiori launchpad 本来就有这个能力，只是入口藏得比较深。真正把我引到“把一次筛选变成团队共识”这个思路上的，是后来我发现“共享应用”按钮和“书签 Tile”这两个看似独立的功能，其实组合在一起，就是一套从个人效率到团队协作的完整闭环。先说“共享应用”按钮。Fiori launchpad 的应用页右上角，通常在用户头像下拉菜单或者应用卡片菜单里，有一个“Share”或“分享”入口。点开之后会出现几个选项，其中最常用的有两种：一种是通过邮件发送一个指向该应用的链接，另一种是复制当前应用的当前状态链接。注意“当前状态”这四个字，它意味着你分享的不只是应用本身，还包括你当前打开这个应用时带入的参数。换句话说，如果我在我的界面上把报表跑成了“公司代码 1000，利润中心 P001，期间 2025.01”，我复制出来的这个链接，别人点开时看到的直接就是同一个筛选状态下的数据。而“创建书签 Tile”的逻辑也非常相似。它做的是把当前应用连同当前状态一起钉回到 launchpad 的某一个分组里，生成一个新的 Tile。这个 Tile 的标题可以自定义，比如“月度利润中心快查”之类的。之后任何人只要点击这个 Tile，就会直接进入你保存的那个筛选状态。看到这里你就明白了：两者本质上都在做同一件事——把“一次操作后的应用状态”变成一个可以被反复访问的入口。区别只是承载方式不同，一个是链接，一个是 Tile。如果我们把“分享链接”发给团队，再把“书签 Tile”挂到公共分组里，那效果就完全不一样了。团队不需要知道筛选条件怎么选、不需要打开应用后再点几下，只需要点一个入口，就进入了大家约定好的那个视角。这就是标题里说的，把一次筛选，变成团队的共识入口。这篇文章我主要想聊三件事：第一，哪些 Fiori 应用可以走“分享当前状态”这条路，哪些不能，边界在哪里；第二，创建书签 Tile 需要什么样的前置条件，有哪些坑是配置的时候特别容易踩的；第三，从管理员或者超级用户的角度，怎么把这两个功能组合起来，做成业务团队真正愿意每天都用的入口。内容偏向实操，所有步骤我都按最常见的 SAP Fiori launchpad 版本（以 SAP S/4HANA 搭配 Fiori Frontend Server 的常规配置为准）来写，个别菜单名称在不同版本里可能略有差异，各位对照自己的环境微调即可。2. 分享功能先搞清楚：可共享的链接是什么、能做多少定制2.1 “共享链接”背后的原理：不是所有分享都是“当前状态”Fiori 应用为什么能做到“把当前状态分享出去”？这要归结到 SAP Fiori 应用导航机制里一个叫“Intent”的概念。Intent 由两部分组成：语义对象（Semantic Object）和动作（Action），再加上一组可选的参数（Parameters）。我拿一张报表举例，比如它的语义对象是“CostReport”，动作是“display”，参数是“companyCode=1000&profitCenter=P001”。一个完整的应用链接，其实就是把 Intent 编码进 URL 里。当你打开一个 Fiori 应用以后，应用本身会把用户的筛选操作映射到 URL 参数上。有的应用是自动映射——你改一个筛选条件，地址栏的 URL 参数就同步更新，我用 Chrome 按 F12 看网络请求的时候，经常能直接抓到完整的 Intent 参数。有的应用则是“半自动映射”——你改完条件之后，需要手动点什么按钮（一般是刷新、搜索或者一个“生成链接”的功能）才会把当前状态写回到 URL 里。还有些应用是彻底不支持的，后面我会专门讲这一类。搞清楚这个原理，你就能理解为什么“分享”出来的链接，有时候别人点了能用，有时候点了却没反应——大概率就是 URL 参数没有被正确地携带过去。2.2 Fiori launchpad 里分享入口的常规操作路径以最常见的标准 Launchpad 配置为例，分享入口的路径大致是这样的：打开目标应用，把筛选条件设置好，让界面处于你想要分享的状态。找到右上角的用户菜单或应用工具栏菜单。不同系统里位置可能有细微差别，有些版本是齿轮图标旁边的“分享”按钮，有些版本是把“分享”收进了“更多选项”（也就是那个“三个点”的图标）里。点击“Share”，菜单展开后会出来几个选项，常见的有：Share Link in E-Mail：通过邮件客户端发送链接。Copy Link：把链接复制到剪贴板。Create Tile：这一步在部分版本里也会出现在分享菜单里，点击之后就是保存书签 Tile 的入口。这里我特别强调一个小技巧：对于比较老的 Fiori 版本，如果你在应用界面里面找不到“Share”菜单，回退到 launchpad 页面，找那个应用卡片右上角的“书签/分享”图标（通常是一个类似链条或者分享箭头的图标），从那个入口一样可以操作。本质上都是调用同一个底层服务，但路径更直观。还有一个很容易被忽略的小细节：复制链接的时候，有的环境复制的是一长串带完整 Intent 的 URL，有的环境复制的是经过短地址服务加工后的短链接。短链接的好处是发邮件不臃肿，但坏处是你没法直接看出来它里面包含哪些参数，排查问题的时候很绕。如果你是在配置阶段做测试，建议优先使用“Copy Link”，然后自己放浏览器里对比一下长链接和短链接在打开时是否完全等价。2.3 哪些应用能分享“当前状态”，哪些不能分享当前状态能不能成功，核心取决于应用本身对 URL 参数的支持程度。我自己的经验可以用一个象限来划分：应用类型是否支持状态分享典型例子备注基于 SAP Fiori Elements 的列表报表/分析页绝大多数支持标准 Fiori 报表应用、带筛选条件的分析页面筛选条件自动映射到 URL 参数，分享最稳定自由开发的 Fiori App（SAPUI5 自编码）取决于开发者是否实现了参数读取逻辑自定义应用很多自开发应用压根没有“根据参数初始化界面”的逻辑，分享过去等于打开了一个空白应用传统 SAP GUI 事务的 Web 封装（例如通过 Fiori 启动 SAP GUI for HTML）基本不支持“当前状态”某些老事务代码可能支持最简单的导航参数，但复杂筛选状态不可能完整映射第三方集成的 OData 应用不一定支持通过自定义 Card 或第三方应用框架接入的页面要验证才知道对第 2、3 类应用，我不建议硬推“分享当前状态”给业务用户，否则他们会觉得这个功能不好用。更务实的做法是把这类应用包在一个“带默认参数的启动配置”里，后面我会讲到怎么通过其他手段实现类似效果。2.4 链接分享给团队的三个适用场景和两个禁忌分享链接适合什么样的场景？我按使用频率排一下：临时转达：同事问我某个报表你是不是跑出来了，让我看一眼数据。我直接把当前状态的链接发过去，对方点开就能看到同款数据，沟通效率大幅提升。跨地沟通：我和另一个城市的分公司同事对账，双方进入同一个筛选状态，讨论的就不是“你在哪儿选的这个数”，而是“你那个数有没有问题”。内部培训/带教：老员工带新人熟悉某项业务报表时，先把一个精心筛选好的链接发过去，新人打开就是正确的筛选模板，少走很多弯路。禁忌也有两个：一是不要传播包含敏感数据的深链接。如果这个链接直接指向“公司代码 1000”的数据视图，那它携带的数据范围就已经固化在 URL 里了。分享到群里或者邮件里，收件人如果权限不匹配，打开时要么报错，要么就只能看到一部分数据，容易造成误解。更稳妥的做法是先确认对方的数据权限范围和你分享的状态是一致的，再发链接。二是不要把链接当成正式的知识资产来管理。链接会过期吗？在大多数环境里不会，但如果 backend system 被刷新、OData 服务的路径发生调整，或者语义对象名称因为传输导入出了变化，那这些旧链接就会失效。你如果把它长期放在 wiki 里当唯一入口，迟早有一天会翻车。链接适合“聊天的即时引路”，长期入口还是交给书签 Tile 更靠谱。3. 创建书签 Tile 前，先确认这五个前置条件3.1 为什么同一套代码，有人能存 Tile，有人找不到入口“创建书签 Tile”这个功能，并不是所有用户所有环境都能用的。它受三个层面影响：Fiori 前端版本、应用是否启用了相关功能开关、用户是否有对应的角色权限。Fiori 前端版本层面， SAP 在标准的 Fiori launchpad 里加入“书签/分享”功能是相对早期的版本就有的事，但是真正稳定支持“自定义 Tile 保存并在下次登录后仍然存在”的体验，是在某一版之后的 Fiori foundation 上才完善的。如果你的系统还跑着非常古老的版本，某些安全策略默认是禁止用户自定义 Tile 的。功能开关层面， Fiori 前端配置里有两个跟分享相关的配置项，分别是 SAP UI5 的“enableShare”相关参数和控制“Pinning”行为的参数。如果管理员在 Fiori Launchpad Designer 或对应 catalog 里把这些行为禁掉了，用户界面上就不会出现“Create Tile”入口。这个是排查“怎么找不到入口”的时候第一个要查的方向。用户权限层面，标准角色模板里通常会包含“SAp_UI_FLEX”相关的权限对象，这个权限对象控制的是界面的“灵活性”修改，书签 Tile 本质上也属于一种用户界面调整的一部分。如果权限配置得太严，用户只能浏览、不能自定义任何 UI，那书签保存也会一并被禁掉。3.2 官方支持的范围从哪里确认因为在 SAP 生态里，“配置是否正确”最终要看激活的 UI technology 版本。最直接的确认方法，是打开应用之后，F12 打开浏览器开发者工具，在 Console 里看有无报错，或者在 Network 里看“/sap/bc/ui2/...”相关的请求是否正常返回。凡是“书签保存”能正常工作，系统一定会有一个“个人化数据持久化”的接口被调用，比较典型的是“sap/ushell/repository”开头的请求或者“personalization”相关的服务。如果发现这个请求返回 404 或者 401，那就说明当前环境根本没有激活个人化数据持久化后端。这时候不是在 launchpad 层面能解决的问题，需要你的 Basis 或者实施团队的顾问去检查前端的 web.xml 和 ICM 配置里是否挂载了对应服务。3.3 后端联动：OData 注释和语义对象名称必须干净还有一个经常被忽略但真实存在的前置条件：Tile 创建之后，点击它能否正确打开应用，取决于语义对象和动作的名称是否与应用 catalog 里注册的 target mapping 完全匹配。如果当初应用配置时有多个 target mapping 或同语义对象有多个 action，系统会弹出一个选择对话框，或者直接进入默认配置。这种“多对一”的情况会让书签 Tile 的体验变得很分裂。从实践角度，我给自己定了一条规矩：生产环境做书签 Tile 之前，先把应用的 Target Mapping 查一遍，确认 Intent 是唯一可解析的。如果发现同一个 Semantic Object + Action 被映射到了多个 Target 上，先让配置管理员清理干净，再去保存书签。不然你存下来的 Tile，过两天点开可能打开的是一个完全不相干的页面。3.4 版本差异：Chapter UI2 的“旧版个人化”与新版行为差异如果你们用的是很老的 Gateway 版本，书签 Tile 的持久化机制和现在的版本是不同的。老版本里，用户的个人化数据是存在用户主数据表里（比如 A 表和 B 表里面），新版本是走统一的前端个人化后端服务。如果你负责维护的系统一直接受升级，注意在升级前后做一次书签 Tile 的回归测试——我自己就遇到过升级之后，老书签 Tile 的 URL 里多了一串兜底参数，导致打开应用直接报错的情况。不过对于大多数读者来说，你们接触的标准版本已经足够稳定，我提版本差异只是想说明：书签 Tile 不是一层不变的静态链接，它背后是一套个人化数据持久化机制，这决定了它“能存、能同步、能跨端”。我建议新实施项目直接按照新版机制配置，没必要走老路。4. 一步步实操：建立“团队共识入口”需要做的事4.1 明确要固化的筛选状态是哪一个在动手创建书签 Tile 之前，首先要和业务方问清楚一个问题：“你们说的快捷入口，到底要固定哪一组筛选条件？”这个问题听起来很基础，但在现实里往往是最耗时的环节。因为很多人是“大概印象”，并没有真的把自己常用的筛选条件列出来。我通常的做法是要求业务方提供三个版本的筛选角度：最常用的日常默认（比如：本期间、当前公司代码、所有利润中心）；每月初做报表时用的期初快查（比如：上月期末数、结转差异、特定利润中心）；老板或者跨部门核对时用的汇总视角（比如：所有公司代码、全财年、只看合计数）。每个版本走一遍“打开应用→设置条件→确认结果正确”，再进入下一步。这一步做得越扎实，后面保存的 Tile 就越有复用价值，而不是存了一个没人用的花架子。4.2 从应用到书签 Tile 的完整操作路径具体操作步骤我按标准路径写一遍，你们照着点就行：进入目标应用，在 Fiori launchpad 的“应用”分组里找到它。在应用界面里把第一步确定好的筛选条件逐一设置好，确保表里的数据是你希望别人第一眼看到的内容。点击右上角分享菜单（或启动面板上的“更多”菜单），找到“Create Tile” / “Add to Home” / “Add Bookmark”之类入口。系统会弹出一个对话框，里面有几个可编辑字段：Tile 标题、副标题（部分版本有）、目标分组。标题我建议写成业务可读的名称，比如“本月财务利润中心快查”，不要叫“Report 1”。副标题可以写“已固定期间=当前月、利润中心=P001”，方便其他人判断里面是什么数据范围。选择目标分组。如果你只是给自己用，放“我的主页/我的分组”都可以。但要作为团队共识入口，就必须先确定一个公共分组，这个问题后面会专门讲。点击保存。保存成功后，返回 launchpad，去看新的分组里有没有出现这个 Tile，点击验证能否正确打开、筛选条件是否自动带上。4.3 验证的四个维度：本人、他人、权限、跨端保存之后不要以为万事大吉，标准化验证流程至少要覆盖四个方面：本人用普通点击走一遍：确认 Tile 能从 launchpad 正常打开、筛选条件正确、无报错。模拟无权用户或不同数据权限的用户：用另一个测试账号打开同一 Tile，看是不是能正常渲染。不能正常穿权限的时候，系统可能拦截数据，也可能直接白屏。这个测试一定要做，否则共享出去会让同事一头雾水。移动端（Fiori Client / 浏览器）：如果团队有用移动端的习惯，还要确认 Tile 在移动端打开时布局不混乱。筛选条件是同一个，但响应式渲染差异会导致部分表格在手机上很难看。清缓存场景：换一个浏览器或开无痕窗口再点一次 Tile，排除客户端缓存把旧界面状态带进来的干扰。我自己见过最典型的翻车现场：Tile 保存时某业务用户是在 A 测试机点开的，应用带了一个临时 URL 参数，结果这个参数被书签持久化了，换到正常笔记本上打开就报“无效参数”。所以验证一定要在“干净环境”里做，不要用带着异常参数、调试模式或者测试专用的会话去保存书签。4.4 配置失败的常见对话框和对应的处理方式现象可能原因处理方式点击 Create Tile 无反应前端分享功能被禁用联系管理员检查 Fiori Launchpad Designer 的配置及权限对象保存后 Tile 出现在 Home 但点开是空白页应用不支持 URL 参数初始化放弃书签方案，改用“启动配置”或自开发入口页保存后打开提示“无权限”目标应用绑定的角色未授予给所有使用人把应用对应的 PFCG 角色挂到相关人员的账号上Tile 显示正常，但筛选值变成了全空应用启动时没有读取书签里的 Intent 参数升级应用版本或联系应用开发团队补参数读取逻辑4.5 分享链接的通用打开方式：从邮件到群公告分享链接还有一种典型的用法，就是配合群公告类工具使用。你把一个已经验证好的、代表“团队共识状态”的链接放到团队的公告栏目里，队友点开直接看到同款数据。这与书签 Tile 属于互补关系，链接适合“在聊天软件里转”，Tile 适合“在 Fiori launchpad 里放”。我日常的做法是：链接负责“活水”，当筛选条件经常变化、临时性强时，大家都可以自己拉一个状态发给别人；Tile 负责“定海神针”，当筛选条件是长期稳定的共识时，就固化到公共分组里。两者互不冲突，甚至可以用同一个验证流程管理。5. 从“个人的书签”变成“团队的共识入口”，需要管理员再走两步5.1 公共分组怎么建：在 Fiori Launchpad Designer 里的配置思路个人保存的书签 Tile，默认只对本人可见。要让整个团队打开 launchpad 就看到同一个 Tile，你需要把 Tile 放到一个“公有” 的分组里，或者用管理员的方式把分组配置分配给一拨人。在 SAP Fiori launchpad 的标准配置里，展示哪些分组，取决于登录用户被分配了哪些目录、角色以及组。实施顾问在 Fiori Launchpad Designer（也就是“组配置”界面）里可以创建组，然后把应用 Tile 和“外部链接” Tile 放进去，再把这个组分配到对应的业务角色上。保存书签 Tile 的行为，本质是用户自己在“我的组”里加入了一个私有 Tile，它并没有自动进入公有组。所以“团队的共识入口”要想成立，管理员通常做的是把这些常用的“带筛选状态”的 Tile 想办法做成公有 Tile。这条路在标准功能里有几个不同做法，取决于你得实现什么程度：如果只是固定筛选参数的单独页面，可以直接在自定义应用目录（Catalog）里配置一个 Target Mapping 带固定参数，然后放到一个公共组里；如果想要“用户自己保存但大家可见”，标准功能本身不支持把个人书签一键转公有，常见做法是让管理员提取出书签的 Intent，手动在 Catalog 里建一个对应参数的应用 Tile。这条路径从技术上是干净的，只是不再依赖用户的个人化数据，而是变成正式配置——这个恰恰才是真正的“共识入口”。5.2 建“带默认参数的 Tile”的配置实操管理员在 Fiori Launchpad Designer 里新建应用 Tile 时，可以通过配置参数的方式，让 Tile 指向一个固定 Intent。具体来说：打开 Fiori Launchpad Designer。在“目录”模块里新建一个目录规则，或者进入现有目录。新建一个“应用”类型的 Tile，填入目标映射（Target Mapping）信息。在“参数”配置里，把你要固定的筛选值以“name=value”的形式写入。比如参数名为 companyCode，值是 1000；保存目录，然后把目录分配到一个组。把这组分配给需要使用的业务角色。做完这一步，团队打开 launchpad，看到的这个 Tile 就已经天然带有筛选条件，不需要用户自己保存书签。它的稳定性比“用户书签”高得多，因为它是正式配置，不会因为个人化数据丢失而消失。5.3 权限模型怎么匹配：共享 Tile 前的三个检查列表在把任何带固定筛选状态的 Tile 做成共享入口之前，建议权限管理员过一遍三个检查：有权访问该 Tile 的所有用户，是否都分配了目标应用本身的授权？否则点开还是没数据。数据的行级/字段级权限是否一致？固定筛选只是设定一个初始视角，但用户最终能看到多少数据，仍然受后端授权对象控制。如果 A 同事能看 1000 公司代码，B 同事不能，那你们都点同一个 Tile，看到的数据范围也不同，这要提前和业务方说明白。如果 Tile 带的是 OData 服务地址，确认服务是全局可用而不是绑定到某个特定客户端或机器名。否则换一台服务器登录，Tile 就指向错误地址了。5.4 业务落地话术：怎么说服业务方用这个功能给业务方讲这个功能，不要从技术术语讲起。我最常引用的一句话是：这个功能可以把你们每天重复的两分钟，变成每天都零操作的一键直达。实际对话过程中，可以用这样几个场景打动他们：对财务：月底结账时要对多个口径的数据，现在不用每天手动切筛选，点一个“本月结账快查”就行。对销售：全国大区经理看各自区域销售，不必教他们去哪找报表，一个 Tile 解决。对领导层：领导不看复杂的筛选器，给他一个“本周汇总”Tile，点开即所见。业务方一旦理解了“入口=固定的视角”这个逻辑，接受度往往高于预期。他们不会关心你用的是书签还是 Catalog 参数，他们只关心每天是不是少点了几次鼠标。6. 配置实践中踩过的坑与排查思路6.1 书签 Tile 保存后神秘消失的排查链路书签 Tile 保存后，理论上会在用户的 launchpad 个人化数据里持久化。如果消失了，排查链路一般长这样：先确认是不是登录到了其他客户端或服务器。Fiori 的 bookmarks 是和 frontend session 关联的，一旦你切换了系统的 client 或 gatewayserver，那很可能看不到原来保存的 Tile，因为个人化数据存储在不同后端上。检查浏览器存储和 local storage。有的轻量级实现把部分 Tile 数据放在浏览器里，清缓存就会被清掉。看 Fiori launchpad 的用户个性化设置里，是否开启了“重置为默认布局”之类功能。一旦重置，所有个人 Tile 都会被抹掉。最后查 Fiori 前端的 gateway 日志中个人化服务请求状态。如果是 500 错误，那就是后端持久化出了问题，要 BASIS 介入。我遇到过一次“书签 TiLe 消失”的排查，最后发现原因是某位用户另建了一个新的前端客户端，还是通过“共享链接”方式进入应用的，结果所有操作都发生在另一个 session 里，自然看不到自己原来组的 Tile。所以就出现了一个很反直觉的结论：你通过什么 URL 进入 launchpad，也影响你能不能看到自己的书签。6.2 带参数 Tile 打开后报“页面找不到”的根因分析这个报错对顾问来说应该很亲切，其实绝大多数不是 Tile 的问题，而是你给的参数名和应用解析参数的代码不匹配。Fiori Elements 列表应用读取 URL 参数时，解析规则是基于 manifest.json 里的 routing 配置和 OData 注释做映射的。如果你在 Tile 配置里随意给参数起名（比如把 standard 的 param 写成缩写），那应用自然不知道你在说什么，等到加载完成找不到 filter 字段，就报页面异常了。所以配置带参数的 Tile 之前，一定要先从应用开发文档里找到“该应用接受哪些 URL 参数”，或者用 F12 观察正常操作时 URL 里的参数结构，抄下来，再放到 Tile 配置里。6.3 分享链接不同人点开结果不一致的现象解释结尾处我再补充一种情况：同一个分享链接，发给不同的人，他们打开时界面可能完全不一样。这不是功能 bug，而是环境差异导致的。常见变量有三个：第一，接收者是否已经登录过同一个前端服务器？如果没登录，链接会先带你到登录页，登完再跳转到目标应用。如果登录的是另一个 client，数据范围和前端配置都可能不同。第二，接收者的语言和时区设置也会影响显示格式，但数据范围不变。部分日期类的筛选参数用的是“YYYYMMDD”这种标准格式，时区差异不会改变底层数据，但日期选择器上显示的值可能不一样。第三，接收者的 Fiori 前端主题是自定义过的，如果自定义主题里调整了组件的默认行为，可能导致部分字段默认值不同。如果出现多人点同一个链接看到不同结果，你不要先怀疑“链接没有带参数”，而是让几个人把地址栏的 URL 发出来对比。如果 URL 完全一致，那就是接收者环境差异；如果 URL 里本来就被截断或附加了各自的东西，那才是传递过程中的问题。6.4 长期维护的一种务实做法：把“共识入口”沉淀成配置库用书签 Tile 解决了当下的问题之后，我建议团队把这类“带固定筛选条件的入口”统一登记到一张配置清单里，记录内容包括：业务场景、应用名称、语义对象/动作、参数键值、目标角色、大概多久需要更新一次。以后再有人问你“那谁谁谁分享的那个入口怎么做的”，你直接翻记录就行，不用每次从零开始排。这种配置库不用做得特别复杂，Excel 都够用。但它的价值在于：让“分享一个入口”从一次偶然的个性操作，变成团队的一种规范流程。这也呼应了标题那句话——一次筛选，真正变成了团队的共识入口。我自己在项目里把这件事做完之后，业务部门的反馈很简单：“终于不用天天教新人怎么选条件了。” 这大概就是这组功能最好的回报。