saiku中datasource与schema管理模块源码分析

       在saiku中，数据源连接信息与schema文件是非常重要的，saiku可以同时连接多个各种数据源：普通关系型数据库、nosql、hive、kylin等大数据数据源；schema文件则将维度指标映射为MDX语句，最终经mondrian转换为sql在各种数据源上运行；在saiku 2.X版本中datasource与schema是存储在tomcat服务下的目录中的，是真真切切可见可编辑的文本文件，但这种做法显然不安全；在saiku 3.X后saiku使用了Jackrabbit这个框架，该框架是jsr中jcr-170的实现，用于管理内容仓库的一套标准（关于jcr和jackrobbit，笔者稍后会在saiku黑科技系列中详细介绍），本章节主要分析下saiku是怎样将datasource与schema存储起来的，又是存储在哪里，这又是怎样一条流程；和之前用户登陆模块类似，本章节也从前端html、js分析，然后后台jersty的controller及service等等；

前端

       saiku的datasource与schema管理是做了限制的，只用admin用户才能看到，页面虽然稍微简陋，但是里面确实有很多研究的点；该功能的管理页面生成的js文件是:js/saiku/plugins/Adminconsole/plugins.js;首先强调一点，由于做过权限限制，使用firebug调试时，会发现找不到这个文件，在脚本页签下搜索，可以找到对应的代码，但是打断点调试，会发现断点出并未挂起，对此笔者猜测，并不是代码没有执行，代码确实执行了，只是断点没有挂起而已；找到plugins.js，里面有多个template方法，并有user的crud、datasource的crud方法、schema的crud方法，template方法在saiku中比较常见，实际上就是将html封装在js中使用js绘制页面；

       这里以datasource的create为例详细说明下，在页面上点击【add Data Source】，js会调用create_datasource方法绘制填写数据源信息的表单，填完信息，点击【save】，则会调用save_datasource方法，在该方法中，首先获取请求后端的url（从href中或从Connection对象中，如果href中能获取到，则修改连接信息---refresh，反之，新建连接信息），然后判断用户使用的哪种方式填写的连接信息（普通或advanced，如果是monogo需要特殊处理），在表单中获取到连接信息，使用ajax提交到后端接口；删除datasource时，则调用remove_datasource，获取到连接名，然后ajax提交到后台；

       同理schema及user管理的代码，与datasource方式大体上一致，前端的可以查看对应的方法，或者html标签；在这里，笔者还发现了之前一个问题的解决方法：下载schema文件出现404的问题，需要修改 schemauploadtemplate方法里，href中的 /saiku/rest/saiku/admin/schema/<%= schema.id%>，由于笔者的项目名称以改变，所以在用saiku的就发送404；

后端

        saiku处理datasource和schema的controller是AdminResource.java，还是以创建datasource为例，找到这个类，创建datasource的方法是 createDatasource，请求发送过来之后，该方法接着调用DatasourceService.addDatasouce()，接着调用 IDatasourceManager.addDatasource()（因 RepositoryDatasourceManager实现了上述接口，且在saiku-bean.xml中可以发现，spring的IOC在初始化的时候已经将RepositoryDatasourceManager注入到DatasourceService中），所以接着又调用了RepositoryDatasourceManager. addDatasource()，该类用持有 JackRabbitRepositoryManager的引用，这个类就是saiku引用JackRabbit存储datasource和schema的核心代码了，会发现RepositoryDatasourceManager.addDatasource()是调用了该类的 saveDataSource()方法，将信息存储到内容仓库（repository，saiku在初始化的时候JackRabbit会自动创建，仓库的路径可在WEB-INF/saiku-beans.properties中配置）的 nt:olapdatasource-》 jcr:content下面，然后返回，整个存储datasource的流程就走完了；

        saiku存储schema的流程和上述流程大体相似，两点不同之处是：一、存储schema时候实际上是将schema文件中的内容读取出来存储到repository中，而不是直接存储的schema文件本身；二、在处理请求的controller中也就是AdminResource. uploadSchema方法 中，在存储完成之后，又将repository的中所有schema重新获取返回到前端；

其余的datasource和schema的update/remove，以及user的crud处理逻辑也在AdminResource中，朋友可以参考上述流程，查阅saiku的源码；

总结

由本篇及上篇可以看出，saiku前后端处理的方法和逻辑遵循和web开发中常见的mvc结构，由此我们可以很快速的研读这些源码。