Yritystietojen arkkitehtuurit toimivat harvoin yhdessä järjestelmässä. Salesforce hallitsee asiakkaiden osallistumista, myyntiputkea ja palvelua. Analytics-alustat, kuten Snowflake, sisältävät historiallisia transaktioita, taloustietueita, käyttötietoja ja toimintatilastoja. Tavallisesti näiden kahden maailman yhdistäminen merkitsi ETL-putkien rakentamista ja ylläpitoa: ajoitetut työt, jotka keräävät dataa lähteestä, muuntavat sen ja lataavat kopioita Salesforceen. Näiden myyntiputkien vuoksi data saapuu viiveellä, hallintakäytännöt moninkertaistuvat eri järjestelmissä ja myyntiputket vaativat jatkuvaa huoltoa.

Salesforce Data Virtualization tarjoaa toisen mallin. Sen sijaan, että data siirretään Salesforceen, se sallii Salesforcen kysellä dataa suoraan sen lähteestä, suorituksen aikana, ilman replikointia. Käyttäjät näkevät ulkoista live-dataa Salesforcen vakiomuotoisten käyttöliittymien kautta. Data ei koskaan poistu sen arvovaltaisesta aloitussivusta. Tämä asiakirja selittää miten kuvio toimii, milloin käyttää sitä ja miten pääset alkuun käyttämällä Snowflakea konkreettisena työskennellyn esimerkkinä.

Salesforce Data Virtualization on integrointiarkkitehtuurin kuvio, jonka avulla Salesforce voi kysellä dataa suoraan ulkoisista järjestelmistä suorituksen aikana kopioimatta tai kopioimatta dataa Salesforcen tallennustilaan. Sen sijaan, että sovellusalusta siirtäisi dataa, se lähettää kyselyn ulos.

Tästä syystä Salesforce-käyttäjät vuorovaikuttavat ulkoisen datan kanssa Salesforcen tuttujen käyttöliittymien (kuten sivuasetteluiden, viiteluetteloiden, raporttien tai kulkujen) kautta, kun taas tiedot säilyvät sen arvovaltaisessa lähdesysteemissä. Hallinta, käyttöoikeuksien hallinta ja datan sijainti pysyvät paikallaan.

Tämä kuvio perustuu yhteen arkkitehtoniseen periaatteeseen: data pysyy lähteessä. Laskutoimi siirtyy dataan.

Useimmat Salesforce-yritysten käyttöönotot integroituvat ulkoisiin datalustoihin (kuten datan varastoihin, toiminta-tietokantoihin tai analyyttisiin myymälöihin) replikointiputkien kautta. Myyntiputket keräävät, muuntavat ja lataavat dataa Salesforceen ajoitetusti. Tämä lähestymistapa toimii, mutta replikointi aiheuttaa rakenteellisia kompromisseja:

• Replikoitu data viivästyy aina. Myyntiputki aiheuttaa viiveitä ja vanhentunut data aiheuttaa huonoja päätöksiä.
• Jokainen datan kopiointi laajentaa vaatimustenmukaisuutta. Useiden järjestelmien luottamukselliset tiedot (kuten henkilötiedot, taloustietueet tai terveystiedot) vaativat useiden hallintakäytäntöjen ylläpitoa.
• Myyntiputket vaativat jatkuvaa toiminta-investointia, valvontaa, virheiden käsittelyä, skeeman drift-hallintaa ja jälkikäsittelylogiikkaa.

Datan virtualisointi korjaa nämä kompromissit suoraan. Se poistaa myyntiputken kokonaan raskaista käyttötarkoituksista, pitää datan arvovaltaisessa sijainnissaan ja tarjoaa Salesforce-käyttäjille ulkoisen datan reaaliaikaisen, hallitun näkymän ilman replikoinnin ylimääräisiä kustannuksia.

Salesforce Connect on sovellusalustan ominaisuus, joka ottaa datan virtuaalisoinnin käyttöön Salesforcessa. Se tarjoaa sovittimen kehyksen, joka kääntää SOQL-kyselyt ulkoisen järjestelmän kyselykielelle, hallitsee todennettuja callout-kutsuja ja kartoittaa tulosjoukot takaisin Salesforce-kenttätyyppeihin. Se sisältää Ulkoiset objektit -ominaisuuden, joka on Salesforcen metadata-rakenne, joka esittää ulkoista dataa kyseltavinä, sovellusalustan natiiveina entiteetteinä replikoimatta dataa Salesforce-tallennustilaan. Ulkoiset objektit käyttäytyvät Salesforcen vakio-objektien tavoin — näkyvissä sivuasetteluissa, viiteluetteloissa ja raporteissa sekä SOQL:n ja vakiomuotoisten API-rajapintojen kautta — mutta ne eivät sisällä dataa. Ulkoiset objektit ovat skeemaprojektio lähdejärjestelmässä.

Ulkoiset objektit ovat ensisijainen mekanismi, jonka kautta datan virtuaalisuus esittää ulkoista dataa Salesforcessa. Ne toimivat Salesforcen vakio-objektien tavoin: kyseltavissa SOQL:n kautta, näkyvissä sivuasetteluissa ja viiteluetteloissa ja käytettävissä Salesforcen vakiomuotoisten API-rajapintojen kautta. Tärkein eroavaisuus on, että dataa ei säilytetä Salesforcessa. Ulkoinen objekti on skeemaprojektio: ulkoisen datan ulkoisen ulkoisuuden määritelmä, ei kopio itse datasta.

Kun käyttäjä lataa sivun tai suorittaa ulkoiseen objektiin viittaavan raportin, Salesforce suorittaa ulkoiselle järjestelmälle live-kyselyn ja palauttaa vain vuorovaikutukselle määritetyn tuloksen.

Kun Salesforce suorittaa SOQL-kyselyn ulkoiselle objektille, se kääntää suodattimet (WHERE-lausekkeet), lajittelujärjestykset (ORDER BY) ja rajoitukset (LIMIT) vastaavaan SQL-tiedostoon ja lähettää ne ulkoiseen järjestelmään. Ulkoinen järjestelmä suorittaa kyselyn omalle laskentajärjestelmällään ja palauttaa vain suodatetun tulosjoukon. Työ tapahtuu missä data on, ja vain vastaus siirtyy takaisin Salesforceen.

Datan virtuaalisuus käyttää kahta itsenäistä suojauskerrosta samanaikaisesti. Ulkoinen järjestelmä käyttää kyselyn suorituksen aikana omia käyttöoikeuksiaan, mukaan lukien rivitason suojaus, sarakkeiden peittäminen ja rooleihin perustuvat käyttöoikeudet. Salesforce käyttää omaa suojausmalliaan ylälaidassa: profiilit, käyttöoikeusjoukot, kenttätason suojaus ja jakosäännöt. Molemmat kerrokset ovat aktiivisia jokaiselle kyselylle. Kumpaakaan ei korvata toista.

Arkkitehdit kuvailevat datan virtuaalisuutta usein "nollakopiokuvakkeena". Nollakopiointi tarkoittaa, että Salesforce-tallennustilaan ei ole jatkuvaa replikointia. ETL-putkea ei ole, joka kirjoittaisi tietueita Salesforce-objekteihin. Paikallisen kopion luomiseen ei ole ajoitettu synkronointia. Ulkoinen objekti ei sisällä rivejä.

Nollakopiointi ei tarkoita, että datan siirtoa olisi nolla. Joka kerta, kun käyttäjä kyselee Ulkoinen objekti -objektia, tulosjoukko siirtyy ulkoisesta järjestelmästä Salesforceen verkon kautta. Suurien tulosjoukkojen tai kyselyiden yleisyyden osalta datan lähtökustannukset ja verkkoviive ovat todellisia tekijöitä, joille arkkitehdit voivat suunnitella. Tämä ei rajoita piilottamista: on design-rajoitus, joka otetaan huomioon.

Ota seuraavat arkkitehtuuriset eroavaisuudet huomioon, jos käyttötarkoituksesi vaatii suuria määriä, usein käytettäviä kohteita tai vähän viiveitä.

Snowflake on yksi yleisimmistä ulkoisista järjestelmistä, jotka on yhdistetty Salesforceen datan virtuaalisoinnin kautta. Se toimii konkreettisena esimerkkinä siitä, miten kuvio toimii loppuun asti.

Tässä kokoonpanossa Salesforce muodostaa yhteyden Snowflakeen käyttämällä Salesforce Connectia SQL-sovittimella Snowflakea varten. Snowflake-taulukot ja -näkymät näytetään ulkoisina objekteina Salesforcessa. Kun käyttäjä kyselee Ulkoinen objekti -objektia, Salesforce kääntää SOQL:n SQL:ään ja lähettää sen Snowflake Statements API -rajapintaan todennetun HTTPS-kutsun kautta. Snowflake suorittaa kyselyn virtuaaliselle varastolleen, käyttää omaa rivitason suojaustaan ja sarakkeiden peittämistä ja palauttaa vain tulosjoukon. Tietoja ei kirjoiteta Salesforce-tallennustilaan missään vaiheessa.

Salesforce Connect käyttää valtuutettua OAuth 2.0 -mallia todentaakseen itsensä Snowflakella. Avainkomponentit ovat:

• Todentaja: Hallitsee OAuth-rakennetta Snowflakella. Käsittelee valtuuspyynnöt ja kartoittaa palautetun valtuuden Salesforce-tunnukseen.
• Ulkoinen tunnus: Pidättää OAuth-käyttöoikeus- ja päivitysvaltuudet turvallisesti Salesforcen salattujen tunnusten säiliössä ja injektoi ne lähteviin callout-kutsuihin.
• Nimetty tunnus: Määrittää Snowflake-päätepisteen URL-osoitteen ja viittaa Ulkoinen tunnus -kenttään.
• Snowflake-suojauksen integrointi: Rekisteröi Salesforcen luotetuksi OAuth-asiakassovellukseksi Snowflakessa. Määrittää sallitun uudelleenohjauksen URI-osoitteen, OAuth-kulut ja valtuuden TTL-koodin.

Nämä komponentit muodostavat riippuvuusketjun: Ulkoinen tietolähde viittaa nimettyyn tunnukseen, joka viittaa ulkoiseen tunnukseen, joka viittaa todentajaan. Tämän ketjun ymmärtäminen on tärkeää, kun ratkaiset yhteys- tai käyttövirheitä.

Salesforce tukee kahta henkilöllisyyden valtuutusmallia, kun todennetaan Snowflakella:

• Nimetty vastuuhenkilö: Yksi jaettu palvelutili todentaa kaikki Salesforce-käyttäjät Snowflakelle. Tämä on yksinkertaisempaa määrittää, mutta sillä ei ole käyttäjäkohtaista tarkastettavuutta tai hienosäätettyä Snowflake-käyttöoikeuksien hallintaa.
• Käyttäjäkohtainen vastuuhenkilö: Jokainen Salesforce-käyttäjä todentaa itsensä omalla OAuth-valtuudellaan. Tämä mahdollistaa Snowflake-rivitason suojauksen ja käyttäjäkohtaisten tarkastusketjujen täydellisyyden, ja vähentää korkeampien valtuuksien hallinnan kokonaiskustannuksia (käyttäjäkohtaiset OAuth-kulut, päivitys, kumoaminen).

Päätöksen ohje: Käytä käyttäjäkohtaista periaatetta säännellyille tiedoille tai henkilötiedoille (Personally Identifiable Information, PII). Käytä nimettyä vastuuhenkilöä, kun Salesforcen jakosäännöt tarjoavat riittävät käyttöoikeudet ja yksinkertaisuus on tärkeintä.

Nämä Salesforce-hallintarajoitukset määrittävät ratkaisun suunnittelun suoraan, kun käytät ulkoisia objekteja Snowflakella:

• Callout-rajoitus: 100 per Apex Sivut tai kulut, joilla on useita Ulkoinen objekti -kyselyitä, voivat saavuttaa tämän rajoituksen nopeasti.
• Callout-kutsun aikakatkaisu: Enintään 120 sekuntia. Pitkäkestoiset Snowflake-kyselyt aiheuttavat suorituksen aikaisen poikkeuksen.
• SOQL-rivien rajoitus: 50 000 riviä. Sivuttaa suuria tulosjoukkoja.
• Asynkronointirajoitukset: Apex ja useimmat asynkronoidut asiayhteydet rajoittavat callout-kutsuja. Pidä ulkoisten objektien käyttöoikeudet synkronoitujen transaktioiden rajoissa. Jos käytät ulkoisia objekteja kyseleviä ei-synkronoituja käyttötarkoituksia, harkitse jatkokutsut käyttäjien käynnistämille ei-synkronoiduille vuorovaikutuksille tai rakenna kulku suorittaaksesi ulkoisen datan käyttöoikeuksia synkronoidussa transaktiossa ja välittääksesi tuloksia ei-synkronoidusti.

Suunnittelua koskevia ohjeita: Älä kysele Ulkoiset objektit -objektia silmukoissa. Paina WHERE-lausekkeen suodattimet Snowflakeen pienentääksesi tulosten kokoa ja kutsun yleisyyttä.

Jokainen Salesforcelle Snowflakeen lähetettävä kysely kirjataan Snowflake-kyselyhistoriaan suorituksen täydellä metadatalla: viive, skannatut rivit, käytetty varasto ja suoritettava identiteetti. Tämä historia tarjoaa kokonaisvaltaisen tarkastuksen Salesforce-käyttäjän toiminnoista Snowflake-suoritukseen, ja se on ensisijainen diagnostinen työkalu suorituskyvyn hienosäätämiseen ja käyttöoikeuksien vahvistamiseen.

Datan virtualisointi soveltuu hyvin tapauksiin, joissa reaaliaikainen käyttöoikeus, hallinta ja vähennetty replikointi ylittävät yhdistetyn kyselyn aikaisen käyttöoikeusmallin rajoitukset.

Käytä sitä, kun:

• Lukuun perustuva analyysi on ensisijainen vaatimus. Jos käyttäjien täytyy kysellä ja näyttää ulkoista dataa Salesforce-käyttöliittymissä, raporteissa tai kuluissa kirjoittamatta sitä takaisin, datan virtuaalisuus välttää myyntiputken ylittymisen Vain luku -skenaarioissa.
• Datan tuoreus on tärkeää. Kun replikoitujen tietojen vanhentuminen aiheuttaa liiketoimintariskiä (kuten vanhentuneita finanssisaldoja, inventaariotasoja tai vaatimustenmukaisuuden tiloja), yhdistetty malli varmistaa, että jokainen kysely vastaa live-dataa.
• Julkaisun ja datan oleskelun vaatimukset ovat tiukkoja. Kun luottamuksellisten tietojen kopiointi Salesforceen on kielletty lakisääteisten tai sopimusten rajoitusten vuoksi, virtuaalisuus säilyttää datan sen arvovaltaisessa sijainnissa ja sallii sen käytön Salesforcessa. Vain yksi järjestelmä säilyttää tiedot.
• Kaksikerroksinen käyttöoikeuden hallinta vaaditaan. Kun ulkoisen järjestelmän natiiviset käyttöoikeusjoukot ja Salesforce-suojausmalli ovat käytössä samanaikaisesti, yhdistetty malli ottaa molemmat käyttöön ilman datan kaksoiskappaleita.
• Ulkoinen järjestelmä on jo tietueiden valtuutettu järjestelmä. Jos data on jo puhdas, hallittava ja kyseltavissa lähdejärjestelmässä, sen virtualisointi välttää tarpeettoman transformaation, tallennuskustannusten ja eroavaisuuksien riskin.

Vältä sitä, kun:

• Vähäisen viiveen kirjoittaminen vaaditaan. Ulkoiset objektit ovat Vain luku -muotoisia. Takaisinkirjoitusten käyttötarkoitukset vaativat eri integraatiokuviota.
• Monimutkaisia usean objektin liitoksia tarvitaan. Useiden ulkoisten objektien SOQL ei tue liitoksia. Esimatertifioi liitetty data yhdeksi näkymäksi lähdejärjestelmässä.
• Salesforcen tekoäly- tai Agentforce-ominaisuudet vaativat natiivitietoja. Tällä hetkellä Einstein ja Agentforce (mukaan lukien Einstein Copilot -pohja, ennakoiva pisteytys ja Agentforce) toimivat Salesforcen natiivisissa objekteissa. Nämä ominaisuudet eivät tue ulkoisia objekteja perustamis- tai aktivointitietolähteenä. Jos tämän datan tekoälyn aktivointi on käytettävissä, Salesforce Data 360 on suositeltu täydentävä ratkaisu.
• Yleisen yleisyyden ja raskaan käytön kuviot. Ulkoiset objektit on suunniteltu käytettäväksi tarvittaessa. Työnkuormat, jotka käynnistävät satoja kyselyitä minuutissa, rajoittavat päästöhallintaa ja heikentävät suorituskykyä.

Seuraavat käyttöskenaariot osoittavat, miten Salesforce-datan virtuaalia käytetään yleisissä yrityskenaarioissa. Jokainen esimerkki käyttää ulkoisena järjestelmänä Snowflakea, mutta sen perustana oleva kuvio koskee kaikkia SQL-yhteensopivia tietolähteitä, joita Salesforce Connect tukee.

Haaste: Tukitiimit tarvitsevat yhtenäistettyjä raportteja, jotka yhdistävät Salesforce Case -dataa Snowflakeen tallennettujen lippujen määrään, ratkaisuaikaan ja eskalointitilastoihin. Tämän datan replikointiputken rakentaminen ja ylläpito johti viiveeseen ja lisäsivät Vain luku -raportoinnin käyttötarkoitukseen liittyviä kustannuksia.

Ratkaisu: Tiimi paljasti Snowflake-näkymät, jotka sisältävät tiketin tilastoja ulkoisina objekteina Salesforcessa. Tiimi on määrittänyt Salesforce-raportit liittääkseen tapaus-objektit ulkoisen tiketin dataan.

Tulos:

• Raportit vastaavat aina live- Snowflake-dataa. Ei myyntiputken viive.
• Luottamuksellisten tukitilastojen hallinta säilyy Snowflakessa.
• Ei ETL-putkea, jota voi rakentaa, valvoa tai ylläpitää.

Haaste: Finanssitiimi ylläpiti Snowflakessa luotettavia luotto- ja saldetietoja. Näiden arvojen kopioiminen Salesforceen käänteisen ETL:n kautta johti replikoinnin viiveeseen, jolloin myyntiedustajat sitoutuivat kauppojen tekemiseen vanhentuneiden luottotietojen perusteella. Vaatimustenmukaisuustiimi merkitsi myös riski, että luottamuksellisia taloustietoja säilytetään Salesforce-tallennustilassa.

Ratkaisu: Tiimi virtuaalisensi Snowflake-rahoitusnäkymän ulkoiseksi objektiksi ja julkaisi sen tilien sivuasettelussa. Myyntiedustajat näkevät nyt live-hyvitystilat osana vakiomuotoista tilinäkymää Salesforcessa.

Tulos:

• Kaikkien tilien sivujen reaaliaikaiset luottotiedot. Ei viive.
• Finanssitietojen käänteinen ETL-myyntiputki poistettu käytöstä.
• Luottamuksellisia taloustietoja ei kopioida koskaan Salesforce-tallennustilaan. Vaatimustenmukaisuuden vaikutusalue pysyy Snowflakessa.

Haaste: Yhdistämisen aikana hankkivan yrityksen oli annettava Salesforce-käyttäjille pääsy liiketoimintatietoihin kuudesta raskaan Snowflake-datajoukosta, jotka kattavat transaktiot, laskutuksen ja käytön. Teratavujen datan replikointi Salesforceen ei ollut mahdollista yhdistämisen aikajanalla, ja mukautettujen ETL-putkien rakentaminen jokaiselle datajoukolle olisi vaatinut merkittäviä insinööri-investointeja.

Ratkaisu: Tiimi määritti ulkoiset objektit kaikille 6 Snowflake-datajoukolle käyttämällä Salesforce Connectia, jolla on vähiten käyttöoikeuksia omaava integraatiorooli. Mukautettua koodia ei vaadita. Kyselyt suoritetaan suoraan Snowflakessa ja kaikki toiminnot kirjataan Snowflake-kyselyhistoriaan vaatimustenmukaisuusraportointia varten.

Tulos:

• Täysin deklaratiivinen kokoonpano. Ei vaadi mukautettua koodia tai myyntiputkea.
• Tietojen tuoreus taattu. Jokainen kysely vastaa live- Snowflake-dataa suorituksen aikana.
• Täysi seuranta Snowflake-kyselyhistoriassa sääntely- ja vaatimustenmukaisuusraportointia varten.

Datan virtualisointi tuo käyttöön erillisen toimintaprofiilin. Suunnittelu näille virheiden skenaarioille:

• OAuth-valtuuden vanhentuminen: Valtuuksilla on lopullinen elinkaari (TTL). Vanhentuneet valtuudet aiheuttavat callout-kutsujen virheitä. Valvo 401-vastausten valtuuttamista ja käytä päivityslogiikkaa.
• Varaston kylmä-aloitus (Snowflake-kohtainen): Automaattisesti keskeytetyt varastot lisäävät 5–30 sekuntia ensimmäiseen kyselyyn. Jos käyttäjille on asetettu käyttötarkoituksia, jotka vaativat viiveitä, käytä ajoitettua kevyttä kyselyä toimistoaikojen aikana.
• Roolin vastaavuus: Ulkoisessa järjestelmässä määritetty rooli voi palauttaa nollia rivejä hiljaa virheen sijaan. Vahvista roolien ja objektien käyttöoikeudet ulkoisessa järjestelmässä Salesforcesta riippumatta.
• Tulosjoukon ylivuoto: Ylimääräiset hyötykuormat ylittävät API-rajoitukset. Käytä aina LIMIT-lausekkeita ja paljasta suodatetut näkymät raakataulukoiden sijaan.
• Ulkoinen järjestelmäkatkos: Varastoa tai välimuistia ei ole. Käännä callout-kutsuja try/catch-tilassa ja näytä virhetilat käyttöliittymässä. Harkitse tasoitettua lähestymistapaa tehtävien kriittiselle datalle: virtualisoida reaaliaikaista käyttöä varten ja ylläpitää kevyitä replikoituja varastoja kriittisimmille kentille varmistaaksesi käytettävyyden lähdejärjestelmän käyttökatkosten aikana.

Salesforce-datan virtualisointi noudattaa seuraavia Salesforcen hyvin rakennetun kehyksen pilareita.

• Trust: Delegoitu OAuth 2.0 -malli ja vähiten etuoikeutettujen roolien ohjeet vastaavat Trustia. Kaksikerroksinen käyttöoikeuden hallinta (lähdejärjestelmä + Salesforce) noudattaa puolustusta syvällisesti.
• Luotettavuus (virheiden toleranssi): Epäonnistumistilat-osio käsittelee luotettavuutta suoraan: valtuuden vanheneminen, kylmä alkamisaika, roolin väärinkokoonpano, tulosjoukon ylivuoto ja käyttökatkoksen käsittely edustavat erillistä vikaluokkaa, jolla on dokumentoitu ratkaisupolku.
• Luotettavuus (skaalattavuus): Kyselyiden pikavalinnat, varaston koon ohjeet ja callout-rajoitusten tietoisuus optimoivat suorituskyvyn Salesforcen hallintarajoitusten sisällä, mikä on luotettavuutta koskeva huolenaihe ratkaisuille, jotka toimivat laajalti.
• Operational Excellence: Snowflake-kyselyhistoria ensisijaisena havaittavuustyökaluna tukee operatiivista huippuosaamista: arkkitehdit tekevät tarkoituksenmukaisen ja jäljitettävän valinnan käyttääkseen sovellusalustan omia työkaluja suorituskyvyn ja suorituskyvyn tarkastuksen suorittamiseen sen sijaan, että rakentaisivat mukautettua lokien infrastruktuuria.

Tämä osio tarjoaa arkkitehdeille ja suunnittelijoille rakenteellisen aloituspisteen datan virtualisointikuvion rakentamiseen sandbox-ympäristössä. Se ei ole täydellinen toteutusopas — käsittele sitä vahvistettuna päätösten ja määritysvaiheiden sarjana, joka ohjaa ensimmäisen käsitteesi.

Varmista seuraavat asiat ennen kokoonpanotyön aloittamista:

• Lisenssi-oikeutus: Salesforce Connect ei sisälly kaikkiin Salesforce-versioihin. SQL-sovitin Snowflake vaatii erillisen lisäosalisenssin Salesforce Connect -perusoikeuden lisäksi. Vahvista molemmat organisaatiossasi ennen jatkamista.
• Sandbox ensin: Suorita kaikki vaiheet sandbox-ympäristössä ennen kokoonpanosi ylentämistä tuotantoympäristöön.
• Snowflake-käyttöoikeus: Varmista, että sinulla on oikeus luoda suojausintegraatio Snowflakessa ja pääsy kohdetietokantaan, skeemaan ja objekteihin.
• Sovittimen versio: Varmista, että SQL-sovitin Snowflakeen on käytettävissä organisaatiosi Edition-versiossa ja että Snowflake-tilisi URL-osoite ei sisällä alaviivoja (korvaa ne väliviivoilla, jos sellainen on). Tämä on Salesforce Platform -rajoitus callout-isäntänimen ratkaisemiselle).

Datan virtualisoinnin määrittäminen ulkoisella SQL-järjestelmällä, kuten Snowflake, on deklaratiivinen, kokoonpanoon perustuva prosessi – mukautettua koodia ei tarvita. Määritykset noudattavat kolmea peräkkäistä vaihetta: identiteetin ja Trustin luominen, datapinta-alan määrittäminen ja datan näyttäminen loppukäyttäjille.

Tämä vaihe luo Salesforcen ja ulkoisen järjestelmän välille turvallisen ja valtuutetun OAuth 2.0 - Trust -ketjun. Suorita tämä vaihe ennen kuin aloitat tietopinta-alan kokoonpanon.

1. Luo todentaja Salesforcessa. Käytä OpenID Connect -tyyppiä. Käytä paikanpitäjäarvoja tässä vaiheessa — palaa ja suorita se loppuun, kun olet noutanut arvot ulkoisesta järjestelmästä. Kun olet tallentanut, Salesforce luo callback-URL-osoitteen. Säilytä tämä arvo.
2. Rekisteröi Salesforce ulkoisessa järjestelmässä OAuth-asiakassovelluksena. Snowflakessa tämä tarkoittaa suojausintegraation luomista (OAuth, Luottamuksellinen asiakassovelluksen tyyppi). Syötä uudelleenohjauksen URI-osoitteeksi Salesforcen callback-URL. Nouda Client ID-, Client Secret-, Authorization URL- ja Token URL -kentät integraatiosta luomisen jälkeen.
3. Valmista todentajan kokoonpano loppuun. Palaa Salesforcen todentajaan ja täytä se ulkoisesta järjestelmästä haetuilla arvoilla: Kuluttaja-avain, Kuluttajasalaisuus, Valtuutuksen URL ja Valtuuden URL.
4. Luo ulkoinen tunnus. Määritä protokollaksi OAuth 2.0, linkitä se todentajaan ja lisää vastuuhenkilö (nimetty tai Käyttäjäkohtainen, perustuen henkilöllisyyden mallisi päätökseen). Tämä objekti hallitsee OAuth-valtuuden elinkaarta.
5. Luo nimetty tunnus. Määritä päätepiste ulkoisen järjestelmän API-URL-osoitteeseen (esimerkiksi https://<account>.snowflakecomputing.com/api/v2/statements/) ja linkitä se ulkoiseen tunnukseen.
6. Myönnä profiilille ulkoisen tunnuksen käyttöoikeus. Ilman tätä vaihetta käyttäjät eivät voi kutsua yhdistettyjä kyselyitä, vaikka kaikki muut kokoonpanot olisivat oikein.
7. Aloita OAuth-kulku suorittaaksesi todennuksen loppuun. Käynnistä OAuth-rakennus Salesforcesta. Sovellusalusta ohjaa ulkoiseen järjestelmään sisäänkirjautumiseen, vahvistaa tunnukset ja tallentaa tuloksena olevat tokenit turvallisesti ulkoiseen tunnukseen. Tämä vaihe sitouttaa käyttäjän asiayhteyden käypiin valtuuksiin. Kaikki yhdistetyt kyselyt epäonnistuvat, kunnes tämä vaihe on suoritettu.

Tämä vaihe yhdistää Salesforcen ulkoiseen datan skeemaan ja luo Ulkoinen objekti -määritelmät, joita käyttäjät ja sovellusalusta kyselevät.

1. Luo ulkoinen tietolähde. Valitse sopiva sovitin (esimerkiksi SQL-sovitin Snowflakeen), osoita se kohdetietokantaan ja skeemaan ja linkitä se vaiheessa 1 luomaasi nimettyyn tunnukseen.
2. Vahvista yhteys. Käytä ulkoisen tietolähteen sisäänrakennettua vahvistusta. Onnistunut tulos vahvistaa, että OAuth Trust -ketju on valmis ja ulkoinen järjestelmä on käytettävissä.
3. Synkronoi metadata. Käynnistä metadatan synkronointi ulkoisesta tietolähteestä. Salesforce tarkastaa kohdeskeeman ja luo Ulkoisten objektien määritelmät kartoittamalla ulkoiset sarakkeet Salesforce-kenttätyyppeihin.
4. Valitse ja näytä vaaditut taulukot tai näkymät. Valitse ulkoiset taulukot tai näkymät, jotka näytetään ulkoisina objekteina. Suosittelemme näyttämään kerätyt näkymät raakataulukoiden sijaan. Näkymät sallivat sarakkeiden esikatselun, rivitason rajoitukset ja tarkemman hallinnan siitä, mitä Salesforce-kerros voi käyttää.

Tässä vaiheessa ulkoiset objektit näytetään ja niitä voidaan käyttää Salesforce Lightning Experiencen loppukäyttäjille.

1. Luo välilehtiä ulkoisille objekteille. Välilehdet sallivat ulkoisten objektien navigoinnin suoraan Lightning.
2. Lisää ulkoiset objektit sivuasetteluihin. Näytä asiaankuuluva ulkoinen data Salesforce-natiivi-tietueiden vieressä (lisää esimerkiksi Snowflake-rahoitusnäkymä tilien sivuasetteluun).
3. Lisää viiteluetteloihin. Sisällytä ulkoiset objektit viiteluetteloihin tarjotaksesi käyttäjille yhtenäisen näkymän sisäiseen ja ulkoiseen dataan asiayhteydessä.
4. Vahvista kyselyn liittäminen loppuun asti. Lataa sivu tai suorita kysely, joka viittaa Ulkoinen objekti -objektiin. Tarkasta sitten ulkoisen järjestelmän kyselyhistoria (esimerkiksi Snowflake-kyselyhistoria) varmistaaksesi, että kysely suoritettiin lähteestä. Varmista, että oikea rooli, varasto ja henkilöllisyys suorittivat kyselyn.

Kun kaikki kolme vaihetta on suoritettu, Salesforce-käyttäjät voivat vuorovaikuttaa ulkoisen live-datan kanssa Salesforcen vakiomuotoisten käyttöliittymien kautta ilman, että tietävät, että tiedot ovat peräisin Salesforcesta.

Salesforce Data Virtualization korvaa replikointiin perustuvan integraation kyselyn aikaisella yhdistämisellä. Data pysyy sen arvovaltaisessa lähteessä. Salesforce-käyttäjät käyttävät sitä tavallisten sovellusalustan käyttöliittymien kautta. Rakennettavaa myyntiputkea, hallittavia kopioita tai hallittavia viiveitä ei ole.

Tämä kuvio on oikea valinta, kun raskaan lukuoikeuden, reaaliaikaisen datan tuoreuden, tiukan hallinnan ja kaksinkertaisen käyttöoikeustason hallinta ovat ensisijaisia tekijöitä. Se on väärä valinta, kun kirjoitukset vaaditaan, kun tekoälyn tai automatisoinnin ominaisuudet ovat riippuvaisia Salesforce-natiiviobjekteista tai kun käyttöoikeuskuviot ovat liian yleisiä hallintarajoituksille.

Snowflake kuvaa kuvaa hyvin: hallittu, kyselyn aikana muodostettu yhdistetty yhteys, joka on luotu deklaratiivisesti ilman mukautettua koodia, joka voidaan havaita lopusta loppuun Snowflake-kyselyhistorian kautta ja jota voidaan noudattaa sekä Snowflake-natiivi-käyttöoikeuksien ohjaimien että Salesforcen täyden suojausmallin kautta.

Ennen kuin sitoudut tähän arkkitehtuuriin, vahvista lisenssin oikeutus, arvioi hallintarajoitukset odotettujen käyttöoikeuskuviesi perusteella ja vahvista OAuth-valmius sandbox-ympäristössä. Kuvio palkitsee harkitun esikatselun: Tarkastele identiteettimallia, tunnusten ketjua ja strategiaa oikein, jolloin toimintajalanjälki on minimaalinen.

Yugandhar Bora on Salesforcen ohjelmistotekniikan arkkitehti, joka on erikoistunut Data & Intelligence -sovellusalustan datan arkkitehtuuriin. Hän johtaa Enterprise Architecture Review Board (EARB) -aloitteita, jotka keskittyvät datan hallintaan ja yhtenäistettyihin datamalleihin, ja työskentelee samalla automatisoitujen sovellusalustan provisiointiratkaisujen parissa.