Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Gliffy
imageAttachmentIdatt458194945
macroId11047a70-882b-472c-bd5b-b48c67e75519
baseUrlhttps://sundsvall.atlassian.net/wiki
displayNamekontrollfunktionen
namebigBlösning
diagramAttachmentIdatt457932803
containerId458129409
pageid458129409
timestamp1621587643632
Gliffy
macroId
11047a70-882b-472c-bd5b-b48c67e75519
baseUrlhttps://sundsvall.atlassian.net/wiki
namebigBlösning
containerId458129409pageid458129409
timestamp16213419651721622807194761

Jag har kollat lite med våra RPA utvecklare och tyvärr är det så att det inte går att fråga på ett specifikt ärende med personnummer som nyckel utan mönstret är tyvärr så att man måste be om en lista på alla ärenden för en viss e-tjänst, sedan får man nästla sig genom alla dessa för att få loss personnummer. Kanske kan man tydligare visualisera det i bilden? Sen är det så att innan vi började med RPA så hade e-tjänsterna oftast inte XML taggats vilket gör att strukturerat data i e-tjänsten inte fanns för API anrop. Det är därför jag sagt att man behöver ha brytdatum för tidigaste ärende som är relevant (XML taggning kan inte ske retroaktivt på ärenden). Nu kan man trevligt nog ange datum som sökvillkor iaf.

Eftersom man måste hämta alla ärenden från OeP så måste det väl vara bättre om vi får en komplett lista med adressändringar från Meta en gång/vecka, eller vad säger ni Marcus Olsson (Unlicensed), ola.enebro (Unlicensed)?

Exempel på anrop samt dokumentation (OeP)

Hämta lista på meddelanden för e-tjänst (id avser e-tjänstens versions ID):

...

View file
nameOpen ePlatform - Integration callback.pdf

URL namnen som är aktuella för resp server i Sundsvall finns här:

Produktion

InternaExterna OePhttps://e-arendentjanster.sundsvall.se 

Test

Externa OePhttps://sundsvalltest.e-tjanster.sundsvalltjansteportalen.se/login2  

Test

Interna: https://e-arendentest.sundsvall.se/

...

Familyid som är aktuella

Test

Skolskjuts: 344 (namn i e-tjänsten : ’Busskortsansökan för gymnasieelever- TEST RPA’)

Elevresor: 349 (namn i e-tjänsten  ’Busskortsansökan för gymnasieelever – Test RPA’)

 Prod

Skolskjuts: 136 (namn i e-tjänsten ’Ansökan om skolskjuts’)

Elevresor: 261 (namn i e-tjänsten’Busskortsansökan för gymnasieelever’)

Variant/kontroll 1: Konceptuellt flöde i mikrotjänst för att söka ut info i OeP (av Mikael 2021-07-09) för Skolskjuts (här är det om föräldern flyttat som är relevant samt om man bytt skola eller ändrat omfattning på förskola, den sistnämnda är dock out of scope just nu då vi inte har den informationen):

  1. Hämta alla ärenden (ärendenummer) med status beslutad för Skolskjuts.

  2. För varje ärendenummer läs in informationen i resp ärende

  3. Identifiera involverade vårdnadshavare i resp ärende och deras personnummer, mappa personnummer för den (endast en) vårdnadshavare som ansökt/skickat in för att möjliggöra kontroll (detta behöver göras baserat på namn som är det enda vi har på den som skickat in, men det ska normalt bara kunna vara VH om det inte lagts upp manuellt). Utifrån identifierat namn fås dennes personnummer.

  4. Kontrollera mot svar från Metakatalogen om vederbörande (den VH som skickat in ansökan) flyttat baserat på personnummer.

  5. När samtliga kontroller gjorts (loopats) kan rapport framställas i e-mail. Förslag till format finns här: https://sundsvall.atlassian.net/wiki/spaces/SK/pages/340590595/Design+approach+20-31+Kontrollfunktion+BoU+Skolskjuts+samt+Elevresor#Detaljering-av-logik-som-beh%C3%B6ver-h%C3%A5llas

Variant/kontroll 2: Konceptuellt flöde i mikrotjänst för att söka ut info i OeP (av Mikael 2021-07-09) för Elevresor (här är det om eleven flyttat som är relevant :

  1. Hämta alla ärenden (ärendenummer med status för Elevresor.

  2. För varje ärendenummer läs in informationen i resp ärende.

  3. Identifiera elev och dennes personnummer. Ansökan kan ske av både VH och elev men oavsett vem som skickat in så är det bara elevens adress som är relevant.

  4. Kontrollera mot svar från Metakatalogen om vederbörande (eleven) har flyttat baserat på personnummer.

  5. När samtliga kontroller gjorts (loopats) kan rapport framställas i e-mail. Förslag till format finns här: https://sundsvall.atlassian.net/wiki/spaces/SK/pages/340590595/Design+approach+20-31+Kontrollfunktion+BoU+Skolskjuts+samt+Elevresor#Detaljering-av-logik-som-beh%C3%B6ver-h%C3%A5llas

Variant/kontroll 3: Konceptuellt flöde i mikrotjänst för att söka ut info i OeP för Skolskjuts där eleven flyttat.

Denna är samma som variant/kontroll 1 men istället för föräldern är det eleven som är intressant. Bakgrunden till detta är att om eleven flyttar så kan det bli aktuellt med annan skola och då vill vi fånga detta. Här kan det alltså tänkas att eleven flyttar utan att för den skulle någon av vårdnadshavarna flyttar, men sannolikt är det nog så att även VH flyttar.

  1. Hämta alla ärenden (ärendenummer med status för Elevresor.

  2. För varje ärendenummer läs in informationen i resp ärende.

  3. Identifiera elev och dennes personnummer.

  4. Kontrollera mot svar från Metakatalogen om vederbörande (eleven) har flyttat baserat på personnummer.

  5. När samtliga kontroller gjorts (loopats) kan rapport framställas i e-mail. Förslag till format finns här: https://sundsvall.atlassian.net/wiki/spaces/SK/pages/340590595/Design+approach+20-31+Kontrollfunktion+BoU+Skolskjuts+samt+Elevresor#Detaljering-av-logik-som-beh%C3%B6ver-h%C3%A5llas