Sidjämförelse

...

Beskrivning av flödet

Set connector properties

För inkommande HTTP  och HTTPS trafik sätts

...

properties som hanterar time-out och keep-alive.

Handle request

• 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.
• Kontrollerar om HTTP headern x-rivta-original-serviceconsumer-hsaid är satt i inkommande anrop.Spara denna om den är sattTa hand om inkommande HTTP properties.
• Skapa korreleringsid och sätt på inkommande meddelande
• Plocka ut RIV-version, receiverId, wsdl namnrymd och tjänstekontrakt och spara undanoch 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 den konfigurerade 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.

...

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.
• 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 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 sätts 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)

...

• Stänger explicit en connection om keep-alive ej skall användas. Gäller endast HTTPS trafik!
• Byter ut URL:er i WSDL:er och XSD:er som returneras från Hanterar att ett GET anrop (?wsdl) som i ett svar pekar på interna adresser (som en Tjänstekonsument ej kommer åt till att vara anropad host istället) byts ut.
• Plockar bort properties ur sessionen som annars blir HTTP Headers i svaret till Tjänstekonsumenten.

...

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

...

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

...