...
Informationen som publiceras i HSA katalogen har flera användningsområden och de som behöver få ut HSA informationen för vidare spridning i sina egna system 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 informationen därefter synkas sedan denna information löpande upp till den nationella HSA katalogen plattformen hos Inera . Hur ofta informationen synkas upp styrs av hur producenten satt upp sin synk.
Hur ofta producenten synkar sina uppgifter är olika men vissa synkar upp ändringar löpande via s.k inkrementella synkar och kompletterar dessa med att gör totalsynkar mer sällan för att säkra upp att alla uppgifter verkligen kommit över till Ineras nationella HSA katalog.
Tågordning för att migrera en producent i kategori A till 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 en 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.
...
<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 men även övergå till att administrativa sin information via det nya administrativa gränssnittet och därmed lämna (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.
