Oikeiden työkalujen ja kuvioiden käyttäminen tapahtumiin perustuville arkkitehtuurille

Tapahtumiin perustuvat arkkitehtuurit tukevat tapahtumien tehokasta tuotantoa ja kulutusta, jotka ilmoittavat järjestelmän tai sovelluksen tilojen muutoksista. Nämä arkkitehtuurit mahdollistavat järjestelmien ja tukiprosessien väliset joustavat yhteydet ja lähes reaaliaikaiset päivitykset, jotka toimivat eri järjestelmissä. Vaikka tapahtumiin perustuvien arkkitehtuurien hyödyt ovat helposti näkyvissä, toteutuksen lisätiedot eivät ole aina yhtä selkeitä. Mitä ominaisuuksia sinun tulisi huomioida tapahtumiin perustuvissa arkkitehtuurikuvioissa? Mitä tiettyjä ongelmia nämä kuviot ratkaisevat? Mitä erityisiä huomioitavia asioita sovelletaan ratkaisuihisi ja mitkä ovat optimaaliset tavat ratkaista ne?

Tämä opas esittää kuviot, joita käytetään tapahtumiin perustuvien optimaalisten arkkitehtuurien rakentamiseen, kun käytät Salesforce-teknologioita. Se käsittelee myös Salesforcesta saatavilla olevia työkaluja ja tarjoaa työkalujen suosituksia useille käyttötarkoituksille. Lisätietoja Salesforceen liittyvistä datataso-integraatioista on Datan integroinnin päätöksentekooppaassamme.

• Käytä tapahtumiin perustuvia arkkitehtuuria prosesseille, jotka eivät vaadi synkronoituja vastauksia pyyntöihin. Tässä oppaassa kuvatut kuviot on suunniteltu datan yhdenmukaisuutta, skaalattavuutta ja uudelleenkäyttöä varten, mikä auttaa pitämään teknisen velan mahdollisimman pienenä, kun organisaatiosi sovellusalue kehittyy. (Lisätietoja on kohdassa Hyvin rakennettu - läpimeno).

• Jos MuleSoft tai muu Enterprise Service Bus (ESB) -ratkaisu kuuluu olemassa olevaan näkymään, käytä sitä aina, kun se on mahdollista. Nämä ratkaisut on suunniteltu tukemaan tapahtumiin perustuvia arkkitehtuurikuvioita ja niillä on tehokkaita ominaisuuksia, joiden avulla voit käyttää integraatioita uudelleen koko organisaatiossasi.

• Käytä Pub/Sub API -rajapintaa tuleville julkaisu-/tilauskuvioille sen sijaan, että rakentaisit omia tapahtumien käsittelijöitä käyttämällä muita API-rajapintoja, mukaan lukien Streaming API:a. Nyt kun Pub/Sub API on yleisesti käytettävissä, käytä sitä kaikille uusille julkaisu-/tilauskuvioille. Suunnittele olemassa olevien tapahtumaviestien siirtäminen Pub/Sub API:iin käyttämällä muita sovellusalustan API-rajapintoja, kuten Streaming API:a tai mukautettuja Apex, kun se on mahdollista.

• Sovellusalustan tapahtumat ja muutostietojen taltiointi (CDC) ovat suosittuja mekanismeja tietueiden ja kenttien muutosten julkaisemiseen, joita muut järjestelmät tarvitsevat. Emme suosittele käyttämään PushTopicia tai yleisiä tapahtumia uusille toteutuksille. Salesforce jatkaa PushTopicin ja yleisten tapahtumien tukemista nykyisten ominaisuuksien sisällä, mutta ei aio investoida tähän teknologiaan.

	Salesforce Platform on kattava tekoälyn perustuva alusta, joka yhdistää työntekijät, itsenäiset tekoälyn agentit, yritystiedot ja sovellukset yhteen luotettuun järjestelmään tuottavuuden ja asiakaskokemuksen parantamiseksi. Se mahdollistaa "aktiivisen yrityksen" luomisen yhdistämällä Customer 360 -sovellukset, Data Cloudin ja Slackin kokonaisvaltaista automatisointia varten.
	MuleSoft on Salesforcen johtava integraatioalusta, jonka avulla organisaatiot voivat yhdistää sovelluksia, dataa ja laitteita paikallisissa ja pilviympäristöissä. MuleSoft on alusta, joka tarjoaa IT-järjestelmille mahdollisuuden avata datan eri järjestelmissä, kehittää skaalattavia integraatio- ja automatisointikehyksiä sekä luoda erillisiä ja yhdistettyjä käyttökokemuksia – nopeasti.

Tapahtumiin perustuvia arkkitehtuuria (EDA) suositellaan skenaarioille, jotka vaativat lähes reaaliaikaisia ilmoituksia, jakavat raskaan tai monimutkaisen viestin käsittelyn kuormituksen ja integroivat järjestelmiä, kuten IoT ja mobiililaitteet, jotka vaativat yhteyden kestävyyden jonojen avulla. EDA:ta ei kuitenkaan tulisi ottaa käyttöön prosesseille, jotka vaativat välittömiä, synkronoituja ihmisten vastauksia, koska ne on suunniteltu ei-synkronoitavaksi suoritukseksi. Ne eivät myöskään sovellu hyvin, jos lähdedata muuttuu niin harvoin, että yksinkertaisempi malli, kuten eräkäsittely, riittäisi.

Alla on useita yleisiä skenaarioita, jotka sopivat usein hyvin tapahtumiin perustuvaan arkkitehtuuriin:

Useimmilla suurilla organisaatioilla on monimutkaisia IT-ympäristöjä, joissa on järjestelmien yhdistelmä eri ominaisuuksilla. On mahdollista tai erittäin todennäköistä, että organisaatiollasi on vanhoja järjestelmiä, jotka eivät tue tapahtumiin perustuvia integraatioita. Sinulla saattaa myös olla käyttötarkoituksia, joissa tapahtumiin perustuvat integraatiot eivät ole järkeviä, vaikka järjestelmät tukisivat niitä (esimerkiksi SFTP-tiedostojen siirrot kolmansilta osapuolilta). Jos otat askeleen taaksepäin ja tarkastelet organisaatiosi IT-ympäristöä kokonaisuutena, todennäköisesti — aivan kuten muutkin arkkitehtoniset ratkaisut — käytät erilaisia kuvioita eri skenaarioiden tukemiseksi. Kun päätät tehdä integraatioista tapahtumiin perustuvia, pidä sitä toisena työkaluna työkalupakissasi. Sitä voidaan ja pitäisi käyttää oikeissa skenaarioissa, mutta se ei ole lähestymistapa jokaiselle järjestelmälle. Kattavan integraatiostrategian kehittäminen auttaa sinua määrittämään, milloin tässä oppaassa kuvatut kuviot eivät välttämättä ole sopivia.

Monet skenaariot vaativat tapahtumiin perustuvia arkkitehtuuria, ja joissakin skenaarioissa tapahtumiin perustuvat arkkitehtuurit toimivat, vaikka ne eivät sovellu parhaiten. Joissakin tilanteissa tapahtumiin perustuvia arkkitehtuuria ei kuitenkaan tulisi käyttää. Alla on joitakin päätöspisteiden kysymyksiä, jotka auttavat sinua tunnistamaan nämä skenaariot:

Tapahtumiin perustuvia arkkitehtuurikuvioita on useita. Jotkin ovat yleisiä käyttötarkoituskuvioita, joita voidaan soveltaa käyttötarkoituksiin, joilla ei ole muita erityisvaatimuksia kuin tapahtumiin perustuva käyttö; katso esimerkiksi lisätietoja kohdasta Well-Architected - Interoperability. Muita kuvioita sovelletaan tässä kuvattuihin käyttötarkoituksiin, kuten suuria datamääriä sisältävät integraatiot tai skenaariot, jotka vaativat viestien pidemmän säilytyksen.

Alla oleva taulukko vertaa tässä asiakirjassa kuvattujen kuvioiden attribuutteja. Käytä sitä nopeana viitteenä, kun sinun täytyy tunnistaa tietyn käyttötarkoituksen mahdolliset kuviot.

Salesforce tarjoaa useita työkaluja, jotka auttavat sinua ratkaisemaan tapahtumiin perustuvia käyttötarkoituksia. Tämä taulukko sisältää yleiskatsauksen käytettävissä olevista työkaluista.

Kun kriittinen tietue muuttaa ydinsovelluksen tilaa — esimerkiksi tila siirtyy ”Käsitellään”-tilasta ”Lähetetty”-tilaan — useat muut järjestelmät vaativat todennäköisesti lähes reaaliaikaisen ilmoituksen suorittaakseen asiaankuuluvia tehtäviään. Erityinen liiketoimintatarve syntyy, kun näiden muutosten määrä on suuri ja viestit ovat monimutkaisia, mikä tekee perinteisistä Pisteestä pisteeseen -integraatioista raskaita ja vaikeita ylläpitää. Haavoittuvien ja mukautettujen yhteyksien luominen jokaiselle riippuvaiselle sovellukselle aiheuttaa teknistä velkaa ja estää organisaation nopean skaalautumisen. Näiden usein tapahtuvien datan synkronointien hallintaan tarvitaan vankka integraatiomenetelmä, joka ei yhdistä lähdesysteemiä suoraan kaikkiin kuluttaviin järjestelmiin.

Alla oleva kaavio kuvaa tyypillistä julkaisun/tilauksen kuviota, jossa useat julkaisijat ja tilaajat jakavat tietoja tapahtumaväylän kautta. Tämä peruskuvio muodostaa perustan tarkemmille kuvioille, jotka löytyvät tästä oppaasta. Tämän kuvion tärkeimmät ominaisuudet ovat:

• Julkaisijoiden ja tilaajien välillä ei ole suoraa yhteyttä. Julkaisijat lähettävät vain viestejä tapahtumaväylään, joka lähettää ne kaikkiin muihin järjestelmiin, jotka haluavat kuunnella niitä.

• Sama järjestelmä voi olla sekä julkaisija että tilaaja.

• Järjestelmät voivat julkaista tai tilata useita tapahtumatyyppejä.

• Kuten tässä oppaassa kaikissa kuvioissa, julkaise/tilaa-kuvio kuuluu yleiseen integraatiokuvion kategoriaan, joka tunnetaan etätoimenpiteen kutsuna (RPI) tai yksinkertaisesti "julkaise ja unohda".

Kun organisaation täytyy lähettää välittömiä päivityksiä suurelle määrälle asiakassovelluksia, kuten työntöilmoituksia tai SMS-viestejä mobiililaitteille, perinteinen prosessi, joka luo yksilöllisiä lähetyksiä jokaiselle vastaanottajalle, muuttuu nopeasti skaalattavuuden pullonkaulaksi. Tässä tapauksessa ydinliiketoimintatarpeena on yhden tietojen — kuten tilihälytyksen tai kriittisen palvelun muutoksen ilmoituksen — nopea ja tehokas jakaminen useille päätepisteiden sovelluksille samanaikaisesti. Virtaviivaistettu lähestymistapa tämän vaatimuksen täyttämiseen sisältää kaikkien viestien reitittämisen yhden jonon kautta, joka toimii kaikkien kuluttavien järjestelmien tapahtumatietojen keskipisteenä. Tämä lähestymistapa parantaa suorituskykyä poistamalla monien erillisten viestien kopioiden hallinta.

fanout-kuviossa viestit toimitetaan yhteen tai useampaan kohteeseen (eli kuunteleviin asiakkaisiin tai tilaajiin) yhden viestijonon kautta. Tilaajat hakevat saman viestin jonosta oman yksilöllisen kopionsa sijaan. (Huomaa, että tämä parantaa suorituskykyä, mutta se voi myös vaikeuttaa sen vahvistamista, vastaanottiko tietty tilaaja viestin vai ei).

Joissakin tapahtumaskenaarioissa on merkittävä viestien määrä, joka uhkaa täyttää synkronointi- ja transformaatioprosessien kapasiteetin, tai monimutkainen monivaiheinen logiikka, joka vaaditaan tapahtumadatan käsittelemiseen ja muuntamiseen.

Joitakin esimerkkejä ovat:

• Kausittaiset äänenvoimakkuuden pikavalinnat: Verkossa toimivien jälleenmyyjien määrä saattaa nousta, kun heidän tuotteidensa valikoima on ”kaudella”. Kun suuri määrä asiakkaita tekee ostoksia samanaikaisesti, luotujen tapahtumien määrä voi ylittää synkronointi- ja transformaatioprosessien kapasiteetin väliaikaisesti. Lisätietoja on kohdassa Well-Architected - Data Handling.

• Tapausten tai korvausvaatimusten hallinta: Palveluun perustuvat yhtiöt saattavat nähdä tapausten tai korvausvaatimusten määrän kasvavan käyttökatkosten aikana.

• Monimutkaiset datan transformaatiot: Organisaatiot, jotka tarvitsevat monimutkaista logiikkaa viestien muuntamiseen, ovat usein huolissaan siitä, että tapahtumat luodaan nopeammin kuin niitä voidaan muuntaa.

Tämä kuvio ratkaisee ongelman, kun viestejä luodaan nopeammin kuin mitä niitä voidaan muuntaa. Se varmistaa, että suuria viestien määriä ja vaadittuja datan manipulointeja voidaan käsitellä luotettavasti, lisäämällä streaming-viestialustan ja segmentoimalla viestien käsittelyn logiikkaa erillisiin komponentteihin.

Kulutetut viestit -kuvio toimii segmentoimalla viestien käsittelyn logiikkaa useisiin komponentteihin:

• Yksi komponentti käsittelee viestien reitityksen määrittämällä vaaditut transformaatiot ja lopullisen kohteen.

• Erillinen komponenttijoukko käsittelee viestin transformaation eri kerrokset (esimerkiksi kenttäkartoitukset, objektien suhteet jne.).

• Viimeinen komponentti kirjoittaa lopullisen, muokatun viestin.

Jotkin tuottajista luovat jatkuvan tapahtumavirran. Yleinen esimerkki on median streaming, joka sisältää käyttäjien vuorovaikutuksia, jotka tapahtuvat luonnollisesti erillisinä tapahtumina. Useiden järjestelmien täytyy reagoida samaan käyttäjän toimintatapaan samanaikaisesti estämättä ydinsä streaming-kokemusta.

Ota huomioon musiikin streaming-alustan tapahtumat. Näihin voi sisältyä:

• Seuraa käynnistyneitä/keskeytettyjä/ohitettuja tapahtumia

• Istuntotapahtumien kuunteleminen aikaleimoilla

• Luettelon luonti-/muokkaustapahtumat

• Sosiaaliset jakotapahtumat

• Lataa offline-kuuntelua varten

Streaming-kuviossa tilaajat käyttävät kutakin tapahtumaketjua ja käsittelevät tapahtumat samassa järjestyksessä kuin missä ne vastaanotettiin. Jokaiselle tilaajalle lähetetään yksilöllisiä kopioita viestiketjuista, jotta voit toimittaa tilaajakohtaista sisältöä ja tunnistaa, ketkä tilaajista saavat mitä viestiketjuja.

Jotta viestiketju olisi järkevä, sen kaikkien tapahtumien ja niihin liittyvien viestien täytyy olla oikeassa järjestyksessä. Jos haet viestiketjussa olevaa dataa eri järjestelmistä, sinun täytyy lisätä tilauslogiikkaa osana suunnitteluprosessia.

Jonojen käyttöskenaariot ovat yleisiä. Esimerkkejä ovat:

• Alhaisen laadun internetyhteydet: Field Service -organisaatiot tai muut organisaatiot, joissa tiimit, joilla on mobiililaitteita, tarvitsevat töitä alueilla, joilla on heikko laatu tai säännöllinen Internet-yhteys, hyötyvät jonosta, koska näillä laitteilla olevat sovellukset voivat muodostaa yhteyden jonoihinsa ja noutaa asiaankuuluvia viestejä, kun yhteys palautuu.

• Viestien puskurointi: Kun viestien määrä joskus ylittää tilaajan käsittelykapasiteetin eikä myöhästyminen aiheuta lisää ongelmia, jonot voivat olla puskurina ylimääräisten viestien tallentamiseen ja tietojen katoamisen estämiseen.

• Lähetysten hallinta: Logistiikkaorganisaatiot, joiden täytyy valvoa laivastojaan, voivat käyttää tätä kuviota nähdäkseen kunkin ajoneuvon käyttämät reitit lähes reaaliajassa ja varmistaakseen, että kuljettajat ovat mahdollisimman tehokkaita.

• IoT-laitteet: Valmistajat käyttävät usein järjestelmiä, jotka luovat nopeita datavirtoja, ja näillä viestiketjuilla voi olla vaikutuksia muihin järjestelmiin. Tätä kuviota voidaan käyttää tunnistamaan tapahtumien sarjat, jotka vaativat ihmisen toimia ennen kuin useita järjestelmiä kattavat katastrofaaliset virheet tapahtuvat.

Jonotuksessa tuottajien täytyy lähettää viestejä jonoihin, jotka säilyttävät viestit, kunnes tilaajat hakevat ne. Useimmat viestijonot noudattavat First In, First Out (FIFO) -järjestystä ja poistavat kaikki viestit, kun ne on noudettu. Jokaisella tilaajalla on yksilöllinen jono, joka vaatii lisämääritysvaiheita, mutta jonka avulla toimitus voidaan taata ja tunnistaa, ketkä tilaajista saivat viestejä.

Jonokuvion asynkronisen luonteen vuoksi jonoon lisättävän viestin ja viestin noutamisen välillä voi olla pitkä viive. Jonot tarvitsevat muistia tai tallennustilaa viestien säilyttämiseen, joten ne eivät voi kasvaa määrittämättömästi, mikä tarkoittaa, että offline-tilassa oleva tilaaja voi aiheuttaa virheen, jos jonossa muodostuu tarpeeksi viestejä. Viestien puskuroinnilla voi olla sama vaikutus, jos tilaajien käsittelyajat ovat liian pitkiä, jolloin heidän jonoissaan muodostuu paljon viestejä. Voit vähentää näitä riskejä suorittamalla perusteellisen tallennusvaatimusten analyysin kaikille viestijonoille ja suunnittelemalla tarvittaessa prosesseja, jotka tyhjentävät ja poistavat jonot käytöstä, jos viestejä ei noudeta tiettynä ajanjaksona tai kun ne saavuttavat ennalta määritetyn määrän.

Vaikka olet täysin vakuuttunut siitä, että tapahtumiin perustuva arkkitehtuuri sopii organisaatiollesi, saatat olla aloittelemassa tilaa, jossa on jo paljon Pisteestä pisteeseen -integraatioita. Rahoituksen hakeminen projektille kaikkien integraatioidesi korvaamiseksi kerralla voi olla vaikeaa, eikä se välttämättä ole edes mahdollista käyttää tapahtumiin perustuvaa arkkitehtuuria suoraan joidenkin vanhojen järjestelmien kanssa. Näissä skenaarioissa voit siirtyä asteittaiseen lähestymistapaan hajanaiseen arkkitehtuuriin muuntamalla ensin liiketoimintaan tärkeimmät sovellukset ja muuntamalla sitten muut järjestelmät, kun ne päivitetään tai korvataan tulevissa projekteissa. Tämä lähestymistapa tekee uusien sovellusten lisäämisestä tapahtumavälyyn helppoa ja sallii kokonaisvaltaisen IT-ympäristön pysyä skaalattavana ja kestävänä, kun järjestelmät lisätään jatkuvasti ajan myötä.

Arkkitehtuurina tiedämme, että jokainen arkkitehtuuri sisältää kompromisseja. Tapahtumiin perustuva arkkitehtuuri ei ole poikkeus. Vaikka löysästi kytketyistä järjestelmistä täynnä oleva maisema on erittäin skaalattava ja kestävää, huomioitavia kompromisseja on myös:

• Yleinen integraatiostrategia: Riippumatta työkaluista ja kuvioista, joita päätät käyttää, on tärkeää aloittaa luomalla strategia siitä, miten tiedot jaetaan organisaatiosi eri järjestelmissä. Tämän strategian tulisi sisältää organisaatiosi tavoitteet sen tiedoille, miten tietoja voidaan jakaa ja miten niitä käytetään, sekä tietolähteet, tavoitteet, rakenteet sekä omistajuus- ja käyttöoikeusvaatimukset.

• Vanhempien järjestelmien tuki: Organisaatiollasi voi olla vanhoja järjestelmiä, jotka eivät yksinkertaisesti tue tapahtumiin perustuvia arkkitehtuurikuvioita. Vaikka ongelmien ratkaiseminen voi olla mahdollista (esimerkiksi prosessilla, joka toimii läpiviivana tilaamalla tapahtumia ja lähettämällä sitten tulokset kohdejärjestelmään eri tietojensiirtomenetelmällä), saatat haluta harkita muita integraatiomenetelmiä tässä tapauksessa.

• Viestien rakenteelliset muutokset: Kun julkaisija ja tilaaja ovat määrittäneet ja hyväksyneet viestien alustavan rakenteen, sen muuttaminen voi olla vaikeaa, varsinkin jos tilaajat ovat ulkoisia. Voit ratkaista tämän ongelman usealla eri tavalla. Voit käyttää versioituja päätepisteitä, mutta muista määrittää selkeä elinkaari kullekin versiolle, jotta kehittäjiesi ei tarvitse ylläpitää liian monta versiota samanaikaisesti. Jos Herokussa oleva Apache Kafka on osa vaakaasi, voit myös harkita skeemojen rekisteriä tai vastaavaa työkalua, mutta varmista, että muut vaakaasi tukevat sitä (ja käyttävät sitä).

• Julkaisijoiden ja tilaajien välinen näkyvyys puuttuu: Useimmissa tapahtumiin perustuvissa arkkitehtuurikuvioissa julkaisijat eivät ole tietoisia tilaajiensa tilasta. Jos siis julkaisija lähettää kriittisen viestin, kun kaikki tilaajat ovat offline-tilassa, viestiä ei välttämättä toimiteta koskaan. Voit ratkaista tämän ongelman käyttämällä toistotoimintoja tai lisäämällä tarpeettomia tilaajia, jotka suoritetaan erillisillä palvelimilla kaikille kriittisille viesteille.

• Suorituskyvyn pullonkaulakohdat: Kun tapahtumiin perustuva arkkitehtuuri laajenee, tapahtumaväylästä voi tulla pullonkaula viestien toimittamiseen, jos liian monta julkaisijaa yrittää lähettää viestejä liian monelle tilaajalle samanaikaisesti. Voit ratkaista tämän lisäämällä tapahtumaväylälle allokoituja muisti- ja käsittelyresursseja tai käyttämällä useita tapahtumaväylät käsitelläksesi erityyppisiä viestejä rinnakkain.

Ennen kuin otat tapahtumiin perustuvan arkkitehtuurin käyttöön, harkitse, tarvitseeko sinun todella käyttää sellaista. Edellinen osio kuvaa yleisiä liiketoimintaskenaarioita, jotka sopivat hyvin kaikkiin tapahtumiin perustuviin arkkitehtuurikuvioihin. Lisätietoja on kohdassa Well-Architected - Interoperability. Tutustu tapahtumiin perustuvien arkkitehtuurien käyttöönotossa huomioitaviin haasteisiin määrittääksesi, sopivatko mielessäsi olevat kuviot parhaiten tietyille käyttötarkoituksillesi.

Huomaa, että vaikka useimmat tässä oppaassa kuvatut skenaariot sisältävät integraatioita, tapahtumiin perustuvia arkkitehtuuria voidaan käyttää myös viestien lähettämiseen yhdessä Salesforce-organisaatiossa käyttämällä esimerkiksi sovellusalustan tapahtumia. Muista pitää mielessäsi kaikki sovellettavat tapahtumien allokointirajoitukset, kun suunnittelet prosesseja, jotka käyttävät sovellusalustan tapahtumia sisäisenä viestintäjärjestelmänä.

Tapahtumiin perustuvien arkkitehtuurien ongelmat johtuvat usein siitä, että tapahtumia käytetään sisäisen viestinnän ratkaisemiseksi Salesforce-organisaatiossa. Yleisiin anti-kuvioihin sisältyy:

• Tapahtumien julkaiseminen samaan tapahtumaobjektiin liittyvistä Apex-käynnistimistä: Tämä aiheuttaa loputtoman käynnistimen silmukan.

• Tapahtumien julkaiseminen Apexista ennen kuin DML-transaktio suoritetaan loppuun: Jos transaktio epäonnistuu ja peruutuu, kaikkia julkaistuja tapahtumia, joilla on Julkaise välittömästi -julkaisutapa, ei sisällytetä periytymistoimintoon.

• Tapahtumien julkaiseminen kulussa myöhemmän automatisoinnin orkestroimiseksi: Paras tapa koordinoida logiikkaa useissa automatisoinneissa on käyttää alakulkuja tai kulkujen orkestrointia.

• Suorituksen aikaisten sidonnaisuuksien luominen: Älä julkaise tapahtumia helpottaaksesi pakettien välistä viestintää, ellet ole ryhtynyt asiaankuuluviin toimenpiteisiin suorituksen aikaisten sidonnaisuuksien poistamiseksi.

• Liian suuret hyötykuormat: Kun teet pyyntöjä, sinun kannattaa lähettää ja vastaanottaa tietosisällössä mahdollisimman vähän dataa. Jokainen käyttäjän tekemä toiminto voi aiheuttaa useita pyyntöjä, ja on tärkeää, että ne käsitellään tehokkaasti. Tarpeettoman määrän datan lähettäminen saattaa hidastaa kuljetusta ja pidentää käsittelyaikaa.

• Sovelluksen tapahtumien ei-valinnainen käsittely: Kun useita komponentteja kuuntelee sovellustapahtumaa, kehittäjien tulisi varmistaa, että tapahtuman käsittelijä suoritetaan vain, kun se on todella toivottavaa ja hyödyllistä. Esimerkiksi Lightning välilehtiin sisältyvät komponentit, jotka eivät ole keskitettyjä, voivat edelleen kuunnella, vaikka ne eivät olisi näkyvissä. Kehittäjä voi käyttää useita tekniikoita, kuten käyttää taustalla olevaa apukohdetta ainoana kuuntelijana tai kutsua getEnclosingTabId()-arvoa määrittääkseen, onko komponentin esiintymä suljettu keskitetyn välilehden sisään varmistaakseen, että jokainen tapahtuma käsitellään vain, kun se on tarkoitettu.

• Sovellusalustan tapahtumien käyttäminen julkaistaan väärin: Sovellusalustan tapahtumilla on kaksi julkaisutapaa — Julkaise välittömästi ja Julkaise sitoumuksen jälkeen. On hyödyllistä käyttää sovellusalustan reaaliaikaisia tapahtumia käyttötapauksissa, kuten Kirjaa lokiin -toiminnossa, jossa haluat julkaista lokitapahtuman riippumatta siitä, onnistuiko transaktio ja sitoutuuko se. Käytä Julkaise välittömästi -vaihtoehtoa kuitenkin erittäin huolellisesti sovellusalustan reaaliaikaisten tapahtumien kanssa. Tilaajat voivat kuluttaa tapahtumia samassa transaktiossa ja aiheuttaa rivien lukituksia tai muita kilpailuehtoja.

Kun toteutetaan tapahtumiin perustuvaa arkkitehtuuria, yksi onnistumisen avain on määrittää standardeja, joilla itse tapahtumat suunnitellaan. Yksityiskohdat vaihtelevat organisaatiosi käyttötarkoitusten mukaan, mutta alla on joitakin yleisiä ohjeita:

• Määritä tapahtumien hyötykuormille optimaalinen rakenne. Pienemmät viestikokoiset viestit lyhentävät käsittelyaikoja, mutta tilaajien pommitus suurilla viestimäärillä voi aiheuttaa ongelmia suorituskyvylle. Sinun täytyy ehkä iteroida hyötykuormasi koot ja rakenteet löytääksesi oikean tasapainon. MuleSoft ja samankaltaiset ESB-työkalut sallivat sinun suunnitella tapahtumiisi liittyvien viestien mukautettuja hyötykuormia, mikä voi auttaa sinua visualisoimaan datarakenteita parantaaksesi suorituskykyä tilaajan puolella. (Lisätietoja on kohdassa Well-Architected - API Management).

• Mieti prosessiesi kokonaisvaltaista käyttöä. Varmista, ettet luo loputtomia silmukoita, joita voi olla vaikea seurata, kun integraatiot on otettu käyttöön. Esimerkki tästä olisi kaksi järjestelmää, jotka julkaisevat tapahtumia, kun tietueita päivitetään, ja kuuntelevat toistensa tapahtumia, jotka käynnistävät muita julkaistuja tapahtumia, kun niitä käsitellään.

  Voit korjata tämäntyyppisen antikuvakkeen lisäämällä molempiin järjestelmiin logiikkaa, joka varmistaa, että kulutettuun tapahtumaan perustuvat muutokset eivät johda uuden tapahtuman julkaisemiseen. Muista myös dokumentoida kaikki tapahtumasi, niihin liittyvät käynnistimet ja mahdollisesti vaikuttavat järjestelmät. Käytä tätä dokumentaatiota viitteenä suunnittelun aikana auttaaksesi sinua havaitsemaan loputtomia silmukoita ja samankaltaisia skenaarioita mahdollisimman pian. (Lisätietoja on kohdassa Hyvin rakennettu - Prosessien suunnittelu).

• Käytä yhteisiä nimeämiskäytäntöjä eri järjestelmissä. Johdonmukaiset nimeämiskäytännöt ovat suositeltuja käytäntöjä kaikille ohjelmistokehityksille, mukaan lukien tapahtumiin perustuville arkkitehtuurille. Ota aikaa dokumentoidaksesi joukon standardeja tapahtumien nimille, rakenteille, niihin liittyville objekteille ja virheiden käsittelyprosesseille varmistaaksesi yhdenmukaisuuden eri järjestelmissä. (Lisätietoja on kohdassa Well-Architected - Design Standards).