...
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.
...
- 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.
- En dynamisk transformer skapas där 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).
- 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 beroende på om keep-alive skall användas eller ej.
...
Då detta flöde endast innehåller en VP-komponent så kommer ursprunglig avsändare att ha samma värde som senderid. Behörighetskontrollen i VP (GetRecipients) kommer att ske mot detta id.
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.
Get recipients
Behörighetskontrollen kommer att ske mot inkommande senderid.
Create recipient endpoint
...
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 TAK
Nedan beskrivs mer i detalj hur resetcache av vägvalsinformation sker i VP.
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 hämtaAlla
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.
AF6 - Resetcache HSA
Nedan beskrivs mer i detalj hur resetcache av HSA sker i VP.
...