Masterdata
Masterdata för bestÀllare
SnabblÀnkar till API per MasterdataomrÄde
- API-sida AvtalsomrÄde
- API-sida Organisation
- API-sida Enhet
- API-sida Serviceplats
- BestÀllningsformulÀr
Information om Masterdata
Information Àr nÄgot av som en organisations viktigaste tillgÄngar. Detta gÀller inte minst i en kunskapsintensiv organisation som Region Stockholm, dÀr Region Stockholm hÄller pÄ att införa masterdata som ett led i utveckling av en mer strategisk informationshantering och en lÄngsiktigt hÄllbar digital miljö. Det ska bidra till ökade förutsÀttningar att styra, leda och utveckla verksamheterna, till nytta för sÄvÀl invÄnare som medarbetare.
Data Àr obearbetad fakta och siffror, medan information Àr data som tolkats och satts i ett sammanhang. InformationsmÀngd Àr information som Àr avgrÀnsad för ett visst ÀndamÄl. En informationskÀlla Àr ett system eller register dÀr information skapas och uppdateras.
Masterdata Àr en typ av data som Àr grundlÀggande och gemensam för en verksamhet. Det Àr data som Àr av strategisk betydelse för organisationen och som anvÀnds för att stödja verksamhetsprocesser och beslutsfattande. Exempel pÄ masterdata Àr information om kunder, leverantörer och priser.
Masterdata lagras i en central kÀlla MDM-plattformen, och delas mellan olika system och tjÀnster som behöver tillgÄng till informationen. Detta eliminerar risken för att olika versioner av data anvÀnds i olika system vilket dÀrmed minskar risken för felaktiga beslut och ineffektivitet. Genom att ha en enda kÀlla för masterdata kan organisationen sÀkerstÀlla att alla har tillgÄng till samma data och korrekta data.
Inom Region Stockholm finns inledningsvis masterdata om Organisation, AvtalsomrÄde, Serviceplats och Enhet. För att komma i gÄng med anslutningsprocessen och börja anvÀnda masterdata fyll i formulÀret hÀr.
Vid frÄgor om masterdata i stort eller anslutning av system: masterdata@regionstockholm.se
Om Masterdataprogrammet i Region Stockholm
Anslutningsprocessen i korthet
Konsumtion av data frÄn MDM-plattformen sker alltid via integrationsplattformen. Det finns generiska tjÀnster tillgÀngliga sÄ det gÄr att hÀmta just den information som behövs till en applikation pÄ ett standardiserat sÀtt. Först mÄste ett avtal signeras som beskriver vilken information som ska konsumerande system vill hÀmta, vad informationen ska anvÀndas till och vilka krav aktuell applikation har pÄ leveransen (SLA).
BestÀllning
En bestÀllning inleds med att ett formulÀr fylls i med fullstÀndiga uppgifter. Observera att fÀlt som Àr markerade med rött Àr obligatoriska. FormulÀret ska sedan signeras innan det skickas in av behörig bestÀllare.
Ladda ned formulÀret (lÀnk)
Signeringen kan göras antingen manuellt eller digitalt. Vid manuell signering scannas dokumentet in innan det skickas. Signerad bestÀllningen mailas till masterdata@regionstockholm.se
Information om digital signering (lÀnk)
Anslutning
NÀr bestÀllningen Àr genomförd blir bestÀllaren kontaktad för uppsÀttning av konto i API-portalen. API-portalen blir sedan motorn för införandet av den nya integrationen. DÀr hittar man som konsument all information kring konfigurering, och det Àr Àven möjligt att genomföra tester för att se hur lösningen kommer att fungera.
NÀr ett konto Àr uppsatt fÄr bestÀllaren stöd av förvaltningarna för MDM-plattformen och Integrationsplattformen tills en fungerande integration Àr pÄ plats.
Tekniska krav för att kunna ansluta till MDM-plattformen
För att ansluta krÀvs alltid att applikationen som ska ansluta till ett API finns registrerat i API-portalen. Vissa API:er krÀver dessutom olika typer av sÀkerhetslösningar. Förfarandet ser olika ut beroende pÄ om anslutningen gÀller en privat aktör eller systemÀgare/-förvaltare inom Region Stockholm. Se API-specifikation och dokumentation för detaljerat svar:
Ăvergripande regelverk fastslĂ„r att alla konsumenter av MDM-plattformens tjĂ€nster behöver kunna identifieras (primĂ€rt pĂ„ systemnivĂ„). Detta görs genom anvĂ€ndningen av "client id och client secret" som i sin tur Ă€r kopplade till en "applikation" hĂ€r i plattformen. Kopplingen genomförs av serviceförvaltningen. En eller flera anvĂ€ndare kan hantera sin applikation men ansökan mĂ„ste göras för varje API som applikationen behöver access till.
NÀr anslutningen har upprÀttats Àr det viktigt att loggning sker pÄ ett sÀtt som ger möjlighet till spÄrning och felsökning. Varje API-instans i MDM-plattformen returnerar ett korrelations-id som identifierar det aktuella anropet, vilket Àr viktigt att spara för att kunna fÄ bÀsta möjliga support frÄn API-supporten.
Driftsinformation/efter anslutning
Incidenthantering
UpptÀcker du ett fel kring anslutningen sÄ rapporterar du in incidenten i ServiceFörvaltningens ServiceDesk (Hem - TellUs) Alternativt kan Àrendet ringas in enligt kontaktuppgifter i Service Desk. Att störningar eller incidenter rapporteras Àr viktigt för att supportteamet ska kunna lösa problemet sÄ fort som möjligt.
FörÀndringsbegÀran
FörÀndringar i MDM-plattformen eller tillgÀnglig data kan begÀras genom att lÀgga ett Àrende i TellUs med tilldelningsgrupp MDM-plattform.
Vilken data kan hÀmtas?
AvtalsomrÄde
En koppling mot API:et för AvtalsomrÄde ger tillgÄng till följande attribut:
LÀs om masterdatastandard för AvtalsomrÄde
LĂ€nkar
Organisation
En koppling mot API:et för Organisation ger tillgÄng till följande attribut:
LÀs om masterdatastandard för Organisation
LĂ€nkar
Enhet
En koppling mot API:et för Enhet ger tillgÄng till följande attribut:
LÀs om masterdatastandard för Enhet
LĂ€nkar
Serviceplats
En koppling mot API:et för Serviceplats ger tillgÄng till följande attribut:
LÀs om masterdatastandard för Serviceplats
LĂ€nkar
Ăvergripande informationsmodell
Teknisk information APIer
Tekniska API-specifikationer för masterdata finns i respektive sida per integration:
Masterdata till applikationskonsumenterna tillhandahÄlls genom synkrona realtidstjÀnster (RESTful).
Konsumenten anropar REST-tjÀnst i Service Förvaltningens integrationsplattorm. Integrationslösningen anropar i sin tur RESTful tjÀnsterna i MDM-plattformen och förmedlar svaret till konsumenten.
REST-tjÀnsterna Àr inspirerade av HATOS och följer i stort DIGGS API- profil ( REST API-profil - Utvecklarportalen (dataportal.se) )
Dataformatet Àr JSON och teckenkodningen UTF-8.
API-sÀkerhet
För att förhindra obehöriga frĂ„n att anvĂ€nda MD-tjĂ€nster eller störa tjĂ€nsterna genom âattackerâ Ă€r lastbalanseraren (Netscaler/ADC) och integrationsplattformen (MuleSoft API-gateway) konfigurerade med API-sĂ€kerhetsfunktioner.
Tekniska krav pÄ konsumerande system
⹠SITHS-funktionscert (Autentisering i integrationsplattformen sker dels med hjÀlp av Mutual TLS).
⹠ClientID/ClientSecret tillhandahÄllas av SF och skickas med i http-headern.
⹠SlutanvÀndarens identitet.
InformationssÀkerhetsklassning
K1R2T3 (ej verksamhetskritisk, ej sekretess)
Notifieringsmeddelanden
Notifieringsmeddelanden anvĂ€nds för att informera konsumenterna om att en förĂ€ndring har intrĂ€ffat. Alternativet hade varit att samtliga konsumenter hela tiden anropar APIerna och frĂ„gat âhar det hĂ€nt nĂ„gotâ - ett antimönster.
Notifieringsmeddelandet skapas av MDM-plattformen nÀr en förÀndring sker i en masterdataresurs. Notifieringssmeddelanden distribueras till mottagare som Àr intresserande av förÀndring i utpekat masterdataomrÄde.
I notifieringsmeddelandet anges vilken resurs som har modifierats, vilket typ av hÀndelse (förÀndrad, skapad, borttagen) samt en lÀnk för att anropa den aktuella resursen.
För att kunna garanterad leverans av meddelandet behöver mottagaren bekrÀfta att meddelandet Àr mottaget.
AMQP rekommenderas som protokoll eftersom den Àr implementationsoberoende. Andra teknologier kan införas vid behov.
Versionshantering
Versionshantering av API:er Àr en teknik för att hantera förÀndringar i ett API över tid. Genom att anvÀnda versioner av API:et kan man sÀkerstÀlla att befintliga applikationer och tjÀnster som anvÀnder API:et inte pÄverkas negativt av förÀndringar eller uppdateringar.
Versionshantering av API:er innebÀr att varje uppdatering av API:et fÄr en ny version, dÀr varje ny version av APIer kan hanteras pÄ tvÄ olika sÀtt beroende pÄ kompabilitet. FörÀndringar som Àr bakÄtkompatibla kallas för minor upgrade medan förÀndringar som inte Àr bakÄtkompatibla kallas för major upgrade.
LÄt oss sÀga att vi har ett API i version 1.0.0, dÀr en förÀndring behöver göras i API:et som inte Àr bakÄtkompatibel. Den nya versionen fÄr dÄ versionsnummer 2.0.0. Nu kan konsumerande system vÀlja att antingen anvÀnda sig av version 1.0.0 eller 2.0.0 av API:et, beroende pÄ om de Àr intresserade av den nya eller gamla informationsmÀngden.
Efter det sÄ behöver vi göra en bakÄtkompatibel förÀndring pÄ version 1.0.0, den nya versionen fÄr dÄ betÀckning 1.1.0. De applikationer eller tjÀnster som sedan tidigare anvÀnde sig av 1.0.0 behöver inte göra nÄgon förÀndring, utan den nya versionen (1.1.0) blir automatiskt kompatibel.
Den hÀr versionshanteringen gör det möjligt för utvecklare att fortsÀtta anvÀnda den tidigare versionen om de sÄ önskar. Varje version Àr unik och specificerar vilka förÀndringar som har gjorts jÀmfört med den föregÄende versionen. Detta innebÀr att om en utvecklare behöver anvÀnda en tidigare version av API:et, kan de enkelt hÀnvisa till den specifika versionen för att sÀkerstÀlla att deras applikation fungerar korrekt.