| Innehållsförteckning | ||||
|---|---|---|---|---|
|
AF1 - Normalflöde genom Virtualiseringsplattformen
Nedan beskrivs normalflödet i detalj genom Virtualiseringsplattformen. VPs grundfunktioner såsom virtualisering och behörighetskontroll är speciellt markerade i flödet nedan.
Beskrivning av flödet
Set connector properties
För inkommande HTTP HTTP och HTTPS trafik sätts propertyn "featureResponseTimeout" med ett värde som antingen är ett defaultvärde för VP instansen eller ett unikt värde just för denna tjänsteinteraktion (reglerar time-out för utgående trafik från VP).
För inkommande HTTPS trafik sätts propertyn "featureResponseTimeout" (se ovan) och propertyn "featureUseKeepAlive" som på samma sätt hämtar värden från VP instansen (reglerar keep-alive för utgående HTTPS trafik från VP).
För båda trafikslagen sätts också om keep-alive skall användas samt time-out för denna keep-alive.
Check sender id
Kontrollerar om HTTP headern x_vp_sender_id är satt i inkommande anrop.
Om den är satt kontrolleras att fältet x_vp_instance_id har samma värde som Virtualiseringsplattformen som handhar anropet. Dessutom kontrolleras att anropet kommer från en ip-adress enligt en white-list för denna VP-instans.
Om den inte är satt försöker man hämta ut avsändar identiteten ur ett certifikat. Detta finns antingen i headern x_vp_auth_cert (en white-list kontroll görs då också) eller i session efter SSL/TLS handskakningen.
Oavsett metod sätts fältet senderid med hittat värde i sessionen.
Save consumer id
Om HTTP headern x-rivta-original-serviceconsumer-hsaid är satt sparas den undan i sessions variablen originalServiceconsumerHsaid. (Detta värde skall propageras genom virtualiseringsplattformen till anropet mot Tjänsteproducenten). Här sker också en kontroll
Create corr id
Skapar ett korrelerings id (GUID) och spara undan detta i sessions variabeln soitoolkit_correlationId. Detta id kan användas internt inom Virtualiseringsplattformen för att t.ex. korrelera log-poster.
RIV extractor
Plockar ut RIV-version, receiverId, wsdl namnrymd och tjänstekontrakt. Dessa värden stoppas in i följande sessionsvariabler: rivversion, receiverid, wsdl_namespace och servicecontract_namespace.
LogReqIn
Sparar ner en loggpost med information om det inkommande anropet.
RIV transformer
Kontrollerar om den konfigurerade properties som hanterar time-out och keep-alive.
Handle request
- Ta hand om inkommande HTTP properties.
- Skapa korreleringsid och sätt på inkommande meddelande
- Plocka ut och bearbeta information från inkommande request och kommunikation och spara för senare användning vid routing och behörighetskontroll.
- Logga anropet
RIV transformer
Kontrollerar om matchad Tjänsteproducenten har en annan RIV version är än RIV versionen för inkommande anrop. Om de är olika sker en översättning till den RIV version som Tjänsteproducenten är konfigurerad med.
Get recipients
Hämtar en URL som matchar de parametrar som inkommande anrop har från Vägvalsagenten när det gäller routing. En kontroll att det finns behörighet att göra anropet görs också.
...
Create recipient endpoint
Skapar dynamisk en representation av den ändpunkt dit anropet skall skickas. Egenskaper som vi konfigurerar för denna ändpunkt är bl a följande:
- URL till ändpunkten som vi tidigare fick från Get recipients anropet.
- Response time-out, dvs hur länge vi skall vänta på ett svar från Tjänsteproducenten innan vi signalerar en time-out. Värdet sätts i början av flödet av virtualiseringens connector.Interactionstyp sätts till Request-Response, dvs ett synkront anrop.
- Encoding sätts till UTF-8.
- HTTP header Content-Type sätts till "text/xml; charset=UTF-8"
- En dynamisk transformer skapas där bl a:
- HTTP Header User-Agent sätts till "SKLTP VP/2.0"
- HTTP Header Content-Type sätts till "text/xml; charset=UTF-8" Följande Headers plockas bort så att de inte blir HTTP Headers: rivversion, wsdl_namespace, x_vp_auth_cert, servicecontract_namespace, PEER_CERTIFICATES, LOCAL_CERTIFICATES, Content-Type?fler HTTP Headers konfigureras.
- Följande HTTP Headers läggs till: x_vp_sender_id och x_vp_instance_id
- Följande HTTP Header läggs till: x-rivta-original-serviceconsumer-hsaid. Antingen propageras den vidare från det inkommande anropet (se Save consumer id) eller så sätts den till samma värde som senderid ( se Check sender id).Om propertyn SOAPAction är satt skapas en HTTP Header (SOAPAction) med detta värde.
- Slutligen väljer man vilken connector som skall göra utgående anrop. Antingen är det ett HTTP eller ett HTTPS anrop som skall göras. I samband med detta sätts connector properties enligt:
- HTTP: Här sätts om keep-alive skall användas samt time-out för denna
- HTTPS: Här sätts bestäms om keep-alive skall användas via propertyn featureUseKeepAlive som sattes redan av virtualiseringen. I VP finns två olika HTTPS connectorer definerade som man väljer time-out samt att beroende på om keep-alive skall användas eller ej så väljs en av två HTTPS-connectorer..
Route
Här sker själva anropet till Tjänsteproducenten. Innan anropet sparar vi en tidsstämpel och när anropet gjorts sparar vi undan hur lång tid själva anrop tog i en sessions variabel (x_skltp_prt).
Handle
...
response (VägvalRouter)
- Om ett fel inträffar tar en exception handler vid och hanterar felet så att en Tjänstekonsument får ett SOAPFault som svar med detaljer om felet.
...
- Sparar ner en loggpost med information om svaret.
...
Handle response (Virtualisering)
- Stänger explicit en connection om keep-alive ej skall användas. Gäller endast HTTPS trafik!
WSDL query respons
...
- Hanterar att ett GET anrop (?wsdl) som i ett svar pekar på interna adresser (som en Tjänstekonsument ej kommer åt
...
- ) byts ut.
- Plockar bort
...
- properties ur sessionen som annars blir HTTP Headers i svaret till Tjänstekonsumenten
...
- SOAPAction
- MULE_CORRELATION_GROUP_SIZE
- MULE_CORRELATION_ID
- MULE_ENCODING
- http.methodLOCAL_CERTIFICATES
- PEER_CERTIFICATES
AF2 - Ursprunglig avsändare
Nedan beskrivs mer i detalj hur informationen om ursprunglig avsändare propageras genom VP till en tjänsteproducent. Endast de funktioner från normalflödet som är delaktiga i hanteringen av ursprunglig avsändare är med i nedanstående flöde.
En VP-komponent
Då detta flöde endast innehåller en VP-komponent så kommer ursprunglig avsändare att ha samma värde som senderid.
Beskrivning av flödet
Handle request
Kontrollerar om HTTP headern x-rivta-original-serviceconsumer-hsaid är satt i inkommande anrop, vilket den inte skall vara då anropet kommer från en tjänstekonsument. Behörighetskontrollen i VP (GetRecipients)
Get recipients
Behörighetskontrollen kommer att ske mot detta id.
inkommande senderid.
Create recipient endpoint
HTTP Headern x-rivta-original-serviceconsumer-hsaid läggs till på ändpunkten och sätts till samma värde som senderid, dvs tjänstekonsumentens identitet.
Route
HTTP headern x-rivta-original-serviceconsumer-hsaid går iväg i anropet till tjänsteproducenten.
Två VP-komponenter
Om det finns en VP-komponent ytterligare i flödet kommer den första VP-komponenten bete sig som ovan, dvs sätta ursprunglig avsändare att vara detsamma som senderid. För den andra VP-komponenten kommer värdet på ursprunglig avsändare att sättas till värdet på den inkommande HTTP headern (x-rivta-original-serviceconsumer-hsaid). Däremot kommer behörighetskontrollen att göras mot det senderid som motsvaras av VP (RTJP).
Beskrivning av flödet
Handle request - VP RTJP
Kontrollerar om HTTP headern x-rivta-original-serviceconsumer-hsaid är satt i inkommande anrop, vilket den inte skall vara då anropet kommer från en tjänstekonsument.
Get recipients - VP RTJP
Behörighetskontrollen kommer att ske mot inkommande senderid.
Create recipient endpoint - VP RTJP
HTTP Headern x-rivta-original-serviceconsumer-hsaid läggs till på ändpunkten och sätts till samma värde som senderid, dvs tjänstekonsumentens identitet.
Route - VP RTJP
HTTP headern x-rivta-original-serviceconsumer-hsaid går iväg i anropet till tjänsteproducenten.
Handle request - VP NTJP
Kontrollerar om HTTP headern x-rivta-original-serviceconsumer-hsaid är satt i inkommande anrop, vilket den är!
Get recipients - VP NTJP
Behörighetskontrollen kommer att ske mot inkommande senderid som motsvaras av VP RTJP.
Create recipient endpoint - VP NTJP
HTTP Headern x-rivta-original-serviceconsumer-hsaid läggs till på ändpunkten och sätts till samma värde som inkommande x-rivta-original-serviceconsumer-hsaid.
Route - VP NTJP
HTTP headern x-rivta-original-serviceconsumer-hsaid går iväg i anropet till tjänsteproducenten.
Tre VP-komponenter
I det sista fallet har vi ytterligare en VP-komponent i flödet. Den sista VP-komponenten kommer att uppföra sig exakt som den mellersta VP-komponenten. Ursprunglig avsändare propageras vidare för att till slut nå Tjänsteproducenten.
Beskrivning av flödet
Se beskrivning för två VP-komponenter!
AF3 - Keep-alive
Nedan beskrivs mer i detalj hur keep-alive används i VP. Endast de funktioner från normalflödet som är delaktiga i keep-alive är med i nedanstående flöde.
Beskrivning av flödet
Set connector properties
Här anges om keep-alive skall användas och isåfall vilken time-out som skall gälla för denna. Denna kan konfigureras fingranulärt per virtualisering genom properties i VP.
Create recipient endpoint
Här väljs vilken connector som skall användas och om keep-alive skall användas sätts keep-alive värden för denna connector.
Route
Anropet går iväg till tjänsteproducenten och keep-alive kapabiliteter förhandlas under uppsättningen av kommunikationen.
AF4 - Timeout
Nedan beskrivs mer i detalj hur time-out sätts i VP. Endast de funktioner från normalflödet som är delaktiga i time-out hanteringen är med i nedanstående flöde.
Beskrivning av flödet
Set connector properties
Här anges vilken time-out som skall gälla för utgående trafik. Denna kan konfigureras fingranulärt per virtualisering genom properties i VP.
Create recipient endpoint
Här väljs vilken connector som skall användas och angiven time-out tas från värdet från "Set connector properties".
Route
Anropet går iväg till tjänsteproducenten där time-out fås om ett svar inte kommer inom konfigurerad time-out tid.
AF5 - Resetcache
...
AF6 - Lastbalansering proxy HTTPS och HTTP
Information i HTTP-headers från en proxy
AF7 - Övervakning med PingForConfiguration
...
TAK
Nedan beskrivs mer i detalj hur resetcache av vägvalsinformation sker i VP. Internt sker ett anrop från Vägvalsroutern även när VP startar upp.
Beskrivning av flödet
ResetVagvalcache
Här anges vilken time-out som skall gälla för utgående trafik. Denna kan konfigureras fingranulärt per virtualisering genom properties i VP.
GetVirtualiseringar
Alla virtualiseringar som gäller hämtas från TAK via ett anrop till tjänsten hamtaAllaVirtualiseringar.
GetBehorigheter
Alla anropsbehörigheter som gäller hämtas från TAK via ett anrop till tjänsten hamtaAllaAnropsbehorigheter.
SaveToLocalCopy
Om anropen till TAK har gått bra skapas en ny TAK-cache internt i VP och sparas som en fil till disk. Om ett fel upptäcks byts inte TAK-cachen ut och ingen fil sparas till disk.
AF6 - Resetcache HSA
Nedan beskrivs mer i detalj hur resetcache av HSA sker i VP. Internt sker ett anrop från Vägvalsroutern även när VP startar upp.
Beskrivning av flödet
ResetHsacache
Här anges vilken time-out som skall gälla för utgående trafik. Denna kan konfigureras fingranulärt per virtualisering genom properties i VP.
Reload from file
Här läses en fil som innehåller HSA-information och ett HSA-träd byggs upp och sparas i HSA-cachen (HSA filen hämtas i en annan process).
AF7 - Reverse-proxy HTTPS
Nedan beskrivs mer i detalj hur headers hanteras bakom en reverse-proxy.
Beskrivning av flödet
Certificate to header
Här plockas Tjänstekonsumentens certifikat och stoppas i en HTTP Header ( x_vp_auth_cert) och ett anrop görs via HTTP in till VP.
Handle request
Här bestäms senderid genom att titta efter HTTP Headers och i detta fall specifikt efter den header där tjänstekonsumentens certifikat finns. Dessutom kontrolleras att anropet sker från en ip-adress som VP litar på dvs Reverse-proxyn i detta fallet.
Request
Här skickas anropet vidare till tjänsteproducenten.