Skip to content

Analysis Models - Custom Configurations

This page provides information about custom specific configuration options related to Tabular Models, an essential part of IFS Analysis Models.

The Tabular Models framework is based on a layered architecture. The core/base definitions are defined in a core/base layer, while custom specific definitions are defined in a specific custom layer that will not interfere with the base layer.

Customization or localization of a Tabular Model normally means to use IFS Developer Studio to add a specific layer on top of the core layer. The Tabular models as well as Tabular Data Sources are defined using the Marble language with IFS Developer Studio as the tool. Regretfully there is not yet support for layered development in IFS Developer Studio.

Many customization can be handled by using existing Aurena configuration support.

  1. The different Tabular Models specific Aurena pages support configurations.
  2. Aurena specific configurations do not require any Marble model handling.
  3. Aurena also support other configurations and tools that are useful when doing customizations/configurations.

The information on this page only relates to Aurena specific configuration support.

General

The basic idea behind the custom configuration support is to provide a way to define a custom specific layer that does not interfere with the base layer definition. Thus, if e.g. an attribute in a tabular model table is to be modified, this is done by creating a configuration and then doing the change as a configuration. The configuration definition will be stored separately. The tabular table will after the configuration consist of both the base and the custom configuration. When the table is used, all sub parts as e.g. columns, measures and hierarchies that are supposed to be included will be considered and the custom configuration will be prioritized over the base layer.

A created configuration can easily be removed to make sure that the base definition applies again.

Disclaimer Information

The Tabular Models are built using different Information Sources. The different Information Sources, consisting of Facts and Dimensions, belong to different components in IFS Cloud. A customer will buy an IFS Cloud configuration that is based on SKUs, leading to customer specific Solution Set that defines active and inactive components.

Models that are based on technical components that are not active must be configured to work properly in the customer's environment.

Information about the different cases and how to configure the models can be found in Disclaimer Information Details.

Configuration State

The available configuration states are described by the following image.

Comments:

  • Models defined in the Marble language needs to be deployed during installation and will end up having the state Base. Thus all IFS delivered models will have this state.
  • A model where the model itself and all configurable parts have the state Base will, when creating a configuration on the model level, get the state ConfiguredBase, displayed as Configured.
  • If a new model is created in Aurena client, it will get the state ConfiguredNew, displayed as New.
  • If a detail of a Base model is configured, the detail will get the state ConfiguredBase, displayed as Configured, the parent entity will get the state ConfiguredDependent, viewed as Dependent, and the model itself will get the state ConfiguredDependent viewed as Dependent.
  • If a Base model is configured, e.g. by first configuring a table and then configuring a table column, then all these levels will get the state ConfiguredBase, viewed as Configured. Same applies if a configuration is first created on the model; the model state is viewed as Configured. When another configuration is created on a detail as e.g. a table, the table state shows Configured. The model state does not change. The state Dependent only appears when a parent object/level has not been configured but a details object has.
  • Configuring a detail in state Base leads to that the detail gets state ConfiguredBase, viewed as Configured, and the parent will get the state ConfiguredDependent, viewed as Dependent.
  • If a Base model is configured, the state will be set to ConfiguredBase ( Configured ) and it will be possible to edit on the model level. If the edit operation changes something that deviates from the base layer, save leads to the state ConfiguredBase ( Configured ). However, if a new edit is done and reverting the change, save leads to the state ConfiguredDependent ( Dependent ) even of no details have yet been configured. The configuration is removed by using Remove Configuration or by performing Exclude and then Include.
    The same pattern is there for model details, if e.g. a parent like a table is configured and edited without changing/configuring any details (e.g. columns).
  • If a Base model is configured and then a new detail is added, the the model gets the state ConfiguredBase, displayed as Configured, while the detail gets the state ConfiguredNew, displayed as New.

Note: The status handling works in a similar way for e.g. a Tabular Data Source as for a Tabular Model.

Note: The Exclude command, that sets state to Excluded can be used to e.g. exclude a model detail as a column, measure, table etc. from DW deployment and from being added to the .bim file that is deployed in a SSAS database. However, excluding parts of a model must be done with great care. Use command Include to go back to previous state.

About Configurations/Customizations

The Tabular framework can be used to handle different types of configurations, where changes are made via IFS Aurena that creates configurations on top of the base definitions.

Customizations are a bit more difficult to define. In some cases it is possible to use existing tools in IFS Aurena e.g., BI Services along with the Tabular framework to handle required custom requirements.

For more complex customizations the development might have to be done mainly in a SQL Server/Azure SQL database and in tools like Visual Studio/Data Tools, Tabular Editor, Power BI. If the main source data comes from IFS Cloud, then the Tabular framework can be used to support creation of tables and views in the target SQL database and to support data transfer. In short how to support this scenario:

  1. Create a new tabular model entry using an arbitrary name for the model.
  2. Figure out what IFS Cloud sources to use.
    Information can only be read through Access Views or via other created views in the schema. Access Views are created from Information Sources. The IAL Object tool can be used to create new read-views in schema.
  3. Create needed Tabular Data Sources using IFS Aurena.

    1. A Tabular Data Source normally has an IFS Cloud (Oracle) view as source and a SQL Server/Azure SQL target table and corresponding view.
    2. May have other view definitions, typically to perform transformations/additions.
    3. Create tables in the new tabular model.

    4. The Name is the name of the table in external tools, while the Table ID is the IFS identity.

    5. At this stage it is not necessary to add any table details. That purpose is only to make sure that new objects can be deployed in the SQL Server database.
    6. Each tables needs to have a partition and a partition should refer to a Tabular Data Source
    7. Create a table partition for each new table.
    8. Assign a Tabular Data Source to the table partition.
  4. Use the framework to test deployment of tables and views to the target db and also to create load definitions and transfer data.

  5. When every needed table, partition and data source has been created and the developed model successfully uses the created source info in the SQL database, perform an import of the model. This step will verify if all necessary information is available. Deploying the model again to Analysis Services will ensure that mode can be deployed via IFS Aurena.
  6. It is also possible to use other sources in a model than IFS Cloud related sources. These sources are always defined in external tools as Visual Studio or Power BI. The IFS representation of the model will contain the tables and table details related to the external sources and also the connect properties. Load of data to these tables takes place when processing the model.

Handling customizations related to Tabular Models can be done in different ways. Some changes are not considered as customizations, rather as configurations. Example on configurations:

  • Renaming a table attribute
  • Renaming a table
  • Hiding/unhiding tables and attributes
  • Excluding parts of the model

Configurations are handled by the Tabular Model framework. Read more about configurations.

Customizations means adding new non-base/non-core attributes and tables to a Tabular Model.

NOTE: It is many times possible to do simple customizations by using existing functionality in Aurena client, thus advanced configurations.

Also important to be aware of the following basics:

  • Access of IFS Cloud data is currently handled by reading source views in the schema.
  • Most of all referenced source views relate to Information Sources i.e., Facts and Dimensions.
    • Facts and Dimensions normally support Online and Data Mart access.
    • Access Views are created on top of either Online or Data Mart views.
    • Access Views are created using an Information Source as starting point, meaning the process will create views for the Fact and all referenced Dimensions.
    • Access Views are available in the schema.
    • The name of an Access View always ends with “_BI”.
  • Other sources, accessible in the schema, that are not related to Facts/Dimensions, are created during installation either by Tabular Model related components or by core product related components.
  • Ways of creating source views in schema:
  • A Tabular Model consists of tables that has columns.
    • The IFS Cloud source for a Tabular table is a source view created in SQL Server/Azure SQL database. These views are in most cases given the suffix “_TM” (Tabular Model view).
    • All objects created in the target database are defined by an entity called Tabular Data Source. It defines the IFS Cloud source, typically a view in the schema, the target table and also [transformation] views to be created in the target database.
    • Some target database views are intermediate/help views.
  • A table in the IFS representation of a Tabular Model, has source partitions and a partition references a Data Source. The Data Source view with the highest order will be the view that is defined as the source in Analysis Services for the table.
  • Exemplifying by using dimension DIM_CODE_B
    • Dimension ID is DIM_CODE_B
    • Supports Online and Data Mart access via specific source views.
    • The related Access View will be named DIM_CODE_B_BI and will be available in the schema.
    • Tabular Data Source with Data Source ID=DIM_CODE_B references the view DIM_CODE_B_BI as the IFS Cloud source view and defines a target storage table in SQL Server/Azure SQL database as well as a couple of transformation views, where the view with the highest Order is named DIM_CODE_B_TM.
    • In the Tabular Model IFS_GENERAL_LEDGER the table with Table ID=CODE_B has a partition that refers to Data Source DIM_CODE_B_FINANCIALS. The Name of the table, CODE B, will appear as a table in the Analysis Services definition of the model.
      The table will have the view DIM_CODE_B_FINANCIALS_TM as the source view in the Analysis Services definition, since this is the view with the highest Order for Data Source ID=DIM_CODE_B_FINANCIALS.
    • Data Source DIM_CODE_B_FINANCIALS requires the Data Source DIM_CODE_B (group Required Data Sources).
      The view DIM_CODE_B_FINANCIALS_TM refers to the view DIM_CODE_B_TM that is defined by Data Source ID=DIM_CODE_B.

Important Considerations when adding Custom Attributes

There are different ways to add custom attributes to an Information Sources e.g., to a Dimension or to a Fact.

Some possibilities are:

  • Referencing a Custom Entity Attribute added via the standard Custom Attribute functionality in IFS Cloud.
  • Referencing a column in a view.
  • Using a function call to retrieve the value or a new attribute.

For the mentioned cases it is rather likely that Row Level Security filtering will come into play. The filtering leads to that depending on context when using the associated source views (Online or Data Mart access), values may or may not show up.

If e.g., an Online source view of a dimension with an added custom attribute is accessed using a reporting tool as IFS Business Reporter, the retrieved data will be filtered with respect to what the current user is authorized to see.

This filtering is relevant and makes sense. But when a Dimension or Fact is used as a source for e.g., a SQL Server/Azure SQL database, it is not ok to use RLS filters during transfer of data from IFS Cloud. The RLS filtering in these cases needs to be built into the application/model that reads the transferred data.

For Analysis Models this means that the RLS should be added to the tabular models.

The thing to be aware of is that the framework functionality used to create custom attributes to be added to Dimensions/Facts, is not capable of handling filtering that happens in referenced sources/definitions. Considering RLS incorrectly might lead to that the transfer of data from IFS Cloud will not cause all rows to be transferred or that transferred rows do not have any values in some columns.

Examples

For more details how to perform configurations, refer to the following examples:

  1. State Changes
  2. Adding a Custom Attribute
  3. Adding New TM View Column
  4. Adding New IAL Source
  5. Adding New Dimension