关于前端:SAP-Fiori-应用-Adapt-UI-动态显示或者隐藏的技术设计细节解析

47次阅读

共计 2400 个字符,预计需要花费 6 分钟才能阅读完成。

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

正文完
 0