在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结构,由此我们可以很快速的研读这些源码。