Gå till slutet av bannern
Gå till början av bannern

Så här går en migrering till

Hoppa till slutet på meta-data
Gå till början av metadata

Du visar en gammal version av den här sidan. Visa nuvarande version.

Jämför med nuvarande Visa sidhistorik

« Föregående Version 14 Nästa »

Inom ramen för projektet Ny teknisk plattform för grunddata och katalog (läs mer om projektet här) ska samtliga HSA-anslutna organisationer, deras HSA-information och deras anrop mot HSA, migreras från befintlig HSA-plattform till den nya plattformen för grunddata och katalog.

Producenter

De organisationer som synkar eller manuellt lägger in information i den nationella HSA katalogen kallas producenter och ska vid migreringen styras om så deras information iställer läggs in i den nya plattformen.

Eftersom vi inte kommer kunna migrera alla producenter samtidigt ligger det på projektet att säkerställa att migrerade organisationers HSA information även finns tillgänglig i den befintliga HSA katalogen så länge det behövs.

Konsumenter

Informationen som publiceras i HSA katalogen har flera användningsområden och de som behöver få ut HSA informationen kallas konsumenter.

Migreringen för konsumenterna går ut på att styra om hämtningen av HSA-information så den går mot den nya plattformen. Om det gäller konsumenttjänster som går via NTjP så ändras dessa av Inera medans regionala/lokala tjänster får konfigureras om av den anropande organisationen.

När alla producenter och konsumenter migrerats till den nya katalogplattformen kan den befintliga HSA katalogen avvecklas.

Migrering av producenter

Kategori A - Producerande organisationer som synkar upp sin HSA-information från lokal katalog och inte använder HSA Admin/HAU för att administrera sin information.

I denna kategori hanterar producenten sina uppgifter fullt ut i den lokala katalogen och därefter synkas denna information löpande upp till den nationella HSA plattformen hos Inera via producentens valda synklösning.

Då producenten ställt om sin synk så den går mot nya plattformen för grunddata och katalog kommer projektet i sin tur synka över den migrerade organisationens information så den även finns tillgänglig i befintliga HSA-plattformen så länge den behövs även där.

Test av producentens synklösningen:

  • Producenten får behörighet till den nya HSA-testmiljön för att testa sin synklösning tillsammans med sin synkleverantör och projektets migreringsgrupp.

    • Producenten synkar först upp sin testdata till den befintliga HSA testmiljön (totalsynk)

    • Producenten synkar sedan upp sin testdata till den nya plattformen och verifierar att informationen kommer över korrekt. Eftersom den nya plattformen har en indatakontroll kan vissa uppgifter stoppas och ska då presenteras i den avvikelselogg som är nåbar via inloggning till den nya användargränssnittet.

    • Producenten och migreringsgruppen jämför innehållet i de två katalogerna och analys görs vad som eventuellt diffar.

    • Om inga fel eller oklarheter finns fortsätter migreringsresan till produktionsmiljön.

  • Producenter som saknar egen testmiljö behöver istället göra en test av sin synklösning mot nya plattformens produktionsvalideringsmiljö.

    • Denna synktest kommer genomföras på samma sätt som beskrivs ovan. Den stora skillnaden är att det i denna test används produktionsdata från producenten.

    • Efter avslutad test rensas denna information från produktionsvalideringsmiljön.

Produktionssättning mot nya katalogplattformen:

  • Producenten har rättat eventuella fel i den befintliga HSA plattformen utifrån kontrollkörningarna.

  • Producenten får behörighet för att genomföra migrering av sitt data i produktionsmiljön. Ny synkanvändare och lösenord förmedlas.

  • Användare i producentens organisation som ska få åtkomst till det administrativa gränssnittet läggs upp i ett administrativt medarbetaruppdrag som styr behörigheten. Därefter kan dessa användare logga in och kontrollera avvikelseloggen utifrån synkarna.

  • Producenten stänger av sin befintliga synk och startar upp sin nya synk mot den nya plattformen.

  • Projektet startar upp en internsynk av den migrerade organisationens information så den synkas från den nya plattformen till den befintliga HSA plattformen. Denna synk kommer köras tills alla beroenden till befintliga plattformen är ersatta av den nya plattformen och kommer därefter stängas av.

<Plats för checklista/tabell>

Kategori B - Producerande organisationer som synkar från lokal katalog och använder HSA Admin/HAU för att administrera sin information

I denna kategori hanterar producenten viss information via synkning direkt mot nationella HSA men administrerar även information manuellt via Ineras HSA Admin/HAU grässnitt

Precis som för en producent i kategori A ska en kategori B testa sin synklösning mot nya katalogplattformen (Se beskrivning ovan för kategori A).

Men det stora migreringsaktiviteten för denna kategori är att lära sig att jobba i det nya användargränssnittet som ersätter dagens webbapplikationer HSA-Admin och HAU.

Kategori C - Producerande som idag administrerar sin HSA-information fullt ut via HSA Admin/HAU

I denna kategori administrerar producenten sin HSA-information manuellt via webbapplikationerna HSA Admin och HAU och migreringen för denna kategori kommer framför allt handla om att lära sig den nya användargrässnittet.

Projektet kommer migrera över kategori C producentens HSA-information från den befintliga plattformen till den nya katalogplattformen när det är dags att migreras.


Migrering av konsumenter

Kategori D - Konsumenter som hämtar HSA-information via HSA Fileservice

I den befintliga HSA plattformen skapas det löpande upp filer som innehåller HSA-information enligt ett förutbestämt format. Dessa filer hämtas upp av konsumenter som använder denna information i sina egna system t ex 1177.se

Migreringen för denna konsumentkategori handlar om att få dessa filer via den nya plattformen för grunddata och katalog och eventuellt hämta dessa filer från en annan plats än idag.

Kategori E - Konsumenter som hämtar HSA-information via Ntjp eller via direktanrop

Migreringen för de som går via NTjP’s tjänstekontrakt kommer kunna fortsätta gör det utan att ändra något i sina egna system då det är projektets ansvar att säkerställa att tjänsten ställs om och hämtar sin HSA information från nya plattformen.

Migreringen för de konsumenter som idag gör egna direktanrop mot befintliga HSA-plattformen kommer behöva ändra tjänsten på sin sida så den istället går mot nya plattformen för att hämta HSA-informationen.

Kategori F - Konsumenter som hanterar SITHS information via SITHS rest-api

De konsumenter som idag hanterar SITHS uppgifterna som lagras i HSA ska ställa om sina anrop så de istället går mot motsvarande SITHS rest api gränssnitt som den nya plattformen kommer erbjuda.

Kategori G - Notify1177 är en funktion som skickar ändringar av HSA information till 1177

Förutom att hämta in uppgifter via Fileservices så skickas ändringar direkt till konsumenten 1177.se via en tjänsten Notify1177.

Denna tjänst kommer byggas upp på samma sätt i nya plattformen så konsumenten 1177.se får samma information som tidigare pcj därmen blir migrerad.

  • Inga etiketter