KlarSynt ToolsA tool for automating configurations of test environments

Simon Vestin & Daniel Svensson

Faculty of Health, Science and Technology

Computer Science

Bachelor's Degree, 15 points

Supervisor: Leonardo Martucci

Examinator: Donald F. Ross

2014-06-03

KlarSynt Tools - A tool for automating

configurations of test environments

Simon Vestin, Daniel Svensson

c© 2014 The author(s) and Karlstad University

This report is submitted in partial fulfillment of the requirements

for the Bachelor’s degree in Computer Science. All material in

this report which is not our own work has been identified and

no material is included for which a degree has previously been

conferred.

Simon Vestin

Daniel Svensson

Approved, 2014-06-03

Advisor: Leonardo Martucci

Examiner: Donald F. Ross

iii

Abstract

Preparing dedicated environments for testing often requires time consuming, manual con-

figurations to be made on databases and the Windows Registry. A proposed Windows

application could improve the efficiency and accuracy of such settings by automating the

processes and providing a user-friendly graphical user interface. On behalf of Ninetech, a

consulting company, such an application was therefore developed - KlarSynt Tools. This

application was to enhance the company’s previous methods of configuring test environ-

ments by removing the need of manual tasks and the use of an unoptimized tool called

Verktyg.

In the development of the application features such as connecting to servers, retrieving

data from databases, and automatic configurations of the Windows Registry was imple-

mented. Problems such as automating manual tasks had to be dealt with for providing

accuracy of the configurations. The usage of development patterns such as MVVM was

also utilized in the project to provide flexibility in the program code, and in that way

prepare the software for future development. Finally, user-friendliness was integrated into

the application interface to provide efficiency in the usage of the application.

This project resulted in that a Windows application was developed to accurately and

efficiently configure settings to a database and the Windows Registry. The developed

application showed to significantly reduce the number of steps required and the time taken

to perform the configurations in the old process.

v

Acknowledgements

We would like to thank our supervisor at Karlstad University, Leonardo Martucci, for his

support and advice on writing this thesis. We would also like to thank our supervisor at

Nintech, Roger Hemstrom, for his helpfulness and assistance. Lastly we would also like to

thank Ninetech for allowing us to do this thesis project.

vi

Contents

1 Introduction 1

1.1 Project goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Dissertation layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Requirements 4

2.1 Implementation features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 General requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Background 6

3.1 Ninetech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 KlarSynt and C-Optikk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.3 ServeIT and OptiWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.4 Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.4.1 Production Environment . . . . . . . . . . . . . . . . . . . . . . . . 8

3.4.2 Test Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.4.3 Development Environment . . . . . . . . . . . . . . . . . . . . . . . 11

3.5 Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.6 Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.6.1 Windows Presentation Foundation . . . . . . . . . . . . . . . . . . 13

3.6.2 XAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.6.3 MVVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.6.4 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.6.5 Stored procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.7 Windows Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

vii

4 System Design 18

4.1 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2 Application design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3 Database design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 System Implementation 23

5.1 Establish connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.1 Retrieve online hosts . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.2 Connect to Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1.3 Connect to Database . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2 Retrieve Information from Database . . . . . . . . . . . . . . . . . . . . . . 25

5.3 Set and compare Windows Registry keys . . . . . . . . . . . . . . . . . . . 29

5.4 Web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.5 Change state and language . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.6 Edit the predefined web services . . . . . . . . . . . . . . . . . . . . . . . . 34

5.7 Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6 Evaluation 39

6.1 Comparison of Verktyg and KlarSynt Tools . . . . . . . . . . . . . . . . . . 39

6.2 Comparison between new and old process . . . . . . . . . . . . . . . . . . . 42

6.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7 Conclusion 46

7.1 Evaluation of the project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.2 Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

References 49

viii

List of Figures

3.1 Copying customer database . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 Three different environments . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 How KlarSynt Tools connects to the different databases . . . . . . . . . . . 12

3.4 Data Flow in the MVVM pattern . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 How settings are being changed through the application . . . . . . . . . . . 19

5.1 The database table containing all host data . . . . . . . . . . . . . . . . . 24

5.2 Information retrieved from the database . . . . . . . . . . . . . . . . . . . 26

5.3 Menu for changing Patch level . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.4 Combobox for login credentials to OptiWeb . . . . . . . . . . . . . . . . . 28

5.5 Keys and their values representing a database on a certain server . . . . . 29

5.6 The Settings-table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.7 The web services are displayed on the GUI . . . . . . . . . . . . . . . . . . 33

5.8 The web services window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.9 Colored indication icons (green, yellow, and red) . . . . . . . . . . . . . . . 36

5.10 Flag icons representing the language of a web service . . . . . . . . . . . . 37

5.11 Warning icon for patch level . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.1 Verktyg’s login screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.2 Web services in Verktyg . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.3 Steps of the old process (standard case) . . . . . . . . . . . . . . . . . . . . 43

6.4 Steps of the new process (standard case) . . . . . . . . . . . . . . . . . . . 44

ix

List of Tables

2.1 Required features for KlartSynt Tools . . . . . . . . . . . . . . . . . . . . . 4

6.1 Comparison between Verktyg and KlarSynt Tools . . . . . . . . . . . . . . 39

6.2 Comparison in time between old and new process . . . . . . . . . . . . . . 44

x

1 Introduction

Ninetech, a consulting company, maintains a client booking system called ServeIT for one

of its customers, KlarSynt1 (an association of optician stores). When a KlarSynt store

indicates that something is wrong with their ServeIT system, Ninetech retrieves a copy of

the customers ServeIT database and redirects it to a dedicated test environment to perform

software testing. At the moment, the process of redirecting a copied database is both time

consuming and exposed to mistypings, as it is partly done by manually inputing values

into the database. Therefore, a Windows application was developed to improve these two

aspects.

1.1 Project goal

The goal of the project was to implement a Windows application to improve efficiency and

accuracy when configuring a database used in ServeIT (see section 3.3) and the Windows

Registry (see section 3.7). As of now the title of this application is KlarSynt Tools. The

main reason for doing these configurations is to redirect the database to a test environment.

Before this project the configurations were partly done with an application initially used

when setting up ServeIT at a KlarSynt store, called Verktyg. Being a setup application

for ServeIT, Verktyg was not originally intended for doing these configurations, and was

therefore missing some required features. Because of that, some settings had to be manually

configured by going in to the copied database and changing them. The proposed application

should be able to show the current settings of the copied database as well as make all the

required changes in order to redirect the database to a test environment. The main goal

of KlarSynt Tools is not to replace Verktyg per se, but instead to enhance the processes of

configuring test environments, and remove the need of Verktyg in these situations. Verktyg

will still be used in the cases where it was intended to be used; for setting up ServeIT at

1In this dissertation KlarSynt is referred to as two associations working in close relation with eachother, KlaySynt and C-Optikk

1

KlarSynt stores.

1.2 Contribution

This project led to the development of a Windows application that can efficiently and

accurately change settings to a customer database used by ServeIT. The application was

delivered and approved by Ninetech and will be used in future support tickets that are

reported by KlarSynt stores. All the mandatory requirements were fulfilled and a clear

improvement to the previously used process was achieved. The results will be discussed in

more detail in chapter 6.

1.3 Scope

This project does only include the development of an application for configuring databases

and the Windows Registry in an efficient and accurate manner. What was left out of the

scope of the project was to include features in the application to further be able to set

up the test environments. This includes, for instance, the ability to retrieve copies of the

ServeIT databases and store them on the test environments. Other features that were

left outside the scope of the project, was the ability to automate the installation of the

correct ServeIT versions on the environments. The project does not include the procedure

of integrating the developed application with other internal tools to a single application,

which was one of the projects Ninetech had alternatively planned to do in the future.

1.4 Dissertation layout

The dissertation is organized in seven main chapters. The second chapter, states the re-

quirements of KlarSynt tools set up by the supervisor at Ninetech. Chapter 3 contains the

background of the project and provides information on the techniques that were used to de-

velop the application and helps the reader to understand the remainder of the dissertation.

2

Thereafter chapter 4 presents the design of KlarSynt Tools and gives an overview of both

the application and the accompanied database. Chapter 5 describes the implementation of

the developed application and how all parts are connected to each other. In chapter 6 the

results of the project are presented and there is also a comparison between the old process

and KlarSynt Tools. Finally, a conclusion of the project is provided in chapter 7.

3

2 Requirements

Before the start of the project, our supervisor at Ninetech presented us with requirements

for the project. The requirements included both features which KlarSynt Tools had to

implement, as well as more general requirements such as having an easy maintainable

system. This chapter will present these requirements.

2.1 Implementation features

The table below, table 2.1, presents all the features to be implemented that was requested

by Ninetech along with a priority level (set by our supervisor at Ninetech).

Priority Description1 Show IP:s of servers2 Show info about selected database:

• IP / instance name

• Culture info (Swe or Nor)

• Patch level

• Web services

• OptiWeb username and password

2 Being able to change username and / or password for Optiweb login2 Make changes to Windows Registry keys:

• Patch level (retrieve from database and add to Windows Registry)

• Database / Server values

3 Separate window for editing web service URL:s stored in every ServeITdatabase (in the CRUD2 fashion)

3 Show language for every web service, as well as being able to switch language(Swe or Nor) on every selected web service.

3 Showing an indication on what kind of web services are currently selected(Test, Dev, Prod, or Various with color gradings on icons)

4 Including images and color gradings in the GUI

Table 2.1: Required features for KlartSynt Tools

4

2.2 General requirements

The project was carried out using the programming language C# to develop the application

and Microsoft SQL Server to store and retrieve values from databases. To do this, the

project was also provided with Microsoft Visual Studio 2013 and SQL Server Management

Studio. Furthermore the application was preferably to be developed using WPF (see

chapter 3.6.1) and the design pattern MVVM (see chapter 3.6.3).

Since ServeIT already has certain external applications for different purposes, Ninetech

had plans to, in the future, integrate all external applications into one single program suite.

Therefore, the code structure had to be loosely coupled and flexible so that it could easily

be integrated with other applications. Techniques used for this are discussed in chapter

3.6.

Lastly, to achieve the main requirement of the project, improve efficiency and accuracy

of a current process, a user-friendly interface was needed. This included having to go

through fewer steps than the current process and removing manual inputs to database and

Windows Registry, while having a comprehensive interface with icons to ease the usage.

2Create, Read, Update, Delete

5

3 Background

This chapter will present a short introduction to Ninetech as well as one of its customers.

Thereafter follows a description of the three environments that are used for the ServeIT

system. Furthermore, an explanation of how customer databases are redirected to the test

environment at the moment and how the proposed software could improve the efficiency and

accuracy of this process is given. The techniques used to develop the proposed application

will also be introduced and discussed.

3.1 Ninetech

Ninetech specializes in offering solutions in digital market communication and IT. One of

their key undertakings is to provide end-to-end [10] solutions to their customers. This

includes having long term relationships with the customers, and thereby offering full main-

tenance and support for their services [1]. As previously mentioned, the goal of this project

was to create an application that could improve the procedure of software testing in favor

of, one of Ninetech’s main customers, KlarSynt.

Ninetech offers support on both a technical, as well as at a development level. When

customers (independent optician stores that are a part of KlarSynt) request support for

ServeIT, they are first directed to technical support. If their problem cannot be resolved

here, they are passed on to the developer support. Usually, the developers are required

to modify the code behind the systems to fix these problems or bugs. One of the most

common causes of bugs like this to emerge, are user input on the customer-side affecting the

underlying database of ServeIT. For testing the causes of user input bugs, the developers

at Ninetech often need to copy the customers database and store it on the test environment

(see figure 3.1). This is done so that changes made while testing will not affect the real

data of the production database.

Currently, the redirection of a customer database residing in the test environment

6

Sv x86 Sv x64

No x64

Test Environments

KlarSynt store

Copy database

No x86

Figure 3.1: Copying customer database

is done with an application originally used to setup ServeIT at a KlarSynt store. This

application lacks some required functionality needed when applying the customer database

to the test environment. Due to this, relatively time-consuming manual changes to the

customer database and the Windows Registry have to be made. To avoid having to make

these manual changes, Ninetech requested a new application to be developed.

3.2 KlarSynt and C-Optikk

KlarSynt and C-Optikk is an association (a concern) of privately owned optician companies.

They are not the same company, although they work in close cooperation with each other,

with KlarSynt operating in Sweden and C-Optikk operating in Norway. They will hereafter

be referred to as simply KlarSynt. The companies in KlarSynt are all run independently as

private businesses, although they share the same booking systems and purchasing systems

with each other. KlarSynt is one of Ninetechs main customers.

7

3.3 ServeIT and OptiWeb

One of the systems provided by Ninetech to KlarSynt is ServeIT. ServeIT is a client-

booking system used by almost all the companies in KlarSynt. It uses a database to store

information about all clients as well as information about client appointments. The system

is constantly being maintained by Ninetech, where new patches are usually released once

every quarter of a year.

When problems arise around any of the released ServeIT systems, the KlarSynt store

experiencing the problem can contact the technicians or developers at Ninetech who will

try to solve their problems.

When ServeIT is put into production, it communicates with a web interface called

OptiWeb. OptiWeb’s task is to provide ServeIT with web services, which can be called

on whenever needed. Some of these web services are, for example, operations to send out

reminders to clients about appointments, or to deliver lenses to customers [3].

3.4 Environments

In the development of ServeIT, Ninetech use an approach including three different envi-

ronment types: Test, Production and Development. An environment is, in this case, a

computer running ServeIT together with an accompanying database, which may or may

not be located in the same area as each other. How these environments relate to each

other is presented in figure 3.2. The environments will be discussed in the following three

sections.

3.4.1 Production Environment

The production environment is the environment that is used for an application which has

been shipped out to the customer ready to be used by its end-users [16].

This environment consists of a local machine running ServeIT and a database. The

8

Development Test Production

Bug found

Tested

OptiWeb(PROD)OptiWeb(TEST)

Need of change

To be tested

Figure 3.2: Three different environments

database contains data about, for instance, clients, appointments, and URL:s to OptiWeb

web services used by the local ServeIT system. As mentioned in section 3.3, one of these

web services is an operation for sending out contact lenses. It would be troublesome if

a mistake during testing caused contact lenses to be sent out to customers who have in

fact not made any orders. Therefore, it is necessary to carefully test an application in an

isolated test environment before turning it over to a customer.

3.4.2 Test Environments

For testing the numerous problems that can arise around any of the released ServeIT

systems, Ninetech uses a number of different test environments where all the testing is

9

done. The reason for this is to be able to accurately replicate how every bug emerges,

without having an effect on the production environment. Because ServeIT is used by

companies either part of KlarSynt (Sweden) or C-Optikk (Norway), environments running

Windows operating systems with both Swedish and Norwegian settings are required. This

is because of language handling features in ServeIT. Furthermore, as ServeIT can be run

on either 32-bit or 64-bit operating systems, some features might behave differently in the

two architectures. Therefore, to accurately test how ServeIT operates, the four different

test environments used by Ninetech are:

• Swedish 32-bit

• Swedish 64-bit

• Norwegian 32-bit

• Norwegian 64-bit

To better replicate the bugs, the same version of ServeIT used by the affected customer

needs to be used in testing. Because this version might not necessarily be the same version

that is already installed on the test environments, the correct version is retrieved (usually

from the customer) and installed on the proper environment. Which environment is the

proper one to use for testing, is based on whether ServeIT is run on a Swedish or Norwegian

system, and whether that system is a 32- or 64-bit version of Windows.

When the proper test environment is chosen and the correct version of ServeIT is

installed, a copy of the customer database needs to be made and stored on the test envi-

ronment. Thereafter ServeIT is routed to this database by changing values in the Windows

Registry. To then be able to log in to ServeIT, all the customer passwords stored in this

database are removed. This means that developers at Ninetech simply can log in to the

ServeIT system with an empty password field.

10

3.4.3 Development Environment

During the development of new versions of ServeIT, Ninetech also uses a dedicated de-

velopment environment. As the name suggest, this environment is used mainly during

development of ServeIT. However, this environment is also frequently used when testing

and correcting bugs that are reported by a KlarSynt store. This is because as long as the

values in the copied ServeIT database have its web services redirected to the test version

of OptiWeb, no real data will be affected. A frequent approach is therefore to have the

copied database in the test environment, while running ServeIT (using this database) in

the development environment. This way, the cause of the bug can promptly be discovered

and quickly be dealt with directly from the development enironment.

3.5 Databases

Throughout the project, three different databases were used in the implementation of the

application. This results in that the term ”database” could refer to different databases

in this dissertation. Therefore, it is important to be able to distinguish between all these

different kinds of databases to understand the inner workings of both KlarSynt Tools as

well as how testing is performed at Ninetech. This sub-chapter will expain the differences

between all databases used in the project, as well as how they relate to each other.

As mentioned in chapter 3.4.2, four different test environments are used during the test-

ing of ServeIT. On each of these test environments there reside copies of ServeIT databases

that have been retrieved from a KlarSynt store having problem with their ServeIT system.

These database copies are referred to as test databases in this dissertation.

Before the testing on ServeIT can be done, however, the ServeIT system running on

the chosen test environment has to be routed to the correct test database. Aside from this,

changes on the databases have to be made to include the proper web services. Helping the

developers at Ninetech to make these changes is one of the purposes of KlarSynt Tools.

11

Figure 3.3: How KlarSynt Tools connects to the different databases

Through the interface of KlarSynt Tools, a test environment can be selected and connected

to. After that, a database can be selected in a similar manner. Finally, when this has been,

done configurations to the chosen database can be made.

Aside from the already mentioned databases, there is yet another database which is

exclusively used by KlarSynt Tools. The purpose of this database is to provide information

to KlarSynt Tools, information which will possibly change in the future. As an example,

information about the test environment servers (IP numbers, host names, and instance

names) is provided here so that if new test environments were to be needed in the future,

they can easily be added to the KlarSynt Tools database. How KlarSynt Tools connects to

the many different databases can be seen in figure 3.3.

12

3.6 Techniques

The decisions on techniques that were to be used in the project were mostly dependent

on how the current ServeIT and OptiWeb systems are built. Ninetech’s preferences were

also taken into consideration, as they might want to further develop the application in the

future. There was also a request for the application to be integrated with other tools used

at Ninetech in the future. This was also kept in mind in the selection of the techniques.

3.6.1 Windows Presentation Foundation

WPF (Windows Presentation Foundation), or Avalon [15] as it was previously known as,

is a system for presenting graphical components in Windows applications. One purpose

for using WPF when developing Windows applications is that it enables separation of the

user interface and the business logic [19]. There are also other benefits such as that every

component is rendered using Direct3D, allowing for elaborated shapes to be displayed and

that animations can easily be made to convey messages [18].

The graphical components in MVVM is defined in XAML (Extensible Application

Markup Language) which is a markup language developed by Microsoft and will be ex-

plained in the next section [22].

3.6.2 XAML

XAML is a markup language that makes it easy to construct GUI:s in a .NET application.

GUI elements such as labels and buttons can be created in XAML, while you keep the

business logic for these elements separated in a code-behind file [4]. To enable this separa-

tion XAML uses an approach called Markup Extensions. Markup Extensions are defined

with curly brackets and can provide a value from a dynamic resource to a property of a

graphical component [6].

13

3.6.3 MVVM

MVVM (Model View ViewModel) is an architectural pattern that can easily be used in

WPF to separate visual logic, business logic and back-end logic [20].

Separating these three areas provides certain benefits [13] [21]:

• Separation of Concern: By having one part of the system do a certain task, it

makes the structure easy to follow and maintenance uncomplicated.

• Development independency: Since the view has no knowledge of the model or

vice versa, they can be developed separately and thereafter being brought together

with the ViewModel.

• Multiple Views: The business logic and back-end logic exist purely in the View-

Model and the Model respectively, and can therefore be used in different views.

• Easier testing: Logic is not embedded in the graphical components and therefore

makes unit testing much more flexible.

To achieve the points stated above, MVVM commonly uses two markup extensions in

XAML called data bindings and commands. These two markup extensions are shown in

figure 3.4 and are explained next.

All properties of graphical components in a View can be bound, using data binding, to

datasets existing in the ViewModel. To know when changes occur to the bound dataset,

the ViewModel implements an interface called INotifyPropertyChanged that tells the view

to update itself when items gets removed, added or changed in the dataset. Since the

binding process just consists of assigning the component a variable name to bind to, both

the View and ViewModel can efficiently be replaced by different ones if so needed [14].

The Model part of MVVM is for classes that represent nouns in natural languages.

This class implements no logic, but instead only holds pure data like integers and strings.

14

View ViewModel Model

Databindnings

Update

User Input

Commands

Uses

Figure 3.4: Data Flow in the MVVM pattern

MVVM also makes use of commands that can be assigned to, for example, buttons.

The assignment of commands is quite similar to data binding; string values are assigned

to command properties of the components that are to trigger the commands. The string

values that are assigned correspond with names of the functions which are to be executed.

Commands also help, like data bindings, to keep a loosely coupled view by not having

functions subscribed to events as they are traditionally in .NET. An additional side effect

form having a tight coupling between events and functions is that replacement of the view

will cause numerous errors, since functions now subscribe to events that no longer exist [11].

3.6.4 SQL

SQL is one of the leading database languages for managing relational databases. With the

help of queries, SQL can create new data, modify already stored data or delete unwanted

data. A query consists of nested clauses to fulfill the desired action [7].

SELECT * FROM Settings WHERE Value LIKE ’http://%’

The example above is a simple SQL-query that retrieves all tuples in the ”Settings”

table that have a Value attribute that begins with the string http://.

15

3.6.5 Stored procedure

A stored procedure is an SQL query that can be stored in a database. The stored procedure

can then be used within the database for validation or access control, but also as a part of

other applications [9].

Instead of having an application implement an SQL query directly into the code, a

stored procedure can be called on to execute the same query. This way, changes to an

application can easily be made, by simply modifying the database of the stored procedures.

This also enables SQL queries to be reused whenever needed, even in other applications

where this specific SQL function is desired.

In the case of this specific project, the application that was made were going to be

used by not only one single person at Ninetech, but by multiple employees. Using stored

procedures, will thereby avoid unnecessary patches regarding SQL functionality having to

be made to the application in the future.

3.7 Windows Registry

The Windows Registry is a hierarchical database where applications running on the Win-

dows system are able to store data regarding the application itself or its users. Having a

tree-structure, the nodes in the Windows Registry are referred to as keys. These keys can

in turn contain subkeys, as well as data items for storing values [5].

3.8 Summary

In this chapter a brief introduction to the company Ninetech and one of its customers,

KlarSynt, was presented. Thereafter a description on how support and maintenance con-

cerning the ServeIT system is handled at the moment was provided. Followed by this the

three different environments; production, development and testing, used in the develop-

ment cycle of ServeIT, were discussed. Lastly the chapter presented the different techniques

16

used to develop KlarSynt Tools, an application that would simplify the handling of support

errands regarding ServeIT.

17

4 System Design

In this chapter the design of the developed application and the accompanying database

will be covered, as well as the features that were included in the application.

4.1 System overview

To solve the issue of having to go through time consuming configurations before being

able to troubleshoot a ServeIT system, a Windows application named KlarSynt Tools was

developed. KlarSynt Tools has features such as switching environment URLs on predefined

web services, updating registry keys for various uses, and more, which will all be described

in detail in the following sub-chapters. Along with KlarSynt Tools, a database called the

KlarSynt Tools database was also created to store information about login credentials to

the test environments and OptiWeb which will be needed for the application to perform

certain configurations. A look-up table for web service URLs was also implemented in this

database which will be discussed in sub-chapter 4.3.

4.2 Application design

First of all, the application needs to send an ICMP echo [8] request to each of the test

environments (servers) to see which of them are available. When an ICMP echo response

is then sent back by a test environment, the application will acknowledge this server as

being online, and place it in a combobox list. The user of the application can then select

one of servers from this list, which will make the application connect to that server. When

a connection is established, information about which databases are stored on this server

will be retrieved. The names of all these databases will then be placed in a list, much in

the same way as with the servers.

The user can then choose one of the databases from the list, and the application will

send a request to retrieve data needed from the database. During testing, the chosen

18

database is the one that will need to be configured in order for the test environment to be

set up correctly. Data from this database is then sent back to the application and displayed

to the user so that it can be configured.

Application sends a ICMP echorequest to the test envorionments

The test environments sends backan ICMP response if they are alive

User selects a database on the selected server

Application requests informationabout settings and web servicesfrom the database Database responds with

the requestd information

User updates the settingsthrough the application

Database updates tables accordingly

User selects an online server

Figure 4.1: How settings are being changed through the application

The different settings a user can configure on the database are the following:

• Remove passwords (sensitive user data)

• Change environment and language of a web service

• Choose or change login credentials to OptiWeb

19

• Add or remove web services

Each customer has his/her own username and password when logging in to ServeIT

which is stored on their respective database. When Ninetech then receives this database

(to perform the testing), they want to be able to quickly log on to ServeIT without having

to manually search through the database for login credentials. This would in that case

reveal user data which could be seen as sensitive. Instead, it was desirable to be able

to remove passwords and usernames automatically, which in turn would allow for logging

in with empty password and username fields. Removing this data would not effect actual

customers, as the database affected is only a copy of the real customer database. To include

this desired feature, a button was implemented to the GUI of the application.

A ServeIT database also contains a settings table that defines URLs to various web

services that ServeIT offers. These URLs can be routed to either one of three environments;

test, production or development. When testing a web service it is important to not have

the values in the database that point to the production environment, since unwanted

configurations could occur to the production database, as mentioned previously. To make

it easy to switch between these environments, check boxes along with buttons are used.

The URL:s for the environments of each web service are predefined in the KlarSynt Tools

database.

It might also be necessary to, in some situations, change the login credentials for Op-

tiWeb. These credentials are not the same as the ones for ServeIT and are also unique for

each KlarSynt store. During testing of a ServeIT database it is therefore necessary to be

able to change the login credentials of OptiWeb for the selected test database. Often, these

login credentials are one of four different login users. These are login users for the test

environment and the production environments for both Swedish and Norwegian stores re-

spectively. In some cases, however, custom login credentials are required. For those cases

there is a custom login option available, where username and password can be applied

manually. To chose a predefined login user or the custom option, there is a drop-down

20

menu where all the options available can be selected. Under this drop-down menu there

are fields which display the username and password for the selected login user. These fields

will become editable when the custom login has been chosen.

As ServeIT continues to be developed, new web services are continuously added to

OptiWeb. The application therefore also has a simple CRUD window where the user can

add new web services and URL:s for each environment. Since the application is going to

be used by several users, the values can not be stored on the local computer. These values

are for this reason stored in a table at the accompanied KlarSynt Tools database.

Apart from communication with the database, the application is required to read and

write to keys in the Windows Registry. This is because when starting up ServeIT, KlarSynt

Tools reads from the registry which database and which host it should try to connect to.

There is also a PatchLevel field that represents the version of ServeIT the local machine is

running. This value must match with the database value of the PatchLevel or else ServeIT

refuses to start. Therefore, an easy way of changing this value in either the registry or on

the database was implemented.

4.3 Database design

Due to the requirement that the application should be versatile and avoid using hard coded

values, the decision was made upon creating a database to go along with the application

that stores values that might possibly change in the future. This also allows for multiple

users to change the values since they are not stored locally on any computer, but on a

shared database residing in the local network. This list below shows the tables in the

KlarSynt Tools database.

• Hosts

• Logins

• WebServices

21

The host table stores tuples that represents the four test environments together with

the actual development environment where the KlarSynt Tools database is located. The

reason behind storing the login credentials to the test environments in a database is so

that when additional databases come into use, it should be easy to incorporate them in the

application as well. Sometimes Ninetech also wants to use the databases when developing

fixes to bugs that were found and therefore the credentials for the development environment

are also present in this table.

ServeIT is also connected to OptiWeb which requires a username and a password. The

login credentials for OptiWeb and the test versions of OptiWeb, for Sweden and Norway

respectively, are quite often used and are therefore predefined in the Logins table. If

additional logins are needed they can simply be added to this table and they will then be

included in the application on application start up.

The last table, WebServices, contains information about the different web services used

by ServeIT. The point of having this table is for the application to be able to associate the

URLs for test, development and production to each web service. Since ServeIT is constantly

being further developed, the number of web services will also grow over time. Because of

this, it would be quite troublesome to have to modify the application code each time a new

web service comes in to use. With this table a tuple containing the information about the

web service can simply be added each time a new web service is put into production and

no changes have to be made to the application.

22

5 System Implementation

The following chapter will give a more detailed description of the system that was imple-

mented and all its consisting parts. For all these parts, an explanation about how they

work, how they were implemented, as well as why they were implemented will be given.

The chapter will also go through the connections between all these parts and how they

interact with each other. Finally, the chapter will discuss decisions made when designing

the GUI to provide user-friendliness.

5.1 Establish connection

For configurations of a database to be able to be made, a number of steps need to be gone

through to establish the connection with this database. This section will describe in detail

what these steps are, and how the work.

5.1.1 Retrieve online hosts

To be able to interact with the test environment servers, the application first needs to

verify that the hosts are up and running. This is done by sending ICMP echo requests to

the hosts upon application startup. Before this is done however, the application needs to

retrieve the IP addresses of all the servers that should be sent request messages. This is

done by connecting to the KlarSynt Tools database containing all the relevant information

about the servers, stored in a database table. The information is then retrieved by using

SQL-commands programmatically from within the application.

This information is then stored in objects of a class called ”Host”. This class contains

properties for all the fields found in figure 5.1. Moreover, it contains a property called

Online. This is a boolean to check whether the specific host is online or not.

For the program to be able to reference these objects later on during runtime, as well

as for display, the objects are placed in a list. The list used in the application is of the

23

Figure 5.1: The database table containing all host data

class ObservableCollection. An ObservableColletion allows the WPF interface to update

accordingly to changes that occur to the objects.

When the relevant hosts have been retrieved and structured into objects, the application

will then test if the hosts are reachable or not by pinging them. If a ping to a host is

successful, the Online-property of this specific host is set to true. If a ping is not successful

however, the ping request will time out, and the Online-property will be set to false.

There is a possible scenario where a host becomes unreachable while using the ap-

plication and the hosts are therefore consequently pinged each 10 seconds. The list is

repopulated with the online hosts at the moment of each ping.

Because a timeout will take considerably longer time than when a ping-request is re-

sponded immediately, the graphical user interface will appear to freeze during this period.

This is because the program is busy waiting for a response from a host, and will therefore

not respond to any user input. To solve this, the whole process of retrieving the online

hosts is done asynchronously in a background thread.

5.1.2 Connect to Host

All hosts that are online are listed in a drop-down menu where they can be selected. When

one of the hosts is selected, an SQL query is initiated to retrieve all names of the databases

that exist on the requested host. The retrieved names are then stored in a list to later be

able to connect to the hosts.

24

Even if the host is up and running, the SQL-server might be down or preventing the

application from using it. When such a situation occurs an error message is shown to

inform that the SQL-server is unavailable. If this happens, the selection of databases is

disabled.

The IP-addresses together with the instance name of the host that was last connected

to is stored in the Windows Registry. This is so that, upon application startup, these values

can be retrieved to automaticaly establish a connection with the most recent host. If no

values can be found in the registry or the values are not valid, an error message is displayed

in the application stating the error. In this case, no host is connected to immediately, and

another host has to be selected from the host list.

5.1.3 Connect to Database

Connection to a database can only be done after an online host is selected. Having selected

an online host, as mentioned in chapter 5.1.2, a list is created with the available databases

on that host. Thereafter, the preferred database can be selected.

In a similar manner as with the hosts, the most recently connected database will be

attempted to connect to by the application upon startup. This is done by storing the

database name in the Windows Registry, and then retrieving this value.

5.2 Retrieve Information from Database

When a database has been selected, the application will try to retrieve necessary data

from it using stored procedures. This data includes patch level, ServeIT language setting

(CultureInfo), OptiWeb login credentials, and web service URL:s, which are all relevant

information when setting up a test database to prepare it for testing. How this data is

displayed to the application user can be seen in figure 5.2.

When copying a customer database, the login credentials to ServeIT used by the cus-

tomers will be kept in it. To be able to login without having to look at the database tables,

25

Figure 5.2: Information retrieved from the database

it was requested by Ninetech to have the option to remove all these passwords from within

the application. This is what the field ServeIT Passwords is for. Next to this label there

is a button labelled Clear. By pressing this button the application simply connects to the

chosen database, and removes all the user passwords stored in there. When this has been

done, the application once again connects to the database to verify that all the passwords

were successfully removed. This is also done each time a new database is selected from

the drop-down menu. If the passwords have been removed, the Clear-button is disabled to

give the user of the application an indication of this.

The culture info is provided to quickly present to the user which country the currently

selected database is used in. This information is presented with an icon representing

the flag of the respective countries. In some cases it might be necessary to test certain

databases on both the Swedish and the Norwegian test environments. This is to be sure

that ServeIT does not act differently depending on which language of the system it is

26

currently running on. Therefore, the Culture info is provided to the user to be able to

know what system-language the databases are normally being run on.

Other important information for the developers to know is which patch of ServeIT the

customer is running. Since all the customers might not have the same version of ServeIT

as the testing environments at Ninetech, it is sometimes necessary to install the right

version of ServeIT on the environment before testing can begin. Because of this, the patch

level stored on the test database is displayed together with the patch level in the Windows

Registry (patch level currently running on the test environment). If these two values do

not match with each other, a warning sign is raised to signal the user that either of them

might need to be up- or downgraded.

Even if the database and test environments have different patch levels there might still

be a chance of performing the testing without an up- or downgrade, but in order for ServeIT

to start, the values in the database and registry must be equal. Therefore, a simple switch

was built into the application that allows the user to shift between the two values, either

using the database or registry value. A rollback function was also implemented so that

if by mistake ”Use database” or ”Use registry” was chosen, the values can be restored to

their original states.

Figure 5.3: Menu for changing Patch level

The field ”Web services” is for giving the user of the application a quick overview of

which web services are currently used by the selected database. The field shows if all

web services are directed to the test environment, the production environment, or the

development environment. This is shown by displaying the values ”Test”, ”Prod”, or

27

”Dev”, respectively for each of the different environments. If the web services are directed

to varying environments the string value ”Various” will be shown.

Next to this string value, an icon is shown. This is to alert the user of the application

when web service URL:s are directed to the production environment. If this is the case, a

red icon will be shown to indicate this. If no web services are directed to this environment

either a green or a yellow icon is shown. The yellow icon is for when one or more web

services are directed to the development environment, and the green is for when only the

test environment is directed to. Usually it is preferred that only the test environment is in

use, hence the green icon.

Username and Password are the credentials for signing in to OptiWeb. There are

different logins for the test and production environment both on the Norwegian and Swedish

side. These are the most commonly used and are therefore stored in the applications

database. In a few cases however, there is a need to login as the customer that submitted

the database. For these cases an alternative way to sign in, custom, is available.

Figure 5.4: Combobox for login credentials to OptiWeb

Upon selecting one of the predefined login users, values for the username and the

password are automatically committed to the database. However, when a custom login is

required, a commit button must be pressed after the credentials has been entered to the

password and login field to commit the values.

The application will also recognize when selecting a database if the values represent a

predefined or a custom login user and display it accordingly in the login drop-down menu.

28

5.3 Set and compare Windows Registry keys

ServeIT uses the Windows Registry to store information such as what version it is and

what user most recently logged in. There are also values that are used to determine which

host and database that should be used to store and access data.

When a database needs to be analyzed for faulty data, the value of the registry keys

representing host and server needs to be changed to the location of the database. Therefore,

when choosing a database in the application, the values in the registry are updated to the

selected database.

Figure 5.5: Keys and their values representing a database on a certain server

The first and third key, as their names might suggest, store the name of the database

that ServeIT is using and on which server it resides on. For customers, the database might

be located on localhost, but when running tests on them at Ninetech they are stored on

one of the four test environments.

The remaining two keys, password and username, are the login credentials for the

server. However, the credentials are not stored in plaintext, but are instead encrypted

with a crypto provided by Ninetech. Because of this, the values that are written here, need

to be encrypted before they are stored. Likewise, when retrieving the data, the values need

to be decrypted by KlarSynt Tools to be able to be read.

Apart from this information about the server and the database, there is one more key

that has to be verified when switching to a new database, the PatchLevel. The PatchLevel

key is located one hierarchy level above the database information and contains information

29

about what version of ServeIT is being used on the test machine.

As mentioned in chapter 3.4.2, both the database and registry PatchLevels need to be

identical to each other before the ServeIT system can be logged in to. However, this does

not mean that the database is not compatible with the current ServeIT version and there is

a possibility that ServeIT can still be run together with the database. Therefore, a simple

update of either the registry or the database PatchLevels can be made to make them both

identical to each other, and access to ServeIT will be granted.

5.4 Web services

One of the primary features of the application is to present all the various web services

contained in the selected database. This is to provide an overview of which web services the

current database contatins as well as to provide the option to make certain configurations

on these settings.

The URL:s to the web services are stored in a table called the SETTINGS-table in

every database. This table is for storing various kinds of data and is not restricted to only

storing web service URL:s. The table uses two attributes for storing of the data, Nyckel

(Key) and Varde (Value), which can be seen in figure 5.6.

Figure 5.6: The Settings-table

30

In figure 5.6, all the rows containing URL:s in their Varde column are web services.

However, because many other kinds of data are stored in the table, some tuples may

contain URL:s which might not necessarily be addresses to web services. Because of this,

there is no easy way of distinguishing which tuples in the table that are actual web services.

To solve the problem, a new table in the KlarSynt Tools database was created where web

services can be predefined and later compared to URL:s in the chosen database. Another

benefit from this approach is that display names can be defined for all web services, which

can then be shown in the application. This provides more user-friendliness, as opposed to

using the values found in the Nyckel attribute, which are not meant to be used for display.

The following attributes are used in the table at the KlarSynt Tools database for the

predefined web services:

• DisplayName

• Lang

• URLTest

• URLProd

• URLDev

• Key

DisplayName is the string used for displaying every web service. The Key attribute is

the same as the key value (Nyckel) found in the SETTINGS-table at a ServeIT database.

Moreover, as can be seen above, every web service contains three URL:s along with a Lang

attribute. The reason for having three different URL:s is to have one each for every test

environment.

Because ServeIT is used in both Norway and Sweden, most web services are also avail-

able in two versions, one for each language. However, they still share the same Key-values

in the SETTINGS-table. This means that there will be twice as many URL:s for every web

31

service. One way of implementing this would have been to include twice as many URL-

attributes in the WebService table at the KlarSynt Tools database. This implementation,

however, would not be a very scalable option; if another country would be introduced to

the service in the future, a lot of changes would have to be made to the database and the

application code. Instead, one new attribute was created Lang. This is simply an attribute

that stores the language for each and every web service. This also meant that every web

service would have to be split up into two separate web services, one Norwegian and one

Swedish. Because the two versions would still share the same Key value, Key together with

Lang would now become the primary key in the database table.

The information kept in the predefined web services table is retrieved on application

startup. Every web service is then put into certain objects called WebService, which are

then placed into a list. The WebService objects contain a number of properties, similar

to the attributes in the database table. However, as an addition to the database table,

WebService also has a property called Include. This is a boolean to set whether a web

service is included in the currently chosen database or not. The web services with this

boolean set to true are the ones that will be displayed in the application.

Every time a database is selected, the SETTINGS-tables content for that database is

retrieved and put into a list. Both the Nyckel as well as the Varde data is retrieved. The

lists are then filtered so that only URL values will remain. To determine which values are

actually web services, comparisons to the predefined web services will have to be made.

Because all the available web services have already been put into WebService-objects and

put into a list, comparison to this list can be done. All web services in this list that contain

either URLTest, URLDev, or URLProd values which can be found in the SETTINGS-table

list will then get their Include property set to true.

32

5.5 Change state and language

When the web services have been retrieved form the database, they will then be displayed

on the GUI, which can be seen in figure 5.7.

Figure 5.7: The web services are displayed on the GUI

The user of the application can select any of the listed web services by checking the

check-boxes to the left of the view. When one or more web services have been selected, a

number of configurations to the those web services can be made by pressing the buttons

Test, Development, Production, and Switch Lang. The first three buttons will make changes

33

to the State-property of the chosen WebService object. For instance, when pressing the

button Test, the chosen WebServices will change their State-property to ”Test” indicating

that TestURL is now the URL currently in use for this WebService. Changes are also

required to be made to the SETTINGS-table containing the key-value pair for this web

service. An SQL request will be executed, changing the URL contained here to the new

URL-value (which in the case of this example is the TestURL value).

The Switch Lang button is for switching between a Swedish and a Norwegian web

service. Because of how the web services table in the KlarSynt Tools database are imple-

mented, each web service is split up into two web services, one Swedish and one Norwegian

(see chapter 5.4). When the chosen web services are switched to another language, the

Include-property of the old web service is set to false whereas the Include-property of the

new web service is set to true. This simply excludes the old web service from the list in

the GUI, and instead includes the new web service. This however, will only affect the GUI

of the application. To make any prominent changes, changes to the SETTINGS-table of

the database have to be made.

The changes made to the SETTINGS-table of the database are similar to the ones made

when switching between State values in the WebService objects. For instance, if a Swedish

web service is switched to a Norwegian, the Varde attribute in the SETTINGS-table will be

switched to the URL of the Norwegian version of the chosen WebService. It is important

to note that the URL value that is being changed is directed to the same environment (a

Swedish test environment URL will be changed to a Norwegian test environment URL in

the case of this example).

5.6 Edit the predefined web services

As web services supported by the many ServeIT systems may be added or removed in

the future, or the URLs to them might change, it will be necessary to be able to edit

the predefined web services stored in the KlarSynt Tools database. The standard way of

34

doing this is to log on to the database with SQL Server Management Studio and simply

edit the table. However, it was proposed by Ninetech that a feature in the application

could be added to improve the efficiency of this procedure and make the task less tedious.

The proposed feature was that a new window could be opened from the main window

of the application, where the web services table of the KlarSynt Tools database could be

accessed and edited by the application user. To access this feature a button labelled ”Edit

web services” was added on the GUI of the application. By pressing this button, a new

window is opened as a dialog box. The window contain a table, displaying the web services

contained on the KlarSynt Tools database which can be edited in a CRUD fashion. This

window can be seen in figure 5.8.

Figure 5.8: The web services window

The application user can click on the table, and will thereafter have the ability to edit

the rows and columns. The last row is left blank, giving the user the option to add new

tuples to the table by filling in the fields of the blank row. Rows in the table can be deleted

by selecting a row and pressing the delete key.

When an edit has been made to the table, the new changes will be committed to the

KlarSynt Tools database when the OK-button is pressed. If the user presses ”Cancel” and

35

changes have been made to the table, a confirmation dialog will appear asking if changes

should be saved or not before closing. If no changes have been made the window simply

closes.

5.7 Icons

The application displays a great deal of information for the user and it could be quite

difficult to skim through line after line with just text. To make it easier for the user to

navigate and locate the desired information, most of the text fields are accompanied by

colored icons [17]. This way the user can more easily determine what the information

means and act accordingly, which in turn makes the configuration process more efficient.

As mentioned in chapter 5.2 depending on which State the web services have at the

moment, a colored icon is shown. These colors are green, yellow, red. Human often

associate green with correctness and therefore this color represents when web services are

set to the test environment since this is the least alarming [2]. In contrast to green, red

is associated with danger and is displayed when web services is directed to the production

environment and that caution must be taken. The combination of green, yellow and red

can also be found at most traffic lights, which we associate with ”drive”, ”slow down” and

”stop” [12].

Figure 5.9: Colored indication icons (green, yellow, and red)

At the moment ServeIT is only used in two countries, Sweden and Norway. An easy

way to distinguish between these two using icons is to use the countries respective flags.

The flags of Sweden and Norway are quite easy to tell apart due to the differences in their

colors. However, if an Icelandic flag, which is very similar to the Norwegian flag both in

36

shape and color, were to be used in the application, it might be difficult to tell them apart.

Although, since this is not the case at the moment, using flags seemed to be the best icons

to represent a country.

Figure 5.10: Flag icons representing the language of a web service

In the database information field on the GUI, information about the registry patch level

and the database patch level is presented. When the patch levels do not match, a triangular

shaped icon is displayed to indicate this. An exclamation mark is also present to indicate

that something is wrong and has to be corrected.

Figure 5.11: Warning icon for patch level

5.8 Summary

In this chapter an overview of the implementation was given, followed by a detailed de-

scription of each process the application goes through and how these processes are linked

together. The detailed description starts with how the application determines which hosts

are online and which databases that exist on these hosts. Thereafter the chapter describes

how the application retrieve and change settings to redirect the database to a different

environment. How the application compares the patch level of the database and the lo-

cal ServeIT is then discussed. Followed by this is an explanation of how the application

switches between the Norwegian and the Swedish OptiWeb. Lastly a description of how

37

the construction of the GUI was given together with reasoning behind the choosing of icons

for the interface.

38

6 Evaluation

This project revolved around the implementation of an application made to improve the

efficiency and accuracy when configuring database and Windows Registry values. In this

chapter the results of this project will be discussed. First, a review of the application goals

will be made. Secondly a comparison of features will be made between the implemented

application and another application used by Ninetech, Verktyg, complimented by a dis-

cussion regarding the matter. To conclude this chapter, the amount of steps needed to

perform a standard case of configuration to the test database and Windows Registry is

measured and compared.

6.1 Comparison of Verktyg and KlarSynt Tools

The final product implemented all of the required features (see table 2.1) that were given

during one of the initial meetings with the supervisor at Ninetech.

Feature VerktygKlarSynt

ToolsConnect to server X XAutomatically retrieve and list available servers XDisplay databases contained on selected server XAutomatically update the database list if new databasesare added / removed

X

Functionality for removing ServeIT passwords XDisplay culture info XDisplay patch level XSet local (registry) patch level to match with databasepatch level

X

Change web service URL:s Only some XAutomatically switch URL:s to point to existing envi-ronments (Test, Prod, Dev)

Prod/Test X

Automatically switch URL:s to Swedish or Norwegianversions

X

Edit OptiWeb login credentials X

Table 6.1: Comparison between Verktyg and KlarSynt Tools

39

Before the project start, developers at Ninetech working with KlarySynt used a setup

application for ServeIT to configure settings to the test database, called Verktyg. Since

this setup application was not originally created for this task, some required configurations

could not be made inside the application and had to manually be made on the databases

and / or the Windows Registry. In table 6.1 a comparison is made between the features

of Verktyg and KlarSynt Tools.

In Verktyg all the data had to be entered manually for the test environments. This

includes entering the address for the test environment, the username and password for it

as well as which database that should be used (see figure 6.1). After this the user can test if

the environment can successfully be connected to. In contrast, KlarSynt Tools automates

all this by predefining the addresses in a database table and upon startup showing only

the test environments that are online. Here there can be no mistakes in typing the wrong

addresses to the test environments nor knowing if it is up and running. Another feature

that was added to the new application was that the IP addresses are displayed next to the

name of the environment.

Having the IP-address does not give any direct benefit to KlarSynt Tools since test

environments can be connected to directly, but was requested by our supervisor since it

can prove be valuable to other processes. Since the IP-addresses are dynamic and can

change from time to time, a user in the previous process always had to, with a computer

name, remotely connect to the test environment and then make an IP-lookup.

Figure 6.1: Verktyg’s login screen

40

Another feature that improves the efficiency is the automated check of the patch levels.

Verktyg provided no such check and the user had to look in both the database and the

Windows Registry to see if the patch levels were equal. In KlarSynt Tool instead, the user

is alerted directly through the GUI if the patch levels do not match up and are given the

opportunity to change either one of them.

Since the development of Verktyg, new web services have been introduced to ServeIT.

Because Verktyg does not implement any way to add additional web services, the users

are therefore restricted to the ones that were initially implemented. There is also no way

of redirecting a single web service to a test environment. This instead has to be done

manually by entering the correct URL:s which once again allow for typing mistakes. In

the KlarSynt Tools database, URL:s for all the web services are stored and can easily

be extended with tuples to include new web services. This database table can also be

manipulated directly from KlarSynt Tools which makes adding a new web service even

less troublesome than having to open a separate application to change the values in the

database table. Functionality has also been implemented to make it possible to redirect

one or a preferred number of web services to OptiWeb without having to type in any URL

addresses manually.

Another problem with Verktyg is that you have to manually look at each web service’s

URL to determine which type of environment (test, production, or development) it belongs

to. This can be seen in figure 6.2. In KlarSynt Tools the environment is displayed together

with each web service and an icon is also present to alert the user if multiple web services

are redirected to varying environments. This both improves efficiency and accuracy since

the user does not have to carefully look through all the web service URL:s to check that

all the addresses are correct. The color coded icons also provide user friendliness which in

turn additionally improves efficiency.

41

Figure 6.2: Web services in Verktyg

6.2 Comparison between new and old process

This section will measure the number of steps using the old process (Verktyg along with

other manual tasks) and the new automated process using KlarSynt Tools. A comparison

of the time taken to configure the settings for an average case, between the previous process

and by using KlarSynt Tools will also be given and valuated.

As can be seen in table 6.1 some features are not present in Verktyg and therefore has

to be done manually. This results in having to go though numerous steps before being able

to completely configure the test database and Windows Registry. Figure 6.3 presents all

the steps that had to be gone through using the old process in a standard case.

The old process consists of a total of 10 different steps, where 5 of them include manual

42

Development environment Test environment Database

Input IP-address and database instance

Input login credentials

Change to test web services

Check the IP-address

Enter right credentials for OptiWeb login

Enter right credentials for ServeIT login

Check patch level

Latest?Enter the patch level in Windows Registry

Install the latest patch No

Yes

Remove desktop to test environment

Figure 6.3: Steps of the old process (standard case)

input of values to the test database or Verktyg.In contrast to this, when using KlarSynt

Tools in the standard case there is only a total of 3 steps needed, which of none include

manual input of values. These steps can be seen in figure 6.4.

Comparing these two processes, clear improvements to the old process can be seen.

The new process using only one application, KlarSynt Tools, have reduced the number of

steps by 7 and removed all the manual inputs that had to be made using the old process.

During the writing of this thesis, we had the opportunity to observe and measure the

time taken for an average case of configurations to be made. We also performed the very

same configurations and measured the time taken with KlarSynt Tools, which showed clear

improvement to the old process. A comparison of the steps performed and the time taken

for each latest is presented in table 6.2.

43

Development environment Test environment Database

Open KlarSynt Tools

Select test environment and database

Change to test/prod/dev web services

Lateset? Install the latset patchNo

Figure 6.4: Steps of the new process (standard case)

As can be seen in table 6.2 the time taken for the old process was approximately 10

minutes and 10 seconds while the time taken for KlarSynt Tools was merely 31 seconds.

This shows an improvement to the old process by nearly 1 / 20 of the time taken.

Old process Time New process TimeRemote desktop 1 min 30 secCheck IP-address 30 secOpen Verktyg 10 sec Open KlarSynt Tools 10 secInput connection-string andtest connection

2 min 15 sec Select server and database 5 sec

Change to test web services 4 min Change to test web service 10 secLogin to the database 30 secEnter OptiWeb login 20 sec Enter OptiWeb login 2 secRemove ServeIT password 20 sec Remove ServeIT password 2 secCheck Patch level 20 sec Change Patch level 2 secEnter patch level in Win-dows Registry

30 sec

10 min 10 sec 31 sec

Table 6.2: Comparison in time between old and new process

44

6.3 Summary

In this chapter the results of the proposed Windows application was presented. A compar-

ison was made between Verktyg and KlarSynt Tools which describes how KlarSynt Tools

improves efficiency and accuracy when configuring test databases at Ninetech. Lastly the

amount of steps required to change values in the database and Windows Registry for the

new and old process is measured and compared.

45

7 Conclusion

Having a controlled environment for developing and testing applications is important,

especially when the application is integrated with other services that could potentially affect

customer data. The main purpose with this project was to create an application that could

show current settings of a customer database as well as efficiently and accurately change

these setting so that the customer database can be redirected to different environments.

This application was also required to have a separate database where information about the

utilized environments and different web services are stored. This so that when additional

environments or web services are added, they can easily be added without having to change

the code of the application. The application was also to be developed in such a way that

further features could easily be implemented. For this, techniques that achieve a loosely

coupled application where used, resulting in that extensions to the current application can

be added with little inconvenience.

7.1 Evaluation of the project

The programming language C# and the database language SQL was familiar and had been

worked with before the start of this project. However, techniques like MVVM, WPF and

using stored procedures in SQL was new at the start of the project and some research had

to be done in order to acquire necessary knowledge for the incorporation of these. The

combination of both familiar and unfamiliar techniques and tools has kept this project at

a reasonable level of difficulty.

Ninetech provided office space at their office next to ServeIT developers which en-

abled us to keep close contact with our supervisor and resolve any issues instantaneously.

Being able to have meetings with the supervisor to discuss further development of new

features and the interface design helped to avoid misinterpretation. Consequently this led

to misinterpretations about design and functionality being resolved at an early stage and

46

eliminating extensive reconstruction of the application. Having a real customer (Ninetech)

was also seen as a great experience and provided insight to how negotiations might take

place with a customer when working at a consulting firm.

7.2 Problems

Implementation wise, there was not any specific notable problem that was encountered.

Most minor problems, however, was centered around understanding the MVVM pattern

and being able to utilize it in the best way possible. As both participants in this project

had no previous experience with this working pattern, some time during the project was

required to be spent on learning. The most difficult part of MVVM, which both authors

could agree on, was to understand how data can be shared between the GUI-side of the

project and the logic-side in the rare cases it was needed (seeing as the GUI should not

hold references to the logic in MVVM). These problems, however, were eventually solved

without much inconvenience.

Another problem concerning the implementation was the structuring of the program

code. As WPF together with MVVM introduced many properties (for binding) in the

logic side of the program code, structuring of the code to hide away this data was seen as

a minor problem.

7.3 Future work

One of the initial purposes of the new application was that it, in the future, might be

integrated in a bigger application together with other tools intended for internal use at

Ninetech. The application was therefore made with this in mind, and implementation

decisions were made to make the application as suitable for integration as possible. As

mentioned earlier, techniques like MVVM were used to make it easy for new features to

be added to the application in the future. With a loosely coupled code structure, for

47

instance, a logic component could be swapped out and replaced by another component

without having much effect on the GUI side of the program code, and vice versa.

By using WPF, the application is further adapted for modification and restructuring of

the program code. Because WPF uses the mark-up language XAML for configuration of

its components, XAML code can be moved to other sources without much inconvenience.

This also means that only the parts that are needed from a GUI in an application, could

be moved to be part of another application. For instance, some of the parts of the GUI

from the KlarSynt Tools application, could be placed inside a tab in a new application,

containing tabs for many different programs and tools (which is what Ninetech might plan

to do in the future). In contrast, using Windows Forms to build the GUI would make it

more inconvenient to move parts of the GUI (or parts of single components), as Windows

Forms is not built around the use of a mark-up language but on settings made by the user

through a graphical interface.

48

References

[1] About Ninetech. http://www.ninetech.se/Om-Ninetech/English-Summary/. Ac-cessed 2014-05-02.

[2] Colour-affects - Psychological Properties Of Colours. http://www.colour-affects.co.uk/psychological-properties-of-colours. 2014-05-07.

[3] KlarSynt - Linsboxen. http://www.klarsynt.se/kontaktlinser.300. Access 2014-05-07.

[4] Microsoft Developer Network - Code-Behind and XAML in WPF. http://msdn.microsoft.com/en-us/library/aa970568%28v=vs.110%29.aspx.

[5] Microsoft Developer Network - Structure of the Registry. http://msdn.microsoft.com/en-us/library/windows/desktop/ms724946%28v=vs.85%29.aspx. Accessed 2014-05-07.

[6] Microsoft Developer Network - XAML Overview (WPF). http://msdn.microsoft.com/en-us/library/ms752059%28v=vs.110%29.aspx. Accessed 2014-05-07.

[7] National Institute of Standards and Technology - Database Language SQL. http://www.itl.nist.gov/div897/ctg/dm/sql info.html. Accessed 2014-05-22.

[8] RFC 792 - Internet Control Message Protocol. https://tools.ietf.org/html/rfc792.Accessed 2014-05-22.

[9] SQL Stored Procedures. http://technet.microsoft.com/en-us/library/aa174792(v=sql.80).aspx. Accessed 2014-05-07.

[10] The Free Dictionary - End to end solution. http://encyclopedia2.thefreedictionary.com/end-to-end+solution. Accessed 2014-05-07.

[11] L. Bugnion. MVVM - Commands, RelayCommands and EventToCommand. http://msdn.microsoft.com/en-us/magazine/dn237302.aspx. Accessed 2014-05-07.

[12] R. Edmondson. Why are traffic lights Red, Yellow and Green? http://www.myuniversalfacts.com/2005/10/why-are-traffic-lights-red-yellow-and.html, 2005. Ac-cessed 2014-05-07.

[13] V. Gaudioso. Mvvm: Model-view-viewmodel. In Foundation Expression Blend 4 withSilverlight, pages 341–367. Apress, 2010.

[14] G. Hall. Model-view separation. In Pro WPF and Silverlight MVVM, pages 55–79.Apress, 2010.

49

[15] M. Hodnick. Windows Presentation Foundation (WPF) 3D Tutorial. http://kindohm.com/technical/WPF3DTutorial.htm. Accessed 2014-06-05.

[16] C. Janssen. Techopedia - What is Production Envrionment. http://www.techopedia.com/definition/8989/production-environment. Accessed 2014-05-07.

[17] N. Mertz. Usabilla - How and Why Icons Improve Your Web Design. http://blog.usabilla.com/how-and-why-icons-improve-you-web-design/, 2012. Accessed 2014-05-07.

[18] P. D. Sheriff. Why Use WPF? http://www.codemag.com/Article/0911031. Accessed2014-05-07.

[19] J. Smith. WPF Apps With The Model-View-ViewModel Design Pattern. http://msdn.microsoft.com/en-us/magazine/dd419663.aspx.

[20] E. Sorensen and M. Mihailesc. Model-View-ViewModel (MVVM) Design Patternusing Windows Presentation Foundation (WPF) Technology. MegaByte Journal, 2010.

[21] R. Vice. MVVM Survival Guide for Enterprise Architectures in Silverlight and Wpf.Packt Publishing, 2012.

[22] D. Worthington. SD Times - Microsoft adds XAML to ’Open Specification’list. http://www.sdtimes.com/%28X%281%29S%28kw21wu45u03kzpnafqlanyiy%29%29/content/article.aspx?ArticleID=31886&page=1, 2008. Accessed 2014-05-07.

50