Gruppe 33 Studieprogram: Informasjonsteknologi Åpen HOVEDPROSJEKT Server Boot

Transkript

1

2 PROSJEKT NR. Gruppe 33 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Server Boot DATO ANTALL SIDER / BILAG 95 PROSJEKTDELTAKERE Fredrik Joramo s Nima Mashouri s Nicolai Nordberg s INTERN VEILEDER Boning Feng OPPDRAGSGIVER TeleComputing As KONTAKTPERSON Erling Wittussen Kristoffer Hovland SAMMENDRAG Gruppe 33 har utviklet et et administrasjonssystem, for automatisk restart av Microsoft Windows servere. Systemet brukes ved å sette opp jobb regler og det logger alle hendelser. Denne webappliksjonen er utviklet til Telecomputing As. 3 STIKKORD Serverboot C#/C-sharp Webappliksjon

3 1

4 Innholdsfortegnelse Forod... 3 Om gruppen... 4 Om oppdragsgiver... 5 Dagens løsning... 5 Mål... 6 Beskrivelse av Applikasjonen... 7 Sammendrag

5 Presentasjon av prosjektet Forod Under dette prosjektet har vi laget et produkt gjennom et helt semester på Høgskolen i Oslo og Akershus, på avdeling for ingeniørutdanning. Vi startet allerede høsten 2013 med å finne gruppe og en arbeidsgiver. Gruppen ble nydannet da, og hadde ikke samarbeidet tidligere. Et av gruppemedlemmene jobber for TeleComputing så det var et av de firmaene vi kontakt først. Vi hadde et møte Erling og Kristoffer hos TC rundt mulige prosjekter og ble enige om at vi skulle lage en Server Boot Applikasjon for dem. Resultatet av dette prosjektet er vi veldig fornøyde med, og vi er glade for å ha laget noe Telecomputing kan benytte seg av. For oss som studenter har det hvert et veldig spennende og innholdsrikt halvår, siden vi endelig fikk litt følelse av hvordan det er å jobbe i et prosjekt ute i arbeidslivet. Vi har jobbet både på Høgskolen i Oslo sine lokaler, og på kontorene til TeleComputing. Dette resultatet ville aldri blitt det samme uten god hjelp fra ansatte hos TeleComputing, og vi ønsker å gi en stor takk til de personene som har hjulpet oss gjennom denne prosessen. Vi er veldig takknemlig for all støtte gjennom dette prosjektet og ønsker å takke: Oppdragsgiver: TeleComputing Ledere i TC: Erling Wittussen, Kristoffer Hovland Programmerere: Sebastian Henriksen, Thomas Eyde, Robin Pettersen, Arild Bakken Veileder: Høgskolen i Oslo og Akershus: Boning Feng. 3

6 Om gruppen Vi er tre IT studenter på Høgskolen i Oslo og Akershus (HIOA) Nima Mashouri, Fredrik Joramo og Nicolai Nordberg som har jobbet sammen i dette prosjektet. To studenter fra Anvendt Datateknologi og en Data Ingeniør student. Dette førte til at vi kunne uveksle kunnskap og ideer. Vi var først bare to studenter som startet, men etter en diskusjon ble vi enige om å rekruttere et tredje medlem av gruppen, noe som var til stor nytte for resten av prosjektet. Måten vi gjorde dette på var via veilederen Thor Krattebøl, som vi sendte mail til at vi trengte gruppe. Gruppen hadde ikke jobbet mye samen tidligere, men erfarte med en gang at vi hadde de samme ambisjonene. Vi kom også i god kontakt med hverandre, og fikk god sosial kontakt gjennom halvåret, noe som også førte til et bra samarbeid. Vi startet med å liste opp alle aktuelle oppdrag vi kunne utføre, vi laget en søknad til bedriftene med litt om oss og med cv. Vi var litt i kontakt med Uloba til å begynne med, men fikk fort et møte med TeleComputing, som virket veldig mottagelige ovenfor gruppen. Figur 1: Kart over alle personer som har vært involvert i dette prosjektet. 4

7 Om oppdragsgiver TeleComputing (heretter kalt TC) har siden 1997 vært en ledende aktør innen sentralisert ITdrift og nettbasert programvaredistribusjon. De tilbyr fleksible, skalerbare systemer til små og mellomstore bedrifter. TC utvikler et administrasjonssystem de kaller Opus. Opus styrer bl.a. Active Directory for de fleste kunder, automatisk innhenting av informasjon fra servere og annen hardware, felles informasjonspunkt for product approval, kommunikasjonsinfo, knowledege base, rapportering, faktureringsgrunnlag m.m. Det legges også stor vekt på at kunder skal kunne administrere så mye som mulig selv av brukere og tilganger på sine egne ressurser via Opus. Programmeringen av Opus foregår primært i C# med. NET og Knockout script. Programmeringsverktøyet er Visual Studio med Team Foundation Server. Den aktuelle oppgaven er å lage et administreringsverktøy for overvåkning og kontrollert omstart av servere. De fleste av TC s servere står i datesentre i Norge, men de har også ca 70 server rack stående i mange forskjellige tidssoner rundt omkring i verden. Restart av disse er en omfattende operasjon som krever mye oppfølging. Dette gjøres i dag via script med begrensede muligheter for å logging og sjekk av at boot og oppstart har foregått som det skal. Det skal lages et GUI i form av en webapplikasjon. Det er viktig at produktet lages i samsvar bestemte rammer for neste versjon av Opus slik at det er mulig å integrere på et senere tidspunkt. Det må også være oversiktlig, intuitivt og enkelt å vedlikeholde. Dagens løsning Helt siden starten har TeleComputing trengt en metode for å kontrollere omstart av servere. I begynnelsen var det ikke noe problem å gjøre dette ved å bare sette opp en scheduled task på hver server som trengte restart ved jevn mellomrom. TeleComputing har vokst seg ganske store siden den gang, og det kom etter hvert et større behov for å få mer kontroll over restartprosessen. En gruppe citrix servere, terminalservere, en kunde benytter seg av kalles et server load. Disse terminalserverne restartes vanligvis en gang per natt på gitte tidspunkt. Det hender rett som det er at en kunde sitter å jobber hele natten, og ikke vil at systemet skal være utilgjengelig den tiden det tar og restarte. Dette løser man ved å la halvparten av De fleste kundene til TeleComputing logger seg på en virtuell desktop som ligger på en av serverne i TC s datasenter, teknologien som blir brukt er Citrix i forskjellige versjoner. Serverne i et load restartes etter de andre. Det samme gjelder to domenekontrollere på en site, og andre tilfeller. Dagens system består av et program og konfigurasjonsfiler. Programmet ble først utviklet når man fortsatt var på NT4 platformet, og har blitt utvidet hver gang det har kommet en ny serverversjon som ikke var støttet av de gamle metodene å restarte/sjekke serverne. Konfigurasjonsfilene er XML filer som programmet leser. I disse XML filene legger man inn filter via regex verdier, alle servere i TC 5

8 følger en navnestandard og den er denne man filtrerer på. Når XML filene kjøres inn i programmet leter det gjennom serverobjekter i Active Directory og legger alle servernavn som matcher per regex i en jobbliste. Programmet kjører så igjennom og oppretter jobber som restarter serverne. TeleComputing er nå en stor bedrift, og det er mange som på et eller annet tidspunkt er inne og vil legge inn en server i konfigurasjonen eller endre tidspunkt den blir restartet på. Da regex ikke akkurat er intuitivt for alle blir det ofte en del rot i disse filene og serverobjekter som treffes av flere filter. Mål Målet med denne applikasjonen, er å lage en mye mer oversiltlig måte for oppdragsgiver til å boot sine servere, og ikke minst gjøre det enklere for dem å kjøre bootene. Vi vil også gjøre det enklere for dem å sette tidspunkt for bootingen, noe de kan sette på forhånd. Vi vil samle alt på et sted, i motsetning til den gamle løsningen deres, hvor de måtte inn flere steder for å kontrollere serverne deres. Applikasjonen skal kunne: Omstarte servere Gi en mer oversiktlig metode for oppdragsgiver til å utføre omstart Sjekke om server kommer opp etter omstart Kunne sette tidspunkt for omstart på forhånd Loggføre hver eneste boot Vi benytter våre egne datamaskiner som arbeidsstasjon er når vi løser oppgaven. Språkene det skal skrives i er C#, ASP.NET og JavaScript. Data skal lagres i SQL databaser. Vi skal benytte TFS som versjoneringssystem via TFS online. Det skal i første omgang ikke integreres med Opus, dette er avtalt med oppdragsgiver for at vi ikke skal bli for avhengige av deres deadlines eller måtte bli stående fast i påvente av deres arbeid med neste release av Opus. Hovedtrekkene i kravene er å lage et system for restart av servere. Det skal bestå av et web basert brukergrensesnitt, en administrasjonsdel, et databasebasert lager for data og en arbeider del som utfører jobbene. Systemet skal kunne benyttes av IT folk i organisasjonen både fra drift og implementasjon. Så mye informasjon som mulig om hva systemet gjør, hva som blir forsøkt utført og hva som feiler skal loggføres. En mer komprimert og lettleselig rapport skal også genereres. Våres egne mål var å utvikle et system for serverdrift, som både vi selv og autoriserte brukere kan være fornøyd med. Vi vil at den skal være enkel i bruk, og ha riktig funksjonalitet. Vi ønsker også å få et innblikk i hvordan det er å jobbe i et større prosjekt, og 6

9 å samarbeide med det som gruppe. I tillegg ønsker vi å lære nytten av det å bruke styringsdokumenter, gjennom et så stort prosjekt. Beskrivelse av Applikasjonen Denne applikasjonen gir TeleComputing brukere en veldig brukervennlig og oversiktlig måte å få kontroll på deres servere. Alt er på et sted og de kan enkelt navigere mellom de ulike servere og regler. De kan enkelt sette opp nye regler for serverboot og se hvilke servere som blir påvirket. Applikasjonen vil bli mer detaljert forklart i Produktrapporten. Sammendrag Under dette prosjektet, har vi utviklet et system for automatisk omstart av Microsoft Windows Servere som et firma kan bruke til å styre omstart av en mengde servere. Produktet kjøre på Microsoft plattform. Dette systemet restarter servere med etter brukerdefinerte regler som kan konfigureres i systemet. Systemet logger hendelser og det er lett å se de siste hendelse for servere. Målet vi hadde for denne utviklingen var å skape en enkel løsning som er enkel i bruk, men kraftig under panseret. Oppdraget ble gjort for TeleComputing og omstartstyring av deres servere. Vi har lært veldig mye om det å jobbe i et prosjekt, og at det krever mye kunnskap og erfaring for å kunne planlegge et godt systemdesign før man begynner. Dette har vært et stort og omfattende prosjekt for oss, det er mange timer arbeid som ligger bak, med mye programmering. Dette er fordi vi ikke hadde noen forkunnskaper i mange av teknologiene vi har benyttet i utviklingen av dette produktet. Vi har jobbet både på Høgskolen, og i TeleComputing sine lokaler, ute i Asker. Gruppen har fått mye god veiledning, fra erfaringsrike ansatte hos TeleComputing, de hjalp oss i både læringsprosessen, og under utviklingsprosessen. 7

10 1

11 Innholdsfortegnelse Forord... 3 Planleggingsprosess... 4 Prosjektstart... 4 Arbeidsmåte/Fremgangsmåte... 4 Begreper innenfor Scrum... 5 Datainnsamling... 6 Styringsdokumenter... 6 Dagbok... 7 Rissikoplanlegging... 7 Rissikostyring... Feil! Bokmerke er ikke definert. Risikohåndtering... 9 Forhåndskunnskaper Prosjekthjemmeside Utviklingsprosess Utviklingsfasen Dokumentasjonsfasen Verktøy og Teknologier Kommunikasjon Utfordringer Avslutning Læringsutbytte Konklusjon Videre Utvikling

12 Forord I prosessrapporten beskriver vi prosessen bak utviklingen av Server Boot Applikasjon til TeleComputing. Hele arbeidsprosessen gjennom hovedprosjektet vil bli beskrevet og består av tre hovedkapitler. Her anbefaler vi at leseren har lest igjennom presentasjonsdokumentet av hovedprosjektrapporten og gjort seg kjent med denne. Under ser du de ulike kapitlene. Planleggingsprosess: Som innebærer planleggingen av prosjektet, hvordan vi planla gjennomføringen av hovedprosjektet. Utviklingsprosess: Her beskriver vi gangen i prosjektet, hvordan vi jobbet i henhold til planen, hvordan vi utviklet produktet fra programmering til design, hvilke utfordringer vi møtte underveis. Avsluttende del: Som tar for seg litt rund våre tanker rundt produktet, en liten avsluttende konklusjon, hva vi gjorde bra og hva vi kunne gjort bedre. 3

13 Planleggingsprosess Planleggingsprosess innebærer hvordan vi planla gjennomføringen av hovedprosjektet. På et større prosjekt er det utrolig viktig å ha en plan, hvis ikke får man aldri helt oversikten og man rekker ikke deadline. Derfor viktig å planlegge hva som skal gjøre og hvem som gjør hva, gruppemedlemmene burde vite hva de andre arbeider med, slik at de får kontroll på hva som gjøres/har blitt gjort, og så de kan støtte opp hverandre når noen sitter fast. Prosjektstart Gruppen hadde sitt første gruppemøte 26. oktober Fram til dette hadde vi bare vært i kontakt via e-post. Hensikten med dette møtet var å hilse på hverandre siden vi ikke hadde jobbet sammen tidligere, og utveksle litt tanker og ideer rundt prosjektet. Det ble også diskutert hvilke bedrifter som var potensielle oppdragsgivere, og som kunne tilby oss et prosjekt. Gruppen satt igjen med en liten liste med virksomheter, og vi fikk også laget ferdig en søknad, som ble sendt rundt til oppdragsgiverne. Gruppen fikk interesse fra flere bedrifter, og vi kom fort i kontakt med TeleComputing som hadde flere oppdrag ledige. TeleComputing ville at vi skulle lage en løsning for kontrollert omstart av servere for dem. De hadde allerede en eksisterende løsning, som de ikke var helt fornøyd med, dette beskrives mer detaljert i Produktrapporten. Prosjektet ble godkjent mitt i januar, slik at vi kunne gjennomføre det våren Arbeidsmåte/Fremgangsmåte Scrum: Gruppen har utviklet dette produktet, med Scrum som utviklingsmetode, noe vi bestemte oss for i begynnelsen av prosjektet. Denne metoden handler om å dele opp arbeidet i små deler, som man utfører hver for seg. Videre så utvikler vi delene, slik at de bygger på hverandre. Dette er for å få frem kreativiteten blant utviklerne, og for at produkteieren kan gi jevnlige tilbakemeldinger. Tilbakemeldinger er fint å ha gjennom hele utviklingsprosessen, slik at man alltid har mulighet til å utføre endringer underveis. Scrum deles inn i tre hoved deler. Produkteier styrer hva som skal utvikles innen de ulike fristene. Utviklere bygger det som skal utvikles innen de ulike fristene, og presenterer resultatene for produkteierne, produkteierne styrer neste sprint etter resultatet av presentasjonen. 4

14 Scrum-master forbereder prosessen ved å legge ting til rette for utviklerne. Utfører nødvendig forarbeid ved å sørge for at de har tilgang til verktøy og programmer som er nødvendig for utviklingen, og fjerner alt som står i veien for dem. Gruppen klarte å holde på dette neste hele veien med visse unntak, hvor vi måte gjøre litt småendringer her og der. Sprint: En sprint er en tidsramme på cirka tre uker, der utviklere utfører en del av et prosjekt helt ferdig. Med en gang en sprint er ferdig, starter en ny, som bygger videre på den forrige. Knockout: Var den første sprinten vi hadde, her satte vi et intervall på to uker. Vi fikk først hjel av veileder i TC's Sebastian Henriksen, når vi skulle prøve selv bød det på visse utfordringer, men vi kom i mål før fristen. Koble til Database: Var den andre sprinten, her satte vi en frist på 3 uker, siden vi så på det som en mer omfattende sprint. Her la vi mye tid for å lære sammenhengen mellom Stored Procedures og Inside Database. Design på Produktet: Var ikke noe so vi la mest vekt på, men satte av en to ukers sprint til dette, vi måtte først planlegge hvordan det skulle se ut. Vi bestemte oss fort for at design ikke var noe vi ville bruke for mye tid på og fant et ferdig design som passet våre designskisser. Vi prøvde holde oss til Scrum gjennom hele prosessen, ved å sette forskjellige sprinter som skulle gjøres innenfor noen par uker. Dette holdt frem til slutten hvor det ble litt mer desorganisert når deadline nærmet seg. Begreper innenfor Scrum Daglig Scrum: Et møte på rundt 15 minutter, hvor utviklerne oppdaterer hverandre om hva de har gjort, og hva de tenker å gjøre de neste dagene. De må da planlegge fremover, i forhold til arbeidet som er blitt gjort de siste dagene. Product Backlog: Er en liste med ting som er nyttig for produktet under utvikling. Det er produkteieren som er ansvarlig for innholdet, og hva som blir prioritert. Sprint: Står forklart på forrige side. Inkrement: Er en liste med alle Product Backlog som har blitt utført. Sprint Backlog: Er en liste med Product Backlog, som producteier ønsker med i de kommende sprintene Lokalisert Lokalisert

15 Sprint-Mål: Er et mål som utviklingslaget jobber for å nå, innen en sprint. Hvis utviklerne finner ut at det er behov for endringer, må de diskutere med produkteieren for å endre målet. Gruppen hadde gjennom prosjektet to faste dager i uka hvor vi møttes for å jobbe. Dagene ble satt opp etter når det passet oss med henhold til forelesningene i andre fag. 2 tirsdag og torsdag ble de faste dagene, hvor vi på tirsdager jobbet på Høgskolen og torsdager hos TC. Samarbeidet mellom gruppemedlemmene har gått fint, gruppen har hatt en veldig god tone, og vi har blitt venner gjennom prosjektet. Det har ikke utartet seg noen konflikter i gruppen, som har hindret framdriften til prosjektet. Forarbeid: I begynnelsen brukte vi mye tid på læringsprosessen. Vi fikk god hjelp av veiledere hos TeleComputing. Det var mye å sette seg inn i alle språk og rammeverk vi skulle bruke til programmering, som var SQL, C#, jquery, Ajax, Javascript, Durandal og knockout. Før vi begynte å sette oss inn i de nye språkene og rammeverkene regnet vi med at dette skulle ta litt kortere tid, men det viste seg å være mer stoff enn forventet. Durandal kom ikke inn før sent i prosjektet. Som følge av dette ble utviklingen litt forsinket, men ting ble litt klarere for oss etter hvert, og gruppen greide å hente oss og inn og vi er tilfredse med de kravene som er innfridd. Datainnsamling TeleComputing ga oss føringer på utviklingsspråk og noen av rammeverkene vi skulle benytte for utvikle systemet og hovedlinjene av hvilke elementer som burde være med i et slikt system. Vi startet med et møte med TC hvor vi fikk en kort innføring i Visual studio og sammen laget et "Hello world!" script eksempel ved hjelp av C#, WebApi, HTML og Knockouts. Styringsdokumenter Statusrapport: En rapport som ble levert høst 2013, for å vise at vi er i gang med å finne gruppe og oppdragsgiver. Når denne ble utført var vi kun to på gruppen, Vi valgte å rekruttere et siste gruppemedlem Fredrik Joramo etter denne deadline. Prosjektskisse: Var det første som ble opprettet, gruppen utførte denne januar 2014 og den ble levert samme måned. Her ble det kort forklart hva slags oppgave vi har satt oss ut på, og 6

16 litt om TeleComputing som var oppdragsgiver. Vi gikk også litt inn på hva oppdragsgiver ønsker at vi lager, og hvilke krav produktet skal innebære. Fremdriftsplan: Fremdriftsplan ble laget tidlig i prosjektet og var veldig nyttig for gruppen. Planlegging av et prosjekt er noe av det viktigst å gjøre før man setter i gang med en slik prosess, derfor var dette noe av det første, gruppe satte opp. Figur2: Her ser vi fremdriftsplanen, hvor de sorte boksene viser hva som skal ha vært gjort og når det skal utføres, Den røde boksen viser når innleveringsfristen er. Dato står øverst i bildet. Dette gav oss en veldig oversiktlig måte, for å holde oversikt på hva som skulle hvert gjort og når. Fremdriftsplanen ble kun justert litt underveis, på grunn av sykdom, og et av gruppemedlemmene måtte reise utenlands. Fremdriftsplanen ble et nyttig verktøy både under planleggingen av prosjektet, og under utføringen. Dagbok Gruppen har ført opp en dagbok helt fra dag 1 i oktober 2013, og frem til innleveringen 27. mai. Dagboken ble ført opp i et Word dokument, og oppdatert hver uke. Rissikoplanlegging Risiko Sannsynlighet Følger Sykdom Veldig høy Moderat Ikke rekker deadline for levering Moderat Katastrofalt Tekniske Problemer Moderat Alvorlig 7

17 Faglige problemer Høy Akseptabelt Motivasjon/Enkelte medlemmer gjør ikke oppgavene sine Liten Alvorlig Endringer i prosjektet underveis Moderat Akseptabelt Tap av gruppemedlem Veldig lav Alvorlig Risikostyring Risiko Sykdom Ikke rekker deadline for levering Tekniske problemer 3 Forebygging Viktig å kommunisere hele tiden gjennom facebook gruppesiden, og informere gruppemedlemmene med en gang man blir syk slik at kritisk arbeid kan settes til andre gruppemedlemmer. Ha hyppige møter i god tid før deadline og hele tiden vurdere hvilke om det er noen av kravene som burde utsettes for å få et fungerende produkt til slutt Bruk av skylagring, slik at nødvendige dokumenter og koder ikke forsvinner hvis en pc streiker. I tillegg til skylagring har vi en reservekopi på lokal maskin. Alle gruppemedlemmene har hver sin pc, og vi ser på det som veldig usannsynlig at alle tre streiker, hvis en streiker har vi fortsatt to som kan programmere, da kan sistemann hjelpe de som koder eller finne en annen maskin Større feil i koden som ikke oppdages før det Benytte et versjoneringssystemslik at vi kan 3 Lokalisert

18 er gjort mange endringer Faglige problemer rulle tilbake til fungerende versjon Viktig å heletiden holde kontakt med kontaktpersoner, de jobber som programmerere til vanlig og kan hjelpe oss når vi har problemer. Motivasjon/Enkelte medlemmer gjør ikke oppgavene sine Viktig å ta opp uenigheter i plenum, og diskutere med alle gruppemedlemmene forskjellige løsninger til vi kommer til enighet. Endringer i prosjektet underveis Tap av gruppemedlemmer På alle prosjekter kan ting endre seg underveis, derfor er det viktig å ha jevnlige møter med gruppa, men også med veileder og kontaktpersoner, slik at vi kan gjøre avtaler, og diskutere problemer. Tap av gruppemedlem ser vi på som usannsynlig, siden vi alle har sagt at vi er veldig motiverte på å føllføre jobben nå. Hvis dette skjer må vi sette oss ned med en gang å fordele arbeidsoppgavene på nytt, og belage oss på mer arbeid fremmover. Risikohåndtering Gruppen var forbredt på å sette av mye tid i begynnelsen av semesteret til tilegning av kunnskap i teknologier vi ikke hadde kunnskap om. Programmeringen til prosjektet ble dermed forsinket noe vi var fullt klar over at kunne skje. Det viste seg å være mer å sette seg inn i enn vi hadde regnet med. Dette medførte mye arbeid mot slutten av prosjektet. 9

19 Forhåndskunnskaper 4 HTML/CSS: Alle gruppemedlemmene hadde tidligere hatt faget Webprosjekt, hvor vi fikk et innblikk rundt denne teknologien. Det handler om og bygge og designe nettsider, og det var nettopp dette vi brukte HTML og CSS til, og lage gruppeside og designe produktet våres. JavaScript: JavaScript var noe vi kunne lite om fra tidligere programmerings fag. Dette er et språk som brukes til å legge til dynamiske elementer til nettsider. Alle viewmodeller har vi skrevet i JavaScript. MS SQL: Alle gruppemedlemmene hadde tidligere hatt faget Database, hvor SQL var en stor del av pensumet. SQL brukes til å hente ut og legge til informasjon i en database, og det er nettopp dette vi har brukt det til. Vi bruker SQL som datalager for applikasjonen og skriver og henter data fra C#. Arbeidsforhold: Gruppen har i hovedsak arbeidet i Høgskolen sine lokaler og i TeleComputing sine kontorer. Vi har også arbeidet litt individuelt hjemmefra hver for oss for. Drengsrudbekken: Hver torsdag gjennom hele prosjektet har gruppen sittet samlet på TeleComputing sine lokaler, Drengsrudbekken i Asker. Dette var et helt nytt bygg med fantastiske arbeidsforhold og kontorer, vist på bildet under. HIOA: På tirsdager møttes gruppen på HIOA sine lokaler i 4. etg i Pilestredet 35 på datatorget, hvor vi har for det meste benyttet oss av gruppe rommene til Høgskolen. 4 Lokalisert Lokalisert Lokalisert Lokalisert

20 Prosjekthjemmeside Prosjekthjemmeside var et krav at gruppen opprettet tidlig i prosjektet, denne skulle brukes til å gi informasjon om prosjektet og til å laste opp nødvendige dokumenter. Hjemmesiden til gruppen er skrevet i HTML/CSS og er vist på bildet under. Utviklingsprosess Her beskriver vi gangen i prosjektet, hvordan vi jobbet i henhold til planen, hvordan vi utviklet produktet fra programmering til design, hvilke utfordringer vi møtte underveis. UML modeller Unified Modelling Language - UML - er et standardisert grafisk språk for å kommunisere strukturen og oppførselen, for å kontrollere og visualisere arkitekturen i et system. Den gir bedre forståelse av systemet vi skal utvikle og kan hjelpe til å håndtere risiko (Østbø, M. udatert) 5. Modellering var viktig for å forstå funksjonaliteten i systemet vi skulle utvikle. Her under beskriver vi de ulike modelleingsspråk som vi har benyttet: Use case Et Use Case er ment å representere systemfunksjoner for det generelle tilfelle. Og er en konkret gjennomgang av en sesjon for brukeren. Det representerer egentlig systemets formål. 5 Østbø, M. (udatert). Unified Modellering Language (UML). Hentet Mai 24, 2014 fra 11

21 En Use Case eller bruksmønster hjelper til å få en bedre oppfatning av om hvem/hva som utgjør systemets omgivelser og hvilken funksjonalitet systemet skal ha. Hensikten er å skaffe et overblikk over funksjonalitetskravene til systemet. Kravene gjelder kun hva systemet skal kunne gjøre og ikke hvordan. For eksempel spør man ikke etter sikkerhetskrav, kvalitetskrav, responstid, rammer i form av kostnader, tidsfrister, operativsystemer, maskinmiljø osv. Omgivelsene er mennesker og andre systemer som spiller en rolle i forhold til systemet vi skal lage (Hansson, 2007, s. 4). 6 For å få oversikt over systemets funksjonalitet i forhold til kravspesifikasjonen benyttet vi både Use Case diagram og Use Case beskrivelse (se vedlegg). Noe som har spillet en viktig rolle i designprosessen og utviklingsprosess. Her under fins en tabell med liste over de forskjellige bruksmønsterene samt aktører og deres krav. Aktivitetsdiagram Aktivitetsdiagrammer viser forretningsprosesser og arbeidsprosesser. Aktivitetsdiagram brukes til å beskrive hvordan aktivitetene må utføres i en operasjon og hvor de er avhengig av hverandre. Det viser også at hvilke aktiviteter skal avsluttes før et annet skulle startes og hvilke aktiviteter må utføres parallelle (Grønning, K. 2008). Klassediagram Klassediagram er det viktigst og mest brukte blant de alle UML diagrammene. Det ble brukt til å definere den statiske strukturen av klasser og deres egenskaper samt assosiasjoner mellom de ulike objekter Utviklingsfasen Forstudie: Forstudie var en fase i prosjektet hvor vi leverte statusrapport, prosjektskisse og forprosjektrapport. Statusrapporten ble gjort først, og var en beskrivelse rundt gruppen og hvordan vi lå an i søkeprosessen etter virksomhet. Prosjektskisse var det neste som ble gjort, da hadde gruppen blitt dannet, og her beskrev vi detaljene i prosjektoppgaven. Prosjektskissen ble levert Den siste innleveringen i forstudie, var Forprosjektrapporten. Den ble levert , og inneholder en mer detaljert beskrivelse 6 Grønning, K. (2008). UML: Unified Modeling Language: Aktivitetsdiagram. Hentet Mai 24, fra: 12

22 av oppgaven, og dens rammebetingelser. Hensikten med disse stadiene, er at skolen skal forsikre seg om at studentene utfører en oppgave, som er ønsket til et hovedprosjekt på IT linjen på Høgskolen. Dette er også fint i tilfelle misforståelse, mellom studenter, veileder og oppdragsgiver. Presentasjon av konsept: 16. januar hadde vi et møte med oppdragsgiver, hvor de presenterte forslaget til oppdrag de ville ha utført. Vi hadde da allerede hvert i kontakt med TeleComputing en stund, men det var først nå oppdraget var godkjent av HiOA og vi kunne begynne. Begge parter ble under møtet enige om oppdraget som ble presentert, og vi fikk flere innspill til hvordan vi burde gå fram i prosessen og hva som skulle gjøres, av veileder Kristoffer Hovland. Oppdraget skulle inneholde følgende: Omstart av servere Gi en mer oversiktlig metode for oppdragsgiver til å utføre reboot Sjekke om server kommer opp etter reboot Kunne sette tidspunkt for reboot på forhånd Loggføre hver eneste boot På slutten av møtet fikk gruppen litt kontakte med en Arild Bakken som har vært i TeleComputing lenge og har gode programmeringskunnskaper. Vi fikk hjelp og veiledning av ham og han ga oss et lite innblikk i hvordan dagens løsning fungerte. Utviklingen av produktet, ble startet med en gang vi følte oss trygge med de teknologiene som skulle benyttes, til utviklingen. Gruppen følte det var nødvendig med en læringsfase før vi satte i gang med utviklingsfasen. Vi programmerte en del i begynnelsen også, men mye måtte gjøres om etter hvert som vi fikk bedre forståelse for hvordan språkene og rammeverkene fungerte. Vi valgte å legge hovedvekten på selve produktet og dens krav til bruk. Når vi begynte utviklingen hadde vi allerede skaffet oss de nødvendige verktøyene, Visual studio 2013, med Team Foundation Server kunne alle gjøre endringer fra sin maskin og få beskjed dersom det var konflikter. Vi satt de to første gangene på et grupperom hos Telecomputing, sammen med to ansatte Sebastian Henriksen og Kristoffer Hovland. De hjalp oss med å komme litt i gang med å sette opp de første skriptene, siden de jobber som systemutviklere til vanlig. Vi tok noen slike sesjoner gjennom prosjektet når vi følte vi hadde mestret en ting og var klare for utfordring. Utenom dette programmerte vi stort sett for oss selv, men hadde alltid muligheten til å spørre de om hjelp hvis vi lurte på noe. 13

23 Pairprogramming 7 Er en metode for utvikling av programvare, dette innebærer at en sitter å koder, men en annen gruppemedlem sitter ved siden av, følger med og kommer med innspill. Dette er noe gruppen har brukt til tider, hvis det er en som sliter litt med programmeringen og har behov for å støttes litt opp. Dette er også en veldig fin måte hvis to på gruppa har forskjellige kvalifikasjoner. Testing: Se testrapporten for en detaljert beskrivelse om de ulike testene som er utført. 7 Lokalisert

24 Dokumentasjonsfasen Styringsdokumentasjonen var noe vi arbeidet med i starten av prosjektet, og fortsatte litt med gjennom hele prosessen. Denne inkluderer dagbok, prosjektskisse, forprosjektrapport, fremdriftsplan og kravspesifikasjon. Prosjektskisse ble allerede levert før jul, og prosjekt skisse, fremdriftsplan og kravspesifikasjon ble utarbeidet og levert i januar. Dagbok ble ført hver uke, gjennom hele prosjektet. Sluttdokumentasjonsfasen var det siste, gruppen begynt å jobbe med. Microsoft Word var verktøyet som ble brukt til å skrive rapporten. Vi leste igjennom dokumentasjonsstandarden som ligger ute på web for alle studenter, og fant her ut at sluttrapporten skulle deles opp i flere hoveddeler, litt opp til hver gruppe å bestemme. Vi valgte dermed å dele sluttrapporten opp i 4 hoveddeler, og samle dem til en sluttdokumentasjon. Presentasjon: Det minste kapittelet, bare noen generelle forord, litt om oss og oppdragsgiver og en takk til alle medvirkende. Prosessrapport: Som beskriver hvordan vi har jobbet gjennom hele prosjektet. Produktrapport: Forklarer de tekniske aspektene til produktet, og hvordan de fungerer. Brukerveiledning: Et lite kapittel som tar for seg hvordan produktet skal brukes. Produktrapporten og testrapporten valgte vi å fullføre i slutten av prosjektet. Det er greit å være ferdig med utviklingen før man går i gang med disse, men notater vi har gjort oss underveis var meget nyttige. Prosessdokumentasjonen var det først vi begynte med, og vi har jobbet litt med gjennom hele prosjektet. Vi begynte for alvor med denne i april, for da hadde vi allerede jobbet en del, og vi kunne da gå i gang med å forklare litt om hvordan vi hadde jobbet. Produktrapporten ville vi vente med, til vi var så å si ferdige med utviklingen, i tilfelle vi skulle støtte på noen eventuelle endringer. For å lage en testrapport må produktet være klart til test, så det ble det siste gruppen tokk for seg. Verktøy og Teknologier Visual Studio 2013: Visual Studio er et program som brukes til programmering, og brukes av de ansatte hos Telecomputing hver dag. Dette var et veldig nyttig program for oss gjennom 15

25 denne prosessen, og vi satte opp en server som gjorde at alle kunne koble seg til å gjøre endringer fra sin egen pc. 8 Dropbox: Dropbox er en skybasert lagringsenhet, hvor du kan lagre filer på web som du kan hente fra hvilken som helst pc, så lenge den har internett tilgang. Gruppen inviterte hverandre, slik at alle kunne legge ut arbeid som alle hadde tilgang til å se. Veldig nyttig verktøy som gjør det lettere å samarbeide. 9 Facebook: På det første gruppemøtet i oktober, satte vi opp en gruppeside på facebook. Denne gruppesiden har blitt brukt til å kommunisere, når vi ikke sitter samlet. Det gjorde det også enkelt for oss å sende linker til nyttige sider, som vi ville se på og lære av. Microsoft Word: Microsoft Word er et tekstredigeringsprogram, og bruker til å skrive innhold i dokumenter, og plassere grafikk. Dette har hovedsakelig blitt brukt i sluttrapporten, men også til skisser og dagbok. Microsoft Excel: Microsoft Excel er et program basert på regneark, og brukes ofte til å behandle mattematikk, tall og analyser. Gruppen brukte dette verktøyet til å lage fremdriftsplan, til hele perioden. Microsoft Visio 2013: Microsoft Visio er et diagram verktøy, som gruppen brukte til å lage prototype av database diagrammene. 10 Notepad++: Notepad++ er et verktøy som brukes til programmering, den ble kun brukt i starten av prosjektet til å lage hjemmeside til gruppen. Etter dette fikk vi oss Visual Studio som er et mye bedre og omfattende verktøy til programmering, og Notepad++ ble da byttet ut. Paint: Paint er et grafisk tegneprogram, som man kan tegne og redigere bilder med. Gruppen har brukt dette til å justere, og redigere bilder og diagrammer, som ble lagt i sluttraporten. Dia/Diagram Editor: Dia er et tegne program, som brukes til å designe ulike diagrammer. Dia støtter mer enn 30 forskjellige diagramtyper som flytskjemaer, nettverksdiagrammer, databasemodeller. Dia kan lese og skrive en rekke forskjellige raster og vektor bildeformater. 11 E-post: Når gruppemedlemmene kom i kontakt med hverandre, var dette via e-post. Da fortsatte vi å kommunisere med dette, frem til første gruppemøte, hvor vi satte opp en facebook gruppe. Etter dette ble e-post brukt til å kommunisere med veileder Boning Feng. 8 Lokalisert Lokalisert Lokalisert Lokalisert

26 Kommunikasjon Gruppen hadde sitt første møte med veileder Boning Feng, Her fikk vi en liten introduksjon til hovedprosjektet, og om generelle råd. Vi fortsatte å holde jevnlig kontakt, vi fikk meget god faglig hjelp hos TeleComputing så vi bruke veileder mest til spørsmål rundt rapportering og praktiske ting rundt hovedprosjektet. Gruppen hadde sitt første møte med kontaktpersonene Erling Wittusen og Kristoffer Hovland allerede Det ble da ingen møter med de før over nyttår. Fra da jobbet vi i TeleComputing sine lokaler, hver torsdag gjennom hele prosessen. Her fikk vi holde jevnlig kontakt med kontaktpersonene, og det ble også holdt flere møter. I disse møtene ble det først diskutert hva vi skulle lage, det ble drøftet litt om eksisterende løsning og ny funksjonalitet. Etter hvert hjalp de oss litt i gang med å programmere. Vi føler at kommunikasjonen med kontaktpersonene har vært utrolig bra, siden vi så dem ofte og det ene gruppemedlemmet Fredrik Joramo kjenner dem godt som kollegaer. Utfordringer Den største utfordringen gruppen hadde, var programmering i C#. Kun et av gruppemedlemmene hadde tidligere erfaring med dette kodespråket. De eneste teknologien vi kunne fra før var HTML/CSS og SQL, utenom dette måtte vi tilegne oss kunnskapen. Gruppen måtte bruke mye tid på å sette oss inn i dette. Vi hadde noen utfordringer med Visual Studio og database ettersom vi ikke hadde en egen SQL server og jobbe mot, det ble brukt separate databaser på hver av gruppemedlemmenes maskiner og dette skapte til tider litt trøbbel. Vi møtte på en stor teknisk utfordring mot slutten av programmerings prosessen. Når vi byttet navn på domene til alle filene, sluttet alt å virke. Det var mulig å navigere seg rundt på siden, men alt stoppet og virke sporadisk med feilmeldingen "undefined undefined". Dette var var nok på grunn av noen referanser til gamle navn som vi ikke klarte lokalisere. Vi ble nå veldig bekymret, for om vi kanskje ikke skulle få produktet til å virke tilslutt. Det som reddet oss med denne utfordringen, var at vi hadde TFS som versjoneringssystem. Dette gjorde at vi bare kunne gå tilbake, til slik koden så ut for noen timer siden, eller tilbake til forrige oppdatering. Vi hadde også kontakt med våre veiledere i TeleComputing, som gav oss råd og tips til hvordan vi skulle håndtere slike situasjoner. Avslutning Å jobbe med et så stort prosjekt som dette, er utrolig lærerikt. Alt arbeid vi gjør bringer frem utfordringer og lærings muligheter. Gruppemedlemmene har lært utrolig mye, under dette prosjektet. Vi hadde alle vært med på prosjekter i andre fag, men ikke i nærheten av størrelsen med dette. Vi har erfart hvor stor arbeidsmengde som kreves for et så stort prosjekt som dette, og hvor mye det krever av planlegging for at gruppen skal fungere effektivt. Vi har høstet mange erfaringer om hvordan et prosjekt burde planlegges og om 17

27 ting vi vil gjøre annerledes i senere prosjekter. Gruppen har blitt utfordret til å lære nye programmeringsspråk. Vi føler nå mot slutten, at vi kanskje burde begynt tidligere med å sette oss inn i det nye stoffet, så vi hadde fått mer tid til utvikling i slutten av prosjektet Læringsutbytte Vi har blitt utfordret til å lære nye språk, som har hvert inntresant og lærerikt for videre karriere. Vi har også lært hvordan å bruke teknologien på et ordentlig prosjekt, og ikke bare simulerte problemstillinger, som vi vanligvis gjør på høgskolen. Vi føler også at vi har utviklet oss til å jobbe mer selvstendig, og evne til å samarbeide i grupper. Det er bra for vår personlige utvikling at vi har fått bryne oss på et større prosjekt. Det har vært utrolig verdifull læring, å jobbe som konsulenter for en bedrift, og vi har fått en god smak på hva som venter oss når vi kommer oss ut i arbeidslivet. Konklusjon Alt i alt er gruppen utrolig fornøyd med det vi har lært på under dette prosjektet, vi har vært i et arbeidsmiljø hos TeleComputing som var veldig aktivt, vi fikk god kontakt med erfaringsrike ansatte som driver med samme fagfelt. Selv om vi gjerne skulle hatt mer tid til denne utviklingen, så føler vi at vi har utviklet et kvalitetsprodukt, som vi er stolte av. Det er mange timers arbeid som ligger bak utviklingen av systemet, og vi mener det er skrevet på en slik måte at det er lett og vedlikeholde, utvide eller gjenbruke deler av koden i andre prosjekter. Videre Utvikling Forslag til videre utvikling er dokumentert i produktrapporten 18

28 1

29 Table of Contents Forord... 4 Informasjon til leser... 5 Arbeidsfilosofi... 5 Produktbeskrivelse... 5 Kode standard... 6 Lagdeling... 6 Standard navngivning... 6 REST... 7 Optimaliseringer... 7 Versjonskontroll... 7 Server siden... 9 Database... 9 Databasediagram... 9 SQL tabeller Stored Procedures Database tilkobling Modeller Controllers Eksterne biblioteker Insight Database LINQ Business logic layer WmiAccess AdAccess JobManager Logging Regel endring Job System- og databasefeil Brukergrensitt Design Durandal Knockout Hjelpe scripts MomentJS

30 Transitions Knockout mapping Knockout validation Bootstrap Datepicker Jquery Datatables Morris og Raphael Bootstrap Growl Klient-Server kobling Home / Status Page List Rules Add Rule List Servers ServerLog Forslag til videre utvikling Utfordringer

31 Forord Dette er produktrapporten om Server Boot systemet vi har laget for TeleComputing AS i forbindelse med hovedprosjektoppgave våren Produktrapporten er delt i serverside og klientside. Klientsiden er i rapporten kalt brukergrensesnitt. Serverside dokumentasjonen tar for seg et og et lag fra databasen og opp til kontrollerne som er kommunikasjonsleddet mellom serverside og brukergrensesnitt. Rapporten er beregnet på de som skal vedlikeholde eller videreutvikle systemet. 4

32 Informasjon til leser De fleste uttrykkene som forklarer spesifikke ting ved kodespråket, navn på variabler/funksjoner eller teknologier er på engelsk, vi har oversatt en del av uttrykkene der vi har funnet passende norske oversettelser. Referanser er gjort på det stedet i rapporten uttrykket er nevnt for første gang. Det forventes at leser har kunnskap om C#, JavaScript og RESTapi for å bruke produktdokumentasjonen Alle kode som er dokumenter i denne rapporten er kopiert inn fra Visual Studio for å få med "syntax highlighting" og sort bakgrunn for å skille den fra resten av teksten. Vi mener dette gjør den lettere å lese og skaper et godt skille mellom programkode og forklaringer. Arbeidsfilosofi Vi har lagt vekt på å lage et modulært system som skal være lett og vedlikeholde, utvide eller gjenbruke deler av koden i andre prosjekter. Vi har gått for klar lagdeling mellom server og klient side. Produktbeskrivelse Systemets oppgave er å utføre rutinemessig omstart av Microsoft Windows servere i et Active Directory1 domene. Det støtter alle versjoner av Windows fra, men ikke inkludert, Windows NT. Det er designet for å kunne styre omstart av tusenvis av servere, det er derfor ikke meningen at man skal trenge å legge inn servere selv eller bestemme egne tidspunkter og intervaller for hver enkelt server. Systemet har en egen metode for å oppdage servere. Denne søker gjennom de konfigurerte domenene og finner maskinobjektene som så legges til i systemets serverdatabase. Systemet har nå informasjon om alle servere i de angitte domenene, men foreløpig er det ingen ting som sier at de skal gjøre noe. Det er her reglene kommer inn. Regler opprettes av brukerne av systemet, her spesifiseres en RegEx2 streng som skal matche hvilke servere regelen skal gjelde. I tillegg legges det inn informasjon om når regelen skal kjøre første gang og intervall. Regelen sier noe om hvilke servere den skal kjøres på og tidspunkt, vi har «Job Steps» som sier hva slags jobber som skal utføres når regelen kjører. Disse jobbene velger man samtidig som regelen opprettes og legger inn eventuelle parametere som trengs for de forskjellige. En av disse jobbene er omstart, andre er jobber som kan sjekke at visse tjenester har startet opp igjen eller bare sjekke at en server svarer på WMI3. Det er lett og utvide med andre jobb steg på senere tidspunkt. En egen metode kjøres i gitte intervaller og oppretter alle jobbene som skal kjøres i løpet av det angitte tidsintervallet, alle jobbene lagres i databasen. En annen prosess plukker opp disse jobbene og kjører dem i henhold til starttidspunkt angitt i jobben. Et viktig aspekt ved det 1 Lokalisert på 2 Lokalisert på 3 Lokalisert på 5

33 nye systemet er logging av hendelser og feilsituasjoner. Alle jobber som utføres, regler som endres og feilmeldinger vil logges til egne tabeller i databasen. Kode standard Lagdeling Lagdeling er et viktig element i en oversiktlig applikasjon som lett skal kunne vedlikeholdes over tid. Med god lagdeling er det også lett å gjenbruke deler av koden i andre situasjoner. I vår løsning har vi følgende lag: User Interface Business Logic Models Test Alt som har med Javascript og HTML å gjøre samt WebAPI kontrollere Alle klasser som gjør systemspesifikt arbeid. For eksempel opprettelse og kjøring av parallelliserte jobber, kontakt med servere og Win32 API Her ligger alle modellene. Vi har holdt oss til mønsteret fete modeller og tynne kontrollere. Alle modellene styrer seg selv når det kommer til lagring og henting av data. Ettersom databaseklassen vår kun returnerer en connection string har vi valgt å ikke legge denne i et eget databaselag Unit tests Lagene er delt opp i namespace s på formen «TeleComputing.ServerBoot.UserInterface» Standard navngivning Alle variabler i objekter har navn som starter med stor forbokstav og har stor forbokstav i alle påfølgende ord. Alle parametere i metoder starter med liten forbokstav og har stor forbokstav i alle påfølgende ord. Namespace starter med stor forbokstav og har og har stor forbokstav i alle påfølgende ord. Klassenavn starter med stor forbokstav og har og har stor forbokstav i alle påfølgende ord. Tabeller starter med tbl for Tables, så SB for serverbot også et bekskrivende navn, for eksempel tblsbjobstep Stored Procedures starter med liten p for procedure, så SB for Serverboot også et beskrivende navn, for eksempel psbgetjobsteps 6

34 TeleComputing har gjeldene standard for servere, eksempelnavn ZD2OSLSSQ001: o ZD2 Domenet o OSL Lokasjon, hvor serveren er fysisk plassert o SSQ S for server SQ for type server, SQL i dette tilfelle o 001 ID nummer TeleComputing har gjeldene standard for cluster servere ZD2OSLCH1CN1 o CH1 C for cluster, H1 for Hyper-V cluster 1 o CN1 Cluster node 1 REST Bruker REST metodikk for å eksponere data mot klient eller server. Optimaliseringer For at websiden skal være raskest mulig benytter vi javascript optimalisering med Weyland 4. Denne går gjennom alle javascriptene og samler de til en lang streng slik at filen tar minst mulig plass. Mange av de 3dje parts javascriptene vi benytter kommer med lisenser som blant annet sier hvem som har laget det og at lisensen må nevnes der det er brukt. Weyland legger derfor inn alle disse kommentarene i toppen av den optimaliserte filen slik at ingen lisenser blir brutt. På serversiden har vi forsøkt og skrive mest mulig lesbar, men samtidig effektiv kode. Versjonskontroll For å ha kontroll på koden og ikke mins mulighet til å rulle tilbake ved større feil har vi benyttet Team Foundation Server5. Vi opprettet en Visual Studio Online Basic konto6 hvor det ble gitt tilgang til alle gruppemedlemmer. TFS er fullt integrert med Visual Studio så det gjør det enkelt og sjekke inn endringer etter hvert og sikrer at flere kan kode på systemet uten konflikter. Når det oppstår konflikt finnes en merge funksjon hvor man får opp begge filer og kan velge hvilke endringer som skal lagres per fil. Vi fikk god bruk for denne da vi forsøkt og endre navn på prosjektene i Visual Studio løsningen vår og ingen ting fungerte stabilt etterpå. Krav for kjøring av modulene Selve webapplikasjonen må ligge på en web server server med ASP.NET 4 registrert i IIS 77. Tabellene og prosedyrene legges i en database på en MS SQL server I DbRepository klassen legges tilkoblingsstrengen til databasen. Det er tre konsoll applikasjoner som aktiveres av Windows scheduled tasks. DiscoverServers.exe som kjører metoden DiscoverServers, CreateJobs.exe kjører metoden CreateJobs og RunJobs.exe kjører metoden RunJobs. 4 Lokalisert på 5 Lokalisert på 6 Lokalisert på 7 Internet Information Services 7

35 Programfil Klasse/Metode Parameter 1 Parameter 2 DiscoverServers.exe AdAccess/DiscoverServers CreateJobs.exe JobManager/CreateJobs Fra tid/dato tid/dato RunJobs.exe JobManager/RunJobs Språk Alle variabelnavn og kommentarer i koden er på engelsk. 8

36 Server siden Her beskrives server siden av koden. Dette består av lagene database, lagrede prosedyrer, modeller, og kontrollere som eksponerer et antall metoder via WebAPI som nåes via http protokollen. Database Tabeller og prosedyrer skrevet i Transact-SQL 8 Databasediagram 8 Lokalisert på 9

37 10

38 SQL tabeller Vi benytter primærnøkler for identifikasjon og fremmednøkler for å beskrive relasjoner mellom tabellene. CREATE TABLE [dbo].[tblsbrulejobstep] ( [pkid] INT IDENTITY (1, 1) NOT NULL, [fkjobsteptemplate] INT NOT NULL, [fkrule] INT NULL, [nstep] INT NULL, [nsteponfail] INT NULL, [sparameter1] NVARCHAR (50) NULL, PRIMARY KEY CLUSTERED ([pkid] ASC), FOREIGN KEY ([fkjobsteptemplate]) REFERENCES [dbo].[tblsbjobsteptemplate] ([pkid]), FOREIGN KEY ([fkrule]) REFERENCES [dbo].[tblsbrule] ([pkid]) ); Stored Procedures Stored procedures legges på som et ekstra abstraksjonslag mellom programkoden og databasen. Alle gjør en spesifik ting og gjør programkoden lettere og lese da man slipper å definere spørringer direkte. Det viktigste aspektet ved å gjøre det på denne måten er ved evt endringer i databasen. Skulle man endre strukturen eller lignende trenger man bare å endre i stored procedures, dette letter også muligheten for bakoverkompabilitet da en prosedyre kan vise data'en slik den ble presentert i forige versjon av programmet, mens en annen kan supportere presentasjonen i den nye versjonen. Her har vi valgt ut en av de mer omfattende prosedyrene for å vise mulighetene man har. Alle variabelnavn som begynner er verdier prosedyren forventer å få fra koden. Insight mapper disse fra et innsendt objekt direkte Et RuleJobStep objekt har fremmednøkler mot andre tabeller. I denne prosedyren sjekker vi om de faktisk finnes før vi forsøker å lagre og kaster en beskrivende feilmelding om de ikke gjør det. Når alt stemmer kjøres den faktisk INSERT kommandoen. Output bestemmer hva prosedyren skal returnere, i alle create metoder returneres id'en til objektet som blir opprettet CREATE PROCEDURE NVARCHAR(50) = NVARCHAR(50) = null AS is not null begin 11

39 = scommand from tblsbjobsteptemplate where pkid end is null begin RAISERROR (15600,-1,-1, 'psbcreateserver cannot find referenced job step'); end is not null begin = sname from tblsbrule where pkid end is null begin RAISERROR (15600,-1,-1, 'psbcreateserver cannot find referenced rule'); end INSERT INTO tblsbrulejobstep( fkjobsteptemplate, fkrule, nstep, nsteponfail, sparameter1 ) OUTPUT @Parameter ); Database tilkobling Alle modeller benytter den abstrakte klassen DbRepository når de skal koble seg til mot databasen. Her går denne mot en lokal database på en av utviklingsmaskinene, når systemet skal settes i produksjon vil det bli byttet til en MS SQL server. public abstract class DbRepository { public static IDbConnection GetConnection() { return new Source=(localdb)\Projects;Initial Catalog=ServerBoot;Integrated Security=True;Connect Timeout=30;Encrypt=False;TrustServerCertificate=False"); } } 12

40 Modeller Alle objekter i systemet er representert via modeller i namespace TeleComputing.ServerBoot.Models. Alle variabler er definert med hva slags tilgang det skal være, hvilke datatype og navn på variabelen. public int Id { get; set; } public DateTime CreatedDate { get; set; } public DateTime StartDate { get; set; public int Status { get; set; Noen av modellene har også referanser til andre modeller, dette kommer av at disse har referanser til hverandre i databasen og brukes ofte i sammenheng i programkoden. public Server Server { get; set; } public RuleJobStep RuleJobStep { get; set; } For å gjøre bruken av disse så lett som mulig andre steder i koden har vi implementert egne get ere og set ere for enkelte verdier i disse. Verdiene går på fremmednøkler i databasen så her vil ServerId bli fylt med fremmednøkkelen som på grunn av vår egne set er vil legges i et nytt Serverobjekt. På den måten slipper man både et Server objekt og en separat ServerId verdi. public int ServerId { get { return Server.Id; } set { Server = new Server {Id = value}; } } public int RuleJobStepId { get { return RuleJobStep.Id; } set { RuleJobStep = new RuleJobStep {Id = value}; } } Der vi ofte trenger sammensatte verdier har vi egne get ere slik at man kan aksessere denne direkte fra andre steder i koden. public string DomainName { get { return Name + "." + Domain; } } Alle modeller er satt opp som interface 9. Et interface deklarerer alle metodene som må være med i basene som arver klassen. public interface IServerRepository { int Save(Server s); IList<Server> Get(); 9 Lokalisert på 13

41 } Server Get(int id); Server Get(string name); IList<Server> GetRegEx(string regex); void Delete(int id); void Put(Server server); Det implementeres et database interface og et test interface pr modell public class TestServerRepository : IServerRepository public class DbServerRepository : DbRepository, IServerRepository Når det skal opprettes et objekt av denne klassen utenifra kan man velge hvilke man skal lage objekt av (databaseinstans vist her) private readonly IServerRepository _serverrepository = new DbServerRepository(); På denne måten er det lett og skifte om man går mot test klasse for test eller mot databasen. Spørring mot databasen gjøres ved å hente en databasekobling og kjøre en Insight spørring. Denne kan benyttes direkte uten try/catch da Insight Database 10 har egen feilhåndtering. return GetConnection().Query<Server>("pSBGetServer", new = id }).FirstOrDefault(); I linjen over kaller vi først metoden GetConnection() som returnerer en kobling til databasen. Så kjøres et Insight Query database kall. Vi definerer at vi forventer et «Server» objekt tilbake. I parameterne sier vi hvilke Stored Procedure som skal kjøres og vi sender med en verdi, i dette tilfelle Id en til server objektet vi vil ha tak i. Siden vi bare forventer et eller ingen server objekter tilbake kaller vi FirstOrDefault(), denne vil returnere et null-objekt hvis den ikke finner noe i motsetning til First() hvor det vil bli undefined dersom ingen objekter returneres fra databasen. Når vi skal lagre et objekt til basen og forventer Id en til det nye objektet tilbake kalles ExecuteScalar med formatet på returverdien. Hva som returneres defineres i den prosedyren. return GetConnection().ExecuteScalar<int>("pSBCreateRuleJobStep", rulejobstep); De fleste modellene har to Get metoder. En for å hente alle, som returnerer en List av det respektive objektet, og en som henter ut et spesifikt objekt ut i fra en id som sendes inn som et parameter. I tillegg har de en Save metode som lagrer nye objekter og returnerer Id'en 10 Lokalisert på 14

42 den får i databasen, en Update metode for å oppdatere et objekt som returnerer hele objektet og en Delete metode som sletter et enkelt objekt. Dette er de generelle, noen har færre fordi det ikke er meningen at de skal slettes, som logg, og andre har flere som dekker mer spesifikke behov. Alle er bygget opp likt og de andre metodene er navngitt slik at det gir en forståelse for hva de gjør. Controllers Controllers er de klassene som eksponerer server koden som et Application Programming Interface (API). Alle metoder som blir eksponert for brukergrensesnittet er definert her. Det er her MS WebAPI 11 kommer inn. I toppen av hver kontroller definerer vi den generelle ruten for denne kontrolleren [RoutePrefix("Server")] Adressen hit vil da være Hver metode har en egen definert sin egen underrute (sub route) over deklarasjonen. Forskjellige metoder kan ha den samme ruten så lenge det er forskjellige parametere eller en metode per http metode (Get, Delete, Post og Put). WebAPI map'er koblingen mellom kontroller metode og http metode automatisk så lenge metoden heter noe som inneholder nøkkelordene nevnt i forrige parentes. [Route("")] public IList<Server> GetAll() { return _serverrepository.get(); } Når det er definert en subrute blir adressen i dette eksempelet: Metoden definerer også hva slags returverdi som skal sendes tilbake og inn parametere. I denne metoden henter den en inn parameter fra Uri'en 12, kaller på en metode i Server interfacet og får en liste over de objektene som matcher tilbake, så returneres denne til klienten som kalte på metoden. [Route("RegEx")] public IList<Server> GetRegEx([FromUri]string regex) { return _serverrepository.getregex(regex); } Neste metode demonstrerer to andre måter å få inn parametere til metoden. Den første er {id} i ruten sammen med int id i inn parameteren sier at det etter standard rute skal komme et tall, i dette tilfelle id'en til server. Eksempel: Den neste 11 Lokalisert på 12 Lokalisert på 15

43 er [FromBody] Server server. Her henter den verdier fra viewmodellen til websiden som kaller på metoden og forsøker og matche disse til et serverobjekt. Denne automatikken i WebAPI sparer en for mye manuelt arbeid. Når matching er ok vil metoden sende objektet videre til server repository som tar seg av oppdatering av objektet i databasen [Route("{id}")] public Server Put(int id, [FromBody] Server server) { if (server == null) return null; server.id = id; return _serverrepository.put(server); } Når WebAPI returnerer et objekt blir det automatisk konvertert til JSON format. Eksterne biblioteker Insight Database Insight er et micro ORM 13 (object-relational mapping). Object-relational mapping (ORM) is a programming technique in which a metadata descriptor is used to connect object code to a relational database. Object code is written in objectoriented programming (OOP) languages such as Java or C#. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages 14 For oss betyr dette at vi i C# koden kun trenger og tenke på slik objektene ser ut og oppfører seg i C#. 13 Lokalisert på 14 Lokalisert på 16

44 C# har et sett med typer variabler Built-in types in C# Lokalisert på 17

45 MS SQL har sitt sett med typer Types in MS SQL Lokalisert på 18

46 Spesifikasjonene på disse varier og Insight gjør en god jobb med oversetting mellom dem, på denne måten klarer vi å lagre et TimeSpan 17 i C# som en DateTime2 18 i MS SQL uten egne oversettelser. LINQ Language-Integrated Query (LINQ) is a set of features introduced in Visual Studio 2008 that extends powerful query capabilities to the language syntax of C# and Visual Basic. LINQ introduces standard, easily-learned patterns for querying and updating data, and the technology can be extended to support potentially any kind of data store. Visual Studio includes LINQ provider assemblies that enable the use of LINQ with.net Framework collections, SQL Server databases, ADO.NET Datasets, and XML documents. 19 Vi bruker LINQ i en liten grad for å lette arbeidet med å hente ut et resultatsett fra et annet basert på en funksjon som returnerer en boolsk verdi. Dette gjør det også mer leselig enn om vi skulle gjort det samme med en for løkke var servers = GetConnection().Query<Server>("pSBGetServers").ToList(); return servers.where(server => Regex.IsMatch(server.Name, regex)).tolist(); Business logic layer Både WmiAccess og AD Manager skal kjøres av en domenebruker med rettigheter til å kontakte Win32 API og søke gjennom Active Directory. De metodene som automatisk skal kjøre med gitte mellomrom skal startes av en windows scheduled task, det er her man setter hvilke brukernavn og passord tjenesten skal kjøres av. WmiAccess Denne klassen styrer all direkte kontakt med serverene. Den setter opp noen konstanter for grunnen til omstart public const uint SHTDN_REASON_FLAG_PLANNED = 0x ; public const uint SHTDN_REASON_MAJOR_OTHER = 0x ; public const uint SHTDN_REASON_MINOR_MAINTENANCE = 0x ; private const int RebootSleepTime = ; Win32 API Dll'en lastes inn. Metoden vi benytter tar inn adressen til maskinen som skal omstartes, en beskjed til event log, antall sekunders nedtelling før omstart, om applikasjoner skal tvinges til å avslutte og grunn til omstart. [DllImport("advapi32", SetLastError=true)] 17 Lokalisert på 18 Lokalisert på 19 Lokalisert på 19

47 public static extern bool InitiateSystemShutdownEx(string lpmachinename, string lpmessage, uint dwtimeout, bool bforceappsclosed, bool brebootaftershutdown, uint dwreason); GetServiceStatus public string GetServiceStatus(Server server, string servicename) Denne metoden tar et server objekt og navn på en tjeneste som parametere, kobler til serverens WMI og sjekker tjenestenes status. Den returnerer så en status som en tekst streng. //Connecting to remote WMI var scope = new ManagementScope("\\\\" + server.name + "\\root\\cimv2", _options); scope.connect(); //Executing WMI Query var query = new SelectQuery("Select Name, State From Win32_Service Where Name = '" + servicename + "'"); var wmisearcher = new ManagementObjectSearcher(scope, query); //Linq expression to get enumerable list var services = from ManagementObject x in wmisearcher.get() select x; //Getting the first object, there should be only one var service = services.firstordefault(); //Getting state of service if (service!= null) state = service["state"].tostring(); State kjøres så gjennom en switch logikk som setter status koden i jobben etter hvilke status den får tilbake GetServerWindowsVersion Denne kontakter en server via WMI og returnerer hvilke versjon av Windows den kjører. WMI klasse Win32_Service. Se GetServiceStatus for hvordan ManagementObjectSearcher fungerer. 20

48 TestWmiConnection Forsøker og kontakte en server via WMI, returnerer en boolsk verdi som sier om forsøket var vellykket. Se GetServiceStatus for hvordan ManagementObjectSearcher fungerer. RebootServer Metoden tar et serverobjekt og en referanse til et jobb objekt som argumenter. Den starter med å sette jobb status til job.status = 10; //10 = Job Initiated Først sendes en vanlig shutdown melding med "force shutdown" satt til false via InitiateSystemShutdownEx 21 var hasrebooted = InitiateSystemShutdownEx(server.DomainName, "Planned System Reboot", 0, false, true, SHTDN_REASON_FLAG_PLANNED); Denne kan feile hvis en bruker har en applikasjon oppe som spør om brukeren vil lagre arbeidet før omstart settes i gang. Hvis den feiler sendes en ny melding, denne gangen med "force shutdown" satt til true. Er ikke operasjonene vellykket denne gangen heller blir det logget en feilmelding og metoden returnerer false. Når omstart kommando har gått igjennom venter tråden i det antall millisekunder definert i RebootSleepTime før den forsøker og kontakte serveren via WMI //Waiting for server to restart System.Threading.Thread.Sleep(RebootSleepTime); //Testing connection to see if server is back up. if (TestWmiConnection(server, ref job)) { job.status = 100; // 100 = System boot OK! return true; } Oppnås kontakt logges status 100 og true returneres, i motsatt fall logges 840 og false returneres. SendUserMessage Metoden sender en beskjed til alle påloggede brukere. Dette gjøres for at brukere skal få tid på seg til å lagre alt ulagret arbeid før serveren starter om. 20 Se kapittel om logging for alle statuskoder 21 Lokalisert på 21

49 AdAccess Har alle metoder som innebærer kontakt med Microsoft Active Directory Domain Services 22. Klassen definerer en DirectorySearcher 23 som brukes for å koble til Active Directory via LDAP 24 protokollen private DirectorySearcher _ds; DiscoverServers Metoden kontakter AD og leter gjennom angitt plassering etter datamaskinobjekter (computer objects). Her vist med et testdomenet hos TeleComputing. Her setter vi opp et ingangspunkt vi til toppnivået i AD strukturen og søker gjennom alle objekter i hele domenet. Vanligvis ligger ikke slike objekter overalt og ved hjelp av LDAP strengen over kan man spesifisere hvilke OU 25 man vil begynne søket i. Den søker rekursivt i alle OU'er under den man starter i. var entry = new DirectoryEntry("LDAP://zd2.no.tconet.net/DC=zd2,DC=no,DC=tconet,DC=net"); _ds = new DirectorySearcher(entry); I TeleComputing starter alle servernavn med domenenavn, mens alle klienter starter med kundenummer. Derfor kjøres følgende søk for å få ut alle server objekter uten klienter. _ds.filter = "(&(objectclass=computer)(cn=" + domain + "*))"; var results = _ds.findall(); For hvert resultat sjekkes servernavn opp mot RegEx stringen som ble sendt med i metoden // Properties comes out as a collection, the "cn" propery will allways be in [0] var propertycollection = searchresult.properties["cn"]; var servername = propertycollection[0].tostring(); //See regex info in GetServers comment //Returns if server doesn't match the supplied regex pattern if (!regex.ismatch(servername)) continue; I test har vi brukt strengen under for å få med alle objekter som starter med 6 bokstaver eller tall. Så en s, S, c eller C, etterfulgt av 2 bokstaver eller tall så et tall, c eller C så 2 bokstaver eller tall. Dette er for å filtre ut virtuelle serverobjekter som for eksempel cluster 26 og DAG objekter 27 new Regex(@"^[a-z,A-Z,0-9]{6}[sScCnN][a-z,A-Z,0-9]{2}[0-9,cC][a-z,A- Z,0-9]{2}") 22 Lokalisert på 23 Lokalisert på 24 Lokalisert på 25 Organizational Unit - Lokalisert på 26 Lokalisert på 27 Database Availability Group - Lokalisert på 22

50 Henter ut domenenavn //Takes DNS name, tostring's it, splits at first '.' then returns the second part! var domainname = (((searchresult.properties["dnshostname"])[0].tostring()).split(new[] {'.'}, 2))[1]; Henter ut Windows versjon os = (searchresult.properties["operatingsystemversion"])[0].tostring(); Metoden sjekker så om serveren finnes fra før, dersom den gjør det oppdateres feltet LastSeen til nå. Finnes ikke serveren opprettes et nytt serverobjekt som sendes til IServerRepository for lagring til databasen. Metoden forkaster så resultat settet og returnerer void. DeactivateOldServer Dette er en metode for å deaktivere servere systemet ikke har sett i AD på en stund. Med mindre det er noe feil med AD kontakten har enten serveren blitt flyttet til en annen OU utenfor skopet til LDAP entry point, eller så er serveren fjernet fra AD og ikke medlem av domenet lenger. Når server er deaktivert vil det ikke kjøres jobber på den og man slipper at loggene fylles med unyttig informasjon om servere som ikke lenger finnes og dermed ikke kan kobles til. Metoden returnerer void. JobManager Alle generering- og kjøring av jobber gjøres i denne klassen. Vi tar oss bruk av C# sin Task 28 muligheter for å kjøre av jobbene asynkront. Ved å bruke Task slipper vi selv styre hvilke tråder som skal kjøre hva til enhver tid. Vi bare oppretter Tasks som skal kjøres og venter på at de blir ferdig. The Task Parallel Library (TPL) is based on the concept of a task, which represents an asynchronous operation. In some ways, a task resembles a thread or ThreadPool work item, but at a higher level of abstraction. The term task parallelism refers to one or more independent tasks running concurrently. Tasks provide two primary benefits: More efficient and more scalable use of system resources. Behind the scenes, tasks are queued to the ThreadPool, which has been enhanced with algorithms that determine and adjust to the number of threads and that provide load balancing to maximize throughput. This makes tasks relatively lightweight, and you can create many of them to enable fine-grained parallelism. More programmatic control than is possible with a thread or work item. Tasks and the framework built around them provide a rich set of APIs that support waiting, cancellation, continuations, robust exception handling, detailed status, custom scheduling, and more Lokalisert på 29 Lokalisert på 23

51 CreateJobs Metoden tar fra tidspunkt og til tidspunkt som parametere og oppretter jobber som skal kjøres mellom disse tidspunktene til databasen Hopper over rules som er deaktivert eller gått ut på dato. if (!rule.enabled) continue; if (rule.enddate < DateTime.Now) continue; Dersom regelens neste kjøretid er på et tidspunkt tidligere enn nå betyr det at en eller flere kjøringer har blitt hoppet over. Hvis det er skjer legges frekvensen til det antall ganger som må til for at neste kjøredato skal kommet etter nå. if (rule.nextrundate < DateTime.Now) { while (rule.nextrundate < DateTime.Now) { rule.nextrundate += rule.frequency; } _rulerepository.update(rule); } Hopper til neste hvis regel ikke skal kjøres i denne tidsperioden if (rule.nextrundate < fromdatetime rule.nextrundate > todatetime) continue; Så kommer en nøsting av løkker som oppretter alle jobbene som blir lagret i databasen. 1. While løkke som legger til frekvens inntill neste kjøretid er utenfor til tidsintervallet metoden legger til jobber i 2. foreach som itererer gjennom alle servere regelen sin RegEx matcher 3. foreach som oppretter en jobb per oppgave for en enkelt server while ( rule.nextrundate < todatetime) { foreach (var server in _serverrepository.getregex(rule.regex)) { //Skip server if disabled if(!server.enabled) continue; foreach (var rulejobstep in _rulejobsteprepository.get(rule.id)) { var newjob = new Job { Server = server, RuleJobStep = rulejobstep, CreatedDate = DateTime.Now, StartDate = rule.nextrundate, Status = 10 //10 = created }; _jobrepository.save(newjob); } } 24

52 } rule.nextrundate += rule.frequency; ProcessJob Metoden får et Job objekt som parameter. Den oppretter et JobLog objekt og setter startparameterene JobStarted, ServerId og RuleJobStepId. Det kjøres en switch på hva slags type jobb som skal utføres switch (job.rulejobstep.command) Når det senere skal legges til flere forskjellige jobb typer må de legges inn i databasen JobStepTemplate og matchene kommando må kodes inn her case "servicerunning": _wmiaccess.getservicestatus(job.server, job.rulejobstep.parameter); break; case "reboot": _wmiaccess.rebootserver(job.server, ref job); break; case "serverup": _wmiaccess.testwmiconnection(job.server, ref job); break; case "usermessage": _wmiaccess.sendusermessage(job.server); break; Til slutt settes resten av verdiene i JobLog objektet og sendes til lagring joblog.statuscode = job.status; joblog.jobended = DateTime.Now; _joblogrepository.save(joblog); RunJobs En asynkron metode som ikke tar noen parametere. Metoden må være asynkron og returnere Task for at vi skal kunne vente på at den gjør seg ferdig før hovedprosessen avslutter. public async Task<object> RunJobs() Starter med å hente alle jobber som venter i databasen og opprette et List array for Task's vi skal opprette. var jobs = _jobrepository.get(); var jobtasks = new List<Task>(); Dersom jobben skulle ha kjørt på et tidligere tidspunkt enn nå sletter vi jobben. Vi vil ikke at en server skal ta en omstart mitt i arbeidstiden hvis tjenesten er stoppet og blir startet igjen klokken 12 på en mandag. if (job.startdate < DateTime.Now) Det lagres et JobLog objekt og jobben blir slettet _jobrepository.delete(job.id); 25

53 Når det er verifisert at jobben skal kjøre en gang i fremtiden opprettes det en Task som legges i Task listen jobtasks. Hver Task får beskjed om å vente til tidspunktet definert i StartDate var newtask = Task.Run(async delegate { await Task.Delay((int)(job.StartDate - DateTime.Now).TotalMilliseconds); ProcessJob(job); }); jobtasks.add(newtask); Når en Task er opprettet slettes oppføringen fra Job tabellen i databasen. _jobrepository.delete(job.id); Venter på at alle Task's skal avslutte await Task.WhenAll(jobTasks); Logging Logging har flere funksjoner. Dersom en regel en dag slutter å fungere vil vi gjerne kunne se om det er gjort en endring nylig og man vil gjerne vite om noen servere ikke har kommet online igjen etter nattens omstart. Regel endring Når Rule kontrolleren får inn en oppdatert regel vil den skrive et gjeldene konfigurasjon til databasen tblsbrulelog før den oppdaterer regelen. [Route("{id}")] public Rule Put(int id, [FromBody] Rule rule) { if (rule == null) return null; _rulelogrepository.save(rule.id); return _rulerepository.update(rule); } Job JobLog objekter blir opprettet i ProcessJob funksjonen når jobben blir kjørt. Status blir oppdatert underveis og lagret av samme metode. 10 Job Created 20 Job Initiated 30 Successfully contacted WMI 40 User message sendt successfully 100 Sever boot OK 200 Service Running 250 Service Starting 26

54 260 Service Stopping 270 Service Stoppet 280 Service Paused 290 Undefined service status 810 Unable to contact WMI 820 Failed to initiate system shutdown 830 System shutdown already in progress 840 System reboot initiated, no contact after boot 890 Job initiated after it was supposed to run. Job terminated. Job Status codes System- og databasefeil Når systemet kaster en feil blir dette fanget opp i EFilters klassen. Feilmeldingen skrives så til databasen. Skrivingen av feilmeldingen til database er det svake ledd og skulle den feile blir den kastet og ingen melding skrevet. 27

55 Brukergrensitt Denne delen beskriver klient siden. Design CSS Sideutformingen, Proton UI Responsive Admin Panel Theme 30, er laget av Orange Hill 31.Proton bygger på Twitter Bootstrap. 32 Shell.css er den eneste css filen vi selv har laget i prosjektet. Det lille øye ikonet på siden hvor man kan velge farge tema for siden kommer fra Proton. JavaScript Alle viewmodeller er skrevet i javascript, her gjør vi også enkelte DOM 33 endringer som å aktivere Modal vinduer $("#submit-success").modal("show"); Durandal Durandal er et rammeverk for å lage en SPA 34. Det er skrevet i javascript og bygger på kjente teknologier som jquery, RequireJS og KnockoutJS. Det lar deg velge mønster selv og har støtte for MVP, MVC og MVVM 35. Durandal styrer rutingen for å navigere rundt i applikasjonen. Alle CSS'er som benyttes refereres til i index.html. Her er også div tag'en durandal benytter til å sette inn html <div id="applicationhost"></div> Her settes også baseurl og hvilke javascript den krever for å sette i gang <script> require.config({ baseurl: 'App', paths: { //"main": "main-built" } }); require(["main"]); </script> Main.js filen kalles og her defineres alle avhengigheter til andre script og hvilke script som avhenger av andre slik at requirejs, som durandal bygger på, kan laste alle scriptene i riktig rekkefølge. Listingen under er også en liste over alle 3dje parts script vi benytter i løsningen. 30 Lokalisert på 31 Lokalisert på 32 Lokalisert på 33 Lokalisert på 34 Single Page Application - Lokalisert på 35 Patterns - Lokalisert på Design-Pattern-MVC-MVP 28

56 requirejs.config({ baseurl: 'App', paths: { 'text': '../Scripts/text', 'durandal': '../Scripts/durandal', 'plugins': '../Scripts/durandal/plugins', 'transitions': '../Scripts/durandal/transitions', 'knockout': '../Scripts/knockout-3.1.0', 'knockout.mapping': '../Scripts/knockout.mapping-latest.debug', 'knockout.validation': '../Scripts/knockout.validation', 'bootstrap': '../Scripts/bootstrap', 'datepicker': '../Scripts/vendor/bootstrap-datetimepicker', 'jquery': '../Scripts/jquery-2.1.0', 'bootstrap.growl': "../Scripts/jquery.bootstrap-growl", 'jquery.datatables': "../Scripts/vendor/jquery.dataTables.min", 'bootstrap.datatables': '../Scripts/vendor/datatables', 'moment': "../Scripts/moment-with-langs", 'proton': '../Scripts/main', 'proton-main-nav': '../Scripts/proton/main-nav', 'proton-user-nav': '../Scripts/proton/user-nav', 'proton-common': "../Scripts/proton/common", 'raphael': '../Scripts/vendor/raphael-min', 'modernizr': "../Scripts/vendor/modernizr", 'select2': '../Scripts/vendor/select2.min', 'morris': '../Scripts/vendor/morris.min', 'bootstrap-tagsinput': '../Scripts/vendor/bootstrap-tagsinput.min', 'pnotify': '../Scripts/vendor/jquery.pnotify.min', 'jquery-cookie': '../Scripts/vendor/jquery.cookie' Applikasjonstittel og utvidelser blir konfigurert app.title = 'Server boot system'; app.configureplugins({ router: true, dialog: true, widget: true }); Applikasjonen startes. Når den er started settes viewlocator til useconvention. Det vil si at den forventer og finne view's (HTML filer) under App/views og viewmodels (javascript) under App/viewmodels. Durandal parrer disse så lenge de har samme navn. 'viewmodels/shell' er definert som rotnivå i applikasjonen og transition er satt til 'entrance'. Det er 'entrance' som får siden til å animere kort inn fra siden når man trykker seg rundt i applikasjonen. Dette er en funksjon som følger med Durandal app.start().then(function () { viewlocator.useconvention(); app.setroot('viewmodels/shell', 'entrance'); }); I shell.js kjøres en activate funksjon som definerer vi alle rutene med rutenavn, sidetittel, adressen til viewmodellen, om den skal legges i router.navigationmodel og hvilke ikon ruten skal få på menyen 29

57 { route: 'listservers', title: 'Servers', moduleid: 'viewmodels/listservers', nav: true, icon: 'icon icon-laptop nav-icon' }, I shell.html ligger menyene og de faste elementene som er med på alle visningene i applikasjonen. Her bygges menyen ut i fra rutene som er definert i shell.js. Dersom ruten har underruter ligger disse i childroutes og blir lagt til under hovedruten. <nav class="main-menu" role="navigation"> <!-- ko foreach: router.navigationmodel --> <ul> <li data-bind="css: (typeof childroutes!= 'undefined')? 'hassubnav' : null "> <a data-bind="attr: { href: hash }"> <i data-bind="css: icon"></i> <span class="nav-text" data-bind="html: title"></span> <!-- ko if: typeof childroutes!= 'undefined' --> <i class="icon-angle-right"></i> <!-- /ko --> </a> <!-- ko if: typeof childroutes!= 'undefined' --> <ul> <!-- ko foreach: childroutes --> <li> <a class="subnav-text" data-bind="html: title, attr: { href: hash }"></a> </li> <!-- /ko --> </ul> <!-- /ko --> </li> </ul> <!-- /ko --> </nav> Til slutt i filen finner vi tagen durandal bruker til å sette inn HTML i rammen som nå er skapt, hver gang vi trykker på en link som peker på en definert rute blir det viewet nå satt inn på denne plasseringen. <div data-bind="router: { transition:'entrance' }"></div> Knockout KnockoutJS 36 er et rammeverk for å binde 37 data i en Model-View-ViewModel stil. Model-View-View Model (MVVM) is a design pattern for building user interfaces. It describes how you can keep a potentially sophisticated UI simple by splitting it into three parts: 36 Lokalisert på 37 Lokalisert på 30

58 A model: your application s stored data. This data represents objects and operations in your business domain (e.g., bank accounts that can perform money transfers) and is independent of any UI. When using KO, you will usually make Ajax calls to some server-side code to read and write this stored model data. A view model: a pure-code representation of the data and operations on a UI. For example, if you re implementing a list editor, your view model would be an object holding a list of items, and exposing methods to add and remove items. Note that this is not the UI itself: it doesn t have any concept of buttons or display styles. It s not the persisted data model either - it holds the unsaved data the user is working with. When using KO, your view models are pure JavaScript objects that hold no knowledge of HTML. Keeping the view model abstract in this way lets it stay simple, so you can manage more sophisticated behaviors without getting lost. A view: a visible, interactive UI representing the state of the view model. It displays information from the view model, sends commands to the view model (e.g., when the user clicks buttons), and updates whenever the state of the view model changes. When using KO, your view is simply your HTML document with declarative bindings to link it to the view model. Alternatively, you can use templates that generate HTML using data from your view model. 38 Viewmodellen definerer de data'ene vi trenger i view'et self.servercount = ko.observable(); self.rulecount = ko.observable(); self.jobcount = ko.observable(); self.jobstepcount = ko.observable(); self.lastjoblogs = ko.observablearray(); Variablene settes til observables, dette er funksjoner som inneholder data og oppdaterer view'et når dataen endrer seg. Skriver man for eksempel inn i et input felt som er bundet til en av disse verdiene vil verdien automatisk oppdatere seg i viewmodellen. 39 De fleste viewmodeller i systemet bruker funksjonen activate som blir kalt hver gang et view laster for å hente inn den data'en som trengs når siden vises. Det brukes Ajax kall for å hente informasjon self.activate = function () { //Get servercount $.getjson("/server").then(function(data) { if (data!= 'undefined') { self.servercount(data.length); } }); 38 Lokalisert på 39 Lokalisert på 31

59 I funksjonen over vil vi bare ha tak i antallet objekter vi får tilbake. Det er viktig og sette en observable via paranteser istedenfor er lik, bruker man er lik tegnet vil ikke variabelen lenger være en observable. Når vi skal hente ut array'er i JSON format å gjøre de om til observables er det en litt annen prosess. 1. Først kjøres et ajax kall (her via jquery funksjonen getjson) 2. Funksjonen venter til den mottar data før den fortsetter 3. Vi bruker funksjonen ko.utils.arraymap for lage et Observable objekt av hvert JSON objekt i resultatsettet. 4. Inne i hvert objekt brukes ko.mapping.fromjs for å sette alle objektets verdier til observables 5. Legger til JobStartedM og JobEndedM som ko.computed observables. Dette for å kunne konverte formen datoen skrives på med momentjs for lettere lesing for brukerene. $.getjson("/joblog/lastentries").then(function (data) { self.lastjoblogs = ko.observablearray(ko.utils.arraymap(data, function (joblog) { var joblogmodel = ko.mapping.fromjs(joblog); joblogmodel.jobstartedm = ko.computed(function () { return moment(joblog.jobstarted).format("dddd HH:mm:ss"); }); joblogmodel.jobendedm = ko.computed(function () { return moment(joblog.jobended).format("dddd HH:mm:ss"); }); return joblogmodel; })); }); I view'et bindes variablene enten via en data-bind attributt direkte på en tag, eller inne i en spesiell kommentarform <div class="counter" data-bind="text: ServerCount"></div> <!-- ko foreach: router.navigationmodel --> Hjelpe scripts MomentJS 40 Formaterer tid og dato objekter til formatter som er mer leselig for mennesker. 40 Lokalisert på 32

60 Transitions 41 Script for å animere lasting av nye DOM elementer Knockout mapping Denne gir oss en del automatikk i det å oversett fra et JSON objekt som vi sendes fra server siden til Observables som finnes i viewmodellen. Knockout validation 42 Klientside validering av forms. Denne fungerte ikke helt slik vi ville sammen med Durandal så vi har lagt til følgende kode for å sette form'en tilbake til slik den var før man begynte å registrere data. For å gjøre dette uten å trigge validering før man begynte å skrive gang nummer to måtte vi legge til en funksjon som satte tilbake hvert felt. Her hentet fra addrule self.resetmodel = function () { var rule = self.rule(); rule.name(""); rule.regex(""); rule.frequency(24); rule.startdate(' :00'); rule.enddate(' '); rule.enabled(true); var steps = self.jobsteps(); for (var i in self.jobsteps()) { steps[i].isselected(false); } rule.name.ismodified(false); rule.regex.ismodified(false); }; Funksjonen trigger når modal'en blir lukket $("#submit-success").modal({show: false}).on("hide.bs.modal", function() { self.resetmodel(); }); Selve valideringen kommer rett i formen enten når man går videre i skjemaet eller når man forsøker sende inn skjemaet 41 Lokalisert på 42 Lokalisert på 33

61 Exempel på validering fra Crate Rule jquery Masked Input Formatet vi krever når man skal skrive inn Frequency for en Rule er litt spesiell. Derfor har vi valgt å legge på en guide som viser et mønster når man skriver inn tall og bare tillater enkelt verdier. Dette jquery biblioteket fungerte ikke like godt med RegEx i vår løsning så slik det er nå krever den at det første tallet i timer er [0-2] og at det første tallet i minutter er [0-5], men man kan fortsatt skrive 29 timer. Skriver man noe feil vil timespan bli 00:00:00 når den kommer til valideringen på vei til databasen. Den vil ikke gå gjennom valideringen og regelen vil ikke bli laget. Bootstrap Datepicker 43 Gjør det lett for bruker og velge dato og tidspunkt 43 Lokalisert på 34

62 Bootstrap Datepicker Jquery Datatables 44 Vi benytter tabeller flere steder I vårt system, for å få en oversiktlig visning av disse benytter vi jquery datatables. Sammen med stilingen vi bruker fra Proton server de slik ut: jquery DataTables Tabellen aktiveres ved at vi kjører følgende script i viewmodellen self.attached = function () { $('#rules-table').datatable(); $('.datatables_wrapper').find('input, select').addclass('formcontrol'); 44 Lokalisert på 35

63 $('.datatables_wrapper').find('input').attr('placeholder', 'Quick Search'); $('.datatables_wrapper select').select2(); }; Dette gir oss sorteringsmulighet på alle felter med tekst og en hurtigsøk funksjon som aktiveres når man har skrevet inn 3 eller flere bokstaver/tegn. Morris 45 og Raphael 46 Gir mange muligheter for grafer og diagrammer. Brukes på server logg siden for et sammendrag av hvilke jobb status'er som finnes i jobb loggen for den aktuelle serveren. Morris Donut Chart Bootstrap Growl Brukes til å vise en popp opp melding når et ajax kall går galt. Vi legger inn følgende kode på error delen av ajax kallet. function () { $.bootstrapgrowl("problem saving rule!", { type: 'error', width: 'auto' }); 45 Lokalisert på 46 Lokalisert på 36

64 Bootstrap Growl beskjed Disse meldingene skal gi en beskjed til bruker når noe går galt på serversiden. 37

65 Klient-Server kobling Her beskrives hvilke deler av API'et som som benyttes av brukergrensesnittet. Home / Status Page Home.js ServerCount RuleCount JobCount JobStepCount LastJobLogs Kontroller/Metode Server/GetAll() Rule/GetAll() Job/GetAll() JobStep/GetAll() JobLog/LastEntries List Rules Listrules.js Rules UpdateRule Kontroller/Metode Rule/GetAll() Rule/Update() Add Rule Listrules.js JobSteps clickcreaterule Kontroller/Metode JobStep/GetAll() Rule/Post() List Servers Listservers.js Servers toggleenable Kontroller/Metode Server/GetAll() Server/Put() ServerLog Serverlog.js ServerLogs Server RebootSuccessCount og JobsPending Kontroller/Metode JobLog/GetByServer() Server/Get() Regnet ut fra det første kallet mot JobLog/GetByServer() 38

66 Forslag til videre utvikling Når de forskjellige jobbene kjører mot en server går de nå etter en satt ventetid (satt i JobManager). En måte jobbene kan grupperes med nåværende funksjoner, er å hente ut alle jobber for en server og gruppere de etter hvilke jobber som har samme start tidspunkt. Det kan så startes en task per gruppe som igjen oppretter child tasks for hver enkelt oppgave. Task'en for gruppen kan da styre flyten av jobber mot en server. Oppgaver som avbryt alle jobber ved feil på en, omstart enkelte jobber hvis de feiler et antall ganger og gruppere logging mer effektivt Systemet sender nå kun en melding om at brukere skal logge seg av 15 minutter før serveren går ned. Det burde lages en database med hvor mange kan legge inn en gruppe meldinger med tittel, melding og tid før omstart den skal vises. En MessageController kan gi brukergrensesnittet tilgang til å opprette meldingsgruppene og en endring i addrule.js og.html kan gi mulighet for å velge meldingsgruppe når man oppretter en regel. Feilmeldingen som nå kommer fra win32 api ved omstart av en server blir nå bare skrevet til konsoll, de burde legges inn som et felt i Det burde muligens legge inn en egen statuskode for at en server måtte kjøre "force reboot" for å klare en omstart. Nå vises status 100 OK om den booter med eller uten force flagget på. Webpplikasjonene er responsiv og skalerer bra nedover, her har vi fått mye gratis fra Proton, det er lagt opp til at siden skal kunne klargjøres for mobil, men selve menyen siden kollapser ned til når den skalerer ned til sin minste størrelse er ikke implementert. Mobilvisning 39

67 Discover servers, burde ha LDAP string lagret i databasen og bare ta inn et LDAP objekt når den kjøres i motsetning til å ha LDAP string hardkodet inn i systemet. For å gjøre ordne dette må metoden DiscoverServers ta inn en string LDAP og det må legges inn en enkel kontroller samt view/viewmodel for. Domeneklasen må utvides til å få de samme funksjonene som resten av modellene. Mulighet for sjekk om server er deaktivert 47 i Active Directory og deaktivere server i serverboot på bakgrunn av den informasjonen. Brukerautentisering. Systemet er planlagt integrert med Opus som har mekanismer for autentisering mot Active Directory. Når dette er på plass burde det legges på forskjellige brukergrupper som styrer hvem som har lov til å legge inn nye regler eller endre gamle og hvem som bare har mulighet til å se på loggene. Feilhåndtering. Vi har lagt inn exception filter som kan tenkes på som en stor try/catch rundt hele systemkoden. Tanken er at man her skal legge inn catch'es for alle de typer exceptions som kan bli kastet rundt om i koden. Mange steder vil man selv velge hvilke exceptions som blir kastet ved forskjellige typer feil, men det er også viktig og legge inn de exceptions som andre moduler kan kaste, for eksempel WebAPI og Insight Database. Exceptions skal så lagres i databasen fra exception filteret. Basen for dette ligger i koden (EFilter.cs er exception filteret), men full utrulling av dette ble nedprioritert i sluttfasen. Døpe om navnene på prosjektene i Visual Studio løsningen. Vi endret namespace og navn på prosjektene i Visual Studio siste helgen for å få en mer helhetlig navngivning. Dette skapte så mye trøbbel, trolig på grunn av noen referanser vi ikke klarte å finne, at vi valgte å rulle tilbake. Vi ville ha gjort følgende navnendringer Nåværende Prosjekt Navn ServerBoot2 ServerBootModels ServerBootBLL ServerBoot.test Nytt navn Serverboot ServerBoot.Models ServerBoot.BusinessLogic ServerBoot.Test Namespace ville vi endret til formen TeleComputing.ServerBoot.Models osv. Skille ut kontrollerene fra user interface delen. Dette ble vurdert i slutten av prosjektet. Vi diskuterte dette med veileder i TC, men ble enige om at dette kunne skape såpass mye trøbbel med WebAPI at det ble nedprioritert. Meningen med unit tester i VS er at det skal legges inn logikk for sjekk via assert metoden. På denne måten kan man kjøre gjennom alle tester og få en liste over hvilke som gikk bra eller ikke. Våre tester gir kun feilmelding dersom den støter på en exception, vi har brukt 47 Lokalisert på 40

68 disse testene manuelt og sjekket data som dukker opp i databasen for å se om resultatet er forventet. Dette ble gjort fordi det endelige databasedesignet ikke kom til sin endelige form før sent i prosjektet JavaScriptene kan ordnes og lages i en mer objektorientert. For eksempel ved å skille ut alle ajax kall til en egen klasse for at koden skal se mer ryddig ut. funksjon, mulighet for varsling via . På dette tidspunktet er det ikke mulig å endre RuleJobsteps som tilhører en regel. All funksjonalitet ligger klart på serversiden for å implementere dette i brukergrensesnittet, men det må opprettes en RuleJobStep logg database for å kunne få med seg endringene som gjøres her. En knapp "Test Regex" i Add rule skjemaet hvor man kan skrive inn et RegEx mønster og få se en prøve av hvilke servere dette mønsteret treffer. WMI kan brukes til så mangt, for å gjøre det lettere å legge til andre spørringer mot forskjellige WMI klasser kan det lages en dynamisk spørre metode. Den vil bygge en WMI spørring ut i fra informasjon den får som parametere. Lages det en kontroller og et view/viewmodel for å legge til parametersett kan det lages nye spørringer uten å endre kode Antall parametere på et JobStep, det er nå bare mulig å legge inn et parameter. For å gjøre det mer skalerbart burde antall mulige gjøres dynamisk. Utfordringer Vår største utfordring i løpet av dette prosjektet har vært alle de nye teknologiene vi har måttet tilegne oss kunnskap i. Et av gruppemedlemmene tok faget WebApplikasjoner, ingen av de andre gruppemedlemmene hadde noen erfaring i C#. Vi hadde heller ingen erfaring med JavaScript og har funnet at det er en ganske annen tenkemåte når man programmerer i JavaScript i forhold til for eksempel Java. Vi bruker en del 3djeparts script i denne løsningen og selv om alle virker fantastisk hver for seg har det bydd på noen utfordringer når dette blir sydd sammen til en løsning. Vi arbeidet lenge med en modell hvor vi skilte omstart jobber og sjekk-etter-omstart jobber. Vi bestemte oss sent i prosessen for å endre dette til å heller være en type regel som kunne ha flere steg (JobSteps) knyttet til seg. En del måtte endres, men vi mener det var verdt og bruke tid på da det viste seg å være et veldig unaturlig skille. 41

69 1

70 Innholdsfortegnelse 1. Testing Feiltesting av koden Funksjonstesting: Kilder.10 2

71 1. Testing Testing av et system er nødvendig for å finne ut om systemet fungere slik det skal og har nådd sitt mål. Vi har gjennomført ulike typer tester ved bruk av ulike metoder både under utvikling og etter det. 1.1 Feiltesting av koden Utviklingen av systemet bestod av flere iterasjoner. Programkoden ble testet underveis i hver iterasjon. Metoder og tekniker vi har brukt for å finne og rette eventuelle feil og svakheter i kildekoden og de ulike typer feil, som oppstod under utvikling av systemet og måten vi har løst de utfordringene beskrives under. Formål: Formålet met kodetesting var at å sjekke hver impementerte funksjon fungerer på riktig måte. Testområde: hele systemet Verktøy: Visuellstudio 2013, nettleser, Postman Teknikker: Vi har benyttet forskjellige teknikker og verktøyer for feilsøking under utviklingen blant annet Runtime tilbakemeldinger, Exceptions, Break pointing og IntelliSense. Runtime error og exception Under kompilering av kodelinje for å teste en funksjon eller et spesifikk view, opplever man at applikasjonen stopper. Når du kjører, er den lagrede informasjonen kontrollert, og eventuelle erklæringer som ikke er gyldig, ender du opp med en run-time exception. Slike informative feilmeldinger gir utvikleren informasjon om hvilken type feil og hvor feilen ligger. Det er ikke alle Exceptions som for eksempel NullReferenceException, som er ikke nok beskrivende og det er mange feil som kan skje under kjøring av metoder. Ved hjelp av Break pointing er det ikke så vanskelig å finne og rette opp slike feil. 3

72 Breakpoints : Teknikken å stoppe kjøring av programmet i et bestemt punkt, kan være veldig effektivt for å finne feil plassering. Man kan sjekke verdiene til lokale variabler og se hva som skjer linje for linje. Slik er det enklere å finne årsaken til at programmet ikke fungerer (Developer Network, udatert). IntelliSense: IntelliSense er en kraftig funksjon som i betydelig grad kan øke produktiviteten, fordi det gir logiske kode elementer, som man kan velge fra en rullegardin meny når man koder. Den er designet for å gjøre utviklingen mye enklere ved å foreslå hvilke funksjoner som passer. Den utfører også automatisk feilretting mens man skriver ved å streke under feil eller gi forslag til endringer. Denne prosessen kan redusere tiden man bruker på skriving og for å unngå skrivefeil i koden (Developer Network, udatert). 4

73 Postman: Postman er en REST Client som er et veldig nyttig verktøy for å teste funksjonaliteten under utviklingsprosessen. Postman kan dramatisk redusere tiden å teste APIer. Postman tilpasser seg for individuelle utviklere, små grupper eller store organisasjoner like godt. Den støtter 11 ulike HTTP-metoder blant annet Get, Post, Put og Delete som blir mest brukt under utvikling. Den støtter både JSON og XML format (Ullnæs, 2013). Alle Controller arver ApiController og ApiController klassen er base klasse av web API kontrolleren som inneholder samme metoder som http, det vil si, Get (for å få resurser), Post (for å legge til resurser), Put (for å oppdatere resurser) og Delete (for å fjerne resurser) For å sende en kall, kjører man prosjektet og fyller inn en URL i postman, velger en httpmetoden blant annet, Get, Post, Put eller Delete. Etter å trykke på send får man resultatet av kallet i form av Pretty, Raw eller Preview. I vår tilfelle, et eksempel på URL for å liste alle serverne er og for hver enkel server kommer serveren sin id i slutten, for eks.: 5

74 Hver forespørsel man sender ved hjelp av Postman blir lagret i historien og kan brukes senere. Man kan lagre forespørsler om en API sammen i Collections. Vi har brukt Postman til å teste verdier vi vet skal fungere, som id'en til et visst objekt. Vi har også testet på id'er vi vet ikke finnes for å bekrefte et "null" resultat. Vi har også testet verdier vi vet ikke passer inn i typen, for eksempel et tall som er større enn en integer for å sjekke at vi får forventet oppførsel fra systemet 6

75 1.2 Funksjonstesting: For å sikre at de funksjonelle kravene ble oppnådd har vi gjennomført en funksjonstesting. Her under vises en liste over de viktigste kravene samt tester og kommentarer. Krav Testresultat Kommentar Systemet skal kunne hente info om status på tjenester tjenester på en server via WMI Systemet skal kunne hente informasjon om server objekter fra Active Directory Ok, vi mottar status på tjeneste fra WMI Ok, vi mottar alle serverobjekter som matcher den insendte RegEx verdien Her har vi selvsagt ikke testet mot hver server, men gjort et lite utvalg og testet med metoden GetServiceStatus fra WmiAccessTest klassen Testet med metoden GetServersTest i klassen AdAccessTest Systemet skal kunne fungere på tvers av soner (domener) fra et sentralt system Ok, vi kan aksessere et domene fra et annet domenet. Vi har testet mot et domenet. Testmaskinen ble plassert i et annet domenet Systemet skal kunne opprette restartjobber Systemet skal kunne kontrollere servere etter boot via WMI Ok, Metoden oppretter de jobber som skal opprettes i det innsendte tidsrommet Ok Testet fra metoden CreateJobsTest i JobManagerTest klassen Vi har testet TestWmiConnection metoden mot et utvalg 7

76 servere Systemet skal kunne sende meldinger til påloggede brukere før restart. Brukeren skal kunne legge inn eksisterende regler på nye servere Brukeren skal kunne se og søke i server logg Brukeren skal kunne søke etter servere og se hvilke regler som treffer den N/A Ok N/A Regler velger hvilke servere som booter utifra en RegEx verdi, nye servere vil automatisk bli tatt med i regler dersom noen treffer. Ved å trykke på logg i serverlisten får man opp en logg liste for den serveren med et søkefelt Ikke implementert Brukeren skal kunne opprette nye regler for restart og sjekk av tjenester etter restart Bruker skal ikke kunne opprette en regel uten å spesifisere navn og regex Ok Ok. Regler kan opprettes via regel siden Det gis en melding i brukergrensesnittet dersom man forsøker å legge inn en ugyldig regel. Spesifiserer man ajax kallet selv er egen input 8

77 Brukeren skal kunne legge til og fjerne mottakere av dagsrapport Systemet skal kunne generere en daglig rapport med utgangspunkt i loggene. Denne skal formateres på en slik måte at det er lett og skaffe seg oversikt uten å bli overlesset med informasjon. N/A validering i modellen. Dette ble testet via Postman1 Det er implementert en rapportside istedenfor utsending av dagsrapport Dette har vi løst med widgets på rapportsiden som gir deg en oversiktover tilstanded til systemet og de siste utførte jobbene. 1 Postman er en verktøy som hjelper til å bli mer effektiv når man arbeider med APIer (Postman-REST client, 2014). 9

78 Kilder: Developer Network. (udatert a). Using IntelliSense: Visual C# IntelliSense. Hentet Mai fra: Postman REST Client. (2014). Beskrivelse: Postman helps you be more efficient while working with APIs. Postman is a scratch-your-own-itch project. The need for it arose Hentet Mai 25, 2014 fra: Developer Network. (udatert b). Debugger Roadmap: Breakpoints and Tracepoints. Hentet Mai fra: Ulnæs, Anders. (2013). Testing av REST-tjenester med Postman. Hentet Mai 25, 2014 fra: 10

79 1

80 Innhold Forord... 3 Systemets formål... 3 Terminologi... 3 Rapport side/home... 4 Forklaring av funksjoner... 5 Navigering... 5 Hovedmeny... 5 Navigering i lister... 6 Se liste over alle regler... 7 Informasjonsside for regel... 8 Legg til ny regel... 9 Server liste System logg

81 Forord Dette er brukerdokumentasjonen for Server Boot. Her går vi igjennom de forskjellige visningene i systemet og hvilke muligheter man har som bruker av systemet. Systemets formål Styre omstart av servere. Som bruker kan du bestemme ett sett med servere som skal startes om automatisk med angitte intervaller. Terminologi Rule JobStep RegEx Server Boot User Message En regel som styrer hvilke servere det skal utføres jobber på ut ifra en RegEx verdi. Jobbene er delt opp i JobSteps En enkelt definert jobb som omstart av server eller sjekk av at en servertjeneste kjører Et mønster for gjenkjenning av tekst Navnet på systemet som også forklarer dets hovedfunksjon, omstart av en servere. Melding som sendes til påloggede brukere før en server gjør en omstart Check if service is running Kontakter en server og får vite statusen til en brukerspesifisert tjeneste Check if server is up Task Sender en tjenesteforespørsel mot en server og sjekker om den får svar eller ikke. Det forteller om serveren er operativ eller ikke. En oppgave systemet skal utføre. I vårt tilfelle har vi tilegnet denne en ventetid slik at den skal starte på et gitt tidspunkt 3

82 Rapport side/home Når man går inn på startsiden til systemet kommer man inn på en rapportside med diverse informasjon. Her får man et sammendrag av systemets tilstand og alle arkiverte logger de siste 24 timene samt en menyliste på venstre side som gjør mulig å navigere i systemet. Rapport side Felt Servers Found Rules Job Steps Job Queued Failed Jobs System Warnings Job Log Last 24 Hours Funksjon Antall servere i server tabellen Antall Regler i regel tabellen Antall forskjellige jobber man kan tilegne en regel Antall jobber som venter på å bli startet som en Task Antall omstart jobber i logg tabellen som har feilmeldingen "could not initate server boot" Antall Systemfeilmeldinger logget siste 24 timer Viser logg for alle jobber som er kjørt de siste 24 timer 4

83 Forklaring av funksjoner Navigering Hovedmeny Menylisten er på venstre side og spretter ut når man beveger musen bort til den. Har menyvalget en liten pil ved seg kommer det flere valg til syne når man beveger musen dit. Lukket tilstand Åpen tilstand Tegnigen viser overgangen fra lukket til åpen meny 5