Pentaho与mondrain笔记(二)

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的查询结果，也会有行头的。