Basically, each chart in instantOLAP is bound to a single pivot table. Overlay charts work generally in the same way, but because an overlay chart is composed from two or more charts, we will also need more than one pivot table to feed the chart with data – each table feeds a single chart. So the first step is to create a block which contains multiple tables.

Providing the chart data

To create the first table, just use the “New pivot table” button from the right toolbar of the query editor. A new block, containing a single and empty table, will appear. Now drag a fact and a data series to the table, in out example this will be the “Amount” Fact and PRODUCT level from the Product dimension of the instantOLAP demo model.

Now you can add a second pivot table to the existing block by opening the context menu of the block (use the right mouse button on the title bar of the block). Use the menu item “Add pivot table” of the menu to add a second and emtpy table.

Because we want the new table to show data for the same samples, you should use the same iteration for the x-axis of the new new table as you did in the previous table. Only the fact in the y-axis will be a different one, in our example we will use the “Quantity” fact from the demo model.

This was the basic step for each chart generation: creating the source table(s) for your chart.

Setting the chart format

It’s time to turn the table into chart: Use the context menu of the block and choose one of the overlay chart types. In out example we’ll use the “Bar / Line” chart which turns the first table into a bar chart and the second into a line chart.

If you execute the query now, you may recognize that there are really two charts, but the second one (the line chart) only displays a flat line at the bottom of the image. This is because till now both charts share the same range and the values for the fact “Amount” much bigger than for the fact “Quantity” (or its line). Therefire it’s down to the bottom. and we’ll have to add a second range to the chart and to scale the line to this new range.

Creating a second range

First of all you’ll have to activate the second range. There is a property named “Range 2 On” which has to be set to “true”. If you execute the query now you will see a second range, but the rest of the chart will look like before, including the  flat line chart.

This is because you must assign each of the chart to the ranges. By default, both charts are assigned to the range number 1, which is the default range at the left side of the chart. To re-assign the second (the line) chart to the new range at the right side, use the property “(Overlay) Series Range” property and set it to “2″ (use “1″ for the first range and “2″ for the second). If you execute the query now you’ll recognize the line beeing scaled over the full image.

Now, you have created an overlay chart with two source tables and two ranges.

Related posts

• No related posts.

Because of copyright reasons, only a few drivers are included in the instantOLAP standard distribution (an open source driver for Sybase and Microsoft SQL-Server and a second driver for HSQLDB databases). For all other database servers, you can find the driver in the internet. This is a list of the common database servers and some internet addresses where to find the driver.

How to install a new driver under Tomcat

If you use Apache Tomcat as your Application Server (which is the default Application Server installed together with instantOLAP), installing a new driver is very simple:

1. Download the driver from the vendors driver page
2. If neccesary, extract the driver or execute the driver installer to extract the driver files onto your hard disk.
3. Locate the driver files (they always end with .jar) and copy them into the library folder of your Tomcat server. Depending on the Tomcat version, the library folder is <tomcat>/common/lib (for Tomcat 5.5) or <tomcat>/lib (for Tomcat 6)
4. Restart Tomcat

How to use drivers in instantOLAP

After you installed the driver in your Application Server you can use from instantOLAP. Generally there are two different ways to access a driver or database: You can connect the server directly out of instantOLAP or you can use a predefined datasource, which has to be prepared inside the Application Server. For testing, developing or small installations, we recommend the first alternative.

To connect a database directly out of instantOLAP, simply use the “Add datasource” button when you are inside the “Datasources” section of a configuration. This will open a datasource wizard, which asks you for the name, driver, connection URL and credentials of the target database. Refer our online documentation for more details.

JDBC drivers for database servers

Microsoft SQL-Server

There are at least two good drivers for the Microsofts SQL-Server: The original Microsoft JDBC driver and the open source driver jDTS for Microsoft SQL and Sybase databases, which is included in the instantOLAP standard distribution.

Microsoft SQL-Server (original driver)

The original Microsoft JDBC driver can be found and downloaded from the Microsoft page.

• Download: Microsoft SQL Server JDBC Driver 2.0
• Driver file(s): sqljdbc.jar
• Driver class: com.microsoft.sqlserver.jdbc.SQLServerDriver
• Connection-URL: jdbc:sqlserver://<server>[:<port>];databasename=<database>

Escpecially in older versions of the originial driver, it is important to know how to form the connection URL. You must include the database name in your URL, otherwise you will be able to see the tables but not to access their content.

Microsoft SQL-Server (jDTS open source driver)

jDTS is an open source alternative for Microsoft SQL and Sybase databases and already included in the instantOLAP standard distribution.

• Download: http://jtds.sourceforge.net
• Driver files(s):  jdts-<version>.jar
• Driver class: net.sourceforge.jtds.jdbc.Driver
• Connection-URL: jdbc:jtds:sqlserver://<server>[:<port>][/<database>]

MySQL

When using MySQL databases, make sure to use the most current available driver version, because older drivers may cause problems with newer versions of the database.

• Download page: http://dev.mysql.com/downloads/#connector-j
• Driver file(s): mysql-connector-java-<version>-bin.jar
• Driver class: com.mysql.jdbc.Driver
• Connection-URL: jdbc:mysql://<server>/<database>

Oracle

For Oracle databases it is imporant to use the correct version of the driver which matches the version of your database server. The drivers for all version can be downloaded from the Oracle page, but you will need to create an account before (if you don’t have already).

• Download: Oracle JDBC/UCP Download Page
• Driver file(s): ojdbc15.jar or ojdbc16.jar
• Driver class: oracle.jdbc.driver.OracleDriver
• Connection-URL: jdbc:oracle:thin:@<server>:1521:<database>

Sybase

Like in the case of Microsoft SQL Server, you can use the original Sybase driver or the open source driver jDTS to connect a Sybase driver.

Sybase (original Sybase driver jConnect)

• Download: jConnect – Software Developer Kit
• Driver file(s): jconn3.jar
• Driver class: com.sybase.jdbc2.jdbc.SybDriver
• Connection-URL: jdbc:sybase:Tds:<server>[:<port>]/<database>

Sybase (jDTS open source driver)

jDTS is an open source alternative for Microsoft SQL and Sybase databases and already included in the instantOLAP standard distribution.

• Download: http://jtds.sourceforge.net
• Driver file(s): jtds-<version>.jar
• Driver class: net.sourceforge.jtds.jdbc.Driver
• Connection-URL: jdbc:jtds:sybase://<server>[:<port>][/<database>]

IBM DB/2

For all current versions of DB/2 you can use the Universal Database Driver (UDB) from DB/2. However, when you wan’t to connect a DB/2 database running on a mainframe system, you’ll have to purchase an additional license from IBM.

• Download: IBM – Application Development with DB/2 (Follow the links and download the DB/2 client)
• Driver file(s): db2jcc.jar
• Driver class: com.ibm.db2.jcc.DB2Driver
• Connection-URL: jdbc:db2://<server>[:<port>]/<database>

Informix

Since IBM bought the Informix database, you can find the Informix drivers on the IBM homepage now, too:

• Download: IBM Software Downloads
• Driver file(s): ifxjdbc.jar
• Driver class: com.informix.jdbc.IfxDriver
• Connection-URL: jdbc:informix-sqli://<host>:<port>/<database>:informixserver=<dbservername>

Related posts

• No related posts.

The tool is very useful whenever instantOLAP loads its data from a data-warehouse and you want to rebuild certain models, dimensions or cubes after the ETL tool rebuild the warehouse or added new data to it.

This article describes, how to use the tool from batch-files or other Java applications (most ETL tools can call native Java commands) and which operations are available.

The console is delivered as a simple Java archive (jar file) and is located in the folder <instantOLAP>/tools/console. You can use the archive from this location or copy it to another computer – no other resource (except a local Java installation) is needed to execute the application.

Starting the console (interactive mode)

To start the console in the interactive mode, use the command:

java -jar iolapConsole.jar <server-url> <user> <password>

where <server-url> is the complete url to the backend-service of your instantOLAP-server and <user> and <password> are the credentials for your administrator account. E.g. the command for a local installation on port 8080 and with the administrator account would be:

java -jar iolapConsole.jar http://localhost:8080/iolapWS admin admin

If the jar file is not located in the current folder, you can also type its whole path (relative or absolute). After you logged successfully into the server, you will see the following welcome message:

instantOLAP console
(c) 2006-2009 Thomas Behrends Softwareentwicklung e.K.
Connecting server http://localhost:8080/iolapWS...
ok
>

Now you can use one of following commands to control the server:

Commands

BUILDDIMENSION <model> <dimension>

This command rebuilds a single dimension of a model (and all dimensions being dependend on this). The command expects the model name and dimension name as argument.

Example:

> BUILDDIMENSION demo/demo Product
Building dimension Product of model demo/demo...

BUILDDIMENSIONS <model>

This command rebuilds all dimensions of the specified model. The only argument the command expects is the name of the model.

Example:

> BUILDDIMENSIONS demo/demo
Building dimensions of model demo/demo...

BUILDSTORE <model> <store>

The command BUILDSTORE rebuilds a single store of the specified model, the store name has to be passed as second argument.

Example:

> BUILDSTORE demo/demo store1
Building store store1 of model demo/demo...

BUILDSTORES <model>

Rebuilds all stores of the specified model.

Example:

> BUILDSTORES demo/demo
Building stores of model demo/demo...

CLEARCACHE <cache>

Use the command CLEARCACHE to empty a single cache of the model. After the execution, the cache still exists but contains no entries.

Example:

> CLEARCACHE demo/demo cache1
Clearing cache cache1 of model demo/demo...

CLEARCACHES

This command clear all caches of the specified model.

Example:

> CLEARCACHES demo/demo
Clearing caches of model demo/demo...

CLEARSTORE <model> <store>

Clears a single store of the model and brings it into the “offline” state. Dependend on the configuration settings, the model will continue using the original adhoc version of the store, otherwise the system will immediatley start to rebuild the store again.

Example:

> CLEARSTORE demo/demo store1
Clearing store store1 of model demo/demo...

CLEARSTORES <model>

This command clears all stores of the model. Like in the CLEARSTORE command, the system will immediatley rebuild all stores dependend on the configuration settings.

Example:

> CLEARSTORES demo/demo
Clearing stores of model demo/demo...

LISTDIMENSIONS <model>

This command returns a list of all dimensions of the specified model.

Example:

> LISTDIMENSIONS demo/demo
Agency
Anim
Campaigns
Manufacturer
Product
Time

LISTMODELS

Returns a list of all models on your server, including the active and inactive ones. For each model, the current state is append as text. The following states are possible:

• ONLINE: The model is started and ready
• BUILD: The model is currently starting
• CLOSED: The model is currently not started
• CLOSING: The model is currently shutting down
• SYNC: The model is started and currently synchronizing its dimensions and / or cubes
• ERROR: The model is not started because an error ocurred while starting it

Example:

> LISTMODELS
demo/demo (ONLINE)
eventlog/eventlog (ONLINE)

MODELSTATE <model>

This function returns the state of a specific model. The state is returned as number in this functions, the following states are possible:

• 0 = CLOSED
• 1 = BUILD
• 2 = ONLINE
• 3 = SYNC
• 4 = ERROR
• 5 = CLOSING

Example:

> MODELSTATE demo/demo
Request model-state for demo/demo...
State = 2

QUIT

This command stops the console.

STARTSYNC <model> <timeout>

This function starts the synchronize process for a model, in which it is checking its cubes and dimensions if they are outaged. You must pass the timeout for the synchronize process in ms as second argument. This function is only useful if you want to synchronize the model immediatly, because the system synchronizes all its online models each minute.

Example:

> STARTSYNC demo/demo 1000
Starting model demo/demo synchronize...

STOP <model>

This command shuts down the specified model.

Example:

> STOP demo/demo
Stopping model demo/demo...
ok

START <model>

This command starts the specified model.

Example:

>START demo/demo
Starting model demo/demo asynchron...

Using the console in batch mode

The batch mode can be used to call the console from external batch files and to execute commands without user interaction. To execute a command, just add it and its arguments behind the standard arguments of the console, the syntax for the batch mode is:

java -jar iolapConsole.jar <server> <user> <pwd> <command> [<arg1> [<arg2> [...] ] ]

If you call the console in batch mode, it will immediatley execute the passed command and then exit. E.g. the following line

java -jar iolapConsole.jar http://localost:8080/iolapWS admin admin START demo/demo

would start the model “demo/demo” on a local server running on port 8080 and then return.

Not that all commands, also in the interactive mode, only fork the requested operation on the server and then return without waiting for the operation to be finished. However, if you send a number of commands for the same model to server, they will be queued and executed in sequential order.

Related posts

• No related posts.

This article describes how to implement such access rules in two steps for the customer / region example.

Step 1: Add a user dimension to your model

Before you can use the user information in access rules, you must make them available inside the model. The only ways to do this is to load the information into a dimension. Use normal SQL-KeyLoader to access the user-database and to load the user information. There are two basic rules when creating a user dimension:

• The dimension must at least contain the exact user-IDs at keys. The user keys can be loaded to the top-level or they can be grouped (e.g. to users groups), but they must be inside the dimension and contain the login-IDs.
• All IDs for keys from other dimension to which the user should have access to must be stored as attributes in the user-keys. E.g. the list of all region IDs could be loaded as attribute “regions”. Later, you can use this attribute to match its values with the region-keys.

Step 2: Add access rules to your other dimensions

Now you can add access rules to your other dimension by referencing the current user-key and its attributes. Switch to the access rule editor by selecting the “Access” tabulator and start adding the rules to the dimension, e.g. to this “Customer” dimension.

The first part of your access rule has to find the current user key in the “User” dimension, because the user key is not automatically selected when the user executes a query. You could select the user in the query itself (in its “Filter” property) or you can use the FIND function in the access rules. The last solution is the better one because in this case you does not need to change every query (and you cannot forget this in future queries). The expression to find the current user is:

FIND( User, USER() )

where “User” is the name of your user dimension (you need to change it if your user-dimension has a different name). The function USER returns the name of the current user (his login). Because we search with the users login-name, it must exactly match the ID of the key in your dimension.

After you located the user key, you can use its attributes. E.g. if the user key has an attribute “regions”, which contains alle region id the user should have access to, the expression

FIND( User, USER() ).regions

will return the region codes. The result can contain no, one or multiple values (of course, a sales representive could be more responsible for more than one region).

Now the last thing is to match this region codes with the customer dimension. It is important to use relative expressions here and to match the REGION level (!) with the attribute, not the keys of the Customer dimension. E.g. the expression

{REGION} IN FIND( User, USER() ).regions

would convert the region name of the current customer, region (or whatever currently is selected) into a string and test its occurence in the region list of the user. Because REGION is a relative expression, this works for all levels of dimension: A customer is only visible if it belongs to a listed region, the regions itself is only visible if listed, and the root key of the Customer dimesion is only visible if one of the regions is listed.

Of course, you could also match the lowest level or match more than one level, but in most cases this is the typical expression we use for access restrictions. Sometimes it is neccesary to use dimension links – e.g. if the customer and region are stored in different dimensions, you would have to change the expression into something like:

{CUSTOMER.region} IN FIND( User, USER() ).regions

This only works, if the customer and region dimension are linked.

The last step is to add access rules for administrators or CEOs, which usually are allowed to see all keys of all dimensions. This can be done by a role-check in an additional access rule. The simple expression

HASROLE( 'iolapAdmin' )

would grant access to all keys for a user owning the role “iolapAdmin”. The expression always returns “true” if the user own this role, independend on the keys.

Related posts

• No related posts.

This must be done before sending any SQL statement to the databases and in instantOLAP this is realized with the internal “ToDo List”, which lists all needed cells and tries to resolve the source for each cell (when running a reports, you can see the generation of the ToDo-List in the Log). There is a maximum size for ToDo-Lists, and if the lists exceed this limit, the system raises the “Query too complex” error. The default maximum size for this ToDo-List is 250.000 cells, but it can be changed easily in the configuration. However, increasing the maximum will result in longer running and more memory-using reports.

There are several possible strategies to avoid large ToDo-List, and some of them are only available in our new version 2.5 or later:

1. Try to calculate as much as possible inside the database: E.g. if you only have a “Quantity” and “Product price” stored in the database, the “Turnaround” (calculated by Quantity * Price) could be realized with a formula. But this formula would add 2 additional entries to the ToDo-List (for each “Turnaround” cell, an additional “Quantity” and “Price” would be necessary) and the list would become three times bigger than needed. If you use the database to calculate this fact and use a SQL expression like “SUM( table1.quantity * table.price)”, the SQL cube could deliver the fact on itself and the ToDo-List would remain small.
2. Use LOOKUPs: When creating large and sparse reports, where only a small percentage of the cells will be filled with data, instantOLAP will also generate ToDo-Entries for this empty cells. If you use the LOOKUP function to eliminate empty rows or columns in ahead, you can reduce the size of the ToDo-List dramatically.
3. CLUSTER your selections: One of the main reasons for large ToDo-Lists are multiple- and range-selectors. E.g. if you have a small pivot table but a range-selector for months and a display aggregated fact (like SUM(Amount()) in your cells, the system will need to load the amount for each cell in combination with each selected month. So, the ToDo-list for 15 selected months would be 15 times larger than for a single month. But you can use the CLUSTER function in your query filter and reduce the number of selected keys for the time dimension. The CLUSTER function replaces selection by their parent, if all of its children are selected. E.g. if you select a whole year, the function will replace the months by their parent year key.
4. Use offline cubes: Since version 2.5, there is no need for any ToDo-List if every cube in the model is in the offline mode. Then, instantOLAP has to generate no SQL statements (and no ToDo-Lists) and every data will be loaded directly out of the offline stores.

Related posts

• No related posts.