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 Applications. 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 and IFS EOI.
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 and IFS EOI
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:
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_Name then 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
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
window 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
window a definition like this is done:
The source type View has been selected
In the Source ID field the view is
specified. It is possible to use <F8> (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 RMB
option called Suggest Join Info on the
header.
The result is that the keys, if found, in the source are collected and added
as detail rows.
What remains now is to specify the fact attributes that corresponds to the
two key columns in the source view.
It is suggested to use <F8> (List of Values) in the Fact Item ID column
to get a list of available attributes
When all connections have been defined, save
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.
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 <F8> (List of Values). If the source type is View
then the LoV dialog has one column called Custom Field Attribute View that
can be used to filter out views related to custom fields specific custom
attributes. This means that 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 Attribute View.
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.
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 has been added and can be found in
Application Monitoring Console in the IEE client.
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, invalid
IFS Lobby data sources and problems with integrations such as IFS Analysis
Models and IFS EOI.
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 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
existing Access View will not be modified.
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 and IFS
EOI. 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.
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.
