Analyse og optimering af et selskabs kundeoverblik

Transkript

1 Analyse og optimering af et selskabs kundeoverblik Jakob Nielsen Kongens Lyngby 2008 IMM-B.Eng

2 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone , Fax

3 Abstract This project deals with systems which should provide information about customers in a pension fund. A crucial functionality is to provide an overview of a customer s data in a fast an reliable manner. We deal with a concrete sceneario (inspired by a current solution) where data is spread on several heterogenous systems. The current solution has deficiencies with respect to availability and response time and this thesis addresses these problems. To solve this problem, a solution based on a cache, was analyzed, designed and implemented. The principles for updating the cache are derived from properties concerning customers pension data, eg. frequency of payments. The new solution was deployed in a development environment (developed in this project), supplying a heterogenous structure with different database systems and a web-based interface. The results were promising, and especially data was available from the cache at all time, even when some connections to the production databases were lost.

4 ii

5 Resumé Dette projekt omhandler systemer, der præsenterer information omkring kunder i et pensionsselskab. En vigtig funktionalitet er at kunne præsentere et overblik over en kundes data på en hurtig og pålidelig måde. Vi behandler et konkret scenarie (inspireret af en eksisterende løsning), hvor data er spredt over flere heterogene systemer. Den nuværende løsning har problemer med hensyn til tilgængelighed og svartider, og denne tese behandler dette problem. For at løse dette problem blev en løsning baseret på en cache analyseret, designet og implementeret. Principperne for opdatering af cache en er baseret på egenskaber i en kundes pensionsdata, eg. frekvensen af indbetalinger. Den nye løsning blev lagt i et udviklingsmiljø (udviklet i dette projekt), der tilbyder en heterogen struktur med forskellige database systemer og en web-baseret brugergrænseflade. Resultaterne var lovende, og specielt var data tilgængelig fra cache en til enhver tid, selv når nogle forbindelser til produktionsdatabaser gik tabt.

6 iv

7 Forord Denne rapport er lavet ved Institut for Informatik og Matematisk Modellering, Danmarks Tekniske Universitet, som delvis opfyldelse af kravene for at opnå en diplomgrad i ingeniørfaget. Rapporten omhandler analyse og optimering af et selskabs kundeoverblik. Hovedfokus ligger på datatilgang og håndtering af data. Der er desuden fokus på anvendelse af nye teknologier og fordele ved anvendelse af disse. Projektet er foregået hos virksomheden Sirius IT A/S, efterfølgende omtalt Sirius, som for en kunde har lavet en specialiseret kundeoverbliksløsning. Det er denne, der i rapporten analyseres og forsøges optimeret. Projektet består af en rapport, der diskuterer systemet, og en optimering af systemet, samt hvordan nye teknologier kan anvendes til dette. Desuden indeholder projektet en implementering af dette koncept. Jeg vil gerne rette en stor tak til Michael R. Hansen, som har vejledt mig igennem dette projektforløb og som har taget sig tiden til at holde ugentlige møder. Ikke mindst vil jeg takke Esben Pedersen, Sirius IT, som har vejledt mig fra virksomheden af. Hans store viden om forretningen har været til stor hjælp. København N, januar 2009 Jakob Nielsen

8 vi

9 Indhold Abstract Resumé Forord i iii v 1 Introduktion Generel introduktion Problemstilling Afgrænsning Problemanalyse Den eksisterende løsning Svartider Datakilder utilgængelige Tilgang til nye former for datakilder Andre datakilder Sikkerhed Cache Kravspecifikation Væsentlige begreber Mit bidrag Opsummering af oprindelige krav Nye krav Design Den nye tilgang Entity Framework

10 viii INDHOLD 4.3 Datalag Webservice interface Load Manager Website Opsætning af udviklingsmiljø Mit bidrag Test Metode Status Eksempel på brug 59 8 Konklusion 69 A Opsætning af udviklingsmiljø 73 A.1 Hypervisor A.2 Database server A.3 Applikations server B Kildekode 81 B.1 Datalag B.2 Webservice B.3 Load manager B.4 Website B.5 Unit tests B.6 Shell scripts B.7 SQL scripts

11 Kapitel 1 Introduktion I dette afsnit gives en kort introduktion til den eksisterende løsning. Problemstillingen diskuteres, og opgaven afgrænses. 1.1 Generel introduktion I en virksomhed med mange kunder, hvor mange afdelinger tager sig af forskellige kundeforhold, kan virksomheden have svært ved hurtigt at få alle relevante kundeoplysninger på en kunde. Ved at have et fælles kundeoverblik kan arbejdsprocesser og håndtering af kunder optimeres betydeligt. Det vil samtidigt spare virksomheden penge, det gør dagligdagen for medarbejdere i virksomhenden lettere, og ikke mindst vil kunden opleve virksomheden som én enhed, frem for flere individuelle enheder. Heraf vil kunden opleve en hurtigere og mere professionel behandling. Dette projekt er en analyse og en optimering af et pensionsselskabs kundeoverblik. For at give et indblik i den eksisterende løsning illustreres kort dennes funktionalitet. Krav vedrørende hvad der skal præsenteres i kundeoverblikket, uddybes i afsnit 3.3, side 19. Brugergrænsefladen til systemet består af et website. Forsiden præsentere et

12 2 Introduktion søgefelt der muliggør søgning på en kundes cpr-nummer. Efter en kunde er fundet frem, præsenteres grundlæggende data (stamdata) på kunden samt kundens to sidste pensionsindbetalinger. Disse informationer vil være tilgængelige på alle undersider. Desuden præsenteres genveje til kundens kundeforhold (aftaler), samt oversigt over bidragsforløb. Af figur 1.1 ses kundeforhold (pensionsaftaler) for en kunde, desuden fremgår den nævnte stamdata i venstre side. Figur 1.1: Stamdata samt kundeforhold for en kunde.

13 1.1 Generel introduktion 3 Ud for hvert kundeforhold er en grøn pil. Ved tryk på denne vises yderligere information for dette forhold. Af figur 1.2 er første forhold valgt og derfor markeret med grå. Detaljer for denne fremgår under PSL bidragssystem. A- PE (alderspension) og de resterende tre-bogstavskombinationer, med tilhørende procentdel, angiver hvor stor dækning kunden har på dette produkt. Se yderligere om de forskellige pensionsprodukter under afsnit 3.1, side 18. Figur 1.2: Detaljer vises for et valgt kundeforhold.

14 4 Introduktion Ved valg af bidragsforløb for kunden vises en liste over kundes bidrag. Da en kunde i løbet af sin pensionopsparingstid vil indbetale mange bidrag, er disse for overskueligheds skyld, begrænset til et vist antal på hver side, hvor de nyeste fremkommer først. Oversigt over bidragsforløb fremgår af figur 1.3. Figur 1.3: Bidragsforløb for en kunde.

15 1.1 Generel introduktion 5 Ud for bestemte felter er angivet en grøn prik med et udråbstegn. Ved at holde musen over dette vises en hjælpetekst, der eksempelvis fortæller, hvilken faggruppe, faggruppenummeret angiver. Denne hjælpetekst er illustreret i figur 1.4. Figur 1.4: Bidragsforløb med forklarende tekst ud for faggruppenummer.

16 6 Introduktion På samme vis som for kundeforhold findes en grøn pil ud for hvert bidrag. Tryk på denne henter og præsentere information om, hvilke produkter bidraget er fordelt på. Dette er illustreret i figur 1.5. Figur 1.5: Detaljer vises for et bidrag med fordeling på produkter. 1.2 Problemstilling Sirius har udviklet et kundeoverblik for en kunde. Kunden oplever dog nogle problemer i forbindelse med brugen af det system, der organiserer information. Systemet tilgår mange heterogene datakilder, som benyttes i produktionen, og som derfor løbende bliver opdateret. Dette kan medføre, at nogle datakilder i perioder er låste eller på anden vis utilgængelige. Det kan også medføre lange svartider. Denne problematik ønskes løst. Desuden har virksomheden et ønske om at kunne tilgå andre datakilder - f.eks. datakilder via webservices og flade filer, der eksempelvis kan være pdf-dokumenter relateret til kunden i form af faktura og lignende.

17 1.3 Afgrænsning 7 Problematikken omkring utilgængelige datakilder og lange svartider tænkes løst ved at indføre en cache mellem produktionsdatakilder og kundeoverblikket. Da der er tale om et system, hvor der kun er behov for læse-adgang, kan data i cachen opdateres asynkront ud fra forretningsviden om, hvor ofte forskellige grupper af data skal opdateres for at være valide. Cache konceptet uddybes under afsnit 2.7, side 13. Der findes systemer på markedet, der implementerer en cache. Her kan nævnes CSQL Cache [2], memcached [4] og TimesTen [5], alle såkaldte in-memorydatabases [16]. For at kunne bruges i en løsning af ovennævnte problemer vil disse kræve meget store mængder hukommelse og er derfor ikke brugbare i denne sammenhæng, hvor der netop er tale om meget store mængder data. Ydermere findes der i virksomheden mange specialiserede og heterogene systemer, hvoraf der skal anvendes mange in-memory-databases, hvilke komplicerer tilgangen yderligere. Den pågældende virksomhed har grundet struktur og forskellighed blandt systemer brug for en specialiseret løsning. 1.3 Afgrænsning Hovedfokus i dette projekt ligger på problematikken omkring tilgangen til datakilder. Nøgleproblemstillingen er de, i for store perioder, utilgængelige produktionsdatakilder og langsomme svartider. Hermed ligger hovedfokus på datalaget og den cache, der er tænkt anvendt, samt anvendelse af nye teknologier hertil. Der vil i mindre grad fokuseres på den grafiske grænseflade til kundeoverblikket. Hvis projektets begrænsede tid tillader det, vil der fokuseres på design af brugergrænsefladen, så denne optimeres til brugen deraf. Projektet er desuden naturligt begrænset af den fiktive data gjort tilgængelig for projektet. Dette medføre at der ikke kan præsenteres alt data i brugergræsefladen og at der ikke kan udvikles og testes for de dele af systemet der benytter disse.

18 8 Introduktion

19 Kapitel 2 Problemanalyse 2.1 Den eksisterende løsning Den eksisterende løsning består af et website, som tilgår datakilder direkte gennem et datalag. Datalaget indeholder dataobjekter, der udgør de forretningsentiteter der ønskes vist i kundeoverblikket. Ved forespørgsler til datalaget, vil det hente data direkte fra produktionsdatabaser, initialisere data- /forretningsobjekter og returnere disse. En illustration af konceptet bag den eksisterende løsning fremgår af figur 2.1, side 10.

20 10 Problemanalyse Web-interface DataLayer Business Objects Bidragsforløb Kundeforhold MedlemsOplysninger FleksionMedlemstilstand Indbetaling Produkt ProduktInfo Stamdata ObsCode PslBidrag PslPension PslPensionAfledte PslPensionSum SystemStatus Utility DlUtils Log... Production databases Figur 2.1: Den eksisterende løsning. Da der i den eksisterende løsning opleves problemer med bl.a. langsomme svartider og låste eller på anden vis utilgængelige datakilder, ønskes en løsning, der kan rette op på dette. Der eksisterer også et ønske om at kunne tilgå nye former for datakilder. Desuden fokuseres på rettigheder i forbindelse med tilgangen til applikationen. Disse problematikker diskuteres yderligere i de følgende afsnit. 2.2 Svartider Medarbejdere der hovedsageligt benytter kundeoverblikket i forbindelse med dialog med kunden, oplever til tider lange svartider. Dette besværliggør deres arbejde, og kunden vil ikke mindst føle sig dårligt betjent. Problematikken omkring svartider fra databaser ligger blandt andet i databasernes funktion. Databaserne er virksomhedens hjørnesten og der foretages beregninger og opdateringer i disse. Derfor kan databaser eller tabeller til tider være kortvarigt låste eller have lange svartider. Ved at benytte en cache imellem produktionsdatabaser og kundeoverblikket (se

21 2.3 Datakilder utilgængelige 11 figur 2.2), vil forespørglser ske på en cache, der ikke er tynget af samme belastning som produktionsdatabaserne, da der ikke opdateres nær så ofte i cache en som i produktionen. Cachen er desuden dedikeret til kundeoverblikket og eneste belastning herpå vil være forespørglser fra kundeoverblikket. Cache databasen vil være denormaliseret, da denne kun rummer data brugt i forretningsentiteterne. Derfor vil der ikke laves kostbare join-operationer på mange tabeller med relationer. Dette kan give væsentligt bedre svartider [6, s. 531]. UI/web-interface Data Layer WS-I Cache... Production databases Figur 2.2: Cache mellem brugergrænseflade og produktionsdatabaser. Svartid er en svær størrelse at måle. En acceptabel svartid kan være meget forskellig, alt efter i hvilken sammenhæng svaret bliver brugt. Hvis en sagsbehandler eksempelvis har en kunde i røret, vil sagsbehandleren kunne hente informationer på kunden gennem kundeoverblikket, mens en dialog med kunden finder sted. Svartiden vil selvfølgelig være uacceptabel, hvis sagsbehandleren ikke har informationerne, når disse skal bruges. Vigtigst er det, at informationerne er tilgængelige til alle tider, så sagsbehandleren reelt kan udføre sit arbejde. 2.3 Datakilder utilgængelige Ved brugen af kundeoverblikket kan det til tider også forekomme, at nogle produktionsdatabaser er utilgængelige. Dette kan medføre før nævnte lange svartider, der medfører at forbindelsen til databasen får timeout. Hvis der forespørges på en tabel, der er låst, kan dette også medfører, at der ikke svares, før forbindel-

22 12 Problemanalyse sen timer ud. Med andre ord er datakilden ikke tilgængelig på det pågældende tidspunkt. Problematikken med lange svartider vil undgåes ved anvendelse af cachen, der ikke vil være utilgængelig i til fælde af, at produktionsdatabaserne ikke kan tilgåes. Der vil ikke være stor belastning på cache-databasen, og timeout vil lidet sandsynligt opstå på grund af belastning. Opdateringer af cachen vil heller ikke foregå i dagstiden, hvor systemet anvendes. Opdatering af cache databasen diskuteres yderligere under afsnit 2.7, side Tilgang til nye former for datakilder I den eksisterende løsning tilgåes kun traditionelle datakilder forstået på den måde, at der fra datalaget kun tilgåes databaser igennem en database-provider. Nyere versioner af den beregningskerne, som virksomheden benytter, eksponerer data via webservices. Derfor er der et ønske om at tilgå denne type datakilder. Ved at benytte.net Framework 3.5 og Windows Communication Foundation (WCF) [9], udvider man mulighederne for at tilgå andre former for services og derved få leveret data på andre måder. Der kan kommunikeres med WCF services via en Remote Procedure Call (RPC) baseret mekanisme, som metodekald. Der er desuden kommet support for kommunikation via Representational State Transfer (REST) [18] i.net Framework 3.5. Dette er også en måde hvorpå man kan kalde en metode via en RPC-baseret mekanisme ved at forespørge på en URL. Denne returnerer svaret i form af eksempelvis XML eller JavaScript Object Notation (JSON) [17], som begge er standardiserede måder, hvorpå man kan repræsentere/gemme data. Ydermere er der support for selv at tilbyde de response formater gennem XML- og JSON-serialisering [17], når WCF benyttes i ens services.dette kan benyttes i forbindelse med brugen af AJAX på et website, eg. en grafisk brugergrænseflade til kundeoverblikket. 2.5 Andre datakilder Kunden, for hvem Sirius har lavet kundeoverblikket, har et journaliseringssystem. I dette projekt vil der dog kun demonstreres, hvordan kundeoverblikket også kunne hente filer fra journaliseringssystemet relateret til en kunde, eksempelvis pdf-dækningsoversigter. Til denne demonstrationen oprettes en simpel database, der simulerer et journaliseringssystems referencer til fysiske filer.

23 2.6 Sikkerhed Sikkerhed Der eksisterer et ønske om større sikkerhed i forbindelse med anvendelsen af systemet. I den eksisterende løsning kan alle på selskabets interne netværk tilgå systemet (websitet). Der noteres dog, i en log, hvem der tilgår det og hvad de tilgår. Dette er et krav fra revisionen, da der præsenteres persondata. I den nye løsning vil det begrænses, hvem der har lov til at tilgå systemet. Styring af tilgangen tænkes gjort gennem det webservice-interface, der eksponerer datalaget. Hvor webservice-kald indeholder den pågældende brugers Active Directory (AD) identitet, og webservicen er bevidst om, hvilke AD-grupper der har lov til at benytte servicen. En yderligere forbedring af sikkerheden kunne opnås ved at kommunikere med webservicen via Secure Socket Layer (SSL) over HTTP (HTTPS). Dette blandt andet ved at oprette certifikater på webserveren, der er vært for webservicen. Man kunne med fordel også benytte WCF Security [9], som også understøtter S- SL over HTTP, Public Key infrastruktur, Kerberos protokol, X.509 certifikater, autentifikation via Windows identitet, der indeholder en Authorization Manager, Windows Cardspace, der samler identiteter til diverse services og giver én tilgang til disse [9], og mange flere ting anvendelige i sikkerhedssammenhæng [13]. Disse ligger tidsmæssigt ud over denne opgave, men ville gøre opgaven i at styrke sikkerheden lettere. 2.7 Cache Ved at indføre en cache mellem brugergrænsefladen, eg. et website, og datakilder skal der tages stilling til flere ting. Cachen skal levere konsistent data, derfor skal der klarlægges, hvor ofte data skal opdateres for at være valide. Dette er tænkt løst ved at gruppere data efter påkrævede opdateringsfrekvens. Grupperingen sker ud fra viden om selskabets forretning. Da der er tale om et pensionsselskab, vil der bl.a. forekomme månedsfremregninger af pension efter pensionsindbetalinger. Der vil være personlig information på en kunde, så som adresse og deslige. Desuden vil der være en mængde dynamisk data, som vil skulle opdateres mere jævnligt. Ud fra dialog med forretningskyndig hos Sirius er følgende tre grupper defineret: Månedligt: Pensionssum, beregnede tal mv. Ugentligt: Personlig information, adresse m.v. Dagligt: Dynamisk data.

24 14 Problemanalyse Der tænkes benyttet Data Warehouse koncepter til håndtering af cachen. Cachen kan anskues som et Data Mart, der er delmængde af et Data warehouse, beregnet på en specifik afdeling eller forretningsfunktion [6, s. 1171]. Ideen bag en Load Manager, der udtrækker og transformerer data for derpå at indlæse dem i warehouse et/data mart et [6, s. 1158], er tænkt benyttet til opdatering af cachen. Cache databasen kan indeholde tabeller med information om og angivelse af hvilke data, der er omfattet af de enkelte intervaller. Denne information vil load manageren benytte sig af ved opdatering af cachen. Et vigtigt aspekt af en cache er synkronisering og opdatering af denne. Flere e- genskaber ved brugen af en cache, netop i kundeoverbliksløsningen, kan dog være med til at løsne kravene en smule. En vigtig egenskab er, at cachen kun skal være læsbar og ikke skrivbar, en såkaldt read-only cache. Det letter arbejdet med at synkronisere data imellem cache-database og produktionsdatabaser, og gør der væsentlig lettere at levere konsistent data. Forretningsspecifikke egenskaber medføre, at bestemte grupperinger af data ikke behøver at blive præsenteret i realtid, i cachen. Disse grupperinger opdateres eksempelvis i produktionen månedligt, ugentligt og dagligt. Derfor vil det for disse ikke være nødvendigt med realtidsdata og valide data kan præsenteres på trods. I forretningen findes desuden et krav om, at sagsbehandleren ikke må angive forventede pensionsudbetalinger baseret på nuværene månedes tal. Disse kunne ske ikke at være fremregnet, og er derfor ikke fuldstændigt sikre. Hvis et beløb oplyses til kunden, er selskabet bundet op på dette. Heraf oplyses kun forventede pensionsudbetalinger for sidst fremregnede månede. Cachens formål er også at skulle optimere svartider. Cache databasen består af forretningsentiteter mappet i tabeller. Af samme grund vil dataen være denormaliseret og i visse tilfælde redundant. Med disse denormaliserede data kan man undgå at lave kostbare (tidskrævende) joins på tværs af mange tabeller. Som oftest vil man kunne nøjes med simple select operationer. Læsehastighed af cachen vil altså forbedres. Dog medfører denormalisering ofte en dårligere skrivehastighed. Til cachens formål er det acceptabelt, da den ikke er opdaterbar fra brugerens side. Den vil kunne opdateres af load manageren og i tidsrum, hvor en lidt langsommere opdateringshastighed ikke vil have betydning. En denormalisering har dog den udlempe, at data fylder mere, da den ofte vil forekomme redundant. På den måde hvorpå cache-databasen anvendes i denne løsning, udgør den kun en delmængde af de informationer, der forefindes i produktionsdatabaserne. Altså er dette ikke set som et stort problem, men skal dog tages med i betragtning. Produktionsdatabaser er primært baserede på Ingres. Ingres leverer.net dataproviders til deres databaser. Der bliver dog i den eksisterende løsning anvendt en dataprovider rettet mod.net framework 1.1. I den nye løsning vil deres nyeste rettet mod.net framework 2.0 anvendes. Ingres har desværre endnu

25 2.7 Cache 15 ikke frigivet en ADO.NET Entity Framework enabled dataprovider, der ville simplificere tilgangen. Det ville også gøre løsningen mere homogen, da der i selve cache-databasen er tænkt anvendt entity frameworket. Entity Framework, EDM og dataproviders uddybes i afsnit 4, side 25. En illustration af cache-konceptet fremgår af figur 2.3. Heraf ses datalaget indeholdende logik for udtræk fra produktionsdatabaser, Entity Data Model en over cache databasen, igennem hvilken cachen opdateres, og data hentes ved forespørgsel på cachen. Desuden ses den omtalte Load Manager, som ud fra forretningsviden om, hvor ofte data skal opdateres for at være valide, opdatere cachen. Datalagets forespørgselsdel er tænkt eksponeret gennem en webservice, load manager benytter datalaget direkte. Load Manager Business Logic Data Categories Update Interval Data Layer WS-I EDM SQL 1 1 * 0..1 * Cache 1..* * 1 * 1... Production databases Figur 2.3: Illustration af cache. En kort opsumering af opdatering er som følger. Load manageren står for opdatering af data. Disse opdateres med en forud defineret frekvens, der er bestemt ud fra viden om forretningsgangen i penssionsselskabet. Heraf vil nogle data opdateres månedligt, ugentligt og dagligt. Opdatering vil ske uden for åbningstid, i løbet af natten.

26 16 Problemanalyse

27 Kapitel 3 Kravspecifikation Da der ikke er tale om konstruktion af et system fra bunden, vil kravspecifikationen ikke ligne en almindelig kravspecifikation. Der tages udgangspunkt i en eksisterende løsning, som før konstruktion havde et kravsæt. Den nye løsning skal selvsagt opfylde samme kravsæt angående hvilke data, der skal præsenteres og være tilgængelige. Ud over disse fremføres nye krav, blandt andet på baggrund af en analyse af problemstillinger i den eksisterende løsning, diskuteret i afsnit 2, side 9. Et use case diagram, der illustrerer sagsbehandlerens brug af kundeoverblikket, fremgår af figur 3.1, side 18. Denne illustrere både krav til den oprindelige løsning, beskrevet i afsnit 3.3, side 19, samt krav til den nye løsning beskrevet i afsnit 3.4, side 23.

28 18 Kravspecifikation Se stamdata Kundeoverblik Se to sidst fordelte indbetalinger Kundeforhold Autentificer bruger Se kundeforhold «uses» Sagsbehandler Se detaljer for kundeforhold Distribruer information til bruger Cache webservice Bidragsforløb Se bidragsforløb Se detaljer for bidrag Se fordeling på produkter Journaliseringssystem Se dokumenter releateret til kunde Hent dokument Figur 3.1: Use case diagram for den nye løsning. 3.1 Væsentlige begreber Stamdata: Omfatter en kundes CPR-nummer, navn, adresse, civilstand og om de har givet samtykke til at pensionsselskabet kan administrere pensionsaftaler på tværs af virksomheden. Fordeling af indbetalinger: Dette er en fordeling af et bidrag på forskellige pen-

29 3.2 Mit bidrag 19 sionsprodukter. Kundeforhold: Hvilke produkter (aftaler) har kunden valgt, og hvad kan kunden forvente at få udbetalt ved pensionering. Udløbsalder: Hvornår ophører kundens pensionsordning, det er den forventede pensionsalder. Pensionsprodukter (aftaler), disse vil resultere i en løbende udbetalinger: APE: Alderspension. IPE: Invalidepension. ÆPE: Ægtefældepension. BPE: Børnepension, op til 18 eller 21 år. WR: Waisenrente, pension der tilfalder børn hvis begge forældre dør. Pensionssummer, disse resultere i en engangsudbetaling: ISUM: Invalidesum, udbetales ved invaliditet. DSUM: Dødssum, udbetales ved død. ASUM: Alderssum, udbetales ved opnået pensionsalder. KAPOPS: Kapitalopsparing. 3.2 Mit bidrag Der forefindes ingen kravspecifikation for det oprindelige system. Derfor er de oprindelige krav i dette afsnit resultatet af egen undersøgelse af løsningens indhold, og ikke mindst pensionsbegreber og pensions-forretningsspecifikke detaljer. Dette arbejde har medført dialoger med forretningskyndige og en nøje gennemgang af det eksisterende systems kildekode samt datakilder. I dette ligger et anseligt arbejde. 3.3 Opsummering af oprindelige krav Den oprindelige løsning havde til formål primært at give sagsbehandlere og aktuarer, en måde hvorpå de hurtigt kunne få et overblik over en kunde og

30 20 Kravspecifikation kundens pensionsordninger og indbetalinger. Herunder følger en opsummering af data præsenteret i kundeoverblikket, samt en kort forklaring af datatypen hvor det ikke er selvforklarende Forsiden På forsiden ønskes vist: Søgefelt, der muliggør søgning på kundes CPR-nummer. Stamdata: CPR-nummer, navn, adresse, civilstand og samtykke. En kunde kan besidde flere jobs, og derfor også flere pensionsaftaler. For at selskabet må give rådgivning på tværs af aftaler, skal kunden give samtykke til dette. De to sidst fordelte indbetalinger. Genvej til kundeforhold. Genvej til bidragsforløb Kundeforhold Under kundeforhold ønskes vist: Alle kundeforhold for den pågældende kunde. Dette er en oversigt over pensionsordninger, kunden besidder. For hver ordning ønskes vist: system, ordning, hvornår kunden er optaget på ordningen, evt. hvornår ordningen fratrædes, kundetype og kunde nummer. For hvert kundeforhold skal der kunne vises: Pensions bidragssystem: Tilstand (aktiv eller hvilende)

31 3.3 Opsummering af oprindelige krav 21 Udløbsalder Løbende pension: bonus, hvilende pension og pension Sumudbetaling: bonus, hvilende pension og pension Ber. md (Beregningsmåned): Den valørmåned, der ligger til grund for pensionsberegningerne. Ber. d. (Beregningsdato): Den dato beregningerne er foretages. Produktinfo: Angiver fordelingen af indbetalingen på pensionsprodukter. Pensionssystem: CPR Pension fra: Hvornår kan personen modtage pension. Ophør: Hvornår ophører denne ordning. Tilstand: Aktiv eller hvilende Årlig pension: Hvad udgør den årlige pension med gældende kriterier. Månedlig pension: Hvad udgør den månedlige pension med gældende kriterier. Pensionssystem sumudbetalinger: Bilagsart og sumudbetaling. I stedet for, eller som supplement til en løbende pension, kan man få udbetalt et engangsbeløb ved pensionering. Dette kan være en dødsfaldssum til de efterladte ved kundens død før pensionsalder eller en sum ved invaliditet. Det kan også ske, at det beløb, man vil få udbetalt månedligt, er så ubetydeligt, at man i stedet får udbetalt et engangsbeløb. Pensionssystem afledte: CPR, navn og tilstand. En afledt pensionist er en, der får udbetalt et beløb, som vedkommende ikke selv har været med til at spare op. Det kan eksempelvis være børnepensionister og ægtefællepensionister, altså pårørende til en hovedpensionist, der enten får pension eller er afdød.

32 22 Kravspecifikation Bidragsforløb Under bidragsforløb ønskes vist en liste af bidrag med følgende parametre: Ordning: Hvilken ordning tilfalder dette bidrag. Faggruppe: Hvilken faggruppe kommer indbetalingen fra, eg. pedeller/rådhusbetjente. Arbejdsgiver Beløb Tildelt valør: Hvornår er valør reelt tildelt. Original valør: Hvornår blev valør oprindelig tildelt. Indbetalingsart: Beskriver om indbetalingen er arbejdsgiverbetalt, selvbetalt, er en supplerende indbetaling, indskud mv. Svarer nøje til oprindelig indbetalingsspecifikation, eg. fra PBS. Fejlkode: Indikerer fejl, f.eks. under præmieregistrering. For hvert bidrag skal der kunne vises en liste med fordeling af bidraget på produkter. Følgende parametre ønskes vist: Indbetalingstype: Minder om indbetalingsart (se ovenfor), men her er indbetalingsspecifikation rettet mod selskabets modtage- og fordelingssystem. Valør: Dato fra hvilken renten beregnes. Produkt: Pensionsprodukt kode. Produktnavn: Navn på pensionsprodukt. Beløb

33 3.4 Nye krav Nye krav Som nævnt skal de tidligere krav angående hvilke data, der skal præsenteres på websitet, stadig opfyldes. Ud over disse har problemanalysen frembragt nye krav til systemet. Da disse er diskuteret i problemanalysen, konkretiseres de blot i følgende Løsning på utilgængelige datakilder Problemet vedrørende de utilgængelige datakilder løses ved at indføre en cache imellem produktionsdatabaser og kundeoverblikket. Ved indførsel af en cache vil belastning, opdateringer og andre faktorer vedrørende produktionsdatabaser ikke spille ind ved forespørgelser fra kundeoverblikket. Man kommer herved ud over problemstillingen omkring for lange perioder med utilgængelige datakilder Løsning på langsomme svartider Ved at indføre en cache opnåes hurtigere svartider. Dette skyldes, at der ikke vil være samme belastning på cache-databasen som på produktionsdatabaserne. Desuden består cache databasen af forretningsentiteter og er derfor denormaliseret. Dette kan give væsentlige performance-forbedringer Synkronisering Som nævnt under afsnit 2.7, side 13, sker synkronisering af cachen med de tidligere nævnte opdateringsintervaller: Månedligt: Pensionssum, beregnede tal mv. Ugentligt: Personlig information, adresse m.v. Dagligt: Dynamisk data. Disse opdateringsgrupperinger skal sikre, at data i cache en altid vil være valide. En Load Manager[6] vil sørge for transformering og indlæsning af data i cachedatabasen. Denne vil også ved utilgængelige produktionsdatabaser sørge for, at

34 24 Kravspecifikation der forsøges opdateret igen. Hvis dette ikke lykkes, fejlmeldes der til driften. Load Manager eksekveres af noget batchkørsel- og job-planlægningssoftware, i dette tilfælde en løsning kaldet Control-M [1]. Dette kan håndtere afvikling af batch-jobs, håndtere logning af disse, samt tage imod fejlbeskeder, som sendes videre til driftansvarlige. Control-M starter Load Manager en gang i døgnet, uden for arbejdstid, hvor en opdatering ikke vil have indflydelse på tilgangen Styring af adgangsrettigheder Der indføres en adgangskontrol på sitet, som benytter Active Directory identitet, som autentifikation imod den webservice, der eksponerer datalaget. Der vil desuden stadig foretages en logning af tilgangen til sitet, som revisionen kræver Tilgang til data fra andre systemer Ved brug af nyeste version af.net frameworket og nye teknologier så som Windows Communication Foundation (WCF) åbnes op for tilgang til nye former for datakilder. Her tænkes i første omgang på data via webservices, da selskabets nye pensionskerne tilgåes via sådanne Dokumenter relateret til kunden At kunne hente dokumenter relateret til en kunde er en naturlig udvidelse til den oprindelige løsning. Desuden er det et krav til den nye løsning, at man kan samle endnu flere data på en kunde på ét enkelt sted Optimering af brugergrænsefladen Hvis projektets begrænsede tid tillader det, vil der fokuseres på brugervenligheden af det grafiske interface fra den oprindelige løsning. Dette kan bl.a. ske ved at benytte flere fordele i teknologier som AJAX, lette søgningen på kunder og sørge let og smidig brug af sitet. For at brugergrænsefladen kan anvende det nye datalag, som eksponeres via en webservice, skal denne grænseflade naturligvis tilpasses dette.

35 Kapitel 4 Design I den oprindelige løsning blev forespørgelser fra brugergrænsefladen gennem datalaget udført i form af SQL-kald, som initialiserede dataobjekter. Disse objekter blev derpå returneret til brugergrænsefladen. I den nye løsning vil forespørgelser ske gennem LINQ to Entities [11] på cache databasen frem for direkte på produktionsdatabaserne. 4.1 Den nye tilgang I denne tilgang er der lavet en mapning af de tidligere dataobjekter over i cachedatabasen. Ud fra denne database er skabt en Entity Data Model (EDM), som er en del af ADO.NET Entity Framework [10].Forespørgsler vil da ske på entiteter i EDM en. Entity Framework og EDM uddybes i afsnit 4.2. Den nye løsning og tilgang til data er illustreret i figur 4.1, side 26.

36 26 Design UI/web-interface Exec (Control-M) Load Manager Business Logic Data Categories Update Interval Data Layer WS-I EDM SQL 1 1 * 0..1 * Cache 1..* * 1 * 1... Production databases Journalisationdatabase PDF-documents Figur 4.1: Illustration af den nye løsning.

37 4.2 Entity Framework Entity Framework ADO.NET Entity Framework (EF ) blev præsenteret i.net Framework 3.5 SP1, og er et sæt data access API er. EF lægger fokus på data gennem en objektmodel frem for gennem en logisk/relationel data model. Dette hjælper med at abstrahere et logisk data skema (data schema) i en konceptuel model. Entity Frameworkets abstraktion af den logiske database struktur sker gennem en model med tre lag, navnligt Entity Data Model (EDM ). De tre lag udgøres af et konceptuelt-, et mapnings- og et logisk lag, hvilket uddybes senere. EF tillader udvikleren at skrive mindre data-tilgangskode (data access code), og derved mindre vedligeholdelse af programmel, og det abstraherer dataens struktur på en mere forretningsvenlig måde. Brugen af LINQ til entiteter (LINQ to Entities), omtalt i afsnit 4.2.1, afhjælper desuden antallet af kompileringsfejl, da entiteterne er genereret som typestærke klasser ud fra den konceptuelle model. Den konceptuelle model uddybes i følgende underafsnit Den konceptuelle model EF genererer en konceptuel model, som udvikleren kan skrive kode imod. Der kan interageres direkte med denne via EntityClient data provideren i form af Entity SQL. En anden mulighed er at benytte Object Services, hvor der anvendes et ObjectQuery objekt, eller ved at bruge LINQ to Entities. Object Services, der præsenterer entiteter som objekter med elementer og relationer eksponeret som egenskaber (properties), gør det muligt at udnytte den konceptuelle models genererede klasser, disse har bla. egenskaber så som typestærke objekter og persistens. ObjectQuery og LINQ er begge måder et forespørge på, hvor LINQ er et nyt forespørgselssprog integreret i.net frameworket. Det og kan forespørge på alt fra databaser til arrays, xml filer og data-klasser. Figur 4.2 [3], side 28, illustrerer EF s arkitektur for at tilgå data.

38 28 Design Figur 4.2: ADO.NET Entity Framework Entity Data Model Kernen af EF er dens modeller. Det understøtter en logisk lagringsmodel, der repræsenterer det relationelle skema fra en database. Da en relationel database ofte gemmer data anderledes, end en applikation bruger disse, tvinger det udvikleren til at hente data, der føres ind i forretningsentiteter, som passer bedre med forretningsregler og brugen af dataen. I dette tilfælde vil der eksistere to modeller, en logisk model for databasen og en konceptuel for forretningsentiteter. Entity Framework udfylder det hul, der er imellem de to modeller igennem en mapningsmodel. Heraf har vi de tre tidligere omtalte lag i EF: Det konceptuelle lag Mapningslaget Det logiske lag

39 4.2 Entity Framework 29 Disse tre lag tillader at mappe data fra en relationel database til en mere objektorienteret forretningsmodel. Entity Frameworket definerer de tre lag i form af XML, hvortil der findes et definitionssprog til hver af de tre lag. Til det konceptuelle lag benyttes Conceptual Schema Definition Language (CSDL), for det logiske lag benyttes Store Schema Definition Language (SSDL), og til at mappe de to lag bruges Mapping Schema Language (MSL). Figur 4.3 [14] illustrerer denne mapning. Figur 4.3: ADO.NET Entity Data Model CSDL definerer entiteter og relationer, som applikationens forretningslag kender dem. SSDL repræsenterer databaseskemaet. Den vil derved have én til én relationer med databasen. Den konceptuelle model kan have én til én relationer med den logiske model, men styrken i EDM ligger i, at man kan have en entitet i den konceptuelle model, som er afledt af flere tabeller i databasen. MSL er det, der gør det muligt for udvikleren at kode imod den konceptuelle model. Entity Frameworkets modeller og mapning abstraherer som sagt datatilgangen. Denne abstraktion har mange fordele, bl.a. undgår man hardcoded SQLstatements i applikationen, som ville skulle ændres ved ændring i tabeller eller ved at benytte en anden type database. Ved at kode mod entiter i den konceptuelle model skrives der ikke databasespecifikke SQL-statements. Derved komme man ud over at skulle omskrive applikationen ved skift af databasetype. Man behøver blot at udskifte dataprovideren. Det er dog et krav, at det er en ADO.NET dataprovider til den pågældende database, som understøtter Entity Frameworket. Entity enabled dataproviders bliver gjort tilgængelige til flere og flere databaser, og mange har varslet, at de har en på vej. Mange ser denne data-tilgang som den måde, hvorpå man vil tilgå databaser fremover.

40 30 Design CustomerOverviewCache EDM Som nævnt før, mappes forretnings entiteter (objekter) fra den tidligere løsning i cache databasen. Herved vil cache databasen kun holde information relevant for kundeoverblikket. Ud fra cache databasen dannes en EDM med de tre tilhørende lag, omtalt i afsnit Entiteterne og deres relationer genereret ud fra cache databasen fremgår af figur 4.4, side 30. Modellen afspejler til en vis grad forretningsmodellen. Dog udgør den kun den del, der er præsenteret i kundeoverblikket. Desuden findes ikke de samme constraints, da databasen som nævnt i afsnit 2.7, side 13, er delvis denormaliseret. Figur 4.4: EDM for cache databasen

41 4.3 Datalag 31 Kundeforholdet er den centrale entitet, der beskriver kundens pensionsaftaler. Stamdata supplerer disse oplysninger med kundens navn, CPR-nummer, adresse mv. Bidragsforløbet er anden central entitet, som udgør en kundes og kundens arbejdsgivers pensionsindbetalinger. Dette danner grundlag for kundens pension, fordelt på forskellige pensionsaftaler (pensionsprodukter). 4.3 Datalag Datalager har en central rolle i kundeoverbliksløsningen. Dette bruges både af load manageren omtalt under afsnit 2.7, side 13, og ikke mindst af webservicen hvor igennem brugergrænsefladen henter data Entity Data Models Datalaget indeholder flere entitet data modeller (EDM), omtalt i afsnit 4.2.2, der bruges for henholdsvis cache databasen, opdateringsdelen og journaliseringssystemet. EDM for selve cache databasen er allerede omtalt i afsnit De to resterende modeller bruges i forbindelse med opdatering af cachen samt autentifikation og journaliseringssystemet. EDM for de informationer, der bruges til opdatering af cache samt autentifikation ved tilgang af webservice fremgår af figur 4.5 og EDM, der bruges ved tilgang til journaliseringssystemet fremgår af figur 4.6, side 32. Figur 4.5: EDM for ekstra informationer på cache databasen. CacheUpdateInfo entiteten beskriver hvor ofte de enkelte forretningsentiteter fra cache databasens EDM (jf. figur 4.4) skal opdateres, samt hvornår de sidst

42 32 Design blev opdateret. AuthGroups entiteten beskriver de AD-grupper der har lov til at tilgå webservicen, og dermed kan benytte kundeoverblikket. Figur 4.6: EDM for journaliseringsdatabasen. Files er den primære entitet, der beskriver en fil fra journaliseringssystemet. Entiteten har egenskaber, der fortæller hvilken kunde filen er tilknyttet, den fysiske sti til filen samt en filtype gennem relationen med den anden entitet FileTypes. Mange filer kan have én filtype. Denne type kunne f.eks. være en dækningsoversigt Opdatering af cache Opdatering af cache databasen sker gennem klassen UpdateCache der fremgår af figur 4.7, side 33. Denne har en række Get-metoder, der bruges til at hente dataobjekter fra produktionsdatabaserne. Disse dataobjekter kommer af den eksisterende løsning og er i stand til at initialisere sig selv ud fra SQL-kald imod produktionsdatabaserne. De eksisterende dataobjekter fremgår af figur 4.8, side 34, dog kun dem det reelt er muligt at benytte, da der som nævnt i introduktionen ikke er data tilgængelig for alle objekter. Get-metoderne henter en samling af disse objekter og bruger dem i Update-metoderne, som igennem den før nævnte EDM (jf. figur 4.4) opdaterer cache databasen. ToBeUpdated-metoden tjekker, igennem EDM for opdateringsinfo (jf. figur 4.5), om den pågældende entitet skal opdateres eller om den er valid, så en opdatering ikke er nødvendig. UpdateLastUpdated-metoden opdaterer, efter endt opdatering af cachen, information om hvornår den pågældende entitet sidst er opdateret. Dette sker ligeså gennem EDM for opdateringsinfo. UpdateCache klassen implementere desuden IDisposable interfacet, som muliggører det at bruge et using statement. Et usingstatement et definere et virkefelt (scope), hvori et eller flere objekter eksisterer. Uden for dette virkefelt, vil alle objekter involveret blive nedlagt og ressourcer

43 4.3 Datalag 33 brugt heri frigjort. Normalt frigiver C#, gennem.net Framework language runtime (CLR), automatisk hukommelse brugt til at gemme objekter der ikke længere er i brug. Frigørelse er udeterministisk og frigøres når CLR beslutter sig for at lave garbage collection, altså at ryde op i ressourcer der ikke længere er i brug. Det er dog som regel bedst at frigøre begrænsede ressourcer så som ressourcer der har fat i filer og netværksforbindelser. Et using-statement tillad programmøren at definere hvornår et objekt der bruger en ressource skal frigive denne. Ønsker man at bruge using-statment et skal objektet implementere IDisposable interfacet og have en Dispose-metode, der nedlægger de ønskede ressourcer. [12]. Figur 4.7: UpdateCache klassen.

44 34 Design Figur 4.8: Oprindelige dataobjekter. I den eksisterende løsning eksisterer 13 dataobjekter, de primære er dog Kundeforhold, Bidragsforloeb og Stamdata, som benyttes i dette projekt. Opdateringen sker som nævnt gennem EDM erne. Ved brug af en EDM arbejder man med modellens objekt kontekst, til denne kan man tilføjer en nye instanser af en entitet.når modellen er opdateret med alle ønskede entiteter, bedes modellen om at gemme ændringer. Disse vil da tilføjes databasen som én operation, en transaktion. Cache databasens EDM objekt kontekst samt objekt kontekst for informations EDM en fremgår af figur 4.9, side 35. De tre primære entitetsobjekter fremgår af figur 4.10, side 36. Som det ses afspejler disse de eksisterende dataobjekter, da cache databasens tabeller som nævnt er en mapning af de eksisterende forretningsobjekter.

45 4.3 Datalag 35 Figur 4.9: Cache databasens objekt kontekst.

46 36 Design Figur 4.10: De primære entitetsobjekter.

47 4.3 Datalag Hente data Til at hente data fra cachen benyttes RetrieveCache klassen, som fremgår af figur Denne har kun Get-metoder, der igennem samme objekt kontekst, der bruges ved opdatering (jf. 4.9), henter data fra cachen. En enkelt metode står for sig selv, navnligt GetAuthGroups, som bruges af webservice interfacet i forbindelse med autentificering. Metoden henter de autentificerede AD-grupper gennem den tidligere nævnte informationskontekst. Figur 4.11: RetrieveCache klassen Tilgang til journaliseringssystem Journaliseringssystemet er oprettet som et fiktivt system. Der findes i produktionen et journaliseringssystem. Dette koncept illustrere hvordan der kan hentes information fra et sådant journaliseringssystem. Tilgang til det fiktive journaliseringssystemes database sker gennem den tidligere nævnte EDM, illustreret i figur 4.6. Til at hente en fil fra journaliseringssystemet, er oprettet en dataobjekt klasse, JournalFile, der er i stand til at initialisere sig selv gennem kald på objekt konteksten for journaliseringsdatabsen, denne fremgår af figur 4.13, side 38. Dataobjekt klassen er illustreret i figur 4.12, side 38. Klassen har en GetFiles-metode, som tager kundens cpr-nummer som argument og returnere en generisk liste af JournalFile objekter. Et JournalFile objekt har egenskaber, der fortæller hvilke filer kunden er tilknyttet, filnavn, fysisk filsti og en filtype brugt til at kategorisere filer. Listen af JournalFile objekter bruges på kundeoverblik websitet, hvor det bindes til et gitter (gridview) for at liste filer tilknyttet kunden.

48 38 Design Figur 4.12: JournalFile klassen. Figur 4.13: Journaliseringsmodellens objekt kontekst Utility klasser Der findes i den eksisterende løsning to utility klasser, som også benyttes i denne løsning. Disse benyttes bl.a. til at konvertere værdier fra databasen til værdier mere præsentable og datoer til dansk tidsformat. Utility klassen, som fremgår af figur 4.14, bruges til dette. Den anden utility klase DlUtils, benyttes af de eksisterende dataobjekter til databasespecifikke operationer, bl.a. at oprette forbindelse til de forskellige produktionsdatabaser. Denne fremgår ligeså af figur Figur 4.14: Utility klasser.

49 4.4 Webservice interface Webservice interface En webservice eksponere, som tidligere nævnt, de dele af datalaget, der benyttes af brugergrænsefladen og bruges som et interface for dette. For at benytte webservicen skal brugeren autentificeres. Dette er som tidligere nævnt bestemt ud fra forud definerede AD grupper. Denne autentifikation benyttes også i brugergrænsefladen, hvor brugeren vil få en meddelelse om, at denne ikke har rettigheder til at tilgå systemet. Angivelsen af AD grupper med tilgang sker i tabellen AuthGroups, som tilgåes via informationskonteksten nævnt i afsnit RetrieveCache-klassen nævnt i afsnit 4.3.3, benyttes i webservicens webmethods, altså de metoder der er tilgængelige gennem webservicen. Disse er alle Get-metoder, da der, som nævnt i afsnit 2.7 kun er læseadgang til cache en. Webservice klassen fremgår af 4.15, side 40. I denne klasse er alle metoder på nær GetFileList og GetFile relateret til cachen. Disse to er brugt til at hente en liste af filer knyttet til en bruger i journaliseringssystemet, samt at hente en pågældende fil fra journaliseringssystemet, så denne kan åbnes af brugeren i kundeoverblikket. I GetFiles bruges JournalFile-klassen fra datalaget til at hente en liste af JournalFile-objekter. Disse objekter indeholder også en fysisk reference til filerne og ved ønske fra brugerfladen om at se en bestemt fil, henter GetFile-metoden denne og sender filen som en byte-stream. Til autentifikation er lavet en brugerdefineret SOAP header, i form af en klasse der nedarver fra.net frameworkets SoapHeader-klasse og definere en property indeholdende domæne og brugernavn. Denne SOAP header skal med i servicekaldet til webservicen for at kunne benytte denne, og ikke mindst skal den property, der angiver domæne og brugernavn kunne verificeres, som værende blandt de AD-grupper der har lov til at benytte servicen. Et eksempel på en forespørgsel med den brugerdefinerede SOAP header fremgår af listing 4.1. Denne viser en forespørgsel på et bidragsforløb på en kunde, hvor brugeren af kundeoverblikkets AD-gruppe og brugernavn gives med som parameter i DomainAndUsername e- lementet, og kundens cpr-nummer i cpr elementet. AuthHeader-klassen fremgår af figur 4.15, side 40.

50 40 Design Listing 4.1: Eksempel på webservicekald med brugerdefineret SOAP header 1 POST /RetrieveCacheWS/RetrieveCacheService.asmx HTTP/1.1 2 Host: localhost 3 Content Type: text/xml; charset=utf 8 4 Content Length: length 5 SOAPAction: <?xml version= 1.0 encoding= utf 8?> 8 <soap:envelope xmlns:xsi= instance 9 xmlns:xsd= 10 xmlns:soap= > 11 <soap:header> 12 <AuthHeader xmlns= > 13 <DomainAndUsername>string</DomainAndUsername> 14 </AuthHeader> 15 </soap:header> 16 <soap:body> 17 <GetBidragsforloeb xmlns= > 18 <cpr>string</cpr> 19 </GetBidragsforloeb> 20 </soap:body> 21 </soap:envelope> Webservicen benytter desuden en hjælpeklasse, WSUtil, der er i stand til bestemme om den pågældende bruger kan autentificeres. Den er også istand til at smide en brugerdefineret SOAP exception, som kastes hvis brugeren ikke kan autentificeres. Figur 4.15: Webservice klasser.

51 4.5 Load Manager Load Manager Load manager benytter Windows Workflow Foundation, som blev inkluderet i.net Framework 3.0. Gennem dette kan afvikles workflows (arbejdsforløb) og giver en deklarativ måde at at skrive et program, ved at linke foruddefinerede aktiviteter, frem for at skrive omfattende kode. Det er desuden muligt at definere kompenserende handlinger, f.eks. ved fejlede aktiviteter. Ydermere er det muligt at opstille regler, eksempelvis at et workflow først er færdig når alle aktiviteter er udført successfuldt, altså kan det forsøge at afvikle en fejlet aktivitet igen. Et workflow er sat op med en aktivitet for opdatering af hver forretningsentitet defineret i cache en. En illustration af dette workflow fremgår af figur 4.16, side 42. Hver aktivitet kalder en tilsvarende metode i datalagets UpdateCache-klasse, eksempelvis UpdateKundeforhold-metoden. Disse aktiviteter er grupperet i en betinget afviklingsgruppe, hvori der er sat et krav om, at alle aktiviteter skal være successfuldt afviklet før workflowet er fuldført. Ved fejl i en aktivitet forsøges denne afviklet igen. Det er dog defineret, at aktiviteten maksimalt forøges afviklet tre gange. Herpå kastes en fejl og workflowet afbrydes. Ideen bag dette er, at produktionsdatabaser kunne være utilgængelige, derfor forsøges opdateret igen, hvis dette ikke lykkes efter et antal forsøg, er der formentlig noget galt og driften bør informeres om dette. Load manageren er som nævnt i afsnit 3.4.3, tænkt afviklet af et batchkørselssystem Control-M. Dette fastlægger en daglig afvikling af load manageren, er i stand til at logge output fra denne og ikke mindst at tage imod fejl. Disse fejl sendes automatisk til driftovervågningen som håndtere dem på passende hvis. Load manageren består af to klasser, en Program-klasse der blot starter workflowet og en UpdateFlow-klasse der udgår selve den sekvensielle workflow aktivitet. Disse fremgår af figur 4.17, side 42.

52 42 Design Figur 4.16: Sekvensielt workflow, der opdatere cache en. Figur 4.17: Load Managerens klasser.

53 4.6 Website Website Kundeoverblikkets brugergrænseflade, et website, er baseret på den eksisterende løsning. Den er dog tilpasset den nye tilgang til cachen, gennem en webservice. Der er desuden tilføjet ekstra informationer på kunden i form af tilgang til det fiktive journaliseringssystem, samt en restriktion af hvem der kan benytte kundeoverblikket. Der er som nævnt i dette projekt en begrænset mængde data gjort tilgængelig. Derfor er det ikke muligt at præsentere samtlige data på websitet. Websitet basere sig på en såkaldt masterpage, som er en skabelon for hvordan sider skal se ud. Denne rummer en indholdsskabelon, hvor sider der benytter masterpage en, kan nøjes med at definere hvad denne skal rumme. Dette sikre et konsisten design over hele sitet, og ikke mindst skal der ikke rettes i samtlige sidder ved ændring på én. De primære elementer der udgør sidens struktur fremgår af figur 4.18, side 44. Default siden (startsiden) er i princippet tom, men benytter masterpage en og vil derfor udgøre indholdet på denne. TreeViewStateklassen håndtere menuens tilstand. SessionData-klassen indeholder sessionsdata, og bevarer sessionens data ved skift til undersidder eller ved genindlæsning af en side. Grundinformationer (stamdata) på kunden vises på alle sider (jf. generel introduktion afsnit 1.1), for at bevare den imellem disse bruges SessionsDataklassen. Der bruges tre undersider, som viser kundens kundeforhold (pensionsaftaler), kundens bidragsforløb og dokumenter fra journaliseringssystemet relateret til kunden. Alle disse benytter som nævnt masterpagen. Data præsenteres på alle sider i såkaldte gridviews, som er et gitter hvori man kan datafelter. Et gridview giver et godt overblik og er meget brugerdefinerbar, så den kan tilpasset de behov for præsentation der eksisterer. Siderne indeholder metoder til at hente data, som derpå kan bindes til gridviewet. Data henter, som nævnt i afsnit 4.4, data via webservice interfacet. Altså er webservicen eneste tilgang til data. Alle forespørgsler til webservicen sker som nævnt i afsnit 4.4 med en brugerdefineret SOAP header, der indeholder brugerens initialer og domænegruppe, som bruges til autentifikation ved tilgang til webservicen. Godkendes denne ikke, returnere webservicen en brugerdefineret SOAP exception, som fanges på siden forespørgslen kom fra, og præsenteres for brugeren.

54 44 Design Figur 4.18: Websitets primære elementer.

55 4.6 Website 45 Figur 4.19: Websitets undersider.

56 46 Design

57 Kapitel 5 Opsætning af udviklingsmiljø Til projektet fandtes ikke et udviklings- og testmiljø, hvor applikationer og databaser kunne afvikles. Der findes i virksomheden strenge krav om separation af test og udviklingsmiljø fra produktionsmiljøet og godkendelse af en række tests, inden applikationen kan flyttes til produktionsmiljø. Udviklings- og testmiljø skal have størst mulig lighed med produktionsmiljøet. Det skal understøtte det heterogene miljø, som findes i produktionen, som en blanding af platforme og databaser. I dette projekt fokuseres primært på to platforme. Windows-platformen, hvor applikationen afvikles, og som vært for Microsoft SQL Server databaser, samt en linux-platform som vært for Ingres databaser og pensionsapplikationer. Windows platformen agerer også vært for det fiktive journaliseringssystem. Figur 5.1, side 48, illustrerer udviklings- og testmiljø opsætning. Testmiljøet afviger en smule fra det eksisterende produktionsmiljø. Primært findes afvigelsen i ressourcer allokeret til databaser og applikationer. Ingres databaser og pensionsapplikationer kører i produktionen dels på et SUSE Linux Enterprise baseret cluster, som er meget skalerbart, og som desuden baserer sig på højtydende diske og SAN-lager, og til dels på ældre UNIX-platforme baseret på Compaqs Tru64 operativsystem. I testmiljøet benyttes SUSEs gratis variant af deres styresystem, OpenSUSE. Denne kører på en såkaldt hypervisor, som fungerer som vært for flere virtuelle servere. Se yderligere om hypervisor og valg

58 48 Opsætning af udviklingsmiljø af denne i appendix A.1, side 73. Windows servere kører ligeledes på samme hypervisor, hvor de i produktionen enten kører på en dedikeret fysisk server eller på nogle store virtualiseringsservere. I testmiljøet i dette projekt er én server med moderate ressourser til rådighed.de virtuelle servere på denne må da deles om de tilgængelige ressourcer. Database afvigelser, opsætning af disse... VMWare ESXi hypervisor Windows 2003 Server IIS 6.0 webserver Vært for webapplikation, Load Manager samt webservices SUSE linux Ingres 9.2 database Pensionsdatabase (mofdb) Webservices Virtual ethernet Windows 2003 Server MS SQL Server 2005 Cache database Windows 2003 Server MS SQL Server 2005 Journaliseringsdatabase Figur 5.1: Illustration af udviklingsmiljø opsætning. 5.1 Mit bidrag Der var til projektet ikke givet et testmiljø. Derfor er der under dette projekt brugt tid på opsætning af et sådant, og ikke mindst undersøgelse af mulige løsninger samt konfiguration og håndtering af disse. Desuden var der behov for at overføre databasestrukturen for Ingres database på Linux-platformen til testmiljøet og ikke mindst at generere fiktivt data til brug i denne. Opsætning og håndtering af testmiljø er til fulde mit værk. Overførsel af databasestruktur for Ingres database, generering af fiktiv data samt scripts dertil er stillet til rådighed af Sirius vejleder.

59 5.1 Mit bidrag 49 Vejledning til opsætning af udviklingsmiljø samt valg taget i forbindelse med dette fremgår af appendix A, side 73.

60 50 Opsætning af udviklingsmiljø

61 Kapitel 6 Test Alt data fra produktionsdatabaser er ikke gjort tilgængeligt. Derfor vil nogle test naturligt fejle, da det ikke er muligt at hente informationer for disse. 6.1 Metode Der er brugt to testmetoder, henholdsvis whitebox-test og blackboxtest. I whitebox testen vælger en person med kendskab til systemet og kildekoden selv hvordan, der bedst kommes igennem alle kodestier. I blackbox testen anskuer man systemet som en lukket boks, uden kendskab til hvad der ligger bag. Dette er den nemmeste tilgang ved større systemer, men der sikres ikke at hele systemet testes. Blackbox testen er i afsnit udført i form af unit tests.

62 52 Test Whitebox Whitebox testen tager udgangspunkt i use case diagrammet, der fremgår af figur 3.1, side 18. Test Forventet resultat Se stamdata CPR-nummer, adresse, postnr. og postdistrikt, civilstand og samstykke Se to sidst indbetalinger To sidst fordelte indbetalinger Se kundeforhold Kundeforhold med angivelse af system, ordning, optaget fra/til, afgangsår, kundetype og kunde nr. Se detaljer for kundeforhold Pensionsaftaler, med angivelse af tilstand, udløbsalder, bonus, løbende/hvilende pension, pension, beregningsmåned og dag Se bidragsforløb Liste af bidrag, med ordning, faggruppe, arbejdsgiver, beløb, tildelt valør, original valør, indbetalingsart og fejlkode Se detaljer for bidragsforløb Bidragets fordeling på pensionsaftaler Se fordeling på produkter En liste af produkter med angivelse af hvor stort beløb der tilfalder dette Resultat OK CPRnummer, adresse, postnr. og postdistrikt, civilstand og samstykke Intet Vises korrekt Intet. Vises korrekt Intet Intet

63 6.1 Metode 53 Se dokumenter relateret til En liste af dokumenter en kunde med tilgørende dokumenttype Hente dokument Brugeren bliver bedt om at gemme filen, og kan derefter åbne dokumentet Vises korrekt Forløber korrekt Som det fremgår af ovenstående tests, kan flere punkter ikke præsenteres. Dette skyldes som nævnt de manglende data. Udførelse af de samme tests med forbindelsen til produktionsdatabaser afbrudt gav samme resultat. Hermed ses, at cachen opfylder kravet om at være tilgængelig på trods af utilgængelige produktionsdatabaser Blackbox I blackbox testen testes datalagets UpdateCache- og RetrieveCache-klasser. Webservicen testes mere grundigt, da denne benytter samme klasser, og er den der eksponere datalaget til brug for kundeoverblikket. Loadmanageren i forskellige scenarier, hvor forbindelsen til produktionsdatabaser bl.a. afbrydes. Blackbox tests er udført som unittest brugt hele vejen gennem udviklingsforløbet. Disse fremgår af af appendix B.5, side 181. UpdateCache Test Test Forventet resultat Resultat OK Hent alle kunde CPRnumre. 100 stk. 100 stk. Opdater stamdata 100 elementer 100 elementer Opdater medlemsoplysningeter 100 elementer 100 elemen- Opdater kundeforhold 100 elementer 100 elementer Opdater bidragsforløb 6013 elementer 6013 elementer

64 54 Test Opdater LastUpdated :22:38 +/-1 min :22: Som det fremgår af ovenstående test, fungere klassen til opdatering af cachen korrekt. RetrieveCache Test Test Forventet resultat Resultat OK Hent stamdata på cpr Navn: Jens Nedergaard Navn: Jens Nedergaard Hent bidragsforløb på cpr 58 bidrag 58 bidrag Hent kundeforhold på cpr System: PSL, Ordning: System: PSL, Ord- ning: 600 Hent om kunden med cpr Tom streng, da der Tom streng har inbetalinger ikke er data for dette på ventekonto At hente data fra cachen fungere ligeså korrekt. Webservice Test Test Forventet resultat Hent stamdata på cpr Navn: Jens Nedergaard Gade: Bir- kestræde 23 Postnr: 1412 Distrikt: København K Samstykke af- Hent stamdata med en bruger der ikke er autentificeret givet: J SOAP exception med beskeden: Du er ikke autoriseret til at benytte denne service. Resultat Navn: Jens Nedergaard Gade: Birkestræde 23 Postnr: 1412 Distrikt: København K Samstykke afgivet: J Du er ikke autoriseret til at benytte denne service. OK

65 6.1 Metode 55 Hent bidragsforløb på cpr Hent kundeforhold på cpr Hent fileliste for kund med cpr Hent file med navn Bidragsoversigt pdf Hent fil med en bruger der ikke er autentificeret Ordning: 600 Faggruppe: 555 arbejdsgiver: 50 Beløb: 1331,23 Tildelt valør: 2447 Aktuel valør: 2447 Indbetalingsart: 1 Fejlkode: 23 System: PSL Ordning: 600 Optaget fra: 2447 Optaget til: 9999 Afgangsår: 0 Kundetype: amp Kundenr: Første fil med navnet: Bidragsoversigt pdf Type: Bidragsoversigt Filstørrelse: bytes SOAP exception med beskeden: Du er ikke autoriseret til at benytte denne service. Ordning: 600 Faggruppe: 555 arbejdsgiver: 50 Beløb: 1331,23 Tildelt valør: 2447 Aktuel valør: 2447 Indbetalingsart: 1 Fejlkode: 23 System: PSL Ordning: 600 Optaget fra: 2447 Optaget til: 9999 Afgangsår: 0 Kundetype: amp Kundenr: Første fil Bidragsoversigt pdf Type: Bidragsoversigt bytes Du er ikke autoriseret til at benytte denne service. Webservice testene er væsentlig mere omfattende. Der testes for samtlige værdier returneret. Samtlige tests forløb korrekt. Der er dog undladt at teste for de data det ikke er muligt at hente, som nævnt i starten af afsnittet.

66 56 Test Load manager Test Der er i load manager testen testet forskellige scenarier, som følger. Af listing 6.1 fremgår output fra et normalt opdateringforløb, hvor alle entiteter opdateres. Returkoden bruges af det batch-afviklingssoftware deres bruges til at afvikle load manageren, som nævnt i afsnit 4.5, side 41. Returkode 0 indikere successfuld udførelse, hvorimod returkode 90 er en alvorlig fejl. 1 Kundeforhold updated 2 Stamdata updated 3 MedlemsOplysninger updated 4 Bidragsforloeb updated 5 ReturnCode returned from the program: 0 Listing 6.1: Successfuld fuld opdatering Af listing 6.2 fremgår output hvor tre af fire entiteter er valide og ikke behøver opdateres. Kun stamdata entiteten opdateres i dette tilfælde. Listing 6.2: Successfuld opdatering, én opdateret 1 Kundeforhold is up to date 2 Stamdata updated 3 MedlemsOplysninger is up to date 4 Bidragsforloeb is up to date 5 ReturnCode returned from the program: 0 Af listing 6.3 fremgår output hvor der først ikke kan skabes forbindelse til produktionsdatabasen, og derpå opnåes forbindelsen og der opdateres successfuldt. Listing 6.3: Først kan der ikke opdateres, herpå prøves igen med success 1 Tried to update Kundeforhold, which failed, trying again. Attempt no. 1 2 Tried to update Stamdata, which failed, trying again. Attempt no. 1 3 Tried to update Medlemsoplysninger, which failed, trying again. Attempt no. 1 4 Tried to update Bidragsforloeb, which failed, trying again. Attempt no. 1 5 Tried to update Kundeforhold, which failed, trying again. Attempt no. 2 6 Tried to update Stamdata, which failed, trying again. Attempt no. 2 7 Tried to update Medlemsoplysninger, which failed, trying again. Attempt no. 2 8 Tried to update Bidragsforloeb, which failed, trying again. Attempt no. 2 9 Kundeforhold updated 10 Stamdata updated 11 MedlemsOplysninger updated 12 Bidragsforloeb updated 13 ReturnCode returned from the program: 0

67 6.2 Status 57 Af listing 6.4 fremgår output hvor alle opdateringer fejler, der forsøges det antal gange der er fastsat for hver entitet, derpå rapporteres fejlen og returkode 90 returneres for at indikere fejl. Listing 6.4: Alle opdateringer fejler 1 Tried to update Kundeforhold, which failed, trying again. Attempt no. 1 2 Tried to update Stamdata, which failed, trying again. Attempt no. 1 3 Tried to update Medlemsoplysninger, which failed, trying again. Attempt no. 1 4 Tried to update Bidragsforloeb, which failed, trying again. Attempt no. 1 5 Tried to update Kundeforhold, which failed, trying again. Attempt no. 2 6 Tried to update Stamdata, which failed, trying again. Attempt no. 2 7 Tried to update Medlemsoplysninger, which failed, trying again. Attempt no. 2 8 Tried to update Bidragsforloeb, which failed, trying again. Attempt no. 2 9 Tried to update Kundeforhold, which failed, trying again. Attempt no Tried to update Stamdata, which failed, trying again. Attempt no Tried to update Medlemsoplysninger, which failed, trying again. Attempt no Tried to update Bidragsforloeb, which failed, trying again. Attempt no Tried to update Kundeforhold 3 times without success. 14 Tried to update Stamdata 3 times without success. 15 Tried to update Medlemsoplysninger 3 times without success. 16 Tried to update Bidragsforloeb 3 times without success. 17 Exception: The underlying provider failed on Open. 18 ReturnCode returned from the program: Status Testene forløb meget pænt og systemet opfører sig som forventet. De fejlede test skyldes som nævnt de manglende data. Ovenstående test præsenterede ingen fejl, ud over de forventede. Mere dybdegående test, og gerne af en tester der ikke kender det bagvedliggende system kunne måske finde sådanne. Da virksomheden er en finansiel virksomhed, er der strenge krav til idriftsættelse af systemer, så vel som idriftsættelse af rettelser i systemer. Hvis denne løsning skulle benyttes i virksomheden, skulle den igennem en række accepttests. Dette vil i endnu højerede grad sikre korrekt opførsel.

68 58 Test

69 Kapitel 7 Eksempel på brug I dette afsnit gennemgåes kort siden i brug. Hovedsageligt i form af screenshots, da disse giver et godt billede af hvordan kundeoverblikket fungere. Der kan med fordel sammenlignes med dem af det eksisterende system i den generelle introduktion afsnit 1.1, side 1.

70 60 Eksempel på brug Af figur 7.1 fremgår den startsiden for kundeoverblikket. Her kan søges på en kundes cpr-nummer. Figur 7.1: Startside.

71 61 Af figur 7.2 fremgår søgeresultatet på en kundes cpr-nummer. Stamdata på kunden præsenteres. Figur 7.2: Stamdata.

72 62 Eksempel på brug Af figur 7.3 fremgår kundeforholdssiden, der præsentere en for alle kundens forhold. På nedenstående billede har kunden kun et enkelt kundeforhold. Figur 7.3: Kundeforhold.

73 63 Af figur 7.4 fremgår kundens bidragsforløb. Her ses samtlige bidrag kunden har indbetalt. Da der som oftest forekommer mange bidrag i løbet af en pensionsopsparing, er disse delt op med 13 på hver side. Figur 7.4: Bidragsforløb.

74 64 Eksempel på brug Af figur 7.5 fremgår dokumenter relateret til kunden, disse hentet fra det fiktive journaliseringssystem. Ved at klikke på pdf-ikonet ud for dokumentet, kan filen hentes. Figur 7.5: Dokumenter relateret til kunden.

75 65 Af figur 7.6 fremgår den dialog der fremkommer når man trykker på pdf-ikonet. Dialogen giver mulighed for at gemme dokumentet på den lokale computer og åbne den her. I Firefox åbnes dokumentet i direkte i browseren. Figur 7.6: Dialog for at hente filen og gemme den lokalt.

76 66 Eksempel på brug Af figur 7.7 illustrere den fejlmeddelelse brugeren bliver præsenteret for, når denne ikke har lov at tilgå kundeoverblikket. Figur 7.7: Brugeren præsenteres for en fejlmeddelelse, hvis denne ikke er kan autentikeres.

77 67 Af figur 7.8 viser den fejlmeddelelse brugeren bliver præsenteret for, når en fil ikke kan hentes. Figur 7.8: Brugeren præsenteres for en fejlmeddelelse, hvis filen ikke kan hentes.