Dagens brevløsning består av to systemer: Metaforce/doksys stack og HP Extreme brev. HP Extreme bruker hovedsakelig ESB(Enterprise Service Bus) som har en rekke problemer:
-
Vanskelig å foreta endringer på grunn av systemets kompleksitet og manglende kompetanse
-
Gammelt (manglende kompetanse, manglende vedlikehold av software, dyre lisenser for legacy systemer)
-
Lite fleksibelt/lite endringspotensiale
-
Avhengig av buss og stormaskin
-
For å komme oss vekk fra HP Extreme var det besluttet å ta i bruk MetaForce for å produsere brev.
-
Arbeidet med å overføre brev fra HP Extreme til MetaForce har pågått siden 2017.
-
Det å overføre brevmaler fra ett system til ett annet er en tung og langvarig prosess, og brevmalene i seg selv er av høy verdi.
MetaForce ønsker vi også å gå bort ifra fordi:
-
Team CCM har besluttet at de ikke lengre vil opprettholde MetaForce i Nav
-
Det er ett proprietært verktøy:
-
Kan ikke tilpasses våres behov
-
Vi er ingen garanti at MetaForce ikke stopper å få oppdateringer
-
Brevmaler låses inn i deres løsning og kan ikke automatisk overføres til nye løsninger
-
-
Det forvaltes ikke av Team Pensjonsbrev, så vi er avhengig av utviklere utenfor teamet hver gang vi skal gjøre endringer i brev.
Se også: Oversikt - Faglige problemstillinger (krever innlogging)
Det ble vurdert å ta i bruk hyllevare(OpenText Exstream), men da antar vi at vi vil støte på tidligere problemstillinger med MetaForce. OpenText Exstream er hyllevare som vi ikke kan tilpasse selv, og vi låser brev-malene inn i ett eksternt CCM verktøy slik som før. Dersom OpenText Exstream ikke vedlikeholdes er vi tilbake til samme tilstand som i dag.
Vi valgte å utvikle en egen fullstendig løsning og ikke hyllevare fordi:
Implementasjonen av brev-malene er av høy verdi. Ved å ta i bruk en egen løsning kan vi skrive malene og lagre de i en løsning vi kan vedlikeholde over lang tid. Vi ønsker at løsningen skal vare så lenge som mulig. Ved å lage en egen løsning vil vi kunne forvalte den så lenge Nav har utviklerkapasitet.
Selv om vi skriver våres egen løsning må vi ha avhengigheter til eksterne verktøy for å produsere PDF dokumenter.
For å ikke knytte oss hardt mot hvordan dokumentet vises, har vi bestemt oss for å skille produksjonen av det tekstlige innholdet i brevet fra verktøyet som produserer den endlige visningen.
Det betyr at alt innholdet i brevet bestemmes av vår egen applikasjon(brevbakeren), også overlates PDF produksjonen til et annet verktøy(LaTeX container i våres tilfelle).
Om vi ønsker å gå bort fra LaTeX i fremtiden slipper vi å skrive alle brevmalene på nytt, og vi trenger kun å lage en ny integrasjon mot ett annet verktøy. Om vi f.eks ønsker å produsere html brev eller noe annet kan vi bare lage ett nytt visnings-lag uten å endre på koden som produserer innholdet i brevet.
Batch --> [Pesys] [Pesys] --> [Brevbaker] [Pesys] --> [Distribusjon] [Pesys] --> [Arkiv] [Brevbaker] --> [Pdfbygger]
Det er tiltenkt at redigering og bestilling av manuelle brev skal gjøres gjennom en dedikert applikasjon. PSAK skal lenke til denne applikasjonen. Det skal minimeres i størst mulig grad hvilke data vi lagrer i databasen til denne nye løsningen, blant annet vil all person og saksdata overlates til Pesys og andre systemer. Kun data om hvordan et brev evt. er endret på skal lagres, samt innstillinger for den enkelte saksbehandler.
package Brevmaler {
[Brevbaker]
[Pdfbygger]
}
package Brevredigering {
[Brevredigering-frontend]
[Brevredigering-backend]
database "Brevredigering-db" as mellomlagretRedigering
}
saksbehandler --> [Brevredigering-frontend]
[Brevredigering-frontend] --> [Brevredigering-backend]
[Brevredigering-backend] --> mellomlagretRedigering
[Brevredigering-backend] --> [Mottakeroppslag e.l.]
[Brevredigering-backend] --> [Brevbaker]
[Brevredigering-backend] --> [Pesys]
[Pesys] --> [Brevbaker]
[Pesys] --> [Distribusjon]
[Pesys] --> [Arkiv]
[Brevbaker] --> [Pdfbygger]
note as pesysansvar
Pensjonsbrev er ansvarlig for deler av pesys
end note
[Pesys]..pesysansvar