Skip to content

Tips and Tricks for IFS Business Reporter Designers and Developers

The purpose with this page is to supply some useful Tips and Tricks for developers of Information Sources as well as for IFS Business Reporter designers.

Performance - General

Using Information Sources for reporting purposes is a good choice due to the nicely packaged information. Connected dimensions enrich the reporting possibilities by adding lots of items that can be used for grouping/categorization or other presentation purposes. The backside of an Information Source with many connecting dimensions is the risk for increasing complexity. If e.g. an Information Source has 15 connected dimensions and one item is selected from each one of these dimensions along with measure items from the fact part of the Information Source, then the query that has to be built will contain one join for each one of the connected dimensions. When it comes to IFS Business Reporter, this means that a SELECT statement in Oracle will be created with many joins and maybe also many selected items. The more sources and items that are part of the query, the greater the risk is for bad performance.

What are the remedies? Here is a list of suggestions.

On Line Access

If On Line access is used, it is rather likely that performance problems will appear sooner or later. If it is still necessary to use On Line access, some measures must be taken to reduce the complexity or the amount of involved transactions. Some possibilities are:

  • Build new IFS Cloud functionality where the business logic creates grouped information and then create detail Information Sources based on this grouped data. The original Information Source. that represents the detail information, could then act as a Drill Down source to the new aggregated source.
  • Open up joiners in the Information Source as visible items, enabling access directly on the Information Source (Fact part) instead of using dimensions. Another possibility is to add more items to the Information Source that replaces the dimension items. The flexibility might be reduced but on the other hand the number of joins can be reduced.
  • Create snapshot functionality where as much information as possible is gathered in new snapshot tables. Build Information Sources based on the new snapshot tables. Creating new tables means that information can be collected from different sources and stored into one source table. A snapshot has the advantage that it contains calculated data instead of calculating it via the On Line view at execution time.
  • New solutions as grouped tables or snapshot tables gives the flexibility to create performance indexes, something that is much more difficult in existing core tables due to the risk of introducing performance problems in other parts of the system.

Switch from On Line access to Data Mart access

A possible measure when it comes to performance tuning is to switch from On Line to Data Mart access.

  • Data Mart access also means that a snapshot table is created. This gives good opportunities to add performance tuning indexes depending on how the customer is accessing the information.

  • Still Data Mart access can be rather costly. The general trick is to reduce the number of transactions handled. This can be done in the following ways:

    • Data Filter for Materialized Views In order to reduce the number transactions stored in a Materialized View, one possibility is to introduce Materialized View filters. A typical implementation is to only include transactions from one specific date or year and onwards. How to implement this is described in the development documentation for Data Mart access.
    • MV as source for another MV A rather nice possibility is to use the Materialized View concept to aggregate information from one Materialized View to another and so on. Then we get a chain of Materialized Views with different degree of aggregated information. These Materialized Views can then be used as sources for creating new Information Sources. By aggregating the data from the beginning, the access can be much more efficient than just building Materialized Views that more or less only mirrors the information in ordinary transaction tables.
    • Reducing Transactions in Incremental Load Table If the Data Mart source type Incremental is used, this means that transactions are moved from a core table via a view definition to an incremental snapshot table. When activating the entity, i.e. when the first snapshot is created, all transaction all transactions will be considered. It is however rather easy to add filter conditions that reduces the number of transactions considered, e.g. only transaction created the last 2-3 years are of interest. Once the initial refresh has been done, subsequent refresh will only consider new or modified transactions. For more information, read about Incremental Load Development

Using Access Views

When creating a Tabular Model, it is recommended to access Information Source information via Access Views. The Access Views can then represent either Data Mart or On Line access depending on access type used when creating the views. There will however still be a risk that the number of transactions are too many, affecting the access performance. The natural way here is to reduce number of transactions. This can be done automatically by defining filters on the Access Views that are related to Information Sources. For more information, please refer to: