Bachelor Degree Project Internal Dashboard

(1)

Author: Michael Wagnberg Author: Peter Danielsson Supervisor:Diego Perez Semester:VT 2018

Subject:Computer Science

(2)

Abstract

(3)

Preface

(4)

List of Figures

3.1 Screen shot from Sigma how the dashboard can look like . . . 5

3.2 The Dashboard Layout . . . 6

3.3 The Dashboard when a server is down . . . 7

4.1 Rate limit - API requests per hour. [1]. . . 9

4.2 Ticket Attributes, Freshdesk API [1]. . . 10

4.3 Company Attributes, Freshdesk API [1]. . . 11

4.4 Ticket Properties, Freshdesk API [1]. . . 11

4.5 Ticket Filter, Freshdesk API [1]. . . 12

4.6 Models for raw data . . . 13

4.7 Domain Specific Model in draw.io . . . 16

4.8 Selection models . . . 17

5.1 Solution Architecture . . . 18

5.2 Configuration file example . . . 18

5.3 Flowchart overview, Data collection/processing routine . . . 19

5.4 Flowchart overview, Freshdesk ticket processing . . . 20

5.5 Flowchart overview, URL Monitor . . . 21

5.6 Main dashboard view . . . 22

5.7 Domain Specific Model in EMF . . . 23

5.8 Domain Specific Model in graphics . . . 24

5.9 The DSMs in Go 1/2 . . . 25

5.10 The DSMs in Go 2/2 . . . 26

5.11 User interface for individual dashboard . . . 26

5.12 User interface for individual dashboard . . . 27

6.1 Dashboard Application . . . 28

(7)

List of Tables

1.1 Table containing the objectives . . . 2

3.2 Functional Requirements . . . 4

3.3 Non-functional Requirements . . . 4

(8)

1 Introduction

This is a 15 HEC bachelor degree report about creating a Dashboard for the company Sigma IT Consulting that informs about the support tickets of their clients.

Sigma IT Consulting delivers services to a large amount of customers. Support is often in-cluded in these service agreements. Today, support tickets created by their customers are regis-tered and listed in an unprioritized fashion within Freshdesk, an online support ticket service[2]. Today Sigma uses the dashboard that is included within Freshdesk to obtain statistics. To get up-dated about the current ticket status each employee must manually login to the ticket system, as there are no event-notifications in real-time.

Furthermore, there are no current monitoring system in place that is able to regularly gather infor-mation concerning health of services. For example, if a server/service goes down, the employees will first notice the problem when trying to access the server/service, or when a customer creates a support ticket.

There is a commercial product called Klipfolio which is an online service where you can create and customize your own dashboards. It supports 100+ services and Freshdesk is one of them [3]. However, Klipfolio is not a free service - in order to use it with Freshdesk you will need to pay a monthly subscription fee. This subscription fee is based on the amount of users that needs access to the Dashboard. Although Klipfolio might be an already existing solution to Sigma’s problems, Sigma considers the extra cost to be a drawback.

1.1 Problem Formulation

The end users want to have an information system, in this case a dashboard, that can collect and organize relevant data from arbitrary services. This dashboard should be flexible in that sense that end users can easily add and remove services.

Therefore, the problem is separated into the sub-problems of

a) Identify and implement appropriate models for the collected data and appropriate models for the information that users want to obtain.

b) Connect data collectors to models and models to Dashboard and implement client-side of the Dashboard

c) Implement model to model transformations

1.2 Motivation

(9)

1.3 Objectives

O1 Implement Domain Specific Languages to support the generation of information that will be shown in the dashboard

O2 Create a Dashboard that provides information about services O3 Analyze the input data to generate the expected output

informa-tion

O4 Implement the automatic generation of models from input data and the representation of output information in the Dashboard

Table 1.1: Table containing the objectives

1.4 Scope/Limitation

We need to know how to get the data from Freshdesk and what kind of data we receive, therefore we need to investigate data from Freshdesk. Further on we need to create domain specific data models of the desired result data we want to display in our Dashboard. We also need to create data models that are derived from the raw source data. These source data models will then be used in a transformation process to populate the previous mentioned result data models. We are going to use Eclipse Modeling Framework (EMF) to design the domain specific models.

These domain specific models will then be used when we are implementing the Dashboard appli-cation, using a programming language that will be decided along the way.

We choose to create the dashboard from scratch by ourselves. The reason for this is because al-ready existing commercial products costs money but Sigma wanted a software solution that was free of charge.

1.5 Modified time plan

The requirements for the Dashboard were not handed to us beforehand. Therefore, we needed a clear set of requirements. We collaborated with Sigma to come up with initial sketches and draft requirements of the Dashboard. Based on these results, we followed a requirements engineering process to establish a list of requirements. Since this process was a bit time consuming we had a slightly modified time plan. However, we managed to achieve the target on time without any problems.

1.6 Target Group

We are creating this dashboard at Sigmas office, so the staff would be the strongest target group. Another target group that might be interested in this project are companies/organizations that are interested in developing their own Dashboard application for monitoring Freshdesk and/or other arbitrary services.

1.7 Outline

(10)

2 Method

Here follows a list of the methods that have been used to achieve the objectives along with a detailed description.

2.1 Case Study

To get a deeper understanding of the problem in terms of the information streams for services used by Sigma and the requirements of the dashboard application, a case study is an effective method to achieve this.

2.2 Verification and Validation

After the case study has been done there is also a need to regularly check that the data models and the dashboard application are complying with the requirements. For this purpose we will utilize Verification and Validation. For the verification phase we will test the Dashboard ourselves to make sure the requirements are fulfilled. In the validation phase we will first demonstrate a prototype of the Dashboard for Sigma, to receive feedback and making sure we are building the right product. Sigma will also later test the finished application to validate that all requirements have been fulfilled.

2.3 Method description

We will start by having a case study at Sigma. This case study will be in the form of personal meetings with a representative from Sigma who will demonstrate the services they want to mon-itor within the dashboard application. The case study will also go over requirements in terms of functionality, performance and look-and-feel. After the initial case study at Sigma, we will use verification and validation as a means to make sure the project is staying in-line with the require-ments established in the case study or to solve any new issue that may arise. To achieve this, we will have regular contact with the same representative from Sigma, either by email or physical meetings.

2.4 Ethical Considerations

When working with a company’s support ticket system, like Freshdesk, you will often get access to sensitive information that might be considered a corporate secret. Sigma does not want us to develop the dashboard application using their existing support ticket system as test data. Therefore we will create a trial Freshdesk account and develop the Dashboard using our own data.

(11)

3 Requirements

Since we are doing this thesis for a company we need a list of requirements so we know what we are going to develop. These requirements were not written down beforehand by Sigma, therefore achieving this list of requirements became a requirements engineering process to us. During the development of the thesis plan the requirements were not included in the project plan because we thought that they were already established. However, as soon as we realized that there were some understanding gaps we added the list of requirements to the work plan. Appendix C contains memo notes from our meetings with a representative from Sigma where we discussed the requirements.

In the requirements, a user is considered an employee of the company with both user/admin privileges within the dashboard. Therefore, we have not made any distinction between a user and an admin in this document.

3.1 Functional Requirements

FR1

User should be able to see a summary of all customers support tickets. Each summary should contain the following information: Unresolved: How many tickets that are unresolved

Overdue: How many tickets has overdue the deadline Due today: How many tickets that has its due today Open: How many tickets that are open

On hold: How many tickets that are on hold Unassigned: How many tickets that are unassigned

FR2 User should be able to see a summary of a specific customers support tickets.

FR3 User should be able to add/remove a customer summary to the dashboard through a configuration file.

FR4 User should be able to access the dashboard through a web-browser with a specific URL.

FR5 User should be able to see a summary of the monitored services’ health (OK/FAIL)

FR6 User should be able to see a summary of the monitored URLs for a specific customer (OK/FAIL)

Table 3.2: Functional Requirements

3.2 Non-functional Requirements 3.2.1 General Requirements

NFR1 The Dashboard application should be designed in such a way that makes it possible to extend it with new integrated information sources.

(12)

3.2.2 Performance and Interface Requirements

NFR2 The process of updating the summary/summaries should take place in a “reasonable” time interval, for example every 30 sec-onds.

NFR3 The dashboard should be responsive; You should be able to use the dashboard from screens of different sizes, for example big screen TVs and mobile devices.

Table 3.4: Performance and Interface Requirements

3.2.3 Hardware Requirements 1gb RAM

1gb free storage

3.2.4 Software Requirements

Should be able to run on Linux, Windows and Mac.

3.3 GUI Design Prototype

We had some discussions with Sigma regarding how the dashboard should be designed. Our con-tact person at Sigma later responded with a screen shot (Fig. 3.1 below) showing their dashboard within Freshdesk. The statistics in the figure have been blurred on purpose.

(13)

We then replied with the next two sketches, see Fig. 3.2 and Fig. 3.3 below. In our sketches, the first section (“All customers”) is a summary of all the customers. All other sections, in this case “Customer 1” and “Customer 2” are customer specific statistics. In each section, there is a row for every service. In our case, we have a row for Freshdesk statistics and the second row is for the URL monitoring service. The contact person then responded saying that our sketches were accepted and that we may proceed with the project.

(14)

(15)

4 Investigation and Design of the solution

This section describes how we investigate the data that we are going to create models for.

4.1 Understanding data collection mechanism for our Dashboard application Here we discuss our different alternative approaches for collecting the necessary data needed for the dashboard application and the reasoning behind our choice.

4.1.1 Passive, Real-time feedback with webhooks

The dashboard could be setup with a form of “real-time” information gathering using a publisher and subscriber pattern, for example Webhooks. However, this requires that the dashboard appli-cation is reachable from the internet. This means that there would be a need for a security layer (for example an authentication mechanism) as the information collected by the Dashboard might be considered a corporate secret and not meant to be shared with the outside world. This approach might be considered optimal in terms of real-time performance, but also adds complexity to the dashboard application.

4.1.2 Active data polling from the services

An alternative approach is to have a dashboard application that can poll the different monitored services for the needed data on a regular basis. With this approach, the dashboard application can be placed within a company’s internal network, only needing an internet connection. Then the dashboard application would not be accessible from the outside and the need for authentication would not be as strong as for the previous mentioned alternative.

4.1.3 Choice of data collection mechanism

After discussions with Sigma, it became clear that they did not want an application that was accessible from the outside world, neither did they have a need for user authentication. Therefore, active data polling was considered the most appropriate method of collecting data.

4.2 Understanding the Freshdesk data

Freshdesk is a support ticket system that Sigma uses for handling support cases with their cus-tomers. A support ticket can be created either by a customer or an employee at Sigma. As of today, to get updated on the current status of support tickets, an employee must manually login to Freshdesk’s own dashboard application. This dashboard shows the total number of unresolved, overdue, due today, open, on hold and unassigned tickets, along with further statistics.

Freshdesk also offers additional functionality, but as we are only interested in collecting some ba-sic ticket statistics the report will focus on this.

Freshdesk has an API [1] that can be used both for creating and retrieving data. In our case, we are only interested in collecting data that can be processed and displayed on our own Dashboard. Since we are interested in collecting data for a total summary, similar to the standard dashboard within Freshdesk, and per-customer summaries, an ideal situation would be to use custom API-calls and filter only the relevant data to minimize the data processing on our end. For example, having a request that asks for the total number of unresolved tickets, another api-request asking for the total number of overdue tickets and so on.

However, at the time of writing this report, Freshdesk’s API does not support such advanced queries that would be needed for this ideal situation.

(16)

Figure 4.1: Rate limit - API requests per hour. [1].

possible and rather making extra processing on our end.

Ticket-objects from Freshdesk’s API consist of multitude of attributes, see Fig. 4.2 below. Since we are interested in calculating statistics in terms of unresolved tickets, there are only a few fields that are of interest in our case. These are company_id, due_by, group_id, responder_id and status. Although they are not essential data for calculating statistics, we also choose to include the attributes name and subject in order to have the ability to later extend the dashboard with notifications. An interesting note regarding the Ticket attributes is that the attribute company_id is a number generated by Freshdesk. In Freshdesk, customers are given names, so there is a need to have a translation between company ID and the actual company name in Freshdesk, in order to know which customer a ticket belongs to. Therefore, we need an additional query, asking for a list of ALL companies from Freshdesk. Appendix B details the format in which these raw data are received. As depicted in Fig. 4.3, a company object holds both the relevant data we need, in our case the ID and name. By saving this information, we have the ability to filter a ticket on our end based on a company name.

With the help of the status code, we can determine if a ticket is considered unresolved or not, see Fig. 4.4 below.

(17)

(18)

Figure 4.3: Company Attributes, Freshdesk API [1].

(19)

(20)

To summarize; in order to get the relevant data we need from Freshdesk, we need to: 1. Retrieve input.

(a) Request a list of ALL companies (b) Request a list of ALL unresolved tickets

2. Process the retrieved data to produce the expected output.

A data model for the raw data from Freshdesk can be seen in Fig. 4.6 below.

Raw Data Models

Ticket (json) attachments : array of objects cc_emails : array of strings company_id : number custom_ﬁelds : dictionary deleted : boolean description : string description_text : string due_by : datetime email : string email_conﬁg_id : number facebook_id : string fr_due_by : datetime fr_escalated : boolean fwd_emails : array of strings group_id : number id : number is_escalated : boolean name : string phone : string priority : number product_id : number

reply_cc_emails : array of strings requester_id : number responder_id : number source : number spam : boolean status : number subject : string tags : array of strings to_emails : array of strings twitter_id : string type : string created_at : datetime updated_at : datetime Companies (json) custom_ﬁelds : dictionary description : string domains : array id : number name : string note : string created_at : datetime updated_at : datetime

All unresolved tickets Total : int

Results : [ ] json (Tickets) Freshdesk API Conﬁg apikey : String showtotal : boolean customers : [ ] object name : String freshdesk : object fdname : String urlmon : object urls : [ ] String Local Files

(21)

4.3 Understanding the data related to monitoring a service

Sigma hosts different kinds of services to their customers. As of today, there are no monitor sys-tem in place that check the health of these different kinds of services, they have to do it manually. A type of service they would like to monitor is web-pages/web applications that they host for their customers. The monitor should be based on URLs to these web-pages/web applications. They would like to graphically see in the Dashboard, the status of monitored web-pages/web applica-tions as a second row for both the Total and per-customer section. The desired statuses that a service can have in the dashboard are either OK if the service is available, and FAIL if a service is not available. The Total section in the Dashboard should show OK if all monitored services are available, and FAIL if any of the monitored services has become unavailable. In the Customer section in the Dashboard, the status should be OK if all the services belonging to a specific cus-tomer are available. If any of the cuscus-tomer’s monitored services are unavailable, the status should be FAIL along with the URL to the failing service. One solution could be to use a third-party service like Uptimerobot [5] for the monitoring part, and querying its API for the results and then transforming the data into the desired output in the Dashboard.

However, after discussions with Sigma, it became clear that a trivial test, like a a simple HTTP GET-request and checking its corresponding response, was a sufficient way of monitoring a ser-vice. We then decided to implement the monitoring functionality ourselves, as a third-party ap-plication in this case would add complexity to the dashboard. The monitor will simply send an HTTP HEAD-request to the specified URL. If the status code in the corresponding reply is not 200 (Status OK), we will consider the web-page as down. If a reply is not received within a certain time-limit (in our case 5 seconds) the web-page will also be considered down.

To summarize; in order to get the relevant data from a monitored service we would: 1. Send an HTTP HEAD-request to the specific URL

2. Check the status code of the corresponding reply.

3. If status code is not 200 (Status OK) or reply not within time-limit, the web-page will be considered down.

4.4 Designing the Domain Specific Models

A data model consist of what data an application or project should contain. In our case the data models consist of data from Freshdesk and data in terms of URLs that are going to be monitored. A model often consists of attributes and its entity types. The attributes within the models should be named as realistic and describable as possible. For example, if an attribute holds the name of a book, the name of the attribute should be something like book_name. The entity type should be clear just to see the name of the attribute. The book_name’s entity type should be a String. Furthermore the attribute book_ISBN should have an entity type of number/integer or similar [6].

4.4.1 Freshdesk models

(22)

fields of information: one for the company name and the other being a field of type FdSummary. Now we have DSMs for all the relevant Freshdesk-data we want to display later in our Dashboard.

4.4.2 URL-monitoring service models

For the URL-monitoring service, we need to keep track on the status (up or down) for each URL. This model is named umUrls and has two fields: The first field being the status which is of boolean type. If the URL is considered up, this field has the value of true, and false otherwise. The second field is the URL, which is of type string. Since a customer can have many URLs that need to be monitored, we need a model for storing several objects of type umUrls. For this purpose, we have a DSM named UrlMon that has two fields. The first field being the overall-status of type boolean and the second field being a list of objects of type umUrls. The overall-status will be set to true if all customer URLs are considered up, and will be false otherwise. The overall-status is a derived attribute. It might be considered redundant, but we choose to have it as a way to fast determine if any URLs are down, which can be helpful later when creating the Dashboard view.

4.4.3 Other models

To utilize the previous mentioned models, we need to attach them to two different kinds of ob-jects: One that holds information for each customer and one for the total statistics. Starting with the Customer information, we have a DSM named Customer. This model will have a field for the Company name and fields for each service we are monitoring. In our case the Customer model will have 2 additional fields. One of type FreshDesk and one for UrlMon. With this approach you can simply add new fields for the additional monitored services one could wish in the Dash-board application. The field holding the Company name is the name that will be displayed in the Dashboard view.

(23)

Total freshdesk : FdSummary urlMon : UrlMon Domain Speciﬁc Models

FdSummary unresolved : int overdue : int dueToday : int open : int onHold : int unassigned : int Freshdesk FreshDesk companyName : String summary : FdSummary Customer name : String freshDesk : FreshDesk urlMon : UrlMon Monitoring system UrlMon overall : boolean umUrls : UmUrl [ ] UmUrl url : String up : boolean

(24)

4.5 Selection models

To select the relevant raw data from Freshdesk and the monitored URLs from the configuration file, we need to create selection models. These selection models will contain only the relevant attributes that are needed for processing and generating output.

In the Ticket-model we will store some selected data from the raw data model. These data are used to derive the information we need to display in the Dashboard. Although the name of the ticket as well as the ticket content (subject) are not needed, we store them for extensibility purposes. An example of a use case could be to display notifications when new tickets are received.

To know how many tickets that are Overdue and Due Today we need to do some calculations with the attribute due_by that comes from the raw data. These calculations will be shown later in this report.

We are using two different API calls when running the application. The first API call will get all the companies, which the model Company will store.

The second API will get all the unresolved tickets and will run approximately every 30 seconds. TicketResultcontains a list of the model Ticket, and an integer that is representing the total amount of unresolved tickets.

UrlMonwill be used for storing all monitored URLs belonging to a customer. This information is parsed from the configuration file.

Selection Models Company Id : json:"id" Name : json:"name" Ticket Name : json:"name" CompanyId : json:"company_id" Subject : json:"subject" ResponderId : json:"responder_id" GroupId : json:"group_id" Status : json:"status" DueBy : json:"due_by" TicketResult

Result : json:"results" ( [ ]Ticket ) Total : json:"total"

UrlMon

Urlmon : json:"urlmon" ( [ ] String)

(25)

5 Implementation

Here follows the actual software implementation of the data models and the dashboard application.

5.1 Solutions Architecture Data Gathering Freshdesk API 1. Query API 2. API Response URL 1. HEAD-Request 2. HEAD-Response Data Processing Reﬁned result Data Dashboard Application Customer Data Conﬁg File GUI

Speciﬁc end user Custom View

Total View

Developer Monitored services

End users

Figure 5.1: Solution Architecture

The application initializes by reading the contents in the local configuration file. This configu-ration file holds information such as the key to Freshdesk’s API, the domain being used within Freshdesk, and all the customers that should be monitored along with their specific customer in-formation. Fig. 5.2 shows a portion of this configuration file. In this figure, we can see that the first customer is named Company A and will be the name displayed in the Dashboard. In Freshdesk, this customer is named company1. Company A has two URLs that needs to be monitored, in this case http://www.sunet.se and http://www.svt.se. For each customer specified in the configuration file, a customer-object is created with its related data, using the models described later in this chap-ter. After the config-file has been processed, the application will ask Freshdesk’s API for a list of

{

"fdAPI": "4csgRrc37qkDrzD6uSHV",

"fdDomain": "sigmaTest",

"customers": [{

"name": "Company A",

"freshdesk": "company1",

"urlmon": ["http://www.sunet.se", "http://www.svt.se"] },

{

"name": "Company B",

"freshdesk": "company2",

"urlmon": ["http://www.aftonbladet.se", "http://www.expressen.se"] }]

}

(26)

all companies that exist in the specific Freshdesk-domain. This data is only asked once in the beginning of the execution. The retrieved data is then processed; the id-to-company and company-to-id relations are stored in two map structures. This information will later be used for processing the freshdesk tickets, making sure we are only processing the tickets for the customers that exists in the configuration file. After the company list has been processed, data collection and processing for Freshdesk and URL-monitor statistics will run approximately every 30 seconds (concurrently). The first thing that happen in this data collection/processing routine, is that an API-request is sent asking Freshdesk for all unresolved tickets. When all unresolved tickets have been received, the data is hashed and compared with the previous cycle, to see whether there is a necessity to update the dashboard models. If so, the downloaded ticket-data will be processed. After Freshdesk statis-tics have been calculated, the URLs for each customer are checked and all the results are saved to the corresponding customer objects. A flowchart of the data collection/processing routine is illustrated in Fig. 5.3 below.

FreshDesk API Request: List All Companies

Fresdesk API Request: List All Unresolved

Tickets

Process data, update customer statistics

Check URLs for each customer, update customer statistics No new data Wait 30 seconds New data

Figure 5.3: Flowchart overview, Data collection/processing routine

As mentioned in Section 4.2, the ticket-objects will have a company id associated to it, rather than a company name. So for each ticket, we resolve the company-name using our map-structures we mentioned before, to check whether it belongs to one of the customers specified in the configura-tion file. If so, it will be processed and the customer’s statistics will be updated.

(27)

Save current time

Clear Freshdesk statistics for each Customer Object and

Total

Next ticket in list

Resolve company name from ticket attribute 'company_id'

Irrelevant ticket Increase Unresolved

counter for customer and Total

Ticket assigned to

group or person

Status other than 'On hold' or 'Waiting

for third party' Increase Unassigned counter for customer

and Total

Status 'Onhold' or 'Wating for

third party'

Increase Open counter for customer

and Total

Compare ticket attribute 'due_bye' against saved time

due_by earlier than saved time Status 'On hold' Increase Overdue counter for customer and Total Status

'Open'

Status other

than 'Open' Status

other than 'On hold'

due_by later than saved time Status

other than 'On hold' Increase 'Due today' counter for customer

and Total

Increase 'On Hold' counter for customer

and Total Status 'On hold' Ticket Unassigned

Status other than 'Pending or Waiting customer' Relevant ticket due_bye date same as saved (today) due_bye date other than saved

Status 'Pending'

or 'Waiting customer' More tickets to process

No more tickets

(28)

Fig. 5.5 below illustrates an overview of the URL Monitor processing.

Pick next Customer in List

Pick next URL in Customer object Send HTTP HEAD-request to URL More URLs to process URL Down URL Up

Update statistics for customer and Total Response Status Code is 200 No more URLs No HTTP Response HTTP Response

Code Other than 200 No more customers to process More customers to process HTTP Response within time limit

(29)

The Dashboard GUI is accessed through a webpage with port 8080. An end-user with network connectivity to the Dashboard can simply navigate to the Dashboard using his/her web-browser. Fig. 5.6 illustrates an example of the main Dashboard view, when only the ip-address and port have been specified. The Dashboard view is refreshed using a page reload every 30 seconds, with the help of a javascript. The Dashboard view is generated using templates, see Appendix D for code examples.

(30)

5.2 Models in EMF

We choose to create the models using the Eclipse Modeling Framework (EMF) since it is a well known tool for creating domain specific models. Fig. 5.7 illustrates the models in classes along with their relations.

(31)

In the next figure, Fig. 5.8, we show the DSM graphically where the dependencies between the classes are seen more clearly.

Totaland Customer have basically the same properties, but Total has not the name property since it should show total numbers for all the customers within the configuration file. The FreshDesk model contains the name of the company and that company’s freshdesk summary. The UmUrl model contains a field for a URL that is of type String, and a boolean for the URL’s availability status. The boolean field will be set to true if the URL is available and false otherwise. The UrlMonhas an array of type UmUrl, as a customer can have several URL addresses that needs to be monitored. It also has a field of type boolean that represents the overall status of the array of UmUrls; if all URLs are available, this boolean will be set to true, otherwise false. Lastly the model FdSummaryhas all the statistics from Freshdesk that needs to be displayed on the dashboard.

Figure 5.8: Domain Specific Model in graphics

5.3 Choice of Language

(32)

picked Go because we think it has a rich standard library, has easy management for concurrency, is well-suited for web applications and has good performance as it compiles to native machine code. Go has types, structs and methods that allows for object-oriented style programming, although it does not have classes or type hierarchy like Java [7]. As a consequence of picking Go rather than Java, our data models created in EMF will not be used to generate code, they will rather serve as blueprints when we are implementing similar models in Go.

5.4 Data models in Go

Fig. 5.9 and Fig. 5.10 illustrates how the implementation of models looks in Go language.

package models

type Total struct {

FreshDesk FdSummary

UrlMon UrlMon

}

type Customer struct {

Name string

FreshDesk FreshDesk

UrlMon UrlMon

}

type FreshDesk struct {

CompanyName string

Summary FdSummary

}

type FdSummary struct {

Unresolved int Overdue int DueToday int Open int OnHold int Unassigned int }

type UrlMon struct {

Overall bool

UmUrls []UmUrl

}

(33)

package models

type UmUrl struct {

Url string

Up bool

}

Figure 5.10: The DSMs in Go 2/2

5.5 Custom end-user view extension

In the problem formulation, in Section 1.1, we stated: "This dashboard should be flexible in that sense that end users can easily add and remove services". When we were collaborating with Sigma to create the Dashboard, the end-users in this case were their staff. Since the staff are developers, they feel comfortable handling code and modifying configuration files and we agreed that the flexibility of adding/removing services should come in a form of a prepared code-base, making it easy for them to further develop the dashboard themselves. We later realized that this approach might not fully comply with the problem formulation. We needed a use case where this flexibility was available for end-users that were not developers. As a way to experiment with this, we added support for creating custom dashboard views for different users. The custom end-user dashboard is accessible by going to /end-user/<end-username>. To edit the custom dashboard view, an end-user would go to /user/<username>/config and select which customers from the configuration file to display on it’s personal dashboard. Fig. 5.11 illustrates an example with a user called micke. The view settings for each end-user are stored as a list of the customer names. When an end-user

Figure 5.11: User interface for individual dashboard

(34)

End user

localhost:8080/user/bob

1. Request personal dashboard

: User settings

alt [ user exist ]

: Customer objects

[ else ]

1.7 : Generate view using templates and customer data 2. Serve customized dashboard

1.1 : Request customer names

1.5 : Request all customer objects 1.2 : Customer names

1.3 : Request customer objects based on end user settings 1.4 : Customer objects

1.6 : Customer objects

(35)

6 Results

This project creates a dashboard application that nicely shows support ticket statistics for Sigma IT Consulting, with regularly updates.

The first part of the solution developed in this project has been the server-side. This part contains • Reading data from a configuration file

• Retrieving status data from monitored URLs • Retrieving raw data from Freshdesk API • Creating input data model

• Elaboration on the input data to generate the information of interest in the Dashboard • Creating an output model with the elaborated data

The second part of the solution developed in this project has been the creation of the client dash-board application. We programmed the dashdash-board in Go, in Fig. 5.3 you can read why we choose Go as our programming language. In section 5 we described the process regarding the implemen-tation. We met up with Sigma and showed our dashboard application, and they where satisfied with the result.

Below are some screen shots on the dashboard, the customer and the data that is represented are synthesized by us because Sigma did not want us to test the Dashboard on their data for confiden-tiality reasons.

Figure 6.1: Dashboard Application

The first row of the Total represent the total amount of unresolved, overdue, due today, open, on hold and unassigned tickets from all the customers within the configuration file. The second row shows the availability status of all the customer URLs. The remaining rows have the same infor-mation as the total but for each customer.

(36)

layout modification doable since we, in our working plan, already anticipated these possible mod-ifications and allocated some time for them.

The layout modification concerned making the information in the total section stand out more; The Freshdesk statistics should have a greater font size and be encapsulated in colored boxes. The colors of the boxes should indicate the severity of the ticket statistics. For example, for a certain severity, the color of the boxes should be orange and an even higher severity should color the boxes red. Appendix A shows the result of the modification.

Fig. 6.2 illustrates the Dashboard when some of the monitored URLs are unavailable.

(37)

7 Discussion

The aim of this software development process was to create a dashboard application and relevant data models for a company that had a need to monitor specific services. Therefore, this project has been driven by a real industrial case study. By first doing a prototype in paper at the company we could get a clear picture of the needed functionalities. During the prototyping, requirements were established. The requirements described the kind of data the company wanted to be displayed on the dashboard. These data played a crucial role when designing the domain specific models. When the domain specific models were in place, we could start experimenting with the actual services that we were required to monitor. The ticket monitor system (Freshdesk) offered a trial version that we could use to examine the API’s requests and responses. For the URL-monitor we could simply try out arbitrary URLs.

Through the experimentation-process we designed our selection-models in order to transform the raw data into the desired results to show in the client Dashboard according to the domain specific models. When the selection-models were established and the data could be retrieved and pro-cessed automatically, the last part was to use the domain-specific models to display the data on a GUI. When the GUI was set up and successfully displaying information using the models, Sigma considered the Dashboard application, along with its relevant data models, complete.

(38)

8 Conclusion

Sigma had a problem that forced the staff to manually log in to their support ticket system, Freshdesk, to see the ticket statistics. With our dashboard application solution the staff of Sigma can now see an overview of all the unresolved support tickets and the health of the web sites that are connected to each customer at a single glance. The result has no relevance to science, but for industry (specific for Sigma) that have Freshdesk as their support ticket system the result has relevance. Our solution can be applied for companies having the same monitoring needs. More-over, we have had the opportunity to learn a new programming language, Go. This language is well-suited for web-applications and has good performance as it compiles to native machine code. In the future, Sigma may want to extend the amount of services supported by the Dashboard. For example, Sigma has another third party system that handles the development process which could be an potential extension. We have done preparations in the code and within the configura-tion file to make this process easier. In order to extend the dashboard with addiconfigura-tional services, one needs to:

1. Create models for the new service.

2. Add the API (or similar) and/or other credentials regarding the new service to the configu-ration file and also add support for parsing this information.

3. Add support for the new service in the data gathering/process routine. 4. Add support for the new service in the html templates.

(39)

References

[1] Freshdesk, “Freshdesk API,” https://developers.freshdesk.com/api/, 2018, Online; accessed 23 May 2018.

[2] ——, “Freshdesk’s web site,” https://freshdesk.com/, 2018, Online; accessed 20 May 2018. [3] Klipfolio, “Klipfolio’s web site,” https://app.klipfolio.com/company/buyNow, 2018, Online;

accessed 15 April 2018.

[4] Martijn Iseger, “Domain-specific modeling for generative

soft-ware development,” https://www.developerfusion.com/article/84844/ domainspecific-modeling-for-generative-software-development/, 2010, Online; accessed 21 April 2018.

[5] UptimeRobot, “UptimeRobot,” https://uptimerobot.com, 2018, Online; accessed 23 May 2018.

[6] Matthew West, “Developing high Quality Data Models,” https://sites.google.com/site/ drmatthewwest/publications/princ03.pdf?attredirects=0, 1996, Online; accessed 1 May 2018. [7] The Go Programming Language, “Is Go an object-oriented language?” https://golang.org/

(40)

A

Appendix A

Here are some screen shots showing how the raw data is received when we print it out in the console.

Figure 1.1: Raw data from Freshdesk displayed in the console 1

Figure 1.2: Raw data from Freshdesk displayed in the console 2

(41)

The screen shot below shows the raw data when getting all the companies from Freshdesk printed out in the console

(42)

B

Appendix B

As mention in Section 6, Sigma wanted the boxes in the Total Section colored based on the amount of, for example, unresolved tickets. Down below we show two screen shots where we are setting a warning flag to 2 and a critical flag to 3, just to exemplify the feature.

Figure 2.1: Dashboard application when warning

(43)

C

Appendix C

Under the work process we have had some meetings with Sigma, the table below contains key points from these meetings.

Date Comment

2018-03-06

Seminar peer-review Monitor/Config files

Specify URLs to monitor along with customer-name. This data can then be parsed and put into a model for monitoring pur-poses. Maybe the config-file should be specified in JSON-format? Database instead of a text file?

Web-Client

How should the information be updated? Should it be a static webpage that get updated? Or a web-client that requests the data from the server and dynamically updates the information on the webpage?

2018-03-07

Meeting with Sigma regarding Requirements document, Martin Tiinus

Key points:

• Services should work as modules; You should be able to extend the Dashboard with more services and put the extra information needed in the config-file for customers. There-fore, we should have some kind of Object-format for each customer. JSON is ok.

• Change “real-time” in requirements document to some-thing tangible, for example in seconds.

• Dashboard should be responsive and usable on different de-vices, like smartphones, TVs and desktop computers. • Ticket system is primary objective. If time allows, pick

some way of monitoring web-services. Cheapest is a high priority. We can pick the monitoring system ourselves. Jira is also an option, with lowest priority.

• Layout: For each Customer, each service should have it’s own row of relevant information that is grouped together.

2018-04-05

Working from Sigma Office, Meeting with Martin Thiinus Questions:

(44)

• Not that important regarding the update time, for example 30 seconds is considered ok.

• A “mechanical” periodic refresh on the dashboard-page is totally fine as a solution, it doesn’t have to be more compli-cated than that.

• Have all the “boxes” (properties from freshdesk) in differ-ent colors, maybe Due today in yellow and Overdue in red since due today is quite important and overdue is urgent. Maybe the boxes becomes more yellow or red when the amount of unresolved or due today reaches a maximum amount of tickets. This because it should be easy to spot “alerts” from a distance. This might be harder if only the text is colored.

• Make the total section stand out more than the section for each customer. For example, divide the rows into several boxes with a larger font size and colored boxes.

• Maybe use framework to get nicer looking Dashboard, for example Bootstrap 4 or Zurb Foundation

• As the information in Sigma’s freshdesk-system might be considered sensitive, a way of testing the dashboard could be to hand over the compiled application to Sigma and let Martin test himself.

• All in all, Martin was satisfied with the functionality and the application itself, but the design of the dashboard could be improved.

(45)

D

Appendix D

Here follows some screen shots of the HTML-templates we have used in Go to generate the Dash-board views using the Domain Specific Models.

Figure 4.1: HTML-template, Main dashboard view

(46)

(47)

Bachelor Degree Project Internal Dashboard

Contents

List of Figures

List of Tables

1

Introduction

2

Method

3

Requirements

4

Investigation and Design of the solution

5

Implementation

6

Results

7

Discussion

8

Conclusion

References

A

Appendix A

B

Appendix B

C

Appendix C

D

Appendix D