Kravspesifikasjon Føderering esporingsløsningen

Kravspesifikasjon Føderering esporingsløsningen Versjon 0.8 2. mai 2011

Innholdsfortegnelse 1 Introduksjon... 1 1.1 BAKGRUNN... 1 1.2 HENSIKT MED DOKUMENTET... 1 1.3 INNHOLD I DOKUMENTET... 1 1.4 MÅLGRUPPE FOR DOKUMENTET... 2 1.5 DEFINISJONER... 2 1.6 REFERANSER... 2 1.7 VERSJONSOVERSIKT... 3 1.8 HØRINGSRUNDER... 3 2 Hensikt med føderering i esporingsløsningen... 4 2.1 HVA ER FØDERERING... 4 2.2 FØDERERING OG INTEROPERABILITET... 5 2.3 FØDERERING I ESPORING... 5 2.4 MÅL MED FØDERERING... 5 2.5 FORUTSETNINGER FOR FØDERERING... 6 3 Overordnede krav til føderering... 7 3.1 HOVEDFUNKSJONER OG ROLLER... 7 3.2 IDENTIFISERE FØDERERTE AKTØRER... 7 3.3 ADMINISTRERE TILGANG TIL FØDERERTE SPORINGSDATA... 8 3.4 VALIDERE FØDERERTE SPORINGSDATA... 8 3.5 INNHENTE FØDERERTE SPORINGSDATA... 9 3.6 REGISTRERE OG TILGJENGELIGGJØRE SPORINGSDATA... 9 4 Detaljerte krav til føderering... 11 4.1 FUNKSJONELLE KRAV... 11 4.1.1 Identifisering av aktører og sporingsdata... 11 4.1.2 Innhente fødererte sporingsdata... 11 4.2 KRAV TIL INFORMASJON OG IDENTIFIKATORER... 12 4.3 KRAV TIL GRENSESNITT FOR DATAUTVEKSLING... 12 4.4 KRAV TIL SIKKERHET... 12 4.5 IKKE-FUNKSJONELLE KRAV... 13 4.5.1 Krav til gjenbruk av esporing løsningsarkitektur... 13 4.5.2 Krav til oppetid og svartid.... 13 5 Eksempler på bruk av føderering... 14 5.1 INNSAMLING AV SPORINGSDATA... 14 5.2 SPØRRING... 15 5.2.1 Spørring initiert fra den sentrale løsningen... 15 5.2.2 Spørring initiert av aktørene... 16 esporing 02.05.2011 Side ii

1 Introduksjon 1.1 Bakgrunn I arbeidet med esporingsløsningen har flere sentrale aktører i matkjeden etterspurt en funksjonalitet i esporingsløsningen for å kunne frigi (dvs. gi tilgang til) data i egne systemer som et alternativ til å overføre store datamengder til esporingsløsningen. Forslaget er basert på at esporingsløsningen skal være verktøyet som styrer tilganger og rettigheter i aktørenes systemer. Det er også fremmet ønske om at en slik tilgang skal fungere sømløst med esporingsløsningen, dvs. at en bruker (forutsatt at brukeren har de rette tilganger og rettigheter) som utfører en spørring mot data i løsningen ikke skal merke om data er lagret i esporingsløsningen eller internt hos en aktør. Denne formen for interoperabilitet mellom ulike informasjonssystemer betegnes føderering, eller en føderert løsning. 1.2 Hensikt med dokumentet Dette dokumentet skal beskrive krav til føderering i esporingsløsningen. Føderering er en ekstra funksjonalitet som vil bli utviklet etter at første versjon av esporingsløsningen er ferdig utviklet. Dokumentet forutsetter at esporingsløsningen oppfyller kravene i kravspesifikasjonen, og henviser til den der det er relevant. Dette dokumentet må derfor leses som et tillegg til Kravspesifikasjonen for esporingsløsningen. Føderering er definert som å forbinde eller samarbeide, og i dokumentet omtales tre typer føderering: Føderering av identitet som styrer tilganger og rettigheter Føderering av data på tvers av flere systemer/databaser Føderering av funksjonalitet mellom ulike løsninger I esporing er det særlig de store aktørene i matkjeden som ønsker føderering og har fremmet krav om dette bl.a. i tilbakemeldingen fra DMF/DLF etter demoen av esporingsløsningen i mai. Kravene til løsningen er avstemt med noen av de sentrale aktørene i matkjeden. Kravspesifikasjonen har som mål å beskrive alle krav til føderering, uavhengig av når disse kan/skal realiseres. Kravspesifikasjonen skal danne grunnlag for en løsningsbeskrivelse og en etterfølgende avtale om utvikling av løsningen. Første versjon av føderering skal realiseres i fase 2 av esporingsprosjektet. 1.3 Innhold i dokumentet Dette dokumentet har følgende innhold: Introduksjon til dokumentet Hensikt med føderering Overordnede krav til føderering Detaljerte krav til føderering Eksempler på bruk av føderering Dokumentet er utarbeidet som en del av esporingsprosjektet. Det er viktig å presisere at den dekker krav til føderering som stilles til den sentrale løsningen. Krav til de lokale løsninger som skal inngå i føderering vil bli beskrevet i Aktørveiledningen. esporing 02.05.2011 Side 1 av 16

1.4 Målgruppe for dokumentet Den primære målgruppen for dette dokumentet er leverandøren av esporingsløsningen (ErgoGroup) som skal utarbeide en løsningsbeskrivelse. 1.5 Definisjoner Definisjon av sentrale begreper i dokumentet. Begrep esporingsløsningen esporing Sporingsdata Sporingsgraf/ Sporbarhetsgraf Kvalitetsdata Grunndata Matkjede Føderering Beskrivelse Den sentrale løsningen for å registrere og administrere sporingsdata innen matkjeden i Norge. Den enhet som oppnevnes av myndighetene for å forvalte og administrere esporingsløsningen og sikre at intensjonene i løsningen ivaretas. Data om sporbare enheter for å angi eierskap og/eller ansvar for enheten, hvor den har vært og når den var der (hvem, hva, hvor, når). Sammenstilling av sporingsdata for en gitt sporbar enhet i historisk perspektiv basert på hendelser som er registrert på en sporbar enhet. Her brukt om data om sporbare enheter utover sporingsdata, f.eks. info. om produkt, næringsinnhold, temperaturkjede, mål og vekt. Dette er informasjon som det kan være aktuelt å etterspørre i forbindelse med etterforskning av utbrudd Offentlige og private dataregistre som benyttes av esporing, f.eks. Brønnøysundregistrene og ulike registre knyttet til f.eks. primærnæringen og varehandelen. I løsningen omtalt som eksterne masterdata. Brukt som fellesbetegnelse for alle verdi-/næringsmiddelkjeder som på en eller annen måte er i befatning med mat, inkludert ikke-mat aktører som transportører, emballasjeprodusenter og andre som bidrar med fysiske innsatsfaktorer i verdikjeden. Definert som å forbinde eller sammenslutte. Her brukt om å knytte sammen eksterne systemer med esporingsløsningen via løse koplinger i en distribuert løsning. 1.6 Referanser Under er referanser til relevant informasjon om esporingsløsningen. Referanse Versjon Beskrivelse Aktørveiledning esporingsløsningen esporing SystemRequirements Architecture Overview www.tracefood.org Versjon 1.0, 2.oktober 2009 Versjon 1.0 13.08.2009 Versjon 1.0 27.02.2009 Utarbeidet av esporingsprosjektet som en veileder for aktører i matkjeden som skal knytte seg til esporingsløsningen. Kravspesifikasjon for esporingsløsningen utarbeidet for esporingsprosjektet av DnV. Leveranse fra Oppdrag 4 i esporingsprosjektet, gjennomført fra oktober 2008 til mars 2009. Wiki med diverse informasjon om sporbarhet i matkjeder. esporing 02.05.2011 Side 2 av 16

1.7 Versjonsoversikt Versjon Dato Beskrivelse 0.1 3.september 2010 Første versjon for gjennomgang i esporingsprosjektet og blant aktører i matkjeden. 0.2 22.september 2010 Oppdatert med kommentarer etter høringsrunde 1 0.3 7.oktober 2010 Oppdatert med kommentarer etter høringsrunde 2 0.4 12. april 2011 Dokumentet er vesentlig omarbeidet og utvidet. Kapittel 2 er utvidet med en beskrivelse av føderering og føderering i esporing. Kap. 3 er totalt omarbeidet med beskrivelse i Use Case (UMLdiagrammer) Omarbeidet og utvidet med mer omfattende beskrivelse av føderering og en beskrivelse av generiske use case som løsningen omfatter. Utvidelse og detaljering av kap. 4 gjenstår. 0.8 2. mai 2011 Gjennomgang av dokumentet etter avklaringsmøte med utvalgte aktører 13. april. Forbedret beskrivelsene i kap. 3. Presisering av krav i kap. 4. 1.8 Høringsrunder I arbeidet med denne kravspesifikasjonen har det vært gjennomført følgende høringsrunder. Versjon Dato Sendt til Tilbakemelding fra v0.1 3.september Tine, Coop, Asko/NorgesGruppen, GS1 v0.2 22.september Tine, Coop, Asko/NorgesGruppen, GS1 Coop, Asko/NorgesGruppen, GS1 (Tine deltok på innledende møte 27/8 og ga innspill til versjon 0.1) Coop, Asko/NorgesGruppen, GS1 v0.3 7.oktober esporing esporing v0.4 13. april Avklaringsmøte med Tine, Norgesgruppen og Coop 2011 v0.8 2. mai 2011 Coop, NorgesGruppen, Tine Kommer senere esporing 02.05.2011 Side 3 av 16

2 Hensikt med føderering i esporingsløsningen 2.1 Hva er føderering Føderering er definert som å forbinde eller samarbeide, og i denne sammenhengen betyr det å knytte sammen esporingsløsningen med lokale systemer hos aktørene i et nettverk der data spørres etter ved behov i stedet for å overføres mellom systemene og blir lagret i esporingsløsningen. Denne forståelsen av begrepet føderering kan i prinsippet omfatte følgende nivåer: Føderering av Beskrivelse Eksempler Identitet Data Funksjonalitet Bruk av en påloggingsmekanisme som gir en single sign-on (SSO) til flere systemer/tjenester. En distribuert databaseløsning som deler data på tvers av flere databaser, verktøy og/eller plattformer uten at en bruker må forholde seg til hvor og hvordan det er lagret En distribuert løsning hvor funksjonalitet fra ulike systemer/prosesser/tjenester er tilgjengelig for en bruker uten at brukeren behøver å forholde seg til i hvilket system/komponent en funksjonalitet befinner seg. Kan også være motsatt i den betydning at en funksjonalitet føderes inn i mange løsninger MinID for felles pålogging til offentlige tjenester som for eksempel MinSide, AltInn og Lånekassen. Skal også kunne brukes for pålogging i esporingsløsningen Feide (Felles elektronisk identitet) som brukes i utdanningssektoren OpenID Pålogging via Facebook eller Twitterkontoer til ulike tjenester Tradisjonelle distribuerte databaseløsninger Datavarehus og BI-verktøy Arbeidsflateløsning, for eksempel klinisk arbeidsflate i helsevesenet er et forsøk på å etablere dette. Generelle konsepter som tjenesteorientert arkitektur og Unified Communications (UC). AltInn 2.0 som felles plattform for offentlige tjenester fra ulike tjenestetilbydere gjør dette til en viss grad Føderering har til hensikt å tilby en bruker sømløs integrasjon mellom løsninger. Dvs. at en bruker kan bruke en løsning uten å måtte forholde seg til hvilket system man opererer i. Ved føderering av identitet er det påloggingen som er sømløs på tvers av ulike løsninger. En god beskrivelse av krav og utfordringer ved dette finnes i dokumentene Implementasjonsguide for føderering med MinID og Tilslutningsguide mot ID-porten. I esporingsammenheng er det aktuelt å benytte føderering av identitet for pålogging til esporingsløsningen via AltInn eller MinID. Dette er en del av leveransen i versjon og ikke videre omhandlet i dette dokumentet. Føderering av data (eller databaser) betyr at en bruker kan foreta søk, lagring, oppdatering m.m. av data uten å måtte forholde seg til hvor data er lagret, og det er tilgangen til data som er sømløs på tvers av databaser. Dette er samme prinsipper som ligger i distribuerte databaser. Datavarehus er en teknologi som kan brukes til å etablere et slikt konsept. Datavarehus og BI-løsninger gjør dette gjennom å replikere en større eller mindre del av data fra de underliggende/distribuerte databasene. Denne kravspesifikasjonen handler om føderering av sporingsdata og evt. masterdata i esporingsløsningen. Føderering av funksjonalitet betyr at en bruker har tilgang til en arbeidsflate der man bruker ulike systemer uten at man behøver å forholde seg til hvor i en distribuert arkitektur funksjonaliteten eller systemet befinner seg. En arbeidsflate som samler ulike systemer i et felles presentasjonslag eller menysystem er ikke føderering av funksjonalitet dersom det ikke er en integrasjon mellom løsningene. Det er få eksempler på slike løsninger foreløpig. Føderering av funksjonalitet er utenfor den målsetting som gjelder føderering av esporingsløsningen, men kan bli aktuelt på et senere tidspunkt. esporing 02.05.2011 Side 4 av 16

2.2 Føderering og interoperabilitet Føderering handler om samhandling mellom systemer på ulike nivåer som beskrevet i foregående avsnitt. Denne form for samhandling har mye til felles med definisjoner av begrepet interoperabilitet. Det er ikke direkte overlappende da interoperabilitet kan oppnås via andre mekanismer enn føderering: Følgende definisjoner av interoperabilitet er basert på definisjonene i European Interoperability Framework. Nivå Fokus Definisjon Teknisk interoperabilitet Semantisk interoperabilitet Organisatorisk Standarder for interaksjon og transport mellom tekniske løsninger Harmonisering av semantikk som brukes i meldingsutveksling Samordning av organisasjon og prosesser Tekniske konnektivitet mellom ulike systemer/løsninger Presise og enhetlige definisjoner av informasjonselementer som skal kunne utveksles Koordinerte prosesser på tvers av organisasjoner EU-definisjonen omfatter også juridisk og politisk interoperabilitet da rammeverket har som utgangspunkt å etablere interoperabilitet for offentlige tjenester mellom EU-stater. Når det gjelder føderering av esporingsløsningen er det først og teknisk og semantisk interoperabilitet som er i fokus. Organisatorisk interoperabilitet er en mulighet som aktører kan oppnå dersom de velger å utvikle verdiøkende tjenester til esporingsløsningen. 2.3 Føderering i esporing Føderering innebærer at aktører skal kunne velge ikke å sende inn sporingsdata til esporingsløsningen, men i stedet gjøre disse tilgjengelig fra egne systemer via et standardisert grensesnitt. Ved behov, f.eks. i en etterforskningssituasjon vil det da sendes en forespørsel til en aktør der man spør etter sporingsdata hos aktøren. I prinsippet skal den som genererer forespørselen ikke merke at data hentes fra en lokal løsning, og ikke fra den sentrale esporingsløsningen. Føderering er også omtalt som informasjonsdeling, og en slik løsning kan også gi mulighet for økt samhandling mellom aktørene der man utveksler mer enn bare sporingsdata. Informasjonsutveksling og deling av data har hele tiden vært planlagt som en del av esporingsløsningen. Det er derfor ikke noen motsetning mellom kravet til føderering og intensjonen i esporingsløsningen. Ufordringen består i å bestemme hva man ønsker å oppnå med en slik løsning og hvilke forutsetninger som må stilles. 2.4 Mål med føderering Det primære målet med føderering er å redusere antall dataoverføringer til esporingsløsningen. Dersom alle de store aktørene skal sende sine interne sporingsdata på jevnlig basis snakker vi om millioner av transaksjoner pr. dag. Dette vil kunne bli en belastning både for esporing og aktørene. I tillegg vil en løsning basert på standardiserte grensesnitt åpne for verdiøkende tjenester i form av utveksling av andre typer data enn sporingsdata. Det er identifisert følgende mål med føderering: 1. Redusere antall dataoverføringer til esporingsløsningen 2. Redusere lagringsbehovet i den sentrale esporingsløsningen 3. Utnytte eksisterende interne sporingsløsninger hos aktører i matkjeden og redusere behovet for å utvikle ny funksjonalitet for overføring til esporingsløsningen 4. Utnytte kompetanse hos aktører i matkjeden ved spørring etter sporingsdata og etablering av sporingsgrafer 5. Gi mulighet for å benytte store aktører i matkjeden som datainnsamlere og kilde for sporingsdata for mindre aktører esporing 02.05.2011 Side 5 av 16

6. Gi mulighet for verdiøkende tjenester for aktørene gjennom utveksling av andre typer data som f.eks. salgsdata 7. Stimulere til at aktørenes sporingsdata er koblet til øvrige data som mengde, produkt, detaljert sporingsinfo, temperatur osv. som kan være viktig for analyseformål. 2.5 Forutsetninger for føderering Utover kravene til den sentrale esporingsløsningen som er beskrevet i dette dokumentet, er det også andre forutsetninger som må være tilfredsstilt for at føderering skal fungere i praksis. Dette gjelder særlig i forhold til å definere regler for bruk av løsningen, og å sørge for at lokale systemer hos aktørene tilfredsstiller nødvendige i forhold til føderering. 1. Bruk av esporingsløsningen må være klart definert i forhold til nivå på sporingsdata og hvilke hendelser som skal trigge sporing. Dette går bl.a. på å avklare hva som er minste sporbar enhet i ulike sammenhenger siden dette kan variere fra sektor til sektor og mellom ledd i kjeden. 2. Aktørene må oppfylle de kravene som føderering stiller til dem i forhold til o o o o Hvilket paknings-/artikkelnivå sporingsdata skal rapporteres på Hvilke hendelser som skal trigge sporing internt Hva som er relevant sporbare enhet for spørring Krav til oppetid og svartid til lokale løsninger i forhold til å respondere på spørringer Punkt 1 forutsettes avklart via pilotene og de erfaringer man høster der. Punkt 2 må tas inn og beskrives i Aktørveiledningen. esporing 02.05.2011 Side 6 av 16

3 Overordnede krav til føderering Dette kapitlet beskriver overordnede funksjonelle krav til føderering i esporingsløsningen. Dette omfatter både krav til den sentrale løsningen og krav til fødererte aktører. Kravene er dokumentert via Use cases og bruk av UML-diagrammer. Dette mener vi gir et presist og oversiktlig bilde av de funksjonelle kravene. Kapittel 4 beskriver detaljerte krav til hver av hovedfunksjonene som er beskrevet i dette kapitlet. 3.1 Hovedfunksjoner og roller Diagrammet under viser hovedfunksjonene i en føderert løsning for esporing. Det er også angitt hvilke roller som er involvert i hver av funksjonene. esporing AS er den sentrale administrasjonen av løsningen Bruker av esporingsløsningen er en aktør hos myndigheter eller i matkjeden som foretar en spørring etter sporingsdata Føderert aktør er en aktør i matkjeden som har valgt å tilgjengeliggjøre sin sporingsdata via en føderert løsning Funksjonen Foreta spørring etter sporingsdata inngår i kjernefunksjonaliteten i esporingsløsningen og vil ikke bli nærmere beskrevet her. Den er tatt med i diagrammet for å vise at en spørring kan trigge innhenting av fødererte data. Forklaring til diagrammene. extend og include angir at funksjoner er knyttet sammen etter følgende regler: include=skal alltid utføres extend=kan utføres i gitte situasjoner (for eksempel kan funksjonen Innhente fødererte sporingsdata utføres når en Bruker foretar spørring etter sporingsdata) 3.2 Identifisere fødererte aktører I esporingsløsningen må det være mulig å angi at en aktør er føderert. I prinsippet er det slik at en aktør som har data føderert også kan ha data lastet opp i esporingsløsningen. Det foreslås at man i første omgang lager en løsning hvor aktører som bruker føderert i utgangspunktet ikke laster opp noe data til esporingsløsningen. esporing 02.05.2011 Side 7 av 16

Det foreslås at det ikke skal være mulig å ha en kombinert løsning hvor noe data lastes opp i esporingsløsningen og noe data ligger lokalt i en føderert løsning. En slik kombinasjonsløsning vil øke kompleksiteten i løsningen i vesentlig grad da løsningen i slike tilfeller må ha informasjon om hva som ligger i løsningen (sentralt) og hva som ligger lokalt hos aktøren. 3.3 Administrere tilgang til fødererte sporingsdata Et sentralt element i esporingsløsningen er at den skal inkludere et regime for tildeling og forvaltning av tilgang til data i løsningen. Ved føderering i esporingsløsningen skal tilganger og rettigheter styres gjennom det samme regimet. Dette er beskrevet i Kravspesifikasjonen til esporingsløsningen. Gjennom føderering av identitet i løsningen skal brukeren få tilgang til data i andre systemer gitt at brukeren er tildelt en rolle som gir slik tilgang. Det er aktøren som eier data som må definere hvilke andre aktører som skal ha tilgang til egne data. Dette gjelder også for en føderert løsning. Det anbefales at man anvender samme rammeverk for føderering av ID her som man gjør for pålogging til esporingsløsningen via AltInn/MinSide. 3.4 Validere fødererte sporingsdata Denne funksjonen omfatter å validere/kontrollere at fødererte aktører registrerer og lagrer sporingsdata i henhold til krav fra esporing. Løsningen skal uformes slik at det foretas rutinemessig validering av fødererte data. De må vurderes om det i tilegg er hensiktsmessig med en validering når en spørring utføres. esporing 02.05.2011 Side 8 av 16

3.5 Innhente fødererte sporingsdata Innhenting av fødererte data trigges av en spørring mot esporingsløsningen. Spørringen utføres uten hensyn til om data er føderert eller ikke. Søk vil foretas mot de innsynroller man har, og egne data. Løsningen skal vite om en aktører er føderert eller ikke, og dersom søket omfatter fødererte data vil esporingsløsningen foreta et søk mot aktørens løsning. Søket skal bruke standard XML-schema for esporingsløsningen. Grensesnittet mellom esporingsløsningen og de fødererte løsningene skal bruk et standardisert grensesnitt (API), og EPCIS-standarden utpeker som et preferert alternativ. Sporingsdata som returneres til esporing som et resultat av et søk skal kunne lagres i esporingsløsningen som et søkereresultat. 3.6 Registrere og tilgjengeliggjøre sporingsdata En føderert løsning forutsetter at aktørene registrerer og lagrer sporingsdata i egne systemer i henhold til krav fra esporing. Det er imidlertid opp til aktørene selv å velge løsning for dette og å ha rutiner som sikrer at sporingsdata er tilgjengelig ved spørring fra esporing. I utarbeidelsen av en slik løsning skal følgende elementer ligge til grunn Data må tilgjengeliggjøres via et standardisert ECPIS-grensesnitt (EPCIS query web service). Det kan for eksempel skje via en datavarehusløsning som samler og preparerer data for esporingsløsningen Autentisering og rettigheter (inklusive innsynroller) skal kunne leses inn fra esporingsløsningen, og aktørene må bruke esporingsløsningen for å tildele andre innsynsroller i egne data. Det vil trolig også kreve at man må laste opp masterdata for å kunne gi detaljerte innsynsroller. Data må være tilgjengelig for rutinemessig validering fra esporingsløsningen. Aktørene er enige om at det er for sent å rydde opp i grunnlagsdata når spørringer feiler, og at det derfor må skje en rutinemessig validering. Det foreslås at aktørene som vil benytte en føderert løsning oppretter et felles forum for å utvikle tilpasningen i sin løsning, og også for å være en sparringpartner mot utvikler. esporing 02.05.2011 Side 9 av 16

esporing 02.05.2011 Side 10 av 16

4 Detaljerte krav til føderering Dette kapitlet gir en detaljert beskrivelse av de krav som må stilles til esporingsløsningen for å få til en løsning for føderering. Dette beskriver ikke krav til aktørene for å betjene en slik løsning. Kravene er gruppert i: Funksjonelle krav Krav til informasjon og identifikatorer Krav til grensesnitt Krav til sikkerhet Ikke-funksjonelle krav 4.1 Funksjonelle krav Mye av den funksjonaliteten som kreves for føderering er allerede utviklet i gjeldende versjon av esporingsløsningen. De vesentligste nye kravene er knyttet til mulighet for å spørre etter data. Kapitlene under beskriver de tilleggskravene som må stilles til esporingsløsningen i forhold til føderering. 4.1.1 Identifisering av aktører og sporingsdata I esporingsløsningen må det ligge informasjon om hvilke aktører som har sporingsdata i sin lokale løsning, og ikke skal overføre disse til den sentrale løsningen. Det forutsettes at det også blir tatt inn mulighet for å etablere hierarkiske strukturer innen organisasjoner. Krav 1.1 I den sentrale løsningen må det kunne angis at en aktør har avtale om føderering og ikke skal sende inn sporingsdata. 1.2 I den sentrale løsningen må adresse for spørringer kunne angis for de som har avtale om føderering. 1.3 Det må være mulig å etablere en hierarkisk struktur innenfor en organisasjon, dvs. angi at et selskap inngår i et annet selskap. 1.4 Det må være mulig å angi at en aktør sender inn sporingsdata for deler av selskapet og har føderering for andre deler. En del av selskapet kan ikke kombinere føderering med innsending av data. Kommentar 4.1.2 Innhente fødererte sporingsdata Spørring er et sentralt krav i en løsning for føderering og skal baseres på EPCIS regler for spørring/query og eksisterende krav til den sentrale løsningen. Krav 2.1 En løsning for føderering skal støtte EPCIS web-service for spørring/query. 2.2 I henhold til EPCIS skal følgende type spørringer støttes: Query Callback On Demand queries 2.3 Alle avvikssituasjoner definert i EPCIS skal støttes, dette gjelder f.eks.: QueryToLarge Kommentar esporing 02.05.2011 Side 11 av 16

4QueryToComplex 2.4 I en query skal det kunne spørres etter data som både ligger i den sentrale løsningen og i lokale løsninger. 2.5 Ved etablering av en query skal en bruker ikke trenge å vite om data skal hentes fra sentral eller lokal løsning. Dvs. at den sentrale løsningen må vite at data er lagret lokalt. 2.6 Dersom en query ikke besvares innen definert tid skal den avbrytes og aktuell aktør skal kontaktes. 2.7 En query må håndtere asynkron kommunikasjon og kunne vente på svar fra en lokal løsning (en query kan omfatte manuell vurdering hos lokal aktør). 2.8 esporingsløsningen skal kunne lagre fødererte sporingsdata som del av et søkeresultat 4.2 Krav til informasjon og identifikatorer Føderering skal primært håndtere spørring på basis sporingsdata som er definert i dagens datamodell. Eventuell bruk av lokale vokabularer må avtales direkte mellom aktører eller innen sektorer. Føderering har samme krav til identifikatorer som den sentrale løsningen. Her må det være et regime for IDhåndtering som er entydig mellom aktørene. Konvertering av id er kan også forekomme, men regler for dette bør etableres og administreres av en sentral enhet, f.eks. GS1. For øvrig henvises det til Kravspesifikasjon for esporingsløsningen for ytterligere krav til identifikatorer. Krav 2.1 I en løsning for føderering må det både aksepteres bruk av globalt unike id er og lokale identer som konverteres.. Kommentar 4.3 Krav til grensesnitt for datautveksling Overføring av data til esporingsløsningen skal gjøres i henhold til de grensesnitt som er definert i den sentrale esporingsløsningen. Krav 3.1 En løsning for føderering må støtte de grensesnitt som er definert i EPCIS. Dette omfatter Web services og XML-formater slik de anvendes i esporingsløsningen. Kommentar 4.4 Krav til sikkerhet Ved spørring mot lokale systemer skal sikkerheten ivaretas via de roller som er definert i esporingsløsningen. Det er to typer sikkerhet som må ivaretas og som også er definert i EPCIS: Autentisering Sikre at den som spør er den han gir seg ut for å være Autorisasjon Sikre at den som spør har riktige rettigheter for tilgang til data Både autentisering og autorisasjon skal ivaretas gjennom sikkerhetssystemet i esporingsløsningen Som eksempel skal Coop kunne gi Tine tilgang for å spørre etter Tine-relaterte data i Coop s lokale systemer. Krav 4.1 Når en aktør får en forespørsel om å returnere sporingsdata, skal autentisering av aktørene Kommentar esporing 02.05.2011 Side 12 av 16

være ivaretatt gjennom sikkerhetssystemet i esporingsløsningen. 4.2 Når Aktør A spør etter data hos Aktør B, skal rolletildelingen i esporingsløsningen sikre at A har rettigheter til de data som det spørres etter hos B. 4.5 Ikke-funksjonelle krav 4.5.1 Krav til gjenbruk av esporing løsningsarkitektur Løsningen for fødereringen skal være en integrert del av esporingsløsningen, og en videreutvikling skal gjøres gjennom å utvikle løsningen kjernefunksjonalitet og ikke gjennom en duplisering/kopiering av funksjonalitet. Krav 5.1 Føderering skal være en integrert del av esporingsløsningens arkitektur som i størst mulig grad gjør gjenbruk av rammeverk og programkode fra løsningen. Kommentar 4.5.2 Krav til oppetid og svartid. Siden alle spørringer skal rutes via esporingsløsningen, krever føderering at den sentrale løsningen alltid må være tilgjengelig. Krav 5.2 Føderering stiller krav til at esporingsløsningen må være tilgjengelig 24/7. Kommentar. esporing 02.05.2011 Side 13 av 16

5 Eksempler på bruk av føderering 5.1 Innsamling av sporingsdata Innsamling av sporingsdata skal i prinsippet skje i henhold til kravene i den sentrale løsningen. Kravet er at en aktør minimum skal kunne dokumentere varer inn og ut av selskapet. Dette kan da være alt fra en liten melkebonde til et stort konsern. Ved behov skal en så kunne etterpopulere data, dvs. tilgjengeliggjøre mer data for å komplettere kjedesporing og eventuelt å etablere interne sporingskjeder. Føderering skal både dekke behovet for innsamling av minimum sporingsdata og etterpopulering av data.. esporingsløsningen åpner også for deling av tilleggsdata/kvalitetsdata utover sporingsdata. Det er naturlig at denne type data også håndteres via føderering for de aktører som velger dette. Figuren på neste side viser innsamling av sporingsdata for en verdikjede der 3 primærprodusenter leverer produkter/enheter til en stor leverandør som videreforedler disse for leveranse av et sluttprodukt til butikk. Dette kan f.eks. være melk som blir til ost eller dyr til kjøttdeig. I praksis vil butikken ofte inngå i en dagligvarekjede med et grossistledd og tilhørende kompleksitet, men dette er utelatt her for å forenkle modellen. Leverandøren har en avtale om føderering og vil da ikke sende inn sporingsdata til den sentrale løsningen. Prosessen hos leverandøren er bare angitt på et generelt nivå for å vise at leveransene fra produsentene blandes hos leverandøren. Det er også listet de ulike pakningsnivåene som hver aktør håndterer. I henhold til Kravspesifikasjonen for esporingsløsningen skal det minimum overføres sporingsdata til den sentrale løsningen som følger: 1. De 3 primærprodusentene overfører sporingsdata om hva de har sendt fra seg. 2. Den store leverandøren overfører ingen data til esporing, men registrerer og lagrer sporingsdata i internt system. a. Leverandøren registrerer mottak av enheter/batcher fra primærprodusentene internt i sitt system. Krav til data for registrering er i henhold til Kravspesifikasjon for esporingsløsningen. b. Sporingsdata for interne steg hos leverandøren lagres i internt system. c. Leverandøren registrerer hva man sender fra seg i henhold til samme prinsipper som i punkt a. esporing 02.05.2011 Side 14 av 16

3. Butikk overfører sporingsdata om mottak fra leverandør. 5.2 Spørring Mulighet for effektiv og sikker spørring etter data i nettverket er en kritisk suksessfaktor for føderering. Spørring må kunne utføres i ulike sammenhenger og etter ulike typer data. Og spørringer må kunne initieres både fra sentralt hold og fra aktørene. De kravene som er stilt til den sentrale query-funksjonen i esporingsløsningen legger naturlig nok føringer for hvordan spørringer skal kunne utføres. Og noe av det mest sentrale her er kravet til EPCIS 1 og webservices. EPCIS er en standard som utnytter elektroniske produktspor til å identifisere og dele produksjons- /sporingsdata. Som en del av EPCIS er det bl.a. spesifisert en predefinert tjeneste (web service) for spørring. Eksisterende esporingsløsning har som intensjon å støtte EPCIS og gjør det også langt på vei i dag. Men siden EPCIS p.t. ikke er særlig utbredt er det gjort noen tilpasninger i forhold til denne. En løsning for føderering skal støtte EPCIS så langt som mulig og innenfor de rammene som er gitt av den sentrale esporingsløsningen. Under er det skissert 2 ulike scenarioer for spørring. En som er initiert fra den sentrale løsningen og en som er initiert fra en aktør i matkjeden. Dette er kun eksempler på hvordan spørring kan utføres, og detaljerte krav til spørrefunksjonen er beskrevet i kapittel 4. 5.2.1 Spørring initiert fra den sentrale løsningen Spørring fra sentralt hold kan f.eks. være en etterforskningssituasjon eller ved tilfeller av tilbaketrekking. Under er etterforskning brukt som eksempel og her vil det være ulike innfallsvinkler avhengig av utgangspunktet og hvilke observasjoner som er gjort. Følgende type spørringer må kunne foretas fra sentralt hold: Spørring etter sporingsdata der kilden er kjent Spørring etter sporingsdata der kilden er ukjent Spørring etter sporingsdata som grunnlag for tilbaketrekking Figuren under viser spørring i en tilbaketrekkingssituasjon, f.eks. der man har funnet bedervet mat i en butikk og man ønsker å finne primærprodusenten(e). I dette tilfellet er leverandøren av produktet kjent. 1 Electronic Product Code Information Service esporing 02.05.2011 Side 15 av 16

1. Via sporingsdata som er overført fra butikk finner man hvilken leverandør den aktuelle varen kommer fra og når den ble levert. 2. Basert på informasjon fra butikken gjør man en spørring etter sporingsdata for den aktuelle leverandøren. Den som spør trenger ikke å vite om dette ligger sentralt eller lokalt. 3. Leverandøren gjør et søk i sitt lokale system og returnerer interne sporingsdata. Svaret kan også være underlagt en manuell vurdering hos leverandøren. 4. Basert på svar fra leverandør finner man en eller flere mulige primærprodusenter og gjør et søk i esporingsløsningen etter sporingsdata som er overført fra aktuelle produsenter. 5.2.2 Spørring initiert av aktørene Føderering gir også mulighet for aktørene til å spørre etter data i nettverket, uavhengig av om disse ligger i den sentrale løsningen eller hos en annen aktør. Dette kan både være interne sporingsdata eller andre typer data som f.eks. salgsdata eller produksjonsdata. Dette forutsetter da at denne type data er spesifisert i datamodellen i tillegg til ordinære sporingsdata. Følgende type spørringer er aktuelle å foreta for aktørene: Spørring etter interne sporingsdata hos en gitt aktør Spørring etter tilleggsdata hos en gitt aktør Spørring etter sporingsdata eller tilleggsdata hos ukjent kilde Under er vist et eksempel der en grossist hos en matvarekjede spør etter lagerbeholdning på en vare hos en leverandør. Begge har avtale om føderering. 1. Grossisten sender en spørring til esporingsløsningen med forespørsel om lagerbeholdning for en aktuell type vare fra en gitt leverandør. 2. esporingsløsningen sjekker om grossisten har rettigheter til å spørre etter informasjon hos aktuell leverandør og om leverandøren har åpnet for spørring i sitt system. 3. esporingsløsningen finner adressen til leverandøren og gjør en spørring etter lagerbeholdning for aktuell vare. 4. Leverandøren gjør et søk i sitt lokale system og returnerer lagerbeholdning til esporingsløsningen. 5. esporingsløsningen videreformidler svaret til grossisten som svar på forespørselen uten at det lagres noe informasjon i den sentrale løsningen esporing 02.05.2011 Side 16 av 16