Hva er hendelsesdrevet arkitektur?

Hendelsesdrevet arkitektur (EDA) er en integrasjonsmodell som oppdager viktige «hendelser» i en bedrift – for eksempel en transaksjon eller en forlatt handlekurv – og handler på dem i sanntid.

Hendelsesstyrt arkitektoversikt

Nesten alle hendelser i en bedrift er tidssensitive. Når en kunde foretar et nettkjøp, merker en sensor en forestående feil, en aksjekursfall eller et sikkerhetsbrudd oppdages – umiddelbare tiltak må iverksettes. Det er her en hendelsesdrevet arkitektur (EDA) kommer inn. En EDA kan skape, oppdage og reagere på hendelser når de utfolder seg, og hjelpe bedrifter med å forbedre alt fra kundeopplevelser til driftseffektivitet og smidighet.

Hva er en hendelse?

Først, noen grunnleggende. En hendelse er enhver handling eller endring av status som er viktig for en bedrift. For eksempel når noen sveiper et kredittkort, sjekker inn for en flyreise eller tilbakestiller et passord – eller når beholdningen oppdateres på et lager. Hendelser skjer hele tiden, i hver organisasjon, i hver bransje. Bedrifter blir «hendelsesdrevne» når de kan fange opp og reagere på hendelser etter hvert som de inntreffer.

Hva er en hendelsesdrevet arkitektur?

En hendelsesdrevet arkitektur (EDA) er en integrasjonsmodell som er bygget for å publisere, fange opp, behandle og svare på hendelser på tvers av distribuerte systemer i sanntid. Når en hendelse oppstår i ett program, blir en melding automatisk sendt til alle de andre programmene som trenger å vite om det, slik at de kan handle på den i sin tur.

 

 

Hendelsesbaserte arkitekturer er frakoblet – noe som betyr at applikasjoner ikke trenger å være klar over hverandre for å dele informasjon og fullføre oppgaver. Hendelsesinformasjon, eller meldinger, kan flyte fritt og automatisk mellom apper. Som et resultat er EDA-modellen mye raskere enn den tradisjonelle forespørsels-/svarmodellen, der én applikasjon må be om den spesifikke informasjonen den trenger fra en annen og vente på et svar før du går videre til neste oppgave. Også på grunn av den frakoplete naturen til en EDA, er de allment ansett som beste praksis for mikrotjenestekommunikasjon.

Hvordan fungerer en EDA?

I en hendelsesdrevet arkitektur fungerer applikasjoner som hendelsesprodusenter (apper som produserer eller fanger opp hendelser) eller hendelsesforbrukere (apper som behandler og handler på hendelser). Produsenter overfører hendelser til forbrukere via en megler, også messaging-orientert mellomvare, i sanntid. Forbrukerne kan deretter behandle hendelsen og utløse andre aktiviteter, workflower eller hendelser på egen hånd.

 

I en veldig enkel arkitektur – når det er en enkelt produsent og en enkelt forbruker som er i direkte kommunikasjon med hverandre – kan meglere være valgfrie. Men i de fleste bedrifter er det flere kilder som sender ut hendelser til flere forbrukere, så en megler, eller til og med et nettverk av meglere (også kjent som en "event mesh") er nødvendig. Når en megler eller et hendelsesnett brukes, skaper dette en "løs kobling" av applikasjoner.

Hendelsesdrevne arkitekturmønstre

Det er to hovedmønstre for overføring av hendelser i en hendelsesdrevet arkitektur: publiser/abonner og hendelsesstrømming.

 

  • Publiser/abonner (også kalt «pub/sub») – Med pub/sub abonnerer hendelsesforbrukere på meldinger og kanaler publisert av arrangementsprodusenter. Når en hendelse publiseres, sendes den direkte til alle abonnenter via en megler. For å unngå duplisering kan ikke hendelser spilles på nytt eller åpnes når de brukes – de slettes av megleren.

  • Event streaming - Med event streaming, produsenter publiserer hele strømmer av hendelser til en megler. Forbrukerne abonnerer på strømmen og kan lese fra alle deler av den, og bare bruke hendelsene som er relevante for dem. Med dette mønsteret blir hendelser beholdt av megleren selv etter at de er forbrukt.

3 tilnærminger til hendelsesbehandling

Det er tre forskjellige tilnærminger til behandling av hendelser når de når en forbruker: enkel hendelsesbehandling, kompleks hendelsesbehandling og hendelsesstrømbehandling.

 

  1. Enkel hendelsesbehandling: Forbrukerne behandler hver hendelse etter hvert som den mottas.
  2. Kompleks hendelsesbehandling: Forbrukerne behandler en rekke hendelser for å oppdage mønstre og utføre handlinger basert på resultatet.
  3. Behandling av hendelsesstrøm: Forbrukerne behandler og handler på en konstant dataflyt (data i bevegelse) i sanntid ved hjelp av en datastrømmingsplattform.

 

Bedrifter velger tilnærming til hendelsesbehandling basert på individuelle behov og brukstilfeller.

Brukstilfeller og eksempler på hendelsesdrevet arkitektur

Det er mange forskjellige brukstilfeller for hendelsesdrevne arkitekturer i alle bransjer – fra bank til detaljhandel. Her er et eksempel fra restaurantbransjen:

 

  • En student plasserer en bestilling for en pizza via en matleveringsapp, for eksempel Uber Eats. Appen fanger opp sin grunnleggende informasjon (navn, adresse, betalingsinformasjon og ordre) og publiserer "pizzaordre"-hendelsen.

  • Pizzarestauranten abonnerer på arrangementet, fullfører bestillingen og publiserer sitt eget «ordreklare» arrangement tilbake til matleveringstjenesten.

  • Tjenesten tildeler deretter en leveringsdriver, planlegger en ETA og varsler kunden om at sektordiagrammet er på vei

 

Et EDA-eksempel fra e-handel:

  • På online shopper skriver sine kredittkort detaljer på en e-handel nettsted, som publiserer "betaling sendt" hendelsen

  • Betalingssystemet abonnerer på hendelsen, behandler betalingen og utsteder sin egen "betalingsbehandlede" hendelse som indikerer suksess eller feil – og ruter den tilbake til brukergrensesnittet for nettstedet

  • Brukergrensesnittet viser betalingsstatusen til kunden og ber om de neste trinnene

 

Noen andre eksempler på EDA inkluderer:

  • Når en nettkunde klikker på et produkt og systemet svarer ved å generere produktanbefalinger basert på lignende elementer

  • Når en kunde foreviser en sjekk i en bank og systemet automatisk konterer forevisningen til kontoen

  • Når en forhandler skjermer globale transaksjoner for svindel og flagger mistenkelige kjøp til kredittkortselskapet

  • Når en produsent overvåker streaming av IoT-data fra utstyret og varsles om eventuelle vedlikeholdsproblemer eller -feil

Fordeler ved en hendelsesdrevet arkitektur

Det er mange fordeler med en hendelsesdrevet arkitektur. Topp 3 er:

 

  1. Arbeidsflyter i sanntid og svartid. En EDA kan overvåke og reagere raskt på hendelser når de oppstår, ofte ved hjelp av robotprosessautomatisering (RPA) for å akselerere arbeidsflyter og utløse neste trinn i sanntid. Dette er spesielt kritisk i perioder med høy etterspørsel – for eksempel under store salgshendelser eller helligdager. Denne reaksjonsevne kan også anvendes hver dag (dvs. non-peak) arbeidsflyter, som forbedrer alt fra automatisering av forsyningskjeden til svindelgjenkjenning.
  2. Asynkrone meldinger. Applikasjoner i en EDA kommuniserer asynkront – noe som betyr at produsentene publiserer hendelsesmeldinger uten å vente på at forbrukerne skal motta dem. Ikke bare lar dette programmene gå videre til andre oppgaver uten å vente, det forenkler integrasjonen.
  3. De- og løs kopling. Applikasjoner i en EDA er frakoplet eller løst koblet og er ikke avhengig av hverandres tilgjengelighet. De kan oppdateres, testes og distribueres uavhengig. De kan også svikte uavhengig – slik at arkitekturen er mer holdbar og vedvarende enn tradisjonelle modeller. Frakobling gjør det også enkelt å legge til ekstra utgivere og forbrukere etter behov, og eliminerer behovet for å omskrive kode hver gang det er en endring.

Konklusjon

Event Mesh tilbyr distribusjonsalternativer på tvers av ulike hyperskalerere og i private nettskymiljøer. Det kan konfigureres til å danne en distribuert mesh av event meglere distribuert på tvers av miljøer i private eller offentlige skyer. Event Mesh tilbyr et komplett sett med hendelsestjenester, inkludert strømming av hendelser, hendelsesadministrasjon og overvåking, og avanserte funksjoner som dynamisk meldingsruting og finkornet filtrering.

placeholder

Utforsk SAPs event mesh-funksjoner

Få tilgang til appene dine med en hendelsesbasert arkitektur fra SAP Integration Suite.

placeholder

Ideer du ikke finner noe annet sted

Registrer deg for en dose Business Intelligence levert rett til innboksen din.

twitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixel