DATA MIGRATION AUTOMATION TOOL (SYBASE

TO ORACLE)

A PROJECT REPORT

submitted by

Anirban Mishra (09BCE010)

in partial fulfillment for the award

of

B. Tech
degree in

Computer Science and Engineering

School of Computing Science and Engineering

May – 2013

1
 School of Computing Science and Engineering

DECLARATION

I hereby declare that the project entitled “DATA MIGRATION AUTOMATION

TOOL (SYBASE TO ORACLE)” submitted by me to the School of Computing Science
and Engineering, VIT University, Vellore-14 in partial fulfillment of the requirements for the
award of the degree of Bachelor of Technology in Computer Science and Engineering is a
record of bonafide work carried out by me under the supervision of Prof. Saleem Durai
M.A. I further declare that the work reported in this project has not been submitted and will
not be submitted, either in part or in full, for the award of any other degree or diploma of this
institute or of any other institute or university.

Signature
Anirban Mishra (09BCE010)

2
 School of Computing Science and Engineering

CERTIFICATE

The project report entitled “DATA MIGRATION AUTOMATION TOOL (SYBASE TO

ORACLE)” is prepared and submitted by Anirban Mishra (Register No: 09BCE010). It
has been found satisfactory in terms of scope, quality and presentation as partial fulfillment
of the requirements for the award of the degree of Bachelor of Technology in Computer
Science and Engineering in VIT University, India.

(Name & Signature of the Internal Guide)

Internal Examiner External Examiner

3
Certificate from company

4
 ACKNOWLEDGEMENT

I take this opportunity to express my profound gratitude and deep regards to my guide
(Prof. Saleem Durai M.A.) for his exemplary guidance, monitoring and constant
encouragement throughout the course of this project. The blessing, help and guidance given
by him time to time shall carry me a long way in the journey of life on which I am about to
embark.

I wish to express my sincere gratitude to Prof. Anand M, Assistant Professor

(Selection Grade), Division Chair & Programme Chair B.Tech CSE for guidance and
encouragement in carrying out this project work.

I sincerely thank to Dr. S. Margret Anouncia , Dean, SCSE for providing me an

opportunity to do my project work.

Besides, we would like to thank the authority of Vellore Institute of Technology,

Vellore (VIT University) for providing us with a good environment and facilities to complete
this project.

I also take this opportunity to express a deep sense of gratitude to Vaibhav B.

Kulkarni, Senior Manager, Ericsson India Global Services Private Limited, for his
cordial support, valuable information, resources and guidance, which helped me in
completing this task through various stages.

I am obliged to staff members of (Ericsson India Global Services Private Limited),

for the valuable information provided by them in their respective fields. I am grateful for their
cooperation during the period of my assignment.

Lastly, I thank almighty, my parents, brother and friends for their constant
encouragement without which this assignment would not be possible.

5
 CONTENTS

Chapter Title Page

Title Page 1
Declaration 2
Certificate 3
Acknowledgement 5
Table of Contents 6
List of Tables 8
List of Figures 9
List of Abbreviations 11
Abstract 12

1 Introduction 13
1.1 General 13
1.2 Motivation 13
1.3 Aim & Objective – Problem Description 13
1.4 Related Work 13
1.5 System Requirements 13
1.5.1 H/W Requirements 13
1.5.2 S/W Requirements 14
1.6 Report Organization

2 Overview of the Proposed System 14

2.1 Introduction of problem and its related concepts 14
2.2. Gaps identified from the existing systems 20
2.3. Proposed solution 20

3 Analysis and Design 21

3.1 Brief Introduction 21

3.2 Requirement Analysis 21

3.2.1 Functional Requirements 21
3.2.1.1 Product Perspective 26
3.2.1.2 Product features 27
3.2.1.3 User characteristics 27
3.2.1.4 Operating requirements 27
3.2.1.5 Assumption & Dependencies 28
3.2.1.6 Domain Requirements 29
3.2.1.7 User Requirements 29
3.2.2 Non Functional Requirements 30
3.2.2.1 Performance requirements 30
3.2.2.2 Safety requirements 30
3.2.2.3 Security requirements 30

3.3 Design of the proposed system 31

3.3.1 Design 31
3.3.1.1 Design Overview 31
3.3.1.2 Requirements Traceability Matrix 35
3.3.2 System Architectural Design 35

6
 3.2.1.1 Chosen System Architecture 35
3.3.3 System Interface Description 36
3.3.3.1 Detailed Description of Components 36
3.3.4 Considered Design Constraints 37
3.3.4.1 Economic 37
3.3.4.2 Ethical 37
3.3.4.3 Sustainability 37
3.3.4.4 Legality 37
3.3.4.5 Inspectability 38

4 Implementation 38
4.1 Tools Used 38
General Introduction 38
Reason for selecting tool 38

4.2 Implementation 39
4.2.1. USER INTERFACE DESIGN 39
4.2.1.1 Description of the User Interface 40
4.2.1.2 Screen Images 41
4.2.1.3. Objects and Actions 60

4.3 Testing 61
4.3.1 Test Approach 61

4.3.2 TEST PLAN 62

4.3.2.1. Features to be tested 62
4.3.2.2 Features not to be tested 62

4.3.3 Testing Tools and Environment 63

4.3.4 TEST CASES 63

4.3.4.1 Case-n 63
4.3.4.2 Purpose 63
4.3.4.3 Inputs 63
4.3.4.4 Expected Outputs & Pass/Fail criteria 63
4.3.5 Test Procedure 69

5 Results and Discussion 70

5.1 Results 70
5.2 Performance Analysis 70

6 Conclusion and Future Enhancements 71

7 References 72

7
 LIST OF TABLES

S.No. Title Page

Table 1Functional Requirements 21

Table 2Requirement Traceability Matrix 35

Table 3Description of Components 36

Table 4Objects and Actions 60

Table 5Test Cases 63

Table 6Test Procedure 69

Table 7Performance Analysis 70

8
 LIST OF FIGURES

S.No. Title Page

Fig 1 Charging System Architecture 31

Fig 2 MINSAT Architecture 32

Fig 3 Charging System Framework 32

Fig 4 ECMS Architecture 33

Fig 5 Data Flow Diagram 34

Fig 6 DMI Tool Architecture 35

Fig 7 Main – Menu 39

Fig 8 Sub – Menu 39

Fig 9 Help Menu 41

Fig 10 Load INIT Process CMD 41

Fig 11 Load Start Process CMD 42

Fig 12 Transfer INIT Process CMD 42

Fig 13 Transfer Start Process CMD 43

Fig 14 Release INIT Process CMD 43

Fig 15 Release Start Process CMD 44

Fig 16 Batch Progress 44

Fig 17 Batch Not Found 45

Fig 18 Move Data 45

Fig 19 Main Menu 46

Fig 20 Load Sub-Menu 46

Fig 21 Load INIT MenuLine 47

Fig 22 Load Start MenuLine 47

9
Fig 23 Skipping Load Process 48

Fig 24 Transfer Sub-Menu 48

Fig 25 Transfer INIT MenuLine 49

Fig 26 Check Progress 49

Fig 27 Skipping Transfer Process 50

Fig 28 Release Sub-Menu 50

Fig 29 Release INIT MenuLine 51

Fig 30 Release Start MenuLine 51

Fig 31 Exit DMI Tool 52

Fig 32 Load INIT-START1 CMD 52

Fig 33 Load INIT-START2 CMD 53

Fig 34 Transfer INIT-START CMD 53

Fig 35 Release INIT-START CMD 54

Fig 36 UNDO INIT CMD 54

Fig 37 UNDO Start CMD 55

Fig 38 UNDO INIT MenuLine 55

Fig 39 UNDO Start MenuLine 56

Fig 40 Interface Files 56

Fig 41 Status File 57

Fig 42 Setup Files 57

Fig 43 Log Files 58

Fig 44 Backup Batches 58

Fig 45 DMI Install 59

10
 LIST OF ABBREVIATIONS

Abbreviation Expansion

AF Account Finder

AIR Account Information and Refill

CCN Charging Control Node

CRS Charging Data Reporting System

CS Charging System

ECMS Ericsson Customer Management System

IVR Interactive Voice Response System

MEDI MINSAT ECMS Data Migration Interface

MINSAT Mobile Intelligent Network Service

Administration Tool

SDP Service Data Point

VS Voucher Server

11
 ABSTRACT

In Present information age, with the invent of new packages and programming languages,
there is need of migrating the data from one platform to another as versions and changes, to
perform quality assurance of any migrated data is tedious task which require more work
force, time and quality checks. To perform efficient data migration process, legacy data
should be mapped to new system by considering extraction and loading entities. The new
system should handle all the data formats, the good design of data migration process should
take minimal time for extraction and more time for loading. Post loading into new system
results in verification and validation of data accurately, by comparing with the benchmark
values and derive accuracy of data migration process. The manual data validation and
verification process is time consuming and not accurate so automated data validation improve
data quality in less time, cost and attaining good data quality. The current process is a manual
process which is prone to errors and is tedious. The proposed system would automate the
entire data migration process from SYBASE to ORACLE and would be less error prone, can
run several batches at a time and also provide and option for rollback.

12
1. Introduction
1.1. General
DMI Tool is an automation tool capable of migrating MINSAT subscriber data which runs on
SYBASE to ECMS which run on ORACLE without any manual scripts being run by the
migrator. It provides flawless transfer of subscriber data between the two systems. DMI Tool
provides a Menu Driven Interface as well as a Command Line Interface as per the
requirement of the migrator. This tool loads up subscriber data into a temporary schema until
it is finally transferred and released into final schema and at any stages in this process any
portion of it can be rolled back to its previous state. It speeds up the migration process as well
as eliminates human error.

1.2. Motivation
The opportunity to work on Charging System which is the most widely deployed real time
charging solution serving more than one billion users and 160 service providers throughout
the world motivated me to take a project that is associated with Charging System. Also, the
chance to automate something which previously took a very long time to be done also
motivated me to take this project. The prospect of working on live project which would be
used all across world by entire Telecom Industry made me enthusiastic to work on the
project.

1.3. Aim & Objective – Problem Description

To design an automation tool that would automate the existing cumbersome process of
migrating data from MINSAT (SYBASE) to ECMS (ORACLE) with the help of MEDI tool.

The objective of our project is to design an automation tool that would automate the process
of migrating client data from MINSAT which works on SYBASE database to ECMS which
works on ORACLE database. The tool would work both as MENU-DRIVEN and
COMMAND LINE which would provide a greater flexibility for the user. The tool would be
able to migrate data in batches created by MEDI tool. The DMI subscriber migration process
eventually consists of three steps in case of online migrations: LOAD, TRANSFER and
RELEASE. For offline migrations, only two steps (LOAD and TRANSFER) are necessary. It
is up to the migration team to migrate all data in one go or to split migration up into different
batches. Each process can also be UNDONE at any stage with the help of this tool. The tool
would also be able to INSTALL, UNINSTALL and REINSTALL the DMI tool.

1.4. Related Work

The earlier migrations were performed using a combination of manually executable scripts as
well as transfers that were manually performed by the migrator. Earlier work included a 8-
step process which has to be performed by the migrated to migrate from MINSAT to ECMS.
It consisted of various Pearl Script and SQL Queries which now have been automated using
Korn Shell Scripts.

1.5. System Requirements

1.5.1. H/W Requirements
The following are the software requirements specifications for DMI Automation Tool:-

13
  MINSAT Server

 ECMS Server

 Hard Disk (300 GB)

 Physical Memory (4 GB)

Both MINSAT and ECMS server must be capable of running:-

 Pearl Script

 Shell Script

 Korn Shell Script

 SQL Query

1.5.2. S/W Requirements

The following are the software requirements specifications for DMI Automation Tool:-

 PuTTY

 Oracle SQL Developer

 SYBASE Developer

 MEBC Tool

 MEDI Tool

 MINSAT

 ECMS

 SDP

 Text Editor

 Windows XP or above

 Solaris v5.10 or above (Server)

 Web Browser

1.6. Report Organization

The report contains the declaration and the certificate signed by the mentor. Followed by the
table of contents and list of tables, list of figures and list of abbreviations used in the report.

Chapter 1 explains the importance of the general description about DMI Automation Tool, the
motivation behind the project, the aim and objective and the software requirements of the
tool.
14
Chapter 2 gives an overview of the entire system and its dependent systems which includes
Charging System 3.0, MINSAT 7.2, ECMS and MEDI Tool and the concepts related to it.

Chapter 3 gives an introduction about Architecture and Design of the system. It also gives the
Functional and Non- Functional Requirements of the system. The chapter also describes the
perspective and features of the system as well as user characteristics, Operating requirements,
domain requirements and user requirements. The Assumption and Dependencies of the
system and also its design constraints has also been discussed in this chapter.

Chapter 4 gives details about the implementation of the system – the tools used, reason for
selecting them, description of user interface objects and actions. It also contains screenshots
of the system. The Testing part has been discussed in this chapter which includes the Test
Approach, test plan, test cases and testing environment.

Chapter 5 summarizes the result of this project and the performance analysis which shows
how the system performed in a real scenario.

Lastly, In Chapter 6 and 7 we give the conclusion and scope of future enhancement that can
be done to the project and also provide the references used.

2. Overview of the Proposed System

2.1. Introduction of problem and its related concepts
Charging System 3.0

Charging System is the most widely deployed real time charging solution serving more than
one billion users and 160 service providers throughout the world. It is designed with high
performance decoupled architecture. This architecture decouples traffic flow from the
administrative system and operators are provided with clean administration and provisioning
interfaces to facilitate integration with business support systems.
The key advantages with Charging System are:

 Real-time charging for all services to avoid revenue leakage.

 User segmentation to reward loyal customers, to provide faster reaction to customer

needs and to speed up the launch of market campaigns.

 Ability to provide real-time notifications, bonuses, and discounts to further build user
satisfaction.

Charging System is a cost-efficient charging solution suitable for up to 32 million

subscribers.
Charging System makes it possible for a network operator to charge in real-time for events
and sessions in the mobile network. These events and sessions can for example be voice calls,
Short Message Service (SMS), events using General Packet Radio Service (GPRS) or events
using Diameter. It is also possible to allow service authorization and service-aware charging
including session control.

15
Each subscriber is connected to an account, which can be refilled, for example, by using a
voucher.
Charging System is constructed as a decoupled architecture. With the decoupling of the
traffic flow from the administrative system, the operator is provided with a clean
administration and provisioning interface, facilitating the integration with business-support
systems.
Charging System gives the possibility of market segmentation with highlights like Subscriber
Segmentation Service Offerings, Subscriber Segmentation Account Group Identity,
Community Charging and Enhanced End of Call (EoC) USSD Notification.
Powerful tools for tariff management, market segmentation, bonus and loyalty programs, as
well as for statistics generation are provided.

MINSAT 7.2

MINSAT is responsible for subscriber administration in a charging system.

Geographical redundancy is an option that is available for MINSAT. MINSAT is the software
application that is used by network operators to manage the Charging System service.
MINSAT consists of a UNIX package comprising a suite of batch processing and interface
applications. The MINSAT database is called csmain.
The following are the components of MINSAT,
Minsatapp
The minsatapp application is the MINSAT request processor and it runs as a daemon process.
All client applications connect to and issue requests to minsatapp. The minsatapp carries out
the relevant processing for the request and issues the response back to the MINSAT clients
(CAI MINSAT GUI, CC-API external clients, and MINSAT batch applications). Each
instance of the minsatapp supports only one API type, that is configurable at startup. When
starting the minsatapp, CAI, CC-API, or BATCH can be specified as the API to activate.
When a client connects, the minsatapp creates an internal handler to service requests
submitted by the client for processing.
Clients
The MINSAT client interface consists primarily of a Java client, which can be run on UNIX
or Windows operating systems. There is also an Application Programming Interface (API)
server that runs on UNIX and supports a programmatic interface (licensable). The Java client
encompasses the following areas of management:
• Customer Care

• Administration

• Batch Administration

• Operation and Maintenance (O&M) Administration

MINSAT is used for the following three types of clients:

• Customer Care/Administration GUI clients

16
• Customer Care API (Application Programmers Interface) clients

• Batch application clients

fqw
The File Queue Worker, fqw, is a daemon that constantly processes files in the
/export/home/minsat/queues directory. The fqw program marks each record in its input file
according to whether it was processed or not.
fqresubmit
The program fqresubmit retries requests that failed when they were processed by fqw. It
marks errors to retry and ignores errors that it cannot retry. It then sets the queue state to
“pending”. If the time period for processing the queue expires or there are no errors to retry,
the queue status is set to “completed”.
opmjobs
The opmjobs program is used to run regular Operation and Maintenance jobs and is generally
configured from cron to run with two entries. One entry for minute jobs and one entry for
daily jobs.
ppb
The ppb program is run daily to allocate promotion plans. It allocates promotion plans based
on the contents of the PromotionPlanAllocation table and will contact the SDP to ensure the
promotions are allocated.
mbd
The script mbd is a script that runs daily and disconnects or removes subscribers from the
SDP as a result of running SDP life cycle disconnect.
masterdr, streamdr, and processdr
The masterdr program runs a number of configured streamdr processes based on the DR
Stream configuration in the MINSAT system. Streamdr runs a set of configured processdrs to
process only LifeCycle Data Records (activation and disconnection) from DR files coming
from SDP. These sets of programs (masterdr, streamdr, and processdr) process LifeCycle
Data Records by directly accessing the csmain database instead of sending requests to
minsatapp.
MINSAT cachemanager
Some of the requests within the minsatapp request engine require the request details to be
loaded from the MINSAT database. In order to improve the performance of these requests, a
cache of all relevant request data in the database is loaded in advance. The high performance
cache is managed by the cachemanager application. The cachemanager uses the cachestartup
program to load the request data into shared memory. When the cachemanager is shut down
again it will call the cacheshutdown program to delete the shared memory

ECMS

17
Ericsson Customer Management System (ECMS) is an end-to-end customer care system for
Ericsson Charging System (CS). ECMS enables simplification and ease-of-use for CSRs
through a user interface that provides a business view and workflows, rather than a highly
technical view of the system. Front-office tasks and maintenance is primarily completed
through the Customer Care client.
ECMS supports the following features :-
Geographical redundancy
Geographical redundancy is supported by means of data replication between two distant sites.
The strategy includes data synchronization and health monitoring. Geographical redundancy
ensures smooth operations in case of disaster or system maintenance. Its implementation is
based on Oracle Data Guard, enhancements of Batch Execution Engine and a new concept
for file duplication.
Support of a Subscriber Base of up to 100,000,000 Subscribers
With this feature, a highly available system setup is offered that is capable to serve a
subscriber base of up to 100,000,000 subscribers. This is achieved by using more powerful
hardware and by distributing application functions and database functions each to a pair
servers in HA configuration.
Account negative balance
For each main account it is possible to define a lower limit for the prepaid balance. In some
cases, the lower limit can have a negative value. That is, the balance for an account would be
allowed to go below zero. In order for an account to have a negative balance, the
corresponding service class must be defined to allow a negative balance. This was already
possible for a service class. However, now the prepaid balance lower limit has precedence
over any service class limits.
Dynamic Discount Solution (DDS) 3.0 - Advise of Discount
Customers can receive a discount based on their location. With this feature it is possible to
advise a customer about the discounts. The available discounts can be viewed in Customer
Care, and when a customer calls, the discount information can be given to the customer.
The status of the discount can be one of the following:
 current - the discount is applicable to the current (or active) call or other service being
used
 potential - the discount would be granted for other calls or services
MEDI Tool

MINSAT ECMS DMI Interface (MEDI) is a tool used for generating data files from MINSAT
database, in the format as required by the ECMS’ Data Migration Interface (DMI) tool to
import the MINSAT data into ECMS database.
The purpose is for the migration from MINSAT to ECMS thus enabling the Charging System
Customer Care function to switch over to ECMS in lieu of MINSAT.
The tool is capable of detecting the MINSAT version (CS3 or CS4 or CS5) automatically
and generates the target files accordingly for ECMS’ DMI tool.
This ‘medi’ tool software is not bundled along with ECMS package, but shall be only
provided for the customers willing to migrate from MINSAT to ECMS.
18
The MEDI tool does not extract Business Configuration data from the MINSAT server to the
ECMS server and hence that is out of scope of this document.
Business configuration of the ECMS server has to be performed before extracting the
subscriber data from the MINSAT server.
CS3, CS4 & CS5 MINSAT versions can use this tool for the recommended migration paths..
There are two configuration files CFG_MAIN.cfg and CFG_VALUE_MAP.cfg available
under ‘/opt/medi/conf’ directory that need to be configured by the user before using the
‘medi’ tool for migration. The configuration files and their purpose are detailed below.
CFG_MAIN.cfg
CFG_MAIN.cfg contains the configuration parameters that are required to export the
subscriber data in the format required for migration of the data into the ECMS server. The
configuration parameters are grouped based on the output interface file and each such group,
viz.,
MIT_CUSTOMER, MIT_CONTRACT, MIT_USER, etc., has its own attributes for which
the possible values could be:
Hard coded, e.g., MIT_ACCESS_KEY="B0001", COUNTRY_CODE="49"
CFG_VALUE_MAP.cfg
The file CFG_VALUE_MAP.cfg contains the configuration based on a key-value pair
mapping between MINSAT and ECMS.
For example, the Organization IDs defined in MINSAT, are mapped to the Business Unit on
ECMS, as below:
"1"="MVNO1"
"3"="MVNO2"
There are as many key-value pairs as defined on MINSAT for that attribute. The MEDI tool
extracts the data from the MINSAT into several batches, with each batch containing a set of
15 interface files, which will then be used for importing the data into the ECMS database by
the DMI tool.
A table ‘MIGRATED_SUBSCRIBER’ in csmain database of MINSAT, holds the list of
subscribers that have been extracted from MINSAT along with the batch ID in which the
subscriber was extracted.
It is possible to set a limit (through the –L option) on the number of subscribers per batch and
the batch ID is automatically incremented for every subsequent batch, until all subscribers
have been extracted. It is also possible to specify start and end subscriber numbers (through
the –S and –E (options) to extract a specific range of subscribers. It is also possible to extract
only the subscribers that have not already been extracted in an earlier run of MEDI i.e.,
those subscribers that are not present in the MIGRATED_SUBSCRIBER table. Cleaning up
the results of the MEDI tool extraction is possible (through the –C option). This also clears
the MIGRATED_SUBSCRIBER table.

2.2. Gaps identified from the existing systems

 The existing system uses a manual procedure that included lot of scripts to be run by the
migrator in order to migrate a single batch.
19
 Each batch consumes a lot of time when migrated manually.

 Due to manual execution of commands and scripts the earlier system is prone to lot of
human errors.

 The existing system doesn’t include an option for rollback in case migration fails at some
point.

 To be able to migrate a batch needs highly trained personnel due to cumbersome process
and order of execution.

 It includes very difficult scripts to be remembered.

 The existing system does not support parallel execution of batches.

 It is not possible to track progress of a batch.

 The existing system does not include error handling.

2.3. Proposed Solution

 The proposed system automates the entire process which eliminates the need to run
scripts by the migrator and the program takes care of it.

The time consumed to migrate each batch would reduce substantially due to automation
of entire process.

 No human errors can occur as scripts are run by the program for the migrator.

 The proposed system includes an option for rollback in case migration fails at some point.

 In proposed system anyone with a little knowledge about migration process would be able
to migrate.

 No need to remember the scripts, the program handles it for the user.

 Parallel execution is a feature of the proposed system.

 In proposed system, progress can be tracked at any point during execution.

 Error handling would be added in the proposed system.

3. Analysis and Design

3.1. Brief Introduction
The system will automate the entire process which will eliminate the need to run scripts by
the migrator and the program will take care of it. The time consumed to migrate each batch
would reduce substantially due to automation of entire process. No human errors can occur as
20
scripts are run by the program for the migrator. The system will include an option for rollback
in case migration fails at some point. In proposed system anyone with a little knowledge
about migration process would be able to migrate. No need to remember the scripts, the
program handles it for the user. Parallel execution is a feature of the proposed system. In
proposed system, progress can be tracked at any point during execution. Error handling
would be added in the proposed system.

3.2. Requirement Analysis

3.2.1. Functional Requirements

4. U1. Login
Precondition Pr1. Must have an account in ECMS Server.

Basic Path 1. Open putty.exe

2 .Connect to ECMS Server
3. Enter ECMS username and password

Post condition Po1. DMI Tool Main Menu is displayed.

Po2. Environment Variables are set.
Po3. Migrate_Status.stat file gets created.

Abnormal Path If the user enters a wrong username or password he

cannot login in ECMS server .

U2. Exit
Precondition Pr1. Already Logged in.
Basic Path 1. Select Exit option.
Post condition Po1. Logged out of ECMS Server.
Abnormal Path None.

U3. Move Data

Precondition Pr1. Must be logged in.
Pr2. Batch to be moved should exists in Migrated directory
Basic Path 1. Select “Move Data” Option from the menu displayed.

Post condition 1. Move data from migrated directory to sample_load

directory.
2. Copy database_load_mdf.xml file into the batch directory.
3. Change Move Status to DONE in Migrate_stat file.
Abnormal Path If sample_load directory already has a batch with the
given name then move it to backup1.

U4. LOAD:INIT
Precondition Pr1. Logged in as ECMS user
Pr2. Environment variables are set
Pr3. Should have already moved data
21
Basic Path 1. Select “Load Option” from the Main Menu displayed.
2. Select “INIT” option from the submenu displayed.
Post condition Po1. dmi_standard_load_{batch_name}_set.xml file
is created from the present
dmi_standard_load_1_set.xmlfile.
Po2. Directory path inside the is set to the current
batch directory.
Po3. Log File gets created
Po4. Load INIT process gets started- MigStart.pl
init -- setup_file dmi_standard_load_
${batch_name}_set.xml
Abnormal Path If Load INIT process is unsuccessful then display error
message and display the path to the log file.

U5. LOAD:START
Precondition Pr1. Logged in as ECMS user
Pr2. Environment variables are set
Pr3. Should have already moved data
Pr4. Load INIT process should have been
successfully executed.
Basic Path 1. Select “Load Option” from the Main Menu Displayed.
2. Select “START” option from the submenu displayed.

Post condition Po1. dmi_standard_load_{batch_name}_set.xml file

is created from the present
dmi_standard_load_1_set.xmlfile.
Po2. Directory path inside the is set to the current
batch directory.
Po3. Log File gets created
Po4. Load START process gets started- MigStart.pl
start -- setup_file dmi_standard_load_
${batch_name}_set.xml

Abnormal Path If Load START process is unsuccessful then display error

message and display the path to the log file.

U6.TRANSFER:INIT
Precondition Pr1. Logged in as ECMS user
Pr2. Environment variables are set
Pr3. Should have already moved data
Basic Path 1. Select “Transfer Option” from the Main Menu displayed.
2. Select “INIT” option from the submenu displayed.
Post condition Po1. dmi_standard_transfer_{batch_name}_set.xml
is created from the present
dmi_standard_transfer_1_set.xmlfile.
Po2. Directory path inside the is set to the current
batch directory.
Po3. Log File gets created
22
 Po4.TRANSFER INIT process gets started
- MigStart.pl start -- setup_file dmi_standard_
transfer_${batch_name}_set.xml
Abnormal Path If Transfer INIT process is unsuccessful then display error
message and display the path to the log file.
U7. TRANSFER:START

Precondition Pr1. Logged in as ECMS user

Pr2. Environment variables are set
Pr3. Should have already moved data
Pr4. Transfer INIT process should have been
successfully executed.
Basic Path 1. Select “Transfer Option” from the Main Menu Displayed.
2. Select “START” option from the submenu displayed.
Post condition Po1. dmi_standard_transfer_{batch_name}_set.xml
is created from the present
dmi_standard_transfer_1_set.xmlfile.
Po2. Directory path inside the is set to the current
batch directory.
Po3. Log File gets created
Po4. TRANSFER START process gets started
- MigStart.pl start -- setup_file dmi_standard_
transfer_${batch_name}_set.xml
Abnormal Path If Transfer Start process is unsuccessful then display error
message and display the path to the log file.

U8.RELEASE:INIT
Precondition Pr1. Logged in as ECMS user
Pr2. Environment variables are set
Pr3. Should have already moved data
Basic Path 1. Select “Release Option” from the Main Menu displayed.
2. Select “INIT” option from the submenu displayed.
Post condition Po1. dmi_standard_release_{batch_name}_set.xml
is created from the present
dmi_standard_release_1_set.xmlfile.
Po2. Directory path inside the is set to the current
batch directory.
Po3. Log File gets created
Po4. Release INIT process gets started- MigStart.pl
init -- setup_file dmi_standard_release_
${batch_name}_set.xml
Abnormal Path If Release INIT process is unsuccessful then display error
message and display the path to the log file.

U9. RELEASE:START

Precondition Pr1. Logged in as ECMS user

Pr2. Environment variables are set
Pr3. Should have already moved data
23
 Pr4. Release INIT process should have been
successfully executed.
Basic Path 1. Select “Release Option” from the Main Menu Displayed.
2. Select “START” option from the submenu displayed.
Post condition Po1. dmi_standard_release_{batch_name}_set.xml
is created from the present
dmi_standard_release_1_set.xmlfile.
Po2. Directory path inside the is set to the current
batch directory.
Po3. Log File gets created
Po4. Release START process gets started- MigStart.pl
start -- setup_file dmi_standard_release_
${batch_name}_set.xml
Abnormal Path If Release Start process is unsuccessful then display error
message and display the path to the log file.

U10.UNDO:INIT
Precondition Pr1. Logged in as ECMS user
Pr2. Environment variables are set
Pr3. Should have already moved data
Basic Path 1. Select “Undo Option” from the Main Menu displayed.
2. Select “INIT” option from the submenu displayed.
Post condition Po1. dmi_standard_undo_{batch_name}_set.xml
is created from the present
dmi_standard_undo_1_set.xmlfile.
Po2. Directory path inside the is set to the current
batch directory.
Po3. Log File gets created
Po4. Undo INIT process gets started- MigStart.pl
init -- setup_file dmi_standard_undo_
${batch_name}_set.xml
Abnormal Path If UNDO INIT process is unsuccessful then display error
message and display the path to the log file.

U11.UNDO:START

Precondition Pr1. Logged in as ECMS user

Pr2. Environment variables are set
Pr3. Should have already moved data
Pr4. Undo INIT process should have been
successfully executed.

Basic Path 1. Select “Undo Option” from the Main Menu Displayed.
2. Select “START” option from the submenu displayed.
Post condition Po1. dmi_standard_undo_{batch_name}_set.xml
is created from the present
dmi_standard_undo_1_set.xmlfile.
Po2. Directory path inside the is set to the current
batch directory.
Po3. Log File gets created
24
 Po4. Undo START process gets started- MigStart.pl
start -- setup_file dmi_standard_undo_
${batch_name}_set.xml
Abnormal Path If Undo Start process is unsuccessful then display error
message and display the path to the log file.

U12.DMI_INSTALL:INIT
Precondition Pr1. Logged in as ECMS user
Pr2. Environment variables are set
Pr3. Should not have dmi already installed
Basic Path 1. Select “DMI Option” from the Main Menu displayed.
2. Select “INIT” option from the submenu displayed.
Post condition Po1.The log file should be created with the details of the
process executed.
Po2.The DMI_INSTALL_INIT successful line was
echoed in the terminal window.
Abnormal Path If DMI_INSTALL INIT process is unsuccessful then display
error message and display the path to the log file.

U13.DMI_INSTALL:START

Precondition Pr1. Logged in as ECMS user

Pr2. Environment variables are set
Pr4. DMI_INSTALL INIT process should have been
successfully executed.
Basic Path 1. Select “DMI Option” from the Main Menu Displayed.
2. Select “START” option from the submenu displayed.
Post condition Po1.The log file should be created with the details of the
process executed.
Po2.The DMI_INSTALL_START successful line was
echoed in the terminal window.

Abnormal Path If DMI_INSTALL START process is unsuccessful then display

error message and display the path to the log file.

U14.DMI_UNINSTALL:INIT
Precondition Pr1. Logged in as ECMS user
Pr2. Environment variables are set
Pr3. Should have dmi already installed
Basic Path 1. Select “DMI Option” from the Main Menu displayed.
2. Select “INIT” option from the submenu displayed.

25
 Post condition Po1.The log file should be created with the details of the
process executed.
Po2.The DMI_UNINSTALL_INIT successful line was
echoed in the terminal window.
Abnormal Path If DMI_UNINSTALL INIT process is unsuccessful then
display error message and display the path to the log file.

U15.DMI_INSTALL:START

Precondition Pr1. Logged in as ECMS user

Pr2. Environment variables are set
Pr4. DMI_UNINSTALL INIT process should have been
successfully executed.
Basic Path 1. Select “DMI Option” from the Main Menu Displayed.
2. Select “START” option from the submenu displayed.
Post condition Po1.The log file should be created with the details of the
process executed.
Po2.The DMI_UNINSTALL_START successful line
was echoed in the terminal window.
Abnormal Path If DMI_UNINSTALL START process is unsuccessful then
display error message and display the path to the log file.

Table 1

3.2.1.1 Product Perspective

The existing system uses a manual procedure that included lot of scripts to be run by the
migrator in order to migrate a single batch which would be replaced by an automated process
in new system.
Each batch consumes a lot of time when migrated manually which would get substantially
reduced in the new system. Due to manual execution of commands and scripts the earlier
system is prone to lot of human errors which will get eliminated by automation of entire
migration process.
The existing system doesn’t include an option for rollback in case migration fails at some
point which would be a feature in the new system. To be able to migrate a batch needs highly
trained personnel due to cumbersome process and order of execution but in new system only
basic knowledge about Black box migration would be sufficient to run the program. It
includes very difficult scripts to be remembered which would be eliminated in the new
system as everything would be automated.
The existing system does not support parallel execution of batches which would be included
as a feature in the new system. It is not possible to track progress of a batch in the existing
system but can be tracked in the new system.

3.2.1.2 Product features

• DMI Automation Tool can move data to the working directory.

• It can Load subscriber data into a temporary database schema DMFADM.

• It can Transfer Subscriber data into a permanent database schema SYSADM.

26
• It can also Release the final version of the database and commit everything.

• DMI Automation Tool can roll back the database at any point in case some failure
happens during the migration process.

• It can also undo the process in case user changes its mind or some error occurs.

• It can also install DMI interface into the ECMS server.

• DMI interface can also be uninstalled and its database can be cleaned of its entry.

• It can track the status of each batch being migrated.

• It also maintains log of every process been run.

• DMI Automation Tool can migrate multiple batches at same time.

• It can skip a part in case if it has been already done for a batch.

3.2.1.3 User characteristics

• Network Administrators

• System Administrators

• Application Administrators

• Operation and Maintenance personnel

3.2.1.4 Operating requirements

The following are the operating requirements for DMI Tool:-
• Hard Disk (300 GB)

• Physical Memory (4 GB)

• Solaris v5.10 or above (Server)

• Windows XP or above (User)

Both MINSAT and ECMS server must be capable of running:-

• Pearl Script

• Shell Script

• Korn Shell Script

• SQL Query

3.2.1.5 Assumption & Dependencies

Move Data
 Assumption:- Must be logged in as ECMS user.
27
 Batch to be moved should exists in Migrated directory
 Dependencies:-If sample_load directory already has a batch with the given name then
move it to backup1.

LOAD Data
 Assumption:- Logged in as ECMS user
Environment variables are set
Should have already moved data
For Load START process Load INIT process should be completed
successfully

 Dependencies:- If Load INIT process is unsuccessful then display error message and
display the path to the log file.
If Load START process is unsuccessful then display error message and
display the path to the log file.

TRANSFER Data

 Assumption:- Logged in as ECMS user

Environment variables are set
Should have already moved data and completed LOAD process
For Transfer START process Transfer INIT process should be completed
successfully

 Dependencies:- If Transfer INIT process is unsuccessful then display error message and
display the path to the log file.
If Transfer START process is unsuccessful then display error message
and display the path to the log file.
RELEASE Data

 Assumption:- Logged in as ECMS user

Environment variables are set
Should have already moved data and completed LOAD and
TRANSFER process
For Release START process Release INIT process should be
completed successfully.

 Dependencies:- If Release INIT process is unsuccessful then display error message and
display the path to the log file.
If Release START process is unsuccessful then display error message
and display the path to the log file.

UNDO Data

 Assumption:-Logged in as ECMS user

Environment variables are set
Should have already moved data

28
 For UNDO START process UNDO INIT process should be completed
successfully

 Dependencies:- If Undo INIT process is unsuccessful then display error message and
display the path to the log file.
If Undo START process is unsuccessful then display error message and
display the path to the log file.

INSTALL DMI

 Assumption:- Logged in as ECMS user

Environment variables are set
DMI not installed previously

 Dependencies:- If Install DMI INIT process is unsuccessful then display error message
and display the path to the log file.
If Install DMI START process is unsuccessful then display error
message and display the path to the log file.

UNINSTALL DMI

 Assumption:- Logged in as ECMS user

Environment variables are set
DMI installed previously

 Dependencies:- If UnInstall DMI INIT process is unsuccessful then display error

message and display the path to the log file.
If UnInstall DMI START process is unsuccessful then display error
message and display the path to the log file.

3.2.1.6 Domain Requirements

The user should be familiar with Ericsson Customer Management System 3.1 Support
Documentation and must have sufficient knowledge about black box migration.

3.2.1.7 User Requirements

• System moves the batch to input directory where user can start the process.

• System loads the data into the temporary schema DMFADM when user runs the Load
process.

• System transfers the data from the temporary schema DMFADM to permanent schema
SYSADM when user runs the Transfer process.

• System commits the changes into the permanent schema SYSADM when user runs the
Release process.

• System accepts the batch name to be migrated from the user.

• System rollbacks the database when user selects the rollback option.

• System unloads the database schema when user selects the UNDO option.
29
• System installs the DMI Tool in the server when user selects the DMI INSTALL option.

• System uninstall the DMI Tool when user selects the DMI Uninstall option.

3.2.2 Non Functional Requirements

3.2.2.1 Performance requirements
Charging System has a maximum subscriber capacity of 32 million subscribers. Depending
on the capacity requirements, a Charging System can consist of one or more SDPs, VSs,
IVRs, SCPs, CCNs, Multi Mediation Solutions and two or more AFs and AIRs.

3.2.2.2 Safety requirements

To ensure data safety and stability for final database, subscriber data is first migrated to a
temporary schema called as DMFADM and afterwards transferred to a permanent schema
SYADM.

3.2.2.3 Security requirements

It is highly secured as only ECMS user with a valid account is able to migrate data and no
one else can.

3.3 Design of the proposed system

3.3.1 Design
3.3.1.1 Design Overview

30
Figure 1

31
 Figure 2

Figure 3

32
Figure 4

33
Figure 5

34
3.3.1.2 Requirements Traceability Matrix
Requirement Statement Of Need Business Area Business Status
ID Priority
1 Karlskrona Windows DMI Automation High Accepted
Server
2 ECMS Server DMI Automation High Accepted
3 MINSAT Server DMI Automation High Accepted
4 PuTTY DMI Automation High Accepted
5 WINSCP DMI Automation Moderate Accepted
6 CCN Server Call Charging Low Rejected
7 SDP Server Subscriber Data Low Rejected
8 MEBC Package Business High Accepted
Configuration
9 MEDI Package Data Configuration High Accepted
10 Oracle SQL Developer Database Moderate Accepted
Table 2

3.3.2 System Architectural Design

3.3.3.1 Chosen System Architecture

Figure 6

35
3.3.3 System Interface Description
3.3.3.1 Detailed Description of Components

Network Elements Description

The SDP network element contains the database with
subscribers and account information. It also provides rating
of calls and events, post processing of Charging Data Records
Service Data Point (CDRs), initiation of Unstructured Supplementary Service
(SDP) Data (USSD) notifications and SMS notifications. SDP is also
used to trigger the setup of a USSD callback call and to take
and return policy decisions

Network Elements Description

The following two administrative systems (ADMIN) for
Mobile IN Service Charging System:
Administration Tool • ECMS
(MINSAT) • MINSAT
MINSAT is only supported for upgrading customers.
ADMIN handles subscriber administration for Charging
Ericsson Customer System. No traffic is handled, but interaction in real time with
Management other systems for provisioning and updates are possible
System (ECMS) through GUI and through the external interfaces provided. At
subscriber provisioning and removal, ADMIN may interact
with both the Account Finder (AF) and SDP, as well as
optionally connect with external systems. ADMIN is used to
display the call and account history. Change of MSISDN or
displaying history of changed MSISDN is not supported in
ECMS.

OCC provides access for data charging of pre-paid and post-

paid subscribers in real time. It acts as a protocol translator
between the core network and the charging system. The
network element internal logic is used to detect roaming
scenarios as well as to distinguish post-paid users from pre-
paid subscribers.
OCC also maintain charging interrogation sessions to SDP
Online Charging OCC terminates the Diameter Credit Control Application
Control (OCC) (DCCA) for Charging System.
OCC also acts as a proxy agent, containing proxy logic for
policy management.
OCC contains service logic for the Diameter service
charging application to support content-based services.
OCC also contains proxy logic and acts as a proxy agent for
policy management. OCC is based on functions from Online
mediation.
The subscriber can use IVR to change and inquire about
Voice Extensible account information, for example, refills and account balance

36
 Markup Language enquiries.
Interactive Voice IVR interacts with Account Information and Refill System
Response System (AIR) to implement the services it provides to subscribers.
(VXML-IVR) IVR can also be used for contacting customer care.

CCN service logic is responsible for maintaining charging

sessions to the application network element, as well as
charging interrogation sessions to SDP.
CCN logic is able to handle circuit switched calls and data for
CS1+, as well as CAPv1, CAPv2, CAPv3, and ERTC access.
Handling of SMS over CS1+, CAPv3 (originating SMS), and
ERTC is supported. CCN also handles GPRS over CAPv3.
CCN also terminates the DCCA for Charging System.
Charging Control CCN contains service logic for the Diameter service charging
Node (CCN) application to support content-based services..
AIR handles external integration of user communication and
administrative network elements.
AIR has three function groups; refill function, adjustment
function, and the enquiry and update function.
Account Information and AIR handles account information in the form of enquiries and
Refill System account administration. It supports a number of file-based
(AIR) batch jobs for making bulk adjustments, promotions, and
refills.
AIR can handle multiple Voucher Servers (VSs).
Charging data CRS is a system for correlating information from many
Reporting System different sources to reconcile provisioning and usage
(CRS) information, provides information for customer enquiries in
near real time, and manage the complex tasks of a Charging
System business. CRS collects data from various network
sources, then filters, correlates, and transforms this
information to provide business critical reports for customer
care, financial and audit departments.
Table 3

3.3.4 Considered Design Constraints

3.3.4.1 Economic
The system needs an ECMS Server and an MINSAT server to migrate the data effectively.

3.3.4.2 Ethical
The code of the software cannot be in any way published or used outside the premises of
Ericsson Private Limited.

3.3.4.3 Sustainability
The system can sustain without any changes required until the database schema are
unchanged and no modification is done to them.

3.3.4.4 Legality
The system can only be used for migration purposes by Ericsson Private Limited and its
customer who purchased their copy from Ericsson.
37
3.3.4.5 Inspectability
The system can be inspected by any user who has a basic knowledge about Black Box
Migration Process.

4 Implementation
4.1 Tools Used
General Introduction
The following tools have been used for the creation of DMI Automation Tool:-
PuTTy - PuTTY is a client program for the SSH, Telnet and Rlogin network protocols.
WinSCP3 v3.8.2 - WinSCP (Windows Secure CoPy) is a free and open
source SFTP, SCP and FTP client for Microsoft Windows. Its main function is secure file
transfer between a local and aremote computer.
Oracle SQL Developer v1.5.3 - Oracle SQL Developer is an Integrated development
environment (IDE) for working with SQL in Oracle databases. Oracle Corporation provides
this product free; it uses theJava Development Kit.
VI Editor - vi is a screen-oriented text editor originally created for the Unix operating system.
The portable subset of the behavior of vi and programs based on it, and the ex editor language
supported within these programs
Notepad++ - It is a text editor and source code editor for Windows. It aims to be a
lightweight and robust editor for a variety of programming and scripting languages.

Reason for selecting tool

PuTTY was selected because to connect to ECMS and MINSAT server and PuTTY is a free
and open source terminal emulator application which can act as a client for SSH and also it
can run on Windows.
WinSCP3 provides an excellent Graphical User Interface and support secure transfers using
SSH and SCP which were used to push file to the MINSAT and ECMS server. It is also free
and open source.
Oracle SQL Developer is a free product from Oracle which was used to connect to database
located globally. It was used to connect to various SYSADM and DMFADM schema. Since
our target database is ORACLE hence we used this software to connect to it.
Vi is universally available on Unix systems. It has been around so long in a stable form that it
is essentially bug free. Many clones have been written for other kinds of computers. Vi has
many powerful commands that utilize just the alphanumeric keys -- it does not require special
function.
Notepad++ has an advantage over the built-in Windows text editor Notepad, is that Notepad+
+ supports tabbed editing, which allows working with multiple open files. It is also a free
software. It supports syntax highlighting and syntax folding which greatly helps while writing
the code.

38
4.2 Implementation
4.2.1. USER INTERFACE DESIGN

Figure 7

Figure 8

4.2.1.1 Description of the User Interface

39
Main – Menu
Main – Menu consists of 6 options related to the batch to be migrated and 1 option for Exit.
Each option has a sub menu within it except Install DMI and Uninstall DMI. Any option can
be selected by entering the number corresponding to it and hitting enter. Each option is
arranged as a step in the Data Migration and each option holds some meaning as described
below:-
Load Data – The load process loads subscriber data from the interface files into the migration
interface tables of the DMIADM schema (so-called MIT tables).
Transfer Data – The transfer process transfers subscriber data from MIT tables in DMIADM
schema into ECMS tables in SYSADM schema.
Release Data – By default, customer data are locked in the target database when transferred.
If customer data have to be released in a migration that he uses this option.
Undo Data – Transfer of data from DMIADM schema, i.e. the MIT tables, to SYSADM
schema can be undone if required. In case of online migrations this is possible even after data
have been released, however, all changes applied to such data after release would be lost in
case of undo.
Install DMI – This procedure installs the Data Migration Interface. This creates the DMI and
DMIADM schemas including all necessary PL/SQL packages.
Uninstall DMI – After a successful migration DMI itself and the migration log files should be
removed, additionally all related DMF entries should be cleaned up. This can be achieved by
using the DMF cleansing process. It will remove DMI and DMIADM schemas from the
database and clean up log files and DMF entries (as configured).
Exit – It exits the user from entire DMI process.
Sub – Menu
Load data, Transfer data, Release Data and Undo Data consists of sub menu which gives the
option for either just initialize the process or to Start it or do both at the same time. Like,
Main Menu it is also a switch case kind of interface where user has to enter the number
corresponding to the option he want to select and hit enter. It also shows the current status of
that option for the batch whether it has been DONE or NOT_DONE yet. Each option of it is
described below:-
INIT – Initialize the load process. Within this step, scripts and parameters are registered in
Oracle schema DMF within ECMS database.
START – Execute the load process. Within this step, scripts registered in step before are
executed, using registered parameters.
INIT & START – If user wishes to run both Initialization process as well as the Start process
at the same time he can do so by select this option.
Exit – It exists from the submenu and directs to the Main – Menu.

40
4.2.1.2. Screen Images

41
Figure 9

Figure 10

Figure 11

42
Figure 12

43
Figure 13

Figure 14

Figure 15
44
Figure 16

45
Figure 17

Figure 18

46
Figure 19

Figure 20

47
Figure 21

Figure 22

48
Figure 23

Figure 24

Figure 25

49
Figure 26

50
Figure 27

Figure 28

51
Figure 29

Figure 30

52
Figure 31

Figure 32

53
Figure 33

Figure 34
54
Figure 35

Figure 36

55
Figure 37

Figure 38
56
Figure 39

Figure 40

57
Figure 41

Figure 42

58
Figure 43

Figure 44

59
 Figure 45

4.2.1.3. Objects and Actions

60
 Objects Actions

./dmiauto Displays the help menu

./dmiauto -h Displays the help menu

./dmiauto -P <Batch Id> Displays the progress of the inputed batch

./dmiauto -B <Batch Id> -L -I Starts the initialization process of load

./dmiauto -B <Batch Id> -L -S Starts the start process of load

./dmiauto -B <Batch Id> -L -I -S Starts the initialization and start process of load

./dmiauto -B <Batch Id> -T -I Starts the initialization process of transfer

./dmiauto -B <Batch Id> -T -S Starts the start process of transfer

./dmiauto -B <Batch Id> -T -I -S Starts the initialization and start process of transfer

./dmiauto -B <Batch Id> -R -I Starts the initialization process of release

./dmiauto -B <Batch Id> -R -S Starts the start process of release

./dmiauto -B <Batch Id> -R -I -S Starts the initialization and start process of release

./dmiauto -B <Batch Id> -U -I Starts the initialization process of undo

./dmiauto -B <Batch Id> -U -S Starts the start process of undo

./dmiauto -B <Batch Id> -U -I -S Starts the initialization and start process of undo

./dmiauto -B <Batch Id> -D Starts the installation process of the DMI tool

./dmiauto -B <Batch Id> -C Starts the un installation process of the DMI tool

./dmiauto -B <Batch Id> -M Starts the the menu driven execution of the automation tool

Table 4

4.3 Testing

61
4.3.1 Test Approach
After migrating data as specified in the ERICSSON Data Migration Specification, we need to
validate the correctness of the resulting data. This is a critical activity. Improperly converted
data can lie dormant and cause invalid results in the new system and, often worse, invalid
results that remain undetected. Careful validation is needed to prevent this time bomb effect.
The risk is often heightened because of the volume of much of the data and because the
project team may have only indirect control of the conversion process.
As with all testing activities, we should first define the test strategy that we will use to
validate the migrated data. The following considerations should be taken into account:
• Data accuracy

• Testing of Automated Data Migration

• Control procedures

Data Accuracy
In data migration, the resulting data may not always need to be completely accurate, as
complete accuracy may be uneconomic or impossible.
• For our application, figures must be accurate. The customers information must be the
same in the ORACLE database as it was in the SYBASE database. So the accuracy or data in
our case must be high and the exact data must be transferred without and discrepancies.
Testing of Automated Data Migration
Special attention must be paid to automatically migrated data to ensure that there are no
errors in the migration software. Migrated data should be verified to ensure that an
appropriate level of accuracy has been achieved.
When results fall outside the acceptable accuracy range, identify the causes and initiate
corrective procedures, such as:
• Make required corrections to source data and re-run the conversion.
• Identify corrections to the automated data conversion software, and re-run the
conversion once the software has been fixed.
• Note the data errors for manual correction on the new system.
• The database must be flushed before re running the code.
Control Procedures
Control procedures must be defined to ensure that all input data is completely and accurately
converted. These procedures can consist of manually checking all or a sampling of data
before and after conversion or manually checking of reports created from the data. The
degree of validation required depends on the criticality of the data being converted.

4.3.2 TEST PLAN

62
4.3.2.1. Features to be tested
The following features were tested both as command line and from Menu:-

 Transfer of Batch from MINSAT server to ECMS server.

 Setting of Environments Variables.

 Load Initialization Process.

 Load Start Process.

 Skipping of Load Process.

 Transfer Initialization Process.

 Transfer Start Process.

 Skipping of Transfer Process.

 Release Initialization Process.

 Release Start Process.

 Skipping of Release Process.

 Undo Initialization Process.

 Undo Start Process.

 Creation XML Files – dmi_standard_load_B0001_set.xml,

dmi_standard_transfer_B0001_set.xml, dmi_standard_release_B0001_set.xml,
dmi_standard_undo_B0001_set.xml, dmi_B0001_par.xml.

 Creation of Status File – Migrate_Status.stat

 Creation of Log files for each stage of individual process.

 Installation of DMI in case not previously installed.

 Skipping Installation of DMI Installed in case previously installed.

 Uninstall DMI.

4.3.2.2. Features not to be tested

 Un orderly execution of LOAD, TRANSFER and RELEASE Process.

 Un orderly execution of INIT and START.

 Starting migration process without DMI being installed.

 Starting migration process without setting the environment variables.

63
4.3.3 Testing Tools and Environment
The testing of this system doesn’t require any special tools for testing. Since, it is a command
based system commands were manually as well as through menu were tested and verified.
The system needs specific environment to be tested. It needs MINSAT and ECMS Servers
and global variables in initialized state.

4.3.4 TEST CASES

Test Case ID DMI01
Purpose Checking if environment is set or not.
Input Run the script dmiauto.
Expected Output A line should be echoed saying “Environment Set” if successful.
Actual Output “Environment Set” was echoed in the terminal window.
Pass/Fail PASS

Test Case ID DMI02

Purpose Setting of correct system Date
Input Running a script with a same batch name that is already present in
sample_load
Expected Output The batch in sample_load to be moved to dmi_backup with the current date
included in its name.
Actual Output A batch with the correct system time was found in the dmi_backup directory.
Pass/Fail PASS

Test Case ID DMI03

Purpose Log files getting created and updated with the details of the process
Input Run any process like load_init or load_start.
Expected Output A log file of the corresponding process be created with the process details
Actual Output A log file was created with all details including the details about spool files
Pass/Fail PASS

Test Case ID DMI04

Purpose Error reporting INIT process.
Input Run the script for Load_INIT or Transfer_INIT or Release_INIT
Expected Output If there is an error it must be reported in log file and process unsuccessful be
echoed.
Actual Output The errors like DMF_FATAL & DMF_ERROR were caught and
64
 unsuccessful process was reported.
Pass/Fail PASS

Test Case ID DMI05

Purpose Error reporting START process.
Input Run the script for Load_START or Transfer_ START or Release_ START
Expected Output If there is an error it must be reported in log file and process unsuccessful be
echoed.
Actual Output The errors like DMF_FATAL, DMF_ERROR, Error in script and
Reinitilization Not Possible were caught, the spool file name was written to
log files and unsuccessful process was reported.
Pass/Fail PASS

Test Case ID DMI06

Purpose Check if user is ECMS user or not
Input Run the script dmiauto as ROOT and ECMS user
Expected Output In the first case the script should not be executed while it sould be executed
in later case.
Actual Output Unauthorized User was displayed in first case while the script got executd in
later case.
Pass/Fail PASS

Test Case ID DMI07

Purpose Checking if MOVE_DATA works properly.
Input Run the script dmiauto with a vaild batch name.
Expected Output  Move the batch to sample_load directory.
 Check If a copy of database_load_mdf.xml is copied into the batch
folder.
 Migrate_status.stat file must be created.
 If a batch is already present in sample_load the it must be moved to
dmi_backup.
Actual Output  The batch was moved to sample_load.
 The database_load_mdf.xml was copied into the batch folder.
 Migrate_status.stat file was created with move_data status set to DONE.
 If an batch is already present it was moved to dmi_backup.
Pass/Fail PASS

65
Test Case ID DMI08
Purpose To check LOAD_INIT process.
Input Start the load_init process for a valid batch that has been moved.
Expected Output  The require xml file must be created in resources directory with
changes.
 The LOAD_INIT successful line must be echoed.
Actual Output  The XML file was created dynamically with the required changes.
 The LOAD_INIT successful line was echoed in the terminal window.
Pass/Fail PASS

Test Case ID DMI09

Purpose To check LOAD_START process.
Input Start the load_start process for a valid batch that has been moved and load
init process completed successfully.
Expected Output  The require xml file must be present in resources directory with
changes.
 The LOAD_START successful line must be echoed.
 The XML file must be deleted if process is successful.
Actual Output  The XML file was present with the required changes.
 The LOAD_START successful line was echoed in the terminal
window.
 The XML file was deleted from the resources directory.
Pass/Fail PASS

Test Case ID DMI10

Purpose To check TRANSFER_INIT process.
Input Start the transfer_init process for a valid batch that has been moved and
LOAD process completed.
Expected Output  The require xml file must be created in resources directory with
changes.
 The TRANSFER_INIT successful line must be echoed.
Actual Output  The XML file was created dynamically with the required changes.
 The TRANSFER_INIT successful line was echoed in the terminal
window.
Pass/Fail PASS

Test Case ID DMI11

Purpose To check TRANSFER_START process.
Input Start the transfer_start process for a valid batch that has been moved and
transfer init process completed successfully.
66
Expected Output  The require xml file must be present in resources directory with
changes.
 The TRANSFER_START successful line must be echoed.
 The XML file must be deleted if process is successful.
Actual Output  The XML file was present with the required changes.
 The TRANSFER_START successful line was echoed in the terminal
window.
 The XML file was deleted from the resources directory.
Pass/Fail PASS

Test Case ID DMI12

Purpose To check RELEASE_INIT process.
Input Start the release_init process for a valid batch that has been moved and
LOAD and TRANSFER process completed.
Expected Output  The require xml file must be created in resources directory with
changes.
 The RELEASE_INIT successful line must be echoed.
Actual Output  The XML file was created dynamically with the required changes.
 The RELEASE_INIT successful line was echoed in the terminal
window.
Pass/Fail PASS

Test Case ID DMI13

Purpose To check RELEASE_START process.
Input Start the release_start process for a valid batch that has been moved and
release init process completed successfully.
Expected Output  The require xml file must be present in resources directory with
changes.
 The RELEASE_START successful line must be echoed.
 The XML file must be deleted if process is successful.
 The batch must ne moved to dmi_backup if successful.
Actual Output  The XML file was present with the required changes.
 The RELEASE_START successful line was echoed in the terminal
window.
 The XML file was deleted from the resources directory.
 The batch was moved to dmi_backup directory.
Pass/Fail PASS

Test Case ID DMI14

67
Purpose To check UNDO_INIT process.
Input Start the undo_init process for a valid batch.
Expected Output  The require xml file must be created in resources directory with
changes.
 The UNDO_INIT successful line must be echoed.
Actual Output  The XML file was created dynamically with the required changes.
 The UNDO_INIT successful line was echoed in the terminal window.
Pass/Fail PASS
Test Case ID DMI15
Purpose To check UNDO_START process.
Input Start the load_start process for a valid batch that has been moved and load
init process completed successfully.
Expected Output  The require xml file must be present in resources directory with
changes.
 The UNDO_START successful line must be echoed.
 The XML file must be deleted if process is successful.
Actual Output  The XML file was present with the required changes.
 The UNDO_START successful line was echoed in the terminal
window.
 The XML file was deleted from the resources directory.
Pass/Fail PASS

Test Case ID DMI16

Purpose To check DMI_INSTALL_INIT process.
Input Start the dmi_install_init process for a valid batch.
Expected Output  The log file must be created.
 The DMI_INSTALL_INIT successful line must be echoed.
Actual Output  The log file was created with the details of the procedure executed.
 The DMI_INSTALL_INIT successful line was echoed in the terminal
window.
Pass/Fail PASS

Test Case ID DMI17

Purpose To check DMI_INSTALL_START process.
Input Start the dmi_install_start process for a valid batch.
Expected Output  The DMI_INSTALL_START successful line must be echoed.
 The log file must be created.
Actual Output  The log file was created with the details of the procedure executed.
 The DMI_INSTALL_START successful line was echoed in the
terminal window.
Pass/Fail PASS

68
Test Case ID DMI18
Purpose To check DMI_UNINSTALL_INIT process.
Input Start the dmi_uninstall_init process for a valid batch.
Expected Output  The log file must be created.
 The DMI_UNINSTALL_INIT successful line must be echoed.
Actual Output  The log file was created with the details of the procedure executed.
 The DMI_UNINSTALL_INIT successful line was echoed in the
terminal window.
Pass/Fail PASS

Test Case ID DMI19

Purpose To check DMI_UNINSTALL_START process.
Input Start the dmi_uninstall_start process for a valid batch.
Expected Output  The DMI_UNINSTALL_START successful line must be echoed.
 The log file must be created.
Actual Output  The log file was created with the details of the procedure executed.
 The DMI_UNINSTALL_START successful line was echoed in the
terminal window.
Pass/Fail PASS

Test Case ID DMI20

Purpose Checking if batch exists or not.
Input Run the script dmiauto with a vaild and invalid batch name.
Expected Output  In case of valid batch the script will run.
 In case of invalid batch it will ask to enter a valid batch.
Actual Output Wrong batch name was echoed in case of invalid batch and the script ran
perfectly in case of valid batch.
Pass/Fail PASS

Test Case ID DMI21

Purpose Checking the Progress of a batch.
Input Run the script dmiauto with the -P option and a valid batch name.
Expected Output The status of the batch should be shown.
Actual Output The status of the batch showing which process is DONE and which are
NOT_DONE was echoed in the terminal window.
Pass/Fail PASS

Table 5
4.3.5 Test Procedure
69
Purpose

The purpose of the test procedure specification is to provide the user with the guideline of
how to use the test cases and what to do in case of any error during the testing. The various
test cases are discussed in detail below.

Special Requirements

The prerequisite for testing is that one must have both the ECMS and MINSAT servers with
the MEDI, MEBC packages installed. We are required to have PuTTY installed in our system
to run the script and test our system. The user running the code must be familiar with the
working of the Ericsson code of data migration and should have the knowledge about how to
use Korn Shell Script. He should also know hoe to read the log files and be able to identify
the errors enlisted in the log file, understand them and find an way to correct it.

Procedure Steps
Log The log files for each process gets created in the log directory in sample_load.
Setup Both MINSAT and ECMS server must be set up first and then the MEDI and MEBC
package must be installed.
Start Start the procedure by executing the dmiauto script.
Proceed Provide the information as asked during the execution like selecting the process in
case of menu driven.
Measure The test measurement will be made with valid and invalid parameters as described in
the test cases.
Shutdown The test at any time can be shutdown by selecting option 7 which is exit otherwise by
pressing ctrl+z to break out.
Restart The code can be restarted at any time just by starting to executing the script again.
Wrap Up If it is to be run again then make sure that the MEBC package has been installed
successfully.
Contingencies For anomalous situation during the execution of script please check the log files
which contains the details of the procedure executed and also the errors if any.

Table 6

5 Results and Discussion

70
5.1Results
The tool is able to migrate data from MINSAT (SYBASE) to ECMS (ORACLE) successfully
through the 3 stages 2-step process consisting of LOAD, TRANSFER and RELEASE stages
with each stage having 2 steps – INIT and START. The process creates an intermediate
database schema called as DMFADM and a final database schema as DMIADM. The tool is
able to install as well as uninstall DMI from ECMS server and is also able to check
previously installed version of it. It can also UNDO at any stage in case it goes wrong. It
supports progress of the batch and performance setting. Databases can be flashed back at any
point in case something goes wrong.

5.2Performance Analysis

Migration Parameters Mid-Range Company Large Company

No. of database products 4-6 10-12
Data volume in giga bytes 100 (approx) >1000
No. of record types 300 (approx) >1000
No, of data elements 5000 (approx) >10000
No. of transaction per second 50-80 >100
Table 7

The performance of the DMI Automation Tool was analyzed on the basis of the time taken
and space consumed to transfer subscriber data from MINSAT server to ECMS server.

 70 million subscribers were successfully transferred from MINSAT to ECMS.

 To successfully transfer 1 million of subscriber the program takes 40 minutes from Load
to Release.
 To Load 1 million of data into the DMF Schema the tool takes 3 minutes.
 To Transfer 1 million of data into the DMI Schema the tool takes 35 minutes.
 To Release 1 million of data into the SYS Schema the tool takes 2 minutes.
 To run the tools the system need just 2MB from free space.
 To successfully transfer 1 million of subscriber the program consumes 5GB of space.
 To Flash back 1 million of subscriber data the program take 5 minutes to flash back the
database to original state.

6 Conclusion and Future Enhancements

The tool successfully automates the process of Data Migration between MINSAT and ECMS
server. The designed tool would work for any number of subscriber data. This model is
71
working fine with main frame source data migration into Oracle DB, this process and
methodology for Data Migration where huge volume of data is involved between databases in
less or more accurate and reducing effort by 40% to 50%. The benefit of this tool is saving of
time, money, and data quality will be high around 30% when compared to manual process
and its 21% efficient with respect to time and defects raised.
In future, the tool would also be able to add functionality for displaying a progress bar. The
tool would also be able to migrate from other databases. A GUI can also be developed over
the present framework in case it’s needed. Global design of a corporate – wide data
architecture will let this tool to be used by other companies as well.

72
7 References
ERICSSON Customer Management 3.1 Support Documentation

http://srvdocpub.lhs-
systems.com/st4/ecms_3.1_support_documentation/current/Documentation/start.html

ECMS Migration Study Brazil

Charging System 3.0 Support Documentation

MINSAT Network Element Description 7.2.2

Learning the KornShell By Bill Rosenblatt, Arnold Robbins

Learning the bash Shell : Unix Shell Programming By Cameron Newham

Expert Shell Scripting By Ron Peters

73