事不嫌小,但是做出你的风格,这是我一向的style,所以几天前负责service 的同事提到,“希望能够管理系统异常混乱的Query”时,
我就开始蠢蠢欲动了。
在我尚未开始参与时,对方已经整理了一部分在用的报表,按照模块进行分类整理,剩下很多报表是因为开发人员或者做技术支持的人员在生产机直接创建的报表,这些报表的去留成为接下来工作的重心。
这些生产环境直接创建的报表,很多是技术支持团队的同事在处理异常时,临时创建的报表,以方便数据的核对,而问题解决后,而又往往忘记去清理,所以在系统运行了近十年的过程中,累积了惊人的数量的垃圾报表。
排除大部分可删除的报表外,还有一部分是因为历史遗留问题有必要区别对待,比如图方便直接创建后提供给用户使用的,或者支持团队针对经常发生问题的MP,创建的问题查询报表。这两类报表,虽然是本地报表,我们应该给予保留。
接下来的工作,就是我去考虑如何构建这个小小的管理平台了。
我粗略的归纳了一下需求。
1. 对象范围为全体Query
2. 按照template 和 Local 的两大分类,而各分类又再分是否授权
3. 能够客制化两大分类
4. 有一个可视化的管理平台
5. 对异常Local Query能够提醒创建人去清理
以下界面是非ABAPer人士的产出,界面比较粗糙,多多包涵。
在几天紧张的设计过程,终于生成了初始画面:
基于需求的预算程度,我经历把问题简单化。除了必要的配置外,不需要太多的设置。
首先, 提供一个客制化分类的界面。 排版问题,后续还需要改进。

当考虑到系统需要提供一个buffer给开发人员时,所以特定设置了一个免扰日期,及在此期间,系统不管控这些新建Query。
另外,可选择是否邮件提醒异常query,是否剔除系统自建Query的控制。

为了邮件提醒更为灵活,我另外新建了一只程序去触发提醒,你可以设置成一次执行,或者定期,系统会按照你的定义,去选择对应的接受对象。

最后,BI 从业者不忘初心,提供了一个简单的报表分类柱状图。

至此,以上设计完成。 从最初的一句话,慢慢地扩展开来,能够做到比较完整的一个需求,这里除了直觉对需求的补充外,我觉得很大程度是自己给自己挑战。
尽量想想对方是不是忽略了什么,是不是可以更加完整,是不是可以更加具有可扩展性等等。
我把代码也附在这里,有空可以一起看看。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/554557/viewspace-2130359/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/554557/viewspace-2130359/