3. Mock Upgrade
3.1 Introduction
This chapter discusses the prerequisites and guides you through the
process of upgrading Oracle FLEXCUBE Universal Banking Solutions from
a lower version to higher version.
The upgrade involves the following two activities:
- Mock upgrade activity
- Cut-over upgrade activity
The mock upgrade activity provides a safe platform for the actual
production environment upgrade. Once the mock upgrade is completed, you
will have a ready target database which is termed as the Gold Copy for
setting up the upgraded production environment.
3.2 Prerequisites
Following are the prerequisites for the upgrade activity:
- Prepare a copy of the production system covering all components
of the product for mock upgrade.
- Set up the Oracle DB parameters as per the FCUBS recommendations
for the destination schema. It is ideal to follow the steps of installation
of a new version.
- Identify and list out the installed components of the production
system.
- List out new components available in the new version that
the customer proposes to use.
- Identify and list out the details missed out in the new
version. Internally discuss and suggest the actions proposed to address
them.
- Update the customer about the proposed plan and get the
customer’s concurrence.
- Following are the other interfacing teams to be involved
in discussions for qualification:
- For qualifying with the new version: Address all changes required
for qualification with the new version.
- For qualifying with the existing interfacing system: Identify and
address the new interfacing requirements for the interfacing system to
remain intact.
- You need to understand the database upgrade strategy proposed
below:
- Identify and document the migration steps that are planned. Identify
whether any module migrations are present and collate the migration scripts
in the migration area (like module migration from LD to CL, LM to ELCM,
etc.).
- Set up the utilities for data comparison and data migration, if any,
in the migration area.
- Identify and document the verification strategy.
- Prepare the staging area for both source schema and target schema
(staging area for source schema is required only if the strategy followed
mandates it; otherwise it is not required).
- Identify the conversion scripts to be applied post-upgrade.
- Prepare a plan with timeline considering all changes required
for a smooth upgrade.
3.3 Mock Upgrade Activity
The mock upgrade activity provides a safe platform for the actual
production environment upgrade. You need to prepare a test area where
the mock activity can be carried out.
During mock activity, you need to perform user acceptance testing
(UAT) for the new modules and the functionality that are added in the
higher versions. While performing the actual migration, you need to take
the maintenances and parameterizations done in UAT to the production
environment.
The target database after the mock upgrade serves as a Gold Copy for
you to set up the upgraded production environment.
You can truncate the p-Data tables from the Gold Copy and re-import
from the production area. In the time between starting mock run activity
and starting the actual production upgrade activity, if any of the static
data is changed, then you need to handle such data manually.
Mock upgrade involves the following steps:
- Upgrade Oracle database to the new version
- Identify temp soft changes to and take appropriate action to setup
target version with temp soft changes (temp soft changes refer to the
customization changes and bug fixed on the source version)
- Setup target version of Oracle FLEXCUBE Universal banking Solutions
- Perform module specific changes if any
- Set up interfaces and adapters
- After upgrade, test the target version along with all interfaces
and adapters
- Get sign off on the production environment upgrade
3.3.1 Applying Temp Soft Changes
Temp soft changes refer to the customization changes and bug fixes
that are applied on the source version of the application used by the
customer. You need to identify the temp soft changes that should be applied
in the target version.
Source File Changes
You can use DIFF tools to compare the base version of the source application
and the version used by the customer.
Static Data Changes
For identifying the differences in the factory shipped data, use utility/scripts
mentioned in the Annexure.
3.3.2 Setting up Target Schema
You need to set up the target schema. For the purpose of illustration,
let us consider a schema by name ‘DESTSCHEMA’.
You can use the Oracle FLEXCUBE Universal Banking Installer to set
up the target schema. Follow the steps given below.
- Create the target version database using the target version
Installer. Refer to the installation manual of the required version for
details on setting up database.
- Load the static data using installer. Refer to the installation
manual of the required version for details on loading static data.
- Exit the installer immediately after loading the static
data. The basic setup step should not be done through the installer.
- At this point all data structures will be in place and
static data tables will have the data populated as of the target version.
But all schema objects like the source packages, triggers, procedures,
functions, constraints, indexes, views, sequences, etc. would be available
as of the base Kernel version.
- If there are any customization changes that needs to retro-fitted
in the target version schema, you may compile them now. You can also
make the related static data changes. While doing the TEMPSOFT changes,
you need to take care of the following:
- If the source version had an additional column with data, you need
to manually move the same as the import of data from production has already
been done.
- Apply the additional static data onto the upgraded schema.
- You need to create a dummy schema in the same oracle instance
as that of target schema. The dummy schema will have the same name as
that of the source schema (from which dump was exported). Provide necessary
grants for import/export. This is necessary to connect and import data
later on from the dump.
3.3.3 Upgrading Database
The activities involved in database upgrade are given in the table
below:
| Activity No. |
| Activity Details |
| Source/Destination |
| Depen-dency |
| 1 |
- For illustration purpose, consider that the name of the source schema
used by the customer is 'SOURCESCHEMA'. This contains the production
data of the bank and the complete set of DB objects including tables,
constraints, index sequences, source packages, triggers, etc.
- Disable the running Oracle jobs, if any.
- Create a full schema dump using the ‘expdp’ utility in
the SOURCESCHEMA. Name the export dump file as ‘SITE_FULL_DUMP.DMP’.
The parameter file ‘Export_Site_FULL_Dump.par’ can be used for
this export (See “Annexure” on page 1.).
|
| Source |
| No Dependency. You can
do this while the target schema is setup. |
| 2 |
- Configure the TNS in source and destination database to create DB
link.
|
| Common |
| |
| 3 |
- Run the schema difference utility (See “Annexure” on page 1.).
This utility lists out the schema differences for the Tables and Columns.
- Run ‘Create_DB_Link.sql’ in the destination schema.
It will prompt for the site schema name, password and database name.
Upon providing the details, MIG_DB database link will be created connecting
source schema.
- In case creating a DB link to the production schema is disallowed,
a staging area can be created and the DB link can be created to point
to the same.
- Run ‘TableDiff_Source_Dest.sql’ utility to identify
the table difference between the SOURCESCHEMA and DESTSCHEMA. Copy the
results to an Excel file.
- Run ‘Existing_Table_Column_Diff.sql’ to identify
the Table Column difference between the SOURCESCHEMA and DESTSCHEMA.
Copy the spooled result to Excel file.
- This Excel file will act as a reference point of the schema differences
between source DB and target DB.
- This file has the column level information and details like whether
null values are allowed or not. For all the ‘not null’ columns
that are newly introduced in the target version, you need to handle the
data import with special consideration because the import for these tables
will fail if the records are present in the SOURCESCHMA for the same.
- Based on the column differences, generate the scripts to disable
the constraints for the new not null columns in the DESTSCHEMA, Along
with this, generate the scripts to disable all the triggers.
- Use the stub ‘Constraint_Trigger_Disable_Script.sql’ (See “Annexure” on page 1.)
to generate the following scripts.
- ALTER_TRIGGER_DISABLE.sql - This sql contains the
scripts to disable all the triggers.
- ALTER_CONSTRAINTS_DISABLE.sql - This sql contains
the script to disable only the not null, unique constraints and check
constraints for a column without default value.
- Execute the above two scripts before importing the table data from
site dump to the DESTSCHEMA.
- You may need to enable any specific triggers during import as a special
case. Certain ELCM triggers need to be enabled during the data import
process. For details on enabling ELCM related triggers, See “Enabling Triggers” on
page 13..
|
| Destination |
| Activity 1 and Activity
2 |
| 4 |
- Note that we have already created a dummy schema with the same name
as the source schema to facilitate impdp command, which is used in the
below command.
- Import the table data from the site dump using the par file given
below:
- Data pump import command: IMPDP source_schema_name/pwd@target_instance
PARFILE=<parameter file name with path>
- The parameter file ‘Import_P-M_data.par’ can be used to import
P Data, M-Data and P-M Data into the DESTSCHEMA (See “Annexure” on page 1.).
- The parameter file ‘Import_EM_data.par’ can be used to import
the E-M data into the DESTSCHEMA (See “Annexure” on page 1.).Refer
the import log to ensure that all the table data is imported without
any error.
- If there is any failure in the import, you need to analyse and handle
it manually.
- While comparing the SOURCESCHEMA and DESTSCHEMA the stub ‘Drop_Sequence_Script.sql’ generates the drop
script for the common sequences. The drop script file name will be ‘DROP_SEQUENCES.sql’. Execute this script to
drop the common sequences from DESTSCHEMA.
- After dropping the sequence, import the sequences from SITE_FULL_DUMP.DMP
using the import par file ‘Import_Sequence.par’.
|
| Destination |
| Activity 1, Activity 2
and Activity 3 |
|
| 5 |
- Ensure that all the triggers and selected constraints are disabled
as mentioned in Activity 3.
- Generate and apply the module wise conversion scripts, EXCEPT for
LD to CL and LM to ELCM migration. (For details on conversion script
generation and application, See “Conversion Script Generation
Tool” on page 1.).
- Enable all the triggers and constraints once the module wise conversion
scripts are generated and applied. You need to manually handle the errors
encountered while enabling the triggers and constraints.
- Once the triggers and constraints are enabled, migrate LD module
to CL module and LM module to EL module.
- Note that conversion from LD module to CL module and LM module to
EL module should be separately handled as they are re-vamped modules.
You may carry out these two migration activities after enabling the triggers
and constraints. (See “Upgrade of Revamped Modules”
on page 1.).
|
| Destination |
| Activity 4 |
| 6 |
- The target database is now ready. Carry out the post-import activities
provided in the next section. Carry out the post upgrade verification
activities.
- You need to preserve the scripts applied while carrying out these
activities to use them again if required.
|
| Destination |
| Activity 5 |
3.3.3.1 Post Import Activities
Once the data import is completed, you need to perform the following
post import activities:
- Recompile invalid objects
3.3.3.2 Issues in Data Import using IMPDP
Utility
You may encounter any the following issues while importing data using
IMPDP utility.
| Issue |
| Problem |
| Cause |
| Resolution |
| Import options not recognized |
| Some of the import options
may not be enabled in the server. One such example is the DATA_OPTIONS
clause of the import, which is used in the E-M Data import par file. |
| Oracle parameter setup |
| DBA needs to enable the
same |
| Data Import fails because
of new indexes |
| If the value for a column
is null in the imported data which is going to be part of an index in
the target then the import fails. |
| The existing column would
have been added as part of a newly created unique index in the DESTSCHEMA.
So, if the data for this column contains null values then the uniqueness
is violated. |
| Disable the index, do
the import, supply values to this column |
| Data Import fails due
to long columns |
| If a varchar2 column was
changed to long column in the higher versions, then the import fails.
|
| IMPDP does not support
importing varchar2 columns into long columns. It is given in oracle
documentation that long columns are deprecated and not recommended
to create tables using long data type. Instead CLOB to be used. |
| As a workaround, instead
of impdp utility, use the imp utility to import the tables affected
by this issue. |
3.3.4 Deploying Front End Application
For deploying the front end application, follow the steps below:
- Refer to the installation manual of the required version
of the application.
- Apply the temp soft changes, if any.
- Ensure that the deployed EAR points to the upgraded database.
3.3.5 Impact on Existing External
System Interfaces
If the customer has any external interfaces maintained in the source
application, you need to follow the steps below:
- Communicate any format level changes (GI files, Gateway
XSDs) in existing interfaces to the external systems.
- Communicate the changes in queues configuration, file locations,
etc to the external systems
- Communicate the changes in the tag names of the XSD files
which are shared with other systems to the respective external system
owners
3.3.6 Verifying Data after Database Upgrade
Once the database is upgraded, you need to do the following verifications:
- System wide data verification of reports and other check points
- Interface testing to check the connectivity
- Module-wise data verification of reports and other check points
- Converted deals testing
- New deals testing
- New product maintenance testing
- Signoff
These verifications are explained in detail under the following headings.
3.3.6.1 System wide Data Verification
This verification includes the following steps.
Generic Checks
generic check includes the following:
- Check the main parameter table ‘cstb_param’ for the parameter
values.
- Menu organization is as per the static factory shipped data and handled
from the import. ELCM and CL modules are not handled by the script. You
need to remove the LD and Limits menu functions and add the ELCM and
CL menu functions.
- The bank may need to modify their user roles. You need to take care
of the change of user roles for the new modules. A script will introduce
all such roles into ALLROLES.
- Unlock and save all modules maintenance such as Products, ICCF Rule,
ICCF Class, UDF etc.
EOD and Performance Testing
This verification includes the following:
- Configure the following as part of FCJ configuration:
- Install Oracle Web cache which is present in the Sizing document
- Change the Internet Explorer setting as per DBA server sizing document
(recommended IE settings)
- Ensure that onsite changes are not done to introduce ‘no-cache’
in the code
- Configure realistic user roles against the usual ALLROLES
- Launch basic screens of high volume module sand process them onsite
- Record and review the EOD and EOM timelines before and after upgrade
to check if there are any major variances
- Check if all the programmes maintained in the EOD window is run without
being skipped
- Check if all aspects of the EOD, i.e. module functionality and reports
generation are covered
- Test on a masked dump of the site if it is done offshore
3.3.6.2 Interface Testing to Check Connectivity
As part of this verification, you need to perform the following activities:
- Test incoming and outgoing interfaces, conversion of FLEXML formats
to gateway, EMS to JEMS and ATM/POS using the SWIG interface
- Check for all the channels that receive information from Oracle FCUBS
3.3.6.3 Module-wise Data Verification
of Reports and other Check Points
See “Module Upgrade” on page 1.
3.3.6.4 Converted Deals Testing
You need to test the converted deals as follows:
- As part of the upgrade, the system will have new tables as well as
new columns in the existing tables. Check the sanctity of the conversion
utility and populate the additional fields and tables by testing the
converted/migrated data.
- Perform basic life cycle testing for the converted contracts.
- Check the product maintenances and static maintenances for modifications.
3.3.6.5 New Deals Testing
You need to test the new deals as follows:
- Create new contracts on existing products and observe the validation
of default values.
- Test the basic life cycle of new deals.
3.3.6.6 New Product Maintenance Testing
Once the upgrade is completed, create a new product in each module.
3.3.6.7 Signoff
Get the customer signoff to go ahead with the upgrade of production
environment.
3.3.6.8 Gold Copy
Gold Copy - DB Schema Setup
Once the above activities are completed, you can use the DESTSCHEMA
as the Gold Copy to set up the database during production environment
upgrade.
Gold Copy - Front End Setup and Interface
Use the latest available executables to set up the various components
for production upgrade.
All interface related changes available in various files need to be
deployed.