Custom Attributes for Facts
This page deals with how to create custom attributes for a Fact, i.e. for the transactional entity in an Information Source.
Custom attributes are added/created in IFS Aurena and can be done by any end user having necessary privileges. All functionality related to Fact specific custom attributes can be found in Solution Manager as a part of the Information Sources framework.
The following prerequisites must be met to be able to create custom attributes for a Fact:
- The user must have access to the Custom Attributes for Facts page.
- Necessary source relations must have been created and approved.
- The user must have authorization to Approve and Publish custom attribute definitions.
- Custom Attributes based on source types Select Statement, Function Call and Expression require that the end user has the system privilege DEFINE_SQL granted.
Defining Custom Attributes
Custom attributes are defined in the Custom Attributes for Facts page. Query for the requested Fact, e.g. FACT_GL_TRANSACTION. If Relations Defined shows as not defined, it is not possible to define any custom attributes. The remedy is to open the Relations for Facts page and create the needed relations and approve them for the Fact before defining custom attributes.
Once there are approved relations the window should look like below.
Next step is to define the custom attributes. This is done in the detail section.
The following custom attributes are added in the example:
- A row counter defined as a measure item. This attribute is based on a the source type Expression.
- The company name defined as a light attribute and based on the source type Function Call
- The association number of a company defined as a light item by using the source type View and the source view COMPANY.
Some detailed information about the detail section:
|Source ID||The identity of the custom attribute source as defined in the Relations for Facts page|
|Source Type||The source type as defined for the relation to be used|
|Source Column Name||The name of a column in the source if the source type is View, IAL View or Table
An attribute reference if the source type is Dimension or Fact
For source types Select Statement, Function Call and Expression, a column name should not be specified.
|Date Type||Data type of the custom attribute|
|Attribute Name||The name of the custom attribute when added to the Fact. Only uppercase characters are allowed. No spaces can be used. Possible characters are also limited.
The resulting Fact Item Id will be <Fact ID>.<Attribute Name> e.g. FACT_GL_BALANCE.ROW_COUNT
|Display Name||The display name of the custom attribute in the Information Source navigator in e.g. IFS Business Reporter and IFS Lobby.|
|Display Folder||The name if the folder in the Information Source navigator where the custom attribute should appear. By default, a measure is added in the Measure Items folder and a non-measure in the Light Items folder. The Display Folder always defines a sub level in one of the two main folders.
E.g. Counters - adds the attribute in Measures\Counters folder
|Read Only in Data Mart||If the Fact supports incremental load, it is important to specify if the custom attribute should be stored in the database or not. By default this check box is not selected, meaning that the custom attribute will be stored in a special incremental table dedicated for custom attributes for the current entity. If the check box is selected, the attribute will not be stored in the database, only added as read-only attribute in the access view.
A typical case is when the value of the attribute is dependent of the context, e.g. current user, current language. For this case the attribute should be defined as a read only attribute.
|Is Measure||This check box should be selected if the added custom attribute is a measure item.|
|Approved||Selected when the definition has been approved.|
|Synchronized||Selected as long as the referenced relations or the published custom attributes are unchanged.|
Once the custom attributes have been defined, the next step is approval. Two levels have to be considered:
- In the detail section, approve the custom attribute definitions that should be published.
This is done via the command Approve.
- Before the custom attributes can be published and created, it is necessary to approve on entity level. Approving on this level makes all approved attribute definitions available for publishing.
Handle this by using the header level command Approve.
If we decide to add the defined attributes, perform Approve for each row and then perform Approve on the entity level.
Publish Custom Attributes
The last step is to publish the approved custom attribute definitions and this requires approval on both attribute and entity level.
Publishing is simply done via the command Publish on the entity level.
Publishing leads to:
- The approved custom attributes will be added to the Fact entity and will be directly available in the Information Source navigator in e.g. IFS Business Reporter and IFS Lobby.
- New database objects will be created, e.g. new access views
- For Information Sources that support incremental load, i.e. the Fact part only, a new table will be created for each Fact to store the custom attributes. The incremental load will work in the same was as without custom attributes.
- If an existing Access View related to the current entity was found, the will be a message saying that the access view will not be modified by default. Please refer to Overview Custom Attributes for Information Sources.
- The entity will be defined as Published.
- The entity level is defined as Synchronized. It mean that all approved custom attributes are all synchronized.
- Each approved custom attribute will be defined as Synchronized.
If there is a need to find out what happened during the publishing step, please check the Information Sources - Installation Log window.
The following error might appears during publishing:
The reason is most likely that a relation based on type SQL Expression has been defined using column references in the expression without an alias definition.
E.g. the expression SITE || ' - ' || COMPANY instead of f.SITE || ' - ' || f.COMPANY
Please refer to fact relations for more info.
The framework keeps track of changes related to the source relations for all approved custom attributes.
Say e.g. that the relation based on the view COMPANY has changed. This leads to the following:
- The custom attribute ASSOCIATION_NO is not Synchronized.
- The entity level is not Synchronized, thus indicating that something has happened with the custom attribute related configurations, that should be investigated. If needed, the definitions might have to be modified and republished.
Invalid Custom Views
If a custom source views related to a Fact are no longer valid, this is indicated by Errors Exist in the Fact Info group in the Custom Attributes for Facts page.
Core attribute removed or data type of core attribute is changed.
- One or more custom attributes created based on the core attribute.
- A core update of the Fact removes one of the previously existing core attributes.
- During Fact metadata deployment the custom source views will get invalidated.
If it is indicated that Errors Exist it is important to republish the custom attributes for the Fact. This is done by performing:
Some related information can be found in the Monitoring - Diagnostics section on the Overview - Custom Attributes for Information Sources page.
Redefining or Removing Custom Attributes
If custom attribute definitions for a Fact entity have to be modified, the first steps will be to:
- Perform Unpublish on header/entity level.
This action will drop all previously created data base objects and finally drop the custom attributes.
- Perform Disapprove on header/entity level.
When the above actions are done the custom attribute definitions can be modified.
- Removing custom attributes
- To remove a custom attribute definition, first the definition must be Disapproved.
- Next the definition can be removed.
- Modifying/redefining custom attributes
- In most cases the attribute definition should first be Disapproved
- A modification can e.g. be to specify that an attribute should be a measure instead of a light item.
- If it is only the used relation definition that has to be modified, that definition can be modified separately without even disapproving the attribute definition.
- Approve the definition once the modifications are done.
- Adding new custom attributes
- Add any number of custom attributes as described previously and make sure to approve the definitions to be published.
When the changes have been made, the actions are as before:
- Approve on the entity level
- Publish on entity level
Visualizing Custom Attributes
When custom attributes have been added to a Fact, it is possible to find out in the Information Sources feature if a Fact has custom attributes and also which attributes that have been added.
Information Sources with added custom attributes are in the Information Sources page marked with Yes in the Customized column.
Information Source items, light or measures, are also marked with Yes if customized.
Export and Import
The Custom Attributes for Facts page provides the possibility to export and import relations and custom attributes.
The commands Export and Import are available in the header.
The export will consider:
- All relations defined for the entity regardless of if they have been approved or not
- All custom attribute definitions defined for the entity regardless of approval or publishing
The content is exported as a XML file.
The import option takes a previously exported XML file and imports the custom attributes and relations. Import will not succeed if a relation or attribute to be imported already exists.
This functionality can be used when moving custom attribute definitions from one environment to another.
When the metadata of an Information Source is deployed, e.g. through a bug correction or an update, the custom attributes will still be available after the deployment process has ended. This is not the case if a new attribute or any other changes are made e.g. through the Information Source page.
Through the Information Source page it is possible to modify custom attributes of a Fact/Info Source and also to reference added custom attributes as part of the entities metadata, e.g. adding parameter functions for a custom attribute, using a custom attribute as part of an URL definition. Generally, it will be made sure that these definitions are kept after having deployed the metadata of the entity.
Custom attributes that are based on the source type Select Statement or Function Call or based on other source types but using the join type Sub Select, will generally have a bigger impact on performance than attributes where an outer join is performed between the original source and the referenced source. Read performance can be affected but might also be good enough. The big problem is when a custom attribute is used as a conditional attribute, easily leading to bad performance. This might happen when accessing data online or when the attribute is read-only for data mart access. For Facts that support incremental data mart load the general solution is to use data mart access and to avoid, if possible, read-only attributes. In the incremental data mart case, the custom attribute definition will be evaluated and the custom attribute value will be stored in a table, which means that referencing the attribute in e.g. a condition, will not impact the performance as bad as an online evaluation of a sub select as part of a condition. Also note that if a custom attribute in the data mart case is added as a read-only attribute, the definition of the attribute is important for performance for the same reasons as mentioned above.
Please note that when using custom attributes that are based on source types View, Dimension or Fact or if a statement references a view and also if a function is used, there is a risk that the retrieved attribute values are empty when using data mart access. The reason being that views and functions might have security filter mechanisms, meaning that retrieved data is dependent on the user and/or language used at the point of refreshing the data mart tables. If such attributes are not read-only, the stored values will in most cases not be correct and apply only to some users. For other users there will be no values or maybe incorrect values during access.