Configuring Domains

Advanced uses of Domains may consider these configurations:

Disabling the Domain Validation Check
Setting the Level of Referential Integrity
Optimizing Snowflake Schema Joins

When you use Domains with certain database constructs, you may need to configure JasperReports Server:

Enabling Oracle Synonyms
Enabling CLOB Fields
Enabling Proprietary Types
Extending JDBC Type Mapping
Accessing Materialized Views
Modifying Domain Calculated Field Variable Behavior

Disabling the Domain Validation Check

By default, JasperReports Server validates a Domain against its data source to ensure that the Domain design maps properly to the underlying tables. This validation occurs when a Domain design file is uploaded to the server. If your data source is very large and complex, this validation can take time. If the validation takes too long, you can disable it. In this case, JasperReports Server assumes the Domain design is valid, and simply uploads it without the check.

To disable the validation edit the following configuration file:

Configuring Domain Validation Check

Configuration File

.../WEB-INF/applicationContext-semanticLayer.xml

Property

Bean

Description

skipDomainDatabase
Validation

slConfig

Set this property to TRUE to disable the validation check.

If the tables and fields referenced in the Domain design don't exist in the data source when skipDomainDatabaseValidation is set to TRUE, the Domain wizard won't detect the problem, but the Choose Data wizard returns errors when your end users work with the Domain.

Setting the Level of Referential Integrity

Referential integrity is the verification process that occurs when opening an Ad Hoc view or a report that is based on a Domain. The server checks that all fields and measures referenced by the view or the report match those defined in the Domain. This ensures that out-of-date views or reports cannot be run if they rely on items in the Domain that were modified or removed.

In practice, when you modify a Domain to remove fields or measures, you must also modify all Ad Hoc views that depend on those fields and measures, and you must regenerate any reports based on those views. In case you don't, referential integrity will give an error so that the user knows why the report did not run, instead of failing at runtime or showing empty data. When opening an Ad Hoc view that has similar referential integrity errors, the server displays a list of missing fields and measures and prompts you to removes the items so the view is coherent when it opens.

However, in cases where Domain security makes a field unavailable to a user, this will also be detected as a referential integrity error upon opening a view or running a report. Some views and their corresponding reports may be designed for multiple users with different security access to data, and you intend to display the report with blank or zero in place of certain data. In such cases, you should change the default setting for referential integrity so that users can open views and run reports without causing an error.

Configuring Referential Integrity

Configuration File

.../WEB-INF/applicationContext-adhoc-dataStrategy.xml

Property

Default

Description

checkSourcesInStrictMode

true

By default (when true) when opening an Ad Hoc view, any mismatch between its fields and those in the Domain it references trigger a missing data dialog in the Ad Hoc editor and prompt the user to remove those fields.

When this configuration is set to false, the following referential integrity errors are allowed:

The item's table ID or join ID does not match the one in the Domain, provided its unique item ID still matches one in another set or subset.
The item's type does not match the one in the Domain, provided the item is not used in any filter, calculated field, or summary function that is incompatible with the altered type.

Referential integrity issues that do not meet these criteria will still trigger a missing data dialog in the Ad Hoc editor, even if this setting is false. For example, if an aggregation on a numerical field in the view is set to Average, but the field in the Domain is now a string, an error is triggered because strings cannot be averaged.

skipCheckSourcesForViews

false

When rendering an Ad Hoc view based on a Domain, the server checks that all fields and measures in the view match those of the Domain. By default (when this setting is false), if there missing fields, the sever will display an error and not display the view.

When this setting is true, the server will render the view even if some fields are missing for any reason, for example if they are hidden due to security in the Domain. This setting is more permissive of referential integrity errors than checkSourcesInStrictMode above.

skipCheckSourcesForReports

false

When running a report based on an Ad Hoc view based on a Domain, the server checks that all fields and measures in the report match those of the Domain. By default (when this setting is false), if there is a mismatch, the sever will display an error and not run the report.

When this setting is true, the server will run the report with missing fields and the result depends on the severity of any mismatch. Fields that are hidden due to security in a properly designed report will appear blank or zero. A report where the missing field leads to a computatuion error will cause the running report to fail.

If you change the referential integrity settings in order to allow certain reports to work with Domain security, you should make sure those reports work as intended for all users and ensure all other reports run correctly. If you later remove fields or measures from your Domains, you should also be diligent in manually updating all views and reports that depend on those Domains.

Optimizing Snowflake Schema Joins

When creating a Domain on top of a snowflake schema, the default joins generated when using the Domain in the Ad Hoc Editor may take a long time and include dimensions not used in the report. For example, a schema with over a hundred dimension tables mostly connected to a subset of 5-10 fact tables may cause such behavior. The following setting can be enabled to optimize the joins generated for such a snowflake database schema. The default setting has better performance in the more common cases with fewer tables.

Configuring Domain Join Optimization

Configuration File

.../WEB-INF/applicationContext-semanticLayer.xml

Property

Bean

Description

specialOptimizationOn

graph
Operations

The default setting of false handles typical cases of Domains based on 10-100 tables. For snowflake schemas that typically have 100 or more tables, or for database topologies that cause slow join performance in Ad Hoc views, set this property to true to optimize the joins in the Ad Hoc Editor.

Enabling Oracle Synonyms

By default, Domains can't access synonyms in an Oracle database. Settings to enable them vary depending on your application server. The settings shown here apply to Apache Tomcat. Your application server may require different values. Set the following property to enable Oracle synonyms on Tomcat. If you access your Oracle database through JNDI, you also need to configure the JNDI connection.

Be aware that the Oracle metadata service is significantly slower when synonyms are in scope.

Enabling Oracle Synonyms

Configuration File

.../WEB-INF/applicationContext-jdbc-metadata.xml

Property

Bean

Description

includeSynonyms
ForOracle

jdbcMeta
Configuration

Set the value to true:

<value>true</value>

Configuration File

.../META-INF/context.xml

Property

Bean

Description

accessToUnderlying
ConnectionAllowed

<Resourcename=
"jdbc/oracle"...

If you use JNDI, add the following property:

accessToUnderlying
ConnectionAllowed="true"

Enabling CLOB Fields

Support for CLOB (Character Large Object) fields is dependent on your database and must be enabled manually. If you want to access CLOB fields in JasperReports Server, set the following options according to your database.

The Oracle JDBC driver implementation uses the CLOB JDBC type for CLOB fields.

CLOB Support for Oracle

Configuration File

.../WEB-INF/applicationContext-jdbc-metadata.xml

Property

Bean

Description

jdbc2JavaType
Mapping

jdbcMeta
Configuration

This property contains a map of database field types to Java types. Find the line for CLOB that is commented out:

<!--entry key="CLOB" value=""/-->

Modify it as follows:

<entry key="CLOB" value="java.lang.String"/>

The MySQL JDBC driver implementation uses either the CLOB JDBC type, the LONGVARBINARY JDBC type, or both to represent CLOB fields, depending on their length.

CLOB Support for MySQL

Configuration File

.../WEB-INF/applicationContext-jdbc-metadata.xml

Property

Bean

Description

jdbc2JavaType
Mapping

jdbcMeta
Configuration

This property contains a map of database field types to Java types. Find the following lines:

<!--entry key="CLOB" value=""/-->
<!--entry key="LONGVARBINARY" value=""/-->

And modify them as follows:

<entry key="CLOB" value="java.lang.String"/>
<entry key="LONGVARBINARY" value="java.lang.String"/>

Due to a limitation, CLOB and NTEXT fields cannot be sorted or compared in a query. For example, trying to add a CLOB field as a crosstab column with domain query optimization enabled will result in an error message.

Enabling Proprietary Types

JasperReports Server provides a JDBC-to-Java type mapping for all standard JDBC column types for use in Domains. However, some databases have proprietary types that you may need to map to a Java type with a special configuration. Some proprietary types, such as NVARCHAR2 for Oracle, are already mapped by default.

As a prerequisite, the proprietary type must be logically equivalent to one of following Java classes:

java.lang.Boolean

java.lang.Byte

java.lang.Character

java.lang.Double

java.lang.Float

java.lang.Integer

java.lang.Long

java.lang.Short

java.lang.String

java.math.BigDecimal

java.sql.Date

java.sql.Time

java.sql.Timestamp

java.util.Date

There are two ways to create a mapping for a proprietary type, as shown in the following table:

Modify the generic mapping for NUMERIC types. By default, any numeric type that doesn't match one of the other types is mapped to BigDecimal.
Create a secondary mapping under the special OTHER key, where the secondary key can be your custom type name.

Proprietary Database Type Mapping

Configuration File

.../WEB-INF/applicationContext-jdbc-metadata.xml

Properties

Bean

Description

jdbc2Java
TypeMapping

jdbcMeta
Configuration

If your proprietary type is not already defined in this file, you can add it:

To modify the generic mapping, edit this line:
<entry key="NUMERIC" value="java.math.BigDecimal"/>
To add a secondary key to the OTHER key, follow this example:
<entry key="OTHER">
    <map>
        <entry key="NVARCHAR2" value="java.lang.String"/>
    </map>
</entry>

Extending JDBC Type Mapping

Some database types are not even mapped to a JDBC type. In particular, Oracle uses TIMESTAMP WITH TIME ZONE and TIMESTAMP WITH LOCAL TIME ZONE that must be mapped in order to appear in JasperReports Server. If there are other types in your database, you can override or extend the JDBC type mapping with the following configuration:

Extending JDBC Type Mapping

Configuration File

.../WEB-INF/applicationContext-jdbc-metadata.xml

Property

Bean

Description

codeToJdbcType
Mapping

jdbcMeta
Configuration

This property contains a map of database type codes to JDBC types. By default the codes for Oracle TIMESTAMP types are mapped:

<entry key="-101" value="TIMESTAMP"/>
<entry key="-102" value="TIMESTAMP"/>

Add or replace these entries to map additional types from your database.

Accessing Materialized Views

Domains access tables and views by default, but some databases support other structures such as materialized views. These alternate table structures don't show up by default, but you can often configure Domains to display and access them.

If the JDBC driver for your database assigns a standard table type identifier to the materialized view, you can access it in Domains, Ad Hoc views, and reports. To find the table type, use a JDBC client such as the SQuirreL tool to view your database schema. In SQuirreL, use the “Objects” tab to browse the tables and views organized by table type. Look for your materialized view and note its table type.

The table type values are defined in the DatabaseMetaData.html.getTables() documentation. When you know the string corresponding to your table type, add it to the following configuration value:

Accessing Materialized Views

Configuration File

.../WEB-INF/applicationContext-jdbc-metadata.xml

Property

Bean

Description

tableTypes

jdbcMeta
Configuration

Uncomment the JDBC table type corresponding to the materialized view or other table structure in your databases, for example:

<value>LOCAL TEMPORARY</value>

Modifying Domain Calculated Field Variable Behavior

The property resolveDomainCalcFieldVariableInAdvance included in WEB-INF/applicationContext-adhoc-dataStrategy.xml for bean id="commonDomainDataStrategy" allows you to calculate a domain calculated field in two ways. The default value is set to false, and the behavior overrides the lookupExpression(Variable var) in ColumnCalculation.

For example, if you have a domain calculated field expression such as “coverage / allowance”, it will translate to sum(coverage) / sum(allowance) instead of sum(coverage / allowance).

You can change the default domain calculated field variable behavior to use a sum aggregation (the original behavior prior to JasperReports Server 7.8) with the following configuration:

Modifying Domain Calculated Field Variable Behavior

Configuration File

.../WEB-INF/applicationContext-adhoc-dataStrategy.xml

Property

Bean

Description

resolveDomainCalcFieldVariableInAdvance

commonDomainDataStrategy

Set value to true:

<property name="resolveDomainCalcFieldVariableInAdvance" value="true"/>