Joka päivä satojatuhannet yritykset ja miljoonat käyttäjät toimivat pilvipalvelimella käyttämällä Salesforce Platform -sovelluksia. Miksi sovellusalusta on niin menestyvä? Miksi voit Trust siihen, että se tukee liiketoimintaasi? Mitä ainutlaatuisia etuja sovellusalusta tarjoaa yrityksillesi, kuten sinun?

Tämä tekninen yhteenveto selittää, miten Salesforce Platform tarjoaa luotettavia, skaalattavissa olevia ja helposti mukautettavissa olevia loppukäyttäjien käyttökokemuksia käyttämällä yksilöllistä pilvipalveluiden ohjelmistojärjestelmää. Tämän oppaan lukemisen jälkeen ymmärrät paremmin sen perustana olevan teknologian, joka tekee Salesforce Platformista vakuuttavan valinnan liiketoimintasovelluksillesi.

Salesforce Platform on erinomainen esimerkki onnistuneesta pilvipalvelualustasta ja siihen liittyvistä sovellusten ekosysteemeistä. Vuosituhannen alusta alkaen alusta on ollut perustana seuraaville kohteille:

• Monet suosittuja liiketoimintasovelluksia yleisiin käyttötarkoituksiin, kuten myynti ja asiakaspalvelu
• Toimialakohtaiset sovellukset erikoistuneempia käyttötapoja varten, kuten rahoitus ja terveydenhuolto
• Miljoonia mukautettuja sovelluksia ja sovelluslaajennuksia yksilöllisille käyttötarkoituksille

Salesforce Platform on suurelta osin niin menestyvä ja suosittu, koska sen ainutlaatuinen ohjelmistojen arkkitehtuuri tukee sovelluksia, joita on helppo rakentaa, käyttää, mukauttaa ja laajentaa poikkeuksellisen suorituskykyisinä ja luotettavina. Sovellusalustan ohjelmistojen arkkitehtuurin ydin on sen usean palveluntarjoajan, metadataan perustuva rakenne.

Salesforce Platform -sovellusrakenne on:

• Multitenantti — Se eristää ja tukee samanaikaisesti useiden vuokralaisten (organisaatioiden, liiketoimintayksiköiden jne.) vaihtelevia vaatimuksia.
• Metadataan perustuva — Se sallii jokaisen vuokralaisen mukauttaa sovelluksiaan ja käyttäjäkokemuksiaan helposti ja nopeasti käyttämällä metadataa, dataa, joka kuvaa elementtejä, kuten käyttöliittymää (UI) ja liiketoimintalogiikkaa.

Kun luot uuden sovellusobjektin tai kirjoitat koodia Salesforce Platformilla, sovellusalusta ei luo tietokantaan todellista taulukkoa tai koodia. Sen sijaan alusta tallentaa jonkin verran metadataa, jota se voi käyttää suorituksen aikana virtuaalisovellusten komponenttien dynaamiseen materialisoimiseen. Sovellusalusta varmistaa, että jokaisen vuokralaisen metadata on yksityinen ja helppo päivittää ilman lukituksia tai käyttökatkoksia, jotta jokainen vuokralainen voi rakentaa ja mukauttaa sovelluksia erillään. Salesforce Platform käyttää samaa metadataa tarjotakseen mukautettuja API-rajapintoja, RESTful-rajapintoja ja Web Services (SOAP-pohjaisia) rajapintoja, joita voit käyttää sovelluksiesi integroimiseen muiden sovellusten ja automatisoitujen prosessien kanssa.

Valmiit ratkaisut ovat käytettävissä myös sovellusalustan laajan sovellusten markkinapaikan AppExchangessa. AppExchange on luotettujen kumppanien ja riippumattomien ohjelmistotoimittajien (ISV) laaja ekosysteemi, joka sisältää kolmannen osapuolen metadataa, joka kuvaa ilmaisia tai maksullisia sovelluslaajennuksia ja kokonaisia sovelluksia, joita voit käyttää tiettyjen liiketoimintavaatimusten täyttämiseksi.

Salesforce Platformin yksi esiintymä käyttää seuraavia ominaisuuksia tukeakseen tätä erittäin mukautettavaa ja laajennettavaa arkkitehtuuria:

• Yksi jaettu multitenant-tietokanta, jossa on yksi skeema, joka sisältää vuokralaisia koskevaa metadataa ja dataa.
• Multitenant-ydin (sovelluksen suorituksen aika), joka lukee metadataa ja dataa tarjotakseen dynaamisesti vuokralaisia koskevia sovelluksia, liiketoimintalogiikkaa ja API-rajapintoja kunkin vuokralaisen käyttäjille suorituksen aikana.

Tämä Salesforcen hallitsemien ydinten selkeä erottaminen vuokralaisen hallitsemasta metadatasta sallii Salesforcen, vuokralaisten ja palveluntarjoajien kehittää järjestelmän osiaan itsenäisesti ilman häiriöitä.

Tämän yleiskatsauksen pohjalta tämän artikkelin seuraavat osiot tarjoavat lisätietoja sovellusalustan ainutlaatuisista ominaisuuksista, jotka perustuvat sen suunnittelun tärkeimpiin osa-alueisiin, mukaan lukien:

• Sovellusalustan datakerros
• Sovellusalustan kehittäminen
• Sovellusalustan sisäinen käsittely
• Sovellusalustan infrastruktuuri

Salesforce Platform -sovelluksen runtime- ja innovatiivinen datakerros erottavat vuokralaiskohtaiset tiedot, skeemojen mukautukset ja liiketoimintalogiikan turvallisesti. Yleisesti ottaen skeema tukee useita käyttötapoja:

• Kun luot sovelluksen tai mukautat sitä, sovellusalusta tallentaa siihen liittyvän metadatan jaettuihin tietokantataulukoihin, jotka ylläpitävät metadataa kaikille vuokralaisille.
• Kun käytät sovellusta tietojen lukemiseen tai kirjoittamiseen, sovellusalusta tallentaa datasi jaettuihin tietokantataulukoihin, jotka ylläpitävät kaikkien vuokralaisten tietoja.
• Sovellusalusta ylläpitää myös sisäistä metadataa kulissien takana useissa taulukoissa, joita ydin käyttää optimoidakseen pyyntöjen viiveen suorituksen aikana.

Mutta miten yksi jaettu tietokanta ja skeema voivat pitää kunkin vuokralaisen tiedot yksityisinä? Jokainen sovellusalustan vuokralainen tunnetaan nimellä organisaatio, eli lyhenteellä organisaatio. Jaettujen tietokantataulukoiden jokaisella organisaatiokohtaisella tietueella on myös organisaationTunnus. Kun ydin käyttää tietokantaa, se käyttää tätä yksilöllistä tunnistetta varmistaakseen, että kunkin organisaation toiminnot ovat yksityisiä.

Organisaatiokohtaiset objektit (ajattele taulukoita perinteisessä suhdetietokantassa), kentät, tallennetut toimenpiteet, tietokantakäynnistimet ja paljon muuta ovat virtuaalisia rakenteita, jotka on kuvattu metadatalla, jota sovellusalusta tallentaa muutamaan tietokantataulukkoon, joita kutsutaan nimellä Universal Data Dictionary (UDD).

• MT_Objects on tietokantataulukko, joka sisältää metadataa sovellukselle määrittämistäsi objekteista, mukaan lukien objektin yksilöllisen tunnisteen (ObjID), organisaatiosi (OrganisaatiosiID) ja objektille antamasi nimen (ObjName).
• Järjestelmätaulukko MT_Fields tallentaa metadataa kullekin objektille esittelemistäsi kentistä (sarakkeista), mukaan lukien kentän yksilöllisen tunnisteen (FieldID), organisaatiosi (Organisaatiosi ID), kentän sisältävän objektin (ObjID), kentän nimen (FieldName), kentän datatyypin, totuusarvon, joka osoittaa, vaatiiko kenttä indeksointia (IsIndexed), sekä objektin kentän sijainnin suhteessa muihin kenttiin (FieldNum).

Koska metadata on tärkeä komponentti, sovellusalustan täytyy optimoida pääsy metadataan. Muutoin metadatan yleinen käyttö estäisi palvelun skaalautumisen. Kun tämä mahdollinen pullonkaula on mielessä, sovellusalusta käyttää massiivisia ja hienostuneita metadatan välimuistoja säilyttääkseen viimeksi käytetyn metadatan muistissa, välttyäkseen suorituskykyä heikentäviltä levyn I/O- ja koodin uudelleenkokoelmilta ja parantaakseen sovellusten vastausaikoja.

Järjestelmätaulukko MT_Data sisältää sovelluksen käytettävissä olevat tiedot, jotka kartoitetaan kaikkiin organisaatiokohtaisiin taulukoihin ja niiden kenttiin, niin kuin metadata on määritetty MT_Objekteissa ja MT_Kentissä. Jokainen rivi sisältää tunnistuskenttiä, kuten globaalin yksilöllisen tunnisteen (GUID), rivin omistavan organisaation (OrganisaationID) ja sisältävän objektin tunnisteen (ObjID). MT_Data-taulukon jokaisella rivillä on myös Nimi-kenttä, joka sisältää ”luonnollisen nimen” vastaaville tietueille. Esimerkiksi tilitietue voi käyttää ”Tilin nimi”, tapaustietue voi käyttää ”Tapauksen numero” jne.

Arvo0... ValueN flex-sarakkeet, joita kutsutaan myös ajoiksi, sisältävät sovellustietoja, jotka kartoitetaan taulukoihin ja kenttiin, jotka on ilmoitettu MT_Objects- ja MT_Fields-objekteissa. Kaikki flex-sarakkeet käyttävät muuttujan pituisen merkkijonon datatyyppiä, jotta ne voivat tallentaa minkä tahansa rakenteellisen sovelluksen datatyypin (merkkijonot, numerot, päivämäärät jne.). Seuraavassa kuvassa kuvataan, että kaksi saman objektin kenttää ei voi kartoittaa samaan ajankohtaan MT_Datassa tallennusta varten. Yksi ajankohta voi kuitenkin hallita useiden kenttien tietoja, kunhan kukin kenttä on peräisin toisesta objektista.

MT-kentät voivat käyttää mitä tahansa useista vakiomuotoisista rakenteellisista datatyypeistä, kuten tekstiä, numeroa, päivämäärää ja päivämäärää/aikaa, sekä erikoiskäyttöisiä, _muotoisia rakenteellisia datatyyppejä, kuten valintaluetteloa (luetteloitu kenttä), automaattista numeroa (automaattisesti lisätty järjestelmän luoma järjestysnumero), kaavaa (vain luku -johdannainen arvo), päätieto–lisätieto-suhdetta (ulkoinen avain), valintaruutua (totuusarvo), sähköpostia, URL-osoitetta ja muita. MT_kentät voivat myös olla pakollisia (ei null) ja niillä voi olla mukautettuja vahvistussääntöjä (esimerkiksi yhden kentän täytyy olla suurempi kuin toinen kenttä), joita sovellusalusta noudattaa.

Kun esität tai muokkaat objektia, sovellusalusta hallitsee MT_Objects-objektien metadatan riviä, joka määrittää objektin. Vastaavasti alusta hallitsee jokaiselle kentälle riviä MT_Fields-kentissä, mukaan lukien metadata, joka kartoittaa kentän tiettyyn MT_Datan flex-sarakkeeseen sitä vastaavien kenttien datan säilyttämiseksi. Koska sovellusalusta hallitsee objektien ja kenttien määritelmiä metadatana, eikä todellisina tietokantarakenteina, järjestelmä voi sietää usean tilaajan sovellusten online-skeeman ylläpitotoimintoja estämättä muiden organisaatioiden ja käyttäjien samanaikaista toimintaa. Vertailun vuoksi perinteisten suhdetietokantajärjestelmien online-taulukoiden uudelleenmääritys vaatii tavallisesti väliaikaisia lukkoja ja usein työläisiä, monimutkaisia prosesseja ja ajoitettuja sovellusten käyttökatkoksia.

Kuten edellisen kuvan MT_Datan yksinkertaistettu esitys osoittaa, flex-sarakkeet ovat universaalia datatyyppiä (muuttujan pituusmerkkijono), jonka avulla alusta voi jakaa yhden flex-sarakkeen useille kentille, jotka käyttävät erilaisia rakenteellisia datatyyppejä (merkkijonoja, numeroita, päivämääriä jne.).

Sovellusalusta tallentaa kaikki flex-sarakkeiden tiedot käyttämällä kanonista muotoa ja käyttää perustana olevia tietokantajärjestelmän datatyyppien muunnosfunktioita (esimerkiksi TO_NUMBER, TO_DATE, TO_CHAR) tarvittaessa, kun sovellukset lukevat tietoja ja kirjoittavat tietoja flex-sarakkeisiin.

MTData sisältää myös sarakkeita, joita ei näytetä edellisessä kuvassa. Esimerkiksi tarkastustietoja voi hallita neljällä sarakkeella, mukaan lukien käyttäjä, joka loi rivin ja milloin se luotiin, käyttäjä, joka muokkasi riviä viimeksi ja milloin riviä viimeksi muokattiin. MT_Data sisältää myös _IsDeleted-sarakkeen, jota sovellusalusta käyttää osoittamaan, milloin rivi on poistettu.

Sovellusalusta tukee myös kenttien esittämistä merkkikokoisina objekteina (CLOB), jotta voit tallentaa enintään 32 000 merkkiä pitkiä tekstikenttiä. Sovellusalusta tallentaa MT Datan jokaiselle riville, jolla on CLOB, CLOB-objektin pois riviltä taulukkoon nimeltään _MT_Clob, jonka järjestelmä voi liittää MT_Datan vastaaviin riveihin tarvittaessa.

Huomautus: Sovellusalusta tallentaa CLOB-tiedostot myös indeksoidussa muodossa tietokannan ulkopuolelle tekstihaun nopeuttamiseksi. Lisätietoja sovellusalustan tekstihaun järjestelmästä on kohdassa Hakut.

Sovellusalusta indeksoi automaattisesti erityyppisiä kenttiä tarjotakseen skaalattavaa suorituskykyä.

Perinteiset tietokantajärjestelmät luottavat natiivisiin tietokantaindekseihin löytääkseen nopeasti tietyt tietokantataulukon rivit, joiden kentät vastaavat tiettyä ehtoa. MTDatan flex-sarakkeille ei kuitenkaan ole käytännöllistä luoda natiivikannan indeksejä, koska sovellusalusta käyttää yhtä flex-saraketta tallentaakseen useiden kenttien tietoja, joilla on erilaiset rakenteelliset datatyypit. Sen sijaan alusta hallitsee MT_Datan indeksiä kopioimalla indeksoitavaksi merkittyjen kenttien tiedot synkronoidusti _MT_Indexes -pivot-taulukon asiaankuuluvaan sarakkeeseen.

MT_Indexes sisältää vahvasti kirjoitettuja, indeksoituja sarakkeita, kuten StringValue, NumValue ja DateValue, joita sovellusalusta käyttää vastaavan datatyypin kenttien datan hakemiseen. Sovellusalusta kopioisi esimerkiksi MT_Data flex -sarakkeen merkkijonoarvon MT_Indexsin StringValue-kenttään, päivämääräarvon DateValue-kenttään jne. MT_Indexes-objektien perustana olevat indeksit ovat vakiomuotoisia, ei-yksilöllisiä tietokantaindeksejä. Kun sisäinen järjestelmäkysely sisältää hakuparametrin, joka viittaa objektin rakenteelliseen kenttään, sovellusalustan mukautettu kyselyiden optimointiohjelma käyttää MT_Indexes-objektia optimoidakseen asiaankuuluvia datan käyttöoikeustoimintoja.

Huomautus: Sovellusalusta voi käsitellä hakuja useilla kielillä, koska järjestelmä käyttää tapauskertaalgoritmia, joka muuntaa merkkijonoarvot universaaliin muotoon, joka ei ole merkkikokoriippuvainen. MT_Indexes-taulukon StringValue-sarake sisältää merkkijonoarvot tässä muodossa. Suorituksen aikana kyselyiden optimointi luo automaattisesti datan käyttöoikeustoimintoja, jotta optimoitu SQL-lauseke suodatetaan vastaavan merkkikokoisen StringValue-arvon perusteella, joka puolestaan vastaa hakupyynnössä annettua literaalia.

Sovellusalusta sallii sinun määrittää, milloin objektin kentän täytyy sisältää yksilöllisiä arvoja (merkkikokoriippuvainen tai merkkikokoriippumaton). Kun otat huomioon MT_Datan järjestyksen ja kenttädatan Arvo-sarakkeiden jaetun käytön, yksilöllisten tietokantaindeksien luominen objektille ei ole käytännöllistä. (Tämä tilanne muistuttaa edellisessä osiossa käsiteltyä tilannetta ei-yksilöllisille indekseille).

Sovellusalusta käyttää MT_Unique_Indexes-pivot-taulukkoa tukeakseen mukautettujen kenttien yksilöllisyyttä. Tämä taulukko muistuttaa hyvin MT_Indexes-taulukkoa, paitsi että MT_Unique_Indexes-tietokannan perustana olevat natiiviset indeksit käyttävät yksilöllisyyttä. Kun sovellus yrittää lisätä identtistä arvoa kenttään, joka vaatii yksilöllisyyttä, tai pääkäyttäjä yrittää käyttää yksilöllisyyttä olemassa olevalle kentälle, joka sisältää identtisiä arvoja, sovellusalusta palauttaa sovellukselle asiaankuuluvan virheviestin.

Harvoissa tapauksissa sovellusalustan ulkoinen hakukone (selitettynä kohdassa Hakut) saattaa olla ylikuormitettu tai muutoin ei ole käytettävissä eikä se välttämättä voi vastata hakupyyntöön oikeaan aikaan. Sen sijaan, että sovellusalusta palauttaisi loppukäyttäjälle pettymyksen aiheuttavan virheen, se käyttää toissijaista hakumekanismia tarjotakseen järkeviä hakutuloksia.

Päivitä haku suorana tietokantakyselyenä, joka sisältää hakuehtoja, jotka viittaavat kohdetietueiden Nimi-kenttään. Sovellusalusta ylläpitää Pivot-taulukkoa MT_Fallback_Indexes, joka tallentaa kaikkien tietueiden nimen optimoidakseen globaalien objektien hakuja (taulukoita kattavat haut). MT_Fallback_Indexsiin tehdyt päivitykset tapahtuvat synkronoidusti, kun transaktiot muokkaavat tietueita, jotta varahakuilla on aina pääsy ajankohtaisiin tietokannan tietoihin.

Taulukko MT_Name_Denorm on lihavoitu datataulukko, joka tallentaa kunkin tietueen ObjID- ja Nimi-arvot MT_Dataan. Kun sovelluksen täytyy tarjota luettelo ylätaso/alitaso-suhteeseen liittyvistä tietueista, sovellusalusta käyttää MT_Name_Denorm-taulukkoa suorittaakseen suhteellisen yksinkertaisen kyselyn, joka noutaa kunkin viitatun tietueen nimen sovelluksessa näytettäväksi, esimerkiksi osana hyperlinkkiä.

Sovellusalusta tarjoaa suhteiden datatyyppejä, joita organisaatio voi käyttää suhteiden (viite-eheyden) esittämiseen taulukoiden välillä. Kun esität objektin kentälle suhdetyypin, sovellusalusta kartoittaa kentän MT_Data-objektin Arvo-kenttään ja käyttää tätä kenttää tallentaakseen siihen liittyvän objektin ObjID-tunnuksen.

Sovellusalusta ylläpitää pivot-taulukkoa MT_Relationships optimoidakseen liitostoimintoja. Tässä järjestelmätaulukossa on kaksi perustana olevaa tietokannan yksilöllistä yhdistelmäindeksiä, jotka mahdollistavat tehokkaan objektin reitityksen kumpaan tahansa suuntaan tarvittaessa.

Sovellusalusta tarjoaa historiatietojen seurannan mille tahansa kentälle vain muutamalla hiiren napsautuksella. Kun organisaatio ottaa tarkastuksen käyttöön tietylle kentälle, järjestelmä tallentaa asynkronisesti tietoja kenttään tehdyistä muutoksista (vanhat ja uudet arvot, muutospäivä jne.) käyttämällä sisäistä pivot-taulukkoa kirjausketjuna.

Kaikki sovellusalustan data, metadata ja pivot-taulukon rakenteet, mukaan lukien niiden perustana olevat tietokantaindeksit, on fyysisesti osioitu OrgID:n kautta käyttämällä tietokannan natiivisia osiointimekanismeja. Datan osiointi on todennettu tekniikka, jota tietokantajärjestelmät tarjoavat jakaakseen suuret loogiset datarakenteet fyysisesti pienempiin ja hallittavissa oleviin osiin. Osiointi voi myös auttaa parantamaan suurten tietokantajärjestelmien, kuten moniasiakasympäristön, suorituskykyä, skaalattavuutta ja saatavuutta. Jokainen sovellusalustan kysely kohdistetaan määritetyn organisaation tietoihin, joten kyselyiden optimoijan täytyy harkita vain organisaation tietoja sisältävien datan osioiden käyttämistä koko taulukon tai indeksin sijaan. Tätä yleistä optimointia kutsutaan joskus nimellä ”partition pruning”.

Tässä osiossa kerrotaan, miten sovelluskehittäjät voivat luoda skeeman perustana olevan metadatan ja sitten sovelluksia, jotka hallitsevat dataa. Tämä metadata ja data tallennetaan edellisessä osiossa kuvattuun sovellusalustan datakerrokseen.

Kehittäjät voivat laatia palvelinpuolen sovelluskomponentteja käyttämällä sovellusalustan selainpohjaista kehitysympäristöä, jota kutsutaan tavallisesti sovellusalustan määritysten ruuduiksi. Määritysten Osoita ja napsauta -käyttöliittymä tukee kaikkia sovellusskeeman rakennusprosessin osa-alueita, kuten sovelluksen datamallin luomista (mukaan lukien objektit ja niiden kentät sekä suhteet), suojaus- ja jakomallia (mukaan lukien käyttäjät, profiilit ja roolihierarkiat), käyttöliittymää (mukaan lukien ruudun asettelut, datan syöttölomakkeet ja raportit), deklaratiivista logiikkaa (työnkulut) ja ohjelmallista logiikkaa (tallennetut toimenpiteet ja käynnistimet). Esimerkiksi Salesforce-kulku tekee useiden käyttötapausten automatisoinnista helppoa. Määritysten Flow Builderin käyttöliittymä, joka näytetään alla, sallii sinun suunnitella ja toteuttaa graafisesti työnkulkuja, jotka vuorovaikuttavat käyttäjien kanssa, tai käynnistää ne automaattisesti aikataulun perusteella tai tapahtuman käynnistämisen yhteydessä.

Määritykset-ruudut auttavat kaikkia kehittämään ja mukauttamaan sovelluksia helposti ilman (tai hyvin vähän) koodia. Esimerkiksi:

• Sovellusalustan natiivi käyttöliittymä on helppo rakentaa ilman koodia. Taustalla oleva sovelluksen käyttöliittymä tukee kaikkia tavallisia datan käyttötoimintoja, mukaan lukien kyselyitä, lisäyksiä, päivityksiä ja poistoja. Natiivialustan sovellusten suorittamat datan manipulointitoiminnot voivat muokata yhtä objektia kerralla ja sitouttaa jokaisen muutoksen automaattisesti erilliseen tapahtumaan.
• Kun määrität luottamuksellisia tietoja sisältävän objektin tekstikentän, voit määrittää sen helposti siten, että sovellusalusta salaa sitä vastaavat tiedot ja käyttää halutessasi syöttömaskeja piilottaaksesi ruudun tiedot vilkkailta silmiltä.
• Deklaratiivinen vahvistussääntö on yksinkertainen tapa, jolla organisaatio voi noudattaa toimialueen eheyden sääntöä ilman ohjelmointia. Voit esimerkiksi esittää vahvistussäännön, joka varmistaa, että LineItem-objektin Määrä-kenttä on aina suurempi kuin nolla.
• Kaavakenttä on sovellusalustan deklaratiivinen ominaisuus, jonka avulla voit lisätä lasketun kentän helposti objektiin. Voit esimerkiksi lisätä kentän LineItem-objektiin laskeaksesi LineTotal-arvon.
• Yhteenvetokenttä on objektien ristikkäiskenttä, jonka avulla voit kerätä ylätason objektin alitason kenttien tietoja helposti yhteen. Voit esimerkiksi luoda yhteenvetokentän OrderTotal SalesOrder-objektissa LineItem-objektin LineTotal-kentän perusteella.

Huomautus: Sovellusalusta toteuttaa sisäisesti kaavakenttiä ja yhteenvetokenttiä käyttämällä tietokantaominaisuuksia ja laskee arvot tehokkaasti uudelleen synkronoidusti osana käynnissä olevia transaktioita.

Sovellusalusta tarjoaa useita avoimia, standardeihin perustuvia API-rajapintoja, joita kehittäjät voivat käyttää sovellusten rakentamiseen. Sekä RESTful- että verkkopalveluiden (SOAP-pohjaiset) API-rajapinnat tarjoavat pääsyn sovellusalustan moniin ominaisuuksiin. Sovellus voi käyttää näitä erilaisia API-rajapintoja seuraaviin toimiin:

• Manipuloi metadataa, joka kuvaa sovelluksen skeemaa
• Yritystietojen (CRUD) luominen, lukeminen, päivittäminen ja poistaminen
• Lataa tai kysele suurta määrää tietueita asynkronisesti
• Näytä lähes reaaliaikainen datavirta turvallisella ja skaalattavalla tavalla

Sovellukset voivat käyttää Salesforcen objektien kyselykieltä (SOQL) rakentaakseen yksinkertaisia mutta tehokkaita tietokantakyselyitä. SOQL sallii sinun määrittää lähdeobjektin, haettavien kenttien luettelon ja ehdot, joilla voit valita riviä lähdeobjektissa, samalla tavalla kuin SQL:n (Structured Query Language) SELECT-komento. Esimerkiksi seuraava SOQL-kysely palauttaa Tunnus- ja Nimi-kenttien arvon kaikille tilitietueille, joiden Nimi on yhtä kuin merkkijono 'Acme'.

SELECT Id, Name FROM Account WHERE Name = 'Acme'

Sovellusalusta sisältää myös täyden tekstin, monikielisen hakukoneen, joka indeksoi automaattisesti kaikki tekstiin liittyvät kentät. Sovellukset voivat käyttää tätä valmiiksi integroitua hakukonetta käyttämällä tekstihaun suorittamiseen Salesforce Object Search Language (SOSL) -kieltä. Toisin kuin SOQL, joka voi kysellä vain yhtä objektia kerralla, SOSL sallii sinun hakea teksti-, sähköposti- ja puhelinkenttiä useille objekteille samanaikaisesti. Esimerkiksi seuraava SOSL-lauseke hakee liidi- ja yhteyshenkilöobjektien tietueita, jotka sisältävät nimikentässä merkkijonon 'Joe Smith' ja palauttaa kunkin löydetyn tietueen nimen ja puhelinnumeron.

FIND {"Joe Smith"} IN Name Fields RETURNING lead(name, phone), contact(name, phone)

Apex, joka muistuttaa Javaa monessa suhteessa, on tehokas kehityskieli, jota kehittäjät voivat käyttää keskittämään toimenpidelogiikkaa sovellusskeemassaan. Apex voi esittää ohjelman muuttujia ja vakioita, suorittaa perinteisiä kulkujen ohjauslausekkeita (if-else, silmukoita jne.), suorittaa datan manipulointitoimintoja (insert, update, upsert, delete) ja suorittaa transaktioiden hallintaoperaatioita (setSavepoint, rollback).

Voit tallentaa sovellusalustaan Apex-ohjelmia käyttämällä kahta eri muotoa: nimettyä Apex-luokkaa, jossa on menetelmiä (kuten tavallisessa tietokantapuheessa), joita sovellukset suorittavat tarvittaessa, tai tietokannan käynnistintä, joka suoritetaan automaattisesti ennen tietyn tietokannan manipulointitapahtuman tapahtumista tai sen jälkeen. Molemmissa tapauksissa alusta kerää Apex ja tallentaa sen metadatana UDD-tiedostoon. Kun organisaatio suorittaa Apex ensimmäistä kertaa, sovellusalustan runtime-tulkinta lataa ohjelman käännetyn version kyseisen organisaation MRU-välimuistiin (viimeksi käytetty). Sen jälkeen, kun saman organisaation käyttäjän täytyy käyttää samaa rutiinia, sovellusalusta voi tallentaa muistin ja välttyä ohjelman uudelleenkokoonpanon kustannuksilta jakamalla jo muistissa olevan valmiin ohjelman.

Yksinkertaisen avainsanan lisäämisen avulla kehittäjät voivat käyttää Apexia tukeakseen useita yksilöllisiä sovellusten vaatimuksia. Kehittäjät voivat esimerkiksi näyttää metodin mukautettuna RESTful- tai SOAP-pohjaisena API-kutsuna, tehdä siitä asynkronisesti ajoitettavan tai määrittää sen käsittelemään suuren operaation erissä.

Apex on paljon muutakin kuin ”vain toinen prosessikieli”. Se on integroidun sovellusalustan komponentti, joka auttaa järjestelmää tarjoamaan luotettavaa monivaltuutusta. Sovellusalusta voi esimerkiksi vahvistaa kaikki upotetut SOQL- ja SOSL-lausekkeet automaattisesti luokassa estääkseen koodin epäonnistumisen suorituksen aikana. Sen jälkeen alusta säilyttää vastaavat objektin sidonnaisuustiedot kelvollisille luokille ja käyttää niitä estääkseen metadatan muutokset, jotka rikkoisivat muutoin sidonnaisen koodin.

Monet Apex ja staattiset järjestelmämetodit tarjoavat yksinkertaisia käyttöliittymiä järjestelmän ominaisuuksiin. Esimerkiksi staattisilla järjestelmän DML-metodeilla, kuten insert, update ja delete, on yksinkertainen totuusarvo-parametri, jota kehittäjät voivat käyttää osoittaakseen halutun joukkokäsittelyvaihtoehdon (kaikki tai ei mitään tai osittainen tallennus); nämä metodit palauttavat myös tulosobjektin, jonka kutsun rutiini voi lukea määrittääkseen, mitkä tietueet käsitellään epäonnistuneesti ja miksi. Muita Apex- ja sovellusalustan ominaisuuksien välisiä suoria suhteita ovat sisäänrakennetut sähköpostiluokat ja XmlStream-luokat.

Suuri osa sovellusalustasta toimii ja skaalaa hyvin, koska Salesforce loi sen kahdella tärkeällä periaatteella mielessä:

• Tarjoa tehokkaita, laajamittaisia perustason sovellusalustan ominaisuuksia.
• Auta kehittäjiä tekemään kaikki mahdollisimman tehokkaasti.

Sovellusalusta yhdistää nämä periaatteet sovellusalustan yksilöllisiin käsittelyarkkitehtuureihin, mukaan lukien:

• Pyynnöt
• Haut
• Joukkotoiminnot
• Skeeman muokkaus
• Monivaltuuden eristys
• Roskakori

Useimmat nykyaikaiset tietokantajärjestelmät määrittävät kyselyiden optimaaliset suoritussuunnitelmat käyttämällä kustannuksiin perustuvaa kyselyiden optimointia, joka ottaa huomioon asiaankuuluvat tilastot kohdetaulukosta ja indeksitiedoista. Tavalliset, kustannuksiin perustuvat optimointitilastot on kuitenkin suunniteltu yhden vuokralaisen sovelluksille, eikä niissä huomioida tietojen käyttöoikeusominaisuuksia, joita tietyt käyttäjät suorittavat kyselyn usean vuokralaisen ympäristössä. Esimerkiksi tietyn kyselyn, joka kohdistetaan objektiin, jossa on paljon dataa, suoritetaan todennäköisemmin tehokkaammin käyttämällä eri suoritussuunnitelmia käyttäjille, joilla on korkea näkyvyys (päällikkö, joka näkee kaikki rivit) ja käyttäjille, joilla on heikko näkyvyys (myy ihmisiä, jotka voivat nähdä vain itselleen liittyviä rivejä).

Sovellusalusta ylläpitää kokonaisvaltaista joukkoa optimointitilastoja (vuokralaisen, ryhmän ja käyttäjätason) jokaisen organisaation objekteille, jotta se voi määrittää kyselyiden optimaalisen suoritussuunnitelman usean vuokralaisen järjestelmässä. Tilastot vastaavat tietyn kyselyn mahdollisesti käytettävissä olevien rivien määrää, ottaen huomioon organisaatiokohtaisen objektin kokonaistilastot (esimerkiksi organisaation kokonaisomistuksessa olevien rivien kokonaismäärä) sekä tarkempia tilastoja (esimerkiksi tietyn käyttöoikeusryhmän tai loppukäyttäjän mahdollisesti käytettävissä olevien rivien määrä).

Sovellusalusta ylläpitää myös muita tilastoja, jotka ovat hyödyllisiä tietyissä kyselyissä. Sovellusalusta ylläpitää esimerkiksi tilastoja kaikille mukautetuille indekseille, jotka paljastavat vastaavan kentän muiden kuin null-arvojen ja yksilöllisten arvojen kokonaismäärän, sekä valintaluettelokenttien histogrammeja, jotka paljastavat kunkin luetteloarvon kardinaliteetin.

Kun olemassa olevia tilastoja ei ole tai niitä ei pidetä hyödyllisinä, sovellusalustan optimoijalla on muutama eri strategia, joita se käyttää luodakseen kohtuullisen optimaalisia kyselyitä. Kun esimerkiksi kysely suodattaa objektin Nimi-kentän perusteella, optimoija voi käyttää MT_Fallback_Indexes-taulukkoa löytääkseen pyydetyt rivit tehokkaasti. Muissa tilanteissa optimointi luo puuttuvia tilastoja dynaamisesti suorituksen aikana.

Sovellusalustan optimointia käytetään yhdessä optimoinnin tilastojen kanssa ja se perustuu myös sisäisiin tietoturvaan liittyviin taulukoihin (ryhmät, jäsenet, GroupBlowout ja CustomShare), jotka ylläpitävät tietoja organisaation käyttäjien suojaustoimialueista, mukaan lukien tietyn käyttäjän ryhmäjäsenyydet ja objektien ja rivien mukautetut käyttöoikeudet. Nämä tiedot ovat arvokkaita määrittääkseen kyselyiden suodattimien valikoivuuden käyttäjäkohtaisesti. Lisätietoja sovellusalustan upotetusta suojausmallista on kohdassa Platform Developer Basics Trailhead.

Seuraavassa kuvassa oleva kulkukaavio osoittaa, mitä tapahtuu, kun sovellusalusta käsittelee datan pyynnön, joka sisältyy yhteen isoista pinotaulukoista, kuten MT_Data. Pyyntö voi olla peräisin mistä tahansa lähteestä, kuten API-kutsusta tai tallennetusta toimenpiteestä. Ensin sovellusalusta suorittaa ”esikyselyitä”, jotka ottavat huomioon monivalvoisen tilaston. Sitten palvelu luo esikyselyiden palauttamien tulosten perusteella optimaalisen perustana olevan tietokantakyselyn, joka suoritetaan tietyssä asetuksessa.

Alla oleva taulukko osoittaa, että sovellusalusta voi suorittaa saman kyselyn neljällä eri tavalla, riippuen kyselyn lähettäneestä käyttäjästä ja kyselyn suodatusehtojen valikoivuudesta.

Käyttäjät odottavat, että interaktiivinen hakutoiminto skannaa sovelluksen tietokannan koko tai valitun vaikutusalueen ja palauttaa lajiteltuja tuloksia, joiden vastausaika on alle sekunti. Sovellusalustan sovelluksille tämän ominaisuuden tarjoamiseksi sovellusalusta käyttää transaktiojärjestelmästään erillistä hakukonetta. Kun päivität tietueita, transaktiojärjestelmä päivittää ydintietokannan ja välittää siihen liittyvät tiedot hakujärjestelmään indeksointia varten. Kun haet tietueita, hakukone käyttää sen indeksejä käsitelläkseen kyselyn nopeasti ja palauttaa lajiteltuja tuloksia, joissa on linkkejä asiaan liittyviin tietokantatietueisiin.

Kun sovellukset päivittävät tekstikentissä olevia tietoja (CLOB, Nimi jne.), indeksointipalvelimet ovat vastuussa vastaavien indeksien asynkronisesta päivittämisestä, joita hakukone ylläpitää ydintapahtumien järjestelmän ulkopuolella. Indeksointiprosessin optimoimiseksi alusta kopioi synkronoidusti muokattuja tekstitietoja sisäiseen indeksoitavaan taulukkoon, kun transaktiot sitoutuvat, mikä tarjoaa suhteellisen pienen tietolähteen, joka minimoi datan määrän, jonka indeksointipalvelimen täytyy lukea levystä. Hakukone ylläpitää automaattisesti erillisiä indeksejä kullekin organisaatiolle.

Tekstiindeksin päivitykset saattavat viivästyä todellisten transaktioiden jälkeen, riippuen indeksointipalvelimien tämänhetkisestä latauksesta ja käyttöasteesta. Sovellusalusta ylläpitää myös äskettäin päivitettyjen rivien MRU-välimuistia, jonka järjestelmä ottaa huomioon koko tekstin hakutulosten materialisoinnissa välttyäkseen odottamattomilta hakutuloksilta, jotka johtuvat vanhentuneista indekseistä. Sovellusalusta ylläpitää MRU-välimuistiin tallennuksia käyttäjäkohtaisesti ja organisaatioittain tukemaan mahdollisia haun vaikutusalueita tehokkaasti.

Sovellusalustan hakukone optimoi tietueiden sijoituksen hakutuloksissa useilla eri tavoilla. Järjestelmä huomioi esimerkiksi haun suorittavan käyttäjän suojaustoimialueen ja painottaa nykyisen käyttäjän käytettävissä olevia rivejä. Järjestelmä voi myös ottaa huomioon tietyn rivin muokkaushistorian ja asettaa aktiivisemmin päivitetyt rivit etusijalle suhteellisen staattisille riveille. Käyttäjä voi halutessaan painottaa hakutuloksia, esimerkiksi korostaakseen viimeksi muokattuja rivejä.

Transaktioiden intensiiviset sovellukset tuottavat vähemmän kustannuksia ja toimivat paljon paremmin, kun ne yhdistävät ja suorittavat toistuvia toimintoja kerralla. Voit esimerkiksi vertailla kahta tapaa, joilla sovellus voi ladata paljon uusia rivejä. Ei-tehokas tapa olisi käyttää rutiinia, jossa on silmukka, joka lisää yksittäisiä rivejä ja tekee API-kutsun toisensa jälkeen jokaiselle rivinsyötteelle. Paljon tehokkaampi tapa olisi luoda taulukko riveistä ja lisätä ne kaikki rutiininomaisesti yhdellä API-kutsulla.

Sovellusalustan tehokas joukkokäsittely on kehittäjille helppoa, koska se on lisätty API-kutsuihin. Sisäinen sovellusalusta käsittelee myös joukkotoiminnon kaikki sisäiset vaiheet.

Sovellusalustan joukkokäsittelyjärjestelmä ottaa automaattisesti huomioon erilliset virheet, joita tapahtuu minkä tahansa vaiheen aikana. Kun joukkotoiminto käynnistyy osittaisen tallennustilan tilassa, järjestelmä tunnistaa tunnetun aloitustilan ja yrittää suorittaa sitten prosessin jokaisen vaiheen (joukkokentän datan vahvistaminen joukkokentällä, joukkokäynnistimet, joukkosietueet jne.). Jos moottori havaitsee virheitä missä tahansa vaiheessa, se peruuttaa virheelliset toiminnot ja kaikki haittavaikutukset, poistaa virheistä vastuussa olevat rivit ja jatkaa yrittämällä käsitellä loput rivit joukkona. Tämä prosessi iteroi jokaisen peräkkäisen vaiheen läpi, kunnes järjestelmä voi sitouttaa rivien alajoukon virheettömästi. Sovellus voi tutkia palautusobjektia tunnistaakseen, mitkä rivit epäonnistuivat ja mitkä niistä aiheutuneet poikkeukset.

Huomautus: Kaikki tai ei mitään -tila on saatavilla joukkotoiminnoille oman harkintasi mukaan. Lisäksi käynnistimen suorittaminen joukkotoiminnon aikana on sisäisten hallintalaitosten alainen, jotka rajoittavat töiden määrää.

Objektin määritelmään tehdyt muutokset vaativat muutakin kuin yksinkertaisia UDD-metadatan päivityksiä. Tällöin sovellusalusta käyttää tehokkaita mekanismeja, jotka auttavat vähentämään kokonaissuorituskykyvaikutuksia pilvipalveluun.

Mieti esimerkiksi, mitä tapahtuu kulissien takana, kun muokkaat sarakkeen datatyyppiä valintaluettelosta tekstiin. Sovellusalusta kohdistaa sarakkeen datalle ensin uuden ajan, kopioi nykyisiin arvoihin liittyvät valintaluettelon otsikot ja päivittää sarakkeen metadatan osoittamaan uuteen ajankohtaan. Vaikka kaikki tämä tapahtuu, tietojen käyttö on normaalia ja sovellukset toimivat edelleen ilman merkittäviä vaikutuksia.

Katso esimerkiksi, mitä tapahtuu, kun lisäät yhteenvetokentän objektiin. Tässä tapauksessa alusta laskee alustavat yhteenvedot asynkronisesti taustalla käyttämällä tehokasta joukkotoimintoa. Kun taustalaskenta on käynnissä, uuden kentän tarkastelevat käyttäjät näkevät, että sovellusalusta laskee kentän arvoa tällä hetkellä.

Sovellusalustalla on laaja joukko hallintarajoituksia ja resurssien rajoituksia, jotka liittyvät sovellusalustan koodin suorittamiseen, jotta voidaan estää jaettujen, usean palveluntarjoajan järjestelmäresurssien pahantahtoinen tai tahaton monopolisointi. Sovellusalusta esimerkiksi valvoo tarkasti koodiskriptien suoritusta ja rajoittaa, kuinka paljon CPU-aikaa se voi käyttää, kuinka paljon muistia se voi kuluttaa, kuinka monta kyselyä ja DML-lausuntoa se voi suorittaa, kuinka monta matemaattista laskentaa se voi suorittaa, kuinka monta lähtevää verkkopalvelukutsuja se voi tehdä ja paljon muuta. Yksittäiset kyselyt, joita sovellusalustan optimointi pitää liian kalliina suorittaakseen, aiheuttavat soittajalle suorituksen aikaisen poikkeuksen. Vaikka nämä rajoitukset saattavat kuulostaa hieman rajoittavilta, ne ovat välttämättömiä jaetun tietokantajärjestelmän skaalattavuuden ja suorituskyvyn suojaamiseksi kaikille asiaankuuluville sovelluksille. Pitkällä aikavälillä nämä toimenpiteet auttavat kehittämään parempia koodaustekniikoita kehittäjille ja luomaan paremman käyttökokemuksen kaikille sovellusalustan käyttäjille. Esimerkiksi kehittäjä, joka yrittää ensin koodata silmukan, joka päivittää tehottomasti tuhat riviä kerrallaan, saa resurssien rajoitusten vuoksi suorituksen aikaisia poikkeuksia ja aloittaa sitten sovellusalustan tehokkaan joukkokäsittelyn API-kutsujen käytön.

Jos haluat välttyä heikosti kirjoitettujen sovellusten mahdollisilta järjestelmäongelmilta, uuden tuotantosovelluksen käyttöönotto on tiukasti hallittava prosessi. Ennen kuin organisaatio voi siirtää uuden sovelluksen kehitystilasta tuotanto-tilaan, Salesforce vaatii yksikkötestejä, jotka vahvistavat sovellusalustan koodirutiinien toimivuuden. Lähetettyjen yksikkötestien täytyy kattaa vähintään 75 prosenttia sovelluksen lähdekoodista.

Salesforce suorittaa lähetetyt yksikkötestit sovellusalustan sandbox-kehitysympäristössä määrittääkseen, vaikuttaako sovelluskoodi haitallisesti monivaltuutettujen populaation suorituskykyyn ja skaalattavuuteen. Yksittäisen yksikkötestin tulokset osoittavat perustietoja, kuten suoritettujen rivien kokonaismäärän, sekä tietoja koodista, jota testi ei suorittanut.

Kun Salesforce on sertifioinut sovelluksen koodin tuotantoympäristöä varten, sovelluksen käyttöönottoprosessi koostuu yhdestä tapahtumasta, joka kopioi sovelluksen kaiken metadatan tuotantoympäristöesiintymään ja suorittaa vastaavat yksikkötestit uudelleen. Jos jokin prosessin osista epäonnistuu, sovellusalusta vain peruuttaa transaktion ja palauttaa poikkeuksia ongelman ratkaisemiseksi.

Huomautus: Salesforce suorittaa yksikkötestit uudelleen jokaiselle sovellukselle sovellusalustan jokaisen kehitysjulkaisun yhteydessä nähdäkseen ennakoivasti, rikkovatko uudet järjestelmäominaisuudet ja parannukset olemassa olevia sovelluksia.

Kun tuotantosovellus on julkaistu, sovellusalustan sisäänrakennettu suorituskykyprofiili analysoi sen automaattisesti ja tarjoaa siihen liittyvää palautetta pääkäyttäjille. Suorituskykyanalyysiraportit sisältävät tietoja hitaista kyselyistä, datan manipuloinneista ja alareitityksistä, joita voit tarkastaa ja käyttää sovelluksen toimintojen hienosäätämiseen. Järjestelmä myös kirjaa ja palauttaa tietoja suorituksen aikaisista poikkeuksista pääkäyttäjille, jotta he voivat korjata sovelluksensa virheet.

Kun sovellus poistaa tietueen objektista, sovellusalusta merkitsee rivin poistettavaksi muokkaamalla rivin IsDeleted-kenttää MTDatassa. Tämä toiminto siirtää rivin tehokkaasti niin kutsuttuun roskakoriin. sovellusalusta sallii sinun palauttaa valitut rivit roskakorista enintään 15 päivän ajan ennen kuin voit poistaa ne pysyvästi MT_Datasta. Sovellusalusta rajoittaa organisaatiossa säilytettävien tietueiden kokonaismäärää organisaation tallennusrajoitusten perusteella.

Kun operaatio poistaa päätiedot–lisätiedot-suhteeseen liittyvän ylätason tietueen, sovellusalusta poistaa automaattisesti kaikki siihen liittyvät alitason tietueet, mikäli se ei rikkoisi viite-yhteensopivuussääntöjä. Kun esimerkiksi poistat SalesOrder-objektin, sovellusalusta siirtää poistamisen automaattisesti sidonnaisiin LineItems-objekteihin. Jos palautat ylätason tietueen myöhemmin roskakorista, järjestelmä palauttaa myös kaikki alitason tietueet automaattisesti.

Kun poistat hakusuhteeseen liittyvän viitatun ylätason tietueen, sovellusalusta asettaa automaattisesti kaikki sidonnaiset avaimet null-arvoon. Jos palautat ylätason tietueen myöhemmin, sovellusalusta palauttaa automaattisesti aiemmin nullatut hakusuhteet, pois lukien poistotoimintojen ja palautustoimintojen välillä uudelleen kohdistetut suhteet.

Roskakori tallentaa myös jätetyt kentät ja niiden tiedot, kunnes organisaatio poistaa ne pysyvästi tai määritetty määrä päiviä on kulunut, kumpi tapahtuu ensin. Tähän asti koko kenttä ja kaikki sen tiedot ovat palautettavissa.

Agiliteetti on avain yritysten menestymiseen nykymaailmassa. Salesforce Platformin perustana olevat kerrokset auttavat liiketoimintasovelluksiasi sopeutumaan nopeasti uusiin haasteisiin, jotta voit jatkaa liiketoimintaasi infrastruktuurin sijaan.

Infrastruktuuri (esimerkiksi peruspalvelut ja laskentaresurssit) on piilotettu, perustana oleva teknologia, joka tukee Salesforce Platformin yläkerroksia. Hyperforce on Salesforce Platform -infrastruktuuri, joka perustuu 100 % uusiutuvaan energiaan ja nettonollalle, ja joka ratkaisee tärkeimmät asiakashaasteet, kuten vaatimustenmukaisuuden, Trustin ja skaalattavuuden

Useissa maantieteellisissä sijainneissa toimivien yritysten täytyy noudattaa uusia, kehittyviä ja vaihtelevia tietojenhallintasäännöksiä. Koska Salesforce ottaa Hyperforcen käyttöön yhä useammassa maassa AWS-alueen saatavuuden perusteella, sovellusalustan sovellukset ja käyttäjät voivat suorittaa luottamukselliset työkuormansa tiukkojen datan tallennus- tai tietoturvastandardien mukaisesti. Esimerkiksi Hyperforcen tarjoama Salesforcen Euroopan unionin (EU) toiminta-alue sallii EU:n yritysten säilyttää tietonsa helposti EU:ssa.

Tietoturva, luotettavuus ja saatavuus ovat ei-toiminnallisia vaatimuksia, jotka kaikkien liiketoimintasovellusten on huomioitava, jotta ne voivat tarjota loppukäyttäjille luottamusta. Hyperforcen avulla Salesforce Platform sallii yritysten tarjota luotettuja liiketoimintasovelluksia helposti.

• Tietoturva — Hyperforce käyttää asiakastietojen natiivisalausta loppukäteen paikallisesti ja siirrettäessä. Hyperforcen Zero Trust -arkkitehtuuri noudattaa tiukkaa henkilöllisyydenvahvistusprosessia, joka varmistaa, ettei resursseille ole epäsuoraa käyttöoikeutta. Lisäksi Hyperforce käyttää vähiten käyttöoikeuksia -periaatetta varmistaakseen, että toiminnot hyväksytään vain oikeaan aikaan oikealla käyttöoikeusmäärällä.
• Luotettavuus — Hyperforcen jokainen esiintymä käyttää useita pilvipalveluiden saatavuusvyöhykkeitä ja modernisoituja lähestymistapoja, jotka nopeuttavat vahinkotapahtumien vastausta tarjotakseen erittäin käytettävissä olevan ja kestävän sovellusalustan.
• Käytettävyys — Hyperforcen moderni CI/CD-putki ja sininen/vihreä sovellusjulkaisu minimoivat sovellusten huoltovälit vain yhteen minuuttiin vuodessa.

Salesforce on Sales Cloudin ja Service Cloudin kaltaisten sovellusten perustana todennettu sovelluskehitysalusta, johon yksittäiset yritykset ja palveluntarjoajat ovat luoneet miljoonia liiketoimintasovelluksia eri käyttötarkoituksiin, mukaan lukien toimitusketjun hallinta, laskutus, kirjanpito, kaupankäynti, vaatimustenmukaisuuden seuranta, henkilöresurssien hallinta ja korvausvaatimusten käsittely. Sovellusalustan ainutlaatuinen, usean palveluntarjoajan ja metadataan perustuva arkkitehtuuri on suunniteltu erikseen pilvipalvelimelle, ja se tukee luotettavasti ja turvallisesti kriittisiä, Internet-laajuisia sovelluksia. Käyttämällä standardeihin perustuvia API-rajapintoja ja natiivisia kehitystyökaluja sovellusalustan kehittäjät voivat luoda helposti kaikki modernin verkkosovelluksen tai mobiilisovelluksen komponentit, mukaan lukien sovelluksen datamallin (mukaan lukien objektit ja suhteet), liiketoimintalogiikan (mukaan lukien työnkulut ja vahvistukset), integraatiot muiden sovellusten kanssa ja paljon muuta.

Salesforcen insinöörit ovat optimoineet sovellusalustan useita palveluntarjoajia varten sen luomisesta lähtien, ja ne tarjoavat ominaisuuksia, joiden avulla sovellusalustan sovellukset voidaan skaalata vastaamaan muuttuviin liiketoimintatarpeisiin. Integroidut järjestelmäominaisuudet — kuten joukkodatan käsittely-API, Apex, koko tekstin hakukone ja ainutlaatuinen kyselyoptimointi — auttavat tekemään sidonnaisista sovelluksista erittäin tehokkaita ja skaalattavissa pienellä tai pienellä vaivalla kehittäjiltä.

Salesforcen hallittu lähestymistapa tuotantosovellusten käyttöönottoon varmistaa erinomaisen suorituskyvyn, skaalattavuuden ja luotettavuuden kaikille sovelluksille, jotka ovat riippuvaisia alustasta. Salesforce valvoo ja kerää operaatiotietoja jatkuvasti sovellusalustan sovelluksista auttaakseen edistämään asteittaisia parannuksia ja uusia järjestelmäominaisuuksia, jotka hyödyttävät välittömästi olemassa olevia ja uusia sovelluksia.

Steve Bobrowski on menestyvä yrittäjä ja teknologiajohtaja, joka on työskennellyt monissa johtavissa yritysohjelmistoyhtiöissä, mukaan lukien eri rooleissa Salesforcessa vuodesta 2008. Tänään Steve työskentelee Salesforcen CTO-virastossa auttaakseen yrityksen teknologia-arkkitehtuuristrategioissa.

Tom Leddy on Salesforcen arkkitehtien evangelisti. Hän tukee globaalia Salesforce Architect Community -yhteisöä auttamalla luomaan resursseja, työkaluja ja ohjeita, joiden avulla arkkitehdit voivat työskennellä parhaalla mahdollisella tavalla. Ota yhteyttä Tomiin Twitterissa.