Вы находитесь на странице: 1из 44

EMAIL TO TICKET AUTOMATION

A PROJECT REPORT
Submitted in partial fulfilment for the award of the degree
of

Master of Technology
in
Information Technology
by

Thanuja M
15MIN0864

Under the guidance of

Prof. Chavan

VIT University

School of Information Technology and Engineering

JULY, 2019

Sensitivity: Internal & Restricted


DECLARATION BY THE CANDIDATE

I hereby declare that the thesis entitled “Email to Ticket Automation” submitted
by me to Vellore Institute of Technology University Vellore, in partial fulfillment
of the requirement for the award of the degree of Master of Technology in
Information Technology is a record of bonafide project work carried out by me
under the supervision of Prof. Kumaran U. 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 in this institute or
any other institute or university.

Place: Bangalore Thanuja M


Date: 27 July 2019 Signature of the Candidate

Sensitivity: Internal & Restricted


School of Information Technology and Engineering

BONAFIDE CERTIFICATE

This is to certify that the project work entitled “Email To Ticket Automation”
by Thanuja M(15MIN0864), to Vellore Institute of Technology University,
Vellore, in partial fulfillment of the requirement for the award of the degree of
Master of Science in Information Technology, is a project bonafide work
carried out by him/her under my supervision. The project fulfills the requirement
as per the regulations of this Institute and in my opinion meets the necessary
standards for submission. The contents of this report have not been submitted and
will not be submitted either in part or in full, for the award of any other degree or
diploma in this Institute or any other Institute or University.

Prof. Kumaran U
Internal Supervisor
VIT University

Internal Examiner(s) External Examiner(s)

Sensitivity: Internal & Restricted


Table of Contents

ABSTRACT ............................................................................................................................. 6
ORGANIZATION OF THE DOCUMENT .......................................................................... 7
LIST OF SYMBOLS AND ABBREVIATIONS ................................................................... 8
LIST OF FIGURES ................................................................................................................. 8
LIST OF TABLES ................................................................................................................... 9
INTRODUCTION ................................................................................................................. 10
1.1 About Wipro Technologies ........................................................................................ 11
1.2 What is EHelpline? ...................................................................................................... 11
1.3 What is Incident Module? ........................................................................................... 12
1.4 Need for Automation of Ticket logging ..................................................................... 12
1.5 Process Methodology ................................................................................................... 13
REQUIREMENT SPECIFICATIONS ................................................................................ 14
2.1 Introduction ................................................................................................................. 15
2.1.1 Purpose of the project ............................................................................................ 15
2.1.2 Scope of the Project ............................................................................................... 15
2.2 Functional Requirements ............................................................................................ 16
2.2.1 Model/Process Flow............................................................................................... 16
2.2.2 Business Requirements .......................................................................................... 17
2.3 System Requirements .................................................................................................. 19
2.3.1 Hardware Requirements ........................................................................................ 19
2.3.2 Software Requirements .......................................................................................... 20
DESIGN/ FUNCTIONAL SPECIFICATIONS .................................................................. 22
3.1 HPOO Introduction ........................................................................................................ 23
3.1.1 What is HP Operations Orchestration? ................................................................ 23
3.1.2 Why HPOO? .......................................................................................................... 23
3.1.3 Key Benefits of HPOO ........................................................................................... 24
3.1.4 HPOO Architecture ............................................................................................... 24
3.2 HPOO FLOW Design .................................................................................................. 26
3.2.1 Introduction to HPOO flows design ...................................................................... 26
3.2.2 Key parts of a flow ................................................................................................. 27
3.2.3 Advanced flow, step, and operation concepts ....................................................... 27

Sensitivity: Internal & Restricted


3.2.4 Benefits for Flow Authors ..................................................................................... 28
3.3 Design specifications ............................................................................................... 30
3.3.1 Introduction....................................................................................................... 30
3.3.2 Page Design............................................................................................................ 31
3.3.3 System Overview .................................................................................................... 32
3.4 Web API ....................................................................................................................... 33
DATABASE DESIGN & SPECIFICATIONS .................................................................... 37
4.1 Introduction ................................................................................................................. 38
4.2 Object Details ............................................................................................................... 38
4.3 Object & Data types .................................................................................................... 38
4.4 Object Relation Structures ......................................................................................... 39
FUTURE GOALS .................................................................................................................. 40
5.1 Introduction ................................................................................................................. 41
5.2 Plan of work ................................................................................................................. 41
5.3 Work Accomplished .................................................................................................... 42
5.4 Way Ahead ................................................................................................................... 42
BIBLIOGRAPHY .................................................................................................................. 43

Sensitivity: Internal & Restricted


ABSTRACT
EHelpline is an integrated ITSM solution, which is offered as a suite of service
management applications. It acts like a single system that can support all processes and
manage the business services required by the organization. EHelpline is a Ticketing
system where calls from End user (Manual) as well as calls based on the Event (Auto
Calls) will be logged. EHelpline is a powerful, flexible, and user-friendly tool for logging
any ticket. In EHelpline, a user can log Incident or Request fulfillment calls by logging
into the application.

By dissertation, Email to ticket automation enables the option in existing EHelpline tool
to log a ticket by sending mails to a dedicated mailbox. Purpose of this project is to make
ticket logging convenient and easy for the end users.

By using this feature, EHelpline tool can provides option for end users to raise an incident
ticket by sending mails. Once the mail sent to a dedicated mailbox, respective ticket will
be logged as an incident. A support staff can work on the ticket in EHelpline and update
his activities on the ticket.

Sensitivity: Internal & Restricted


ORGANIZATION OF THE DOCUMENT

This document includes the following chapters:

 Chapter 1. Introduction. This chapter explains the challenges faced in current scenario.
Also it describes the need, solution over the challenges of current scenario using Email
to ticket Automation

 Chapter 2. Requirement Specification. This chapter discusses the functional, business


and software requirements required for Automation.

 Chapter3.Design/Functional Specification. This chapter discusses the


design/functional specification required for Automation.

 Chapter 4. Database Design & Specification. This chapter presents the Database
structure and Table objects.

 Chapter 5: Future Goals. This chapter presents the things done for the first 8 weeks
for Mid-Semester according to the plan of work presented earlier and also presents a
list of work that are going to be carried out for the rest of the semester

 Chapter 6: Glossary and Bibliography. This chapter presents the list of abbreviations
and resources referred.

Sensitivity: Internal & Restricted


LIST OF SYMBOLS AND ABBREVIATIONS

Term Definition
SQL Structured Query Language
IIS Internet Information Services
.Net Language to create forms and UI designs
DB Database
HTML Hypertext Markup Language
ITSM Information Technology Service Management
HPOO HP Operations Orchestration
RAS Remote action service
POP3 Post Office Protocol version 3
SLA Service level agreement
API Application programming interface
XML Extensible Markup Language
PFA Pending For Approval

LIST OF FIGURES

Figure Captions
shows the higher-level representation of MAILBOX, HPOO and
Figure 1
EHelpline Applications
shows the process flow of Ticket Automation
Figure 2
Shows HPOO Architecture
Figure 3
HPOO simple flow design and Process
Figure 4
HPOO email send flow
Figure 5
Shows the Home Page for Ticket logging in EHelpline tool.
Figure 6
shows the overall system workflow for Email To ticket Automation
Figure 7
Figure 8 shows the Object Relation Structure

Sensitivity: Internal & Restricted


LIST OF TABLES

Table Captions
Represents the fields required to log a ticket in EHelpline.
Table 1
Represents the hardware requirements
Table 2
Represents Hardware requirements for HPOO studio installation on
Table 3
its own machine
Represents the software requirements
Table 4
Represents the Software Requirements for Studio
Table 5
Table 6 Represent object details for database structure

SD Incidents Table
Table 7
Table 8 Plan of work

Sensitivity: Internal & Restricted


Chapter

1
INTRODUCTION

This chapter contains the following topics:

 About Wipro Technologies


 What is EHelpline?
 What is Incident Module?
 Need for automation of ticket logging
 Process methodology

10

Sensitivity: Internal & Restricted


INTRODUCTION

1.1 About Wipro Technologies

Wipro Technologies is the global technology services division of Wipro Ltd.


(NYSE:WIT). It offers a full portfolio of services across industries, delivering measurable
business benefits for our customers with six-sigma consistency. Wipro is the world's first
software services company to attain SEI Level 5 certification for software quality. Wipro has
business offices in North America, West Europe and Japan and development centers in India,
USA and UK.

Wipro is a Service Organization engaged in a wide range of Product as well as consultancy


services. Most organizations have recognized the need for offering a "Personalized Service"
as an intelligent, cost effective way to retain their business. Customers and People
management are the focus areas of Wipro.

1.2 What is EHelpline?

EHelpline is an integrated ITSM solution, which is offered as a suite of service management


applications. It acts like a single system that can support all processes and manage the
business services required by the organization. EHelpline is a Ticketing system where calls
from End user (Manual) as well as calls based on the Event (Auto Calls) will be logged.
EHelpline is a user-friendly versatile tool that focuses primarily on self-service. It is flexible,
easy to implement and aims at helping organizations achieve superior.
Incident and problem resolution, faster request fulfillment and uncomplicated change,
configuration and knowledge management processes.
EHelpline facilitates organizational learning and transfer of information by enabling easy
creation and maintenance of knowledge repositories and reports.
By dissertation, we can enable the option in the EHelpline tool to allow users to log tickets in
EHelpline by sending emails to a dedicated email ID.
This feature Automates the manual process of the ticket logging by allowing users to log a
tickets by sending mails through outlook to a dedicated email ID which intern reduces
manual effort of end users, time and cost.

11

Sensitivity: Internal & Restricted


1.3 What is Incident Module?

An incident is an unplanned interruption to an IT Service or reduction in the quality of an


IT Service. Any event that could affect an IT service in the future is also an Incident.

Incident Management is the process responsible for managing the lifecycle of all incidents.
The primary Objectives of incident Management is to return the IT Service as quickly as
possible.
By dissertation, Email based call logging feature will be introduced for Incident module in
EHelpline Tool.

1.4 Need for Automation of Ticket logging

An organization that automates the process will become more efficient and improve its
customer satisfaction.
Ticket automation can improve the development process of a software product in many cases.
The automation of tests is initially associated with increased effort, but the related benefits
will quickly pay off.
Email to ticket automation can save a business time and money by minimizing the manual
work and makes the things even quicker.
This option has been enabled in the tool to allow users to log tickets in EHelpline by sending
emails to a dedicated email ID. Users can send emails to a specified email ID to log incident
and service request calls.
Below are the main reasons why automation is more adopted in organization.
Speed
Efficacy
Quality
Decreased cost

12

Sensitivity: Internal & Restricted


1.5 Process Methodology

The design and implementation of this project involves Waterfall model.

Requirement Analysis Phase:


The goal of this phase is to produce requirement specification document of the proposed
system. Identify and document all the functional and non-functional requirements completely
and unambiguously.

Design Phase:
The goal of this phase is to produce a design document. Both, a high level and a detailed design
document will be prepared. An appropriate design methodology suitable for the project is
decided and a detailed design document is prepared.

Implementation Phase:
The main activity of this phase would be to develop source code based on the detailed design
document. A unit test plan is prepared explaining the approach for testing the implementation
of features and functionality of each component or each module of the project. Unit test cases
are prepared based on the Unit Test Plan. The individual components of the project are tested
according to the procedure defined in the Unit Test Plan. The unit test cases are executed and
their results are recorded.
Testing Phase:
This includes detailed testing phase.
Integration Phase:
An integration test plan is prepared explaining the approach for testing the interfaces between
various units of the project. The system is tested, according to the test procedures defined in
the Integration Test Plan.

Maintenance Phase: This includes the support for INT, Acceptance, Production and related
changes to support application

13

Sensitivity: Internal & Restricted


Chapter

2
REQUIREMENT SPECIFICATION

This chapter contains the following topics:

 Introduction
 Purpose of the project
 Scope of the project

 Functional Requirements
 Model/Process Flow
 Business Requirements

 System Requirements
 Hardware Requirements
 Software Requirements

14

Sensitivity: Internal & Restricted


2.1 Introduction

2.1.1 Purpose of the project

This document provides a description of the email to ticket logging automation in terms of
technical requirements, actual implementation done on the project. The information will help
to know how far the goal is being attained. Development will use this document mainly in the
implementation purpose, and Customers may examine and provide input to the document.

Tickets has to be created in EHelpline tool by sending mails to a dedicated mailbox using web
services as a medium of integration for create operations.

EHelpline will expose a web method, which has to be invoked by HPOO work flow and Mail
box by passing needful parameters to create a ticket.

2.1.2 Scope of the Project

 Integrate with HPOO & EHelpline tool possible use cases or workflows that can
developed with the integration.
 We can use the web services of hpoo and EHelpline for integration
 HPOO email automation POP3:When some email account receives mail my flow
should trigger(start execution)and do automation based on email content.
 The mail trigger content pack has been designed to enable one to trigger flows by
simply sending mails to a specific format to a custom mail address.
 HPOO supports the flexibility of allowing automatic creation of Tickets from an e-
mails sent by end users.
 These can be used to allow users to create simple tickets, comment and add attachments
on tickets via email.
 HPOO can be configured to automatically create issues or comments on existing issues
based on incoming messages received by a mail server or external mail service.
15

Sensitivity: Internal & Restricted


2.2 Functional Requirements

2.2.1 Model/Process Flow

Figure1 shows the higher-level representation of MAILBOX, HPOO and EHelpline


Applications:

Figure 1

16

Sensitivity: Internal & Restricted


2.2.2 Business Requirements

 Ticket automation can improve the development process of a software product in many
cases. The automation of tests is initially associated with increased effort, but the related
benefits will quickly pay off.

 Email to ticket automation can save a business time and money by minimizing the
manual work and makes the things even quicker.

 This option has been enabled in the tool to allow users to log tickets in EHelpline by
sending emails to a dedicated email ID. Users can send emails to a specified email ID
to log incident and service request calls.

 Below are the main reasons why automation is more adopted in organization.
Speed
Efficacy
Quality
Decreased cost

 Automation of Email to ticket has to reduce manual efforts, save time and has to provide
end users convenient and efficient way of ticket logging by allowing end users to send a
mail to a dedicated mail id to log tickets in tool, rather than traditional approach of ticket
logging.

 To achieve this making use of HPOO Automation tool which is the industry-leading
solution for IT process automation and run book automation and Reduces operational cost
with automation of common tasks and processes

 EHelpline will expose a web method, which has to be invoked by HPOO work flow and
Mail box by passing needful parameters to create a ticket.

 Tickets have to log automatically in EHelpline tool with all the required information sent
through mail and processed by support staff which reduces the ticket logging time of the
end users time.

17

Sensitivity: Internal & Restricted


Fig 2 shows the process flow of Ticket Automation:

Figure 2

18

Sensitivity: Internal & Restricted


Table 1 represents the fields required to log a ticket in EHelpline.

Table 1

Company Wipro

Service category Service restart

Group HPOO

Service classification Restart AD service

Priority P1

Impact Critical

Urgency very urgent

Department Ehelpline

Location Bangalore

Title Server issue

Description Need to Restart server

2.3 System Requirements

2.3.1 Hardware Requirements

Table 2 represents the hardware requirements


Table 2

Application Server / Database Server / Reporting Server

Pentium xeon processor and above

One Tier 4GB RAM, 80GB HDD- Free Disk space for application [C:\ Should be of 20 GB for
Architecture OS] 10 / 100 Ethernet card, 24 X CD / DVD ROM Drive or above.

Server class hardware configuration, dedicated server (No other activity to be


performed on the server).

19

Sensitivity: Internal & Restricted


Table 3 represents Hardware requirements for HPOO studio installation on its own
machine

Table 3

Component Requirement (minimum)

CPU 2 Gigahertz (GHz) for single-or multi-


process or systems 1CPU core

2GB (this is the amount of memory that the


Memory (RAM) Studio process requires

4 GB (this includes room for the flows and


Hard-drives pace operations that are included in the

2.3.2 Software Requirements

Table 4 represents the software requirements

Table 4

Windows server 2008 32/64

Exchange server required(2003 or 2007 or 2010)

IIS 7.0 and above with latest service pack.


Minimum Software SQL server 2008 with latest service pack
requirements for all Tiers
Excel 2003 and above

.Net framework 4.5 only.

Browser : Compatible with I.E 6.0, 7.0, Mozilla 3.6.3 and above

20

Sensitivity: Internal & Restricted


Table 5 represents the Software Requirements for Studio
Table 5

Component Requirement
Microsoft Windows Server 2012 64 bit
Supported operating systems Microsoft Windows Server R2 2012 64bit
Microsoft Windows Server 2008 64 bit
Microsoft Windows ServerR2 2008 64 bit

Microsoft.NETFramework4.5orlater,fullinstallation.
.NET Framework
Microsoft Visual C++2008 SP1 redistributable
Service packs package(x86).

21

Sensitivity: Internal & Restricted


Chapter

3
DESIGN/FUNCTIONAL SPECIFICATIONS

This chapter contains the following topics:

 HPOO Introduction

 HPOO FLOW Design

 Design specifications

 WEB methods

22

Sensitivity: Internal & Restricted


3.1 HPOO Introduction

3.1.1 What is HP Operations Orchestration?

 HP Operations Orchestration (HP OO) is the industry-leading solution for IT process


automation and run book automation.
 HPOO is a system for creating and using actions in structured sequences (called flows)
which maintain, troubleshoot, repair, and provision your Information Technology (IT)
resources by:

 Checking the health of, diagnosing, and repairing, networks, servers, services, software
applications, and individual workstations.

 Deploying applications, patching, and maintaining them by checking client, server, and
virtual machines for required software and updates, and, if needed, performing the
necessary installations, updates, and distributions.

 Performing repetitive tasks, such as checking status on internal or external website pages.

3.1.2 Why HPOO?

 In many companies, the following issues can result in poor service quality, delayed time-
to-market, and high operating costs:

 Incidents–floods of alerts, unnecessary escalations

 Change and releases–too many manual errors, lack of audit trails

 Process management–need for processes for complex tasks, for example, disaster recovery

 Virtualization–in consistent management of physical and virtual assets

23

Sensitivity: Internal & Restricted


3.1.3 Key Benefits of HPOO

The key benefits of HPOO include:

 Reduced operational cost with automation of common tasks and processes

 Improved service quality with accelerated incident resolution

 Improved audit compliance through documentation generation and reporting

 Integration with current IT environment to ensure minimal impact on procedures and tools

3.1.4 HPOO Architecture

HP Operations Orchestration 10.x is composed of 4 main functional components:


 OO Studio
 OO Central
 OO Remote Action Service(RAS)
 OO Content

Together, the components of HPOO enables us to manage various services and devices across
the organization and across their life cycle.

24

Sensitivity: Internal & Restricted


Figure 3 HPOO Architecture

HPOO Studio
HPOO Studio is a desktop-based application that is used by flow authors to create the HPOO
flows. Studio enables the author to design flows, debug them, and package them. It provides
automation via code capabilities, such as integration to Source Control Management
software, project separation, and multi-authoring.

HPOO Central
HPOO Central is the run time environment of HPOO. It is used for running flows, monitoring
the various runs, and generating reports. It has a web-based UI and a set of APIs, which are
accessed by the administrators, end users, and integrators.

25

Sensitivity: Internal & Restricted


HPOO Remote Action Service(RAS)

The HPOO RAS enables execution in remote data centres and networks. The HPOO RAS
interacts with HPOO Central and polls it for operations to execute. Since the communication
is from the RAS to Central, you need to open ports for in bound communication only in
Central. Moreover, to achieve high availability of RASes, you simply add another RAS and
point it to Central.

HPOO Content

HPOO provides a rich set of out-of-the-box operations and flows that enable you to author
complex flows, orchestrating various services. The HPOO content is delivered as a set of
granular content packs that you can download, deploy, and manage individually. These are
the Process Automation Libraries. In addition, HPOO provides wizards for generating
additional content over other services such as Web Service Wizard.

3.2 HPOO FLOW Design

3.2.1 Introduction to HPOO flows design

A flow is a set of actions that are linked by decision-making logic and automate tasks such as
health checks, troubleshooting or any other repetitive IT support tasks. A run is the execution
of a flow.

3.2.2 Key parts of a flow


Steps are the basic units of a flow. Operations do the actual work of the flow, Steps are
created from operations, which are the templates for steps. Thus, operations are the building
blocks of any flow.
 Inputs give the operation the data that they need to act upon.
Inputs can be:
 Entered by the person running the flow.
 Set to a specific value.
 Obtained from information gathered by another step.

26

Sensitivity: Internal & Restricted


 Responses are the possible outcomes of the operation. Our copy file operation might
have just “success” and “failure”.
 Transitions:. A transition leads from an operation response to one of the possible next
steps, so that the operation’s response determines what the next step will be.

A flow step’s operation uses input data to perform a task, from which it obtains results.
The operation has several possible responses, one of which is chosen depending on what its
results were.
Each response is connected by a transition to one of the possible next steps in the flow.

3.2.3 Advanced flow, step, and operation concepts

The basic difference between steps and operations is that steps are instances of operations.
Operations and flows tell HPOO how to do something.
This is why a flow is a kind of operation (remember this particularly when you use the flow
to create a step in another flow).
A step is always an instance of an operation or flow. Thus, an operation is a template from
which you create a step when you drag the operation on to a flow’s authoring canvas.
Each input is mapped to a variable, whose value can come from a variety of sources.
Which element you add an input to can determine when the input’s value is obtained: An
input for a flow obtains a value before the first step runs.

27

Sensitivity: Internal & Restricted


FIGURE 4 shows HPOO simple flow design and Process

Figure 4

Figure 5 shows Send email flow

OO uses Flow to maintain the IT resources, Creation of the automation factory framework
with a web-based front end of searchable content and flows , enabled consistent selection,
design, development, support and reuse of workflows. The Client was able to develop a
strong and sustained process to create and manage workflows as a core strategic differentiator
in supporting its global expansion.

28

Sensitivity: Internal & Restricted


3.2.4 Benefits for Flow Authors

Easy-to-use

HP OO Studio offers an intuitive drag-and-wire capability to design, create, share, and


customize flows. The drag-and-wire visual interface enables rapid time-to-value. A visual flow
debugger makes it easy to debug flows.

Out-of-the-box Content

HP OO offers out-of-the-box content to manage operating systems, databases, app/web


servers and networking platforms. You can utilize out-of-the-box integrations with common
HP and third party systems management tools, such as ticketing, monitoring and event
consoles, virtualization, CMDB, and data centre automation.

Standalone Studio

HP OO Studio is a standalone tool that doesn’t require a connection to Central. All of its
repository operations are available offline. If a source control interaction is required, you decide
when the interaction occurs. In this manner, remote teams can use various standalone Studios,
and it is even possible to author outside of the office network.

Standard Source Control Integration

HP OO Studio integrates with standard source control software. Even the out-of-the box
solution is based on a common source control software (SVN). This means that the common
capabilities of source control software are available for Studio, so you can connect and use
your organization's source control software. This also means that the automation code can
reside with other source code and follow the same life cycle (automation as code).

Multi-Authors and Multi-Geographies

HP OO Studio works offline and leverages standard source control software to share work
between multiple and distributed authors.

29

Sensitivity: Internal & Restricted


Annotation-Based Content

HP OO Studio includes ‘@Action’ annotations that can be added directly to your own code.
This means that your code can be leveraged to be OO content and still be tested in the context
of your development framework.

Fine-Grained HP Content

HP OO content has been organized into a set of about 15 content packs. Each content pack
provides flows and operations for a functional domain. You have control over which content
packs to download and which to deploy. You can use only what you really need and ignore
others.

Fine-Grained Customer Content

In HP OO Studio, your content can be separated into projects and managed separately for each
author and group. This gives you complete flexibility in defining the flows that are grouped
together and the workspace of each author. Different authors get a focused development
environment with the flows that are relevant to them, and do not affect other authors' flows.

Remote Debugging
HP OO Studio allows the author to connect to a live Central environment and achieve full
debugging capabilities for that environment. This enables multiple authors to test their flows
on a real environment and control the testing from within the Studio debugging environment.
Flow debugging does not affect the content that is deployed on Central and does not require
pre-deployment; however, it provides full logging information in Central and is protected by
entitlement.

3.3 Design specifications

3.3.1 Introduction

This section describes the design and technical implementation of Email to ticket
Automation, page designed for Incident.

30

Sensitivity: Internal & Restricted


3.3.2 Page Design

The below figure 6 shows the Home Page for Ticket logging in EHelpline tool.

Figure 6

31

Sensitivity: Internal & Restricted


3.3.3 System Overview

Figure 7 shows the overall system workflow for Email To ticket Automation

Figure 7

System workflow steps are as explained below.

1. Sending mails to a dedicated mailbox by providing mail content in predefined format.


2. EHelpline will expose a web methods which are required to create a HPOO flows,
3. Web methods have to be invoked by HPOO tool.
4. Designing of simple HPOO flow using predefined operators.
5. Need to create a new table structure in EHelpline DB
6. All the required fields will be inserted into EHelpline DB though web services.
7. Tickets are getting logged in EHelpline tool.

32

Sensitivity: Internal & Restricted


3.4 Web API

EHelpline contains a web service layer in which certain methods are exposed. This web
service layer is used by third parties to access EHelpline.

Web APIs are used by third parties to access EHelpline through the web service layer and log
web service calls.

A web API (Application Programming Interface) is typically a defined set of HTTP request
messages along with a definition of the structure of response messages.

EHelpline Web API is a web service API that enables customers to interact with EHelpline.
Customers can develop their own client interface to interact with EHelpline through the use of
Web Service API.

Web service calls that can be logged using EHelpline web API are as follows:

1. Login

2. GetTicketsData

3. GetTicketData

4. GetMasterData

5. GetServiceTypes

6. GetClassifications

7. GetCIData

8. CreateTicket

9. CloseTicket

10. ReOpenTicket

11. UpdateUserClarifications

12. UpdateUserComments

13. GetTicketActivityData

14. GetTicketHistoryData

15. Logout

33

Sensitivity: Internal & Restricted


1) Validating the login and creating a session:

Web Service users will be provided with User Credentials (such as User Name, string
Password) before be given access to the web services. On successful authentication of the
credential a unique Session ID will be created in Ehelpline application and returned to the
consumers. This unique Session ID should be used to access other web service method calls.
Without a valid session Id no services will be provided to consumers.

2) GetTicketsData

GetTicketsData Web Service method provides the list of Service Desk Calls to the consumers.
The list of calls will include necessary columns such as Call Id, Call Status, Open Date Time,
End date time, Staff, etc. In addition Filter By call status option enables the consumers to
retrieve filtered calls.

3) GetTicketData

GetTicketData Web Service method provides the necessary ticket information for the given
ticket id. List includes all the necessary columns such as Call Id, Call Status, Open Date Time,
End date time, Staff, etc. If the Ticket Id does not belong to the user who is logged in then an
exception will be thrown.

4) GetMasterData

GetMasterData provides the master data for the ServiceDesk Business objects. GetMasterData
method requires a valid business object key name to retrieve the data.

5) GetServiceTypes

This web method provides the data on all available Service Types. GetServiceTypes has an
optional parameter of Classification which will provide information on all Service Types
belonging to a particular Classification. However GetServiceTypes provides data on all Service
Types if no classification is specified.

34

Sensitivity: Internal & Restricted


6) GetClassifications

This web method provides data on all Service Desk Classifications. GetClassifications has an
optional parameter of ServiceType which will return all Classifications belonging to the given
Service Type. However GetClassifications provides information on all Classifications if no
Service Type specified.

7) GetCIData

GetCIData Method provides data about Configuration Items for the logged user.

8) Create New Incident & Service Request Calls:

CreateTicket method is used to log Incident or Service Request call and provides the user with
the Ticket ID. Before creating the ticket all the data sent will be validated for valid SLA and or
Approval Matrix (if Service Request ticket is being logged). If no SLA is found then an
exception will be thrown at the client end.

9) Close Ticket

CloseTicket method gets Ticket Id as input and checks whether or not the ticket is in User to
Confirm State. If the ticket is UTC then it will be closed. If the ticket is not in UTC no action
will be taken.

10) Re Open UTC Ticket

ReOpenTicket method used to reopen the UTC ticket. Ticket will be reopened only if it is in
UTC state.

35

Sensitivity: Internal & Restricted


11) Update User Clarification – Pending for User

UpdateUserClarification method is used to provide clarification for the call which requires user
clarification. UpdateUserComments is provided for Incident calls only and not for Service
Request calls.

12) Add Activity - User Comments

UpdateUserComments method is used to add an activity entry for a given ticket. The input
parameter and return types is given below. The activity will be updated if the ticket is not
closed. User Comments is provided for Incident only, not for Service Request.

13) List History for Incident and Service Request Calls

GetTicketHistoryData provides the history data for the given ticket id. History Data will be
returned if given Ticket is logged by the User, Otherwise no data will be displayed and an
exception will be thrown to the user.

14) List Ticket Activity Data for Incident and Service Request Calls

GetTicketActivityData provides the activity data for the given ticket id. Activity Data will be
returned if given Ticket is logged by the user.

15) Logout Web Service Session

Logout web method is used to sign off from the web service session. After calling this method
web service session will be removed and users cannot access other web service methods for the same
session ID.

36

Sensitivity: Internal & Restricted


Chapter

4
DATABASE DESIGN & SPECIFICATIONS

This chapter contains the following topics:

 Object Details

 Object & its Data types

 Object Relation Structures

37

Sensitivity: Internal & Restricted


4.1 Introduction
This section describes the table structures used to create a ticket in EHelpline tool.
4.2 Object Details

Table 6 represent object details for database structure

Table 6

SYS Object Name Type Type Description Object Description


SD_Incident U Table Table used to capture ticket details
SD_IncidentView U View View to fetch the logged ticket details

4.3 Object & Data types

o SD_IncidentS Table (Table 7)


Table 7

Column_name Type Description


Id int PK field unique for new each entity. Null is not accepted
UserId int FK Field, User unique id
CompanyId int FK Field, User company
DepartmentId int FK Field ,User department
LocationId int FK Field ,Current Employee Location
ContactNo varchar FK Field ,User contact number
ServiceCategoryId int FK Field ,Service category
ClassificationId int FK Field, service classifications
SLMId int FK Field, Service level agreement
ImpactId int FK Field, Service Impact of the ticket
UrgencyId int FK Field, Service Urgency of the ticket
PriorityId int FK Field, Service Priority of the ticket
Title varchar Ticket Filed
Description nvarchar Issue highlighted by the user
StatusId varchar FK field, Service call status
GroupId int FK field, Service group
StaffId int FK field, support staff
OpenDateTime datetime Date of ticket creation
FileUploadId varchar File upload path
TimeZoneId int Time zone of the ticket
srcApplicationID nvarchar FK field, call source where ticket logged

38

Sensitivity: Internal & Restricted


4.4 Object Relation Structures

Figure 8 shows the Object Relation Structure

Figure 8

39

Sensitivity: Internal & Restricted


Chapter

5
FUTURE GOALS

This chapter contains the following topics:

 Introduction

 Plan Of Work

 Work Accomplished

 Way Ahead

40

Sensitivity: Internal & Restricted


5.1 Introduction

This section describes the things done for the first 8 weeks for Mid-Semester according to the
plan of work presented earlier and also presents a list of work that are going to be carried out
for the rest of the semester.

5.2 Plan of work

Table 8

Planned
Tasks/Sub-tasks to be Specific Deliverable in
Serial duration Status
done terms of the project
Number (in weeks)

1 Requirement 3 Requirement
Specification and High- Specification
Completed
Level Analysis Phase: Document
Detailed requirement
gathering and Analysis.
2 Design Phase: 4 Design document and
Test description
Detailed design of Completed
document.
HPOO flows and all
components.
3 Coding Phase: 2 Source Code.
Coding of various Unit Test Plan Simple flow design
components. document. has been
completed
4 Unit Testing Phase 2 Unit Tested Code
ready for System
Test case preparation to Yet to Start
testing
check quality for all
types of programs.
5 System Testing Phase 3.5 System tested Code/ Yet to Start
and UAT: Final Product and
Deployment Plan.
Delivery of the product.
6 Deployment Phase : 0.5 Deployment Report Yet to Start
and product given for
Code movement.
smoke testing.
7 Documentation 1 User Manual, Final Yet to Start
Dissertation Report.

41

Sensitivity: Internal & Restricted


5.3 Work Accomplished

In the past 8 weeks, various kinds of activities have been carried out. They are:
Detailed study of the existing process, gathering and analyzing the business requirements
have been carried out.
Analysis of HPOO tool and understood the basic concepts of tool.
Learnt integration concepts over web technology
Functional Requirement specification had been prepared

5.4 Way Ahead

Going forward, below are the activities taken care of as part of dissertation work.

 Complete coding and unit testing for all the requirements


 Prepare Unit Test cases
 Prepare System Test cases
 Integrate the application
 System Testing
 Analyzing the Result

 Final Report

42

Sensitivity: Internal & Restricted


Chapter

6
BIBLIOGRAPHY

This chapter contains the following topics:

Bibliography
Referred Links:

1. http://www.evergreensys.com/hp-operations-orchestration-case-study
2. http://helpfiles.intactcloud.com/OO/10.20/online-
help/Content/HelpCenter_Expert.htm

Referred Books:

3. Book: Software Engineering: A Practitioner's Approach (Roger S.


Pressman) McGraw-Hill Science/Engineering/Math; 4th edition.
4. Software Testing: A Craftsman’s Approach, 2nd Edition, Paul C
Jorgenson, CRC Press

43

Sensitivity: Internal & Restricted


------------------------------ THANK YOU ------------------------------------------

44

Sensitivity: Internal & Restricted