Modernin Salesforce-integraation täytyy tukea paljon muuta kuin yksinkertaista datan vaihtoa. Niiden odotetaan tarjoavan reaaliaikaisia asiakaskokemuksia, koordinoivan toimintoja useissa järjestelmissä ja toimivan luotettavasti yrityksen laajuisesti – kaikki noudattaen tiukkoja tietoturva- ja vaatimustenmukaisuusvaatimuksia. Oikean integraatiomenetelmän valitseminen on siis kriittinen arkkitehtoninen päätös, ei toteutuksen lisätieto. Harkitse yleistä yrityskenaariota. Asiakas suorittaa ostoksen mobiilisovelluksessa, mikä käynnistää oikeutustarkistuksen reaaliajassa henkilökohtaiselle tarjoukselle. Samalla transaktioiden data täytyy tallentaa ERP-järjestelmään, asiakkaan attribuutit täytyy päivittää Salesforcessa ja analyysejä täytyy lähettää Data Lakeen — ilman viiveen, datan identtisyyden tai vaatimustenmukaisuuden riskiä. Tällaiset skenaariot ovat tyypillisiä nykyisissä Salesforce-ympäristöissä, joissa Salesforce harvoin toimii erillään ja joiden täytyy integroida saumattomasti sovellusten ja datalustojen laajempaan ekosysteemiin. Tämä opas auttaa arkkitehtejä ja kehittäjiä suunnittelemaan integraatiot selkeästi ja luottavaisesti. Sen sijaan, että se keskittyisi pisteestä pisteeseen -toteutuksiin, se esittää joukon todennettuja integraatiokuvioita, jotka käsittelevät toistuvia yritysskenaarioita — kuten prosessien orkestrointia, datan synkronointia ja reaaliaikaista datan käyttöä. Jokainen kuvio korostaa arkkitehtonisia tarkoituksia, kompromisseja ja suoritusmalleja, jotta tiimit voivat tehdä tietoon perustuvia suunnittelupäätökset, jotka skaalautuvat ja kestävät. Tässä asiakirjassa löydät:

• Integrointikuvioita, jotka edustavat yleisiä yrityksen ”arkkityyppejä” prosesseissa, datassa ja virtuaalisessa käyttöoikeudessa
• Kuvion valintakehys, joka auttaa tunnistamaan oikean lähestymistavan integraation tarkoituksen ja suorituksen ajoituksen perusteella
• Käytännön ohjeita skaalattavuutta, kestävyyttä, hallintaa ja tietoturvaa koskeviin huomioitaviin asioihin
• Salesforce- ja Data 360 -toteutuksista saatuja suositeltuja käytäntöjä Tämän asiakirjan tavoitteena on tarjota yhteinen arkkitehtoninen kieli integraatiolle, joka auttaa tiimejä suunnittelemaan ratkaisuja, jotka tasapainottavat suorituskykyä, joustavuutta ja Trustia ja jotka vastaavat yritystietoja ja hallintastrategioita.

Tämä asiakirja on tarkoitettu suunnittelijoille ja arkkitehdeille, joiden täytyy integroida dataa yrityksensä muista sovelluksista Salesforce Data 360 -palveluun (aiemmalle Data Cloudille). Tämä sisältö on joukko Salesforce-arkkitehtien ja -kumppanien onnistuneita toteutuksia. Lisätietoja Data 360:n laajamittaisen käyttöönoton integrointiominaisuuksista ja vaihtoehdoista on alla olevissa Kuvion yhteenveto- ja Kuvion valintaopas -osioissa . Arkkitehtien ja kehittäjien tulisi huomioida nämä kuvion lisätiedot ja suositellut käytännöt datan vuorovaikutusprojektien suunnittelu- ja toteutusvaiheessa Data 360:ään. Kun nämä kuviot on otettu käyttöön oikein, voit siirtyä tuotantoympäristöön mahdollisimman nopeasti ja käyttää mahdollisimman vakaita, skaalattavissa olevia ja huoltovapaita sovelluksia. Salesforcen omat konsultointiarkkitehtit käyttävät näitä kuvioita viitepisteinä arkkitehtuurin tarkastuksissa ja ylläpitävät ja parantavat niitä aktiivisesti. Tämä sisältö kattaa useimmat integraatioskenaariot, mutta ei kaikkia. Vaikka Salesforce sallii käyttöliittymän (UI) integraation, -mashups, esimerkiksi, tällainen integraatio ei kuulu tämän asiakirjan soveltamisalaan.

Jokainen integraatiokuvio noudattaa yhdenmukaista rakennetta. Tämä varmistaa yhdenmukaisuuden kussakin kuviossa annetuissa tiedoissa ja helpottaa kuvien vertaamista.

• Nimi: Kuvion tunnus, joka osoittaa myös kuviossa olevan integraation tyypin.
• Konteksti: Kokonaisvaltainen integraatioskenaario, johon kuvio vaikuttaa. Konteksti tarjoaa tietoja siitä, mitä käyttäjät yrittävät saavuttaa ja miten sovellus toimii vaatimusten täyttämiseksi.
• Ongelma: Tämä on kysymyksenä ilmaistu skenaario, jonka ratkaisemiseksi kuvio on suunniteltu. Lue tämä osio ymmärtääksesi, sopiiko kuvio integraatioskenaarioosi.
• Voimat: Rajoitukset ja olosuhteet, jotka tekevät määritetystä skenaariosta vaikean ratkaistavan.
• Ratkaisu: Suositeltu tapa ratkaista integraatioskenaario.
• Kuvaus: UML-järjestyksen kaavio, joka näyttää sinulle, miten ratkaisu käsittelee skenaariota.
• Tulokset: Selittää, miten voit soveltaa ratkaisua integraatioskenaarioosi ja miten se ratkaisee kyseiseen skenaarioon liittyvät ongelmat. Tämä osio sisältää myös uusia haasteita, jotka voivat ilmetä kuviossa.
• Sivupalkit: Muotoon liittyvät lisäosiot, jotka sisältävät tärkeimpiä teknisiä ongelmia, kuviossa esiintyviä variaatioita, kuviokohtaisia huolenaiheita jne.
• Esimerkki: Todellinen skenaario, joka kuvaa, miten suunnittelukuviota käytetään todellisessa Salesforce-skenaariossa. Tämä esimerkki selittää integraatiotavoitteet ja miten se toteutetaan tavoitteiden saavuttamiseksi.

Käytä tätä taulukkoa sisällysluettelona tässä asiakirjassa oleville integraatiokuvioille.

Tässä asiakirjassa olevat integraatiokuvioet on luokiteltu kolmeen kategoriaan: data, prosessi ja visuaaliset integraatiot.

Data 360:n datan integrointimuodot käsittelevät datan siirtoa ja synkronointia eri järjestelmissä varmistaakseen, että Data 360 ja ulkoiset alustat sisältävät yhdenmukaisia, ajankohtaisia ja luotettavia tietoja. Nämä kuviot käsittelevät tavallisesti suuria, raskaita datakulkuja ja ovat riippuvaisia hallituista myyntiputkeista, jotka noudattavat skeemojen yhdenmukaisuutta, linjausten seurantaa ja pääkäyttäyssääntöjä.

• Erän syöttökuviot edustavat enterprise-datan perustasoa. Joukkodatan tuonti pilvitallennuspalveluista, kuten AWS S3, Azure Blob tai Google Cloud Storage, sallii suurten historiallisten datajoukkojen lataamisen säännöllisesti Data 360:ään identiteetin ratkaisemista, segmentointia ja analyysiä varten. Vastaavasti joukkotuonti Salesforce Cloudista — kuten Sales, Service tai Marketing Cloud — käyttää natiiviliittimien ja datavirtojen avulla CRM-dataa yhtenäistettyyn datakerrokseen, mikä varmistaa harmonisointi ja jatkuvuuden eri osallistumistoimintojen järjestelmissä.
• Streaming ja reaaliaikaiset syöttökuviot laajentavat tätä kaappaamalla nopean tapahtumadataa. Tapahtumiin perustuva syöttö Käsittely-API:n kautta sallii ulkoisten järjestelmien lähettää asiakkaiden toimintoja jatkuvasti Data 360:ään. Verkko- ja mobiilitoimintojen reaaliaikainen syöttö kaappaa napsautusvirran ja vuorovaikutustiedot suoraan digitaalisista yhteydenottopisteistä edistääkseen henkilökohtaisuutta välittömästi. Lähes reaaliaikainen CRM-synkronointi Streaming API -rajapintojen kautta varmistaa, että asiakasattribuutit ja suostumusten päivitykset näytetään nopeasti eri järjestelmissä. Tapahtumaketjun tuonti viestintäalustoista, kuten Amazon Kinesis tai Confluent MSK, tukee jatkuvia, tehokäyttöisiä myyntiputkia, jotka yhdenmukaistavat Data 360:n yritystapahtumien arkkitehtuurien kanssa.
• Yhtenäistetty usean organisaation datalusta Data Cloud One -sovelluksella edustaa datan integrointia ja tarjoaa yhdistetyn ympäristön, josta voit yhdistää dataa useista Salesforce-organisaatioista ja ulkoisista lähteistä yhteisen hallinnan ja semanttisen kerroksen alla. Tämä sallii organisaatioiden saavuttaa yhtiönlaajuista datan yhdenmukaisuutta, jaettuja datamalleja ja skaalattavia analyysejä.
• Aktivointivaiheessa eräaktivointikuviot noudattavat samaa datan integrointiperiaatetta. Data 360:ssä kerätyt segmentit viedään ajoitetuissa töissä myöhempiin markkinointi- ja mainosalustoihin — kuten Marketing Cloud, Meta Ads tai Google Ads — mistä ne käynnistävät kampanjoiden suorituksen. Vastaavasti datajoukkoja voidaan viedä pilvitallennustilan kohteisiin ulkoisten analyysien ja datatieteiden myyntiputkien edistämiseksi. Data 360 toimii kaikkien näiden käyttötarkoitusten synkronoidun ja kerätyn asiakastietojen totuuden lähteenä.

Process Integration -kuviot Data 360:ssa sisältävät liiketoimintaprosessien käynnistämisen tai orkestroinnin eri järjestelmissä lähes reaaliajassa. Nämä kuviot sallivat Data 360:n osallistua aktiivisesti yrityksen työnkulkuihin, mikä mahdollistaa asiayhteydestä riippuvat vastaukset ja dynaamisen datan aktivoinnin.

• API-pohjainen on-demand-aktivointi sallii reaaliaikaisten osallistumiskenaarioiden käytön. Connect API:n kautta mukautetut sovellukset voivat kysellä tai aktivoida asiakasprofiileja suoraan Data 360:sta osana toimintaprosesseja — esimerkiksi agenttikonsoli noutaa yhtenäistettyjä profiilien havaintoja asiakasvuorovaikutuksen aikana. Complete Customer Profile Retrieval via Data Graph API tukee yhdistelmäsovelluksia ja mikropalveluita, jotka luottavat API-pohjaiseen pääsyyn asiakkaan täyteen entiteettikaavioon, mikä mahdollistaa dynaamiset käyttökokemukset ilman esimääritettyjä segmenttejä.
• Reaaliaikaiset datatoiminnot edistävät tätä integraatiomenetelmää ottamalla käyttöön välitön reagointi. Kun asiakassignaali havaitaan — kuten ostos, lomakkeen lähetys tai kynnysarvotapahtuma — Data 360 voi käynnistää toimintoja, kuten päivittää CRM-tietueen, kutsua ulkoista Webhookia tai käynnistää henkilökohtaisen tarjouksen työnkulun. Nämä kuviot edustavat todellista prosessien orkestrointia ja yhdistävät reaaliaikaisen Älykkäät asiakastiedot automatisoituun toiminnalliseen suoritukseen.

Data 360:n virtuaaliintegraatiokuvioiden avulla voit käyttää ulkoisia tai yhdistettyjä tietolähteitä fyysisesti kopioimatta tai kopioimatta dataa. Nämä ovat tärkeitä yrityksille, jotka tarvitsevat hallittuja ja ajankohtaisia tietoja kyselyn aikana ja vähentävät datan liikkuvuutta.

• Saapuvan nollakopiodatan yhdistäminen (External Platforms-to-Data 360) sallii ulkoisten järjestelmien — kuten datan varastojen tai data lakien — jakaa datajoukkoja Data 360:n kanssa suojattujen, hallittujen yhteyksien kautta (esimerkiksi Snowflake Secure Data Sharing). Tämä varmistaa, että Data 360 voi käyttää ja työstää ulkoista dataa virtuaalisesti, mikä säilyttää sen tuoreuden ja välttää tarpeettoman replikoinnin.
• Outbound Zero Copy Data Sharing (Data 360-to-External Platforms) sallii Data 360:n paljastaa kuratoituja datajoukkoja ulkoista kulutusta varten, kuten tekoälymallinnusta, liiketoimintaälyä tai edistyneitä analyysejä, turvallisen datan yhdistämisen ja live-kyselyjen mekanismien avulla. Parhaan integraatiostrategian valitseminen järjestelmällesi ei ole vaikeaa. Harkittavana on useita näkökohtia ja useita työkaluja, joita voidaan käyttää, ja jotkin työkalut soveltuvat paremmin tiettyihin tehtäviin kuin toiset. Jokainen kuvio käsittelee tiettyjä kriittisiä osa-alueita, kuten kunkin järjestelmän ominaisuudet, datan määrä, virheiden käsittely ja transaktiivisuus.

Kun valitset integraatiokuviota, aloita vastaamalla kahteen peruskysymykseen, jotka määrittävät integraation kokonaiskuvan ja toimintatavan. Mitä olet integroimassa? — Prosessi, Data tai Virtuaali-käyttöoikeus Tämä ulottuvuus määrittää integraation ensisijaisen käyttötarkoituksen.

• Prosessien integraatiot keskittyvät liiketoimintatyönkulkujen orkestrointiin ja toimintojen koordinointiin eri järjestelmissä.
• Datan integraatiot keskittyvät datan synkronoimiseen, rikastamiseen tai levittämiseen järjestelmien välillä.
• Virtuaaliintegraatiot keskittyvät ulkoisten tietojen käyttämiseen reaaliajassa kopioimatta niitä tai säilyttämättä niitä Salesforcessa tai Data 360:ssa. Tämän tarkoituksen ymmärtäminen auttaa määrittämään järjestelmien välisen orkestroinnin, datan siirron ja yhdistämisen tason.
• Kuinka se täytyy suorittaa? — Synkronoitu tai Ei-synkronoitu-metodi määrittää integraation suoritusmallin.
• Synkronoidut integraatiot ovat reaaliaikaisia ja estäviä, jolloin soittaja odottaa välittömästi vastausta – ja niitä käytetään tavallisesti käyttäjien määrittämissä tai vahvistuksissa.
• Asynkroniset integraatiot ovat estämättömiä ja irrotettavissa, ja ne on suunniteltu käsittelemään skaalaa, pitkäkestoisia prosesseja, uudelleenkäynnistyksiä ja suuria datamääriä. Yhdessä nämä kaksi ulottuvuutta — integraation tarkoitus ja suorituksen ajoitus — tarjoavat selkeän ja yhdenmukaisen kehyksen oikean integraatiokuvion valitsemiseen käyttäjäkokemuksen, skaalattavuuden ja toiminnan kestävyyttä tasapainottaessa. Huomautus: Integraatio voi vaatia ulkoisen välisovelluksen tai integraatioratkaisun (esimerkiksi Enterprise Service Bus), riippuen integraatioskenaarioosi liittyvistä näkökohdista.

Tämä taulukko kuvaa kuviot ja niiden tärkeimmät näkökohdat, jotka auttavat sinua määrittämään, mikä kuvio sopii parhaiten tarpeisiisi, kun integraatiosi tapahtuu Salesforcesta toiseen järjestelmään

Tämä taulukko kuvaa kuviot ja niiden tärkeimmät näkökohdat, jotta voit määrittää tarpeisiisi sopivimman kuvion, kun integraatiosi tapahtuu toisesta järjestelmästä Salesforceen.

Tämä taulukko kuvaa joitakin välisovelluksiin liittyviä avainsanoja ja niiden määritelmiä näiden kuvioiden osalta.

Datan tuonti on ensimmäinen ja tärkein vaihe Salesforce Data 360 -datan elinkaaressa. Näin raakat tiedot useista ulkoisista järjestelmistä — CRM, ERP, web, mobiili tai kolmansien osapuolten API-rajapinnoista — saapuvat sovellusalustaan ja niistä tulee osa yhtenäistettyä asiakasnäkymää. Oikea syöttökuvio riippuu yrityksen tarpeista:

• Datan määrä — kuinka paljon dataa siirretään kerralla
• Latency — kuinka tuoreen datan on oltava
• Lähdejärjestelmän ominaisuudet — miten järjestelmä voi yhdistää ja toimittaa dataa Data 360 tukee useita syöttötiloja näiden tarpeiden täyttämiseksi: erä suuria latauksia varten, suoratoisto lähes reaaliaikaisia päivityksiä varten, tapahtumiin perustuva transaktioiden välittömyyttä varten ja Zero Copy -syöttö ulkoisen datan välittömään käyttöön siirtämättä sitä fyysisesti. Yhdessä nämä kuviot varmistavat, että jokainen asiakassignaali — olipa kyseessä sitten ostostapahtuma, napsautusketjun loki tai kanta-asiakaspäivitys — virtaa Data 360:ään tehokkaasti, turvallisesti ja oikeaan aikaan luotettavien analyysien ja tekoälyn tarjoamien käyttökokemusten tarjoamiseksi.

Eräsyötön kuviot ovat suurten datan perehdytyksen perusta Data 360:ssa. Ne on optimoitu skenaarioille, joissa dataa käsitellään joukkona — tavallisesti ajoitetusti tai säännöllisesti — eikä jatkuvasti. Nämä kuviot soveltuvat parhaiten:

• Historialliset datan lataukset alustan alustamiseksi olemassa olevilla yritystietueilla
• Säännöllinen synkronointi tietuejärjestelmien kanssa, kuten ERP:t, datan varastot tai omistamat tietokannat
• Käytä tapauksia, joissa reaaliaikainen tuoreus ei ole tärkeää, mutta johdonmukaisuus, täydellisyys ja auditoitavuus ovat tärkeitä. Eräsyöte tarjoaa ennustettavissa olevan suorituskyvyn ja yksinkertaisen toimintatavan, joten se on luotettu valinta yrityksille, jotka hallitsevat teratavua rakenteellista tai puolirakenteista dataa. Data 360 tarjoaa joukon tuotanto-valmiita, yleisesti saatavilla olevia liittimien, jotka tukevat erien tuontia oletusarvoisesti. Nämä liittimet virtaviivaistavat integraation määrityksiä, vähentävät mukautetun ETL:n kehittämistä ja varmistavat datan laadun ja tietoturvan jokaisessa tuonnissa. Alla olevassa taulukossa on kuvattu yleisimmät liittimet, joita käytetään yrityksen erien syöttämiseen.

Konteksti

Tämä kuvio on suunniteltu yrityskenaarioille, jotka sisältävät suuria määriä rakenteellista dataa — kuten CSV- tai parkettitiedostoja — ja jäsentämättömiä resursseja keskitetyistä datalähteistä tai ajoitetuista tiedostoputouksista. Tietolähteisiin sisältyvät tavallisesti pilvitallennusalustat, kuten Amazon S3, Google Cloud Storage (GCS) ja Microsoft Azure Blob Storage, joissa tiedostoja toimitetaan säännöllisesti osana datavirtoja tai erävienteitä.

Ongelma

Miten organisaatio voi luoda luotettavan, turvallisen ja tehokäyttöisen prosessin tuodakseen suuria, tiedostoihin perustuvia datajoukkoja ensisijaisesta pilvitallennusalustastaan Data 360:ään ennustettavassa, toistuvassa aikataulussa – ilman, että hallintotapaa, skaalattavuutta tai suorituskykyä uhataan?

Voimat

Massiivisten, tiedostoihin perustuvien datajoukkojen tuominen Data 360 -palveluun ei ole yksinkertainen datan siirtoharjoitus — se on arkkitehtoninen haaste, joka perustuu skaalan, hallinnan ja sovellusalustan rajoituksiin.

Datan määrä ja skaala : Data 360 -syöttöliittimet on optimoitu luotettavuutta ja hallintaa varten, eivät satunnaista joukkotuotetta varten. Esimerkiksi Amazon S3 -liitin tukee enintään 100 miljoonaa riviä tai 50 Gt per objekti, kumpi tahansa raja ylittyy ensin. Tästä rajoituksesta tulee tärkeä suunnittelurajoitus yrityksille, joiden historialliset datajoukot sisältävät miljardeja tietueita. Yksittäisen tiedoston, ylentämisen ja siirtämisen lähestymistapa ei ole nopeasti toteutettavissa, ja se vaatii älykkäitä datan osiointi-, pilkkomis- ja orkestrointistrategioita skaalan saavuttamiseksi ilman liittimien rajoituksia.

Skeeman määritelmä ja ylläpito : Data 360 vaatii erilliset skeemojen määritelmät jokaiselle syöttöputkelle semanttisen ja rakenteellisen eheyden takaamiseksi. Jos käytät S3-syötettä, csv-tiedoston täytyy määrittää sarakkeiden otsikot ja yksi edustava datarivi. Tämä tiedosto toimii lähdejärjestelmän, eli pilvitallennustilan ja Data 360:n välisenä kanonisena sopimuksena. Kaikki kenttien nimissä, datatyypeissä tai koodauksessa olevat virheet voivat aiheuttaa syöttövirheitä tai tyhjää datan korruptiota. Tämän skeematiedoston ylläpitäminen versiohallinnassa ja vahvistuksen noudattaminen CI/CD- tai datan hallintatyönkulkujen kautta on suositeltu käytäntö tuotantoympäristöille.

Tiukat nimeämiskäytännöt : Data 360 noudattaa kiinteitä objektien ja kenttien nimeämissääntöjä säilyttääkseen yhdenmukaisuuden metadata-kaaviossa.

• Objektien nimien täytyy alkaa kirjaimella ja ne voivat sisältää vain kirjaimia, numeroita tai alaviivoja.
• Kenttien nimien täytyy noudattaa samoja kuvioita. Tiedostot, jotka rikkovat näitä käytäntöjä — esimerkiksi kentät, jotka sisältävät välilyöntejä, erikoismerkkejä tai ei-tuettuja symboleita — epäonnistuvat skeeman vahvistuksessa syötön aikana. Yritysten täytyy ottaa käyttöön tietojen esihygieniaprosesseja saapuvien tiedostorakenteiden puhdistamiseksi ja normalisoimiseksi.

Todennus ja tietoturva-asento : Jokaisen yhteyden ulkoiseen tallennustilaan täytyy noudattaa yritystason suojaus- ja vaatimustenmukaisuusstandardeja.

• Todennus käsitellään tavallisesti AWS-käyttöoikeuden/salaisuuden avainten tai yhdistetyn henkilöllisyydentarjoajan (IdP) todennuksen kautta.
• IAM-roolit täytyy rajata käyttämään vähiten käyttöoikeuksia, mikä sallii vain määritettyjen tallennuspolkujen lukuoikeuden.
• Lähtevien IP-osoitteiden täytyy lisätä suoraan lähdejärjestelmän sallittujen osoitteiden luetteloon suojatun käytön varmistamiseksi. Nämä kerroksiset ohjaimet varmistavat, että kaikki tiedostojen siirrot toimivat nollatason Trust- ja auditoitavan alueen sisällä, mikä tasapainottaa yrityksen vaatimustenmukaisuuden ja joustavuuden, jota tarvitaan suuren skaalan syöttämiseen.

Ratkaisu

Tämä taulukko sisältää ratkaisuja tähän integraatio-ongelmaan.

Luonnos

Tämä kaavio kuvaa vaiheet, joilla data tuodaan pilvitallennustilasta Data 360:ään.

Tässä skenaariossa:

• Pääkäyttäjä määrittää yhteyden pilvitallennustilaan Data 360 -määritysten käyttöliittymän kautta (määrittämällä todennuksen, kategoriatiedot, IAM-roolit ja valintaluettelot).
• Data Cloudin Määritykset-valikon käyttöliittymä todentaa itsensä Cloud Storage Platformilla ja vahvistaa tunnukset ja käyttöoikeudet.
• Pääkäyttäjä luo datavirran Data 360:ssa, linkittää datavirran objektiin/kansioon Cloud Storessa ja määrittää syöttöaikataulun.
• Ajoituksen käynnistimen datavirta pyytää lähdetiedostoja (esimerkiksi CSV, Parquet) Cloud Storage Platformista.
• Cloud Storage Platform tarjoaa tiedostot, mukaan lukien vaaditut käyvät schema_sample.csv-tiedostot ja muut nimeämiskäytäntöjä noudattavat datatiedostot.
• Datavirta siirtää tiedostot Data 360:n sisäiseen vaiheistuksen ympäristöön.
• Data 360 Pipeline käsittelee tiedostot: Käyttää skeeman määritelmää schema_sample.csv-tiedostosta Vahvistaa rakenteen, kenttien nimet ja jakaa latauksen, jos syötön kynnysarvot ylittyvät (100 miljoonaa riviä / 50 Gt tiedostoa kohti). Jos suuria tiedostoja havaitaan, esikäsittelyn osiointivaihe (ilmoitetaan pääkäyttäjälle seuraavaa suorituskertaa varten) suoritetaan ulkoisesti.
• Tietueet tuodaan vaiheistamisesta Data Lake -objektiin (DLO).
• Käytä append-noodia erädatan datamuunnos yhdistääksesi useita DLO-objekteja tarvittaessa ja kun data on osioitu.
• Data 360 kirjaa onnistumisen/epäonnistumisen lokiin, päivittää tilan valvontaan ja ilmoittaa, että data on valmiina kartoitukseen, harmonisointiin ja yhtenäistämiseen.

Tulokset

Tämän kuvion käyttö mahdollistaa rakenteellisten tai jäsentämättömien tiedostojen suojatun, ajoitetun ja laajan tuonnin Enterprise Cloud -tallennusalustoista Data 360:ään. Prosessi on automatisoitu, skaalattava ja joustava — se toimittaa raakadataa Data Lake -objekteihin (DLO), jotka toimivat perustana Customer 360 -tietomallin harmonisointiin ja kartoittamiseen.

Syöttömekanismit

Syöttömekanismi riippuu Data 360:ssa määritetystä liittimestä ja ajoitusstrategiasta.

Virheiden käsittely ja palautus

Virheiden käsittely ja palautus ovat tärkeitä luotettavuuden varmistamiseksi raskaan syötteen operaatioissa.

• Virheen havaitseminen: Jokainen datavirta, joka suoritetaan, kirjaa syöttövirheet lokiin (esimerkiksi skeeman epäjohdonmukaisuus, tiedostojen korruptio tai nimeämisrikkomukset) Data 360 Monitoringissa. Pääkäyttäjät voivat tarkastaa ja käsitellä epäonnistuneet erät uudelleen.
• Palautusmekanismi: Data 360 ylläpitää tarkastuspisteytystä varmistaakseen, että epäonnistuneet erät eivät korruptoi aiempia syötteitä. Uudelleenkäynnistyksiä voidaan määrittää lähdeongelmien korjaamisen jälkeen (esimerkiksi väärin muotoillut CSV-tiedostot).
• Skeeman vahvistus: schema_sample.csv-tiedosto määrittää datatyypit ja rakenteen. Kaikki muutokset käynnistävät vahvistuksen välttyäkseen skeeman häiriöiltä suorituskertojen välillä.

Idempotent-suunnittelussa huomioitavia asioita

Syöttö on suunnittelusta riippumatonta — saman tiedoston uudelleenkäsittely ei johda identtisiin tietueisiin. Tärkeimpiin strategioihin sisältyy:

• Tiedoston sormenjälki: Data 360 laskee tarkistusmäärät tunnistaakseen ja ohittaakseen aiemmin käsitellyt tiedostot.
• Transaktioiden syöttö: Data vaihdetaan ja sitoutetaan DLO:hen vasta, kun kaikki tietueet on käsitelty onnistuneesti.
• Liitä vs. Korvaa: Riippuen liiketoimintalogiikasta, viestiketjut voivat lisätä kohteen DLO-objektin tai korvata sen kokonaan. Tämä varmistaa deterministiset lopputulokset ja estää datan osittaisen päällekkäisyyden.

Tietoturvassa huomioitavia asioita

Tietoturva on olennainen osa koko tuontiputkea, aina todennuksesta salaukseen ja käyttöoikeuksien hallintaan.

• Todennus ja valtuutus: Liittimet käyttävät Salesforcen suojattua integraatiokehystä, joka hyödyntää nimettyjä tunnuksia ja ulkoisia tunnuksia todennusta varten paljastamatta salaisuuksia.
• Salaus: Data salataan siirron aikana (TLS 1.2+) ja levossa (AES-256).
• Verkon ohjaimet: Lähdesäiliöjärjestelmien (esimerkiksi S3-säiliöiden) täytyy sallia Data 360 IP -osoitteet.
• Yhteensopivuuden tasaus: Tukee yrityksen tietoturvakehyksiä, kuten GDPR-, HIPAA- ja FFIEC-ohjeita, yhdistettynä asiakashallittuihin avaimiin (CMK).
• Auditointi: Jokainen syöttötyö ja tunnuksen käyttöoikeus kirjataan lokiin jäljitettävyyden ja vaatimustenmukaisuuden raportointia varten.

Sivupalkit

Aikavyöhyke

Aikataulu riippuu tuonnin aikataulusta ja datan määrästä.

• Suuret yritysdatajoukot (100M+ rivejä) saattavat vaatia osioinnin rinnakkaista syöttämistä varten.
• Tyypillinen tuonnin viive vaihtelee minuuteista muutamaan tuntiin, riippuen tiedoston koosta ja transformaation monimutkaisuudesta.
• Data 360 Streaming-ominaisuus tai API-pohjaiset liittimet saattavat täydentää tiedostopohjaista mallia lähes reaaliaikaista tuontia varten.

Datamäärät

• Soveltuu parhaiten raskaan ja säännöllisen erän syöttämiseen.
• Jokainen S3-liittimen kautta käsitelty objekti tukee enintään 100 miljoonaa riviä, eli 50 Gt per tiedosto.
• Käytä petatavuisia järjestelmiä käyttämällä datan osiointia ja usean viestiketjun orkestrointia.

Päätepisteen kapasiteetin ja standardien tuki

Päätepisteen kapasiteetti ja tavallinen tuki riippuvat valitsemastasi ratkaisusta.

Osavaltioiden hallinta

Tila seurataan datavirtojen ja niiden edellisen onnistuneen suorituksen aikaleiman kautta.

• Data 360 ylläpitää synkronointitiloja ja offset-tiloja automaattisesti varmistaakseen, että vain uudet tai muokatut tiedostot käsitellään myöhemmissä suorituskerroissa.
• Kun integroit ulkoisia ETL-työkaluja, sinun kannattaa käyttää yksilöllisiä tiedostotunnisteita (esimerkiksi UUID-tunnuksia tai aikaleimoja) välttyäksesi identtisiltä tietueilta.

Monimutkaiset integraatioskenaariot

Tämä kuvio voidaan integroida edistyneissä yritysarkkitehtuureissa seuraaviin kohteisiin:

• Middleware ETL Pipelines (esim. Informatica, MuleSoft): esimerkkikäsittelyn, vahvistuksen ja tiedostojen osioinnin orkestrointi ennen datan siirtämistä Data 360:ään.
• AI/ML-työnkulut: käsitelty DLO-data voidaan julkaista DMO:n kautta koulutusympäristöjen mallinnukseen tai RAG-indekseihin Data 360 -aktivointikohteiden kautta.
• Transaktio-järjestelmät: yhdenmukaistetut DMO-organisaatiot voivat käynnistää myöhempiä päivityksiä Salesforce CRM:ssä tai ulkoisissa järjestelmissä datatoimintojen tai sovellusalustan tapahtumien kautta.

Esimerkki

Globaali finanssilaitos tallentaa asiakastiedot ja maksutapahtumatiedot AWS S3 -datajoukkoon, jossa osioituja Parquet-tiedostoja luodaan öisin alueittain (kuten Yhdysvallat, EU ja APAC). Data-arkkitehtuuritiimi määrittää Data 360:ssa useita datavirtoja, jotka on yhdistetty alueelliseen kansioon ja joilla on jaettu schema_sample.csv, joka varmistaa yhdenmukaiset otsikot ja datatyypit kaikissa osioissa. Öiset syöttöaikataulut lataavat datan automaattisesti DLO-objekteihin, minkä jälkeen erädatan transformaatiot liittää kaikki alueelliset osiot yhtenäistettyyn Customer_Transactions_DLO-objektiin. Tämä yhdenmukaistettu datajoukko kartoitetaan sitten Customer 360 -tietomalliin, mikä sallii myöhemmän analyysin ja tekoälyn aktivoinnin. Tämä lähestymistapa tarjoaa automatisoidun ja luotettavan tuonnin olemassa olevasta datamerestä, käyttää vahvaa todennusta ja salausta yrityksen IT-käytäntöjen mukaisesti ja tarjoaa skaalattavan ja modulaarisen perustan, joka tukee tulevaa laajentumista ja skeeman evoluutiota.

Konteksti

Ensisijainen ja tärkein Data 360 -käyttötarkoitus on asiakastietojen yhdistäminen koko Salesforce-ekosysteemissä. Tämä kuvio kattaa datan tuomisen suoraan Salesforce-ydinalustoilta — Sales Cloud ja Service Cloud (yhteensä Salesforce CRM) ja Marketing Cloud Engagement. Lähteisiin sisältyvät vakiomuotoiset ja mukautetut CRM-objektit (esimerkiksi Tili, Yhteyshenkilö, Tapaus, Mahdollisuus) sekä Marketing Cloud Engagement -datalaajennukset, jotka sisältävät osallistumistapahtumia, sähköpostien lähetyksiä ja seurantadataa.

Ongelma

Miten organisaatio voi tuoda vakiomuotoisia ja mukautettuja CRM-objekteja ja Marketing Cloud Engagement -datalaajennuksia Data 360:ään tehokkaasti ja luotettavasti, jotta dataa voidaan käyttää yhtenäistettyjen asiakasprofiilien laatimiseen (identiteetin vahvistus, Customer 360) ja samalla suorituskyvyn, hallinnan ja lähdejärjestelmien häiriöiden vähentämiseksi?

Voimat

Natiiviliittimet tekevät työstä yksinkertaisempaa, mutta useita toiminta- ja arkkitehtuuriryhmiä täytyy hallita:

• Yleiset lähdekoodin käyttöoikeudet: Erillisellä yhdistämiskäyttäjällä (integraatiotilillä) täytyy olla asiaankuuluvat objektin ja kenttätason lukuoikeudet. Vaadittujen käyttöoikeusjoukkojen kohdistamisen epäonnistuminen (esimerkiksi käyttövalmis Data 360 -liittimen käyttöoikeusjoukko) on yleinen syy syöttövirheisiin.
• Datan päivitystilat ja kustannukset: Liittimet tukevat täyttä ja delta/asteittaista päivitystilaa. Täydet päivitykset vaativat enemmän suorituskykyä ja hyvityksiä. delta-noudot vähentävät kuormitusta, mutta riippuvat luotettavasta muutosten seuraamisesta lähdejärjestelmässä.
• Mukautetut skeemat ja kenttäkartoitukset: CRM-instanssit sisältävät usein mukautettuja objekteja/kenttiä. Mukautettujen kenttien (nimien ja tyyppien) tarkat skeemakartoitukset ja käsittely ovat tarpeen kartoitusvirheiden tai semanttisen viivan välttämiseksi.
• Aloitusdatapaketit vs. Mukautettu kartoitus: Aloitusdatapaketit nopeuttavat perehdytystä valitsemalla tyypillisiä objekteja/kenttiä valmiiksi, mutta raskaasti mukautetut organisaatiot tarvitsevat viestiketjujen mukautettuja määritelmiä.
• Lähetyksen ja API:n rajoitukset: Lähdeorganisaation API-rajoitukset ja Marketing Cloud -noutoasteet rajoittavat, miten aggressiivisesti voit ajoittaa päivityksiä.
• Datan hygienia ja nimeämiskäytännöt: Lähdekenttien nimet, null-toiminnot ja datatyypit täytyy normalisoida ennen syöttämistä välttyäksesi myöhemmiltä kartoitusongelmilta.
• Tietoturva ja pienimmät käyttöoikeudet: Liitin luottaa turvalliseen todennukseen ja sen täytyy noudattaa vähiten käyttöoikeuksia omaavia IAM-kuvioita, tarkastettavuutta ja verkko-ohjauksia.

Ratkaisu

Tämä taulukko sisältää ratkaisuja tähän integraatio-ongelmaan.

Luonnos

Tämä kaavio kuvaa vaiheet, joilla data tuodaan pilvitallennustilasta Data 360:ään.

Tässä skenaariossa:

• Pääkäyttäjä provisioi integraatiokäyttäjät ja kohdistaa liittimen käyttöoikeusjoukot lähdeorganisaatioissa.
• Pääkäyttäjä määrittää liittimet Data 360 -määritykset-valikosta (yhteys Salesforce CRM:ään ja Marketing Cloudiin OAuth/yhdistetyn sovelluksen kautta).
• Pääkäyttäjä luo datavirrat, jotka valitsevat objektit ja datalaajennukset, valitsevat täyden tai delta-päivityksen ja määrittävät aikataulut.
• Data 360 pyytää skeema- ja delta-valtuuksia lähteestä tai lähteistä ajoitetulla suorituskerralla.
• Lähdejärjestelmät palauttavat tietueita (delta tai täysi tietosisältö). Marketing Cloud voi toimittaa noutoja ja CRM voi palauttaa JSON/Query-tuloksia.
• Data 360 vaihtaa tiedostot sisäisessä suojatussa vaiheistusalueessaan ja vahvistaa kartoitetun skeeman perusteella.
• Jos vahvistus epäonnistuu, syöttö kirjaa virheen lokiin, varoittaa pääkäyttäjää ja pysäyttää sitouttamisen. Jos vahvistus onnistuu, Data 360 sitouttaa tietueet atomisesti kohde-DLO-objektiin.
• Monitorointi- ja auditointilokit päivitetään linjan, suorituksen keston, rivien määrän ja tunnusten käytön perusteella. Hälytykset, jotka lähetetään pääkäyttäjille kynnysarvojen tai virheiden varalta.

Tulokset

Asiakassuhteiden ja markkinoinnin osallistumistietojen ydintiedot tuodaan Data 360:ään Data Lake -objekteina (DLO). Tämä palauttaa:

• Yhtenäistetty datajoukko, joka sisältää profiileja, tapauksia, mahdollisuuksia ja sähköpostien/osallistumistietojen tilastoja.
• Perus identiteetin ratkaisemiseen ja yhtenäistettyjen yksityishenkilöiden profiilien rakentamiseen.
• Toimintavalmius myöhempää harmonisointiin, rikastamiseen, tekoälymallinnukseen ja aktivointiin hallinnan ja auditointikyvyn säilyttämiseksi.

Syöttömekanismit

Syöttömekanismi riippuu Data 360:ssa määritetystä liittimestä ja ajoitusstrategiasta.

Virheiden käsittely ja palautus

Virheiden käsittely ja palautus ovat tärkeitä luotettavuuden varmistamiseksi raskaan syötteen operaatioissa.

• Suorituskertaiset lokit: Jokainen datavirta-suoritus tarjoaa lisätietoja onnistumisesta/epäonnistumisesta ja rivitason virheistä.
• Palautukset ja tarkastuspisteytys: Epäonnistuneita suorituksia voidaan yrittää suorittaa uudelleen, kun lähde- tai skeemavirheitä on korjattu. Data 360 käyttää vaiheistamista ja atomisen sitoutuksen semanttiikkaa.
• Hälytykset: Määritä hälytyksiä skeemavirtoille, toistuville virheille tai delta-järjestyksen aukkoille.

Idempotent-suunnittelussa huomioitavia asioita

Syöttö on suunnittelusta riippumatonta — sen uudelleenkäsittely ei johda identtisiin tietueisiin. Tärkeimpiin strategioihin sisältyy:

• Muutoksen tunnistus: Delta-noudot perustuvat lähdejärjestelmän muutostietäjiin (LastModifiedDate / järjestelmän muutostietojen datan taltiointi). Varmista, että lähde tarjoaa luotettavia aikaleimoja/merkintöjä.
• Deduktointi: Käytä yksilöllisiä liiketoiminta-avaimia (esimerkiksi Contact.ExternalId) poistaaksesi kopioinnin tai lisätäksesi sen DLO-objekteihin.
• Transaktioiden sitoumus: Tietueet vaihtuvat ja sitoutetaan vain, kun eräkäsittely on suoritettu onnistuneesti.

Tietoturvassa huomioitavia asioita

Tietoturva on olennainen osa koko tuontiputkea, aina todennuksesta salaukseen ja käyttöoikeuksien hallintaan.

• Todennus ja valtuutus: Liittimet käyttävät Salesforcen suojattua integraatiokehystä, joka hyödyntää nimettyjä tunnuksia ja ulkoisia tunnuksia todennusta varten paljastamatta salaisuuksia.
• Salaus: Data salataan siirron aikana (TLS 1.2+) ja levossa (AES-256).
• Verkon ohjaimet: Lähdesäiliöjärjestelmien (esimerkiksi S3-säiliöiden) täytyy sallia Data 360 IP -osoitteet.
• Yhteensopivuuden tasaus: Tukee yrityksen tietoturvakehyksiä, kuten GDPR-, HIPAA- ja FFIEC-ohjeita, yhdistettynä asiakashallittuihin avaimiin (CMK).
• Auditointi: Jokainen syöttötyö ja tunnuksen käyttöoikeus kirjataan lokiin jäljitettävyyden ja vaatimustenmukaisuuden raportointia varten

Sivupalkit

Aikavyöhyke

Aikataulu riippuu tuonnin aikataulusta ja datan määrästä.

• Ideaalinen tahti riippuu liiketoimintatarpeesta — tunneittain lähes reaaliaikaisille markkinointikäynnistimille, öisin suurille yhteensovituksille.
• Delta-tilat vähentävät kuormitusta ja kustannuksia. Täydet päivitykset ovat raskaampia ja niitä käytetään alustavia latauksia tai suuria skeeman muutoksia varten.

Datamäärät

• CRM-liittimet on optimoitu transaktioille ja keskitason datajoukoille (miljoonia tietueita).
• Jos käytät erittäin suuria historiallisia määriä, harkitse vaiheittaisen ETL:n jakamista ja lataamista vaiheisiin.

Päätepisteen kapasiteetin ja standardien tuki

Päätepisteen kapasiteetti ja tavallinen tuki riippuvat valitsemastasi ratkaisusta.

Osavaltioiden hallinta

• Liittimen tila: Datavirrat ylläpitävät viimeisimpiä onnistuneita synkronoinnin aikaleimoja ja delta-poikkeuksia.
• Päästrategia: Valitse yhtenäisiä yritystunnuksia (ulkoisia tunnuksia), jotta downstream-yhteensovitukset ja upserts ovat deterministisiä.

Monimutkaiset integraatioskenaariot

Tämä kuvio voidaan integroida edistyneissä yritysarkkitehtuureissa seuraaviin kohteisiin:

• Hybridit-topologiat: Yhdistä CRM-syöttö streaming-ominaisuuteen (sovellusalustan tapahtumat) saadaksesi päivityksiä lähes reaaliajassa.
• Middleware-orkestrointi: Käytä MuleSoft- tai ETL-työkaluja, kun vaaditaan monimutkaista orkestrointia, rikastamista tai transformaatiota edeltävää käyttöönottoa.
• Aktivoinnin palautteen silmukat: Harmonisoidut DMO-organisaatiot voivat käynnistää lähdejärjestelmien alempia päivityksiä datatoimintojen tai sovellusalustan API-rajapintojen kautta (huomioi SoD-ohjaimet).

Esimerkki

Monikansallinen jälleenmyyjä yhdistää Tilit-, Yhteyshenkilöt-, Tapaukset-, Mahdollisuudet- ja Marketing Cloud -osallistumistiedot Data 360:ään luodakseen yhtenäisen asiakasnäkymän. Aloitusdatapaketti käynnistää myynti- ja palvelualueiden ydinobjektit, kun taas tiimi laajentaa mallia mukautetuilla kentillä, kuten Loyalty_Membershipc ja Customer_Tierc, kerätäkseen kanta-asiakaskontekstin. CRM-datavirrat suoritetaan tunneittain delta-tilassa, ja Marketing Cloud Engagement synkronoi päivittäin käyttämällä delta-noutoja osallistumistapahtumille. Nämä datajoukot käsitellään DLO-objektien ja identiteetin ratkaisun kautta, mikä johtaa yhtenäistettyyn asiakasprofiiliin, joka yhdistää CRM- ja osallistumissignaalit personalisointiin ja myöhempiin tekoälymalleihin.

Nämä kuviot on laadittu skenaarioille, joissa millisekunteilla on merkitystä — kun asiakasvuorovaikutusten, transaktioiden tai signaalien täytyy käynnistää välitön havainto tai toiminto. Niiden avulla voidaan ottaa käyttöön tapahtumiin perustuva datakulku, jossa tietoja käsitellään heti, kun ne luodaan. Salesforce Data 360 -ekosysteemissä ”reaaliaikainen” ei ole yksi tila — se on viivemallien jatkuvuus. Yhdellä puolella on lähes reaaliaikainen synkronointi, jossa tietuejärjestelmien päivitykset (kuten CRM tai ERP) heijastuvat Data 360 -versioon sekunteina tai minuutteina. Toisella puolella on todellinen reaaliaikainen tapahtumien kaappaus, jossa asiakkaan toiminnalliset signaalit — kuten napsautukset, ostokset tai mobiilitoiminnot — tuodaan ja aktivoidaan millisekunteina. Arkkitehtien eroavaisuus on enemmän kuin semanttinen. Se määrittää, miten myyntiputket on suunniteltu, miten API-rajapintoja kutsutaan ja miten myöhemmät päätökset tehdään. Oikeanlaisen kuvion valitseminen — olipa se sitten lähes reaaliaikainen synkronointi tai tapahtumien suoratoisto — varmistaa, että järjestelmä täyttää yrityksen toiminnallisten viiveiden tavoitteet säilyttäen datan eheyden, skaalattavuuden ja hallinnan.

Konteksti

Tämä kuvio sallii minkä tahansa ulkoisen järjestelmän — kuten mukautetun sovelluksen, Internet of Things (IoT) -alustan, myyntipistejärjestelmän (POS) tai kolmannen osapuolen palvelun — lähettää tapahtumadataa ohjelmallisesti Data 360:ään lähes reaaliajassa, kun erillisiä tapahtumia tapahtuu.

Ongelma

Miten kehittäjä voi lähettää yksittäisiä tietueita tai pieniä ei-synkronoituja tapahtumien eroja ulkoisesta sovelluksesta Data 360:ään luotettavasti pienellä viiveellä, jotta dataa voidaan käsitellä, segmentoida ja aktivoida nopeasti?

Voimat

Tämä kuvio tarjoaa lyhyen viiveen ja parempaa kehittäjien hallintaa, mutta se sisältää useita teknisiä rajoituksia ja toimintariippuvuuksia:

• Kehittäjän sidonnaisuus: Vaatii kehittäjien vaivaa toteuttaakseen todennettuja REST API -asiakassovelluksia ja virhe-/uudelleenyrityslogiikkaa — se ei ole Osoita ja napsauta -liitin.
• Tiukka skeema-on-writing: Käsittely-API käyttää skeema-on-write-protokollaa. Tarkka skeema täytyy määrittää ja ladata liittimen kokoonpanoon. Kaikkien tietosisältöjen täytyy noudattaa tarkalleen tai ne hylätään.
• Kaksinkertaiset vuorovaikutustilat: Sama liitin tukee sekä suoratoistoa (JSON) vähäisen viiveen, tietueen tietueen päivityksiä ja joukkosynkronointia (CSV) suurille säännöllisille synkronoinneille — arkkitehtien täytyy valita käyttötarkoituksia.
• Todennus ja tietoturva: Puhelut täytyy todentaa yhdistetyn Salesforce-sovelluksen kautta käyttämällä OAuth 2.0 -versiota (esimerkiksi JWT-haltijan kulku palvelimelta palvelimelle). Valtuuksien hallinta-, kierrättäminen- ja vähiten käyttöoikeuksia käyttävät vaikutusalueet ovat pakollisia.
• Toiminnallinen näkyvyys: Kehittäjien ja sovellusalustan tiimien täytyy ottaa käyttöön valvonta vastauskoodeille, uudelleentarjouksille, dead-letter-jonoille ja skeema-hälytyksille.
• Reaaliaikaisen kaavion vaatimus: Jos haluat todellisen välitön aktivoinnin (välitön segmentointi, reaaliaikainen DMO-kartoitus), datamalliobjektin kohdeobjektin (DMO) täytyy olla osa reaaliaikaista datakaaviota. Muussa tapauksessa tapahtumat kulkevat hieman pidemmällä aikavälillä.

Ratkaisu

Tämä taulukko sisältää ratkaisuja tähän integraatio-ongelmaan.

Luonnos

Tämä kaavio kuvaa vaiheiden järjestystä, joilla data tuodaan Käsittely-API:sta Data 360:ään.

Tässä skenaariossa:

• Ulkoinen järjestelmä pyytää todennusta OAuth/JWT-todennuksella todennuspalvelimelta.
• Todennuspalvelin palauttaa käyttöoikeusvaltuuden ulkoiseen järjestelmään.
• Ulkoinen järjestelmä lähettää datan tuontipyynnön POST-pyynnön Data 360 -käsittely-API:iin valtuutuksella ja JSON-tietosisällöllä.
• Käsittely-API vahvistaa pyyntöjen skeeman ja todennuksen Vaiheistaminen ja vahvistus -moduulin kautta.
• Jos skeema/todennus epäonnistuu:
• Ulkoiseen järjestelmään palautettu virhe.
• Hylkääminen kirjattu valvontaan ja hälytykseen.
• Onnistuneessa vahvistuksessa:
• Data Lake -objektiin (DLO) vaiheittaiset ja sitoutetut tietueet.
• Onnistui kirjattu seurantaa varten.
• Jos tämä vaihtoehto on käytössä, reaaliaikaiseen datakaavioon (DMO) lisätty data käynnistää myöhempiä työnkulkuja.
• Muussa tapauksessa vakiomuotoisen erän tai pidemmän viiveen myyntiputken kautta käsitelty data.
• Käsittely-API vahvistaa, että ulkoinen järjestelmä on onnistunut.
• Valvonta-komponentit varoittavat pääkäyttäjää kuolleiden kirjaimien jonoista, hylkäyssuhteista tai viiveongelmista.

Tulokset

Ulkoisten tapahtumien data tuodaan Data 360 -dLO-objekteihin pienellä viiveellä. Kun kohde-DMO on osa reaaliaikaista kaaviota, dataa voi käyttää välitöntä segmentointia, agenttien työnkulkuja, tekoälymalleja ja toiminta-aktivointia varten. Tämä sallii nopean liiketoiminnan vastauksen tapahtumiin mistä tahansa yhdistetystä järjestelmästä.

Syöttömekanismit

Syöttömekanismi riippuu Data 360:ssa määritetystä liittimestä ja ajoitusstrategiasta.

Virheiden käsittely ja palautus

• Äkilliset (synkronointi) -virheet: 4xx vastaukset skeema-/todennusvirheille — asiakassovelluksen täytyy korjata tietosisältö tai valtuus ja yrittää uudelleen.
• Väliaikaiset (asynkronointi) virheet: 5xx-vastaukset — Asiakassovellus yrittää uudelleen eksponenttisella rästityksellä.
• Dead-Letter-jono (DLQ): Pysyvät virheet laskeutuvat DLQ:ään manuaalista tarkastusta ja toistamista varten.
• Valvonta: Seuraa skeemojen hylkäämissuhdetta, todennusvirheitä, viiveen prosenttiosuuksia ja DLQ-varastoa. Kynnysarvojen hälytys.

Idempotent-suunnittelussa huomioitavia asioita

• Idempotency-avain: Jokaisen tapahtuman tulisi sisältää yksilöllinen idempotency-avain/viestin tunnus.
• Upsert-strategia: Käytä liiketoiminta-avaimia (ExternalId) välttyäksesi identtisiltä nimikkeiltä toistuville.
• Dedup-ikkuna: Arkkitehtin tulisi määrittää identtisten tietueiden poistamisen ajanjaksot ja säilytyksen idempotenssin seurantaa varten.

Tietoturvassa huomioitavia asioita

Tietoturva on olennainen osa koko tuontiputkea, aina todennuksesta salaukseen ja käyttöoikeuksien hallintaan.

• Todennus: OAuth 2.0 (JWT Bearer) on suositeltu palvelimelta palvelimelle. Rajoita vaikutusalueita vain syöttöön.
• Salaus: TLS 1.2+ kuljetusta varten; Data 360 käyttää salausta paikallisesti.
• Pienin käyttöoikeus: Yhdistettyjen sovellusten tunnuksilla on vähäiset käyttöoikeudet; he voivat kierrättää salaisuuksia ja laitteiden käyttöoikeuslokeja.
• Palkkujen hallinta: Lisää tapahtumien metadataan suostumus-/kulutusmerkintöjä. Ota käyttöön ABAC/CEDAR-käytännöt välittömästi syöttämisen jälkeen.
• IP-ohjaimet / Yksityinen yhteys: Rajoita käyttöoikeuksia sallittujen luetteloiden kautta tarvittaessa tai käytä Private Connectia yksityiseen verkostoitumiseen.

Sivupalkit

Aikavyöhyke

Aikataulu riippuu tuonnin aikataulusta ja datan määrästä. Streaming JSON palauttaa viiveen sekunteista toiseen, riippuen käsittelystä ja kaavion kokoonpanosta. Joukko-CSV on minuutteista tunteihin. Valitse liiketoimintasopimusten perusteella.

Datamäärät

Yksittäisten tapahtumien kokojen tulisi olla pieniä (alle muutaman kt). Jos tuottajasi tuottavat tehokäyttöisiä tuotteita, harkitse erien lisäämistä tuottajasta tai käyttämällä streaming-bufferia (Kafka/Kinesis) ennen API:n kutsumista.

Osavaltioiden hallinta

• Skeeman versiointi: Ylläpidä skeeman versiota tapahtumien metadatassa ja käytä liittimien versiointia, kun päivität OAS-sopimusta.
• Liittimen poikkeamat: Data 360 käsittelee sitoumusten semanttiset seikat. Tuottajien tulisi seurata idempotency-avaimia ja viimeistä onnistunutta järjestystä turvallisen toistamisen varmistamiseksi.

Monimutkaiset integraatioskenaariot

Tämä kuvio voidaan integroida edistyneissä yritysarkkitehtuureissa seuraaviin kohteisiin:

• Edge Validation Layer: Käytä middleware-ohjelmistoa kääntääksesi heterogeeniset tuottajamuodot vaadittuun OAS-sopimukseen, suorittaaksesi tiedonsiirtorajoituksen ja esivaltuutuksen.
• Hybridirakenteet: Yhdistä syöttö-API tapahtumille ja liittimet joukkokäyttöön.
• Agentin aktivointi: Reaaliaikaisiin DMO-organisaatioihin kartoitetut tapahtumat voivat käynnistää Agentforce ja Einstein automatisoituun päätöksentekoon.

Esimerkki

Vähittäismyyntiketju lähettää myyntipisteen (POS) ostotapahtumat Data 360 inReal-Timeen edistääkseen asiakkaiden välitöntä osallistumista. Jokainen myymälä käyttää kevyttä palvelinkomponenttia, joka kerää transaktiot, rikastaa ne sijaintien ja laitteiden metadatalla ja lähettää JSON-tapahtumia turvallisesti käyttämällä JWT Bearerin OAuth-todennusta idempotency-avaimilla välttyäksesi identtisiltä tietueilta. Pääkäyttäjä määrittää tapahtumarakenteen lataamalla palvelimelle OAS-skeeman myyntipisteelle ja määrittämällä Käsittely-API -liittimen. Saapuvat tapahtumat tuodaan pos_sale DLO -objektiin, kartoitetaan Sale DMO -organisaatioon ja lisätään reaaliaikaiseen kaavioon. Tästä syystä arvokkaat ostokset havaitaan välittömästi, mikä käynnistää VIP-työnkulut Agentforcessa ja päivittää asiakassegmentoinnin edistääkseen reaaliaikaista personalisointia.

Konteksti

Tämä kuvio sallii suurten määrien ja tarkkojen käyttäjien vuorovaikutustietojen keräämisen — kuten sivujen tarkastelukerrat, painikkeiden napsautukset, tuotekuvaukset ja videosoitteet — verkkosivustoilta ja mobiilisovelluksista trueReal-Time-tilassa. Se on välttämätöntä henkilökohtaiselle personalisoinnille, jossa jokainen digitaalinen vuorovaikutus voi vaikuttaa dynaamisesti käyttäjäkokemukseen ja edistää osallistumista.

Ongelma

Miten yritys voi siepata ja käsitellä jatkuvaa toimintatapahtumien virtaa digitaalisista ominaisuuksista — joka kattaa miljoonia käyttäjien vuorovaikutuksia minuutissa — ja tehdä datasta välittömästi käytettävissä Data 360:ssa real-aikojen segmentoinnin, personalisoinnin ja aktivoinnin edistämiseksi?

Voimat

Tämä käyttötarkoitus esittelee useita suunnitteluhaasteita, jotka vaativat käyttötarkoituksen mukaisen, vähäisen viiveen syöttöarkkitehtuurin:

• Extreme Throughput : Kiireiset verkkosivustot tai mobiilisovellukset voivat lähettää miljoonia tapahtumia minuutissa. Syöttökerroksen täytyy skaalata vaakasuorasti käsitelläksesi tätä määrää ilman tapahtumien häviöitä tai taustapaineita, mikä varmistaa yhdenmukaisen viiveen huippukuormitusten aikana.
• Asiakaspuolen instrumentaatio : Toisin kuin palvelinpohjaiset integraatiot, tämä kuvio riippuu asiakaspuolen SDK-työkaluista. Jokaiselle sivulle täytyy olla upotettu JavaScript-kuvake (Salesforce Interactions SDK) tai mobiilisovelluksiin integroitu natiivinen SDK. Tämä vaatii kestävän asiakassovelluksen käyttöönoton, versioinnin ja tapahtumien skeeman hallinnan.
• Low-latency-tapahtumien käsittely : Käyttäjien toimintojen — kuten ”lisää ostoskoriin” tai ”videosoita” — täytyy saavuttaa Data 360 sekunneissa, mikä mahdollistaa reaaliaikaisen aktivoinnin ja asiayhteydestä riippuvat vastaukset (esimerkiksi kohdennetut tarjoukset, henkilökohtaiset suositukset).
• Datan harmonisointi ja identiteetin vahvistus : Tallennetut tapahtumat sisältävät usein anonyymejä tunnisteita (evästeet, laitetunnukset, istuntovaltuudet). Customer 360 -käyttöskenaariot täytyy kartoittaa tunnettuihin profiileihin Data 360 -henkilöllisyyden ratkaisun kautta ja harmonisoida Customer 360 -tietomalliin.

Ratkaisu

Suositeltu lähestymistapa on käyttää Salesforce Marketing Cloud Personalization -liitintä — sellaista natiivia, täysin hallittua streaming-putkea, joka on suunniteltu korkean läpimenoasteen toimintatapojen syöttämiseen.

Luonnos

Tämä kaavio kuvaa vaiheet, joilla data tuodaan mobiili- ja verkkokanavista Data 360 -palveluun.

Tässä skenaariossa:

• Ota SDK käyttöön verkkokanavissa tai mobiilikanavissa (käyttäjien vuorovaikutusten kaappaus).
• Määritä SDK vuokralaisen tunnuksen, ympäristön ja suostumusten ohjaimilla.
• Viestiketju kaapatut JSON-tapahtumat (metadata + attribuutit) Marketing Cloudin streaming-päätepisteeseen.
• Luo ja määritä Data 360 -määritykset-valikosta Personalization Connector vuokralaiselle.
• Tuo tapahtumia DLO-objektiin ja kartoita DLO → DMO Data 360:een.
• Ota DMO käyttöön reaaliaikaisessa kaaviossa, jotta voit aktivoida sen välittömästi.
• Valvo viiveitä, skeeman yhteensopivuutta, suostumuslippuja, läpimenoa ja virhesuhteita.
• Ota käyttöön tuotantoympäristöön ja valvo jatkuvasti.

Tulokset

Jatkuva, vähäisen viiveen käyttäytymistapahtumien virta kulkee digitaalisista kanavista Data 360:ään. Sekunneissa jokainen käyttäjän toiminto on käytettävissä reaaliaikaista segmentointia, ennakoivaa mallinnusta tai käynnistettyä personalisointia varten, mikä mahdollistaa todella mukautetun asiakaskokemuksen.

Syöttömekanismit

Syöttömekanismi riippuu Data 360:ssa määritetystä liittimestä ja ajoitusstrategiasta.

Virheiden käsittely ja palautus

• Lajennettu vikojen toleranssi: Toteuta monitasoisia vahvistus- ja uudelleenyritysmekanismeja — asiakassovelluksen SDK-työkalut käsittelevät väliaikaisia virheitä eksponentiaalisella rästityksellä, kun taas syöttökerros käyttää kestäviä jonoja ja toistettavissa olevia myyntiputkia tietojen katoamisen estämiseksi.
• Skeema ja datan hallinta: Versioi ja vahvista tapahtumien skeemat jatkuvasti. Virheelliset tai kehittyvät tapahtumat reititetään skeeman hylkäämiseen tai kuolleen kirjaimen jonoon turvallista lajittelua ja toistamista varten.
• Idempotency ja Deduplication: Käytä vakaita tapahtumien tunnisteita ja upsert-semantiikkaa varmistaaksesi, että käsittely tapahtuu tarkasti kerran, vaikka se tapahtuisi uudelleen tai uudelleen.
• Valvonnan ja palautuksen automatisointi: Läpimäärän, viiveen ja virhesuhteiden jatkuva valvonta käynnistää automatisoituja palautustyönkulkuja — mikä varmistaa alhaisen viiveen, luotettavan toimituksen ja yhdenmukaiset reaaliaikaiset personalisointitulokset.

Idempotent-suunnittelussa huomioitavia asioita

• Jokaisella tapahtumalla täytyy olla yksilöllinen idempotency-avain tai viestitunnus, jotta identtisiä lähetyksiä voidaan poistaa alempana.
• Käytä liiketoiminta-avaimia (esimerkiksi sessionID + eventTimestamp + userID) tarvittaessa identtisten tietueiden tunnistamiseen.
• Määritä kopioinnin poistamisen ajanjakso (esimerkiksi 24 tuntia), jonka aikana identtiset tapahtumat ohitetaan tai suodatetaan.
• Käytä tarvittaessa upsert-strategioita (esimerkiksi päivitä laskurit tai merkintöjä identtisten tietueiden lisäämisen sijaan).

Tietoturvassa huomioitavia asioita

Tietoturva on olennainen osa koko tuontiputkea, aina todennuksesta salaukseen ja käyttöoikeuksien hallintaan.

• Lähetyksen salaus: TLS 1.2+ kaikille SDK → streaming-palvelun yhteyksille.
• Datan salaus paikallisesti Data 360:ssa ja markkinointivirrassa.
• SDK noudattaa käyttäjien suostumusmerkintöjä (GDPR/CCPA) ja estää seurannan, jos suostumus evätään.
• SDK-liikenteen todennus: varmista, että vain hyväksytyt vuokralaiset/asiakkaat voivat suoratoistaa tapahtumia.
• Metadata: jokaisen tapahtuman täytyy sisältää lähdetunnus, aikaleima, skeeman versio, istunnon tunnus, idempotens-avain.
• Pienin käyttöoikeus: SDK-päätepisteet ja liittimet, jotka on rajoitettu tapahtumien syöttöalueeseen. Kierrä tunnukset säännöllisesti.
• Datan luokittelu: Annotoi henkilötietoja tapahtumien tietosisällöissä, noudata käytäntöjä välittömästi syötteen jälkeen

Sivupalkit

Aikavyöhyke

• Aikataulu riippuu loppukäyttäjän toiminnasta ja tapahtumien streaming-kokoonpanosta.
• Salesforce Interactions SDK:n kautta kaapatut ja Marketing Cloud Personalization -viestiketjun kautta toimitetut tapahtumat saavuttavat tavallisesti välisekuntien ja ~2 sekunnin viiveen ennen kuin ne ovat käytettävissä Data 360 Real-Time -kaaviossa.
• Tämä sallii lähes välittömän segmentoinnin, personalisoinnin ja aktivoinnin aktiivisissa käyttäjäistunnoissa.

Datamäärät

Yksittäiset toimintatapahtumat (esimerkiksi napsautus, tarkastelu, lisää ostoskoriin) ovat kevyitä — tavallisesti 1–5 kt per tietosisältö. Jos käytät suuria digitaalisia ominaisuuksia, odota tuhansia tai miljoonia tapahtumia minuutissa. Tuoton ja keston varmistaminen:

• Käytä SDK:n sisäänrakennettuja erä- ja kokeilumekanismeja liikkuville sivuille.
• Offload burst -käsittely Marketing Cloudin streaming-buffer-kerrokselle.
• Valvo tuonnin läpimeno- ja virhesuhteita käyttämällä liittimen tilastojen mittaristoa.

Osavaltioiden hallinta

Jokainen tapahtuma sisältää metadataa osavaltioiden ja versioiden hallintaan:

• Skeeman versiointi: Upota skeeman versio kaikkiin tapahtumiin ja versioi Personalization -liitin, kun päivität skeemaa.
• Toisto-oikeus: SDK yrittää uudelleen automaattisesti tapahtumia, jotka epäonnistuvat väliaikaisten verkko-ongelmien takia, ja korjaa ne eksponentiaalisesti.
• Idempotency keysit: Yksilölliset tunnisteet (sessionId + eventType + timestamp) varmistavat, että toistetut tapahtumat eivät luo identtisiä tietueita Data 360:ssa.
• Offset-hallinta: Data 360 seuraa onnistuneita sitoumuksia. Liitin asettaa kaikki käsittelemättömät tapahtumat uudelleen, kunnes ne tuodaan onnistuneesti.

Monimutkaiset integraatioskenaariot

Tämä kuvio integroituu saumattomasti edistyneisiin yritysarkkitehtuureihin:

• Edge-rikastuksen kerros: Lisää middleware (esimerkiksi käänteinen välityspalvelin tai palvelinpoikkeava toiminto) syöttääksesi lisää konteksteja — kuten maantieteellistä sijaintia, laitetyyppiä tai kampanjan metadataa — ennen kuin tapahtumat saavuttavat Marketing Cloudin.
• Hybrid (Streaming + Erä): Käytä Marketing Cloud -liitintä reaaliaikaisille viestiketjuille ja yhdistä se ETL-erätöihin (esimerkiksi tilaustietoihin) myöhempää yhteensovitusta varten.
• Agentin aktivointi: Reaaliaikaisiin DMO-organisaatioihin kartoitetut tapahtumat voivat käynnistää Einsteinin personalisointi, Agentforce tai tekoälyyn perustuvaa päätöksentekoa digitaalisen käyttökokemuksen mukauttamiseksi tällä hetkellä.
• Monien vuokralaisten hallinta: Käytä suostumusmerkintöjä ja vuokralaisen tietoista metadataa noudattaaksesi yksityisyyttä ja vaatimustenmukaisuutta usean brändin tai usean alueen ympäristöissä.

Esimerkki

Globaali verkkokauppayritys tarjoaa asiakkaille henkilökohtaisia tuesuosituksia ja dynaamista sisältöä, kun he selaavat aktiivisesti React-pohjaista yhden sivun sovellusta www.retailx.com. Käyttämällä Salesforce Interactions SDK -pakettia asiakaspuolella sivusto tallentaa sivujen tarkastelukerrat, tuotenapsautukset, ostoskorin toiminnot ja videoiden vuorovaikutukset reaaliajassa. Nämä tapahtumat kulkevat Marketing Cloud Personalization -tapahtumaketjun ja Personalization -liittimen kautta Data 360 DLO -objekteihin, joista ne mallinnetaan DMO-organisaatioihin ja sisällytetään reaaliaikaiseen kaavioon. Tämä arkkitehtuuri sallii käyttäytymisen signaalien käytön välittömästi segmentointia, Einsteiniin perustuvaa personalisointia ja Agentforcen aktivointia varten, mikä mahdollistaa interaktiivisen asiakaskokemuksen istunnossa

Konteksti

Data 360:n pitäminen täysin linjassa CRM-ydinjärjestelmien uusimpien päivitysten kanssa on tärkeää monille liiketoimintaan kriittisille prosesseille. Asiakaspalvelu-, myynti- ja markkinointitiimit ovat riippuvaisia ajankohtaisista tiedoista, jotta he voivat tehdä päätöksiä, käynnistää matkoja ja aktivoida automatisointia. Tämä kuvio tarjoaa mekanismin, jolla voit synkronoida tärkeimpiin Salesforce CRM -objekteihin (kuten Yhteyshenkilö, Tili ja Tapaus) tehtyjä muutoksia Data 360 -palveluun mahdollisimman vähän viiveellä ilman, että useita eräkyselyitä aiheuttaisi tehottomuutta tai viiveitä.

Ongelma

Miten Data 360 voi ylläpitää lähestulkoon täydellistä synkronointia tärkeimpien Salesforce CRM -objektien kanssa varmistaakseen, että myöhemmät analyysit, segmentointi ja tekoälyyn perustuva aktivointi toimivat aina ajankohtaisimmalla saatavilla olevalla datalla?

Voimat

Tämä kuvio esittelee useita teknisiä rajoituksia ja arkkitehtuurissa huomioitavia asioita:

• Tapahtumiin perustuva arkkitehtuuri : Synkronoinnin täytyy olla reaktiivinen — perustuen CRM-lähdeorganisaation muutostapahtumiin eikä säännöllisiin erätöihin.
• Valinnaisten objektien tuki : Kaikki Salesforcen vakiomuotoiset ja mukautetut objektit eivät tue reaaliaikaista suoratoistoa. Arkkitehtien täytyy viitata tuettujen objektien luetteloon suunnittelun aikana välttyäkseen aukkoilta.
• Käyttöoikeudet : Streaming vaatii, että lähdeorganisaation integraatiokäyttäjälle on kohdistettu CRM Streaming -sovelluksen käyttöoikeuksien käyttöoikeus.
• Datan tuoreus vs. Käsittelyn kustannukset : Vaikka lähes reaaliaikainen synkronointi parantaa reagointia, liiallinen tapahtuman läpimeno saattaa vaatia vaakasuoraa skaalaa ja vahvoja virheiden palautusmekanismeja.
• Suojaus- ja luottamuskerrosten integrointi : Kaikkien tapahtumadatan täytyy noudattaa Salesforcen Trust ja suojauksen kehyksiä — salattu siirron aikana, vahvistettu skeeman vaatimustenmukaisuutta varten ja käsitelty organisaation Trust rajoissa.

Ratkaisu

Suosittelemme käyttämään Salesforce CRM -liitintä Streaming (Muuta datan taltiointi) -ominaisuudella. Kun pääkäyttäjät luovat datavirran tuetulle CRM-objektille (esimerkiksi Yhteyshenkilö), he voivat vaihtaa ”Ota striimaus käyttöön” -vaihtoehtoa. Salesforcen Change Data Taltiointi (CDC) -sovellusalusta julkaisee ChangeEvent-viestin joka kerta, kun tietue luodaan, päivitetään, poistetaan tai poistetaan uudelleen lähde CRM-organisaatiossa. Data 360 CRM -liitin tilaa nämä CDC-tapahtumat ja soveltaa niihin liittyviä muutoksia kartoitettuun Data Lake -objektiin (DLO) Data 360:ssa lähes reaaliajassa. Tämä varmistaa jatkuvan synkronoinnin CRM:n ja Data 360:n välillä vähällä manuaalisella toimenpiteellä.

Luonnos

Tämä kaavio kuvaa vaiheiden järjestystä, joilla data tuodaan CRM:stä Data 360:ään nearReal-Time-tilassa

Tässä skenaariossa:

• Muutos tapahtuu Salesforce CRM:ssä (luo/päivitä/poista/poista käytöstä).
• CDC julkaisee ChangeEvent-tapahtuman sisäisessä Salesforce-tapahtumaväylässä.
• Data 360 CRM -liitin tilaa tapahtumaväylän käyttämällä kestävää toistokursoria.
• Tapahtuman tietosisältö vahvistetaan skeeman, käyttöoikeuksien ja datan eheyden osalta.
• Data 360 kirjoittaa vahvistetun tapahtuman kartoitettuun Data Lake -objektiin (DLO).
• Jos tämä asetus on käytössä, kartoitetut datamalliobjektit (DMO) päivitetään nearReal-aikavyöhykkeellä, mikä parantaa segmentointia ja aktivointia.

Tulokset

Data 360 ylläpitää avain CRM-datan jatkuvasti synkronoitua peiliä. Tämä sallii:

• Reaaliaikaiset käynnistimet (esimerkiksi Matka käynnistyy, kun tapaus luodaan).
• Päivitetty segmentointi (esimerkiksi siirtää asiakkaat ”Kulta”-segmenttiin tilin tilan muutoksen yhteydessä).
• Tarkempia analyysejä ja personalisointia live CRM -kontekstin perusteella.

Syöttömekanismit

Tämän kuvion syöttömekanismia hallitaan oletusarvoisesti Salesforce CRM -liittimen kautta, jossa on muutostietojen datan taltiointi (CDC) käytössä. Data 360 toimii CDC-tapahtumaketjun tilaajana, mikä varmistaa luotettavan ja vähäisen viiveen synkronoinnin lähde CRM-organisaation ja Data 360:n välillä.

Virheiden käsittely ja palautus

• Automaattinen vianmääritys: CRM-liitin yrittää automaattisesti uudelleen väliaikaisia verkko- tai sovellusalustan virheitä käyttämällä eksponentiaalista rästityötä ja reitittää pysyvät virheet Dead-Letter-jonoon (DLQ) toistamista varten.
• Skeeman ja todennuksen kestokyky: Skeemojen vastaavuuksien epäjohdonmukaisuudet on karanteenoitu järjestelmänvalvojan tarkastettavaksi kaavion hylkäysjonossa, kun taas todennusvirheet tai käyttöoikeusvirheet käynnistävät hallittuja uudelleenyrityksiä ja hälytyksiä Data 360 Monitoringin kautta.
• Takuutettu tapahtumien jatkuvuus: Kestävä ReplayID varmistaa, että tapahtumat eivät häviä liittimien käyttökatkoksen aikana. Puuttuvat tapahtumat rehydratoidaan toistoikkunoiden tai erien uudelleensynkronointitöiden kautta.
• Datan eheys ja järjestys: Sisäänrakennettu idempotency (RecordID + SequenceNumber) estää identtisyyden ja ChangeEventHeader.sequenceNumber säilyttää tapahtumien oikean järjestyksen jokaiselle CRM-tietueelle.

Idempotent-suunnittelussa huomioitavia asioita

• Tapahtuman yksilöllisyys: Jokainen CDC-tapahtuma sisältää ReplayID- ja ChangeEventHeader.entityName-arvot determinististä kaksoiskappaleen poistamista varten.
• Upsert-strategia: Toteuta UPSERT-logiikkaa tietueen tunnuksen perusteella varmistaaksesi, että toistuvat tapahtumat eivät luo identtisiä tietueita.
• Toisto-oikeus: Käytä liittimen toisto kursoria jatkaaksesi edellisestä sitoutetusta offset-arvosta väliaikaisten virheiden varalta.
• **Skeeman kehitys: **Ylläpidä skeeman versiota tapahtumien metadatassa ja päivitä DLO-kartoitukset, kun CRM-skeemaa muutetaan.

Tietoturvassa huomioitavia asioita

Tietoturva on olennainen osa koko tuontiputkea, aina todennuksesta salaukseen ja käyttöoikeuksien hallintaan.

• Salaus ja Trust : Kaikki tapahtumat lähetetään käyttämällä TLS 1.2+ -protokollaa ja tallennetaan salattuina Data 360:een.
• Käyttöoikeuksien hallinta: Vain todennetut liittimet, joilla on asiaankuuluvat integrointioikeudet, voivat tilata CDC-kanavia.
• Skeeman vahvistus: Jokainen tapahtuman tietosisältö vahvistetaan DLO-skeeman perusteella ennen syöttämistä.
• Suostumuksen propagointi: Suostumusten ja datan luokittelun metadatan kulkuja alempana kunkin tapahtuman kanssa yksityisyyden ja vaatimustenmukaisuuden säilyttämiseksi (GDPR, CCPA).
• Toimintojen hallinta: Tapahtumat kirjataan lokiin, auditoidaan ja valvotaan toistamisen, skeeman hylkäämisen ja läpimäärän poikkeavuuksien varalta Data 360 Trust -kerroksen kautta.

Sivupalkit

Aikavyöhyke

• CDC-tapahtumat käsitellään lähes reaaliajassa — tavallisesti sekunteina CRM-muutoksesta.
• Viive saattaa vaihdella tapahtumien määrän ja liittimen läpimenoasteen mukaan, mutta Data 360 takaa, että tuetut objektit ovat saatavilla minuutteina.

Datamäärät

• Jokainen tapahtuman tietosisältö on kevyt (~1–5 kt).
• Jos objekti sisältää paljon muutoksia, kuten Tapaus tai Yhteyshenkilö, varmista, että läpimenoarvojen rajoitukset vastaavat Salesforce CDC -tapahtumien rajoituksia.

Osavaltioiden hallinta

Jokainen tapahtuma sisältää metadataa osavaltioiden ja versioiden hallintaan:

• Toisto-tunnukset: Käytetään tapahtumien peräkkäiseen palautukseen.
• Skeeman versiointi: Ylläpidä versioiden metadataa hallitaksesi sopimusten muutoksia.
• Idempotency keysit: Kumoa replikointeja uudelleenyrityksistä.
• Offset Commit: Data 360 säilyttää sitoutustilan onnistuneiden tapahtumien jokaisen erän jälkeen.

Monimutkaiset integraatioskenaariot

Tämä kuvio integroituu saumattomasti edistyneisiin yritysarkkitehtuureihin:

• Hybrid (Streaming + Erä): Käytä CDC:tä delta-päivityksille ja joukkotyöille täysiä päivityksiä varten.
• Organisaatioiden välinen striimaus: Useat lähdeorganisaatiot voivat viestiketjua samaan Data 360 -vuokralaiseen, yhtenäistettynä DMO-kartoitusten kautta.
• Agentin aktivointi: Reaaliaikaiset objektin päivitykset käynnistävät Einsteinin tai Agentforcen automatisointeja.
• Tapahtumien reititys: Middleware (esimerkiksi MuleSoft tai Event Relay) voi rikastaa tai reitittää CDC-viestejä ennen syöttämistä.

Esimerkki

Globaali pankki haluaa varmistaa, että Salesforce Sales Cloudin asiakastietojen muutokset heijastuvat välittömästi Data 360 -palveluun.Kun yhteyshenkilön osoite päivitetään Sales Cloudissa, Muuta datan taltiointi -mekanismi julkaisee ContactChangeEvent-tapahtuman.Data 360 CRM -liitin kuluttaa tämän tapahtuman, soveltaa päivitystä Asiakas DLO -objektiin ja päivittää automaattisesti kaikki siihen liittyvät Customer 360 -profiilit. Tämä käynnistää Einstein Next Best Action -toiminnon, joka vahvistaa uuden osoitteen — joka suorittaa palautelyn sekunteina alkuperäisestä CRM-muutoksesta.

Konteksti

Modernit digitaaliset yritykset luottavat reaaliaikaisiin tapahtumien streaming-alustoihin, kuten Amazon Kinesis -datavirtoihin ja Amazon MSK (Managed Streaming for Apache Kafka) sieppaamaan jatkuvia datakulkuja jaetuista sovelluksista, IoT-laitteista ja transaktiojärjestelmistä. Data 360 sallii suoran tuonnin näistä sovellusalustoista ensimmäisen osapuolen natiiviliittimien kautta — jolloin sinun ei tarvitse käyttää mukautettuja ETL- tai middleware-pohjaisia ratkaisuja. Tämä kuvio on suunniteltu tehokäyttöön, vähäisen viiveen datan tuontiin, lähes reaaliaikaisiin havaintoihin, personalisointiin ja tekoälyyn perustuvaan aktivointiin.

Ongelma

Miten yritys voi yhdistää Data 360:n AWS Kinesis- tai AWS MSK Kafka -aiheisiin turvallisesti ja tehokkaasti tuodakseen rakenteellisia tapahtumatietoja ja profiilitietoja jatkuvasti, mikä varmistaa skeeman vaatimustenmukaisuuden, skaalattavuuden ja hallinnan?

Voimat

Tämä kuvio esittelee useita arkkitehtonisia ja toiminnallisia huomioitavia asioita:

• Natiivi-liittimen saatavuus: Salesforce tarjoaa yleisesti saatavilla olevat natiiviliittimet sekä Amazon Kinesisille että Amazon MSK:lle. Nämä liittimet tarjoavat ensimmäisen osapuolen tuen ja välttävät mukautettujen API-pohjaisten myyntiputkien tarvetta.
• Todennus ja tietoturva: Jokainen liitin vaatii AWS-tason todennuksen.
• Kinesis käyttää tässä tapauksessa AWS-käyttöoikeusavainta ja salaista avainta, joita IAM-käytännöt hallitsevat.
• MSK:lle todennus voidaan määrittää Access Key/Secret- tai OpenID Connect (OIDC) -ratkaisun kautta.
• Skeeman määritelmä: Data 360 vaatii skeeman tulkitakseen streaming-hyötykuormaa. Kun käytät Kinesisia, skeematiedosto ladataan palvelimelle yhteyden määrittämisen aikana, mikä määrittää tapahtumarakenteen ja kenttäkartoitukset.
• Kokoonpanon lähde:
• Kinesis-liitin tilaa tietyn Kinesis-viestiketjun nimen.
• MSK-liitin tilaa Kafka-aiheen MSK-klusterissa.
• Verkon käyttöoikeus: Suojattujen ympäristöjen liittimet voidaan määrittää PrivateLink- tai VPC-reitityksellä, jotta julkisen internetin kautta ei pääse dataa.
• Toimintojen hallinta: Streaming throughput-, skeeman vahvistus- ja todennustapahtumia valvotaan Data 360 Trust -kerroksessa, mikä varmistaa vaatimustenmukaisuuden ja jäljitettävyyden.

Ratkaisu

Ratkaisu hyödyntää natiiviä Amazon Kinesis- tai Amazon MSK -liitintä Data 360:ssa.

Luonnos

Tämä kaavio kuvaa vaiheiden järjestystä, joilla data tuodaan tapahtumalustoilta, kuten Kafka ja Kinesis, Data 360:ään lähellä reaaliaikaa

Tässä skenaariossa:

• Sovellukset tai laitteet julkaistavat tapahtumia Kinesis-viestiketjuun tai MSK-aiheeseen.
• Data 360 -liitin todentaa itsensä AWS-tunnuksilla tai OIDC-valtuudella.
• Liitin kyselee tai tilaa viestiketjun jatkuvasti.
• Tapahtumat vaihdetaan, vahvistetaan skeemalle ja käytännölle ja sitoutetaan sitten Data Lake -objektiin (DLO).
• Jos datamalliobjektit on kartoitettu, ne päivitetään lähes reaaliajassa aktivointia varten.
• Valvakerros seuraa tilastoja, skeemojen hylkäämiä ja viiveitä.

Tulokset

Jatkuva, vähäisen viiveen tuonti rakenteellisesta datasta suoraan AWS Kinesis- tai MSK-palvelusta Data 360 -palveluun. Data on välittömästi käytettävissä:

• Identiteetin vahvistus
• Reaaliaikainen segmentointi
• Einsteinin tekoälyn aktivointi
• Agentforcen määrittämät käynnistimet Estää riippuvuuden eräETL:stä ja ottaa käyttöön viestiketjuihin perustuvat arkkitehtuurit, jotka on linjattu enterprise-tapahtumiin perustuviin rakenteisiin.

Syöttömekanismit

Virheiden käsittely ja palautus

• Automaattiset uudelleenyritykset: Liittimet yrittävät uudelleen väliaikaisia verkko- tai sovellusalustan virheitä eksponenttisella rästityksellä.
• Skeeman hylkäämiset: Virheelliset hyötykuormat reititetään skeeman hylkäysjonoon pääkäyttäjän tarkastusta varten.
• DLQ-toisto: Pysyvät virheet tallennetaan kuolleiden kirjaimien jonoihin uudelleenkäsittelyä varten.
• Identiteetin hallinta: Tapahtumien avaimet tai järjestysnumerot varmistavat identtisten tietueiden poistamisen ja järjestetyn tuonnin.
• Monitoring-integraatio: Kaikki virheet, uudelleenyritykset ja läpimenointitilastot näytetään Data 360 Monitoring -mittaristoissa.

Idempotent-suunnittelussa huomioitavia asioita

• Tapahtumien yksilöllisyys ja seuranta: Jokaiselle tapahtumalle kohdistetaan deterministinen yksilöllinen avain (esimerkiksi PartitionKey + SequenceNumber for Kinesis tai Topic + Partition + Offset for MSK) varmistaakseen tarkan kerran syötettävän avaimen.
• Liittimen tarkastuspisteytys: Data 360 -liittimet säilyttävät viimeksi käsitellyn offset- tai järjestysnumeron jatkaakseen tuontia turvallisesti virheiden tai uudelleenkäyntien jälkeen.
• Deduktoinnin poistaminen ja UPSERT-logiikka: DLO-kutsujen aikana identtiset tapahtumat havaitaan ja ohitetaan. Kelvolliset tietueet lisätään käyttämällä yksilöllistä avainta yhdenmukaisuuden ylläpitämiseksi.
• Toisto ja palautuksen hallinta: Epäonnistuneet tai viivästyneet tapahtumat toistetaan tallennetuista offset-muuttujista Dead-Letter- ja Replay-jonojen kautta, mikä varmistaa luotettavan palautuksen ilman identtisiä tietueita.

Tietoturvassa huomioitavia asioita

Tietoturva on olennainen osa koko tuontiputkea, aina todennuksesta salaukseen ja käyttöoikeuksien hallintaan.

• Todennus: Suojele tunnusten vaihtoa AWS IAM -käytännöillä tai OIDC:llä.
• Salaus: Data 360:n siirron aikana (TLS 1.2+) ja tilassa (AES-256) salattu data.
• Käyttöoikeuksien hallinta: Vähiten etuoikeutettuja rooleja käytössä; liittimet, jotka on rajoitettu tiettyihin viestiketjuihin/aiheisiin.
• Hallinta: Periytymisen ja luokittelun metadataa sovelletaan kaikkiin tietueisiin täydellisen jäljitettävyyden takaamiseksi.
• Verkon suojaus: Ota halutessasi käyttöön yksityisissä aliverkeissä AWS PrivateLinkin avulla.

Sivupalkit

Aikavyöhyke

• Lähes reaaliaikainen käsittely: CDC ja streaming-liittimet käsittelevät tapahtumia sekunteina lähteen muutoksista, mikä tavallisesti varmistaa datan tuoreuden minuutteina.
• Deterministinen viive: Päättymisviive riippuu lähteen läpimäärästä, tapahtumien erästä ja verkkoehdoista, mutta Data 360 takaa ennustettavan palvelutasosopimukseen perustuvan viiveen tuetuille objekteille.
• Elastic Scaling: Syöttöputki skaalataan automaattisesti suurella tapahtuman määrällä, mikä säilyttää ajantasaisuuden jopa datan ruuhka-aikojen aikana.
• Toiminnallinen näkyvyys: Valvontamittaristot paljastavat tapahtumien viiveen, sitoumuksen aikaleimat ja toistotilan viiveen vahvistamista ja vianmääritystä varten.

Datamäärät

• Vähäiset hyötykuormat: Yksittäiset CDC- tai streaming-tapahtumat ovat kompakteja (1–5 kt tyypillistä kokoa), ja ne on optimoitu yleisiä päivityksiä varten.
• Korkea muutos -objektit: Jos kyseessä on haihtuva entiteetti (esimerkiksi tapaus, yhteyshenkilö, tilaus), arkkitehtien täytyy varmistaa, että CDC-rajoitukset ja tapahtumien läpimeno vastaavat odotettuja päivityssuhteita.
• Yhdensuuntaiset viestiketjut: Data 360 tukee usean viestiketjun syöttämistä vaakasuoralle skaalautumiselle suurissa objekteissa tai useissa lähdeorganisaatioissa.
• Vastapaineen käsittely: Sisäänrakennetut rajoitusmekanismit ylläpitävät syötteen vakautta kuormituksen ollessa ilman tapahtumia.

Osavaltioiden hallinta

Jokainen tapahtuma sisältää metadataa osavaltioiden ja versioiden hallintaan:

• Toisto- ja offset-seuranta: Jokainen tapahtuma sisältää toistotunnuksen ja järjestyksen metadatan, mikä mahdollistaa tilatun toimituksen ja tarkastuspisteisiin perustuvan palautuksen.
• Skeeman versiointi: Tapahtumien otsakkeiden versioiden tunnisteet varmistavat, että niiden käsittely on yhteensopivaa lähdeskeemojen kanssa.
• Idempotency keysit: Jokainen tapahtuma sisältää yksilöllisen transaktio- tai sitoutusavaimen, jotta Data 360 voi poistaa identtisyyksiä ja uudelleenkäynnistyksiä turvallisesti.
• Atomic Commit: Syöttöputki merkitsee offset-objektit valmiiksi vasta, kun DLO-objektien alempien sitoumusten onnistuminen varmistaa yhdenmukaisuuden.

Monimutkaiset integraatioskenaariot

Tämä kuvio integroituu saumattomasti edistyneisiin yritysarkkitehtuureihin:

• Hybridien syöttö: Yhdistä asteittaisten delta-arvojen CDC ja joukkodatavirrat täydellisiin päivityksiin, mikä säilyttää tuoreuden ja täydellisyyden.
• Organisaatioiden välinen striimaus: Useat CRM- tai ERP-organisaatiot voivat julkaista samalle Data 360 -vuokralaiselle, yhtenäistettynä DMO-kartoituksen ja ontologian tasauksen kautta.
• Tapahtuman rikastaminen: Middleware (esimerkiksi MuleSoft, Event Relay) voi rikastaa, suodattaa tai reitittää streaming-dataa ennen kuin se saavuttaa Data 360:n.
• AI ja agenttien aktivointi: Reaaliaikaiset päivitykset käynnistävät myöhemmän automatisoinnin, kuten Einstein tai Agentforce, sekunteina alkuperäisestä tapahtumasta.

Esimerkki

Globaali vähittäismyyntiyritys käyttää AWS Kinesisia virtaamaan myyntipiste- ja verkkotoimintojen dataa.Data 360:n Kinesis-liitin todentaa IAM-tunnuksilla ja tuo tapahtumia jatkuvasti transaktio-DLO:hen.Jokainen tietue vahvistetaan skeemalla, rikastetaan metadatalla ja levitetään välittömästi Asiakas DMO:hen.Sekunneissa Einstein AI -mallit päivittävät asiakassegmenttejä ja Agentforce käynnistää reaaliaikaisia Next-Best-off-suosituksia — saavuttamalla täysin tapahtumiin perustuvan personalisoinnin silmukan.

Zero Copy on muutakin kuin integraatiomenetelmä — se on perustavaa laatua oleva muutos yritystietojen liikkeessä tai pikemminkin ei liikkeessä. Datan integrointi vaati perinteisesti suurten tietueiden kopioimista ETL-myyntiputkien kautta, tarpeettomien datasäiliöiden luomista, synkronoinnin viiveitä ja hallintakysymyksiä. Nollan kopiointi poistaa kaiken tämän. Tässä mallissa Data 360 muodostaa yhteyden suoraan ulkoisiin datalustoihin, kuten Snowflake ja Databricks, lukeakseen ja aktivoidakseen tietoja turvallisesti — siirtämättä niitä tai kopioimatta niitä. Tuloksena on saumaton silta yrityksesi datan järven ja Salesforce-ekosysteemisi välillä, mikä tarjoaa välittömän pääsyn, vähentää liiketoimintakulutusta ja parantaa datan hallintaa.

Saapuvien nollan kopiointiominaisuuksien avulla Data 360 voi kysellä ja yhdenmukaistaa Snowflakessa tai Databricksissa säilytettyä ulkoista dataa lähteessä — kuten asiakasprofiileja, transaktioita tai tuotetietoja. Data 360 luo tiedostojen tuonnin sijaan turvallisen, metadatan tunnistavan yhteyden, joka hyödyntää ulkoisessa varastossa olevia skeemojen määritelmiä ja suojauskäytäntöjä.

• Suora liitos: Data 360 lukee paikallista dataa turvallisten ja optimoitujen kyselyiden avulla ilman replikointia.
• Yhtenäistetty hallinta: Data pysyy lähdejärjestelmän tietoturvan, käyttöoikeuksien hallinnan ja vaatimustenmukaisuuden puitteissa.
• Toimintatehokkuus: Estää ETL:n päällekkäisyyden ja tallennustilan päällekkäisyyden, mikä vähentää kustannuksia ja monimutkaisuutta.
• Reaaliaikainen valmius: Ottaa käyttöön tarvittaessa tapahtuvan harmonisoinnin — kun data päivitetään Snowflakessa, se on välittömästi käytettävissä Data 360 -aktivointia varten.

Konteksti

Nykyaikaiset dataan perustuvat yritykset hallitsevat asiakkaiden, transaktioiden ja telemetristen tietojen petatavua pilvitason datan lakehouse-alustoilla, kuten Snowflake ja Databricks. Nämä ympäristöt toimivat yksittäisenä totuuden lähteenä analyyseille, tekoälylle ja vaatimustenmukaisuudelle. Data 360 esittelee Zero CopyData Federationin, joka sallii Data 360:n kysellä ja käyttää ulkoisia datajoukkoja suoraan paikan päällä — kopioimatta, muuntaamatta tai tallentamatta tarpeettomia tietoja. Tämä kuvio sallii organisaatioiden laajentaa Customer 360 -materiaalia olemassa olevaan datan varastoon tai lakehouse-infrastruktuuriin – saavuttamalla reaaliaikaisen yhtenäistämisen ja aktivoinnin, jossa ei ole identtisiä tietueita, ei myöhästymistä ja ei hallintaa.

Ongelma

Miten yritykset voivat hyödyntää muotoiltuja datajoukkoja, jotka on jo kerätty Snowflakessa, Databricksissa tai avoimen järven formaateissa, kuten Apache Icebergissa — segmentointiin, identiteettien ratkaisemiseen ja aktivointiin Data 360:ssa — ilman ETL-putkien tai fyysisen datan siirron kustannuksia, viiveitä ja hallintakustannuksia?

Voimat

Tämä kuvio esittelee useita arkkitehtuurissa, tietoturvassa ja suorituskyvyssä huomioitavia asioita:

Verkostot ja tietoturva

• Data 360:n täytyy muodostaa turvallinen ja yksityinen yhteys ulkoiseen varastoon tai järvitarhaan.
• Tavallisesti määritetty käyttämällä Salesforce Private Connectia tai PrivateLink/VPC Peeringia, jotta liikenne ei koskaan poistu asiakkaan hallitsemasta verkosta.
• Ulkoisten järjestelmien täytyy sallia Data 360 IP -osoitteet ja käyttää TLS 1.2+ -salausta.

Todennus ja käyttöoikeuksien hallinta

• Tukee avainparin todennusta, OAuth 2.0 -todennusta tai henkilöllisyydentarjoajaan (IdP) perustuvaa Trust (Data 360 toimii luotettuna asiakassovelluksena)
• Ulkoisessa järjestelmässä rooleihin perustuva käyttöoikeuden hallinta (RBAC) pakottaa vähiten käyttöoikeuksia kyselyn suorittamiseen.

Suorituskyvyn ja laskutoimien sidonnaisuus

• Kyselyiden yhdistäminen siirtää SQL-suorituksen alas Snowflakeen tai Databricksiin hyödyntämällä niiden laskentaklustereita.
• Suorituskyky- ja kustannusasteikko ulkoisen kyselyn latauksella — segmentoinnin viive ja kustannus on sidoksissa ulkoiseen laskentakokoonpanoon.

Kehittyvät standardit: Tiedoston yhdyskäyttö

• Seuraavan sukupolven tiedostojen yhdyskäyttö -malli hyödyntää avoimia taulukkomuotoja, kuten Apache Iceberg tai Delta Lake, jolloin Data 360 voidaan lukea suoraan objektin tallennustilasta (esimerkiksi Amazon S3, Azure ADLS, Google Cloud Storage).
• Tiedostojen yhdyskäyttö ohittaa lähdekohtaisen laskentakerroksen ja vähentää lukemattomien analyyttisten työkuormien viiveitä ja kustannuksia merkittävästi, mutta säilyttää skeeman eheyden.

Hallinta ja vaatimustenmukaisuus

• Data ei koskaan poistu lähdealustasta — vaatimustenmukaisuus-, salaus- ja säilytyskäytännöt pysyvät käytössä alkuperässä.
• Kaikki metadata-, sukupolvi- ja suostumusattribuutit leviävät Data 360:n Trust varmistaakseen lopputuloksen jäljitettävyyden.

Ratkaisu

Suosittelemme käyttämään natiivisia Zero Copy -liittimitä Snowflake-, Databricks- tai Data 360 -tiedostojen yhdyskäyttöön.

Luonnos

Seuraava kaavio osoittaa, miten voit määrittää nollan kopioinnin yhteyden ja luoda ulkoisia DLO-objekteja Data 360:ssa.

Tässä skenaariossa:

• Pääkäyttäjä määrittää Zero Copy -yhteyden Data 360 -määritykset-valikosta (Snowflake, Databricks tai tiedostojen yhdyskäyttö).
• Suojattu todennus ja verkko-reititys on määritetty (Private Connect / OAuth / Key Pair).
• Pääkäyttäjä luo datavirran, joka valitsee ulkoisen lähteen — joka selaa live-tietokantoja, skeemoja ja taulukoita.
• Data 360 luo datan kopioinnin sijaan ulkoisen DLO-objektin (Data Lake -objekti) — metadata-osoittimen, joka viittaa live-taulukkoon tai Iceberg-tiedostoon.
• Ulkoiset DLO-objektit kartoitetaan Customer 360 -entiteetteihin (esimerkiksi Asiakas, Maksutapahtuma, Tuote).
• Data 360 kyselee paikallista lähdettä segmentoinnin, aktivoinnin tai havaintojen laskennan aikana.
• Kaikki käyttöoikeudet, kyselyiden sukupolvi ja metadata tarkastetaan Data 360 Trust -kerroksessa.

Tulokset

• Ulkoinen data säilyy Snowflakessa, Databricksissa tai S3:ssa — ei ETL:ää, ei identtisiä tietueita tai ylimääräistä tallennustilaa.
• Data 360 saa reaaliaikaisen, luku-aikaisen pääsyn yritystason dataan identiteettien ratkaisemista, laskettuja havaintoja ja aktivointia varten.
• Organisaatiot hallitsevat hallinta-, salaus- ja vaatimustenmukaisuuskehystään täysin.
• Tämä kuvio ottaa käyttöön todellisen Zero Copy -arkkitehtuurin — joka yhdistää paikallisen käytön suorituskyvyn yhdistetyn tallennustilan hallintaan.

Puheluiden mekanismit

Kutsumekanismi riippuu tämän kuvion toteuttamiseen valitusta ratkaisusta.

Virheiden käsittely ja palautus

• Automaattinen uudelleenyritys ja kyselyiden rästityöt: Väliaikaisen yhteyden tai kyselyn aikakatkaisut käynnistyvät automaattisesti uudelleen käyttämällä eksponenttista rästityötä.
• Skeeman vastaavuuden eristys: Lähdeskeeman muutokset (esimerkiksi uudet sarakkeet) kirjataan kaavion hylkäysjonoon. Pääkäyttäjät voivat muokata tai päivittää kaavion metadataa.
• Todennusvirheytys: Jos tunnukset vanhenevat, Data 360 yrittää muodostaa yhteyden uudelleen käyttämällä tallennettuja päivitysvaltuuksia tai avainten kierrätyskäytäntöjä.
• Laske saatavuuden tunnistus: Jos Snowflake- tai Databricks-klusterit keskeytetään, Data 360 keskeyttää yhdistämistyöt ja yrittää uudelleen, kun laskenta jatkuu.
• Monitoring-integraatio: Kaikki yhteyden kunto, kyselyiden viive ja linjan metadata näkyvissä Data 360 Monitoring -mittaristoissa.

Idempotent-suunnittelussa huomioitavia asioita

• Kyselyn deterministisyys: Yhdistetyt kyselyt käyttävät yhdenmukaista tilannekuvan semanttiikkaa varmistaakseen vakaan ja toistettavan lukeman segmentoinnin tai aktivoinnin aikana.
• Ulkoinen DLO-versiointi: Jokainen yhdistetty kysely sisältää skeeman ja aikaleiman metadataa linjan seuraamista varten.
• Offset-free-käyttöoikeus: Koska Zero Copy on Vain luku -muotoinen, se ei luota tapahtumien korvauksiin — yhdenmukaisuutta noudatetaan ulkoisen järjestelmän ACID-takuiden kautta (Snowflake/Delta Lake).
• Skeeman käynnistyksen hallinta: Ylläpidä versioituja skeemakartoituksia Data 360:ssa ja päivitä ulkoisen DLO:n metadata lähteen evoluution yhteydessä.

Tietoturvassa huomioitavia asioita

Tietoturva on olennainen osa yhdistämismallia, joten se ei vaaranna Trustia tai vaatimustenmukaisuutta.

• Salaus: Kaikki tietojenvaihdot käyttävät TLS 1.2+ -protokollaa. Ulkoiset varastot salaavat tilan AES-256-protokollalla.
• Käyttöoikeuksien hallinta: Ulkoisia taulukoita käytetään vähiten käyttöoikeuksia käyttävillä rooleilla, joilla on Vain luku -oikeudet.
• Verkon eristys: Private Connect- tai VPC-reitit estävät julkisten päätepisteiden käytön.
• Hallittu datakulku: Periytymisen, suostumuksen ja luokittelun metadatan kulku Data 360 Trust -kerrokseen käytäntöjen noudattamista varten.
• Auditointi: Jokainen yhdistetty kysely ja skeeman käyttöoikeustapahtuma kirjataan lokiin vaatimustenmukaisuuden seuraamista varten (GDPR, CCPA, HIPAA).

Sivupalkit

Aikavyöhyke

• Kyselyt suoritetaan suoraan ulkoiselle varastolle tai tallennustilaan, jotta uusimmat tiedot ovat näkyvissä reaaliajassa.
• Segmentointi- tai aktivointisuoritukset vastaavat Snowflake-, Databricks- tai S3-tuettujen Iceberg-taulukoiden toistuvia muutoksia.
• Kyselyn viive riippuu lähdejärjestelmän suorituskykytasosta — tavallisesti sekunteista kymmeniin sekunteihin per kysely.
• Soveltuu erinomaisesti analyyttisille ja tekoälytyökaluille, jotka vaativat ”uutta, ei kopioitua” datan käyttöoikeutta.

Datamäärät

• Tukee petatavuisia datajoukkoja, joita säilytetään oletusarvoisesti Snowflakessa tai Databricksissa ilman replikointia.
• Data 360 noutaa vain tuloksia — ei raakadatajoukkoja — mikä minimoi verkko- ja laskentakustannukset.
• Tiedostojen yhdyskäyttö optimoi suuret analyyttiset skannaukset osioiden ja sarakkeiden tiivistämisen avulla.
• Skaalaa lineaarisesti varaston laskentakapasiteetilla ja Data 360:n yhdistetyn kyselyn orkestrointikerroksella.

Osavaltioiden hallinta

• Ulkoiset DLO-objektit säilyttävät yhteyden, skeeman ja version metadatan Data 360:ssa.
• Skeeman evoluutiota hallitaan automaattisesti metadatan päivitysjaksojen kautta.
• Kyselyn linja sisältää aikaleimat, käyttäjän identiteetin ja suoritusmittarit seurattavaksi.
• Tilaisia syötteitä tai kompensointeja ei säilytetä — yhdenmukaisuus peritään ulkoisen lähteen happojen takuista.

Monimutkaiset integraatioskenaariot

• Hybriditila: Yhdistä Zero Copy (live-liitokselle) ja syöttö (historiallisille datajoukoille).
• Kauppojen välinen käyttöoikeus: Data 360 voi yhdistää useita Snowflake- tai Databricks-vuokralaisia yhteen organisaatioon.
• AI/BI-yhteensopivuus: Ulkoiset järjestelmät (esimerkiksi SageMaker, Tableau, Power BI) voivat kysellä Data 360:n rikastettuja profiileja takaisin käänteisen Zero Copyn kautta.
• Tiedostojen yhdyskäyttötiedosto: Open Lake -formaatteja (Iceberg/Delta) käyttävät yritykset voivat yhdistää rakenteellista ja jäsentämätöntä dataa yhdessä yhdistetyssä mallissa.

Esimerkki

Globaali finanssisopimus tallentaa kaikki transaktio- ja vuorovaikutustiedot Snowflakeen, mutta ylläpitää asiakasattribuutteja ja markkinointitapahtumia Data 360:ssa. Käyttämällä Zero Copy Data Federationia, Data 360 muodostaa turvallisen yhteyden Snowflakeen Private Connectin kautta.Kun segmentointityö suoritetaan, esimerkiksi ”Asiakkaat, joilla on kulunut yli 10 000 dollaria edellisen 30 päivän aikana, Data 360 siirtää kyselyn alas Snowflakeen, noutaa aggregoidut tulokset ja aktivoi kyseiset profiilit välittömästi Journey Builderissa. Replikointia tai ETL:ää ei tarvita. Tämä esimerkki käyttää reaaliaikaista yhdistettyä älyä, joka on yhtenäistetty koko yritystietojen ekosysteemissä.

Lähtevä nollakopio laajentaa samaa periaatetta päinvastaisessa muodossa. Sen sijaan, että datajoukkoja viedään tai kopioitaisiin Data 360:sta, ulkoiset järjestelmät, kuten Snowflake, voivat kysellä Data 360:a suoraan ja käsitellä sitä yhdistettynä Älykkäät asiakastiedot -lähteenä.

• Käänteinen liitos: Ulkoiset analyysit tai tekoälysovellusalustat voivat käyttää Data 360:n yhtenäistettyjä profiilitietoja keräämättä niitä.
• Datan aktivointi lähteessä: Liiketoimintatiimit voivat hyödyntää havaintoja, joissa data on jo — olipa kyseessä sitten tekoälymallinnus, raportointi tai asiakkaan personalisointi.
• Latency-free-yhteensopivuus: Erätöitä ei viedä tai synkronoida töitä. Havainnot kulkevat välittömästi sovellusalustojen välillä.
• Yhtenäinen semantti: Koska molemmilla järjestelmillä on sama ontologia ja skeemakartoitukset, konteksti ja merkitys säilytetään ekosysteemeissä. Nollakopiointi määrittää Data 360:n roolin uudelleen datasäilöstä semantiseksi aktivointivakerrokseksi. Sen avulla organisaatiot voivat säilyttää dataa tarkalleen siellä, missä se kuuluu — hallituissa ja tehokkaissa varastoissa — samalla kun se avaa koko arvonsa Salesforcen Trust rajoissa. Tämä kuvio noudattaa nykyaikaista datan verkkoa ja tekoälyn alkuperäisiä arkkitehtuuria: data pysyy hajautettuna, mutta älykkyys yhtenäistyy. Arkkitehtit voivat nyt rakentaa aktivointiputkia, jotka ovat nopeampia, ohuempia ja vaatimustenmukaisempia — kopiointia ei tarvita.

Konteksti

Nykyiset yritykset toimivat yhä useammin usean sovellusalustan datajärjestelmissä, joissa Salesforce Data 360 tukee yhtenäistettyjä asiakasprofiileja ja aktivointia, kun taas yritystietovarastot, kuten Snowflake tai Databricks, toimivat analyyttisinä selkärankaina datatieteelle, koneoppimiselle ja BI-työkuormille. Salesforce Data 360:n Zero Copy -lähtevä jakaminen -ominaisuus luo sillan näihin ympäristöihin saumattomasti — mikä sallii hallitun, suojatun ja reaaliaikaisen pääsyn harmonisoituun Data 360 -dataan suoraan Snowflakessa tai Databricksissa ilman replikointia tai ETL:ää. Tämä sallii analyytikkojen ja datatieteilijöiden kysellä, visualisoida ja mallinntaa samaa live-dataa, joka tukee markkinointia, myyntiä ja palvelun aktivointia.

Ongelma

Miten yritys voi paljastaa Data 360:n yhtenäistettyjä asiakasprofiileja ja laskettuja tilastoja (esimerkiksi elinkaaren arvo, vaihteen riski) turvallisesti ja tehokkaasti ulkoisiin analyysijärjestelmiin kopioimatta dataa, rikkomatta hallintaa tai ottamatta käyttöön viiveitä perinteisten käänteisten ETL-myyntiputkien avulla?

Voimat

Tämä kuvio esittelee useita arkkitehtuurissa, hallinnassa ja toiminnassa huomioitavia asioita:

• Hallittu tietoturva: Data 360 -datan käyttöoikeuksien täytyy olla hallittuja, tarkkoja ja tarkastettavissa. Zero Copy -jakaminen käyttää selkeää objektitason käyttöoikeutta, mikä varmistaa, että vain hyväksytyt datamalliobjektit (DMO) ja lasketut havainto-objektit (CIO) ovat määritettyjen kuluttajien käytettävissä.
• Objektin selkeä valinta: Pääkäyttäjät keräävät jaettavaa dataa datan jakamisen kautta ja valitsevat selkeästi näytettävät objektit. Tämä ylläpitää hallintaa ja minimoi riskien altistumisen.
• Kaksivälinen kokoonpano: Data 360 ja ulkoinen varasto vaativat määritystoimia. Data 360 määrittää datan jakotavoitteen (Snowflake/Databricks), kun taas vastaanottavan järjestelmän täytyy hyväksyä ja luoda jakotavoite.
• Kyselyn yhdistämismalli: Kun ulkoinen alusta on hyväksytty, se lähettää live-kyselyitä, jotka hallitsevat Data 360 -dataa yhdistettyjen näkymien kautta, mikä estää noutotyöt tai manuaaliset päivitysjaksot.
• Avoimien standardien kehitys: Uusimmat lähestymistavat, kuten tiedostojen yhdyskäyttö, hyödyntävät avoimien taulukoiden muotoja (esimerkiksi Apache Iceberg) salliakseen Vain luku -käyttöoikeuden tallennustasoilla — mikä parantaa skaalattavuutta, suorituskykyä ja yhteentoimivuutta usean pilvitason arkkitehtuurien välillä.

Ratkaisu

Tämä ratkaisu hyödyntää Salesforce Data 360:n natiivista nollakopiointikäytäntöä datalustojen kanssa, kuten Snowflake tai Databricks.

Luonnos

Seuraava kaavio kuvaa kutsun Salesforce Data 360:sta ulkoiseen Data Platformiin.

Tässä skenaariossa:

• Data 360 -pääkäyttäjä määrittää datan jakamisen, mukaan lukien yhtenäistetty asiakas- ja laskettu havainto -objektit.
• Datan jakotavoite (Snowflake tai Databricks-tili) on rekisteröity suojatuilla tunnuksilla ja hallintakäytännöillä.
• Data 360 julkaisee jaon. Snowflake/Databricks-pääkäyttäjät hyväksyvät sen.
• Jaetut tiedot näytetään varastossa suojattuina Vain luku -taulukoina.
• Analyytikot, BI-työkalut tai ML-putket kyselevät live-asiakastietoja kopioimatta tai synkronoimatta niitä.
• Kaikki käyttöoikeudet tarkastetaan Data 360 Trust Layer -kerroksessa ja varaston hallintalokeissa.

Tulokset

• Ulkoiset varastot saavat reaaliaikaisen ja kyseltavan pääsyn harmonisoituun Data 360 -dataan.
• Estää käänteiset ETL-putket, mikä vähentää toiminnallista kuormitusta ja viiveitä.
• Ottaa käyttöön tekoälyn/ML-koulutuksen, ennakoivan mallinnuksen ja edistyneen BI:n suoraan yhtenäistetylle datalle.
• Ylläpitää nollan identtisyyden, vahvan hallinnan ja suojatun käyttöoikeuden suunnitteluun.
• Suorittaa kaksisuuntaisen Zero Copy -silmukan, jossa saapuva liittäminen ja lähtevä jakaminen toimivat yhdessä yhden hallintamallin alla.

Puheluiden mekanismit

Kutsumekanismi riippuu tämän kuvion toteuttamiseen valitusta ratkaisusta.

Virheiden käsittely ja palautus

• Yhteys uudelleen: Automatisoituja uudelleenyrityksiä väliaikaisille yhteys- tai todennusvirheille Data 360:n ja varaston välillä.
• Jaon vahvistus: Virheelliset tai valtuuttamattomat jako-kokoonpanot karanteenoidaan pääkäyttäjän tarkastusjonossa.
• Synkronoinnin terveysvalvonta: Data 360 näyttää live-jaon tilan, kyselyiden viiveen ja käyttöoikeuslokit Valvonta-mittaristojen kautta.
• Käyttöoikeuden kumoaminen: Pääkäyttäjät voivat kumota jakoja välittömästi ja poistaa käyttöoikeuden molemmilta puolilta ilman jäljellä olevia datakopioita.
• Hallittu kirjausketju: Kaikki kokoonpano- ja käyttöoikeusmuutokset kirjataan lokiin vaatimustenmukaisuuden vahvistamista varten.

Idempotent-suunnittelussa huomioitavia asioita

• Yhtenäinen osuuden tunnistus: Jokaisella datan jakamisen ja datan jakamisen tavoitteen parilla on yksilöllinen tunniste, joka varmistaa tarkan hallinnan ja käyttöoikeuksien jäljitettävyyden.
• Muuttamattomat näkymät: Jaetut dataobjektit ovat Vain luku -muotoisia. Kuluttajat eivät voi muuttaa tilaa, mikä varmistaa deterministisiä tuloksia ja vaatimustenmukaisuutta.
• Atomisen jaon elinkaari: Jakaaminen, kumoaminen ja päivittäminen ovat atomitoimintoja — joko täysin suoritettuja tai peruutettuja.
• Toista yhdenmukaisuus: Kun Data 360 -data päivitetään, varasto-puoliset kyselyt palauttavat aina uusimman yhdenmukaisen tilannekuvan, mikä välttää vanhentuneet lukemat.

Tietoturvassa huomioitavia asioita

Tietoturva perustuu nollakopioinnin jakamisen kaikkiin osa-alueisiin:

• Todennus: Yhteinen Trust luotu OAuth 2.0:lla, yksityisellä avaimella vaihdolla tai identiteettien yhdistämisellä (OIDC).
• Salaus: Siirrettäessä (TLS 1.2+) ja levossa (AES-256) salattu data.
• Käyttöoikeuksien hallinta: Objektitason käyttöoikeudet vaativat vähiten käyttöoikeuksia, joita hallitsee Data 360 Trust -kerros.
• Verkon tietoturva: Tietojen vaihto tapahtuu yksityisten verkkolinkkien kautta, kuten Salesforce Private Connect tai Secure Data Exchange API -rajapintojen kautta.
• Governance-metadata: Jokainen jaettu objekti sisältää periytymisen, luokittelun ja suostumusattribuutteja, jotta se on täysin jäljitettävissä ja säännösten mukainen.

Sivupalkit

Aikavyöhyke

• Reaaliaikainen saatavuus: Jaettu data vastaa Data 360:n ajankohtaista tilaa ilman replikoinnin viiveitä.
• Kyselyn tuoreus: DMO-organisaatioiden tai johtajien muutokset leviävät välittömästi jaettuihin varastonäkymiin.
• Suorituskyvyn elastisuus: Kyselyiden ponnahdusikkuna sopeutuu dynaamisesti varaston laskentaresursseihin.
• Valvonta: Live-mittaristot paljastavat jaettuja viive- ja kyselyiden suorituskykytilastoja toiminnan vahvistamiseksi.

Datamäärät

• ** Skaalattava jakaminen:** Tukee tarkkaa objektitason tai koko toimialueen datan jakamista analyyttisten tarpeiden mukaan.
• Optimoitu kyselyiden suorituskyky: Snowflake/Databricks tallentaa jaetut tiedot välimuistiin älykkäästi viiveen minimoimiseksi.
• Säiliötehokkuus: Nollan identtisyys välttää tarpeettomat tallennuskulut.
• Tiedoston yhdyskäyttö: Petatavuisia datajoukkoja varten suora Iceberg-pohjainen jakaminen ohittaa laskutoimet ja nopeuttaa käyttöä.

Osavaltioiden hallinta

• Skeeman kehitys: Version ohjaamat skeemat varmistavat yhteensopivuuden, kun Data 360 -malli kehittyy.
• Käyttöoikeuden tilan seuranta: Active/inactive-jaon tilat, joita säilytetään Data 360:ssa elinkaaren hallintaa varten.
• Metadatan synkronointi: Jaettujen objektien määritelmien päivitykset näytetään automaattisesti myöhemmissä varaston katalogeissa.
• Muuttamaton valtion takuu: Varastonäkymät edustavat aina Data 360 -datan yhdenmukaista, ajankohtaista tilaa.

Monimutkaiset integraatioskenaariot

• Hybriditila: Yhdistä Zero Copy (live-liitokselle) ja syöttö (historiallisille datajoukoille).
• Kauppojen välinen käyttöoikeus: Data 360 voi yhdistää useita Snowflake- tai Databricks-vuokralaisia yhteen organisaatioon.
• AI/BI-yhteensopivuus: Ulkoiset järjestelmät (esimerkiksi SageMaker, Tableau, Power BI) voivat kysellä Data 360:n rikastettuja profiileja takaisin käänteisen Zero Copyn kautta.
• Tiedostojen yhdyskäyttötiedosto: Open Lake -formaatteja (Iceberg/Delta) käyttävät yritykset voivat yhdistää rakenteellista ja jäsentämätöntä dataa yhdessä yhdistetyssä mallissa.

Esimerkki

Pilvipohjaiset analyysit sallivat organisaatioiden yhdistää hallittua Salesforce Data 360 -dataa natiivien datajoukkojen kanssa alustoilla, kuten Snowflake ja Databricks, tarjotakseen kattavan ja 360 asteen analyyttisen näkymän. Usean vuokralaisen käyttöoikeuden avulla eri liiketoimintayksiköt voivat turvallisesti kuluttaa kerättyjä ja käytäntöjen hallitsemia dataleikkeitä erillisten jakojen kautta identtisiä tietoja käyttämättä. Datatieteilijät voivat sitten suorittaa yhdistettyä tekoälyä ja koneoppimista kouluttamalla malleja suoraan yhtenäistettyihin asiakasprofiileihin Snowflake ML- tai Databricks MLflow -ympäristöissä. Koko tämän prosessin aikana sisäänrakennetut johdon, hallinnan ja auditoinnin ominaisuudet varmistavat, että kaikki tietojen käyttö ja käyttö noudattavat yrityksen käytäntöjä ja lakisääteisiä vaatimuksia, kuten GDPR ja HIPAA.

Data Cloud One sallii organisaatioiden, joilla on useita Salesforce-organisaatioita (esimerkiksi liiketoimintayksiköiden, alueiden, tuoterivien tai hankintojen vuoksi), jakaa yhden keskitetyn Data 360 -esiintymän. Tämä organisaatio toimii ”kotiorganisaationa”, kun taas muut organisaatiot, joita kutsutaan ”kumppaniorganisaatioiksi”, voivat käyttää ja työstää yhtenäistettyä dataa — vähällä vaivalla, ilman mukautettua koodia ja täydellä hallintajärjestelmällä.

Konteksti

Yritykset käyttävät usein useampaa kuin yhtä Salesforce-organisaatiota (esimerkiksi myyntiorganisaatio, palveluorganisaatio, markkinointiorganisaatio tai erilliset alueet). Jokaisella organisaatiolla voi olla omat datansa, kokoonpanonsa ja prosessinsa. Ennen Data Cloud One -versiota jokainen organisaatio vaati joko omia Data 360 -määrityksiään tai monimutkaisia mukautettuja koodeja jakaakseen dataa eri organisaatioiden välillä. Data Cloud One yksinkertaistaa tätä sallimalla yhden ”koti”-organisaation, jossa on Data 360 ja useita ”kumppani”-organisaatioita, jotka muodostavat yhteyden vähäisen koodin kokoonpanon ja metadatan jakamisen kautta.

Ongelma

Miten yritys voi käyttää yhtenäistettyä Customer 360 -dataa — jota kotiorganisaation Data 360 -organisaatio syöttää, yhdenmukaistaa ja hallitsee — yhdenmukaisesti kaikissa Salesforce-organisaatioissaan (jotta kaikki myynti-, markkinointi-, palvelu- jne. -organisaatiot käyttävät samoja perustana olevia tietoja), samalla kun vältetään päällekkäisiä töitä, mukautettua koodausta, erillisiä Data 360 -esiintymiä per organisaatio ja hallinta-aukkoja?

Voimat

Tämä kuvio esittelee useita arkkitehtuurissa, tietoturvassa ja suorituskyvyssä huomioitavia asioita:

• Monien organisaatioiden monimutkaisuus: Jokaisella liiketoimintayksikön organisaatiolla voi olla erilaisia tietoja, mukautettuja objekteja, tietoturvaa ja prosesseja — yhtenäisten yhtenäistettyjen näkymien ylläpitäminen on vaikeaa.
• Kopiointi ja kustannukset: Erillisen Data 360 -esiintymän suorittaminen per organisaatio tarkoittaa ylimääräistä määritystoimia, ylimääräistä hallintaa, lisälisenssejä ja datasilojen riskiä.
• Johtamisen ja datan jakamisen ohjaimet: Sinun täytyy päättää, mitä tietoja kukin kumppaniorganisaatio voi nähdä ja käsitellä — et voi yksinkertaisesti jakaa kaikkea ilman hallinnon riskiä.
• Määritysten nopeus: Markkinointi-, myynti- tai palvelutiimit eivät voi odottaa viikkoja, kun mukautettu koodi sallii organisaatioiden välisen datan käytön — he tarvitsevat napsautusten määritysratkaisuja.
• Datan sijainti, alueelliset huomioitavat asiat: Jos aloitus- ja kumppaniorganisaatiot sijaitsevat eri alueilla, datan säilyttämiseen ja jakamiseen saattaa liittyä lakisääteisiä tai lakisääteisiä rajoituksia.

Ratkaisu

Seuraava taulukko sisältää useita ratkaisuja tähän integraatio-ongelmaan.

Luonnos

Seuraava kaavio kuvaa tapahtumien järjestystä tässä kuviossa, jossa Salesforce on datan päätoiminto.

Tässä skenaariossa:

• Home Admin: luo datatila ja määritä datan jakaminen (valitse DMO/CIO, segmentit).
• Aloituspääkäyttäjä: luo datan jakotavoite kumppaniorganisaatioille ja määritä Trust (OAuth-asiakassovellus, sallitut organisaation tunnukset).
• Aloitussivun pääkäyttäjä: julkaise Datan jakaminen kohteeseen, liitä ABAC-käytäntöjä (CEDAR) ja salaus-/avainten ohjaimia (CMK tarvittaessa).
• Companion Org Admin: vastaanottaa kutsun, vahvistaa henkilöllisyyden kartoituksen ja hyväksyy jaon.
• Yhteisöorganisaatio: Data Cloud One Bridge provisioi Data Cloud One -käyttäjän ja käyttää käyttöoikeusjoukkojen ja datatilan näkyvyyttä.
• Yhteisöorganisaation sovellukset (kulut / Einstein / Apex): Kysele datakaaviota tai kutsu Data Cloud One API -rajapintoja lukeaksesi jaettuja DMO-organisaatioita tai segmenttejä.
• Aktivointi: Kumppaniorganisaatio käynnistää aktivoinnin tai kirjoittaa sen takaisin datatoiminnoilla (jos sallittu).

Tulokset

• Asiakastietojen (Customer 360) yksittäinen totuuden lähde kaikissa yhdistetyissä organisaatioissa — ei tarpeettomia Data 360 -esiintymiä.
• Arvon luominen tapahtuu nopeammin. Kumppaniorganisaatiot voivat käyttää yhtenäistettyä dataa ja Data 360 -ominaisuuksia muutamassa minuutissa, eikä viikkoja mukautetun koodauksen aikana.
• Datan hallittu jakaminen. Vain valtuutetut datatilat jaetaan, mikä säilyttää tietoturvan ja hallinnan ja mahdollistaa liiketoiminnan joustavuuden.
• Liiketoimintaominaisuudet (myynti, palvelu, markkinointi) toimivat samalla yhtenäistetyllä tietopohjalla, mikä mahdollistaa yhdenmukaiset tilastot, aktivoinnin ja havainnot koko organisaatiossa.

Puheluiden mekanismit

Kutsumekanismi riippuu tämän kuvion toteuttamiseen valitusta ratkaisusta.

Virheiden käsittely ja palautus

• Organisaatioiden välisen synkronoinnin kestokyky: Data Cloud One yrittää epäonnistuneita synkronointitöitä automaattisesti uudelleen aloitus- ja kumppaniorganisaatioiden välillä käyttämällä eksponentiaalisia rästityksiä väliaikaisille verkko- tai sovellusalustan virheille.
• Osittainen erän eristys: Epäonnistuneet tietueiden erät karanteenoidaan aloitusorganisaation Uudelleen-kokeilujonossa, kunnes yhteensovitus onnistuu, mikä estää tietojen eroavaisuudet.
• Skeeman hylkäämisen hallinta: Skeeman tai kartoituksen epäjohdonmukaisuudet reititetään kaavion hylkäysjonoon pääkäyttäjän tarkastettavaksi ja korjattavaksi.
• Toisto ja jatkamisen jatkuvuus: Jokainen synkronointityö ylläpitää offset-tarkastuspisteitä, jotta replikointia voidaan jatkaa edellisestä onnistuneesta sitoutumisesta ilman identtisiä tietueita.
• Integroitu valvonta: Kaikki epäonnistumiset, uudelleenyritykset ja palautustilastot tallennetaan Trust Layer Monitoring -mittaristoon näkyvyyden ja palvelutasosopimuksen varmistamiseksi.

Idempotent-suunnittelussa huomioitavia asioita

• Deterministiset henkilöllisyyden avaimet: Jokainen synkronointitapahtuma sisältää yksilöllisen avaimen (organisaation tunnus + tietueen tunnus + versionumero) varmistaakseen, että se käsitellään tarkalleen kerran.
• Toistotietoturva: Identtiset tai toistuvat tapahtumat suodatetaan sitoutumisajankohtana varmistaaksesi, että myöhemmät DMO- ja CIO-päivitykset ovat yhdenmukaisia.
• Atomic Commit Semantics: Kumppaniorganisaatiot merkitsevät datan sitoutuneeksi vasta, kun myöhemmät kirjoitukset on suoritettu onnistuneesti, mikä säilyttää organisaatioiden välisen transaktioiden eheyden.
• Ristiriitojen ratkaiseminen: Usean lähteen päivitykset noudattavat viimeksi kirjoitettuja/voitettuja- tai käytäntöihin perustuvaa yhdistämislogiikkaa, mikä säilyttää linjan ja yhdenmukaisuuden.
• Tarkastuspisteen säilyvyys: Synkronointityöt säilyttävät edellisen käsittelyn kompensoinnin ja tilan Trust turvallista palautusta ja toistamista varten.

Tietoturvassa huomioitavia asioita

• Vahva todennus: Aloitussivun ja kumppaniorganisaatioiden väliset yhteydet käyttävät yhteistä OAuth 2.0 -protokollaa ja automaattisesti kierrätettyjä valtuuksia, joita hallitaan yhdistettyjen sovellusten kautta.
• Yleinen valtuutus: Kumppaniorganisaatiot voivat käyttää vain tiettyjä datatiloja, DMO-organisaatioita tai johtajia, jotka on jaettu erikseen hallittujen datan jakokäytäntöjen kautta.
• Salaa kaikkialla: Data salataan siirrettäessä (TLS 1.2+) ja levossa (AES-256) sekä aloitus- että kumppaniorganisaatioissa.
• Pienimmän oikeutuksen periaate: Integrointikäyttäjät rajoittuvat vain vaadittuihin objekteihin. Hallinta- tai järjestelmätason käyttöoikeuksia ei lisätä.
• Tarkastuksen ja vaatimustenmukaisuuden näkyvyys: Kaikki synkronointitapahtumat, skeeman muutokset, tunnusten päivitykset ja käyttöoikeuksien myöntäminen kirjataan Data 360 Trust Layer -kerrokselle, jotta niitä voidaan seurata täysin.
• Yksityisen verkoston eristys: Valinnainen Salesforce Private Connect tai yksityinen linkki varmistaa, että datan replikointi tapahtuu vain suojatulla, sisäisellä kanavalla.

Sivupalkit

Aikavyöhyke

• Aloitus- ja kumppaniorganisaatioiden välinen synkronointi tapahtuu lähes reaaliajassa, tavallisesti sekunneissa lähdeorganisaation datan muutoksesta.
• Zero Copy -arkkitehtuuri varmistaa, että jaettua dataa voidaan kysellä välittömästi kaikissa osallistuvissa organisaatioissa — ilman replikointia tai eräviiveitä.
• Aktivointi- ja segmentointityöt vastaavat automaattisesti kaikkien yhdistettyjen organisaatioiden uusimpia päivityksiä ja pitävät toimintosi tuoreena.
• Päättymisviive on deterministinen ja sitä hallitsee Data Cloud One -organisaation orkestrointiputki, mikä varmistaa yhdenmukaisen organisaatioiden välisen ajoituksen, vaikka se olisi ladattu.

Datamäärät

• Suunniteltu usean vuokralaisen datan synkronointiin eri alueiden ja liiketoimintayksiköiden välillä — ja se voi hallita miljardeja tietueita per organisaatio.
• Tietoja viitataan, ei identtisiä, mikä vähentää tallennusjalanjälkeä ja säilyttää globaalin kyselytilan.
• Streaming-delat ja metadatan tiivistäminen optimoivat kaistanleveyden ja sitouttavat korkean muutosasteen objekteja (esimerkiksi Yhteyshenkilö, Tilaus).
• Skaalaa vaakasuorasti useissa kumppaniorganisaatioissa käyttämällä mukautettua kuormituksen tasapainottamista ja orkestrointia Trust Layer -kerroksen kautta.

Osavaltioiden hallinta

• Jokainen synkronoitu datajoukko ylläpitää metadatan riviä, versiota ja organisaation omistajuuden kontekstia varmistaakseen lopputuloksen jäljitettävyyden.
• Tarkastuspisteen pysyvyys kaappaa viimeksi synkronoidut offsetit organisaatioiden välillä, mikä mahdollistaa palautuksen ilman identtisiä tietueita.
• Skeeman versiointia ja semanttista kohdistusta organisaatioissa hallitaan automaattisesti Trust Layers -kerroksilla.
• Manuaalisia tilan nollauksia ei vaadita — synkronoinnin tilaa ylläpidetään Data Cloud One -orkestrointipalvelun kautta.

Monimutkaiset integraatioskenaariot

• Organisaatioiden välinen liitos: Sallii saumattoman kyselyn ja aktivoinnin useissa Data 360 -vuokralaisissa tai -alueissa yhtenäistetyn hallintamallin alla.
• Hybridisynkronointi: Yhdistää transaktioiden päivitysten lähes reaaliaikaisen replikoinnin ja joukko- tai arkistointidatan ajoitetun synkronoinnin.
• Monen alueen hallinta: Tukee maantieteellisesti jaetun datan jakamista ja kunnioittaa asuinpaikan, suostumuksen ja vaatimustenmukaisuuden rajoituksia.
• AI ja automatisoinnin aktivointi: Synkronoitu data tukee välittömästi Einsteinin tekoälyä, Agentforcea tai organisaatioiden mukautettuja ML-malleja — mikä mahdollistaa reaaliaikaisen organisaatioiden välisen älykkyyden.

Esimerkki

Globaalissa vähittäismyyntiorganisaatiossa on kolme Salesforce-organisaatiota: yksi Consumer Retailille, yksi Premium Brandsille ja yksi International Marketsille. He provisioivat Data 360:n Consumer Retail -organisaatiossa (joka tekee siitä kotiorganisaation). Data Cloud One sallii heidän muodostaa yhteyksiä Premium Brands- ja International Markets -organisaatioihin. He jakavat kullekin organisaatiolle vain asiaankuuluvia datatiloja (esimerkiksi ”Customer 360 – Retail Profiles” ja ”Customer 360 – Premium Profiles”). Premium Brands -organisaatiossa markkinointitiimit voivat tarkastella yhtenäistettyjä asiakasprofiileja, laatia segmenttejä laskettujen havaintojen perusteella (esimerkiksi premium-asiakkaiden elinkaaren arvo) ja käynnistää markkinoinnin automatisointeja — kaikki aloitusorganisaation Data 360 -esiintymän avulla ilman mukautettua koodausta tai datan kopiointia.

Datan aktivointi tuo Salesforce Data 360:n arvon todelliseen eloon. Se on prosessi, joka ottaa yhtenäistetyn, rikastetun ja hallitun datan, joka on alustassa, ja tekee siitä toimivan koko liiketoiminnassa. Käytännössä tämä tarkoittaa, että Data 360 tarjoaa kuratoituja segmenttejä, laskettuja havaintoja ja asiayhteydestä riippuvaisia attribuutteja turvallisesti järjestelmiin, jotka kiinnittävät asiakkaita — olipa kyse sitten markkinoinnin automatisoinnista, palvelukonsoleista, myynnin käyttöönotosta, analyysistä tai tekoälymalleista. Aktivointikuviot määrittävät teknisestä näkökulmasta, miten tämä data siirretään: mitkä kanavat käynnistetään, mitkä transformaatiot tai kartoitukset tapahtuvat ja miten käytäntöjä noudatetaan matkan aikana. Nämä kuviot eivät koske vain tietojen viemistä — ne koskevat reaaliaikaisten, käytännön tietoisten datakulkujen organisointia, jotka edistävät mitattavissa olevia liiketoimintatuloksia. Jokainen aktivointireitti muuttaa Customer 360:n aktiiviseksi toimintoresurssiksi, joka mahdollistaa personalisoinnin, ennakoivan päätöksenteon ja jatkuvan oppimisen kaikissa yhteydenottopisteissä.

Eräaktivointi on edelleen yleisin ja toiminnallisesti todennettu tapa viedä dataa Data 360:sta. Se toimii ajoitetulla tahdilla — julkaisee esimääritettyjä kohdeyleisösegmenttejä tai attribuuttijoukkoja alemmille alustoille säännöllisin väliajoin. Tämä kuvio soveltuu erinomaisesti markkinointi- ja osallistumistyönkulkuihin, jotka perustuvat yhdenmukaiseen ja tehokkaaseen kohdeyleisötoimitukseen pikapäivitysten sijaan. Tavallisiin käyttötarkoituksiin sisältyvät sähköpostien matkojen käynnistäminen, suorakampanjat tai kohdeyleisöjen lataaminen digitaalisiin mainosverkostoihin. Jokainen aktivointisuoritus noutaa hyväksytyn segmentin Data 360:n yhtenäistetystä profiilikaaviosta, käyttää hallinta- ja suostumuskäytäntöjä ja siirtää tulokset turvallisesti kohdejärjestelmään. Arkkitehtuurisesti eräaktivointi tarjoaa ennustettavan, auditoitavan ja kustannustehokkaan lähestymistavan datan jakamiseen — tasapainottaen toiminnan yksinkertaisuuden ja yritystason luotettavuuden. Se on laajamittaisen kampanjan selkäranka, jossa oikea data, joka toimitetaan ajoissa ja hallinnassa, aiheuttaa mitattavissa olevaa liiketoimintavaikutusta.

Konteksti

Modernit markkinoijat toimivat useilla osallistumiskanavilla — sähköposti, mainonta, mobiili ja verkko — jotka vaativat tarkkoja, ajantasaisia ja henkilökohtaisia asiakasyleisöjä. Data 360 toimii yhtenäisenä perustana näille kohdeyleisöille, ja se yhdistää asiakastietoja kaikista järjestelmistä muotoiltuihin, interaktiivisiin segmentteihin. Eräaktivointi on yleisin aktivointikuvio, jota käytetään näiden segmenttien viemiseen Data 360:sta myöhempiin markkinointi- tai mainosalustoihin. Tavallisiin kohteisiin sisältyvät Marketing Cloud Engagement, Google Ads, Meta Custom Audiences tai LinkedIn Ads, joissa kampanjat voidaan suorittaa suoraan näille kerätyille kohdeyleisöille.

Ongelma

Miten markkinointitiimi voi ottaa tarkasti määritetyn kohdeyleisön — joka on laadittu Data 360:n yhtenäistetystä ja rikastetusta datasta — ja sallia sen käytön ulkoisissa markkinointi- tai mainosjärjestelmissä aktivointia varten? Kuvittele esimerkiksi segmentti: ”Arvokkaat asiakkaat, jotka eivät ole tehneet ostoksia edellisen 90 päivän aikana, mutta ovat hiljattain osallistuneet verkkosivustolle.” Markkinoijien täytyy varmistaa, että tämä kohdeyleisö siirretään tarkasti, että se on rikastettu asiaankuuluvilla attribuuteilla (esimerkiksi kanta-asiakastasolla, alueella tai ennustetulla CLV:llä) ja että se päivitetään säännöllisin väliajoin säilyttääkseen kampanjan relevanttiuden ja tehokkuuden.

Voimat

Erän aktivointikuvioon vaikuttaa useita teknisiä ja toiminnallisia osatekijöitä:

• Identiteetin kartoitus: Tarkka kohdeyleisötoimitus vaatii, että Data 360:n yhtenäistetty yksityishenkilön tunnus kartoitetaan vastaavaan tunnisteeseen kohdejärjestelmässä — kuten tilaaja-avain Marketing Cloudissa tai tiivistetty sähköposti digitaalisille mainosalustoille. Tämä varmistaa tarkan täsmäyksen ja välttää kohdennusvirheet.
• Määritteen valinta ja rikastaminen: Markkinoijien täytyy ylittää tunnukset ja lisätä profiilitietoja — kuten etunimi, kanta-asiakastila, CLV tai muut henkilökohtaiset attribuutit — ottaakseen käyttöön myöhemmän personalisoinnin ja analyysin.
• Tavoitealustan kokoonpano: Jokaisen kohteen täytyy rekisteröityä Data 360:ssa aktivointikohteena, mukaan lukien yhteyden lisätiedot, todennukset ja datakenttien kartoitukset. Tämä kertaluonteinen määritystoiminto määrittää suojatun yhteyden ja määrittää, mitkä järjestelmät voivat vastaanottaa aktivoitua dataa.
• Hallinta ja vaatimustenmukaisuus: Datan aktivoinnin täytyy noudattaa yhtenäistetyssä profiilissa säilytettyjä suostumusmetadataa, tietosuojakäytäntöjä (esimerkiksi GDPR tai CCPA) ja markkinointioikeuksia. Suostumusten tietoinen aktivointi varmistaa, että tietoja käytetään vain valtuutetuissa tarkoituksissa.
• Ajoitus ja suorituskyky: Aktivoinnit ajoitetaan usein päivittäin tai tunneittain pitääkseen myöhemmät kohdeyleisöt ajan tasalla. Järjestelmän täytyy käsitellä suuria määriä ja asteittaisia päivityksiä tehokkaasti ilman identtisiä tietueita tai datan katoamista.

Ratkaisu

Data 360 -sovelluksen eräaktivointiprosessi noudattaa ohjattua työnkulkua, joka minimoi markkinoijille aiheutuneet tekniset ongelmat säilyttäen hallinnan ja skaalattavuuden:

Luonnos

Alla on vaiheiden yhteenveto:

• Segmentin rakentaminen: Markkinoija tai analyytikko luo segmentin käyttämällä visuaalista segmentointityökalua, joka yhdistää kaikkien yhtenäistettyjen dataobjektien suodattimet.
• Luo aktivointi: He valitsevat lähteeksi segmentin ja valitsevat esimääritetyn kohteen (kuten Marketing Cloud tai Google Ads).
• Määritä tietosisältö: Yhteyshenkilön tunnus ja muut profiiliattribuutit valitaan kohdeyleisön vientiä ja raportointia varten.
• Toimitusaikataulu: Aktivointi on ajoitettu tapahtumaan kerran tai toistuvasti, jotta kohdeyleisö pysyy ajan tasalla.
• Suoritus: Käynnistimen yhteydessä Data 360 kyselee segmenttiä, rakentaa tietosisällön, käyttää suodattimia suostumusta varten ja siirtää tuloksen kohdejärjestelmään.

Tulokset

• Data 360:n kohdennetut ja rikastetut kohdeyleisösegmentit ovat suoraan käytettävissä myöhemmissä markkinointi- ja mainosalustoissa.
• Kohdeyleisöt päivitetään ja synkronoidaan automaattisesti uusimmalla yhtenäistetyllä asiakastiedoilla, mikä säilyttää kampanjan reaaliaikaisen relevanttiuden.
• Markkinoijat voivat käyttää näitä aktivoituja kohdeyleisöjä pääsyn lähteinä Marketing Cloud -matkoihin, sähköpostikampanjoihin tai mukautettuihin kohdeyleisöihin digitaalisissa mainosalustoilla, kuten Google Ads, Meta tai LinkedIn Ads.
• Jokainen aktivointisuoritus ylläpitää kokonaisvaltaista linjaa varmistaakseen vaatimustenmukaisuuden, jäljitettävyyden ja yhdenmukaisuuden Data 360:n ja ulkoisten järjestelmien välillä.
• Yrityskäyttäjät voivat tarjota henkilökohtaisia ja dataan perustuvia käyttökokemuksia, jotka perustuvat kattavaan ja luotettuun Customer 360 -näkymään.

Puheluiden mekanismit

Kutsumekanismi riippuu kohdesovellusalustasta ja aktivointikohteen kokoonpanosta.

Virheiden käsittely ja palautus

• Työtason vikojen eristys: Jokainen aktivointisuoritus suoritetaan erillisenä seurattavana työnä Data 360 -orkestrointikerrossa. Epäonnistuneet suoritukset karanteenoidaan automaattisesti vaikuttamatta muihin aktivointeihin tai segmentin määritelmiin.
• Osittainen eräpalautus: Jos tiettyjen tietueiden vienti epäonnistuu (esimerkiksi tunnisteiden vastaavuuksien tai API-suhderajoitusten vuoksi), järjestelmä yrittää niitä uudelleen käyttämällä asteittaisia delta-jonoja, joilla on eksponenttinen rästitystoiminto ja rinnakkainen palautus.
• Skeeman vahvistusvirheet: Kun lähtevät hyötykuormattribuutit eivät enää vastaa kohdeskeemaa (esimerkiksi poistettu attribuutti tai uudelleennimetty kenttä), työ reitittää asiaankuuluvat tietueet kaavion hylkäysjonoon pääkäyttäjän tarkastettavaksi.
• Toista ja jatka tukea: Jokainen aktivointityö ylläpitää tarkastuspistevaltuutta — joka tallentaa viimeisen onnistuneen erän. Palautuksen jälkeen käsittely jatkuu tarkastuspisteestä varmistaen, ettei identtisiä tietueita tai dataa katoa.
• Yleinen seuranta: Kaikki aktivointitapahtumat, uudelleenyritykset ja toimitustilastot kirjataan Trust Layer Monitoring -ominaisuuteen, mikä mahdollistaa palvelutasosopimuksen seurannan, juuritason analyysin ja automatisoidun hälytyksen Event Monitoring API -rajapintojen kautta.

Idempotent-suunnittelussa huomioitavia asioita

• Deterministiset aktivointiavaimet: Jokainen aktivointisuoritus käyttää yhdistelmävahvistuksen avainta — joka yhdistää segmentin tunnuksen, aktivointitunnuksen ja kohdejärjestelmän tunnuksen — varmistaakseen tarkan toimituksen kerran.
• Toistohavainto: Data 360 -aktivointipalvelu tarkastaa saapuvat hyötykuormat aiempien töiden tiivisteiden perusteella havaitakseen ja estääkseen toistot.
• Atomien vientitehtävät: Hyötykuormat sitoutetaan kohdejärjestelmään vasta, kun kirjoitus on vahvistettu onnistuneesti, mikä estää osittaiset päivitykset tai kaksinkertaisen laskennan.
• Yhtenäinen identiteetin vahvistus: Aktivoinnit riippuvat yhtenäistetyistä tunnuksista (esimerkiksi yhtenäistetty yksityishenkilö), joten toistot tai uudelleenyritykset kohdistuvat aina samaan kultaiseen tietueeseen, mikä säilyttää semanttisen yhdenmukaisuuden.
• Aktivoinnin tilan pysyvyys: Orkestrointikerros säilyttää aktivointitilan metadatan — eli aikaleimat, tilakoodit ja järjestysvaltuudet — determinististä uudelleenkäsittelyä varten tarvittaessa.

Tietoturvassa huomioitavia asioita

• Vahva todennus: Jokainen aktivointikohde (esimerkiksi Marketing Cloud, Ads tai CRM) käyttää OAuth 2.0 -versiota, joka sisältää valtuuksien kierrätyksen ja vuokralaiskohtaisen raja-arvon, estääkseen valtuuttamattoman datan viennin.
• Määritteen tason hallinta: Vain yhtenäistetystä profiilista hyväksytyt attribuutit ovat oikeutettuja aktivointiin, jota datan jakokäytännöt ja aktivointimallit noudattavat.
• Salaus liikenteessä ja levossa: Kaikki hyötykuormat salataan käyttämällä siirron aikana TLS 1.2+-protokollaa ja AES-256-protokollaa paikalla Data 360:ssa ja kohdealustassa.
• Suostumus ja käytäntöjen noudattaminen: Aktivointityöt noudattavat suostumusobjekteja ja Data 360:n Trust säilytettyjä datakäytäntöjä. Tietueet, joilla ei ole kelvollista suostumusmetadataa, jätetään automaattisesti pois viennistä.
• Tarkastus ja vaatimustenmukaisuuden kirjaaminen: Jokainen aktivointisuoritus kaappaa sen käynnistäneen henkilön, mitä tietoja lähetettiin ja mihin kohteeseen — ja ottaa käyttöön täydet lakisääteiset tarkastuspolut (GDPR, CCPA) Trust Layer -mittaristossa.
• Pienin käyttöoikeus: Kunkin kohteen integrointikäyttäjät on rajoitettu aktivointikohtaisiin vaikutusalueisiin — heillä ei ole hallintaoikeuksia tai kirjoitusoikeuksia ei-liittyviin järjestelmiin.

Sivupalkit

Aikavyöhyke

• Suunniteltu ajoitetuille tai lähes reaaliaikaisille eräviennille (minuuteista tuntiin myöhässä).
• Tukee ajastettuja päivityksiä, jotka on linjattu kampanjakalentereihin.
• Aktivointitöitä voidaan järjestellä datan valmiusmerkinnöillä varmistaakseen datan tuoreuden.
• Soveltuu parhaiten ei-interaktiivisille aktivointikenaarioille, joissa tietojen tarkkuus on nopeampaa.

Datamäärät

• Käsittelee suuria datajoukkoja (miljoonia tietueita per suorituskerta).
• Skaalaa vaakasuorasti segmenttien osioinnin ja rinnakkaisten vientikanavien kautta.
• Käyttää osioihin perustuvaa erittelyä aikakatkaisujen välttämiseksi ja läpiviennin optimoimiseksi.
• Ihanteellinen yritystason dataputkille, joissa datan täydellisyys on tärkeää.

Osavaltioiden hallinta

• Ylläpitää aktivointitilaobjekteja, jotka tallentavat töiden tunnukset, aikaleimat ja järjestysvaltuudet.
• Käyttää tarkastuspisteytystä uudelleenkäyttöönottoon ja vianmääritykseen.
• Versioitujen segmenttien määritelmät varmistavat toistettavuuden aktivointisyklien välillä.
• Ottaa käyttöön lähdesegmentin, DMO-attribuuttien ja kohdelatausten välisen linjauksen jäljitettävyyden.

Monimutkaiset integraatioskenaariot

• Integroi saumattomasti Salesforce CRM-, Marketing Cloud- ja ulkoisten järjestelmien kanssa käyttövalmiiden liittimien avulla.
• Tukee usean kohteen aktivointeja ja jakaa dataa samanaikaisesti eri kohteisiin (esimerkiksi CRM + Ads).
• Voi käynnistää yhdistelmätyönkulkuja — esimerkiksi erävientiä ja myöhemmin API-kutsuja tai tekoälyn pisteytystä.
• Käsittelee skeeman kehityksen hienovaraisesti datamallin hallintakerroksen kautta.

Esimerkki

Globaali vähittäismyymälä haluaa ottaa uudelleen vastaan ei-aktiivisia asiakkaita edellisen 90 päivän ajalta. Data 360:n avulla datan arkkitehti määrittää ostohistorian, kanta-asiakastason ja suostumusten metadatan sisältävän ”Pysyviä asiakkaita” -segmentin. Erätyö suoritetaan öisin, ja se siirtää tämän segmentin Marketing Cloud Engagementiin käynnistääkseen henkilökohtaisen ”Olemme ikävä” -sähköpostikampanjan ja Ad Studioon uudelleenkohdistusta varten. Työ hyödyntää idempotent-toimitusta varmistaakseen, että uudelleenkäynnit eivät tapahdu identtisiksi, ja kaikki tapahtumat kirjataan Trust Layer -luokkaan tarkastusten vaatimustenmukaisuutta varten.

Konteksti

Yritykset tarvitsevat usein hallitun mekanismin viedäkseen yhtenäistetyn tai segmentoidun datan Salesforce Data 360:sta vakiomuotoiseen tiedostomuotoon (esimerkiksi CSV tai Parquet) arkistointia, vaatimustenmukaisuutta tai downstream-integraatiota varten. Tämä kuvio sallii Data 360 -tallennustilan viennin pilvipalvelimelle — mikä sallii luotettujen asiakkaiden datan virrata turvallisesti Enterprise Data Lakesiin tai Amazon S3:ssa, Azure Blobissa tai Google Cloud Storage (GCS) -palvelimella isännöityihin analyysiputkeihin. Tyypillisiin käyttötarkoituksiin sisältyy:

• Säännöllinen arkistointi suostuneista asiakasdatajoukoista lakisääteistä säilyttämistä varten.
• Kuratoitujen segmenttien vieminen muihin kuin Salesforcen analyyttisiin työkuormiin (esimerkiksi Tableau, Databricks tai Power BI).
• Ulkoisten koneoppimismallien ottaminen käyttöön, jotka vaativat rakenteellisia CSV- tai parkettitiedostoja input-arvona.

Ongelma

Miten organisaatio voi viedä kerätyn segmentin tai datajoukon Data 360:sta pilvitallennustilaan (esimerkiksi Amazon S3) — hallitulla, turvallisella ja automatisoidulla tavalla — samalla kun se ylläpitää skeeman eheyttä ja vaatimustenmukaisuuden hallintaa? Vaatimustenmukaisuustiimin täytyy esimerkiksi: ”Nouda kaikki aktiiviset asiakkaat EU-alueella kelvollisella suostumuksella ja vie tiedot viikoittain S3-sijaintiin ulkoista auditointia ja raportointia varten.” Tämä vaatii toistettavan ja käytännön mukaisen vientiputken, joka varmistaa oikean tiedostomuodon, käyttöoikeudet ja toimitusaikataulut — ilman manuaalisia toimenpiteitä tai hallitsematonta datan siirtoa.

Voimat

Tämän vientikuvion hallitsevat useat toiminnalliset ja arkkitehtoniset tekijät:

• Todennus ja valtuutus: Vientien täytyy noudattaa pilvipalveluntarjoajan IAM-mallia (esimerkiksi AWS IAM -rooleja tai Azure Service Principalsia) varmistaakseen, että vain valtuutetut järjestelmät voivat kirjoittaa kohdekategoriaan.
• Skeeman tasaus: Lähtevän skeeman täytyy vastata kohdejärjestelmän odotettua rakennetta ja muotoa (CSV, Parquet tai JSON).
• Datan yksityisyys ja suostumus: Vietyjen datajoukkojen täytyy suodattaa pois kaikki tietueet, joilla ei ole kelvollista suostumusmetadataa.
• Ajoitus ja tuoreus: Monet viennit ovat säännöllisiä (päivittäin, viikoittain tai kuukausittain) ja niiden täytyy noudattaa yritystietojen päivityssykliä.
• Hallinta ja valvonta: Jokaisen viennin täytyy olla tarkastettavissa ja linjan näkyvyys täynnä, mikä varmistaa tietojen säilyttämisen ja lakisääteisten velvoitteiden noudattamisen (esimerkiksi GDPR, CCPA).

Ratkaisu

Tiedostojen viennin aktivointikuvio käyttää uudelleen samoja suojattua pilvitallennustilaa, joita käytetään tuontia varten, mutta jotka on määritetty datan poistamista varten. Pääkäyttäjät rekisteröivät ensin pilvitallennusalustan (esimerkiksi Amazon S3, Azure Blob Storage tai GCS) aktivointikohteeksi Data 360:ssa. Sitten käyttäjät määrittävät ja suorittavat aktivointityönkulun viedäkseen haluamansa segmentin tiedostojen tallennuspolkuun.

Luonnos

Alla on vaiheiden yhteenveto.

• Valitse segmentti: Analyytikko tai datan hallinta valitsee vientiä koskevan yhtenäistetyn segmentin.
• Luo aktivointi: He luovat uuden aktivointityön ja valitsevat rekisteröidyn Cloud Storage -kohteen.
• Määritä tietosisältö: Määritä vientiskeema, attribuuttien luettelo ja tiedostomuoto (esimerkiksi CSV).
• Ajoituksen vienti: Valitse kertaluonteinen tai toistuva aikataulu.
• Suorita työ: Data 360 luo tiedoston ja toimittaa sen turvallisesti määritettyyn paikannuspolkuun.
• Valvo ja vahvista: Tulokset ja lokit tarkastetaan Trust vahvistusta ja vaatimustenmukaisuutta varten.

Tulokset

• Data 360:n kohdennetut ja rikastetut kohdeyleisösegmentit ovat suoraan käytettävissä myöhemmissä markkinointi- ja mainosalustoissa.
• Kohdeyleisöt päivitetään ja synkronoidaan automaattisesti uusimmalla yhtenäistetyllä asiakastiedoilla, mikä säilyttää kampanjan reaaliaikaisen relevanttiuden.
• Markkinoijat voivat käyttää näitä aktivoituja kohdeyleisöjä pääsyn lähteinä Marketing Cloud -matkoihin, sähköpostikampanjoihin tai mukautettuihin kohdeyleisöihin digitaalisissa mainosalustoilla, kuten Google Ads, Meta tai LinkedIn Ads.
• Jokainen aktivointisuoritus ylläpitää kokonaisvaltaista linjaa varmistaakseen vaatimustenmukaisuuden, jäljitettävyyden ja yhdenmukaisuuden Data 360:n ja ulkoisten järjestelmien välillä.
• Yrityskäyttäjät voivat tarjota henkilökohtaisia ja dataan perustuvia käyttökokemuksia, jotka perustuvat kattavaan ja luotettuun Customer 360 -näkymään.

Puheluiden mekanismit

Kutsumekanismi riippuu kohdepilvitallennusalustasta ja aktivointikokoonpanosta.

Virheiden käsittely ja palautus

• Työtason eristys: Jokainen vienti suoritetaan erillisenä työnä. Epäonnistuneet työt karanteenoidaan ja yritetään uudelleen itsenäisesti.
• Tiedoston osittainen uudelleenyritys: Jos tiettyjen erien lataaminen palvelimelle epäonnistuu (esimerkiksi verkkohäiriöiden vuoksi), järjestelmä yrittää palauttaa ne uudelleen käyttämällä eksponenttista rästityötä.
• Skeeman vastaavuuksien käsittely: Kaikki skeeman hajonta- tai kenttävirheet reitittävät tietueet kaavion hylkäämisen jonoon tarkastettavaksi.
• Tarkastuspiste ja Jatka: Vientityöt ylläpitävät tarkastuspisteiden metadataa, mikä mahdollistaa jatkamisen edellisestä onnistuneesta kirjoituksesta ilman identtisiä tietueita.
• Integroitu valvonta: Virheet ja uudelleenyritykset kirjataan Trust Layer -mittaristoon näkyvyyden ja palvelutasosopimuksen noudattamisen varmistamiseksi.

Idempotent-suunnittelussa huomioitavia asioita

• Deterministiset viennin avaimet: Jokainen vientityö sisältää yksilöllisen tunnuksen, joka koostuu Segmentin tunnus + Kohteen tunnus + Aikaleima.
• Toistotietoturva: Identtiset työn suoritukset havaitaan käyttämällä töiden tiivistelmää ja ohitetaan välttyäksesi tarpeettomilta vienneiltä.
• Atomic Write -takuu: Data 360 sitouttaa tiedostot kohdekategoriaan vasta, kun se on suoritettu ja tarkistettu.
• Yhtenäinen skeeman versiointi: Vientimääritelmät ovat versio-ohjaimia varmistaakseen skeeman yhdenmukaisuuden kaikkien suorituskertojen välillä.
• Tarkastuspisteen säilyvyys: Vie töitä pysyvä tila determinististä palautusta ja uudelleenkäsittelyä varten tarvittaessa

Tietoturvassa huomioitavia asioita

• Vahva todennus: Cloud-liittimet käyttävät todennetuille kirjoituksille OAuth 2.0-, IAM-rooleja tai palvelupäälliköitä.
• Salaa kaikkialla: Data salataan sekä siirron aikana (TLS 1.2+) että levossa (AES-256).
• Suostumuksen tietoinen vienti: Vain tietueet, joilla on käypä suostumus, viedään Trust Layer -käytäntöjen mukaisesti.
• Pienin käyttöoikeusperiaate: Viedä käyttäjiä ja palvelutilejä on rajoitettu niiden määritettyihin tallennuspolkuihin.
• Yleinen lokien kirjaaminen: Jokainen vienti tallentaa metadatan, mukaan lukien käynnistimen, skeeman, kohteen ja aikaleimat vaatimustenmukaisuusraportointia varten.

Sivupalkit

Aikavyöhyke

• Suunniteltu välittömään, tapahtumiin perustuvaan aktivointiin, joka kestää alle sekunnin.
• Soveltuu erinomaisesti tilanteisiin, jotka vaativat henkilökohtaisuutta, suosituksia tai päätöksentekoa välittömästi.
• Toimii streaming-tilassa — Käynnistimet käynnistyvät heti, kun Data 360:ssa tapahtuu kelvollisia datan muutoksia.
• Varmistaa jatkuvan reagoinnin ilman eräaikatauluja tai segmentin uudelleenlaskentaa.

Datamäärät

• Käsittelee suuria datajoukkoja (miljoonia tietueita per suorituskerta).
• Skaalaa vaakasuorasti segmenttien osioinnin ja rinnakkaisten vientikanavien kautta.
• Käyttää osioihin perustuvaa erittelyä aikakatkaisujen välttämiseksi ja läpiviennin optimoimiseksi.
• Ihanteellinen yritystason dataputkille, joissa datan täydellisyys on tärkeää.

Osavaltioiden hallinta

• Jokainen tapahtumatoiminto säilyttää oman tapahtumavaltuutensa ja toistotunnuksensa idempotent-käsittelyä varten.
• Tukee tarkastuspisteen pysyvyyttä jatkaakseen edellisestä sitoutuneesta tapahtumasta väliaikaisen epäonnistumisen varalta.
• Sisältää sisäänrakennetun identtisten tietueiden poistalogiikan ja toistohyökkäysten, jotta aktivoinnin semanttinen tunniste on tarkka.
• Toiminnon tulokset (onnistui/epätosi) kirjataan lokiin reaaliajassa ja näytetään Trust Layer -havaintojen mittariston kautta.

Monimutkaiset integraatioskenaariot

• Integroi suoraan Salesforce-kulkuihin, Einstein 1 Platform -tapahtumiin tai ulkoisiin webhookeihin välittömiä vastausketjuja varten.
• Voi käynnistää myöhempiä automatisointeja — esimerkiksi CRM-tietueiden pikapäivityksiä, tekoälyn pisteytystä tai Marketing Cloud -viestien lähetyksiä.
• Tukee yhdistettävää orkestrointia: tapahtumien käynnistimet voivat kutsua Data 360 -toimintoja, Apex tai ulkoisia API-rajapintoja.
• Tarkoitettu agenteille ja mukautuville yrityskuvioille, joissa kontekstitietoisten vastausten täytyy tapahtua välittömästi.

Esimerkki

Globaalin vähittäismyymälän täytyy toimittaa viikoittainen vienti ”Active Loyalty Members” -segmentistään databricks-analyysiä varten. Data 360 -pääkäyttäjä määrittää Amazon S3:n aktivointikohteeksi ja ajoittaa viikoittaisen CSV-viennin s3://enterprise-analytics/loyalty/weekly_exports/-polkuun. Vientityö suoritetaan joka sunnuntai ja se luo suostumusten suodattaman tiedoston, jossa on yli 2 miljoonaa tietuetta. Kaikki tapahtumat, skeemojen määritelmät ja lajittelu tallennetaan Trust Layer -mittaristoon, mikä varmistaa läpinäkyvyyden, auditointikyvyn ja vaatimustenmukaisuuden.

On-Demand API-pohjainen aktivointi on reaaliaikainen, tapahtumiin perustuva lähestymistapa, jolla Data 360 -havaintoja voidaan käyttää tarvittaessa — ilman erätöiden tai ajoitettujen vientien odottamista. Sen sijaan, että julkaistaisit käyttövalmiita segmenttejä kiinteällä järjestyksellä, tämä kuvio sallii ulkoisten järjestelmien, Salesforce-sovellusten tai tekoälyn agenttien kutsua Data 360 API -rajapintoja suoraan noutaakseen tai aktivoidakseen tiettyjä kohdeyleisöjä, asiakkaan attribuutteja tai havaintoja tarvittaessa. Tämä kuvio on suunniteltu interaktiivisille, käynnistimiin perustuville käyttökokemuksille — esimerkiksi kun käyttäjä kirjautuu portaaliin, agentti avaa asiakastietueen tai tekoälypilotti käynnistää seuraavan parhaan toiminnon kyselyn. Sen sijaan, että järjestelmä luottaisi esimääritettyihin vienteihin, se kyselee tai aktivoi dynaamisesti ajankohtaisia, hallittuja tietoja Data 360:sta reaaliajassa. Keskeinen etu on välitön ja tarkka:

• Jokainen API-kutsu käyttää ajankohtaisia Älykkäät asiakastietoja Data 360:n yhtenäistetyssä, suostumuskohtaiseen profiilikaaviossa.
• Aktivoinnit ovat tehokkaita ja auditoitavia, ja ne vastaavat Enterprise Trust- ja vaatimustenmukaisuusvaatimuksia.
• Integraatiot voidaan käynnistää suoraan Salesforce-kuluista, Apexista tai ulkoisista järjestelmistä Einstein 1 Platform API:n, Connect API:n tai aktivointi-API:n kautta. Tämä lähestymistapa tukee tapauksia, joissa viive ja personalisointi ovat tärkeimpiä — esimerkiksi:
• Henkilökohtaisen tuotetarjouksen käynnistäminen palvelupuhelun aikana.
• Dynaamisten kampanjoiden kohdeyleisöjen luominen live-toimintatapahtumien perusteella.
• Reaaliaikaisten päätösten syöttäminen tekoälyn tai ML-malleihin, jotka toimivat osallistumisen aikana.

Konteksti

Yritysten täytyy usein näyttää yhdenmukaistettuja reaaliaikaisia Data 360 -havaintoja mukautetuissa sovelluksissa — kuten sisäisissä verkkoportaaleissa, mobiilisovelluksissa tai kumppaneille tarkoitetuissa verkkokokemuksissa. Tämä kuvio sallii kehittäjien rakentaa turvallisia, käyttöliittymään perustuvia ratkaisuja, jotka kuluttavat ja näyttävät yhtenäistettyä asiakastietoja Salesforce CRM:n ja muiden asiayhteydestä riippuvaisten järjestelmien rinnalla, kaikki hallitun ja API-pohjaisen käytön kautta. Tyypillisiin käyttötarkoituksiin sisältyy:

• Data 360 -havaintojen upottaminen sisäisiin työntekijöiden mittaristoihin tai mobiilisovelluksiin.
• Luo kumppani- tai jälleenmyyjäportaaleja, joissa näkyy asiakkaat ja transaktiot.
• Data 360 -datan integrointi kolmansien osapuolten verkkosovelluksiin tai kokemusten kerroksissa.
• Reaaliaikaisten, henkilökohtaisten suositusten näyttäminen Data 360:n ja Einsteinin avulla 1.

Ongelma

Miten kehittäjä voi rakentaa mukautetun käyttöliittymään keskittyvän sovelluksen, joka käyttää ja näyttää yhdenmukaistettua Data 360 -dataa turvallisesti, usein muiden Salesforce-tietolähteiden rinnalla — kopioimatta tai viemättä luottamuksellisia tietoja? Yrityksen täytyy ehkä esimerkiksi rakentaa asiakasportaali, joka näyttää yhtenäistettyjä asiakasprofiileja, vuorovaikutuksia ja laskettuja havaintoja Data 360:sta. Tämä vaatii yhden, suojatun ja suorituskykyisen API-kerroksen, joka voi tarjota etukäteen käyttökokemusta, käsitellä todennusta ja varmistaa hallinnon — samalla kun se poistaa Data 360:n sisäisen datamallin monimutkaisuuden.

Voimat

Useat arkkitehtoniset ja toiminnalliset asiat vaikuttavat tähän kuvioon:

• UI-centric-käyttöoikeus : Ensisijainen tavoite on esittää dataa mukautetuissa front-end-käyttökokemuksissa (verkkosivulla tai mobiililaitteilla), eikä suorittaa erien noutoa tai taustasynkronointia.
• Suojattu yhdyskäytävä : Valitun API:n täytyy toimia turvallisena ja skaalattavana sisääntulopisteenä todennetuille sovelluksille ja käyttäjille, ja se vaatii yritystason käyttöoikeuksien hallintaa.
• Yhtenäistetty datan konteksti : Sovellusten tulisi voida yhdistää Data 360 -dataa (esimerkiksi yhtenäistettyjä profiileja, laskettuja havaintoja) CRM-, ERP- tai mukautettujen objektien dataan saumattomasti.
• Kehittäjän yksinkertaisuus : API-rajapintojen tulisi palauttaa esitelmälle valmiita tietosisältöjä, jotka minimoivat asiakassovellusalustan taustakäsittelyn tai skeemakartoituksen.
• Hallinta ja havaittavuus : Kaikkien käyttöoikeuksien tulisi kulkea luotettujen ja tarkastettavien kanavien kautta selkeällä linjauksella, todennuksella ja käytäntöjen noudattamisella.

Ratkaisu

Ratkaisu on käyttää Salesforce Connect REST API -rajapintaa ensisijaisena integraation yhdyskäytävänä mukautettujen, dataan perustuvien sovellusten rakentamiseen Data 360:n päälle. Connect API tarjoaa RESTful-käyttöoikeuden Salesforce-dataan — mukaan lukien Data 360:n yhdenmukaistettuihin profiileihin, segmentteihin ja laskettuihin havaintoihin — käyttöliittymän kulutukseen optimoiduissa vastausmuodoissa (JSON-pohjaiset, kevyet ja mobiiliystävälliset). Kehittäjät todentavat itsensä yhdistetyn sovelluksen kautta, hankkivat OAuth 2.0 -valtuuksia ja kutsuvat Connect API -resursseja, kuten /query, /chatter tai /data, näyttämään yhtenäistettyä dataa suoraan sovelluksen käyttöliittymissään. Connect API toimii kulissien takana muiden API-rajapintojen — kuten Query API:n, Data Graph API:n ja Einstein 1 Platform API:n — kuljetusalustanä, jolloin kehittäjät voivat yhdistää useita tietolähteitä yhdellä yhtenäistetyllä käyttöliittymällä.

Luonnos

Alla on vaiheiden yhteenveto.

• Rekisteröi yhdistetty sovellus — Määritä OAuth-vaikutusalueet ja API-käyttöoikeudet ulkoisten sovellusten todennusta varten.
• Obtain Access Token — Ulkoinen sovellus suorittaa OAuth 2.0 -todennuksen saadakseen valtuuden Data 360 -käyttöoikeudelle.
• Invoke Connect API — Sovellus suorittaa REST API -kutsuja noutaakseen yhtenäistettyjä profiilien, segmenttien tai havaintojen tietoja.
• Datan renderöinti käyttöliittymässä — Vastaukset jäsennetään ja esitetään käyttäjille brändätyssä portaalissa tai mobiilikäyttöliittymässä.
• Käsittele virheet ja päivitysvaltuudet — Sovellukset käyttävät uudelleenyrityslogiikkaa ja valtuuksien automaattista päivitystä istunnon jatkuvuuden takaamiseksi.
• Monitorin ja auditoinnin käyttöoikeudet — Kaikki API-kutsut kirjataan Trust-kerrokselle näkyvyyden ja vaatimustenmukaisuuden varmistamiseksi.

Tulokset

Kehittäjät voivat luoda turvallisia ja mukautettuja sovelluksia, jotka on integroitu tiiviisti Data 360:n kanssa. Nämä sovellukset voivat:

• Näytä yhdenmukaistetut asiakasprofiilit ja havainnot reaaliajassa.
• Näytä Data 360 -data CRM- tai mukautettujen objektien kanssa yhtenäistettyjen API-rajapintojen avulla.
• Hyödynnä yhdenmukaisia todennus-, valtuutus- ja auditointiasetuksia Trust kautta.
• Tarjoa yrityskäyttäjille tai kumppaneille saumaton ja hallittu pääsy luotettuihin Älykkäät asiakastietoihin eri käyttökokemuksista.

Puheluiden mekanismit

Kutsumekanismi riippuu kohdepilvitallennusalustasta ja aktivointikokoonpanosta.

Virheiden käsittely ja palautus

• Pyynnön ketjutus: Palauttaa API-kutsut automaattisesti ja yrittää niitä uudelleen nopeusrajoitusten alaisena.
• Schema Drift Protection: Käyttää GraphQL-skeeman versiointia tai REST-metadatan löytämistä sekaantumaan skeeman muutoksiin.
• Tunnusten vanhenemisen hallinta – Sovellukset päivittävät OAuth-valtuudet automaattisesti istuntojen keskeyttämisen välttämiseksi.
• API-virheiden eristys – Epäonnistuneet API-kutsut kirjataan lokiin ja yritetään uudelleen vaikuttamatta samanaikaisiin istuntoihin.
• Trust Layer Observability – API:n onnistumissuhteet ja käyttöoikeuslokit ovat näkyvissä Trust Layer -mittaristossa.

Idempotent-suunnittelussa huomioitavia asioita

• Determinististen pyyntöjen tunnukset: Jokainen API-pyyntö sisältää korrelaatiotunnuksen toistoturvallista käsittelyä varten.
• Vahvistuksen välimuistin otsikot: ETag- ja Edellinen muokkaaja -otsikot estävät tarpeettoman datan noutamisen.
• Atomiset lukutoiminnot: Connect API varmistaa, että jokainen vastaus vastaa yhdenmukaista tilannekuvaa yhtenäistetystä datasta.
• Toisto-suojaus – Identtiset API-kutsut suodatetaan pyyntöjen allekirjoituksilla ja aikaleimoilla.

Turvallisuudessa huomioitavia asioita

• OAuth 2.0 -todennus: Kaikki API-kutsut käyttävät suojattuja, lyhytaikaisia OAuth-käyttöoikeusvaltuuksia yhdistettyjen sovellusten kautta.
• Pienin käyttöoikeus: API-vaikutusalueet on rajoitettu vain tarvittaviin objekteihin ja kenttiin.
• Salaa kaikkialla: TLS 1.2+ siirrettäessä; AES-256-salaus paikallaan välimuistiin tallennetuille tai tallennetuille vastauksille.
• Sovelluksen tietoinen käyttöoikeus dataan: Data 360 varmistaa, että kaikki noudetut tietueet noudattavat suostumus- ja hallintakäytäntöjä.
• Yleinen lokien kirjaaminen: Jokainen API-vuorovaikutus tallennetaan käyttäjän, sovelluksen ja aikaleiman metadatan kanssa Trust Layer -kerroksessa.

Sivupalkit

Aikavyöhyke

• Suunniteltu reaaliaikaisille API-käyttöoikeuksille, joilla on pieni viive.
• Soveltuu erinomaisesti interaktiivisille sovelluksille, jotka vaativat datan renderöinnin välittömästi.
• Tukee lähes välittömiä kyselyiden vastausaikoja välimuistiin tallennetuilla ja indeksoiduilla Data 360 -lähteillä.
• Ei riippuvuutta eräaikatauluista tai ei-synkronoiduista aktivointisykleistä.

Datamäärät

• Optimoitu interaktiivisille käyttötarkoituksille, jotka noutavat pieniä ja keskisuuria datajoukkoja (esimerkiksi profiileja, havaintoja tai viimeaikaisia tapahtumia).
• Käsittelee sivutetut tulokset tarkasti kursoripohjaisen sivutuksen avulla.
• Ei tarkoitettu raskaan joukkosiirron yhteydessä — käytä suurille datajoukoille Erä- tai Tiedoston vienti -kuvioita.

Osavaltioiden hallinta

• Sovellukset ylläpitävät istunnon kevyttä tilaa OAuth-valtuuksilla ja paikallisella välimuistilla.
• Connect API tukee ehdollisia pyyntöjä ja osittaista päivitystä tehokkuuden parantamiseksi.
• API-vastaukset sisältävät versioiden merkintöjä, jotka varmistavat skeeman yhdenmukaisuuden julkaisujen välillä.

Monimutkaiset integraatioskenaariot

• Yhdistä Connect API ja Data Graph API semanttisille kyselyille useissa toimialueissa.
• Integroi Einstein 1 Copilot- tai AI API -rajapintoihin tarjotaksesi ennakoivia ja selkokielisiä käyttökokemuksia.
• Käytä Experience Cloudin tai Lightning kanssa hybridikäyttöliittymän kehittämiseen.
• Laajenna MuleSoftin kautta orkestroidaksesi datan rikastamisen tai ulkoisten järjestelmien hakuja reaaliajassa.

Esimerkki

Monikansallinen vakuutusyhtiö rakentaa asiakaspalveluportaalin, jonka avulla vakuutusten omistajat voivat tarkastella yhtenäistettyjä profiilejaan, viimeaikaisia korvausvaatimuksiaan ja henkilökohtaisia tarjouksiaan. Etusivu, eact-pohjainen sovellus todentaa itsensä OAuth 2.0:n kautta ja noutaa dataa Connect REST API:n ja Data Graph API:n avulla. Kaikki tiedot näytetään reaaliaikaisesti, suostumus on tietoinen ja niitä hallitaan Data 360 Trust -kerroksen kautta. Kehittäjät valvovat API-kutsuja ja kirjausketjuja suoraan Salesforcessa varmistaakseen täyden vaatimustenmukaisuuden ja havaittavuuden.

Konteksti

Yritykset tarvitsevat yhä enemmän välitöntä pääsyä täydelliseen asiakasprofiiliin reaaliaikaisille päätöksentekojärjestelmille — kuten palvelukonsoleille, suositusjärjestelmille tai personalisointialustoille.Tämä kuvio sallii sovellusten hakea valmiiksi laskettuja, yhtenäistettyjä näkymiä asiakkaan tiedoista lähes reaaliajassa Data 360:n Data Graph API:n avulla, joka tarjoaa interaktiivisille käyttökokemuksille sekuntien vastausaikoja. Tyypillisiin käyttötarkoituksiin sisältyy:

• Näyttää 360 asteen asiakkaan näkymän Asiakaspalvelu- tai Sales Console -palvelussa.
• AI-pohjaisten ”Next Best Action”- tai ”Next Best Offer” -suositusten lisääminen.
• Tarjoamalla hyperpersonalisoituja verkkokokokemuksia tai mobiilikokemuksia sivujen lataamisen aikana.
• Tuki istunnon sisäiseen päätöksentekoon agenttien tai itsepalveluympäristöissä.

Ongelma

Miten sovellus voi noutaa täydellisen, esimääritetyn ja yhtenäistetyn asiakkaanäkymän välittömästi sen sijaan, että se suorittaisi hitaita, usean objektin kyselyitä suorituksen aikana? Web-henkilöstöjärjestelmän täytyy esimerkiksi ladata asiakkaan koko asiayhteys (demografiat, valinnat, transaktiot ja lasketut havainnot) millisekunteina valitakseen henkilökohtaisen tarjouksen. Perinteiset suhdekyselyt saattavat vaatia useita liitoksia ja aiheuttaa hyväksymättömän viiveen. Tämä vaatii API:n, joka tarjoaa denormalisoituja, käyttövalmiita profiilitietoja, jotka voidaan hakea yhden avaimen haulla — yhdistämällä nopeus, täydellisyys ja hallinta.

Voimat

Useat toiminnalliset ja suorituskykyyn liittyvät tekijät vaikuttavat tähän kuvioon:

• Nopeus: Vastauksen ajan täytyy olla lähellä Real-Time-aikaa. API:n täytyy palauttaa täydellinen profiili millisekunteina synkronoitavien vuorovaikutusten tukemiseksi.
• Yksityisyys: Vastauksen täytyy sisältää kaikki asiaankuuluvat attribuutit, suhteet ja lasketut havainnot — mieluummin yhdessä tietosisällössä.
• Hakutehokkuus: Profiileja tulisi voida hakea tunnisteiden kautta, kuten customerId, contactKey tai email, jolloin monivaiheisia kyselyitä ei tarvita.
• Datan tuoreus vs. Viive: Jotkin käyttötarkoitukset suosivat valmiiksi laskettua dataa (välimuistiin tallennettua dataa) nopeutta varten. Toiset tarvitsevat live-dataa ja hyväksyvät korkeamman viiveen.
• Hallinta ja tietoturva: Käyttöoikeuksia täytyy hallita edelleen Salesforcen Trust Layer -käytännöillä, jotta tietojen näkyvyys- ja suostumusten sääntöjä noudatetaan.

Ratkaisu

Ratkaisu on käyttää Salesforce Data Graph API -rajapintaa noutaaksesi esimääritettyjä, denormalisoituja asiakasnäkymiä, joita säilytetään Data Graph -tietueina. Datakaavio on materialisoitu semanttinen näkymä, joka yhdistää useita datamalliobjekteja (DMO) — kuten Individual, Transaction ja ProductInterest — yhdeksi Vain luku -muotoiseksi tietueeksi, joka esitetään usein JSON-blobina. Kehittäjät voivat käyttää REST-päätepisteitä, kuten: GET /api/v1/dataGraph/{dataGraphEntityName}/{id} noutaaksesi koko tietueen sen yksilöllisen tunnisteen perusteella. Dynaamisissa skenaarioissa API tukee live=true-parametriä, joka ohittaa materialisoidun välimuistin, suorittaa reaaliaikaisen kyselyn Data 360:ssa ja vaihtaa vähäistä viiveä tuoreimmille tiedoille. Tämä sallii kehittäjien valita väliaikaisen (välimuistiin tallennetun) ja ajankohtaisen (live) profiilien noutamisen liiketoimintatarpeiden mukaan.

Luonnos

Alla on toteutuskulun yhteenveto:

• Datakaavion määrittäminen — Data-arkkitehtit luovat datakaavion, joka mallinntaa yhtenäistetyn asiakasnäkymän useista DMO-organisaatioista.
• Rekisteröi yhdistetty sovellus — Kehittäjät määrittävät OAuth-tunnukset suojattua API-käyttöoikeutta varten.
• Invoke Data Graph API — Sovellus lähettää GET-pyynnön, joka sisältää Data Graph -nimen ja tietueen tunnuksen.
• Prosessin vastaus — API palauttaa asiakkaan profiilin täydellisen JSON-kuvauksen.
• Render tai Act — Kuluttaja-sovellus (käyttöliittymä tai järjestelmä) käyttää yhtenäistettyä dataa personalisointiin, suosituksiin tai palvelutoimintoihin.
• Monitor ja säätö — Suorituskykytilastoja ja käyttöoikeuslokeja tarkastetaan Trust Layer -havaintojen konsolin kautta.

Tulokset

Sovellukset voivat nyt noutaa valmiiksi yhdistetyn asiakasprofiilin heti, mikä mahdollistaa reaaliaikaiset vuorovaikutukset, kuten personalisoinnin, palvelun ja päätösten automatisoinnin. Tämä kuvio varmistaa:

• Välisekuntien vastausajat, joita käytetään päätösten tekemiseen tällä hetkellä.
• Johdonmukainen ja hallittu datan nouto, joka on linjassa Data 360 -semanttisen mallin kanssa.
• Yksinkertaistettu sovelluslogiikka — ei liitoksia, ei skeemojen yhteensovitusta.
• Seurattava ja yhteensopiva käyttö Trust Layer -kerroksella tarkastusta ja havaittavuutta varten.

Puheluiden mekanismit

Kutsumekanismi riippuu kohdepilvitallennusalustasta ja aktivointikokoonpanosta.

Virheiden käsittely ja palautus

• Hienot varastot – Jos live-kyselyt epäonnistuvat tai ylittävät aikakatkaisun kynnysarvot, palauta automaattisesti välimuistiin tallennetut datakaavion palautukset.
• Timeout Management – Ota käyttöön uudelleenyritys- ja katkaisulogiikka API-kutsuille raskaan kuormituksen ollessa käytössä.
• Virheellinen tunnusten käsittely – Palauta vakiomuotoinen 404 Ei löytynyt vastauksia ei-elämässä oleville profiilien avaimille.
• Skeeman version vahvistus – Vahvista datakaavion version metadata välttyäksesi vastaavuuksilta, kun skeema kehittyy.
• Observability Integration – Kirjaa kaikki virheet, uudet yritykset ja viiveet Trust Layer -mittaristoihin palvelutasosopimuksen valvontaan.

Idempotent-suunnittelussa huomioitavia asioita

• Deterministiset avaimet – Jokainen profiilin nouto käyttää vakaata tunnusta (esimerkiksi IndividualId) varmistaakseen ennustettavissa olevat ja toistamisen turvalliset kyselyt.
• Välimuistin yhdenmukaisuus – Käytä ETag- tai Viimeksi muokatut -otsakkeita ehdollisiin noutoihin ja välimuistin vahvistukseen.
• Atomic Retrieval – Jokainen API-vastaus edustaa yhdenmukaista tilannekuvaa materialisoidusta Data Graph -tietueesta.
• Toisto-suojaus – Varmista, että asiakassovellukset havaitsevat identtiset noutot korrelaatiotunnusten ja aikaleimojen avulla.

Tietoturvassa huomioitavia asioita

• Vahva todennus – OAuth 2.0 yhdistettyjen sovellusten kautta vaatii suojatun ja valtuuksiin perustuvan käyttöoikeuden.
• Sovelluksen tietoinen nouto – Vain suostuneet attribuutit palautetaan. Trust-kerros käyttää suostumussuodattimia automaattisesti.
• Kenttätason hallinta – Attribuuttien käyttöä hallitaan Data 360:n metadatan ja käytäntöjen määritelmien kautta.
• Salaus liikenteessä ja levossa – Kaikki vastaukset salataan TLS 1.2+- ja AES-256-salauksella.
• Tarkastus ja jäljitettävyys – Jokainen profiilien noutotapahtuma kirjataan lokiin tunnisteilla, aikaleimoilla ja käytännön kontekstilla.

Sivupalkit

Aikavyöhyke

• Suunniteltu välittömään noutamiseen.
• Tukee live-kyselyitä päivitetystä datasta, joiden viive on hieman korkeampi (alisekunteina).
• Optimoitu synkronoitaville päätöksenteolle ja interaktiivisille sovelluksille.
• Estää erää edeltävän aktivoinnin tai segmentin uudelleenlaskennan.

Datamäärät

• Soveltuu erinomaisesti yksittäisille tietueiden hauille tai pienille joukkoille (kymmenistä sataan) per pyyntö.
• Ei ole optimoitu suuria joukkopäivityksiä varten. Käytä erä- tai kysely-API-rajapintoja raskaille lukuille.
• Käyttää vaakasuorasti skaalattavaa välimuistiin tallennusta ja esimaterialisointia nopeuttaakseen.

Osavaltioiden hallinta

• Ylläpitää kevyttä käyttöoikeutta ilman tilaa. Jokainen pyyntö on itsenäinen.
• Tukee ylätunnisteiden tallentamista välimuistiin toistoturvallista hakua varten.
• Sovellukset voivat ylläpitää paikallista välimuistia tai istuntojen lyhytaikaista tallennustilaa vähentääkseen toistuvia hakuja.

Monimutkaiset integraatioskenaariot

• Integroi saumattomasti Einstein 1-, Connect API- ja MuleSoft -versioihin yhdistelmädatan käyttökokemuksia varten.
• Voi käyttää tehokkaita järjestelmiä (esimerkiksi Copilot- tai tekoälyn päättelyjärjestelmiä), jotka vaativat välittömästi asiayhteydestä johtuvaa tietoisuutta.
• Yhdistetään reaaliaikaisten käynnistimen datatoimintojen kanssa noudon tai tilan muutoksen yhteydessä.
• Sallii mukauttamisen mittakaavassa vaarantamatta suorituskykyä tai hallintaa.

Esimerkki

Globaali verkkokauppa-alusta käyttää Data 360:n Data Graph API -rajapintaa noutaakseen yhtenäistettyjä asiakasprofiileja reaaliajassa suosituksen järjestelmälleen. Kun käyttäjä kirjautuu sisään, sovellus kutsuu Data Graph -päätepistettä noutaakseen asiakkaan UnifiedCustomerProfile-arvon, joka palauttaa demografiset attribuutit, toimintosignaalit ja lasketut havainnot yhtenä JSON-tietosisällönä. Personalisointijärjestelmä kuluttaa tämän vastauksen millisekunteina määrittääkseen ja näyttääkseen ”Next Best Offer” -arvon aktiivisen istunnon aikana. Kaikkia pyyntöjä hallitaan ja kirjataan lokiin Trust-kerroksen kautta, mikä varmistaa täydellisen näkyvyyden, käytäntöjen noudattamisen ja vaatimustenmukaisuuden vuorovaikutuksessa.

Reaaliaikaiset datatoiminnot sallivat asiakastietojen aktivoinnin heti, kun data muuttuu Data 360:ssa. Sen sijaan, että odottaisit ajoitettuja erävienteitä, nämä toiminnot lähettävät päivityksiä, havaintoja tai käynnistimiä suoraan Salesforceen tai ulkoisiin järjestelmiin millisekunteina. Kun asiakkaan tila, suostumus tai osallistumistietue päivitetään Data 360:ssa, tämä signaali voi välittömästi tarjota henkilökohtaisia tarjouksia, käynnistää Service Cloud -automaatioita tai päivittää kanta-asiakastasoja varmistaakseen, että jokainen asiakaskokemus vastaa ajankohtaista ja yhtenäistettyä totuutta. Tämä kuvio soveltuu erinomaisesti korkean vaikutuksen ja viiveeseen liittyviin käyttötarkoituksiin, kuten henkilökohtaisiin verkkokokemuksiin, petosten havaitsemisen hälytyksiin, Next-best-action-suosituksiin tai reaaliaikaisiin CRM-päivityksiin. Se sulkee datan havaintojen ja liiketoimintatoimintojen välisen aukon ja muuntaa yhtenäistetyn datan ajankohtaiseksi älykkyydeksi.

Konteksti

Nykyiset digitaaliset käyttökokemukset ja toiminnalliset työnkulut vaativat välittömiä, asiayhteydestä riippuvaisia toimintoja tapahtuman tapahtuessa — esimerkiksi asiakastietueen päivittäminen Checkoutin aikana, inventaarion säätäminen palautuksen skannauksen yhteydessä tai henkilökohtaisen tarjouksen toimittaminen, kun käyttäjä hylkää ostoskorin. Reaaliaikaiset datatoiminnot sallivat järjestelmien kutsua, rikastaa ja työstää yhtenäistettyjä Data 360 -profiileja ja laskettuja havaintoja sekuntien ja sekuntien välisellä viiveellä, mikä mahdollistaa interaktiivisen personalisoinnin, toiminnan automatisoinnin ja välittömän päätöksenteon.

Ongelma

Miten sovellukset, käyttöliittymän vuorovaikutuskulut tai middleware voivat soittaa Data 360 -palveluun suorituksen aikana lukeakseen, laskeakseen tai päivittääkseen yhden yhtenäistetyn profiilin tai käynnistääkseen toiminnon (esimerkiksi lähettääkseen tarjouksen, päivittääkseen CRM:n, käynnistääkseen työnkulun) vähällä viiveellä, vahvalla yhdenmukaisuudella ja hallinta-asetuksilla — ilman ajoitettuja erätöitä tai raskaita myyntiputkiä?

Voimat

Tämän kuvion muodostavat useat tekniset, toiminnalliset ja hallinnalliset voimat:

• Vähäisen viiveen vaatimus: Puheluiden täytyy kestää sekunteja tai sekunteja säilyttääkseen hyvän käyttöliittymän tai noudattaakseen palvelutasosopimuksia.
• Deterministinen identiteetin vahvistus: Pyyntöjen täytyy ratkaista oikeaan yhtenäistettyyn yksityishenkilön profiiliin (kultainen tietue) luotettavasti ja nopeasti.
• Pienoisvaltuutus: Reaaliaikaisten puheluiden täytyy noudattaa attribuuttitason käytäntöjä ja suostumusten tarkistuksia pyynnön aikana.
• Korvauskuormituksen minimalismi: Reaaliaikaisten hyötykuormien tulisi olla pieniä ja keskitettyjä (yksittäinen profiili tai pieni attribuuttijoukko) viiveen ja kustannusten vähentämiseksi.
• Kehittäjäkokemus: API-rajapintojen täytyy olla kehittäjäystävällisiä (REST/gRPC/GraphQL), joilla on selkeät skeemat ja vakaat sopimukset tuotantoympäristön käyttöön.
• Tarkastus ja jäljitettävyys: Jokainen reaaliaikainen toiminto täytyy kirjata lokiin sukupuolen, käyttäjän identiteetin ja käytäntöjen päätösten kanssa noudattamista varten.

Ratkaisu

Suositeltu ratkaisu on käyttää Data 360:n reaaliaikaisia datatoimintoja (API + SDK) yhdistettynä reunan välimuistiin tallentamiseen ja vähäisiin laskentatransformaatioihin tarvittaessa. Integraatiot kutsuvat datatoimintojen päätepistettä lukeakseen tai kirjoittaakseen profiilien attribuutteja, laskeakseen havaintoja tai käynnistääkseen orkestrointeja. Käytäntöjen reaaliaikaisia tarkistuksia (CEDAR) ja dynaamista peittämistä sovelletaan käytäntöjen käyttöönottopisteessä ennen kuin tietosisältö palautetaan tai toiminto suoritetaan.

Luonnos

Alla on vaiheiden yhteenveto.

• Client (UI / middleware / POS) lähettää todennettuja datatoimintojen pyyntöjä tunnuksilla ja toiminnon tyypillä.
• API-yhdyskäytävä vahvistaa valtuuden, nopeusrajoitukset ja välittää sen Data 360 Action Serviceen.
• Toimintopalvelu ratkaisee tunnisteen → yhtenäistetty yksityishenkilön tunnus (pikapolun välimuisti; varmuuskopio Kaavio-hakuun).
• Käytännön noudattaminen (PDP) arvioi CEDAR-käytännöt käyttämällä PIP- ja pyyntökontekstista saatuja attribuutteja.
• Jos tämä on sallittu, toimintopalvelu lukee kaikki vaaditut profiilien attribuutit/havainnot ja suorittaa kevyitä transformaatioita.
• Toimintopalvelu palauttaa vastauksen synkronoidusti (esimerkiksi tarjousvaltuus, päivitetty attribuutti) tai asettaa asynkronisen orkestroinnin jonoon ja palauttaa hyväksynnän.
• Kaikki tapahtumat, päätökset ja hyötykuormat kirjataan Trust Layeriin ja välitetään halutessasi SIEM:ään.

Tulokset

• Sovellukset saavat välittömästi käytäntöjen hallitsemien käyttöoikeuksien yhtenäistettyihin profiilien luku/kirjoitus- ja toimintokäynnistimiin, joiden viive on alle sekunnista toiseen.
• Reaaliaikainen personalisointi, päätöksenteko ja toiminnalliset työnkulut (esimerkiksi tarjoukset, agenttien avustaminen, inventaariopäivitykset) ovat käytössä ilman eräviiveitä.
• Kaikki toiminnot ovat auditoitavia, suostumuskohtaisia ja noudattavat attribuuttitason peittämistä yksityisyyden ja vaatimustenmukaisuuden ylläpitämiseksi.

Puheluiden mekanismit

Kutsumekanismi riippuu kohdesovellusalustasta ja aktivointikohteen kokoonpanosta.

Virheiden käsittely ja palautus

• Synkronoidut virheet: Palauta rakenteellisia virhekoodeja, joilla on ihmiselle luettavissa olevia viestejä ja idempotency-valtuuksia.
• Täydellinen uudelleenyritys: Asiakkaiden tulisi yrittää esittää idempotent-pyyntöjä uudelleen 429/5xx-vastausten perusteella.
• Käytännön hylkäämisen käsittely: Hylkääjät palauttavat selkeät syykoodit. Luottamuksellisia tietoja ei koskaan palauteta käytännön epäonnistumisen yhteydessä.
• Asynkronoinnin orkestrointivirheet: Orkestrointityöt siirretään DLQ:ään ja niitä voi toistaa. Työtilan API sallii asiakkaiden kysellä tai vastaanottaa callback-kutsuja.
• Fallback-strategiat: Jos identiteetin ratkaisu epäonnistuu, palauta deterministinen virhe ja halutessasi ehdotettu korjaus (esimerkiksi vaati externalId).

Idempotent-suunnittelussa huomioitavia asioita

• Idempotency-avain: Asiakkaat tarjoavat idempotency-avaimen (UUID + asiakassovelluksen nimitila) toimintojen muuntamiseen.
• Deterministiset avaimet: Käytä komposiittiavaimia (UnifiedIndividualId + ActionType + TimestampWindow) identtisten tietueiden havaitsemiseen.
• Turvalliset uudelleenkerrat: Suunnittele toiminnot kestämään sivuvaikutuksia tai suorittaaksesi lisäosia sokeiden lisäosien sijaan.
• Toisto-suojaus: Säilytä käsitellyt idempotence-avaimet ja TTL ne liiketoimintajakson jälkeen välttyäksesi toistumisilta.
• Valtiottomuus: Pidä synkronoidut toiminnot tilattomina aina, kun se on mahdollista. Pidä asynkronisten työnkulkujen minimitila.

Tietoturvassa huomioitavia asioita

• Todennus: OAuth 2.0 (JWT Bearer tai mTLS palvelutileille); lyhytaikaiset valtuudet ja päivityksen kierrättäminen.
• Valtuutus: Käytännön päätöspiste käyttää attribuutteihin perustuvaa käyttöoikeuksien hallintaa (CEDAR) ja suostumusten tarkastuksia per pyyntö.
• Lähetyksen ja tallennuksen salaus: TLS 1.2+ siirretään, AES-256 on paikallaan välimuistiin tallennetuille fragmenteille tai kirjauslokeille.
• Pienin käyttöoikeus: API-asiakkaat, joiden käyttöoikeudet ovat vähäisiä; roolit on erotettu luku vs kirjoitus vs orkestrointi.
• Datan minimointi: Palauta vain pyydetyt ja suostuneet attribuutit ja käytä dynaamista peittämistä henkilötiedoille/PHI:lle.
• Verkon ohjaimet: Vaadi halutessasi puheluita yksityisistä verkostoista (Private Connect, IP-allowlists) korkean riskin toiminnoille.
• Tarkastus ja valvonta: Kirjaa pyyntöjen metadata, käytännön päätökset, pyynnön tekijän identiteetti ja vastausten tiivisteet Trust Layer- ja SIEM-kokoonpanoihin.

Sivupalkit

Aikavyöhyke

• Suunniteltu synkronoitujen toimintojen keskiarvoisille viiveille sekunnin alapuolella tai pienellä yhdellä sekunnilla.
• Edge-välimuistit (lyhyt TTL) ja esimääritetyt havainnot vähentävät matkoja.
• Asynkronointipolut tarjoavat lähes välittömän hyväksynnän ja taustakäsittelyn raskaille tehtäville.

Datamäärät

• Optimoitu yhden tietueen tai pienen erän vuorovaikutuksille (1–100 tietuetta).
• Ei tarkoitettu joukkoviennoille — käytä eräaktivointia suurille määrille.
• Suuri läpimeno käyttää yhdistämistä/yhteyden uudelleenkäyttöä ja rinnakkaisia orkestrointijonoja.

Osavaltioiden hallinta

• Synkronoitujen puheluiden valtuuttamaton pyyntömalli; minimitoimintojen tila säilytetään apurahoille/transaktioille.
• Muutostapahtumien aiheuttama välimuistin mitätöinti — varmista, että TTL:t ja virheenkorjaus signaalit pitävät välimuistit tuoreina.
• Orkestrointityöt ylläpitävät kestävää tilaa (jobId, status, retries) Trust Layer -kerroksessa.

Monimutkaiset integraatioskenaariot

• Agentin avustin: Reaaliaikainen profiilien haku + laskettu yleisyys palautetaan palvelukonsoliin agenttien sekunneissa.
• POS / Edge-laitteet: Paikallinen SDK + satunnainen datatoiminto tarjousten tai kanta-asiakastilan vahvistamiseksi.
• Hybridikulut: Synkronoi data -toiminto päätöksenteon + asynkronoinnin orkestroinnille päivittääksesi alempia järjestelmiä ja käynnistääksesi kampanjoita.
• ** Kolmannen osapuolen välitysohjelmisto:** MuleSoft- tai API-yhdyskäytävät voivat välittää todennusta, rikastaa asiayhteyttä ja käyttää ylimääräisiä käytäntöjen tarkastuksia.

Esimerkki

Vähittäismyyntisovellus määrittää, näytetäänkö henkilökohtainen pikakuponki, kun shoppailija napauttaa Checkout -painiketta kutsumalla tarjouksen oikeutuksen datatoimintoa, joka sisältää shoppailijan sähköpostin ja ostoskorin asiayhteyden. API-yhdyskäytävä vahvistaa pyynnön ja välittää sen Data Action -palveluun, joka renderöi sähköpostin yhtenäistetyksi yksityishenkilön tunnukseksi käyttämällä välimuistin osumaa, vahvistaa markkinointisuostumuksen PDP:n kautta ja arvioi oikeutuksen asiakkaan elinkaaren arvon ja viimeaikaisten ostosten perusteella. Jos shoppailija hyväksyy sen, palvelu palauttaa allekirjoitetun kuponkivaltuuden ja kirjaa päätöksen lokiin. Kun kuponkien myöntäminen vaatii inventaariovarauksen, ei-synkronoitu orkestrointi käynnistyy varatakseen inventaarion ja ilmoittaakseen CRM-järjestelmille. Sovellus näyttää kupongin välittömästi, kun taas myöhemmät päivitykset suoritetaan taustalla ja Trust kaappaa täydellisen seurannan hallintaa ja vaatimustenmukaisuutta varten.

• Liittimet ja integrointi
• Web & Mobile SDK
• Toisen sekunnin reaaliaikainen syöttö
• Bring Your Own Lake (Zero Copy -kysely)
• Bring Your Own Lake (Zero Copy File)
• Datakaaviot
• Aktivointi: MC-osallistumistoiminto
• Aktivointi: MC Personalisointi
• Aktivointi: B2C Commerce
• Datan jakaminen (Zero Copy)
• Aktivointi: Tiedostojen tallennustila
• Datan toiminnot
• Real-Time Sub-Second Data -toiminnot
• Ulkoinen aktivointialusta