工作中笔者的同事曾经问过我一个问题，SAP Fiori 界面上这个 Adapt UI 的按钮，为什么有的系统上有，有的系统上没有？Fiori Key User 正是通过点击该按钮，进入 Fiori UI 的 Adaptation 模式，从而实现在屏幕上新增扩展字段的目的。

比较下面两个不同系统的截图：

为什么这个 Adapt UI 按钮，如此神出鬼没，有的系统上有显示，有的没有？

自己动手，丰衣足食。假设你的身边找不到 SAP Fiori 专家，如何通过自己在系统里调试的方法找到问题的答案呢？

本文我们通过单步调试的方式，来分析这个 Adapt UI 按钮动态显示与否的逻辑。首先我们根据笔者之前介绍过的 SAP UI5 控件在浏览器端的渲染逻辑的知识，找出一个 ID 为 sap.ushell.plugins.rta 的插件，负责管理该 Adapt UI 按钮。我个人把 rta 理解成 Run Time Adaptation 的缩写。

这个插件从哪里来呢？在 Chrome 开发者工具里对 sap.ushell.config 和 sap-ushell-config 这组关键字进行全文搜索，找到了下面的代码片段：

由此可见，rta 这个插件实例，存储在 sap-ushell-config 这个全局对象的 bootstrapPlugins 属性里。

在 Adapt UI 按钮能够显示的系统上调试，发现全局对象 sap-ushell-config 的值，来自 oServerSideConfig 这个 JSON 对象，而后者的值，是从 SAP Fiori Launchpad 的 html 页面里一个硬编码的字符串反序列化而成：

把 FioriLaunchpad.html 里这个硬编码的字符串拷贝下来：

decode 之后，发现其层级结构同我们之前在 Chrome 开发者工具里观察到的 sap-ushell-config 全局对象完全一致，说明我们找对地方了。

下一步就是要弄清楚 FioriLaunchpad.html 里这个硬编码的字符串到底来自何方。标准开发人员一个字符一个字符敲进去的？SAP 软件没有这么傻。

SE80 打开 Fiori Launchpad Shell 对应的 BSP 应用:

/ui2/ushell, 发现字符串的值来自变量：

${SERVER-SIDE-CONFIG}

因此 SE80 里我们找到的这个 FioriLaunchpad.html 只是起到一个模板文件的作用，里面第 76 行出现的 ${SERVER-SIDE-CONFIG}, 也只是一个占位符，会被运行时该变量的实际值替换，最后就成了我们在 Chrome 开发者工具里观察到的那个长长的字符串。

那么变量 ${SERVER-SIDE-CONFIG} 的值从哪里来？在 BSP 应用里查找，发现 get_server_side_config_json 方法返回的值，注入到该变量里。

所以现在的问题转化为，通过单步调试 get_server_side_config_json 方法，弄清楚里面的逻辑：

当我单步调试进入该方法时，发现上图第 18 行 lr_data->mt_plugin 这个内表里，已经包含了需要返回并注入到变量 ${SERVER-SIDE-CONFIG} 里的当前系统上所有可用的 Fiori Launchpad 插件实例了，本文关注的 sap.rta.plugin 也赫然在列。

那么为什么本文开头提到的另一个系统里，没有显示 Adapt UI 按钮呢？

问题就出在下图第 22 行的 CHECK 语句。第 18 行的 mt_plugin 内表，存储了当前系统所有可用的 Fiori Launchpad 插件，每个插件都对应一个 catalog ID.

第 21 行的内表 it_catalogs, 存放的是当前登录用户通过分配的 PFCG 角色所拥有的 catalog ID 集合。

上图这段代码的语义是，遍历当前系统所有可用的 Fiori Launchpad 插件，如果其对应的 catalog ID，没有出现在登录用户所拥有的 catalog ID 集合里，那么该插件对于该登录用户来说就是无效的(invalid), 应该将其从 Fiori Launchpad 上隐藏。

从上图的调试窗口，我得知 Run Time Adaptation 这个插件对应的 catalog ID 为/UIF/SAP_RTA_PLUGIN, 然后我到 ABAP 后台 SU01 去检查，发现在看不到 Adapt UI 按钮的那个系统里，我的用户果然没有分配这个 catalog. 于是将其分配上去：

问题得以解决，现在 Fiori UI 里，这个久违的 Adapt UI 又回来了。

这就是一个实际的“自己动手，丰衣足食”的例子——通过单步调试，没有求助 Fiori 专家，也解决了工作中遇到的实际问题。

对 Fiori Adapt UI 更多技术细节感兴趣的朋友，不妨继续阅读下去。

为了让 Key User 在运行时能够使用 Adapt UI 按钮对 SAP Fiori 应用进行适配，这个 Fiori 应用中的所有控件都需要具有 Stable id.

只有 Adapt UI 的逻辑在运行时使用 Stable id，才能确保 Key User 所做的适配，可以再次被重复施加，例如在 Fiori 应用升级后。

Stable id 用于在运行时识别和修改控制器内的控件。但是，如果重用或嵌套这些视图，这些 id 就不再是惟一的了。为了避免歧义，每个视图都将自己的 ID 作为前缀, 添加到所有子控件中。

如果 ID 是在控件实例化期间创建的，则默认情况下它是唯一的。如果在运行时创建新的控件，控制器将通过调用 oController.createId("ID") 方法创建一个惟一的 ID. 这些方法可以为 ID 添加必要的前缀。另一方面，由于在生产系统中直接进行的 UI 调整，可能会干扰传输的更改，因此不建议 Key User 在生产系统中直接调整 UI。

总结

本文首先通过一个笔者工作过程中，经常被同事问起的一个问题出发，接着详细介绍了笔者如何通过单步调试的方式，自行分析 SAP Fiori Adapt UI 按钮显示与否的设计逻辑，通过这个例子再次阐述了 SAP 系统的权限管控设计思路。