VP 2.2.5 (RC1)
...
- SKLTP-430: VP: Utred om VP har prestandaproblem i sin felhantering
- Ändrad felstrategi för att förbättra prestandan i VP vid fel.
Förändrad konfiguration
Mjukvaran finns att ladda ner från http://central.maven.org/maven2/se/skltp/vp/vp-services/2.2.5-RC1/vp-services-2.2.5-RC1.zip
...
- SKLTP-380: Konfigurerbara könamn för INFO- och ERROR-loggar.
- Hårdkodat i koden sattes tidigare SOITOOLKIT.LOG.STORE, så för att stödja bakåtkompabilitet sätts
SOITOOLKIT_LOG_INFO_QUEUE=SOITOOLKIT.LOG.STORE i vp-config.properties.
- SKLTP-10 - Hantera ursprungsanvändare i flera led enligt RIV TA
- införande av http header x-vp-sender-id för att identifiera konsumenten i de fall http kommunikation används.
- införande av http header x-vp-instanceid-id för att i kombination med x-vp-sender-id avgöra om http anropen kommer från en känd VP instans.
- införande av ny property, VP_INSTANCE_ID för att konfigurera information om VP instanses id
- SKLTP-421: VP: Möjlighet att konfigurera subnät whitelist
- Nu går det att uttrycka subnät i vp-config-override.properties IP_WHITE_LIST, tex IP_WHITE_LIST=127.0.0 för alla adresser under det nätet.
Förändrad konfiguration
| Property | Defaultvärde | Kommentar |
|---|---|---|
| ny property: VP_INSTANCE_ID | THIS_VP_INSTANCE_ID | Ett id för instanser av VP för att kunna identifiera sig vid kommunikation med en annan instans av VP, tex vid en nationell och regional installation. Förekommer flera instanser av VP inom samma SKLTP kluster så skall dessa dela samma id. Specifikt används detta id i kombination med http header x-vp-sender-id. |
| uppdaterad: IP_WHITE_LIST | 127.0.0.1 | I whitelist kan man nu ange subdomän i listan av adresser, tex 192.168.0 för alla adresser därunder. |
...
- SKLTP-402: VP: Vissa tjänster som tillhandahålls via VP skall exponeras med både http/https
- Ping tjänst nås nu via https://localhost:20000/vp/Ping/1/rivtabp20 och http://localhost:8080/vp/Ping/1/rivtabp20
Nya funktioner
Förändrad konfiguration
Nya parametrar med dess defaultvärde
...
- SKLTP-339 - Möjlighet att konfigurera response timeout per tjänstekontrakt (virtuell tjänst). Se konfiguration av VP för detaljer om hur detta konfigureras default och per tjänstekontrakt.
Förändrad konfiguration
- Ta bort parameter: VP_MULE_HTTP_CONSUMER_CONNECTOR_SERVICE_TIMEOUT_MS, definition av response timeout nu sker i SERVICE_TIMEOUT_MS.
Ta bort parameter: GETLOGICALADDRESSESBYSERVICECONTRACT_RIVTABP21_PORT
- Lägg till parameter: CLIENT_SO_TIMEOUT_MS=<default satt till 30000ms >
Lägg till parameter: VP_MULE_HTTP_CONSUMER_CONNECTOR_CLIENT_SO_TIMEOUT_MS=<default satt till 30000ms>
Lägg till parameter: GETLOGICALADDRESSESBYSERVICECONTRACT_V1_INBOUND_ENDPOINT=https://${TP_HOST}:23001/${TP_BASE_URI}/GetLogicalAddresseesByServiceContract/1/rivtabp21?connector=VPProducerConnector
- Lägg till parameter:GETLOGICALADDRESSESBYSERVICECONTRACT_V2_INBOUND_ENDPOINT=http://${TP_HOST}:${TP_PORT_HTTP}/${TP_BASE_URI}/services/GetLogicalAddresseesByServiceContract/2/rivtabp21
Lägg till parameter: GETSUPPORTEDSERVICECONTRACTS_V2_OUTBOUND_URI=tp-vagval-admin-services/GetSupportedServiceContracts/v2
...
Tidigare var VP beroende av att TK var uppe och körde vid omstart, och i nuvarande driftsmiljö innebar detta beroende till TK ett sk single point of failure. I och med 2.0 så sparas alltid den senaste hämtningen från TK på en lokal backup $HOME/.tk.localCache och skulle TK inte svara så används denna lokala backup istället. I loggen skrivs det en INFO rad varje gång en lokal kopia sparas eller används, och även ERROR rader om dettas skulle misslyckas. Exempel på en INFO rad i loggen:
INFO ... se.skl.tp.vp.vagvalagent.VagvalAgent: Save to local copy: /home/mule/.tk.localCache
Stöd (Mule) för en komponentbaserad paketering
...