I dag aggregeres data for motivasjon og kompetanse inn i dataene for hver rad i ansatt-tabellen (endepunktet employeeTable i Folk-backenden).
Det er to utfordringer med dette:
Dataene som hentes for å vise ansatt-tabellen blir veldig tunge og trege å aggregere og overføre.
Det er en relativt tett kobling mellom data fra kompetansekartleggingen og data fra CV-partner og UBW. Når Folk skal gjøres tilgjengelig for hele Objectnet, bør koblingen ideelt sett være løsere, slik at det er enkelt å utelukke data fra kompetansekartleggingen (som skal ha tilgangsnivå level 4, altså ikke for alle ansatte).
Derfor bør dataene for filtrering på motivasjon og kompetanse separeres ut i et eget endepunkt, slik at de kan fjernes fra employeeTable-endepunktet, og heller hentes separat (og dermed også bare hvis brukeren har tilgang til dem, når det ønskes implementert).
Et par mulige løsninger her er:
1) Hente data fra employeeMotivationAndCompetence-rapporten, og omstrukturere i backenden til en datastruktur ala den som er skissert nedenfor. Dette kan være en litt ineffektiv løsning, der Folk-backenden må gjøre mye jobb.
2) Lage en ny rapport i dataplattform-API-et, der man henter ut dataene i en struktur som krever minimalt med bearbeiding for å matche noe ala datastrukturen som er skissert nedenfor. Her kan det være aktuelt å bruke Presto array/aggregerings-funksjoner, samt casting til JSON, i SQL-spørringen.
Skisse av datastrukturen som kan returneres fra det nye separate endepunktet:
(Scorene er lagt i en liste, og ikke et objekt, i et forsøk på å redusere størrelsen på datastrukturen litt.)
I Folk-frontenden, kan så filter-boksene (for kompetanse og motivasjon) på toppen av ansatt-tabellen selv ha ansvar for å hente inn og holde styr på data fra dette endepunktet.
Dette vil kreve en endring i implementasjonen av filteringen av listen over ansatte som skal vises i ansatt-tabellen:
Dagens løsning er at alle aktive filterverdier (underkategorier, samt grenseverdi for score, valgt av brukeren) ligger i en liste med FilterObject. Før visning av tabellen, kjøres alle ansatte gjennom en søke/filtrerings-funksjon, der de blir sjekket opp mot de aktive filtrene.
Den nye løsningen kan være noe lignende, men der man holder orden på hvilke e-postadresser som matcher de aktive filtrene på ett sted separat fra listen over ansatte, og at man så kjører alle ansatte gjennom filtreringsfunksjon som finner ut hvem som matcher basert på e-postadressen.
I dag aggregeres data for motivasjon og kompetanse inn i dataene for hver rad i ansatt-tabellen (endepunktet
employeeTable
i Folk-backenden).Det er to utfordringer med dette:
Derfor bør dataene for filtrering på motivasjon og kompetanse separeres ut i et eget endepunkt, slik at de kan fjernes fra
employeeTable
-endepunktet, og heller hentes separat (og dermed også bare hvis brukeren har tilgang til dem, når det ønskes implementert).Et par mulige løsninger her er: 1) Hente data fra
employeeMotivationAndCompetence
-rapporten, og omstrukturere i backenden til en datastruktur ala den som er skissert nedenfor. Dette kan være en litt ineffektiv løsning, der Folk-backenden må gjøre mye jobb. 2) Lage en ny rapport i dataplattform-API-et, der man henter ut dataene i en struktur som krever minimalt med bearbeiding for å matche noe ala datastrukturen som er skissert nedenfor. Her kan det være aktuelt å bruke Presto array/aggregerings-funksjoner, samt casting til JSON, i SQL-spørringen.Skisse av datastrukturen som kan returneres fra det nye separate endepunktet: (Scorene er lagt i en liste, og ikke et objekt, i et forsøk på å redusere størrelsen på datastrukturen litt.)
I Folk-frontenden, kan så filter-boksene (for kompetanse og motivasjon) på toppen av ansatt-tabellen selv ha ansvar for å hente inn og holde styr på data fra dette endepunktet.
Dette vil kreve en endring i implementasjonen av filteringen av listen over ansatte som skal vises i ansatt-tabellen:
FilterObject
. Før visning av tabellen, kjøres alle ansatte gjennom en søke/filtrerings-funksjon, der de blir sjekket opp mot de aktive filtrene.