Fact On Line Development

Online development of a fact means creating a fact view before defining and deploying IFS Business Reporting & Analysis services specific metadata for the fact.

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

Note: It is recommended to always develop the Online and Data Mart access version of a Fact. For more details about Data Mart implementation please refer to the Data Mart development page.

Note: All development of fact entities in IFS Applications should be done by using the IFS Developer Studio. The development is model based. Compared to a LU entity, a fact entity has a model file as well as generated files in the code repository. This is important to remember - never edit the fact files manually, instead always use the model.
For more information about how to handle modeling of a fact, 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 fact entity.

Contents

• General Remarks
• Access Security
• Deployment
• Fact View File
• Metadata File
• Implementation Example

General Remarks

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

Some general remarks about Online development for facts

• Check out general fact specifics first.
• The fact 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 fact 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.
• The Online version of an Information Source should support the same items as as the Data Mart version.

  Dimension identities should be defined but the NULL value handling differs from the way it is done in the Data Mart version.

• To support join in the Online scenario, it is normally necessary to make sure that there are fact items that represent the true keys of each dimension.
• About performance:

• The performance if executing Online is normally not as good as a Data Mart execution.

  The reason is that all information has to be retrieved and calculated at runtime.

• One single function in the fact view can affect performance quite badly.

  The only way to find out is to test and maybe consider view modifications or even design changes.

• Normally the performance is very bad if the ordinary join principles are used for Online, i.e. joining the ID column in DIM_X with the DIM_ID_X column in FACT_Y.

  Use the true/natural join principle instead, meaning that for each dimension the natural key items are connected to corresponding items in the fact.

• About joins:

• 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.
• 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. Some possibilities are:
  • Redesign in IFS Applications, storing information in a way that is more beneficial for On Line access.
  • Switching to the Data Mart version.

• Development Templates can be found here but it is not encouraged to use them. Instead use IFS Developer Studio to model your fact.

Access Security

It should not be possible to retrieve any data from Information Source (fact) specific Online views if access has not been granted. More specifically this means:

• The component BIBASE must be available in the environment.
• Controlling data access is handled by adding a condition to the WHERE clause in the views, calling the function Bi_Access_Granted in package Bi_Utility_API.

  FUNCTION Bi_Access_Granted RETURN VARCHAR2 DETERMINISTIC;
  PRAGMA restrict_references(Bi_Access_Granted, WNDS);

  Implementing this function in an Information Source (fact) view, may look as follows:

  ...
  FROM  ACCOUNTING_BALANCE_TAB a, CODESTRING_COMB c
  WHERE Bi_Utility_API.Bi_Access_Granted = 'TRUE'
  AND   a.posting_combination_id = c.posting_combination_id
  AND   'TRUE' = (SELECT Authorize_Comb_Finance_API.Is_Allowed(a.company, a.posting_combination_id) FROM DUAL)
  WITH READ ONLY;

  Directly after the WHERE statement a call is made to the function Bi_Utility_API.Bi_Access_Granted, checking for string value 'TRUE'.

Note: IFS Developer Studio will automatically add the necessary call to the Bi_Access_Granted to the online access views. The call will not be added to Data Mart specific access views, due to that Buisness Reporting & Analysis related features in Solution Manager will not be accessible if the BIBASE component is not available. Thus it will be very difficult to administrate activation and/or refresh of Materialized Views without that access.

Deployment

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

The files are:

1. Fact View file definition
2. Fact Metadata file

Fact View File

The fact 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 have values that match the identities of the referenced dimensions. This includes checking that NULL is returned if one of the involved key columns is NULL. This handling differs from the data mart version (see below).
• Measures and light items, also calculated ones, are correct.
• Columns to be used for natural/true join are available for all referenced dimensions.

Metadata File

A fact 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 fact metadata in the Information Source feature.

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. Modifying the metadata via the Information Source feature means doing a customization in the current installation. If the changes are not saved and kept in an installation specific metadata file version, the manual changes will be overwritten next time the metadata is deployed, e.g. a new standard version of the file via a bug correction

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

• Open the Information Source log feature
• Perform the following SELECT

  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 Fact can be found here.