Use Cases Adressering Server
Overzicht Adressering Server
Onderstaande figuur toont een overzicht van de interfaces, services en functies van de Adressering Server.
De Adressering Server helpt bij het bepalen welke interacties en versies, uit een beoogde set, kunnen worden geïnitieerd bij een bepaalde Resource Server. Verder biedt de Adressering Server ook informatie over interacties die uitgevoerd kunnen worden. De Adressering Server houdt ook rekening met transformaties tussen informatiestandaarden die eventueel, op het pad tussen Resource Client en Resource Server, zouden kunnen worden uitgevoerd.
Tevens biedt de Adressering Server Resource Clients de mogelijkheid om informatie op te halen over interacties (bijvoorbeeld compatibele interacties, zodat Resource Clients bij zoekopdrachten in ZORG-AB rekening te kunnen met welke interacties doelsystemen kunnen ontvangen).
De services zijn toegankelijk via een geboden interface en worden beschreven in de vorm van use cases. Een service wordt altijd vervult middels één of meerdere applicatiefuncties, bijvoorbeeld "Adressering".
Bepaal route
Primaire actor | Resource Client, RB MedMij-in, Autorisatie Server ZA |
|---|---|
Systeem | Adressering Server |
Secundaire actor | Resource Broker APR, Transformatie Server, ZORG-AB |
Code | |
Realiseert Feature |
Pre-condities
Het systeem is slechts benaderbaar voor
|
Het systeem beschikt over up-to-date gegevens betreffende de door RB MedMij-in ondersteunde MedMij gegevensdiensten, en de daarbinnen gehanteerde AORTA interactie-id's. |
Het systeem beschikt over een voldoende actueel AORTA Stelseltoken die het via de AORTA Stelsel Metadata Interface heeft verkregen. |
Het systeem beschikt over up-to-date gegevens betreffende de ondersteunde interacties en compatible interacties. |
Het systeem beschikt over up-to-date gegevens betreffende de ondersteunde transformaties (transformatie server metadata), die het heeft verkregen via Feature getTransformatieMetadata. De base-URL van de Transformatie Server is verkregen uit het AORTA Stelseltoken. |
Het systeem beschikt over up-to-date gegevens betreffende ondersteunde scopes van externe GTK’s. |
Triggers
De primaire actor stuurt een routing info request in
Main flow
AOF.UCe.VAL.100.v1 - Toetsing type content | Uitkomst | |
|---|---|---|
Stap | Omschrijving | |
i | Het systeem ontvangt een verzoek en start de verwerking. Het systeem toetst of het gevraagde type content (Accept header) en het gehanteerde type content (Content-Type header) worden ondersteund. NB. wanneer het verzoek wordt ontvangen van een component van VZVZ, dan hoeft geen toets op type content te worden uitgevoerd. | Gevraagd type content niet ondersteund statuscode 406 Not Acceptable
|
Gehanteerd type content niet ondersteund statuscode 415 Unsupported Media Type
| ||
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
Stap | Omschrijving | Uitkomst |
|---|---|---|
1 | Het systeem toetst of het verzoek voldoet aan de interface specificatie. | Ongeldig verzoek statuscode 400 Bad Request |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
2 | Het systeem stelt vast voor het verzoek voor welke interactie-id('s) routing info wordt gevraagd. Zie de Toelichting bepalen ontvangen interactie-id(s) NB. interacties van het type transaction of batch, worden hierin vooralsnog niet uitgesplitst in de individuele interacties die deel uitmaken van de batch/transaction. Tijdelijke work-around (nodig tot GBZ-applicaties cancelation van notificaties gaan ondersteunen). Indien de uitvoerbare interactie een “update:twiin-TaskNotifiedPull:1” interactie betreft, dan behandelt het systeem deze als “create:twiin-TaskNotifiedPull:1“. In de response (exit stap) wordt als interactie-id echter wel opgenomen “update:twiin-TaskNotifiedPull:1“. | Interactie-id kan niet worden bepaald (komt niet voor in de AORTA interactietabel en/of is onjuist) statuscode 400 Bad Request |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
3 | Het systeem stelt vast voor voor het verzoek welke beoogde doel systeem(en) routing info wordt gevraagd. Zie de Toelichting bepalen beoogde destination(s). | Destination kan niet worden bepaald statuscode 400 Bad Request |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
4 | Het systeem stelt de routeringsinformatie vast m.b.v. het routeringsalgoritme. Als input voor het routeringsalgoritme wordt het interactie-id(s) en beoogde doelsystem(en) gebruikt. Zie de Beschrijving routeringsalgoritme. | Destination niet gevonden statuscode 404 Not Found |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
5 <exit> | Het systeem retourneert een response naar de primaire actor. | Verwerking succesvol statuscode 200 OK |
Post-condities
Het systeem heeft het verzoek op de juiste wijze verwerkt en heeft een daarbij passende response geretourneerd. |
Het systeem heeft van het ontvangen request, de volgende attributen gelogd:
== Het systeem heeft voor ieder uitgaand request, dat bij het doorlopen van de use case werd verzonden, de volgende attributen gelogd:
|
Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:
== Het systeem heeft voor iedere response, die bij het doorlopen van de use case werd ontvangen, de volgende attributen gelogd:
|
Toelichting bepalen ontvangen interactie-id(’s)
De Adressering Server moet uit het verzoek bepalen voor welke interactie‑id(s) routeringsinformatie is opgevraagd. Voor elk ontvangen interaction‑object wordt één interactie‑id bepaald. De wijze waarop het interactie‑id wordt bepaald, is afhankelijk van de samenstelling van het ontvangen interaction‑object.
Bepalingswijze 1 – interaction.id
Indien het interaction‑object is gevuld met het attribuut id, wordt dit attribuut gebruikt als interactie‑id. Het versie‑deel in het id‑attribuut wordt geïnterpreteerd als een major versienummer conform semver (bijv. 1, * of x).
Voorbeeld: search:mp-MedicationAgreement:1
Bepalingswijze 2 – method + url + aortaVersion (Legacy)
Indien het interaction‑object is gevuld met method, url en aortaVersion, bepaalt de Adressering Server het interactie‑id door:
het interactietype af te leiden uit de HTTP‑method;
het resource‑type en eventueel resource‑id af te leiden uit de URL;
de interactieversie af te leiden uit
aortaVersion.
Eventuele URL‑parameters en een meegezonden base‑URL worden genegeerd. Deze methode wordt uitsluitend gebruikt voor legacy interacties.
Voorbeeld: read:Observation:2.1:request of search:Observation:2.1:request
Bepalingswijze 3 – type + fhirProfile + fhirProfileVersion
Indien het interaction‑object is gevuld met type, fhirProfile en fhirProfileVersion, stelt de Adressering Server het interactie‑id samen op basis van:
het FHIR interactietype (
type);het opgegeven FHIR‑profiel;
de major versie van het FHIR‑profiel, afgeleid uit
fhirProfileVersion.
Voorbeeld: read:zib-LivingSituation:2
Bepalingswijze 4 – type + fhirProfile
Indien het interaction‑object is gevuld met type en fhirProfile, stelt de Adressering Server het interactie‑id samen op basis van:
het FHIR interactietype (
type);het opgegeven FHIR‑profiel.
In dit geval wordt geen versie vastgelegd.
Voorbeeld: search:zib-LivingSituation
Toelichting bepalen beoogde destination(s)
De Adressering Server moet uit het verzoek bepalen voor welke beoogde doel systeem(en) routeringsinformatie is opgevraagd. Dit kan resulteren in 0..n appIDs of 0..1 URA. De wijze waarop de destination wordt bepaald, is afhankelijk van de gebruikte samenstelling van het interaction‑object:
Voor interaction‑bepalingswijzen 1, 3 en 4 wordt de beoogde destination appID of URA bepaald op basis van het destination‑object.
Voor interaction-bepalingswijze 2 (Legacy) wordt de destination appID:
Indien de
interaction.urleen appID bevat wordt deze gebruikt als beoogde destinationIndien de
interaction.urlgeen appID bevat wordt het destination bepaald op basis van het destination-object.
Indien meerdere interaction-objecten aanwezig zijn, kan per interaction een andere wijze van destination-bepaling van toepassing zijn.
Merk op, De Adressering Server kan meerdere beoogde destinations (appIDs en/of URA) bepalen; de uiteindelijke selectie van een destination vindt plaats in vervolgstappen van de flow.
Beschrijving routeringsalgoritme
Het routeringsalgoritme heeft als doel om, gegeven een ontvangen interactie‑id en beoogde destination(s), de beste uitvoerbare match te bepalen tussen de versturende en ontvangende interactie‑id’s waarvoor zowel client als server aantoonbaar de vereiste conformances, transformaties en autorisatiecontext ondersteunen. Het algoritme omvat de volgende stappen:
Voor elke ontvangen interactie(s) wordt bepaald m.b.v. de Transformatie server getTransformatieMetadata, vast welke uitvoerbaar zijn (eventueel na toepassing van een transformatie) en naar welke uitgaande interactie‑id’s deze zou worden getransformeerd.
Voor de uitvoerbare interactie(s) wordt bepaald of de beoogde doelsysteem(en) de interactie ondersteunen (de conformance om het interactie-id te kunnen verwerken).
De Resource Broker GTK wordt hierin als reguliere GBx-applicatie (Resource Server) beschouwd. RB GTK heeft één appID, en kan interacties opzetten met alle, op Twiin aangesloten, externe GTK’s.
Indien het beoogde doel systeem een URA is wordt bepaald, m.b.v. het Applicatie Register (APR) getApplications bepaald welke appIDs bij deze URA horen en welke conformances deze hebben. Er wordt bepaald welke appIDs de uitvoerbare interactie(s) ondersteunen.
Indien het beoogde doel systeem appID(s) betreft wordt bepaald, m.b.v. het APR getApplication welke appIDs de uitvoerbare interactie(s) ondersteunen.
Op alle van de APR ontvangen conformances worden additionele toetsen uitgevoerd. Zie de Toelichting conformance en Toelichting additionele conformance toetsen).
Indien in stap 2 geen geschikte appID gevonden is in het APR wordt m.b.v. ZORG-AB gecontroleerd welke interacties de URA kan ontvangen.
Voor elke appID wordt op basis van de opgehaalde systeemrollen bepaald of de de appID AORTA access_tokens kan verwerken, en zo ja wat de hoogste versie is die wordt ondersteund.
Indien een transformatie vereist is, wordt altijd minimaal AORTA access_token versie 3 toegepast
Voor een v3-bron is dit de hoogste versie die door de RB VnC wordt ondersteund.
Bij een fhir-bron moet de hoogste ondersteunde versie van de GBx-applicatie (resource server) worden meegegeven.
Op basis van de verzamelde uitvoerbare routes selecteert de Adressering Server per destination (appID) de beste uitvoerbare match. De selectie vindt plaats op basis van de hieronder beschreven voorkeursregels bepalen route.
Indien voor een interactie geen uitvoerbare route kan worden bepaald, wordt voor deze interactie geen destinationInfo opgenomen in de getRoutingInfoResponse.
Het resultaat van het routeringsalgoritme wordt opgenomen in de routeringsinformatie (getRoutingInfoResponse)
Toelichting conformances
Het APR bevat gegevens over welke systeemrollen een applicatie ondersteunt. Deze APR-gegevens zijn ook opvraagbaar via ZORG-AB.
Aan een systeemrol zijn, indien van toepassing, conformanceregels verbonden, met daarin de volgende gegevens:
interactie-id
ontvangen (ja/nee)
verzenden (ja/nee)
Het interactie-id heeft voor FHIR-interacties de volgende structuur:
<basis interactietype>:<FHIR-profiel>:<major FHIR profiel versie>, bijv. "search:mp-MedicationAgreement:1", OF
operation:<operation name>:<major operation versie>, bijv. "operation:$get-aorta-data:1".Voor oude interactie-id’s (<= AoF 0.7) geldt: de FHIR code (bijvoorbeeld "search" of "read"), het FHIR resourcetype (bijvoorbeeld "Observation") en interactieversie (bijvoorbeeld "1.0.x") worden tezamen opgevat als een interactie-id, en wel in het formaat "<code>:<resourcetype>:<versie>:<request/response>". Voorbeeld: “search:Observation:2.1:request”.
HL7v3-interacties worden in het APR altijd geregistreerd in request-response-paren. Voor FHIR-interacties wordt altijd gewerkt met één conformance voor een interactie, namelijk degene voor een request-interactie. Bijvoorbeeld, wanneer een GBx-applicatie een FHIR-request mag verzenden, dan mag deze applicatie altijd ook de bijbehorende response ontvangen. Wanneer een GBx-applicatie een FHIR-request mag ontvangen, dan mag ook de bijbehorende response worden geretourneerd (verzonden).
Om een v3-interactie te mogen initiëren (initiate=yes) en de bijbehorende response te mogen ontvangen heeft een GBx-applicatie een conformance nodig voor de request-interactie en één voor de bijbehorend response-interactie:
Initiëren van een request - verzenden “ja”.
Ontvangen van bijbehorende response - ontvangen “ja”.
Om een medische bouwsteen via een generieke query (HL7v3) te kunnen opvragen (trigger=yes), heeft een initiërende GBx-applicatie, naast conformances voor de generieke query, conformances nodig voor:
De betreffende v3-request-interactie, waarbij verzenden op “nee” staat en ontvangen op “nee” staat, EN voor de bijbehorende v3-response-interactie, waarbij ontvangen op “ja” staat (het laatste wordt geborgd door het TKID-proces).
Om een v3-interactie te mogen ontvangen (process=yes) en de bijbehorende response te mogen retourneren heeft een GBx-applicatie een conformance nodig voor de request-interactie en één voor de bijbehorend response-interactie:
Ontvangen van een request - ontvangen “ja”.
Retourneren van bijbehorende response - verzenden “ja”.
In het TKID-proces wordt geborgd dat een v3-systeem altijd beschikt over benodigde conformances voor de responses, doordat request-response paren zijn opgenomen in eenzelfde systeemrol.
Om een FHIR-interactie te mogen initiëren (initiate=yes) en de bijbehorende response te mogen ontvangen heeft een GBx-applicatie, zoals gezegd, slechts een conformance nodig voor de request-interactie:
Initiëren van een request inclusief ontvangen van bijbehorende response - verzenden “ja”.
Om een medische bouwsteen via een $get-aorta-data operation (HL7FHIR) te kunnen opvragen (trigger=yes), heeft een initiërende GBx-applicatie, naast een conformance voor de $get-aorta-data, een conformance nodig voor:
de betreffende FHIR-interactie, waarbij verzenden op “ja” OF op “nee” staat en waarbij ontvangen op “nee” staat.
Om een FHIR-interactie te mogen ontvangen (process=yes) en de bijbehorende response te mogen retourneren heeft een GBx-applicatie een conformance nodig voor de request-interactie:
Ontvangen van een request inclusief retourneren van bijbehorende response - ontvangen “ja”.
Toelichting additionele conformance toetsen
Het systeem toetst altijd ook of een destination (appID) in staat is om interacties te verwerken ten behoeve van MedMij, danwel ten behoeve van zorgaanbieder-zorgaanbieder uitwisseling. Dit wordt gedaan middels specifieke systeemrollen in het APR:
DVZA.BES* voor MedMij uitwisseling.
GBZ.BES* voor zorgaanbieder-zorgaanbieder uitwisseling binnen AORTA.
NB. aangezien v3-systemen allemaal verkeer moeten ontvangen van GBZ'en, maar de systeemrol GBZ.BES* nog niet hebben gekoppeld, is het noodzakelijk dat de Adressering Server er vooralsnog vanuit gaat dat, wanneer een v3-interactie zal worden uitgestuurd, het betreffende systeem altijd open staat voor ontvangst van zorgaanbieder-zorgaanbieder verkeer.
Een routing info request heeft betrekking op zorgaanbieder-zorgaanbieder uitwisseling wanneer deze wordt ingestuurd door Autorisatie Server ZA, of door een GBx-applicatie.
Een routing info request heeft betrekking op MedMij uitwisseling wanneer deze wordt ingestuurd door Resource Broker MedMij-in.
Voorkeursregels bepalen route
Indien de client, m.b.v. de Applicatieregister hasConformance , een interactie niet ondersteunt, dan wordt voor deze nooit destinationInfo opgenomen in de getRoutingInfoResponse. De client mag deze interactie immers niet initiëren.
Indien een client RoutingInfo vraagt voor meerdere interacties, die functioneel equivalent zijn aan elkaar, dan wordt hiervan, per destination (appID), voor maximaal één interactie destinationInfo opgenomen in de getRoutingInfoResponse (dataminimalisatie).
Voor een interactie wordt, bij een specifieke destination (appID), slechts destinationInfo opgenomen in de getRoutingInfoResponse wanneer de betreffende GBx-applicatie deze interactie, of een compatible versie ervan, of een transformeerbare versie ervan blijkens het APR ondersteund.
Bij de selectie van de juiste interactie uit een set van interacties die tot eenzelfde groep behoren gelden de volgende eisen:
Niet transformeren heeft de voorkeur boven een nieuwere versie gebruiken.
Exact dezelfde interactie heeft voorkeur boven gebruik van een nieuwere compatible versie.
Nieuwe versie gaat voor een oudere versie. Let op: interacties binnen eenzelfde protocol kunnen functioneel equivalent zijn, maar een totaal ander interactie-id hanteren. In deze situaties kan de nieuwste versie worden bepaald a.d.h.v. een preference attribuut in de AORTA interactietabel.
Client-specifieke filtering en selectie van interacties wordt slechts gedaan wanneer een appID is ontvangen van de client.
Wanneer in één request RoutingInfo wordt gevraagd voor meer dan één destination, dan wordt bovenstaand algoritme uitgevoerd voor iedere gevonden destination (appID), waardoor eenzelfde interactie, door de client, dus mogelijk kan worden geïniteerd bij meerdere applicaties van eenzelfde zorgaanbieder.
Voorbeeld werking routeringsalgoritme
Inhoud van de interactietabel:
interactieId | Preference | Protocol | groupId |
|---|---|---|---|
create:vitalsign-bloodglucose:1 | 2 | application/fhir | create:LaboratoryTestResult:1 |
create:vitalsign-bloodglucose:2 | 1 | ||
ZTZM_IN000004NL01 | 1 | application/hl7-v3 | |
search:mp-MedicationAgreement:1 | 1 | application/fhir | search:MediationAgreement:1 |
QUMA_IN991201NL04 | 1 | application/hl7-v3 | |
search:mp-VariableDosingRegimen:1 | 1 | application/fhir | search:VariableDosingRegimen:1 |
QUDS_IN000001NL01 | 1 | application/hl7-v3 | |
search:mp612-DispenseToFHIRConversion-AdministrationAgreement:1 | 3 | application/fhir | search:AdministrationAgreement |
search:mp-AdministrationAgreement:1 | 1 | application/fhir | |
search:zib-AdministrationAgreement:2 | 2 | application/fhir | |
QURX_IN990111NL | 2 | application/hl7-v3 | |
QUTA_IN991211NL02 | 1 | application/hl7-v3 |
Interacties delen eenzelfde groupId wanneer ze functioneel equivalent zijn. Verschillende interacties zijn technisch, per definitie, niet gelijk aan elkaar.
Functioneel equivalente interacties kunnen al dan niet transformeerbaar zijn naar elkaar. Ondersteunde transformaties worden vastgelegd in de Transformatie Server metadata.
Inhoud van de Transformatie Server metadata:
Transformatie Algoritme ID | Input | Output | ||||
Type | Protocol | Interactie-ID | Type | Protocol | Interactie-ID | |
|---|---|---|---|---|---|---|
1.1 | request | application/fhir+xml, application/fhir+json | create:vitalsign-bloodglucose:1 | request | application/hl7-v3+xml | ZTZM_IN000004NL01 |
1.2 | request | application/fhir+xml, application/fhir+json | create:vitalsign-bloodglucose:2 | request | application/fhir+xml, application/fhir+json | create:vitalsign-bloodglucose:1 |
2.1 | request | application/fhir+xml, application/fhir+json | search:mp-MedicationAgreement:1 | request | application/hl7-v3+xml | QUMA_IN991201NL04 |
2.2 | response | application/hl7-v3+xml | QUMA_IN991203NL04 | response | application/fhir+xml, application/fhir+json | search:mp-MedicationAgreement:1 |
3.3 | request | application/fhir+xml, application/fhir+json | search:mp-AdministrationAgreement:1 | request | application/hl7-v3+xml | QUTA_IN991211NL02 |
3.4 | response | application/hl7-v3+xml | QUTA_IN991213NL02 | response | application/fhir+xml, application/fhir+json | search:mp-AdministrationAgreement:1 |
3.5 | request | application/hl7-v3+xml | QUTA_IN991211NL02 | request | application/fhir+xml, application/fhir+json | search:mp-AdministrationAgreement:1 |
3.6 | response | application/fhir+xml, application/fhir+json | search:mp-AdministrationAgreement:1 | response | application/hl7-v3+xml | QUTA_IN991213NL02 |
request (oorspronkelijk request) | application/hl7-v3+xml | QUTA_IN991211NL02 | ||||
3.7 | request | application/fhir+xml, application/fhir+json | search:mp-AdministrationAgreement:1 | request | application/hl7-v3+xml | QURX_IN990111NL |
3.8 | response | application/hl7-v3+xml | QURX_IN990113NL | response | application/fhir+xml, application/fhir+json | search:mp-AdministrationAgreement:1 |
Betreffende interactie, zoals benoemd in de input, kan, na de genoemde transformatie, worden geïnitieerd bij een server die de interactie, zoals benoemd in de output, ondersteund.
Inhoud van het APR:
Applicatie | Conformances (send + receive) |
|---|---|
1 | create:vitalsign-bloodglucose:1 |
2 | create:vitalsign-bloodglucose:2 |
3 | ZTZM_IN000004NL01 |
4 | search:mp-MedicationAgreement:1 search:mp-VariableDosingRegimen:1 |
5 | QUMA_IN991201NL04 QUMA_IN991203NL04 |
6 | QUDS_IN000001NL01 QUDS_IN000003NL01 |
7 | search:mp-AdministrationAgreement:1 search:zib-AdministrationAgreement:2 |
8 | QURX_IN990111NL QUTA_IN991211NL02 |
9 | search:zib-AdministrationAgreement:2 QUTA_IN991211NL02 |
Inhoud van getRoutingInfoRequest en getRoutingInfoResponse:
getRoutingInfoRequest | getRoutingInfoResponse | ||||
|---|---|---|---|---|---|
Client | Destination | Interactions | Destination | Interaction | Transformation |
1 | 2, 3 | create:vitalsign-bloodglucose:1 | 3 | create:vitalsign-bloodglucose:1 | 1.1 |
2 | 1, 3 | create:vitalsign-bloodglucose:2 | 1 | create:vitalsign-bloodglucose:2 | 1.2 |
3 | 1, 2 | ZTZM_IN000004NL01 | - | - | - |
4 | 5, 6 | search:mp-MedicationAgreement:1 search:mp-VariableDosingRegimen:1 | 5 | search:mp-MedicationAgreement:1 | 2.1 |
Onbekend | 2, 3 | create:vitalsign-bloodglucose:1 create:vitalsign-bloodglucose:2 | 2 | create:vitalsign-bloodglucose:2 | - |
3 | create:vitalsign-bloodglucose:1 | 1.1 | |||
7 | 8 | search:zib-AdministrationAgreement:2 | - | - | - |
7 | 8 | search:mp-AdministrationAgreement:1 | 8 | search:mp-AdministrationAgreement:1 | 3.3 |
7 | 9 | search:mp-AdministrationAgreement:1 search:zib-AdministrationAgreement:2 | 9 | search:zib-AdministrationAgreement:2 | - |
Ophalen interactie info
Primaire actor | Resource Client (GBx-applicatie) |
|---|---|
Systeem | Adressering Server |
Secundaire actor | Transformatie Server |
Code | |
Realiseert Feature |
Pre-condities
Het systeem is slechts benaderbaar voor
|
Het systeem beschikt over een voldoende actueel AORTA Stelseltoken die het via de AORTA Stelsel Metadata Interface heeft verkregen. |
Het systeem beschikt over up-to-date gegevens betreffende de ondersteunde interacties en compatible interacties. |
Het systeem beschikt over up-to-date gegevens betreffende de ondersteunde transformaties (transformatie server metadata), die het heeft verkregen via Feature getTransformatieMetadata. De base-URL van de Transformatie Server is verkregen uit het AORTA Stelseltoken. |
Triggers
De primaire actor stuurt een interaction info request in
Main flow
AOF.UCe.VAL.100.v1 - Toetsing type content | Uitkomst | |
|---|---|---|
Stap | Omschrijving | |
i | Het systeem ontvangt een verzoek en start de verwerking. Het systeem toetst of het gevraagde type content (Accept header) en het gehanteerde type content (Content-Type header) worden ondersteund. NB. wanneer het verzoek wordt ontvangen van een component van VZVZ, dan hoeft geen toets op type content te worden uitgevoerd. | Gevraagd type content niet ondersteund statuscode 406 Not Acceptable
|
Gehanteerd type content niet ondersteund statuscode 415 Unsupported Media Type
| ||
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
Stap | Omschrijving | Uitkomst |
|---|---|---|
1 | Het systeem toetst of het verzoek voldoet aan de interface specificatie. | Ongeldig verzoek statuscode 400 Bad Request |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
2 | Het systeem stelt vast voor welke ontvangen interactie-id('s) interactie info wordt gevraagd. Zie de Toelichting bepalen ontvangen interactie-id(s) | Interactie-id kan niet worden bepaald (komt niet voor in de AORTA interactietabel en/of is onjuist) statuscode 400 Bad Request |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
3 | Het systeem bepaald m.b.v. de transformatie server metadata de interactie-ids waarnaar de gevraagde interactie getransformeerd kan worden. | |
4 <exit> | Het systeem retourneert een response naar de primaire actor. | Verwerking succesvol statuscode 200 OK |
Post-condities
Het systeem heeft het verzoek op de juiste wijze verwerkt en heeft een daarbij passende response geretourneerd. |
Het systeem heeft van het ontvangen request, de volgende attributen gelogd:
== Het systeem heeft voor ieder uitgaand request, dat bij het doorlopen van de use case werd verzonden, de volgende attributen gelogd:
|
Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:
== Het systeem heeft voor iedere response, die bij het doorlopen van de use case werd ontvangen, de volgende attributen gelogd:
|