Här beskrivs hur interaktionen mellan de olika systemdelarna ser ut för olika användningsfall.
Skapa och förhandsgranska beslut
Först hämtas aktuell meddelandemall från Template, baserat på val av lagrum i droplistan. För Parkeringstillstånd finns endast ett lagrum och därmed endast en mall. 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.
Därefter kan handläggaren editera (delar av?) meddelandet genom att lägga till ytterligare text. Det vore bra om vissa givna fält i mallen kan fyllas i direkt med uppgifter från ärendet.
Innehållet för beslutet bör sparas ner på ärendet, dvs till CaseData.
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 Template.
Denna rendering bör sparas ner som en bilaga (på Decision-objektet?) på ärendet.
Om förhandsgranskningen är okej kan 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?
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.
Skicka meddelande
Först hämtas aktuell meddelandemall från Template, baserat på val av mall i droplistan.
Därefter kan handläggaren editera (delar av?) meddelandet genom att lägga till ytterligare text. Det vore bra om vissa givna fält i mallen kan fyllas i direkt med uppgifter från ärendet.
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. 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.