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:
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:
Some detailed information about the detail section:
Column Name | Description |
---|---|
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:
If we decide to add the defined attributes, use RMB Approve for each row and then perform Approve on the entity level.
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:
Some observations:
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:
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.
Typical scenarios:
If it is indicated that Errors Exist it is important to republish the custom attriutes for the fact. This is done by performing:
Also find some related information in the following section about Monitoring - Diagnostics.
If custom attribute definitions for a Fact entity have to be modified, the first steps will be to:
When the above actions are done the custom attribute definitions can be modified.
When the changes have been made, the actions are as before:
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.
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:
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.