Näin minä sen suunnittelisin

🌐 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 6/6 luvussa Perustiedot ja identiteetti, Data Architect -kurssin luku 6, ja osan 1 loppu. Edellinen: Kun auktoriteetti on jaettu · Seuraava: osa 2 alkaa luvulla Suunnittelu mittakaavaa varten (coming soon)

Kysymys, johon tämä tarkistuspiste vastaa: Pystytkö kokoamaan osan 1 yhteen todellisessa skenaariossa?

Kokeile tehtävää ensin. Tämä on oma läpikäyntini tarkistuspisteen 1 tehtävästä. Jos et ole vielä piirtänyt omaa suunnitelmaasi, tee se ennen kuin luet eteenpäin. Arvo on siinä, että vertaat päättelyäsi omaani, ei vastauksen lukemisessa.

Tämä on ”näin minä sen suunnittelisin”: yksi mahdollinen toimiva ratkaisu, ei se vastaus, kompromissit nimettyinä ja kantani otettuina. Emme ole vielä käsitelleet suuria tietomääriä, kyselyjen suunnittelua, integraatiomalleja, migraatiota tai transaktioita, ja se on tarkoituksellista: arkkitehtuuri kehittyy sitä mukaa kuin opit lisää. Mutta osa 1 antaa meille tarpeeksi luurangon rakentamiseen.

Aloita luvuista

Kuvauksesta: noin 3 300 toimitusta työpäivässä, miljoona vuodessa, kasvua 30 % vuodessa. Noin 1,6 riviä toimitusta kohden (1,6 miljoonaa vuodessa); noin kahdeksan tilamuutosta toimitusta kohden (8 miljoonaa vuodessa); neljästä viiteen miljoonaa valokuvaa vuodessa; noin 200 000 GPS-lukemaa päivässä; noin 180 000 tapausta vuodessa; kolme vähittäiskauppakumppania, jotka lähettävät kuormaluettelot kolmella eri tavalla; yhdeksän jakelukeskusta; 330 kuorma-autoa kahden hengen tiimeineen. Ja Steve Truckingilla on jo yksi Salesforce-org, jossa on Service Cloud, Field Service ja kumppaniportaali. Laske nollat ennen kuin piirrät yhtäkään laatikkoa. Ne ratkaisevat alla useita asioita.

Toimitusten ydin: katso emoalukseen

Toimitukset ovat kaiken ydin, ja Field Service hoitaa jo ajojärjestelyn. Siksi aloitan Field Servicen vakiomallista, kuten luvun 3 viipale teki:

Liiketoiminnan käsite	Salesforce-objekti	Miksi
Vähittäiskauppakumppani (Retail Partner)	Tili (Account) (Retail Partner -tietuetyyppi)	Yritys, jonka kanssa Steve Trucking tekee sopimuksia; kantaa sopimukset, tapaukset ja portaalipääsyn
Kumppanin henkilöstö (jakelukeskusten esihenkilöt, myymälöiden henkilöstö)	Yhteyshenkilö (Contact)	Portaalikäyttäjien on oltava yhteyshenkilöitä
Yksi toimitus: yksi vastaanottaja, yksi osoite, yksi kumppanin tilaus, yksi päivä	Työtilaus (Work Order)	Field Servicen työn yksikkö; aikataulutus, mobiilisovellus ja huoltoraportit riippuvat siitä
Kukin tuote tai palvelu: jääkaappi, asennus, vanhan poisvienti	Työtilauksen rivi (Work Order Line Item)	Jakaa työn, ohjaa tarkistuslistoja ja laskutusta
Pysähdyksen laji: pelkkä toimitus, asennuksella, poisviennillä	Työn tyyppi (Work Type)	Määrää keston, taidot ja asennuksen tarkistuslistan
Aikataulutettu käynti ja sen aikaikkuna	Huoltokäynti (Service Appointment)	Se, minkä Field Service aikatauluttaa ja tiimin sovellus näyttää
Tiimit ja kuorma-autot; jakelukeskusten ajojärjestelyalueet	Service Resource, Service Crew, Service Territory (huoltoresurssi, huoltotiimi, huoltoalue)	Field Service aikatauluttaa tiimin yhtenä resurssina
Vastaanottajien kyselyt, kumppanien korvausvaatimukset	Tapaus (Case)	Palvelukonsoli, palveluoikeudet (entitlements), email-to-case
Kumppanin tiistain lista Phoenixin jakelukeskukseen	Manifest__c (mukautettu)	Mikään vakio-objekti ei edusta vastaanoton, täsmäytyksen ja uudelleenajon yksikköä

Kaikki muu pysyy vakiona. Lisäobjektien vastustaminen on tarkoituksellista: luvun 1 kysymys oli, milloin arkkitehdin pitäisi vastustaa vielä yhtä mukautettua objektia, ja tässä vastaus on ”melkein aina”. Esimerkiksi kumppanin tilausrivi ei ole uusi objekti. Se on työtilaus, joka tunnistetaan kumppanin viitteellä.

Click to enlarge

Se kasvaa luvun 3 loppukaaviosta (Suunnittele Salesforcen fyysinen malli): samat objektit samoilla paikoilla, lisättyinä tiimillä, ajojärjestelyalueella, tapauksella ja sillä, minkä tarkistuspiste 1 pitää coren ulkopuolella.

Avain, joka täsmää kumppanin tilauksen toimitukseen

Jokaisesta kuormaluettelon rivistä tulee yksi työtilaus, joka linkitetään kuormaluetteloonsa. Avain on kysymys, johon haluan eniten vastauksen: mistä tiedämme, että tämä kumppanin rivi on tuo toimitus? Vastaukseni: External ID työtilauksessa, joka muodostetaan vähittäiskauppakumppanista ja kumppanin omasta tilaus- ja toimitusviitteestä (jotain kuten KEYSTONE-PHX-8843119-1), merkittynä yksilölliseksi (unique). Yksi kenttä lähdettä kohden, yksi yhteen. Se on kumppanin tunniste, ei meidän: luvun 2 ”useita tunnisteita yhdelle asialle” ja moduulin 1 ”kumppani omistaa tilausviitteensä”.

Miksi sillä on väliä: kuormaluettelot saapuvat päivää tai kahta etukäteen, ja niitä muutetaan saman päivän aikana. Tuolla avaimella jokainen uudelleen lähetetty tai muutettu kuormaluettelo tekee upsertin kaksoiskappaleiden luomisen sijaan. Muutos päivittää työtilauksen, kenttä kirjaa sen, ja muutos jo reititettyyn toimitukseen hälyttää koordinaattorille: kumppanin muutos otetaan käyttöön, mutta se on merkittynä, kunnes ajojärjestely vahvistaa sen. Tämä on myös se, mikä muuttuu luvun 4 kuvasta. Nykyään jokainen kuormaluettelo laskeutuu RouteDeskiin, ja koordinaattorit näppäilevät reitit uudelleen Salesforceen ja valmiit pysähdykset takaisin. Tässä suunnitelmassa kuormaluettelot tulevat suoraan Salesforceen upsertattuina kumppanin avaimella; RouteDesk poistuu käytöstä, ja uudelleennäppäily loppuu. Integraatioluku suunnittelee kolme sisääntulevaa muotoa. Tietopäätös on avain.

Vastaanottaja: henkilötili, yhteyshenkilö vai ei kumpikaan?

Tämä on osan 1 kiinnostavin tietopäätös, joten tässä vaihtoehdot ja sitten valintani.

Vaihtoehto A: henkilötilit. Jokaisesta vastaanottajasta tulee henkilötili (person account), joka linkitetään jokaiseen toimitukseen. Puolesta: vakioratkaisu, toimii luontevasti Service Cloudin, viestinnän ja konsolin kanssa, tunnistaa toistuvat vastaanottajat. Vastaan: noin miljoona uutta vastaanottajaa vuodessa, kukin henkilötili, joka vie noin kaksi kertaa yritystilin tallennustilan (Estimated Record Size by Object Type (opens in a new tab)), joten kahdessa vuodessa yksi orgin suurimmista objekteista. Eivätkä vastaanottajat ole Steve Truckingin asiakkaita. He ovat kunkin vähittäiskauppakumppanin asiakkaita, eikä Steve Trucking saa koskaan sekoittaa yhden kumppanin asiakasta toisen asiakkaaseen (S2).

Vaihtoehto B: yhteyshenkilöt vähittäiskauppakumppanin tilin alla. Vastaan: miljoona yhteyshenkilöä kolmen tai neljän tilin alla on vanhempi–lapsi-skew’tä valtavassa mittakaavassa, kauas Salesforcen noin 10 000 lapsen suosituksen yli vanhempaa kohden (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab)). Tämä on vaihtoehto, joka näytetään ja hylätään.

Vaihtoehto C: vastaanottaja elää toimituksessa. Vastaanottajan nimi, puhelinnumero, sähköposti, osoite ja toimitusohjeet ovat työtilauksen kenttiä (osoitekentät ovat siellä jo vakiona), ja ne otetaan kuormaluettelosta. Puolesta: ei uutta suurta objektia; tiedot elävät täsmälleen niin kauan kuin toimitus niitä tarvitsee; poisto tapahtuu toimitus kerrallaan kumppanin aikataulun mukaan; ja kumppanien eristäminen tulee kaupan päälle, koska jokainen toimitus kuuluu yhdelle kumppanille. Vastaan: toistuvaa vastaanottajaa ei tunnisteta samaksi henkilöksi.

Siinä on tasapaino, joka pitää löytää. Tuleeko koskaan tarvetta tunnistaa useat toimitukset samaksi henkilöksi samassa paikassa? Antaa sille henkilölle kirjautuminen? Siinä kulkee raja vastaanottajan, joka tarvitsee oman tietueen, ja vastaanottajan tietojen, jotka ovat yksinkertaisesti tietoja toimituksesta, välillä. Ja on keskitie. Kuljeta vähittäiskauppakumppanin omaa asiakas-ID:tä toimituksen kenttänä, Retail Partner Customer ID (kumppanin asiakas-ID). Se ei luo vastaanottajatietuetta, mutta se sitoo yhteen toimitukset, jotka kumppani lähettää samalle asiakkaalle, mikä on alku yhtenäisemmälle asiakaskokemukselle, ja se johtaa suoraan takaisin vähittäiskauppakumppanin järjestelmään, jossa se asiakas todella elää. Se on heidän tunnisteensa, joten se merkitsee jotain vain yhdessä kumppanin kanssa: yhden kumppanin asiakkaalla 4417 ei ole mitään tekemistä toisen kumppanin asiakkaan 4417 kanssa.

Ammatillisen näkemykseni mukaan vaihtoehto C on oikea valinta. Se, ettei toistuvaa vastaanottajaa tunnisteta, on hyväksyttävää, jopa toivottavaa: Steve Truckingilla ei ole näihin ihmisiin mitään suhdetta toimituksen ulkopuolella. Taas moduuli 1: vastaanottaja on kumppanin asiakas, ja kumppani on auktoriteetti sen suhteen, kuka hän on. Ja luku 5: henkilötiedot, jotka päätyvät yhteen paikkaan yhteen toimitukseen sidottuina, on paljon helpompi suojata, säilyttää ja poistaa. Ja se kestää luvun 2 normaalimuodot: vastaanottajan tiedot ovat yksi yhteen toimituksen kanssa, joten ne kuuluvat sille. Erillinen vastaanottaja-lapsiobjekti säästäisi muutaman toistuvan arvon, mutta hintana olisi uusi objekti, uusi suhde ja niiden kuormitus, ja ainoa tapa säästää enemmän olisi käsitellä samaa henkilöä yhtenä vähittäiskauppakumppanien yli, mitä emme tee. Joten toimitus kantaa vastaanottajan, ja Retail Partner Customer ID on tie takaisin kumppanin omaan järjestelmään.

Click to enlarge

Yhtenäistäisinkö vastaanottajat kumppanien yli?

John Smith, 123 Main Street, esiintyy Redrockin kuormaluettelossa ja Brightwaven kuormaluettelossa. Todennäköisesti sama henkilö. Pitäisikö Steve Truckingin yhtenäistää heidät? Ei, tarkoituksella ei. Vastaanottajien yhtenäistäminen vähittäiskauppakumppanien yli rikkoisi S2:n: kumppani ei saa koskaan nähdä toisen kumppanin vastaanottajia, ja yhtenäinen identiteetti on juuri se silta, josta tiedot vuotavat. Se on tämän luvun kanta käytännössä: täsmäytä liian vähän, kun sekoittuminen tulee kalliiksi, ja tässä sekoittuminen tulee hyvin kalliiksi.

Jos vähittäiskauppakumppani myöhemmin haluaa tunnistaa toistuvat vastaanottajat omissa toimituksissaan, se on tehtävä identiteetin selvityksen työkalulle, kuten Data 360:lle, rajattuna siihen kumppaniin: rekisterityylinen kartta, ei henkilötili, eikä koskaan kumppanien yli. Kartta siitä, kuka on kuka, ei anna omistajuutta, eikä se anna pääsyä.

Mikä jää orgiin ja mikä ei

Luku 3 kysyi, missä tietojen pitäisi asua. Nollat vastaavat siihen tässä:

• Nykyinen tila elää huoltokäynnissä ja työtilauksessa. Tilamuutosten historian, noin 8 miljoonaa vuodessa ja kasvussa, ei tarvitse elää core-orgissa. Jokainen muutos julkaistaan tapahtumana ja säilytetään tietovarastossa, Snowflakessa. Org pitää nykytilan; historia on yhä olemassa palvelua, operaatioita ja analytiikkaa varten, vain ei operatiivisessa tietokannassa.
• Valokuvat (neljästä viiteen miljoonaa vuodessa, osassa näkyy ihmisiä tai kodin sisätiloja) elävät coren ulkopuolella tuolle volyymille rakennetussa tallennuksessa, ladattuina suoraan tiimin sovelluksesta. Org pitää vain sen, mitä se tarvitsee: pienen indeksitietueen kustakin kuvasta tai pelkän lukumäärän ja ”vaaditut asennuskuvat valmiina” -lipun. Suosin kevyempää vaihtoehtoa: pidä org kevyenä ja anna kuvasäilön omistaa indeksinsä ja säilytyksensä.
• GPS-lukemat (200 000 päivässä) pysyvät FleetLinkissä ja menevät Snowflakeen; org tarvitsee vain viimeisimmän sijainnin seurantasivua ja ajojärjestelijän karttaa varten.
• RouteDeskin kahdeksan vuoden historia (noin 5 miljoonaa toimitusta) menee tietovarastoon tai arkistoon, jossa se on korvausvaatimusten käytettävissä. Se, mitä orgiin tulee, jos mitään, on osan 2 migraatiopäätös.

Click to enlarge

Tarkistuspiste 1: näin minä sen suunnittelisin. Samat paikat kuin luvun 4 järjestelmäkartassa (Steve Truckingin järjestelmäkartta), ilman uudelleennäppäilyä ja laskentataulukkoa.

Kuka näkee mitä ja kuka tarvitsee lisenssin

• Vähittäiskauppakumppanit näkevät vain omat toimituksensa (S2). Jokainen työtilaus kantaa vähittäiskauppakumppaninsa; portaalikäyttäjät näkevät oman kumppaninsa toimitukset, ja jakelukeskusten esihenkilöt vain oman jakelukeskuksensa toimitukset.
• Kumppanikäyttäjät tarvitsevat portaalilisenssin, joka tukee jakamissääntöjä ja rooleja: Customer Community Plus tai Partner Community. Luvun 3 stadionin istumapaikat: halvimmat paikat eivät saa sitä jakamista, jota tämä suunnitelma tarvitsee. Molemmat lisenssit tarvitsevat ulkoisille käyttäjille rooleja, ja Salesforce varoittaa, että useammat roolit hidastavat orgia (Experience Cloud User Licenses (opens in a new tab)). Rooli kumppania ja jakelukeskusta kohden on hyvä; rooli jokaiselle myymälälle ei ole.

Koetieto. Tunne, mitkä ulkoiset lisenssit sisältävät vakiojakamisen: Customer Community Plus ja Partner Community (ulkoisten käyttäjien rooleineen), ei Customer Community, joka käyttää jakamisjoukkoja (sharing sets).

• Vastaanottajat eivät tarvitse lisenssiä. Seurantasivu näyttää yhden toimituksen linkin kautta, jossa on vanheneva tunniste (token) (S3), ei kirjautumista.
• Varo skew’tä. Satoja tuhansia työtilauksia vuodessa, jotka osoittavat kolmeen tai neljään kumppanitiliin, on tilien data skew’tä. Yksi vaihtoehto on lapsitili kullekin jakelukeskukselle kunkin kumppanin alla, mikä jakaa lapset yhdeksään tai useampaan osaan; valmiiden toimitusten arkistointi korvausvaatimusten aikaikkunan jälkeen pitää aktiivisten lasten määrän vanhempaa kohden pienenä. Osa 2 tarttuu siihen.

Mitä en tekisi

En loisi henkilötiliä jokaiselle vastaanottajalle sillä perusteella, että vastaanottaja on yksityishenkilö. En ripustaisi miljoonaa yhteyshenkilöä kolmen tilin alle. En rakentaisi mukautettua Delivery-objektia Field Servicen työtilauksen rinnalle. En yhtenäistäisi vastaanottajia kumppanien yli. En laittaisi miljoonia valokuvia tai GPS-lukemia coren tallennustilaan. Enkä kutsuisi yhtenäistettyä vastaanottajaa golden recordiksi, ellemme olisi oikeasti tehneet hallintapäätöstä.

Mikä on vielä auki

Osa 1 rakensi luurangon; osa 2 testaa sitä. LDV-mittapuu kolmantena vuonna (työtilaukset, huoltokäynnit ja rivit ovat kaikki suurten tietomäärien aluetta kahden tai kolmen vuoden sisällä), kyselyjen suunnittelu kumppanikohtaisille listanäkymille, kolme sisääntulevaa integraatiota ja kolme tilasyötettä, RouteDeskin migraatio, saman päivän transaktiot ja portaalin takana oleva tietoturvasuunnitelma. Steve Truckingkin muuttuu. Pidä tämä suunnitelma tallessa; palaat siihen.

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

• Mitkä vakio-objektit kantavat ytimen (tässä Field Servicen objektit) ja mitkä mukautetut objektit ovat todella perusteltuja (tässä yksi).
• Avain, joka täsmää kunkin kumppanin tilausrivin toimitukseen, ja miksi se kuuluu kumppanille.
• Mikä vastaanottaja on, sen suhteen perusteella, joka Steve Truckingilla todella on heihin.
• Yhtenäistetäänkö identiteetit, ja missä sekoittuminen on liian kallis riski.
• Mikä jää orgiin, mikä elää coren ulkopuolella ja mistä lisensseistä suunnitelma riippuu.

Lue lisää

• Steve Truckingin kuvaus ja tehtävät (D1, D3, DC1).
• Salesforce Help, Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Considerations for Object Relationships (opens in a new tab) ja Experience Cloud User Licenses (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).
• Salesforce Developers, Parent-Child Data Skew (opens in a new tab) (englanniksi), kuten luvussa 3 viitattiin.