Page Comparison

WIP (väldigt) på förslag för ny resurs i caseStatus samt caseManagement för att returnera statusar på ärenden på ett (subset) nationellt format. Den nationella specen är på svenska, därav är även API:et på svenska.
För PoC:en antar vi att status endast kommer att frågas på ärenden i Ecos2 och att det är externalCaseId som används.

Request / Response

Fördel: Enklare för klienter
Nackdel: Vi måste leta reda på alla ärenden, hantering av personuppgifter ( ? )

Antaganden / Förslag för PoC:

• OpenE "kopplas bort" och för poc:en skapas ett enkelt GUI (fejka Tillväxtverket) för att skicka anrop direkt mot caseStatus.

• För att ytterligare förenkla används externalCaseId istället för personnummer (bara i poc).

  • TODO: Vet ej hur detta skall lösas framgent, men någon metod/nyutveckling för att hämta tillväxtverkets id:n kopplat mot pnr / org.nr?

• Då caseStatus är en "dum" tjänst, dvs slussar vidare json från caseManagement bör caseManagement stå för översättning av statusar från Ecos2 -> "nationell standard".

• CaseManagement gör en kopia av ett anrop mot Ecos2 men med en egen mappning av svar till nationell standard, dvs gå förbi existerande mappnings-logik.

“Lösningsförslag”

• Nya resurser i både caseStatus samt caseManagement skapas, t.ex: GET /cases/tvCaseMapping?anropandeSystem=system&externalCaseId=externalCaseId-1.

  • caseStatus gör ett anrop mot caseManagement, som idag fast ny endpoint för att särskilja.

• CaseManagement anropar GetCase i Ecos2 för att hämta statusar på ärenden.

• Svare från Ecos2 mappas serdan till nationell standard:

  • kundhandelser ()

    • varje OccurrenceListItemSvcDto mappas till ett objekt i kundhandelser

    • OccurrenceTypeId-> handelsebeskrivning

    • OccurrenceDate -> registreradTidpunkt

    • ? -> handelserubrik. Här bör vi kunna nyttja en enum som innehåller förklarande text tillhörande varje kundhandelsekategori i "kundhandelsekategori".

    • OccurrenceTypeId -> kundhandelsekategori

  • metadata

    • Utelämnar huvudman samt externAnvandare (för poc).

    • hamtatDatum == LocalDateTime.now();

Förslag på API efter POC:

Request

{
	"anropandeSystem": "något system",
	"huvudman": "165565491461",
	"externAnvandare": "197001011234"
}

Fördel: Enklare för klienter
Nackdel: Vi måste leta reda på alla ärenden, hantering av personuppgifter ( ? )

Alternativt förslag på request (utökning med key-value-lista, där mottagaren (vi) har specificerat vilka nycklar och värden som är aktuella.) för att möjliggöra att skicka in data som inte annars passar in i API:et:
Kan bli stökigt att köra GET vid många ärenden, eller undvika anropande system att göra ett anrop per ärende. I sådana fall kan en POST användas och är “lagligt” enligt spec, typ… I detta fall aggregerar tjänsten caseStatus / oepStatus alla ärenden till _ett_ response.

Fördel: Sändande system håller reda på ärenden, slipper hantering av personuppgifter
Nackdel: Stökigare för klienter, utökning av spec, kan bli många varianter av key-value-par.

{
	"anropandeSystem": "något system",
	"flexibeltFaltMedBraNamn": [
		{
			"externalCaseId": "externalCaseId-1"	
		},
		{
			"externalCaseId": "externalCaseId-2"
		}
	]
}

Fördel: Sändande system håller reda på ärenden, slipper hantering av personuppgifter
Nackdel: Utökning Ärendenummer hålls av klient, utökning av spec, ett anrop per ärendestatustappar kontrollen på api:et, hålla dokumentation / giltiga värden aktuella blir utmanande.

{
	"anropandeSystem": "något system",
	"arendenummer": "externalCaseId-1"
}

Förslag på responseFördel: Sändande system håller reda på ärenden, slipper hantering av personuppgifter, behåller kontroll över vad som kan skickas in.
Nackdel: Utökning av spec, ett anrop per ärendestatus

Response:

{
	"metadata": 
	{
		"huvudman": "165565491460",
		"externAnvandare": "197001011234",
		"hamtatDatum": "2021-09-29T13:05:00+01:00"
	},
    "kundhandelser": [
        {
        	"kundhandelseId": "externalCaseId-1",
            "handelserubrik": "Text som kortfattat beskriver händelsen.",
            "handelsebeskrivning": "En ännu längre text som beskriver ärendet med fler detaljer.",
            "kundhandelsekategori": "Åtgärd krävsMottagningskvittens",
            "registreradTidpunkt": "2021-09-25T12:05:20+01:00"
        },
        {
        	"kundhandelseId": "externalCaseId-2",
            "handelserubrik": "Text som kortfattat beskriver händelsen.",
            "handelsebeskrivning": "En ännu längre text som beskriver ärendet med fler detaljer.",
            "kundhandelsekategori": "FöreläggandeBeslut",
            "registreradTidpunkt": "2021-09-24T11:01:10+01:00"
        }
    ]
}

Förklaring av parametrar

request

...

Förklaring till möjliga värden i parametern kundhandelsekategori för att kunna mappa, se nästa punkt.

ToDo

Förtydligande “kundhandelsekategori”

Efter mail-konversation med Martin Karlsson på Tillväxtverket är det i dagsläget dessa 4 kundhändelsekategorier som gäller:

• Mottagningskvittens (Bollen är hos oss …)

• Beslut (Bollen är i mål …)

• Fråga (Bollen är hos dig …)

• Upplysning (Ungefär som “Fråga”, du kan göra något men behöver inte, annars tar vi det vi har. En “vänlig upplysning” om vad kunden kan tänkas ta sig för. )

ToDo efter poc

• Mappning av värden:

  • från Ecos2 till kundhandelsekategori, handelserubrik, handelsebeskrivning

• Vad skall användas i parametern kundhandelseId, är externalCaseId vettigt?

• Hur får vi tag i ärenden från Ecos2 m.h.a. personnummer / orgnummer?