Missä nämä tiedot asuvat?

🌐 Saatavilla myös 28 kielellä

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Español (México) · Français (Canada) · Deutsch (Schweiz)

Kuva on luotu tekoälyllä

Tekoälyn kääntämä. Yhteisö ei ole vielä tarkistanut käännöstä. Lue englanniksi

Moduuli 4/10 luvussa Salesforcen tietoarkkitehtuuri, Data Architect -kurssin luku 3. Jokainen moduuli on itsenäinen. Edellinen: Rakenna omasi: mukautetut objektit · Seuraava: Valitse oikea objekti

Kysymys, johon tämä moduuli vastaa: ennen kuin luot objektin, missä näiden tietojen oikeastaan pitäisi asua: coressa Salesforcessa, viitattuna sieltä, missä ne jo ovat, vai arkistoituna?

Kysyn sinulta jotain. Uusi vaatimus tupsahtaa pöydällesi. Mitä teet ensimmäiseksi?

Jos olet kuin useimmat meistä, avaat Setupin ja luot mukautetun objektin. Ymmärrän sen. Kymmenessä minuutissa sinulla on välilehti, sivuasettelu ja luettelonäkymä. Ja tämän sanon jokaiselle ryhmälle: sillä hetkellä, kun luot tuon uuden objektin, ajattelet jo arkkitehtina, tarkoitit sitä tai et. Koska jokainen luomasi objekti on sitoumus. Se vie tallennustilaa. Se kerää rajoja. Se saa jakamismallin, suunnittelitpa sellaisen tai et. Se tarvitsee lisenssin jokaiselle, joka koskee siihen. Ja kun ihmiset ja integraatiot ovat siitä riippuvaisia, onnea sen poistamiseen.

Ensimmäinen arkkitehtuuripäätös ei siis ole mikä objekti. Se on missä näiden tietojen pitäisi asua? Kun saat sen oikein, objektityyppi melkein valitsee itse itsensä.

Coressa ja coren ulkopuolella

Ensin sana, jota käytän paljon: core. Core on Salesforce-alusta, jolla orgisi pyörii: moduulin 1 metatietovetoinen, monivuokralainen alusta, jossa moduulin 2 myynti- ja palveluobjektit asuvat, samoin kuin jokainen mukautettu objekti, jonka rakennat moduulissa 3. Kun sanon, että tiedot ovat coressa (on core), tarkoitan, että ne on tallennettu orgiisi, sen objekteihin.

Kaikki tiedot eivät asu siellä. Data 360 pitää tietonsa omassa tallennuksessaan, orgisi objektien ulkopuolella (se on lähellä corea, near-core: sitä hallitaan coressa, mutta sen tiedot sijaitsevat coren ulkopuolella; lisää luvussa 4). Ja sitten on kaikki se, mitä yrityksesi pyörittää ja mikä ei ole Salesforcea lainkaan: ERP, varasto, tilausjärjestelmä, kumppanin alusta. Kaikki se on coren ulkopuolella (off core). Salesforce voi tavoittaa sen, näyttää sen ja käyttää sitä, mutta orgisi ei tallenna sitä.

Coressa on kahdenlaisia objekteja, jotka oikeasti sisältävät tietueesi: sObjektit, vakio- ja mukautetut (__c), sekä big objectit (__b). Coren ulkopuolella tietoihin päästään ulkoisten objektien (__x) ja muiden integraatiotyökalujen kautta. Pidä moduulin 3 jälkiliitteet mielessä; ne kertovat pelkästä nimestä, missä tieto asuu.

Ajattelen sitä toimistona. Jotkin asiat kuuluvat työpöydällesi, jossa käytät niitä joka päivä. Jotkin asiat sinun tarvitsee vain katsoa jonkun toisen arkistokaapista. Ja jotkin asiat menevät laatikoihin takapihan vajaan. Siitä saan kolme vastausta.

1. Coressa: se asuu työpöydälläsi

Tiedot luodaan, niitä muutetaan ja käytetään Salesforcessa joka päivä: tilit, tapaukset, myyntimahdollisuudet, työtilaukset. Niiden pitäminen sObjekteissa on kuin pitäisi ne toimiston etuosassa. Tätä varten vakio- ja mukautetut objektit ovat olemassa, ja saat kaiken: sivuasettelut, jakamisen, automaation, raportoinnin, haun ja nykyään tietomallin varaan rakennetut tekoälyominaisuudet.

Työpöytäsi ei kuitenkaan ole ilmainen. Coressa olevat tiedot maksavat tallennustilaa, laskettuna niin kuin Salesforce laskee, tietue kerrallaan eikä sarake kerrallaan, ja asiakirjat lasketaan erikseen tiedostotallennustilaan. Kävimme molemmat läpi moduulissa 2. Suuret määrät valokuvia ja skannauksia kuuluvat usein coren ulkopuolelle, ja Salesforceen jää vain linkki.

2. Viitattu: se asuu jonkun toisen arkistokaapissa

Tiedot kuuluvat toiselle järjestelmälle (ERP:lle, tietovarastolle, tilausalustalle), ja se järjestelmä pysyy totuuden lähteenä. Käyttäjien täytyy nähdä ne Salesforcessa, ehkä liittää ne tietueeseen, mutta Salesforce ei tarvitse omaa kopiota. Tästä käytetään myös nimitystä virtuaaliset tiedot: ne näkyvät Salesforcessa virtuaalisesti, ilman että niitä koskaan tallennetaan sinne.

Siihen ovat ulkoiset objektit Salesforce Connectin kautta. Sanon mielelläni, että se näyttää ankalta ja kävelee kuin ankka, mutta se ei ole ankka. Se näkyy kuin sObjekti: voit laittaa sen sivuasetteluihin ja liittyviin luetteloihin ja liittää sen omiin tietueisiisi ulkoisilla ja epäsuorilla lookup-suhteilla. Mutta tietoja ei tallenneta coreen. Joka kerta, kun kosket siihen, se tekee kutsun (callout). Avaa tietue, lataa liittyvä luettelo, aja raportti, niin Salesforce lähtee kysymään toiselta järjestelmältä. Se tarkoittaa viivettä, ja sivusi on käytettävissä vain niin hyvin kuin sen takana oleva järjestelmä.

Ihmiset vastustavat lisenssin hintaa, joten laske niin kuin minä lasken kurssilla. Connect lisensoidaan päätepistettä kohden, ja yksi päätepiste voi tuoda mukanaan monta objektia. Kysy sitten, mitä vaihtoehdon rakentaminen ja ylläpito maksaa: mukautettu komponentti, sen takana oleva kutsukoodi ja kehittäjä päivystämässä, kun se hajoaa. Usein lisenssi on halvempi, ja ylläpitäjäsi voivat määrittää sen kirjoittamatta riviäkään koodia. Missä se ei toimi: tiedot, joita käyttäjäsi muokkaavat koko päivän tai joista raportoidaan paljon.

Myös asiakirjoihin voi viitata. Jos sopimus on jo SharePoint Onlinessa, OneDrivessa, Google Drivessa tai Boxissa, Files Connect antaa käyttäjien päästä siihen Salesforcesta kopioimatta sitä sisään.

Salesforce Connect ei ole ainoa tapa viitata tietoihin. Joskus se on mukautettua logiikkaa: koodia, joka kutsuu toista järjestelmää reaaliajassa ja näyttää sen tiedot sivulla ilman tallennettua kopiota. Se antaa täyden hallinnan ja täyden vastuun kutsusta, virheistä ja ylläpidosta. Ja Data 360 voi myös federoida kopioimatta. Sillä valinnalla on oma lukunsa (Virtualisointi, federointi ja Zero-Copy). Tässä pointti on itse päätös: viittaa, älä kopioi.

3. Arkistoitu: se menee takapihan vajaan

Historia, kirjausketjut, vanhat tapahtumat. Ne on säilytettävä, joskus vuosia, mutta lähes kukaan ei avaa niitä. Ja tätä tiimit lykkäävät. Kun ryhmä kertoo minulle, että heillä on objekti, jossa on 50 miljoonaa tietuetta, ja kysyy, miksi heidän pitäisi arkistoida, kysyn takaisin: jos et arkistoi tänään, arkistoitko koskaan? Kun tänään on 50 miljoonaa, olet matkalla kohti 100, 150 ja 200 miljoonaa.

Vajoja on kaksi. Toinen on coressa: big objectit. Ajattele niitä tietojen säilyttämisenä autotallissa. Voit säilyttää valtavan määrän tietueita, mutta et voi laittaa niitä sivuasetteluun, vakiokäyttöliittymää tai -raportointia ei ole, ja kyselyt tehdään big objectin indeksin kautta, tarkalla osumalla tai välillä (Big Objects Best Practices (opens in a new tab)). Suojaus on pelkkiä objekti- ja kenttäoikeuksia ilman tietueiden jakamista, eikä automaatio toimi niissä. Olen käyttänyt Salesforce Connectia kymmeniä kertoja ja big objecteja vain kerran tai kahdesti. Ne toimivat, mutta ne ovat kömpelöitä, ja olen kirjoittanut osani kiertoteitä tietojen saamiseksi. Neuvoni siis: tee prototyyppi ennen kuin ehdotat sitä, ja suunnittele, miten ihmiset löytävät tiedot, ennen kuin valitset sen.

Toinen vaja on coren ulkopuolella: tietovarasto tai tietokanta jossain muualla (Suunnittelu mittakaavaa varten). Usein se on parempi vaja, eikä sen tarvitse olla näkymättömissä. Coren ulkopuolella arkistoidut tiedot voivat silti näkyä raporteissa Tableaun kaltaisten työkalujen kautta, ja niihin voi silti päästä Salesforcesta, Salesforce Connectin tai muun virtualisointitavan kautta, kun jonkun tarvitsee katsoa taaksepäin.

Kerron projektista, jossa teimme tämän oikein alusta asti. Vähittäiskauppa-asiakkaalla oli yli 1 200 toimipistettä. He sanoivat minulle: ”Teemme vain sata ajanvarausta päivässä myymälää kohden. Ei mikään iso juttu.” Sitten laskin: sata päivässä, kuutena päivänä viikossa (noin 305 päivää vuodessa), 1 200 toimipisteessä, on yli 36 miljoonaa ajanvarausta vuodessa. Sitten he mainitsivat, että jokainen käynti loi kaksi ajanvarausta, yhden etutiskille ja yhden liikkeen takaosaan: yli 73 miljoonaa tietuetta vuodessa. Sitten he halusivat viiden vuoden historian: yli 360 miljoonaa tietuetta, ennen minkäänlaista kasvua. Emme olleet vielä käyttöönotossa, ja näin jo junan suuntaavan suoraan suurten tietomäärien asemalle. Joten arkisto rakennettiin ennen kuin keräsimme ainuttakaan ajanvarausta: vanhemmat ajanvaraukset siirtyivät big objecteihin, ja hakunäkymä näytti nykyiset ajanvaraukset ja arkistoidut heti niiden alla. Vuosia myöhemmin se toimii yhä hyvin.

Click to enlarge

Käytäntöön: Steve Trucking

Steve Trucking on kulkeva esimerkkimme: perheomisteinen viimeisen kilometrin kuljetusyritys, joka noutaa kodinkoneita ja elektroniikkaa suurten vähittäiskauppaketjujen jakelukeskuksista ja toimittaa ja asentaa ne asiakkaiden koteihin. Neljä sen tietolajia, kolme vastausta:

Tiedot	Missä ne asuvat	Miksi
Tämän päivän toimitukset, tiimit ja ajanvaraukset	Coressa	Ajojärjestelijät ja tiimit työskentelevät niissä koko päivän
Vähittäiskauppiaan tilaustiedot	Viitattu (tai ohut kopio coressa)	Vähittäiskauppiaan järjestelmä on totuuden lähde
Toimitushistoria kolmen vuoden takaa	Arkistoitu	Säilytetään reklamaatioita ja trendejä varten; lähes kukaan ei avaa sitä
Toimitusten valokuvat	Coren ulkopuolella, linkitettynä	Tuhansia päivässä; tallennettu Salesforcen ulkopuolelle, linkki toimituksessa

Tässä sama asia tietomallina. Toimitus (Delivery) on coressa, jossa ihmiset työskentelevät sen parissa koko päivän. Kolmen vuoden kuluttua se siirtyy Delivery History -objektiin, joka on big object: yhä coressa, mutta ulkona vajassa. Kumppanin tilaus näkyy ulkoisena objektina, __x: Salesforce liittää toimituksen siihen, mutta tiedot pysyvät vähittäiskauppiaan järjestelmässä. Ja valokuvat asuvat kokonaan coren ulkopuolella, linkki toimituksesta. Yksi malli, kolme kotia.

Click to enlarge

Jokaisessa todellisessa orgissa on kaikki kolme. Ne, jotka joutuvat vaikeuksiin, laittavat kaiken coreen, koska objektin luominen oli oletuspainike.

Mitä arkkitehti tässä päättää

• Koti kullekin tietolajille, ennen kuin yhtäkään objektia suunnitellaan: coressa, viitattuna vai arkistoituna.
• Totuuden lähde. Jos toinen järjestelmä omistaa tiedot, Salesforcesta ei pitäisi hiljaa tulla toista masteria.
• Pääsypolku kaikkeen coren ulkopuoliseen. Viitatut tiedot tarvitsevat käytettävissä olevan lähteen ja hyväksyttävän viiveen; arkistoidut tiedot tarvitsevat tavan, jolla ihmiset löytävät ne.
• Tallennustilan kasvu. Laske nyt (tietueita päivässä, kertaa kasvu, kertaa säilytysaika), älä vasta kun tallennustilavaroitus saapuu.

Kokeen jälkeen: tekoäly nostaa panoksia ”coressa”-valinnassa. Tekoälyominaisuudet ja agentit toimivat parhaiten tiedoilla, jotka alusta ymmärtää: vakio- ja mukautettujen objektien tiedoilla, hyvin nimettyinä ja hyvin kuvattuina. Se vetää laittamaan enemmän coreen. Vastusta sitä väärien tietojen kohdalla. Agentti, joka on ankkuroitu ERP-tietojen vanhentuneeseen kopioon, antaa varmoja, vääriä vastauksia. Usein parempi siirto on viitata elävään lähteeseen tai pitää pieni, hyvin kuvattu siivu coressa. Se, mistä tekoäly lukee tiedot, on nyt osa päätöstä siitä, missä tiedot asuvat.

Lue lisää

• Big Objects Best Practices (opens in a new tab), Salesforce Developers (englanniksi, tarkistettu 2026-09-25)
• Files Connect FAQ (opens in a new tab), Salesforce Help (englanniksi, tarkistettu 2026-09-25)
• Tällä kurssilla: Virtualisointi, federointi ja Zero-Copy ja Suunnittelu mittakaavaa varten