Administrators oppgaver
Oppgaver for administrator fra den enkelte tjenesteeier.
På denne siden:
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 vanlige tjenesteutviklere. Dette være seg å legge inn nye prosessflytmaler, legge til betingelser, opprette brukere eller angi rettigheter i TUL. Denne beskrivelsen vil ta for seg noen av scenarioene, men ikke hvor standardproduktene dekker hele funksjonaliteten som ikke er spesifikk for TUL.
Prosessflytmaler
Som nevnt ifbm. prosessflyt i innsendingstjenesten, finnes to typer prosessflytmaler i TUL, en felles og en spesifikk for tjenesteeieren. ASF-administrator legger til nye felles maler, mens de enkelte tjenesteeier-administratorene legger til for den enkelte tjenesteier. Begge typer maler er bygget på samme måte, men tjenesteeierspesifikk 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>
identifiserer 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). Attributtet lcid
angir 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.
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 steg 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>
</Step>
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 rekkefølge.
- 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>
</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 Nedtrekksliste | Beskrives under denne tabellen |
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>
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>
<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>
</Property>
Administrasjon av brukere, grupper og rettigheter
Beskrivelse av hvordan man administrerer brukere, grupper og rettigheter finnes i dokumentet Veiledning for brukeradministrasjon i TUL.pdf.
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 and folders | Altinn/Service Owner XXX | ||
Service Owner XXX SharePoint Administrators | All Service Owner Administrators | Brukere som skal være tj.eier administrator | Altinn/Service Owner XXX |
Service Owner XXX Users | All Service Owner Users | Alle etatens tjenesteutviklere | Altinn/Service Owner XXX |
Service Owner XXX Code List editors | Service Owner Code List editors | Alle som skal ha tilgang til å vedlikeholde kodelister | Operations/Administrative Users and global groups |
Service Owner XXX Group administrators | AD Snap-In Access | Alle som skal vedlikeholde brukere for etaten | Operations/Administrative Users and global groups |
Service Owner XXX Password administrators | AD Snap-In Access | Alle som skal vedlikeholde brukere for etaten | Operations/Administrative Users and global groups |
Service Owner XXX User administrators | AD Snap-In Access | Alle som skal vedlikeholde brukere for etaten | Operations/Administrative Users and global groups |
(XXX er den nye etatens kode)
Tjenesteeierverktøy
Det er kun administratorer av TUL sin startside som kan opprette tjenesteeiere. For å opprette dette, må vedkommende navigere til følgende plassering:
http://<miljø>/_layouts/altinn/ServiceOwner.aspx
Der må administrator fylle ut i følgende skjermbilde:
Legg inn relevant data og klikk på *Create/Opprett.*Tjenesteeieren opprettes og status vises:
Som markert i rødt over, vil også en lenke til den nye arbeidsflaten vises. Klikker man på den, taes man til den nye tjenesteeieren.
Hvis opprettelse feiler, vil dette vises på samme sted.
Hvis arbeidsflaten ikke inneholder veiledningskomponent og tjenesteliste, må disse aktiveres.
Dette gjøres ved å klikke på 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.
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.
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 | Altinntul\Service owner XXX users |
XXX site owners | Altinntul\ASF SharePoint Administrators |
XXX site visitors | Altinntul\All service owner users |
(XXX er tjenesteeierkode)
Nå er tjenesteeieren/etaten klar til bruk.
Betingelser (conditions)
Betingelser er SBL-kode som utvikles og sjekkes in i TFS av en utvikler. Disse betingelsene kan kjøres når en hendelse inntreffer som kan føre til endring av tilstand for en samhandlingstjeneste.
Når koden er sjekket inn og migrert til tilhørende SBL-miljø, så må AFS-admin gå inn på følgende URL for å legge til den nye betingelsen for at den skal kunne benyttes av en samhandlingstjeneste:
Merk: Navn på betingelse (tittel) er case-sensitiv og må samsvare med metodenavn som utvikler har kodet.
Gjenbrukbar logikk
Gjenbrukbar logikk (“hooks”) er kode som kjøres i SBL ved gitte hendelser i en tjenesteutgaves livsløp. Hvilken logikk som kjøres for en gitt utgave defineres av tjenesteutvikler i TUL.
Når en ny gjenbrukbar logikk er kodet og migrert i tilhørende SBL-miljø, så må administrator legge inn en rad i listen.
Det er typisk Driftsleverandør som oppdaterer dette, men ASF-admin kan også gjøre det hvis nødvendig informasjon om hva som skal legges inn er gitt.
Følgende typer logikk kan defineres:
- Instantiation: Logikk kjøres når en utgave opprettes i SBL, og hvilken logikk som skal kjølres defineres på utgaveparametersiden.
- Payment: Kjøres ved arkivering i SBL og velges på parametersiden for SKD betalingsinformasjon.
Betalingsadministrasjon
Adgang til betalingsleverandøravtalesiden
For å få adgang til betalingsleverandøravtalesiden hos en tjenesteeier må brukeren være medlem av betalingsadministratorgruppen for tjenesteeieren. Hva som er gruppe for betalingsadministrator blir avgjort av konfigverdien «PaymentAdminGroupName» i Altinn.TUL.config. Gruppen må inneholde navnet som er definert der. I utgangspunktet er denne verdien «Payment Admin Group». Anbefalt struktur er å styre tilgang gjennom grupper i AD som er medlem i disse SharePoint-gruppene. For eksempel en AD-gruppe «SKD betalingsadministratorer» som er medlem av SharePoint-gruppe «SKD Payment Admin Group». Adgang blir deretter styrt ved å legge til eller fjerne brukere i AD-gruppen.
Dersom konfigverdien blir endret vil den nye verdien brukes for å bestemme adgang til siden. Lenken til siden fra tjenesteeierarbeidsflaten blir derimot låst til en bestemt SharePoint-gruppe ved aktivering av tjenesteeier-featuren i SharePoint. Skal lenken oppdateres til å godta en ny verdi i konfig, må denne featuren aktiveres på nytt etter at konfig er endret.
Adgang til siden bør begrenses til de personene som har ansvar for å opprette og vedlikeholde betalingsavtaler.
Betalingsmetoder
Betalingsmetodene som vil være mulig å velge i TUL blir styrt av en SharePoint-liste i Startside site collection. Denne listen vil du finne under «Områdeinnhold» med navn «Tilgjengelige betalingsmetoder».
Listen skal inneholde alle de betalingsmetoder som det er ønskelig å kunne velge gjennom TUL. Hver enkelt betalingsmetode må legges inn med et visningsnavn som er navnet som vil bli vist i TUL. I tillegg må det legges inn en kode for betalingsmetoden for hver enkelt betalingsleverandør. Disse kodene må stemme overens med den koden som betalingsleverandøren bruker for denne metoden. Dersom koden er feil vil ikke betalingsmetoden fungere for den leverandøren den er feil for. Beskrivelse er valgfritt, og vil ikke bli vist andre steder enn i denne listen.
Metodene som blir lagt inn i listen er felles for alle tjenesteeiere og skal være alle betalingsmetoder som det skal være lov å velge mellom dersom du velger å tillate begrensing av betalingsmetoder på betalingsleverandøravtalesiden.
Prosessflytmal
For at betaling skal fungere må det brukes en prosessflyt som inneholder et betalingssteg. Administrator må derfor gjøre tilgjengelig (se 23.1 Prosessflytmaler) minst en prosessflytmal med betalingssteg. Ved innføring av betalingsfunksjonaliteten ble det opprettet fire prosessflytmaler for betaling. Disse er «Betaling», «Utfylling og betaling», «Utfylling, signering og betaling» og «Utfylling, betaling og signering».