AL T granskning NeR 2013-01-13 Version 1.0
Revisionshistorik Datum Version Beskrivning Författare 2013-01-13 PA1 Dokumentet skapat AL T, CeHis, Lennart Eriksson 2013-01-31 1.0 Bara gula markeringar inför slutgiltigt överlämnande till NeR AL T, CeHis, Lennart Eriksson Sida i
Innehållsförteckning 1. Inledning 1 1.1 Syfte 1 1.2 Omfattning 1 1.3 Definitions, Acronyms and Abbreviations 1 1.4 Referenser 1 1.5 Översikt 1 2. [G1] SAD NeR 2 3. [G2] Arkitekturella beslut NeR 2 4. [G3] Hantera aktiviteter, remiss Tjänstekontraktsbeskrivning 1.0 beta 4 Sida ii
1. Inledning 1.1 Syfte Nationell elektronisk remiss 2013-01-13 Projektet E-remiss (NeR) har begärt granskning av arkitekturen inför SAD som finns framtagen januari 2013. Granskningen har utförts av Lennart Eriksson ansvarig teknisk arkitektur inom CeHis arkitektur och regelverk. Dokumenten som granskats är att betrakta som slutgiltigt dokument för projektets aktuella etapp. Dock bör det som syns i kommentarer nedan komma in i aktuella dokument vid nästa genomgång för att få till stånd en komplett gemensam plattform. Granskningen syftar till att Belysa lösningens följsamhet mot tekniska arkitekturella krav och regler. Belysa eventuella överlapp med befintliga komponenter i den gemensamma arkitekturen. Att identifiera kandidater till nya komponenter i gemensamma arkitekturen, för att gynna systematisk återanvändning i kommande projekt. Granskningsrapporten är ett redskap i den gemensamma arkitekturprocessen. 1.2 Omfattning Granskningen är avgränsad till den information som NeR projektet delgivit granskningsgruppen via e-post: [G1] Nationell elektronisk remiss (NeR) SAD 0.9, NeR SAD_0 9_Leriks_Vikjer.doc [G2] Nationell elektronisk remiss (NeR) arkitekturella beslut 1.0, Arkitekturella beslut NeR 1_0.doc [G3] Hantera aktiviteter, remiss Tjänstekontraktbeskrivning 1.0 beta, nstekontraktbeskrivning NeR.doc 1.3 Definitions, Acronyms and Abbreviations NeR = Nationell elektronisk Remiss-projektet 1.4 Referenser [R1] T-boken med underdelar som publicerad på CeHis hemsida www.cehis.se, [R2] RIVTA standarder som de finns publicerade på http://code.google.com/p/rivta/. 1.5 Översikt Kommentarer identifieras av en inledande referens på formatet >ALn", d r n r ett löpnummer. Varje kommentar föregås av en färgmarkering, i syfte att uttrycka önskad åtgärd: Svart Gul Röd Diskussionspunkt. Önskan om att projektet uppdaterar arkitekturbeskrivningen. Kan gälla önskan om förtydligande, förslag till alternativa angreppssätt, klargöranden kring Arkitektur och regelverks ståndpunkt m.m. Avvikelse identifierad. Önskan om att projektet etablerar handlingsplan (och budget) för att nå följsamhet inom rimlig framtid. Avvikelse eller åtgärdsbehov identifierat som bedöms angelägen att projektet genomför innan leverans kan bli tekniskt godkänd! Sida 1
2. [G1] SAD NeR Övergripande bedömning är att det inte finns några avvikelser som föranleder omedelbara åtgärder. AB bilagan innehåller en del gula markeringar, detta beror främst på att planering behöver ske i samarbete med andra parter genomgående för att NeR:s beslut skall bli verklighet. T-delen av granskning är OK förutom nedanstående punkter och dess kommentarer. Kommentarer 1.7.3 IT4: Lös koppling >AR1: Eftersom det finns referens (i kommentar) bör den skrivas in i dokumentet. 2.3.1 Flöde AF1 m.fl. >AR2: Utbudstjänst är väl kopplad till AB 2.6. Detta bör framgå av skrivning 3. [G2] Arkitekturella beslut NeR Det finns totalt 10 AB som behöver hanteras när det startas en utveckling inom NeR. Det är av yttersta vikt att varje AB gås igenom och att korrekta förutsättningar kontrolleras innan slutgiltigt beslut fattas. Dessa beslut bör innan beslut kontrolleras med Arkitektur och regelverk på CeHis. Ett antal gula punkter beskrives i dessa AB i stället för på flera ställen i SAD. Kommentarer AB 1 Remisstatus >AR3: För denna del finns det olika lösningar. Fram tills det finns en gemensam processmotor som kan hålla status för olika pågående processer har projektet valt alternativ 2. Förvaltningen av NeR bör fortsatt ta med hantering av detta AB så att på sikt lösningen blir alternativ 3. AB 2 Producent och konsumentavtal >AR4: Dessa avtal är även de viktiga att de explicit hanteras i NeR:s fortsatta förvaltning. AB 3 OID:ar för Green CDA uppfyllnad >AR6: Denna punkt är den punkt som kan bli helt hängande om inte alla parter gör sin del. Detta måste bevakas mycket noga och innan slutgiltigt beslut CeHis Arkitektur kontaktas! AB 4 Meddelande och notifieringstjänst >AR7: Här finns flera explicita beroenden mellan olika implementerande projekt. Vid en eventuell fortsättning med utveckling måste detta mycket noga studeras. AB 5 Remittent och svarsmottagare skall kunna vara olika enheter >AR8: Detta är ett krav som måste tas med i vidare etapper av NeR. Sida 2
AB 6 Sortimentskatalog >AR9: Flera olika projekt behöver denna typ av centralt register över sortiment och utbud. Detta bör förvaltningen starkt trycka på för att få till utanför den temporära lösningen som projektet pekar på. Detta måste bevakas mycket noga och innan slutgiltigt beslut CeHis Arkitektur kontaktas! AB 7 Processmotor >AR10: Denna punkt har en fungerande lösning. Dock bör förvaltning/fortsatt projekt ta fram krav, tidplan och kostnad för anpassning till en gemensam processmotor. Detta måste bevakas mycket noga och innan slutgiltigt beslut CeHis Arkitektur kontaktas! AB 8 Asynkrona anrop >AR11: Den lösning som lösning bygger på finns ännu inte implementerad på TP. Detta måste synkroniseras med intygsprojektet som troligen kommer ta fram denna funktion för sin meddelandelåda. Detta måste bevakas mycket noga och innan slutgiltigt beslut CeHis Arkitektur kontaktas! AB 9 Meddelandetjänstens kontroll av att meddelanden uthämtas inom konfigurerad tid >AR12: Även denna punkt är en koppling till funktion inom intygsprojektets realisering. Detta måste bevakas mycket noga och innan slutgiltigt beslut CeHis Arkitektur kontaktas! AB 10 Tjänsteplattformens möjlighet att skicka meddelanden direkt eller via Meddelandetjänsten >AR13: Den lösning som lösning bygger på finns ännu inte implementerad på TP. Detta måste synkroniseras med implementation inom TP av denna funktion. Detta måste bevakas mycket noga och innan slutgiltigt beslut CeHis Arkitektur kontaktas! Sida 3
4. [G3] Hantera aktiviteter, remiss Tjänstekontraktsbeskrivning 1.0 beta Bedömning av detta dokument sker i samband med genomgång av kontrakt som lagts upp på RIVTA site. T-delen av granskning är OK, med gula påpekanden. Kommentarer Genomgång kontrakt på Google Code RIVTA >AR13: Granskning gjord i detta tidiga skede. Detta måste ses över efter det att implementations etapp påbörjas och måste ny granskning ske. Sida 4