工作小结碎碎念(1): FPM for Web Dynpro从零开始

一. 前言

其实发现已经好久没来更新博客了，一方面是因为工作还是比较忙的另一方面就是脑子里总在构思写什么，但又每天犹豫不决不知道该写什么。其实发现也没啥好纠结的，把每次自己经历过做过的工作拿过来整理下也就OK了吧吗，而且也难得空闲了一点，那就索性再写点记录记录吧。(反正也就是给自己看看，作为以后可能的一个参考)

二. 背景

那为什么要选择这个主题呢，因为大约从5月份开始就着手开始做起了一个UI Renewal的项目。然后定下来就是把现有的在R3上的payroll solution，放到web dynpro上包装一层并且优化一些流程上的问题与新工具的开发。

接到任务的时候感觉还是有点tough的，毕竟以前完全没做过Web Dynpro ABAP，而且这次还要在一个FPM的框架下创建各种新的用户界面，总觉得更多的还是对一种新的框架的学习而不是一种对自我写代码的一种设计上的锻炼 (其实个人还是不太喜欢SAP Web dynpro这一套东西...读一个页面总有点卡的感觉有木有...) 。但学什么不是学呢，就放下心来好好认识下FPM这个框架吧，所以这篇主要就是讲如何“无中生有”这些FPM application的一个创建流程与个人认为的一些在这个项目中比较有意义的一些功能实现。

三. 正文

首先就来简单介绍下一个FPM application的创建过程与对应一些实现方式：

在一个package下创建一个web dynpro的application，然后根据现有的需求填上对应的FPM component，目前只支持4中components：Object Instance Floorplan (OIF)，Overview Page Floorplan (OVP)，Guided Activity Floorplan (GAF) and Quick Activity Floorplan (QAF)。 个人觉得像OVP 跟 GAF还是比较常见的, 所以我之后的例子就是创建一个OVP的component了。具体还是参考下图吧：


然后鼠标右键新建的application，选create/change configuration, 于是这时会跳出一个浏览器来创建这个新的configuration。这里要理解一点，FPM的框架下每一个component都会需要一个对应的configuration，这也是FPM的一个推广的特点之一：任何页面与控件都能配置(遗憾的是这里的配置当然不是随心所欲的，做过的会发现还是有很多局限新- -)。但它的理念还是值得肯定的，那就是对于这种可配置化的图形界面，会让开发变得更为方便, 这也是时下众多APP开发的一个共同套路：MVC。略有点扯远，总之创建的时候输入一个configuration的名字就行了，如果想套用之前的配置也可以直接copy或者输入之前的配置名称。
创建完一个component与对应的configuration之后，就可以通过这个configuration来对该控件进行相应的配置了：在OVP中就可以加自己想要的section啊，page啊，子控件啊，toolbar button啊，页面信息啊等等。这里我想主要介绍的还是添加子控件的流程，也就是添加一个新的UIBB到这个OVP的component中。在配置网页上的“Overview Page Schema”中有个添加UIBB的按键，通过这个可以在这个大的OVP控件下添加各种需求所要的子控件了。我这里的例子就添加一个Form的UIBB吧，也是一个非常实用的控件了，主要就是用来展示各种基本信息。同样在点了添加form
UIBB的时候需要创建一个对应的configuration，来配置这个form UIBB。
创建好了一个UIBB之后，则需要对该UIBB进行对应的配置了，而在这个配置之前系统得需要知道这个控件具体操作的是哪些信息与之对应一些事件与处理逻辑了。那么这里则就需要引入一个‘feeder class’的概念，这个概念在传统的web dynpro也有，就是用来对一个控件在逻辑上与信息获取上的一个控制。因此这个时候，就得回系统上去创建这么一个feeder class。这里我也不具体展开了，总之这里需要做的就是实现2个基本FPM控件的interface，然后在对应的方法上绑定对应的structure来作为显示在form上的信息，同时通过不同的事件处理来对获取后台的具体信息展示在前台的form上。

所以大概就是这么4步来创建一些简单的FPM application，然后基本的一个overview图如下：(临时画一个吧...)

四. 一些经验

说了这么多，那么具体在这项目中我做了哪些呢？其实主要还是完整的做了4个FPM的application，这些application的作用基本就是在原先R3上的一个迁徙，然后也加上了一些新的功能与流程优化。这些application(GAF,OVP)上主要还是form，list与search这些控件，还有一些自定义的toolbar的添加。后台也对应的建立了一套ABAP OO的框架来实现各种取数逻辑与事件处理。 现在在印象中觉得有意义的总结点可以归结如下：

控件的feeder class其实可以放一个extend的interface，用来实现一些页面上的confirmation的dialog跳出
有些特例化的confirmation check则需要自己去手动建立一个新的dialog page
子控件之间的信息传递可以通过一个singleton的class去交互，我这边都是叫这些为data shared class。当然FPM也有提供wire的方式来让控件之间做交互。
FPM标准的search控件是很有限制的，而且面对具体的需求很难有很好的adoption，完全没有R3上的selection screen好用。于是这里也引入了一个free style的UIBB来替代这个标准的search控件：WDR_SELECT_OPTIONS，这个控件好像是印度那边开发的，个人感觉比标准的好用多了。
List中有自带的下载成excel的功能比较好用，因此还对应的开发了一个upload excel的功能，但还是很有局限性，不如R3上call个function那么方便好用。
不同FPM application之间的网页跳转实现也是比较方便的，甚至还可以传参数来实现一些为下一个窗口需要的默认显示。
动态去绑定List UIBB所展示的表的内容，可以通过配置信息来显示这个List的内容，而不是通过传统的配置去完成。对于那种表结构很复杂，元素很多的情况下还是比较好用的，不然手工的去配置这些信息是需要很大的effort的。
用SHDB去录制一些在R3上的操作然后包装成class的方法通过FPM的前台控件去实现这些录制操作(虽然觉得很蠢的办法，但还是可以用的)

当然也有些不足之处现在还觉得比较没有把握的，也希望在以后的工作中去寻找答案吧：那就是FPM这套application对权限的管理我还是很陌生，比如对于一个FPM上的List内容的修改与显示的权限是否也是跟着pfcg上的role来走？毕竟R3上的maintenance view那一套都是可以在role上配的，或者说还是在feeder class里加authorization check的代码？还有就是比如在FPM上做了一个配置上的修改，是否会生成一个customized request能传到其他系统上？因为R3上可以通过scc4对不同client做一个transport的配置。

五. 后语

总之整个创建过程还是比较容易的，可能也有别的方式去创建，好像标准的也有提供create wizard之类的工具，我尝试过发现还是不怎么好用啊...所以觉得还是最原始的方式比较方便了。至于后台feeder class里的代码其实总觉得就是把该填的东西填进去，然后给予一些share data class 与 utility class去实现一些功能。总之我个人不是很喜欢代码级别的东西，它只是个工具用来帮我们解决问题而已，而对于FPM这框架，我也只能持中立的态度，我这边也就当通过这个项目了解一下吧。