1. Introduktion #
Modular opbygning af kode, er en måde man kan mindske vedligehold af sine RPA-processer. Tanken er at bygge en stor proces, som har moduler som kan genbruges over flere mindre processer. Afsnit 2 er dokumentation på netop sådan en proces, som er bygget i Power Automate Desktop, hvor man journaliserer digitale blanketter til et ESDH-system. Da koden er stort set det samme om man journalisere en blanket eller flere, så er det en ideel proces at lave modular.
| Navn | Note | Link |
| Kodning – Strukturering | Teorien fra afsnit 3 her bruges også i denne gennemgang. | https://www.rpahelp.org/docs/kodestruktur/#6-toc-title |
| KMD SAP | Afsnit 3 heri er et andet eksempel på en modul opbygget proces | https://www.rpahelp.org/docs/kmd-sap/#6-toc-title |
1.1 Hvad er et modul? #
Et modul er generisk kode som er genanvendeligt i flere sammenhænge. Hvis vi kigger koden til 30.30 – Journaliser filer nedenfor, ser det således ud. Kort fortalt med et API-kald forsøges en liste med filer at journaliseres. Såfremt det ikke lykkedes, er der indbygget debugging, som selv håndterer fejlen. Yderligere returnerer modulet en DocumentIdentifier, et unikt ID i ESDH-systemet til det specifikke dokument, samt en JSON hvor der kan være flere variabler med som kan bruges efterfølgende.
1.2 Hvordan bruges et modul? #
Forsat med eksemplet kan en arbejdsgang i en modular RPA-proces se således ud. Inden vi kører modulerne, sættes de variabler som ønskes brugt i denne. Efterfølgende kan man bruge det, som modulet sender retur videre i arbejdsgangen. Se sidste Region, hvor der sættes variabler ud fra den JSON som kommer efter Run subflow 30.10.
2. XFlow til eDoc – Journaliser blanketter ALLE #
2.1 Beskrivelse #
Selve koden er udviklet til at arbejde i robot-brugernes indbakke, hvor den gennemgår mails fra XFlow, og journalisere blanketter til eDoc sager. Dette betyder at i takt med at behovet opstår, kan man løbende opsætte nye cases til enten robot-brugere i 10.10 eller blanketter i 20.10.
Liste over blanketter som robotten håndterer:
| Fagområde | Blanket | Kommentar |
| DUV | Fritagelse for tysk | |
| VIS | Diæt og Befordring | Tager sig af alle 6x blanketter (Beboerklagenævnet, Bevillingsnævnet, Børn og Ungeudvalget, Handicaprådet, Hegnssyn, Huslejenævnet) |
2.2 Kodebeskrivelse #
Kort overblik over variablerne som bruges til eDoc API’et, og hvad disse gør:
| Navn | Beskrivelse |
| BoolEdocDokument | Bruges til at aktiver en else-if, så robotten trækker EdocDokumentID ud af JSON |
| BoolEdocProjekt | Bruges til at aktiver en else-if, så robotten trækker EdocProjektID ud af JSON |
| EdocCaseFileIdentifier | En sags unikke ID i backend |
| EdocDokumentDato | Påkrævet når der journaliseret, som udgangspunkt dagsdato dd-mm-yyyy. Kan overskrides ved behov, da den nulstilles imellem hvert loop. |
| EdocDokumentID | Et dokuments unikke ID i backend |
| EdocDokumentNr | Et dokuments nummer ud mod brugergrænsefladen |
| EdocKategori | ID’et på den kategori som skal bruges, for liste se: R:\SCRIPTS\PowerShell\eDoc\GetItemList\edoc\CaseCategory.txt |
| EdocOpretSag | Bruges i en Switch til at afgøre hvad skal oprettes |
| EdocProjektID | Et projekts unikke ID i backend |
| EdocProjektNr | Et projekts nummer ud mod brugergrænsefladen |
| EdocSagsbehandler | Initialerne på en sagsbehandler |
| EdocSagsnummer | En sags nummer ud mod brugergrænsefladen |
| EdocSkabelon | Den skabelon som skal bruges til oprettelse |
| EdocSøgEfter | Bruges i en Switch til at afgøre hvad der skal søges efter |
| EdocTitel | En titel i eDoc enten til søgning eller oprettelse |
| EdocType | eDoc sagstypen: Slettet sag Administrativsag Borgersag Ejendomssag PPR – Sag |
| JSONEdocJournaliser JSONEdocOpret JSONEdocSøg | De respektive JSON filer som indlæses efter hvert API kald. Som udgangspunkt levere de kun en EdocCaseFileIdentifier, EdocProjektID eller EdocDokumentID tilbage. Resten skal man selv lave i sin kode hvis der er behov for at trække yderligere ud. |
Koden er delt op i følgende subflows, hvori der er kommentarer med #TODO i koden, hvis man aktivt skal foretage ændringer:
Main: Dette er hovedfunktionen, der orkestrerer hele processen. Herfra kaldes andre funktioner i rækkefølge, for at håndtere forskellige dele af arbejdsgangen.
00.10 Initialize: Forbereder miljøet ved at opsætte nødvendige variabler, mapper og logdetaljer. Heri findes variabler til debugging og logning til SQL, som skal overskrides til nyt brug.
99,99 Exit: Håndterer oprydningen og logningen i slutningen af processen, herunder afsendelse af fejlrapporter, hvis det er nødvendigt.
Global Error Handler: Giver en mekanisme til at fange og logge fejl, der opstår under udførelsen af automatiseringen, som ville stoppe processen helt fra at afvikle. Dette sikrer, at eventuelle problemer registreres, og en fejlmeddelelse sendes til udvikler.
00.20 – MonthNumber to MonthName: Laver kørselsdatoens måned om til månedens navn i “MonthName” variabel. Tiltænkt hvis man har behov for at navngive sager / dokumenter med indeværende måned.
10.10 – Loop credentials: Ud fra forudindstillede cases, køres hver enkelt robot bruger igennem, og tjekker efter mail i dennes postkasse. Hvis relevant køres 20.10 efterfølgende.
20.10 – Loop emails: Har en Switch indbygget, hvor der skal være en Case per XFlow blanket.
20.20 – Find vedhæftninger: Finder PDF og JSON filen fra vedhæftninger på mailen.
20.30 – Afslut behandling: Tæller +1 på SQL, flytter mailen til behandlet mappen i postkassen, og nulstiller alle relevante variabler så de ikke forstyrrer næste loop.
30.10 – eDoc søg: Bruges til at kunne søge efter sag, dokument eller projekt. Returnere enten en EdocCaseFileIdentifier eller EdocProjektID.
| EdocSøgEfter | Mulige variabler til søgning |
| Sag | EdocCaseFileIdentifier EdocSagsbehandler EdocSagsnummer EdocType VarCPR |
| Projekt | EdocProjektID EdocProjektNr |
| Dokument | EdocCaseFileIdentifier EdocDokumentID EdocDokumentNr EdocSagsbehandler EdocType |
| Default | ErrorList – “30.10 – Sagstype blev ikke genkendt, sprunget over – %EdocOpretSag%” Next Loop |
| Error Handling | ErrorList – “30.10 – ScriptError fandt sted ved søgning – %ScriptError%” CurrentMail flyttes til ErrorMailFolder Next Loop |
| Return | JSONEdocSøg EdocProjektID eller EdocCaseFileIdentifier |
30.20 – eDoc opret: Kan bruges til at oprette nedenstående
| EdocOpretSag | Mulige variabler til oprettelse |
| Borger (Borgerskabelon) | EdocKategori EdocProjektID EdocSagsbehandler EdocSkabelon EdocTitel VarCPR |
| Ejendom (Ejendomsskabelon) | EdocKategori EdocProjektID EdocSagsbehandler EdocSkabelon EdocTitel VarBFE |
| Sagskabelon | EdocKategori EdocProjektID EdocSagsbehandler EdocTitel EdocSkabelon |
| Sag | EdocKategori EdocProjektID EdocSagsbehandler EdocTitel EdocType |
| Projekt | EdocKategori EdocSagsbehandler EdocTitel |
| Default | ErrorList – “30.20 – Sagstype blev ikke genkendt, sprunget over – %EdocOpretSag%” Next Loop |
| Error Handling | ErrorList – “30.20 – ScriptError fandt sted ved oprettelse – “%ScriptError%”” CurrentMail flyttes til ErrorMailFolder Next Loop |
| Return | JSONEdocOpret EdocProjektID eller EdocCaseFileIdentifier |
30.30 – eDoc journaliser filer: Journalisere filerne som er tilknyttet %ListUpload%. Vær opmærksom på at dokument status altid er sat til “Endelige”, har man brug for andet se afsnit om vedligehold, og opret variabel til dette.
| Oversigt | Variabler |
| Journaliser | EdocCaseFileIdentifier EdocType EdocSagsbehandler EdocTitel ListUpload |
| Error Handling | ErrorList – “30.30 – ScriptError fandt sted ved journalisering af %EdocTitel% til %EdocSagsnummer% – “%ScriptError%”” CurrentMail flyttes til ErrorMailFolder Next Loop |
| Return | JSONEdocJournaliser EdocDokumentID |
40.00 – Eksempel: Eksempel på hvordan man kan udfylde et flow til en blanket. Man kan kopiere denne, og bruge som udgangspunkt til en ny journalisering.
2.3 Ny blanket huskeliste #
I 20.10 – Loop, laves en ny case, som skal hedde det samme som mailemnet -PVA. XFLowPDFName variablen udfyldes med filnavnet på PDF-filen med XFlow blanketten -pdf (robotten finder selv ud af (1) (2) og lignende ekstra autonummering). Hvis der er yderligere vedhæftninger som skal journalisere, sætter man BoolMultiAttachments til true. PDF af XFlow blanketten vil altid være hoveddokumentet, JSON springes over da den ikke er relevant, og alle andre vedhæftninger sættes på listen vilkårligt. Hvis det er simpel journalisering, kan man nøjes med at udfylde variablerne til journaliseringen, og efterfølgende køre 30.30 – Edoc journaliser filer. Har man behov for at trække data ud af blanketten, lave et større mængde kode, så opretter man en 40.xx +1 fra sidst oprettede, og udfylder denne med arbejdsgangen. Se eventuelt 40.00 som eksempel. Dette for at undgå at 20.10 bliver uoverskuelig.
Hvis man skal bruge flere variabler end dem som eksistere, eksempelvis til logik, må man gerne lave en forkortelse og sætte foran navnene, så det er nemt at se hvilke variabler hører til hvilken blanket. Eksempelvis hvis blanketten hedder “Ferie – Aftale om afvikling på forskud” man kan forkorte det ned til eksempel FerieAAF<variabelnavn> og sætte det reelle variabel navn bagved. Man kan eventuelt også sætte det i en kommentar øverst i casen.
2.4 Vedligehold #
Det mest almindelige vedligehold vil være behovet for at kunne udfylde en variabel til et API-kald, som ikke i forvejen er skrevet ind. Det er direkte ULOVLIGT at hardcode det ind i feltet, da det vil have indflydelse på alle andre blanketter fremover også. Hvis man som nedenfor eksempel har brug for BOM Sagsnummer, er det lovligt at lave en variabel til dette. Den skal dog hedde Edoc + det som står ud fra teksten, i eksemplet EdocBOMSagsnummer. Herefter må man gerne tjekke 30.10, 30.20 og 30.30 igennem for at se om andre API-kald også har denne og udfylde.
Til sidst –SKAL– den nulstilles i 20.30 – Afslut behandling i regionen til nulstilling. Eller risikere man at den forsat lever videre i næste loop.
