Innehållsförteckning

VP 2.2.2 RC3

...

• SKLTP-339 
  • Parameter VP_MULE_HTTP_CONSUMER_CONNECTOR_SERVICE_TIMEOUT_MS borttagen då all definition av response timeout nu sker i SERVICE_TIMEOUT_MS och med möjligheten att sätta response timeout per tjänst.
  • Separat konfiguration av client_so_timeout och response timeout. Tidigare användes parametern SERVICE_TIMEOUT_MS för att konfigurera båda värdena. För bakåtkompabilitet så har defaultvärden satts till 30 sek som tidigare, men med möjlighet att sätta olika värden på client_so_timeout och response timeout.

    Ny parameter: CLIENT_SO_TIMEOUT_MS=<default 30000>
    Ny parameter: VP_MULE_HTTP_CONSUMER_CONNECTOR_CLIENT_SO_TIMEOUT_MS=<default 30000>
    Läs om parametrarna på konfiguration av VP.

    
    

• SKLTP-332

  • Parameter GETLOGICALADDRESSESBYSERVICECONTRACT_RIVTABP21_PORT borttagen och ersatt med GETLOGICALADDRESSESBYSERVICECONTRACT_V1_INBOUND_ENDPOINT för att kunna styra om

    man vill ha http eller https internt.

  • Ny parameter: GETSUPPORTEDSERVICECONTRACTS_V2_OUTBOUND_URI=<default tp-vagval-admin-services/GetSupportedServiceContracts/v2>
  • Ny parameter: GETLOGICALADDRESSESBYSERVICECONTRACT_V1_INBOUND_ENDPOINT=<default https://${TP_HOST}:23001/${TP_BASE_URI}/GetLogicalAddresseesByServiceContract/1/rivtabp21?connector=VPProducerConnector>
  • Ny parameter: GETLOGICALADDRESSESBYSERVICECONTRACT_V2_INBOUND_ENDPOINT=<default http://${TP_HOST}:${TP_PORT_HTTP}/${TP_BASE_URI}/services/GetLogicalAddresseesByServiceContract/2/rivtabp21>
  • Läs om parametrarna på konfiguration av VP.
    
• SKLTP-336
  • Ny parameter: GETSUPPORTEDSERVICECONTRACTS_V2_OUTBOUND_URI=<default tp-vagval-admin-services/GetSupportedServiceContracts/v2>
  • Läs om parametrarna på konfiguration av VP.
    
    

Nya funktioner

• 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.

...

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

...