Together with this update, we provide a complete new query reference with dozends of new screenshots and descriptions. In the next update, we will also add the interactive documentation to the Workbench, both for the query and configuration editor.

Continue reading to see the release notes for 3.1 update 1.

• Online documentation added to the property editor of the report editor. Just click onto a property with the mouse to display the documentation for a certain property.
• Export format “XSLX” added to automation tasks (export and mail).
• The table designer now uses SCREENY() to colorize every 2nd row. This will give you good results, even if the query suppresses some of the table rows.

• A new property “Cache Grants” was added to the dimensions. When activated, the system will cache the access rules for certain users and keys. When using complex access rules, this can improve the performance of the system.

• Report names are shown behind the file names in the explorer

Continue reading and find the relases notes for update attached to this post.

• Like version 2.7 or less, 3.0 now uses IFrames to display large tables. This increases the performance and lowers the memory usage of the Browsers.
• A new block format “googlechart” has been added. GoogleCharts allow to add interactive charts like maps or sortable tables.
• A new attribute “suggestion count” has beed added to SuggestBoxes. The number of suggestions was by default 20 but can be changed with this attribute now.
• Progress bars now display the current duration of a process (in seconds).
• A new print argument “USER” was added and can be used in word templates as field.
• Invisible rows and columns are no longer exported (before they only had the width or height 0).
• Word-Templates can now be addressed relativley (e.g. with a path “../templates/template.dot”).
• The frontend now longer reports “Query killed” when restarting a running report. The message was also caused by interacting and reloading selectors with “Use Filter = true”.
• CTRL-A is now also supported for Chrome and Safari Browsers in the property editor.
• The send automation now has a “Query String” property which allows to set the filter for a report. This allows to send the same report multiple times with different selection.
• The “Add automation” menu item of the query viewer now opens a dialog which allows to edit the Query String for an automation (like in the bookmark editor).
• The Folder Editor now warns about changed content when closing it.
• Bugfix: The color editor throwed error messages when editing complex color expressions or multiple colors (comma separated).
• Bugfix: The query editor created two comment blocks when using the “add block/ comment” menu item.
• Bugfix: Some minor display bugs in tables with fixed headers, mainly for IE, have been fixed.
• Bugfix: A pagebreak caused an error when a report was exported as Word or PDF documents.
• Bugfix: The vertical space for rotated texts in Word or PDF exports was too small.
• Bugfix: Bold fonts now work better in Word and PDF exports.
• Bugfix: Visible = false did not hide blocks when exporting to Excel.
• Bugfix: Charts with title were to small in “Fit To Screen” mode.
• Bugfix: Firefox somtimes suppressed the left or upper border of a table.

• The server now logs filters AND parameters (e.g. from names selectors) on DEBUG level.
• An escape character ^ was added to expressions (e.g. use ^\ to add the character \ to an expression).
• The colors for exception can now be modified in the iolapWS.xml file.
• Store warnings are logged unique now, you’ll no longer see the same key being reported over and over again.
• The new Property “Always show corner” allows to show the corner of a query even if no X- or Y-axis exists (e.g. for empty list reports).
• The new Property “Show empty headers” allows to remove empty headers if the iteration returned no keys.
• Bugfix: The timeouts for model builds were possibly too short when starting multiple models at the same time.
• Bugfix: Models with fatal errors (e.g. broken XML files) weren’t displayed in the ModelManager.
• Bugfix: Stores were build with “Build offline stores = false” when they did no exist at model startup and had a cron pattern.
• Bugfix: The cache caused problems with reports using the LineDimension (List reports).

• The Workbench now shows both the license number and the first for characters of license code in the license manager.
• Configurations can be cryted and decrypted with a password now.
• Bugfix: The chart generator added an invalid paramter “samplevaluecolors” (This caused error messages in the server log).
• Bugfix: Table links where created without the ‘ delimiter, causing error messages when linking tables with spaces or illegal characters in their name.

• Selectors now lose their selection if their options change and the old selection is not part of the new options
• Better start zoom for Geo Charts (the charts fills the block 100% now) andmore data types for shape DBF files supported
• Hierarchy selectors now also support hierarchies with missing levels (in example if the user has no access to a whole level)
• The new reset button for queries resets all selectors to their default selection
• Better IE support for tables with fixed headers
• Better performance for the model tree in the query editor with large models
• Dimensions are now displayed with their caption in the query editor
• Scrollbars added for selectors wider than the Browser window
• The automation editor in the Browser now allows to edit the iteration
• The visible property for selectors and selector groups is now supported
• Wider color editor (the toolbar wasn’t completely visible in all Browsers)
• The report title is now optionally visible in Fit-To-Screen mode (use the new property “Show Property”)
• Table block with ONLY width or height now also become scrollable tables
• The block title now fits to the font size
• Icon paths for folders and reports can be relative now
• The new “Search from Start” property for SuggestBoxes allows to search for Items beginning (instead of containing) the text
• The __hidePortal parameter is now only valid for a single window instead for the whole session
• The new property “fontFolder” allows to locate the font folder for PDF export  if the system is unable to locate it automatically
• Bugfix: SuggestBoxes inside a popup selector group have been displayed behind the group
• Bugfix: The needSelection property now works with input fields
• Bugfix: The permalinks are now selectable in Chrome and Safari
• Bugfix: A font size in comments caused an IOException when exporting to Excel
• Bugfix: Rotated headers fixed
• Bugfix: The query converter for reports from older versions now also converts tables with multiple sub-queries
• Bugfix: Default selection for Interval Selectors is now displayed
• Bugfix: A deadlock situation opened too many threads and caused memory problems
• Bugfix: Better cleanup for temporary files
• Bugfix: FileUpload now works with Chrome and Safari Browsers

• SQL Expression can be used in Table Links now
• Cache size and compression level for dimension and store files are now configurable with properties
• Better performance for file caches
• Values without a mapping are mapped to the root key when loaded into a Store. This makes totals equal to the values queried from an adhoc cube.
• Better read performance for Stores
• New Function YTDR (equal to YTD but with support for large filters with multiple keys)
• The FORECAST function now returns NULL values instead of NaN for unpredictable cells
• The engine is now fully compatible with reports from version 2.2 – 2.6 (By default, ToDo lists are generated cell wise)
• Improved access control (if the root key is read protected, all headers with the key will be removed even if they do not iterate over the protected dimension)
• Bugfix: Filter for Blocks and Reports fixed
• Bugfix: Match for multiple Stores for the same adhoc cube fixed
• Bugfix: Selectors with name and key options now select the id of the keys (was <dimension>:’<id>’ before)

Version 3.0 comes with a fresh and new interface, new flexible report and dashboard layout possibilities, two web-based report editors for both experts and novice users, a new template based export engine and much much more…

Continue reading for an updated overview of the new features and the release notes.

We cleaned up and gave instantOLAP 3 a fresher and clearer design with less buttons and tabulators but more functionality. Not much to write here, just have a look onto the following screenshots.

instantOLAP 3 allows to interactivly change content and the look&feel of your reports while watching them. A couple of new “designers” can be opened while watching a report, including a designer for the pivot-table content, a designer for the table-layout, a designer for charts and others.

The Query Designer allows to add axes, facts and selectors to your report with single mouse clicks. You can also rearrange your reports, add Top 10 filters and do many things more inside the designer without having any knowledge of instantOLAP queries.

The Table Designer offers a large number of predefined table designs. Simply change the look & feel of your report by selecting one of them. Of course, after you selected on the designs, you can change it afterwards by changing the table properties.

The Block Designer is very similar to the Table Designer but changes the look & feel of the containing blocks. Like the Table Designer, it offers a number of predefined layouts where you can choose from.

Another very useful is the Chart Designer. It automatically turns your query into one of the predefined charts. A large number of chart layout are offered, including 3D versions of every available chart type.

First of all, we broke the fixed block structure of queries and created a new, more flexible alternative. Now you can nest as much blocks as you want and as deep as you want. E.g. it is possible now to nest complete reports in tabulator block and to build huge executive reports which contain all neccesary data in one page.

Also, the selectors are no longer limited to stay at the top of the query, they can also be placed in any other block and every block can have its own selector. You may even place the selector at the left, right or bottom border of your blocks.

Of course, the old query structure will automatically converted in the current one and every existing query will be compatible with version 3.

The new option “Fit To Screen” for reports lets them use the whole available space on the screen. This is very nice e.g. for building dashboards.

All blocks will be displayed inside the screen without the need to scroll the report in order to see blocks outside the screen. If you enlarge browser window, all blocks will be enlarged immediately, too.

Because in this mode the content of the blocks can be larger than the block itself, all tables will automatically display as scrollable tables with fixed headers. Images and maps will be zoomed to the size of their block. All other content like IFrames or commets will be displayed with scroll bars if the content is too large.

We also introduced two new block types, the “IFrames” and “Query-Imports”. IFrames allow to display other HTML pages within your reports and to enrich them with other content. Query-Imports display other queries inside the importing query as if they were part of it itself.

And – you can include other queries as a block by using the “Query Import” format. This allows to reuse and to build dashboards by putting multiple queries together!

Another great change is how the queries load their content: Until now, every query was executed and displayed as a monolithic block, but now every block can update its content without the need to refresh other blocks. E.g. drilldown inside a table can become much more comfortable, because only the block containing the table has to be refreshed.

Also, blocks now do not load their content until it is needed. E.g. tabbed blocks will only load the data of their visible tab and dynamically load the other tabs content when the user selects them. Additionally, blocks can be collapsed and only load their data when the user expands them. This allows to build fast dashboards which load their data only on demand.

A much requested feature was to use multiple models in a single query. In instantOALP 3, each query can use a different model and you can generate reports with data from multiple models. Even the selectors work with different models if the dimensions have the same name. The only limit is that a single table or chart may only use a single model.

This is surely one of the greatest features in instantOLAP 3: This version will contain a fully functional and powerful query editor, even more mighty than the editor included in the Workbench of previous versions.

The new editor used the same layout and look & feel like the Workbench version – including drag & drop – but contains a couple of new improvements:

• First of all, it reflects the new block structure, this means you can nest blocks as you want and create selectors everywhere. A large number of new context menus will help you to arrange blocks and to change their format.
• Also, the new Designers from the Query Viewer are available in the editor. This means, you can also design tables or turn them into predefined charts within the editor with a few mouse clicks.
• The property editor has the same functionality as the Workbench version. Properties are now group in the web front end and Workbench.
• The query editor will use the powerful expression editor of the portal which allows a much more powerful editing of expressions, including Top 10 requests, dimension searches, saved expressions and much more. We also improved the expression editor between version 2.7 to version 3.
• A zoom function allows to keep the whole report in sight when editing large reports.

In difference to our first planning, the Workbench still contains the query editor (now compatible with the new query structure).

With the final version 3, we changed the export engine for PDF exports and added the new DOC export (compatible with MS Word). Both export formats use the same engine.

The new export format is based on document templates (either MS Word or Open Office format). instantOLAP uses this templates as the base for exports and appends the report content to them. Templates can contain images, headers, footers, an index, fields and anything else. Some report informations (like the name, title or author) are passed to the template as fields and can be used anywhere in the exported documents.

Each report can use its own template – the new property “Export Template” allows to specify the template for a report.

By default, instantOLAP comes with three predefined templates, a “normal” template (DIN A4), a template with index and a landscape version. All templates contain the instantOLAP logo which can be easily replaced with your company logo. All default templates are placed in the folder “stylesheets” inside the repository.

Because the size and orientation of the document is now defined by the template, all export properties for the size have been removed (Print Width and Print Height). Also, the logo is now defined by the template and not by the report itself. Therefore, the “Print Logo” property has been removed from the report and folder properties.

By default, reports are now exported without the original block layout of the report and all blocks are exported below each other. Because reports can contain many nested block since version 3, this is necessary in order to keep the exported documents readable.

With the new export property “Keep Block Layout”, you can force a report to export it block with nearly the same block layout as the screen version – e.g. images will be placed next to tables etc.

These release notes only contain the differences between the final version and the release candidate. To see all differences between 2.7 and 3.0, you should also read the release notes of 3.0 RC.

• Browser support for Internet Explorer 9 and Firefox 4/5 added
• Better compability with Safari browser (resizing the repository, restoring the scrollposition when switching between reports etc)
• Better compability with Internet Explorer 7 and 8
• New export format (Microsoft DOC format) added. The new format uses DOT templates, which can be changed or extended by the customer. Also, the PDF export now uses the same technology and is just a PDF output of the DOC export. Because of the templates, the page size and export label properties for reports have been deleted.
• Improved import of 2.x reports (importing border colors and block aligns)
• The repository search now also searches in the description of reports
• XML export can now be enabled / disabled with the new property “Enable XML export”
• Permalink option added to export menu
• Invisible cells are not exported to charts
• Bugifx: Targets for chart links were ignored

• New function GETDAYOFWEEK was added
• Less memory usage for large reports
• Concurrent license codes can be assigned to user names now
• Better compability with the newer versions of the Tomcat server (newer Tomcats can change the JSESSION id of a running session at any time)

• Reports and Configurations can be opened in “Read only” mode, even if the file is currently locked by another user

• Better transaction control for Stores
• Better progress display for Stores
• The DIV function now only write a warning into the log if the second argument has more than one value
• A new function GETDAYOFWEEK was added
• A new property “Connection Properties” for database connections was added
• Bugfix: Less bugs in the server log for suspended dimension- and store-databases
• Bugfix: List reports with data from multiple SQL statements now work

• A new query parameter “Auto Execute Body” allows to disable to automatic generation of the report body. When set to “false”, the body will only be generated if the users uses the execute button. This allows to do all selections in a report without performing the query itself.
• Line breaks in comments are supported now
• Bugfix: Files with equal names were suppressed
• Bugfix: The font size and weight of comments is now used in PDF and Excel exports

The release candidate contains the new front end with all features the final release will have and some new demo reports, which demonstrate the new layout possibilities of 3.0.

In difference to our original plan, the Workbench still contains a report editor and users will be able to create and edit reports in the web front end OR in the Workbench.

Complete, 32-Bit (Windows Installer), Version 3.0.rc, 08.02.2012, 74.9 MB
Workbench, 32 Bit (Windows Installer), Version 3.0.rc, 08.02.2012, 26.1 MB

Server (Linux Installer, RPM) , Version 3.0.rc, 08.02.2012, 69.6 MB

Frontend (WAR-Archive), Version 3.0.rc, 08.02.2012, 19.9 MB
Backend (WAR-Archive), Version 3.0.rc, 08.02.2012, 4.9 MB
Workbench (WAR-Archive), Version 3.0.rc, 08.02.2012, 16.0 MB
Complete (EAR-Archive), Version 3.0.rc, 08.02.2012, 40.5 MB
instantOLAP Console (JAR-Archive), Version 3.0.rc, 08.02.2012, 0.1 MB

• A new block structure was introduced:
  • There is no difference between inner and outer blocks and they can be nested as deep as wanted
  • Each block can contain a selector bar, attached to the top, bottom, left or right of the block.
  • Blocks will load their content individual and parallel to other blocks
  • Tabbed blocks load their content on demand when switching to another tabulator
  • The orientation property of blocks was replaced by the new block formats “vertical”, “horizontal”, “tabbed” and “animated”
• A new designer mode was added and replaces the prior pivot-designer:
  • The designer offers different panels for different report elements, for the report itself, blocks and queries The block designer offers a couple of block designs
  • The query designer allows to add dimensions and levels to axes with a single mouseclick
  • With the table designer, you can switch blocks into tables by using one of  the preformatted layouts
  • The chart designer turns a query into one of the predefined charts
• A new edit mode allows to edit reports inside the browser. In difference to the simple design mode, the editor offers the same ability to build the same complex reports and to edit all existing properties – like in the workbench.
• The frontend has a new look&feel

• The query editor was adopted to the new block structure

We decided to release this version for migration reasons. Customers can install 2.7 and test their existing reports with the new backend without dealing with the new frontend features. The backend will not change between version 2.7 and 3.0 except bug fixes.

Version 3.0 is scheduled for release within the next few weeks. Currently we’re making the Workbench query editor compatible to the new version 3 reports – this means, in difference to our first idea, creating reports will be both avaibable in the Browser and the Workbench.

The new backend has many new and effective internal performance improvements. Mainly the preprocessing of reports has rapidly changed, some types of reports will now execute exponentially faster. Especially reports with large range selectors profit from the new preprocessing algorithm.

The new preprocessing does no longer examine reports “cell by cell”, it rather analyses the whole report at once and creates SQL load instructions for whole regions of a query simultaneously.

Also, the preprocessing for LOOKUP has changed – it does no longer send SQL statements to the database but used the standard proprocessing and loading techniques as the rest of the report engine. This e.g. allows to use nested LOOKUPs in a query which gather their data together and with a single SQL statement.

The very most configuration settings and functions are are still compatible with version 2.6, only LOOKUP and SORT have slightly changed:

• The functions DLOOKUP and DSORT are no longer available and should be simply replaced by LOOKUP and SORT
• The LOOKUP function does no longer treat a dimension name (like LOOKUP(Product)) as a special argument. Instead of this, the current selection of that dimension will be passed to the function and it will perform a lookup over these keys.

SQL Cubes now can rollup your dimensions while loading the data from the underlying database. This is very helpful for unbalanced hierarchies where e.g. only data for leafs is stored in the database. instantOLAP will only load the data for leafs and aggregate it up to the wanted dimensions elements when executing a report.

The new user management of instantOLAP allows to connect with a Windows Domainer controller and to use your existing username, password and roles inside instantOLAP.

We also support Single Sign On (NTLM based) in intranets. SSO will identify and login the user without prompting his username and password. For SSO, the server must run on a Windows. SSO works best with Internet Explorer as client though other Browsers, like FireFox, can also be configured to use it.

The Workbench now supports report previews on Mac OSX machines. Though there is no installer for Mac, the Workbench can be launched from the Java Webstart URL.

There are a few new features in the frontend, mainly a few new design properties and some export improvements:

• PDF tables will now repeat their header lines on new pages
• The export of the current selections can be disabled with the new “Export Selectors” property
• The title of a block can be overriden for exports with the “Export title” property
• The font for the main title can be changed now with the new properties “Title Font”, “Title Font Size” and “Title Color”
• The visibility for cells can now, independent of the header visibility, controlled with the “Cell Visible” property

• A new internal engine now speeds up generating ToDo-Lists, loading data and building reports. The ToDo-List generation was changed from cell-oriented to package- (filter) oriented in order to speed up the list generation.
• The functions DLOOKUP and DSORT no longer exist and have to be replaced by LOOKUP and SORT
• Multiple LOOKUP and nested LOOKUPs inside a report now load their data with a single SQL statement
• Configurations can now specify a global filter for all reports using it
• The Omit-Factor for dimension mappings can now also be specified as a maximum number of keys (instead of a percentage value) with the property “Omit Limit”
• A new property “SQL Fetch Size” allows to set the fetch size for SQL cubes
• A new property “Cell Visible” allows to control the visibility of a cell independent to the header
• The new properties “Title Font” and “Title Font Size” control the font and size of the report title
• Bugfix: The YTD function didn’t work properly with multiple input keys
• Bugfix: Cells of a table now cannot be spanned by the neighbor cells left and above the cell simultaneously

• The default values of a selector are now recalculated if the selector has the option “Use Filter” set to true.
• Calendar-Selectors now allow to specify the selectable range with its options
• Comments now can contains and display line breaks
• Descriptions of selector groups are now displayed a hover texts
• Bugfix: Applet-Charts didn’t display overlay charts correctly
• Bugfix: CalendarRange-Selectors now accept Default-Values
• Bugfix: All types of selectors can now access variables
• Bugfix: The Save and SaveAs dialog now show empty folders
• Bugfix: The font size for comments wasn’t used
• Bugfix: The CRS for ESRI maps (geo charts) is now calculated more accurate

• Support for Mac OSX 32/64 bit added
• The process of a still running query is now killed when leaving the preview
• Table Aliases can now be generated from the context menu of a table in the database explorer
• The original table for aliases and the expression of virtual columns are displayed in the database explorer
• The SQL query tool holds the result for each SQL statement in a single tabulator window
• Better representation of the queries in the Query Editor (correct header size, font size etc)
• Bugfix: A locking problem in the matrix-editor in combination with at least one open preview window was solved

Because the 2.6.2 Workbench is not compatible to previous versions, this is a real new version and no small update like the releases before.

Continue reading to learn about the new features and the release notes of 2.6.2.

The common SQL phrase “CASE WHEN … THEN … ELSE … END” can now be used without escaping it and became an official syntax of our SQL parser.  Using the new CASE phrase allows the SQL parser to investigate the used tables and their types, therefore we strongly recommend to use it instead of its escape version in future.

Of course the target database will only understand this phrase when it’s part of its native syntax, but most database systems support the CASE expression.

Two new properties for the Time-Keyloader allow to fine-tune the weekday generation: “First Day In Week” and “Minimum Days In First Week”. In the past, these properties have been controlled by the locale setting of your server or the Time-Keyloader, but now you can override them manually, too. This is very helpful when binding a period dimension with a database, e.g. when it’s using ISO dates for its data.

When building Stores the number of warnings indicated a problem in the Cube mapping and administrators had to keep open the log view while building the Store in order to see them.

For a better convinience, the log entries are now always stored inside the Store, whether the log view is opened or not, and can be viewed at any time. The new button “Show Store log” in the Model Information dialog will show the log entries in a small viewer dialog.

• The SQL generator now accepts “CASE WHEN … THEN … ELSE … END” phrases without the need to escape them.
• The SQL generator now always generates “IS NULL” instead of “= NULL” for better compability with some databases.
• The SQL generator now generates “<expression> IN (<value>, <value>, …) OR NULL” instead of “<expression> IN (<value>, <value>, …, NULL)”, because some databases don’t accept NULLs in IN listings. The database property “Drop IN With NULL” was dropped in respect of this new syntax.
• Time-Keyloaders allow to set the “Minimum number of days in first week” and the “First day of week” for generating ISO (or other, country specific) calendars.
• A gzip compression was added between the server and the frontend or Workbench for less and faster traffic.
• The LOOKUP now performs became faster on Stores by building internal substores.
• List reports now can recevice data from multiple SQL statements inside the same SQL cube.
• Bugfix: The LOOKUP function now calculates its return type more accurate.
• Bugfix: LOOKUP on stores returned empty results if the searched dimension was part of the original SQL cube but not of the store.
• Bugfix: The vertical space between blocks with multiple line titles has been to small.

• The XML export of reports is now enabled for all users (instead for administrators only).
• The querystring of links do not contain the “All” keys any longer (this was originially introduced in 2.6.0).
• A SuggestionBox-selection can be deleted by clearing the search field and using enter.
• Exported PDF documents now repeat the table headers on each page.
• Bugfix: The default key of TreeSelectors is now visually selected when loading a report
• Bugfix: The tab-colors of tabbed blocks are now using the border color of the embedded blocks
• Bugfix: Scrollable tables with a fixed width and height scaled wrong in PDF documents.

• The model tree inside the Expression editor is now loaded async (which means less waiting time before you can start typing).
• A new “Show store log” button was added to the Model info dialog – this log shows all warnings and error messages from the last Store build.
• The User Manager does no longer delete custom column content from the user tables and only updates the changed columns when editing users or groups.

This (video) tutorial shows how to create GEO charts, starting with a simple background layer. Watch the video or continue reading to learn more about maps in instantOLAP.

This tutorial uses the beta version of instantOLAP 3. Creating Geo Charts with instantOLAP 2.6 works exactly the same way, you’ll only need to design your report with the instantOLAP Workbench, because the web query editor is a new feature of version 3.

The OLAP System uses standard ESRI Shapefiles for the maps. Because the ESRI Shapefile format is very common, nearly every kind of map is available. Various shapefiles can be found for free in the internet or purchased. The instantOLAP default installation contains the free “world_countries_shp” shapefile with the world countries borders, which will be used for this example.

First of all, you will have to create a new block inside your report and change its format into the “Geo Chart” format. After you did this, a number of new properties will appear for this block.

Maps in instantOLAP are organized in background and foreground layers. Each kind of layer can be displayed as polygons, texts or symbols.

The background layers will always be rendered, independend of the table data or anything else. You can use the background layers to display the fixed background information you need for your report, e.g. country borders and country names.

First of all, we will a add a simple background layer to the chart. Simply tell the system where to find the shapefile on the hard disk by filling the property “BG 0 Sourcefile”. Fill in the absolute path here, because shapefiles don’t need to be located inside the instantOLAP repository. Also, if your background and frontend server are located on different machines, this path should be visible for the frontend server.

For this example, the path would be “<instantOLAP>/repository/geodata/World_countries_shp.shp” – whereby <instantOLAP> is the installation path of your instantOLAP server.

After you located the shapefile, it’s time for a test. Execute the report and you should see your first map inside instantOLAP. It displays the world country borders as black borders with empty polygons.

Now you can change some properties of the background layer to change its presentation, e.g. by assigning colors to the properties “BG 0 Background” and “BG 0 Color” (which is the border color).

Now we’ll display the country names in a second background layer. Shapefiles can contain additional informations for each polygon which are stored in a simple DBase database (located in the same folder as the Shapefile itself). There are a number of tools you may use to open and view/edit this database files, including Microsoft Excel.

You max have noticed that additional properties were added to the chart property list after you edited the “BG 0 Sourcefile” property. The editor automatically adds properties for an additional layer whenever you assign a value to a layer sourcefile and this is the location where to add the second layer.

Use the same shapefile for the property “BG 1 Sourcefile” and set the “BG 1 Type” property to “Text” – this will turn the layer  into a text layer. Now you must tell the system which database information you want to display as the text. In our example Shapefile, the country names are stored in the column “NAME” – simply enter this attribute name into the property “BG 1 Text Attribute”.

Data layers are similar to background layers but they only display the fragments of the Shapefiles related to the table data. E.g. a data layer could highlight single countries in certain colors, dependend on a cube value like the turnaround for that country.

Each row of your OLAP query will be related to a single map fragment. Therefore, a data layer needs additional information to link the fragments to the rows of your query. This is realized by matching the header text of the Y-axis with a text attribute of the Shapefile database. E.g. if your query contains ISO country codes in the Y-headers, there must be a database field in the Shapefile with exactly mathing ISO codes.

Adding a data layer works the same as adding a background layer: Enter the absolute path of the shapefile in the property “Data 0 Sourcefile” to create a new layer.

Now you’ll have to match the table with the Shapefile segments: For our example, add a fact (e.g. turnaround) to the X-axis of the table and the level “COUNTRY” of the agency dimension to the Y-axis. Because the COUNTRY level contains the ISO contry codes as keys and the World_countries_shp Shapefile contains these codes as attribute, we can tell the system how to match the headers to the Shapefile. The Shapefile attribute is named “ISO_2″, therefore you’ll have to enter this name in the attribute “Data 0 Text Attribute”.

If you execute the report now you’ll see some new numbers in some countries. This is the table content, mapped to the regions identified by the Y-axis headers which are mapped to the Shapefile regions.

A number of table properties are straight forward displayed in the map, including the background and foreground color of your table cells. Therefore, color coding for maps works the same as for tables – simply change the background color of the Y-axis headers and the polygons in the map will have the same colors as the table would.

In our example, you can add a simple color coding by entering the following expression into the background expression of the Y-Axis header: “IIF( Amount() < 30000000, ‘red’, ‘green’ )”. This will turn the background color to “red” if the turnaround for a country is less than 30 million or to “green” if not.

In instantOLAP, every Cube is by default a ROLAP cube. This is because we believe creating a new cube is very productive with adhoc cubes: You can add new dimensions to cubes or modify mappings and then instantly test the new results without any aggregation process (which may take time).

After you finished the first production quality version of your cube it is time to test its performance and to improve it if neccesary. This is when Offline Stores come into sight.

Since version 2.6 building offline stores is very easy and comfortable: Use the context menu of the cube to add a new Offline Store to it. Then you must decide, which dimensions you want to add to the cube and how you want them to be loaded.

After you added the store, a new column will appear right to the mappings. In this new column you can define, which dimensions and facts you want to be added to the new Store.

Now it’s time to create the most simple form of a store: Add every dimension and fact to the store by clicking into the related cells of the column. A checkmark will show that the dimension or fact is now part of the Store.

Now you should open the Model Manager and fill the Store with data. Locate the Model in the Manager, open the Model Information dialog for “demo/demo” by double clicking the model and switch to the Cubes tab in the dialog.

Here you can see the new Store which replaced its source cube in the Cubes tab. The most important information for Stores is the “State” columns which shows if the Store is currently available (online), not available (offline) or building (online + building or offline + building).

Because our cube is not loaded yet, its state is “offline”. To load the Store, select it and use the “Rebuild” button from the toolbar at the right side. Then wait a few seconds and use the “Refresh” button from the toolbar to view the current state.

Now the store is loaded and the execution time of the demo reports will shrink from seconds to milliseconds. There are a couple of new informations in the table: The build time, the error message for the case the build process stopped with an error, the number of raised warning while loading the data and the Store size.

The Store size, the last reload timestamp and the build time are simple informations from the loading process. The build time show how long it took to load and aggregate the source data and the size shows the effective (compressed) size of the Store. This is not the number of cells the Store can deliver but the number of informations instantOLAP wrote to the local disk. In this oexample, the Store needs 73,863 records to deliver data for 151,632,000 cells, a compression of 2000:1!

The error message and the warnings are very important informations for the case your cube delivers no or wrong data or didn’t load at all.

There are two different ways how to aggregate the values for higher levels of a dimension: By doing a rollup or by querying each single level.

Rolling up means that the system will only query the lowest level and single mapped keys from the database and calculate every upper level manually. Querying the levels means the system will perform one SQL query per level.

Be careful with the query scheme, because usually your Store contains more than one dimension. E.g. if you have three dimensions with three levels, this will perform 27 queries to the database. Ten dimensions with three levels means 118.000 queries, one for each possible combination of each dimension level!

But why should you use the query scheme? There are some reasons you might need this:

• One of your facts uses a COUNT DISTINCT aggregation, and this cannot be calculate by performing a rollup in some cases
• Your hierarchy cannot be calculated by rolling up data because a key value is not the SUM, AVG or else of its children
• Sometimes it can be faster to perform many small queries than a single, large one

Also for facts you can change the aggregation scheme, but here you can change the aggregation formula the system uses. The default value is “default” – then the Store automatically determines the aggregation type from the SQL expression you mapped the fact with. But can also change it manually to one of the aggregations “SUM”, “AVG”, “MIN”, “MAX” etc. This is needed whenever the system is unable to automatically determine the aggregation from the SQL expression or simply want something different.

There are some pitfalls when loading the data of a Cube into a Store. The Store might raise an error or collect warning while its building process. Whenever an error is raised you should, of course, fixed it and reload the Store again. But even warning should always be fixed, because they can be a reason for wrong data. But why can a Store raise errors or warnings when original cube works correct?

There two main reasons and they are not always easy to understand:

• In ROLAP cubes, the cube will of course only load data for the requested dimensions and facts. Which also means it will only use the tables containing information for this dimension and facts. But if you combined, for example, two different fact tables in one cube, the Store will perform one SQL query to gather both facts – and combining two fact tables means a full permutaion of both tables, the numbers get exponentially higher. Maybe with the ROLAP version of your cube you didn’t see the error, because you always used only one of the facts, but the Store combines everything.
• Your cube may deliver data for more keys than a dimension contains. E.g. if you build a product dimension and filter the dimension to load only yellow products, you must apply the same filter to the cube. Otherwise, the cube will load facts for keys which are not part of the dimension, warn you (in fact, this is 99.99% of all warning a cube will raise are “missing keys”) and drop the row. Dropping the data itself is not the problem, because you don’t want the cube to load data for unknown keys, but your original ROLAP does it!  E.g. if the ROLAP cube is queried for the Amount of 2010 for all products, the ROLAP Cube will simply generate no WHERE statement for products, because you want all of them. But the store will calculate this value by rolling up all product data and the value will be less than the ROLAP value. This is not an error in the Store, it is originally located in the ROLAP Cube!

As you can see, the source for all problems with Stores is the ROLAP Cube itself. Therefore, you should always look for error messages and warnings and try to eliminate the problems in you cube.

Also important for warnings: You need to know how to find them, because the model information only shows the number of raised warnings but not the warnings itself. The warnings are sent to the log while building the Store, therefore you should open the log console before starting your first Cube aggregations. It is also important to switch of the session filter before building the Store, because this is a system process not related to any (or your) user session.

Our simple approach to load all dimensions into a single Store is good for small Cubes, but with a raising number of dimensions the Store size will grow exponentially (this is, because the number of cells in a Cube is the product of all dimension sizes).

Adding more and more dimensions to a MOLAP Cube will bring every OLAP system to its limit -  including instantOLAP. We have a good experience with cubes up to one billion compressed datasets (Stores of this size can hold up to 5000 billion cells), but even if this number sounds very high it can easily be reached by combining 20 or more large dimensions. And aggregating this number of cells can take many hours.

Therefore, we have a different approach for this problem: Combining of multiple Stores. In practice, there are several combinations of dimensions which are used often and other combination which are used never or very seldom. This means, you can aggregate a ROLAP Cube into more than one Store, and each Store holds a smaller number of dimensions the original Cube contains.

In this example we combined two Stores, one holding the Campaing dimension, the other the Manufacturer dimension. The system will now automatically choose the correct Store whenever a user queries the cube.

Now you might say “Okay, but what happens if the user queries all dimensions together or an unknown combination?”. This is where HOLAP comes into play: The “H” in HOLAP stands for hybrid – a mixture between offline MOLAP Stores and adhoc ROLAP Stores. You can create subset Stores and tell the system to use the orignial ROLAP Cube whenever an unknown combination of dimensions is queried. This means, you can deliver performant Stores but also a fallback solution for unmapped combinations.

How to turn an MOLAP Cube into an HOLAP Cube? There is a property for Cubes, “Keep Adhoc Cube With Stores”. Simply set the property to “true” and redisplay the Cubes in the Model Information dialog. Now you will see the original ROLAP Cube behind your Stores. And, because the order of Cubes and Stores is important in instantOLAP, the system will use the ROLAP cube only, if none of the Stores can deliver the wanted data.

You can see this in the Model Information also: When switching the property “Keep Adhoc Cube With Stores” to “true”, the original Cube appears behind the Stores. Simple but effective.

This is the last question: When will the system build or refresh my Stores? Of course, you don’t want to create the Stores manually after creating them. Therefore, there are two different ways to keep Stores up to date: Dimension triggered (automatic refresh) or time triggered (crontab refresh).

The automatic refresh will always start the build of a Store whenever it is offline or one of its source dimensions changed (in this case, the Store must be rebuild otherwise it would contain corrupted data). To turn the automatic refresh on, set the switch “Build Offline Store Immedialtey” of the configuration / model to true.

The alternative to automatic refresh is to refresh a Store triggered by a cron pattern. This cron pattern, which is a property of the Stores, you can manually control when the Store should be rebuild. Whenever a source dimension of the Store changes, the Store will fall back into the ROLAP mode and the data will be queried from the underlying database.

Usually, it is more comfortable to use automatic refresh, but there are sometimes reasons to manually controll the cron pattern. E.g. if you don’t want to stress your source database with the large SQL queries at daytime or if a source database is not available at certain times.