开篇声明，以下内容仅代表个人见解，如有大牛发现存在不正确的地方，还请指出以共勉。如需转载，请注明来处。谢谢大家！
记得那年冬天，我从J2EE工程师转到Cognos报表开发岗，起初挺痛苦。因为从编码到单纯工具使用，心理上的转变和发展方向差距蛮大。所以起初开发的报表中充满着各种奇异的JS和各种HTML....开发报表的同时，为了对Java实施不丢弃不放弃的目的，兼理了Java SDK和Cognos外部portal等开发，这一点让我认识Cognos更为深入了一些。其实，Cognos对于使用者来说，其中还是有很多博大精深的地方值得学习，虽然谈不上全自动化，但商业智能方面它也能不错的完成给定的内容。
从事Cognos开发，这一看似挖掘非挖掘、coding非coding的职位，曾几何时我们也都茫然过。记得公司老总常说，工作几年还停留在仅有的托拉拽？这句话足以让我低头沉默许久。反思过去，其实我学到的不只是托拉拽，而更多的是思路和理念以及业务知识。当然我也学到了架构和基本的ETL工作等等....所以，新手在看到这篇文章的时候，如果你喜欢报表方面的工作，或者不得不做这一块，请相信自己，总有一天我们不会再是托拉拽式搬运工。
一、安装部署。
所有功能的施展前提，都基于这一块。
1. 硬件配置
我遇到过很多客户第一件咨询的问题是：硬件配置
对于硬件配置的计算和预估，是需要结合用户和计划用户的个数来决定的。为什么这么说，因为报表工具服务对象是用户，用户的多少决定报表系统的访问量以及并发量。做过软件测试的人一定知道，压力测试其中一项就包含并发量。所以，100个用户就需要一台能支撑100+个用户并发使用报表的机器。
2. 是否集群
如果单台服务器的配置已经秒杀多台服务器，其实在使用方面并没有多大问题。但双机热备功能恐怕就难以实现了，曾经做过测试，最稳定的报表服务器还是正确配置集群后的服务器。当某一台宕机以后，其它服务器继续服役。
3. 报表服务器和数据库、CUBE服务器放在一起？
看起来节约了不少的成本，但后患无穷。首先，强烈建议数据库服务器单独一台，因为报表服务器跑批量报表或操作不当的时候，如果数据库在同一台，服务器宕机很可能带来数据丢失等大麻烦。其次，CUBE服务器一般是可以放在报表服务器，但是CUBE CREATE的时候，数据吞吐量较大，网络占用较多，如果此机是主节点，那么报表访问会因此收到牵连。
4. 中间件的选择
如果有中间件当然最好，如果没有，自带Tomcat也不耐，配置好JVM大小就好。另：中间件自带的集群不建议开启，建议使用Cognos自带集群功能。
5. F5对Cognos的作用
如果Cognos网关服务器没有独立出来，那么F5起到的作用就是平衡网关服务的压力。
二、FM建模
1. 关于星形模型、雪花模型
这个概念其实是在数据建模中最常用的，我就不再解释其中的含义。如果你是新手，那么你要注意，这会影响到报表的访问速度和数据库的负载压力。
2. 建模方法
做了那么多模型，不论是复杂的银行报表模型，还是简单的KPI小指标模型，小生认为，好的FM模型其实是最简易的模型，清晰的条理（分好主题和层次）、简单的数据逻辑....当然，做过开发的人知道，select * 这种简易SQL都能出报表的查询项，基本不太可能出现在实际开发中，ETL人员可能不会将数据整理得完全如你所愿。因此，在无法满足简易的情况下，尽量在物理层写好逻辑吧，各种relations线在FM中让人眼花撩乱，N天后，谁还知道那是神马东东呢？
3、模型管理和备份
最好用ZIP打包存放SVN吧，FM有个缺陷就是不能直接SVN协作开发，因此多人协作开发的时候，通常都采用一样的层次结构模型，一起填补内容，最后合并。当模型丢失，也不要慌张，可以使用之前发布的数据包找回。
三、报表开发
1. 普通报表
不论是表格和图表，开发报表如果要使用JS，那么你需要考虑是否导出到文件，JS写的内容是无法导出的。
影响报表访问速度的因素主要有：数据量、数据库优化、FM模型优化、表间计算、报表过滤条件等等...因此报表开发的注意事项是不是就一目了然了？有人说JS会影响报表效率，会。但只要不写冗余代码，基本可以忽略JS的语句执行时间。
地图功能？
如果有市区的地图报表需求，其实Cognos是可以实现的。使用MAPINFO画出地图，注意区域和点都需要画。最后导出gst文件，使用FM工具里自带的Cognos Map Manager导入gst文件，确认区域无问题另存为cmf。地图配置各大论坛一堆，我就不详细介绍了。
图表颜色按条件控制？
请采用样式变量。
联动效果？
钻取报表自身可以实现。
如何开发比较炫的报表？
这个其实是个噱头，虽然报表以业务价值为主，但太丑的布局和配色，恐怕谁也无心看下去。男女老少，都学学配色去吧...可能的话用PS做一些高端大气的背景。
2. 活动报表
这一块可能用到的人不多，活动报表其实很简单，控制好各个组件之间的关系就很OK。如果想要提升报表的访问效率，尽量减少数据量和图表量，最后还得控制好各个组件之间的连动关系。在多个图表需要因某个操作一起联动时，可以使用容器装好这些图表，设置主要明细关系即可。否则过多的关联关系会导致报表整体速度很慢。
四、CUBE开发
CUBE开发遵循业务为主的原则，访问、刷新效率都兼顾。
1. CUBE数据来源的选择
建议使用FM数据包。用于CUBE制作的FM查询项，必须访问效率高，否则CUBE刷新将会异常缓慢。
2. TR模型
大家都知道TR模型有维度属性个数限制的，所以客户号、身份证号等就别设计到TR模型中了。
建议维度不超过7个。我这里建议不超过10个以上吧，在国内7个可能不太现实。
3. 度量的精度
度量精度一般保持默认就好，这个默认的精度是根据FM模型中查询数据项来自动判断的。如果出现数字不对，可以从FM查询项中找原因。
4. CUBE文件在集群中如何存放？
建议使用共享盘或NAS
5. 如何优化CUBE
在TR模型中，CUBE选项有个processing选项，看到有一个游标卡尺了吧？CUBE访问速度和刷新速度调节，自己去权衡吧..
6. 增量方案？
曾经有很多人问我这个问题，其实最常用的就是CUBE分组+FM查询。FM查询中与时间参数表关联，实现T+1很简单。自带功能也有一个增量选项，不过这个使用起来可能不是非常方便。
五、SDK应用
SDK分为Java和Csharp、.NET等，我这边只说说Java。
1. 主要应用范围：外部集成、自定义portal、用户集成、权限管理、报表批量、邮件分发...等
2. 如何使用？
首先需要购买SDK，然后下载安装，安装完以后在安装目录下有一个SDK目录：install\IBM\cognos\c10_64\sdk\java，将这些个例子导入到Java project，慢慢开始您的SDK之旅。
3. 第三方认证？
建议使用SDK开发数据库认证，有OA系统的将OA用户集成过来。
4. 单点登录？
目前么有最好的方式，常用的有：cookies、passport，个人觉得passport比较靠谱。cookies在跨域方面还有点问题。
六、其它功能
1. 权限管理
建议使用Cognos自带的用户组和角色来管理，然后将外部用户添加到其成员里。为什么这样做，因为外部用户组和角色可能不太稳定，一旦发生改变，很可能导致谁也没有权限查询报表系统。
2. 调度功能，EventStudio有什么用？
这里可以使用JOB和EventStudio来调度，主要可以生成报表视图和邮件分发等功能。
可能很多人不知EventStudio可以用来干什么，就说其中一个简单功能：在群发报表的时候，报表参数可以是动态的数据项。
其他功能后续可能会添加。感谢您的支持！
