How Do You Configure Your Reporting Platform?

DZone 's Guide to

How Do You Configure Your Reporting Platform?

· Java Zone ·
Free Resource

Following previous articles ‘How do you make your reports? ‘ and ‘How do you use your reports?’ the last one will show some of the configuration you may need on your server. A reporting platform that it is not configurable may not be considered a real option.  Using Spring allows for easy configuration of any kind of beans even if they are created for server business or for user interface.

1.Platform Settings

As any server application, you need some properties specified in properties files or any other storage place. You need to define urls and home directories, storage like data sources or repositories, define your mail server, configure your scheduler and any other settings your reporting server needs. These kinds of properties can be of two types : those which are set once at startup and will not be modified in the future and those which can be modified more often by administrators. Latter ones may be customer-dependent and it is a good practice to allow for their modification directly from server user interface.

2. Business Settings

Any report, chart, scheduler job may have some properties which are defined by the user. Here we can think at report parameters, exporting formats, chart types, all settings used to define a scheduler job.

3. Cache Settings

Any reporting platform must take into account a cache to reduce the number of hits to your storage. Even if you have only one chart in a dashboard, if many concurrent users are viewing it, without a cache the system will choke soon or later. NextReports Server allows defining cache settings for all entities that can be added to dashboards : charts, table reports, alarm reports, and user can set an expiration time in minutes, if cache is used.

4. Integration

You want to integrate your server with other applications. But your application has its security, its  users and it will be cumbersome to create all your users with their passwords to your reporting server. Even more, if some user is added later, modified or deleted you have to update users on the reporting server. This is an impossible task. So if you want to take advantage of your application security, the reporting server must offer a synchronization job. Depending on what type of security your application has, this job must be something customized to your needs. NextReports defines a process which brings and updates the users into the content repository. A simple xml configuration will define synchronization process with a database. You must specify your data source and your queries to get users names and users attributes (which allows mapping any fields you may have to NextReports Server repository):  

<bean id="syncUserDetailsService" class="com.asf.nextserver.security.DatabaseExternalUsersService">
  <property name="dataSource" ref="syncDataSource"/>
  <property name="userNamesQuery">
   <value>SELECT USER_NAME FROM USERS</value>         
  <property name="userQuery">
    <value>SELECT * FROM USERS WHERE USER_NAME = ?</value>
  <property name="mapping">
      <!--  required -->
      <entry key="user.username" value="USER_NAME"/>

You also have to think about integration with more than one application. In this case you will have more synchronization jobs and you must extend your reporting server with a 'realm' definition. Think of it as a domain which can be for example the name of the application. In that case your login must contain principal, credentials and realm.

5. Profiles

You may need sometimes to customize your reporting server to allow your users to see less or more from your UI regarding functionality. Do not mistake this with security where you have permissions  to see what data is visible to users.   NextReports Server uses a profile concept which is attached to users that are not administrators. A profile specifies two things :

  • what UI functionality can be seen by users with such profile : perhaps some users only want to look at results in dashboards, others may just want to configure their scheduler jobs, and others are interested in monitoring and so on.
  • what actions need to be hidden  for users with such profile not because they do not have the permissions, but just because they are not interested.

 Configuration may be done in an xml file like this :

<bean id="businessAnalystProfile" class="com.asf.nextserver.security.Profile">
  <property name="name" value="businessAnalyst"/>
<property name="displayName" value="Business Analyst"/>
<property name="sectionIds">
   . . .           
<property name="hiddenActionContributorIds">
    . . . 

In this way it is very easy to add new profiles with your desired functionality (sections) and visible actions making NextReports Server integration with your application as easy as possible.

6. Single Sign On

If you need a Single Sign On so that once the user is connected in its application, it will not be asked for credentials on the reporting platform, Spring comes to the rescue with CAS integration. NextReports Server allows integration with all your applications through Single Sign On using CAS.

To define your CAS , a validation ticket must be written which will inform about cas login and cas logout urls:    

<bean id="ticketValidator" class="com.asf.nextserver.web.security.cas.CasServiceTicketValidator">

  <constructor-arg index="0" value="https://myurl:myport/cas"/>
  <property name="loginUrl" value="https://myurl:myport/cas/login"/>
  <property name="logoutUrl" value="https://myurl:myport/cas/logout"/>

Spring has support for CAS integration through a filter :

<bean id="casProcessingFilter" class="org.springframework.security.ui.cas.CasProcessingFilter">
  <property name="authenticationManager" ref="authenticationManager"/>
  <property name="defaultTargetUrl" value="/app/"/>
  <property name="filterProcessesUrl" value="/app/j_spring_cas_security_check"/>

To use his casProcesingFilter, you have to add it to the filter chain proxy :

<bean id="filterChainProxy" class="org.springframework.security.util.FilterChainProxy">
  <security:filter-chain-map path-type="ant">                       
<security:filter-chain pattern="/**" filters="httpSessionContextIntegrationFilter, casProcessingFilter"/>                  

7. Modularity & UI Configuration

It  is a good practice to customize how your user interface looks and your functionality directly from xml configuration files. In this way you can create loosely coupled functionality (you can contribute) and when you want to add or remove it from your application you just need to modify this xml file. For example if we want to customize what actions will be seen for scheduler jobs we can define what are those which are global (menu action), what are those for a specific entity (popup action) and what are those for multiple selection (bulk action). This may be considered as something similar to plugins.  

<bean id="schedulerSection" class="com.asf.nextserver.web.schedule.SchedulerSection">
  <property name="menuContributors">           
<bean class="com.asf.nextserver.web.action.SearchEntityActionContributor"/>           
  <property name="popupContributors">
     <bean class="com.asf.nextserver.web.action.schedule.ModifyActionContributor"/>
      <bean class="com.asf.nextserver.web.action.schedule.HistoryActionContributor"/>
 <property name="bulkMenuContributors">           
<bean class="com.asf.nextserver.web.action.DeleteActionContributor"/>           

Depending on your needs there are many other things you can consider and of course there are many ways in which you can apply them.



Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}