Ideen med DRG er at hjælpe med at udbrede forståelse af hvad NSP komponenter kan og hvordan disse kan kaldes. DRG skal være tilgængelig for ikke-tekniske personer, der ønsker mere viden om NSP, men også brugbar af interessenter, der ønsker en hurtig måde at kalde og inspicere kald til NSP.
Her følger nogle mål, som ønskes at blive opfyldt af løsningen:
Derudover findes der nogle sekundære mål:
Med udgangspunkt i at DRG’s funktionalitet skal kunne udvides over tid, er løsningen baseret på et repository eller en folder i et filsystem med en række navngivne ressourcer. Dette kaldes for DRG data. Det vil være en fordel hvis DRG data blev underlagt revisionskontrol og at brugen heraf er specificeret. Se mere herom senere.
Den basale idé med DRG er at udforme requests mod en NSP komponent. I DRG data vil der være måder at gøre dette mod flere NSP komponenter. For hver udviklet request, vil der findes en måde at konstruere et signeret ID-kort vha. en rolle, samt en måde at stykke et request sammen med forskellige information, der normalt vil indgå i tilhørende requests.
DRG data giver ligeledes mulighed for at formidle ekstra information til brugeren, når brugeren udfylder requestet.
Brugeren skal vælge et request, (underneden et request-id
), et miljø samt en passende rolle. Dernæst skal brugeren udfylde informationer som skal fyldes i en defineret skabelon. Herunder vil brugeren kunne få hjælpetekst præsenteret. Efter udfyldelsen kan brugeren vælge at få requestet præsenteret, dvs. det fulde request, som valgte NSP komponent vil modtage, eller brugere kan vælge blot at få udført requestet, hvorefter svaret præsenteres for brugeren.
I det følgende vil de forskellige typer af ressourcer i DRG data blive beskrevet. Format og semantik vil dog blive mere detaljeret beskrevet senere.
environments.json
indeholder hvilke NSP miljøer, som brugere kan vælge for at lave requests mod.<request-id>.metadata.json
indeholder meta information om det navngivne request.<request-id>.request.json
indeholder information om hvilke informationer et request kan udfyldes med.<request-id>.request.xml
indeholder et skabelon for det navngivne request.<role-id>.role.json
indeholder en rolle beskrivelse.Udover disse type af ressourcer vil der ligeledes være certifikater at finde. Disse burde placeres i en underfolder navngivet certificates
.
Denne type filer indeholder et JSON object, som skal består af følgende felter:
id
- den identifikation, som også findes i filnavnet.name
- navnet der præsenteres i klienten.path
- den sti NSP komponenten kaldes på.soap-action
- den SOAP Action header, requests udfyldes med.authentication
- et JSON array af tags til hjælp af valg af rolle. Her kunne f.eks. stå ["VOCES"]
, hvormed kun rolle, som også har VOCES
benyttes.parents
- et JSON array. Bruges til præsentation i klient for at konstruere et træ af grupperede requests.Dette er en beskrivelse af hvilke informationer, der kommer med i requestet, og indeholder desuden ekstra information til anvendere i forbindelse med udfyldelse.
Overordnet indeholder filer af denne type et JSON object, hvori der kun findes en indgang, fields
, som er et JSON array, med forskellige typer af objekter, men her har de alle til fælles at have et id
og en type
. Førstnævnte er navnet på den information/variable, som bruges til videre udfyldelse af selve requestet.
Her en beskrivelse af de forskellige typer:
enum
, så indeholder objektet ligeledes et JSON-array med mulige værdier for udfyldning.predicate
, så indeholder objektet også en test
indgang, som indeholder en Javascript-funktion (repræsenteret som en streng) til at afgøre om et yderligere antal indgang, nested
skal udfyldes. Denne nested
indgang kan indeholde samme type objekter som fields
; dermed kan udfyldningen forgrenes.string
betyder at brugeren kan indtaste en vilkårlig streng.number
betyder at brugeren kan indtaste et vilkårlig tal.text
indeholder en tekst, som vises til brugeren, hvis den er aktiv, hvilket vil sige er direkte i fields
eller er aktiv i en forgrening.Derudover kan objekter af typen, string
og number
, indeholde et JSON-array, validators
, som er validator-funktioner (igen repræsenteret som en streng) til validering af indhold af feltet.
Rækkefølgen i fields
(og forgreninger) er vigtig, da dette anvendes til gradvis udfyldning af værdier i klienten.
Ud fra en request JSON fremgår en række felter navngivet med deres id
. Ikke alle er nødvendigvis aktive pga. forgrening. En fil af request xml type indeholder selv den SOAP body, der sendes til NSP komponenten. Den endelig body udfyldes dog med førnævnte variable ved hjælpe af Apache Velocity. Der er flere mekanismer i dette template sprog, der hjælper til at håndterer f.eks. forgrening.
Filer af denne type indehoder et JSON objekt med følgende indgange:
id
- den identifikation, som også er indehold i filnavnet.display-name
- det som rollen benævnes i klienten.credential-vault
- et JSON objekt, der indeholder:path
- stien til den keystore, som skal bruges til udfyldes af ID kort.password
- kodeordet til det keystore, der peges på.care-provider
- et JSON objekt, der indeholder:cvr
- det CVR som skal benyttes i ID-kortet (burde matche med anvendte certifikat)org
- indeholder navnet på den anvendte organisation.user-info
- benyttes kun ved MOCES, men indeholde et JSON objekt med: cpr
, first-name
, last-name
, email
, title
, role
, authentication-code
som direkte bruges i ID-kortet.tags
- som tidligere nævnt bruges disse til at matche med requests.