Søgenings model i silo arkitektur (TO-BE)

Denne side er pt. blot på idestatsiet OBS ovenstående mand er en arkitekt

Afsende af søgning grundprincip

Søgning indenfor et forretningsområde (en silo)

Selve søgninger sker fra en silo, hvis alle relevante data findes i silo, f.eks. vi dedikeret metoder, statusservice eller alm. get metoder, dette er inkl. data en silo måtte have i sit ekstrene data område (replikeret data fra andre siloer)

Søgningerne baserer sig altid på realtidsdata

Søgning på tværs af flere forretningsområde (flere silo)

Søgning på tværs af forretningsområder sker i flere sammenhæng og her er derfor kun på den hvor data kan være håndteret “realtid” (tæt på) og ikke den batchbehandling der f.eks. sker i BI eller VOA

Eksempler på en sådan tværgående søgning i den eksisterende løsning er PersonAdvanceSearch som pt. kun bruges internt pga. performance. Denne søgning foregår på følgende parametre

  • JobCenterCode

  • Enrollment

  • ContactGroup

  • ClientCategory

  • PersonCategory

  • HasNotAbsence

  • AbsenceTypeIdentifier

  • UnemploymentFund

  • Insured

  • AgeFromDate

  • AgeToDate

  • HasNotAbsenceSince

  • EnrollmentPriorTo

  • ContactGroupPriorTo

  • HasCv

  • HasIntegrationContract

  • HasBenefitsGrading boolean

  • SelfBookingStatus

Udfordring

  • Performance og ressourceforbrug

  • Hårde afhængigheder mellem forretningsområder (siloer)

  • En ø, udnytter ikke vores setup/arkitektur

  • Besværligt at tilpasse forbedre

Model

Model tage udgangspunkt i at udnytte Eventbroker modellen for WSRM og de beskeder der dannes i den sammenhæng

  1. De eksisterende event udnyttes både de alm. med data og den der er til WSRM afsendelse

  2. Ydelsesudstillings/rapportering silo henter de relevante eventbrokerbeskeder og identificere derved hvilke data der skal opdateres i de tværgående søgninger

  3. Ydelsesudstillings/rapportering aka. BI henter de relevante data der skal opdateres ente via snitflade eller direkte i databaserne (de har jo allerede denne mulighed i forbindelse med deres øvrige behandling af data)

  4. Søgedata ligges til rette i relevant datastruktur i Ydelsesudstillings/rapportering. BI processorer data og ligger den til rette så de er optimeret for søgning (datamart)

  5. Søgedata udstilles på en WS søgemetode med alt DFDG normale sikkerhed, filtrering, logning osv.

 

En sådan model giver en række fordele:

  • Bygger videre på vores nye arkitektur og får yderlige dekoblet bindingerne mellem siloer

  • Optimeret vores søgninger. Søgninger vil ikke belaset vores drift system i DFDG og give langt bedre søgepreformance

  • Giver bedre mulighed for mere avanceret søgløsninger

  • Giver BI mulighed for “realtid at distribuerer data til andre aftagere f.eks. i SUP til VOA og dermed øge tilgænglighede og aktualiteten til data interne og eksterne i STAR

  • Langt større fleksibilitet i tilpasninger af søgninger