2.5 BISERVER之Cache管理
从我目前了解的情况看来,部分cache与pentaho的session相关,即用户一次会话所用的缓存与一个cache相关,这个可以从CacbeManager的类即可发现,CacheManager只实现了IcacheManager并未继承任何类,并且从其中发现Hibernate的CacheProvider变量即可只利用Hibernate的echache来提供cache对象。并且定义变量private Map<String, Cache> regionCache,其中String即为session的id。Cache自然为cache变量。
另外,在定义的PentahoCacheSessionListener implements HttpSessionListener,中的sessionDestroyed方法也可以验证cache与session相关,其方法为
public void sessionDestroyed(final HttpSessionEvent event) {
HttpSession session = event.getSession();
Object obj = session.getAttribute( PentahoSystem.PENTAHO_SESSION_KEY ); //$NON-NLS-1$
if (obj != null) {
IPentahoSession userSession = (IPentahoSession)obj;
ICacheManager cacheManager = PentahoSystem.getCacheManager( userSession );
if ( null != cacheManager ) {
IPentahoSession pentahoSession = (IPentahoSession) obj;
if(pentahoSession != null) {
cacheManager.removeRegionCache(pentahoSession.getId());
}
}
}
}
removeRegionCache就不阐述源码了,即为从regionCache中移除以pentahoSession.getId()为key的cache,关闭与清除cache要调用其cache的clear方法。
2.6 BISERVER之执行引擎
BISERVER数据展示在demo中主要有4中,分别为图表(只显示数据图形),报表、多维分析和仪表盘。首先分析图表,在Pentaho User Console中,点击某个图表解决方案,发现房屋的url为http://localhost:8080/pentaho/ChartSamplesDashboard,在web.xml中查找发现其处理终端为ChartSamplesDashboard.jsp,其中调用ChartHelper.doChart( "steel-wheels", "charts", "barchart.xml", parameters, content, userSession, messages, null )显示图形。
其函数定义如下:
public static boolean doChart(final String solutionName, final String actionPath, final String chartName,
final IParameterProvider parameterProvider, final StringBuffer outputStream, final IPentahoSession userSession,
final ArrayList messages, ILogger logger)
从以上函数的源码中,能够发现图表的解析过程,首先获得初始化一些参数,如图表宽和高之类的显示属性,然后到pentaho-solutions\solutionName\actionPath文件夹,查询chartName的图表,并且解析它,获得图表类型属性,根据这些属性生成CategoryDatasetChartComponent对象,调用getXmlContent()方法获得图表内容,在getXmlContent方法中利用createChart生成数据集,createChart调用getActionData获得IpentahoResultSet数据集,而在getActionData中则是通过org.pentaho.platform.engine.services.solution.SolutionEngine的execute方法再次解析解决方案,这次是要获得数据,解析barchart_data.xaction文件,其中定义了一系列的action序列,包括数据源类型和查询语句,SolutionEngine进行解析过程产生RuntimeContext对象,其调用executeSequence方法执行barchart_data.xaction解析出来的action序列,将结果保存在ParameterManager对象中,后返回IruntimeContext对象,最终利用其获得IpentahoResultSet对象,再生成报表所需的DataSet。
2.7 Pentaho MetaData Editor
Pentaho MetaData Editor将数据源描述三个层次,分别为物理层、抽象业务层和业务层,如下图所示:
其中,Connections下的为物理层,Bussiness Models为业务层,它又分为Bussiness Tables和Bussiness View即上面提到的抽象业务层和业务层,其中的Relationships表示其中的业务表的关联关系。
下图为物理表的数据描述:
物理表的描述比较简单,其中一些描述含义和用处我也没理解。
下图为物理表列的描述:
其中增加了更加详细的列描述,如聚合类型,计算的语法等等。
下图为抽象业务层表描述属性:
它比物理层的表多了Metadata Security描述,因此它可以定义该模型表能够某用户对其的操作,具体设置过程如下图:
默认是无权限设置的。
下图为抽象业务层表列描述,如下图:
列都包含了安全信息,同时具有物理层的所有描述。
下图为业务层表描述:
很简单啊。
下面看看其列描述,如下图:
与抽象层是相同。
上面介绍了它们各个层的表和列的描述都包含哪些,它们是如何存储的,导出后发现生成的以xmi结尾的文件,开头的部分内容如下:
从上面的命名空间可以看出,其遵循的为XMI规范,XMI(XML-based Metadata Interchange) 使用扩展标记语言(XML),为程序员和其它用户提供元数据信息交换的标准方法。XMI的目的在于帮助使用统一建模语言(UML)以及不同语言和开发工具的程序员彼此交换数据模型。XMI也可用于交换数据仓库信息。XMI格式有效地标准化了任意元数据集的描述,它要求用户跨越多个工业和操作环境而使用同一种方式读取数据。
Pentaho Metadata editor形成的xmi文件有什么用处呢,我只在report designer发现其用户,可以作为数据源使用,如下图:
可以选择生成的xmi文件,然后选择表和列即可了。
2.8 Pentaho之数据查询接口与实现
Pentaho自己设计了查询接口,所有的数据查询(在图表、报表及多维分析中)均返回自己查询的接口对象,主要的接口为IpentahoResultSet、IpentahoMetaData、IpentahoConnection。
首先分析下IpentahoConnection的属性和结构,public interface IpentahoConnection,如下图:
在pentaho中有其4个实现类,分别为SQLConnection、MDXConnection、XQConnection(XML数据连接)、HQLConnection。
在SQLConnection中,自然利用sql的连接实现,其属性和构造函数如下图:
其中的nativeConnection : Connection变量即为sql的数据库连接,我们还注意到其中的ResultSet变量为IpentahoResultSet类型。其构造函数分别传入驱动类型、数据库连用户名及密码等,然后调用init函数初始化连接。
MDXConnection为Mondrain的连接,其属性和构造函数大致如下图:
其nativeConnection为mondrian.olap.Connection类型,在构造函数中进行初始化连接。
剩下的xml连接中依靠生成的net.sf.saxon.Configuration查询,而在hibernate查询中则保存了org.hibernate.cfg.Configuration做为根本。
然后再分析下IpentahoResultSet、IpentahoMetaData,由于不同类型的查询均有自己的ResultSet和Metadatadio对象,于是它们都需要在executeQuery中进行转换,如在SqlConnection中的查询方法返回SQLResultSet对象,其构造函数为
public SQLResultSet(final ResultSet nativeResultSet, final SQLConnection nativeConnection) 。
MDX则同样,Metadata与其原理是相同的,进行了封装,其SQLResultSet的获得metadata方法如下:
public IPentahoMetaData getMetaData() {
if (metadata == null) {
try {
metadata = new SQLMetaData(nativeResultSet.getMetaData());
} catch (SQLException e) {
// log.error(null, e);
throw new RuntimeException(e);
}
}
return metadata;
}
从而可以发现IpentahoResultSet、IpentahoMetaData、IpentahoConnection与不同的数据源实现均利用其本地实现进行了封装而成,因此我们只需要关注这些接口定义了哪些方法即可。IpentahoConnection已经进行了说明,下图为IpentahoResultSet接口:
没有定义任何变量。下图为IpentahoMetaData接口定义:
看起来sql的简单,但是注意其getColumnHeaders对象,实现起来可能复杂了。
getRowHeaders很少见,哪里采用rowHeaders呢,首先想到了mondrain的查询结果,也会有行头的。