Innehåll

Inledning

Denna sida beskriver GU:s integrationsarkitektur. Med integrationsarkitektur avses de principer, modeller och ramverk som tillämpas inom systemintegration på GU.

...

I alla dessa frågor är ICC ett stöd inom administration och dokumentation, arkitektur och teknik. Inga implementationer och ingen data ägs av ICC eller Integrationsplattformen. Integrationsplattformen och de tekniska komponenter som ingår där (IBM MQ, webMethods osv) utgör en infrastruktur som tillhandahålls av IT-enheten, att jämföra med nätverk och lagring. Alla tjänster och integrationsflöden på GU ägs av en applikation och därigenom ett objekt, inte av ICC.

Dokumentation

Integrationskatalogen

Översikt

Alla systemintegrationer som involverar centralt förvaltade applikationer på GU dokumenteras i Integrationskatalogen, som är ett ramverk och en applikation för att dokumentera systemintegrationer. Målsättningen är att samtliga integrationer på GU skall vara beskrivna här. Graden av detaljer kan variera, men alla integrationsflöden skall kunna återfinnas åtminstone på den översta nivån (tjänster och kontrakt). Ansvaret för innehållet i integrationskatalogen ligger hos ICC.

...

Målgrupp för Integrationskatalogen

Integrationskatalogen är tillgänglig för all personal på universitetet, men den huvudsakliga målgruppen är:

• Objektägare, Objektledare och Objektspecialister tillsatta enligt GUSPP styrmodell

• IT-arkitekter och personal på IT-enheten knutna till ICC

• Externa aktörer som önskar integrera med GU:s IT-system

Funktion och innehåll

Integrationskatalogen är en implementation i Sharepoint av den begreppsmodell som beskrivs ovan. Detta innebär att följande objekt finns för alla integrationer: 

• Publicerande system (System, benämns Application i bilden ovan)

• Publicerad tjänst (Service)

• Tjänstemeddelande (Message)

• Kontrakt mellan mottagare och tjänst (Contract)

• Konsumerande system (System)

Förutom detta finns möjlighet att beskriva hur en tjänst eller ett kontrakt är implementerat, om detta sker utanför respektive applikation t.ex. på Integrationsplattformen:

• Kontraktimplementation (Implementation)

• Tjänsteimplementation (Implementation)

Alla ovanstående objekt representeras i listor (System List, Service List) med kopplingar sinsemellan enligt modellen. Service har således alltid en referens till System som är publicerande system för tjänsten, Message som är det meddelande som tjänsten tillhandahåller, osv.

Varje objekt har en uppsättning beskrivande attribut. Alla typer av objekt har ett ID, ett namn och en beskrivande text. Förutom detta kan det finnas mer specifika fält som t.ex. Service Endpoint Type som talar om hur en tjänst är tillgänglig (kö, REST, SFTP osv.), Message Format som talar om vilket format som ett meddelande använder (XML, JSON osv.).

Dessutom finns dokument med ytterligare information knutna till enskilda objekt. Även dessa lagras i dokumentlistor (Service Doc, Implementation Doc osv.). För meddelanden kan det vara t.ex. XML-scheman eller andra typer av formatbeskrivningar. För tjänster kan det vara information om hur man använder tjänsten och vilken data den tillhandahåller. För implementationer är det designdokument (blueprints) som i detalj specificerar hur t.ex. en konsumentadapter fungerar, vilka mappningar som görs mellan meddelandeformat osv.

Förutom dokumentation av tjänster och kontrakt finns också en avdelning i integrationskatalogen för integrationsbeställningar (Integration Request).

Designdokument och specifikationer

krfsm

Infrastruktur