Noter:
Denne del er tilegnet klienter til NSP og specifikt den leverede komponent/service. Denne del skal være tilstrækkelig for en klientleverandør, som skal udvikle aftagersystemer.
Heri tilgodeses specielt referencer til andre dokumenter, da en anvender også skal have en bredere forståelse af den anvendte komponent og eventuelle omgivelse.
Denne guide har til formål at give udviklere af afprøvningsprojekter til NAP eksempler på en webapplikation og en facade.
Nap-reference-web er en web applikation som implementerer nap-typescript-sdk og nap-angular-sdk. Som konsekvens af dette kan denne køres indlejret i et værtssytem (eks. nap-java-host) og kommunikerer med værtssystemet over en injected javascript bridge. Via denne bro henter applikationen SAMLassertion og patientkonteksten fra værtssytemet, hvorefter den kalder den tilhørende facade og forsøger at hente aftale dokumenter med SAMLAssertion som en authentication header.
Nap-reference-facade er en javaapplikation, som implementerer SEAL.java til at validerer SAMLassertion, org.openehealth.ipf.commons til at hente Aftale dokumenter fra Dokumentdelingsservice (DDS), og dk.s4.hl7.builders til at formatere aftaledokumenter fra XML til objekter, hvorfra den hiver den relevante information ud og sender tilbage til klienten.
Nap-reference-web er bygget med Angular 9.1.7 og fungerer som illustration på:
Brug af NAP SDK
Applikationens hovedfunktionalitet er at vise aftaledokumenter for den patient, der er i kontekst i det værtssystem, den er indlejret. Således er der ingen funktionalitet, hvis ikke der findes en NAPbridge på global scope, som når applikationen åbnes i en almindelig browser.
Da angular frameworket lægger sig op af model-view-controller pattern er dette også implementeret i nap-reference-web. Således bliver komponenter, templates og style sheets genereret med `ng g c`.
Derfor er der simple komponenter til at visning aftaler, hjælpinformation, fejl osv.
Services håndterer forretningslogikken og bliver genereret med `ng g s`.
Derfor er der simple services til håndtering af authentication, applikationsfejl og konfigurering osv.
Der ligger en .npmrc, som sørger for at hente dependencies fra https://nexus.nspop.dk/nexus/repository/nsp-npm/
Nap-reference-web benytter sig af en konfigurationsfil (assets/configurtation.json), som loades via configuration-servicen. Denne konfigurationsfil bliver således overskrevet i de forskellige docker-compose setups.
Da NSP web applikationer kan blive deployet på vilkårlige paths, er det vigtigt at applikationen fungerer med relative paths. Derfor blive base i index.html sat dynamisk i app.module.
Nap-reference-web benytter sig af testframeworket Karma, da det kommer default med angular. Karma hiver Istanbul indtil at genere test-coverage rapporter. Testene køres i en headless chromium browser.
Jenskinsfilen beskriver en jenkins pipeline, som anvender NSPs eget docker-image til afvikle tests.
Derudover ligger der en folderstruktur under compose, som skal anvendes til at verificere at byggene virker og som bruges til release opsætning.
Kodedokumentationen bliver generet med TSDoc.
Nap-reference-web implementerer version 1 af eventkataloget.
Session-open starter en trusted session hvor brugerens SAMLassertion overføres. Session-close lukker sessionen og brugerens SAMLassertion slettes. Denne funktionalitet findes i auth-servicen.
export class AuthService {
private innerLogout: Subject<undefined> = new Subject();
public logout$ = this.innerLogout.asObservable();
public session$: Observable<NAPMessage | undefined> = merge(
this.logout$,
this.napSDK.incomming$.pipe(
filterEvents([NAPEventCatalogue.v1.SessionOpen, NAPEventCatalogue.v1.SessionClose]),
shareReplay(1),
startWith(undefined),
)
);
constructor(private napSDK: NapAngularService) {
const napMsg: NAPMessage = {
date: new Date().toISOString(),
id: UUID(),
event: { type: NAPEventCatalogue.v1.SessionOpen },
};
// Ask for the SAMLassertion in host
this.napSDK.sendMessage(napMsg);
}
logout(): void {
this.innerLogout.next(undefined);
}
} |
Patient-open sender den brugervalgte patient journal og patient-close lukker den bruger valgte patient (set fra det indlejrede systems perspektiv). Et eksempel på dette kan ses i appointment.component
constructor(
private napSDK: NapAngularService,
private appointmentService: AppointmentService,
private authService: AuthService
) {
const napMsg: NAPMessage = {
date: new Date().toISOString(),
id: UUID(),
event: {
type: NAPEventCatalogue.v1.PatientOpen,
},
};
this.napSDK.sendMessage(napMsg);
}
public currentPatient$: Observable<NAPPatientInfo | undefined> = this.napSDK.incomming$.pipe(
filterEvent(NAPEventCatalogue.v1.PatientOpen),
map(message => FHIRValueGetter.getPatientInfo(message))
); |
Session-error sendes, hvis der sker en uventet fejl i gæstesystemet skal dette sendes til værtssystemet og vice versa. Et eksempel på dette findes i appointment-service:
private appointmentEndPoint$ = this.configurationService.fetch(
config => config.appointmentsEndpoint
);
private serverUrl = this.configurationService.fetch(config => config.serverUrl);
public getAppointments(patientIdentifier: string | undefined): Observable<any[] | undefined> {
return combineLatest(
[
this.serverUrl,
this.appointmentEndPoint$,
this.serviceActivator
]
).pipe(
switchMap(([serverUrl, endpointPath, _]) => this.http.get<any[]>(serverUrl + endpointPath + '/' + patientIdentifier)),
catchError(error => {
this.errorService.postError(error);
this.napSDK.sendMessage(this.createNapErrorMessage(error)); // indicate to the host that something went wrong
return of(undefined);
}),
);
} |
Nap-reference-facade er bygget med java 8 og fungerer som illustration på:
Brug af Dokumentdelingsservice (DDS)
Dependencies er hentet fra https://nexus.nspop.dk/nexus/content/groups/public og de dependencies, som stilles til rådighed af wildfly8 platformen er angivet med scope provided.
For at kunne kalde Dokumentdelingsservice (DDS) er følgende dependencies anvendt:
dk.sosi.seal | Java-bibliotek til understøttelse af "Den Gode Webservice" og validering af SAMLassertion, se http://digitaliser.dk/group/374971. |
dk.s4.hl7.builders | Dansk profileret XML converter af hl7 aftale - dokumenter |
org.openehealth.ipf.commons | Dansk profileret bibliotek til Cross Enterprise Document sharing. Bruges til at integrere Dokumentdelingsservice (DDS) |
Alt konfiguration foregår ved at loade filer fra er defineret et wildfly module, som der efterfølgende dependes på i jboss-deployment-structure.xml.
Testene bliver eksekveret af maven-surefire-plugin med test frameworket junit. Test coverage bliver målt af Jacoco.
Jenskinsfilen beskriver en jenkins pipeline, som anvender NSPs eget docker-image til at bygge og afvikle tests.
Derudover ligger der en folderstruktur under compose, som skal anvendes til at verificere at byggene virker og som bruges til release opsætning.
Kodedokumentationen bliver generet med Javadoc.