| Innehållsförteckning |
|---|
=== Input från Marval-ärende 48499 ===
När det finns flera versioner av kontrakt med aggregering uppstår ett “randfall” som det är viktigt att logiken i aggregerande tjänster kan hantera.
Beskrivning av “randfall”:
- Det finns två (eller fler) huvudversioner av ett kontrakt i bruk
- Kontraktet har aggregering i tjänsteplattformen
- Det finns tjänsteproducenter som stödjer båda versionerna av kontraktet eftersom det finns tjänstekonsumenter som förlitar sig på gamla versionen samtidigt som det finns tjänstekonsumenter som förlitar sig på den nya versionen (eller på båda för att få med alla producenter oavsett version)
- Posterna i Engagemangsindex anger inte version (detta vill vi inte ändra på) av kontrakt
Krav vid randfall enligt ovan:
- En tjänstekonsument som anropar en aggregerande tjänst ska INTE få fel-rapporter (i aggregeringsheadern) från de källsystem som bara har stöd för den andra versionen.
- En tjänstekonsument som anropar en aggregerande tjänst ska INTE orsaka att anrop förmedlas vidare till tjänsteproducenter som bara stödjer den andra versionen.
Tankar kring lösning:
Att Aggregerande tjänster - efter svar från EI - via TAK-info matchar källsystemet OCH kontraktsversion innan anrop sker, så att EI-poster som logiskt pekar ut producent som - enligt TAK - saknar stöd för den version som aggregerande tjänsten är.
Beskrivning
Denna feature används i de fall Aggregeringsplatformen behöver supportera olika major versioner av samma tjänstekontrakt.
Detta görs genom en integration med TAK som håller vilken version av tjänstkontraktet en vis logisk-address exponerar.
Informationen om vilken version av tjänstkontraktet som är aktuellt finns i befintlig konfiguration av aktuell aggregerande-tjänst.
...