这几天，算是充分见识了OBIEE开发之“低效”，虽然这个报表的业务逻辑并不复杂，但开发过程简直是困难重重。

简单回顾一下这个艰辛的过程：

1. 直接使用拖放字段的方式，需要在列公式(column formula)中做各种设置，耗时不说，关键是不靠谱。LISTAGG()函数并不能正常工作。

2. 所以，只能由Ad-hoc模式(即，从subject area将报表字段逐个拖放至analysis文件的方式)切换为DDR(Direct Database Retrieve，数据库直连)的方式。这里难在需要明确各字段来自哪张表(对应SQL语句中的SELECT、子查询部分)、各表之间的连接关系(对应WHERE部分)。这部分有个技巧：使用Ad-hoc方式(即，拖放字段)创建一个草稿版报表，运行该报表，可在OBIEE后台(需要使用独立于developer权限的账号才能访问该模块)查看实际执行的query(即系统根据拖放的字段即其关系自动生成的SQL脚本)。以此query为基础，进行“大刀阔斧”的修改(机器生成的query真的有点反人类，可以说是“圆环套圆环”，好像压根没打算让人读懂似的)。

3. DDR脚本的开发心得：

1)选取一个具体case(如，一个protocol)缩小数据集(这个看似简单的步骤，实际上非常有用，可以节省大量调试时间)

2)一边开发一边进行单元测试(一个字段即可看作一个小功能，甚至一个字段的一个小bug也可看作一个小功能，不断进行开发 —》测试 —》开发的迭代)，直至数据准确、完整(这个过程有如战场上开坦克碾压一切敌人的感觉)

3)使用好子查询(with as, 子查询嵌套)，优化SQL脚本(query)结构

4)活用LISTAGG()函数，实现行转列，有效减少数据行数(提高数据致密化程度)(期间出现了LISTAGG()查询结果的去重问题，参见本人的另一篇拙作：调试经验——Oracle列转行函数 Listagg() 查询结果的去重(去除重复值)方法)

4. DDR脚本开发并测试完成后，需要完成显示层了(prompt，applied filter等)。这个过程可以说是最为艰辛的(耗用了两天时间)。

要点：

1)对于普通的prompt(相当于筛选器、filter，即用户用于指定查询条件的控件，基本上为下拉列表)，可在prompt view中新建column prompt，然后在query中添加Decode语句判断用户是否在该prompt中指定了内容(用DECODE函数)

2)对于日期型prompt，就不能使用column prompt了

3)注意Prompt view中，Presentation Value的值不能重复，否则就会出现用户指定的结果不能在页面上一闪而过，不能保存的怪现象(排查此bug又花费了半个多小时)

至此，本报表基本开发完成。剩下的工作主要在于完成繁杂(看似内容很多，但有用的信息却很少)的报表文档了。