This section contains important information that differ from standard routines where manual steps or actions must be taken. Components not stated in the list are considered as normal components which can be installed without any manual steps or considerations.
Note: These manual steps must be executed before clean scripts are executed.
It is common to upgrade the Oracle to a newer version
together with an IFS Applications upgrade. The Oracle lift is normally done
by exporting IFS Application from the existing database with the old Oracle
version and import it into an empty database with the new Oracle version.
This export/import or changes in the different Oracle versions might invalid
some SYS packages (e.g. Installation_SYS and Database_SYS)
needed for running the manual pre scripts. A way to fix these invalids could
be to run the
Prepare Database step before the pre scripts are executed. Actually, it
could be done even before the import into the new database.
History Logging and Custom Events in IFS Applications
are handled by database triggers. During an upgrade due to changes in
database tables these triggers might get invalidated. These need to be fixed
manually using the relevant windows (e.g. History Log Configuration) after
the upgrade.
The by RnD defined refresh categories before and after upgrade are listed below:
| Refresh Categories before Apps 8 | Purpose |
|---|---|
| DIM_ALL | Contains all dimension related Materialized Views |
| FACT_DISTRIBUTION | Contains Distribution IS related Materialized Views |
| FACT_ENGINEERING | Contains Engineering IS related Materialized Views |
| FACT_FINANCIALS | Contains Financials IS related Materialized Views |
| FACT_HR | Contains HR IS related Materialized Views |
| FACT_MAINTENANCE | Contains Maintenance IS related Materialized Views |
| FACT_MANUFACTURING | Contains Manufacturing IS related Materialized Views |
| TRANSLATIONS | Contains all translation specific Materialized Views |
| Refresh Categories in Apps 10 | Purpose |
|---|---|
| DIM_ALL | Contains Materialized Views related to all dimensions |
| IS_FINANCIALS | Contains Materialized Views related to Information Sources in Financials |
| IS_HR | Contains Materialized Views related to Information Sources in Human Resources |
| IS_MANUFACTURING | Contains Materialized Views related to Information Sources in Manufacturing |
| IS_PROJECTS | Contains Materialized Views related to Information Sources in Projects |
| IS_SERVICE_ASSET | Contains Materialized Views related to Information Sources in Service and Asset |
| IS_SUPPLY_CHAIN | Contains Materialized Views related to Information Sources in Supply Chain |
| TRANSLATIONS | Contains all translation specific Materialized Views |
It is recommended to manually remove these old schedules and replace them with schedules based on the new MV refresh categories, to make sure that correct Materialized Views are refreshed.
An alternative is of course to manually update the existing MV refresh categories. Instead of removing old schedules it is also possible to set them as not active.
Access Views are on-demand created views that serve as read interfaces for Analysis Models but also for the integration with IFS EOI. If an upgrade is performed from an earlier version of IFS Applications where Analysis Model has been used, there is a risk that some of the Access Views are invalid after the upgrade. The main reason is that the referenced source views has changed. An Access View can be invalid in two ways; either as an invalid object in the database or invalid in the sense that the Access View is not compatible with its references source view.
There is no automatic recreate task started during the upgrade since it must always be investigated if it is possible or not to recreate invalid Access Views. If a Access View is recreated it is necessary that the definition of the view is compatible with the SSIS packages and database tables in SQL Server where the IFS Data warehouse resides.
To handle the case where Access Views are considered as invalid database objects:
The script will only consider Access Views where the object status in the database in INVALID.
It is still important to be aware of the fact that once an Access View has been recreated, it might not be compatible with Analysis Models definitions.
Note: The script might fail to recreate some of the Access Views. If there are any views with status Invalid in the Access Views form after the script-execution, go to the detail window and perform RMB Validate and use the Info field to get an idea about what the problem is. Also note that recreating an Access View might lead to that the view changes, meaning that it is no longer a consistent read interface. This situation might lead to that is is necessary to perform modifications where the access views are used, e.g. in 3rd party tools or in Analysis Models.
To handle the case where Access Views are considered as in invalid by the framework:
All Materialized Views with a status (staleness) other than UNUSABLE will during an upgrade be marked as active.
When the installation has finished, there might be Materialized Views that are not valid, i.e. considered as invalid database objects. There is currently no automatic mechanism that can reduce the number of invalids. The reason for a Materialized View to become invalid might be due to changes to referenced tables without recreating the Materialized View. One way of handling this is to use the existing Data Mart Sources form in IEE and to do a manual refresh. The refresh mechanism will try to recreate a Materialized View that is marked as having a compilation error status.
For more general info about Materialized Views, please refer to the following link >>
Note: Since previously used Materialized Views, during the update are marked as active, this means that even if the staleness after upgrade is UNUSABLE, such Materialized Views will be refreshed next time a refresh schedule, containing the Materialized Views, is executed. It is thus not necessary to manually Activate these Materialized Views.
Note: Changes in source tables might cause Materialized Views to become invalid. This can happen if Materialized Views are actively used or not. To handle this situation there is a script, biserv\manualdeploy\database\biserv\biserv_Recompile_All_Invalid_MVs.sql, in component BISERV that can be manually executed after an upgrade if the database contains invalid objects of type Materialized View. Please refer to the script for more information.
EOI will in IFS Applications 10 be named IFS Business Cockpit.
It is important to note that from the Apps 10 release it is mandatory to use a service account when accessing Information Source metadata from IFS Business Cockpit. This means that if a customer is already using the functionality to import Information Source metadata to IFS Business Cockpit, it will be necessary to make sure that used credentials represent a valid service account in IFS Applications.
Some more information about integration with IFS Business Cockpit is provided via the following link.
To remove obsoleted IAL objects, excute the ialdr.sql drop script located at: <build_home>\manualdeploy\database\prodifsapplications after the upgrade.
Note: In order to execute the <build_home>\manualdeploy\database\prodifsapplications\ialdr.sql
file you must be logged in as IFSINFO.
Before deploying the files, the file contents have to
be verified and the EXIT statements should be removed.