Fælleskommunal Filudveksling

Når der skal udveksles filer via infrastrukturen foregår det som oftest via Filudveksling (SFTP). Infrastrukturens Filudveksling (SFTP) er derfor også en teknisk betingelse for at bruge en lang række af infrastrukturens integrationer.

Fælleskommunal Filudveksling håndterer formidling af filer fra afsender til en modtager. Filudveksling flytter filer mellem forskellige fagsystemer i og på tværs af kommuner.

Filudveksling har til formål at give fagsystemer mulighed for at aflevere og hente filer på en dekoblet og ensartet måde på tværs af fagområder og systemer.

Filudveksling rummer som udgangspunkt to centrale funktioner, hvor fagsystemet enten henter eller afleverer filer.

I den enkelte integration kan du finde de filudvekslingsoplysninger, der er specifikke for den pågældende integration, eks. Triggerfil-indhold og hvilken type af Filudveksling der benyttes, eks. dynamisk rutning.

Vejledninger

 
  • ”Filudveksling: Serviceaftaler og Ruter” fungerer som introduktion til den nye funktionalitet. Med udgangspunkt i et konkret eksempel, illustrerer denne pixibog, hvordan serviceaftalerne for både det afsendende og modtagende it-system udfyldes, samt hvordan den automatisk oprettede fil-rute efterfølgende administreres i selvbetjeningsløsningen ”Ruteadministration”. Bogen indeholder desuden en FAQ-sektion, der besvarer de hyppigst stillede spørgsmål.
     
  • "Vejledning til Serviceplatformens SFTP-service" beskriver i detaljer alle facetter af løsningen Filudveksling – fra SSH-nøgler over trigger-filer til serviceaftaler og ruter. Vejledningen er opdaterede med afsnit, der beskriver den nye logik bag serviceaftaler og fil-ruter, herunder en detaljeret beskrivelse af logikken, som sammenligner serviceaftaler og automatisk opretter fil-ruter ved match. Særligt relevante afsnit er: 3.3. ”Ruter”, 5.4 ”Dynamisk routing” og 5.4.1 ”Oprettelse af dynamiske routingregler”.
     
  • "Vejledning til Ruteadministration" beskriver, hvorledes man via Ruteadministration kan se og administrere fil-ruter (efter disse er oprettet).
     

Filudveksling som en teknisk betingelse

For at kunne benytte en række af integrationer i den fælleskommunale infrastruktur er det nødvendigt, at du enten kan afsende og/eller modtage filer via filudveksling. Det fremgår af de enkelte integrationsbeskrivelser, hvis de benytter filudveksling.

Bemærk, at der p.t. anvendes to forskellige former for filudveksling i den fælleskommunale infrastruktur: Simpel og rutebaseret (dynamisk rutning). Gradvist vil simpel filudveksling dog blive udfaset og erstattet af rutebaseret filudveksling. Nyere integrationer vil derfor kun kunne anvendes med rutebaseret filudveksling.

Filudveksling FAQ

Vi anbefaler, at du starter med at læse pixibogen ”Filudveksling: Serviceaftaler og Ruter".

Pixibogen beskriver ikke blot koncepterne bag fil-ruter, men illustrerer også skærmbillede-for-skærmbillede, hvordan serviceaftaler sammensættes, samt hvordan fil-ruter kan administreres i Ruteadministration.

Ved at læse pixibogen får du indblik i de opgaver, du som myndighed eller leverandør skal løse, ligesom du får indblik i, hvordan disse ”spiller” sammen med øvrige parters opgaver.

Generelt vil disse vejledninger og dokumenter være nyttige:

  1. ”Vejledning til anvendelse af Serviceplatformen SFTP Service”: Denne vejledning beskriver i detaljer mekanismerne i Filudveksling, inkl. trigger-filer, serviceaftaler og ikke mindst fil-ruter. Ønsker du at forstå specifikke detaljer om serviceaftalers sammenspil eller indblik i logikken bag oprettelsen af fil-ruter, bør du læse vejledningen. 
  2. ”Vejledning til Ruteadministration”: Denne vejledning beskriver anvendelse af selvbetjeningsløsningen Ruteadministration til administration af fil-ruter, efter de er oprettet.
  3. Integrationsbeskrivelser: Anvendelse af Filudveksling er i et vist omfang integrationsspecifik. Fx specificerer de enkelte integrationer mange af de informationer, der benyttes i serviceaftaler, herunder InfRef samt afsendende- og modtagende myndighed. Informationen findes typisk i integrationsbeskrivelsen for pågældende integration. I integrationsbeskrivelsen er der ofte også en beskrivelse af den data, der udveksles via filer, samt evt. filnavnekonventioner.

Der kan være flere årsager, men de typiske forklaringer på, at der ikke er oprettet en fil-rute endnu, er:

  • Manglende serviceaftaler: Både afsendersystem og modtagersystem skal have en relevant serviceaftale, og begge aftaler skal være godkendte.
  • Forkerte værdier: Værdier i afsendersystems og modtagersystems serviceaftaler skal være korrekte – ellers ”matcher” de ikke hinanden og ruten oprettes ikke.
  • Forsinkelse: Ruter oprettes som regel kort tid efter sidste serviceaftale godkendes, men der kan være en forsinkelse på op til 30 minutter.

Alle kommuner har udpeget en ”Ruteadministrator” (jf. KOMBITs rollegalleri), der kan hjælpe med at koordinere arbejdet vedr. fil-ruter, herunder sikre, at både afsender- og modtagersystemer anmoder om serviceaftaler.

I Fælleskommunalt Administrationsmodulet er det p.t. ikke muligt at kombinere servicerne ”FilAflever” eller ”FilHent” med andre services i én serviceaftale. 

Hvis du skal bruge en integration, hvor der fx både hentes filer og kaldes webservices, er du derfor nødt til at indgå separate serviceaftaler for ”Filhent” og de øvrige services.

Ofte vil det være tilfældet, men ikke altid, da det afhænger af den specifikke integration. 

Fx er nogle integrationer baseret på, at data udveksles inden for samme myndighed (dvs. afsendende myndighed er samme som modtagende), hvorimod andre er baseret på, at data udveksles på tværs af myndigheder. Det betyder, at der vil være situationer, hvor der er større forskelle mellem et afsendersystems og et modtagersystems serviceaftaler.

Lad os som eksempel antage, at data sendes fra Udbetaling Danmark (UDK) til Frederikshavn Kommune:

Afsendersystem
Fordi afsendersystemet skal aflevere data på vegne af UDK, skal serviceaftalen indgås med UDK. Da data skal modtages af Frederikshavn Kommune, skal kommunen fremgå som myndighed i feltet ”Tilladte modtagermyndigheder”.

Modtagersystem
Fordi modtagersystemet skal modtage data på vegne af Frederikshavn Kommune, skal serviceaftalen indgås med Frederikshavn Kommune. Da data skal afsendes af UDK, skal UDK fremgå som myndighed i feltet ”Tilladte afsendermyndigheder”.

I udgangspunktet skal alle nye fil-ruter aktiveres manuelt – naturligvis forudsat, at der skal/bør udveksles filer via dem. Der kan dog være undtagelser, hvor aktivering af nye fil-ruter sker automatisk. Det afhænger af den specifikke integration/den enkelte InfRef.

Der kan være flere årsager, men de typiske er:

Brugerrolle: I Ruteadministration benyttes brugerrollerne ”Rute Administrator” og ”Rute Supporter”, men kun førstnævnte giver rettigheder til at ændre en fil-rute.

Modtagende myndighed: En fil-rute kan kun ændres af brugere, der er tilknyttet den modtagende myndighed. Hvis en fil-rute fx har Udbetaling Danmark og Guldborgsund Kommune som hhv. afsendende og modtagende myndighed, vil kun medarbejdere fra Guldborgsund Kommune kunne ændre ruten.

Legacy fil-rute: Fil-ruter, der er oprettet vha. de tidligere anvendte bestillingsblanketter, betragtes som ”legacy fil-ruter”. Disse ruter kan stadig bruges til at udveksle fil og vil kunne ses i Ruteadministration, men kun i ”læsetilstand”. Legacy fil-ruter kan dog konverteres til non-legacy fil-ruter (se ”Vejledning til Serviceplatformens SFTP service” for mere information om legacy fil-ruter og konvertering).

”Kollision” med eksisterende implicit fil-rute: Fil-ruter findes i to varianter, implicit og eksplicit. For implicitte fil-ruter er det et krav, at de ikke må kollidere med hinanden, da Fælleskommunal Filudveksling i så fald ikke kan fremsøge det korrekte modtagersystem. Hvis en implicit fil-rute kolliderer med en anden, vil den ikke kunne gemmes med tilstand ”aktiv”.

Fejlbeskeden udløses fordi fil-ruten ”kolliderer” med en anden fil-rute. Det er et problem, hvis implicitte fil-ruter kolliderer, fordi Fælleskommunal Filudveksling så ikke kan finde det rette modtagersystem:

Når filer sendes gennem en implicit rute, behøver et afsendersystem ikke angive et modtagersystem i trigger-filen. I stedet bruger Filudveksling trigger-filen til at finde en fil-rute, der indeholder information om modtagersystemet og derfor kan bestemme modtagersystemet entydigt.

For at det kan lade sig gøre, må der kun være ét resultat, når Filudveksling søger efter fil-ruten. Hvis søgningen resulterer i flere fil-ruter (og dermed flere modtagersystemer), kan Filudveksling ikke entydigt bestemme korrekt modtagersystem. Derfor kan du ikke få lov til at gemme ændringer på en implicit fil-rute, hvis ændringerne betyder, at fil-ruten kolliderer med en anden fil-rute.

For at løse problemet, skal du typisk justere de kolliderende fil-ruters perioder. Hvis din myndighed fx udskifter et modtagersystem, skal datoerne justeres, så de er forskellige. Dvs. at fx ved udskiftning ved et årsskifte kan slutdato for fil-ruter til det gamle system angives til 2025-12-31 og startdato på fil-ruter til det nye system angives til 2026-01-01. Derefter kan alle fil-ruter gemmes som aktive.

Bemærk, at dette problem ikke opstår for eksplicitte fil-ruter, fordi afsendersystemet her angiver modtagersystemet i trigger-filen. Filudveksling behøver derfor ikke søge efter modtagersystemet og skal blot sikre, at filen matcher mindst én fil-rute (og dermed er tilladt).

Delegeringsfunktionaliteten gør det muligt for myndigheder at uddelegere administration af ruter til fx leverandører. 

Delegeringen fungerer på "InfRef-niveau”. Hvis en kommune fx uddelegerer en specifik InfRef til en leverandør, vil den pågældende leverandør kunne se samtlige ruter, der vedrører InfRef'en, og hvor kommunen er afsendende eller modtagende myndighed. I de tilfælde, hvor kommunen er modtagende myndighed, vil leverandøren også kunne foretage ændringer af ruten.

Delegering kan især være nyttig i forbindelse med leverandørskifte, hvor fil-ruter til det gamle system skal sættes til udløb, og fil-ruter til det nye system skal sættes til at starte umiddelbart efter.

Disse informationer er integrationsspecifikke og vil derfor kunne findes i dokumentationen for den pågældende integration, typisk   i integrationsbeskrivelsen. Det er i øvrigt de samme informationer, der tidligere blev benyttet i den ”gamle” bestillingsblanket til oprettelse af fil-ruter.