Arena Kundereskontro Gruppe 25 Andreas Åkesson Roger Ommedal Ashkan Vahidishams Simen Trippestad
Gruppe 25 Om oss Gruppemedlemmer: Andreas Åkesson Roger Ommedal Ashkan Vahidishams Simen Trippestad Informasjonsteknologi Samarbeidet på tidligere prosjekter
Agenda Introduksjon Prosessen Løsningen Avslutning
Introduksjon
Oppdragsgiver - Kredinor Norges neste største infordringsselskap Mellom 400-500 ansatte IT avdeling på ca 30 stk Egenutviklede kjernesystemer Kontaktpersoner Ole Marius Thorstensen IT sjef Øyvind Andersen - Systemarkitekt
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?
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
Prosessen
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
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
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
Paralellitet Resultat av krav om høy ytelse Asynkron behandling Tabellen er hentet fra Testrapporten og viser ytelsesforhold sync vs. async Bruk av GUID
Sporbarhet Hvorfor sporbarhet? TransaksjonsID Modellen beskriver ønsket sporbarhet i løsningen Forelder Barn
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
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
Løsningen
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
Klassebibliotekets kontekst AKContext Sentralt RequestContext Lokalt ConnectionString
Klient Et system som tar klassebiblioteket i bruk Klassebiblioteket må vite hvor transaksjonen kommer fra
Implementasjon av klient Interface for klientene Hvorfor? Identifisering av klienter Mottak av transaksjonskvitteringer Opp til Klient å implementere funksjonalitet for håndtering av kvitteringer.
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.
Håndtering av Transaksjonsforespørsler
Trimming av forespørsel
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
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.
Kvitteringer En tilbakemelding fra modulen der klient får vite: Vellykket postering Transaksjon er behandlet fra før Feilmelding
Kvitteringer - nytte Tilbakemelding etter behandling av transaksjon GUID dersom vellykket Beskrivende melding ved feil Gir klienten en mulighet til etterbehandling/loggføring.
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
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
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" : -146.0, "TransferedToAccountingSystem" : null, "Transaction" : null, "ParentTransaction" : null, "Account" : null, "Reference" : null }
Bruk av Web API
Front End AngularJS Javascript MVC-rammeverk SPA (Single-page Application) Brukergrensesnitt i HTML Bootstrap CSS 6 views En controller per view
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(); };
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
Importering av filer
Polling av kvitteringer Etterspørr nye kvitteringer en gang i sekundet Rød: Opplasting av XML (skjer en gang) Blå: Polling (skjer flere ganger)
Sporbarhet
Registrering av enkel transaksjon
Legge til postering/motpostere
Kontoadministrasjon
Registrering av ny klient
Uttak til regnskapssystem <?xml version="1.0"?> <accountingrequest xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema" count="4"> <postings> <posting> <date>2015-06-09t00:00:00+02:00</date> <financial_year>2015</financial_year> <financial_period>1</financial_period> <account_no>1018</account_no> <parent_guid>ea424dfa-ae01-4863-aa2a-974ee31424f3</parent_guid> <amount>-2000</amount> </posting> <posting> <date>2015-06-09t00:00:00+02:00</date>
Avslutning
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
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
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
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.
?
Takk for oss!