1. No category

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
Tidlig utgave av klassediagram
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
Utviklingsprosessen
 Stadige endringer i kravspesifikasjon
 Tidlige sprinter preget av treg progresjon
 Utfordringer:




Milepælsplan som viser overordnet fremdrift
Paralellitet
Sporbarhet
Pålitelighet
Testing
 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
 Bruk av GUID
Tabellen er hentet fra Testrapporten og
viser ytelsesforhold sync vs. async
Sporbarhet
 Hvorfor sporbarhet?
 TransaksjonsID
 Forelder
 Barn
Modellen beskriver ønsket sporbarhet i løsningen
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
GET /postings
Forespørsel
GET api/postings
Beskrivelse
Hente ut alle posteringer.
Response
Kode
Beskrivelse
200
Retunerer en liste med Posting.
POSTING MODEL
Svar
Array med posteringer (JSON)
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!