Page History

Baggrund

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.

Målsætninger

Her følger nogle mål, som ønskes at blive opfyld af løsningen:

• Det skal være muligt at udvide funktionaliteten af DRG uden af nye releases af komponenten skal rulles ud.
• DRG funktionaliteten skal være tilgængelig for alle (med passende akkreditiver) vha. en gængs Web browser.
• DRG skal kunne komme til at kalde alle NSP komponenter. I første version begrænses dette dog til ID-kort baserede services.

Derudover findes der nogle sekundære mål:

• Hjælpe NSP anvendere og NSP leverandører med at integrere med øvrige NSP komponenter.
• Hjælpe med til aftestning af komponenter. Her tænkes specielt på let adgang til STS signerede ID-kort til brug i testrequests.

Løsningen

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 revisions kontrol og at brugen heraf er specificeret. Se mere herom senere.

Requests

Ideen med DRG er at udform 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 en signeret ID-kort vha en rolle samt en måde at stykke et requests 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ære et request, (underneden et request-id), et miljø samt en passende rolle. Dernæst skal brugeren udfylde informationer som skal fyldes i den definerede 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.

Ressourcer

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.

Metadata

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"], hvor med kun rolle, som også har VOCES benyttes.
• parent bruges til præsentation i klient for at konstruere et træ.

Request JSON

Dette er en beskrivelse af hvilke informationer, der komme med i requestet, og indeholder desuden ekstra information til anvendere i forbindelse med udfyldes.

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 udfyldes 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 javascript til afgøres af om en yderligere 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 en validator, som er en stump javascript 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.

Request XML

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.

Roller

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 er 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 er 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.