和开发漫谈

核心提示用SAP GUI + Dynpro 开发应用的UI界面仿佛是石器时代的事情了。据我所知,至少在SAP成都研究院已经没有团队仍旧使用这种古老的技术来开发UI了。虽然S/4HANA的后台还有大量事务码可供终端用户使用,但是,借助SAP Inte

用SAP GUI+Dynpro开发应用的UI界面,好像是石器时代。据我所知,至少SAP成都研究院没有团队还在用这种古老的技术开发UI。虽然在S/4HANA的后台有大量的交易代码可供终端用户使用,但是在SAP Internet Transaction Server的帮助下,这些基于SAP GUI的交易代码可以直接运行在浏览器端,具有费奥里应用的外观。

也就是说,如果你的S/4HANA On Premise客户需要一些新的UI,除了常规的UI5开发方法,从技术上来说,你还是可以开发一个带有SAP GUI的Dynpro屏幕,然后将其打包成一个交易代码,最后将这个交易代码分配给S/4HANA费奥里launchpad的一个tile。详见我的博客:在fiori launch pad中打开您的sap GUI事务。

blogs . sap . com/2016/12/21/open-your-sap-GUI-transaction-in-fiori-launch pad/

用浏览器访问SAP GUI交易代码SE80的效果如下:

实际上,S/4HANA的许多标准应用程序也采用这种方法。以物料主数据管理的应用为例,S/4HANA既有这个“烟幕”打造的伪费奥里应用,也有下面要介绍的原生费奥里应用。

部件包含至少一个

从实现语言上可以分为ABAP Web Dynpro和Java Web Dynpro。据我所知,基于ABAP Web Dynpro开发的SAP标准应用要比Java Web Dynpro多很多。例如,SAP SRM的标准UI基于ABAP Web Dynpro。此外,还有很多属于SAP_BASIS软件组件的应用或框架,其UI也是由ABAP Web Dynpro开发的,最著名的是BRF。

作为Netweaver ABAP堆栈的一部分,BRF及其升级版BRF+在许多SAP产品中发挥着重要作用。典型的例子是SAP Solution Manager的事件管理和SAP Cloud for Customer的服务请求应用场景中的支持团队确定功能。通过BRF,我们可以配置一系列基于组件、系统id、客户端id和事件优先级字段的规则。BRF可以根据用户配置的这些规则,自动决定哪个团队应该处理事件/服务请求。

然后是SAP document Builder,一个用于复杂文档生成的解决方案。文档管理员负责配置符合实际业务中使用的文档外观和格式的文档元素。这些由Word编辑的文档元素是最终文档的组成部分。用户访问ABAP Web Dynpro UI,填写一些关键字段,最终生成PDF、Word、HTML或XML格式的文档。

这种技术特别适合一些国内客户,他们认为SAP标准UI衍生的文档格式与客户平日使用的纸质文档外观相差甚远。通过document Builder,客户可以使用Word设计符合自己格式和外观要求的文档元素作为模板,然后上传到系统,并基于这些模板生成最终文档。

SAP document Builder的ABAP Web Dynpro UI:

此外,ABAP Web Dynpro的入门速度很快,学习曲线相对平缓,UI编辑方式接近所见即所得。作为MVC框架,ABAP Web Dynpro不需要像CRM WebClient UI那样开发一个真实的业务对象作为模型,而是可以直接调用控制器中的底层API。这种简单快捷的开发方法很受合作伙伴的欢迎。几乎在我支持的每个内部项目的二次开发中都可以看到ABAP Web Dynpro的身影。

虽然ABAP Web Dynpro有这么多的优势,但这并不意味着它是一个通用的解决方案。因为不能很好的适应移动设备,ABAP Web Dynpro在费奥里诞生后逐渐退出了UI开发的历史舞台。

有一点需要提醒:

如果一个SAP标准产品的UI不是使用ABAP Web Dynpro开发的,那么在决定使用该技术进行二次开发之前,请慎重考虑,因为你很可能会遇到这些坑:

后退按钮的处理

数据丢失的检测和处理

对话处理

支持UI可配置性

消息显示区的处理

对底层API的调用不正确

这些坑是我之前支持国内客户项目时,大量混用ABAP Web Dynpro和CRM WebClient造成的。关于这些坑的更多细节,请参考我的博客。

在CRM UI中使用ABAP Webdynpro的问题列表

blogs . sap . com/2014/01/08/issue-lists-of-using-abap-webdynpro-in-CRM-ui

BSP/CRM web客户端用户界面

SAP BSP是一项神奇而重要的技术。很神奇,因为它历史悠久。据我所知,从90年代就开始服役了。而其重要的一面,暂时卖个关子。

BSP和JSP原理相同,可以直接在前端HTML页面中嵌入ABAP代码。

运行时,这些ABAP代码在服务器端执行,然后合并到页面源代码中。最后,服务器端将页面源代码发送给浏览器,显示给用户。

下图是BSP应用的一个例子。BSP的HTML中仍然可以触发一些事件,但是这些事件的响应函数并不是Javascript函数,而是ABAP实现的代码片段,也就是下图左边以on开始的一系列事件处理逻辑。

从上面的界面也可以看出,BSP应用缺乏MVC支持,ABAP编程只能在其框架支持的6个事件响应位置进行。用BSP开发一些小工具还可以,但是开发企业应用就太弱了。正因为BSP的这个缺陷,CRM WebClient UI才有了用武之地。

CRM WebClient UI的应用本质上是一个BSP应用。与传统的BSP开发交易代码SE80不同,CRM WebClient UI有了新的开发交易代码。该开发工具为在MVC中使用BO作为模型层提供了原生支持,即开发者可以在开发工具中将BO的某个领域绑定到UI的某个领域。

WebClient UI和下面要介绍的SAP UI5一样,也包含了很多开箱即用的标准控件,只不过我们一般不用control这个术语,而叫它element。开发者只需要使用这些标准元素就可以快速开发出高质量的UI界面。

例如,下图显示了由WebClient UI实现的典型搜索页面。第二行和第三行声明了SAP的标准元素库thtmlb和chtmlb的引用,然后在第十一行使用thtmlb库中的元素searchframe。有SAP UI5开发经验的朋友可以把这种做法归类为在UI5的XML视图中使用SAP标准UI5控件。原理是一样的。

在短短29行代码中,绘制出如下搜索界面:不仅支持通过下拉菜单改变搜索条件,还支持通过带+和-的圆形按钮添加或删除搜索条件。

因此,应用程序开发人员不需要编写原生HTML代码和CSS。在运行时,对应于searchframe元素的Render类将负责生成本机HTML代码。

更多WebClient UI的开发细节,可以参考我的微信官方账号文章杰瑞收集的42篇WebClient UI原创文章。

此外,与ABAP Webdynpro相比,CRM WebClient UI有更多的业务对象层和通用交互层,如下图红框所示。有些朋友可能会觉得这两层会带来一些额外的运行时开销,导致WebClient UI的性能不如ABAP Web Dynpro。

关于运行时开销这个话题,我做了一个评测,结果显示:假设用WebClient UI和ABAP Web Dynpro实现同样的需求,在WebClient UI中引入BOL和GenIL层带来的运行时开销,与ABAP Web Dynpro相比并不会导致太大的性能差异。底层API逻辑越复杂,运行时开销就越小。

下图显示了分别由社交帖子、销售订单和产品测试的BOL和GenIL造成的运行时开销的详细信息。请参考我的博客,了解我所做的绩效评估的更多细节。

webclient UI vs ABAP webdynpro:BOL/赫尼尔河层讨论中的性能损失

blogs . sap . com/2014/01/02/webclient-ui-vs-abap-webdynpro-performance-loss-in-BOL-genil-layer-discussion/

SAP UI5/费奥里

这一对术语经常互相同时出现,有些朋友并不太清楚它们之间的区别和联系。费奥里是SAP的官方设计语言,代表了一种UI设计风格。我的同事周帅在他的微信文章《SAP成都C4C小李探花:浅谈费奥里设计准则》中对SAP费奥里做了详细的介绍。SAP UI5是一种UI开发技术,是基于jQuery的UI开发框架和UI控件库。

目前S/4 HANA的UIS、面向客户的SAP云、SAP Engagement Center、SAP RevenueCloud都是基于SAP UI5的。

在我之前介绍BSP的时候,为什么这项技术如此重要?S/4HANA,SAP的旗舰产品,其费奥里应用仍以BSP的形式存储在Netweaver上。

例如,S/4HANA物料主数据管理的费奥里应用程序,其BSP应用程序名称为md_prod_mas_s1。

BSP应用程序在ABAP后台打开,如下所示:

开发者可以使用WebIDE、Eclipse、Webstorm、Atom、Sublime Text或任何其他喜欢的IDE/编辑器来开发SAP UI5。开发完成后,一旦这些UI5应用程序部署到Netweaver,SAP框架将自动创建一个BSP应用程序来存储UI5应用程序的所有内容。

SAP UI5支持不同的视图类型,最常用的是xml视图和js视图。对于xml视图,声明要使用哪些UI5控件。

运行时加载xml视图,由UI5框架的xmlTemplateProcessor将内容解析成DOM树,树中的每个叶节点对应XML视图中一个UI5控件的声明。然后深入遍历这个树,创建UI5控件的运行时实例。因为是深度遍历,所以在下面显示的调用栈中可以观察到handleChildren和createRegularControls的多次递归调用。

与xml视图相比,js视图中控件的实例化不是由XMLTemplateProcessor完成的,而是由开发人员自己用Javascript代码完成的。

每个UI5控件都有一个对应的渲染器,负责根据实例中包含的属性,在运行时渲染对应的HTML本机代码。

但是,有一些S/4HANA费奥里应用程序。如果按照Jerry在本文中告诉你的关于Chrome Developer Tools的方法,用Chrome Developer Tools打开它的实现,你会发现这个应用既没有xml视图,也没有js等类型的视图。那么,我们如何绘制费奥里用户界面呢?

举个例子,如果你按照我博客的步骤,你可以在几分钟内构造一个支持服务订单添加、删除和修改的费奥里应用,而且你不需要写一行Javascript代码。

在几分钟内创建一个CRM服务订单费奥里应用程序

blogs . sap . com/2016/03/31/create-a-CRM-service-order-fiori-application-在几分钟内/

神秘之处在于这里使用了一个叫做智能模板的费奥里框架。有了这个框架,界面布局信息不再在xml或js视图中维护,而是在CDS视图中定义。

下图是我在ABAP工作室的博客中提到的服务订单应用程序使用的CDS视图的显示。可以观察到有很多注释,其中名称以@UI开头的注释定义了一些元数据,描述了被注释字段在费奥里UI上出现的具体位置。

@UI.lineItem:在UI的搜索结果列表中以列的形式出现,具体位置由属性位置指定。

@UI.selectionField:声明该字段呈现为搜索字段。

这些注释的详细定义可以在SAP帮助中找到。这就是元数据驱动的UI开发方式。这种方法实际上将UI开发的大部分复杂性从应用程序开发人员转移到了智能模板框架本身的实现上。有了这个框架,应用程序开发人员需要做的就是专注于CDS视图的开发,并在视图中定义UI注释。在运行时,SAP UI5框架读出这些元数据,然后负责生成原生HTML代码。

这就解释了为什么在基于智能模板的费奥里应用中找不到xml或者js视图,因为UI布局根本不再存储在这些前台资源中,而是维护在ABAP后台的CDS视图中。

下图显示了前面提到的服务订单费奥里应用程序使用的CDS视图的层次结构。每个视图的详细代码都在我的博客里。

更多关于智能模板的信息,请参考我的微信官方账号文章Jerry的博客集《通过CDS view+智能模板开发费奥里应用》。

面向客户的SAP云中的UI5

之所以把C4C单挑出来,是因为虽然C4C也是基于SAP UI5,但是SAP UI5的用法和其他SAP产品不同,比如S/4HANA、SAP Revenue Cloud、SAP Engagement Center。SAP成都研究院开发团队的杨乔伊将在他的文章中介绍具体的差异。

Hybris企业商务平台

根据使用场景,可以分为店面UI和后台UI。

店面UI的布局和用法类似于我们日常使用的淘宝JD.COM,是用JSP开发的。

与前面介绍的CRM WebClient UI中使用的BSP技术一样,Hybris封装了许多标准UI元素,供开发人员在Hybris Storefront UI的JSP开发中使用。这些标准的UI元素在Hybris中被称为标签。

例如,下图使用标签ycommerce:testId在页面中显示产品搜索结果:

该标签的定义位于以下文件中:

ext-template/yacceleratirstorefront/WEB/webroot/we b-INF/common/TLD/ycommercetags . TLD

标签的实现位于TestIdTag.java文件中:

ext-template yaccelerator store front web src de hybris platform yaccelerator store front tags

如前所述,UI5控件的呈现器和WebClient UI元素的呈现器的职责是相同的。这个Java类也可以看作是JSP标签的渲染器,负责在运行时渲染JSP标签testId对应的原生HTML代码。

上面的注释还提到,为了保证id的唯一性,pageContext内部维护了一个计数器,每生成一个页面元素,计数器就加1。此计数器生成的整数值用作最后生成的本机HTML p标记的id属性的后缀,以确保每个P标记都有一个全局唯一的id。

Hybris JSP标签,保证了p id属性的全局唯一性,与WebClient UI完全一致。在下图中,我们可以很容易地从WebClient UI页面的原生HTML代码中找到id属性值的整数后缀:

WebClient UI中id属性计数器的累积在下面的第24行中完成。

关于Hybris JSP标签的更多细节,请查看我的博客:

在Hybris UI实现中使用的JSP属性标签和ABAP BSP中的对应标签

blogs . sap . com/2018/02/02/JSP-attribute-tag-used-in-hybris-ui-implementation-and-counter-in-abap-bsp/

以上只是Hybris ECP店面UI开发的微观描述。宏观来说,这些JSP开发的接口如何组装才能最终形成用户看到的电子商务页面?导航配置文件,类似于SAP WebClient UI,可以基于业务角色定义一系列UI及其页面跳转关系。Hybris ECP公司也有一个类似的模块,叫做网络内容管理系统:

在WCMS中,您可以定义一个页面模板,它包含不同的页面槽,在这些槽中放置特定的uicomponents。比如下图中的首页模板,定义了电商首页的布局。我们可以观察到SiteLogoSlot位于TopHeaderSlot和ButtonHeaderSlot之间,包含SiteLogoComponent,负责在电商页面上显示logo。

UI组件标签的渲染可以分为三个阶段:预渲染、渲染和后渲染,分别对应renderItem方法中的三个子方法:

之前项目

渲染项目

后续项目

这三个方法分别对应WebClient UI中的这三个子方法:

开始时做

提出

在终点做

至于WCMS创建的模板运行时如何生成最终的HTML源代码,是一个比较复杂的过程。这里由于篇幅有限,就不详细介绍了。可以参考Hybris官网的帮助文档。

Salesforce UI

在谈论Salesforce UI时,您会遇到以下名词:

顶点

闪电体验

光环框架

Lightning组件框架

视觉力量

Apex: Apex是Salesforce推出的强类型面向对象编程语言,语法类似于Java。Apex到Salesforce就像ABAP到SAP一样。有趣的是,Apex可以像ABAP开放SQL一样直接与持久层交互。

下图中两个红色突出显示代码的等效ABAP Open SQL代码是:

从名称类似“test%”的帐户中删除。

闪电体验:Salesforce的设计语言,相当于SAP费奥里,也支持移动设备访问。

下图显示了在PC浏览器中打开的Salesforce主页:

下图显示了在手机上打开的机会创建页面:

Aura framework:一个开源的Web应用开发框架,源代码在github上;

github.com/forcedotcom/aura

Lightning组件框架:基于上面提到的开源框架Aura,作为一个组件前端框架,Salesforce用它来开发可复用的UI组件。

下图是帐户视图如何由不同的UI组件组成的示意图。可以和前面介绍的SAP Hybris店面UI的WCMS对比一下,思路其实是一样的。回想一下,Hybris Storefront页面模板包含几个页面槽,每个槽包含一个UI组件。

visual Force:sales Force使用的基于MVC的UI开发框架。开发接口类似SAP UI5的xml视图。接口的模型声明语法{0}类似于SAP UI5。界面控制器用Apex语言开发。

和前面提到的JSP和SAP BSP一样,Visualforce是一种基于服务器端渲染的技术。

希望这篇文章能给你一些关于不同SAP产品UI的基础知识,以及Salesforce UI的开发技术。

感谢阅读。

 
友情链接
鄂ICP备19019357号-22