Overview - Custom Attributes for Information Sources¶
This page gives an overview of the solution that enables an end user, through configuration, to add Custom Attributes for Information Sources without having to do any programming or file deployment. A general overview of the solution is presented as well as some overview information related to source types, source relations, work flow and export/import functionality.
The described Custom Attributes functionality is related to Information Sources and should not be mixed up with custom attributes functionality as part of the Custom Fields functionality in IFS Cloud. An Information Source consists of a Fact entity and zero or more Dimension entities. The functionality supports adding custom attributes to both these types of entities.
Note: Custom Fields specific attributes can of course be added as Fact or Dimension attributes, which means that it is easy for a customer to get access and to use Custom Fields specific attributes through Information Sources, e.g. used in IFS Business Reporter or IFS Lobby or as a read interface for integrations such as IFS Analysis Models.
The functionality can be described as in the following picture.
- A decision is made to customize a Fact or a Dimension
- The needed attributes are specified and especially important is to figure out which of the available sources that should be used for the attributes
- The provided functionality is used to create source relations and then the new attributes are added in a dedicated client
- New attributes have to be approved and then published
- During publishing, the new attributes are created and new storage objects are created
Existing attributes can be removed completely or just unpublished and disapproved before added again but with modified definitions. It is of course also possible to add new attributes to an entity that once was published. Adding new attributes over time does not normally create any issues. Removing attributes that once have been published is a bit more problematic, since it might lead to issues as e.g.:
- IFS Business Reporter reports where these attributes are referenced will become invalid
- Lobby data sources might get invalid
- Access Views created based on customized Information Sources will get invalid, which might effect integrations with IFS Analysis Models
The Custom Attributes for Information Sources functionality will out-of-the box provide enough functionality to cover the basic needs. For advanced usages the functionality can be combined with the following:
- Quick Information Sources
- Standard customizations
A customized attribute is always based on a source of a specific source type. Available source types can be found in the below table.
|The source is the identity of an existing dimension
|The source is the identity of an existing fact
|The source is the name of an existing view
|<IAL view name>
|The source is the name of an existing IAL view
|The source is the name of an existing table
|The source is a select statement identified by a user defined identity
|The source is a PL/SQL function identified by a user defined identity
|The source is a SQL expression identified by a user defined identity
For each source, of a given source type, it is necessary to define the relation between the entity to be customized and the source that holds the value of the new attribute. These relations are defined first, before adding any attributes.
- Each entity, Fact or Dimension, can have one or more relations
- Each relation refers to a specific source type
- If the source type is Dimension, Fact, View, IAL View or Table then for each type there can be many sources. The source identity is the name of the referenced entity (Dimension/Fact) or database object.
- If the source type is Select Statement, Function Call or Expression then the user has to supply a source identity.
E.g. if an attribute is based on a function call to
Company_API.Get_Namethen the source identity can be any string but here assuming that it is set to COMPANY_NAME
- For each relation it is necessary to define the relation between the customized entity and the target source. This also applies to source types Select Statement and Function Call where the defined statement/function call in most cases will contain bind variables that must be associated with the entity attributes.
- Relations are provided in the same way for Facts and Dimensions but in separate windows
A few examples will be provided.
Assume that we want to add the company name (description) to the Fact with identity FACT_SHOP_ORDER. The first step will be to create a relation. In the Relations for Facts page a definition like the following is done:
- The source type Select Statement has been selected
- For this source type the user must provide an identity to be referred to when creating the custom attribute. In this case the identity is set to COMPANY_NAME
- The description is a free text field but in the example it is given as FACT_SHOP_ORDER->COMPANY_NAME
- Join Type should be Sub Select for the used source type.
- In the SQL Expression field the statement to fetch the company name is defined and this is done by fetching the name column from the view COMPANY. Since the company name should be available in each transaction it is necessary to specify how the key column company in the view is connected to the fact. To do this, a bind variable :company is used in the statement.
- The header information is saved and then the next step will be to define the relation details. Since the statement contains one bind variable we need to define one relation, i.e. the attribute in the fact that represents the company, FACT_SHOP_ORDER.COMPANY, is related to the source reference company which represents the bind variable.
In the next example the goal is to enable the possibility to add one or more attributes from the view ACCOUNT to the fact FACT_GL_TRANSACTION. The first step will be to create a relation between the fact and the view. In the Relations for Facts page a definition like this is done:
- The source type View has been selected
- In the Source ID field the view is specified. Use List of Values to list available views to select from.
- The description is a free text field but in the example it is given as GL_TRANS->ACCOUNT
- Join Type is defined as Outer Join meaning that attributes added from the ACCOUNT view will be added by performing a left outer join between the entity view and the source view. Using outer join is the default suggested option which normally means that both select and conditional performance will be good. But note that this also means that it is very important to supply the relation details correctly; if a relation is missing it might lead to that too many rows are retrieved when accessing the customized entity. It is possible to use the join type Sub Select which will guarantee that only one row is returned from the source view, thus making sure that number of rows returned will be correct. The backside of this is that if a custom attribute based on this source is used as a conditional value, then the performance might drop due to that the condition in reality leads to execution if a Sub Select statement for each row/transaction.
- When the header information has been save the next step will be to define the relation details. To simplify for the end user there is a command called Suggest Join Info in the header that will open an assistant that will suggest how to join the keys, if found, in the source with attributes in the entity. If the suggestion is not complete or correct, it can be manually defined in the assistant.
The assistant has suggested one join correctly but for the COMPANY key it is necessary to define the join entity attribute.
- Edit the detail and use List of Values to view available Fact Item ID s
- When all joins/connections have been defined, press OK
When a relation has been defined and verified, it has to be approved to make it available when creating custom attributes based on that relation. This is done by using the RMB option Approve in the header part. When approving, the relation will be validated as far as possible.
List of Values for Source Views¶
When supplying the source identity related to source types Dimension, Fact, View, IAL View, Table, the easiest way to find existing sources is to use List of Values. If the source type is View then the LoV dialog has one attribute called Custom Field Attribute View that can be used to filter out views related to custom fields specific custom attributes. If new attributes are added to a Logical Unit via custom fields functionality, new custom specific views will be created for all existing views in the Logical Unit and the view name will end with _CFV. If these new attributes should be added to a Fact or Dimension, the easiest way to find an appropriate view is to use the LoV dialog on filter on e.g. Logical Unit Name and Custom Field Attribute View.
The workflow for defining custom attributes for a Fact or Dimension can be described as in the below picture.
- Decide entity, Dimension or Fact, to be customized
- Define necessary source relations for the entity
- Approve the necessary relations
- Start defining custom attributes
- Define custom attributes for a given source relation
- Approve the custom attribute(s).
Only approved attributes will be published.
- Perform the steps for each source relation.
E.g. for a view relation, many attributes can be added from the referenced view source but for a relation based on source type Select Statement, Function Call or Expression only one attribute can be added.
- Approve on the entity level.
Approval can only be performed if there is at least one approved custom attribute.
- The last step will be to publish on the entity level.
- Publish is only available after having approved on the entity level.
- Only approved custom attributes will get published.
- The publish step leads to the following:
- The new attributes will be added to the entity (Dimension/Fact) 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.
Once new custom attributes have been published, it is not possible to change existing definitions or add new custom attributes unless the entity is unpublished.
How to modify and/or remove published custom attributes is described in the following work flow.
- Unpublish is performed on the entity level
- Earlier created database objects are removed
- All custom attributes are removed from the entity
- Next step is to disapprove on the entity level, i.e. the existing custom attribute definitions are not considered approved anymore
- The custom attribute definitions to be modified or removed must be disapproved
- Modification of a custom attribute definitions is to some extent possible.
- If e.g. a new attribute was added to a Fact as a non-measure attribute but the attribute really represents a measure, then after disapproval the definition can be changed and then approved and published
- Other things that can be changed after disapproval is the attribute data type, display name, the folder name and for a Fact that supports incremental load it is possible to define if the attribute should be read-only or not. These type of changes do not require that the attribute definitions are removed.
- If it is necessary to change the source or the source type it will be necessary to remove the custom attribute definition before adding the required relation again.
Export and Import¶
Custom attribute definitions can be exported from one environment and imported in another.
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 same windows as mentioned earlier are used to handle the import.
Monitoring - Diagnostics¶
Custom Attributes related to Information Sources can be added from several types of sources through a source relation.
If a referenced source is modified it might lead to that a custom attribute based on that source is no longer valid. Some examples:
- A custom attribute is referencing a custom fields attribute (i.e. an attribute added to a Logical Unit (entity),) then if the custom fields attribute is removed or the custom fields source view gets invalidated, the custom attribute will also get invalidated, meaning that the Fact or Dimensions no longer is a valid entity.
- A custom attribute is added to a Fact based on an attribute in a Dimension. Later the dimension is modified and the referenced attribute is removed or the access view column name related to the attribute is changed, then the Fact custom attribute is no longer valid.
To keep track of changes to referenced objects that leads to invalid Fact/Dimension attributes, a monitoring event with identity IS_CUSTOM_ATTRIB_INV_VIEWS in monitoring category IS_CUSTOM_OBJECTS has been added and can be found in Application Monitoring Console,
- If there are created custom attribute specific source views that are invalid due to changes to referenced source objects, then the monitor entry Information Source Custom Attributes will show a red indicator and also the number of invalid views
- The RMB option Details can be used to show the details
- If there are invalid Fact/Dimension views it is wise to investigate what has happened and how the attributes in the invalid views are used. Invalid Facts/Dimensions might lead to broken IFS Business Reporter reports and problems with integrations such as IFS Analysis Models.
If Access Views have been created based on the entity to which new custom attributes should be added, the following must be considered:
- When the entity is published, i.e. custom attributes are added to the entity, there will be a warning popping up if an Access View related to the entity already exists. The message will say that no alterations will be made to the existing Access View.
The reason for this is that, it if is automatically changed it might mean that existing integrations using the Access View will stop working. Example of integrations are IFS Analysis Models. If the new custom attributes should be considered in the integrations, then integrations will have to be modified accordingly. Recreating the view can easily be done, please refer to Access View documentation, but recreating it should be done first when changes to the integrations are planned/done, thus trying to minimize the time that existing integrations will be out of synchronization.
- If custom attributes have first been added to Facts or Dimensions and then Access Views have been created, this means that the custom attributes will be represented in the create views. After this the access views have been used as the read interface for e.g. IFS Analysis Models. In this case it is even more important to think twice before removing some of the custom attributes. Removing attributes leads to that the source view referenced by the access view will be modified, thus leading to that the access view will get invalid and thus the integration will no longer work as it should.
About permissions and access:
- By default the end user permission set BA_ADMINISTRATOR will have access to the form in IEE
- Custom attributes that are based on the source type Select Statement, Function Call or Expression cannot be defined unless the user has been granted the system privilege DEFINE_SQL. Users that are given the DEFINE_SQL privilege can use the functionality in an unintended way but at the same time this is a trusted privilege.
For more detailed information about relations and how to define custom attributes for a Fact or Dimension, please refer to one of the below links.