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.
Contents
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:
A customized attribute is always based on a source of a specific source type. Available
source types can be found in the below table.
| Source Type |
Source |
LoV Supported |
Description |
| Dimension |
<dimension id> |
Yes |
The source is the identity of an existing
dimension |
| Fact |
<fact id> |
Yes |
The source is the identity of an existing
fact |
| View |
<view name> |
Yes |
The source is the name of an existing view |
| IAL view |
<IAL view name> |
Yes |
The source is the name of an
existing IAL view |
| Table |
<table name> |
Yes |
The source is the name of an existing table |
| Select Statement |
<user defined> |
No |
The source is a select
statement identified by a user defined identity |
| Function Call |
<user defined> |
No |
The source is a PL/SQL
function identified by a user defined identity |
| Expression |
<user defined> |
No |
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_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
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 IDs
- 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.
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.
Custom attribute definitions can be exported from one environment and
imported in another.
The export is available in the
Custom Attributes for Facts and
Custom
Attributes for Dimensions windows.
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.
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, currently only available
in the IEE client. The events are found under the monitor group
Information Source Custom Objects
- The following entries related to custom attributes are available:
- Number of invalid views related to Information Source Custom
Attributes.
- If created custom attribute specific source views are invalid
due to changes to referenced source objects, then this event will
show a red indicator and also the number of invalid views.
- The source views cannot be used anymore.
- Number of Dimensions with errors
- If created custom dimension source views have errors due to e.g.
deployed core metadata change, then then this event will show a red
indicator and also the number of invalid views.
- The source views cannot be used anymore.
- Often it is possible to fix the problem by performing Unpublish
and then Publish of related custom attributes.
- Number of Information Sources with errors
- If created custom Fact source views have errors due to e.g.
deployed core metadata change, then then this event will show a red
indicator and also the number of invalid views.
- The source views cannot be used anymore.
- Often it is possible to fix the problem by performing Unpublish
and then Publish of related custom attributes.
- Use RMB option Details to
show details about invalid views,
- 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.
For more information about monitoring, please refer to documentation about
Application Monitoring Console Configuration
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 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.
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.