AP221 Use Case TUL Utvikle tjenesteinnhold

Transkript

1 AP221 Use Case TUL Utvikle tjenesteinnhold

2 Utvikle tjenesteinnhold Use caset omhandler utvikling av innhold for en tjeneste. Resultatet av use caset er den faktiske presentasjonen sluttbrukeren ser i Sluttbrukerløsningen, hovedsaklig skjemautvikling i InfoPath. Det innebærer layout, grafikk, kalkyler, kontroller, mappinger mellom filformat og skjema, presentasjon, navigasjon osv. Herunder vil også tilpasninger ift Elmer 2-standarden utføres. Ikke alle aktivitetene foregår i InfoPath, noen gjøres andre steder i Tjenesteutviklingsløsningen. Dette er nevnt i aktivitetsbeskrivelsen. Tjenesten kan defineres på flere språk. Tjenesteutvikler lager kun én InfoPath-fil, på hovedspråket. Denne oversettes i oversettelsesmodulen. Definering av språk for andre deler av tjenesten gjøres også i oversettelsesmodulen. Se use case Oversett tjeneste. Ved migrering til sluttbrukermiljø, genereres InfoPath-filer for de andre språkene som er definert i oversettelsesmodulen. InfoPath er et Microsoft Office-produkt, og alle standard funksjoner som klipp, lim, søk, hjelp osv er tilgjengelige. Dette gjør det mulig å gjenbruke for eksempel felter, kalkyler, tekster og lenker fra en annen tjeneste. Verktøyet kan brukes av ikke-tekniske personer etter en initiell opplæring. InfoPathdokumentet lagres som et vanlig SharePoint-dokument, og arkivering, versjonshåndtering og tilbakerullingsmulighetene dekkes her. En tjeneste består av flere ulike informasjonselementer. I tillegg til det som beskrives i dette use caset er det også egne sider for registrering av metadata på tjenesten (se use case Definer tjeneste ) og egne sider/dokumenter for oversettelse (se use case Oversett tjeneste ). Det er lagt opp til at flere tjenesteutviklere kan jobbe samtidig på de ulike deler av en tjeneste. Innenfor hvert dokument eller side er det bare mulig for én tjenesteutvikler å oppdatere. Dette kommer av dokumenthåndteringen i SharePoint med låsing av dokument for eksklusiv oppdatering og versjonskontrollering. Utvikling av formidlingstjenester vil foregå ved bruk av Microsoft BizTalk som vil være tilgjengelig på Citrix arbeidsflaten for tjenesteutviklingsløsningen. Følgende aktiviteter kan utføres: Importere meldingsspesifikasjon Transformasjon i grafisk verktøy Transformasjon fra ML til ML, fra flatfil til ML og fra ML til flatfil Enhetstesting av transformasjonen Formidlingstjenester vil ikke beskrives ytterligere i use caset. Dokumentet er organisert i to use case, og de tilhørende aktivitetsdiagrammene kommer før beskrivelsen av de respektive use case. Utvikle tjenesteinnhold Viser utviklingen av innhold for alle tjenestetyper. Dette inkluderer import og eksport av meldingsbeskrivelse, bruk av mal, utvikling av layout etc. Utvikle tjenesteinnhold Innsendingstjeneste Viser aktivitetene for utvikling av tjenesteinnhold som er spesifikt for innsendingstjeneste. For innsendingstjeneste vil det også være mulig å lage transformasjon av data til mottaksformat (annet enn generisk ML) ved hjelp av Biztalk Mapper, som en del av Visual Studio. Tabell 1 viser sammenhengen mellom de forskjellige tjenestene og hvilke elementer som kan inngå i de forskjellige tjenestene. Tabell 1 - Aktiviteter som kan utføres i utvikling av tjenesteinnhold 2

3 Aktivitet Felles Innsendingstjeneste Meldingstjeneste Importer meldingsbeskrivelse Eksporter meldingsbeskrivelse Utvikle layout (dynamisk layout, grafikk...) Utvikle utskriftsversjon Utvikle kontrollere og valideringer Utvikle kalkyler Angi preutfylling Angi oppslag i støtteregistre Angi sporvalg Angi betalingsinfo Angi kodelistekobling Formidlingstjeneste Opprettelse og utvikling av meldings- og innsendingstjeneste foregår i InfoPath. Typiske steg for utvikling av en tjeneste i InfoPath, som tjenesteutvikler må igjennom er: 1. Laste opp meldingsformat (xsd) 2. Lage view(s) 3. Trekke grupper/felter fra meldingsformat over på det enkelte view 4. Definere layout 5. Endre/legge til tekster 6. Lage regler/valideringer/kalkuleringer 7. Enhetsteste 3

4 Utvikle tjenesteinnhold Velg utgangspunkt Lag nytt Endre eksisterende Velg tomt dokument Velg fra mal Åpne Lagre Velg funksjon Importer meldingsbeskrivelse Utvikle layout Hvis innsendingstjeneste? Eksporter meldingsbeskrivelse Utvikle utskriftsversjon Utvikle tj.innhold - Innsendingstjeneste Figur 1 - Utvikle tjenesteinnhold Referanse til krav Aktør(er) Trigger Pre-betingelser Post-betingelser Normal utføring Utvikle tjenesteinnhold Se Tabell 2 Krav Fagperson, Teknisk Bruker velger å utvikle tjenesteinnhold Test avdekket feil i tjenesteinnhold Bruker er logget inn (use case Logg inn) Tjeneste opprettet (use case Opprett tjeneste og tjenesteutgave) Tjeneste som skal utvikles er valgt (use case Finn tjeneste og utgave) Bruker har navigert til tjenestearbeidsflat og tjenestetype er valgt Tjenesteinnhold for tjenesten er utviklet Utvikling av tjenesteinnhold skjer i all hovedsak i InfoPath, og kan bestå av aktivitetene angitt i Tabell 1 - Aktiviteter som kan utføres i utvikling av tjenesteinnhold for den gitte tjenestetype. Tabellen viser et sett med aktiviteter som er felles for alle tjenestetyper, samt aktiviteter som er spesifikke for den gitte tjeneste. Meldingstjeneste vil i stor grad ikke inneha noen egne, spesifikke aktiviteter, men bli utviklet ved hjelp av fellesaktiviteter. 1. Velg utgangspunkt: Bruker velger utgangspunkt (TUL) a. Velger å lage et nytt skjema/presentasjon i. Velger en tjenestemal som finnes 4

5 ii. Velger å begynne med et nytt, tomt skjema/presentasjon. b. Velger å endre eksisterende skjema/presentasjon 2. Åpne: Bruker åpner skjema/presentasjon (InfoPath) 3. Velg funksjon: Bruker står overfor flere aktiviteter som er frivillige og kan gjøres i vilkårlig rekkefølge. Alle aktivitetene kan også gjentas flere ganger: Importer meldingsbeskrivelse (InfoPath) Bruker importerer en eksisterende ML schema meldingsspesifikasjon inn i InfoPath. Dersom bruker ønsker å rulle tilbake til en tidligere versjon av meldingsbeskrivelsen gjøres det ved å importere ønsket versjon. Eksporter meldingsbeskrivelse (InfoPath) Bruker eksporterer ML schema meldingsspesifikasjon fra InfoPath. Utvikle layout (InfoPath) Bruker angir brukergrensesnittelementer, farger, dynamisk layout, tekstfelter og andre brukergrensesnittrelaterte elementer. Dynamisk layout innebærer at layout endres dynamisk på bakgrunn av valg, feltverdier eller kalkyler i skjemaet. Innebærer også å definere hvordan en side i et skjema/presentasjon skal, eller kan, oppføre seg på bakgrunn av brukervalg i skjemaet. Et eksempel vil være at elementer skjules eller vises avhengig av valg på siden eller feltverdier. Må ikke forveksles med sporvalg. Utvikle utskriftsversjon (InfoPath) Innebærer å definere en egen presentasjon av tjenesten som kun brukes ved utskrift. Dette gir muligheten til å presentere dataene på en mer utskriftsvennlig måte enn skjermvisningen. Innsendingstjeneste (InfoPath) Innebærer alle aktivitetene vist i Tabell 1 - Aktiviteter som kan utføres i utvikling av for innsendingstjeneste. Se use case Utvikle tjenesteinnhold Innsendingstjeneste Alternativ utføring Hvis ønsket mal for tjenestetype ikke finnes, vil denne måtte lages av en IKT / Teknisk person. Feilhåndtering Import av meldingsbeskrivelse kan feile. En informativ feilmelding skal da vises. Forretningsregler Tjenesteutvikler skal kunne utvikle og endre alle relevante aspekter ved brukergrensesnittet til tjenesten (skjema) Utviklingen trenger ikke gjøres ferdig i én omgang, men tjenesteutvikler skal kunne gå til andre deler av tjenesteutviklingen og returnere til utviklingen på et hvilket som helst tidspunkt. Referanse til Opprettet tjeneste og tjenesteutgave eksterne use case (s) o AP221 Use Case - TUL Opprett tjeneste og tjenesteutgave.doc Logge inn o AP221 Use Case - TUL Logg inn.doc Finn tjeneste o AP221 Use Case - TUL Finn tjeneste.doc Krav dekket i design Se Feil! Fant ikke referansekilden. 5

6 Utvikle tjenesteinnhold Innsendingstjeneste Velg funksjon Angi sporvalg Angi betalingsinfo Utvikle kalkyler Utvikle kontrollere og valideringer Angi preutfylling Angi kodelistekobling Angi oppslag i støtteregistre Tilpass til Elmer2 Figur 2 Innsendingstjeneste elementer Referanse til krav Aktør(er) Trigger: Pre-betingelser Post-betingelser Normal utføring Utvikle tjenesteinnhold Innsendingstjeneste Se Tabell 2 Krav Fagperson, Teknisk Bruker velger å utvikle tjenesteinnhold Test avdekket feil i tjenesteinnhold Bruker er logget inn (use case Logg inn) Tjeneste opprettet (use case Opprett tjeneste og tjenesteutgave) Tjeneste som skal utvikles er valgt (use case Finn tjeneste og utgave) Tjenestetype innsendingstjeneste er valgt Tjenesteinnhold for tjenesten er utviklet Dette use caset utvider use caset Utvikle tjenesteinnhold. Use caset utdyper enkeltstegene i prosessen for utvikling av tjenesteinnhold for innsendingstjeneste. Det er mulig for skjemautvikler å velge i hvilken rekkefølge og hvordan tjenesten utvikles. Det er også mulig å iterere over de forskjellige funksjonene mange ganger. Det er ikke mulig for flere tjenesteutviklere å jobbe med samme skjema i en InfoPath-fil samtidig. Dette kan omgås ved å kopiere et view fra et InfoPathdokument til et annet. Dermed kan flere tjenesteutviklere jobbe på samme skjemaet samtidig. På ønsket tidspunkt (evt. ved ferdigstillelse) kopierer tjenesteutvikler viewet tilbake til originalfilen. En innsendingstjeneste består av ett eller flere skjema. Dersom tjenesten består av flere skjema, danner disse til sammen et skjemasett. Felt i alle skjemaene i skjemasettet er tilgjengelige for oppslag og beregninger ved å 6

7 importere skjemasett-xsd en på samme måte som meldingsbeskrivelsen importeres og benyttes. Se use case Spesifiser skjemasett. Beskrivelse av normalutføring for de enkelte elementene: Utvikle kontrollere og valideringer (InfoPath/Visual Studio) Innebærer å definere og utvikle feltvalideringer. Her angir man f.eks. at inndata i et bestemt felt skal være på et gitt format eller at inndata i et tallfelt må være over/under en bestemt verdi. Det kan legges til én eller flere utslagstekster til en kontroll. Disse vises avhengig av hva resultatet av kontrollen er. Kontroller og valideringer som er lagt til radene i en tabell vil kopieres til nyopprettede rader i tabellen. Utvikle kalkyler (InfoPath/Visual Studio) Innebærer å lage kalkulasjoner for et eller flere felt. Her kan man angi summeringer og transformasjon av talldata. Her vil det kunne være naturlig å kombinere kalkyler og valideringer. Feltinformasjon kan tas med fra en side til en annen uten bruk av hjelpefelter. Kalkyler som er lagt til radene i en tabell vil kopieres til nyopprettede rader i tabellen. Angi preutfylling (TUL) Innebærer å angi hvilke felt som automatisk skal fylles ut av sluttbrukerløsningen før utfylling av skjema. Typiske valg kan være brukerens navn, adresse etc. Hvilke felter det gjelder vil angis i Tjenesteutviklingsløsningen. Angi oppslag i støtteregistre (InfoPath) Innebærer å ha muligheten til å angi oppslag fra støtteregistre. Angi sporvalg (TUL) Innbærer å angi valg som fører til at navigasjonen for sluttbrukeren endres. Et eksempel kan være et valg på side 1 hvor hva sluttbruker velger definerer som han/hun skal kunne navigere til side 2 (svaravhengige spørsmål). Dette defineres i Tjenesteutviklingsløsningen, enten basert på feltene i meldingsspesifikasjonen eller på egne felt. Angi betalingsinfo (TUL) Gir muligheten til å angi felter som vise betalingsinformasjon i en skjema-/presentasjonsside. Dette defineres i Tjenesteutviklingsløsningen. Angi kodelistekobling (InfoPath) Innebærer å koble en kodeliste til en nedtrekksliste i tjenesten. Se use case AP221 Use Case - TUL Vedlikehold kodeliste for forklaring på hvordan man oppretter og vedlikeholder kodelister. Det vil også være mulig å hente data inn i nedtrekkslister fra andre kilder enn via kodeliste i TUL. Dette kan være en ekstern webservice, et xml-dokument, en database eller en generell Sharepoint liste. Det anbefales dog å bruke kodeliste fra TUL grunnet fleksibilitet og vedlikehold. Tilpass til Elmer 2: Spesifisering av Utvikle Layout fra hoved-use 7

8 case. Her vil brukergrensesnittet tilpasses Elmer 2-standard. Dersom Elmer 2 velges bort må navigering legges inn manuelt/spesifikt i InfoPath. Bortvelging av Elmer 2 gjøres i definering av tjenesten (se use case Definer Tjeneste ) Alternativ utføring Feilhåndtering Forretningsregler Referanse til eksterne Use Case(s) Flere av operasjonene kan feile. En fornuftig feilmelding vil da vises. Tjenesteutvikler skal kunne utvikle og endre alle relevante aspekter ved brukergrensesnittet til tjenesten (skjema) Utviklingen trenger ikke gjøres ferdig i én omgang, men tjenesteutvikler skal kunne gå til andre deler av tjenesteutviklingen og returnere til utviklingen på et hvilket som helst tidspunkt. Vedlikehold kodeliste o AP221 Use Case - TUL Vedlikehold kodeliste.doc Opprettet tjeneste og tjenesteutgave o AP221 Use Case - TUL Opprett tjeneste og tjenesteutgave.doc Logge inn o AP221 Use Case - TUL Logg inn.doc Finn tjeneste o AP221 Use Case - TUL Finn tjeneste.doc Definer tjeneste o AP221 Use Case - TUL Definer tjeneste.doc Spesifiser skjemasett o AP221 Use Case - TUL Definer tjeneste.doc Krav dekket i design Se Tabell 3 - Krav dekket i design 8

9 Tabell 2 Krav Referanse til krav Req. Id. Generelt TUL_ SBLE_ INT_ INT_ Innsendingstjeneste TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ Utvikle tjenesteinnhold Beskrivelse Det er mulig å gjenbruke direkte, ved for eksempel å klippe og lime, deler av en tjeneste (for eksempel felter, kalkyler, tekster og lenker) til en annen tjeneste. Det skal angis i Tjenesteutviklingsløsningen om et felt skal preutfylles ved instansiering eller ikke Tjenesteutviklingsløsningen kan hente inn ML Schema-meldingsspesifikasjoner fra ulike metadatakilder for bruk i utvikling av sluttbrukertjenester og som grunnlag for felles datamodell. Det er mulig å kalle egenutviklede komponenter på en tjenesteorientert måte fra både arbeidsflyt, skjema og regler. All registrering av tekst kan utføres av fagpersonell uten IKT-kompetanse. Registrering av tekst bør kunne utføres i en sentralisert del av tjenesteutviklingsløsningen. Tjenesteutviklingen kan i sin helhet gjøres av tjenesteeier selv. Leverandøren har utdypet hvilke deler av løsningen som krever at applikasjonsforvalter må involveres under tjenesteutviklingen. Tjenesteutviklingsmiljøene inneholder en oversikt over tjenestetypene som kan utvikles. Det er mulig å rulle tilbake utgaven til et tidligere versjonsnummer. Det er enkelt å endre/tilpasse blant annet tekster/layout underveis for en innsendingstjeneste uten at det får konsekvenser verken for sluttbrukersystemer eller systemer hos tjenesteeiere. Det er viktig at det som legges inn første gang man definerer en innsendingstjeneste enkelt kan endres i etterkant. I dette ligger det også at det er enkelt å produksjonssette endringer i definisjonen. Leverandøren har utdypet hvordan alle tre alternative prosessmodeller for utvikling av innsendingstjenester kan støttes. TUL_ TUL_ TUL_ Tjenesteutviklingsløsningen skal ha støtte for å kunne generere ut meldingsbeskrivelse basert på utviklede innsendingstjenester. Meldingsspesifikasjonen kan importeres inn i tjenesteutviklingsløsningen for den aktuelle utgaven av innsendingstjenesten. Leverandøren har overordnet beskrevet alle prosessstegene utvikler typisk må gjennom ved etablering/revidering av en skjematjeneste (innsendingstjeneste). Der det finnes knytninger eller avhengigheter mellom prosess-stegene (for eksempel dersom behov for spesiell rekkefølge på steg) er dette spesielt beskrevet. Besvarelsen av dette kravet bør ta 9

10 Utvikle tjenesteinnhold utgangspunkt i notatet Visualisering av prosessforløpet ved tjenesteutvikling som ble gjennomgått i dialogfasen. TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ Tjenesteutviklingsløsningen skal ha støtte for å kunne generere ut meldingsbeskrivelse basert på utviklede innsendingstjenester. Dersom det oppstår en feilsituasjon ved import av en ML Schema meldingsspesifikasjon gir tjenesteutviklingsløsningen en informativ og teknisk utdypende tilbakemelding. Meldingsspesifikasjonen kan importeres inn i tjenesteutviklingsløsningen for den aktuelle utgaven av innsendingstjenesten. Tjenesteutviklingsløsningen håndterer alle mulige endringer i ML Schema meldings-spesifikasjonen, og tjenesten blir automatisk oppdatert som en følge av importert spesifikasjon. Det er mulig å rulle tilbake en import av en ML Schema meldingsspesifikasjon. Eventuelle forutsetninger og begrensninger i en foreslått løsning må utdypes. Import av ML Schema meldingsspesifikasjon fra OR fører til automatisk generering av innhold som støtter opp om de påfølgende prosesstegene for utvikling. Noen tjenesteeiere har behov for å kunne definere layout og utvikling av kalkyler, kontroller, navigasjon og sporvalg før import av ML Schema meldingsspesifikasjon fra OR. Leverandøren må beskrive hvordan dette kan støttes. For innsendingstjenester som har sekvensiell navigering mellom sidene kan tjenesteutvikler angi rekkefølgen for sideutsnittene. Det er mulig å angi logikken som styrer om de aktuelle feltene skal være tilgjengelige eller utilgjengelige. Sporvalg skal kunne benytte web-services oppslag for å styre sluttbrukerens navigering gjennom innsendingstjenester. Tjenesteutvikler kan definere kalkyler i et utviklingsverktøy eller velge å importere kalkyler. Løsningen er slik utformet at en person uten IKTkompetanse kan skrive enkle kalkyler og at kobling mot de aktuelle feltene kan gjøres ved å peke og klikke på felter i stedet for å skrive kode i et programmeringsspråk. Leverandøren har utdypet hvordan skriving av kalkyler kan støttes og presisere eventuelle forutsetninger og begrensinger knyttet til en slik støtte. Det er mulig å angi hvilke kalkyler som er begrenset til enkeltsider. Disse kan man så generere ut som klientsidescript, som utføres ved bestemte hendelser som kan oppstå under utfylling. 10

11 Utvikle tjenesteinnhold TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ Meldingstjeneste Det er mulig å validere alle typer felter, dvs. beløpsfelter, tekstfelter, radioknapper, nedtrekklister, avkrysningsbokser. Det er mulig å knytte én eller flere utslagstekster til en kontroll. For skjemasett som beskrives i kapittel er det særdeles viktig å ha tilgang til alle felt i innsendingstjenesten, både for kalkuleringer, kontroller og presentasjon av verdier og utregninger på tvers av skjemasettet. Leverandøren må utdype hvordan dette kan håndteres. Alle kalkyler og kontroller følger med i nyopprettede rader dersom det legges slike egenskaper på felter i en tabell i et skjema. Valideringer og kontroller vedlikeholdes/utvikles i samme verktøy uavhengig om valideringen skal kjøres på klient eller på server Leverandøren har utdypet om det er noen operasjoner som må gjøres for at tjenesteutvikler skal kunne enhetsteste tjenesten. Leverandøren har utdypet i hvilken grad eksport støttes, eventuelt hvilke formater som støttes, samt hvilke muligheter som generelt finnes for å konfigurere resultatet som genereres. Det understrekes at de aktuelle feltene både kan komme både fra ML Schema meldingsspesifikasjonen fra OR, SERES eller annen metadatakilde, og være egendefinerte hjelpefelter. Tjenesteutviklingsløsningen kan tilby kodelister fra et bibliotek for kodelister som brukes av flere forskjellige innsendingstjenester. Tjenesteutvikler kan enkelt konfigurere hvilke felter som er avhengige av kodelistene. Det finnes ingen krav som spesifikt gjelder utvikling av meldingstjeneste. 11

12 Tabell 3 - Krav dekket i design Krav dekket i design Req Id. TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ Utvikle tjenesteinnhold Krav dekket i design For all registrering av tekst og informasjon er det foruten bokmål og nynorsk mulig å registrere minimum alle samiske, nordiske og europeiske språk. Det er mulig å registrere tekst på andre internasjonale språk, såfremt teksten skrives normalt fra venstre mot høyre Det finnes støtte for registrering av tekst basert på Unicodetegnsett. Det er hjelpemiddel for å finne riktig Unicode-tegn på de angitte språkene. ML Schema meldingsspesifikasjoner fra både OR, SERES og andre kilder støttes. Der det i kravene i resten av dokumentet nevnes meldingsspesifikasjon fra OR eller SERES, gjelder også kravet meldingsspesifikasjoner fra andre kilder. En innsendingstjeneste kan ha flere utgaver produksjonssatt i parallell og for hver utgave kan det eksistere en tilhørende utgave i OR og i tjenesteutviklingsløsningen, slik at de forskjellige utgavene kan vedlikeholdes i parallell. Tjenesteutviklingsløsningen har for hver innsendingstjeneste to sett identifikatorer. En identifikator må være spesifikk for Altinn slik at en innsendingstjeneste kan opprettes og skilles fra andre innsendingstjenester uavhengig om det er knyttet en ML Schema meldingsspesifikasjon til den, mens det i tillegg må kunne knyttes til et sett med identifikatorer som er identiske med de OR bruker. Ved import av meldingsspesifikasjonen fra OR genereres det automatisk nødvendige og standard kontroller for hvert felt basert på formatspesifikasjonen. Tjenesteutviklingsløsningen må støtte at én ML Schema meldingsspesifikasjon kan dekke flere resulterende Altinn innsendingstjenester. Når rekkefølgen skal prioriteres ved flere kilder, må også preutfylling på meldingsnivå kunne inkluderes i prioritetslisten. Tjenesteutviklingsløsningen støtter en rekke ulike typer kalkyler. Leverandøren må beskrive hvilke typer kalkyler som støttes. Leverandøren må utdype. Det er ikke nødvendig å overføre en verdi fra en variabel på en side i en innsendingstjeneste til en duplikatvariabel på en annen for å få tilgang til den. Alle variabler som er definert for en innsendingstjeneste kan være tilgjengelige for kalkuleringer og kontroller fra en hvilken som helst presentasjonsside i tjenesten. Det er mulig å angi hvilke felter som skal inngå i kontrollen i tjenesteutviklingsløsningen. Formatspesifikasjoner som følger med en ML Schema meldingsspesifikasjon fra OR, SERES eller annen metadatakilde håndheves automatisk som kontroller for feltene det gjelder. Tjenesteutvikler må ikke behøve å gjøre noe for å aktivere dette. Kontrollene som skal beskrives kan alltid ha tilgang til alle felt i innsendingstjenesten. Dette gjelder både de felt som følger av meldingsbeskrivelsen og de hjelpefelt som er opprettet for visning i sluttbrukerløsningen. Kalkyler og valideringer skal implementeres kun én gang, men 12

13 Utvikle tjenesteinnhold Krav dekket i design skal kunne kjøres både i web-skjema i portalen og på data innsendt fra sluttbrukersystem. Leverandøren må utdype eventuelle avvik fra dette prinsippet. TUL_ Som ett minimum kan kontrollene og kalkylene eksporteres på et format som kan leses og forståes av mennesker. TUL_ Tjenesteutviklingsløsningen støtter alle de beskrevne formene for sideutsnitt. TUL_ Tjenesteutvikler kan angi rekkefølge og gruppering av sideutsnittene. TUL_ Defineringen av layout i de ulike sideutsnittene kan utføres av personer uten IKT-kompetanse. TUL_ Den layout tjenesteutvikler ser i tjenesteutviklingsløsningen er tilnærmet lik det bruker blir presentert for i portalen. TUL_ Det er mulig å angi felter fra OR sin ML Schema meldingsspesifikasjon og i tillegg opprette egendefinerte hjelpefelter på et sideutsnitt. TUL_ Alle slags type felter kan legges til - eksempelvis beløp, tekst, nedtrekkslister, radioknapper og avkrysningsbokser. Alle disse feltene kan være i en tabell. TUL_ Det er mulig å angi samme felt fra meldingsspesifikasjonen på ulike sider i skjema i portalen. TUL_ Om et felt tilhører en tabell eller ikke utledes direkte av ML Schema meldingsspesifikasjonen fra OR. Alle felter i en tabell i et sideutsnitt kommer fra samme klasse i meldingsspesifikasjonen fra OR. I tillegg kan man føye til egendefinert hjelpefelter, inkl. egendefinerte tabeller. TUL_ I portalen er tabeller dynamiske. Det er ikke nødvendig for tjenesteutvikler å foreta seg noe for at nye rader i tabeller skal fremkomme i sluttbrukerløsningen. TUL_ En rad i en tabell i enkelte innsendingstjenester kan utgjøre en hel side i portalen der feltene er presentert som et vanlig sideutsnitt i stedet for en rad i vanlig forstand. Leverandøren må beskrive hvordan slike repeterende felter, både i form av tabeller og repeterbare sideutsnitt, skal presenteres og oppføre seg i portalen. TUL_ Alle felt i en innsendingstjeneste kan ha ledetekster, fremskutte ledetekster og hjelpetekster på nivå 1 og 2. TUL_ Tekstene kan legges inn for alle typer felt, uavhengig av om det er definert i OR eller i tjenesteutviklingsløsningen, og de kan legges inn på alle språk som løsningen støtter. TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ TUL_ Løsningen må også ha tegnsett støtte for UNICODE. Ord eller setninger i hjelpetekst på nivå 1 kan kobles til hjelpetekster på nivå 2 eller eksterne URLer (websider, PDFer, osv). Hjelpetekstene på nivå 2 kan kobles til eksterne URLer (websider, PDFer, osv). Ut over de faste tekstelementene som er knyttet til hvert enkelt felt kan det legges til ekstra tekstelementer. Det er også mulig å bruke eksisterende tekst som grunnlag og så gjøre egne endringer og tilpasninger. Den endrede teksten legges da til som ett nytt alternativ for senere bruk. Til alle felter som benyttes i et sideutsnitt (fra OR eller egendefinerte hjelpefelt) kan det settes ulike egenskaper knyttet til presentasjon. Feltegenskapene kan lagres i kontekst av visning i sideutsnittet. Det betyr at man kan legge ulike egenskaper på samme felt i ulike sideutsnitt, eller ulike egenskaper på samme felt innenfor samme sideutsnitt. 13

14 Utvikle tjenesteinnhold Krav dekket i design TUL_ Det er et krav til tjenesteutviklingsløsningen at man kan definere sideutsnitt, lage tabeller, registrere egenskaper til felter pr side, definere sporvalg og legge til kalkyler/kontroller før layout for innsendingstjenesten defineres. TUL_ Det gjøres oppmerksom på at kalkyler/kontroller ikke skal ha noen avhengigheter til utformingen av webskjema. Det vil si at man skal ikke implementere kalkyler og kontroller i selve presentasjonslaget. TUL_ I tjenesteutviklingsløsningen er det mulig å angi en samling med felter som skal brukes til presentasjon av instanser for en innsendingstjeneste på hovedsiden i sluttbrukerløsningen. TUL_ Det er mulig å angi at en gruppe felter skal trekkes ut og vises som sammendragsside(r). TUL_ Gruppen felter kan velges fritt fra meldingsbeskrivelsen og de hjelpefelter som er opprettet. Feltene som benyttes i sammendragssiden kan være andre enn de som benyttes i presentasjonen av skjema i sluttbrukerløsningen under utfylling av skjema. TUL_ Tjenesteutviklingsløsningen for innsendingstjenester er fleksibel nok til at man kan realisere skjemaordninger som går ut over ELMER 2. TUL_ Presentasjonsmodeller som er benyttet i forbindelse med innsending av selvangivelse støttes. TUL_ Det er mulig å definere egen layout for utskrift av utfylte data. TUL_ Layout på utskrift kan være svært ulik layout i webskjema. Layout på utskrift kan i mange tilfeller være svært likt layout på papirskjema. TUL_ Løsningen for utskrift layout støtter utskrift av dynamiske tabeller. TUL_ Det er mulig å tilpasse kvitteringssiden for en innsendingstjeneste etter innsendingstjenestens behov. TUL_ Standard tekst som benyttes kan byttes ut, og et sammendrag av innrapporterte data kan presenteres i kvitteringen. Dette kan styres av tjenesteutvikler fra tjenesteutviklingsløsningen. TUL_ Tjenesteutvikler kan definere innholdet på signeringssider, herunder prosess og signeringstekster, hva som skal listes for signering og om det er mulig å angi delvis signering. TUL_ Det er mulig å gjenbruke direkte, ved for eksempel å klippe og lime, deler av en tjeneste (for eksempel felter, kalkyler, tekster og lenker) til en annen tjeneste. TUL_ Endringer som gjøres på en utgave av en tjeneste kan aldri påvirke andre utgaver av tjenesten eller andre tjenester, unntatt i de tilfeller der tjenesteeier av en annen tjeneste aktivt gjør inngrep for å gjenbruke fra andre tjenester. TUL_ Endringer som gjøres på en utgave av en tjeneste kan aldri påvirke andre utgaver av tjenesten eller andre tjenester, unntatt i de tilfeller der tjenesteeier av en annen tjeneste aktivt gjør inngrep for å gjenbruke fra andre tjenester. TUL_ Tjenesteutvikler kan utvikle transformasjon av ML-dataene og layout for presentasjonen i form av ()HTML. TUL_ Det er mulig å angi at betalingsinformasjon/prislister skal hentes gjennom en web-service mot tjenesteeier i sanntid dersom betalingsinformasjonen ikke er tilgjengelig i Altinn; for eksempel størrelse på priset tjeneste, en beregnet avgift m.m. SBL_ Både ledetekster og svarfelter for svaravhengige spørsmål skal være utgrået på sidene og åpnes bare for utfylling hvis det framgår av forutgående svar at de er aktuelle. (2.1.3) SBLE_ Presentasjonsfelter benyttes i forbindelse med en 14

15 Utvikle tjenesteinnhold Krav dekket i design innsendingstjeneste og vises som en del av tjenesteinstansnavnet i lister for å kunne skille ulike instanser av samme tjeneste. Presentasjonsfelter skal kunne benyttes for alle tjenester som har instansdata presentasjonsfeltene kan populeres fra. Med instansdata menes data som er dynamiske, eksempelvis skjemainnhold fra bruker og data fra innsynstjeneste. For statiske tjenester, eksempelvis meldinger, defineres titler o.a. i de statiske dataene, og presentasjonsfelter benyttes derfor ikke for disse. SBLE_ I ny løsning skal presentasjonsfelter kunne benyttes for alle tjenester INT_ Det er mulig å kalle regler fra et skjema for å få utført kontroller og kalkyler. INT_ Det er mulig å kalle eksterne tjenester/komponenter fra både arbeidsflyt, skjema og regler. Relatert dokumentasjon Dokument Type Kommentar AP353 Component Definition - TUL - Service Development Komponentdesign Beskriver hvordan alle komponentene i TUL henger sammen og beskriver kort de forskjellige komponentene AP347 Page Specification High Level - TUL - Prefill Sidedesign Beskriver siden der man registrerer prefill i TUL AP347 Page Specification High Level - TUL - Formtracks Sidedesign Beskriver siden der man registrerer sporvalg i TUL AP347 Page Specification High Level - TUL - Payment Info Sidedesign Beskriver siden der man registrerer betalingsinfo i TUL AP347 Page Specification High Level - TUL - Sidedesign Beskriver siden der man registrerer og Codelist AP311 Service Definition High Level - TUL - Form AP311 Service Definition - High Level - TUL - Service AP311 Service Definition - High Level - TUL - Service Edition AP311 Service Definition High Level - TUL - Code List Service-design Service-design Service-design Service-design vedlikeholder kodelister i TUL Beskriver den servicen som håndtere all logikk knyttet til håndtering av SNfilene Beskriver den servicen som håndterer tjenester Beskriver den servicen som håndterer utgaver av tjenester Beskriver den servicen som håndterer kodelister 15