Arena Kundereskontro. Gruppe 25. Andreas Åkesson Roger Ommedal Ashkan Vahidishams Simen Trippestad

Transkript

1 Arena Kundereskontro Gruppe 25 Andreas Åkesson Roger Ommedal Ashkan Vahidishams Simen Trippestad

2 Gruppe 25 Om oss Gruppemedlemmer: Andreas Åkesson Roger Ommedal Ashkan Vahidishams Simen Trippestad Informasjonsteknologi Samarbeidet på tidligere prosjekter

3 Agenda Introduksjon Prosessen Løsningen Avslutning

4 Introduksjon

5 Oppdragsgiver - Kredinor Norges neste største infordringsselskap Mellom ansatte IT avdeling på ca 30 stk Egenutviklede kjernesystemer Kontaktpersoner Ole Marius Thorstensen IT sjef Øyvind Andersen - Systemarkitekt

6 Oppgaven Arena Kundereskontro Bakgrunn for oppgaven Roger ansatt i Kredinor Kredinor hadde behov for å få utviklet en ny reskontroløsning for bruk på tvers av systemene Dagens systemer: Vanskelig å hente ut samlet informasjon Enkelte transaksjoner kan korrigeres/slettes uten at historikk lagres Hva er Arena?

7 Hva skal vi lage Arena Kundereskontro Et Klassebibliotek for bruk i andre system Transaksjonsoversikt på tvers av systemer Sikre pålitelighet Sikre sporbarhet Generelt, ikke bransjespesifikt Visual Studio - C#.NET En klient som benytter klassebibliotek (test / demo) Alternativ Nytt intranett, web programmering Hvorfor Web side har vi laget før Klassebibliotek - mer utfordrende Lærerikt å programmere i c#.net

8 Prosessen

9 Planlegging Mål: Utarbeidelse av kravspesifikasjon Valg av utviklingsmetodikk Begresning av omfang Forsikring av nødvendig forankring Utarbeidelse av nødvendige dokumenter og diagrammer - Fremdriftsplan - Sprint-oversikt - Risikoanalyse - Klassediagram Benyttede verktøy - Yed - Trello Tidlig utgave av klassediagram

10 Utviklingsprosessen Stadige endringer i kravspesifikasjon Tidlige sprinter preget av treg progresjon Utfordringer: Paralellitet Sporbarhet Pålitelighet Testing Milepælsplan som viser overordnet fremdrift Brøt ned utfordringer i så små deler som mulig

11 Eksempel på Scrum-kort i trello Scrum Hvorfor Scrum? Bruk av trello Sprint oversikt Stand-up møter Gantdiagram som viser oversikt over sprinter, varighet og helhetlig prosess

12

13 Paralellitet Resultat av krav om høy ytelse Asynkron behandling Tabellen er hentet fra Testrapporten og viser ytelsesforhold sync vs. async Bruk av GUID

14 Sporbarhet Hvorfor sporbarhet? TransaksjonsID Modellen beskriver ønsket sporbarhet i løsningen Forelder Barn

15 Pålitelighet Mulighet for feil i gammel løsning Samme fil kan leses inn flere ganger, vil gi redundans Checksum Hash av transaksjonsforespørsel Lokal database Hver klient har sin egen database Checksum lagres her Nye forespørsler kontrolleres mot databasen

16 Hvordan teste et klassebibliotek? Klassebibliotek => mangler brukergrensesnitt Via en klient => Web API Testprogram med utskrift til konsoll Enhetstester Skjermutklipp fra Web-apiet som viser Import-XML viewet

17 Løsningen

18 Context EntityFramework En kontekst kan defineres som en klasse Grunnleggende data Info om forbindelse til database Hvilke objekter databasen inneholder Viktige funksjoner Refererer til ConnectionStringen Inneholder Metadata Holder Kontroll på endringer

19 Klassebibliotekets kontekst AKContext Sentralt RequestContext Lokalt ConnectionString

20 Klient Et system som tar klassebiblioteket i bruk Klassebiblioteket må vite hvor transaksjonen kommer fra

21 Implementasjon av klient Interface for klientene Hvorfor? Identifisering av klienter Mottak av transaksjonskvitteringer Opp til Klient å implementere funksjonalitet for håndtering av kvitteringer.

22 Transaksjonsforespørsler Ankommer klassebiblioteket i XML format En forespørsel består av: TransactionRequest - TransactionData - PostingData Data om selve forespørselen Data om Gitt Transaksjon Data om gitt postering XML konverteres til et objekt som klassebiblioteket kan behandle videre.

23 Håndtering av Transaksjonsforespørsler

24 Trimming av forespørsel

25 Validering av transaksjoner Påkrevd for å sikre at en transaksjon er korrekt: I balanse Konto eksisterer Oppfylling av vilkår i bokføringsloven, derav pålitelighet til data som lagres i databasen/modulen. Validering etter trimming for å spare ressurser

26 Lagring av transaksjon Etter validering blir transaksjonen forsøkt lagret. Ved vellykket lagring oppdateres den lokale Request databasen. Dette for å unngå duplikat behandling dersom forespørsel sendes inn på nytt. Til slutt sendes en kvittering til klienten med transaksjonens unike ID.

27 Kvitteringer En tilbakemelding fra modulen der klient får vite: Vellykket postering Transaksjon er behandlet fra før Feilmelding

28 Kvitteringer - nytte Tilbakemelding etter behandling av transaksjon GUID dersom vellykket Beskrivende melding ved feil Gir klienten en mulighet til etterbehandling/loggføring.

29 Uttak til regnskapssystem Nåværende system (gammel løsning) Batch-jobb Kjøres som regel en gang per natt Sender inn en datastrøm (ny løsning) AccountingRequest blir skrevet som XML til strøm Posteringer med tilhørende transaksjonsinformasjon Posteringer blir merket som eksportert (timestamp) Kan også hente ut alt som er eksportert på en gitt dato

30 Web API Forlengelse av det opprinnelige prosjektet Klient som implementerer klassebiblioteket Benyttes til å teste ut og demonstrere funksjonaliteten til klassebiblioteket ASP.NET Web API Rammeverk for å bygge RESTful Web API Returnerer JSON objekt Gjør data tilgjengelig for mange plattformer F.eks. en mobilapplikasjon

31 Eksempel på en forespørsel Forespørsel GET api/postings GET /postings Beskrivelse Hente ut alle posteringer. Response Kode Beskrivelse 200 Retunerer en liste med Posting. Svar Array med posteringer (JSON) POSTING M ODEL Beskrivelse En postering i modulen. Eksempel Type application/json { "TransactionId" : "050fea39-b054-4d6f-bcd1-001b6f835362", "AccountNo" : 2802, "ParentTransactionId" : "050fea39-b054-4d6f-bcd1-001b6f835362", "Amount" : , "TransferedToAccountingSystem" : null, "Transaction" : null, "ParentTransaction" : null, "Account" : null, "Reference" : null }

32 Bruk av Web API

33 Front End AngularJS Javascript MVC-rammeverk SPA (Single-page Application) Brukergrensesnitt i HTML Bootstrap CSS 6 views En controller per view

34 Services Utfører forespørsler mot Web API Gjenbrukbar kode (DRY) En service kan brukes i flere controllers ngresource modul til Angular som tilbyr interaksjon mot RESTful services.factory('client', ['$resource', function ($resource) { return $resource('api/clients/:clientid', {}, {}); }]); $scope.newclient = new Client({ Name: "Demo", Active: true}); $scope.registerdemoclient = function () { $scope.newclient.$save(); };

35 Funksjonalitet Laste opp fil med flere transaksjoner eller registrere en enkel transaksjon. Demonstrere sporbarheten ved hjelp av søk Administrere kontoer samt importere flere kontoer fra fil Registrere nye klienter Laste ned fil med posteringer for regnskapssystem

36 Importering av filer

37 Polling av kvitteringer Etterspørr nye kvitteringer en gang i sekundet Rød: Opplasting av XML (skjer en gang) Blå: Polling (skjer flere ganger)

38 Sporbarhet

39 Registrering av enkel transaksjon

40 Legge til postering/motpostere

41 Kontoadministrasjon

42 Registrering av ny klient

43 Uttak til regnskapssystem <?xml version="1.0"?> <accountingrequest xmlns:xsi=" xmlns:xsd=" count="4"> <postings> <posting> <date> t00:00:00+02:00</date> <financial_year>2015</financial_year> <financial_period>1</financial_period> <account_no>1018</account_no> <parent_guid>ea424dfa-ae aa2a-974ee31424f3</parent_guid> <amount>-2000</amount> </posting> <posting> <date> t00:00:00+02:00</date>

44 Avslutning

45 Gruppens utbytte Lært mye om prosess, viktigheten av å ha et nøye planlagt og gjennomtenkte prosjekt før man starter Lært programmering (.Net), fordeler med testdreven utvikling og behovet for god dokumentasjon Lært å arbeide i prosjekt i næringslivet, både på godt og vondt Krevende å oppfylle alle ønsker, mange som gjerne vil komme med innspill. Kan bli mange endringer underveis Vanskelig å få allokert ressurser Lett for at det oppstår misforståelser viktigheten av god kommunikasjon

46 Nytteverdi for Kredinor Samlet oversikt over transaksjoner og historikk Mulighet for uthenting av data til regnskapssystem Produktet kan tas i bruk, men man ser at det sannsynligvis trenger videreutvikling for at det skal fungere optimalt Inneholder for lite informasjon Støtte ønsker om å ta ut informasjon om kunden / oppdragsgiver, ikke bare transaksjonen, på tvers av systemer

47 Gjort annerledes? Mer planlegging og avklaringer før kodestart Bedre og mer gjennomtenkte use-case, klassediagram, etc. Enda tettere oppfølging mot oppdragsgiver og raskere avklaringer

48 Konklusjon Vi har laget et produkt som samsvarer godt med det oppdragsgiver i utgangspunktet ønsket seg Prosessen har vært litt «humpete» definitivt god lærdom å ta med seg til neste gang man skal jobbe i et slikt prosjekt Utfordrende prosjekt Et produkt som ikke har noe grensesnitt for sluttbruker Vanskelig å demonstrere og systemteste Faglig vanskelig innhold transaksjon, postering, sporbarhet, pålitelighet etc.

49 ?

50 Takk for oss!