API-530

WIP (väldigt) på förslag för ny resurs i caseStatus 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.

Request / Response

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

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

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: Ärendenummer hålls av klient, utökning av spec, tappar kontrollen på api:et, hålla dokumentation / giltiga värden aktuella blir utmanande.

{
	"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, behåller kontroll över vad som kan skickas in.
Nackdel: Utökning av spec, ett anrop per ärendestatus

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

Förslag på 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ävs",
            "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äggande",
            "registreradTidpunkt": "2021-09-24T11:01:10+01:00"
        }
    ]
}

Förklaring av parametrar

request

response → metadata

response → kundhandelser

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

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

• Mappning av värden:

  • från Ecos2 till kundhandelsekategori, handelserubrik, handelsebeskrivning

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