gdmoreno

IntroductionIn this article, we learn how to connect the Apache web server to the Tomcat server, and how to write re-direct rules. The key benefit of this is that it allows us to write re-direct rules in Apache to serve up static files directly, rather than having to go through Tomcat, which is less efficient and adds needless load. This article assumes that you have already installed a Tomcat server somewhere. It doesn't go through how to install the Apache web server on a system, other than to point out a simple way to install it on Ubuntu systems. Setting up the Apache web server on UbuntuThis will vary from system to system. If you have Ubuntu, you can download it and install it like this, from the command line: $ sudo apt-get install apache2[/code]This will install Apache 2 to your environment. In a typical Ubuntu installation, the web root is in /var/www, and the configuration files are in /etc/apache2. Enable the AJP Connector on TomcatYou'll need to enable the AJP Connector in Tomcat, so that the Apache web server can redirect requests meant for JRS from Apache to Tomcat. You did by editing Tomcat's server.xml file, and making sure that the connector below is active and not commented out. <!-- Define an AJP 1.3 Connector on port 8009 --><Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />[/code]You'll need to restart the Tomcat server for this change to take effect. Installing and configuring mod_jk on UbuntuMod_jk is an Apache web server module that allows the web server to interface with the Tomcat application server. Installing it and configuring it are the keys to getting the web server and the application server working together. $ sudo apt-get install libapache2-mod-jk[/code]Execute this command to activate the new configuration: /etc/init.d/apache2 restart[/code]Edit or create the /etc/apache2/workers.properties file: # Define 1 real worker using ajp13worker.list=worker1# Set properties for worker1 (ajp13)worker.worker1.type=ajp13worker.worker1.host=localhostworker.worker1.port=8009[/code]Now reference this file in the /etc/apache2/apache2.conf by adding these lines: JkWorkersFile /etc/apache2/workers.properties# Where to put jk shared memory# Update this path to match your local state directory or logs directoryJkShmFile /var/log/apache2/mod_jk.shm# Where to put jk logs# Update this path to match your logs directory location (put mod_jk.log next to access_log)JkLogFile /var/log/apache2/mod_jk.log# Set the jk log level [debug/error/info]JkLogLevel info# Select the timestamp log formatJkLogStampFormat "[ %a %b %d %H:%M:%S %Y ] "[/code]TroubleshootingWhen restarting the Apache web server, it's possible that you may get a JkWorkersFile only allowed once error message after making that last modification to apache.conf; that's because the workers file has been defined elsewhere. If that happens, you can check the mods-available directory for the jk.conf file, which will contain an entry to the JkWorkersFile directive. The directive will specify where workers.properties file is located, and you can edit it to either add your own worker configuration to it, or, what is more likely, to use a worker that's already defined there that takes care of the AJP connector. In that case, all you have to do if undo the changes you made to the apache2.conf file, and reference the worker in the 000-default file. That step is covered in the next section. Configure which URLs to manage with ApacheAt this point, you'll need to configure Apache to tell it which URLs to process and hand off to Tomcat, and which URLs you want Apache itself to process. For both cases, you'll need to modify /etc/apache2/sites-enabled/000-default. You can add entries right below the "DocumentRoot" line, within the VirtualHost settings. Add the following line under the DocumentRoot entry. This makes it so that you can request JRS via the Apache web server. JkMount /jasperserver-pro* worker1[/code]Save the file, and restart the apache service (/etc/init.d/apache2 restart). If you now go to http://localhost/jasperserver-pro, you should see the normal JasperReports Server login screen. What you have accomplished so far is to put the Apache web server in front of Tomcat. Add the JkUnMount directiveSo far so good, but we still need a better of dealing with static files. The modification so far passes every single JRS request from Apache to Tomcat, including requests for static files. We want Apache to serve up static files and not have Tomcat do it. Apache is much better suited for serving up static files than Tomcat, and by taking this approach we lighten Tomcat's load. Tomcat can now concentrate on serving up dynamic application content. The steps for putting this in place are: Copying over the static files from the web application to the Apache web server rootAdd "JkUnMount" entries that intercept these incoming requestsRestart the Apache web server.The example I did deals with the "scripts" folder containing JavaScript files. I followed these steps: I created the /var/www/jasperserver-pro folderI copied over scripts folder from the JRS web application to the above directory.I added the "JkUnMount" entry below, right under the JkMount entry I had added before:JkUnMount /jasperserver-pro/scripts* worker1[/code]You can repeat this process as many items as you want; all you need to do is create additional "JkUnMount" entries to the /etc/apache2/sites-enabled/000-default file. After you're done, you'll need to re-start Apache by running this command: /etc/init.d/apache2 restart[/code]How to verify that it's workingA simple way of verifying that the configuration is working is to request one of the files that Apache should serve up and then verify the logs - it should show up in Apache's logs, and not in the Tomcat logs. For example, request this file with the browser: http://localhost/jasperserver-pro/scripts/resource.base.js[/code]We had previously added a "JkUnMount" entry for the scripts folder, and we had also copied the scripts folder to Apache's web root (/var/www). So when we look at the logs, this request should show up in Apache's log files (somewhere like /var/logs/apache2/access.log, as defined in the apache2.conf file). You can also verify the Tomcat logs, and you will see that the file request wasn't processed by Tomcat.

IntroductionWhen installing TIBCO JasperReports® Server on a running Tomcat 6 server without a web server such as Apache, Tomcat 6 assumes the roles of both web server AND application server. This dual role is fine in most cases, especially when JasperReports Server is running internally behind a corporate firewall, but we should recognize that Tomcat isn't an ideal web server. Once server loads start to go up, you should consider setting up a web server such as Apache in front of your Tomcat server, which gives you better options for serving up static content and also lightens Tomcat's load. See http://httpd.apache.org/docs/2.2/caching.html and http://httpd.apache.org/docs/2.2/mod/mod_expires.html. However, if you have to stay with Tomcat, you can also implement a "cache filter" mechanism, which decreases the number of times that static files get requested by a browser. The cache filter effectively intercepts a server response, and gives it an "expiration value" far into the future, which it then adds to the HTTP response header. When the browser gets the response back with the expiration value in the distant future, it will know not to request that file again, and to simply pull it from its own browser cache. This strategy is very effective for dealing with static files such as CSS, JavaScript, static HTML and image files. This article deals specifically with how to set up a cache on Tomcat 6. You could apply the solution we present here to Tomcat 7, or you could use the built-in cache filter that Tomcat 7 ships with. This solution also works with JBoss 7. Download the Cache filter here: CacheFilterJar.zip This cache filter is released under an open source Apache License 2.0. The JAR file comes packaged up with the source files. Additional documentation may be found at the cache-filter project. What the Cache Filter doesThe Cache Filter is a JAR file containing Java CLASS files that modify the outgoing HTTP headers. Without a cache filter, you can expect to see something like the image below (I used Firebug to capture the HTTP traffic). The fact that the "Expires" value is in the past forces the browser to request this file every single time. This isn't efficient, especially for static files such as this CSS file, because not only does this file not change, but Tomcat itself is forced to process the request. The key is to be able to change the outgoing value here so it doesn't expire, or that it expires at a date far into the future. A Tomcat server with the cache filter in place will return header values like the ones below: In this particular case, this CSS page expires a week into the future. Deploying the Cache FilterTo deploy the cache filter, download the JAR file, which you can find in the Introduction section of this article. Then: Stop your Tomcat serverCopy the cachefilter.jar file to [TOMCAT_HOME]/webapps/jasperserver-pro/WEB-INF/libModify the [TOMCAT_HOME]/webapps/jasperserver-pro/WEB-INF/web.xml file The purpose of modifying this file is to map the file types that the cache filter will be processing. We do this by defining the URL pattern we're looking for (or just the file extension, as in the example below). Add this section anywhere you want within the web.xml file. <filter> <filter-name>imagesCache</filter-name> <filter-class>com.samaxes.filter.CacheFilter</filter-class> <init-param> <param-name>static</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>expirationTime</param-name> <param-value>2592000</param-value> </init-param> </filter> <filter> <filter-name>cssCache</filter-name> <filter-class>com.samaxes.filter.CacheFilter</filter-class> <init-param> <param-name>expirationTime</param-name> <param-value>604800</param-value> </init-param> </filter> <filter> <filter-name>jsCache</filter-name> <filter-class>com.samaxes.filter.CacheFilter</filter-class> <init-param> <param-name>private</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>expirationTime</param-name> <param-value>216000</param-value> </init-param> </filter> This sets up the different filters, and gives them expiration values that get added to the time when the server request was made. The values are in seconds; 216000 corresponds to two and a half days, 604800 corresponds to seven full days, and 2592000 corresponds to 30 full days. The next item is to add the filter mapping to this same file. In the example below, we look for specific file extensions; you are not limited to the ones we added there. Add this section to another part of the same file: <filter-mapping> <filter-name>cssCache</filter-name> <url-pattern>*.css</url-pattern> </filter-mapping> <filter-mapping> <filter-name>jsCache</filter-name> <url-pattern>*.js</url-pattern> </filter-mapping> <filter-mapping> <filter-name>imagesCache</filter-name> <url-pattern>*.png</url-pattern> <url-pattern>*.gif</url-pattern> <url-pattern>*.jpg</url-pattern> </filter-mapping> Restart the Tomcat serverTest!Cache Control filter in 5.xBeginning with v5.1 an internal JasperReports Server cache control filter was created. The expires time is configurable in web.xml in the StaticFilesCacheControlFilter filter and AppThemeServlet servlet, the default is 1 day (86400 seconds). The StaticFilesCacheControlFilter takes a space-delimited list of files as shown in the config snippet below. Image files such as .jpg, .png and .gif are served from the AppThemeServlet, which sets the expires time. <filter> <filter-name>StaticFilesCacheControlFilter</filter-name> <filter-class>com.jaspersoft.jasperserver.war.StaticFilesCacheControlFilter</filter-class> <init-param> <param-name>urlEndsWith</param-name> <param-value>.js .htm .html</param-value> </init-param> <init-param> <param-name>expiresAfterAccessInSecs</param-name> <param-value>86400</param-value> </init-param> </filter> <servlet> <servlet-name>AppThemeServlet</servlet-name> <servlet-class>com.jaspersoft.jasperserver.war.themes.ThemeResolverServlet</servlet-class> <init-param> <param-name>expiresAfterAccessInSecs</param-name> <param-value>86400</param-value> </init-param> </servlet> Cache Control filter in 6.xIn 6.x the Cache Control filters have been built into the JRS product, so no additional configuration is necessary. In 6.0 thru 6.1.1 see the StaticFilesCacheControlFilter in web.xml, in 6.2.0 thru 6.3 see resourceHTTPHeadersFilter in applicationContext-webapp.xml.

Introduction The database tester is a simple command line tool that lets you test Oracle, Postgres, and MySQL databases for their speed in executing queries. You can configure what queries to execute and what database test against. You get value in using this tool when you test it from different locations in a network, which will allow you to detect any latency issues that might exist. You can download the zip file containing the tool from dbtester.zip Executing a runnable JAR The tool is a runnable JAR file, which takes two arguments. The first argument is the db.properties file, which contains the information the tool needs to connect to the database. The second argument is the list of queries that the tool will run and time. The tool will return data in a comma-delimited format, which you can save to a CSV file for more analysis. To use it, run it from the command line like this: % java -jar dbtester.jar db.properties queries.txt Configuring the db.properties file The db.properties file contains a set of key-value pairs, which contains the information the tool needs to connect to the database. For example, it might look like this: hostname=localhost portNumber=5432 dbName=jasperserver dbType=postgres dbUsername=postgres dbPassword=password Here is the list of parameters you can use: hostname The hostname or IP address where the database lives portNumber The port that the database listens on. Usually it's 3306 for MySQL, 1521 for Oracle, and 5432 for Postgres dbName The Name of database. For example, "sugarcrm", "foodmart", "jasperserver", etc. dbType Right now, the values available are "oracle", "postgres", or "mysql" dbUsername The username for the database account dbPassword The password for the database account delimiter The JDBC URL and service name delimiter. By default, it's the ":" character, but when using Oracle service names, the delimiter is "/" showJdbcUrl This will output the JDBC URL if its value is set to "true"; by default it's "false" printQueries This will output the queries it's testing if its value is set to "true"; by default it's "false" Configuring the queries.txt file The queries.txt file contains the list of queries that the tool will test. It expects to have one query per line, so if you have a multi-line queries, make sure you've joined them up as one line. Here's an example of a queries.txt file: SELECT COUNT(1) FROM JITENANT SELECT COUNT(1) FROM JIUSER The key is choosing good queries. You can do this by enabling the JDBC query logger in JRS, and then pulling out a few interesting queries from the log files. This will give you good insight into database execution times. Executing the tool After you have configured the two files, you run it from the command line: $ java -jar dbtester.jar db.properties queries.txt Query Executed,No. of Times Executed,Elapsed Time (only query execution),Total Elapsed Time (including connection time) 1,50,36,135 2,50,19,38 1,500,183,203 2,500,159,178 1,2000,731,752 2,2000,538,559 As you can see, the output is in the form of comma-delimited data, which you can save to a CSV file, which will allow you to do more analysis with a a desktop tool like Excel. $ java -jar dbtester.jar db.properties queries.txt > test_results.csv The above command saves the results to a file, which you can then view with Excel, and do the analysis you are used to doing. Interpreting the results The key is to compare one set of results with another - compare the results between running the test in one machine versus another, for example, to measure the effects of network latency. For example, if you ran the tool from the host that's running the database, you would expect it to be a lot faster than from the host that's running the application server. However, would you expect it to be five times slower? If it was that much slower, then it's time to start evaluating network issues. Other Performance Tips: Measure and Test Do Performance Testing with JMeter Measure Ad Hoc Performance Ad Hoc Set query limits on the "Ad Hoc Options" page Modify the Ad Hoc caching values if your data does not update constantly Tomcat Compress HTTP responses at the Tomcat level Increase the maximum thread count at the Tomcat level Set up a cache filter for Tomcat or JBoss Disable automatic deployment on production servers using Tomcat Database Index columns in the database to speed up domain-based reports Set the fetch size in the jasperreports.properties file to modify the number of rows to fetch JasperReports Configuration Items Modify Virtualizer Settings for Very Large Reports Modify the jasperreports.properties file to disable multi-line data processing Back to JasperReports Server Performance Tips and Tricks dbtester.zip

When adding a data source to JasperReports Server, there are several areas that could introduce errors. This article is intended to assist in troubleshooting some common issues when setting up JasperReports Server Data Sources. [toc on_off::hide=0 box::collapsed=1]General IssuesLoggingOften the quickest way to find the issue is to increase the logging. Find the following section in .../webapps/jasperserver-pro/WEB-INF/log4j.properties and uncomment the relevant logger: #JDBC Connection Logging#log4j.logger.com.jaspersoft.jasperserver.api.engine.jasperreports.service.impl.JdbcDataSourceService=DEBUG, stdout, fileout#log4j.logger.com.jaspersoft.jasperserver.api.engine.jasperreports.service.impl.JndiJdbcDataSourceService=DEBUG, stdout, fileout#log4j.logger.com.jaspersoft.jasperserver.war.action.ReportDataSourceAction=DEBUG, stdout, fileout#log4j.logger.com.jaspersoft.commons.datarator.JdbcDataSet=DEBUG, stdout, fileout#log4j.logger.com.jaspersoft.jasperserver.war.common.JasperServerUtil=DEBUG, stdout, fileout#log4j.logger.com.jaspersoft.commons.semantic.dsimpl.JdbcDataSetFactory=DEBUG, stdout, fileout#log4j.logger.com.jaspersoft.commons.semantic.metaapi.impl.jdbc.BaseJdbcMetaDataFactoryImpl=DEBUG, stdout, fileout#log4j.logger.com.jaspersoft.jasperserver.war.validation.ReportDataSourceValidator=DEBUG, stdout, fileout[/code]Database DriverEnsure Driver is in the ClasspathJasperReports Server ships with drivers for several databases, including MySQL, Oracle, PostgreSQL, etc. It is important to ensure that the drivers for your database are included in the JasperReports Server classpath. Ensure that the Driver Class Name is correctThe following are some example driver class names for various databases: DatabaseDriver PathMySQLcom.mysql.jdbc.DriverIngrescom.ingres.jdbc.IngresDriverOracleoracle.jdbc.OracleDriverDB2com.ibm.db2.jcc.DB2DriverSQL Servercom.microsoft.sqlserver.jdbc.SQLServerDriver Database PrivilegesWhen creating Database users, you must ensure that the user has the appropriate permissions to your database as well as from the server that JasperReports Server is running on. Permissions Required to the DatabaseThe database user that is used within your data source definition should have the appropriate select permissions to query the tables within your database for the reports you wish to generate. The easiest way to troubleshoot this is to use a tool, such as SquirrelSQL or other database query tool, to run various queries against your database. Ensuring Permission from JasperReports ServerMany databases, including MySQL, also require the user grants to include the specific host from which connections are allowed. Otherwise, when testing the JDBC connection, a connection may not be allowed even though the username and password are correct. For example, you may refer to the following page for Setting up MySQL users: http://dev.mysql.com/doc/refman/5.1/en/adding-users.html An fairly easy way to test connectivity from the server to that database location with a particular user is to use a tool such as SquirrelSQL or another DB query tool to connect to the database from the same host as JasperReports Server. JDBC Data Source IssuesEnsure Database URL is correctEnsure that the Database URL string entered when defining your JDBC Connection is consistent with what is required for your specific database and database driver. DatabaseExample Connection URLMySQLjdbc:mysql://localhost:3306/jasperserver?useUnicode=true&characterEncoding=UTF-8Oraclejdbc:oracle:thin:@localhost:1521:orclPostgreSQLjdbc:postgresql://localhost:5432/jasperserverSQL Serverjdbc:sqlserver://localhost:1433; databaseName=jasperserver;SelectMethod=cursorDB2jdbc:db2://localhost:50000/jsprsrvr:driverType=4; fullyMaterializeLobData=true;fullyMaterializeInputStreams=true; progressiveStreaming=2;progresssiveLocators=2;currentSchema=JSPRSRVRIngresjdbc:ingres://localhost:II7/jasperserver;CURSOR=READONLY;auto=multi JNDI DataSource IssuesJNDI is handled by your application server, check the documentation of your application server for help with JNDI data sources. TomcatEnsure the driver for your database connection is in the <tomcat>/lib folder. Ensure you've created entries in both the context.xml and web.xml files. Here is an example for a mysql JNDI connection: <resource auth="Container" driverclassname="com.mysql.jdbc.Driver" maxactive="100" maxidle="30" maxwait="10000" name="jdbc/YOUR_DATABASE" password="YOUR_PASSWORD" testonborrow="true" type="javax.sql.DataSource" url="jdbc:mysql://YOUR_HOST:3306/YOUR_DATABASE?autoReconnect=true&autoReconnectForPools=true" username="YOUR_USERNAME" validationquery="SELECT 1"></resource>[/code]In <tomcat>/webapps/jasperserver-pro/WEB-INF/web.xml: <resource-ref> <description>JNDI Example</description> <res-ref-name>jdbc/YOUR_DATABASE</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth></resource-ref>[/code]If you installed JasperReports Server from a WAR file, Tomcat may have created a separate copy of context.xml in <tomcat>/conf/Catalina/Localhost/jasperserver-pro.xml. See the Install Guide's Troubleshooting Section Special Configuration Case under Tomcat for more detail. Also see the Tomcat documentation for JNDI data sources. Glassfish > Oracle GlassFish Server Administration Guide > Administering the Java Naming and Directory Interface (JNDI) Service OracleConfiguring a JNDI entry should be straightforward - start by copying an existing Resource entry and modifying it to use the right driver and URL. The big "gotcha" to watch out for is the value for the validationQuery attribute; MySQL and Postgres can take "SELECT 1" but Oracle cannot; instead use "SELECT 1 FROM DUAL" and that should work. MsSQLConfiguring MsSQL involves many things and enumerating all possible source of issue would be too long to be described here and generally unrelated with JasperReports. Situation:One thing though which can happen is, in the situation when you use MsSQL setup to use windows authentication credentials and thus you don't need to pass any username or password in the JNDI connection, you may get a connection failure due to the way the Windows Service which starts JasperReports Server is setup. For example if the MsSQL Database is located on a different server than JasperReports Server, the credentials passed for the Windows authentication will be, by default, the one from the server which runs the server and not from the server which runs the database. If this situation happens, the logs (when setup the way described above) will show that the server name is passed as the username. Fix:To fix this you need to restart your server without using the Windows service or to change the log on properties of the service from local to the other account. Also SeeJasperReports Server > Data Sources > Troubleshooting

IntroductionBy default, at the ad hoc design level, values get displayed "as is" without any formatting. JasperReports Server comes with a set of pre-defined formatting options that you can apply to columns on a report, but what do you do if you want to enable other options? In this article, we look into adding more currency for numeric values. Out-of-the-box functionalityWhen using the ad hoc report designer, numeric values get displayed "as is" in the designer, such as in the screen shot below In this article, we consider formatting numeric values, and we take a closer look at formatting for currency symbols. The method we'll take a look applies to other situations as well. We can change the formatting for numeric values by right-clicking on the column we're interested in, and then choosing the style we want, as in the screen shot below: Then we can go ahead and choose the currency format we want, and we would get a result as in the screen shot below However, the list of choices is limited, and so the question becomes how do we add more choices to that list? Understanding the configuration fileYou can manage the formatting options for numeric values by editing the adhoc_masks.properties file, which you can find under the web application root in the /jasperserver-pro/WEB-INF/bundles directory. Let's focus on adding more formatting options for decimal values. We find the section below in the file: ADH_100_MASK_dec_0 = #,##0.00 ADH_100_MASK_dec_1 = 0 ADH_100_MASK_dec_2 = $#,##0.00;($#,##0.00) ADH_100_MASK_dec_3 = $#,##0;($#,##0) ADH_100_MASK_dec_4 = EUR #,##0;(EUR #,##0) ADH_100_MASK_dec_5 = u20AC #,##0;(u20AC #,##0) [/code]The first four entries correspond to what's available by default in JasperReports Server. I added the last two entries to display "EUR" before a value (the ISO code for the euro) and the € symbol itself; u20AC is the Unicode value for the euro. Using the € symbol itself may or not work with your environment, and using the Unicode value itself insures that you won't encounter character set issues. After modifying that file and restarting the server, you can go ahead and test the formatting options for ad hoc decimal values - first we see that there are extra values now available from which to choose: And by choosing the format we're interested in, we see that we can mix currency symbols as in the screenshot below Other Currency CodesHere's a table with some common currency codes: CurrencyUnicode ValueBritish Pound (£)u00A3Japanese Yen (¥)u00A5Euro (€)u20ACIndian Rupeeu20A8Chinese Yuanu3350

IntroductionTypically when wanting to improve ad hoc performance, we consider the domain itself and figure out ways to optimize its structure, volume, or security. There are other strategies we can try that fall outside fixing the domain itself. Domain OptimizationsBy analyzing the actual SQL queries that the domain generates, we can often get a sense of what needs to be optimized. A slow-running query can often be optimized by adding indexes to the database, along with other database-specific strategies. Filter IssuesWhen creating filters, the queries should ideally hit the dimension tables and not the fact tables; the fact tables are usually much, much larger, and can really slow down filter creation. By analyzing a domain, we can see where the table joins are being made; the display values should reference the values from the dimension tables, where appropriate. This may need some re-factoring of the domain definition. A key goal here is that it if there are existing ad hoc reports, that the new domain definition doesn't break any existing ad hoc reports. Two OptionsThere are two other options to think about to get better ad hoc performance. These options are outside what we typically do with domains, in that our typical strategies focus on tuning the domain itself along with the underlying database. As a recap, those strategies include: Limiting the size of the domain - applying filters to the data Denormalizing the database somewhat, to simplify the domain definition - this speeds up the domain's performance Optimizing database lookups by adding indexesThe other two options fall outside the sphere of domains, but would accomplish the goal of getting better performance. Option 1 : Using Topics InsteadTopics are a lot simpler than domains. You can create a topic by simply creating a report that you then save in the topics folder. The user would then create an ad hoc report by choosing the "Topics" link that pops up, where it would display the topic you saved there. The advantage of this approach is that since a topic has an SQL-based report behind the scenes, you can tune and optimize the SQL request to whatever degree you want, in whatever way is appropriate for the situation, without having the server have to go through the extra step of processing the domain's request before turning it into SQL (SQL that's not necessarily optimal). The result of this would be faster times at the report design stage. Since topics are based on a single SQL query, that means they would contain less data than you would find in a domain, so you could conceivably separate the "Assignment Data" set of your Analytics domain into a single (but complex) query; you would have to see if that makes sense in your case. The disadvantage is that you would have to find other ways than using the domain's security file to impose row- and column-level security; you would have to incorporate that into the topic query itself. That means that you would have to have access to a user's profile information, which is available to you in iReport via a special variable. Option 2 : Using one environment for ad hoc report design, and another for its executionIn this approach, you have the user go through the report design process in an environment that has the same exact domain definition but less data in the database. The advantage of this is that the report design stage goes a lot faster (since you control the volume of data in the database). The challenge then becomes how to take that ad hoc report and have it point to the real database. There's some options in here, but they would involve customizing the application somewhat; you wouldn't be modifying the way ad hoc itself behaves but rather what datasource the ad hoc report points to after it gets saved to the repository. Note on Option 2: Since Jaspersoft 4.7 a feature was introduced to allow limiting data at design time ("Sample Data") and issuing a "LIMIT BY" style clause. You can read more here.