AP221 Use Case - TUL - Utarbeid komponenter
Utarbeid komponenter En tjeneste i Sluttbrukerløsningen har en arbeidsflyt som bestemmer de forskjellige stegene som må gjennomføres i skjemainnsendingen. Disse stegene kan være for eksempel utfylling, signering, innsending, kvittering og arkivering. I tillegg til steg kan en arbeidsflyt også inkludere andre typer komponenter. Dette kan for eksempel være kontroller 1. Eksempel på en kontroll er en sjekk på om innsender er myndig eller ikke, hvor svaret trigger videre handlinger i arbeidsflyten. Ved parametrisering av prosessflytmalen inkluderes da kontrollene som en del av stegdefinisjonen (se Figur 1 for en illustrasjon). Ved definering av en tjeneste kan en tjenesteutvikler velge fra predefinerte prosessflytmaler 2 og spesifiserte maler tilpasset tjenesteeier 3. Dersom ønsket mal ikke finnes, må den utvikles i Visual Studio, publiseres til Sluttbrukerløsningen og deretter tilgjengeliggjøres som en mal. Dette use caset omhandler det å lage prosessflytmalen og arbeidsflytkomponentene som skal tilgjengeliggjøres i Tjenesteutviklingsløsningen. For å tilgjengeliggjøre prosessflytmalen for bruk i tjenestetuviklingsløsningen, se use case Bygg verktøykasse. Bruk av prosessflytmalen, det vil si videre parametrisering for tilpassing til tjeneste ved tjenesteutvikling beskrives i use case Spesifiser arbeidsflyt (inkludert i use case Definer tjeneste ). Use caset dekker opprettelse og utvikling av ny komponenter. Dersom en allerede produksjonssatt prosessflytmal skal endres, er videre handlemåte avhengig av hva som skal endres. Dersom endringen fører til en endring i selve arbeidsflyten, må det lages en ny prosessflytmal. Dersom endringen er en bugfix som ikke påvirker arbeidsflyten direkte, så kan prosessflytmalen endres og migreres på nytt i en ny versjon. Arbeidsflyten vil baseres på Windows Workflow Foundation og utvikles med Visual Studio Designer 2008 og Visual Studio 2008. De detaljerte stegene for hvordan arbeidsflyten blir laget vil dermed styres av mulighetene som ligger i disse verktøyene. Utviklingen er i stor grad programmering med Visual Studio Designer 2008 og Visual Studio 2008. I tillegg til utvikling av selve prosessflytmalen og komponentene må det lages en XML som representerer malen med steg og inputfelter, inkludert eventuelle defaultverdier. XMLen bestemmer hvilke verdier som kan parameteriseres og knytter de til prosessflytmalen. XMLen har språkstøtte, som benyttes for både prosessflytmaler og spesifiserte prosessflytmaler. Det er flere mulige løsninger på hvordan utviklere av prosessflytmaler og komponenter skal få tilgang til utviklingsmiljøet. På analysetidspunktet er det ikke avgjort om dette er noe som kan gjøres direkte fra TUL eller om det er mer hensiktsmessig å la utviklere få tilgang for eksempel til leverandørens utviklingsmiljø. Det må taes en avgjørelse på hva som er mest hensiktsmessig, da utvikling i praksis vil gjøres med tilgang til Leverandørens kodestruktur og utviklingsmiljø. Det er derfor ikke beskrevet noe i dette use caset om hvordan og hvor innlogging foretas. Det er tekniske fagpersoner med nødvendig kompetanse som lager prosessflytmalene. 1 Tidligere kalt hooks. Også kalt avansert logikk. 2 Omtalt som prosessflytmal 3 Omtalt som spesifisert prosessflytmal 2
Figur 1 Spesifisering av arbeidsflyt - tenkt løsning (ikke ferdig design) Aktør(er) Trigger: Pre-betingelser Post-betingelser Normal utføring Se Figur 1 Utarbeid komponenter IKT Teknisk Tjenesteutvikler (Fagperson) har behov for en prosessflytmal som ikke finnes Tjenesteutvikler (IKT) skal endre i en eksisterende, ikke publisert, prosessflytmal Bruker har rettigheter til å bruke Visual Studio Bruker er logget inn i Visual Studio og Windows Workflow Foundation. Prosessflytmalen er ferdig utarbeidet 1. Velg arbeidsflytprosjekt: Visual Studio er basert på bruken av prosjekter for utvikling a. Opprett tomt prosjekt: Ved opprettelse av ny prosessflytmal b. Endre eksisterende prosjekt: Ved fortsatt utvikling av eksisterende, ikke produksjonssatt, prosessflytmal. Kan også kopiere et annet arbeidsflytprosjekt og endre dette. i. Varsel sendes til abonnenter ved endring av dokument 3
2. Velg arbeidsflytkomponenter: Bruker velger hvilke arbeidsflytkomponenter 4 (steg) som kan være med. Disse kan velges i vilkårlig rekkefølge og antall. Eksempel på steg og konfigurerbare parametere vises under. a. Utfylling ii. preutfylling iii. tekstlig beskrivelse av steg b. Signering ii. tekstlig beskrivelse av steg c. Innsending ii. tekstlig beskrivelse av steg d. Kvittering ii. tekstlig beskrivelse av steg e. Arkivering ii. tekstlig beskrivelse av steg Andre, ikke definerte parametere kan også settes her. Statiske/dynamiske (input fra bruker), obligatoriske/frivillige 3. Utvikle: Bruker utvikler arbeidsflyten basert på valgt komponentmal. Dette innebærer blant annet utvikling av flytrekkefølge og eventuelle parallelle arbeidsflytsteg. Dette er standard kode-utvikling, hvor brukeren må sørge for at prosjektet kompilerer og blir enhetstestet. 4. Lagre prosjekt Alternativ utføring Dersom den nødvendige komponenten ikke finnes, må den lages. Utvikling av arbeidsflytkomponenter gjøres på bestilling eller av tjenesteutvikler selv dersom han innehar nok kompetanse. Ny arbeidsflytkomponent, se Figur 1 1. Velg arbeidsflytprosjekt: Visual Studio er basert på bruken av prosjekter for utvikling a. Opprett tomt prosjekt: Ved opprettelse av ny prosessflytmal b. Endre eksisterende prosjekt: Ved fortsatt utvikling av eksisterende, ikke produksjonssatt, prosessflytmal i. Varsel sendes til abonnenter ved endring av dokument 2. Velg arbeidsflytkomponenter: Bruker finner ikke den arbeidsflytkomponenten han trenger 3. Lag ny komponent: Bruker bestiller ny arbeidsflytkomponent via en egen prosess 4. Lag arbeidsflytkomponent: Teknisk personell utvikler arbeidsflytkomponent, foregår ved programmering, lagring, kodegjennomgang osv.. 5. Test arbeidsflytkomponent: 6. Tilgjengeliggjør arbeidsflytkomponent: Komponenten legges ut for bruk. Brukeren som skal lage prosessflytmaler vil da ha komponenten tilgjengelig neste gang han trenger den. (Se use case Bygg verktøykasse for rutiner rundt kvalitetssikring og tilgjengeliggjøring) Feilhåndtering Standard feilhåndtering i Visual Studio og Windows Workflow Foundation Forretningsregler Prosessflytmaler som endres kan allerede være i bruk av en eller flere tjenester. Det vil ikke være mulig å gjøre ting som fører til endringer i selve arbeidsflyten i produksjon. I disse tilfellene vil det måtte lages en ny mal. Dette er ikke en prosess som er automatisk i tjenesteutviklingsløsningen. Bugfix som går på for eksempel tekstendringer kan gjøres. Varsling til andre tjenesteutviklere om at ny eller endret prosessflytmal er tilgjengelig må gjøres via kunngjøringer i SharePoint. Referanse til use Bygg verktøykasse case o AP221 Use Case TUL Bygg verktøykasse.doc Referanse til TUL_3.4.3.2.1 I arbeidsflyt for 4 I Workflow Foundation forstås en komponent som en activity 4
krav TUL_3.4.3.2.4 TUL_3.4.3.2.6 TUL_3.4.3.2.7 TUL_3.4.3.2.8 TUL_3.4.3.2.15 TUL_3.4.3.2.5 TUL_3.4.3.2.2 TUL_3.4.3.2.5 TUL_3.4.3.2.9 Innhold i arbeidsflyten kan styre hvilken rettighet som skal signere, og hvor mange signeringssteg innsendingstjenesten har. En arbeidsflyt kan ha parallelle signeringssteg. Logikken som styrer hvilke deler av arbeidsflyten som skal benyttes kan være styrt av innhold i skjema og informasjon om den som skal signere. TUL_3.4.3.2.14 Alle tekster som vises i forbindelse med prosess kan vedlikeholdes av tjenesteeier. I det ligger det også krav om støtte for bokmål, nynorsk og andre språk TUL_3.4.3.2.16 Det skal være versjonskontroll av prosessflytmal slik at det alltid er mulig å gjenskape det brukeren opplevde. TUL_3.4.3.2.11 En og samme arbeidsflyt kan brukes av flere innsendingstjenester samtidig. TUL_3.4.3.2.12 Det er ikke mulig å oppdatere en arbeidsflyt som brukes av flere tjenester uten at det gis tydelig varsel til tjenesteutvikler. INT_3.3.2.1.2 INT_3.3.2.1.3 En arbeidsflyt kan kalle regler for å gjøre valg i arbeidsflyten. En arbeidsflyt kan startes av en regel. utfylling, signering, kvittering, arkivering og innsending kan man både definere hvilke steg som ligger i arbeidsflyten og hvilke rollekrav som ligger til de enkelte stegene. Det er full frihet i definering av prosessene slik at man f.eks. kan fravike utfylling eller ha en signering før utfylling (f.eks. bekreftelse av at man innehar fullmakt til å se skjemainformasjonen). Det kan angis hvorvidt en signering er obligatorisk. Det er mulig å angi sikkerhetskrav til hvert signeringstrinn, det vil si hvilket sikkerhetsnivå og rettigheter man stiller til en bruker som skal signere i sluttbrukerløsningen. Det er mulig å angi logikk som styrer hvilke deler av arbeidsflyten som skal benyttes. Det er mulig å fritt styre tekstlig innhold for alle steg i prosessen. En arbeidsflyt kan ha parallelle signeringssteg. 5
Krav dekket i design INT_3.3.2.1.4 INT_3.3.2.1.10 TUL_3.4.3.2.5 TUL_3.4.3.2.9 TUL_3.4.3.2.14 TUL_3.4.3.2.16 TUL_3.4.3.2.11 TUL_3.4.3.2.12 INT_3.3.2.1.2 INT_3.3.2.1.3 INT_3.3.2.1.4 INT_3.3.2.1.10 En arbeidsflyt kan startes av en egenutviklet komponent. Det er mulig å kalle eksterne tjenester/komponenter fra både arbeidsflyt, skjema og regler. En arbeidsflyt kan ha parallelle signeringssteg. Logikken som styrer hvilke deler av arbeidsflyten som skal benyttes kan være styrt av innhold i skjema og informasjon om den som skal signere. Alle tekster som vises i forbindelse med prosess kan vedlikeholdes av tjenesteeier. I det ligger det også krav om støtte for bokmål, nynorsk og andre språk Det skal være versjonskontroll av prosessflytmal slik at det alltid er mulig å gjenskape det brukeren opplevde. En og samme arbeidsflyt kan brukes av flere innsendingstjenester samtidig. Det er ikke mulig å oppdatere en arbeidsflyt som brukes av flere tjenester uten at det gis tydelig varsel til tjenesteutvikler. En arbeidsflyt kan kalle regler for å gjøre valg i arbeidsflyten. En arbeidsflyt kan startes av en regel. En arbeidsflyt kan startes av en egenutviklet komponent. Det er mulig å kalle eksterne tjenester/komponenter fra både arbeidsflyt, skjema og regler. 6
IKT Velg arbeidsflytprosjekt Teknisk Opprett tomt prosjekt Endre eksisterende prosjekt Velg arbeidsflytkomponenter Utfylling Signering Kvittering Arkivering Innsending Annet steg Utvikle Lag ny komponent Lag arbeidsflytkomponent Lagre prosjekt Test arbeidsflytkomponent Tilgjengeliggjør arb.flytkomponent Figur 2 - Utarbeid komponenter 7
Relatert dokumentasjon Dokument Type Kommentar TUL Brukerveiledning Brukerveiledning AP347 Page Specification High Level - TUL - Workflow Design 8