Page Comparison

Här beskrivs hur interaktionen mellan de olika systemdelarna ser ut för olika användningsfall.

Skapa och

...

skicka beslut

• Först hämtas aktuell meddelandemall från Template Templating, baserat på val av lagrum i droplistan. För Parkeringstillstånd finns endast ett lagrum och därmed endast en malluppsättning mallar associerade med det lagrummet. Vilken mall som ska användas avgörs också av aktuellt beslut (bifall eller avslag) samt om ansökan gäller förare eller passagerare. Så, just nu alltså 1 lagrum och 4 mallar. Detta ger vilka parametrar som ska fyllas i för aktuellt beslut.

• Eventuellt hämtas också den samling fraser som handläggaren ska kunna editera (i form av beslutstext). Ej inritat i sekvensdiagrammet, men ser ut på samma sätt som steget innan här.

• Därefter kan handläggaren editera (delar av?) meddelandet genom att lägga till ytterligare text. Det vore bra fylla i (eller ta bort) information för beslutstexten i handläggargränssnittet för att på så sätt bygga ihop den datamängd (i form av en JSON) som ska kunna skickas vidare i nästa skede. Det är också önskvärt om vissa givna fält i mallen datamängden kan fyllas i direkt med uppgifter från ärendet - namnuppgifter etc, vilket minimerar handpåläggningen för handläggaren.

• Innehållet för beslutet bör sparas ner på ärendet, dvs till CaseData. Det som sparas ner är en JSON innehållande metadata och parametervärden för aktuell mall, som kan renderas till det färdiga meddelandet i ett senare skede.

• För att se hur det faktiska beslutet kommer att se ut när det skickas ut till sökanden finns möjlighet att begära en rendering av beslutsdokumentet från TemplateTemplating. Det är då metadatat och parametrarna som skickas in och tillbaka kommer ett dokument i form av exempelvis PDF.

• Denna rendering bör sparas ner som en bilaga (på Decision-objektet?) på ärendet (i CaseData).

• Om förhandsgranskningen är okej kan det renderade beslutet skickas ut via Messaging. Som svar erhålls meddelande-id, som måste sparas ner på ärendet, via CaseData, tillsammans med tidsstämpel (implicit?). Även detta på Decision-objektet? Vilken kanal (dvs funktion) som ska användas vid anropet mot Messaging avgörs av ärendets ursprung: För ärenden som inkommit via papper är det Kivra (eller i förlängningen) vanlig post och för ärenden som inkommit via e-tjänsteplattformen är det “webMessage”.

• När ett meddelande-id erhålls från Messaging innebär det egentligen enbart att tjänsten tagit emot förfrågan om att skicka ett meddelande, inte om det faktiskt har skickats vidare. Om den statusen behöver kontrolleras finns en funktion i Messaging även för det (märkt som “Get Message Status” i sekvensdiagrammet). Dock kan vi inte se om meddelandet faktiskt också kommit fram.

Utestående frågor

• Är det en annan uppsättning mallar som ska gälla för webMessage, dvs om ärendet har sitt ursprung i e-tjänsten för parkeringstillstånd?

• Vi har tidigare pratat om en “fras-mall” som skulle kunna hämtas från Templating-tjänsten för att kunna fylla i grundtexten för beslutet - egentligen det enda som handläggaren ska kunna ändra i. Vi behöver en sammanställning av dessa fraser.

• Hur ska ett utskickat beslut sparas på ärendet? Förslagsvis som en attachment på Decision-objektet eller är et bättre att ha det som en attachment bland andra på ärendet, men av en specifik typ?

Skicka meddelande

• Först hämtas aktuell meddelandemall från Template Templating, baserat på val av mall i droplistan.

• Därefter kan handläggaren editera ( delar av ?) meddelandet genom att lägga till ytterligare text . (i textfältet “Ditt meddelande”) Det vore bra om vissa givna fält i mallen kan fyllas i direkt med uppgifter från ärendet, om det finns några sådana i respektive mall.

• Slutresultatet blir en JSON, som skickas in till Templating för rendering. Det färdiga (renderade) meddelandet är det som skickas vidare till Messaging.

• Om så önskas, kan bilagor hämtas från ärendet för att användas i meddelandet. För att populera droplista över möjliga bilagor att lägga till behöver en lista på attachments och attachment type hämtas från CaseData. Handläggaren kan välja att lägga till en eller flera av dessa bilagor, som då laddas ner (en i taget) från CaseData.

• Det finns också ett val att ladda upp en eller flera bilagor från datorn. I det fallet finns möjlighet för bilagan att adderas även till ärendet (viktigt med typen här!).

• Meddelandet skickas genom att sända request till Messaging. Kanal här bör vara email, eller kan andra kanaler vara aktuella? Som svar erhålls meddelande-id, som måste sparas ner på ärendet, via CaseData, tillsammans med tidsstämpel (implicit?) och eventuell referens till bilagor.

• När ett meddelande-id erhålls från Messaging innebär det egentligen enbart att tjänsten tagit emot förfrågan om att skicka ett meddelande, inte om det faktiskt har skickats vidare. Om den statusen behöver kontrolleras finns en funktion i Messaging även för det (märkt som “Get Message Status” i sekvensdiagrammet). Dock kan vi inte se om meddelandet faktiskt också kommit fram.

Utestående frågor

• Var någonstans hålls listan över möjliga mallar för meddelanden att använda för just Parkeringstillstånd?

• Är en mall tvingande eller kan meddelandet komponeras utan mall?

• Hur hanteras eventuell förhandsvisning av det faktiska meddelandet som ska skickas?

• Ska det faktiska meddelandet sparas som attachment på ärendet även fast det finns att tillgå från Messaging?

• Är det givet att det enbart är e-post som ska användas i meddelandefunktionen här?

Lista meddelanden

• Tidigare skickade meddelanden kan listas genom att skicka förfrågan till CaseData för alla meddelanden som hör till aktuellt ärende. Som svar erhålls en lista med meddelande-id, inklusive tidpunkter för när meddelandet skickades.

• Denna lista itereras och det faktiska meddelandet hämtas från Messaging. Eventuella attachments kommer också med i svaret från Messaging.

Meddelandematris

När det kommer till att skicka meddelanden avgörs vilken typ av meddelande som ska skickas av följande matris: