Formålet med dette dokument er at beskrive hvordan et udviklingsmiljø, til videreudvikling af NAP SDK, skal sættes op, kodens struktur, samt hvordan koden bygges, deployes og testes.
Dette dokument er en del af den samlede dokumentation for NAP SDK.
Dokumentet er udformet, så det i videst muligt omfang opfylder sit formål uafhængigt af de øvrige dokumenter.
Ønskes mere information omkring arkitektur og design findes dette på NAP SDK - Design og Arkitektur beskrivelse.
Ønskes mere information omkring installationsvejledning til anvender kan findes på NAP SDK - Installationsvejledning.
Ønskes mere information omkring guide til anvendelse findes dette på NAP SDK - Guide til anvendere.
Kildekoden til NAP-SDK findes på https://svn.nspop.dk/svn/libraries/nap/
NAP-SDK er udviklet og testet på.
Pakke | Version |
---|---|
npm | 6.14.8 |
node | 14.4.0 |
Installer dependencies ved at køre `npm install --registry https://nexus.nspop.dk/nexus/repository/nsp-npm/`
Kør "npm run build" for at bygge projektet. Dette giver et output i dist/ folderen.
For at køre unit tests med Karma kør "npm run test". Det genererer en coverage rapport i coverage/ mappen.
Eventuelle fejl skrives til STOUT.
For at bygge SDK til CI køre "npm run ci:build". Jenkins filen beskriver jenkins pipelinen.
Der kan laves snapshots og release-candidates fra jenkins til NSP npm repository.
Versionering af Nap-typescript-sdk følger sem.
For at lave et release opdateres versionen i (package.json), hvorefter der køres en `npm i` for at opdatere package-lock.json.
Dernæst laves et tag i SVN på den følgende version manuelt som fx:
svn copy https://svn.nspop.dk/svn/libraries/nap/nap-typescript-sdk/trunk \ https://svn.nspop.dk/svn/libraries/nap/nap-typescript-sdk/tags/release-1.0.0-rc.1 \ -m "Tagging the 1.0.0-rc.1 release of the 'nap typescript sdk' project." |
Det er vigtigt at tagget i svn stemmer overens med versionen i package.json og package-lock.json
Kør "npm run lint" for linting.
Eventuelle fejl skrives til STOUT.
For at generere dokumentation til koden, kør "npm run doc". Dokumentation ligger i docs/ mappen.
NAPMessage er meget inspireret af FHIR / FHIRcast (https://fhircast.org/specification/Feb2020Ballot/), og er udgangspunktet i NAPMessage datastrukturen og grundlaget for de events der er implementeret i eventkataloget version 1.
Eventkataloget fungerer som versionering af NAPMessages.
Et anvenderprojekt definerer hvilken version af eventkataloget den implementerer.
Dette fungerer som en kontrakt således, at et givent værtssytem ved et givent projekt kan håndtere en række events.
Skal der implementeres nye events kræver det nyt release af nap-typescript-sdk'et.
En NAP bridge er et simpelt interface med en send-funktion og en callback handle.
interface NAPHostBridge { setCallback: (handler: { handle: (message: string) => void }) => void; send: (message: string) => void; } |
Et værtssystem skal ligge en sådan bridge på window.NAP - for nærmere beskrivelse af det, henvises til Guide til anvender.
Når "nap-typescript-sdk" kalder "createNAP()", bruger den referencen til denne bridge. Håndtaget til sendMessage() bruges til at initialisere en toHost kanal (fra det indlejrede system til værtssystemet). Håndtaget for setCallback bruges for at opsætte en fromHost kanal (fra værtssytemet til det indlejrede system).
Dependencies skal installeres for både roden og projektet.
Der er defineret et fhir-value-getter namespace med hjælpe funktioner til mappe NAPMessages til de værdier, som egentlig er interessante.
Mapping funktioner | |
Funktionsnavn | Beskrivelse |
---|---|
getFilteredProjects() | Trækker en string liste ud med WebAppShortnames. |
getPatientInfo() | Trækker familyName, givenName og ssNo ud af et PatientOpenEvent |
Der er defineret et fhir-value-setter namespace, som indeholder enums af typiske værdier, der skal sættes i NAPMessages.
Mapping funktioner | |
Type | Beskrivelse |
---|---|
FHIRResourceType | Resource typen for event ('Patient' | 'Basic') |
FHIRSystem | System identifier ('nap') |
FHIRIdentifierSystem | System identifier til cpr, errorMessage og errorDescription |
FHIRextensionURL | Url for extensions WEBAPPSHORTNAMES, WEBAPPSHORTNAME, WEBAPPAUDIENCE, WEBAPPSERVICEENTRY, WEBAPPPRODUCER, WEBAPPRELEASEDATE, WEBAPPURL, WEBAPPCATALOGUEVERSIONS |
Fungerer som versionering af de forskellige events, hvor der udstilles håndtag de events der er implementeret i en given version. Desuden udstiller den også hjælpefunktioner til at generere NAPmessages.
export const EventCatalogue: EventCatalogues = { v1: { WebAppSelected: NAPEventType.WebAppSelected, PatientOpen: NAPEventType.PatientOpen, PatientClose: NAPEventType.PatientClose, ProjectsRetrieved: NAPEventType.ProjectsRetrieved, ProjectsFiltered: NAPEventType.ProjectsFiltered, SessionClose: NAPEventType.SessionClose, SessionError: NAPEventType.SessionError, MessageFactory: { createPatientOpenMessage: createPatientOpenMessageV1, createPatientCloseMessage: createPatientCloseMessageV1, createProjectsRetrievedMessage: createProjectsRetrievedMessageV1, createSessionCloseMessage: createSessionCloseMessageV1, createSessionErrorMessage: createSessionErrorMessageV1, createWebAppSelectedMessage: createWebAppSelectedMessageV1 } }, }; |
Indeholder 3 "projekter".
SDK'et udstiller en service, som sørger for at kalde createNAP() fra nap-typescript-sdket og dermed initialisere NAP bridge (konteksdelingsbroen).
Efterfølgende subscribes der på de forskellige messagestreams, og deres emits bliver håndteret i forhold til Angulars change detection zone og udstillet i nye observables.
|
Effekten for anvenderen bliver, at broen initialiseres som en singleton og at Angular opfanger beskeder sendt over broen og opdaterer UI på baggrund af disse værdier.
Installer dependencies ved at køre npm install --registry https://nexus.nspop.dk/nexus/repository/nsp-npm/
Vær opmærksom på, at der findes en afhængighed til nap-typescript-sdk både for workspacet (package.json) og for selve sdket (projects/nap-angular/package.json). Begge skal opdateres, for at anvende en nye version.
Kør "npm run build" for at bygge projeket med sdk. Dette giver et output i dist/ folderen.
Testimplementeringen har en afhængig til nap-angular-sdk, derfor skal dette bygges, som beskrevet ovenfor, før en udviklings server kan startes.
For at starte en web pack dev server kør "npm run start:dev". Dette vil starte test implementering på (projects/test) http://localhost:4200/.
Jenkins filen beskriver jenkins pipelinen.
Der kan laves snapshots og release-candidates fra jenkins til NSP npm repository.
Versionering af Nap-angular-sdk følger sem versioneringen af Nap-typescript-sdket.
For at lave et release opdateres versionen i workspacet (package.json) og for selve sdket (projects/nap-angular/package.json) hvorefter der køres en `npm i` for at opdatere package-lock.json.
Dernæst laves et tag i SVN på den følgende version manuelt som fx:
svn copy https://svn.nspop.dk/svn/libraries/nap/nap-angular-sdk/trunk \ https://svn.nspop.dk/svn/libraries/nap/nap-angular-sdk/tags/release-1.0.0-rc.1 \ -m "Tagging the 1.0.0-rc.1 release of the 'nap angular sdk' project." |
Det er vigtigt at tagget i svn stemmer overens med versionen i package.json og package-lock.json
Kør `npm run lint` for linting.
Eventuelle fejl skrives til STOUT.
For at generere dokumentation til koden, kør "npm run doc". Dokumentation ligger i docs/ mappen.
Indeholder 2 "projekter".
SDK'et sørger for at kalde createNAP() fra nap-typescript-sdket og dermed initialisere kontekstbroen.
Efterfølgende subscribes der på de forskellige messagestreams, hvor deres emits håndteres i React.state.
De forskellige subscriptions håndtag håndteres i react.useCallback
Dette pakkes ind en NAP-Context, som injectes til alle child elementer heraf.
interface Context { latestIncoming: NAPMessage | null; latestError: NAPError | null; postMessage: (message: NAPMessage) => void; subscribe: (subscriber: NAPHostSubscriber) => void; unsubscribe: (subscriber: NAPHostSubscriber) => void; } |
Installer dependencies ved at køre npm install --registry https://nexus.nspop.dk/nexus/repository/nsp-npm/
Vær opmærksom på, at der findes en afhængighed til nap-typescript-sdk både for for sdket (package.json) og for eksemplet (example/package.json). Begge skal opdateres, for at anvende en nye version.
Kør "npm run build" for at bygge projektet. Dette giver et output i dist/ folderen. Brug "npm run build-prod" for et produktionsbyg.
Jenkins filen beskriver jenkins pipelinen.
Der kan laves snapshots og release-candidates fra jenkins til NSP npm repository.
Versionering af Nap-react-sdk følger sem versioneringen af Nap-typescript-sdket.
For at lave et release opdateres versionen i (package.json), hvorefter der køres en `npm i` for at opdatere package-lock.json.
Dernæst laves et tag i SVN på den følgende version manuelt som fx:
svn copy https://svn.nspop.dk/svn/libraries/nap/nap-react-sdk/trunk \ https://svn.nspop.dk/svn/libraries/nap/nap-react-sdk/tags/release-1.0.0-rc.1 \ -m "Tagging the 1.0.0-rc.1 release of the 'nap react sdk' project." |
Det er vigtigt at tagget i svn stemmer overens med versionen i package.json og package-lock.json
Kør "npm run start" for en byggeserver, der bygge sdk'et hver ændringer gemmes. Outputtet er i dist/ folderen.
Start en ny terminal og navigere ind i example/ folderen og køre "npm run start".
Derefter vil en dev server med live deployment af både eksempel-projektet og SDK'et køre på http://localhost:3000/.
Kør "npm run lint" for linting.
Eventuelle fejl skrives til STOUT.
For at generere dokumentation til koden, kør "npm run doc". Dokumentation ligger i docs/ mappen.