工作中笔者的共事已经问过我一个问题,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 零碎的权限管控设计思路。