Referencedatamodelprojektet. Integrationsmønstre. Version oktober 2012

Transkript

1 Referencedatamodelprojektet Integrationsmønstre Version oktober 2012

2 ISBN: --- Titel: Udgiver: DDV integrationsmønstre DANVA Vandhuset Godthåbsvej Skanderborg Udarbejdet af: DDV projektgruppen i samarbejde med Kurt Hansen, Strand & Donslund A/S

3 Indholdsfortegnelse 1 Indledning Projektets anledning og baggrund Målgruppe og læsevejledning Proces Metode fra OIO EA 3 2 Oversigt over DDV integrationsmønstrene 4 3 De enkelte DDV integrationsmønstre Asynkron service Synkron service Fil baseret Kø Publish/Subscribe Event Replikering 22 4 Støttemønstre Read only cache Systemkonvertering 26 5 Ikke godkendte integrationsmønstre Database connection Human copy/paste API 31 Appendiks: Ordliste 33 I

4 Revisionshistorik Ver. Dato Ændret af: Ændringsbeskrivelse Kurt Hansen Dokument oprettet på basis af de tre gennemførte arbejdsmøder Kurt Hansen Høringsversion Kurt Hansen Opdatering efter høring Peter Huber Endelig udgave II

5 1 Indledning 1.1 Projektets anledning og baggrund DANVAs Digitale Vandselskab (DDV) har igangsat Referencedatamodelprojektet. Projektet skal i overordnede termer beskrive rammerne og principperne for den fremadrettede digitaliseringsindsats i Det Digitale Vandselskab. Alt arbejde med standardisering og datamodellering i DANVA regi afventer resultaterne af dette projekt. Projektets scope i relation til metode- og arkitekturleverancer er afgrænset som angivet i tilbuddet fra Strand & Donslund. Leverancerne i projektet er jf. dette tilbud: 1. DDV principper - Udarbejdelse af en række principper der kan bruges som redskab til at sikre retning i digitaliseringsarbejdet i sektoren og til at støtte beslutningsprocessen i forbindelse med tværgående governance, og i de enkelte projekter der følger integrationsmetoden 2. DDV integrationsmetode Udarbejdelse af en struktureret beskrivelse af en fremgangsmåde til digitaliseringsopgaver i sektoren der behandler de fire primære aspekter: Analyse af arbejdsgange, Datamodellering, Specifikation af data-service samt Valg af integrationsmønstre. 3. DDV integrationsmønstre Udarbejdelse af et katalog over integrationsmønstre som danner grundlag for konkrete integrationsløsninger i sektoren. Et integrationsmønster egner sig typisk til brug ud fra givne omstændigheder som gives af arbejdsgangen, det konkrete informationsbehov mv. 4. Illustrative eksempler Udarbejdelse af illustrative eksempler på de resultater som brug af integrationsmetoden leder frem til. 5. DDV-governance-model Udarbejdelse af en governance-model der skal sikre overensstemmelse mellem resultaterne i de fremtidige modeller og standarder på den ene side, og de rammer og principper der etableres i projektet på den anden side. 6. Anbefalingsleverancer Evt. udarbejdelse af et særskilt notat vedr. de anbefalingsleverancer der efterspørges i afsnit 2.8 i DANVAs projektbeskrivelse. Dette dokument udgør tredje projektleverance: DDV integrationsmønstre som er en egentlig arkitekturleverance i modsætning til fx DDV integrationsmetoden som bliver vejledende for DDVs arkitekturarbejde. Integrationsmønstrene skal forvaltes jf. DDV-governance-modellen. 1.2 Målgruppe og læsevejledning Målgruppen er DANVA ledelsen, DDV styregruppen, leverandører, alle deltagere i DDV arkitekturarbejde og alle deltagere i selskabernes digitaliseringsarbejde. Integrationsmønstrene læses bedst efter først at have orienteret sig i Målbillede for DDV inklusiv ordliste (under udarbejdelse). Ordliste i Appendiks DDV principperne DDV integrationsmetoden eller et resume Side 1 af 33

6 Dokumentet hører til i DDV enterprise arkitektur som vist på figur 1 i OIO EA reolen (Konceptuelt & Applikation). Figur 1: DDV vejledninger og arkitekturbeskrivelser i den DDV tilpassede EA reol Figur 1 viser hvor DDV integrationsmønstre hører til i de overordnede arkitekturbeskrivelser, der styrer arkitekturen på reolhylden nedenunder i Applikationssøjlen. Integrationsmønstrene vælges for hver datasnitflade som DDV arkitekturen standardiserer, Læs mere om OIO EA i indledningen og appendiks i DDV integrationsmetoden. Læs mere om brugen af mønstrene i DDV integrationsmetodens kapitel Proces Opstillingen af integrationsmønstrene er foregået i projektgruppen: 1. arbejdsmøde afholdt den 28. august 2012 hos DANVA: Identifikation af integrationsmønstre 2. arbejdsmøde afholdt den 6. september 2012 hos KE: Bearbejdning af integrationsmønstrene 3. arbejdsmøde afholdt den 13. september 2012 hos KE: Bearbejdning af beskrivelsen af hvert integrationsmønster Side 2 af 33

7 Integrationsmønstrene er beskrevet mellem møderne og efterfølgende redigeret af Strand & Donslund. Efter høringen er mønstrene opdateret ud fra de indkomne høringssvar. 1.4 Metode fra OIO EA DDV integrationsmønstrene er udarbejdet i henhold til den fællesoffentlige arkitekturramme, OIO EA ( og specifikt ea.oio.dk). Til identifikation og formulering af DDV integrationsmønstrene, udover projektdeltagernes viden og erfaring, er især følgende DDV arkitekturprincipper benyttet: Princip 10: It-løsninger skal gøres mere integrer- og udskiftsbare gennem standardiserede snitflader og integrationsmønstre Princip 11: DDV databeskrivelser skal omfatte veldefineret struktur, betydning, kvalitet og formål Princip 12: DDV data skal udveksles med standardiseret struktur og efter vedtagne integrationsmønstre Side 3 af 33

8 2 Oversigt over DDV integrationsmønstrene De godkendte DDV integrationsmønstre er vist i figur 2 og beskrevet i afsnittene i kapitel 3. Derefter følger kapitel 4 med støttemønstre og kapitel 5 med ikke godkendte mønstre. Figur 2: Godkendte DDV integrationsmønstre (ikoner) Side 4 af 33

9 3 De enkelte DDV integrationsmønstre 3.1 Asynkron service Navn Asynkron service Ikon Beskrivelse Asynkron service er et asynkront funktionskald mellem to domæner ( en Anvender og en Udstiller), som hver især kan befinde sig på forskelligartede og distribuerede hard- og software platforme. Anvender kalder en service hos en Udstiller der udfører den tilhørende datafunktion og sender et svar tilbage, hvor datafunktion kan være en læsning eller en opdatering. Anvender afventer IKKE datasvar fra Udstiller inden yderligere arbejde påbegyndes, men fortsætter eller igangsætter nyt arbejde. Anvendelse Asynkron service baseret integration er velegnet i situationer hvor der er behov for høj dataaktualitet og små datamængder, men hvor der gerne må være en mindre tidsmæssig forskydning mellem Kald og Svar. Er velegnet i situationer hvor Udstiller er en kritisk komponent og hvor Anvender ikke bør låse/binde de kritiske ressourcer under behandlingen af kaldet. Hvis belastning af Udstiller er af varierende karakter og med høje spidbelastninger bør dette integrationsmønster vælges. Anvendes i situationer hvor Anvender har mulighed for at behandle Kald og Svar adskilt og har mekanismer til at håndtere det asynkrone svar. Specielt velegnet hvor der skal indhentes data fra flere domæner da alle kald kan initieres næsten samtidig, og det derfor kun vil være det tidsmæssigt længste kald der er afgørende for færdiggørelse af forløbet. Asynkron service understøtter også indkapsling og afkobling af Anvender og Udstiller der sikrer at de hver især kan ændre deres interne struktur og design, så længe at den grænseflade de Side 5 af 33

10 deler i forbindelse med integrationen forbliver uændret. Virkemåde Den vigtigste egenskab for det asynkrone service mønster er at sikre at beskeder bliver modtaget og processeret af netop én Modtager (Udstiller), og at denne er kendt af Afsender (Anvender). Kort beskrevet virker mønsteret på følgende måde: Afsender opbygger en kald-besked, sender beskeden, og fortsætter umiddelbart derefter med andet arbejde, f.eks. initierer et nyt kald. Se nedenstående sekvensdiagram. Modtageren konstaterer at kald-besked er modtaget. Der er ikke nødvendigvis et tidsmæssigt sammenfald mellem hvornår besked modtages og hvornår det konstateres af Modtageren. Modtageren behandler kald-beskeden og afsender svar når behandling er færdiggjort. Afsender modtager svar-besked, og behandler denne når det passer ind i forhold til igangværende arbejde. En variant på dette mønster er at Afsender domænet ikke ønsker svar fra Modtager-domænet, således at mønsteret kun består af første trin. Dette er også kendt under navnet fire and forget. Eksempel på anvendelse kan være opdatering af status-information. Overvejelser Når Asynkron service mønsteret vælges, er der en række overvejelser der skal gøres ved ibrugtagning. Alt afhængig af den forretnings- og løsningsmæssige kontekst, som mønsteret aktuelt skal benyttes i, er der forskellige valg der kan træffes. De enkelte valg har igen nogle afledte Side 6 af 33

11 forhold, beskrevet i nedenstående, som også skal overvejes. Teknologivarianter Garanteret aflevering og behov for dette er en af kvaliteterne der skal overvejes nøje, da dette omfatter både kald og svar-besked. Afhængig af den ønskede leveringsgaranti Exactly-Once, At-least-Once eller At-Most-Once, skal evt. håndtering af Idempotence hos Modtageren analyseres og understøttes. Hvis idempotence skal understøttes, vil det få afledte konsekvenser for service kontrakten, hvilket Afsender naturligvis skal overholde. Beskedrækkefølge. Afsendelse af beskeder og behandling hos modtager domænet er afkoblet fra hinanden. Er der behov for at beskeder behandles i samme rækkefølge som de er afsendt i, skal der evt. aftales håndtering af end-to-end beskedrækkefølge mellem Afsender og Modtager. Der er forskellige metodikker som kan vælges herunder, brug af sekvensnumre, tidsstempling etc. Logning og overvågning. Afkoblingen mellem Afsender og Modtager kan medføre situationer, hvor en afsendt besked ikke kan modtages. Denne problemstilling kaldes for Dead letter. Bemærk at dette gælder for både kald og svar. Dette stiller igen markante krav til overvågning og logning, således at Dead letter beskeder bliver håndteret, så datatab undgås. Der skal afdækkes hvordan overvågning opdager at en besked er havnet i en Dead letter situation, samt hvilke tiltag skal der igangsættes når situationen opstår. Nogle af de spørgsmål der bør besvares/tages stilling til er f.eks.: skal der igangsættes en manual proces der bærer besked igennem, eller skal besked ud på en fejlliste. Ved netværksfejl og lign. bør der være en automatisk retransmissionsmekanisme fra Dead letter, evt. med intelligent styring af forsøg Invalid messages stiller også en række krav til Asynkron service mønsteret. Et eksempel på en Invalid Message er en modtaget besked hvis indhold er formateret forkert. Da mønsteret har en implicit afkobling mellem afsender og modtager på det tidspunkt hvor beskeden er modtaget, men endnu ikke behandlet, kan modtageren ikke informere afsender om problemstillingen. Hvis den aktuelle implementering også håndterer ordering af beskeder, skal det på forhånd være afklaret hvordan en invalid besked skal håndteres og hvilken påvirkning på rækkefølgen af beskeder den må få. Hvis beskeden bare droppes, giver det udfordringer i forhold sekvens, da der så er huller i processeringen af beskeder. Besked levetid (Message expiration). Hvor længe skal en besked vente på at blive afleveret til modtageren, og skal en besked der ikke kan leveres fjernes eller afleveres på en Dead letter channel. Sikkerhedsovervejelser er de samme som beskrevet under Synkron services, dog med den udvidelse at da kald og svar reelt sendes i hver sin session, skal disse vurderes enkeltvis og ikke nødvendigvis have samme sikkerhedsniveau. Asynkron service mønstret understøttes af forskellige teknologier: Web Services (SOAP over HTTP). Åben standard REST. Åben standard Platformsspecifikke teknologivarianter.net Remoting. Microsoft teknologi RMI. Java teknologi Referencer Henvisninger til eksterne beskrivelser og eksempler på implementeringer. Enterprise Integration Patterns : Asynchronous Callback Side 7 af 33

12 Service Design Patterns : Asynchronous Response Handler Metadata Metadata for beskrivelsen: Status (gældende, forslag): Gældende Version: 1.0 Udarbejdet af: Kurt Hansen, S&D Ændringslog: Oprettet Opdateret med høringssvar 3.2 Synkron service Navn Synkron service Ikon Beskrivelse Synkron service er et synkront funktionskald mellem to domæner, en Udstiller og en Anvender, som hver især kan befinde sig på forskelligartede og distribuerede hard- og software platforme. Anvender kalder en service hos en Udstiller der udfører den tilhørende datafunktion og sender et svar tilbage, hvor datafunktion kan være en læsning eller en opdatering. Anvender afventer datasvar fra Udstiller inden yderligere arbejde påbegyndes. Anvendelse Synkron service er et velegnet integrationsmønster når en Anvender har behov for at udføre en datafunktion hos en Udstiller, og hvor Anvender har brug for resultatet af funktionen inden yderligere arbejde kan påbegyndes, eller det igangværende arbejde fortsættes. Synkron service baseret integration er velegnet i situationer hvor der er behov for høj dataaktualitet og små datamængder. Synkron service understøtter en indkapsling og afkobling af Anvender og Udstiller der sikrer at de hver især kan ændre deres interne struktur og design, så længe at den grænseflade de deler i forbindelse med integrationen forbliver uændret. Hvis integrationsbehovet omfatter mange små data ændringer/hændelser, og der ikke er Side 8 af 33

13 et ultimativt krav om øjeblikkeligt svar, bør integrationsmønstre der giver en løsere form for integration så som Asynkron service eller Publish-Subscribe overvejes. Virkemåde Set ud fra Anvender og Udstiller domænerne fungerer synkron service grundlæggende som et lokalt funktionskald hvor Anvender og Udstiller er afkoblet vha. et interface. Udstiller domænet (applikationen) udstiller et Interface der definerer kontrakten som Anvender skal overholde, og hvor der kan være en eller flere Anvendere (brugere af Interfacet). Interfacet kan f.eks. være defineret som en Web Service specifikation (WSDL). Når en Anvender ønsker at kalde en datafunktion hos Udstiller opbygges der en parameterstruktur der overholder kontrakten i interfacet, f.eks. XML besked der overholder XML Skemaet defineret i WSDL kontrakten, sender denne over en given kommunikations protokol, f.eks. SOAP over HTTP. og afventer et svar/resultat. Udstiller reagerer ved at kalde en matchende intern funktion/procedure, og sender resultatet tilbage til Anvenderen i henhold til kontrakten. Svaret sendes over den samme kommunikations protokol som beskeden/kaldet blev modtaget via. Kontrakten omfatter en teknisk header, forretningsmæssig header, fx kontekst (hvis relevant) og forretningsmæssige fejlkoder, evt. genbrugt på tværs af services. Side 9 af 33

14 Overvejelser Synkron service mønsteret er ofte det umiddelbare valg af integrationsmønster, da udviklere ofte tænker i funktionskald. Naturen i synkron service mønsteret medfører også at nogle af de emner som skal overvejes ved integration besvares implicit eller kræver forholdsvis få overvejelser. Første overvejelser der skal gøres er om asynkron integrationsmønster kan anvendes. Sekvens og ordering af kald styres implicit med Synkron service ved at Anvenderen, på et givet tidspunkt, kun giver mulighed for ét udestående kald. Afleveringsgaranti. Ved Synkron service kan afleveringsgarantien implementeres som At most once ved at Anvender simpelthen ignorerer fejl. At least once opnås ved at Anvender foretager automatisk gensendelse, Exactly Once afleveringsgaranti kan realiseres ved at Anvender spørger modtager om status (hvis dette er muligt) når en fejl er konstateret og eventuelt gensender beskeden. Alternativt kan Exactly Once realiseres ved at Anvender altid foretager gensendelse (At Least Once) kombineret med idempotence hos Udstiller. Fejlsituationer løses ofte også som en integreret del af brugen af mønsteret, idet kaldet umiddelbart returnerer en fejl i stedet for et resultat fra den udførte funktion. Dette medfører at emner som Dead letter og parameterfejl (Invalid messages), behandles ved håndtering af fejl-svar fra Synkron service kaldet. Side 10 af 33

15 Teknologivarianter Referencer Håndtering af idempotence skal overvejes for Synkron service mønsteret, da svar fra Udstiller stadig kan gå tabt, og resultere i at Anvenderen står med en time-out problematik. Synkron service mønsteret medfører at der skabes temporale afhængigheder mellem applikationer/domæner. Anvender og Udstiller skal være tilgængelige samtidigt på kald og svar tidspunkt. Hvis begge parter både agerer som Anvender og Udstiller, kan dette medføre cykliske afhængigheder hvor flere applikationer/domæner afhænger af hinanden for at kunne udføre en fælles opgave (processer) og potentielt medføre en dead-lock. For at undgå disse hændelser skal en Anvender reelt kende hele kalde-hierarkiet. Samtidig kan ændringer i en enkelt applikation der indgår i kalde-hierarkiet potentielt få konsekvenser for hele processen og dermed de andre applikationer. Da der indgår 2 eller flere parter ved brug af Synkron service integrationsmønsteret, skal det overvejes hvordan der evt. kan skabes en logning som bidrager til at skabe sammenhængende overvågning. Sikkerhed er en integreret del af realiseringen af mønsteret, da Anvenderen skal overholde de sikkerhedsmæssige forskrifter og definitioner som Udstilleren har defineret. Synkron service mønstret understøttes af forskellige teknologier: Web Services (SOAP over HTTP). Åben standard REST. Åben standard Platformsspecifikke teknologivarianter.net Remoting. Microsoft teknologi RMI. Java teknologi Henvisninger til eksterne beskrivelser og eksempler på implementeringer. Service Design Patterns : Request/Response Metadata Metadata for beskrivelsen: Status (gældende, forslag): Gældende Version: 1.0 Udarbejdet af: Kurt Hansen, S&D Ændringslog: Oprettet Opdateret med høringssvar Side 11 af 33

16 3.3 Fil baseret Navn Fil baseret Ikon Beskrivelse Anvendelse Filbaseret kommunikation er en asynkron måde at udveksle data mellem 2 eller flere parter. Afsender-domænet producerer en fil som gøres tilgængeligt for Modtager-domænet der efterfølgende kan behandle læse og behandle data-indholdet af filen. Der er kun ét domæne der kan producere filen. Fil baseret integration er en simpel måde at flytte data fra et domæne til et andet uden behov for speciel software eller hardware, da filer er en forholdsvis universal måde at udveksle data på tværs af platforme og teknologier. Fil baseret integration er velegnet til overførsel af data i situationer hvor der ikke stilles høje krav til data aktualitet, og oplagt hvis der er behov for at overføre store datamængder på én gang, f.eks. TV-inspektioner. Kan anvendes ved dataleverancer fra/til eksterne parter, specielt hvis det drejer sig om større datamængder. Også velegnet til lavfrekvente dataoverførsler fra eksterne parter, og hvor de teknologiske muligheder er begrænsede. Virkemåde Når en bestemt hændelse indtræffer i Afsender domænet, f.eks. afslutningen af dagen, måneden, kvartalet, året, skriver Afsender domænet de relevante data til en fil på det lokale fil system i et aftalt format og navngivningsmønster. Ud fra en hændelse, f.eks. tidsinterval eller registrering af en afsluttet filskrivning, læser en eller flere Modtager domæner data fra filen, og opdaterer deres lokale datakilde med disse data. Ved at benytte filer til integrationen sikres en afkobling mellem Afsender og Modtagere, da de ikke behøver at kende til hinandens interne data strukturer, men skal være enige om et fælles format og struktur for filen, f.eks. XML med tilhørende XML Schema eller komma-separeret. Overvejelser Fil baseret integration har mange af de samme karakteristika som integration via beskeder. En Side 12 af 33

17 fil kan betragtes som én besked der udveksles mellem Afsender og Modtager, så de forhold der skal overvejes har nogle af de samme karakteristika. Når fil formatet og strukturen er aftalt, skal Afsender og Modtager enes om de øvrige forhold der skal gælde ved den filbaserede integration. Dette involverer som minimum en fælles fil navngivning og placeringsstruktur. I nedenstående liste er beskrevet en række overvejelser som skal gennemtænkes og evt. udarbejdes løsninger for: At en fil ikke fejlagtigt sendes mere end en gang. Det skal overvejes om det skal være Exactly Once eller At Least Once. Ved At Least Once skal idempotence overvejes. Hvis indholdet i filerne skal behandles i samme rækkefølge som det er produceret, skal filnavne og struktur udarbejdes så de understøtter sekvens/ordering, således at Modtageren aldrig er i tvivl om korrekt rækkefølge. Afsender skal sikre unikke filnavne, så nye filer ikke kolliderer og overskriver gamle filer der endnu ikke er læst (/Garanteret aflevering). Afsender og Modtager(e) skal enes om en låsnings eller tidskonvention, således at en Modtager ikke læser filen mens Afsenderen er i gang med at skrive den (Transaktionsgrænser). Der skal udpeges et ansvarligt domæne som skal slette gamle filer når de ikke længere skal bruges. Logning over behandlede filer er et vigtig element, for at kunne gennemføre sletning af gamle filer uden at risikere datatab. Hvis fil placeringen ikke kan læses af alle Modtagere, skal der udpeges et ansvarligt domæne der har til opgave at flytte filen fra ét filsystem til et andet, dvs. der skal implementeres en transportmekaniske/form der også skal forholde sig til Afleveringsgarantier. Afhængigt af det filformat der benyttes, skal der tilvejebringes en mekanisme der kan sikre at fil skrivning, læsning og overførsel sker uden fejl, f.eks. vha. en MD5 checksum i en header/ fil, kontrol fil etc. (Reliability). Et samlet koncept for Afsender og Modtager der understøtter overvågning af det samlede fil flow og behandling skal etableres. Sikkerhed er som regel afkoblet i forhold til den konkrete implementering af dette mønster. Adgang til f.eks. filsystemer skal sættes rigtig op, for at det kun er den/de ønskede modtagere af filen der kan læse dem, og det samme gælder mht. skriverettigheder for Afsenderen. Transporteres filer via FTP/HTTP skal de samme sikkerhedsforhold overvejes. Fil baseret integration fungerer alene som data integration. Hvis der er behov for at integrere logik bør det overvejes at benytte Asynkron service mønsteret Teknologivarianter Referencer Fil baseret integrations mønstret understøttes af forskellige teknologier: FTP, i forskellige varianter (FTP, FTPS, SFTP) HTTP Netværks-drev/Fil share Fil-delingstjenester: Dropbox og lignende tjenester Henvisninger til eksterne beskrivelser og eksempler på implementeringer. Enterprise Integration Patterns : File transfer Side 13 af 33

18 Metadata Metadata for beskrivelsen: Status (gældende, forslag): Gældende Version: 1.0 Udarbejdet af: Kurt Hansen, S&D Ændringslog: Oprettet Opdateret med høringssvar 3.4 Kø Navn Kø Ikon Beskrivelse Anvendelse Mønsteret er en punkt til punkt integration, altså mellem 2 navngivne domæner. Der er en afsender der lægger beskeder på køen, og der én modtager der læser og tager beskeder af køen. Beskeder venter på køen indtil modtager er klar til at behandle disse. Kø integrationsmønsteret er en god måde for Afsender domænet at aflevere data til modtagerdomænet på i situationer hvor modtagerdomænet ikke behøver at være klar til at modtage eller behandle data på afsendelsestidspunktet. Mønsteret er også velegnet i situationer hvor Modtagerdomænet selv vil kontrollere hvornår data modtages og behandles. Mønsteret understøtter forhold hvor Afsender vil være sikker på at data afleveres, garanteret leverance, uden at skulle kommunikere direkte med Modtager. Et eksempel på dette er data indsamlet på en Logger (håndholdt enhed til dataopsamling). Velegnet i situationer hvor Afsender inden for et kortere tidsrum generer et stort antal beskeder, som Modtager er længere tid om at behandle, dvs. integrationsmønstret giver en belastningsudjævning for Modtager-domænet. Integrationsmønsteret giver fuld afkobling mellem Afsender og Modtager domænerne. Side 14 af 33

19 Sikkerhed for at beskeder modtages og er i sekvens(ordering) Køen ejes af det domæne der har ejerskab for de data der sendes. I det fleste tilfælde vil dette være Modtager domænet. Virkemåde Integrationsmønsteret er karakteriseret ved at det består af 2 integrationspunkter. 1 punkt hvor data lægges på køen, og 1 punkt hvor data læses fra køen. Integrationsmønstreret virker ved at Afsenderdomænet skriver data til køen, og betegnes som der lægges en besked på køen. Afsenderdomænet kan kun skrive til køen. Afsenderdomænet kan principielt lægge ubegrænset antal beskeder på køen. Køen gemmer data indtil Modtagerdomænet er klar til at modtage data (beskeden), og gør dem tilgængelig ved det integrationspunkt som Modtagerdomænet tilgår. Modtagerdomænet læser data fra køen og sletter beskeden. Modtagerdomænet kan læse og slette beskeder. Læsning og sletning af beskeder kan gennemføres uafhængigt af hinanden. Afsender kan principielt lægge lige så mange beskeder på køen som det passer i forhold til den givne integrationskontekst, uden at skulle tage højde for Modtagerens kapacitet. Ønskes data udvekslet begge veje mellem domænerne, skal der implementeres to instanser af integrationsmønsteret. Hvis der er flere afsendere, vil hver afsender have sin egen kø som beskeder lægges på. Overvejelser Kø integrationsmønsteret giver en fuld afkobling mellem de to domæner, hvilket afleder en række forhold for køen og beskederne som kræver overvejelser og beslutninger omkring. Sekvens og ordering af beskeder skal vælges ved opsætning af køen, og vil være statiske attributter for denne. Afleveringsgaranti. Ved Kø-integrationsmønsteret kan afleveringsgarantien implementeres gennem brug af faciliteter i den underliggende kø-infrastruktur, og ved at opsætte de to integrationspunkter som køen udstiller til at være transaktionelle, så læsninger og skrivninger fra/til køen sker som transaktioner. Kø-infrastrukturen understøtter både At least once og Exactly Once afleveringsgarantier Fejlsituationer løses ofte også ved at anvende de indbyggede faciliteter i køinfrastrukturen. Dog skal situationen hvor beskeder ikke kan afleveres skal gennemtænkes, og evt. løses gennem brug en Dead letter kø. Håndtering af beskeder der af Modtager karakteriseres som fejlbehæftede eller forvanskede, Signering af beskeder kan overvejes som understøttende teknologi, men selv håndteringen skal aftales. Håndtering af idempotence skal overvejes i forhold til de afleveringsgarantier der defineres for den specifikke implementering af kø-mønsteret. Hvis der ingen aflevererings- Side 15 af 33

20 garanti eller persistence messages anvendes, bør understøttelse af idempotence indarbejdes i besked-designet. Sikkerhedsovervejelser skal primært fokuseres omkring de to integrationspunkter som køen udstiller, således at autoriseret skrivning til køen ikke kan ske til køen og det samme med læsning fra køen. Teknologivarianter Besked/kø integrations mønstret understøttes af forskellige teknologiprodukter, hvor selve køen kræver en lagrings/afleveringsmekanisme. JMS, Java Messaging System Mail-systemer, hvor posthuset realiserer køen Leverandørteknologier Tibco IBM WebShere Progress/Sonic MQ Software AG Nirvana Microsoft MSMQ Referencer Henvisninger til eksterne beskrivelser og eksempler på implementeringer. Enterprise Integration Patterns : Message Channel Eksempel på brug af mønsteret er hvor den kommunale tømningsordning udnyttes til aflæsninger. I dette eksempel er køen placeret i tømningsbilen (skraldevogn). Metadata Metadata for beskrivelsen: Status (gældende, forslag):gældende Version: 1.0 Udarbejdet af. Kurt Hansen, S&D Ændringslog: Oprettet Opdateret med høringssvar Side 16 af 33

21 3.5 Publish/Subscribe Navn Publish/subscribe (databærende) Ikon Beskrivelse Anvendelse Publish/subscribe er et integrationsmønster hvor der er én Afsender af data og hvor der er/forventes to eller flere modtagere. Det er modtagerne der angiver om de vil abonnere på beskeden og de data den indeholder og ikke Afsender. Afsender er som udgangspunkt uvidende om hvilke modtagere der er på et givet tidspunkt. Publish-subscribe er et asynkront en vejs integrationsmønster der er velegnet når en afsender har behov for at sende beskeder til potentielt mange modtagere, og hvor afsender ikke afventer svar. Når afsenderen har afleveret beskeden, fortsætter denne med andet arbejde uden at bekymre sig om hvor mange modtagere der får leveret beskeden, eller hvornår modtagerne behandler beskeden. Mønsteret deler de samme afleverings garantier som Asynkron service. Publish-subscribe kommunikationsmønsteret afkobler en afsender fra en eller flere potentielle modtagere af en besked, og er velegnet i scenarier hvor ændringer i et system (afsendersystemet), skal kendes/anvendes i to eller flere andre domæner(modtagersystemet), og hvor modtagerdomænerne ikke nødvendigvis er kendt på forhånd og kan ændre sig over tid. I en distribueret arkitektur er Publish-subscribe kommunikationsmønsteret eksempelvis velegnet til at synkronisere ændringer i centrale masterdata ud til decentrale databaser (med redundante data) i distribuerede systemer. Virkemåde Publish-Subscribe kommunikationsmønsteret virker ud fra et logisk perspektiv således: 1) Afsender definerer et Topic, dvs. et emne hvor afsender ønsker at publicere beskeder til. Når afsender definerer et topic, oprettes der en input kanal hvortil afsender leverer beskeder. 2) Modtagere abonnerer (subscriber) på et Topic. Når en modtager abonnerer på et topic, oprettes der en output kanal specifikt til denne modtager. Side 17 af 33

22 3) Afsenderen publicerer en besked på et givent Topic, hvilket betyder at beskeden kopieres til hver enkelt modtagers output kanal. 4) Hver modtager læser beskeder på sin egen output kanal og behandler beskeden. Publish-Subscribe dækker bredere end udvekslingen af beskeder, da subscriber delen af mønsteret (Modtagere) eventuelt også omfatter et dynamisk forhold, omkring hvem der subscriber på et given besked. Subscribere kan principielt af- og til-melde sig som subscriber på vilkårlige tidspunkter. Den overordnede relation mellem Afsender og Modtagere i et Publish- Subsribe mønster er derfor fuldt dynamisk. Dog vil forhold til sikkerhed, hvor der er restriktioner på hvem der må Subscribe på beskeder, og f.eks. garanteret aflevering, sætte restriktioner på denne dynamik. Integrationsmønsteret kræver at der en distributions og subscribe mekanisme i infrastrukturen som er tilgængelig for både publisher og alle subscribere. En besked i et Publish-subscribe integrationsmønster vil kun indeholde data fra det domæne som Afsender (publisher) tilhører, dvs. kun data fra et domæne. I Publish/Subscribe integrationsmønsteret er det publisher der har initiativet og dermed aktiverer subscriber. Overvejelser Når publish/subscribe mønsteret vælges, er der en række overvejelser der skal gøres ved ibrugtagning. Garanteret aflevering. Skal publiserede beskeder overleve system nedbrud, eller skal beskeder afleveres til ikke aktive modtagere? Anvend Durable Subscriber som gemmer beskeder, så de overlever system nedbrud, og når modtagere er inaktive. En Durable subscriber er det samme som en subscriber med Garanteret aflevering. Grunden til at der introduceres denne term er at Garanteret aflevering ikke er for hele mønsteret, men er specifikt for den enkelte subscriber der indgår i mønsteret. Durable subscribers bør anvendes sammen med message expiration eller lignende, for at håndtere modtagere der aldrig bliver aktive. Message expiration. Samme overvejelser som beskrevet under asynkron service. Garanteret beskedrækkefølge/sekvens. Hvordan sikres det at eksempelvis to beskeder med hver sin opdatering af kundenavn modtages i den rigtige rækkefølge? Afsendelse af beskeder og behandling hos modtageren er afkoblet fra hinanden. Er der behov for at beskeder behandles i samme rækkefølge som de er afsendt i, skal der aftales en endto-end beskedrækkefølge/sekvens håndtering mellem Afsender og Modtager. Der er forskellige metodikker som kan vælges, herunder brug af unikke nøgler, sekvensnumre, tidsstempling etc. Dead letter. Afkoblingen mellem Afsender og Modtager medfører situationer hvor en besked ikke kan afsendes eller modtages. Denne problemstilling kaldes for Dead letter. Dette stiller igen krav til overvågning og logning, således af Dead letter beskeder håndteres, så datatab undgås. Der skal afdækkes hvordan man opdager at en besked er havnet i en Dead letter situation, samt hvilke tiltag der skal igangsættes når situationen opstår (logning og overvågning). Nogle af de spørgsmål der bør besvares/tages stilling til er f.eks.: skal der igangsættes en manual proces der bærer besked igennem, skal besked redirigeres til en anden modtager, eller skal besked ud på en fejlliste. Invalid messages Samme overvejelser som beskrevet under asynkron service. Sikkerhed skal specielt overvejes i relation til modtagerne. Må et topics kunne ses af Side 18 af 33

23 alle modtagere? Må alle modtagere kunne abonnere på et givent topic? Teknologivarianter Publish/subscribe integrations mønstret understøttes af forskellige teknologiprodukter, idet selve distribueringen af beskeder kræver en distribueringsmekanisme/produkt: JMS, Java Messaging System Leverandørteknologier Tibco IBM WebShere Progress/Sonic MQ Software AG Nirvana Microsoft Biztalk Referencer Henvisninger til eksterne beskrivelser og eksempler på implementeringer. Enterprise Integration Patterns : Publish-Subscribe channel Metadata Metadata for beskrivelsen: Status (gældende, forslag): Gældende Version: 1.0 Udarbejdet af: Kurt Hansen, S&D Ændringslog: Oprettet Opdateret med høringssvar 3.6 Event Navn Event (kun nøglebærende) Ikon Beskrivelse Event er et integrationsmønster hvor et eller flere domæner kan generere og sende et event. Et event er information om at der er sket en datahændelse på data udpeget med nøgler, men event et indeholder ikke de øvrige data som hændelsen vedrører. Alle domæner kan frit modta- Side 19 af 33

24 ge event et, og evt. behandle det. Anvendelse Velegnet til at udsende information om hændelser der er sket inden for et domæne, og som vurderes at have generel interesse for andre domæner. Det er det specifikke indhold i eventet der afgør om modtagere vil agere på hændelsen eller bare smide det væk. Event skal betragtes som her og nu information, og et udtryk for afsender domænets viden præcist på event genereringstidspunktet. Der ønskes 100% afkobling mellem afsender og modtagere af event, og hvor reaktion/handling på et modtaget event kan være afledte aktioner der ikke vedrører de data som hændelsen er genereret på grundlag af. Integrationsmønsteret kan anvendes til at informere om centrale data er blevet opdateret, og er velegnet i kombination med f.eks. spejlning/replikerings integrationsmønsteret, hvor spejl kan opdateres ud fra fastlagte regler baseret på indkomne events. Mønsteret er desuden velegnet til informering om alarmer. Virkemåde Integrationsmønsteret virker ved at der udføres en handling i afsenderdomænet. Denne hændelse ønskes informeret til de øvrige domæner, da den vurderes at have generel interesse, og udsendes som et event. Event et indeholder information om hændelses og nøglen på det dataobjekt hændelsen vedrører, hvis det omhandler et specifikt dataobjekt. Alle de øvrige domæner kan modtage event et, og beslutter ud fra indholdet om det har interesse for det givne domæne. Er event et relevant igangsættes de definerede handlinger tilknyttet event et. Virker i nogen udstrækning som publish/subscribe, men event indeholder ikke data, men er udelukkende nøglebærende. Mønsteret har endvidere ikke nogen abonneringsmekanisme. Dvs. at alle modtager den fulde mængde af event. Behandling af et event hos en modtager kan resultere i at der er behov for data fra flere domæner. Disse data hentes via benyttelse af et eller flere af de øvrige integrationsmønstre, og er umiddelbart ikke en del af event integrationsmønsteret Overvejelser Integrationsmønsteret er et forholdsvist simpelt mønster, hvor en række af de kvalitative egenskaber der kan opsættes for et integrationsmønster normalt ikke vil finde anvendelse. Garanteret aflevering. Ønskes der garanteret aflevering af event bør Publish/subscribe mønsteret overvejes. Garanteret beskedrækkefølge/sekvens er ikke relevant da event et kun indeholder hændelsen og evt. nøgler. Er der genereret to sammenlignelige event med samme nøgler, vil modtagere agere ens, uanset hvilket event der ankommer først. Det er dog vigtigt at nøgler der medsendes er unikke Event granularitet. Det er vigtigt at mængden af genererede events ikke bliver uoverkommelig stor, da et event altid vil aflede større eller mindre handling hos alle modtagere. Events afledt af ændring af enkelt-attributter bør overvejes meget nøje. Mønsteret bør overvejes ved ad hoc og unormale forretningsmæssige situationer Sikkerhed. Der er ikke nogen specielle sikkerhedsmæssige overvejelser for event der Side 20 af 33

25 Teknologivarianter kun modtages internt, men for event der sendes ekstern, skal det enkelte event sikkerhedsvurderes, og mønsteret evt. skiftes til publish/subscribe mønsteret, hvor der er kontrol på modtagelse. Teknologivarianter herunder protokoller & standarder, fx inden for og uden for firewall. Her angives evt. overvejelser specifikt for denne teknologivariant, fx vedr. sikkerhed, tilgængelighed og hosting. Hændelse/event integrations mønstret understøttes af forskellige teknologiprodukter, idet selve udsendelsen af event kræver en underliggende forsendelsesmekanisme: JMS, Java Messaging System Event busses Referencer Leverandørteknologier Tibco Software AG Nirvana IBM WebShere Henvisninger til eksterne beskrivelser og eksempler på implementeringer. Design Patterns : Observer pattern Enterprise Integration Patterns :Event-driven Consumer Eksempler En anvendelse af mønsteret er f.eks. til informering om at der er observeret en atypisk forbrug i forbindelse med en måleraflæsning eller ved den efterfølgende behandling af aflæsningsdata. Metadata Metadata for beskrivelsen: Status (gældende, forslag): Gældende Version: 1.0 Udarbejdet af: Kurt Hansen, S&D Ændringslog: Oprettet Opdateret med høringssvar Side 21 af 33

26 3.7 Replikering Navn Replikering Ikon Beskrivelse Anvendelse Data replikeres fra et domæne til et andet, så der opbevares et eksakt spejl af data (der laves en kopi). Det domæne der har spejlet læser data heri i stedet for at hente data i det domæne data ejes af. Er velegnet når data skal udstilles som read-only data i f.eks. DMZ. Herved beskyttes Data ejer domænet både sikkerheds- og belastnings-mæssigt. Kan anvendes når Anvender domænet, grundet tekniske forhold, kræver at data skal replikeres til Anvender domænet. Tekniske forhold kan f.eks. være standard-produkter som ikke fungerer uden lokal kopi af bestemte data. Virkemåde Integrationsmønsteret virker ved at Anvender domænet får en eksakt kopi af data fra Data-ejer domænet. Dette kan ske både som push og pull. Ved Push er det Data-ejer domænet der har initiativet, og sørger for at Anvender domænet har de ønskede data i en lokal kopi, spejlet. Ved Pull er det Anvender-domænet der henter data i Data-ejer domænet, og sørger for opdatering og vedligeholdelse af data i spejlet. Spejlet oprettes ved at data trækkes ud af database i Dataejer domænet. Data flyttes direkte til database hvor spejlet lagres eller kan mellemlagres i et staging-areal. Anvendelse af staging-areal afhænger af værktøjs- og teknologivalg. Overvejelser Dette integrationsmønster afleder en række overvejelser primært relateret til at data er lagret 2 steder og i forskellige domæner. Ejer-skab af spejl. Der skal tages beslutning, og der skal anvendes Push eller Pull i forhold til spejlet, og dermed hvem der ejer spejlet. Opdatering af spejl. Skal opdatering af spejl ske real-time eller med fastlagte intervaller, hvor data kan være ikke-aktuelle mellem opdateringer? Beslutning om opdatering af- Side 22 af 33

27 hænger af to forhold, dels dynamikken af data og anvendelsen af data i Anvenderdomænet og dels krav til data-aktualitet Delta-opdatering. Vælges der delta-opdatering af replikerede data, skal der etableres mekanismer til synkronisering af spejl og den originale datakilde (data ejer domænet). Dette kan f.eks. ske gennem en fuld replikering en gang pr. uge. Intervallet afhænger af dynamikken i data. Forretningsregler for og tolkning af data vil i større eller mindre omfang blive placeret 2 steder. Dvs. forretningsregler tilhørende Data-ejer domænet vil også skulle implementeres i Anvender domænet. Designmæssige overvejelser skal foretages for at minimere dette. Sikkerhed. Sikkerhedsopsætning for læsning/tilgang til data skal synkroniseres, og der skal være sikkerhedsmæssige mekanismer der sikrer at samme sikkerhedsregler er gældende i Data-ejer domænet og Anvender domænet Teknologivarianter Teknologivarianterne for dette integrationsmønster kan opdeles i 2 grupper, databaseplatformsværktøjer og ETL værktøjer. Databaseværktøjer: SQL-værktøjer og direct database connections Databaseproduktet replikeringsmekanismer ETL-værktøjer (Extract, Transform & Load) Der findes et bredt udsnit af ETL-værktøjer på markedet, herunder også open source alternativer. Referencer Henvisninger til eksterne beskrivelser og eksempler på implementeringer. Et konkret og jordnært eksempel på anvendelse er markpersonalet, der tager en kopi af ledningsdatabasen med i marken for at sikre tilgængelighed til data på steder/tider, hvor mobildækningen falder ud. Metadata Metadata for beskrivelsen: Status (gældende, forslag): Gældende Version: 1.0 Udarbejdet af: Kurt Hansen, S&D Ændringslog: Oprettet Opdateret med høringssvar Side 23 af 33

28 4 Støttemønstre Nedenstående mønstre er ikke egentlige integrationsmønstre, men er støttemønstre der typisk anvendes inden for et domæne. 4.1 Read only cache Navn Read only cache Ikon Beskrivelse Anvendelse Cache er en datakopi indenfor domænet der er organiseret og optimeret til specifikke anvendelses formål. Integrationsmønsteret er velegnet hvor der enten skal vises større datamængder, eller der skal etableres søgemuligheder som ikke harmonerer med den struktur og format data er lagret i. GIS/kort-data er gode eksempler på data som er velegnede til at udstille gennem en cache. Dels er det store datamængder, dels er det data til visuel visning. Søgning i store datamængder kan også optimeres gennem brug af cache mønsteret Cache ligger i et hurtigere lagringsmedie Giver mulighed for optimeret indeksering Kun relevante attributter indgår i cache Kan også anvendes i situationer hvor der ønskes aflastning af den bagvedliggende database, eller hvor anvendelsesmønsteret er ukendt eller fluktuerer meget. Virkemåde Integrationsmønsteret er ikke et selvstændigt mønster, men bør kombineres med et af de andre integrationsmønstre. Cache-mønsteret fungerer ved at udstiller domænet laver en kopi af udvalgte data indenfor domænet. Cachen ejes og etableres i dette domæne. Data i cachen optimeres i forhold til anvendelse. Data kan beriges med optimerede indeks, organiseres på en anden form eller format afhængig af formålet med cachen Side 24 af 33

29 Overvejelser For cache integrationsmønsteret er der nogle specifikke overvejelser der skal gøres. Opdatering af cache. Hvor ofte skal cache opdateres og hvilket med hvilket tidsdelta skal cache afspejle opdateringer. Dedikeret cache. Skal der være dedikerede cache til forskellige formål, eller er det samme cache der skal forsøges anvendt til alle formål. Retningslinjer for oprettelse af ny cache. Der skal opsættes retningslinjer for hvornår der oprettes yderligere cache for de samme data. Teknologivarianter Cache teknologi er et område i rivende udvikling grundet den hastighed datamængder vokser i. Data grid ses derfor på sigt som en teknologi der overtager de mere traditionelle former for inmemory cache. Leveres ofte som en del af applikationen. Teknologi produkter Data grid produkter Oracle Coherence Referencer Henvisninger til eksterne beskrivelser og eksempler på implementeringer. Cache af grundkort er et typisk eksempel på anvendelse af dette støttemønster. Metadata Metadata for beskrivelsen: Status (gældende, forslag): Gældende Version: 1.0 Udarbejdet af: Kurt Hansen, S&D Ændringslog: Oprettet Opdateret med høringssvar Side 25 af 33

30 4.2 Systemkonvertering Navn Systemkonvertering Ikon Beskrivelse Anvendelse Virkemåde Integrationsmønsteret er et specialmønster der eksporterer alle systemdata ud af et system. Eksport omfatter både domænedata og systemspecifikke data. Eksport sker til et gængs maskinlæsbart format. Anvendes ved systemkonvertering hvor et nyt system erstatter et eksisterende system, og data skal flyttes til det nye system. Mønsteret virker ved at data eksporteres fra det eksisterende system. Data lagres i et gængs tilgængeligt og systemuafhængigt format. Format omfatter både lagrings og indholdsformat. Data indlæses eller importeres efterfølgende i det nye system. Overvejelser Overvejelser for dette mønster er primært rettet mod håndtering af data i perioden mellem eksport og import data. Mellemlagring af eksporterede data og flytning da det kan dreje som om større datamængder Sikring af at data ikke opdateres efter eksport Teknologivarianter Referencer Metadata Teknologivarianter herunder protokoller & standarder Databaseeksport Eksport til flade filer Henvisninger til eksterne beskrivelser og eksempler på implementeringer. Metadata for beskrivelsen: Status (gældende, forslag): Gældende Version: 1.0 Udarbejdet af: Kurt Hansen, S&D Side 26 af 33

31 Ændringslog: Oprettet Opdateret med høringssvar Side 27 af 33

32 5 Ikke godkendte integrationsmønstre Nedenstående integrationsmønstre er kategoriseret som ikke godkendte integrationsmønstre, dvs. at det er integrationsmønstre som ikke anbefales anvendt til DDV standardisering. 5.1 Database connection Navn Database connection Ikon Beskrivelse Anvendelse Anvender domænet har en database-forbindelse direkte til Udstiller domænets database, hvor anvender domænet har direkte adgang til tabeller. Anvender domænet kan principielt både læse og skrive i Udstiller domænets database. Kan anvendes i situationer hvor der ikke er andre tekniske eller løsningsmæssige muligheder for at tilgå data i Udstiller domænet. Kan ikke anbefales til fremadrettet brug og nye integrationer. Mønsteret kan dog anvendes så længe integrationen sker indenfor det enkelte domæne. Virkemåde Mønsteret virker ved at der i Anvender domænet konfigureres en direkte databaseforbindelse til en database i Udstiller domænet. Data læses/skrives direkte til tabeller i denne database på samme måde som databaser indenfor Anvender domænet. Overvejelser Valg af dette integrationsmønster giver anledning til en række specifikke forhold der skal overvejes nøje, og vedtages regler for eller opstilles driftsmæssig håndtering af. Belastning af database i Udstillerdomænet bliver principielt ukendt, da forespørgsler fra andre domæner sker direkte i databasen. Herved er dels antallet af samtidige forespørgsler ukendt, Side 28 af 33

33 men der er også stor risiko for at læsninger (select) går på tværs af tabeller og indeks på en sådan måde at det medfører: Meget store Joins der kræver meget memory på DB server Table-scan af store tabeller, da index ikke matcher Select-statement Ukontrolleret låsninger af tabeller/records hvis der foretages update/insert Tolkning af data sker på baggrund af forretningsregler der udføres i domæne A, men principielt hører til i domæne B. Dette giver enten Dublering af forretningsregler for data med høj sandsynlighed for inkonsistens mellem disse. Dobbeltvedligehold af forretningsregler Forretningsregler tilhørende Udstiller domænet findes og eksekveres kun i et Anvender domæne, hvilket afleder store governancemæssige udfordringer Anvendes dette integrationsmønster bør skrivning (update/insert) undgås. Teknologivarianter Teknologi varianter er reelt dikteret af den teknologiske understøttelse som databaseleverandøren tilbyder. Dog kan følgende markedsstandarder fremhæves ODBC JDBC Referencer Metadata For eksterne beskrivelser henvises til de enkelte databaseleverandører. Metadata for beskrivelsen: Status (gældende, forslag): Gældende Version: 1.0 Udarbejdet af: Kurt Hansen, S&D Ændringslog: Oprettet Opdateret med høringssvar Side 29 af 33

34 5.2 Human copy/paste Navn Human copy/paste Ikon Beskrivelse Anvendelse Virkemåde Integrationsmønsteret virker ved at en bruger læser data i et system i det ene domæne, online eller på print, og indtaster de samme data i et system tilhørende det andet domæne. Bør kun anvendes i nødsituationer eller specialtilfælde, hvor dette er det mest økonomiske optimale integrationsmønster En bruger der har adgang til data i et domæne, enten online eller på print, læser data og indtaster eller kopierer data til et system i det andet domæne. Overvejelser Ved meget små datamængder kan integrationsmønsteret overvejes anvendt frem for Systemkonverterings-mønsteret. Integrationsmønsteret har en indbygget fejl-rate, som skal håndteres gennem kvalitetssikringsaktiviteter. Meget ressourcekrævende ved større datamængder. Teknologivarianter Referencer Der er kun en variant af dette mønster, da forskelligt antal brugere ikke anses for at være en variant. Eksempler på implementeringer. Manuel aflæsning af måler Metadata Metadata for beskrivelsen: Status (gældende, forslag): Gældende Version: 1.0 Udarbejdet af: Kurt Hansen, S&D Ændringslog: Oprettet Opdateret med høringssvar Side 30 af 33

35 5.3 API Navn API Ikon Beskrivelse Anvendelse Virkemåde API integrationsmønsteret er hvor man kalder datafunktioner i et andet domæne direkte, og hvor runtimemoduler fra det andet domæne bliver linket med ind som en del af anvender systemet. Kan anvendes i situationer hvor Udstiller domænets data er lagret i et proprietært format, ofte binært, og den eneste tilgang til data er via et API. Integrationsmønsteret virker ved at der i applikationskoden indlægges API-kald for tilgang til data. Koden kompileres og linkes, hvorved der indlejres runtime-moduler/biblioteker i den linkede applikation. Runtime moduler kan være i form af dll er eller lignende teknologier. Overvejelser Brug af dette mønster skaber en meget hård teknologisk binding mellem domæner, og afleder ofte en binding til specifikke versioner af applikationer. Bindinger til teknologiplatforme og programmeringssprog skal overvejes, og der bør beskrives roadmaps for den fremadrette håndtering af dette forhold hvor opgraderinger og teknologisk forældelse adresseres. Integrationsmønsteret giver ingen funktionel afkobling mellem domænerne, så de afledte konsekvenser heraf skal vurderes. API'er er proprietære og Forsyningerne udsætter sig for en risiko ved at benytte dem, idet rettighedshaveren énsidigt kan ændre API'et og dermed afstedkomme anseelige udgifter i forbindelse med opdatering af de systemer, der benytter API'et. Teknologivarianter Er leverandørspecifikt Side 31 af 33