API-530

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.

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.

{
	"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: Ä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",
	"arendenummer": "externalCaseId-1"
}

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

Response:

Förklaring av parametrar

request

parameter	typ	förklaring	Extra-info / kommentar

parameter	typ	förklaring
anropandeSystem	String
externAnvandare	String	Den externa användare som utför förfrågan, kan vara personnummer eller organisationsnummer.
huvudman	String	Person eller organisation som det skall hämtas uppgifter om.

response → metadata

parameter	typ	förklaring	Extra-info / kommentar

parameter	typ	förklaring	Extra-info / kommentar
huvudman	String	Person eller organisation som det skall hämtas uppgifter om.
externAnvandare	String	Den externa användare som utför förfrågan, kan vara personnummer eller organisationsnummer.
hamtatDatum	DateTime	Datum när kundhändelserna hämtades, kanske inte oerhört nödvändig men är med i specen.	ISO8601: “YYYY-MM-DDThh:mm:ssTZD” / “2021-09-29T13:05:00+01:00”

response → kundhandelser

parameter	typ	förklaring	Extra-info / kommentar

parameter	typ	förklaring	Extra-info / kommentar
handelserubrik	String	Kortfattad beskrivning för ärendet
handelsebeskrivning	String	Ännu längre beskrivande text för ärendet	Behövs denna?
kundhandelseId	String	`externalCaseId` för ärendet.	Skall enligt spec vara unikt överallt, är `externalCaseId` ?
kundhandelsekategori	String	Typ av händelse för ärendet	Möjliga värden: Mottagningskvittens, Beslut, Fråga, Upplysning
registreradTidpunkt	DateTime	Startdatum för ärendet	Tas från `OccurrenceListItemSvcDto`

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?