Tekniskt lyft av PaperLine
Uppgradering av klient till Single Page Application i ett Manufacturing Execution System.
Technical lift of PaperLine
Upgrading of client to Single page Application in a Manufacturing Execution System.
Filip Skogum
Alexander Bennetoft
Fakulteten för Hälsa, Natur och Teknikvetenskap Datavetenskap
C-Uppsats 15hp
Handledare, Katarina Asplund Examinator, Thijs J. Holleboom 18 jan -17
Abstract
This dissertation summarizes a project mission done at the requestor and company ÅF, Karlstad. The project was to investigate the possibilities of upgrading parts of the system named PaperLines which has outdated software. The system is used today at a paper mill for tracking production and ease administrative work.
AMP, a SPA-platform for MES developed by ÅF, was used in the project to create a proof-of- concept client with modernized user interface, support for odd screen resolutions and smarter communication logics. Additionally, it was supposed to be able to run in the old system, communicating with the server that was initially designed to work with the old client that used outdated software.
During the development problems concerning the interlinking of the old client and the new on a single computer and also cooperative communication between them on the same server got revealed.
The project is seen as successful. A new client with modern user interface has been
produced including support for mobile usage. The client could in a near future even get to be used in a live environment after evaluation made by ÅF.
Sammanfattning
Denna uppsats beskriver ett examensarbete utfört hos uppdragsgivaren och företaget ÅF i Karlstad. Arbetet gick ut på att undersöka i möjligheterna att uppgradera delar av systemet PaperLines utdaterade tekniker. Systemet används idag på pappersbruk för att spåra produktionen och underlätta administrativt arbete.
AMP, en SPA-plattform utvecklad av ÅF, användes i projektet för att utveckla ett proof-of- concept till det gamla systemet. Tekniker, ramverk och verktyg som ingår i plattformen är bland annat HTML5, TypeScript, Aurelia och Kendo UI.
Under utvecklingen uppdagades problem som att samköra en gammal och en ny klient på en och samma dator samt att få båda att kunna kommunicera med samma server. Dessa
utmaningar har trots allt uppnåtts.
Projektet ses som lyckat då en ny klient med modernt användargränssnitt tagits fram där bland annat stöd för mobil användning finns. Klienten kan även komma att användas i skarp miljö efter en validering gjorts av ÅF.
Förord
Vi vill tacka alla medarbetare på ÅF för sitt engagemang i projektet. Hjälpen vi fått av dem har varit ovärderlig. Speciellt stort tack till eldsjälen Mikael Arvidsson för det han gjort för oss. Mikael jobbar på samma avdelning vi suttit på denna termin och har ett betydande deltagande i utvecklingen av AMP som ÅF tagit fram. Vi vill även tacka Katarina Asplund, vår handledare på Universitetet, för hjälpen hon gett oss i att strukturera denna uppsats. Tack går även ut till Katarina Friberg och Richard Hellberg på ÅF handledare på ÅF för möjligheten vi fått att göra examensarbetet på ÅF samt er hjälp och stöd vi fått under tiden projektet gått.
Innehåll
Abstract ... 3
Sammanfattning ... 4
Förord ... 5
Figurförteckning ... 9
1 Introduktion ... 1
1.1 Uppdragsgivare - ÅF ... 1
1.2 Syfte och mål ... 1
1.3 Sammanfattning av projektet ... 2
1.4 Rapportens översikt ... 2
1.4.1 Bakgrund... 2
1.4.2 Design ... 2
1.4.3 Implementation ... 2
1.4.4 Resultat ... 3
1.4.5 Slutsats ... 3
2 Bakgrund ... 4
2.1 Översikt av projektet ... 4
2.1.1 Kravspecifikation ... 4
2.2 PaperLine ... 5
2.2.1 Arkpack ... 6
2.3 Gamla klienten – ASP.NET ... 7
2.3.1 Fördelar med Web Forms ... 8
2.3.2 Nackdelar med Web Forms ... 8
2.4 Nya klienten – AMP ... 9
2.4.1 Utvecklingsmiljö – Visual Studio ... 10
2.4.2 Programmeringsspråk ... 11
2.4.3 TFS (Team Foundation Server) ... 12
2.4.4 Bootstrap ... 12
2.4.5 Kendo UI ... 13
2.4.6 Aurelia.io ... 13
2.4.7 Gulp.js ... 13
2.5 Sammanfattning ... 14
3 Design ... 15
3.1 Översikt ... 15
3.1.1 Översikt över systemet ... 15
3.2 Uppgradering av Front End ... 17
3.2.1 Uppgradering av användargränssnitt ... 17
3.2.2 Uppgradering av komponenter ... 18
3.3 Uppgradering av Back End... 21
3.3.1 Före uppgraderingen ... 21
3.3.2 Efter uppgraderingen ... 24
3.4 Spegling av databas ... 27
3.5 Asynkron kommunikation ... 28
3.6 Sammanfattning ... 29
4 Implementation ... 30
4.1 Inledning ... 30
4.2 Implementation av grafiska komponenter ... 30
4.3 Dataflöde ... 32
4.4 NHibernate och databaskommunikation ... 36
4.5 Problem och val av lösningar... 38
4.6 Automatiskt genererade filer. ... 43
4.7 Sammanfattning ... 44
5 Resultat ... 45
5.1 Resultat av krav ... 45
5.1.1 Går projektet att genomföra? ... 46
5.1.2 Samkörning av gammal och ny klient ... 46
5.1.3 Sammanfogning av AMP och serverlagret ... 47
5.1.4 Användargränssnitt ... 47
5.1.5 Serverkommunikation ... 47
5.2 Prestandajämförelse av gamla och nya tekniken ... 48
5.2.1 Front end ... 48
5.2.2 Back end ... 48
5.3 Utvärdering av AMP teknikstack ... 49
5.4 Problem ... 50
5.5 Sammanfattning ... 51
6 Slutsats ... 52
6.1 Utvärdering av projektet ... 52
6.2 Vidareutveckling ... 52
6.3 Kundkontakt ... 53
6.4 Tidsåtgång ... 53
6.5 Slutord ... 54
Referenser ... 55
Figurförteckning
Figur 1: MES PaperLine. ... 6
Figur 2: Massa till Papper ... 6
Figur 3: Ett exempel på MVC-modellen. ... 7
Figur 4: Teknikstacken som användas i projektet AMP(Aurelia MES Platform) ... 9
Figur 5: MVVM-arkitekturen ramverket Aurelia följer ... 10
Figur 6: Kodexempel: Implementation av javascript ... 11
Figur 7: Kodexempel: Ett enkelt rutnät från biblioteket i Kendo UI. ... 13
Figur 8: Klassdiagram över systemet PaperLine... 16
Figur 9: Den gamla vyn i sin helhet ... 17
Figur 10: Den nya vyn i sin helhet ... 18
Figur 11: Rutnät från gamla vyn. ... 18
Figur 12: Rutnät uppritat av Kendo UI. ... 19
Figur 13: Hantering av gränssnitt utan Bootstrap. ... 20
Figur 14: Hantering av gränssnitt med Bootstrap. ... 20
Figur 15: .aspx klass .aspx.designer.cs klass och .aspx.cs klass ... 21
Figur 16: Dataflöde i det gamla systemet ... 23
Figur 17: Klassdiagram över gamla systemets fyra stora komponenter ... 24
Figur 18: Dataflöde i nya implementationen. ... 26
Figur 19: Klassdiagram över nya implementations fyra stora komponenter ... 27
Figur 20: Representation av Transferobjekt och Transferaggregat ... 28
Figur 21: Asynkron kommunikation i Typescript ... 29
Figur 22: Kodexempel: Implementation av Rutnät i både Web Form och Kendo UI ... 30
Figur 23: Kodexempel: Kendo Contextmenu ... 31
Figur 24: Kendo Contextmenu med ett menyobjekt ... 31
Figur 25: Kodexempel: Implementation av funktion i TypeScript-fil ... 33
Figur 26: Kodexempel: Implementation av function i proxyobjektet ... 33
Figur 27: Kodexempel: Implementation av Web-API ... 34
Figur 28: Kodexempel: Implementation av Response-objekt ... 34
Figur 29: Kodexempel: Implementation av Request-objekt ... 34
Figur 30: Kodexempel: Implementation av function i Serviceklass ... 35
Figur 31: Kodexempel: Anrop från klient till server ... 36
Figur 32: Kodexempel: Proxyfactor med uppsättning av TCP-förbindelser ... 37
Figur 33: Representation av Interface mellan klient och server ... 37
Figur 34: Kodexempel: Databasanrop från server ... 38
Figur 35: Kodexempel: Konfiguration av Mousetrap. ... 39
Figur 36: Kodexempel: Implementation av Mousetrap. ... 39
Figur 37: Web Forms representation av meddelanderuta. ... 39
Figur 38: Aurelias representation av meddelanderuta. ... 40
Figur 39: Utskriftsfunktion från Web Forms. ... 42
Figur 40: Utskriftsfunktion från Aurelia.IO och Kendo UI ... 43
1
1 Introduktion
Detta projekt går ut på att skaffa kunskap kring och påbörja utvecklingen av den nya webbaserade klienten till PaperLine, ett MES [1] (Manufacturing Execution System) som utvecklas och säljs av uppdragsgivaren; ÅF, till kunden som är ägare till ett pappersbruk i Sverige. Produkten används av kunden för att spåra produktionen i ett pappersbruk. Den gamla klienten är idag baserad på .NET Web Forms [2], se avsnitt 2.3, för att efter kundens önskemål efterlikna en skrivbordsklient. Dagens lösning har visat sig ha ineffektiv prestanda med ofta långa väntetider mellan anrop och operationer. Klienten är dessutom inte
anpassad för mobila enheter eller enheter med annorlunda bildförhållande. Därför har ÅF beslutat att pröva utvecklingen av en ny klient, baserad på dess egenutvecklade plattform.
Genom att utveckla klienten på den nya plattformen förenklas användandet på flera plan, till exempel kan truckföraren ha PaperLine på en surfplatta i hytten. Klienten kommer att bli mer responsiv och mobilanpassad samt bli mer prestandavänlig.
1.1 Uppdragsgivare - ÅF
ÅF [3] grundades 1895, då kallat Ångpanneföreningen. Föreningen gjorde initialt besiktningsuppdrag på ångpannor och har genom historien varit betydande inom
utvecklingen av ångkraft, elektricitet, kärnkraft och digitalisering. Idag är ÅF med cirka 8500 medarbetare i mer än 30 länder ett konsult- och ingenjörsföretag som skapar lösningar inom energi, industri och infrastruktur. Företaget har en nettoomsättning på ca 10 miljarder SEK per år och driver projekt i länder över hela världen. På Karlstadskontoret vid stadsparken jobbar ca 200 personer.
1.2 Syfte och mål
Målet med projektet är att analysera den gamla klienten, ta till vara på de bra delarna och vidareutveckla delar i behov av förbättring enligt kravspecifikationen se avsnitt 2.1.1.
Därefter ska en början till ny klient skapas med några fåtal färdigställda vyer. Vyerna ska sedan användas i en guide som görs till uppdragsgivaren. Guiden ska i sin tur beskriva vidareutvecklingen av den nya klienten. Syftet är att säkerställa prestanda och öka
2 användareffektiviteten, det vill säga minimera den uppmärksamhet operatörer behöver spendera på klienten.
Kunden är i denna en rapport referens till ett pappersbruk som drivs i Sverige.
Pappersbruket är ett integrerat bruk där hela produktionen av papper sker, ända från pappersmassan till färdiga produkter i form av kartong och skrivarpapper.
1.3 Sammanfattning av projektet
Uppgiften var att ta reda på hur mycket nytta en ny klient kan göra och om den kan implementeras utan stora konsekvenser. Därpå ska ett en prototyp byggas och presenteras.
Uppgiften anses vara slutförd.
1.4 Rapportens översikt
Rapporten innehåller 5 kapitel, exklusive detta kapitel, som beskrivs kort nedan:
1.4.1 Bakgrund
Kapitlet Bakgrund ger en övergripande bild av projektets syfte och mål. Kapitlet beskriver även kravspecifikationen och uppdragsgivaren. Därefter introduceras systemet PaperLine och en beskrivning av den gamla klienten samt den nya klienten och alla tillhörande tekniker som klienterna nyttjar.
1.4.2 Design
Detta kapitel ger en systemöversikt över PaperLine, beskriver fördelarna med den nya
klienten samt diskuterar skillnaden på den gamla och den nya klienten. Här nämns även vilka förbättringar den nya klienten för med sig. Sist beskrivs hantering av data från databasen och hur kommunikationen till den fungerar.
1.4.3 Implementation
Implementationskapitlet beskriver genomförandet på en detaljerad nivå. Det täcker implementationen av såväl grafiska komponenter och vy-komponentens kommunikation som dataflödet genom hela systemet. Vidare finns även diskussion kring problem och val av lösningar. Här motiveras lösningsvalen och det ges även en djupare förståelse för tekniken.
3 1.4.4 Resultat
Detta kapitel reflekterar över alla fördelar med den nya klienten samt diskuterar resultatet utifrån kravspecifikationen. Därefter kommer ett avsnitt som jämför gamla och nya klienten prestandamässigt och ett avsnitt som utvärderar tekniken i den nya klienten. Sist diskuteras problem som uppstod under projektets gång.
1.4.5 Slutsats
Slutsatsen utvärderar uppdraget och summerar erfarenheten det givit. Kommentarer kring vidareutveckling och kortfattat om kontakten med kunden. Kapitlet beskriver även
tidfördelningen på projektet och avslutar med slutord.
4
2 Bakgrund
I detta kapitel presenteras tekniken i den nya klienten. Kravspecifikationen beskrivs och tolkas. Ett avsnitt går igenom vad PaperLine är och vad det används till. Den gamla klienten i PaperLine beskrivs här tillsammans med sin systemarkitektur MVC(Model, View, Controller) [4]. Även verktyg, tekniker och ramverk som använts i projektets nya klient samt dess systemarkitektur MVVM(Model, View, ViewModel) [5] förklaras här för att vidare kunna förstå diskussioner kring designen i kapitel 3.
2.1 Översikt av projektet
Projektet beskriver det initiala steget i bytet av klient för systemet PaperLine och innehåller dess planering samt implementering av teknikstacken AMP(Aurelia MES Platform, där MES står för ’Manufacturing Execution System’), vilken är baserad på en rad verktyg och ramverk, se avsnitt 2.4.
Utvecklingsmiljön har under projektets gång varit Visual studio [6], se avsnitt 2.4.1 och arbetet har, som tidigare nämnts i introduktionen, framförallt utgått från att uppgradera en vy i klienten, samt att i mån av tid uppgradera fler vyer med det slutliga målet att alla gamla vyer i systemet blivit uppgraderade med den nya tekniken(AMP).
2.1.1 Kravspecifikation
Projektet innebar från start en uppgradering av det existerande systemet PaperLines klient från dåvarande Web Forms till en mer modernare och snabbare klient i form av bland annat HTML5 [7](se avsnitt 2.4.2). Eftersom PaperLine i dagens läge omfattar stora delar av
kundens produktionssystem innebär det att en uppgradering av hela systemet skulle medföra tusentals timmars arbete. Därför valdes att en eller två vyer skulle uppgraderas.
Projektet skulle även innehålla en utredning av vilka problem som kan uppstå vid denna uppgradering.
Efter små ändringar hos kunden, ändrades projektet och kravspecifikationen till att demonstrera en vy som ett proof-of-concept, för att senare demonstrera och visa den uppgraderade vyn och bevisa fördelar med tekniken AMP.
Sammanfattningsvis ingår följande punkter i projektets specifikation:
5
Kan gammalt system och ny teknik samverka?
Uppgradera den gamla klienten med en uppgraderad vy som proof-of-concept.
Kraven som sattes upp var generella vilket gjorde att delkrav under implementationen sattes upp. Delkraven var inget som var i diskussionen med kunden utan bestämdes i samråd med de involverade i projektet på ÅF.
Ett av de krav kunden hade, men som lågprioriterades då planering av projektet gjordes, var att den grafiska designen skulle behållas till största möjliga mån. Detta då kunden till så stor del som möjligt skall kunna känna igen sig i systemet och snabbt kunna återfå högt
produktionstempo. Fokus lades istället på uppgradering av visuella delar utan på prestandan.
2.2 PaperLine
PaperLine är sedan 2008 utvecklat av ÅF som ett MES. PaperLine är byggt för att övervaka och spåra produktionen i pappersindustrin. PaperLine ligger mellan lagren automation och affärssystem vilket innebär att PaperLine tar in basdata från affärssystemen och returnerar produktionsdata, vilket man ser i figur 1. Från lagret automation får PaperLine
planeringsdata för att sedan vidarebefordra information om det producerade materialet till affärssystemet.
Högst upp finns systemet som tillhandahåller information om vad som skall produceras, framtida produktion av order, planering och lagerstatus.
Lagret i mitten tillhandahåller information om utvärderingar kring producerade order samt utvärderingar om vad som skall produceras.
Till sist det undre lagret, som består av många olika system, maskiner och data. Lagret har till uppgift att tillhandahålla system till var och en av maskinerna i produktionen. Där ingår allt från sensorer till teststationer för order som produceras.
6
Figur 1: MES PaperLine.
2.2.1 Arkpack
Under projektets gång valde ÅF, till en början, att en vy skulle uppgraderas och efter diskussioner med medarbetare på ÅF ledde det till att projektet initialt lyfter vyn
Arkpackning, vilket är en av de vyer i kategorin pack som är inringat i figur 2 . Arkpack är en av de nuvarande omkring 5 vyer som existerar i kategorin pack men har i PaperLine klassats som efterbehandling.
Figur 2: Massa till Papper
7 Arkpackning är en senare del av produktionslinjen i fabriken. Figur 2 visar att packningen ligger efter utskott och efterbehandlingen vilket mynnar ut i lagret. Till arkpack kommer specifika ark in till avdelningen för att packas till ”Reams”, vilket är ett mått på ett visst antal pappersark. Antalet ark i ett ream kan variera.
Packningen sker till stor del automatiskt med hjälp av robotar vilket innebär att arkpacksbilden i PaperLine-vyn kan operera utan konstant uppsikt från användare.
2.3 Gamla klienten – ASP.NET
Systemet PaperLines klient som existerar idag hos kunden är byggt med Web Forms, en del av Microsofts ramverk ASP.NET [8]. Ramverket är byggt med öppen källkod för att bland annat producera webbapplikationer. Web Form, som är en av ramverkets grundblock när det kommer till webbapplikationer, är designat enligt arkitekturen MVC, se figur 3.
Figur 3: Ett exempel på MVC-modellen.
I modellens tre delar är det vyn(View) användaren kommer se, modellen(Model) skickar information från databasen vid uppdateringar som användaren skapat via
kontrollen(controller) i form av inmatningar i vyn.
8 2.3.1 Fördelar med Web Forms
User Controls
User Controls [9] är grafiska komponenter som utvecklare själva kan skapa och återanvända.
Dessa komponenter byggs upp av redan existerande komponenter ASP.NET och Visual Studio erbjuder, vilket gör att de mycket liknar Web Forms-sidor. Komponenter måste sedan bäddas in i redan existerande Web Forms-sidor då de inte fungerar utan att implementeras i andra Web Forms. User Controls kan göra stora och repetitiva arbeten enklare.
2.3.2 Nackdelar med Web Forms View State
En av nackdelarna med Web Forms är hur ramverket behandlar webbapplikationen vid uppdateringar och hämtning av data. Web form måste vid dessa fall slänga all data sparad på sidan för att sedan hämta hem allt på nytt. Detta medför att mycket onödig data kommer skickas mellan klient och server. Web Forms lösning på problemet blev att skapa
lagringsutrymmen kallade View- och Sessionstates [10] [11] som till stor del fungerar som en cookie fungerar i en webbläsare. I lagringsutrymmena kan data tillfälligt sparas som kommer användas då sidan laddat om eller data kommit tillbaka från servern. Trots att dessa
lagringsutrymmen existerar kan inte all data sparas undan i utrymmena, detta för att vid med stora mängder sparad data tillkommer prestandaproblem då view och sessionstates måste följa med ner till servern och tillbaka upp igen. Men så länge kommunikationen behålls enkel kan dessa problem undvikas.
9
2.4 Nya klienten – AMP
Figur 4: Teknikstacken som användas i projektet AMP(Aurelia MES Platform)
Den nya klienten som ersätter Web Forms innehåller komponenter bestående av bland annat HTML-filer och Typescript-filer(se avsnitt 2.4.2). Utöver det används en rad komponenter och verktyg som beskrivs nedan. Den nya klienten jobbar på en helt ny plattform kallad AMP där Aurelia (se avsnitt 2.4.6) [12] är det ramverk som används för struktur och kodning. Aurelia och är baserat på systemarkitekturen MVVM(Model, View, ViewModel).
MVVM-arkitekturen, se figur 5, är ett alternativ till MVC och går ut på att skilja
användargränssnittet från dess logik. Delen ’View’ innehåller grafisk struktur, layout och kod för kommunikation till ’View-Model’, det vill säga kod som inte innehåller logik. Model är precis som i MVC den enhet som innehåller all logik.
10
Figur 5: MVVM-arkitekturen ramverket Aurelia följer
2.4.1 Utvecklingsmiljö – Visual Studio
Microsoft har sedan 1997 släppt nya versioner av sin utvecklingsmiljö Visual Studio som innehåller en handfull kompilatorer för programmeringsspråk. Beroende på
programmeringsspråk kan användaren få automatisk komplettering och automatisk
generering av sin kod. Utvecklingsmiljön omhändertar projektets filsystem, bygger och kan exportera projektet som en produkt färdig att installera.
11 2.4.2 Programmeringsspråk
Nedan beskrivs de programmeringsspråk som används i projektet.
C#
”C-Sharp” [13] är vad många kallar Microsofts version av Java [14]. C# är ett objektorienterat och hårt typat1 programmeringsspråk. Det är en del i Microsofts .NET-plattform och är officiellt baserat på C++ [15]. Likt Java kompileras C# först till bytekod2 och körs sedan i en virtuell maskin. Detta tillvägagångssätt är självklart prestandakrävande men gör språket plattformsoberoende vilket ger det fler applicerbara områden.
HTML5
År 2014 fastställdes version 5 av standarden som HTML använder sig av i uppbyggnad av World Wide Web. HTML som är ett märkspråk använder sig av så kallade taggar för att skapa allt från indelade sektioner till att importera bilder. Taggarna definierar typerna av en
komponent på webbsidan.
Språket går att expandera utanför sina egna ramar med hjälp av script i form av JavaScript [16](se avsnittet nedan) och andra tillägg. Exemplet i figur 6Figur 6: beskriver en inkludering av JavaScript till en HTML-sida. Verktygen och ramverken som beskrivs senare i bland annat avsnitt 2.4.4 och 2.4.5 är exempel på sådana tillägg.
Figur 6: Kodexempel: Implementation av JavaScript
JavaScript
JavaScript är som tidigare nämnts en påbyggnad till HTML där fokus ligger på att manipulera komponenter i webbsidor på framförallt klientsidan av webbläsaren. Språket kan på
klientens sida utvärdera, beräkna och presentera användarens inmatning utan anropa till servern eller att behöva ladda om sidan. Med tiden har JavaScript utvecklats och gått från att bara vara ett klientbaserat språk till att även kunna implementeras och användas bland annat på webbservrar.
1 Hård typning, även statisk typning, är när variabler tilldelas en specifik datatyp vid kompilering och behåller den under resten av programmets livslängd.
2 Bytekod är en slags kompilerad programkod. Till skillnad från maskinkod, som är knuten till en specifik plattform, är bytekod abstrakt eller virtuell eftersom den inte är bunden till en maskinarkitektur
12 TypeScript
TypeScript [17] är ett scriptspråk som transpilerar3 till JavaScript. TypeScript, som är byggt i öppen källkod av Microsoft, ger användaren möjlighet att koda hårdtypat och
objektorienterat. TypeScript som språk är influerat av JavaScript, Java och C# vilket gör att utveckling med Typescript blir klassbaserad. Transpilatorn som ingår i TypeScript översätter TypeScript till JavaScript-kod samt skapar upp en mappnings fil som knyter samman den traspilerade JavaScript-filen och TypeScript-filen. Denna sammanfogning görs för att enkelt felsöka koden under exekvering. Skulle fel inträffa kommer mappningen att hänvisa vart felet inträffat i TypeScript-koden trots att felet inträffade i JavaScript-koden.
CSS
CSS [18] står för ’Cascading Style Sheets’ och är kod som beskriver hur grafiska komponenter bland annat ska bete sig, positionera sig, förhålla sig med hänsyn till skärmupplösning samt storlekar på text och tillgängliga fonter ingår i CSS. Varje enskild HTML-sida kan inkludera sin egen CSS-kod men i detta projekt kommer mycket av CSS-hantering ske automatiskt med hjälp av Bootstrap [19] och Kendo UI [20].
2.4.3 TFS (Team Foundation Server)
TFS [21] är ett nätverksbaserat versionshanteringsverktyg som låter programmerare enkelt kunna jobba på samma projekt och bidra med varsin del kod till lösningen. TFS migrerar ihop filerna och behåller all historik så man alltid kan stega bakåt till föregående ändringar i projektet.
2.4.4 Bootstrap
Bootstrap är ett HTML-och CSS-ramverk där hemsidor dynamiskt kan redigera sin grafik beroende på plattformen och enhetens skärmstorlek. Användning av Bootstrap sker framförallt då utvecklare vill skapa webbapplikationer och webbsidor för såväl datoranvändning som mobilanvändning.
I Bootstrap manipuleras så kallade “stylesheets” automatiskt när användaren delger grafiska komponenter olika klasser och kan på så sätt bestämma hur webbsidan skall se ut.
3En transpilator är en typ av kompilator som använder kod från ett programmeringsspråk och genererar ekvivalent kod i ett annat programmeringsspråk.
13 Stylesheeten är även modulära vilket innebär att vissa delar till viss del går att ändra på för att skapa ett mer personligare gränssnitt.
2.4.5 Kendo UI
Kendo UI är ett utvecklingsverktyg för webbsidor. Biblioteket innehåller grafiska komponenter i form av bland annat grafer, menyer och kartor som kan inkluderas till webbsidan för en mer användarvänlig upplevelse. Kendo UIs grafiska komponenter gör att den visuella utvecklingen av webbsidor blir enklare och snabbare för utvecklare. I figur 7Figur 7: Kodexempel: Ett enkelt rutnät från biblioteket i Kendo UI. nedan visas hur Kendo UI i en
inbyggd HTML-scriptfunktion kan bygga upp ett simpelt men stilrent rutnät.
Figur 7: Kodexempel: Ett enkelt rutnät från biblioteket i Kendo UI.
2.4.6 Aurelia.io
Aurelia.io är ett SPA-ramverk byggt enligt MVVM-arkitekturen för att enkelt kunna skapa och strukturera användargränssnitt. SPA [22] står för Single Page Application, vilket innebär att sidan aldrig ska behöva laddas om utan användaren skall känna som om sidan hela tiden dynamiskt laddar in ny data. Aurelia.io utgår från ett skelett där fördefinierade funktioner finns för att med hjälp av verktyg som TypeScript och JavaScript enkelt kunna utveckla webbsidor och webbapplikationer. Verktygets stora fördel kan framförallt ses då storleken på programmets kod går från i vanliga fall vara överskådligt till oöverskådlig. I fallet då aurelia används kommer utvecklarens kod att förbli överskådlig även vid stora projekt.
2.4.7 Gulp.js
Gulp [23] är ett kompileringsverktyg med bland annat enhetstestning och minimering av kod. Stegen för funktioner i Gulp sker automatiskt via flöden genom processer där varje process lägger på en ny funktion, t.ex. kan en process minimera koden genom att ta bort onödiga delar utan att förändra grundfunktionaliteten. Efter den processen kan programmet
14 skicka utdata till en debug-komponent för felhantering och slutligen skicka ut resultatet av alla processer till en specifik mapp.
2.5 Sammanfattning
Detta kapitel har presenterat projektets bakgrund där en kravspecifikation för projektet och det gamla system kunden använder sig av idag har beskrivits. Kapitlet har även beskrivit de tekniker och de verktyg som använts i projektet.
15
3 Design
I detta kapitel beskrivs programmets nya klient i detalj samt förbättringar sett mot den gamla versionen som bygger på ASP.NET. Det förs även diskussioner kring de problem som fanns i den gamla klienten och hur dessa problem tacklas i den nya plattformen. I design- kapitlet beskrivs även hanteringen av databasanrop och den metod som används för att spegla datamängder till klienten. Sist diskuteras den asynkrona kommunikationen i den nya klienten.
3.1 Översikt
Den nya klienten som kommer implementeras i projektet bygger i dagsläge på en klient från ett annat projekt ÅF jobbat med. Klienten är en webbaserad applikation för surfplattor hos ett företag som driver en stor återvinningsstation och används vid uppgraderingen som mall för att försöka hålla en standard för hur projekt skall se ut producerade av ÅF med
teknikstacken AMP.
Mallen innehåller bland annat komponenter för utveckling av webbapplikationer. En av komponenterna är vyer, vilket i AMP är en SPA(Single Page Application). SPA innebär att sidan aldrig behöver laddas om utan hämtar endast nödvändig data på begäran och uppdaterar sidan bitvis.
3.1.1 Översikt över systemet
Klassdiagrammet representerat i figur 8 beskriver systemet i sin helhet, där klient, server, common och windows service ingår. Figuren beskriver även hur kommunikationen mellan delarna i systemet fungerar. Lagret common tillhandahåller all kommunikation mellan klient, server och windows service vilket även beskrivs vidare i avsnitt 3.3.1.
I figuren syns klienten där vyerna, bland annat gamla och nya Arkpack, ligger. Servern som tillhandahåller kommunikationen med databasen samt windows services som tillhandahåller bland annat meddelandetjänster syns också här.
16
Figur 8: Klassdiagram över systemet PaperLine.
Client Windows service
Common
Server Returnerar:
Data Förbindelser
Skickar:
Andvändar- förfrågningar
Returnerar:
Data Skickar:
Andvändar- förfrågningar
17
3.2 Uppgradering av Front End
Nedan beskrivs skillnaderna i det grafiska utseendet mellan Web form i den gamla klienten och AMP i den nya klienten.
3.2.1 Uppgradering av användargränssnitt Gamla vyns användargränssnitt.
Figur 9 representerar den gamla vyns användargränssnitt, uppritad med komponenter från .NET Web Forms. Upplägget är ganska simpelt med få inmatningsfält och fler textfält där information om order kommer fram. Inmatningsfälten kommer ofta från skannad order och mätinstrument som därefter packas då inga fel uppstått. I gränssnittet ingår även ett antal rutnät där bland annat meddelanden gällande order från tidigare steg i produktionen finns samt information om order som redan packats. Vyns syfte är simpelt; ta in mätdata, kontrollera att allt stämmer, uppdatera databasen om att ordern blivit packad samt visa användaren relevant data för ordern och andra order.
Figur 9: Den gamla vyn i sin helhet
18 Nya vyns användargränssnitt
I figur 10 demonstreras den nya vyns användargränssnitt med komponenter uppritade med bland annat Kendo UI.
Gränssnittet har här ett mer modernt utseende men med samma komponenter där de liggandes på i princip samma plats som i den gamla vyn.
Figur 10: Den nya vyn i sin helhet
3.2.2 Uppgradering av komponenter Kendo UI
Vid uppgradering av front end för systemet valdes, som tidigare nämnt, att använda sig av det grafiska utvecklingsverktyget Kendo UI istället för Web Forms utdaterade och gamla design av grafiska komponenter. I figur 11 och figur 12 kan dessa förändringar ses.
Figur 11: Rutnät från gamla vyn.
19
Figur 12: Rutnät uppritat av Kendo UI.
Komponenter som ritas upp av verktyget Kendo UI kommer till stor del att likna de gamla komponenterna uppritade av Web Forms. En av anledningarna till att utseendet behålls är att till största del göra övergången mellan gammalt och nytt system så enkelt som möjligt för kunden.
Bootstrap
Som tidigare nämnt är Bootstrap ett responsivt ramverk för användargränssnitt. Där en av funktionaliteterna som inkluderats är att bygga upp användargränssnitt utefter plattform.
Detta innebär att då storleken ändras på plattformen kommer Bootstrap att arrangera layouten olika för att till bästa möjlighet illustrera vyns ursprungliga utseende.
Som illustreras i figur 13 och 14 kan skillnader ses mellan vanlig hantering av webbsidor, som inte tar storlek på plattform i hänsyn och Bootstraps hantering av layout.
Vid hantering av layout utan Bootstrap kommer, som demonstrerat i figur 14, komponenter inte alltid synas på den plattform man använder. För full användning av sidan på bland annat mobil tvingas därför användaren zooma ut vyn, vilket medför att vyn blir liten och oläsbar.
Bootstrap hanterar alla delar av hemsidan individuellt och kan strukturera om dem, som att trycka ihop dem och sträcka ut dem. Även placera dem, till exempel, under varandra eller vid sidan av varandra.
Figur 13 visar hur Bootstrap löser de situationer då användning av mobil sker. Genom att stapla om komponenter på höjden istället skapar Bootstrap ett mer mobilvänligt
användargränssnitt.
20
Figur 14: Hantering av gränssnitt utan Bootstrap.
Figur 13: Hantering av gränssnitt med Bootstrap.
21
3.3 Uppgradering av Back End 3.3.1 Före uppgraderingen Vyns uppbyggnad
Skapandet av en vy i ASP.net görs till stor del genom tre komponenterna aspx, aspx.deginer och aspx.cs och denna visualiseras i figuren Figur 15 där komponenterna aspx och
aspx.designer.cs utgör lagret där det grafiska användargränssnittet utvecklas.
Figur 15: .aspx klass .aspx.designer.cs klass och .aspx.cs klass
Aspx klassen tillhandahåller grafiska html-komponenter samt ASP.NETs egenbyggda
komponenter vilket innebär att klassen försöker att till så stor del som möjligt frångå logiskt uttryck.
Inmatning från användare Data från server till användare
22 Aspx.designer-klassen är en brygga som genereras automatiskt av Visual Studio och skapad för att enklare kunna utveckla och hantera koden i aspx.cs klassen för de komponenter skapade i det grafiska användargränssnittet.
Till sist är det aspx.cs klassen vars uppgift är att hantera alla logiska operationer. Här sker allt från visuella ändringar i de grafiska komponenterna till serveranrop och beräkningar av data.
Data som kommer hit kan vara från användaren där utvärdering av inmatning behöver göras eller serverdata som skall sållas och visas på vyn.
Dataflöde
Dataflödet för ett Web Form är i ett “fågelperspektiv” enkelt att begripa och kan ses som ett bra val för en webbapplikation som använder sig av mycket serverkommunikation då en av fördelarna med Web Form är kontrollen man har över servern.
Användningen av webform sker i tre steg med serverns sida inräknat. Dessa tre steg visas i figur 16 och beskrivs som följer.
1. Klassen aspx tillhandahåller information kring vyns element och dess identifierare.
Därifrån kommer information från användaren skickas vidare till aspx.cs klassen 2. Klassen aspx.cs är code-behind till Web Forms. Här sker alla logiska funktioner, anrop
till servern, vyhantering samt valideringar. Det kan, som tidigare diskuterats, vid stora projekt skapa komplex och icke hanterbar kod. Trots detta är server-anropen relativt simpla utifrån klientens perspektiv.
3. Detta sista steg i kommunikationen med servern sker med fördefinierade
“endpoints” [24] klienten kan koppla upp sig mot. Därifrån hämtas önskad data som sedan skickas tillbaka till aspx.cs klassen och sedan upp till användaren.
23
Figur 16: Dataflöde i det gamla systemet
Klassdiagram
I figur 17 visas ett mer ingående klassdiagram samt hur en vy hämtar data från databasen och servern.
Då vyn skall hämta data från databasen krävs, som beskrivs avsnitt 4.4, först förbindelser till servern från klassen ProxyFactory som är lokaliserad i delprojektet common. Det sker genom funktionen Get. Förbindelserna(som Microsoft döpt till kanaler) innehåller den endpoint till servern där TCP(Transmission Control Protocol)-förbindelse [25] sätts upp.
För att sedan knyta samman klient och server skapas ett mellanlager kallat IService. IService är ett interface för asynkron kommunikation(se avsnitt 3.5) där bland annat det så kallade
24 transferobjektet(se avsnitt 3.4) [26] skickas från databasen till klient och vy via .NET-
ramverket WCF(Windows Communication Foundation) [27].
Figur 17: Klassdiagram över gamla systemets fyra stora komponenter
3.3.2 Efter uppgraderingen Vyns uppbyggnad
Uppbyggnaden av de nya vyerna med hjälp av AMP uppdelas till skillnad från de gamla vyerna i flera delar. Likheterna i sin helhet kan dock fortfarande ses då tre delar fortfarande bygger upp grunden, SPA, Web-API [28] och Service och Server. Kommunikationen har dock förflyttats och delats upp mellan fler lager. Den logiska koden existerar inte längre i en klass, utan har här blivit uppdelad i fler delar där var och en tillhandahåller egna funktionaliteter.
Högst upp och närmast användaren ligger HTML och TypeScript filer som tillsammans kallas vy-komponenter. Vyns grafiska gränssnitt samt presentationslogiken definieras av dessa två filer. Att frigöra och dela upp logik till specifika filer och klasser medför att utveckling av webbapplikationer blir enklare och lättare att underhålla.
Till varje vykomponent finns ett objekt som abstraherar bort hanteringen av
kommunikationen, det vill säga Servicelagret och Web-API(även kallat Controller, ska inte förväxlas med Controller i gamla klientens struktur). Objektet är döpt till proxy då
kommunikationen går via dessa objektet som en mellanhand för att låta vyn tro att den har
Client Aspx.cs LoadData();
Server Service
GetData(); Databas
Common
IService GetData();
Proxy Get();
Create();
WCF – Skickar Transferdata
WCF – Skickar Transferdata
TCP- förbindelser
25 direktåtkomst till metoder liggande i Web API(beskrivs nedan). HTML-filen, TypeScript-filen och proxyklassen utgör strukturen för SPA.
Mellanlagret Web API och Service utgör kommunikationen mellan klient och server. Web- APIs uppgift är att exponera serverns metoder för klienten. Till varje Web-API skall en serviceklass finnas, den tar rollen serverkommunikation i nya tekniken.
Serverkommunikationen som tidigare beskrevs existerade i aspx.cs klassen i webform.
Servicen tillhandahåller kommunikationen med servern och skapar response på de förfrågningar som klienten och användaren utfört och som TypeScript-filen sedan kan presentera i vyn.
Dataflöde
Dataflödet i den nya implementation, illustrerat i figur 18, visar hur data via objekt bestående av olika TypeScript-filer, HTML-filer och C#-klasser bygger upp den nya implementationen av PaperLine. De tre delarna klient, mellanlagret och server mellan användare och server kan beskrivas som följer.
1. Användare gör en förfrågan i en av vy-komponenterna i webbapplikationen.
2. TypeScript-filen behandlar förfrågan med den funktion som är länkad samman med inmatningen, för att sedan skickas vidare via den uppsatta Proxyklassen.
3. I denna specifika proxy-klassen, som varje HTML och TypeScript-fil har, finns fördefinierade ‘response’-funktioner som tar in förfrågan och skapar ett ‘request’- meddelande. ‘Response’-funktionerna har även som krav att ge ett så kallat ‘promise’
[29].
4. När proxy-objektet skapat ett Request skickas detta vidare till Controllern.
5. Via controller skickas information direkt vidare till services där kommunikationen till databasen sätts upp.
6. Via kommunikationen sätts direkta förbindelser upp till fördefinierade endpoints i servern.
7. Information hämtas ut från servern och databasen och returneras tillbaka till Proxy som ett response.
8. När meddelandet kommer tillbaka till proxyn skickas meddelandet vidare till vyns TypeScript-fil som tar hand om responseobjektet sorterar ut rätt data och placerar det på rätt plats. Typescript-filen kan även utföra simpel logik på data servern skickat
26 tillbaka då datamängderna ofta kommer som transfersobjekt där mycket data
samlats, för lättare överföring från databasen.
Figur 18: Dataflöde i nya implementationen.
HTML .ts
Proxy
Controller
Server
Aurelia(klient)
Request Response
Web-Api & Service Services
Request Response
27 Klassdiagram
Dataflödet som beskrivs i avsnitt 3.3.2 kan beskrivas med hjälp av klassdiagrammet i figur 19.
Figur 19: Klassdiagram över nya implementations fyra stora komponenter
Likt diagrammet i avsnitt 3.3.1 sätts förbindelserna till servern från klienten upp via ProxyFactor och sedan via interfacet IService. Skillnaden mellan gammalt och nytt är att istället för en klass som tillhandahåller både logik för vy och serverkommunikation görs det i separata klasser i den nya klienten. Detta innebär att serverkommunikationen och
uthämtning av endpoints från ProxyFactor i den nya klienten görs av serviceklassen.
3.4 Spegling av databas
Databasen som existerar i projektet är en kopia av den verkliga produktionsdatabasen över PaperLines all produktionshistorik ute hos kunden, vilket innebär att stora mängder av data måste hanteras vid databasanrop.
För att på ett enkelt sätt samla all relevant data från databasen till klient har man valt att skapa så kallade transfer-objekt. Dessa objekt fungerar som en spegling av databasens tabeller, vilket gör hanteringen av data mycket mer överkomlig vid utveckling av klientens och serverns kommunikation.
Server Service
GetData(); Databas
Common
IService GetData();
Proxy Get();
Create();
Client
.ts LoadData();
Service LoadData();
WCF – Skickar Transferdata WCF –
Skickar Transferdata
TCP- förbindelser
28 Dessvärre existerar relevant data för order ofta i många olika tabeller vilket gör anrop till databasen där produktinformation skall returneras ibland stora och komplexa. Lösningen till detta problem är då att samla alla relevanta transfer-objekt i ett så kallat transferaggregat.
Transferaggreganten fungerar och liknar till stor del ett transferobjekt med skillnaden att transferaggregat kan grupperar såväl transferobjekt som andra transferaggregat i sig själv, vilket innebär stora fördelar för utvecklaren vid anrop av databasen men har även sina nackdelar. Problemet i vissa fall med transferaggregantens transferobjekten är att de i många fall kommer fyllas med all information som existerar i databasens tabell. Detta innebär att mycket onödig information kommer upp till vy komponenterna.
Denna nackdel skapar inga stora problem vid små mängder data då det som visas i figur 20 kan vara enklare att skapa aggregat-objekt med redundans för att enkelt komma åt mer information med mindre kod. Men kan vid större mängder data skapa problem i
kommunikationen mellan databas och klient.
Figur 20: Representation av Transferobjekt och Transferaggregat
Figur 20 beskriver en del i ett transferaggregat där fler transferaggregat kan inkludeas med fler transferobjekt för att få ut mer information från databasen.
3.5 Asynkron kommunikation
En viktig del av nya klientens kommunikation i projektet är hur information skickas
asynkront. Asynkron kommunikation innebär att klientsidan inte stannar andra operationer och bara väntar på informationen som hämtas från servern. Klienten fortsätter istället med andra uppgifter och när svar kommer från servern behandlas det som en ny uppgift. Den asynkrona kommunikationen utförs i TypeScript med funktioner som illustreras i figur 21 .
29
Figur 21: Asynkron kommunikation i Typescript
I exemplet visas hur ett resultat genom funktionen searchOrder i Proxyobjektet kommer, då korrekt returnering skett, att hamna i den temporära variabeln searchResult som sedan lägger resultatet i objektet this.orders. Detta utförs bara när ett resultat har kommit tillbaka från databasen, därav funktionen .then(). Det hindrar inte andra funktioner från att utföra sina uppgifter.
3.6 Sammanfattning
Detta kapitel har täckt designen i den nya klienten AMP som för tillfället används parallellt med den gamla klienten. Kapitlet beskriver även ingående skillnaden mellan dataflödet i den gamla klienten och den nya. Detta följdes av en beskrivning av data som färdas i dataflödet mellan klient och server samt hur skillnaderna visar sig mellan de grafiska komponenterna i vyn.
30
4 Implementation
4.1 Inledning
I detta kapitel beskrivs ingående mycket av projektet implementationer. Kapitlet omfattar även några av de redan existerande lösningarna i den gamla klienten samt kommunikationen mellan server och databas. De gamla implementation inkluderades i kapitlet då det ger en bättre förklaring av fullständig kommunikation mellan klient och databas.
4.2 Implementation av grafiska komponenter Aurelia-Kendo UI Bridge
Aurelia-Kendo UI Bridge [30] är ett hjälpmedel för att slippa så kallad wrapper code, det vill säga importering av hjälpfunktioner. Aurelia-Kendo UI Bridge ger programmeraren möjlighet att använda Kendo UI-komponenter i Aureliaapplikationer, som huvudsakligen är gjorda för vanliga HTML-sidor. Därmed använder man taggar som börjar med ak(Aurelia Kendo), till exempel <ak-grid> är Kendo Grid.
Kendo Grid
Som tidigare beskrivet i avsnitt 3.3.2 visas den grafiska skillnaden mellan rutnät uppritat i den gamla(Web Forms) och den nya tekniken(AMP). Skillnaden är ytterst liten och samma gäller för implementation för att rita upp rutnäten. Web forms använder sig av objektet GridView för att åskådliggöra ett rutnät medan AMP utnyttjar Kendo UI:s inbyggda
funktioner för rutnät. I figur 22 demonstreras skillnaderna mellan gammalt och nytt. Båda bär på inställningar som kan manipuleras för att få fram den önskvärda grafiska
komponenten. Den markanta skillnaden ligger i vad Kendo UI erbjuder i form av tillägg till sina komponenter, vilket vidare beskrivs i avsnitt 4.5. Figuren beskriver den gamla klienten till vänster och den nya till höger.
Figur 22: Kodexempel: Implementation av Rutnät i både Web Form och Kendo UI
31 Att sedan föra in data in i rutnätet sker på liknande sätt, båda objekten tar in listor i form av transferobjekt in till en datasource. Denna datasource i GridView [31] kan bland annat behandla objekt som Datatable [32](en tabell i C#), Dataset [33](en kollektion av Datatable), och IList [34](en kollektion av objekt), dock kan inte Kendo UI behandla alla objekt som GridView kan, men i det fall blir det inte några förhinder då gamla vyns rutnät använder sig av IList vilket datasource i ’Kendo UI’ kan behandla.
Kendo Contextmenu
Kendo Contextmenu [35] är en högerklicksmeny i Kendos grafiska bibliotek. Funktionen går endast att binda till andra Kendo UI-komponenter.
Implementation av komponenten Kendo Contextmenu utförs likt implementationen av Kendo Grid. Figur 23 visar hur, likt Kendo Grid, även Kendo Contextmenu kräver vissa inställningar för att få fram de önskvärda design på komponenterna, bland annat inställningar om vart Contextmenu skall visa sig.
Figur 23: Kodexempel: Kendo Contextmenu
Den komponent som sedan visas vid högerklick är en simpel meny med endast ett valbart objekt, att skriva ut och visas i Figur 24Figur 24. Väljer användaren att skriva ut renderas en ny specialgjord komponent beskriven utförligare i avsnitt 4.5.
Figur 24: Kendo Contextmenu med ett menyobjekt
32 Språkhantering
Alla texter och etiketter i HTML-filerna är språkhanterade och gör det möjligt att ändra all text i en vy. Varje textelement är bundet till en strängvariabel i en specifik språkfil, en .cs- klass(C#), som hör till vykomponenten. För varje vykomponent finns respektive språkfil fylld med variabler för alla texter i vyn. Dessa variabler har en get-metod för att hämta texten och en set-metod för att ändra texten. Figur 23Figur 23 på föregående sida innehåller två
scripttaggar som hämtar text från språkfilerna. Taggarna börjar med language. i texten och pekar på varsin variabel.
4.3 Dataflöde
Som beskrivet i avsnitt 3.3.2 skapades under projektets gång kommunikation mellan klient och server med hjälp av response- och request-objekt som skickas fram och tillbaka.
Kommunikationen har till största mån försökt efterlikna den gamla kommunikationen men med den nya tekniken AMP.
I avsnittet nedan beskrivs ingående vilka komponenter som utvecklats och implementerats i projektet från klient till server.
HTML-fil
I HTML-filen skrivs koden för all grafisk struktur. Med hjälp av ramverket Aurelia skapas en dynamisk HTML-struktur som behandlar alla verktyg på ett simpelt och användarvänligt sätt för programmeraren. Verktyg som Kendo UI och Bootstrap fungerar bra ihop i Aurelia.
HTML-filen har för övrigt en TypeScript-fil kopplad till sig med kommunikationslogik, se avsnittet nedan. Dessa två filer utgör en vykomponent.
TypeScript-fil
Den översta och närmast användaren, tillsammans med html-filen, liggande filen är en TypeScript-fil. Filen har som uppgift att skicka ner data bland annat från användaren ner till proxyobjektet. Här tillhandahålls även data som kommer från servern för att sedan visas på vyn. Minimalt med logiska operationer existerar här då enbart grafisk manipulering sker här.
Figur 25 visar på hur en lista läggs in i ett listobjekt uppritat i html-filen.
33
Figur 25: Kodexempel: Implementation av funktion i TypeScript-fil
Proxy
I figur 26 sätter Proxyobjektet upp ett nytt requestobjekt med användarens inmatade inparametrar till förfrågan. Objektet skickas sedan in i funktionen där den asynkrona kommunikationen sätts upp, skulle fel inträffa i kommunikationen kan detta fångas upp av programmet genom att definiera en så kallad catch-funktion [36] där det genererade felet kan behandlas.
Då inga fel genererats returnerar proxyn resultatet från databasen upp till klienten. Skulle retur-meddelandet bestå av ett objekt måste ett nytt objekt sättas upp med en egen
konstruktor [37]. Detta utförs för att den asynkrona kommunikationen ska fungera med det objekt som returneras. I figur 26 ser man att ett Promise skapas med objektet i sig.
Figur 26: Kodexempel: Implementation av function i proxyobjektet
Web API
Web API som beskrivs i figur 27 visar på hur simpel bindningen mellan Proxyobjektet och serviceklassen är. Det måste inkluderas då en ny vykomponent skapas och tillhandahåller ett request-objekt och ett response-objekt. Även om request- och response-objektet inte kommer returnera något eller inga inparametrar krävs måste Web API använda sig av request och response. Detta görs för att skapa en standard för all transport mellan servern och klienten.
34
Figur 27: Kodexempel: Implementation av Web-API
Response
Ett response-objekt kan, som visat i figur 28, innehålla varierande data. Allt från nummer och textsträngar till objekt och andra klasser.
Varje gång klienten skickar en förfrågan om data från servern kommer ett nytt tomt response objekt att skapas som sedan fylls på med information i serviceklassen(se nedan).
Sedan skickas det upp till Proxyobjektet.
Figur 28: Kodexempel: Implementation av Response-objekt
Request
Likt response-objektet tar request-objektet in varierande data som ska till servern. Dessa objekt kan, som tidigare beskrivet, vara tomma, detta inträffar då servern inte kräver någon användardata för att utföra sin förfrågan.
I figur 29 beskrivs ett request-objekt där klassen inte innehåller någon förfrågan till servern.
Figur 29: Kodexempel: Implementation av Request-objekt
Service
Service klassen har uppgiften att kommunicera med servern. Med hjälp av förfrågan från request-objektet som användaren skrivit in, kan klassen via serverns egna serviceklasser hämta ut transferobjekten. I figur 30 kan ses hur funktionen Fetch tar emot ett request samt returnerar ett response. Response fylls med data via förbindelserna beskrivet vidare i avsnitt 4.4. Efter all data har fyllts i kommer ett nytt objekt sättas upp, detta responseobjektet
public class FetchBatchDetailsRequest {
}
35 kommer returneras till controllern, för att sedan evalueras av proxyn som sedan skickar ut data till vykomponenterna.
Figur 30: Kodexempel: Implementation av function i Serviceklass
36
4.4 NHibernate och databaskommunikation
Figurerna beskrivna i detta avsnitt är en förenkling av hur kommunikationen mellan klient och server är uppsatt i det gamla systemet. Implementation finns redan och var inget detta projekt inkluderade för utveckling, men togs med för att förstå funktionalitet som använts.
För att kommunikationen mellan server och databas skall fungera används kartläggningsverktyget NHibernate [38]. Verktyget är inte enbart byggt för att få kommunikationen fungerande utan förenklar även anropen utvecklaren vill utföra från webbservern till databasen. Figur 31 visar hur klienten sätter upp en kommunikation,
beskrivet nedan, till servern där funktionen GetId() finns. För att sedan hämta ut returvärdet från GetId() måste klienten gå via, beskrivet nedan, ett interface [39] för uppsättning av asynkron kommunikation.
Figur 31: Kodexempel: Anrop från klient till server
Klientens uppsättning av kommunikationen börjar med en TCP-förbindelse mellan klient och server vilket visas i figur 32 . Förbindelsen skapas via klassen Proxyfactor där Endpoints för varje serverklass sparas undan via funktionen “register” i så kallade dictionaries (kataloger) [40], vilket visas i figur 32. Förbindelserna som sätts upp görs via den inbyggda klassen ChannelFactory [41] som kan ses i figur 32. ChannelFactory sätter upp det Microsoft kallar för kanaler via en adress till en server samt en fördefinierad TCP-förbindelse. Sedan sparas kanalerna i katalogen som klienten sedan kan hämta ut när serverkommunikation skall sättas upp.
37
Figur 32: Kodexempel: Proxyfactor med uppsättning av TCP-förbindelser
När förbindelserna skapats till servern, krävs ett interface mellan server och klient där WCF- ramverket kan skicka data asynkront mellan server och klient. Interfacet innehåller enbart de funktioner som klienten vill erhålla från databasen.
För att interfacet sedan skall bli definierat som ett interface som skall tillhandahålla WCF- kommunikation mellan klient och server, måste implementationen av ServiceContract [42]
göras, samt OperationContract [43] vilket definierar att en metod är en operation i WCF kommunikationen. Detta demonstreras i figur 33.
Figur 33: Representation av Interface mellan klient och server
När sedan klienten vill koppla upp sig mot servern via WCF och kanalerna som blivit sparade i ProxyFactors katalog ChannelFactories görs detta via funktionen ’get’ som skapar en tillfällig förbindelse via nyckeln som också är interfacet mellan server och klient till den specifika platsen i servern. Via funktionerna kan klienten sedan få de transferobjekt som servern skapar och skickar tillbaka till klienten, se figur 34.
public class ProxyFactor{
public static ProxyFactor Create() {
return new ProxyFactor();
}
static ProxyFactor() {
Register<IPersonService>(“PersonService”,tcpBinding);
}
public static void Register<T>(string address, ClientBindingBase tcpBinding){
string endAddress = ”net.tcp//:localhost/Server”;
address = endAdress + address;
ChannelFactory<T> channel = ChannelFactory<T>(tcpBinding, address);
ChannelFactories.Add(typeof(T), channel);
}
public T get<T>() {
ChannelFactory<T> factory = (ChannelFactory<T>)ChannelFactories[typeof(T)]
T proxy = factory.CreateChannel();
return proxy;
} }
[ServiceContract()]
public interface IPersonService {
[OperationContract]
PersonTransferAggregate GetId(int id);
}
38
Figur 34: Kodexempel: Databasanrop från server
Slutligen kräver server att få vetskap om databasen, där används en liknande uppsättning som klienten gör för kommunikation med server. Skillnaden i servern är att där,
demonstrerat i figur 34 , öppnas en session upp med NHibernate via ett repository1 [44] där bland annat SQL-kommandon kan skickas in till fördefinierade kommandon representerade i figur 34, repo.GetAll().
4.5 Problem och val av lösningar
Nedan beskrivs några av de problem som uppstått under projektets gång. Problemen diskuteras och lösningarna till dem reflekteras med motiveringar till besluten.
Mousetrap
I vyn existerar funktionalitet där knapptryck är bundna till funktioner . Detta är skapat för att snabbt kunna arbeta med vyn och snabbt kunna navigera sig till andra vyer samt utföra kommandon utan behov av en mus. Dessa snabbkommandon skapades med ramverket JQuery [45], ett JavaScript-bibliotek som används för enklare hantering av händelser, animationer och navigering i dokument. Biblioteket sätter upp händelser i Web Form för att hantera knapptryck från användare och vidarebefordra dessa snabbkommandon till rätt funktion.
Att använda sig av biblioteket JQuery hade varit en alternativ lösning till uppgraderingen då både TypeScript och JQuery bygger på JavaScript. Men denna lösning ansågs inte vara användbar då Aurelia kan utöka sitt ramverk med tredjepartsbibliotek och biblioteket Mousetrap [46] löste alla problem JQuery tidgare löst.
Att sätta upp en konfiguration för Mousetrap sker enligt figur 35 på följande sätt. En mappning för vilka tangenter man vill använda sig av sätts upp med ett namn.
39
Figur 35: Kodexempel: Konfiguration av Mousetrap.
Sedan, representerat i figur 36 , binds detta event till ett objekt i html filen. När sedan användare trycker på knappen som implementerat i mousetrap skapar mousetrap en händelse som simulerar ett knapptryck till från användaren och kallar på rätt funktion.
Figur 36: Kodexempel: Implementation av Mousetrap.
Felmeddelanden
En av den stora funktionaliteterna med webbapplikationen var hur felmeddelande genererades. I den gamla klienten skapades dessa rutor via en så kallad
ModalPopupExtender [47] som visas i figur 37 .Meddelanderutan är en komponent skapad för att låsa bakomvarande komponenter från interaktion från användare samt lägga sig ovanpå det redan existerande fönstret.
Figur 37: Web Forms representation av meddelanderuta.
40 För att skapa en mer manipulativ komponent kan felmeddelandet i figur 37 ta in en rubrik, ett meddelande, en ikon samt en knappgrupp som parametrar och visa upp det i
ModalPopupExtender. Inparametrarna tas in då meddelandet användaren ser kan variera.
Knapparna kan även variera beroende på vad användaren skall göra då felmeddelandet kommer upp.
ModalPopupExtender existerar inte till Aurelia vilket innebar att ett plugin Aurelia-Dialog [48] valdes att användas till uppgraderingen. Aurelia-Dialog fungerar på liknande sätt som ModalPopupExtender där meddelande, rubrik och typ av knapp kan implementeras till dialogrutan, vilket visas i figur 38.
Figur 38: Aurelias representation av meddelanderuta.
View- och Session State
Som tidigare nämnt är Web Forms lösning på problemet, med data som inte sparas vid serveranrop och uppdateringar, att skicka med data i anropet till servern för att sedan skickas tillbaka till klienten.
View- och session state fungerar på samma sätt men har olika långa livscykler där livscykeln för View states bara existerar då sidan utför ett så kallat postback, vilket innebär att då sidan skickar en förfrågan för att spara data i servern, kommer användare tillbaka till samma sida som tidigare. Data servern inte sparar åt användaren kommer då att försvinna om den inte sparats undan i View state.
Session states livscykel varar så länge en cookie existerar för sidan. Fördelen med session state framför View state är att session state kan behålla sina värden över anrop av andra sidor, vilket ger en stor fördel då systemet PaperLine bygger på att användare skall kunna förflytta sig mellan vyer med samma användarinställningar för var och en av vyerna.
41 Användningen av View state och session state är dock begränsad till ASP.NET vilket innebär en stor förändring vid uppgradering till AMP. Lösningen till View states problem, att spara undan data då postback sker, blev simpel. Som tidigare nämnt hämtar AMP enbart data om det behövs vilket innebär att data tillfälligt kan sparas undan i klienten under serveranropet.
Problem med session state blev dock svårare att lösa och beskrivs vidare in avsnitt 6.2.
Skriv ut och exportera
Likt felmeddelande existerar det specialbyggda meddelanderutor för utskrifter till Excel- dokument samt utskrifter till skrivare. Dessa meddelanderutor har egenskapen att skriva ut specificerade rutnät med order. Funktionaliteten sträcker sig även till att användaren skall kunna plocka bort kolumner från diagrammet samt ändra textstorlek och orienteringen av sidan.
Problemet uppstår då metoderna för implementationen enbart stöds av webbläsaren Internet Explorer. Att låsa sig till en webbläsare är inte är att föredra då användare i framtiden kan komma att byta plattform eller webbläsare.
Lösningen var att likt “felmeddelanden” bygga upp egna komponenter via Aurelias plugin
‘Aurelia-dialog’ och där utföra samma operationer den gamla meddelanderutan utförde.
Figurerna 39 och 40 ger en tydligare bild över skillnaden mellan den uppgraderade versionen och den gamla versionen. Figur 39 skildrar hur funktionaliteten byggdes upp med hjälp metoden enbart Internet explorer stödjer showModelessDialog [49]. Metoden tar in och visar ett HTML-dokument med specifika attribut, vanliga webbapplikationsfönster inte har som standard. Till exempel inaktivt statusfält och möjlighet att inte skala fönstret.
Figur 39 visar det gamla fönstret för utskriftsfunktion samt export till Excel.
42
Figur 39: Utskriftsfunktion från Web Forms.
I den nya dialogrutan som användare kan bestämma utseendet för rutnätet har förändringar skett i form av Kendo UIs funktionalitet att sortera bland kolumner och rader. Även
funktionen för export till Excel sköts nu av Kendo UI. Figur 40 ger exempel på hur det kan se ut när man använder funktionerna i den nya klienten.
43
Figur 40: Utskriftsfunktion från Aurelia.IO och Kendo UI
4.6 Automatiskt genererade filer.
Som beskrivet i avsnitt 3.3.2 ligger en controller mellan proxyobjektet och service-klassen.
Controller, även kallad Web-API, har i uppgift att vidarebefordra meddelanden från en SPA till serviceklassen. Eftersom klassens enda uppgift är att vidarebefordra meddelanden mellan två klasser existerar inte mycket kod i klassen. Kontrollerklassen tillhandahåller bara ett objekt för varje funktion som skapas för anrop till servern.
För att sedan föra samman Web-API och proxyobjektet så kräver SPA-klienten att alla C#- klasser som används genereras automatiskt till ts-filer. Detta för att skapa en mer effektiv och typsäker kod. Den automatiska genereringen sker genom ett projekt med öppen källkod vid namn TypeWriter [50], skapat för att generera TypeScript-kod från C#-kod.
Tyvärr innebär genereringen att filer separeras från varandra, och har därför ingen
kännedom om varandras värden då TypeScripts filer enbart känner till data inom sitt eget scope [51]. För att använda variabler i en utanför filens scope tvingas utvecklaren exportera klassen. Denna lösning fungerar enbart åt ena hållet då andra filer nu kan se variabler och funktioner men kan inte använda sig av dem. Detta på grund av att när en funktion vill använda en variabel från en annan fil krävs ett import-“statement” för varje användning av de exporterade funktioner och variabler. Arbetet ansågs då bli för stort för att implementera alla dessa “statements” vilket innebär att lösningen istället blev att samla alla dessa
automatiskt genererade filer till en enda DTO(Data Transfer Object) fil. Nackdelen med denna lösning är att filen som genereras innehåller kod för stora delar av projektet vilket kan
