TR435 Brukerveiledning for TUL

Transkript

1 Altinn TR435 Brukerveiledning for TUL Document template ID TR435 Document Type Opplæringsmateriale Activity Utvikling Application in Altinn TUL Document Version 1.3

2 Informasjon om dokumentet Dette dokumentet er en brukerveiledning for de som ønsker å utvikle tjenester i Altinns Tjenesteutviklingsløsning (TUL). Målgruppen for dokumentet er fagpersoner, kommunikasjonsmedarbeidere og IKT-medarbeidere hos tjenesteeier som benytter TULs verktøy i tjenesteutviklingsprosessen. Brukerveiledningen dekker også løsningsadministrators arbeidsoppgaver knyttet til å tildele/kontrollere brukertilgang i TUL på vegne av tjenesteeier. Følgende tjenestetyper er beskrevet i brukerveiledningen; innsendingstjeneste og meldingstjeneste. Dette dokumentet sammen med veilednings-komponenten i TUL SharePoint har som målsetning å gi tilstrekkelig beskrivelse av alle arbeidsoppgaver knyttet til tjenesteutvikling i Altinn. Viktige forkortelser: TUL Tjenesteutviklingsløsningen SBL Sluttbrukerløsningen SBS Sluttbrukersystem XSN Filtypen til InfoPath skjema Utover disse finnes flere ord som er verdt å merke seg i begrepslisten i kapittel 16. 2

3 Innholdsfortegnelse 1 Innledning Bestanddeler Forutsetninger Oversikt og struktur Struktur Aktører Prosess Forutsetninger og konfigurasjon Kom i gang med TUL Citrix arbeidsflate zip filemanger Command prompt Excel viewer Internet Explorer Microsoft Office InfoPath Utforsker delt område Utforsker lokal PC Word viewer Sentral funksjonalitet i TUL Statuser Veiledningskomponent Inn- og utsjekking Sortering og filtrering Påkrevde felter og røde stjerner Felles kodebibliotek Startsiden i TUL Tjenesteeiers arbeidsflate Lage tjeneste og utgave Lage tjeneste Lage utgave Design Design i InfoPath Definèr tjeneste og utgave Definèr tjeneste Definèr utgave Utgaveparametere Prosessflyt Skjemasett Utvikling av tjenesteinnhold Innholdsspesifikasjon Skjema Sjekke ut, editere og sjekke inn InfoPath-skjema Sideegenskaper Sporvalg Presentasjonsfelt Preutfylling Betalingsinformasjon Hjelpetekster Meldingstjeneste

4 9.1 Definere meldingstjeneste Meldingsinnhold InfoPath-skjema som meldingsinnhold Enhetstest Migrering til portalmiljø Start migrering Migreringsstatus Direktelenke Migreringsstatus på utgaven arbeidsflate Kjente feilmeldinger Rulle tilbake Oversetting Slette tjeneste og utgave Slette tjeneste Hvordan slette utgave Gjenopprette slettede tjenester og utgaver Kodelister Administrere kodelister Ny kodeliste Vedlikeholde kodelister Migrere kodeliste Slette kodeliste Sortering av kodeliste Kodeliste inn i InfoPath Administrators oppgaver Prosessflytmaler XML seksjon - Malinformasjon XML seksjon Steg XML seksjon Egenskaper Tjenesteeiers maler Administrasjon av brukere, grupper og rettigheter Lage ny tjenesteeier Forberedelser Active directory Tjenesteeierverktøy Begrepsliste Referanser Vedlegg Vedlegg A: Veiledning i skjemautvikling i InfoPath Før oppstart av InfoPath Altinn-definerte inputfelt Oppstart av InfoPath, Import av XSD-fil og generell oppsett av skjema og layout Definisjon av sider i InfoPath skjema (Views) Innlegging av felt fra Datakilde (fra XSD) Kalkyler, eksempel på repeterende gruppe og radioknapper Valideringer Dynamikk Hjelpefelter, verdioverføringer Web-, print- og kvitteringssider Hjelpetekster (knapper) Sporvalg Innlegging av kode i et skjema Forhåndsvisning og enhetstest i InfoPath

5 Fargekoder Altinn (foreløpig utgave pr ) Vedlegg B: Veiledning i utforming av brukergrensesnitt for skjema Sidestørrelse Scrolling Sideoverskrift (skjemanavn) Etatslogo Grupper Popup vinduer/dialogbokser Knapper Tabeller Tekstfelter, ledetekster og grafikk Plassering av overskrifter, ledetekster og rammer Plassering av felt Plassering av hjelpe-ikon Radioknapper (radio buttons) Listebokser (List box) Ferdig utfylte felt Dynamiske felt Fremskutt hjelpetekst Avsender, regnskapsfører og ev. revisor samles på første side Gruppe: skattemessig verdi på kundefordringer Tab mellom felt Innledende dialog (sporvalg) Vedlegg C: Veiledning i utforming av brukervennlige tjenester Retningslinjer for utforming av innsendingstjenester Vedlegg D: Veiledning i brukeradministrasjon Hvordan administrere brukere Tildele rettigheter i SharePoint Vedlegg E: InfoPath kodestandard Vedlegg F: InfoPath navnestandard Vedlegg G: Web Service oppslag fra InfoPath skjema Hvordan kalle en WebService fra et InfoPath skjema C# kode for registeroppslag Tilgjengelige webtjenester og oppslag

6 1 Innledning Dette dokumentet tar for seg den delen av tjenesteutviklingsprosessen som foregår i Tjenesteutviklingsløsningen, heretter kalt TUL. I forkant av dette må tjenesteutvikler gjennomføre en jobb knyttet til spesifisering av krav og design for tjenesten. Dette bør resultere i en skisse som beskriver hvordan tjenesten skal se ut i Altinn og sjekkliste for ønskede egenskaper som tjenesten skal ha. Likedan så finnes rutiner for varsling og bestillinger knyttet til testing og produksjonssetting som tjenesteutvikler må forholde seg til. Produktet av TUL kan sies å være en utgave som migreres til Sluttbrukerløsningen, heretter kalt SBL. 1.1 Bestanddeler TUL består av en samling flere utviklingsverktøy hvor ulike deler benyttes til å utvikle ulik funksjonalitet i tjenesten i Altinn. Av disse så er følgende relevant for tjenesteutvikler i TUL; 1. SharePoint 2. InfoPath (utvikling av skjema) 3. Microsoft Visual Studio Tools for Applications (utvikling av avanserte kontroller og kalkyler) 4. Active Directory Users and Computers 5. Andre hjelpeverktøy som Windows utforsker og andre standardprodukter 1.2 Forutsetninger Denne brukerveiledningen forutsetter grunnleggende kunnskap om standardproduktene SharePoint og InfoPath, og er ikke en komplett brukermanual for disse verktøyene. Det forutsettes også at tjenesteutvikler i TUL har gjennomført tilstrekkelig opplæring/kursing i regi av Altinn Sentralforvaltning før tilgang til TUL gis. For nærmere informasjon om kurs som tilbys i TUL, send forespørsel til tjenesteeier@altinn.no. 6

7 2 Oversikt og struktur TUL er som nevnt en helhetlig løsning for utvikling av tjenester i Altinn. Dette kapittelet gir en enkel oversikt over struktur og prinsipper. 2.1 Struktur TUL er designet slik at man har et hierarki mellom tjenesteeier, tjeneste og utgave, som vist i Figur 1 - Struktur i TUL. TUL kan brukes av et udefinert antall tjenesteeiere som hver har sin arbeidsflate i TUL SharePoint. En arbeidsflate er en side som viser og gir tilgang til all relevant informasjon for gitt nivå. Hver tjenesteeier kan ha en eller flere tjenester. Hver tjeneste er representert ved sin egen arbeidsflate. En tjeneste kan igjen har en eller flere utgaver. Figur 1 - Struktur i TUL SharePoint I figuren over representerer hver boks en arbeidsflate. Det er verdt å merke seg at en tjenesteutgave kan kun tilhøre en tjeneste, og en tjeneste kan kun tilhøre en tjenesteeier. Eksempel på tjenesteeier: Skatteetaten / SKD Eksempel på tjeneste: Alminnelig omsetningsoppgave Eksempel på utgave: 2009 I eksempelet over vil man i år 2010 kun opprette en ny utgave under eksisterende tjeneste. På denne måten får man granulariteten man ønsker. 2.2 Aktører Det er ønskelig at man innenfor den enkelte tjenesteeier skal kunne utføre betydelige deler av arbeidet knyttet til å etablere og vedlikeholde tjenester i Altinn. Dog er det samtidig enkelte kompliserte oppgaver som krever til dels dyp teknisk kompetanse. De involverte brukerne kan derfor grupperes basert på kompetanse og arbeidsfordeling i tjenesteutviklingen. Dette er ikke en kategorisering uten nyanser, da en og samme person vil kunne falle inn i flere grupper. Tabellen under viser de ulike brukerene og deres typiske oppgaver. 7

8 Bruker og egenskaper Fagperson som forstår kommunikasjonsbehov knyttet til aktuelle offentlig tjenester basert på faglig kompetanse. Er opptatt av at tjenester skal være effektive, feilfrie og av høy brukskvalitet; er nøyaktig og ønsker å levere god kvalitet. Har et fagområde utenom IKT; bruker IKTverktøy, men er ingen systemutvikler. Har fått grunnopplæring i TUL og evt. InfoPath. Arbeider med tjenestedefinisjon og -vedlikehold generelt, eller er spesialisert inn mot bestemte oppgaver. Oversetter som har kompetanse på de aktuelle språkene. Typiske oppgaver - Opprette tjeneste/tjenesteutgave - Utarbeide design - Definere tjeneste inkludert evt. prosessflyt og skjemasett - Utvikle tjenesteinnhold inkludert layout, tekster, kalkyler og regler - Enhetsteste tjeneste - Migrere til portalmiljø - Systemteste/akseptanseteste tjeneste - Publisere informasjon om tjeneste - Vedlikeholde og migrere kodeliste - Oversette tjeneste Er grundig og ønsker å bidra til enkel og forståelig kommunikasjon. Løsningsadmin Har fått grunnopplæring i TUL vinklet mot språkmodulen. IKT-person som har erfaring med systemutvikling. Behersker InfoPath (inkludert Xpath og C# i Microsoft Visual Studio Tools for Application) og SharePoint. Har fått grunnopplæring i TUL. Teknisk utvikler med god forståelse av Altinn-løsningen. Har spesialisert kompetanse knyttet til verktøyene i Altinn, for eksempel Workflow Foundation eller BizTalk. Enkelte har tilgang til å iverksette endringer i produksjonsmiljøet. For øvrig som IKT. Løsningsadministrator med god forståelse av Altinn-løsningen, spesielt TUL. Gir støtte til tjenesteeiere i tjenesteutviklingsarbeidet. Kan være administrator på vegne av en enkelt tjenesteeier eller for hele løsningen. Bruker IKT-verktøy, men er ingen systemutvikler. Har fått opplæring i Active Directory og i SharePoint, vinklet mot brukeradministrasjon og/eller tilpasning av samhandlingsområder i SharePoint. - Utarbeide prosessflytmal - Utarbeide komplekse regler/kontroller - Utvikle ny kjøretidskomponent, for eksempel prosessflytkomponent - Produksjonssette mal - Produksjonssette tjeneste - Opprette arbeidsområde og database for etat/ny tjenesteeier - Opprette nytt integrasjonspunkt mot etat - Administrere roller og rettigheter - Laste opp nyttig og nødvendig informasjon for de som skal jobbe i TUL, for eksempel dokumentmaler, dokumenter og kunngjøringer 8

9 2.3 Prosess Prosessmodellen for TUL vises i Figur 2 og inneholder følgende steg: Opprette overordnet design for tjeneste: Kan gjøres i Tjenesteutviklingsløsningen, men også i egne dokument i forkant av opprettelse av tjeneste. Opprette detaljert design for tjeneste: Opprettelse av tjeneste. Man får da tilgang til arbeidsflaten, dokumentbibliotek, tjenestedefinering og tjenesteutvikling (skjemautvikling). Definer tjeneste: Konfigurering av tjeneste, ved parametersetting. Utvikle tjeneste: Utvikling av skjema, samt: o Utvikle språkutgave. o Oversette tjeneste. o Utvikle og migrere kodeliste. o Utvikle og migrere prosessflytmal og komponenter. Enhetstest tjeneste: Enhetstesting av skjema og kodegjennomgang. Utføres i forkant av systemtest, men kan også utføres iterativt i utviklingsprosessen. Systemtest tjeneste: Test av tjeneste i sluttbrukerløsningen og sluttbrukersystemer. Akseptansetest tjeneste: Test av tjeneste i sluttbrukerløsningen og Sluttbrukersystemer. Produksjonssett tjeneste: Migrering til sluttbrukerløsningen. 1 a. Opprette overordnet design for tjeneste 2. Definere tjeneste 1 b. Opprette detaljert design for tjeneste 3. Utvikle tjeneste 4. Enhetsteste tjeneste 5. Migrere tjeneste til portalmiljø 6. Systemteste tjeneste 7. Akseptanseteste tjeneste 8. Produksjonsette tjeneste Figur 2 - Prosess for tjenesteutvikling 9

10 3 Forutsetninger og konfigurasjon <Tekst fjernet> 10

11 4 Kom i gang med TUL Som nevnt i kapittel 2 og vist i Figur 1 - Struktur i TUL, er TUL SharePoint strukturert i flere nivåer. Når man åpner TUL SharePoint fra Citrix-arbeidsflaten havner man på startsiden. Dette er startpunktet fra hvor man når tjenesteeierarbeidsflaten, og videre tjenester og utgaver. Dette kapittelet vil kort beskrive startsiden og tjenesteeierarbeidsflaten og hvordan man kommer i gang med tjenesteutvikling, samt sentral funksjonalitet i TUL SharePoint. 4.1 Citrix arbeidsflate Etter innlogging i Citrix presenteres du med et antall ikoner. Antall tilgjengelige applikasjoner avhenger av hvilke rettigheter du har i TUL, samt hvilke oppgaver du er tiltenkt å utføre zip filemanger Dette er et alternativ til vanlig windows utforsker og vil gi den samme funksjonaliteten Command prompt Dette er kommandolinjeverktøy, som bl.a. kan brukes for å kjøre applikasjonen RequiredFields.exe Excel viewer Denne lar deg forhåndsvise Excel-filer i TUL, f.eks. migreringsrapporter etc Internet Explorer Dette er inngangsporten til TUL SharePoint og vil åpne en nettleser hvor TUL er satt som startside Microsoft Office InfoPath 2007 Dette er skjemaverktøyet i TUL og vil i dette dokumentet kun bli referert til som Infopath Utforsker delt område Dette er standard Windows utforsker som tar deg til det delte området, også referert til som TUL-Share. 11

12 4.1.7 Utforsker lokal PC Dette er standard Windows utforsker som tar deg til din lokale maskin. Det er her viktig at du gir applikasjonen tilgang i vinduet som kan dukke opp med advarsel om at noen prøver å få tilgang til dine lokale filer Word viewer Denne lar deg forhåndsvise Word-filer i TUL, feks. Designdokumenter, kokebøker etc. 4.2 Sentral funksjonalitet i TUL For å bruke TUL er det en fordel å kjenne til funksjonaliteten i SharePoint, da TUL SharePoint bruker lignede funksjonalitet på en del sentrale funksjoner. Disse gjengis i de følgende delkapitlene Statuser For alle metadataseksjoner på tjeneste- og utgavearbeidsflaten er det brukt symboler for å indikere status for seksjonen. Disse ikonene skal gi bruker et kjapt overblikk over hva som er uferdig, endret eller migrert, samt komplett. Ikoner og status er vist i tabell 1: Tabell 1 - Ikoner og status Ny, uendret Endret, ikke komplett Komplett Migrert, uendret etter migrering Veiledningskomponent Alle sider i TUL SharePoint (med få unntak) har veiledningskomponenten tilgjengelig på høyre side. Denne vil inneholde relevant informasjon om gitt side, samt vise en lenke til den komplette brukerveiledningen for TUL. Veiledningskomponenten er del opp i seksjoner med overskrifter. Den fungerer som et trekkspill, og hvis man klikker på overskriften til den gitte seksjonen, vil denne ekspandere eller trekke seg sammen Inn- og utsjekking Inn- og utsjekking brukes for å sikre at andre ikke kan gjøre endringer mens du jobber med en parameterseksjon eller et dokument. Mens parameterseksjonen er sjekket ut, kan du redigere den, lukke den, åpne den på nytt, uten at andre brukere kan gjøre endringer. Først når du velger å sjekke inn igjen vil andre kunne gå inn og gjøre endringer. Man vil også kun ha utsjekkingstilgang til sin egen tjenesteeier, tjenester og utgaver, selv om man har lesetilgang til alle tjenesteeiere, tjenester og utgaver. Inn og utsjekking av parameterseksjoner gjøres via knappene som finnes øverst og nederst på siden, som vist i Figur 3 - Sjekk ut/inn knapper, under. Ved innsjekk har man også mulighet for å angi en kommentar som blir lagret, og kan ved å benytte Vis versjonslogg kan man se historikk over ulike innsjekkinger og kommentarer. 12

13 Det er verdt å merke seg at hvis man har sjekket ut, og så trykker på avbryt, vil det være det samme som å angre utsjekking; endringer man har gjort blir ikke lagret og parameterseksjonen vil ikke lengre være utsjekket. Man returneres til arbeidsflaten Sortering og filtrering Figur 3 - Sjekk ut/inn knapper Som ellers i SharePoint, vil man også i TUL SharePoint ha filtrering og sortering på de viktige listene. Et utvalg av disse listene er: Liste over tjenesteeiere. Liste over tjenester. Liste over utgaver. Liste over kodelister. Det fungerer på den måten at man for hver kolonneoverskrift har en meny som vist i figur 4. Figur 4 - Sortering og filtering i lister Merk at ikke alle kolonner kan filtreres da disse kun kan inneholde unike verdier Påkrevde felter og røde stjerner For mange av metadatasidene i TUL, vil det være felter som må fylles ut før seksjonen kan lagres og sjekkes inn. Disse er markert med røde stjerner, som vist i figuren nedenfor. Figur 5 - Røde stjerner Det er viktig at det skilles på hva som er påkrevd for at utgaven skal migreres, og hva som er påkrevd for å sjekke inn/lagre. Røde stjerner angir kun sistnevnte Felles kodebibliotek I TUL vil man kunne oppleve at mange skjemaer krever mye av samme funksjonaliteten, som f.eks. å validere fødselsnummer, org.nr, epostadresser etc. Dette er tiltenkt å legges i et felles (C#) kodebibliotek i dokumentbiblioteket på forsiden. Dette er ment som et levende sett av funksjonalitet og vedlikehold av tjenesteutviklerne, og det vil opp til de å utvikle de gjenbrukbare valideringene/kodesnuttene. Dette kodebiblioteket vil være kildekode pluss et kompilert bibliotek som man kan i bruk i C# koden til ethvert skjema. 13

14 4.3 Startsiden i TUL Startsiden, som vist i figur 6, er det første skjermbildet du kommer til når du logger inn i TUL. Her kan du utføre følgende aktiviteter: Navigere til tjenesteeiernes arbeidsflater. Hvis tjenesteeieren du skal til ikke ligger i listen, må en administrator for din etat gi deg tilgang. Navigere til kodelistene som gjelder på tvers av alle tjenesteeiere. Lese meldinger som er rettet mot tjenesteutviklere i TUL. Navigere til aktuelle eksterne nettsider gjennom liste med lenker. I tillegg vil en administrator kunne utføre følgende aktiviteter: Hente frem og lagre prosessflytmaler som gjelder på tvers av alle tjenesteeierne. Disse ligger i et dokumentbibliotek kalt EmptyWorkflowTemplates. Figur 6 Startsiden På startsiden finnes også et felles dokumentbibliotek hvor det er opp til tjenesteeierene hva som skal ligge her, men et godt utganspunkt er felles kode, logoer etc. Det kan også en idè å lage en mappestruktur. 14

15 4.4 Tjenesteeiers arbeidsflate Når du har valgt en tjenesteeier på startsiden kommer du til tjenesteeierens arbeidsflate. Dette er en arbeidsflate som er spesifikk for den enkelte tjenesteeier, og kan av tjenesteeieradministrator tilpasses den enkelte tjenesteeiers behov. Her kan du: Navigere til eksisterende tjenester. Opprette ny tjeneste. Lese kunngjøringer som er rettet mot tjenesteeierens tjenesteutviklere i TUL. Finne kontaktinformasjon om deltakere i tjenesteutvikling fra tjenesteeierne dersom denne delen er lagt til arbeidsflaten for tjenesteeier. Administrator kan i tillegg: Hente frem og lagre prosessflytmaler for den enkelte tjenesteeier. Disse ligger i dokumentbiblioteket PreDefinedWorkflowTemplates. Du kan nå velge en eksisterende tjeneste eller opprette en ny. Figur 7 - Tjenesteeiers arbeidsflate 15

16 5 Lage tjeneste og utgave En tjeneste i TUL SharePoint fungerer som en beholder for utgavene. Med dette menes at man ikke migrerer selve tjenestene til SBL, men utgaver som tilhører tjenesten. Og hver gang den migreres med endret innhold, vil det opprettes en ny versjon av utgaven i SBL. En tjeneste kan ha en eller flere utgaver, for eksempel en utgave per år. I TUL finner du en arbeidsflate for tjeneste og en for utgave. For å identifisere en tjeneste og en utgave har TUL egne parametersider knyttet til tjenesten tjenesteparametre og til utgaven utgaveparametre. Tjenesteparametrene er felles for alle utgaver av tjenesten. 5.1 Lage tjeneste For å lage en ny tjeneste, klikk på Ny i menylinjen til listen over tjenester. Da kommer du først til parametersiden Tjenesteparametre, som vist i Figur 8 - Lage tjeneste. Som vist i figuren over kan man angi fem forskjellige parametere: Figur 8 - Lage tjeneste Tjenestenavn: Dette er tjenestens fulle navn og brukes i SBL for avansert søk. Kortnavn: Dette er tjenestens identifikator i TUL og brukes ikke i SBL. Kortnavnet vil kunne finnes igjen i tjenestens URL. Kortnavnet må også være unikt innad i en tjenesteeier. Ekstern tjenestekode: Identifiserer tjenesten i SBL og SBS. Må være unikt på tvers av alle tjenesteeiere i TUL. Maksimalt 7 bokstaver eller tall. Tjenestetype: Dette angir om alle utgavene som lages for denne tjenesten enten er en innsendingstjeneste eller meldingstjeneste 1. Merk at tjenestetype ikke må velges ved opprettelse av tjenesten, men velges før en utgave kan lages. Når du har skrevet inn og trykker OK, vil tjenesten opprettes. 1 Dette er de to tjenestetypene som er tilgjengelig i versjon 1 16

17 5.2 Lage utgave En utgave kan opprettes på to forskjellige måter; ny tom eller kopi basert på en eksisterende utgave. Begge måter vil resultere at en utgave blir opprettet under valgt tjeneste. Ny tom lages ved å klikke på Ny i menylinjen i tjenestelisten på arbeidsflaten for tjeneste. Se figuren nedenfor. Figur 9 - Ny utgave Vil man lage en ny utgave basert på en eksisterende velger man Ny kopi basert på denne i kontekstmenyen til utgaven man vil basere seg på. Se figuren nedenfor. Figur 10 - Ny utgave, kopi Begge valgene vil ta deg til samme siden, men det er noen forskjeller. Hvis du lager en ny fra scratch, vil alle felter være tilgjengelig for utfylling. Velger du derimot å lage utgaven som en kopi av en eksisterende, vil kun utgavenavn, kortnavn og tjenesteutgavekode være mulig å fylle ut. Resten må endres etterpå. Dette fordi det kun er disse verdiene som ville måtte være unike mellom utgavene. Disse parameterene er: Utgavenavn: Brukes som beskrivende navn i SBL Kortnavn: Brukes kun i TUL som sitenavn og i url Tjenesteutgavekode: brukes som unik identifikator i SBL og SBS. Denne behøver kun å være unik innenfor tjenesten. En god regel er å enten gi utgavene kodene 1, 2, 3 osv. 2007, 2008, 2009 osv. Det som er viktig er at på skjemasettsiden og for SBL vil utgaven med høyest kode ansees å være nyest. Hovedspråk angir hvilken som blir grunnspråket for utgaven Siden for utgaveparametere beskrives i kapittel

18 6 Design Design kan utføres i TUL, men også i egne dokument i forkant av at tjenesten opprettes. Fra tjenestens arbeidsflate i TUL kan du samle relevant bakgrunnsinformasjon og eksisterende designdokumenter knyttet til tjenesten, i et dokumentbibliotek. Dokumentbiblioteket har versjonskontroll, så du bør sjekke ut dokumentet for å hindre at andre gjør endringer samtidig. Designdokumentasjonen vil være felles for alle utgavene av tjenesten. Hvis det etter hvert utvikles mange versjoner, kan det være praktisk å lage en katalogstruktur i dokumentbiblioteket. Dette gjøres ved å navigere til selve dokumentbiblioteket ved å klikke på Designdokumenter. Det som skjer nå er at du ser selve dokumentbiblioteket i SharePoint kontekst/gui. Her ser du flere knapper som kan benyttes. Velg Ny og så Ny mappe, som vist i figuren nedenfor. Dette er standard og normal SharePoint-oppførsel, og vil være samme for andre dokumentbiblioteker. Figur 11 - Lage mappe På denne måten kan du lage en oversiktlig struktur. 6.1 Design i InfoPath Det vil også kunne lages design i InfoPath. Måten dette gjøres på er å lage skallet til skjemaet uten å basere dette på en datakilde (XSD). Det man gjør da er å lage en ny tom mal i InfoPath, som vist i figuren under. Skjemaet får sin egen datakilde, noe vil endre i ettertid. Figur 12 - Ny, tom mal i InfoPath Deretter er det bare å lage utkastet til hvordan skjemaet skal se ut. Dette gjøres ved å dra inn felter og grupper på vanlig måte. 18

19 Det interessante skjer når man vil bruke designet til utvikle selve skjemaet. Det man må gjøre nå er å konvertere hoveddatakilden til å bruke en ferdig datakilde (XSD), f.eks. meldingsbeskrivelsen fra oppgaveregisteret. Dette gjøres ved å velge Verktøy fra InfoPath sin menylinje, deretter velge Konverter hoveddatakilde..., som vist i figuren under. Figur 13 - Konverter hovedddatakilde Man velger så den hoveddatakilden man vil at skjemaet skal bruke, samt at man ikke vil bruke flere datakilder. Nå har skjemaet den datakilden det skal ha, og designet har blitt tatt i bruk. Det siste som må gjøres er å endre binding på de brukergrensesnittelementene som allerede er skjemaet. Dette gjøres ved å høyreklikke på valgt element og velge Endre binding.... Design utarbeidet i andre applikasjoner en InfoPath vil ikke kunne tas i bruk direkte som skjema eller en del av skjema. 19

20 7 Definèr tjeneste og utgave Tjenestedefinering utføres fra tjenestens arbeidsflate, mens definering av utgave fra utgavens arbeidsflate. Å definere tjenesten omfatter kun tjenesteparametere, mens for utgave innebærer det alle deler som ikke er knyttet til eventuelt tjenesteinnhold. Eksempel på innhold er skjema som utvikles i InfoPath. Tjenestedefinisjonen vil være den samme for alle utgaver i gitt tjeneste, mens hver enkelt utgave kan ha forskjellige definisjoner og egenskper. 7.1 Definèr tjeneste Tjenestespesifikasjonen initieres allerede idet du velger å opprette en ny tjeneste ved at du blir navigert til tjenesteparametersiden. Samme side vil du også komme til ved å klikke på Tjenesteparametere på arbeidsflate for tjeneste. Skjermbilde av siden vises under. Figur 14 Tjenesteparametere Det som er verdt å merke seg, er at ekstern tjenestekode og tjenestetype ikke kan endres etter at det er valgt og lagret. Følgende parametre kan defineres på tjenesteparametersiden: Parameter Beskrivelse Obligatorisk Type Språkstøtte Tjenestenavn Tjenestens navn er navnet tjenesten har på tvers Ja Tekst Ja av alle utgaver. Brukes blant annet til å gruppere utgaver i sluttbrukerløsningen mtp. avansert søk Kortnavn Tjenestens kortnavn er navnet på tjenestens Ja Tekst arbeidsflate i TUL, og brukes i URL Tjenestekode Tjenestekode brukes til å identifisere en tjeneste i Ja Tekst Altinn, for eksempel ved dyplenking. Denne genereres automatisk. Tjenestetype Tjenestetype brukes til å definere type tjeneste. Tjenestetype må settes før man kan opprette en utgave av tjenesten. Nei 2 Liste 2 Tjenestetype må velges før utgave opprettes 20

21 Referanse Referanse kan for eksempel brukes som referanse til papirutgaven av tjenesten eller skjemanavn. Maksimalt 10 tegn (bokstaver, siffer eller spesialtegn). Nei Tekst I versjon 1 kan kun Innsendingstjeneste og meldingstjeneste velges som tjenestetype. 7.2 Definèr utgave Fra tjenestens arbeidsflate kan du opprette en utgave under tjenesten som beskrevet i kapittel 5. Hvilke parametre som skal angis for en tjenesteutgave kommer an på hva slags tjenestetype som ble valgt for tjenesten. For å opprette en utgave av en innsendingstjeneste må parametrene Utgavenavn, Kortnavn, Tjenesteutgavekode, Hovedspråk og Spesifikasjonskilde angis. De andre parametrene kan defineres senere. På samme måte som for tjenesteparametrene kan du klikke OK for å lagre eller Avbryt for å avbryte og gå tilbake til tjenestens arbeidsflate. Velger du OK vil tjenesteutgaven opprettes og du kommer til en egen arbeidsflate for tjenesteutgaven. Her kan du gå tilbake til utgaveparametrene ved å klikke på Utgaveparametre under området for Utgavespesifikasjon. Hvis tjenesten er en innsendingstjeneste må du definere en prosessflyt, og kan definere et skjemasett for utgaven. For å definere dette må du velge henholdsvis Prosessflyt eller Skjemasett under området for Utgavespesifikasjon Utgaveparametere Utgaveparametrene brukes for å identifisere og konfigurere egenskaper ved utgaven. Parametrene er tilpasset den aktuelle tjenestetypen. Selve parametrene er listet midt på siden. Parametrene er gruppert etter type parameter og til venstre på siden fins en forklaring til parametrene. Figur 15 - Utgaveparametere 21

22 Følgende parametre kan definers på utgaveparametersiden: Parameter Beskrivelse Tjenestetype Obl. Type Språkstøtte Utgavenavn Utgavens navn vises på Alle Ja Tekst Ja utgavens arbeidsflate i TUL. Kortnavn Utgavens kortnavn er navnet Ja Tekst på utgavens arbeidsflate i TUL. Kan maksimalt inneholde 30 bokstaver eller siffer. Kan ikke inneholde spesialtegn, dog og _. Tjenesteutgave Tjenesteutgavekode brukes Alle Ja Tekst kode sammen med tjenestekode til å identifisere en utgave i Altinn, for eksempel ved dyplenking. Tjenesteutgavekoden må være unik innenfor en tjeneste. Maksimalt 6 siffer. Dette feltet kan ikke endres i etterkant og vil være read only etter at utgaven er lagret første gang. Hovedspråk Angir utgavens hovedspråk. Brukes som oversett-fra-språk ved oversetting. Alle Ja Liste Gyldig fra Gyldig til Kun underskjema Type melding Metode for oversending av tjenesteutgave Kontroller Innsendingstjeneste Spesifikasjonsnummer Angir når utgaven er tilgjengelig i SBL. Gjelder i utg.punkt produksjonsmiljø, men også testmiljø hvis Gyldig fra-dato overstyres ved migrering. Angir når utgaven ikke lengre er tilgjengelig i SBL. Gjelder i utg.punkt produksjonsmiljø, men også testmiljø hvis Gyldig fra-dato overstyres ved migrering. Angir at denne utgaven kun blir brukt som et underskjema. Prosessflyt og skjemasett, samt migrering blir utilgjengelig. Angir hva slags meldingstype denne utgaven er. Det kan velges mellom Binær (typisk PDF etc), HTML, Skatteoppgjør og Foreløpig skatteoppgjør. Angir hvordan data skal sendes fra Altinn til etat. Her kan det velges mellom de ulike grensesnittene som er gyldig for den gitte tjenesteeier Angir at det skal kjøres tilpasset funksjonalitet ved instansiering av utgaven. Her kan det velges mellom tilgjengelig funksjonalitet. Spesifikasjonsnummer brukes til å referere til riktig versjon av datakilde (XSD) fra angitt 22 Alle Dato + Tid Alle Dato + Tid Alle Sjekkboks Meldingstjeneste Ja Innsendingstjeneste Liste Liste Liste Alle Ja 4 Tekst

23 Versjon av dataform Vis ELMER Fri navigasjon Styrt navigasjon Tillat vedlegg Kryptér binære filer Lagre i arkiv Tillat instansiering fra arkiv Benytt sporing og logging Tillat innsending fra SBS spesifikasjonskilde. Angir kilden til dataene som skjemaet er basert på. Kan være Oppgaveregisteret, Seres eller Altinn. Angir versjonsnummer av spesifikasjonskilde Angir om skjema skal presenteres i sluttbrukerløsningen i henhold til ELMER-rettningslinjene. Vis ELMER er satt som default valg i TUL. Dette vil gi et navigasjonsområde til venstre og et område for selvvalgt tilleggsinformasjon til høyre. I tillegg vil det være en knapperad med navigasjonsknapper under skjemaet. Se Vedlegg C: Veiledning i utforming av brukervennlige tjenester for mer informasjon. Angir om navigasjonen skal være fri eller styrt. Bruk av ELMER med fri navigasjon er satt som default valg i TUL, og anbefales. Kun i spesielle tilfeller kan det være hensiktsmessig å velge styrt navigasjon, som for eksempel hvis det er nødvendig å lede sluttbrukeren gjennom et bestemt resonnement. Se Vedlegg C: Veiledning i utforming av brukervennlige tjenester for mer informasjon. Angir om sluttbruker kan laste opp egne filer som vedlegg til innsendingstjenesten. Satt som default valg i TUL. Angir om binære filvedlegg skal krypteres. Deaktiveres hvis Tillat vedlegg ikke er valgt. Angir om tjenesteutgaven skal lagres under Sendt og arkivert på Min Hovedside i SBL. Satt som default valg i TUL. Angir om om sluttbruker kan lage en ny kopi av arkivert tjeneste i SBL. Satt som default valg i TUL. Deaktiveres hvis Lagre i arkiv ikke er valgt. Angir om utvidet sporing og sporing skal benyttes for tjenesteutgaven i et sluttbrukermiljø. Angir om tjenesten kan sendes inn fra et eksternt sluttbrukersystem. Satt som default valg i TUL. 23 Alle Ja 4 Liste Alle Radio Tall Spesifikasjonskilde Innsendingstjeneste Sjekkboks Innsendingstjeneste Innsendingstjeneste Sjekkboks Innsendingstjeneste Sjekkboks Innsendingstjeneste Sjekkboks Innsendingstjeneste Sjekkboks Innsendingstjeneste Sjekkboks Innsendingstjeneste Sjekkboks

24 Tillat instansiering for sluttbrukere uten brukerprofil Kvitteringstekst Krav til avgivertype Sikkerhetsnivå Rettighetskrav for tjenesteutgave Avsender Bekreftelse for mottatt: Sluttbruker må bekrefte Bekreftelse for mottatt: Sluttbruker trenger ikke bekrefte Angir om en bruker åpne en gitt tjenesteutgave i SBL uten registrert brukerprofil Etter å ha fylt ut et skjema i SBL vil sluttbruker bli sendt til en egen kvitteringsside med kvitteringsteksten. Se Vedlegg C: Veiledning i utforming av brukervennlige tjenester for mer informasjon. Angir hvilke type brukere som kan stå som avsender av innsendings-tjenesten. Kan være privatperson, juridisk enhet, bedrift eller ingen avgivertype krav. Bedrift er enheter med type bedr. Hva som skal velges vil ofte være angitt i skjemadesignet. Angir krav til hvilken innloggingsmetode som minimum kreves for innsendingstjenesten. Kan være Kun passord, Engangskode, MinID eller Smartkort. Angir hvilke rettigheter som kreves for de ulike hendelsene i SBL. Se neste tabell. Angir hvem som står som avsender av meldingen i SBL. Angir hvorvidt meldingen må bekreftes lest av sluttbruker. Satt som default valg i TUL. Angir hvorvidt meldingen må bekreftes lest av sluttbruker. Sjekkboks Innsendingstjeneste Innsendingstjeneste Alle Alle Lenker til popupvindu for å velge rettigheter Tekst Meldingstjeneste Meldingstjeneste Meldingstjeneste Innsendingstjeneste Tekst Liste Liste Radio Radio Følgende rettighetskrav kan defineres for en utgave: Hendelse Beskrivelse Tjenestetype Angis hvor Les Angir rettighet som kreves for å lese instanser av Alle Utgaveparametere avgiverelement denne tjenesten i arbeidsdatabasen i SBL. Opprett Angir rettighet som kreves for å opprette en instans Innsendingstjeneste Utgaveparametere avgiverelement av denne utgaven i SBL. Slett arkiv 3 Angir rettighet som kreves for å slette en arkivert instans av denne tjenesten fra brukers arkiv i SBL. Merk: Tilhører instansen en organisasjon, kan den Alle Utgaveparametere 3 For meldingstjeneste: Denne hendelsen vil vises i TUL, men ikke være gjeldende før v2 24

25 Les arkiv 4 Les tjenesteeierarkiv Slett avgiverelement Bekreft melding Fyll ut avgiverelement Signèr avgiverelement Send tilbake ikke slettes fra arkiv. Angir rettighet som kreves for å åpne kvittering av denne tjenesten i arkivet i SBL. Angir rettighet som kreves av etatsbruker for å kunne åpne en arkivert instans av denne tjenesten i SBL. Angir rettighet som kreves for å slette en instans av denne tjenesten fra arbeidsdatabasen. NB! Hvis dette er en meldingstjeneste, og instansen tilhører en organisasjon, så kan ikke denne instansen slettes uansett rettighet. Angir rettighet som kreves for å bekrefte at en melding er mottatt. Angir rettighet for å kunne fylle ut Angir rettighet for å signere Angir rettighet som kreves for sende utfylt instans tilbake til forrige steg. Alle Alle Meldingstjeneste Meldingstjeneste Innsendingstjeneste Innsendingstjeneste Innsendingstjeneste Utgaveparametere Utgaveparametere Utgaveparametere for melding, prosessflyt for innsending Utgaveparametere Prosessflyt Prosessflyt Prosessflyt For alle rettigheterkrav kan det settes en eller flere rettigheter. Det er ikke hensiktsmessig å liste opp alle her, og ved å føre musepekeren over de enkelte rettighetene i rettighetspopup en i TUL vil det komme en beskrivelse(tooltip). For hver utgave må man også angi hvilket sikkerhetsnivå som kreves for å åpne tjenesteutgaven i SBL. Sikkerhetsnivåene er fra 1 til 4 og hvert nivå kan ha en eller flere innloggingsmetoder. Disse vises i tabellen under: Sikkerhetsnivå Innloggingsmetode 1 Kun passord 2 PIN-kode fra Altinn 2 PIN-kode fra selvangivelsen 2 PIN-kode fra SMS 3 PIN-kode fra MinID 4 Buypass 4 BankID 4 For meldingstjeneste: Denne hendelsen vil vises i TUL, men ikke være gjeldende før v2 25

26 7.2.2 Prosessflyt Prossessflyt kan defineres for en innsendningstjeneste og angir hvilken flyt tjenesten skal følge i SBL. Med dette menes at man velger hvilke steg tjenesteeier vil at utgaven skal igjennom hos utfyller. F.eks. vil en prosessflyt med signeringssteg tvinge utfyller til å måtte signere skjemaet før den kan sendes inn og arkiveres. På parametersiden Prosessflyt kan du definere en prosessflyt basert på en prosessflytmal. Det finnes to typer prosessflytmaler du kan velge mellom: Felles maler tilgjengeliggjør generelle maler som alle tjenesteeiere kan benytte i nedtrekkslisten. Disse er tomme. Tjenesteeiers maler - tilgjengeliggjør maler som allerede er tilpasset tjenesteeier i nedtrekkslisten. Disse kan være delvis eller ferdig utfylt. Dette velges ved hjelp av radioknappene på toppen. Valget vil påvirke hvilke maler som er tilgjengelig i nedtrekkslisten. For å benytte en gitt mal trykker man på knappen Bruk Mal Dette vises i figur 16. Vanlige steg i en prosessflyt er utfyllingssteg, signeringssteg og innsendingssteg. Du velger hvilke steg tjenesten skal inneholde ved å velge en mal som inneholder de rette stegene. Klikk på Bruk mal for å velge ønsket mal. For hvert steg i prosessflyten kan du sette rettighetskrav og andre parametre som bestemmer hvordan hvert enkelt steg i flyten skal gjennomføres i sluttbrukerløsningen. P.t. finnes det fem felles prosessflytmaler tilgjengelig i TUL: Utfylling og innsending Utfylling og signering Utfylling og betinget Utfylling og dobbel signering Utfylling og betinget dobbel signering For alle maler med signeringssteg vil det også være mulig å velge om sluttbruker må signere på skjema og alle vedlegg, eller om han/hun kan velge hva som det skal signeres på (felles signering). Det er også mulig å angi en signeringstekst. Både felles signering og singneringstekst er pr steg. Betinget signering betyr at man kan avgjøre under utfylling om bruker må signere på skjema eller ikke, ved å sjekke inntastet verdi i et felt mot en gitt grenseverdi. For prosessflytene som inneholder betinget signering, vil det på signeringssteget være noen ekstra parametere: Betinget felt: Her angis xpath til feltet som det skal sjekkes mot. Operator: Angir hvordan man skal sjekke grenseverdi mot felt. Grenseverdi: Angir hvilken verdi det betingete feltet skal matche iht operatoren. F.ek.s hvis man i et skjema vil at utfyller skal slippe å signere hvis han eller hun sender inn skjema for en bedrift som har under kr i omsetning kan verdiene være som følger: Betinget felt Operator Grenseverdi /skjema/grp_omsetning/aarligomsetning >

27 Figur 16 - Prosessflyt Prosessflytmalene i TUL SharePoint er basert på XML, og skal kunne vedlikeholdes av IKTpersoner. Hvordan dette gjøres vil beskrives i kapittel Skjemasett Et skjemasett er en hierarkisk samling av skjemaer som inngår i en innsendingstjeneste. Her bestemmer du hvilke underskjemaer som inngår i utgaven, hvor utgaven inneholder hoveskjemaet. Et skjemasett kan bygges basert på de skjemaene som tilhører gitt tjenesteeier. Det kan ikke velges underskjema fra samme tjeneste som utgaven du definerer tilhører. På parametersiden Skjemasett er alle tjenesteeiers skjema listet med tjenestens kortnavn, utgavens kortnavn, informasjon om hvorvidt skjemaet er definert som hovedskjema eller ikke, versjonsstatus og produksjonsstatus sammen med en lenke (Legg til) for å legge til skjemaet i skjemasettet. Det er viktig å merke seg at man kun velger å benytte skjemaet og skjemaets metadata, være seg preutfylling, sideegenskaper etc fra utgaven man velger i listen. Disse dataene vil inngå i hovedskjemaets utgave ved en migrering. I forhold til i SUM er det derfor ikke nødvendig å migrere underskjema før hovedskjema. Underskjema vedlikeholdes derfor i sin egen utgave. Når et skjema bir valgt legges det til en liste der tjenesteutvikler kan konfigurere egenskaper for valgte underskjema ved å sette følgende parametre: Parameteren Sluttbruker kan legge til manuelt vil gjøre det mulig for sluttbruker selv å legge dette skjema inn som underskjema. Satt som default valg i TUL. Parameteren Maks ett vil gjøre det umulig å legge til mer enn én forekomst av dette skjema for sluttbruker i SBL. Satt som default valg i TUL. Parameteren Inkluder i felles datakilde fører til at felter i underskjema blir tilgjengelig for hovedskjema. Satt som default valg i TUL. Parameteren Bruk felles datakilde betyr at underskjema vil få tilgang til felter fra andre utvalgte skjema i skjemasettet. Felles datakilde er en funksjon som tilgjengeliggjør ekstra datakilder i InfoPath skjemaet. Man kan dermed benytte strukturen fra andre skjema og få eksempelvis verdioverføringer innad i et skjemasett. 27

28 Det vil ikke være mulig å enhetsteste verdioverføringer.dvs, man kan ikke teste en verdioverføring fra et underskjema til hovedskjema i InfoPath preview-modus. Felles datakilde genereres ved hjelp av Generèr felles datakilde knappen. Det er verdt å merke seg at siden et underskjema kan være medlem av flere skjemasett, vil det kunne forekomme flere datakilder i skjemaet enn det som er nødvendig. Disse kan, hvis ønskelig, slettes ved å navigere til Datakilde i hjelpefanen i Infopath, deretter velge Behandle datatilkoblinger og deretter markere den man vi slette og velge Fjern. Felles datakilde vil da finnes i skjemaet som en sekundær datakilde. Dermed kan man velge å benytte felter fra underskjemaet i kalkyler, valideringer o.l. i hovedskjemaet. Disse feltene hentes fra InfoPath sin datakilde-meny på samme måte som for hovedkilden. Et skjema kan slettes fra skjemasettet i etterkant ved å trykke på lenken Fjern i listen over skjemaer som lagt til. Figur 17 - Skjemasett Ved åpning av skjemasettsiden vil viste utgaver være sortert alfabetisk på utgave-kortnavn. 28

29 8 Utvikling av tjenesteinnhold Tjenesteinnhold er alt som har med skjema og selve interaksjonen med sluttbruker i SBL å gjøre. Tjenesteinnhold defineres gjennom utvikling av skjema i InfoPath. Under området for Innholdsspesifikasjon på utgavens arbeidsflate kan du legge til et InfoPath-skjema og åpne og redigere skjemaet i Microsoft Office InfoPath. Det er skjemaet som definerer utgaven brukergrensesnitt og grafiske layout. Når et skjema er ferdigutviklet i InfoPath kan det defineres tilleggsegenskaper i TUL for å gi tjenesten ønskede egenskaper. Tilleggsegenskapene som kan legges inn er sideegenskaper, sporvalg, presentasjonsfelt, preutfylling, betalingsinfo og hjelpetekster. Kapitlet er organisert rundt disse, med fokus på hva som må gjøres i InfoPath for å få samspillet med TUL til å fungere. Veiledning knyttet til bruk av C# kode etc. beskrives til slutt i kapittelet. Skjema er mest brukt i innsendingstjenster, men kan også brukes i meldingstjenester. Dette kapittelet er mest rettet mot utvikling av innsendingstjenester, men meldingstjenester beskrives i kapittel 9. En generell brukerveiledning i InfoPath gis ikke i denne brukerveiledningen, og det henvises til Microsoft sin generelle brukerdokumentasjon på dette standardproduktet. Vedlegg A inneholder derimot en kort innføring i skjemautvikling i InfoPath for bruk rettet mot TUL. 8.1 Innholdsspesifikasjon Mens det i kapittel 7 ble beskrevet hvordan man definerer en utgave ved å angi prosessflyt og skjemasett, vil innholdsspesifikasjonen være rettet mot det som har med skjemaet å gjøre. For å lage skjemaer benyttes InfoPath, som er et standard Microsoft Office-produkt. Her bestemmes skjemaets layout, overskrifter/ledetekster, datafelt, kalkyler, valideringsregler og tilhørende feilmeldinger. Du kan også legge inn Hjelp-knapper som gir tilgang til hjelpeinformasjon under utfyllingen i SBL. Dette beskrives i kapittel En nærmere beskrivelse av hvordan InfoPath benyttes finner du i Vedlegg A: Veiledning i skjemautvikling i InfoPath Skjema Kjernen i en tjenesteutgave er skjemaet. Det lastes opp og vedlikeholdes i skjemabiblioteket på arbeidsflaten, som vist i figur 18. Dette er et standard SharePoint dokumentbibliotek, men godtar kun InfoPath-filer(.xsn). Sjekk ut/sjekk inn, versjonerings- og dokumentbibliotekfunksjonalitet er tilgjengelig. For detaljer om hvor sjekke ut og inn skjema, se kapittel Figur 18 - Skjemabibliotek Et skjema kan om ønskelig bestå av mange visninger som man kan navigere mellom under utfylling i SBL, eller benyttes for utskrift eller kvittering. En visning er synonymt med side. Det er verdt å merke seg at navnene og rekkefølgen som er på visningene inne i InfoPath, er 29

30 irrelevant. Hvordan de ulike sidene skal benyttes, angis på utgavens arbeidsflate under Sideegenskaper. Se kapittel Når man utvikler skjema for en utgave, gjør man det for utgavens hovedspråk. Som nevnt tidligere angis hovedspråket blandt utgaveparameterene. For at man skal kunne ha skjema på flere språk, er det flere ting som er viktig. Alle språkavhengige elementer i skjemaet (ledetekster, overskrifter og lignende) må defineres som uttrykksfelter (expression boxes) i InfoPath, slik at de skal kunne oversettes i oversettermodulen i TUL. Hvordan du setter opp uttrykksfelter er beskrevet i Vedlegg A: Veiledning i skjemautvikling i InfoPath. Tekster som flyter fritt utenfor uttrykksbokser vil ikke la seg oversette. Det er da også viktig å merke seg at tekster knyttet til radioknapper og sjekkbokser, samt tabelloverskrifter etc. må ligge i uttrykksbokser. Skjemaet selv, og de ulike komponentene skjemaet består av, bør navngis i henhold til gjeldende navnestandard, se Vedlegg F: InfoPath navnestandard. Når skjemaet er ferdig og lagret laster du det opp på utgavens arbeidsflate. Klikk på Last opp nytt dokument under området for Innholdsspesifikasjon, og velg den filen du ønsker å benytte. En tjenesteutgave av en innsendingstjeneste må ha ett, og bare ett, hovedskjema. Dersom tjenesten skal ha underskjemaer må underskjemaene defineres som egne tjenester og utgaver, og deretter knyttes opp mot tjenesten gjennom et skjemasett, som beskrevet i kapittel En meldingstjeneste kan også ha et skjema, som benyttes til å formattere meldingsdata før meldingen presenteres for sluttbruker. Dette beskrives i kapittel 9. For mer utfyllende dokumentasjon av hvordan skjemaer bør utformes, se kapittel Sjekke ut, editere og sjekke inn InfoPath-skjema For å kunne editere InfoPath-skjemaet, er det viktig at man sjekker ut først. Gjør man ikke dette vil man få en melding om at skjemaet er i bruk. Når man har sjekket ut, så trenger man bare å klikke på skjemaet navn for å editere. Det som skjer nå er at skjemaet åpnes i designmodus, men kan bli bedt om å taste inn brukernavn og passord. Dette er helt normalt og skyldes at InfoPath ikke deler sikkerhetsinformasjon med TUL SharePoint. Før skjemaet åpnes vil du første gang for hvert skjema få beskjed om at skjemaet er publisert til en annen lokasjon. Dette kan man bare ignorere ved å klikke Ok, og så svare Ja i neste dialogboks. Når skjemaet så åpnes, er det i read-only modus. Derfor velger man å lagre til TULShare før man begynner å editere. Grunnen til at man bør gjøre dette er at da har man en sikkerhetskopi på lokal disk. Velg derfor å lagre. Når alle endringer er gjort, så kan man lagre tilbake til TUL SharePoint. Velg Publisér fra samme meny som Lagre. Da åpnes et vindu hvor man velger Til en nettverksplassering, som vist i figuren under. 30 Figur 19

31 Trykk Neste. Så skal man angi hvor man vil publisere skjemaet. Det vil være tilbake til TUL og skjemabiblioteket i Innholdsspesifikasjonen. Det som typisk vil stå i øverste feltet er: Figur 20 F.eks. En av måtene man finner fram til denne adressen på, er å velge Vis egenskaper og så høyreklikke på skjemanavnet velge Kopier snarvei. Dette limer man så inn igjen i InfoPath. Merk at dette er noe man kun trenger å gjøre en gang for hvert skjema/utgave. Klikk Neste og verifiser at samme bane og filnavn som i forrige skjermbilde står også her. Klikk Neste, og så Publisér. Nå lagres skjema tilbake i TUL og du kan klikke Lukk når dette er fullført. Det er viktig å påpeke at valget Rediger i Microsoft InfoPath, som finnes i kontekstmenyen til skjemaet, ikke skal benyttes. Dette valget støtter ikke åpning i design modus eller SharePoint sin utsjekk/innsjekk-funksjonalitet Sideegenskaper Under Sideegenskaper kan du tildele egenskaper til skjemaets visninger fra InfoPath. Egenskapene bestemmer hvordan en visning fra InfoPath skal benyttes i sluttbrukerløsningen. De neste seksjonene angir hva som må angis for hver visning, og for at en migrering av utgaven til SBL skal være vellykket, må sideegenskaper være komplett Navn Dette er navnet som skal være gjeldene for utgavens hovedspråk. Navnet kan inneholde norske bokstaver, og vil kunne oversettes i språkverktøyet. Navnet på siden vises i Elmer s høyre kant, også kalt navigasjonsmenyen i SBL. Navnet vil deles ved mellomrom hvis det er langt, men det er verdt å tenke på at navnene ikke bør inneholde lange ord uten mellomrom. Hvor mange bokstaver et ord kan ha, vil avhenge av oppløsningen sluttbruker har på sin skjerm under utfylling. Det bør dog taes hensyn til at denne kan være så liten som 1024x Rekkefølge I InfoPath er det ikke mulig å definere rekkefølge/sekvens på sidene. Dette er avhengig for å styre sluttbrukers utfylling. Det er derfor i sideegenskaper mulig å angi et unikt nummer for en visning, hvor prinsippet med stigende rekkefølge vil være gjeldene. Det vil ikke være mulig å velge samme nummer på to sider da det nummeret man velger vil byttes med den siden som 31

32 allerede har gjeldene nummer. Ved åpning av sideegenskaper vil visningene være listet i rekkefølgene de befinner seg i skjemaet. Dette medfører at en visning tiltenkt utskrift eller kvittering kan ligge i listen før andre visninger tiltenkt utfylling. Det er da viktig at sekvens/rekkefølge tar hensyn til dette. Det er derimot viktig at siden som er satt til å være først i TUL, i InfoPath har egenskapen Angi som standardvisning avkrysset. Dette gjøres på egenskaper for gitt view i InfoPath Visningstype InfoPath har mulighet for å angi utskriftversjon for et skjema, men denne funksjonaliteten skal ikke benyttes, da det setter begrensninger for PDF-generering av visninger. Det finnes tre visningstyper å velge mellom: Web: Skjemaside skal benyttes for utfylling i sluttbrukerløsningen. Dette vil være typen de fleste visninger har. Denne typen skal også velges om skjemaet benyttes i en meldingstjeneste. Utskrift: Angir at denne visningen skal benyttes ved generering av utskriftsformat i sluttbrukerløsningen. Dersom man ønsker utskrift basert på webvisning av skjema skal man opprette så mange visninger som det er sider i skjema og kopiere og lime inn innholdet fra hver side til tilhørende visning for utskrift. Utskrift-visningene kan settes til å være read-only ved å klikke på Fil, så Sideegenskaper og krysse av for Read-only. Der kan man også sette formatet på side som skal skrives ut, samt at man kan se forhåndsvisning for utskriftsversjon. Kvittering: Vises til sluttbruker etter innsending. Kvittering opprettes ved at man lager ekstra visning og kaller den f.eks for Kvittering, definerer layout og legger deretter på de feltene som man ønsker å ha på kvitteringen. Man kan definere hjelpefelter og legge dem på utskriftsvisninger og på kvitteringen. For å gjøre det enklere å opprettholde riktig rekkefølge og sidetype i TUL så bør sidene i InfoPath gis navn som klart indikerer hva de skal brukes til: Web 1, Web 2 osv, Utskrift 1, Utskrift 2 osv og Kvittering. Figuren nedenfor viser skjermbilde av siden for sideegenskaper. Figur 21 - Sideegenskaper 32

33 8.1.4 Sporvalg Sporvalg er en funksjonalitet bestemmer hvilke sider som presenteres for sluttbrukeren avhengig av hva bruker fyller ut i skjema. Dette muliggjør å tilpasse skjemaet til flere formål. Et sporvalg består av flere spor. En utgave kan ha flere sporvalg, på ulike sider, det skal dog ikke være mer enn ett sporvalg pr side. Skal man ha flere sporvalg på samme side, må verdier mellomlagres i uttrykksbokser. Eksempel: Dersom spørsmålet Er du gift? ligger på side 1 i et skjema kan svaret medføre to ulike spor avhengig av om sluttbrukeren svarer Ja eller Nei. Dersom sluttbruker svarer Ja skal skjemaside 2 Informasjon om ektefelle fylles ut før skjemaside 3 og 4. Dersom sluttbruker svarer Nei skal ikke skjemaside 2 Informasjon om ektefelle bli vist i det hele tatt, men sluttbruker skal tas direkte til skjemaside 3 og 4. For å definere sporvalget videre i TUL, velg Sporvalg under område Innholdsspesifikasjon på utgavens arbeidsflate. Definer et spor ved å velge side og felt, og skriv inn verdi. Velg deretter hvilke sider som skal vises for denne verdien. Alle spor med felles side og felt vil danne et sporvalg. Figuren under viser to spor i samme sporvalget. Figur 22 - Sporvalg Presentasjonsfelt Presentasjonsfelt bruker i SBL for å skille flere innsendinger av samme utgave fra hverandre i arbeidslisten og arkiv. Måten dette gjøre på er å vise det utfyller har skrevet i gitt(e) felt sammen med navnet på utgaven. Presentasjonsfeltene listes etter utgavenavnet og henter verdier som brukeren har oppgitt under utfylling av skjemaet. Naturlige presentasjonsfelt kan være f.eks organisasjonsnummer, navn eller termin. I TUL velges presentasjonsfelt ved å først velge side. Rekkefølgen på de presenterende feltene kan endres. Det er mulig å oppgi maksimalt seks presentasjonsfelt. Rekkefølgen vil være gjeldende i SBL hvor presentasjonsfeltet med ID 1 vil komme først etter utgavenavn, så ID 2 osv. Definerte presentasjonsfelter fjernes ved å klikke på Fjern. Eksempel: Tjenesten RR-0002 Årsregnskap for små, store og øvrige selskap kan benytte feltet Organisasjonsnavn som presentasjonsfelt. I sluttbrukerløsningen vil ulike innsendinger av denne tjenesten bli listet med tjenestenavnet først og verdien i feltet Organisasjonsnavn bak, eksempelvis: RR-0002 Årsregnskap for små, store og øvrige selskap, Nordmanns advokatselskap RR-0002 Årsregnskap for små, store og øvrige selskap, Hansens Bygg og Håndverksselskap 33

34 Figur 23 - Presentasjonsfelt Preutfylling Med preutfylling menes at felter i et skjema kan være forhåndsutfylt når skjemaet åpnes i sluttbrukerløsningen. Det er tre ulike måter å preutfylle på: 1. Skjemaet leveres ferdig preutfylt fra tjenesteeier til Altinn. Sluttbruker vil se et utfylt skjema i sluttbrukerløsningen med data som tjenesteeier/etat har bestemt. 2. Tjenesteeier sender prefilldata som nøkkel/verdi-par, i kombinasjon med avgiver-id. Nøkkelen identifiserer skjema og felt (xpath) der verdien skal fylles inn. Her vil felt bli preutfylt hvis de matcher xpath som tjenesteeier/etat har angitt. Dette vil tilsvare preutfyllingen av spesifikke orid er i Altinn Preutfyllingsdata hentes fra sentrale registre og fylles ut i gitte felter. Tjenesteutvikler bestemmer hva som skal preutfylles i de enkelte feltene. Data til disse feltene hentes fra registeret i sluttbrukerløsningen ved instansiering av skjema. I TUL må preutfyllingssiden fylles ut dersom dersom tjenesten skal benytte preutfyllingsmåte 2 eller Nøkkel/verdi-preutfylling Huk av for Tillat nøkkel/verdi preutfylling dersom tjenesteeier skal kunne sende inn prefilldata som nøkkel/verdi-par for denne tjenesten. Det er viktig at Xpath som ligger lagret i SBL må matche skjemaets felter sin xpath for at de skal forhåndsutfylles ved nøkkel/verdi preutfylling Registerpreutfylling Registerpreutfylling går ut på at man velger hvilke felt som skal inneholde data fra hvilke registerfelt. Dataene som vises er da basert på hvilken avgiver som utfyller sender inn for. Velg register, skjemaside, skjemafelt, kontekst og registerfelt for de feltene som skal hentes fra sentrale registre. Det legges til en ny blank linje i preutfyllingsbildet for hver linje som registreres, slik at man kan registrere så mange felt man vil. Det finnes tre registre, og hver av registrene har egne kontekster. Kontekster er på bakgrunn av hva man skal hente ut data Registerforkortelse Registernavn Kontekst(er) DSF Det sentrale folkeregister Privatperson ER Enhetsregisteret Enhet, juridisk enhet og valgt org.nummer DLS Deltakerlignende selskap Ingen Merk: DLS har p.t. ingen prefillfelter tilgjengelig. 34

35 8.1.7 Betalingsinformasjon Figur 24 - Preutfylling Dersom en innsendningstjeneste skal kunne generere betalingsinformasjon i sluttbrukerløsningen angir du her hvilke felter i innsendingen som skal benyttes for de ulike betalingsdetaljene. Du kan velge gjenbrukbar logikk for generering av betalingsinformasjon i et nedtrekksliste for Betalingslogikk øverst på siden. Hvilke felter som er påkrevd, avhenger av hvilken betalingslogikk som er valgt. Det vil derfor ikke i TUL valideres og må kjennes av den enkelte skjemautvikler basert på logikken som velges. Figur 25 - Betalingsinformasjon Hjelpetekster Til hvert felt i et skjema laget i InfoPath kan det knyttes en hjelpetekst. Hjelpteksten vises i Elmer s høyre side i SBL. En hjelpetekst i TUL knyttes ikke direkte til et felt, men til en knapp som må plasseres i nærhet av feltet den skal tilhøre. Denne knappen på ha et navn som begynner på HelpText_ for å kunne gjenkjennes i TUL. For hver knapp i skjemaet som har et navn som begynner på HelpText_ vil det være mulig å definere èn tekst. 35

36 Først oppretter du hjelpeknapper i InfoPath for enkeltfelter og overskrifter som skal ha hjelpetekster. For hver hjelpeknapp må det opprettes C#-kode i InfoPath. Se Vedlegg A: Veiledning i skjemautvikling i InfoPath for en beskrivelse av hvordan dette gjøres. I TUL, kan du velge å se alle hjelpeknappene i skjemaet eller velge side i nedtrekkslisten for å begrense innholdet i listen. En hjelpetekst bør inneholde en begrenset mengde tekst for ikke å flyte ut i SBL. Begrensningen er dog ca tegn, inklusive mellomrom og spesialtegn. Det er verdt å merke seg at dette er inkludert HTML-formatering. Figur 26 - Hjelpetekster Hjelpetekst nivå 1 og nivå 2 Det er hensiktsmessig å begrense innholdet i hjelpeteksten som vises i sluttbrukerløsningen til så kort og konsist som mulig, men der hvor det ikke er hensiktsmessig eller mulig bør man tilstrebe å vises informasjon fra eksterne kilder i et eget vindu. Hjelpetekst som vises i sluttbrukerløsningen kalles Nivå 1, mens ekstern hjelpetekst kalles Nivå 2. For å gjøre dette må man legge inn en lenke i hjelpeteksten i TUL. Dette gjøres i to steg via teksteditoren: (tekst innenfor $ vil variere) 1. Plassèr markøren i hjelpeteksten der du vil at lenken skal vises. 2. Klikk på lenke-ikonet og tast inn url en til den eksterne hjelpeteksten. 3. Bytt til kildevisning av teksten ved å klikke på kilde-ikonet 4. Finn HTML-koden til lenken, angitt som <a href= >$Lenke$</a> 5. Legg til target= _blank slik at HTML-koden blir <a href= target= _blank >$Lenke$</a> Dette vil gjøre at lenken åpnes i nytt vindu. 36

37 9 Meldingstjeneste En meldingstjeneste er ikke likt en innsendingstjeneste. Mens en innsendingstjeneste instansieres i SBL, dvs initialiseres som et element tilhørenende en gitt avgiver, er en meldingstjeneste en definisjon på en melding, men ikke selve meldingen. Det er ikke mulig å åpne en melding uten av en tjenesteeier har sendt deg en. Ergo, meldingstjenester kan bare instansieres av etat enten via enten webservice eller batchgrensesnitt. Med andre ord er det å definere en meldingstjeneste slik at en bruker kan åpne den i SBL, en to-delt affære. 9.1 Definere meldingstjeneste En meldingstjeneste kan ha utgaver akkurat som en innsendingstjeneste, og har også utgaveparametere. Utgaveparameterene er ikke de samme som for utgaver av innsendingstjenster, selv om mye er likt. Se kapittel for mer informasjon. Det som er viktig å skille på, er hva som defineres for utgaven i TUL, i forhold til hva som er del av meldingsinnholdet som i all hovedsak kommer fra tjenesteier. 9.2 Meldingsinnhold Innholdet i en melding kommer som sagt i all hovedsak fra tjenesteier direkte til SBL, med unntak av InfoPath-skjema. Følgende overordnet informasjon er påkrevet i data sendt fra tjenesteier: Mottaker. Avsender (Avsender i TUL vil overskrive denne). Meldingsinnhold. Varsling. Referanse til metadata(dvs utgaven definert i TUL). Når det gjelder meldingsinnhold, så kan dette i hovedsak bestå av tre typer: Binært vedlegg: Dette er det mest benyttede i dagens løsning, meldingsinnhold er en PDF fil som er generert av etat. HTML: Meldingsinnholdet er i sin helhet vist fram i correspondence siden. Infopath skjema: Benytte InfoPath skjema som presentasjon. Se kapittel InfoPath-skjema som meldingsinnhold Å bruke infopath skjemaer i meldingstjenester er noe helt nytt i Altinn2, og har ikke vært mulig i Altut (Altinn1). De fleste meldingstjenester benytter enten et binært PFD vedlegg eller HTML innhold. Skjema som lastes opp på utgavearbeidsflaten i TUL vil angi hvordan hver meldingsinstans skal vises fram. Når et infopath skjema er med i utgaven, må du som tjenesteier ved instansiering i SBL legge ved data som passer til det skjemaet du har lagt ved. Disse dataene vil i hver enkelt meldingsinstans bli smeltet sammen med InfoPathskjemaet. Dataene må altså baseres på samme XSD som Infopath skjemaet. 37

38 10 Enhetstest Med enhetstest menes å verifisere enkeltdeler av en tjeneste hver for seg. Layout og andre tjenesteegenskaper som legges inn via InfoPath kan enhetstestes I InfoPath. Regler definert I InfoPath kan testes direkte I InfoPath ved å bruke forhåndsvisning (preview). For tjenestespesifikasjon, utgavespesifikasjon og parametre knyttet til en utgave, må en eventuell enhetstest skje ved å gå gjennom definerte sjekklister for disse. Utfylte sjekklister kan eventuelt lagres under Designdokumenter i tjenestens arbeidsflate. En videre test av tjenesten må foretas i portalmiljø. 38

39 11 Migrering til portalmiljø En utgave av en tjeneste kan migreres til sluttbrukermiljø når tjenesten er tilstrekkelig definert og utviklet. I TUL fins fire ulike statusikoner som skal illustrere statusen for hver enkelt parameterseksjon som vist i tabell 1 i kapittel Når en utgave av en tjenste skal migreres til et sluttbrukermiljø, skal alle statusikoner vise ikonet,eventuelt Ett unntak er språk, hvor sekundærspråk ikke behøver å være komplette Start migrering Migrering skjer fra en egen side i TUL. Hit kommer man via lenken Gå til migreringssiden under området for Status og migrering på utgavens arbeidsflate. Fra migreringssiden kan tjenesteutvikler velge sluttbrukermiljø, versjon, språk som skal migreres og sette gyldighetsdato for test. Sluttbrukermiljø kan være miljø for systemtest, akseptansetest og opplæring. Sluttbrukermiljøene vil kunne variere fra et tjenesteutviklingsmiljø til et annet. Tjenesteutvikler kan ikke migrere tjenester til produksjonsmiljø, da all migrering til produksjon skal kvalitetssikres av applikasjonsforvalter i forkant av migreringen. Tjenesteutvikler kan imidlertid velge å sende en bestilling av produksjonssetting fra migreringssiden. Sluttbrukermiljø velges fra en nedtrekksliste der alle miljø det er mulig å migrere til står listet, i tillegg til et valg om å bestille produksjonssetting. Versjon velges fra en nedtrekksliste med defaultvalg Nyeste. Det vil si at en lager en ny versjon bestående av de siste endringene som er gjort på tjenesteutgaven. Språk velges fra en liste med sjekkbokser. Her listes hovedspråk samt eventuelle oversettelser (sekundærspråk). Alle tjenester har en gyldighetsperiode som er satt i utgaveparametrene. Utgavens Gyldig fra -dato må overstyres for at man skal kunne teste tjenesten før den skal være tilgjengelig for sluttbruker. Når migrering igangsettes, starters en eksportjobb som pakker sammen tjenestekomponentene til en pakke, versjonerer den og overfører den til valgt sluttbrukermiljø. Eksportjobben kjøres automatisk og status for migreringen gjøres tilgjengelig for tjenesteutvikler på en egen side for migreringsstatus. Velger man å migrere en tidligere versjon, hentes pakken fra denne versjonen fram igjen og migreres Migreringsstatus Hvis du nettopp har gjennomført en migrering, blir du tatt til en egen side med oversikt over alle gjennomførte migreringer. Øverst på siden vises resultatet av den siste migreringen og i en tabell listes alle migreringsjobber som har blitt gjort. Listen inneholder et innslag per miljø som den enkelte versjonen er migrert til. Listen inneholder også migreringsdato, navn på den som har kjørt migreringen og lenke til en migreringsrapport. Rapporten er i excel-format og inneholder detaljer om hva som er inkludert i hver enkelt migrering. Denne informasjonen kan være nyttig hvis det blir nødvendig å rulle tilbake. Visningen av nylig gjennomført migrering viser enten at skjema prosesseres eller er aktivert og migrering er fullført. For å komme videre kan du gå direkte til et portalmiljø ved å klikke på navnet til miljøet du ønsker i listen over migreringer, eller du kan klikke på OK-knappen for å gå tilbake til 39

40 utgavens arbeidsflate. Du taes til gitt utgave i SBL via en direktelenke. Direktelenken er beskrevet i neste kapittel, Direktelenke Direktelenken er konstruert på bakgrunn av utgavens eksterne tjenestekode og eksterne utgavekode: <A> er adressen til miljøet <B> er den eksterne tjenesteutgavekoden <C> er den eksterne tjenestekoden F.eks. itioncode=635821&servicecode= Migreringsstatus på utgaven arbeidsflate På utgavens arbeidsflate er det et område for Status og migrering. Her vises en oversikt over versjonens migreringsstatus. Herfra kan du også gå direkte til siden med migreringsoversikt via en lenken Vis oversikt. Mulige statuser for utgave: Type status Versjonsstatus Migreringsstatus Produksjonsstatus Ordlyd til overskrift i tabeller/ arbeidsflate for utgave Siste versjon Siste migrering I produksjon Mulige statuser Under utvikling Ikke migrert Nei Hovedskjema: Migrert Underskjema: Komplett dd.mm.yy Ja Kjente feilmeldinger Ved migrering til sluttbrukerløsningen kan det oppstå plutselige og uhåndterte feil som følge av kommunikasjonsproblemer, problemer med skjema o.l. Det er vanskelig for løsningen å oversette disse feilene i og med at de originerer fra et standardprodukt. Dette kapittelet vil derfor forsøke å beskrive noen av de vanligere feilmeldingene som kan oppstå ved uhåndterte feil. An unexpected error occured that prevented the migration of the service edition. Migration failed Denne tyder i de fleste tilfeller på at noe er feil med skjemaet, som gjør at den ikke TUL ikke klarer å oversette skjemaet på hovedspråket. Åpne skjemaet i InfoPath og påse at Designchecker ikke melder noen feil. Rett evt. feil og sjekk inn skjema på nytt. A communication error occured that prevented communicating with SBL. Unable to migrate Denne antyder i 9 av 10 tilfeller at TUL ikke får kontakt med importeringstjenesten i SBL. Det kan også bety at skjemaserverene i SBL ikke klarer å laste opp skjema og kaster et unntak. Vent noen minutter og prøv igjen, hvis du har mistanke om at det er skjema, kjør design checker. 40

41 The request channel timeout while waiting for a reply...timeout Dette indikerer at SBL bruker for lang tid på å svare. Dette kan enten skyldes en feil i SBL, eller at trykket på løsningen er veldig stort. Vent noen minutter og forsøk igjen. SBL was unable to import the service ediiton package sent. All the changes have been rolled back. Migration failed. SBL returned the message: An error occurred: The XSN cannot be used on the server Dette indikerer at det er noe feil med skjemaet som forsøkes lastet opp. Påse at skjemaet er Browser enabled, og at design checker ikke rapporterer noen feil. Denne vil også vises hvis et eller flere felter er ubundet, ved f.eks. at det er fjernet en datakilde e.l. Typisk hvis en felles datakilde er fjernet. An error occured Dette er en standard SharePoint feilmelding som i de fleste tilfeller skyldes en feil med løsningen eller serverproblemer, og ikke utgaven som er forsøkt migrert. SBL was unable to import the service ediiton package sent. All the changes have been rolled back. Migration failed. SBL returned the message: An error occurred: Object reference not set to an instance of an object Dette indikerer at det er noe feil med skjemaet som forsøkes lastet opp. Påse at design checker ikke rapporterer noen feil. Forsøk å rull tilbake skjema til en tidligere versjon og forsøk igjen. I de fleste tilfeller kommer denne feilen hvis det finnes felter i skjemaet som ikke er bundet mot datakilden, eller at en datakilde som hadde felter bundet mot seg, er fjernet Rulle tilbake For å rulle tilbake til en tidligere migrert versjon av utgaven må man på migreringssiden velge den versjonen man ønsker å rulle tilbake til i nedtrekkslisten der man kan velge miljø (2 Velg miljø). Denne lister alle versjoner av utgaven. Vil man rulle tilbake arbeidsflaten, må dette gjøres manuelt ved hjelpe av migreringsrapporten for gitt versjon. 41

42 12 Oversetting En tjenesteutgave utvikles alltid i et hovedspråk. Hovedspråket velges som utgaveparameter når utgaven opprettes, som beskrevet i kapittel 7.2.1, og kan ikke endres senere. Man kan velge mellom følgende språk: bokmål, nynorsk, samisk og engelsk. Alle deler av tjenesten utvikles først i hovedspråket, både InfoPath-skjema og tekster som legges inn i TUL (for eksempel tjeneste- og utgavenavn, sidenavn, signeringstekst, hjelpetekster). Hvis det er behov for å tilby tjenesten på flere språk må TUL oversettermodul benyttes. Denne startes fra tjenesteutgavens arbeidsflate. Det lønner seg å vente med oversettelsen til utgaven er komplett på hovedspråket, for å slippe ekstra vedlikehold. For å starte oversettelse til et nytt språk, velg Ny i språkseksjonen i arbeidsflaten. Du får opp en side der du kan velge hvilket språk du vil oversette til: Figur 27- Oversetting i TUL. Velg hvilket språk du ønsker å oversette til. Alternativene er de samme som for hovedspråk, se over, med unntak av det språket som er valgt som hovedspråk, Når språk er valgt presenteres oversettelsessiden: 42 Figur 28 - Oversettelsessiden i TUL Her han du velge hva du vil oversette (parametre, hjelpetekster, skjemaelementer, valideringstekster eller alt sammen) og hvilket språk du vil oversette fra. For den første oversettelsen er det bare ett alternativ å oversette fra (nemlig hovedspråket), men for senere oversettelser kan du fritt velge blant de eksisterende språkversjonene, uavhengig om de er komplette eller ikke. På oversettelsessiden presenteres en liste over de tekstelementene som utgaven inneholder innenfor den kategorien du har valgt, med plass til å skrive inn din oversettelse av hvert tekstelement: Merk at for hovedspråket er det kun mulig å oversette tjenestenavn.

43 Figur 29 - Oversetting i TUL Skriv inn dine oversettelser og lagre med OK-knappen. Om ønskelig kan du avbryte oversetterarbeidet før det er ferdig. Språkversjonen blir da liggende utsjekket til deg, og ingen andre får lov til å endre den. Den nye språkversjonen vil nå vises på utgavesiden, og du kommer inn igjen i oversettelsen ved å klikke på det aktuelle språket. Klikk på Sjekk inn når du er ferdig med oversettelsen, eller ønsker at andre skal ta over arbeidet. Vær oppmerksom på at det må tas spesielle hensyn i InfoPath når skjemaet utvikles for at skjemaet skal kunne oversettes i TUL. Alle språkavhengige elementer i skjemaet (ledetekster, hinttekster, gruppeoverskrifter osv.) må defineres som uttrykksfelter ( expression box ), ellers vil de ikke bli oversatt. Uttrykksbokser beskrives i Vedlegg A. For å teste en språkversjon av et skjema, kan du gå tilbake til utgave-arbeidsflaten og velge Vis InfoPath form fra nedtrekksmenyen som er knyttet til språknavnet: Figur 30 - Test språkversjonen ved å trykke Vis InfoPath fra nedtrekksmenyen som er knyttet til språknavnet Skjemaet vil da bli vist i InfoPath med språkavhengige elementer erstattet med de oversettelsene som er lagt inn i TUL. I de fleste tilfeller vil man måtte lagre skjemafilen lokalt og velge design for å få se at skjemaet er på riktig språk. For å teste oversettelse av øvrige tekster må tjenesteutgaven migreres til et testsluttbrukermiljø. Hvordan dette gjøres er beskrevet i kapittel 11. Dersom du migrerer en språkversjon til testmiljøene uten at alle tekster er oversatt, vil manglende oversettelser bli erstattet av samme tekst på hovedspråket. Dersom det ikke lenger er behov for en oversettelse kan den slettes fra utgaven ved å velge Slett fra nedtrekksmenyen som er knyttet til språknavnet. Du får da opp et pop-up vindu der du må bekrefte at oversettelsen til dette språket skal slettes. 43

44 13 Slette tjeneste og utgave Det er mulig å slette en tjeneste eller en tjenesteutgave fra TUL dersom du skulle ønske dette. Det kan være fordi tjenesten ikke lenger skal være i bruk og dermed skal slettes både fra TUL og fra sluttbrukerløsningen. Det kan også skyldes at en tjeneste erstatter en annen eller at det er startet arbeid på en tjeneste eller utgave som ikke er korrekt. Når du har slettet en tjeneste eller tjenesteutgave vil den ikke lenger være synlig i TUL eller SBL. Den vil ikke fjernes fysisk fra TUL SharePoint, men vil bli merket som slettet. Utgaven da bare kunne sees av en administrator Slette tjeneste For å slette en tjeneste fra TUL starter du med å slette eventuelle utgaver først. Du får ikke lov å slette en tjeneste som har aktive utgaver. Deretter går du til tjenesteeiers arbeidsflate og velger alternativet Slett i kontekstmenyen til tjenesten du ønsker å slette. Du kommer da til et eget skjermbilde der du kan slette tjenesten. Figur 31 - Slett tjeneste Figur 32 - Det er kun mulig å slette tjenester som ikke har noen utgaver Når du har bekreftet slettingen vil tjenesten fjernes fra alle steder den tidligere har vært tilgjengelig. Det er verdt å merke seg, at tjenesten vil være synlig for administratorer, men da ville være markert i rødt Hvordan slette utgave For å slette en tjenesteutgave fra TUL starter du på tjenestens arbeidsflate og velger alternativet Slett i kontekstmenyen til utgaven du ønsker å slette. Du kommer da til et skjermbilde der du kan slette tjenesteutgaven. Sletting er bare mulig dersom ingen deler av utgaven er sjekket ut for editering. 44

45 Figur 33 - Slett tjenesteutgave Når du har bekreftet slettingen vil prosessen videre være avhengig av om utgaven er produksjonssatt eller ikke. Hvis utgaven er produksjonssatt vil det bli sendt melding til applikasjonsforvalter om at utgaven skal deaktiveres i produksjon. Utgaven blir liggende i TUL med status deaktivering bestilt, inntil bekreftelse kommer fra driftsoperatøren om at deaktivering er utført. Først da blir utgaven slettet, og det gjøres manuelt av en bruker med administratorrettigheter i TUL. Bare brukere med administratorrettighet får lov å velge Slett på en utgave som har status deaktivering bestilt status. Hvis utgaven ikke er produksjonssatt blir den slettet i TUL SharePoint straks, samtidig som eventuelle versjoner som er migrert til testmiljø blir deaktivert der. Det er verdt å merke seg, er at tjenesteutgaven vil kunne vises for administratorer, men da ville være markert i rødt Gjenopprette slettede tjenester og utgaver Dette er en operasjon som utføres sjelden, og det er derfor ikke et eget brukergrensesnitt for dette i TUL, men en manuell jobb som gjøres i databasen av driftsleverandør. Det vil avhenge av tjenesteeier sin prosess mot driftsleverandør, men det oppfordres til at gjennopprettelse av slettede utgaver og tjenester bestilles enkeltvis ved behov. 45

46 14 Kodelister En kodeliste er en liste med faste verdier som for eksempel postnummer og poststed eller kommuner og landkoder. Kodelisten brukes typisk i nedtrekkslister i skjema i sluttbrukerløsningen. En kodeliste kan brukes på tvers av tjenesteeiere og tjenester, eller den kan spesiallages for enkelte tjenesteeiere eller tjenester. Kodelister vil vedlikeholdes utenfor den enkelte tjeneste og må migreres over til sluttbrukerløsningen på linje med tjenestene. Kodelistene nåes ved å klikke på kodeliste-lenken til høyre på startsiden. Du kommer da til kodelistebiblioteket Administrere kodelister Dette er en oversikt over alle kodelistene som finnes i TUL. Alle kodelister som er tilgjengelig vises med navn, hvilken person som har opprettet kodelisten (eier), samt informasjon om status og endringstidspunkt. Listen kan sorteres og filtreres ved å trykke på kolonneoverskriftene. Du henter fram en enkelt kodeliste ved å trykke på kodelistenavnet i listen. Klikk på Ny for å legge til en ny kodeliste Ny kodeliste En kodeliste opprettes ved å klikke på Ny i toppen av kodelistebiblioteket. Det er viktig at kodelisten ikke inneholder spesialtegn, samt norske bokstaver (æ,ø,å). Dvs, tegn som ikke kan brukes er typisk!, }, (, &, %, $,, *, é, è, á, ä, æ, ø, å etc. Kodelistenavnet brukes kun for identifikasjon, og vil ikke vises noe sted for sluttbruker. Det er også mulig å legge til en beskrivelse. Denne heller brukes ikke annet i TUL SharePoint. For å endre beskrivelse i ettertid, må man navigere til kodelisten og navigere til innstillinger. Der kan beskrivelsen endres. Du kan migrere kodelisten ved å velge Migrer i Handlinger-menyen. For å se hvilke versjoner av kodelisten som finnes i hvilke miljøer, velg Migreringsstatus i samme meny Vedlikeholde kodelister Ved å klikke på gitt kodeliste i kodelisten kan du lese og endre kodelisten. Sorter listen ved å trykke på kolonneoverskriften du ønsker å sortere på, for eksempel Språk. Endre et enkelt element i listen ved å trykke på navnet til det elementet du ønsker å endre. Du kan også vedlikeholde kodelisten i Excel-visning ved å velge Rediger i dataark Handlinger. Hver rad i listen inneholder følgende kolonner som kan editeres: Tittel: Denne verdien brukes kun i TUL i kodelistvisning, og er ikke brukt i skjema Kode: Denne verdien må være unik og angir koden/nøkkelen til verdiene for den gitte raden. Merk at koden må være den samme for alle språkene av den samme raden. Språk: Angir språket raden er på Verdi 1-3: Angir verdier som kan kobles mot gitt kode I en kodeliste må det finnes like mange rader for alle språk det finnes rader på. F.eks., hvis man har tre rader på engelsk, og kodelisten skal defineres for bokmål også, så må det være tre rader med de samme kodene her også. Det må også være et likt antall verdier for alle rader. Grunnen til at det er tre verdier som kan defineres, er for at man skal kunne lagre mer informasjon om en kode. F.eks. kan en rad i kodelisten se slik ut: Kode Verdi 1 Verdi 2 Verdi 3 Språk NO Norge Oslo NOK 1044 (bokmål) NO Noreg Oslo NOK 2068 (nynorsk) NO Norway Oslo NOK 1033 (english) Eller slik: Kode Verdi 1 Verdi 2 Verdi 3 Språk NOK Norge (bokmål) SEK Sverige (bokmål) USD USA (bokmål) 46

47 Kodelisten må deretter migreres etter den er ferdig definert. Statusen til kodelisten vil da endres fra Endret til Migrert Migrere kodeliste Før kodelisten kan tas i bruk i et skjema, må den migreres til SBL i samme miljø som utgave som benytter kodelisten migreres til. Kodelisten kan migreres til både testmiljøer og til produksjonsmiljø. Dersom du velger å migrere til produksjonsmiljø, sendes det en bestilling om produksjonssetting. Du kan migrere en kodeliste til flere miljøer samtidig ved å huke av sjekkboksen foran miljøene du ønsker. Deretter velge versjon; tidligere migrerte versjoner eller den nyeste. Den nyeste vil være den som er gjeldene i kodelistebiblioteket p.t. Ved å klikke OK startes migreringen og migreringsstatussiden med migreringsoversikt vises. Migreringsoversikten for kodelister inneholder en komplett oversikt over alle migreringer som er gjort av denne kodelisten. Du vil også få beskjed om migreringen var vellykket eller ikke. Denne meldingen vil ikke vises hvis du navigerer direkte til migeringsstatussiden fra kodelistebiblioteket. I migreringsloggen vil du også kunne se XML-kildekoden for den enkelte migrerte kodeliste ved å klikke på Vis XML til høyre for hvert element i listen over migrerte versjoner av en kodeliste Slette kodeliste En kodeliste kan enkelt slettes ved å velge slett fra kodelistens kontekstmeny, uavhengig av om den er migrert eller ikke Sortering av kodeliste Fast for alle kodelister er at de sorteres alfabetisk på kolonnen Verdi1. Det betyr at når kodelisten migreres til SBL og hentes ut igjen og inn i skjema, presenteres verdiene sortert på kolonnen innefor hvert språk. Merk at dette er en tekstsortering, slik at man behøver ledende 0 ere for tall. Denne funksjonaliteten kan utnyttes på to måter: a. Benytte Verdi1 som sortert visningsnavn. Alt som blir vist i nedtrekkslisten er da sortert alfabetisk. b. Benytte Verdi2 eller Verdi3 som visningsnavn og Verdi1 for å angi sorteringsrekkefølge. Det vil si at man kan tvinge frem en annen sorteringsrekkefølge en rekkefølgen som er angitt i kodelisten i TUL Kodeliste inn i InfoPath For å benytte en kodeliste i et skjema, må som nevnt kodelisten først være migrert til det eller de miljøene man skal migrere utgaven med skjemaet til. En kodeliste vil for et skjema opptre som en ekstra datakilde, som kan kobles til en nedtrekksliste etc. i skjema, på omtrent samme måte som felles datakilde for skjemasett. Hvis kodelisten ikke er benyttet for valgt utgave før, starter man med å høyreklikke på feltet man vil kodelisten skal vises i. Dette må være et flervalgsfelt, typisk en nedtrekksliste. Man velger egenskaper for feltet, f.eks. Egenskaper for Rullegardinliste og angir at man vil Slå opp verdier fra en ekstern datakilde. Trykk Legg til... for å opprette en ny tilkobling og velg Motta data. Her er det verdt å merke seg at hvis man ønsker å benytte samme kodeliste for et annet felt, behøver man ikke opprette en ny kobling, men bare benytte eksisterende ekstern datakilde. Se figuren nedenfor. 47

48 Figur 34 - Kodeliste i Infopath Man må deretter benytte en Webtjeneste som datakilde. Adressen til webservicen vil være gitt av sluttbrukerløsningen, og vil kunne finnes på lenken under kodeliste-lenken på startsiden; Kodeliste-WS. Kodeliste-webservicen vil trenger tre parametere som inndata, som vist i figuren under. Parameterene er som følger: Figur 35 - Inndata for kodeliste i InfoPath tns:codelistname: Dette er navnet på kodelisten som den heter i kodelistebiblioteket. tns:codelistversion: Dette er versjonen av kodelisten du vil knytte mot skjemaet. Angis 0 vil siste versjon benyttes tns:languageid: Dette er identifikatoren til språket. Dette må være det samme som hovedspråket til utgaven. Bokmål=1044, Nynorsk=2068, Samisk=1083 og Engelsk=1033. Det man nå må gjøre er å velge hva som skal vises, og hva som skal lagres fra kodelisten i skjemaet. Dette gjøres ved å først velge den repeterende noden i dataene som webservicen returner ved å klikke på ikonet til høyre for feltet Oppføringer. Da åpnes et vindu som vist under. Velg CodeListRow. 48

49 Figur 36 - Kodeliste i InfoPath Deretter velges verdi og visningsnavn ved å klikke på de samme ikonene til høyre for de gitte tekstboksene. Visningsnavn er det som vises i nedtrekkslisten, verdi er det som lagres. Nå er kodelisten koblet til skjemaet og kan testes i forhåndsvisning. Hvis man ved forhåndsvisning for en advarsel om at man kobler til ekstern server, velger man ok, ja eller tilsvarende. 49

50 15 Administrators oppgaver I TUL er langt fra alle administratorer, og det anbefales kun at en eller to personer fra hver tjenesteeier har administratorrettigheter. Disse er kalt tjenesteeieradministrator. I tillegg vil det være en eller to såkalte ASF-administrator. Disse er da administratorer for hele TUL, og ikke bare den enkelte tjenesteeier. Felles for disse to administratorgruppene er at de skal og kan utføre oppgaver som ikke er tiltenkt den enkelte bruker. Dette være seg å legge inn nye prosessflytmaler, opprette brukere eller angi rettigheter i TUL. Dette kapittelet vil ta for seg noen av scenarioene, men ikke hvor standardproduktene dekker hele funksjonaliteten som ikke er spesifikk for TUL Prosessflytmaler Som nevnt i kapittel 7.2.2, finnes to typer prosessflytmaler i TUL, en felles og en spesifikk for tjenesteeieren. ASF-administrator legger til nye felles maler, mens de enkelte tjenesteeieradministratorene legger til for den enkelte tjenesteier. Begge type maler er bygget på samme måte, men tjenesteeier spesifikk mal har utfylte verdier. Malene behøver kun å lastes opp i riktig dokumentbibliotek for å fungere. For felles maler legges de i dokumentbiblioteket Tomme prosessflytmaler på startsiden. Dette biblioteket er ikke synlig direkte, men aksesseres via Områdehandlinger. For tjensteeierspesifikke maler lastes de opp i dokumentbiblioteket Pre-definerte prosessflytmaler på den enkelte tjenesteeierarbeidsflaten. Ei heller dette biblioteket er synlig for alle, men må aksesseres via Områdehandlinger. Ved opplasting i bibliotekene er det viktig at dokumenttype settes til prosessflytmal og at prosessflytmal-id er unikt innad i dokumentbiblioteket. Malene er XML-filer som har en proprietær struktur som prosessflytsiden i TUL kan tolke. Kapitlene nedenfor forklarer de ulike seksjonene i XML filen XML seksjon - Malinformasjon Denne seksjonene inneholder generell informasjon om prosessflytmalen og vises i brukergrensesnittet på prosessflytsiden. <WorkflowId>12</WorkflowId> <Name> <Text lcid="1044">navn </Text> <Text lcid="1033">namn </Text> <Text lcid="2068">name of process flow</text> </Name> <Description> <Text lcid="1044">beskrivelse </Text> <Text lcid="1033">beskrivnong </Text> <Text lcid="2068">description of workflow</text> </Description> <WorkflowId> iidentifiserer hvilken arbeidsflyt som skal benyttes I SBL. P.t. skal den alltid være 1. ID en er ikke vist i brukergrensesnittet. <Name> er navnet på malen og skal finnes på minimum språkene bokmål (1044) og engelsk (1033). lcid="1044"> anger dette. Teksten i noden vises i brukergrensesnittet i nedtrekkslisten over tilgjengelige maler. <Description> inneholder malens beskrivelse på flere språk. Denne teksten vises under nedtrekkslisten etter at bruker har byttet mal i nedtrekkslisten. All informasjonen i denne seksjonen i XML-filen er statisk i brukergrensesnittet, og må endres direkte i XML-filen. 50

51 XML seksjon Steg Denne seksjonen inneholder informasjon om stegene, og det kan være mange steg-noder i denne seksjonen. Steg-noden beskriver steget mtp. oppførsel i SBL. Det vil også være et navn og en beskrivelse for hvert stef som vist I XML nedenfor: <Step activityid="1" activitytype="signing"> <Name> <Text lcid="1044">navn </Text> <Text lcid="1033">namn </Text> <Text lcid="2068">name of process flow</text> </Name> <Description> <Text lcid="1044">beskrivelse </Text> <Text lcid="1033">beskrivnong </Text> <Text lcid="2068">description of workflow</text> </Description> I hovedsak er det to attributter: ActivityId: Identifiserer ID en til steget. Steg-ID en skal være i sync mellom SBL og TUL, og to steg kan ikke ha same ID, og det må angis i stigende. ActivityType: Beskriver type steg. Skal enten være Formfilling, Signing eller SendIn. Hvert steg må også ha noder som omhandler sikkerhetsnivå og rettigheter. Disse deklarer at sikkerhetsnivå og rettighetsvelgeren skal vises for steget, og det er viktig at actiontype i AuthorizationRequirements er det samme activitytype som i stegbeskrivelsen, som vist under: <AuthenticationLevel propertytype="authenticationlevel"/> <AuthorizationRequirements propertytype="authorizationrule" actiontype="signing" /> XML seksjon Egenskaper Denne seksjonen i XML-filen kan forekomme ingen eller flere ganger pr steg, og gir muligheten for å definere ekstra parameter utover sikkerhetsparametere. Et typisk slikt parameter vil være signeringstekst. En egenskapseksjon består av flere deler, hvorav tre er påkrevd: Tabell 2 - XML egenskaper Del Påkrevd Beskrivelse Value Yes Kan brukes til å definere egenskapen defaultverdi, men er tom for felles maler Label Yes Vil være ledeteksten som vist for egenskapen I TUL. Språkstøttet. Description Yes Beskrivelsen som vist under ledeteksten for egenskapen. Språkstøttet. Validation No Valideringsregel for egenskapen. Vises hvis validering feiler. Språkstøttet. Benytter regulæruttrykk. Eksempel på XML en er vist under: <Property name="someintegerproperty" propertytype="xs:int"> <Value></Value> <Label> <Text lcid="1044">antall</text> <Text lcid="1033">count</text> <Text lcid="2068">antal</text> </Label> <Description> <Text lcid="1044">viser antall</text> <Text lcid="1033">shows the count</text> <Text lcid="2068">visar antal</text> 51

52 </Description> <Validation regexp="\d\d\d\d"> <Text lcid="1044">må være fire tall</text> <Text lcid="1033">must be four digits</text> <Text lcid="2068">må vere fire tal</text> </Validation> </Property> <Property noden er rotnode for parameteret og inneholder et navn som må være unik innad i malen og samsvare med SBL, og viktigst propertytype-attributten. Mulige verdier i PropertyType følger i de neste delkapitlene. Undernodene til rotnoden er angitt i tabellen over XML propertytype Tabellen under viser hvilke typer som kan benyttes. Tabell 3 - XML PropertyType Type UI-element Beskrivelse xs:choice RadioButton Beskrives under denne tabellen Nedtrekksliste xs:string TekstBox Fritekst iht evt validering xs:date Datovelger Dato xs:integer TekstBox Kun numeriske verdier iht evt validering xs:boolean Sjekkboks Checked, Unchecked, True, False, 1, 0 Xs:choice benyttes for ferdigdefinerte valg i prosessmalen, og krever derfor litt mer informasjon enn de andre typene. Da verdiene er språkstøttet, må det være en tekst for hvert språk. Hvis antall valg overskrider tre, vil det bli presentert en nedtrekksliste istedenfor radioknapper. Et eksempel er gjengitt under: <Property name="choosefruit" propertytype="xs:choice"> <Choice value="apple"> <Text lcid="1044">eple</text> <Text lcid="1033">apple</text> <Text lcid="2068">eple</text> </Choice> <Choice value="orange"> <Text lcid="1044">appelsin</text> <Text lcid="1033">orange</text> <Text lcid="2068">appelsin</text> </Choice> <Choice value ="Banana"> <Text lcid="1044">banan</text> <Text lcid="1033">banana</text> <Text lcid="2068">banan</text> </Choice> <Value></Value> <Label> <Text lcid="1044">velg frukt</text> <Text lcid="1033">choose fruit</text> <Text lcid="2068">velg frukt</text> </Label> <Description> <Text lcid="1044">du kan velge en av fruktene</text> <Text lcid="1033">you can choose only one fruit</text> <Text lcid="2068">vel berre ein frukt</text> </Description> </Property> 52

53 Tjenesteeiers maler Tjenesteeiers maler har mulighet til å være helt eller delvis preutfylte. Dvs. at et sett med rettigheter autoimatisk kan settes pr. steg. Det vil også si at sikkerhetsnivå og andre egenskaper kan preutfylles. Sikkerhetsnivå og rettigheter angis ved å legge de i XML-nodene i malen: <AuthenticationLevel propertytype="authenticationlevel">1<authenticationlevel/> <AuthorizationRequirements propertytype="authorizationrule" actiontype="signing"> ALLEA-SIGNE<AuthorizationRequirements/> Signeringstekst og andre egenskaper. <Property name="signingtext1" propertytype="xs:string"> <Value>Dette er min signeringstekst</value> <Property name="choosefruit" propertytype="xs:choice"> <Choice value="apple"> <Text lcid="1044">eple</text> <Text lcid="1033">apple</text> <Text lcid="2068">eple</text> </Choice> <Choice value="orange"> <Text lcid="1044">appelsin</text> <Text lcid="1033">orange</text> <Text lcid="2068">appelsin</text> </Choice> <Value>Orange</Value> 53

54 15.2 Administrasjon av brukere, grupper og rettigheter Beskrivelse av hvordan man administrerer brukere, grupper og rettigheter finnes i Vedlegg D: Veiledning i brukeradministrasjon. 54

55 15.3 Lage ny tjenesteeier En etat i TUL kalles også en tjenesteeier, og fungerer som en samling for alle etatens tjenester og utgaver Forberedelser For å opprette en ny tjenesteeier i TUL må først noen praktiske ting være ordnet av driftsleverandør: Åpning av brannmur for å slippe inn nye tjenesteutviklere Tilgang til Citrix for the den nye etatens brukere Tjenesteeieren må være opprettet i Sluttbrukerløsningene som er knyttet til TUL. Tjenesteeierkodene må stemme overens. Det normale vil være å gi etaten en tre/fire bokstavers forkortelse som identifikator. F.eks. vil Skatteetaten være SKD, Statistisk Sentralbyrå være SSB etc. Denne identifikatoren benyttes i adressen (URL) til tjenesteeiers arbeidsflate Active directory Det første som må gjøres er å opprette kataloger (Organization unit) og grupper i Active Directory. Disse vil være tjenesteeierspesifikke og skal følge samme hierarki som for BRG: Tabell 4 - Active directory Navn Medlem av gruppe Medlemmer Plassering Service Owner XXX Files Altinn/Service Owner XXX and folders Service Owner XXX SharePoint Administrators Service Owner XXX Users Service Owner XXX Code List editors Service Owner XXX Group administrators Service Owner XXX Password administrators Service Owner XXX User administrators All Service Owner Administrators All Service Owner Users Service Owner Code List editors AD Snap-In Access AD Snap-In Access AD Snap-In Access Brukere som skal være tj.eier administrator Alle etatens tjenesteutviklere Altinn/Service Owner XXX Altinn/Service Owner XXX Alle som skal ha tilgang til å vedlikeholde kodelister Operations/Administrative Users and global groups Alle som skal vedlikeholde Operations/Administrative brukere for etaten Users and global groups Alle som skal vedlikeholde Operations/Administrative brukere for etaten Users and global groups Alle som skal vedlikeholde Operations/Administrative brukere for etaten Users and global groups (XXX er den nye etatens kode) Tjenesteeierverktøy Nå benyttes applikasjonen Service Owner Creation Application for å opprette tjenesteeierarbeidsflaten i TUL, som vist under. 55 Figur 37 - Tjenesteierverktøy

56 Legg inn relevant data og klikk på Lag tjenesteeier.tjenesteeieren opprettes og den nye tjenesteeierarbeidsflaten vises. Hvis arbeidsflaten ikke inneholder veiledningskomponent og tjenesteliste, må disse aktiveres. Dette gjøres ved å klikke på Områdehandlinger. Figur 38 - Områdehandlinger På siden som kommer opp velger man Funksjoner for områdesamling, som vist under: Man får nå en liste hvor alle Altinnspesifikke elementer skal aktiveres. Figur 39 - Funksjoner i områdesamling Figur 40 - Områdefunksjoner Når disse er aktivert vil alle elementer på arbeidsflaten være tilgjengelig. Nå gjenstår det å gi de riktige grupper og brukere tilgang til den nye arbeidsflaten. Alle nye tjenester og utgaver vil arve disse tilgangene. 56

57 Gå til den nylig opprette tjenesteierarbeidsflaten og velg Områdehandlinger. Velg så Administrator for områdesamling. Legg til brukeren(e) hos etaten som er tjenesteieradministrator. Gå så til Personer og grupper. Her må du opprette tre grupper: Tabell 5 - Personer og grupper Gruppenavn Rettighet XXX site members Bidra XXX site owners Full kontroll XXX site visitors Lese Det er ikke påkrevd at gruppene skal ha navnene angitt i tabellen over, men det er å anbefale. Dette er SharePointgrupper som man knytter til Active Directory gruppene som følger: Tabell 6 - Personer og grupper Gruppenavn AD gruppe XXX site members Alttulad\Service owner SKD users XXX site owners Alttulad\ASF SharePoint Administrators XXX site visitors Alttulad\All service owner users Nå er tjenesteeieren/etaten klar til bruk. 57

58 16 Begrepsliste Under følger en liste over mye brukte begreper i tjenesteutviklingsløsningen TUL: Datakilde o En samling felt og grupper som definerer og lagrer dataene for et InfoPathskjema. Kontroller i skjemaet er bundet til feltene og gruppene i datakilden. ELMER o ELMER er vedtatt som retningslinjer for brukergrensesnitt i offentlige skjemaer på Internett Hovedskjema o Hovedspråk o InfoPath o Kodeliste o Kortnavn o En innsendingstjeneste vil Alltid ha ett skjema som er hovedskjema. Det kan knyttes null, ett eller flere underskjemaer til et hovedskjema. En tjeneste vil alltid ha ett språk som hovedspråk. Dette angis når tjenesten opprettes og kan ikke endres i etterkant. Tjenesten kan oversettes til ett eller flere andre språk i tillegg til hovedspråket. En tjeneste kan ikke bli migrert til noe miljø uten at hovedspråket er komplett. InfoPath er et verktøy fra Microsoft som benyttes til å utvikle skjemaer. I TUL må tjenesteutviklere utvikle skjemaer i InfoPath og koble disse gjennom å laste opp InfoPath-dokumentet til TUL for å kunne spesifisere innholdet i skjemaet og bruken av det ytterligere. En kodeliste er en liste med faste verdier som for eksempel postnummer og poststed. Kodelisten brukes typisk i nedtrekkslister i skjema i sluttbrukerløsningen. En kodeliste kan brukes på tvers av tjenesteeiere og tjenester, eller den kan spesiallages for enkelte tjenesteeiere eller tjenester. Kodelister vil vedlikeholdes utenfor den enkelte tjeneste og må migreres over til sluttbrukerløsningen på linje med tjenestene. Både tjenester og utgaver har kortnavn. Kortnavnene både for tjeneste og for utgave benyttes kun i TUL for å angi navn på henholdsvis tjenestens og utgavens arbeidsflate i TUL. Migrere o Pakke sammen alle data i en tjenesteutgave, versjonere, og legge det over til et sluttbrukermiljø. Presentasjonsfelt o Felter som beskriver utfylt instans av en utgave Preutfylling o Felter fylles ut av SBL ved åpning av utgave Prosessflyt o Automatisert navigasjon gjennom en spesifikk rekkefølge av handlinger eller oppgaver relatert til en forretningsprosess. Sideegenskaper o Egenskaper for en visning (side) fra InfoPath-skjema. Skjemasett o Samling av skjemaer og vedlegg som signeres og sendes inn i én prosess. Der innsendingsrutinen forutsetter at ett bestemt skjema alltid er med i sendingen, er dette et hovedskjema og resten er underskjema. Sporvalg o Tjeneste o Definerer en samling av sider som bare presenteres for en bestemt avgivergruppe eller avgivere i en bestemt situasjon. Grunnlaget for sporvalg kan være basert på tidligere svar i samme skjema eller på allerede kjente opplysninger hos oppgaveinnhenteren. Sporene kan delvis, men ikke utelukkende, være satt sammen av identiske sider. En tjeneste kan ha en eller flere tjenesteutgaver, for eksempel en utgave per år. Det er tjenesteutgaven som migreres over til sluttbrukerløsningen. Det finnes ulike tjenestetyper, for eksempel innsendingstjeneste og 58

59 Tjenesteeier o meldingstjeneste. Eksempel på tjeneste: Selvangivelse for næringsdrivende mv (RF-1030). En tjenesteeier er en etat som utvikler og eier tjenester som tilgjengeliggjøres gjennom Altinn. Eksempel på tjenesteeiere: Skattedirektoratet, NAV, Mattilsynet, Husbanken. Tjenesteparametre o Tjenesteparametre er egenskaper ved tjenesten som settes på tjenestenivå. Underskjema o Et underskjema er et skjema som benyttes som tillegg til et hovedskjema for en tjeneste. Et skjema kan eksistere kun som underskjema, eller det kan eksistere som hovedskjema for én tjeneste men benyttes som underskjema for én eller flere andre tjenester (da må det i så fall være forskjellige utgaver eller forskjellige tjenester som bruker samme xsn-fil). Et underskjema kan knyttes til ett eller flere hovedskjema. Utgave o Også kalt tjenesteutgave. En tjeneste kan ha en eller flere utgaver, for eksempel en utgave per år. Det er tjenesteutgaven som migreres over til sluttbrukerløsningen. Eksempel på utgave: Søknad om utsatt frist for levering av selvangivelsen for næringsdrivende for inntektsåret 2008 (RF- 1114). Utgaveparametre o Utgaveparametre er egenskaper ved utgaven som settes på utgavenivå. Versjon o Hver gang en tjenesteutgave blir migrert til et miljø blir det opprettet en ny versjon av tjenesteutgaven. XSD o XSD er en forkortelse for XML Schema Definition. XSD er en filtype som brukes til å implementere et InfoPath-skjema. Også kalt datakilde. 59

60 17 Referanser Online hjelp for SharePoint: Online hjelp for InfoPath: ELMER: 60

61 18 Vedlegg Videre følger de enkelte vedleggene. Merk at skjermdumper fra SBL vil være illustrasjoner og ikke nødvendigvis oppdaterte. De er tiltenkt som illustrasjoner Vedlegg A: Veiledning i skjemautvikling i InfoPath Dette vedlegget tar for seg hvordan man stegvis utvikler et Altinn-skjema / innsendingstjeneste i InfoPath. For informasjon om mer generell InfoPath funksjonalitet, henvises til standard dokumentasjon for Microsoft InfoPath. Denne kan bl.a. finnes ved hjelp av hjelp-funksjonen (trykk F1) i InfoPath eller på Det forventes at den som skal bruke dette dokumentet har bakgrunn fra bruk av dataverktøy og helst også fra programmering. Kjennskap til hva en XSD er, og hvor den kommer fra er en betingelse for å utvikle skjemaer. Videre for de som skal programmere, forlanges kompetanse i bruk av Visual Studio. Kunnskap om skjemautvikling fra Altinn I anses som en fordel, men ikke nødvendighet Før oppstart av InfoPath I eksemplet beskrevet i dette dokumentet, skal det lages utvalgte deler av skjema RF Først bør det lages en egen katalog for lagring av filer knyttet til utvikling av skjemaet. Det skal her benyttes TUL-share. P.t. er det \\alt-tul-db-c02\tulshare\infopath\etater og hvilken tjenesteeier man utvikler for. Det bør lages én katalog pr. utgave. På denne katalogen bør også datakilde (XSD) lagres. XSD kan hentes fra OR (Brønnøysund oppgaveregister) før et skjema kan utvikles i InfoPath (inneholder definisjon av hvilke felt som skal være med i skjema). Det er også mulig å lage XSD selv, eller lage XSD på bakgrunn av InfoPato-skjemaet i InfoPath. Siden InfoPath ikke leser den originale XSD korrekt, må denne først kompileres vha applikasjonen RequiredFields.exe. Dette må kjøres fra et DOS command vindu, og vil ha original XSD som input parameter og fikset XSD som output. Lokasjonen til applikasjonen er ikke tilgjengelig p.t., men det er lurt å ha programmet i samme katalog som XSD ene du skal kompileres.det vil være opp til ASF-administrator og driftsleverandør å bestemme lokasjonen for applikasjonen. For skjemaer som skal benytte felter fra altinn-namespace så må applikasjonen kjøres før altinn feltene legges inn i den originale XSD en. Syntaks for programmet: RequiredFields.exe <input-fil> <output-field> [p] Eksempel for RF-1189 skjema (forusatt at RequiredFields.exe ligger på katalog../forms): Start program cmd.exe og kjør RequiredFields-programmet fra katalogen som ble opprettet for skjema: Cd../InfoPath/RF-1189 RequiredFields.exe melding xsd melding _rettet.xsd NB! InfoPath skal videre benytte outputfilen melding _rettet.xsd. 61

62 Altinn-definerte inputfelt Ut av boksen lar ikke InfoPath deg benytte egendefinerte inputfelter i en repeterende gruppe. Dette er ønsket løst uten at hjelpefeltene må legges til i skjemaets opprinnelige datakilde, i tidligere løsning omtalt som OR-spesifikasjon. For å løse dette problemet må man benytte et Altinn-definert input felt. Et altinn-definert felt er et felt som er definert i en egen datakilde, hvor datakilden en er importert/referert til å hoveddatakilden. Dette gjøres ved å først lage datakilden hvor hjelpefeltene skal ligge. Disse vil da ligge i et eget navnerom (namespace). Dette navnerommet må begynne med altinn i alle tilfeller. Videre følger et eksempel på bruk av Altinn-definerte inputfelt i RF RF-1037 inneholder en tabell for arbeidsgiveravgift hvor bruker skal velge en komunne fra en nedtrekksliste, hvorpå arbeidsgiveravgiftsone og komunnenummer skal vises automatisk. For å få dette til, må man velge å legge arbeidsgiveravgiftsone og en radindeks (som ikke vises i skjema) i altinn-navnerommet. Dermed må man definere disse to feltene i en egen datakilde, altinn_namespace.xsd: <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" xmlns:or=" xmlns=" xmlns:altinn=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="altinnfield_kommunenavn_grp_4953" type="xs:string"/> <xs:element name="altinnfield_sone_grp_4953" type="xs:string"/> <xs:element name="altinnfield_rowindex_grp_4953" type="xs:string"/> </xs:schema> Som man ser over er det angitt tre felter i altinn-datakilden. Nå må man i hovedkilden angi at denne datakilden skal kunne benyttes. Dette gjøres ved å inkludere en import-statement i toppen av datakilden: <?xml version="1.0" encoding="utf-8" standalone="no"?> <xs:schema attributeformdefault="unqualified" elementformdefault="qualified" xmlns:brreg=" xmlns:xs=" xmlns:altinn=" <xs:import namespace=" schemalocation="altinn_namespace.xsd"/> Merk at begge datakildene må ligge i samme katalog slik at InfoPath finner de. Videre må man så i hoveddatakilden legge til de feltene man vil benytte fra altinnnavnerommet: <xs:element name="tabellarbeidsgiveravgift-grp-4953"> <xs:complextype> <xs:sequence> <xs:element minoccurs="0" ref="avgiftsbetalerorganisasjonsnummer-datadef-27605"/> <xs:element minoccurs="0" ref="kommunenummer-datadef-5950"/> <xs:element minoccurs="0" ref="arbeidsgiveravgiftgrunnlagspesifisert-datadef-27607"/> <xs:element minoccurs="0" ref="refusjongrunnlagspesifisert-datadef-27608"/> <xs:element minoccurs="0" ref="pensjonpremietilskuddspesifisert-datadef-27611"/> <xs:element minoccurs="0" ref="altinn:altinnfield_kommunenavn_grp_4953"/> <xs:element minoccurs="0" ref="altinn:altinnfield_sone_grp_4953"/> <xs:element minoccurs="0" ref="altinn:altinnfield_rowindex_grp_4953"/> </xs:sequence> <xs:attribute fixed="4953" name="gruppeid" type="xs:positiveinteger" use="required"/> </xs:complextype> </xs:element> Som vist over er det lagt til tre altinn-definerte felter i gruppen TabellArbeidsgiveravgift-grp Disse feltene vil da vises i InfoPath etter at datakilden (XSD) er importert. Se kapittel Dermed kan de nye feltene fritt benyttes hvor som helst i skjema, og i motsetning til vanlig egendefinerte hjelpefelter som man oppretter direkte i InfoPath (typisk my:felter), kan disse feltene også benyttes i repeterende grupper. Merk at altinn-definerte felter ikke sendes med til tjenesteier. I og med at dette er vanlig tekst, kan f.eks. Notepad benyttes som editeringsverktøy. 62

63 Oppstart av InfoPath, Import av XSD-fil og generell oppsett av skjema og layout Start InfoPath, og velg kommando Utform en skjemamal fra Fil-menyen. Følgende skjermbildet vil vises. Figur 41 - InfoPath, utform skjemamal Velg ikonet XML eller XML-skjema. Kryss av Aktiver bare funksjoner som er kompatible med webleser og velg deretter OK. I neste skjermbilde angis navnet på datakilden (XSD) som skal benyttes, og velg å ikke benytte flere datakilder. Fullfør. Husk å benytte den rettede datakilden hvis den kommer fra brreg. Skjemaet er nå klart til bruk. Figur 42 - Oversikt over alle grupper/felter som finnes i datakilden Som vist i figuren over, er det på høyre side i InfoPath en oversikt over alle grupper/felter som finnes i datakilden. På venstre side er det et tomt område, hvor skjema skal bygges. Hit skal sidemal fra tjenesteier kopieres til på følgende vis: 63

64 I Windows Utforsker, høyreklikk sidemal_skd-pmh xsn (gjelder for SKD, for andre etater kan man bruke andre maler med andre navn) og velg Design fra meny. Klikk OK på evt feilmelding som dukker opp. Kopier hele sidemal over i i det nye skjema (skjermbilde ovenfor) vha standard kopier/lim inn (eksempel Ctrl-A, Ctrl-C og Ctrl-V (i nytt skjema)): En sidemal lages som et normalt InfoPath-skjema uten datakilde. For at skjemaet ikke skal få horisontal scroll i SBL, er det viktig at bredden ikke overstiger 630px. Denne bredden tar da høyde for bredden på en evt. vertikal scrollbar, og det anbefales at det tas høyde for dette uansett om siden forventer vertikal scroll eller ikke. Det anbefales at sidemalen lagres på arbeidsflate for tjenesteeier. Figur 43 - Sidemal Tilpass bilde til mal for det aktuelle skjema ved å fjerne felter og ledetekster i sidemal og sette riktig headertekst. Marker felter og ledetekst som angitt i ramme over, samt tekstene Skjematittel og Framskutt ledetekst, og trykk Slett. Legg inn ny headertekst for skjemaet. Alle tekster skal defineres i Uttrykksbokser (Expression box). Velges fra Flere kontroller under meny Sett inn-menyen, eller fra høyre-panelet i InfoPath under kontroller: Figur 44 - Infopath, uttrykksboks Legg inn tittelen på utgaven i hermeteng ( RF-1189 Årsoppgjør for utleie mv. fast eiendom 2008 ). Se kapittel Fargekoder Altinn for definering av riktig fargekode, font og størrelse for teksten. Dermed har vi en mal for kopiering til øvrige sider i skjemaet ved og opprette sider og bruker utklippstavlefunksjonalitet. 64

65 Definisjon av sider i InfoPath skjema (Views) Endre Utformingsoppgaver-fanen til Visninger. Visning 1 vises som default. Visning betegner side i skjema. Velg Legg til ny visning og skriv navn. Man bør definere beskrivende sidenavn for hver visning/side i InfoPath. Dette er ikke nødvendig, ettersom sidensidenavn og rekkefølge må oppgis i TUL. Men det anbefales å gi navn med løpenummeret slik at sidene kan sees i riktig rekkefølge i InfoPath under utvikling, men det er altså ingen spesielle krav. Fra Visning 1 kopieres det oppsettet man lagde (Ctrl A, Ctrl C) og limes inn på alle sider som skal finnes i skjema Innlegging av felt fra Datakilde (fra XSD) Velg side 1 (Visning 1) og bytt til Datakilde. Legg til Uttrykksbokser for tekstene Innledning og Avgiver som vist under. Husk å sjekke fonter, farger etc. i henhold til sidemal. Velg gruppe som skal være på denne siden, ved å markere Avgiver-grp-231 under GenerellInformasjon-grp-959, som vist i eksemplet under. Dra den fra Datakilde til punktet under overskriftslinje i skjema og velg Kontroller i oppsettstabell fra popup meny (merk at man ikke kan velge hele siden dvs gruppe med undergrupper, man må velge gruppe som kun inneholder orid er. Er det flere slike grupper på side, må alle dras inn på siden enkeltvis). Det er også mulig å dra inn enkeltfelter ved å ikke markere hele gruppen, men markere enkeltfelter i datakilden. 65 Figur 45 - Innlegging av felt fra datakilde Linje med Gruppeid skal ikke vises, og fjernes ved å markere linjen, høyreklikke og velge Slett rader. Erstatt alle ledetekster i layouttabellen med Uttrykksbokser og tekster som vist i eksempel under, i henhold til standard font/farge. Vær nøye med riktig ledetekst til riktig felt. For å skape litt luft i venstre kant av layout tabellen, anbefales det å legge inn en smal kolonne til venstre. Dette kan gjøres ved markere tabellen, høyreklikke, og velge Sett inn -> Kolonne til venstre fra popup. Denne vil være del av tabellen og det er tabellen som må få riktig avstand til venstre marg. Sett bakgrunnsfarge på grupperammen (layout tabellen), ved å markere gruppen, høyreklikk og velge Kantlinjer og skygger. Velg flipp Skygger og sett riktig farge (ref avsnitt Fargekoder Altinn).

66 Feltene for fødselsnummer og organisasjonsnummer skal være skrivebeskyttet og ha bakgrunnsfarge for skrivebeskyttet felt. Marker felt og velg bakgrunnsfarge fra verktøylinja. For å skrivebeskytte felt, dobbeltklikk på feltet, og Egenskaper for tekstboks vises. Velg flipp Visning og marker Skrivebeskyttet: Figur 46 - InfoPath, tekstboks Sett riktig størrelse på feltet i forhold til antall tegn, ved å velge flipp Størrelse, velg riktig enhet (em) og bredde, som vist i eksempel for postnummer: Figur 47 - Infopath, tekstboks, størrelse Hvis det ikke er et vanlig tekstfelt man ønsker, men en annen type kontroll (radioknapp, nedtrekksliste osv) skal man høyreklikke på feltet Endre til -> og velge ønsket kontroll type: Ved å høyreklikke på feltet og velge egenskaper kan man velge forskjellige innstillinger som: skrivebeskyttet, max antall tegn i feltet, justering på innholdet, formatet på numerisk felt osv. For å kunne tabulere i riktig rekkefølge, må man velge avanserte egenskaper og sette ønsket tabulatorindeks. Om feltet ikke skal være tabulerbart så skal tabulatorindeks settes til

67 Kalkyler, eksempel på repeterende gruppe og radioknapper Siden som nå er laget inneholder ikke kalkyle(r). Det er derfor behov for å bygge en side til, for eksempel side 3 i RF Vha. Legg til visning funksjonen nevnt ovenfor, vil vi kalle siden for View 3. Denne inneholder også en repeterende gruppe (enten tabell for innlegging av flere rader eller seksjon som kan også legges inn flere ganger etter hverandre), knapp (ikon) for hjelpetekst, samt kontroller for radioknapp, nedtrekksliste og datovalg. Figur 48 - Skjema RF Visning 3 I utgangspunktet benyttes samme fremgangsmåte som for første siden i skjemaet. Ledetekster skal gis inn i hver sin uttrykksboks og feltene som skal benyttes finnes i datakilde under hovedgruppen InntekterUtleieverdi-grp-960. Legg inn den repeterende gruppen for utleieinntekter ved å markere Utleie-grp-4939 i datakilden, og dra den inn på skjema. Du får nå 3 valg fra popupmeny, velg Repeating table og følgende utgangspunkt for videre redigering vil vises: Hvis repeterende gruppe er veldig stor med lange overskrifter kan det være lurt å velge Repeating section, da vil feltene med tilhørende ledetekster bli plassert under hverandre. Slett kolonne for Gruppeid, erstatt hver enkelt standard ledetekst med uttryksboks og ledetekst som vist i det ferdige side eksempel. Husk også å tilpasse bredden slik at den passer med mal-bredden for skjema. Fortsett med gruppe for kårbolig (Kar-grp-4942), som legges inn med valg kontroller i layouttabell. For de tre siste feltene i denne gruppen, må presentasjon endres til 67

68 radioknapper. Høyreklikk på feltene, i popup meny velges Endre til og deretter Alternativknapp. For hver av radioknappene vil det vises en ledetekst på høyre side. Disse må erstattes av de vanlige uttrykksboksene, en for hver tekst. Legg merke til at teksten som skal vises ikke alltid er helt identisk med den genererte fra datakilden (xsd). Til sist legges feltene for post 1.3 til post 1.5 inn. Disse feltene ligger i datakilden rett under hovedgruppen InntekterUtleieverdi-grp-960, derfor er det denne som skal markeres som vist under: Figur 49. RF-1189 visning 3 Før kalkylearbeidet kan starte, må feltet for post 1.5 Samlet bruttoinntekt settes til skrivebeskyttet, og layouttabellen tilpasses med blanke kolonner for luft på venstre side, samt plass til å kunne sette inn hjelpeikon senere, som vist i det ferdige sideeksempelet, figur 48. Det skal nå legges inn en kalkyle i post 1.5, som skal summere Beløp fra tabellen i post 1.1, samt postene 1.2, 1.3 og 1.4. Kalkylen skal dermed inneholde følgende elementer og orid er: :22033 = sum(:22014) + : : :22026 Eksempel skjermbildene for denne seansen vises samlet under teksten. Høyreklikke på orid :22033 (post 1.5 Samlet bruttoinntekt ), velge Egenskaper for tekstboks (1) og flipp Data. Her vises Verdi -feltet hvor kalkylen skal legges inn. Klikk videre på knappen fx til venstre for Verdi -feltet for å komme inn Sett inn formel vinduet (2). Her kan en skrive inn kalkylen. Skriv inn funksjonsnavn og operatorer og velg felt som skal inngå vha. knappen Sett inn fellt eller gruppe (3). Funksjonsnavn med syntaks kan også velges vha. knappen Sett inn funksjon. Kalkylen skal se slik ut når den er ferdig, og inneholder en funksjon sum() som summerer alle rader med angitt felt fra den repeterende gruppen i post 1.1: sum(utleieinntektspesifiserteiendom-datadef-22014) + VedlikeholdskostnaderMvLeietakere-datadef InntekterAndre-datadef sum(utleieinntektspesifiserteiendom-datadef-22014) + EgenleieKarInntekt-datadef

69 Skjermbilder henvist til i beskrivelsen over: Figur 50 - Sett inn formel Merk at summeringsfeltet får verdi 0 hvis alle feltene som inngår i kalkyle er tomme. Om dette ikke er ønskelig kan det løses med Regler funksjonen: Høyreklikk på feltet for post 1.5 Samlet bruttoinntekt og velg Regler Her kan det legges inn regler tilknyttet feltet ved å trykke på Legg til -knappen Figur 51 - Regler Velg så Angi betingelse for å sette opp kriteriene: Figur 52 - Regler - Legg til Figur 53 - Angi betingelse Det første kriteriet er at selve summeringsfeltet skal ha verdi 0. Dette må settes eksplisitt som standardverdi i feltet man sjekker på. Velg deretter de feltene som inngår i kalkylen. For disse velges Er tomt. Alle felt i kalkylen må være med, ellers risikeres at summeringsfeltet blir blanket ut selv om deler av kalkylen har verdi. Trykk OK for å returnere til forige vindu. Til sist må Legg til handlig -knappen benyttes fra Regler -vinduet. Velg Angi verdien for et felt som aksjon og så feltet som skal settes. Felt vises som et punktum, siden der dette feltet det ble klikket på ved inngang til regeldefinisjonen. 69

70 Figur 54 - Handling Merk at man ikke får skrevet mer enn fem if-setninger i betingelsene. Hvis man vil implementere det for kalkyler med flere felter så må man bruke uttrykksbokser. Dette gjøres ved å mellomlagre deler på den måten at man tar f.eks. to if-setninger og lagrer resultatet av denne i en uttrykksboks og benytter da den aggregerte verdien inn i den betingelsen det ikke var plass. Kalkyler i repeterende gruppe legges inn på samme måte. Hvis noen repeterende felter skal summeres opp i feltet som er utenfor repeterende gruppe så skal man bruke funksjon SUM og sette inn feltet som skal summeres. Flere tips: Man har tilgang til alle variabler fra alle sider Det er ikke mulig å få kopiert en kalkyle fra et felt til et annet, kalkyle må opprettes manuelt på hvert summerings felt. Derimot er det mulig å kopiere XPath og formler fra andre felter. For mer informasjon om xpath, se Microsofts dokumentasjon. For å skrive kompliserte kalkyler i C#, kan man høyreklikke på et felt og velge Programming- >Changed event For å telle antall ikke-tomme felt skal man bruke formel count(felt_xxx[text()!= ""]) For å sette in formel med betingelse bruk (field1 field2)[condition]. For eksempel se Hvis man skal summere det totale, f.eks pris*antall som repeteres bruk: sum(eval(grp-3455; " datadef * datadef-23949")) Ref. I noen tilfeller vil det ikke være mulig å sette inn feltnavn ved å peke på feltene, og man får gjerne en feilmelding når en prøver på det. I så fall kan man kopiere XPath (for å få tak i XPath så skal man finne feltet i datakilden, høyreklikke og velge kopier XPath) og fjerne stien slik at det kun feltenavn står igjen. For å summere det totale som ovenfor (pris*antall som repeteres bruk) men kun ved spesielle betingelser bruker man formel under. Eksempel gjelder summering kun de tilfellene der valget i en nedtrekksliste er lik S ) sum(eval(nyutstedteaksjeromfordeling-grp- 3455[AksjerNyutstedteFondsemisjonMvType-datadef-17679!= "S"]; "AksjerNyutstedteFondsemisjonMvAntall-datadef * AksjerNyutstedteFondsemisjonMvPalydende-datadef-23949")) Valideringer Valideringen forhindrer bruker fra å levere feilaktige data eller f.eks data som ikke kan leveres sammen eller ikke stemmer med hverandre. Valideringen kjøres uansett om feltet er tomt (forskjell fra Altinn I løsning). For å legge inn valideringer i RF-1189, er det behov for å legge inn nok en side. Med bakgrunn i tidligere avsnitt, kan denne nå lages som vist under, med unntak av hjelpeikonet. På denne siden inngår layout tabellene Nettoinntekt-grp-4945 og "OmfatterKostnadeneNoeAvFolgende-grp-2330" som ligger under gruppe "Kontrollsporsmalgrp-239": 70

71 Figur 55 - SKjema RF1189. Visning 6 For å legge inn validering på et felt skal man høyreklikke på dette, velge Datavalidering- >Legg til og legge inn betingelser og feilmelding. Legg inn følgende validering i RF-1189 for post 3.1 og radioknapp med orid :7911: Tabell 7 - Validering i RF-1189 Skjemaer Kontroll Formel Utslagstekst i Altinn involvert RF-1189 Må svare på kontrollspørsmål om skatter utslag_hvis ikke felt_utfylt(:7911/*rf Ja/Nei*/); NOB:Vennligst svar på kontrollspørsmålet om skatter i post 3.1. NON:Ver gild og svar på kontrollspørsmålet om skattar i post 3.1. Dette betyr at det er obligatorisk å velge enten Ja eller Nei ved hjelp av radioknappene; feltet kan ikke være ubesvart. Høyreklikk radioknappen i post 3.1 og velg kommando Datavalidering. Velg her knappen Legg til for å legge til til en validering: 71 Figur 56 - Datavalidering Under Hvis betingelsen oppfylles: velges UtgifterSkattFormueInntekt-datadef-7911 (radioknapp-feltet) og med operand er ikke lik og verdi Ja. Velg og og legg til samme operand for samme felt, men denne gang med verdi Nei. Med andre ord sjekker vi på om

72 feltet har enten verdi Ja eller Nei. I skjermtips kan for eksempel legges inn Post 3.1 mens feilmelding på bokmål skal være Vennligst svar på kontrollspørsmålet om skatter i post Trykk OK for å returnere til datavalideringsvinduet, og OK for å returnere til skjermbildet. Figur 57 - Datavalidering Tilsvarende valideringer skal legges inn på de to øvrige radioknappfeltene for post 3.2 og 3.3. Sjekk detaljert design for nærmere spesifikasjoner. Flere tips: Merk at man ikke får lagt inn mer enn 5 betingelser samt at det ikke er mulig å sette parentes mellom OG er og ELLER er For å skrive kompliserte valideringer i C#, kan man høyreklikke på et felt og velge Programming->Validating event. I så fall må Visual Studio være installert. I InfoPath må en huske på å velge aktuell mappe fra skjemaet i Verktøy->Alternativer for skjema->programmering->project location for Visual Basic and C# code Ved store valideringer, må en benytte expressions. Avansert eksempel på validering For de mer viderekomne, gis her et litt mer avansert eksempel på store valideringer med bruk av expression. Det anbefales å sjekke eksemplet i RF Implementering av følgende betingete validering i RF-1086: BOH_10: , 17678, 17679, 17680, HVIS (orid eller orid eller orid eller orid eller orid er blanke) SÅ utslag. I post 10 mangler ett eller flere av de følgende feltene utfylling: Antall nyutstedte aksjer, Antall aksjer etter, Hendelsestype, Tidspunkt eller Pålydende per utstedt aksje. Dvs. hvis noen av disse 5 felter av fylt ut skal alle være fylt ut. Nedenfor følger en anbefaling på hvordan dette kan implementeres: Opprette hjelpefelt BOH_10_1 med default value 1. Kopiere Xpath til alle de 5 feltene (med å høyreklikke på feltene i Data source og velge Kopier Xpath ). Opprette validering med 2 if-setninger, der det ene sjekker om noen av disse feltene er fylt ut og det andre skjekker om noen av feltene er blank da skal man få feilmelding, fordi enten alle skal være tomme eller alle skal være utfylt. For å skrive if-setningene, velger man expression og skriver følgene to linjer: Den første linjen/valideringen sjekker om noe er tomt: /Skjema/UtstedelseAvAksjerIfmFondsemisjonSplittMv-grp- 3454/NyutstedteAksjerOmfordeling-grp- 3455/AksjerNyutstedteFondsemisjonMvAntall-datadef /Skjema/UtstedelseAvAksjerIfmFondsemisjonSplittMv-grp- 3454/NyutstedteAksjerOmfordeling-grp- 3455/AksjerNyutstedteFondsemisjonMvAntallEtter-datadef /Skjema/UtstedelseAvAksjerIfmFondsemisjonSplittMv-grp- 3454/NyutstedteAksjerOmfordeling-grp- 72

73 3455/AksjerNyutstedteFondsemisjonMvType-datadef /Skjema/UtstedelseAvAksjerIfmFondsemisjonSplittMv-grp- 3454/NyutstedteAksjerOmfordeling-grp- 3455/AksjerNyutstedteFondsemisjonMvTidspunkt-datadef /Skjema/UtstedelseAvAksjerIfmFondsemisjonSplittMv-grp- 3454/NyutstedteAksjerOmfordeling-grp- 3455/AksjerNyutstedteFondsemisjonMvPalydende-datadef = "" Videre, følger her den andre som sjekker om noe er fylt ut: /Skjema/UtstedelseAvAksjerIfmFondsemisjonSplittMv-grp- 3454/NyutstedteAksjerOmfordeling-grp- 3455/AksjerNyutstedteFondsemisjonMvAntall-datadef /Skjema/UtstedelseAvAksjerIfmFondsemisjonSplittMv-grp- 3454/NyutstedteAksjerOmfordeling-grp- 3455/AksjerNyutstedteFondsemisjonMvAntallEtter-datadef /Skjema/UtstedelseAvAksjerIfmFondsemisjonSplittMv-grp- 3454/NyutstedteAksjerOmfordeling-grp- 3455/AksjerNyutstedteFondsemisjonMvType-datadef /Skjema/UtstedelseAvAksjerIfmFondsemisjonSplittMv-grp- 3454/NyutstedteAksjerOmfordeling-grp- 3455/AksjerNyutstedteFondsemisjonMvTidspunkt-datadef /Skjema/UtstedelseAvAksjerIfmFondsemisjonSplittMv-grp- 3454/NyutstedteAksjerOmfordeling-grp- 3455/AksjerNyutstedteFondsemisjonMvPalydende-datadef-23949!= "" På grunna av at InfoPath har relativt små vinduer som ikke gir god oversikt, anbefales det å skrive alt dette i et tekst-verktøy som for eksempel Notepad og lime inn i InfoPath etterpå. Om alt legges inn korrekt vil Datavalideringsvinduet få ut noe sånt: Eksempel på validering av gyldig verdi i et felt vha pattern Figur 58 - Datavalidering For å legge på sjekk av gyldig verdi, for eksempel for og epost, kan man i InfoPath matche verdien mot et pattern. Dette gjøres også vha Datavalideringskommandoen. Eksempel på setting av mønster for epost i skjema RF-1086: 73

74 Figur 59 - Eksempel på validering av gyldig verdi i et felt vha pattern I tillegg til de valideringene som legges inn av skjemautvikler så vil InfoPath/Forms Server utføre xsd valideringer, dsv restriksjoner som er lagt på feltene i xsd spesifikasjonen til skjemaet. Rekkefølgen på disse feilmeldingene styres av InfoPath/FormServer, og det er ikke mulig å endre denne rekkefølgen. Microsoft har valgt å gi xsd-valideringer (f.eks sjekk på lengde, maks/min verdi og regulære uttrykk) presidens foran valideringen som sier at feltet er påkrevd. Dette er årsaken til at meldinger som f.eks. Only spesific pattern allowed vises før Cannot be blank. Pattern validering Hvis man velger å benytte pattern validering, så vil man kunne se at regulæruttrykket vises i høyrekolonnen i SBL ved validering. For å komme rundt dette, må man gjøre følgende: 1. Legg inn et hjelpefelt istedenfor feltet som har pattern validering. Feltet som kommer fra datakilde skal da ikke dras inn i skjemaet. 2. Legg inn en egen pattern validering på hjelpefeltet med en egen feilmelding slik at denne vises istedenfor pattern valideringsmeldingen fra xsd en. 3. Overfør verdien til det egentlige feltet fra hjelpefeltet. 4. Hvis dette gjelder felter i en repeterende gruppe så må hjelpefeltet ligge i en altinn xsd, ellers samme prinsipp. Hvis denne metodikken benyttes vil man unngå at regulæruttrykkene vises i SBL Dynamikk Dynamikk går ut på at utseende/oppførsel til et felt i skjermbildet, er avhengig av en betingelse knyttet til informasjon i et annet felt. Utfra de sidene som nå er laget i skjema RF- 1189, kan det legges inn dynamikk for følgende spesifikasjon fra detaljert design: Tabell 8 - Dynamikk Feltnavn (Datadef/orid) Post i skjema Beskrivelse av dynamikk 74

75 7911/ Beløpsfelt skal gråes ut hvis svar er nei 7913/ Beløpsfelt skal gråes ut hvis svar er nei 7915/ Beløpsfelt skal gråes ut hvis svar er nei Dette er en vanlig form for dynamikk, som altså går ut på å disable et felt ved inntreff av en betingelse. Normalt ønskes det at både feltet og ledeteksten blir grået ut, og at det ikke er mulig å klikke inn i feltet. I tillegg skal feltet her blankes ut. Denne dynamikken skal inn på samme skjemaside som også vist i Figur 1189 View 6 i forrige avsnitt (Valideringer): Figur 60 - RF-1189 Som spesifikasjonen viser, gjelder dynamikken alle de 3 siste postene. Her nøyer vi oss med å legge den inn for Post 3.1, vha følgende framgangsmåte: Høyreklikke på feltet 7912 ( Ev. beløp ) og velge Betinget formattering. Først skal vi sette feltet vårt til Skrivebeskyttet. Trykk knappen Legg til for å legge inn betingelsen på samme vis som ved valideringer (opp til 5 linjer) som vist under: Figur 61 - Betinget formattering Det er her kun behov for en linje i betingelsen. I første nedtrekkslisteboksen velges radioknappfeltet UtgifterSkattFormueInntekt-datadef-7911, i neste er ikke lik og verdien i det siste skal være Nei. Til slutt klikkes det på skrivebeskyttet og OK. I dette tilfellet velger vi ikke at feltet skal skjules, noe som kan ellers kan være aktuelt. For de andre radioknappene i samme gruppe vil det være vice versa. Merk at feltet ikke blir tømt selv når det er skrivebeskyttet eller skjult. Derfor må verdien fjernes manuelt ved å opprette en regel (Rule) på det feltet som styrer dynamikken (radioknapp feltet 7911). Det er verdt å merke seg at reglene kjøres kun når feltene er blitt valgt og gitt en verdi. Regel opprettes ved å: 75

76 o Høyreklikke radioknapp feltet o Velge Regler. o Klikk på Legg til knappen for å legge til en ny regel. o Klikk Angi betingelse for å sette opp betingelse for når regelen skal kjøres ( UtgifterSkattFormueInntekt-datadef-7911 is equal to Nei ). o Trykk OK for å returnere. o Til sist settes selve aksjonen opp ved å trykke på Legg til handling. o Handling settes til Sett feltverdi. o Felt skal være UtgifterSkattFormueInntektBelop-datadef o Verdi skal være blank. For å utføre dynamikken også på ledetekst Ev. beløp, må denne være opprettet som uttrykksboks. Uttrykksbokser kan behandles som et vanlig felt og man kan legge på samme betinget formattering på den. Til forskjell fra formatet på feltet, kan det her settes en fargekode som for et felt som er skrivebeskyttet (ref avsnitt Fargekoder Altinn) Avansert eksempel på dynamikk For de mer viderekomne, gis her et noe mer avansert eksempel på dynamikk som krever bruk av expressions. Eksemplet kan sjekkes i RF Bruk av expressions er nødvendig dersom man må bruke flere enn 5 felt/betingelser. Formelen må da bygges opp ved å bruke XPath på feltene. NB! InfoPath bryter automatisk en stor expression i flere. Derfor bør man ikke blande or og and i samme expression Nedenfor eksempel fra RF-1097: /Skjema/SoknadOmEndringAvEllerKravOmForskuddsskatt-grp- 7675/Innsender-grp-7676/EnhetOrganisasjonsform-datadef = "1" or /Skjema/SoknadOmEndringAvEllerKravOmForskuddsskatt-grp- 7675/Innsender-grp-7676/EnhetOrganisasjonsform-datadef = "3" or /Skjema/SoknadOmEndringAvEllerKravOmForskuddsskatt-grp- 7675/Innsender-grp-7676/EnhetOrganisasjonsform-datadef = "5" or /Skjema/SoknadOmEndringAvEllerKravOmForskuddsskatt-grp- 7675/Innsender-grp-7676/EnhetOrganisasjonsform-datadef = "11" or /Skjema/SoknadOmEndringAvEllerKravOmForskuddsskatt-grp- 7675/Innsender-grp-7676/EnhetOrganisasjonsform-datadef = "12" or /Skjema/SoknadOmEndringAvEllerKravOmForskuddsskatt-grp- 7675/Innsender-grp-7676/EnhetOrganisasjonsform-datadef = "14" or /Skjema/SoknadOmEndringAvEllerKravOmForskuddsskatt-grp- 7675/Innsender-grp-7676/EnhetOrganisasjonsform-datadef = "20" or /Skjema/SoknadOmEndringAvEllerKravOmForskuddsskatt-grp- 7675/Innsender-grp-7676/EnhetOrganisasjonsform-datadef = "67" or /Skjema/SoknadOmEndringAvEllerKravOmForskuddsskatt-grp- 7675/Innsender-grp-7676/EnhetOrganisasjonsform-datadef = "68" or /Skjema/SoknadOmEndringAvEllerKravOmForskuddsskatt-grp- 7675/Innsender-grp-7676/EnhetOrganisasjonsform-datadef = "69" or /Skjema/SoknadOmEndringAvEllerKravOmForskuddsskatt-grp- 7675/Innsender-grp-7676/EnhetOrganisasjonsform-datadef = "86" Slik blir eksempelet seende ut i InfoPath: 76

77 Figur 62 - Betinget formatering Hjelpefelter, verdioverføringer Man kan opprette hjelpefelter som ikke finnes opprinnelig i XSD og bruke dem f.eks for å vise delsummer på andre sider. For å opprette felt eller gruppe skal man velge Datakilde, høyreklikke på Skjema og velge Legg til. Skriv her inn navn på felt og trykk OK. Feltet vises nå under Datakilde på skjemaets høyeste nivå. Deretter kan man dra feltet fra Datakilde til visning (side) og plassere feltet der man vil og velge ønsket felttype (kontrol). Figur 63 - Legg til felt/gruppe Merk at i Datakilde forblir feltet på øverste nivå, det er ikke mulig å få flyttet det til andre sider eller grupper som er definert i XSD. Verdioverføringer: For å vise verdien fra et felt på en annen side (view) i skjema, trenger en ikke å opprette duplikate-felt. For dette kan man bare dra det originale feltet fra Datakilde til de stedene man vil ha det (husk at å la alle disse kopiene være skrivebeskyttet). 77

78 Eksempel på verdioverføring finnes allerede i skjemaeksemplet vårt. Se Figur 1189 visning 6 eller visning 6 i InfoPath. Der viser feltet for samlet bruttoinntekt den overførte verdien fra post 1.5 i visning 3. Dette har skjedd automatisk ved at feltet BruttoinntektUtleieMv-datadef også er blitt opprettet i visning 6. Man trenger dermed ikke å overføre verdier av delsummer fra side til side, fordi en i InfoPath har tilgang til alle variabler fra alle steder i skjema. Man får ikke opprettet egendefinerte grupper eller repeterende felter, men man kan legge kontrolluttryksboks inn i repeterende gruppe og opprette kalkyler eller dynamikk der Web-, print- og kvitteringssider For å lage printutgaver basert på skjermbildene på Web, skal man opprette så mange view er som det er sider i skjema, kalle dem f.eks Print view 1 osv. Deretter kopiere og lime innholdet fra hver side til tilhørende print view side. Print view ene kan settes til å være read-only ved å velge Visningsegenskaper fra Vismenyen, flipp Generelt og krysse av for skrivebeskyttet. I flipp utskriftsinnstillinger kan man også sette formatet på side som skal skrives ut. Benytt gjerne forhåndsvisfunksjonen for å verifisere utskriftversjon. Figur 64 - Egenskaper for visning Hvis man vil ha en annen layout på printutgavene, for eksempel slå sammen flere web sider på samme printside, så er det bare å opprette det nødvendig antall visninger, definere ønsket layout, for eksempel ved å kopiere felter fra andre web sider (views) eller dra dem direkte fra datakilden. Kvittering opprettes på samme måte. Lag et ekstra view og kall den f.eks Receipt. Definer deretter layout og legge på de feltene som man ønsker å ha på kvitteringen. Det er også mulig å definere hjelpefelter og legge dem på print utgaver og kvitteringen Hjelpetekster (knapper) Svært mange skjermbilder i Altinn er definert med mulighet for å få opp hjelpeinformasjon på skjermen. Til dette benyttes det i InfoPath hjelp knapper som ser slik ut: For å plassere en trykk-knapp i skjermbildet, velg Controls siden og dra kontrollknappen dit hjelpeknapp skal plasseres, ref View 3 og View 6. Dobbeltklikk for å komme inn i Button Properties. Her kan knappen tilpasses med størrelse og tekst. Høyreklikk og velg Borders and Shading for å velge ramme rund og bakgrunnsfarge. 78

79 I vårt eksempel nøyer vi oss med å kopiere hjelp-knappen fra malen for InfoPath-skjemaene, sidemal_skd-pmh xsn, som ble nevnt innledningsvis. Deretter kan knappen kopieres til alle stedene i skjema hvor det skal være hjelpeknapper, og det gjenstår bare å endre til respektive Id er: Høyreklipp på knapp og velg egenskaper for knapp. Endre ID fra CTRLXX til HelpText_orid_xxxx eller HelpText_grp_xxx, hvor xxx står for de respektive orid er som det skal defineres hjelp for. Trykk på knapp Edit Form Code som vist under (dette er betinget av at Visual Studio er korrekt installert): Figur 65 - Egenskaper for knapp Slett den genererte metoden HelpText_orid_xxxx og endre den genererte linja i InternalStartup() til å peke på felles metode HelpText_Clicked (se eksemper under): public void InternalStartup() { ((ButtonEvent)EventManager.ControlEvents["HelpText_grp_50"]).Clicked += new ClickedEventHandler(HelpText_Clicked); ((ButtonEvent)EventManager.ControlEvents["HelpText_orid_5659"]).Clicked += new ClickedEventHandler(HelpText_Clicked); ((ButtonEvent)EventManager.ControlEvents["HelpText_orid_10093"]).Clicked += new ClickedEventHandler(HelpText_Clicked); ((ButtonEvent)EventManager.ControlEvents["HelpText_orid_8446"]).Clicked += new ClickedEventHandler(HelpText_Clicked); ((ButtonEvent)EventManager.ControlEvents["HelpText_orid_10095"]).Clicked += new ClickedEventHandler(HelpText_Clicked); } public void HelpText_Clicked(object sender, ClickedEventArgs e) { NotifyHost(e.ControlId); } Husk å alltid høyreklikke på skjemanavn i Project Explorer til høyre i Visual Studio, og velge Build etter at koden er endret. Eksempel fra Microsoft Visual Studio Tools for Applications: 79

80 Figur 66 - Eksempel fra Microsoft Visual Studio Tools for Applications Sporvalg For at sporvalgsfelter skal fungere i InfoPath skjema, er det nødvendig med to handlinger. Sporvalgsfeltet må alltid settes til å poste tilbake til serveren. Dette gjøres ved å dobbeltklikke feltet og velge flipp Webleserskjemaer som vist under: Figur 67 - Egenskaper for tekstboks Det andre er at det må legges inn C# kode for feltets Changed hendelse. Siden sporvalg ikke er en del av eksempel skjema RF-1189, henvises til eksempelet under fra RF-0900: 80

81 Figur 68 - InfoPath, kodeliste Følgende kode skal legges inn for dette feltet: NotifyHost("TrackFieldChanged_" + e.site.name); Dette skal legges i metoden som automatisk ble lagt til av Visual Studio. public void OppgaveAr_2D_datadef_2D_11236_Changed(object sender, XmlEventArgs e) { NotifyHost("TrackFieldChanged_" + e.site.name); } Hvis det benyttes avkrysningbokser for sporvalg, må det håndteres at kombinasjonen av disse anger et spor. Ellers må samme kode legges på Changed hendelsen for avkrysningsboksen Innlegging av kode i et skjema For å kunne legge inn kode i skjema må man gjøre følgende: Se eksempel nedenfor: Velg kommando Alternativer for skjema fra verktøymenyen. Velg Programmering. Velge C# som programmerings språk under Kodespråk for skjemamal. Merk at denne kan være grået ut og forhåndsvalgt. I Prosjektplassering, bla til mappe hvor InfoPath skal legge koden, helst i samme mappe som XSN fila (skjemafilen) på TUL-Share. 81

82 Figur 69 - Alternativer for skjema. Programmering 82

83 Forhåndsvisning og enhetstest i InfoPath I InfoPath gis det mulighet til å foreta en enkel inspeksjon av hvordan skjema fungerer, ved å benytte Forhåndsvisnings -valget. Denne finnes i verktøylinja i InfoPath og kan benyttes til enhetstest av skjema. For eksempel kan det legges inn verdier, og en kan verifisere at feltene oppfører seg som de skal. Det samme gjelder for kalkylene som er lagt inn. Eksempel fra RF-1189 View 3: Figur 70 - Forhåndsvisning i Infopath For å komme tilbake til Design modus, velges Lukk forhåndsvisning fra verktøylinja. Viktig tips dersom det vises følgende feilmelding når en skal åpne forhåndsvisning: "Infopath cannot open the selected form" I Infopath må da kommando Tools -> Form Options -> Security and Trust velges, deretter: Uncheck "Automatically determine security level" Velg radioknapp Full Trust og trykk OK Dette tipset er for øvrig hentet fra: 83

84 Fargekoder Altinn (foreløpig utgave pr ) Fargekoder altinn I (Adobe form designer) RGB Bakgrunn side: 241,245,247 Bakgrunn grupperamme: 226,234,240 Rammestrek rundt grupperamme: 212,224,231 Overskrift - skjema (9ptBold) 22,55,68 Strek øverst på siden: 223,237,239 Overskrift gruppe (8ptbold) 0,51,102 Ledetekst: (8pt) 0,51,102 Felttekst: (8pt) 0,51,102 Fremskutt hjelpetekst: 112,150,175 bakgrunn - Skrivebekyttet felt: 226,234,240 (samme som bagrunn grupperamme) Hjelpeikon - bakgrunn: 231,226,161 Ramme rundt felt: 212,208,200 Ramme rundt web-side: 184,203,216 (vises på WEB-PRINT) I beskrivelsen over vil f.eks. 9ptbold bety skriftstørrelse 9 og fete typer. Skrifttyper Det er for InfoPath-skjemaer, som for HTML generelt når det gjelder skrifttyper (fonts). Det er derfor viktig å velge standardiserte skrifttyper som f.eks. Arial, Verdana, Times New Roman, Lucida etc. Det vil være opp til sidemalen hvilken skrifttype som bør benyttes, samt hvordan denne vises i de ulike browserene/os ene. Sette fargekoder i Infopath: 1. ekspander nedtrekksgardin for farge. 2. Velg More Colors. I vindu "Farge": 3. Velg en hvit tom rute under seksjon egendefinerte farger. 4. Endre fargekoder for rød, Grønn og Blå (se koder over). 5. Legg til egendefinert farge. 6. Lagre som en egendefinert farge. 7. OK. Tips: bruk av Picker 1.0 Picker må lastes ned av bruker fra adressen angitt nedenfor. a. Trykk først på pipett. b. Beveg mus til riktig fargepunkt på skjerm. c. Klikk en gang med Venstre museknapp (for å registrere), evt flere venstre museklikk for flere registeringer. d. høyreklikk for å avslutte innsamling URL: The Color Picker The Color Picker enables you to pick your favorite colors from anywhere on your screen. Colors can then be added to a palette and saved for later use. The program supports color code in RGB and HEX, and you can easily copy the color code to the clipboard. 84

85 18.2 Vedlegg B: Veiledning i utforming av brukergrensesnitt for skjema Dette vedlegget tar for seg retningslinjer for utforming av sider i skjema. Vedlegget inneholder ikke de siste oppdateringene av skjemalayout. Prinsippene for utforming av skjemasider er fortsatt som vist i de følgende eksemplene Sidestørrelse Standard sidestørrelse for skjema er 16,0 cm x 13,210 cm (bredde x høyde) Hvis siden avviker fra standard sidestørrelse må man justere høyde/bredde slik at man ikke får både vertikal og horisontal scrollbar. Skjemasider som er høyere enn standard skal ha størrelsen: 15,545 cm x høyde bredere enn standard skal ha størrelsen: bredde x 12,779 cm Scrolling Det skal være minst mulig scrolling og helst ikke horisontal scrolling. Skjema skal deles over flere sider, men der dataene henger tett sammen skal man heller bruke scrolling vertikalt. Dette kan for eksempel være hvis det er en stor tabell eller utregninger som er avhengig av andre felt. I enkelte tilfeller kan det være nødvendig med horisontal scrolling i forbindelse med store tabeller for ikke å gjøre skjemaet for komplekst for brukeren. Hvis man må ha scrolling, forsøk å markere at det kommer noe mer på siden, feks ved å legge deler av en ledetekst eller et felt før scrollingen begynner. For å unngå horisontal scrolling, må ikke sidebredden overstige 630px. Denne bredden tar hensyn til vertikal scrollbar Sideoverskrift (skjemanavn) Alle sider skal ha en sideoverskrift i form av skjemanavn (Gruppe 2). Skjemanavnet skal plasseres top 0,070 cm og left 0,3 cm og skal være 1,550 cm høy og 10,400 cm bred. Under skjemanavnet skal det være en linje. Plassering er top 1,897cm og left 0,0. Linjen skal gå tvers over hele siden, og altså være like bred som siden Etatslogo Figur 71 - Etatslogo I Altinn er det obligatorisk med etatslogo på skjemaets første side. Det er valgfritt hvorvidt man også legger inn logo øverst til høyre på øvrige sider i skjemaet. Logo for de ulike etatene skjemaene i Altinn skal plasseres øverst til høyre i skjemaene, på følgende koordinater: top 0,070 cm og left 10,930 cm Grupper Grupper er felter som logisk hører sammen. Det kan være flere grupper på én side. En gruppe bør ikke være delt over flere sider. 85

86 Avstanden mellom to rammer skal settes slik: sett gruppeoverskrift for ramme nummer 2 kant i kant med rammen over og så 2 shift+pil ned. Grupperammen skal plasseres 0,2 cm left og følge bredden på skjemasiden. Den generelle regelen er at grupperammen skal være 0,4 cm kortere enn sidestørrelsen. Dette for å gi innrykk på 0,2 cm på hver side. Ved standard sidestørrelse skal grupperammen være 15,60 cm bred. For skjemasider som er: høyere enn standard skal grupperammen være 15,145 cm bred bredere enn standard skal grupperammen være lik sidebredden minus 0,4 cm Grupper inne i andre grupper (nivå 4) skal ikke ha ramme rundt seg. En gruppe skal ha gruppeoverskrift, hvis den ikke har overskrift skal den heller ikke ha ramme rundt seg Popup vinduer/dialogbokser Popup vinduer/dialogbokser bør i utgangspunktet ikke brukes Knapper Knapper i skjema skal ha følgende design: 1. Høyde 0,5 cm 2. Bredde: 0,2 cm lengre enn teksten, men korteste lengde er 2,0 cm 3. Teksten skal ha Justification lik Middle center 4. Farge BackColor: R175 G200 B Farge CaptionBackColor: R175 G200 B Farge ForeColor: R0 G0 B0 Plassering av knapper i skjema: For knapper som har direkte tilknytning til felter i skjemaet skal knappene plasseres i forhold til disse. Når knapp har tilknytning til ett felt skal knappen som hovedregel plasseres til høyre for inputfeltet, slik: Figur 72 - Plassering av knapper i skjema I situasjoner der dette ikke er gunstig grunnet lengde på ledetekst og feltlengde, kan knapp plasseres under inputfelt: Figur 73 - Plassering av knapper i skjema For knapper med direkte tilknytning til flere felter bestemmes plassering av knapp ut fra plassering av felter. Dersom alle inputfelter ligger på en linje bør også knappen ligge på denne linjen, slik: 86

87 Figur 74 - Plassering av knapper i skjema I situasjoner der tilknyttede inputfelter er fordelt på flere linjer plasseres knappen under inputfeltene, slik: Tabeller Figur 75 - Plassering av knapper i skjema Antall rader i tabell genereres automatisk. Det er alltid en rad i utgangspunktet, og så kan bruker legge inn ønsket antall. Det må også presiseres begrepsbruk om med tabell det menes repeterende gruppe og må jo være det. Det skal være 1 shift + pil (0,3 cm) luft mellom kolonnene + eventuelle tegn som +,-,e.l. o o o Kolonneoverskrifter skal alignes left med feltene i kolonnene. Kolonneoverskrifter og ledetekstene på rader skal ikke være i fet skrift. Kolonneoverskrifter med ulik antalle rader i teksten, skal "alignes" i bunnen (se eksempel nedenfor, i Figur 79). Tabeller og matriser med sumfelt Tabeller og matriser med ledetekst foran radene skal ha ledeteksten for sum venstrejustert med ledetekstene. (Se eksempel i Figur 76) Figur 76 - Matrise med ledetekst foran rader Tabeller som ikke har ledetekst foran hver rad skal ha ledeteksten for sum venstrejustert lik tabellens første kolonne. (Se eksempel i Figur 77) 87

88 Figur 77 - Tabell uten ledetekst foran rader Vertikale overskrifter Vertikale overskrifter med flere ledetekster til høyre for seg (se eks. fra RF-1071 under): Her er teksten "A. Tilgang i året" overskrift for postene Figur 78 - Vertikale overskrifter Løsning: Del opp i 3 grupper, flytt vertikal tekst opp som gruppetittel - da "A. Tilgang i året" gruppen seende slik ut: Tekstfelter, ledetekster og grafikk. Figur 79 - Løsning for A. Tilgang i året Redigerbare datafelter skal vises med hvit bakgrunn. Ikke-redigerbare data skal vises med grå bakgrunn Ledetekster starter med stor bokstav (må sikres ved registrering i OR) Ledetekster avsluttes uten kolon (må sikres ved registrering i OR). (Kolon kan i visse tilfeller føre til feil i skjema) Ledetekster skal venstrejusteres og feltene skal igjen venstrejusteres slik at ledetekst og felt danner to kolonner. TAlle i beløpsfelt skal høyrejusteres. Alle andre typer tekster skal venstrejusteres i sine felt. Hvis et felt har maks antalle tegn, skal ikke feltet være større enn maks antalle tegn. Det skal være jevn avstand mellom ledetekstene selv om en ledetekst går over flere linjer. Hvis det ikke er ramme rundt ledetekster, skal det være minst like stor luft mellom siste ledetekst og sideslutt som mellom ledetekstene (0,25 cm - se Grupper). Hvis papirskjemaet har spesialtegn som + eller - i feltet, skal dette plasseres på venstre side av feltet, sentrert (vertical center) i det elektroniske skjemaet og ha samme font og farge som ledeteksten. Trekk ledeteksten lengst mulig ut slik at den blir på færrest mulig linjer. Dette begrenses naturligvis av feltenes lengde. 88

89 Avstanden mellom slutten av den lengste ledeteksten og tilhørende felt/ev. grafikk ved feltet skal være 0,4 cm. Dette tilsvarer ca. 2 shift+pil. Hvis man har både hjelpeikoner og spesialtegn så er hovedregelen at man skal plassere hjelpeikonet 0,4 cm (2 shift + pil) fra slutten av den lengste ledeteksten, spesialtegnet 0,2 cm (1 shift + pil) fra slutten av hjelpeikonet, og feltet 0,2 cm ( 1 shift + pil) fra slutten av spesialtegnet. Kommentarfelt (som går over flere linjer) skal plasseres under tilhørende ledetekst og være en stor boks. Det skal være samme innrykk på ledeteksten og kommentarfeltet. Ledetekster som er uthevet i papirskjemaet med feks fet skrift, kan også utheves i WEB skjemaet hvis skjemaeier ønsker det. Alle felt er i utgangspunktet redigerbare med unntak av preutfylte og kalkulerte felt Plassering av overskrifter, ledetekster og rammer Tabell 9 - Plassering av overskrifter, ledetekster og rammer Hva Top Left Merknad Med ramme - en overskrift Overskrift 1 2,10 0,20 Ramme 2,60 0,20 Ledetekst 1 2,80 0,50 Ledetekst2 3,50 0,50 To hakk ned med shift+pil Med ramme - to overskrifter Overskrift1 2,10 0,20 Overskrift2 2,60 0,20 Ramme 3,10 0,20 Ledetekst1 3,30 0,50 Ledetekst2 4,00 0,50 Uten ramme Overskrift1 2,10 0,20 Ledetekst1 2,80 0,30 Ledetekst med tilhørende felt plasseres likt fra toppen av siden. Plassering av øverste tekstfelt når det ikke er ramme rundt er 2,8 cm. Ledetekst som står i en ramme skal plasseres med innrykk 0,5 cm. Ledetekst som ikke står i en ramme skal plasseres med innrykk 0,3 cm. Gruppeoverskriften skal plasseres 0,2 cm fra venstre kant. Det skal være 0,20 cm i avstand fra rammen til toppen av øverste felt/ledetekst og fra nederste felt/ledetekst og rammen under. Sideoverskriften (skjematittel) plasseres med topp 0,070 og innrykk 0,3. Overskrifter midt på en side uten tilhørende ramme skal ha 4 shift+pil nedrykk fra ledeteksten over. Avstanden mellom ledetekster under hverandre er 2 shift+pil ned. Avstanden mellom ramme og ledetekst er et hakk ned med shift+piltast. Avstanden mellom ramme og neste overskrift er to hakk ned med shift+piltast Plassering av felt Forsøk å danne kolonner på en side når det står flere felt horisontalt. Felt som står under hverandre skal være venstrejustert. Hvis felt og ledetekst ikke er så lange at de vil dekke hele siden horisontalt, skal feltene plasseres mot venstre slik at det kun er 0,4 cm luft (to hakk bort med shift+piltast) mellom lengste ledetekst og tilhørende felt og luften blir på høyre side av feltet. Rekkefølgen på felter skal som en hovedregel ha samme rekkefølge som i papirskjemaet. Ett unntak på dette er plassering av avgiver og revisor/regnskapsfører på første side. Postnummer og poststed skal som hovedregel plasseres under hverandre og rett etter adresse feltet. Hvis det er to eller flere kolonner med samme grafiske tegn tilhørende feltet i alle kolonnene, kan grafikken plasseres til venstre for feltet lengst til venstre for å spare plass. Dette gjelder ikke hvis en av de høyre kolonnene har egne grafiske tegn eller hvis det er plass til tegnene for alle kolonnene (da skal det ligne mest mulig på papirskjemaet). 89

90 Hvis man har noen generelle informasjonsfelt og deretter en del summeringsfelt, kan man unngå fra hovedregelen om at lengste ledetekst bestemmer plassering av alle felter som vist her: 90 Figur 80 - Unntak fra regel om lengste ledetekst Når flere sider i et skjema har samme oppsett, skal feltene på sidene ha samme feltlengde og plassering. Dette gjelder f.eks. årsregnskap fra BR (RR0003) Plassering av hjelpe-ikon Hjelp-ikon skal plasseres foran feltet det tilhører, justert midt på. Hjelp-ikon som tilhører hele grupper skal plasseres etter gruppetittelen med 0,4 cm luft, justert topp til topp Radioknapper (radio buttons) Radioknapper skal benyttes der brukeren må velge en fra en gruppe av 6 eller mindre gjensidig utelukkende valg. Hvis det er mer enn 6 valg, skal en rullgardinliste brukes. Hvis radioknapper benyttes i en tabell, skal Alletid rullgardinliste brukes uansett antalle valg. Tekst tilhørende radioknappene skal stå på høyre side av knappen. Ingen av radioknappene skal være valgt som standard. Radioknapper skal ha spørsmål til venstre og knappene med alternativene ved siden av til høyre. Dette gjelder ikke sporvalg (se under Innledende dialog) Avstanden mellom radioknapper er 0,5 cm fra topp til topp (på radioknappene) hvis ikke teksten på.alternativet er så lang at den går over flere linjer. Teksten på alternativet til en radioknapp skal plasseres midt på radioknappen med en avstand på 0,5 cm. Margin på hver radioknapp skal stå til auto (kjent feil i InfoPath Form Services gjør at den må stå til auto) Teksten på øverste alternativ skal stå på linje med ledeteksten. Avkryssingsbokser (check boxes) Avkryssingsbokser skal benyttes for binære valg. Avkryssingsboksene skal være uavhengige av hverandre. Tekst tilhørende avkryssingsboksene skal stå på høyre side av avkryssingsboksen. Flere avkryssingsboks skal arrangeres vertikalt. Hvis det er mange avkryssingsbokser, kan de også plasseres horisontalt for å utnytte plassen. Avstanden mellom avkryssingsboksen er 0,5 cm fra topp til topp (på boksene) hvis ikke teksten på alternativet er så lang at den går over flere linjer. Teksten på alternativet til en avkryssingsboks skal plasseres midt på avkryssingsboksen med en avstand på 0,5 cm. Avkryssingsbokser skal ikke rammes inn. Hvis det er 10 eller færre avkryssingsbokser kan de plasseres i kolonner for å utnytte plassen. Rekkefølgen av alternativene skal følge rekkefølgen i skjemaet. Vi anbefaler skjemaeier å plassere alternativene logisk, feks alfabetisk Listebokser (List box) Listebokser skal brukes for store datamengder.

91 Fra 3 til 9 elementer skal vises av gangen. Bruker skal kunne taste en eller flere bokstaver for å flytte i listene. Dersom brukeren kan velge flere forekomster fra en liste, skal det være en liste til som viser hva som er valgt Dersom det er aktuelt å velge alle, skal det være en avkryssingsrute eller knapp med Velg alle. Denne må da ha kode for å automatisk velge alle instanser i listen Ferdig utfylte felt Felt som er ferdig utfylt fra for eksempel fagsystemer skal som hovedregel være utilgjengelige. Dette markeres med at feltet får grå bakgrunnsfarge Dynamiske felt Alle felt som er dynamiske skal være synlige, men utilgjengelige (altså "grået ut"). Med dynamiske felt menes felt som brukeren skal svare på basert på tidligere svar, f.eks. ved å svare Ja på et felt skal brukeren fylle ut en adresse, mens svarer brukeren nei skal adressen ikke fylles ut. Hvis du må lage spørsmålet for å få dynamiske felt, skal spørsmålet stilles med radioknapper med ja/nei svaralternativ Fremskutt hjelpetekst Generell fremskutt hjelpetekst skal settes i en egen gruppe uten overskrift. Fremskutt hjelpetekst som gjelder hele skjemaet og som brukeren bør lese før hun starter å fylle ut skjemaet skal stå på toppen av første side i skjemaet. Figur 81 - Fremskutt hjelpetekst Fremskutt hjelpetekst som tilhører et felt, skal plasseres tilsvarende som i papirskjemaet. Hvis fremskutt hjelpetekst skal plasseres på linjen etter ledeteksten, men sammen med ledetekst skal de plasseres med rett venstrekant. Eksempel: 1. Dette er en ledetekst Og her er den tilhørende hjelpeteksten Fremskutt hjelpetekst skal ha fargen #4A9BAE (RGB: 74, 155, 174) og samme font som ledetekstene Avsender, regnskapsfører og ev. revisor samles på første side Forsøk å samle Avsender, Regnskapsfører og ev. Revisor på første skjemaside Gruppe: skattemessig verdi på kundefordringer Hvorvidt ttregningen stilles opp mest mulig likt papirskjemaet, må vurderes i hvert enkelt tilfelle. Se eksempelet under. (Obs! Hele tabellen og utregningen plasseres høyere på siden og post 0420 i rammen skal lenger til høyre. Oppdatert bilde kommer.) 91

92 Tab mellom felt Figur 82 - Gruppe Brukeren skal kunne flytte seg mellom felter i et skjema ved bruk av TAB-tasten. TAB skal ikke gå innom hjelp-ikon og heller ikke felt som brukeren ikke kan endre Innledende dialog (sporvalg) Innledende dialog er en egen side før selve skjemautfyllingen begynner for å velge spor. Siden skal ha: Ramme med gruppetittel: NOB: innledede spørsmål NON: "innleiande spørsmål" EN: "preliminary query" Fremskutt hjelpetekst før spørsmålet: Dette er spørsmål som vil avklare hvilke deler av skjemaet du skal fylle ut. Velg riktig alternativ for deg og klikk på Neste knappen. Hvis det er flere spørsmål plasseres de under hverandre tilsvarende som inne i skjemaet. Radioknapper plasseres under spørsmålet (se eksempel under). Eksempel: 92

93 Innledende spørsmål Figur 83 Sporvalg i portalen 93

94 18.3 Vedlegg C: Veiledning i utforming av brukervennlige tjenester Dette vedlegget tar for seg hvordan man kan lage brukervennlige tjenester. Brukervennlige tjenester bidrar til at brukeren får en positiv opplevelse av tjenesten, og sikrer at alle brukere kan benytte tjenesten, samt at tjenesten kan benyttes på ulike skjermlesere. Alle offentlige nettskjemaer skal følge ELMER 2-retningslinjene. ELMER er vedtatt som retningslinjer for brukergrensesnitt i offentlige skjemaer på Internett og skal sikre bedre skjemaer, bedre datakvalitet og raskere saksbehandling. Ved å benytte InfoPath og påfølgende parametersetting i TUL kan tjenesteutvikler utvikle ELMER-skjema. Altinn II støtter ELMER 2-retningslinjene, med unntak av: Advarsler (melding ved uvanlige, men tillatte verdier); kommer sannsynligvis i versjon 2. Utsatt visning av feil/mangler ved kryssvalidering og obligatoriske felt (alle meldinger knyttet til feltvalidering vises fortløpende i informasjonsområdet og deretter på kontrollside, som ved feil utfylling av enkeltfelt). Separate tabellsider i full skjermbredde i skjema som for øvrig benytter ELMER-navigasjon. Hjelpetekst med lenker som leder til andre steder i skjemaet. Gruppering av sider i navigasjonsmenyen med kapitteloverskrifter. Det vil være mindre unntak mht. nøyaktig hvordan informasjon blir presentert for sluttbruker. For eksempel sier ELMER at bruker kan fjerne fremhentet hjelpetekst ved å klikke på Hjelpknappen på nytt. I Altinn vil bruker i stedet kunne fjerne hjelpeteksten ved å klikke på et x- symbol ved teksten i informasjonsområdet. Siden ELMER 2-retningslinjene fokuserer på enkeltskjema, mens Altinn II også håndterer skjemasett, er det også gjort enkelte justeringer i sideflyten rundt kontroll og innsending i forhold til retningslinjene Retningslinjer for utforming av innsendingstjenester TUL støtter ELMER for innsendingstjenester ved at tjenesteutvikler kan angi om skjemaet skal presenteres i sluttbrukerløsningen i henhold til ELMER-retningslinjene. I følge ELMER skal skjemasiden være delt i tre områder ved siden av hverandre. Alle ordinære sider i skjemaet beståd av et utfyllingsområde for selve skjemaet med et navigasjonsområde til venstre og et område for selvvalgt tilleggsinformasjon til høyre. I tillegg skal det være en knapperad med navigasjonsknapper under skjemaet. Selve skjemaet bygges i InfoPath og lastes opp på en tjenesteutgaves arbeidsflate i TUL. I skjemadelen presenteres svarfelter som skal fylles ut av sluttbrukeren sammen med ledetekster og eventuelle hjelpeikoner. Navigasjonsområdet vil ved bruk av ELMER bli plassert til venstre for selve utfyllingsområdet. Navigasjonsområdet er en meny bygget opp av alle sidene i skjemaet. Skjemaet bør gis forståelige sidenavn som beskriver den enkelte sides temaer. Sidenavnet som skal vises i menyteksten kan være et forenklet kortnavn. Kortnavn kan defineres i parameterseksjonen Sideegenskaper i TUL. Tjenesteutvikler kan også angi om navigasjonen skal være fri eller styrt. Bruk av ELMER med fri navigasjon er satt som default valg i TUL, og anbefales. Kun i spesielle tilfeller kan det være hensiktsmessig å velge styrt navigasjon, som for eksempel hvis det er nødvendig å lede sluttbrukeren gjennom et bestemt resonnement. Når skjemaet åpnes første gang, vil området for tilleggsinformasjon presentere en standardisert oppskrift på hvordan skjemaet skal brukes. Området kan også inneholde meldinger fra systemet eller hjelpetekster. Disse dukker opp ved validering av skjema eller når bruker klikker på et hjelpeikon. Hensikten er å kunne gi individuell støtte for utfyllingen uten å forstyrre selve utfyllingsområdet. Hjelpetekstene defineres i parameterseksjonen Hjelpetekster i TUL. Meldinger til sluttbruker angis i InfoPath (se Valideringer). 94

95 I følge ELMER skal nettskjemaer benytte svaravhengige spørsmål og sporvalg. Svaravhengige spørsmål defineres i InfoPath, mens sporvalg defineres i TUL, under parameterseksjonen Sporvalg. ELMER anbefaler at kjente opplysninger forhåndsutfylles hvis det vil være til hjelp for sluttbrukeren (utfylleren). Under parameterseksjonen Preutfylling i TUL kan tjenesteutvikler forhåndsutfylle data fra Det sentrale folkeregister, Enhetsregisteret og Register over deltakerlignede selskap. I noen skjemaer kan det være nyttig for brukeren å få en oppsummering av tallstørrelser fra utfylte sider. Hvis det finnes et slikt sammendrag, skal det i følge ELMER presenteres alene på siste side i skjema og hete Sammendrag. Når sluttbrukeren er ferdig med å fylle ut et nettskjema, er det dessuten viktig at han får en klar og tydelig tilbakemelding om at skjemaet er sendt inn. Etter å ha fylt ut et skjema vil sluttbruker bli sendt til en egen kvitteringsside med kvitteringstekst, en oversikt over innsendte skjema og et sammendrag av det enkelte skjema, samt betalingsinformasjon der dette er aktuelt. Kvitteringsteksten defineres på siden for utgaveparametre i TUL. Hvilke felter som skal med i sammendraget defineres i InfoPath, men i parameterseksjonen Sideegenskaper i TUL må det defineres hvilkne sider i InfoPathdokumentet som skal brukes til sammendraget. 95

96 18.4 Vedlegg D: Veiledning i brukeradministrasjon TUL benytter seg av Active Directory og SharePoint for brukeradministrasjon. Dette betyr at administrasjon av brukere og grupper er tett knyttet til operativsystemet. Brukeradministrasjon og administrasjon av rettigheter i TUL foregår på den måten at brukere og grupper blir opprettet og vedlikeholdt i Active Directory Users and Computers, mens tildeling av rettigheter skjer i SharePoint. Eksempel på struktur vises i figuren under. Gruppe 1 Active Directory Bruker 1 Bruker 3 Bruker 2 Bruker 4 Gruppe 2 Bruker Hvordan administrere brukere Det er allerede et ferdigdefinert sett med grupper som er tiltenkt forskjellige roller og rettigheter i TUL. Hvordan disse gruppene opprettes og strukturen de har er ikke dekket i brukerdokumentasjonen. Det vil kun beskrives hvordan man på generell basis oppretter en gruppe. Opprette en bruker eller grupper Man oppretter nye brukere og grupper i Active Directory Users and Computers (AD), som kan nås fra Citrix for ASF-admin og tjenesteeieradministratorer. Bildet nedenfor viser åpningsbildet til AD hvor det er høyreklikket på mappen Users og valget New er valgt. 96

97 Figur 84 - Opprett en bruker eller en gruppe. Som vist i figuren over har man fra her tilgang til å opprette brukere eller grupper. De andre valgene er irrelevante for TUL. Bildene nedenfor viser hvor informasjonen ved opprettelse av bruker tastes inn. Figur 85 - Opprett en bruker eller en gruppe. Dette innebærer navn, brukernavn og passord. Merk at det her er huket av for at passordet må endres ved første pålogging. Dette er anbefalt. Ved å trykke på neste vil man se bekreftelse på inntastede data og mulighet for å fullføre opprettelsen. Husk at den enkelte brukeren skal legges til i de riktige gruppene for den aktuelle etat/tjenesteeier. Bildet under viser hvor informasjon ved opprettelse av grupper tastes inn. 97

98 Figur 86 - Opprett en bruker eller en gruppe. Når en gruppe lages, vil den alltid være tom. Man har så muligheten til å legge andre brukere eller grupper inn i gruppen. På denne måten kan man lage et hierarki av grupper. For å tildele rettigheter til en bruker eller gruppe, må man gjøre dette i SharePoint. 98

99 Tildele rettigheter i SharePoint Som en best pratice, skal man ikke tildele enkeltbrukere tilganger i SharePoint, men grupper. På denne måten vil det senere være lettere å la flere få samme rettighet. I SharePoint vil man kunne tildele spesifikke rettigheter på mange nivåer, og som en gylden regel vil alle underliggende elementer arve rettighetene fra sin forelder. Med dette menes at hvis en tjenesteeier har gitt tilgang til gruppen Service Owner SKD Users, så vil alle tjenester i denne gruppen automatisk gi tilgang til nevnt gruppe. Rent teknisk sett vil det ikke være problem å hindre gruppen i å få tilgang til en bestemt tjeneste. For å gjøre dette må man bryte rettighetene, noe som ikke anbefales. For å kunne endre rettigheter i SharePoint, må man ha tilstrekkelige rettigheter. Noe som i de fleste tilfeller vil være tjenesteeieradministrator. Er man da logget inn med tj.eieradministrator vil man få en ekstra knapp på arbeidsflaten, som gir tilgang til følgende kontekstmeny: Velg Innstillinger for webområde og så Personer og Grupper Figur 87- Kontekstmeny Figur 88 - Innstillinger for webområde. Personer og grupper Dette vil da gi muligheten til å legge til og fjerne grupper som har tilgang til tjenesteeieren. 99

100 Figur 89 - Legg til brukere Ved å velge Legg til brukere, kan fortelle SharePoint at en bruker eller gruppe som ligger i Active Directory skal ha en gitt tilgang til dette arbeidsområdet og alle underliggende elementer, så fremt de ikke har brutt arverekken. Det er verdt å merke seg at selv om det kun refereres til brukere, så vil en bruker og en gruppe fra Active Directory være likestilt for SharePoint. Figur 90 - Legg til brukere Man kan enten skrive inn gruppen/brukeren man vil legge til, eller søke. For å verifisere at man har skrevet riktig navn, benyttes. For å søke benyttes. Nedenfor kan man velge hva slags rettigheter valgt(e) gruppe(r) eller bruker(e) skal få: Full kontroll gir alle tilganger Utforme gir lese- og skriverettigheter Bidra enklere lese- og skriverettigheter Lese gir kun visningstilgang. Klikk OK for å lagre rettighetstildelingen. 100

101 18.5 Vedlegg E: InfoPath kodestandard Dette vedlegget inneholder en oversikt over kodestandard for InfoPath. Dette vedlegget bør oppdateres etter hvert som nye skjema blir utviklet i TUL og man kommer fram til standarder på tvers av tjenesteeierne. Det er altså opp til tjenesteeiere å oppdatere dette vedlegget. Som et utgangspunkt anbefales Brad Adams sin oppsummering 101

102 18.6 Vedlegg F: InfoPath navnestandard Dette vedlegget inneholder en oversikt over navnestandard for felter, grupper, skript og skjema i InfoPath. Som for kodestandarden er dette vedlegget levende og skal vedlikeholdes av tjenesteeierene. Det er ingen forutsetning av alle tjenesteeiere har lik navne standard, men en felles navnestandard vil lette arbeid og videreutvikling på tvers av personer. Det anbefales at felter som ligger i altinn-namespace prefikses med Altinn_Field_. Eks. altinn:altinn_field_123. Merk at det som står etter kolon-tegnet er valgfritt, og alle felter som benytter altinn-navnerommet, fjernes før oversendelse til etat.

103 18.7 Vedlegg G: Web Service oppslag fra InfoPath skjema Dette vedlegget inneholder en beskrivelse av hvordan man kan gjøre Web Service oppslag fra et InfoPath skjema. Webservice oppslag vil være i kjernen i hvordan registeroppslag fungerer. Dette vil fungere på den måten at skjemaet vil kontakte registeret med predefinerte parametere og deretter få et svar som man kan behandle i skjema. Denne veiledningen vil derfor beskrive en generell fremgangsmåte for hvordan gjøre et webserviceoppslag i InfoPath-skjema. Eksempeldataene benyttet i fremgangsmåten tilhører Hent arkivreferanse. P.t. er det ikke andre skjemaspesifikke tjenester tilgjengelig Hvordan kalle en WebService fra et InfoPath skjema Legg til en datatilkobling ved å vise Datakilde i Utformingsoppgaver-vinduer i InfoPath. Deretter velge Behandler datakilder... og Legg til... Man må si velge å opprette en ny tilkobling for å motta data, og dette via en webtjeneste. Adressen som angis for webtjenesten vil kunne variere iht hvilket oppslag som skal gjøres, for eksempel vil adressen for å hente arkivreferanse være Når denne adressen er angitt, vil InfoPath forsøke å kontakte tjensten for å hente en liste over operasjoner. Antall operasjoner og navn vil variere med tjenesten. I dette eksempelet velger vi GetArchivedFormTaskList. Figur 91 - Hent arkivreferanse Husk å fjern avkryssning for om data skal hentes når skjema åpnes hvis data ikke skal hentes før man trykker på en knapp i skjemaet. Nå er datastrukturen fra oppslaget tilgjengelig som en sekundær datakilde og kan derfor benyttes i skjema. Det er verdt å merke seg at for de fleste spesifikke Altinn registeroppslagene vil man måtte autentisere seg, og at enhetstest i InfoPath derfor vil være vanskelig. Se kapittel for kode som må legges inn for spesifikke oppslag.

104 Resultatet fra oppslaget kan vises i skjemaet på mange måter. Et eksempel er en repeterende tabell som populeres på bakgrunn av klikk på knappen Hent arkivreferanser. Figur 92 - Registeroppslag inn i repeterende tabell For å angi registeroppslaget skal utføres eller den eksterne tjensten skal kalles ved trykk på knappen, må det lages en regel på knappen som skal brukes til å kalle Web servicen. Dette gjøres ved å høyreklikke på knappen og velge Egenskaper for knapp... og deretter klikke på Regler... og velge Legg til... Man må nå angi et navn på regelen. Dette navnet kan være selvvalgt. Velg Legg til handling... og velg Spørring ved hjelp av datatilkobling i nedtrekkslisten for Handling. Nå må den sekundære tilkoblingen velges. Nå vil oppslaget utføres ved klikk på knappen. Som nevnt tidligere vil enkelte registeroppslag kreve ekstra informasjon fra skjemaet for å kunne autentisere seg, samt vite hvilke brukerspesifikke data som skal hentes ut. Neste kapittel vil vise dette for Altinn spesifikke oppslag C# kode for registeroppslag Legg inn C# kode i Loading eventen til skjema. Koden skal hente ut portal parametre som skal benyttes i kallet til web servicen. Dette er data som hentes ut fra FormState under skjemautfylling i portalen. Eksemplet under viser hvordan dette skal kodes, og legg merke til at det enkelte skjemaspesifikke verdier som må settes, bl.a. ekstern tjenestekode og ekstern utgavekode. Dette er markert i grønt i eksempelet. public void FormEvents_Loading(object sender, LoadingEventArgs e) { string opensso = FormState["OpenSSOID"] as string; string userid = FormState["UserID"] as string; string reporteeelementid = FormState["ReporteeElementID"] as string; string reporteeid = FormState["ReporteeID"] as string; string language = FormState["Language"] as string; XPathNavigator secds = this.datasources["getarchivedformtasklist"].createnavigator(); XPathNavigator node = secds.selectsinglenode( "/dfs:myfields/dfs:queryfields/tns:getarchivedformtasklist/tns:userid", NamespaceManager); if (node!= null && userid!= null) 104