Skip to content

Dimension On Line Development

Online Development of a dimension means creating a dimension view before defining and deploying IFS Business Reporting & Analysis services specific Metadata for the dimension.

This section provides some of the basic steps needed to create Online support for a dimension.

Note: A dimension should as far as possible always support both Online and Data Mart access. For more details about Data Mart implementation please refer to the Data Mart development page.

Note: All development of dimension entities in IFS Applications should be done by using the IFS Developer Studio. The development is model based. Compared to a LU entity, a dimension entity has a model file as well as generated files in the code repository. This is important to remember - never edit the dimension files manually, instead always use the model.
For more information about how to handle modeling of a dimension, please refer to IFS Develop Studio but also to the section about modeling.
The current page provides some details, things that can be good to know when developing a dimension entity.

General Remarks

Some general remarks about Online development for dimensions,

  • Check out general dimension specifics first.
  • Note that the dimension is supposed to be represented in a Meta Data model and that model is the same regardless if the execution is based on Data Mart or Online data.
  • All dimension data will be evaluated at runtime, which means that the performance might be affected compared to storing the calculated data in a Materialized View as in the Data Mart solution.
  • Normally the Online version of a dimension should NOT contain NULL identities. This means that the dimension view does not have a UNION ALL section that adds parent lines as in the Data Mart implementation. The reason is trying to keep the dimension definitions as simple as possible and to avoid negative performance effects by the UNION ALL section.
  • About performance,

    • The performance if executing Online is normally not as good as a Data Mart execution. The reason is normally that all information has to be retrieved and calculated at runtime.
    • One single function in the dimension view can affect performance quite badly. The only way to find out is to test and maybe consider view modifications or even design changes.
  • About dimension join,

    • The join between a fact and a dimension is in the Online case normally performed as a so called natural join between the ordinary key columns in the dimension and the matching columns in the fact, also called joiners.
    • For a natural join it is necessary to specify if the join is exact or not, i.e. if the dimension identity is always present or not in all transaction rows.
    • It might be the case that it is very difficult to get a decent performance with the natural join. When this happens the following should be considered:
      • Redesign - might mean preparing purpose-built data in IFS Applications that is better suited as the base for an Information Source.
      • Switch to Data Mart solution.
  • Each row in the dimension should be uniquely identified.

Deployment

Development of Online support for a dimension means creating a set of files that have to be deployed in the database.

The files are,

  1. Dimension View file definition
  2. Dimension Metadata file

Dimension View File

The dimension view definition is represented as an APV file, meaning that it represents a public read interface.

The file is deployed in the database.

After deployment the natural thing would be to SELECT from the view.

Make sure that:

  • The dimension identities are correctly defined.
  • Parent values are represented.
  • Enumeration db and client values are available.
  • Values derived via function calls or SUB SELECT statements are correct.

Note: It is very important to refresh the F1 dictionary after having created a new dimension view that is supposed to act as List of values view in Info Services.

Metadata File

A dimension has to be described/defined in a Metadata file. The Metadata is represented as an INS file.

The file is deployed in the database as any other INS file.

There is of course also the possibility to create the dimension metadata in the Information Source page.

Note: If the Information Source feature is used to create or add metadata, it is important to make sure to export the metadata to file as the last step. The reason is that any modification through the feature is a customization of the metadata in the current environment and if the changes are not reflected in a metadata file, it means that next time the metadata file is executed, all manual configuration will be lost.

Note: All development should preferably be made using IFS Developer Studio

Information about the deployment is output on screen (or in a log file). Errors must be investigated and corrected. Information lines should be looked up. Do one of the following:


SELECT * FROM XLR_IMPORT_LOG_TAB ORDER BY TIMESTAMP DESC
 When the accurate `IMPORT_ID` has been found, the following `SELECT` can be performed:

SELECT * FROM XLR_IMPORT_LOG_TAB WHERE IMPORT_ID = '<import_id>' ORDER BY LINE_ID ASC

Implementation Example

An implementation example related to an Online version of a Dimension can be found here.