Integrointikuvio | Data 360 ja integrointi | Perusteet

Kun otat Salesforcen käyttöön, sinun täytyy tavallisesti integroida se muihin sovelluksiin. Vaikka jokainen integraatioskenaario on yksilöllinen, kehittäjien ja arkkitehtien täytyy ratkaista yleisiä vaatimuksia ja ongelmia.

Tämä asiakirja kuvaa strategioita (kuvioiden muodossa) näille yleisimmille integraatioskenaarioille. Jokainen kuvio kuvaa tietyn skenaarion suunnittelua ja lähestymistapaa, eikä yksityiskohtaista toteutusta. Tässä asiakirjassa löydät:

Useita kuvioita, jotka käsittelevät tärkeimpiä ”arkkityyppien” integraatioskenaarioita
Valintamatriisi, joka auttaa määrittämään, mikä kuvio sopii parhaiten skenaarioosi
Integrointivihjeitä ja suositeltuja käytäntöjä

Tavoite ja vaikutusalue

Tämä asiakirja on tarkoitettu suunnittelijoille ja arkkitehdeille, joiden täytyy integroida Salesforce Platform muiden yrityksensä sovellusten kanssa. Tämä sisältö on joukko Salesforce-arkkitehtien ja -kumppanien onnistuneita toteutuksia.

Lisätietoja Salesforce-pohjaisten sovellusten laajamittaisen käyttöönoton integrointiominaisuuksista ja vaihtoehdoista on kohdassa Kuvion yhteenveto ja Kuvion valintaopas. Arkkitehtien ja kehittäjien tulisi huomioida nämä kuvion lisätiedot ja suositellut käytännöt Salesforce-integrointiprojektin suunnittelu- ja toteutusvaiheessa.

Kun nämä kuviot on otettu käyttöön oikein, voit siirtyä tuotantoympäristöön mahdollisimman nopeasti ja käyttää mahdollisimman vakaita, skaalattavissa olevia ja huoltovapaita sovelluksia. Salesforcen omat konsultointiarkkitehtit käyttävät näitä kuvioita viitepisteinä arkkitehtuurin tarkastuksissa ja ylläpitävät ja parantavat niitä aktiivisesti.

Tämä sisältö kattaa useimmat integraatioskenaariot, mutta ei kaikkia. Vaikka Salesforce sallii käyttöliittymän (UI) integroinnin, esimerkiksi mashups, tällainen integrointi ei kuulu tämän asiakirjan soveltamisalaan.

Kuvion malli

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

Nimi

Kuvion tunnus, joka osoittaa myös kuviossa olevan integraation tyypin.

Konteksti

Kokonaisvaltainen integraatioskenaario, johon kuvio vaikuttaa. Konteksti tarjoaa tietoja siitä, mitä käyttäjät yrittävät saavuttaa ja miten sovellus toimii vaatimusten täyttämiseksi.

Ongelma

Skenaario tai ongelma (ilmaistuna kysymyksenä), jonka ratkaisemiseksi kuvio on suunniteltu. Kun tarkastelet kuvioita, lue tämä osio ymmärtääksesi nopeasti, sopiiko kuvio integraatioskenaarioosi.

Voimat

Rajoitukset ja olosuhteet, jotka tekevät määritetystä skenaariosta vaikean ratkaistavan.

Ratkaisu

Suositeltu tapa ratkaista integraatioskenaario.

Kuvaus

UML-järjestyksen kaavio, joka näyttää sinulle, miten ratkaisu käsittelee skenaariota.

Tulokset

Selittää, miten voit soveltaa ratkaisua integraatioskenaarioosi ja miten se ratkaisee kyseiseen skenaarioon liittyvät ongelmat. Tämä osio sisältää myös uusia haasteita, jotka voivat ilmetä kuviossa.

Sivupalkit

Muotoon liittyvät lisäosiot, jotka sisältävät tärkeimpiä teknisiä ongelmia, kuviossa esiintyviä variaatioita, kuviokohtaisia huolenaiheita jne.

Esimerkki

Päättymiskenaario, joka kuvaa, miten suunnittelukuviota käytetään todellisessa Salesforce-skenaariossa. Tämä esimerkki selittää integraatiotavoitteet ja miten se toteutetaan tavoitteiden saavuttamiseksi.

Kuvion yhteenveto

Seuraava taulukko kuvaa tässä asiakirjassa olevat integraatiokuvioet.

Kuvioiden luettelo remote-process-invocation--request-and-reply

Kuvakkeet	Skenaario
Prosessin etäkutsut — Pyyntö ja vastaus	Salesforce kutsuu prosessia etäjärjestelmästä, odottaa sen suorittamista ja seuraa sen tilaa etäjärjestelmästä saadun vastauksen perusteella.
Prosessin etäkutsut — Sytytä ja unohda	Salesforce kutsuu prosessia etäjärjestelmässä, mutta ei odota, että prosessi on valmis. Sen sijaan etäprosessi vastaanottaa ja hyväksyy pyynnön ja siirtää sen sitten takaisin Salesforcelle.
Erädatan synkronointi	Lightning Platformissa säilytetty data luodaan tai päivitetään ulkoisen järjestelmän päivitysten ja Lightning Platformista lähetettyjen muutosten mukaisesti ulkoiseen järjestelmään. Päivitykset molempiin suuntiin tehdään erätasolla.
Etäpuhelu	Salesforce Platformissa säilytetty data luodaan, haetaan, päivitetään tai poistetaan etäjärjestelmällä.
Datan muutosten perusteella tehty käyttöliittymäpäivitys	Salesforce-käyttöliittymä täytyy päivittää automaattisesti Salesforce-datan muutosten vuoksi.
Datan virtualisointi	Salesforce käyttää ulkoista dataa reaaliajassa. Näin sinun ei tarvitse säilyttää dataa Salesforcessa ja tällöin täsmätä dataa Salesforcen ja ulkoisen järjestelmän välillä.

Kuvion lähestymistapa

Tässä asiakirjassa olevat integraatiokuvioet on luokiteltu kolmeen kategoriaan:

Datan integrointi — Nämä kuviot käsittelevät kahden tai useamman järjestelmän datan synkronoinnin vaatimusta, jotta molemmat järjestelmät sisältävät aina ajankohtaista ja hyödyllistä dataa. Datan integrointi on usein yksinkertaisin toteutettava integrointityyppi, mutta se vaatii asianmukaisia tietojenhallintatekniikoita tehdäkseen ratkaisusta kestävän ja kustannustehokkaan. Tällaisiin tekniikoihin sisältyy usein päätietojen hallinnan (MDM), datan hallinnan, päätoiminnon, identtisten tietueiden poistamisen, datakulkujen suunnittelun ja muita osa-alueita.
Prosessien integrointi — Tämän kategorian kuviot käsittelevät liiketoimintaprosessin tarvetta hyödyntää kahta tai useampaa sovellusta tehtävänsä suorittamiseen. Kun otat ratkaisun käyttöön tälle integraatiotyypille, käynnistävän sovelluksen täytyy kutsua prosessin rajat muihin sovelluksiin. Tavallisesti nämä kuviot sisältävät myös orkestroinnin (jossa yksi sovellus on keskeinen ”controller”) ja koreografian (jossa sovellukset ovat useita osallistujia eikä keskeistä ”controlleria” ole). Nämä integraatiot vaativat usein monimutkaisia suunnittelu-, testaus- ja poikkeusten käsittelyvaatimuksia. Lisäksi tällaiset yhdistelmäsovellukset ovat tavallisesti vaativampia perustana oleville järjestelmille, koska ne tukevat usein pitkäaikaisia transaktioita ja kykyä raportoida tai hallita prosessien tiloja.
Virtuaaliintegraatio — Tämän kategorian kuviot koskevat käyttäjän tarvetta tarkastella, hakea ja muokata ulkoisessa järjestelmässä säilytettyä dataa. Kun otat ratkaisun käyttöön tälle integraatiotyypille, käynnistävän sovelluksen täytyy kutsua muita sovelluksia ja käyttää niiden dataa reaaliajassa. Tämäntyyppinen integrointi välttää datan replikoinnin eri järjestelmissä ja tarkoittaa, että käyttäjät käyttävät aina ajankohtaisia tietoja.

Parhaan integraatiostrategian valitseminen järjestelmällesi ei ole vaikeaa. Harkittavana on useita näkökohtia ja useita työkaluja, joita voidaan käyttää, ja jotkin työkalut soveltuvat paremmin tiettyihin tehtäviin kuin toiset. Jokainen kuvio käsittelee tiettyjä kriittisiä osa-alueita, kuten kunkin järjestelmän ominaisuudet, datan määrä, virheiden käsittely ja transaktiivisuus.

Kuvion valintaopas

Valintamatriisitaulukoissa näytetään kuviot ja niiden tärkeimmät näkökohdat, jotta voit määrittää, mikä kuvio sopii parhaiten integraation vaatimuksiin. Kuvakkeet luokitellaan näiden ulottuvuuksien perusteella.

Aspekti	Kuvaus
Tyyppi	Määrittää integraation tyylin: Prosessi, Data tai Virtuaali. Prosessi: Prosessiin perustuvat integraatiot ovat tapoja, joilla voit integroida toiminnallisen kulun käsittelyn kahdelle tai useammalle sovellukselle. Nämä integraatiot sisältävät tavallisesti enemmän abstraktiota ja monimutkaisuutta, varsinkin transaktiivisuuden ja periytymisen osalta. Data: Datan integroinnit ovat sovellusten käyttämien tietojen integrointia. Nämä integraatiot voivat vaihdella yksinkertaisesta taulukon lisäämisestä tai lisäämisestä monimutkaisiin datapäivityksiin, jotka vaativat viitteellistä eheyttä ja monimutkaisia käännöksiä. Virtuaali: Virtuaaliintegraatioissa Salesforce vuorovaikuttaa ulkoisessa järjestelmässä olevan datan kanssa ilman, että sinun täytyisi kopioida Salesforcessa olevaa dataa. Tämäntyyppinen integrointi käynnistyy aina Salesforce Platform -tapahtuman kautta, kuten käyttäjän toiminnon, haun tai tietueen päivityksen kautta, jolloin data integroidaan ulkoiseen lähteeseen reaaliajassa.
Aikataulu	Määrittää integraation tyylin: Prosessi, Data tai Virtuaali. Synkronoitu: Estopyynnöt ja reaaliaikaiset pyynnöt ovat pyyntö-/vastausoperaatioita. Tulos palautetaan soittajalle välittömästi tämän toiminnon kautta. Ei-synkronoitu — Estämättömiä, jonoihin tai viesteihin perustuvia pyyntöjä kutsuu lähes reaaliaikainen yksisuuntainen toiminto. Tulokset ja mahdolliset virheet palautetaan kutsumalla muita yksisuuntaisia toimintoja.Kutsuttaja tekee pyynnön ja jatkaa vastausta odottamatta.

Aspekti

Kuvaus

Tyyppi

Määrittää integraation tyylin: Prosessi, Data tai Virtuaali.

Prosessi: Prosessiin perustuvat integraatiot ovat tapoja, joilla voit integroida toiminnallisen kulun käsittelyn kahdelle tai useammalle sovellukselle. Nämä integraatiot sisältävät tavallisesti enemmän abstraktiota ja monimutkaisuutta, varsinkin transaktiivisuuden ja periytymisen osalta.
Data: Datan integroinnit ovat sovellusten käyttämien tietojen integrointia. Nämä integraatiot voivat vaihdella yksinkertaisesta taulukon lisäämisestä tai lisäämisestä monimutkaisiin datapäivityksiin, jotka vaativat viitteellistä eheyttä ja monimutkaisia käännöksiä.
Virtuaali: Virtuaaliintegraatioissa Salesforce vuorovaikuttaa ulkoisessa järjestelmässä olevan datan kanssa ilman, että sinun täytyisi kopioida Salesforcessa olevaa dataa. Tämäntyyppinen integrointi käynnistyy aina Salesforce Platform -tapahtuman kautta, kuten käyttäjän toiminnon, haun tai tietueen päivityksen kautta, jolloin data integroidaan ulkoiseen lähteeseen reaaliajassa.

Aikataulu

Määrittää integraation tyylin: Prosessi, Data tai Virtuaali.

Synkronoitu: Estopyynnöt ja reaaliaikaiset pyynnöt ovat pyyntö-/vastausoperaatioita. Tulos palautetaan soittajalle välittömästi tämän toiminnon kautta.
Ei-synkronoitu — Estämättömiä, jonoihin tai viesteihin perustuvia pyyntöjä kutsuu lähes reaaliaikainen yksisuuntainen toiminto. Tulokset ja mahdolliset virheet palautetaan kutsumalla muita yksisuuntaisia toimintoja.Kutsuttaja tekee pyynnön ja jatkaa vastausta odottamatta.

Salesforcen integrointi toiseen järjestelmään

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

Tyyppi	Aikataulu	Huomioitava avainkuvio
Prosessien integrointi	Synkronoitu	Prosessin etäkutsut — Pyyntö ja vastaus
Prosessien integrointi	Ei-synkronoitu	Prosessin etäkutsut — Sytytä ja unohda
Datan integrointi	Synkronoitu	Prosessin etäkutsut — Pyyntö ja vastaus
Datan integrointi	Ei-synkronoitu	Datan muutosten perusteella tehty käyttöliittymäpäivitys
Virtuaaliintegraatio	Synkronoitu	Datan virtualisointi

Toisen järjestelmän integrointi Salesforceen

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

Tyyppi	Aikataulu	Huomioitava avainkuvio
Prosessien integrointi	Synkronoitu	Etäpuhelu
Prosessien integrointi	Ei-synkronoitu	Etäpuhelu
Datan integrointi	Synkronoitu	Etäpuhelu
Datan integrointi	Ei-synkronoitu	Erädatan synkronointi

Middleware-termit ja määritelmät

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

Termi	Määritelmä
Tapahtumien käsittely	Tapahtuman käsittely on tunnistettavan esiintymän vastaanotto määritetyssä vastaanottajassa (jäljempänä käsittelijä). Tapahtumien käsittelyyn liittyviin tärkeimpiin prosesseihin sisältyy: Tapahtuman välittämisen sijainnin määrittäminen Tämän välitystoiminnon suorittaminen Lähetetyn tapahtuman vastaanottaminen Suorittaa jonkinlaisia toimenpiteitä vastauksena, kuten kirjoittaa lokiin, lähettää virheen tai palautusprosessin tai lähettää ylimääräisen viestin Pidä mielessäsi, että tapahtuman käsittelijä voi lopulta välittää tapahtuman tapahtuman kuluttajalle. Tämän ominaisuuden yleisiä käyttötapoja middleware-ohjelmiston kanssa voidaan laajentaa sisältämään suosittu ”julkaise/tilaa”- tai ”pub/sub”-toiminto. Julkaise/tilaa-skenaariossa välitysohjelmisto reitittää pyyntöjä tai viestejä aktiivisille datatapahtumien tilaajille aktiivisista datatapahtumien julkaisijoista. Nämä kuluttajat, joilla on aktiivisia kuuntelijoita, voivat sitten noutaa tapahtumat, kun ne julkaistaan. Salesforce-integraatioissa, jotka käyttävät middleware-ohjelmistoa, middleware-kerros ohjaa tapahtumien käsittelyä. Se kerää kaikki asiaankuuluvat tapahtumat, synkronoidut tai ei-synkronoidut, ja hallitsee jakelua kaikkiin päätepisteisiin, mukaan lukien Salesforce. Voit myös saavuttaa tämän ominaisuuden Salesforce-yritysviestintäalustalla käyttämällä tapahtumavälyä sovellusalustan tapahtumien kanssa.
Protokollan muuntaminen	Protokollamuunnos on tavallisesti ohjelmistosovellus, joka muuntaa yhden laitteen vakiomuotoisen tai omistaman protokollan toiselle laitteelle sopivaksi protokollaksi yhteentoimivuuden saavuttamiseksi. Middleware-kontekstissa tietyn kohdejärjestelmän yhteys saattaa olla rajoitettu protokollan perusteella. Tällöin viestiformaatti täytyy muuntaa tai kapselata kohdejärjestelmän muotoon, josta hyötykuorma voidaan poimia. Tätä kutsutaan myös tunnellemiseksi. Salesforce ei tue natiiviprotokollan muuntamista, joten oletetaan, että kaikki nämä vaatimukset täyttyvät middleware-kerroksella tai päätepisteellä.
Käännös ja transformaatio	Transformaatio on kyky kartoittaa dataformaatteja toisiinsa varmistaakseen integroitavien eri järjestelmien yhteentoimivuuden. Tavallisesti prosessi sisältää viestien muotoilun uudelleen lähettäjän tai vastaanottajan vaatimusten mukaisesti. Monimutkaisemmissa tapauksissa yksi sovellus voi lähettää viestin omassa natiivimuodossaan ja kaksi tai useampi sovellus voi vastaanottaa viestistä kopion omassa natiivimuodossaan. Middleware-käännös- ja transformaatiotyökalut sisältävät usein kyvyn luoda palvelun fasetteja vanhoille tai muille ei-vakiomuotoisille päätepisteille. Nämä palvelun fasetit sallivat näiden päätepisteiden näyttää palvelun osoitettavilta. Salesforce-integraatioissa oletetaan, että kaikki nämä vaatimukset täyttyvät middleware-kerroksella tai päätepisteellä. Datan muuntaminen voidaan koodata Apexissa, mutta emme suosittele sitä huolto- ja suorituskykyyn liittyvistä syistä.
Jonot ja puskurointi	Jonot ja puskurit ovat tavallisesti riippuvaisia ei-synkronoidusta viestien välittämisestä, toisin kuin pyyntöjen ja vastausten arkkitehtuurista. Ei-synkronoiduissa järjestelmissä viestijonot tarjoavat väliaikaista tallennustilaa, kun kohdeohjelma on kiireinen tai yhteys vaarantuu. Lisäksi useimmat ei-synkronoidut middleware-järjestelmät tarjoavat pysyvää tallennustilaa viestijonon varmuuskopioimiseen. Ei-synkronoidun viestiprosessin tärkein etu on se, että jos vastaanottajasovellus epäonnistuu jostain syystä, lähettäjät voivat jatkaa ilman muutoksia. Lähetetyt viestit kerääntyvät vain viestijonoon myöhempää käsittelyä varten, kun vastaanottaja käynnistyy uudelleen. Salesforce tarjoaa vain erillisen jonotoiminnon työnkulkuun perustuvan lähtevän viestin muodossa. Tarjota todellinen viestijono muille integraatioskenaarioille, kuten orkestrointi, prosessien koreografia ja palvelun laatu, vaatii välityspalveluratkaisun.
Synkronoidut kuljetusprotokollat	Synkronoidut kuljetusprotokollat viittaavat protokollat, jotka tukevat toimintoja, joissa "yksi soittajan ketju lähettää pyyntöviestin, estää sen odottamaan vastausviestiä ja käsittelee vastauksen....Pyyntöketju, joka odottaa vastausta, tarkoittaa, että on vain yksi keskeneräinen pyyntö tai että tämän pyynnön vastauskanava on yksityinen tälle ketjulle."
Ei-synkronoidut kuljetusprotokollat	Ei-synkronoidut kuljetusprotokollat viittaavat toimintoja tukeviin protokollisiin, joissa ”yksi soittajan ketju lähettää pyyntöviestin ja määrittää vastaukselle callback-kutsun. Erillinen ketju kuuntelee vastausviestejä. Kun vastausviesti saapuu, vastausketju kutsuu asiaankuuluvaa callback-kutsua, joka luo soittajan asiayhteyden uudelleen ja käsittelee vastauksen. Tämä tapa sallii useiden keskeneräisten pyyntöjen jakaa yhden vastausketjun.”
Välitysreititys	Välitysreititys on monimutkaisen viestien ”kulun” määritelmä komponentista komponenttiin. Esimerkiksi monet välitysohjelmistoihin perustuvat ratkaisut ovat riippuvaisia viestijonojen järjestelmästä. Vaikka jotkin toteutukset sallivat viestintäkerroksen tarjoaman reitityslogiikan, toiset riippuvat asiakassovelluksista tarjotakseen reititystietoja tai salliakseen molempien paradigmien yhdistelmän. Tällaisissa monimutkaisissa tapauksissa middleware-toiminnon välittäminen yksinkertaistaa kehitystä, integraatiota ja vahvistusta. tietokone [Mediator] voi varmistaa, että oikea viesti saapuu oikealle kuluttajalle.”
Prosessien koreografia ja palvelun orkestrointi	Prosessien koreografia ja palvelun orkestrointi ovat molemmat ”palvelun koostumuksen” muotoja, joissa koordinoidaan mitä tahansa määrää päätepisteitä ja kykyjä. Koreografian ja palvelun orkestroinnin eroavaisuudet ovat: Koreografia voidaan määrittää asynkroniseksi lähestymistavaksi, joka sallii prosessien toimia itsenäisesti ja poistaa kaikki riippuvuuksien aiheuttamat ongelmat, jotka johtuvat yksittäisten yksittäisten yksiköiden ryhmästä, joilla ei ole keskeistä valtuutta vuorovaikuttaakseen. Orkestrointi voidaan määrittää synkronoiduksi lähestymistavaksi, joka sallii kyselyn tai prosessin suorittamisen sallimalla kunkin mikrosivuston toteuttaa orkestroijan kohdistamia tehtäviä, mikä on toimintatapa, joka saadaan keskitetystä johtimesta, joka koordinoi yksittäisten yksiköiden toimia, jotka suorittavat tehtäviä toisistaan riippumatta. Lisäksi orkestrointi näyttää kunkin palvelun koko toimintatavan, kun taas koreografia yhdistää kunkin palvelun käyttöliittymän toimintatapojen kuvaukset. Liiketoimintaprosessien osia voi rakentaa Salesforce-työnkuluissa tai Apexilla. Suosittelemme, että kaikki monimutkaiset orkestroinnit toteutetaan middleware-kerroksessa Salesforcen aikakatkaisuarvojen ja hallintarajoitusten vuoksi, varsinkin ratkaisuissa, jotka vaativat todellisen transaktioiden käsittelyn.
Transaktiivisuus (salaus, allekirjoitus, luotettava toimitus, transaktioiden hallinta)	Transaktiivisuus voidaan määrittää kyvyksi tukea globaaleja transaktioita, jotka sisältävät kaikki tarvittavat toiminnot jokaiselle vaaditulle resurssille. Transaktiivisuus tarkoittaa kaikkien neljän ACID-ominaisuuden tuen, atomisointi, johdonmukaisuus, eristys ja kestävyys, jossa atomisointi takaa työn yksikölle (transaktiolle) kaiken tai ei mitään. Vaikka Salesforce on transaktiivinen itsessään, se ei voi osallistua Salesforcen ulkopuolella käynnistettyihin jaettuihin transaktioihin tai transaktioihin. Tästä syystä oletetaan, että monimutkaisille, usean järjestelmän transaktioita vaativille ratkaisuille transaktiivisuus ja siihen liittyvät periytymisen/kompensaation mekanismit otetaan käyttöön middleware-kerroksessa.
Reititys	Reititys voidaan määrittää määrittämällä monimutkaisen viestien kulun komponentista komponenttiin. Nykyisissä palveluihin perustuvissa ratkaisuissa tällaiset viestikulut voivat perustua useisiin ehtoihin, kuten yläpalkkiin, sisältötyyppiin, sääntöön ja prioriteettiin. Salesforce-integraatioissa oletetaan, että kaikki nämä vaatimukset täyttyvät middleware-kerroksella tai päätepisteellä. Viestien reititys voidaan koodata Apexissa, mutta emme suosittele sitä huolto- ja suorituskykyyn liittyvistä syistä.
Nouda, muunna ja lataa	Nouda, muunna ja lataa (ETL) viittaa prosessiin, joka sisältää: Datan noutaminen lähdejärjestelmistä. Tämä prosessi sisältää tavallisesti dataa useista lähdejärjestelmistä sekä suhteellisista ja ei-suhteellisista rakenteista. Datan muuntaminen toiminnallisiin tarpeisiin, joihin voi sisältyä tietojen laatutasoja. Muunna-vaihe soveltaa tavallisesti lähdepalvelusta kerättyyn dataan sarjaa sääntöjä tai toimintoja saadakseen dataa, joka ladataan päätekohteisiin. Datan lataaminen kohdejärjestelmään. Kohdejärjestelmä voi vaihdella suuresti tietokannasta, toiminta-tietokannasta, datan martista, datan varastosta tai muista käyttöjärjestelmistä. Vaikka useimmat kehittyneet ETL-työkalut eivät ole välttämättä välttämättömiä, ne tarjoavat muutostietojen datan taltiointi. Tällä ominaisuudella työkalu tunnistaa lähdejärjestelmässä tietueet, jotka ovat muuttuneet edellisen noudon jälkeen, mikä vähentää tietueiden käsittelyn määrää. Salesforce tukee nyt myös muutostietojen datan taltiointi, eli Salesforce-tietueisiin tehtyjä muutoksia edustavien muutostapahtumien julkaisemista. Muuta dataa taltiointi -ominaisuuden avulla asiakassovellus tai ulkoinen järjestelmä vastaanottaa Salesforce-tietueiden muutokset lähes reaaliajassa. Näiden tietojen avulla asiakassovellus tai ulkoinen järjestelmä voi synkronoida vastaavia tietueita ulkoisessa datasäilössä.
Pitkä kysely	Pitkä kysely, jota kutsutaan myös Comet-ohjelmoinniksi, imitoi palvelimelta asiakkaalle lähetettyä tiedonsiirtoa. Asiakassovellus muodostaa yhteyden ja pyytää tietoja palvelimelta tavallisen kyselyn tapaisesti. Sen sijaan, että palvelin lähettäisi tyhjän vastauksen, jos tietoja ei ole saatavilla, se säilyttää pyynnön ja odottaa, kunnes tiedot ovat saatavilla (tapahtuma tapahtuu). Sen jälkeen palvelin lähettää asiakassovellukselle täydellisen vastauksen. Sen jälkeen asiakas pyytää tietoja välittömästi uudelleen. Asiakassovellus ylläpitää jatkuvasti yhteyttä palvelimeen, joten se odottaa aina vastausta. Jos palvelin aikakatkaistaan, asiakassovellus muodostaa yhteyden uudelleen ja aloittaa alusta. Salesforce Streaming API käyttää Bayeux-protokollaa ja CometD:ää pitkän kyselyn tekemiseen. Bayeux on protokolla ei-synkronoitujen viestien siirtämiseksi ensisijaisesti HTTP:n kautta. CometD on skaalattava HTTP-pohjainen tapahtumien reititysbussi, joka käyttää AJAX-työntöteknologian kuviota, joka tunnetaan nimellä Comet. Se toteuttaa Bayeux-protokollan.

Konteksti

Käytät Salesforcea seurataksesi liidejä, hallitaksesi myyntiputkeasi, luodaksesi mahdollisuuksia ja kerätäksesi tilaustietoja, jotka muuntavat liidejä asiakkaiksi. Salesforce-järjestelmä ei kuitenkaan sisällä tai käsittele tilauksia. Kun tilauksen lisätiedot on kerätty Salesforcesta, tilaus luodaan etäjärjestelmässä, joka hallitsee tilausta loppuun asti.

Kun otat tämän kuvion käyttöön, Salesforce kutsuu etäjärjestelmää luomaan tilauksen ja odottaa sen onnistuneen suorittamisen. Jos se onnistuu, etäjärjestelmä vastaa tilauksen tilan ja tilausnumeron kanssa synkronoidusti. Salesforce päivittää tilauksen numeron ja tilan sisäisesti osana samaa transaktiota. Tilausnumeroa käytetään vieraana avaimena etäjärjestelmän myöhemmissä päivityksissä.

Ongelma

Kun Salesforcessa tapahtuu tapahtuma, miten käynnistät prosessin etäjärjestelmässä, välität vaaditut tiedot prosessiin, saat vastauksen etäjärjestelmästä ja käytät vastaustietoja päivitysten tekemiseen Salesforcessa?

Voimat

Ota huomioon seuraavat tekijät, kun käytät tähän kuvioon perustuvia ratkaisuja.

Vaatiiko etäjärjestelmään soittaminen, että Salesforce odottaa vastausta ennen käsittelyn jatkamista? Onko etäjärjestelmään tehty puhelu synkronoitu pyyntö/vastaus vai ei-synkronoitu pyyntö?
Jos etäjärjestelmään soitettu puhelu on synkronoitu, täytyykö Salesforcen käsitellä vastaus osana samaa transaktiota kuin ensimmäinen puhelu?
Onko viesti pieni vai suuri?
Perustuuko integraatio tiettyyn tapahtumaan, kuten painikkeen napsautukseen Salesforce-käyttöliittymässä, vai DML-pohjaisiin tapahtumiin?
Voiko etäpäätepiste vastata pyyntöön pienellä viiveellä? Kuinka monta käyttäjää suorittaa tämän transaktion todennäköisesti ruuhka-ajanjakson aikana?

Ratkaisu

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

Ratkaisu	Sovita	Kommentit
Ulkoiset palvelut kutsuu REST API -kutsua	Paras	Ulkoiset palvelut -ominaisuus sallii sinun kutsua ulkoisesti isännöityä palvelua deklaratiivisella tavalla (ei vaadi koodia). Tätä ominaisuutta käytetään parhaiten, kun seuraavat ehdot täyttyvät: Ulkoisesti isännöity palvelu on RESTful-palvelu, ja määritelmät ovat käytettävissä OpenAPI 2.0- tai OpenAPI 3.0- tai YAML-skeemamuodossa. Pyyntöjen ja vastausten määritelmät sisältävät primitiivisiä datatyyppejä, kuten totuusarvo, päivämäärä/aika, kaksinkertainen, kokonaisluku, merkkijono tai primitiivisten datatyyppien taulukko. Sisäkkäisiä objektityyppejä ja lähetä parametrejä, kuten HTTP-pyyntöjen otsakkeita, tuetaan. Transaktiota voidaan kutsua kulusta.
Salesforce Lightning — Lightning tai -sivu käynnistää synkronoidun Apex REST- tai SOAP-kutsun.</ Jos etäpäätepisteellä on riski, että vastaus on pitkä viive (katso uusimmat rajoitukset -dokumentaatio sovellettavista rajoituksista täältä), suosittelemme käyttämään ei-synkronoitua callout-kutsua, jota kutsutaan myös jatkokseksi, välttyäksesi synkronoitujen Apex hallintarajoitusten ylittymiseltä.	Paras	Salesforce sallii sinun kuluttaa WSDL:n ja luoda tuloksena olevan välityspalvelimen Apex. Tämä luokka tarjoaa tarvittavan logiikan etäpalvelun kutsumiseen. Salesforce sallii sinun myös kutsua HTTP (REST) -palveluita käyttämällä tavallisia GET-, POST-, PUT- ja DELETE-metodeja. Käyttäjän käynnistämä toiminto Lightning kutsuu sitten Apex toimintoa, joka suorittaa tämän välityspalvelimen Apex suorittaakseen etäkutsun. Lightning vaativat Salesforce-sovelluksen mukauttamista.
Salesforce-datan muutoksista kutsuttu synkronoitu käynnistin suorittaa asynkronisen Apex SOAP- tai HTTP-callout-kutsun.	Aloptimaali	Voit käyttää Apex suorittaaksesi automaatiota tietueiden datan muutosten perusteella. Apex voidaan suorittaa DML-toiminnon tuloksena käyttämällä Apex. Kaikkien käynnistimen kontekstista tehtyjen puheluiden täytyy kuitenkin suorittaa asynkronisesti käynnistäneestä tapahtumasta. Siksi tätä ratkaisua ei suositella tälle integraatioongelmalle. Tämä ratkaisu soveltuu paremmin Ulkoinen prosessin kutsu -kuvioon — Fire- ja Forget-kuvioille.
Apex suorittaa synkronoidun Apex SOAP- tai HTTP-callout-kutsun.	Aloptimaali	Voit soittaa etäjärjestelmään erätyöstä. Tämä ratkaisu sallii eräprosessin etäprosessin ja vastauksen käsittelyn etäjärjestelmästä Salesforcessa. Tietyssä erässä on kuitenkin puheluiden määrän rajoituksia. Lisätietoja on kohdassa Governor Limits. Eräsuoritus voi suorittaa useita transaktioiden konteksteja (tavallisesti 200 tietueen välein). Hallintarajoitukset nollataan transaktion asiayhteydelle.

Kuvaus

Tämä kaavio kuvaa synkronoitua prosessin etäkutsua käyttämällä Apex.

Salesforcen lähettäminen etäjärjestelmään

Latauskaavio

Tässä skenaariossa:

Lightning käynnistetään toiminto (esimerkiksi painikkeen napsauttaminen).
selain (Lightning asiakassivun ohjaimen kautta) suorittaa HTTP POST -toiminnon, joka puolestaan suorittaa toiminnon vastaavalle Apex.
Ohjain kutsuu todellista puhelua etäpalveluun.
Etäjärjestelmästä saatu vastaus palautetaan Apex. Pääkäyttäjä käsittelee vastauksen, päivittää Salesforcessa olevat tiedot tarvittaessa ja renderöi sivun uudelleen.

Jos seuraavaa tilaa on seurattava, etäjärjestelmä palauttaa yksilöllisen tunnisteen, joka on tallennettu Salesforce-tietueeseen.

Tulokset

Tähän kuvioon liittyvien ratkaisujen käyttö mahdollistaa tapahtumien käynnistämät etäprosessin kutsut, joissa Salesforce käsittelee käsittelyn.

Soitusmekanismit

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

Kutsumismekanismi	Kuvaus
kulkuun upotettu parannettu ulkoinen palvelu tai Lightning tai Apex	Käytetään, kun etäprosessi käynnistetään osana käyttöliittymää käsittelevää loppuun -prosessia, ja tulokset täytyy näyttää tai päivittää Salesforce-tietueessa. Esimerkiksi luottokorttimaksun lähettäminen ulkoiseen maksusiltapalveluun ja maksutulokset palautetaan välittömästi ja näytetään käyttäjälle.
Apex	Käytetään ensisijaisesti etäprosessien kutsumiseen käyttämällä DML-käynnistettyjen tapahtumien Apex. Lisätietoja tästä kutsumismekanismista on kohdassa kuvio Etäprosessin kutsu — Fire and Forget.
Apex	Käytetään etäprosessien kutsumiseksi erissä. Lisätietoja tästä kutsumismekanismista on kohdassa kuvio Etäprosessin kutsu — Fire and Forget.

Virheiden käsittely ja palautus

On tärkeää sisällyttää mukaan virheiden käsittely- ja palautustrategia osana kokonaisratkaisua.

Virheiden käsittely — Kun tapahtuu virhe (poikkeukset tai virhekoodit palautetaan soittajalle), soittaja hallitsee virheiden käsittelyä. Esimerkiksi loppukäyttäjän sivulla näytettävä virheviesti tai taulukkoon kirjattu virheviesti, joka vaatii lisätoimia.
Palautus — Muutoksia ei sovelleta Salesforceen ennen kuin soittaja saa onnistuneen vastauksen. Tilauksen tilaa ei esimerkiksi päivitetä tietokannassa ennen kuin onnistuneen vastauksen saa. Soittaja voi tarvittaessa yrittää toimintoa uudelleen.

Idempotent-suunnittelussa huomioitavia asioita

Idempotent-ominaisuudet varmistavat, että toistuvat kutsut ovat turvallisia. Jos idempotenssia ei oteta käyttöön, saman viestin toistuvat kutsut voivat johtaa eri tuloksiin, mikä saattaa aiheuttaa ongelmia datan yhtenäisyyteen. Mahdollisiin ongelmiin sisältyy identtisten tietueiden luominen tai transaktioiden identtisten tietueiden käsittely.

On tärkeää varmistaa, että kutsuttu etätoimenpide on idempotent. Jos puhelu tehdään käyttöliittymän kautta, meidän on huolehdittava integraatiokerroksessa olevista mahdollisuuksista varsinkin, jos Salesforcen ei voi taata soittavan vain kerran.

Tyypillisin tapa rakentaa idempotent-vastaanotin on se, että se seuraa identtisiä tietueita kuluttajan lähettämien yksilöllisten viestien perusteella. Apex tai REST-kutsuja täytyy mukauttaa lähettääkseen yksilöllisen viestitunnuksen.

Lisäksi operaatioiden, jotka luovat tietueita etäjärjestelmässä, täytyy tarkastaa identtisyydet ennen niiden lisäämistä. Valitse välittämällä yksilöllinen tietuetunnus Salesforcesta. Jos tietue on olemassa etäjärjestelmässä, päivitä tietue. Useimmissa järjestelmissä tätä toimintoa kutsutaan upsert-toiminnoksi.

Turvallisuudessa huomioitavia asioita

Kaikkien etäjärjestelmään soitettujen puheluiden täytyy säilyttää pyynnön luottamuksellisuus, eheys ja saatavuus. Seuraavat tietoturvaan liittyvät asiat koskevat Apex SOAP- ja HTTP-kutsujen käyttöä tässä kuvioissa.

Yksisuuntainen SSL on oletusarvoisesti käytössä, mutta kaksisuuntaista SSL-protokollaa tuetaan sekä itse allekirjoitetuilla että CA-allekirjoitetuilla sertifikaateilla asiakassovelluksen ja palvelimen todennuksen ylläpitämiseksi.
Määritä nimetty tunnus callout-päätepisteeseen virtaviivaistaaksesi Apex ja yksinkertaistaaksesi todennettujen callout-kutsujen määrittämistä.
Harkitse OAUTH 2.0:n käyttämistä todennusmekanisminä ulkoisten järjestelmien integrointiin.
Harkitse tarvittaessa yksisuuntaisten tiivisteiden tai digitaalisten allekirjoitusten käyttämistä Apex Crypto -luokkien menetelmillä pyyntöjen eheyden varmistamiseksi.
Etäjärjestelmä täytyy suojata käyttämällä asiaankuuluvia palomuurimekanismeja. Lisätietoja on kohdassa Turvallisuudessa huomioitavia asioita.
Salesforce ei tue tällä hetkellä WS-Securityta. Vaikka se ei luo näitä monimutkaisia WS-Security-otsakkeita oletusarvoisesti tai noudata niitä automaattisesti saapuvasta WSDL:stä, voit rakentaa ja toteuttaa niitä manuaalisesti luomalla mukautettuja Apex käsittelemään SOAP-otsakkeita ja saapuvien pyyntöjen suojausvaltuuksia.

Sivupalkit

Ei mitään.

Aikaisuus

Aikavyöhyke on merkittävä tässä kuviossa. Tavallisesti:

Pyyntö kutsutaan tavallisesti käyttöliittymästä, joten prosessin ei tarvitse pitää käyttäjää odottamassa.
Salesforcessa voi määrittää Apexista saatujen puheluiden aikakatkaisua enintään 120 sekunniksi.
Etäprosessin suorittaminen suoritetaan ajoissa, jotta se voidaan suorittaa Salesforcen aikakatkaisun rajoituksen ja käyttäjien odotusten mukaisesti.
Ulkoiset puhelut ovat Apexin synkronoitujen transaktioiden hallintarajoitusten alaisia, joten muista vähentää yli 50 transaktion esiintymisen riskiä, jotka kestävät yli viisi sekuntia. Ulkoisen päätepisteen suorituskyvyn varmistamisen lisäksi vaihtoehtoihin aikakatkaisun riskin vähentämiseksi sisältyy:
- Määrität ulkoisen callout-kutsun aikakatkaisuksi viisi sekuntia.
- Jatkamisen käyttäminen Lightning pitkäaikaisten transaktioiden käsittelemiseen

Datan määrät

Tätä kuviota käytetään ensisijaisesti pienille reaaliaikaisille toiminnoille Apex ratkaisun pienien aikakatkaisuarvojen ja pyynnön tai vastauksen enimmäiskokojen vuoksi. Älä käytä tätä kuviota eräkäsittelyoiminnoissa, joissa tietojen hyötykuorma sisältyy viestiin.

Päätepisteen kapasiteetin ja standardien tuki

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

Ratkaisu	Päätepisteissä huomioitavia asioita
Apex HTTP -kutsut	Päätepisteen täytyy voida vastaanottaa HTTP-kutsuja. Salesforcen täytyy voida käyttää päätepistettä julkisen Internet-yhteyden kautta. Yksityisen ja turvallisen viestinnän osalta Salesforce on nyt aloittanut myös Salesforce Private -yhteyden tukemisen Hyperforce Platformin kautta turvallisesti. Lisätietoja on kohdassa Salesforce Private Connect. Voit käyttää Apex HTTP -kutsuja kutsuaksesi REST-palveluita käyttämällä vakiomuotoisia GET-, POST-, PUT-, DELETE- ja PATCH-metodeja.
Apex SOAP -kutsut	Päätepisteen täytyy voida vastaanottaa HTTP-kutsuja. Salesforcen täytyy voida käyttää päätepistettä julkisen Internet-yhteyden kautta. Yksityisen ja turvallisen viestinnän osalta Salesforce on nyt aloittanut myös Salesforce Private -yhteyden tukemisen Hyperforce Platformin kautta turvallisesti. Lisätietoja on kohdassa Salesforce Private Connect. Tämä ratkaisu vaatii, että etäjärjestelmä on yhteensopiva Salesforcen tukemien standardien kanssa. Salesforcen tukemat verkkopalvelun standardit Apex SOAP -kutsuille ovat kirjoitushetkellä: WSDL 1.1 SOAP 1.1 WSI-perusprofiili 1.1

Ratkaisu

Päätepisteissä huomioitavia asioita

Apex HTTP -kutsut

Päätepisteen täytyy voida vastaanottaa HTTP-kutsuja. Salesforcen täytyy voida käyttää päätepistettä julkisen Internet-yhteyden kautta. Yksityisen ja turvallisen viestinnän osalta Salesforce on nyt aloittanut myös Salesforce Private -yhteyden tukemisen Hyperforce Platformin kautta turvallisesti. Lisätietoja on kohdassa Salesforce Private Connect.

Voit käyttää Apex HTTP -kutsuja kutsuaksesi REST-palveluita käyttämällä vakiomuotoisia GET-, POST-, PUT-, DELETE- ja PATCH-metodeja.

Apex SOAP -kutsut

Päätepisteen täytyy voida vastaanottaa HTTP-kutsuja. Salesforcen täytyy voida käyttää päätepistettä julkisen Internet-yhteyden kautta. Yksityisen ja turvallisen viestinnän osalta Salesforce on nyt aloittanut myös Salesforce Private -yhteyden tukemisen Hyperforce Platformin kautta turvallisesti. Lisätietoja on kohdassa Salesforce Private Connect.

Tämä ratkaisu vaatii, että etäjärjestelmä on yhteensopiva Salesforcen tukemien standardien kanssa. Salesforcen tukemat verkkopalvelun standardit Apex SOAP -kutsuille ovat kirjoitushetkellä:

WSDL 1.1
SOAP 1.1
WSI-perusprofiili 1.1

Valtion hallinta

Kun integroit järjestelmiä, avaimet ovat tärkeitä tilojen jatkuvalle seurannalle. Sinulla on kaksi vaihtoehtoa.

Salesforce tallentaa etäjärjestelmän etätietueen ensisijaisen tai yksilöllisen korvaava avaimen.
Ulkoinen järjestelmä tallentaa Salesforcen yksilöllisen tietuetunnuksen tai jonkin muun yksilöllisen korvaava avaimen.

Integraatioavaimien käsittelyssä on erityisiä huomioitavia asioita, riippuen päätietueen sisältävästä järjestelmästä, niin kuin alla olevassa taulukossa on kuvattu.

Päätieto	Järjestelmä Kuvaus
Salesforce	Ulkoinen järjestelmä tallentaa joko Salesforce RecordId -arvon tai jonkin muun yksilöllisen korvaava avaimen tietueesta.
Ulkoinen järjestelmä	Etäprosessin kutsu palauttaa yksilöllisen avaimen sovelluksesta, ja Salesforce tallentaa avaimen arvon yksilölliseen tietuekenttään.

Monimutkaiset integraatioskenaariot

Joissakin tapauksissa tämän kuvion määrittämä ratkaisu voi vaatia useiden monimutkaisten integraatioskenaarioiden toteuttamista. Tämä tapahtuu parhaiten käyttämällä middleware-ohjelmistoa tai kutsumalla Salesforcea yhdistelmäpalveluun. Näihin skenaarioihin sisältyy:

Monimutkaisia kulkujen logiikkaa sisältävien liiketoimintaprosessien ja -sääntöjen orkestrointi
Puheluiden ja niiden tulosten aggregointi useisiin järjestelmiin
Saapuvien ja lähtevien viestien transformaatio
Transaktioiden eheyden ylläpito useisiin järjestelmiin lähetetyissä puheluissa

Päälliköiden rajoitukset

Lisätietoja Apex-rajoituksista on Apex Developer Guide -oppaan kohdassa Execution Governors and Limits.

Middleware-ominaisuudet

Seuraava taulukko korostaa tämän kuvion sisältävän middleware-järjestelmän halutut ominaisuudet.

Ominaisuus	Pakollinen	Haluttu	Ei pakollinen
Tapahtumien käsittely		X
Protokollan muuntaminen		X
Käännös ja transformaatio		X
Jonot ja puskurointi		X
Synkronoidut kuljetusprotokollat	X
Ei-synkronoidut kuljetusprotokollat			X
Välitysreititys		X
Prosessien koreografia ja palvelun orkestrointi		X
Transaktiivisuus (salaus, allekirjoitus, luotettava toimitus, transaktioiden hallinta)		X
Reititys			X
Nouda, muunna ja lataa			X
pitkä kysely			X

Esimerkki

Apupalveluyritys käyttää Salesforcea ja sillä on erillinen järjestelmä, joka sisältää asiakkaan laskutustiedot. Osana tilausprosessia laskutusjärjestelmässä täytyy luoda uusia laskutustilejä, ja Salesforcen tulisi näyttää laskutustilin numero tilauksen aktivointiprosessissa. Heillä on olemassa oleva verkkopalvelu, joka sallii laskutustilin luomisen ja palauttaa laskutustilin numeron vastauksena.

Tämä vaatimus voidaan saavuttaa seuraavalla tavalla.

Salesforce kuluttaa laskutuspalvelun WSDL-tiedoston Apex.
Suorita Apex, jonka asiakastiedot välitetään ulkoiseen verkkopalveluun mukautetusta Apex tai ulkoisesta palvelusta.
Mukautettu ohjain jäsentää Apex palautusarvot ja tallentaa tiedot Salesforce-objektiin.

Tämä esimerkki osoittaa, että:

Asiakkaan tilaa seurataan Salesforce-tiliobjektin tilinumerolla.
Soittajan vastausviestin myöhempi käsittely

Konteksti

Käytät Salesforcea seurataksesi liidejä, hallitaksesi myyntiputkeasi, luodaksesi mahdollisuuksia ja kerätäksesi tilaustietoja, jotka muuntavat liidejä asiakkaiksi. Laskutustili täytyy kuitenkin luoda tilauksen laskutusjärjestelmään osana tilaustenhallintaprosesseja.

Kun otat tämän kuvion käyttöön, Salesforce kutsuu etäjärjestelmää luomaan laskutustilin, mutta ei odota, että puhelu on suoritettu onnistuneesti. Ulkoinen järjestelmä voi halutessaan päivittää Salesforcen uudella laskutustilillä, joka luotiin erillisessä transaktiossa.

Ongelma

Kun tapahtuma tapahtuu Salesforcessa, miten käynnistät prosessin etäjärjestelmässä ja välität vaaditut tiedot prosessiin odottamatta vastausta etäjärjestelmästä?

Voimat

Ota huomioon seuraavat tekijät, kun käytät tähän kuvioon perustuvia ratkaisuja.

Vaatiiko etäjärjestelmään soittaminen, että Salesforce odottaa vastausta ennen käsittelyn jatkamista? Onko puhelu etäjärjestelmään synkronoitu vai ei-synkronoitu?
Jos puhelu etäjärjestelmään on synkronoitu, täytyykö Salesforcen käsitellä vastaus osana samaa transaktiota kuin puhelu?
Onko viesti pieni?
Perustuuko integraatio tiettyyn tapahtumaan, kuten painikkeen napsautukseen Salesforce-käyttöliittymässä, vai DML-pohjaisiin tapahtumiin?
Onko varmistettu viestien toimittaminen Salesforcesta etäjärjestelmään vaatimus?
Voiko etäjärjestelmä osallistua sopimuksen ensisijaiseen integraatioon, jossa Salesforce määrittää sopimuksen? Joissakin ratkaisuvarianteissa (esimerkiksi lähtevä viestintä) Salesforce määrittää sopimuksen, jonka etäjärjestelmän päätepiste toteuttaa.
Tukeeko päätepiste tai Enterprise Service Bus (ESB) pitkäaikaista kyselyä?
Ovatko deklaratiiviset määritysmenetelmät suositeltuja mukautetun Apex sijaan? Tässä tapauksessa ratkaisut, kuten sovellusalustan tapahtumat, ovat Apex parempia.

Ratkaisu

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

Ratkaisu	Sovita	Kommentit
Kulkuihin perustuvat sovellusalustan tapahtumat	Paras	Luo kulkuja deklaratiivisesti toteuttaaksesi sovellusalustan tapahtumia. Suositeltu ratkaisu on, kun etäprosessia kutsutaan lisää- tai päivitystietueesta. Sovellusalustan tapahtumat ovat tapahtumaviestejä (tai ilmoituksia), joita sovelluksesi lähettävät ja vastaanottavat jatkaakseen toimintoja. Sovellusalustan tapahtumat yksinkertaistavat muutosten ilmoittamisen ja niihin vastaamisen prosessia kirjoittamatta monimutkaista logiikkaa. Yksi tai useampi tilaaja voi kuunnella samaa tapahtumaa ja suorittaa toimintoja. Esimerkiksi ohjelmistojärjestelmä voi lähettää tapahtumia, jotka sisältävät tietoja tulostimen mustepatruudeista. Tilaajat voivat tilata tapahtumia valvoakseen tulostimen mustepitoisuuksia ja tehdä tilauksia korvatakseen mustepatruunat, joiden mustepitoisuus on alhainen. Ulkoiset sovellukset voivat kuunnella tapahtumaviestejä tilaamalla kanavan CometD:n kautta. Myös sovellusalustan sovellukset, kuten Lightning, voivat tilata tapahtumaviestejä CometD:n avulla. Salesforce PubSub -sovellus, joka perustuu gRPC- ja HTTP/2, voidaan käyttää myös tässä. Salesforce tukee myös sovellusalustan tapahtumien käynnistämiä kulkuja, mikä mahdollistaa kuuntelijan luomisen Flow Builderin käyttöliittymästä. Tämäntyyppinen kulku käynnistyy automaattisesti, kun tietty sovellusalustan tapahtumaviesti julkaistaan Salesforce-tapahtumaväylässä.
Pub/Sub API	Paras	Pub/Sub API on suositeltu tapa ulkoisille kuluttajille kuluttaa tapahtumaväylän tapahtumia. gRPC-pohjainen Pub/Sub API : Tukee sovellusalustan tapahtumien julkaisemista ja tilaamista ulkoisista sovelluksista Käytettävissä oikealla todennuksella (OAuth, JWT tai istuntovaltuudet) Kun sovellusalustan tapahtuma on määritetty Salesforcessa, se on käytettävissä sekä sisäisille että ulkoisille kuluttajille.
Muuta datan taltiointi	Paras	Muutosdatan datan taltiointi (CDC) julkaisee tapahtumia Salesforce-tietueiden muutoksille, jotka vastaavat luonti-, päivitys-, poisto- ja kumoustoimintoja. Muutosdatan datan taltiointi (CDC) ottaminen käyttöön Salesforcessa on pelkästään deklaratiivinen prosessi, joka ei vaadi Apex. Ilmoitusviestit lähetetään tapahtumaväylään, jonka asiakkaat voivat tilata käyttämällä Pub/Sub API- tai Apex. Tapahtumiin perustuvat järjestelmät virtaviivaistavat jaettujen yritysjärjestelmien välistä viestintää, parantavat skaalattavuutta ja tarjoavat reaaliaikaista dataa. Jos tilaustiedot sijaitsevat esimerkiksi ERP-järjestelmässäsi ja Salesforcessa, voit lähettää tilausten muutostapahtumia Salesforcesta integraatiosovellukseen. Sen jälkeen sovellus synkronoi muutokset ERP-järjestelmässä
Omnistudio-integrointitoimenpiteet	Hyvä	Käytä Omnistudio-integrointitoimenpiteitä automatisoidaksesi datan vuorovaikutukset Salesforcen ja ulkoisten kolmansien osapuolten sovellusten välillä deklaratiivisesti. Integrointitoimenpiteet käsittelevät monimutkaisia datatransformaatioita, API-kutsuja ja tapahtumiin perustuvaa automatisointia, ja ne voivat suorittaa useita toimintoja yhdessä palvelinkutsussa. Käytä integrointitoimenpiteitä, kun käyttäjän ei tarvitse tehdä toimintoja suorituksen aikana ja haluat: Nouda, muuntaa ja lähettää tietoja Salesforcen ja ulkoisten järjestelmien välillä Poista käsittely palvelimelle suorituskyvyn ja skaalattavuuden parantamiseksi Pakkaa useita operaatioita yhteen palvelintransaktioon Ota käyttöön välimuistiin tallentaminen usein käytetyille tiedoille Katso lisätietoja integraatiotoimenpiteistä tästä.
Mukautukseen perustuvat sovellusalustan tapahtumat	Hyvä	Samanlainen kuin kulkuihin perustuvat sovellusalustan tapahtumat, mutta tapahtumat luodaan Apex tai -luokkien avulla. Voit julkaista ja kuluttaa sovellusalustan tapahtumia Apexilla tai API:lla. Sovellusalustan tapahtumat integroituvat Salesforce Platformiin Apex avulla. Käynnistimet ovat tapahtumien kuluttajia Salesforce Platformissa, jotka kuuntelevat tapahtumaviestejä. Kun ulkoinen sovellus käyttää API-rajapintaa tai sisäinen Salesforce-sovellus käyttää tapahtumaviestin julkaisemiseen Apexia, tapahtuman käynnistin käynnistyy. Käynnistimet suorittavat toiminnot vastauksena tapahtumien ilmoituksiin.
Kulkuun perustuva lähtevä viestintä	Sovita	Tämäntyyppiselle integraatiolle suositeltu ratkaisu on, kun etäprosessia kutsutaan lisää- tai päivitystietueesta. Salesforce tarjoaa kulkuun perustuvan lähtevän viestinnän ominaisuuden, joka sallii SOAP-viestien lähettämisen Salesforcen lisäys- tai päivitystoiminnon käynnistämille etäjärjestelmille. Nämä viestit lähetetään ei-synkronoidusti ja ne ovat riippumattomia Salesforce-käyttöliittymästä. Lähtevä viesti lähetetään tiettyyn etäpäätepisteeseen. Ulkoisen palvelun täytyy voida osallistua sopimuksen ensisijaiseen integraatioon, jossa Salesforce tarjoaa sopimuksen. Jos etäpalvelu ei vastaa viestin vastaanottamiseen positiivisella hyväksynnällä, Salesforce yrittää lähettää viestin uudelleen tarjotakseen takaaman toimituksen.
Mukautettu Lightning, joka käynnistää Apex SOAP- tai HTTP-asynkronisen callout-kutsun	Aloptimaali	Tätä ratkaisua käytetään tavallisesti käyttöliittymään perustuvissa skenaarioissa, mutta se vaatii mukautusta. Lisäksi ratkaisun täytyy käsitellä koodissa olevan viestin taattu toimitus. Samanlainen kuin etäprosessin kutsu -ratkaisu — Pyyntö- ja vastauskuvioiden ratkaisu, joka määrittää Lightning-komponentin ja Apex-kutsun avulla. Eroavaisuus on, että tässä muodossa Salesforce ei odota pyynnön suorittamista ennen kuin se siirtää ohjauksen käyttäjälle. Kun etäjärjestelmä on vastaanottanut viestin, se vastaa ja ilmoittaa, että viesti on vastaanotettu, ja käsittelee sen sitten ei-synkronoidusti. Etäjärjestelmä siirtää ohjaimen takaisin Salesforcelle ennen kuin se aloittaa viestin käsittelyn, joten Salesforcen ei tarvitse odottaa käsittelyn suorittamista.
Apex, jotka tekevät Apex SOAP- tai HTTP-kutsusta asynkronisen	Aloptimaali	Voit käyttää Apex suorittaaksesi automaatiota tietueiden datan muutosten perusteella. Apex voidaan suorittaa DML-toiminnon tuloksena käyttämällä Apex. Kaikki käynnistimen kontekstista tehdyt kutsut täytyy kuitenkin suorittaa asynkronisesti.
Apex, jotka tekevät Apex SOAP- tai HTTP-kutsusta asynkronisen	Aloptimaali	Etäjärjestelmään lähetetyt puhelut voidaan suorittaa erätyöstä. Tämä ratkaisu sallii eräprosessin etäprosessin ja vastauksen käsittelyn etäjärjestelmästä Salesforcessa. Tietyn erän asiayhteyden puheluiden määrälle on kuitenkin rajoituksia. Lisätietoja on kohdassa Salesforce Developer Limits and Allocations Quick Reference.

Kuvaus

Seuraava kaavio kuvaa puhelun Salesforcesta etäjärjestelmään, jossa tietueen toimintojen luominen tai päivittäminen käynnistää puhelun.

Latauskaavio

Tässä skenaariossa:

Etäjärjestelmä tilaa sovellusalustan tapahtuman.
Tietyn tietuejoukon päivitys tai lisääminen tapahtuu Salesforcessa.
Salesforce-kulku käynnistyy, kun tietyt ehdot täyttyvät.
Tämä kulku luo sovellusalustan tapahtuman.
Etäkuuntelija vastaanottaa tapahtumaviestin ja asettaa sen paikalliseen jonoon.
Jonotussovellus välittää viestin etäsovellukselle käsittelyä varten.

Jos etäjärjestelmän täytyy suorittaa toimintoja Salesforcea vastaan, voit suorittaa valinnaisen callback-toiminnon.

Tulokset

Tähän kuvioon liittyvien ratkaisujen soveltaminen sallii:

Käyttöliittymän käynnistämät etäprosessin kutsut, joissa transaktion tulokset voidaan näyttää loppukäyttäjälle
DML-tapahtumien käynnistämät etäprosessin kutsut, joissa transaktion tulokset voidaan käsitellä kutsusprosessilla

Soitusmekanismit

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

Kutsumismekanismi	Kuvaus
Kulku	Käytetään prosesseihin perustuvissa ja mukautuksiin perustuvissa ratkaisuissa. Tapahtumat käynnistävät Salesforce-prosessin, joka voi julkaista sovellusalustan tapahtuman etäjärjestelmän tilaamista varten.
Pub / Sub API	Pub/Sub API tarjoaa yhden käyttöliittymän sovellusalustan tapahtumien julkaisemiseen ja tilaamiseen, mukaan lukien reaaliaikaiset tapahtumien valvontatapahtumat ja muutostietojen datan taltiointi. Pub/Sub API perustuu gRPC:ään ja HTTP/2-protokollaan julkaistakseen ja toimittaakseen binääritapahtumaviestejä tehokkaasti Apache Avro -muodossa.
Muuta datan taltiointi	Salesforcen muutostietojen datan taltiointi julkaisee muutostapahtumia, jotka edustavat Salesforce-tietueiden muutoksia. Muutoksiin sisältyy uuden tietueen luominen, olemassa olevan tietueen päivittäminen, tietueen poistaminen ja tietueen poistamisen kumoaminen.
Lightning ja Apex	Käytetään kutsumaan etäprosessia asynkronisesti käyttämällä Apex.
Kulkuun perustuva lähtevä viestintä	Käytetään vain lähtevälle viestintäratkaisulle. DML-tapahtumien luonti- ja päivitysoikeudet käynnistävät Salesforcen työnkulkusäännöt, jotka voivat lähettää viestin etäjärjestelmään.
Apex	Käytetään käynnistimiin perustuville sovellusalustan tapahtumille ja etäprosessien kutsumiselle käyttämällä DML-käynnistettyjen tapahtumien Apex.
Apex	Käytetään etäprosessien kutsumiseksi erätilassa.

Virheiden käsittely ja palautus

Virheiden käsittely- ja palautustrategia täytyy huomioida osana kokonaisratkaisua. Paras tapa riippuu valitsemastasi ratkaisusta.

Ratkaisu	Virheiden käsittely ja palautustrategia
Kulku	Virheiden käsittely — Joissakin tilanteissa kulkujen käsittely saattaa epäonnistua kokonaan. Kun prosessi tai kulun haastattelu epäonnistuu, prosessia tai kulkua viimeksi muokanneelle pääkäyttäjälle lähetetään yksityiskohtainen sähköposti. Muokkaa oletusarvoista toimintatapaa lisäämällä vikapolkuja kaikkiin elementteihin, jotka voivat epäonnistua. Tätä toimintatapaa tulisi parantaa käyttämään mukautettuja toimintatapoja, kuten luoda tapaus tai kirjoittaa virheitä mukautettuun objektiin, jota voidaan valvoa ja seurata. Palautus — Palautus on monimutkaisempi tässä skenaariossa. Mukautettu uudelleenyritysmekanismi täytyy luoda, jos sen edellyttävät palvelun laadun vaatimukset.
Apex	Virheiden käsittely — Ulkoinen järjestelmä poistaa lopetusprosessin kutsut käytöstä, joten callout käsittelee vain poikkeukset etäpalvelun alkuperäisessä kutsussa. Esimerkiksi aikakatkaisutapahtuma käynnistyy, jos etäkutsusta ei saatu positiivista hyväksyntää. Ulkoisen järjestelmän täytyy käsitellä myöhemmät virheet, kun ensimmäinen kutsu välitetään ei-synkronoitavaksi. Palautus — Palautus on monimutkaisempi tässä skenaariossa. Mukautettu uudelleenyritysmekanismi täytyy luoda, jos sen edellyttävät palvelun laadun vaatimukset.
Muutosdatan datan taltiointi (CDC) / Sovellusalustan tapahtumat	Virheiden käsittely — Ulkoisen palvelun täytyy suorittaa virheiden käsittely, koska tapahtuma siirretään tehokkaasti etäjärjestelmään jatkokäsittelyä varten. Koska tämä kuvio on asynkroninen, etäjärjestelmä käsittelee viestien jonon, käsittelyn ja virheiden käsittelyn. Lisäksi sovellusalustan tapahtumia ei käsitellä tietokantatransaktioissa. Tästä syystä julkaistuja sovellusalustan tapahtumia ei voi peruuttaa transaktiossa. Palautus — Koska tämä kuvio on asynkroninen, etäjärjestelmän täytyy käynnistää uudelleenyritykset palvelun laatua koskevien vaatimusten perusteella. Jokaiseen tapahtumaan liittyvä toistotunnus on atominen ja kasvaa jokaisen julkaistun tapahtuman kanssa. Tätä tunnusta voidaan käyttää viestiketjun toistamiseen tietystä tapahtumasta (esimerkiksi edellisen onnistuneesti kaapatun tapahtuman perusteella). Raskaan sovellusalustan tapahtumaviestejä säilytetään 72 tuntia (kolme päivää). Voit noutaa menneitä tapahtumaviestejä, kun käytät CometD-asiakassovellusta kanavan tilaamiseen.

Idempotent-suunnittelussa huomioitavia asioita

Sovellusalustan tapahtumat julkaistaan bussille vain kerran. Salesforce-puolella ei yritetä uudelleen. ESB voi pyytää tapahtumien toistamista. Uudelleentarjouksessa sovellusalustan tapahtuman toistotunnus pysyy samana ja ESB voi yrittää lähettää identtisiä viestejä toistotunnuksen perusteella.

Idempotenssi on tärkeä lähtevälle viestinnälle, koska se on asynkroninen ja yritykset käynnistyvät uudelleen, kun positiivista hyväksyntää ei ole saatu. Tästä syystä etäpalvelun täytyy voida käsitellä Salesforcesta saatuja viestejä helposti.

Lähtevä viestintä lähettää yksilöllisen tunnuksen per viesti, ja tämä tunnus pysyy samana uudelleenkäynnissä. Etäjärjestelmä voi seurata identtisiä viestejä tämän yksilöllisen tunnuksen perusteella. Myös jokaisen päivitettävän tietueen yksilöllinen tunnus lähetetään, ja sitä voidaan käyttää välttämään tietueiden luominen identtisinä.

Etäprosessin kutsuminen — Pyyntö ja vastaus -kuviossa huomioitavat suunnittelussa huomioitavat asiat koskevat myös tätä kuviota.

Turvallisuudessa huomioitavia asioita

Kaikkien etäjärjestelmään soitettujen puheluiden täytyy säilyttää pyynnön luottamuksellisuus, eheys ja saatavuus. Eri tietoturvaan liittyvät asiat riippuvat valitsemastasi ratkaisusta.

Ratkaisu	Tietoturvassa huomioitavia asioita
Apex	Etäjärjestelmään soittamisen täytyy säilyttää pyynnön luottamuksellisuus, eheys ja saatavuus. Alla on seuraavat Apex SOAP- ja HTTP-kutsujen käyttämiseen liittyvät tietoturvaan liittyvät seikat tässä kuvioissa. Yksisuuntainen SSL on oletusarvoisesti käytössä, mutta kaksisuuntaista SSL-protokollaa tuetaan sekä itse allekirjoitetuilla että CA-allekirjoitetuilla sertifikaateilla asiakassovelluksen ja palvelimen todennuksen ylläpitämiseksi. Salesforce ei tue WS-Security-ominaisuutta, kun Apex luodaan. Harkitse tarvittaessa yksisuuntaisten tiivisteiden tai digitaalisten allekirjoitusten käyttämistä Apex Crypto -luokan menetelmillä pyynnön eheyden varmistamiseksi. Etäjärjestelmä täytyy suojata käyttämällä asiaankuuluvia palomuurimekanismeja.
Muutosdatan datan taltiointi (CDC) / Sovellusalustan tapahtumat	Sovellusalustan tapahtumien tilaajan ulkoisen järjestelmän täytyy voida todentaa Salesforce Streaming API -rajapintaan. Sovellusalustan tapahtumat noudattavat Salesforce-organisaatiossa määritettyä olemassa olevaa suojausmallia. Käyttäjällä täytyy olla tapahtumaentiteetin lukuoikeus tilatakseen tapahtuman. Käyttäjällä täytyy olla tapahtumaentiteetin luontioikeus julkaistakseen tapahtuman.

Ratkaisu

Tietoturvassa huomioitavia asioita

Apex

Etäjärjestelmään soittamisen täytyy säilyttää pyynnön luottamuksellisuus, eheys ja saatavuus. Alla on seuraavat Apex SOAP- ja HTTP-kutsujen käyttämiseen liittyvät tietoturvaan liittyvät seikat tässä kuvioissa.

Yksisuuntainen SSL on oletusarvoisesti käytössä, mutta kaksisuuntaista SSL-protokollaa tuetaan sekä itse allekirjoitetuilla että CA-allekirjoitetuilla sertifikaateilla asiakassovelluksen ja palvelimen todennuksen ylläpitämiseksi.
Salesforce ei tue WS-Security-ominaisuutta, kun Apex luodaan.
Harkitse tarvittaessa yksisuuntaisten tiivisteiden tai digitaalisten allekirjoitusten käyttämistä Apex Crypto -luokan menetelmillä pyynnön eheyden varmistamiseksi.
Etäjärjestelmä täytyy suojata käyttämällä asiaankuuluvia palomuurimekanismeja.

Muutosdatan datan taltiointi (CDC) / Sovellusalustan tapahtumat

Sovellusalustan tapahtumien tilaajan ulkoisen järjestelmän täytyy voida todentaa Salesforce Streaming API -rajapintaan.

Sovellusalustan tapahtumat noudattavat Salesforce-organisaatiossa määritettyä olemassa olevaa suojausmallia. Käyttäjällä täytyy olla tapahtumaentiteetin lukuoikeus tilatakseen tapahtuman. Käyttäjällä täytyy olla tapahtumaentiteetin luontioikeus julkaistakseen tapahtuman.

Lisätietoja on kohdassa Turvallisuudessa huomioitavia asioita.

Sivupalkit

Ei mitään.

Aikaisuus

Aikavyöhyke on vähemmän tärkeä tekijä Fire-and-forget-kuviossa. Ohjaustoiminto siirretään takaisin asiakkaalle joko välittömästi tai onnistuneen siirron hyväksymisen jälkeen etäjärjestelmälle. Salesforcen lähtevien viestien yhteydessä hyväksynnän täytyy tapahtua 24 tunnin kuluessa (tätä voidaan pidentää seitsemään päivään); muutoin viesti vanhenee. Salesforce lähettää sovellusalustan tapahtumat tapahtumaväylään eikä odota vahvistusta tai hyväksyntää tilaajalta. Jos tilaaja ei nouda viestiä, hän voi pyytää tapahtuman toistamista käyttämällä tapahtuman vastauksen tunnusta. Raskaan tapahtuman viestejä säilytetään 72 tuntia (kolme päivää). Jos haluat noutaa menneet tapahtumaviestit, käytä CometD-asiakassovellusta tilataksesi kanavan.

Datan määrät

Datan määrässä huomioitavat asiat riippuvat valitsemastasi ratkaisusta. Katso kunkin ratkaisun rajoitukset kohdasta Salesforcen rajoitukset -pikaviite.

Päätepisteen kapasiteetin ja standardien tuki

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

Ratkaisu	Päätepisteissä huomioitavia asioita
Apex SOAP -kutsut	Päätepisteen täytyy voida käsitellä verkkopalvelupuhelu HTTP:n kautta. Salesforcen täytyy voida käyttää päätepistettä julkisen Internet-yhteyden kautta. Tämä ratkaisu vaatii, että etäjärjestelmä on yhteensopiva Salesforcen tukemien standardien kanssa. Salesforcen tukemat verkkopalvelun standardit Apex SOAP -kutsuille ovat kirjoitushetkellä: WSDL 1.1 SOAP 1.1 WSI-perusprofiili 1.1 HTTP
Apex HTTP -kutsut	Päätepisteen täytyy voida vastaanottaa HTTP-kutsuja ja sen täytyy olla Salesforcen käytettävissä julkisella internetillä. Apex HTTP -kutsuja voidaan käyttää kutsuakseen RESTful-palveluita käyttämällä GET-, POST-, PUT- ja DELETE-vakiomenetelmiä.
Muutosdatan datan taltiointi (CDC) / Sovellusalustan tapahtumat	Käynnistimet, prosessit ja kulut voivat tilata tapahtumia. Voit vastaanottaa tapahtumien ilmoituksia riippumatta niiden julkaisutavoista. Käytä CometD-funktiota tilataksesi sovellusalustan tapahtumia ulkoisesta asiakassovelluksesta. Toteuta oma CometD-asiakassovelluksesi tai käytä EMP-liitintä, joka on avoimen lähdekoodin ja yhteisön tukema työkalu, joka käyttää kaikkia CometD-yhteyden muodostamisen ja kanavan kuuntelun lisätietoja. Salesforce lähettää sovellusalustan tapahtumat CometD-asiakkaille järjestyksessä, jossa ne vastaanotetaan. Tapahtumien ilmoitusten järjestys perustuu tapahtumien toistotunnukseen.

Valtion hallinta

Kun integroit järjestelmiä, yksilölliset tietuetunnisteet ovat tärkeitä tilojen jatkuvalle seurannalle. Jos tietue luodaan esimerkiksi etäjärjestelmässä, sinulla on kaksi vaihtoehtoa.

Salesforce tallentaa etäjärjestelmän etätietueen ensisijaisen tai yksilöllisen korvaava avaimen.
Ulkoinen järjestelmä tallentaa Salesforcen yksilöllisen tietuetunnuksen tai jonkin muun yksilöllisen korvaava avaimen.

Seuraava taulukko kuvaa osavaltioiden hallinnassa huomioitavia asioita tässä kuviossa.

Päätieto	Järjestelmä Kuvaus
Salesforce	Ulkoisen järjestelmän täytyy tallentaa Salesforce-tietueeseen joko Salesforce RecordId tai jokin muu yksilöllinen korvaava avain.
Ulkoinen järjestelmä	Salesforcen täytyy tallentaa viite yksilölliseen tunnisteeseen etäjärjestelmään. Koska prosessi on asynkroninen, tämän yksilöllisen tunnisteen tallentaminen ei voi olla osa alkuperäistä transaktiota. Salesforcen täytyy antaa yksilöllinen tunnus etäprosessin kutsussa. Etäjärjestelmän täytyy sitten soittaa takaisin Salesforcelle päivittääkseen Salesforcessa olevan tietueen etäjärjestelmän yksilöllisellä tunnisteella käyttämällä Salesforcen yksilöllistä tunnusta. callback tarkoittaa, että etäsovelluksessa käsitellään tiettyjä tiloja, joihin tallennetaan Salesforcen yksilöllinen tunnus kyseiselle transaktiolle, jota käytetään callback-kutsussa, kun käsittely on suoritettu, tai että Salesforcen yksilöllinen tunnus tallennetaan etäjärjestelmän tietueeseen.

Päätieto

Järjestelmä Kuvaus

Salesforce

Ulkoisen järjestelmän täytyy tallentaa Salesforce-tietueeseen joko Salesforce RecordId tai jokin muu yksilöllinen korvaava avain.

Ulkoinen järjestelmä

Salesforcen täytyy tallentaa viite yksilölliseen tunnisteeseen etäjärjestelmään. Koska prosessi on asynkroninen, tämän yksilöllisen tunnisteen tallentaminen ei voi olla osa alkuperäistä transaktiota.

Salesforcen täytyy antaa yksilöllinen tunnus etäprosessin kutsussa. Etäjärjestelmän täytyy sitten soittaa takaisin Salesforcelle päivittääkseen Salesforcessa olevan tietueen etäjärjestelmän yksilöllisellä tunnisteella käyttämällä Salesforcen yksilöllistä tunnusta.

callback tarkoittaa, että etäsovelluksessa käsitellään tiettyjä tiloja, joihin tallennetaan Salesforcen yksilöllinen tunnus kyseiselle transaktiolle, jota käytetään callback-kutsussa, kun käsittely on suoritettu, tai että Salesforcen yksilöllinen tunnus tallennetaan etäjärjestelmän tietueeseen.

Monimutkaiset integraatioskenaariot

Jokaisella tässä kuviossa olevalla ratkaisulla on erilaiset huomioitavat asiat monimutkaisissa integraatioskenaarioissa, kuten transformaatiossa ja prosessien orkestroinnissa.

Ratkaisu	Huomioitavia asioita
Apex	Joissakin tapauksissa tämän kuviossa määritetyt ratkaisut vaativat useiden monimutkaisten integraatioskenaarioiden toteuttamista, jotka parhaiten toimivat käyttämällä middleware-ohjelmistoa tai Salesforcen kutsumalla yhdistelmäpalvelua. Näihin skenaarioihin sisältyy: Monimutkaisia kulkujen logiikkaa sisältävien liiketoimintaprosessien ja -sääntöjen orkestrointi Puheluiden ja niiden tulosten aggregointi useisiin järjestelmiin Saapuvien ja lähtevien viestien transformaatio Transaktioiden eheyden ylläpito useisiin järjestelmiin lähetetyissä puheluissa
Muutosdatan datan taltiointi (CDC) / Sovellusalustan tapahtumat	Tapahtumien staattisen ja deklaratiivisen luonteen vuoksi monimutkaisia integraatioskenaarioita, kuten aggregointia, orkestrointia tai transformaatiota, ei voi suorittaa Salesforcessa. Ulkoisen järjestelmän tai välitysohjelmiston täytyy käsitellä seuraavantyyppisiä toimintoja.
OmniStudio-integrointitoimenpiteet	Integrointitoimenpiteet (OmniStudio) tarjoavat palvelinpuolen orkestroinnin ilman tilaa koordinoidakseen useita taustapalveluita suorittaessaan monimutkaisia, deklaratiivisia datan transformaatioita. Integrointitoimenpiteet ketjuttavat vaiheita, kuten HTTP-toiminnot, DataRaptor-nouto/transformaatio/lataus, arvojen asettaminen, silmukka/jos ja matriisiraportit, normalisoidakseen, rikastaakseen, aggregoidakseen ja kartoittaakseen hyötykuormia käyttöliittymän sopimusten ja eri API-rajapintojen välillä. Ne tukevat tehokkaita suorituksen aikaisia ohjaimia, kuten ehdollista haarautumista, sivutusta, aikakatkaisua, uudelleenyrityksiä, osittaisen epäonnistumisen käsittelyä ja jatkamista virheestä, sekä suorituskyvyn optimointeja, kuten palvelinpuolen välimuistiin tallentamista ja vastausten muotoilua. IP-osoitteita voidaan kutsua synkronoidusti OmniScriptista tai headlessly REST:n kautta, mikä mahdollistaa uudelleenkäytettävissä olevat ja versioidut ”integrointifasetit”, jotka piilottavat taustalla olevan monimutkaisuuden kanavista.

Päälliköiden rajoitukset

Salesforce-sovellusalustan monivaltuuden vuoksi lähtevien callout-kutsujen käyttö on rajoitettu. Rajoitukset riippuvat lähtevän puhelun tyypistä ja puhelun ajoituksesta.

Lisätietoja sovellusalustan tapahtumien rajoituksista ja rajoituksista on kohdassa Platforms Events Developer Guide.

Luotettava viestintä

Luotettava viestintä yrittää ratkaista ongelman, joka koskee viestin toimittamisen takaamista etäjärjestelmään, jossa yksittäiset komponentit eivät ole luotettavia. Tapa, jolla etäjärjestelmä voi varmistaa viestin vastaanottamisen, riippuu valitsemastasi ratkaisusta.

Salesforce Change -datan taltiointi tarjoaa muutostapahtumien tyypit käsittelemään erityisiä tilanteita, kuten tallentamalla muutoksia, joita ei havaita Salesforce-sovelluspalvelimissa, tai käsittelemällä paljon muutoksia.

Joissakin tapauksissa Salesforce lähettää Gap-tapahtumia muutostapahtumien sijaan ilmoittaakseen tilaajille virheistä tai jos muutostapahtumien luominen ei ole mahdollista. Taukotapahtuma sisältää tietoja otsakkeessa olevasta muutoksesta, kuten muutostyypin ja tietueen tunnuksen. Se ei sisällä muutosta koskevia tietoja, kuten tietueiden kenttiä. Ylivuotojen tapahtumat luodaan yksittäisille transaktioille, jotka ylittävät kynnysarvon, jotta muutokset voidaan siepata tehokkaammin. Katso lisätietoja tästä.

Ratkaisu	Luotettavissa viesteissä huomioitavia asioita
Apex	Salesforce ei tarjoa suoraa tukea luotettaville viestintäprotokollille (esimerkiksi WS-ReliableMessaging). Suosittelemme, että Salesforce-viestin vastaanottava etäpäätepiste käyttää luotettavaa viestintäjärjestelmää, kuten JMS tai MQ. Tämä järjestelmä varmistaa täyden lopputuloksen ja varmistetun toimituksen etäjärjestelmään, joka lopulta käsittelee viestin. Tämä järjestelmä ei kuitenkaan takaa toimitusta Salesforcesta sen kutsumaan etäpäätepisteeseen. Takuutettu toimitus täytyy käsitellä Salesforcen mukautuksilla. Sinun täytyy käyttää tiettyjä tekniikoita, kuten käsitellä positiivinen hyväksyntä etäpäätepisteestä mukautetun uudelleenyrityslogiikan lisäksi.
Muutosdatan datan taltiointi (CDC) / Sovellusalustan tapahtumat	Sovellusalustan tapahtumat -ominaisuus yrittää tarjota luotettavaa viestintää säilyttämällä tapahtumaviestit väliaikaisesti tapahtumaväylässä. Tilaajat voivat seurata puuttuvia tapahtumaviestejä toistamalla viestejä tapahtumaväylästä käyttämällä tapahtumaviestien toistotunnusta. Tapahtumaväli on jaettu järjestelmä eikä sillä ole samoja takuita kuin transaktioiden tietokannalla. Tästä syystä Salesforce ei voi tarjota synkronoitua vastausta tapahtuman julkaisupyyntöön. Tapahtumat asetetaan jonoon ja välimuistiin, ja Salesforce yrittää julkaista tapahtumat ei-synkronoidusti. Harvoissa tapauksissa tapahtumaviesti ei välttämättä säilytetä jaetussa järjestelmässä ensimmäisen tai seuraavan yrityksen aikana. Tämä tarkoittaa, että tapahtumia ei toimiteta tilaajille eikä niitä voi palauttaa.

Ratkaisu

Luotettavissa viesteissä huomioitavia asioita

Apex

Salesforce ei tarjoa suoraa tukea luotettaville viestintäprotokollille (esimerkiksi WS-ReliableMessaging). Suosittelemme, että Salesforce-viestin vastaanottava etäpäätepiste käyttää luotettavaa viestintäjärjestelmää, kuten JMS tai MQ. Tämä järjestelmä varmistaa täyden lopputuloksen ja varmistetun toimituksen etäjärjestelmään, joka lopulta käsittelee viestin. Tämä järjestelmä ei kuitenkaan takaa toimitusta Salesforcesta sen kutsumaan etäpäätepisteeseen.

Takuutettu toimitus täytyy käsitellä Salesforcen mukautuksilla. Sinun täytyy käyttää tiettyjä tekniikoita, kuten käsitellä positiivinen hyväksyntä etäpäätepisteestä mukautetun uudelleenyrityslogiikan lisäksi.

Muutosdatan datan taltiointi (CDC) / Sovellusalustan tapahtumat

Sovellusalustan tapahtumat -ominaisuus yrittää tarjota luotettavaa viestintää säilyttämällä tapahtumaviestit väliaikaisesti tapahtumaväylässä. Tilaajat voivat seurata puuttuvia tapahtumaviestejä toistamalla viestejä tapahtumaväylästä käyttämällä tapahtumaviestien toistotunnusta.

Tapahtumaväli on jaettu järjestelmä eikä sillä ole samoja takuita kuin transaktioiden tietokannalla. Tästä syystä Salesforce ei voi tarjota synkronoitua vastausta tapahtuman julkaisupyyntöön. Tapahtumat asetetaan jonoon ja välimuistiin, ja Salesforce yrittää julkaista tapahtumat ei-synkronoidusti. Harvoissa tapauksissa tapahtumaviesti ei välttämättä säilytetä jaetussa järjestelmässä ensimmäisen tai seuraavan yrityksen aikana. Tämä tarkoittaa, että tapahtumia ei toimiteta tilaajille eikä niitä voi palauttaa.

Middleware-ominaisuudet

Seuraava taulukko korostaa tämän kuvion sisältävän middleware-järjestelmän halutut ominaisuudet.

Ominaisuus	Pakollinen	Haluttu	Ei pakollinen
Tapahtumien käsittely		X
Protokollan muuntaminen		X
Käännös ja transformaatio		X
Jonot ja puskurointi	X
Synkronoidut kuljetusprotokollat			X
Ei-synkronoidut kuljetusprotokollat	X
Välitysreititys		X
Prosessien koreografia ja palvelun orkestrointi		X
Transaktiivisuus (salaus, allekirjoitus, luotettava toimitus, transaktioiden hallinta)	X
Reititys			X
Nouda, muunna ja lataa			X
pitkä kysely	X (pakollinen sovellusalustan tapahtumille)

Ratkaisun muuttuja — Sovellusalustan tapahtumat: Julkaisutapa ja transaktiot

Kun sovellusalustan tapahtumaviestit julkaistaan välittömästi, tapahtumien julkaisu ei noudata julkaisuprosessin transaktioiden rajoituksia. Tapahtumaviestit voidaan julkaista ennen transaktion suorittamista tai vaikka transaktio epäonnistuisi. Tämä toimintatapa voi aiheuttaa ongelmia, kun tilaaja odottaa löytävänsä tietoja, jotka julkaisutapahtuma sitouttaa. Data ei välttämättä ole läsnä, kun tilaaja vastaanottaa tapahtumaviestin. Voit ratkaista tämän ongelman määrittämällä sovellusalustan tapahtuman julkaisutavan tapahtuman määritelmässä Julkaise sitoutuksen jälkeen. Sovellusalustan tapahtumien määritelmässä määritettävät julkaisutavat ovat:

Julkaise Vähimmäissumman jälkeen julkaistaksesi tapahtumaviestin vasta, kun transaktio on sitoutunut onnistuneesti. Valitse tämä vaihtoehto, jos tilaajat luottavat julkaistavan transaktion sitouttamiin tietoihin. Esimerkiksi prosessi julkaisee tapahtumaviestin ja luo tehtävätietueen. Toinen tapahtumaan tilattu prosessi käynnistyy ja odottaa löytävän tehtävätietueen. Toinen syy tähän toimintatapaan on, että et halua julkaista tapahtumaviestiä, jos transaktio epäonnistuu.
Julkaise välittömästi näyttääksesi tapahtumaviestin, kun julkaisukutsu suoritetaan. Valitse tämä vaihtoehto, jos haluat julkaista tapahtumaviestin riippumatta siitä, onnistuiko transaktio. Valitse tämä vaihtoehto myös, jos julkaisija ja tilaajat ovat itsenäisiä ja tilaajat eivät luota julkaisijan sitouttamiin tietoihin. Välitön julkaisutapa soveltuu esimerkiksi tapahtumaan, jota käytetään lokitarkoituksiin. Tämän vaihtoehdon avulla tilaaja saattaa saada tapahtumaviestin ennen kuin julkaisija-transaktio sitouttaa dataa.

Esimerkki

Telekommunikaatioyritys haluaa käyttää Salesforcea etusijana tilien luomiseen liidistä mahdollisuuteen -prosessin avulla. Salesforcessa luodaan tilaus, kun mahdollisuus on suljettu ja voitettu, mutta datan pääjärjestelmä on taustalla oleva ERP-järjestelmä. Tilaus täytyy tallentaa Salesforce-mahdollisuustietueeseen ja mahdollisuuden tila muuttui osoittamaan, että tilaus luotiin.

Seuraavat rajoitukset ovat voimassa.

Vain deklaratiivinen kehitys voidaan toteuttaa.
Et tarvitse ilmoitusta tilauksen numerosta välittömästi, kun mahdollisuus on muunnettu tilaukseksi.
Organisaatiolla on ESB, joka tukee CometD-protokollaa ja voi tilata sovellusalustan tapahtumia.

Tämä esimerkki on paras toteuttaa Salesforce Platform -tapahtumilla, mutta vaatii, että ESB tilaa sovellusalustan tapahtuman.

Salesforce-puolella:

Luo kulku käynnistääksesi sovellusalustan tapahtuman (kun esimerkiksi mahdollisuuden tilaksi muuttuu Suljettu/voitettu).
Luo uusi sovellusalustan tapahtuma, joka julkaisee mahdollisuuden lisätiedot.

Järjestelmän etäpuolella:

ESB tilaa Salesforce Platform -tapahtuman käyttämällä CometD-protokollaa.
ESB saa yhden tai useamman ilmoituksen, joka ilmoittaa, että mahdollisuus muunnetaan tilaukseksi.
ESB välittää viestin taustalla olevaan ERP-järjestelmään, jotta tilaus voidaan luoda.
Kun tilaus on luotu ERP-järjestelmässä, erillinen ketju kutsuu takaisin Salesforceen käyttämällä todennusvaltuutta SessionId. Callback päivittää mahdollisuuden tilauksen numerolla ja tilalla. Voit tehdä tämän callback-kutsun käyttämällä dokumentoituja kuvion ratkaisuja, kuten Salesforce Platform -tapahtumia, Salesforce SOAP API:a, REST API:a tai Apex.

Tämä esimerkki osoittaa seuraavaa.

Asynkronisesti kutsutun etäprosessin toteutus
Taattu toimitus loppuun asti
Seuraava callback-kutsu Salesforcelle tietueen tilan päivittämiseksi

Konteksti

Olet siirtämässä CRM-toteutustasi Salesforceen ja haluat:

Nouda ja muunna tilejä, yhteyshenkilöitä ja mahdollisuuksia tämänhetkisestä CRM-järjestelmästä ja lataa data Salesforceen (alustava tietojen tuonti).
Nouda, muunna ja lataa asiakkaan laskutustietoja Salesforceen etäjärjestelmästä viikoittain (johdossa).
Nouda asiakkaiden toimintojen tietoja Salesforcesta ja tuo ne paikalliseen datan varastoon viikoittain (jatkossakin).

Ongelma

Miten tuot dataa Salesforceen ja viet dataa Salesforcesta, kun otat huomioon, että nämä tuonnit ja viennit voivat häiritä loppukäyttäjien toimintoja toimistoaikojen aikana ja sisältää suuria määriä dataa?

Voimat

Tähän kuvioon perustuvia ratkaisuja käytettäessä on huomioitava useita eri tekijöitä:

Pitäisikö dataa säilyttää Salesforcessa? Jos näin ei ole, arkkitehti voi ja tulisi harkita muita integraatiovaihtoehtoja (esimerkiksi täsmäyksiä).
Jos dataa tulisi säilyttää Salesforcessa, tulisiko data päivittää vastauksena etäjärjestelmän tapahtumaan?
Täytyykö data päivittää ajoitetusti?
Tukeeko data ensisijaisia liiketoimintaprosesseja?
Onko analyysejä (raportointia) koskevia vaatimuksia, jotka vaikuttavat tämän datan saatavuuteen Salesforcessa?

Ratkaisu

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

Ratkaisu	Sovita	Datan päätieto	Kommentit
Replikointi kolmannen osapuolen ETL-työkalun kautta	Paras	Ulkoinen järjestelmä	Jos ulkoisen järjestelmän täytyy lähettää suuria määriä dataa Salesforceen, hyödynnä kolmannen osapuolen ETL-työkalua, jonka avulla voit suorittaa muutostietojen datan taltiointi perusteella. Työkalu reagoi lähdedatajoukon muutoksiin, muuntaa tiedot ja kutsuu sitten Salesforce Bulk API:a luomaan DML-lausekkeita. Tämä voidaan toteuttaa myös käyttämällä Salesforce REST API -rajapintoja, jos tietueita on vähemmän.
Replikointi kolmannen osapuolen ETL-työkalun kautta	Hyvä	Salesforce	Hyödynnä kolmannen osapuolen ETL-työkalua, jonka avulla voit suorittaa muutostietojen datan taltiointi ERP- ja Salesforce-datajoukoille. Tässä ratkaisussa tietolähde on Salesforce, ja voit käyttää yksittäisten rivien aikaan ja tilaan liittyviä tietoja kyselläksesi dataa ja suodattaaksesi tavoitteen tulosjoukkoa. Tämä voidaan toteuttaa käyttämällä Bulk API 2.0 -rajapintaa tai tavallista REST API -rajapintaa (jos tietueita on vähemmän ).
Tietojen ohjattu tuontitoiminto ja Data Loader	Sovita	Salesforce / Ulkoinen järjestelmä	Tietojen ohjattua tuontitoimintoa ja Data Loaderia voidaan käyttää tietojen tuomiseen, viemiseen ja siirtämiseen. Data Loaderin komentoja voidaan komentosarjoittaa myös datan tuonnin ja viennin automatisoimiseksi, mutta komentorivikäyttöliittymä on tarkoitettu vain Windowsille. Kumpikaan näistä työkaluista ei ole suositeltu pohja datan integrointistrategialle. Sen sijaan niiden tulisi täydentää datan hallinta- ja ylläpitostrategiaasi. Lisätietoja Data Loaderista on tässä.
Etäkutsu	Aloptimaali	Ulkoinen järjestelmä	Etäjärjestelmä voi kutsua Salesforcea käyttämällä jotakin API-rajapintoja ja suorittaakseen päivityksiä tietoihin niiden tapahtuessa. Tämä aiheuttaa kuitenkin huomattavan liikenteen kahden järjestelmän välillä. Virheiden käsittelyyn ja lukitsemiseen tulisi kiinnittää enemmän huomiota. Tämä kuvio voi aiheuttaa jatkuvia päivityksiä, mikä saattaa vaikuttaa loppukäyttäjien suorituskykyyn.
Prosessien etäkutsut	Aloptimaali	Salesforce	Salesforce voi kutsua etäjärjestelmään ja suorittaa päivityksiä tietoihin niiden tapahtuessa. Tämä aiheuttaa kuitenkin huomattavan liikenteen kahden järjestelmän välillä. Virheiden käsittelyyn ja lukitsemiseen tulisi kiinnittää enemmän huomiota. Tämä kuvio voi aiheuttaa jatkuvia päivityksiä, mikä saattaa vaikuttaa loppukäyttäjien suorituskykyyn.

Kuvaus

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

Latauskaavio

Seuraava kaavio kuvaa tapahtumien myöhempää synkronointia lähes reaaliajassa, jossa Salesforce on datan päätoiminto.

Tulokset

Voit integroida Salesforceen ulkoisesti saatuja tietoja seuraavissa tilanteissa:

Ulkoinen järjestelmä on datan pääjärjestelmä — Salesforce on yhden lähdejärjestelmän tai useiden järjestelmien tarjoamien tietojen kuluttaja. Tässä skenaariossa on tavallista, että sinulla on datan varasto tai datan martti, joka kerää tiedot yhteen ennen kuin tiedot tuodaan Salesforceen.
Salesforce on datan pääjärjestelmä — Salesforce on tiettyjen entiteettien tietueiden järjestelmä, ja Salesforce Change Data Taltiointi -asiakassovellukset voivat saada tietoja Salesforce-datan muutoksista.

Tyypillisessä Salesforce-integraatioskenaariossa toteutustiimi tekee jonkin seuraavista:

Ota muutostietojen datan taltiointi käyttöön lähdedatajoukolle.
Toteuta joukko tukevia tietokantarakenteita, joita kutsutaan ohjaustaulukoiksi, keskitason paikallisessa tietokannassa.

ETL-työkalua käytetään sitten ohjelmien luomiseen, jotka:

Lue ohjaustaulukko määrittääksesi työn viimeisen suoritusajan ja kerätäksesi muut tarvittavat ohjausarvot.
Käytä yllä kuvattuja ohjausarvoja suodattimina ja kysele lähdedatajoukkoa.
Käytä esimääritettyjä käsittelysääntöjä, mukaan lukien vahvistus, rikastaminen jne.
Käytä ETL-työkalun käytettävissä olevia liittimiä/transformaatiota luodaksesi kohdedatajoukon.
Kirjoita datajoukko Salesforce-objekteihin.
Jos käsittely onnistuu, päivitä ohjaustaulukon ohjausarvot.
Jos käsittely epäonnistuu, päivitä ohjaustaulukot arvoilla, jotka sallivat uudelleenkäynnistyksen ja poistumisen.

Huomautus: Suosittelemme, että luot ohjaustaulukot ja niihin liittyvät datarakenteet ympäristöön, johon ETL-työkalulla on käyttöoikeus, vaikka Salesforcen käyttöoikeus ei olisikaan käytettävissä. Tämä tarjoaa riittävät kestotasoja. Salesforcea tulisi käsitellä tässä prosessissa ponnahdusikkuna, ja ETL-infrastruktuuri on hub.

Ota seuraavat asiat huomioon, jotta ETL-työkalu voi hyödyntää datan synkronointiominaisuuksia mahdollisimman hyvin:

Ketjuttaa ja järjestellä ETL-töitä tarjotaksesi yhdenmukaisen prosessin.
Käytä molempien järjestelmien ensisijaisia avaimia täsmätäksesi saapuvaa dataa.
Käytä tiettyjä API-metodeja noutaaksesi vain päivitettyä dataa.
Jos tuot alitason tietueita päätiedot–lisätiedot-suhteessa tai hakusuhteessa, ryhmitä tuotu data käyttämällä sen ylätason avainta lähteessä välttyäksesi lukitsemalta. Jos olet esimerkiksi tuomassa yhteyshenkilötietoja, muista ryhmittää yhteyshenkilötiedot ylätason tilin avaimen mukaan, jotta yhden tilin yhteyshenkilöiden enimmäismäärä voidaan ladata yhteen API-kutsuun. Jos tuodun datan ryhmitys epäonnistuu, ensimmäinen yhteyshenkilötietue ladataan ja tilin seuraavat yhteyshenkilötietueet epäonnistuvat tavallisesti API-kutsun asiayhteydessä.
Kaikki tuonnin jälkeiset käsittelyt, kuten käynnistimet, tulisi käsitellä vain valikoidusti.
Jos skenaarioosi liittyy suuria datamääriä, noudata suositeltuja käytäntöjä tästä Trailhead-moduulista Parhaat käytännöt suuria datamääriä käyttäville käyttöönotoille

Virheiden käsittely ja palautus

Virheiden käsittely- ja palautustrategia täytyy huomioida osana kokonaisratkaisua. Paras tapa riippuu valitsemastasi ratkaisusta.

Virheen sijainti	Virheiden käsittely- ja palautustrategia
Salesforcen lukuoikeus käyttämällä Muutosdatan datan taltiointi	Virheiden käsittely — Virheiden käsittely täytyy suorittaa etäpalvelussa, koska tapahtuma välitetään tehokkaasti etäjärjestelmään jatkokäsittelyä varten. Koska tämä kuvio on asynkroninen, etäjärjestelmä käsittelee viestien jonon, käsittelyn ja virheiden käsittelyn. Lisäksi Muuta datan taltiointi -tapahtumia ei käsitellä tietokantatransaktioissa. Tästä syystä julkaistuja tapahtumia ei voi peruuttaa transaktiossa. Palautus — Koska tämä kuvio on asynkroninen, etäjärjestelmän täytyy käynnistää uudelleenyritykset palvelun vaatimusten laadun perusteella. Jokaiseen muutostietojen datan taltiointi liittyvä toistotunnus on atominen ja kasvaa joka kerta, kun tapahtuma julkaistaan. Tätä tunnusta voidaan käyttää viestiketjun toistamiseen tietystä tapahtumasta (esimerkiksi edellisen onnistuneesti kaapatun tapahtuman perusteella). Raskaan sovellusalustan tapahtumaviestejä säilytetään 72 tuntia (3 päivää). Voit noutaa menneitä tapahtumaviestejä, kun käytät CometD-asiakassovellusta kanavan tilaamiseen.
Luku Salesforcesta käyttämällä kolmannen osapuolen ETL-järjestelmää	Virheiden käsittely — Jos lukutoiminnon aikana ilmenee virhe, yritä nähdä uudelleen virheet, jotka eivät liity infrastruktuuriin. Jos epäonnistuu toistuvasti, ohjaustaulukoita/virhetaulukoita käyttävä vakiokäsittely olisi toteutettava ETL-toiminnon kontekstissa seuraaviin toimiin: Kirjaa virhe lokiin Kokeile Lue-toimintoa uudelleen Lopeta, jos epäonnistui Lähetä ilmoitus Palautus — Käynnistä ETL-prosessi uudelleen toipumaan epäonnistuneesta lukutoiminnosta. Jos operaatio onnistuu, mutta on epäonnistuneita tietueita, työn välitön uudelleenkäynnistys tai myöhempi suoritus ratkaisee ongelman. Tässä tapauksessa viiveellinen uudelleenkäynnistys voi olla parempi ratkaisu, koska se sallii aikaa lajitella ja korjata virheitä aiheuttavia tietoja.
Salesforceen kirjoittaminen	Virheiden käsittely — Kirjoitustoiminnon aikana esiintyvät virheet voivat johtua sovelluksessa olevista tekijöistä. API-kutsut palauttavat tulosjoukon, joka koostuu alla mainituista tiedoista. Näitä tietoja tulisi käyttää kirjoitustoiminnon uudelleenyrittämiseen (tarvittaessa). Tietueiden tunnistetiedot Onnistui/epätosi-ilmoitus Virheiden joukko kullekin tietueelle Palautus — Käynnistä ETL-prosessi uudelleen toipumaan epäonnistuneesta lukutoiminnosta. Jos operaatio onnistuu, mutta on epäonnistuneita tietueita, työn välitön uudelleenkäynnistys tai myöhempi suoritus ratkaisee ongelman. Tässä tapauksessa viiveellinen uudelleenkäynnistys voi olla parempi ratkaisu, koska se sallii aikaa lajitella ja korjata virheitä aiheuttavia tietoja.
Ulkoinen pääjärjestelmä	Virheet tulisi käsitellä pääjärjestelmän suositeltujen käytäntöjen mukaisesti.

Turvallisuudessa huomioitavia asioita

Kaikkien etäjärjestelmään soitettujen puheluiden täytyy säilyttää pyynnön luottamuksellisuus, eheys ja saatavuus. Eri tietoturvaan liittyvät asiat riippuvat valitsemastasi ratkaisusta.

Todennetun API-käyttöoikeuden myöntäminen Salesforce API:lle vaatii Lightning Platform -lisenssin, jolla on vähintään ”vain API” -käyttöoikeudet.
Suosittelemme, että käytät salasanasi suojaamiseksi vakiomuotoista salausta.
Käytä HTTPS-protokollaa, kun teet kutsuja Salesforce API -rajapintoihin. Voit myös välittää liikennettä Salesforce API -rajapintoihin tarvittaessa paikallisen suojausratkaisun kautta.

Lisätietoja on kohdassa Turvallisuudessa huomioitavia asioita.

Sivupalkit

Ei mitään.

Aikaisuus

Aikakatkaisulla ei ole merkittävää merkitystä tässä kuviossa. Käyttöliittymien suunnittelu edellyttää kuitenkin huolellisuutta, jotta kaikki eräprosessit suoritetaan määritetyssä eräikkunassa.

Kuten kaikkien eräpohjaisten toimintojen kohdalla, suosittelemme vahvasti, että varmistat lähdesysteemien ja kohdesysteemien eristämisen erien käsittelyaikojen aikana. Erien lataaminen toimistoaikojen aikana saattaa aiheuttaa ristiriitoja, mikä johtaa joko käyttäjän päivityksen epäonnistumiseen tai merkittävästi erän latauksen (tai osittaisen erän latauksen) epäonnistumiseen.

Jos organisaatiolla on globaaleja toimintoja, kaikkien eräprosessien suorittaminen samanaikaisesti ei välttämättä ole mahdollista, koska järjestelmä saattaa olla jatkuvasti käytössä. Tietojen segmentointitekniikoita, jotka käyttävät tietuetyyppejä ja muita suodatusehtoja, voidaan käyttää välttymään datan ristiriidoilta näissä tapauksissa.

Valtion hallinta

Voit ottaa tilan hallinnan käyttöön käyttämällä korvaavia avaimia kahden järjestelmän välillä. Jos tarvitset transaktioiden hallintaa kaikissa Salesforce-entiteeteissä, suosittelemme käyttämään Apexin avulla etäkutsuja.

Vakiomuotoinen optimaalinen tietueen lukitus tapahtuu alustalla, ja kaikki API:lla tehdyt päivitykset vaativat, että tietueen muokkaava käyttäjä päivittää tietueen ja käynnistää tapahtumansa. Optimaalinen lukitus viittaa Salesforce API:n asiayhteydessä prosessiin, jossa:

Salesforce ei ylläpidä tietyn käyttäjän muokkaaman tietueen tilaa.
Kun se lukee, se tallentaa datan keruun ajan.
Jos käyttäjä päivittää tietueen ja tallentaa sen, Salesforce tarkastaa, onko toinen käyttäjä päivittänyt sen aikana tietueen.
Jos tietue on päivitetty, järjestelmä ilmoittaa käyttäjälle, että päivitys on tehty, ja käyttäjän tulisi hakea tietueen uusin versio ennen päivitysten tekemistä.

Middleware-ominaisuudet

Tämän kuvion toteuttamiseen käytetyt tehokkaimmat ulkoiset teknologiat ovat perinteisiä ETL-työkaluja. On tärkeää, että valitut middleware-työkalut tukevat Salesforce Bulk API -rajapintaa.

On hyödyllistä, mutta ei tärkeää, että middleware-työkalut tukevat getUpdated()-funktiota. Tämä funktio tarjoaa lähinnä Salesforce-sovellusalustan muutostietojen tavallista datan taltiointi.

Seuraava taulukko korostaa tämän kuvion sisältävän middleware-järjestelmän halutut ominaisuudet.

Ominaisuus	Pakollinen	Haluttu	Ei pakollinen
Tapahtumien käsittely		X
Protokollan muuntaminen		X
Käännös ja transformaatio	X
Jonot ja puskurointi	X
Synkronoidut kuljetusprotokollat	X
Ei-synkronoidut kuljetusprotokollat			X
Välitysreititys		X
Prosessien koreografia ja palvelun orkestrointi	X
Transaktiivisuus (salaus, allekirjoitus, luotettava toimitus, transaktioiden hallinta)		X
Reititys		X
Nouda, muunna ja lataa	X
Pitkä kysely	X (pakollinen Salesforcen muutostietojen datan taltiointi)

Esimerkki

Apupalveluyritys käyttää pääjärjestelmään perustuvaa eräprosessia, joka kohdistaa potentiaaliset asiakkaat yksittäisille myyntiedustajille ja tiimeille. Nämä tiedot täytyy tuoda Salesforceen öisin.

Asiakas on päättänyt ottaa muutostietojen datan taltiointi käyttöön lähdetaulukoissa käyttämällä kaupallisesti saatavilla olevaa ETL-työkalua. Ratkaisu toimii seuraavalla tavalla:

cron-muotoinen ajoitus suorittaa erätyön, joka kohdistaa potentiaalisia asiakkaita käyttäjille ja tiimeille.
Kun erätyö on suoritettu ja päivitetty, ETL-työkalu tunnistaa nämä muutokset käyttämällä muutostietojen datan taltiointi. ETL-työkalu kerää muutokset tietokannasta.
ETL-liitin käyttää Salesforce REST API -rajapintaa lataakseen muutokset Salesforceen.

Konteksti

Käytät Salesforcea seurataksesi liidejä, hallitaksesi myyntiputkeasi, luodaksesi mahdollisuuksia ja kerätäksesi tilaustietoja, jotka muuntavat liidejä asiakkaiksi. Salesforce-järjestelmä luo tilaukset sisäisesti ja siirtää tiedot sitten ulkoiseen laskutusjärjestelmään provisiointia ja aktivointia varten. Laskutustilauksia hallitaan ulkoisella järjestelmällä (etäjärjestelmällä). Tämän etäjärjestelmän täytyy päivittää tilauksen tila Salesforcessa, kun laskutusjärjestelmän tilan tilaus- tai laskutusentiteetti muuttuu.

Ongelma

Miten etäjärjestelmä muodostaa yhteyden ja todentaa itsensä Salesforcen kanssa ilmoittaakseen Salesforcelle ulkoisista tapahtumista, luodakseen tietueita ja päivittääkseen olemassa olevia tietueita?

Voimat

Tähän kuvioon perustuvia ratkaisuja käytettäessä on huomioitava useita eri tekijöitä:

Onko Salesforcelle lähetetyn etäpuhelun tarkoitus ilmoittaa Salesforcelle tapahtumasta, joka tapahtui ulkoisesti tapahtumiin perustuvan arkkitehtuurin avulla? Tai onko tarkoitus suorittaa CRUD-operaatioita tietyille tietueille? Jos käytät tapahtumiin perustuvaa arkkitehtuuria, tapahtuman tuottaja (etäprosessi) irrotetaan Salesforce-tapahtumien kuluttajasta.
Vaatiiko Salesforceen soittaminen, että etäprosessi odottaa vastausta ennen käsittelyn jatkamista? Salesforceen lähetetyt etäpuhelut ovat aina synkronoituja pyyntöjä/vastauksia, vaikka etäprosessi voi hylätä vastauksen, jos sitä ei tarvita ei-synkronoidun puhelun simuloimiseen.
Toimiiko jokainen transaktio yhden Salesforce-objektin tai useiden asiaan liittyvien objektien kanssa?
Mikä on viestin muoto (esimerkiksi SOAP tai REST tai molemmat HTTP:n kautta)?
Onko viesti suhteellisen pieni vai suuri?
Jos etäjärjestelmä on SOAP-yhteensopiva, voiko etäjärjestelmä osallistua sopimuksen ensisijaiseen lähestymistapaan, jossa Salesforce määrittää sopimuksen? Tämä on pakollinen, kun SOAP API -rajapintaa käytetään, jolle on toimitettu esimääritetty WSDL.
Vaaditaanko transaktioiden käsittelyä?
Kuinka suvaitsevainen olet mukautuksille Salesforcessa?

Ratkaisu

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

Ratkaisu	Sovita	Kommentit
Composite API -rajapintaa	Paras	Salesforce tarjoaa yhdistetyn API:n, joka on käytännössä REST API ja tukee yhdistelmäpyyntöjä. Etäjärjestelmät voivat käyttää tätä: Lähetä enintään 25 pyyntöä yhdellä puhelulla. Salesforce-organisaation datan kyselemiseen, luomiseen ja muokkaamiseen JSON-pyyntöjen avulla. Synkronoitu API — Kun API-kutsu on tehty, etäsovellus odottaa vastausta palvelusta. Transaktion/vähimmäissumman toimintatapa — Composite API ei salli oletusarvoisesti osittaista onnistumista, jos jotkin tietueet on merkitty virheiksi. Voit muuttaa tätä merkitsemällä ”kaikki tai ei mitään” -merkinnän arvoksi false, mikä mahdollistaa osittaisen onnistumisen. Virheiden käsittely: Virheiden asianmukaisen käsittelyn tulisi tutkia vastauksen tekstiosaa, eikä vain HTTP-tilakoodeja. Yhdistelmäpäätepiste vastaa 200 HTTP-tilakoodilla, vaikka se vastauksen tekstiosassa osoittaisi, että jokin alakyselyistä epäonnistui ja transaktion täytyi peruuttaa.
REST API	Paras	Helppokäyttötila — Salesforce tarjoaa REST API -rajapinnan, jota etäjärjestelmät voivat käyttää seuraaviin toimiin: Julkaise tapahtumia ilmoittaaksesi Salesforce-organisaatiollesi Kysele organisaatiosi tietoja Luo, päivitä ja poista tietoja Hanki organisaatiotasi koskevaa metadataa Synkronoitu API — Kun API-kutsu on tehty, etäsovellus odottaa vastausta palvelusta. REST API noudattaa Salesforcessa sisäänkirjautuneen käyttäjän profiilin perusteella määritettyä objektitason ja kenttätason suojausta. REST paljastaa resurssit (entiteetit/objektit) URI-osoitteina ja käyttää HTTP-verbejä määrittääkseen näille resursseille CRUD-operaatioita. Toisin kuin SOAP, REST API ei vaadi esimääritettyä sopimusta, käyttää XML- ja JSON-tiedostoja vastauksille ja käyttää löysää kirjoitusta. REST API on kevyt ja tarjoaa yksinkertaisen tavan vuorovaikuttaa Salesforcen kanssa. Sen etuihin sisältyy helppo integrointi ja kehittäminen, ja se soveltuu erinomaisesti mobiilisovellusten ja verkkosovellusten kanssa. Transaktion/vähimmäissumman toimintatapa — Jokaista tietuetta käsitellään oletusarvoisesti erillisenä transaktiona ja sitoutetaan erikseen. Yhden tietueen muutoksen epäonnistuminen ei palauta muita tietueen muutoksia. Tämä toimintatapa voidaan muuttaa ”kaikki tai ei mitään” -toiminnoksi. Käytä REST API -yhdistelmäresursseja tehdäksesi sarjan päivityksiä yhteen API-kutsuun. Bulk Data — Mikä tahansa yli 2 000 tietuetta sisältävä datatoiminto on hyvä ehdokas Bulk API 2.0:lle, jotta se voi valmistella, suorittaa ja hallita onnistuneesti ei-synkronoitua työnkulkua, joka käyttää Bulk-kehystä.
Bulk API 2.0	Paras joukkotoiminnoille	Bulk API 2.0 on Salesforcen moderni ja virtaviivaistettu API, joka käsittelee suuria datatoimintoja. REST-pohjainen Bulk API 2.0 tarjoaa ohjelmallisen vaihtoehdon, jolla voit lisätä, lisätä, kysellä tai poistaa suuria datajoukkoja asynkronisesti Salesforce-organisaatiossasi. Se on suunniteltu tehokkuutta varten, kun sinun täytyy ladata suuria määriä dataa Salesforceen tai suorittaa joukkokyselyitä organisaatiosi datalle. Toisin kuin Bulk API 1.0, Bulk API 2.0 käsittelee erät aina rinnakkain eikä tue sarjatilaa. Tämä tarkoittaa, että: Tietueita käsitellään samanaikaisesti useissa ketjuissa Erien välistä käsittelyn järjestystä ei ole taattu Parempi suorituskyky, mutta myös lukkojen ristiriitojen mahdollisuus Jokainen Bulk API 2.0 -versio käsitellään omana transaktionaan. Tämä tarkoittaa, että: Onnistuneet erät sitoutuvat itsenäisesti Epäonnistuneet erät eivät vaikuta onnistuneisiin Kaikissa töissä ei ole oletusarvoisesti ”kaikki tai ei mitään” -toimintoa. Vaikka SOAP API -rajapintaa voidaan käyttää myös suurten tietueiden käsittelyyn, se ei ole enää optimaalinen, kun datajoukot sisältävät satoja tuhansia tai miljoonia tietueita. Tämä johtuu sen suhteellisen korkeista kustannuksista ja heikommasta suorituskyvystä. Tapahtumiin perustuva arkkitehtuuri — Sovellusalustan tapahtumat määritetään samalla tavalla kuin Salesforce-objektit. Tapahtuman julkaiseminen Bulk API 2.0:n kautta on sama asia kuin Salesforce-tietueen luominen. Vain luonti- ja lisää-toimintoja tuetaan. Erässä olevat tapahtumat julkaistaan Salesforce-tapahtumaväylään asynkronisesti, kun erätyö käsitellään.
Pub/Sub API	Paras	Pub/Sub API on suositeltu tapa, jolla ulkoiset julkaisijat voivat julkaista tapahtumia tapahtumaväylässä. Pub/Sub API on gRPC-pohjainen API, joka sallii ulkoisten järjestelmien julkaista sovellusalustan tapahtumia. Pub/Sub API: Tukee sovellusalustan tapahtumien julkaisemista ja tilaamista ulkoisista sovelluksista Käytettävissä oikealla todennuksella (OAuth, JWT tai istuntovaltuudet) Kun sovellusalustan tapahtuma on määritetty Salesforcessa, se on käytettävissä sekä sisäisille että ulkoisille kuluttajille.
Sovellusalustan tapahtumat	Paras	Sovellusalustan tapahtumat määritetään samalla tavalla kuin Salesforce-objektit. Sovellusalustan tapahtumat voidaan julkaista käyttämällä erilaisia mekanismeja, kuten REST API-, Bulk API- ja SOAP API -rajapintoja. Tapahtuman julkaiseminen REST API:n kautta on sama asia kuin Salesforce-tietueen luominen. Päätepisteen muoto: POST /services/data/vXX.X/sobjects/EventName__e/ Sisältötyyppi: application/json Todennus: Haltijatunnus (OAuth) Bulk API tukee vain luonti- ja lisää-toimintoja. Erässä olevat tapahtumat julkaistaan Salesforce-tapahtumaväylään asynkronisesti, kun erätyö käsitellään. Koska sovellusalustan tapahtumat ovat SObjecte-objekteja, SOAP API -vakiotoimintoja tuetaan.
SOAP API	Sovita	Helppokäyttötila — Salesforce tarjoaa SOAP API -rajapinnan, jota etäjärjestelmät voivat käyttää seuraaviin toimiin: Julkaise tapahtumia ilmoittaaksesi Salesforce-organisaatiollesi Kysele organisaatiosi tietoja Luo, päivitä ja poista tietoja Hanki organisaatiotasi koskevaa metadataa Suorita apukohteita suorittaaksesi hallintatehtäviä Synkronoitu API — Kun API-kutsu on tehty, etäsovellus odottaa vastausta palvelusta. Ei-synkronoituja puheluita Salesforceen ei tueta. Luotu WSDL — Salesforce tarjoaa kaksi WSDL:ää etäjärjestelmille: Enterprise WSDL – Tarjoaa vahvasti kirjoitetun WSDL:n, joka koskee vain Salesforce-organisaatiota. Kumppanin WSDL - Sisältää löysästi kirjoitetun WSDL:n, joka ei koske Salesforce-organisaatiota. Suojaus — SOAP API -rajapintaa käyttävällä asiakassovelluksella täytyy olla käypä sisäänkirjautuminen ja istunto, jotta se voi suorittaa API-kutsuja. API noudattaa Salesforcessa sisäänkirjautuneen käyttäjän profiilin perusteella määritettyä objektitason ja kenttätason suojausta. Transaktion/Sopimuksen toimintatapa — Oletusarvoisesti jokainen API-kutsu mahdollistaa osittaisen onnistumisen, jos jotkin tietueet on merkitty virheiksi. Tämä voidaan muuttaa "kaikki tai ei mitään" -toiminnoksi, jossa kaikki tulokset peruutetaan virheiden ilmetessä. Transaktion laajentaminen useisiin API-kutsuihin ei ole mahdollista. Tämän rajoituksen ylittämiseksi yksi API-kutsu voi vaikuttaa useisiin objekteihin.
Apex	Aloptimaali	Apex voidaan näyttää ulkoisissa sovelluksissa verkkopalvelumetodeina. Tämä menetelmä on vaihtoehto SOAP API:lle, ja sitä käytetään tavallisesti vain, kun seuraavat lisävaatimukset täyttyvät. Täysi transaktioiden tuki vaaditaan (esimerkiksi tilin, yhteyshenkilön ja mahdollisuuden luominen yhdellä transaktiolla). Mukautettua logiikkaa täytyy soveltaa Salesforce-puolella ennen sitouttamista. Apex käytön etu on painotettava Salesforcessa ylläpidettävään lisakoodiin nähden. Ei sovelleta sovellusalustan tapahtumiin, koska transaktioiden ennen lisäämistä kuluttajalle -logiikkaa ei sovelleta tapahtumiin perustuva arkkitehtuuri. Jos haluat ilmoittaa Salesforce-organisaatiolle tapahtuneesta tapahtumasta, käytä SOAP API-, REST API- tai Bulk API 2.0 -rajapintaa.
Apex REST -palvelut	Aloptimaali	Apex voidaan näyttää REST-resursseina, jotka on kartoitettu tiettyihin URI-osoitteisiin, joilla on määritetty HTTP-verbi (esimerkiksi POST tai GET). Voit käyttää REST API -yhdistelmäresursseja suorittaaksesi useita päivityksiä yhteen transaktioon. Toisin kuin SOAP:llä, asiakassovelluksen ei tarvitse kuluttaa palvelumääritelmää/sopimusta (WSDL) ja luoda asiakassovelluksen pistemääriä. Ulkoinen järjestelmä vaatii vain HTTP-pyynnön muodostamisen ja palautettujen tulosten käsittelyn (XML tai JSON). Ei sovelleta sovellusalustan tapahtumiin, koska transaktioiden ennen lisäämistä kuluttajalle -logiikkaa ei sovelleta tapahtumiin perustuva arkkitehtuuri. Jos haluat ilmoittaa Salesforce-organisaatiolle tapahtuneesta tapahtumasta, käytä SOAP API-, REST API- tai Bulk API 2.0 -rajapintaa.

Kuvaus

Seuraavat kaaviot näyttävät tapahtumien järjestyksen, kun toteutat tämän kuvion joko käyttämällä REST API:a ulkoisten tapahtumien ilmoituksille tai SOAP API:a kyselläksesi Salesforce-objektia. Tapahtumien järjestys on sama, kun käytät REST API -rajapintaa.

Salesforcen järjestelmän etäkysely SOAP API:n kautta

Salesforcen järjestelmän etäilmoitus tapahtumilla REST API:n kautta

Tulokset

Tapahtumiin perustuvassa arkkitehtuurissa etäjärjestelmä kutsuu Salesforcea käyttämällä SOAP API-, REST API- tai Bulk API 2.0 -rajapintaa julkaistakseen tapahtuman Salesforce-tapahtumaväylään. Tapahtuman julkaiseminen ilmoittaa kaikille tilaajille. Tapahtumien tilaajat voivat käyttää Apex Salesforce Platformissa, kuten Kulut tai Lightning. Tapahtumien tilaajat voivat olla myös Salesforce Platformin ulkopuolisia, kuten CometD-tilaajia.

Kun työstät suoraan Salesforce-objekteja, tähän kuvioon liittyvät ratkaisut sallivat:

Ulkoinen järjestelmä kutsuu Salesforce API -rajapintoja kyselläkseen tietokantaa ja suorittaakseen yksittäisten objektien toimintoja (luo, päivitä, poista jne.).
Ulkoinen järjestelmä, joka kutsuu Salesforce REST API -yhdistelmäresursseja suorittaakseen useita objektien toimintoja.
Etäjärjestelmä, joka kutsuu mukautettuja Salesforce API -rajapintoja (palveluita), jotka voivat tukea usean objektin transaktioiden operaatioita ja mukautettua esimies-/viestikäsittelylogiikkaa.

Soitusmekanismit

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

Kutsumismekanismi	Kuvaus
SOAP API	Ulkoinen järjestelmä käyttää Salesforce Enterprise- tai Partner WSDL -tiedostoa luodakseen asiakaspisteitä, joita käytetään soittamaan vakiomuotoista SOAP API -rajapintaa.
REST API	Etäjärjestelmän täytyy todentaa itsensä ennen kuin se voi käyttää mitään Apex REST -palvelua. Ulkoinen järjestelmä voi käyttää OAuth 2.0 -todennusta tai käyttäjänimi- ja salasanatodennusta. Molemmissa tapauksissa asiakassovelluksen täytyy määrittää valtuutuksen HTTP-otsake asiaankuuluvalla arvolla (OAuth-käyttöoikeusvaltuus tai istuntotunnus voidaan hankkia SOAP API -sisäänkirjautumiskutsun kautta). Sen jälkeen etäjärjestelmä luo REST-kutsut (HTTP-pyynnöt) asiaankuuluvilla verbeillä ja käsittelee palautetut tulokset (JSON- ja XML-tiedostomuotoja tuetaan).
Apex	Etäjärjestelmä kuluttaa mukautetun Apex WSDL-tiedoston luodakseen asiakaspisteitä, joita käytetään kutsumaan mukautettua Apex.
Apex REST -palvelu	REST API:n mukaan resurssin URI ja asiaankuuluvat verbit määritetään @RestResource-, @HttpGet- ja @HttpPost-annotaatioilla.
Bulk API 2.0	Bulk API 2.0 on REST-pohjainen API, joten samat kutsumekanismit kuin REST API ovat käytössä.
REST API kutsuaksesi kulkua	Käytä REST API -rajapintaa kutsumaan mukautettujen kutsuttavien toimintojen päätepistettä kutsumaan automaattisesti käynnistyvää kulkua.

Virheiden käsittely ja palautus

Virheiden käsittely- ja palautustrategia täytyy huomioida osana kokonaisratkaisua.

Virheiden käsittely — Kaikki etäkutsut, vakiomuotoiset tai mukautetut API-rajapinnat, vaativat, että etäjärjestelmä käsittelee kaikki myöhemmät virheet, kuten aikakatkaisut ja uudelleenyritysten hallinta. Middleware-sovellusta voidaan käyttää tarjoamaan logiikkaa virheiden käsittelyyn ja palauttamiseen.
Palautus — Mukautettu uudelleenyritysmekanismi täytyy luoda, jos sen edellyttävät palvelun laadun vaatimukset. Tässä tapauksessa on tärkeää varmistaa, että suunnittelun ominaisuudet ovat tehokkaita. Sovellusalustan tapahtuma sallii tilaajien käyttää toistotunnusta noutaakseen viestejä tietyn ajanjakson kuluessa viestien julkaisemisesta.

Idempotent-suunnittelussa huomioitavia asioita

Idempotent-ominaisuudet varmistavat, että toistuvat kutsut ovat turvallisia eikä niillä ole negatiivisia vaikutuksia. Jos idempotenssia ei oteta käyttöön, saman viestin toistuvat kutsut voivat johtaa eri tuloksiin, mikä saattaa aiheuttaa datan eheyteen liittyviä ongelmia, esimerkiksi identtisten tietueiden luominen, transaktioiden identtisten tietueiden käsittely jne.

Etäjärjestelmän täytyy hallita useita (kaksoiskutsuja) puheluita virheiden tai aikakatkaisujen varalta välttyäkseen päällekkäisiltä lisäyksiltä ja tarpeettomilta päivityksiltä (varsinkin jos myöhemmät käynnistimet ja työnkulkusäännöt käynnistyvät). Vaikka jotkin näistä tilanteista voidaan hallita Salesforcessa (erityisesti mukautettujen SOAP- ja REST-palveluiden tapauksessa), suosittelemme, että etäjärjestelmä (tai välitysohjelmisto) hallitsee virheiden käsittelyä ja idempotent-suunnittelua.

Turvallisuudessa huomioitavia asioita

Eri tietoturvaan liittyvät asiat riippuvat valitusta ratkaisukuvioista. Kaikissa tapauksissa alusta käyttää sisäänkirjautuneen käyttäjän käyttöoikeuksia (esimerkiksi profiiliasetuksia, jakosääntöjä, käyttöoikeusjoukkoja jne.). Lisäksi profiilien IP-rajoituksia voidaan käyttää rajoittaakseen API:n käyttöoikeuksia tietylle IP-osoitealueelle.

Ratkaisu	Tietoturvassa huomioitavia asioita
SOAP API	alesforce tukee Secure Sockets Layer v3 (SSL)- ja Transport Layer Security (TLS) -protokollia. Salausten avaimen pituuden on oltava vähintään 128 bittiä. Ulkoisen järjestelmän täytyy kirjautua sisään käypiin tunnuksiin saadakseen istuntotunnuksen. Jos etäjärjestelmällä on jo käypä istuntotunnus, se voi kutsua API:a ilman suoraa sisäänkirjautumista. Tätä käytetään tässä asiakirjassa aiemmin kuvattuihin callback-kuvioihin, joissa Salesforcen edellinen lähtevä viesti sisälsi istuntotunnuksen ja tietueen tunnuksen myöhempää käyttöä varten. Suosittelemme, että SOAP API -välimuistia kutsuvat ja istuntotunnuksen uudelleen käyttävät asiakkaat maksimoivat suorituskyvyn sen sijaan, että saavat uuden istuntotunnuksen jokaiselle kutsulle.
REST API	Suosittelemme, että etäjärjestelmä luo Trust valtuutusta varten. REST-kutsuja voidaan sitten soittaa tietyille resursseille HTTP-verbeillä. Voit myös tehdä REST-kutsuja, joilla on käypä istuntotunnus, joka on saatu muilla tavoin (esimerkiksi soitettu kutsumalla SOAP API:a tai annettu lähtevän viestin kautta). Suosittelemme, että asiakkaat, jotka kutsuvat REST API -välimuistia ja käyttävät istuntotunnusta uudelleen suorituskyvyn maksimoimiseksi, eivät saa uutta istuntotunnusta jokaiselle kutsulle.
Apex	Suosittelemme, että etäjärjestelmä luo Trust valtuutusta varten.
Apex REST -palvelu	Suosittelemme, että etäjärjestelmä luo Trust valtuutusta varten.
Bulk API 2.0	Suosittelemme, että etäjärjestelmä luo Trust valtuutusta varten.

Lisätietoja on kohdassa Turvallisuudessa huomioitavia asioita.

Sivupalkit

Ei mitään.

Aikaisuus

SOAP API ja Apex Web Service API ovat synkronoituja. Seuraavat aikakatkaisut ovat käytössä:

Istunnon aikakatkaisu — Istunto aikakatkaistaan, jos Salesforce-organisaation istunnon aikakatkaisun asetuksen perusteella ei ole toimintoja.
Kyselyn aikakatkaisu — Jokaisella SOQL-kyselyllä on yksittäinen aikakatkaisurajoitus, joka on 120 sekuntia.

Datan määrät

Datan määrässä huomioitavat asiat riippuvat valitsemastasi ratkaisusta ja viestintätyypistä.

Ratkaisu	Viestintätyyppi	Rajoitukset
SOAP API tai REST API	Synkronoitu	SOAP Login — SOAP-sisäänkirjautumispyynnön enimmäiskoko on 10 kt. Voit tehdä enintään 3 600 kutsua login()-funktioon per käyttäjä per tunti. Jos ylität tämän rajoituksen, API palauttaa virheen. Luo, Päivitä, Poista — Etäjärjestelmä voi luoda, päivittää tai poistaa enintään 200 tietuetta kerralla. Voit soittaa useita puheluita käsitelläksesi yli 200 tietuetta yhteensä, mutta jokainen pyyntö on rajoitettu 200 tietueeseen. BLOB-data — Voit käyttää SObject Basic Information-, SObject Rows- tai SObject Collections REST -resursseja lisätäksesi tai päivittääksesi BLOB-dataa Salesforcen vakio-objekteihin. SObject Basic Information- tai SObject Rows -resurssien latausten enimmäiskoko on 2 Gt ContentVersion-objekteille ja 500 Mt kaikille muille hyväksytyille vakio-objekteille. Kun käytät SObject-kokoelmat-resursseja, yhden pyynnön kaikkien tiedostojen enimmäiskoko on 500 Mt. Kyselyn tulosten koko — Kyselyn tulosobjektissa (erän koko) palautettujen, query()- tai queryMore()-kutsussa palautettujen rivien määrä on oletusarvoisesti 500. Palautettujen rivien enimmäismäärä on 2 000. Voit määrittää erän koon erikseen, mutta et voi taata, että pyydetty erän koko vastaa erän todellista kokoa. Tämä tehdään suorituskyvyn maksimoimiseksi. Jos palautettavien rivien määrä ylittää erän koon, käytä API-kutsua queryMore() iteroidaksesi useiden erien läpi. Muita sääntöjä saatetaan soveltaa, joten katso lisätietoja. Tapahtumaviesti — Tapahtumaviestin enimmäiskoko on 1 Mt. Tapahtuman julkaiseminen Salesforce API -rajapintojen avulla lasketaan API-vakiorajoituksiisi.
Bulk API 2.0	Ei-synkronoitu	Bulk API 2.0 on optimoitu suurten datajoukkojen tuomiseen ja viemiseen ei-synkronoidusti. Kaikki yli 2 000 tietuetta sisältävät datatoiminnot ovat hyviä ehdokkaita Bulk API 2.0 -rajapintaa käyttävän ei-synkronoidun työnkulun valmistelemiseen, suorittamiseen ja hallintaan. Työt, joissa on alle 2 000 tietuetta, tulisi sisältää ”bulkattuja” synkronoituja kutsuja REST:ssä (esimerkiksi Composite) tai SOAP:ssä. Bulk API 2.0 on synkronoitu, kun eräpyyntö ja siihen liittyvät tiedot lähetetään. Tietojen todellinen käsittely tapahtuu ei-synkronoidusti. Lisätietoja API- ja eräkäsittelyn rajoituksista on kohdassa Rajoitukset.

Päätepisteen kapasiteetin ja standardien tuki

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

Ratkaisu	Päätepisteissä huomioitavia asioita
SOAP API	Ulkoisen järjestelmän täytyy voida ottaa käyttöön asiakassovellus, joka voi kutsua Salesforce SOAP API -rajapintaa Salesforcen esimäärittämän viestiformaatin perusteella. Etäjärjestelmän (asiakassovelluksen) täytyy osallistua sopimuksen ensisijaiseen toteutukseen, jossa sopimus on Salesforcen toimittama (esimerkiksi Enterprise tai Partner WSDL).
REST API	Ulkoisen järjestelmän täytyy voida ottaa käyttöön REST-asiakassovellus, joka kutsuu Salesforcea — määritettyjä REST-palveluita — ja käsittelee XML- tai JSON-tulokset.
Apex	Ulkoisen järjestelmän täytyy voida ottaa käyttöön asiakassovellus, joka voi kutsua SOAP-viestejä esimääritetyssä muodossa Salesforcen määrittämällä tavalla. Ulkoisen järjestelmän täytyy osallistua koodiin perustuvaan toteutukseen, jossa sopimus toimitetaan Salesforcesta Apex käyttöönoton jälkeen. Jokaisella Apex on oma WSDL-tiedostonsa.
Apex REST -palvelu	Samat päätepisteessä huomioitavat asiat kuin REST API:ssa.

Valtion hallinta

Kun integroit järjestelmiä, avaimet ovat tärkeitä jatkuvalle tilojen seurannalle, esimerkiksi jos tietue luodaan etäjärjestelmässä, tukeakseen tietueen jatkuvia päivityksiä. Vaihtoehtoja on kaksi:

Salesforce tallentaa etäjärjestelmän etätietueen ensisijaisen tai yksilöllisen korvaava avaimen.
Ulkoinen järjestelmä tallentaa Salesforcen yksilöllisen tietuetunnuksen tai jonkin muun yksilöllisen korvaava avaimen. Tässä synkronoidussa kuviossa integrointiavaimien käsittelyssä on erityisiä huomioitavia asioita.

Päätieto	järjestelmä Kuvaus
Salesforce	Tässä skenaariossa etäjärjestelmä tallentaa joko Salesforce RecordId -arvon tai jonkin muun yksilöllisen korvaava avaimen tietueesta.
Ulkoinen järjestelmä	Tässä skenaariossa Salesforce tallentaa viitteen yksilölliseen tunnisteeseen etäjärjestelmässä. Koska prosessi on synkronoitu, avain voidaan tarjota osana samaa transaktiota käyttämällä ulkoisia tunnuskenttiä.

Monimutkaiset integraatioskenaariot

Tässä kuvion jokaisella ratkaisulla on eri huomioitavia asioita, kun käsittelet monimutkaisia integraatioskenaarioita, kuten transformaatiota ja prosessien orkestrointia.

Ratkaisu	Huomioitavia asioita
SOAP API tai REST API	SOAP API ja REST API tarjoavat yksinkertaisia transaktioita objekteille. Monimutkaisia integraatioskenaarioita, kuten aggregointia, orkestrointia ja transformaatiota, ei voi suorittaa Salesforcessa. Näiden skenaarioiden täytyy käsitellä etäjärjestelmä tai välisovellus, ja preferoitu menetelmä on välisovellus.
Apex tai Apex REST -palvelu	Mukautetut verkkopalvelut voivat tarjota objektien ristikkäistoimintoja, mukautettua logiikkaa ja monimutkaisempien transaktioiden tukea. Tätä ratkaisua tulisi käyttää huolellisesti, ja sinun tulisi aina huomioida, soveltuuko välitysohjelmisto mihin tahansa transformaatio-, orkestrointi- ja virheiden käsittelylogiikkaan.

Päälliköiden rajoitukset

Salesforce-sovellusalustan monivaltuuden vuoksi API-rajapintojen käyttö on rajoitettu.

Ratkaisu	Rajoitukset
SOAP API, REST API ja mukautetut Apex API -rajapinnat	API-pyyntöjen rajoitukset — Salesforce rajoittaa API-kutsujen määrää per 24 tunnin ajanjakso. Rajoitus perustuu Salesforce Edition -version tyyppiin ja lisenssien määrään. Esimerkiksi Unlimited Edition tarjoaa 5 000 API-pyyntöä per Salesforce Platform -lisenssi 24 tunnin välein. Lisätietoja on kohdassa Salesforce Developer Limits and Allocations Quick Reference. API-kyselyn kursorin rajoitukset — Käyttäjällä voi olla enintään 10 kyselyn kursoria avoinna kerralla. Muussa tapauksessa vanhin kymmenestä kursorista vapautuu. Jos etäsovellus yrittää avata julkaistun kyselyn kursorin, ilmenee virhe. Jos esimerkiksi jaat integraatiokäyttäjien tunnuksia, kyselyiden kursorien enimmäismäärä täytyy huomioida. Jos se on mahdollista, välitysohjelmiston tulisi suorittaa täysi kysely ennen toisen kyselyn suorittamista (sarjan muodossa) tai jokaisen sovelluksen tulisi käyttää määritettyä integraatiokäyttäjää. Vaihtoehtoisesti välitysohjelmiston täytyy ehkä suorittaa pyyntöjä useille käyttäjille ”pyöristettynä”. Puheluiden rajoitukset — Lisätietoja luonti-, päivitys- ja kyselyn rajoituksista on kohdassa Datamäärien sivupalkki.
Bulk API 2.0	Lisätietoja on kohdassa Datan määrät -sivupalkki.
Sovellusalustan tapahtumat	Tapahtumien ilmoitusten rajoitukset — Vakiomuotoisille määräalustan tapahtumille voidaan julkaista enintään 100 000 tapahtumaa tunnissa. Enintään 250 000 tapahtumaa voidaan julkaista per tunti raskaan käyttöön perustuville sovellusalustan tapahtumille. Voit valvoa raskaan tapahtuman käyttöä käyttämällä REST API -rajoitukset -resurssia. Tapahtumaviestien kokorajoitukset — Tapahtumaviestien enimmäiskoko on 1 Mt. Tapahtuman julkaiseminen Salesforce API -rajapintojen avulla lasketaan API-vakiorajoituksiisi.

Luotettava viestintä

Luotettava viestintä yrittää ratkaista ongelman, joka koskee viestin toimittamisen takaamista etäjärjestelmään, jossa yksittäiset komponentit eivät välttämättä ole luotettavia. Salesforce SOAP API ja REST API ovat synkronoituja, eivätkä ne tarjoa selkeästi tukea luotettaville viestintäprotokollille (esimerkiksi WS-ReliableMessaging).

Suosittelemme, että etäjärjestelmä ottaa käyttöön luotettavan viestintäjärjestelmän varmistaakseen, että virhe- ja aikakatkaisukenaarioita hallitaan onnistuneesti. Sovellusalustan tapahtumien julkaiseminen ulkoisista järjestelmistä perustuu Salesforce API -rajapintoihin, joten samat huomioitavat asiat pätevät SOAP API:lle ja REST API:lle.

Middleware-ominaisuudet

Tämä taulukko korostaa tämän kuvion sisältävän middleware-järjestelmän halutut ominaisuudet:

Ominaisuus	Pakollinen	Haluttu	Ei pakollinen
Tapahtumien käsittely		X
Protokollan muuntaminen		X
Käännös ja transformaatio		X
Jonot ja puskurointi	X
Synkronoidut kuljetusprotokollat	X
Ei-synkronoidut kuljetusprotokollat			X
Välitysreititys		X
Prosessien koreografia ja palvelun orkestrointi		X
Transaktiivisuus (salaus, allekirjoitus, luotettava toimitus, transaktioiden hallinta)	X
Reititys			X
Nouda, muunna ja lataa		X (joukko/erät)

Esimerkki

Tulostustarvikkeiden ja palveluiden yritys käyttää Salesforcea etusijana tulostimen tarvikkeiden ja tilausten luomiseen ja hallintaan. Tulosttimia edustavat Salesforce-resurssitietueet päivitetään säännöllisesti tulostuksen käytön tilastoilla (musteen tila, paperin taso) paikallisesta Tulostimen hallintajärjestelmästä (PMS), joka valvoo asiakassivustojen tulostimia säännöllisesti. Kun määritetty kynnysarvo saavutetaan (esimerkiksi matala muste-tila tai alhainen/tyhjä paperitaso on alle 30 %), tapahtumaan kiinnostuneille useille sovelluksille/prosesseille (muuttujalle) lähetetään ilmoitus, sähköpostitse tai Chatter lähetetään ja tilaustietue luodaan. PMS tallentaa Salesforce-tunnuksen (Salesforce on omaisuustietueen päätietue).

Seuraavat rajoitukset ovat voimassa:

PMS voi osallistua sopimuksen ensimmäiseen integraatioon, jossa Salesforce tarjoaa sopimuksen ja PMS toimii Salesforce-palvelun asiakassovelluksena (kuluttajana) (määritettynä Enterprise- tai Partner WSDL:n kautta).
Salesforcessa ei tulisi olla mukautettua kehitystä.

Tämä esimerkki voidaan toteuttaa parhaiten käyttämällä Salesforce SOAP API:a tai REST API:a tapahtumien julkaisemiseen sekä deklaratiivista automatisointia (kulku) Salesforcessa. Ensisijainen syy sovellusalustan tapahtumien käyttämiseen on muuttuja ja tilaajien ei-lopullinen määrä. Jos kuitenkin haluat tehdä yksinkertaisia päivityksiä tietueluetteloon, kuten tilauksiin, käytä SOAP- tai REST API -rajapintaa tietueiden päivittämiseen.

Salesforcessa:

Määritä sovellusalustan tapahtuma Salesforcessa sisältämään PMS:stä saadut ilmoitustiedot.
Luo tulostintapahtuman ilmoituksen käynnistämä kulku. Prosessi päivittää tulostinresurssin ja luo tilauksen (käyttämällä automaattisesti käynnistyvää kulkua).
Lataa Enterprise- tai Partner WSDL ja tarjoa se etäjärjestelmään.

Etäjärjestelmässä:

Luo asiakaspiste Enterprise- tai Partner WSDL:stä.
Todenna Salesforce (OAuth-verkkopalvelimen tai haltijatunnuksen kulun kautta) integraatiokäyttäjän tunnuksilla.
Kun tulostimen tilatapahtuma tapahtuu, PMS kutsuu API:a luomaan tulostimen tilan sovellusalustan tapahtuman (ja tulostimen käytön tilastoja). Salesforce-tapahtumaväli ilmoittaa kulun tilaajalle ja kaikille muille tilaajille.

Kun käytät sovellusalustan tapahtumia, tapahtumaväylä sallii sinun toistaa tapahtumia 72 tunnin ajan raskaan sovellusalustan tapahtumille. Näiden tapahtumien julkaiseminen middleware-ratkaisulla voi auttaa virheiden käsittelyyn julkaisun puolella. Voit kuitenkin ottaa virheiden käsittelyn käyttöön tilaajan puolelta, jos tarvitset parempaa luotettavuutta.

Tämä esimerkki osoittaa seuraavaa:

Salesforcen synkronoidun API-asiakassovelluksen (kuluttajan) toteutus.
Callback-kutsu Salesforcelle julkaistaksesi sovellusalustan tapahtuman (joka on linjassa aiemmin katettujen pyyntöjen/vastausten sovellusalustan tapahtumien kuvioiden kanssa).

Konteksti

Käytät Salesforcea asiakastapausten hallintaan. Asiakaspalveluedustaja keskustelee tapausta käsittelevän asiakkaan kanssa. Asiakas tekee maksun ja asiakaspalveluedustajan täytyy nähdä reaaliaikainen päivitys Salesforce-sovelluksessa maksun käsittelysovelluksesta, joka osoittaa, että asiakas on onnistuneesti maksanut tilauksen erääntyneen summan.

Ongelma

Miten käyttäjälle ilmoitetaan Salesforcessa tapahtuneesta tapahtumasta Salesforce-käyttöliittymästä ilman, että hänen täytyisi päivittää näytönsä tai menettää töitään?

Voimat

Tähän kuvioon perustuvia ratkaisuja käytettäessä on huomioitava useita eri tekijöitä:

Täytyykö toimintoja käyttävä data tallentaa Salesforceen?
Voidaanko tämän datan tarkastelemiseen luoda mukautettu käyttöliittymäkerros?
Voiko käyttäjällä olla käyttöoikeus mukautetun käyttöliittymän kutsumiseen?

Ratkaisu

Tämän integraation ongelman suositeltu ratkaisu on käyttää sovellusalustan tapahtumia, jotka varmistavat lähes reaaliaikaisen tapahtuman Salesforcessa. Sovellusalustan tapahtumat -ominaisuus tarjoaa rakenteellisen ja joustavan hyötykuorman riippumatta mistä tahansa Salesforce-objektista. Se varmistaa myös kestävät aiheet, joiden toistoaika on 72 tuntia. Tämä varmistaa, että tapahtumat ovat käytettävissä, vaikka offline-asiakas olisi myöhemmin käytettävissä. Tämä ratkaisu koostuu seuraavista komponenteista :

Apex tai kulut, joilla on logiikka sovellusalustan tapahtuman julkaisemiseksi aiheessa
Aihe, jonka avulla voit julkaista tapahtuman Apex tai kulusta
JavaScript-pohjainen toteutus Bayeux-protokollasta (tällä hetkellä CometD), jota käyttöliittymä voi käyttää
Lightning
Staattisena resurssina sisällytetty JavaScript-kirjasto

Kuvaus

Seuraava kaavio osoittaa, miten Streaming API -rajapintaa voidaan käyttää ilmoitusten suorittamiseen Salesforce-käyttöliittymään. Nämä ilmoitukset käynnistyvät tietueiden muutoksilla Salesforcessa.

Datan muutoksen käynnistämä käyttöliittymäpäivitys Salesforcessa

Tulokset

Hyödyt

Tähän kuvioon liittyvän ratkaisun soveltaminen tarjoaa seuraavat hyödyt:

Estää mukautettujen kyselymekanismien kirjoittamisen
Estää käyttäjien käynnistämän palautteen silmukan käytön

Ei-tuetut vaatimukset

Ratkaisulla on seuraavat rajoitukset:

Ilmoitusten toimittamista ei taata.
Ilmoitusten järjestystä ei taata.
Ilmoituksia ei luoda Bulk API:n tekemistä tietuemuutoksista.

Turvallisuudessa huomioitavia asioita

Salesforcen organisaatiotason vakio-suojausta noudatetaan. Suosittelemme, että käytät HTTPS-protokollaa muodostaaksesi yhteyden Streaming API -rajapintaan. Lisätietoja on kohdassa Turvallisuudessa huomioitavia asioita.

Sivupalkit

Optimaalinen ratkaisu sisältää mukautetun käyttöliittymän luomisen Salesforcessa. Sinun on välttämättä otettava huomioon sopiva käyttöliittymäsäiliö, jota voidaan käyttää mukautetun käyttöliittymän renderöimiseen. Tuetut selaimet on lueteltu Streaming API Developer Guide -oppaassa.

Esimerkki

Telekommunikaatioyritys käyttää Salesforcea asiakastapausten hallintaan. Asiakaspalvelupäälliköt haluavat saada ilmoituksen, kun heidän asiakaspalveluedustajansa on sulkenut tapauksen onnistuneesti.

Kun asiakas toteuttaa tämän kuvion määrittämän ratkaisun, hänen tulisi:

Luo Apex PushTopic, joka lähettää sovellusalustan tapahtuman, kun tapauksen tila on Suljettu ja Ratkaisu Onnistui.
Luo mukautettu käyttöliittymä asiakaspalvelupäälliköille. Tämä käyttöliittymä tilaa tapahtumaväylän kuluttaakseen sovellusalustan tapahtumia.
Toteuta mukautetussa käyttöliittymässä logiikkaa, joka näyttää esimiehen asiakaspalveluedustajien luomat hälytykset.

Konteksti

Käytät Salesforcea seurataksesi liidejä, hallitaksesi myyntiputkeasi, luodaksesi mahdollisuuksia ja kerätäksesi tilaustietoja, jotka muuntavat liidejä asiakkaiksi. Salesforce ei kuitenkaan ole järjestelmä, joka sisältää tai käsittelee tilauksia. Tilauksia hallitaan ulkoisella (etäjärjestelmällä). Myyntiedustajat haluavat kuitenkin tarkastella ja päivittää reaaliaikaisia tilaustietoja Salesforcessa ilman, että heidän täytyisi oppia tai käyttää ulkoista järjestelmää.

Ongelma

Miten tarkastelet, haet ja muokkaat Salesforcen ulkopuolella säilytettyä dataa Salesforcessa siirtämättä dataa ulkoisesta järjestelmästä Salesforceen?

Voimat

Tähän kuvioon perustuvia ratkaisuja käytettäessä on huomioitava useita eri tekijöitä:

Haluatko laatia deklaratiivisen / Osoita ja napsauta -lähtevän integraation tai käyttöliittymän mashup-version Salesforcessa?
Onko sinulla paljon tietoja, joita et halua kopioida Salesforce-organisaatioosi?
Tarvitseeko sinun käyttää pieniä määriä etäjärjestelmätietoja kerralla?
Tarvitsetko reaaliaikaisen pääsyn uusimpiin tietoihin?
Tallennatko datasi pilvipalvelimeen tai back-office-järjestelmään, mutta haluatko näyttää tai käsitellä kyseisiä tietoja Salesforce-organisaatiossasi?
Onko sinulla huolenaiheita tietyntyyppisten tietojen säilyttämisestä Salesforcessa?

Ratkaisu

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

Ratkaisu	Sovita	Kommentit
Salesforce Connect	Paras	Käytä Salesforce Connectia käyttääksesi dataa ulkoisista lähteistä sekä Salesforce-dataasi. Nouda dataa järjestelmistä, kuten SAP, Microsoft, Oracle ja muut pilvipohjaiset järjestelmät, kuten Snowflake, reaaliajassa kopioimatta dataa Salesforcessa. Salesforce Connect kartoittaa ulkoisten järjestelmien datataulukoita organisaatiosi ulkoisiin objekteihin. Ulkoiset objektit muistuttavat mukautettuja objekteja, mutta ne kartoitetaan Salesforce-organisaatiosi ulkopuoliseen dataan. Salesforce Connect käyttää ulkoisen datan live-yhteyttä pitääkseen ulkoiset objektit aina ajan tasalla. Ulkoisen objektin käyttäminen noutaa tiedot ulkoisesta järjestelmästä reaaliajassa. Salesforce Connect sallii sinun: Kysele tietoja ulkoisessa järjestelmässä. Luo, päivitä ja poista tietoja ulkoisessa järjestelmässä. Käytä ulkoisia objekteja luettelonäkymien, lisätietosivujen, tietueiden syötteiden, mukautettujen välilehtien ja sivuasetteluiden kautta. Määritä ulkoisten objektien ja vakio-objektien tai mukautettujen objektien välisiä suhteita integroidaksesi dataa eri lähteistä. Suorita raportteja (rajoitetusti) ulkoisesta datasta. Tarkastele dataa Salesforce-mobiilisovelluksessa. Jos haluat käyttää ulkoisessa järjestelmässä säilytettyä dataa Salesforce Connectin avulla, voit käyttää jotakin seuraavista sovittimista: OData 2.0 -sovitin tai Odata 4.0 -sovitin — muodostaa yhteyden mihin tahansa OData 2.0- tai 4.0 -tuottajaan liittyviin tietoihin. Organisaatioiden välinen sovitin — muodostaa yhteyden toiseen Salesforce-organisaatioon tallennettuun dataan. Organisaatioiden välinen sovitin käyttää Lightning Platform REST API -standardia. Toisin kuin OData, organisaatioiden välinen sovitin muodostaa yhteyden suoraan toiseen organisaatioon ilman välityspalvelua. Apex luotu mukautettu sovitin — jos Odata ja organisaatioiden väliset sovittimet eivät sovellu tarpeisiisi, kehitä oma sovittimesi Apex Connector Frameworkin avulla.
Pyyntö ja vastaus	Aloptimaali	Käytä Salesforcen verkkopalvelun API-rajapintoja tehdäksesi ad hoc -datapyyntöjä käyttääksesi ja päivittääksesi ulkoisen järjestelmän dataa. Tämä ratkaisu sisältää seuraavat lähestymistavat: Käytä Salesforce SOAP API -rajapintaa. Mukautettu sivu tai painike käynnistää Apex REST/SOAP -kutsun synkronoidusti. Salesforcessa voit kuluttaa WSDL:n ja luoda tuloksena olevan välityspalvelimen Apex. Tämä luokka tarjoaa tarvittavan logiikan etäpalvelun kutsumiseen. Käyttäjän käynnistämä toiminto sivulla kutsuu sitten Apex toimintoa, joka suorittaa tämän välityspalvelimen Apex suorittaakseen etäkutsun. Sivut vaativat Salesforce-sovelluksen mukauttamista. Käytä Salesforce REST API -rajapintaa. Mukautettu sivu tai painike käynnistää Apex HTTP -kutsun (REST-palvelu) synkronoidusti. Salesforcessa voit kutsua HTTP-palveluita käyttämällä tavallisia GET-, POST-, PUT- ja DELETE-metodeja. Lisätietoja tästä ratkaisusta on kohdassa Prosessin etäkutsut — Pyyntö ja vastaus.

Ratkaisu

Sovita

Kommentit

Salesforce Connect

Paras

Käytä Salesforce Connectia käyttääksesi dataa ulkoisista lähteistä sekä Salesforce-dataasi. Nouda dataa järjestelmistä, kuten SAP, Microsoft, Oracle ja muut pilvipohjaiset järjestelmät, kuten Snowflake, reaaliajassa kopioimatta dataa Salesforcessa.

Salesforce Connect kartoittaa ulkoisten järjestelmien datataulukoita organisaatiosi ulkoisiin objekteihin. Ulkoiset objektit muistuttavat mukautettuja objekteja, mutta ne kartoitetaan Salesforce-organisaatiosi ulkopuoliseen dataan. Salesforce Connect käyttää ulkoisen datan live-yhteyttä pitääkseen ulkoiset objektit aina ajan tasalla. Ulkoisen objektin käyttäminen noutaa tiedot ulkoisesta järjestelmästä reaaliajassa.

Salesforce Connect sallii sinun:

Kysele tietoja ulkoisessa järjestelmässä.
Luo, päivitä ja poista tietoja ulkoisessa järjestelmässä.
Käytä ulkoisia objekteja luettelonäkymien, lisätietosivujen, tietueiden syötteiden, mukautettujen välilehtien ja sivuasetteluiden kautta.
Määritä ulkoisten objektien ja vakio-objektien tai mukautettujen objektien välisiä suhteita integroidaksesi dataa eri lähteistä.
Suorita raportteja (rajoitetusti) ulkoisesta datasta.
Tarkastele dataa Salesforce-mobiilisovelluksessa.

Jos haluat käyttää ulkoisessa järjestelmässä säilytettyä dataa Salesforce Connectin avulla, voit käyttää jotakin seuraavista sovittimista:

OData 2.0 -sovitin tai Odata 4.0 -sovitin — muodostaa yhteyden mihin tahansa OData 2.0- tai 4.0 -tuottajaan liittyviin tietoihin.
Organisaatioiden välinen sovitin — muodostaa yhteyden toiseen Salesforce-organisaatioon tallennettuun dataan. Organisaatioiden välinen sovitin käyttää Lightning Platform REST API -standardia. Toisin kuin OData, organisaatioiden välinen sovitin muodostaa yhteyden suoraan toiseen organisaatioon ilman välityspalvelua.
Apex luotu mukautettu sovitin — jos Odata ja organisaatioiden väliset sovittimet eivät sovellu tarpeisiisi, kehitä oma sovittimesi Apex Connector Frameworkin avulla.

Pyyntö ja vastaus

Aloptimaali

Käytä Salesforcen verkkopalvelun API-rajapintoja tehdäksesi ad hoc -datapyyntöjä käyttääksesi ja päivittääksesi ulkoisen järjestelmän dataa. Tämä ratkaisu sisältää seuraavat lähestymistavat:

Käytä Salesforce SOAP API -rajapintaa. Mukautettu sivu tai painike käynnistää Apex REST/SOAP -kutsun synkronoidusti. Salesforcessa voit kuluttaa WSDL:n ja luoda tuloksena olevan välityspalvelimen Apex. Tämä luokka tarjoaa tarvittavan logiikan etäpalvelun kutsumiseen. Käyttäjän käynnistämä toiminto sivulla kutsuu sitten Apex toimintoa, joka suorittaa tämän välityspalvelimen Apex suorittaakseen etäkutsun. Sivut vaativat Salesforce-sovelluksen mukauttamista.

Käytä Salesforce REST API -rajapintaa. Mukautettu sivu tai painike käynnistää Apex HTTP -kutsun (REST-palvelu) synkronoidusti. Salesforcessa voit kutsua HTTP-palveluita käyttämällä tavallisia GET-, POST-, PUT- ja DELETE-metodeja.

Lisätietoja tästä ratkaisusta on kohdassa Prosessin etäkutsut — Pyyntö ja vastaus.

Kuvaus

Seuraava kaavio osoittaa, miten voit käyttää Salesforce Connect noutaaksesi dataa ulkoisesta järjestelmästä Odata.

Tässä skenaariossa:

selain suorittaa AJAX-kutsun, joka puolestaan suorittaa toiminnon vastaavalle ulkoisen objektin sovittimelle.
Sovitin kääntää toiminnon Odata ja lähettää HTTP GET -pyynnön etäjärjestelmään Integraatio- ja Palvelut-kerrosten kautta.
Ulkoinen järjestelmä palauttaa Salesforcelle JSON-vastauksen Integration and Services -kerrosten kautta.
Vastaus käännetään ODatasta ulkoiseen objektiin ja esitetään takaisin selaimeen.

Tulokset

Tähän kuvioon liittyvien ratkaisujen käyttö mahdollistaa käyttöliittymän käynnistämät kutsut, joissa transaktion tulokset voidaan näyttää loppukäyttäjälle.

Soitusmekanismit

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

Kutsumismekanismi	Kuvaus
Ulkoiset objektit	Salesforce Connect kartoittaa Salesforcen ulkoiset objektit ulkoisten järjestelmien datataulukoihin. Sen sijaan, että kopioisit dataa organisaatioosi, Salesforce Connect käyttää dataa tarvittaessa ja reaaliajassa. Vaikka dataa säilytetään organisaatiosi ulkopuolella, Salesforce Connect tarjoaa saumattoman integraation Lightning Platformiin. Ulkoiset objektit ovat käytettävissä Salesforce-työkaluissa, kuten globaali haku, hakusuhteet, tietueiden syötteet ja Salesforce-mobiilisovellus. Ulkoiset objektit ovat käytettävissä myös Apexissa, SOSL:ssä, SOQL-kyselyissä, Salesforce API -rajapinnoissa ja käyttöönotossa Metadata API:n, muutosjoukkojen ja pakettien kautta.
Valaistuskomponentit	Käytetään, kun etäprosessi käynnistetään osana käyttöliittymää käsittelevää loppuun -prosessia, ja tulokset täytyy näyttää tai päivittää Salesforce-tietueessa. Esimerkiksi prosessi, joka lähettää luottokorttimaksut ulkoiseen maksusiltapalveluun ja palauttaa välittömästi käyttäjälle näytettävät maksutulokset. Käyttöliittymän tapahtumista käynnistetty integrointi vaatii tavallisesti mukautettujen Lightning luomisen.

Kutsumismekanismi

Kuvaus

Ulkoiset objektit

Salesforce Connect kartoittaa Salesforcen ulkoiset objektit ulkoisten järjestelmien datataulukoihin. Sen sijaan, että kopioisit dataa organisaatioosi, Salesforce Connect käyttää dataa tarvittaessa ja reaaliajassa. Vaikka dataa säilytetään organisaatiosi ulkopuolella, Salesforce Connect tarjoaa saumattoman integraation Lightning Platformiin. Ulkoiset objektit ovat käytettävissä Salesforce-työkaluissa, kuten globaali haku, hakusuhteet, tietueiden syötteet ja Salesforce-mobiilisovellus. Ulkoiset objektit ovat käytettävissä myös Apexissa, SOSL:ssä, SOQL-kyselyissä, Salesforce API -rajapinnoissa ja käyttöönotossa Metadata API:n, muutosjoukkojen ja pakettien kautta.

Valaistuskomponentit

Käytetään, kun etäprosessi käynnistetään osana käyttöliittymää käsittelevää loppuun -prosessia, ja tulokset täytyy näyttää tai päivittää Salesforce-tietueessa. Esimerkiksi prosessi, joka lähettää luottokorttimaksut ulkoiseen maksusiltapalveluun ja palauttaa välittömästi käyttäjälle näytettävät maksutulokset. Käyttöliittymän tapahtumista käynnistetty integrointi vaatii tavallisesti mukautettujen Lightning luomisen.

Virheiden käsittely

On tärkeää sisällyttää virheiden käsittely osana kokonaisratkaisua. Kun tapahtuu virhe (poikkeukset tai virhekoodit palautetaan soittajalle), soittaja hallitsee virheiden käsittelyä. Salesforce Connect Validator on ilmainen työkalu, jolla voit suorittaa yleisimpiä kyselyitä ja ilmoitusvirhetyyppejä ja virheiden syitä.

Hyödyt

Salesforce Connect -ratkaisun käytössä on joitakin etuja:

Tämä ratkaisu ei kuluta datan tallennustilaa Salesforcessa.
Käyttäjien ei tarvitse huolehtia datan säännöllisestä synkronoinnista ulkoisen järjestelmän ja Salesforcen välillä.
Deklaratiivinen määritys, joka voidaan saavuttaa nopeasti Odata tai organisaatioiden välisen sovittimen avulla tai käyttämällä vähäistä koodia mukautetun Apex kanssa.
Käyttäjät voivat käyttää ulkoista dataa samalla tavalla kuin mukautettuja objekteja ulkoisten objektien muodossa.
Oikeus tehdä yhdistetty haku yhdistetyssä ulkoisessa järjestelmässä käyttämällä globaalia hakua.
Kyky suorittaa raportteja, jotka käyttävät ulkoista dataa pilvi- ja paikallisista lähteistä. Katso raportoinnissa huomioitavia asioita alta.

Salesforce Connectissa huomioitavia asioita

Salesforce Connect -ratkaisu ottaa huomioon seuraavat asiat:

Ulkoiset objektit käyttäytyvät mukautettujen objektien tavoin, mutta jotkin ominaisuudet eivät ole käytettävissä ulkoisille objekteille. Lisätietoja on kohdassa Salesforce Connectin yhteensopivuudessa huomioitavia asioita Salesforce Connectille.
Ulkoiset objektit voivat vaikuttaa raportin suorituskykyyn. Lisätietoja on kohdassa Raportissa huomioitavia asioita Salesforce Connectille.
Lisätietoja Salesforce Connect -sovittimien käyttämisestä on kohdassa Salesforce Connectin huomioitavat asiat — Kaikki sovittimet.
Jos aiot käyttää organisaatioiden välistä sovitinta, katso lisätietoja kohdasta Salesforce Connect — Organisaatioiden välinen sovitin.
Jos aiot käyttää OData-sovitinta, katso lisätietoja kohdasta Salesforce Connect -sovittimissa huomioitavia asioita — OData 2.0- ja 4.0 -sovittimet.
Jos aiot käyttää mukautettua Apex-sovitinta, katso lisätietoja kohdasta Salesforce Connect — Mukautettu sovitin.

Turvallisuudessa huomioitavia asioita

Tämän kuvion ratkaisujen tulisi noudattaa organisaatiotason Salesforce-vakiomuotoista suojausta. Suosittelemme, että käytät HTTPS-protokollaa yhteyden muodostamiseksi mihin tahansa etäjärjestelmään. Lisätietoja on kohdassa Turvallisuudessa huomioitavia asioita.

Jos käytät Odata, varmista, että ymmärrät ulkoisten Odata Cross-Site Request Forgery (CSRF) -ominaisuuden erityiset toimintatavat, rajoitukset ja suositukset. Lisätietoja on kohdassa CSRF:ssä huomioitavia asioita Salesforce Connectille — OData 2.0- ja 4.0 -sovittimet.

Sivupalkit

Ei mitään.

Aikaisuus

Aikavyöhyke on merkittävä tässä kuviossa. Pidä seuraavat asiat mielessäsi:

Pyyntö kutsutaan tavallisesti käyttöliittymästä, joten prosessin ei tarvitse pitää käyttäjää odottamassa.
Ulkoisten tietojen noutaminen saattaa kestää kauan, riippuen ulkoisen järjestelmän saatavuudesta ja yhteydestä. Salesforcessa on määritettävä 120 sekunnin aikakatkaisun enimmäisarvo, joka odottaa vastausta ulkoisesta järjestelmästä.
Etäprosessin suorittamisen tulisi tapahtua ajoissa ja Salesforcen aikakatkaisun rajoituksen ja käyttäjien odotusten mukaisesti.

Datan määrät

Päätepisteen kapasiteetin ja standardien tuki

Päätepisteen ominaisuuksien ja standardien tuki riippuu valitsemastasi ratkaisusta.

Ratkaisu	Päätepisteissä huomioitavia asioita
Salesforce Connect	OData API -rajapinnat — Käytä Open Data -protokollaa käyttääksesi Salesforcen ulkopuolella säilytettyä dataa. Ulkoisen datan täytyy olla näkyvissä Odata kautta. Muut API-rajapinnat — Käytä Apex Connector Frameworkia kehittääksesi oman mukautetun sovittimen, kun muut saatavilla olevat sovittimet eivät sovellu tarpeisiisi. Mukautettu sovitin voi noutaa dataa mistä tahansa lähteestä. Esimerkiksi jotkin tiedot voidaan noutaa Internetistä callout-kutsuilla, kun taas muita tietoja voidaan manipuloida tai jopa luoda ohjelmallisesti. Yhdistä Salesforceen — Käyttää Lightning Platform REST API -rajapintaa käyttääkseen muissa Salesforce-organisaatioissa säilytettyä dataa. Yhdistä Middlewareen Yhdistä Middlewareen — Salesforce Connect -kumppanien ekosysteemi on tehnyt tiivistä yhteistyötä Salesforcen kanssa varmistaakseen, että heidän middleware-yhdyskäytävänsä paljastavat Odata palvelustaan, jotta Salesforce voi muodostaa yhteyden niihin kirjoittamatta ylimääräistä koodia.
Pyyntö ja vastaus	Apex SOAP -kutsut - Päätepisteen täytyy voida vastaanottaa verkkopalvelupuhelu HTTP:n kautta. Apex HTTP -kutsut - Päätepisteen täytyy voida vastaanottaa HTTP-kutsuja. Voit käyttää Apex HTTP -kutsuja kutsuaksesi RESTful-palveluita käyttämällä vakiomuotoisia GET-, POST-, PUT- ja DELETE-metodeja

Ratkaisu

Päätepisteissä huomioitavia asioita

Salesforce Connect

OData API -rajapinnat — Käytä Open Data -protokollaa käyttääksesi Salesforcen ulkopuolella säilytettyä dataa. Ulkoisen datan täytyy olla näkyvissä Odata kautta.

Muut API-rajapinnat — Käytä Apex Connector Frameworkia kehittääksesi oman mukautetun sovittimen, kun muut saatavilla olevat sovittimet eivät sovellu tarpeisiisi. Mukautettu sovitin voi noutaa dataa mistä tahansa lähteestä. Esimerkiksi jotkin tiedot voidaan noutaa Internetistä callout-kutsuilla, kun taas muita tietoja voidaan manipuloida tai jopa luoda ohjelmallisesti.

Yhdistä Salesforceen — Käyttää Lightning Platform REST API -rajapintaa käyttääkseen muissa Salesforce-organisaatioissa säilytettyä dataa.

Yhdistä Middlewareen

Yhdistä Middlewareen — Salesforce Connect -kumppanien ekosysteemi on tehnyt tiivistä yhteistyötä Salesforcen kanssa varmistaakseen, että heidän middleware-yhdyskäytävänsä paljastavat Odata palvelustaan, jotta Salesforce voi muodostaa yhteyden niihin kirjoittamatta ylimääräistä koodia.

Pyyntö ja vastaus

Apex SOAP -kutsut -

Päätepisteen täytyy voida vastaanottaa verkkopalvelupuhelu HTTP:n kautta.

Apex HTTP -kutsut -

Päätepisteen täytyy voida vastaanottaa HTTP-kutsuja.

Voit käyttää Apex HTTP -kutsuja kutsuaksesi RESTful-palveluita käyttämällä vakiomuotoisia GET-, POST-, PUT- ja DELETE-metodeja

Valtion hallinta

Kun integroit järjestelmiä, avaimet ovat tärkeitä tilojen jatkuvalle seurannalle. Jos esimerkiksi tietue luodaan etäjärjestelmässä, tietue tarvitsee tavallisesti jonkinlaisen tunnistusavaimen jatkuvien päivitysten tukemiseksi. Avainten säilyttämiseen on kaksi vaihtoehtoa.

Salesforce tallentaa etätietueen ensisijaisen tai yksilöllisen korvaava avaimen.
Ulkoinen järjestelmä tallentaa Salesforcen yksilöllisen tietuetunnuksen tai jonkin muun yksilöllisen korvaava avaimen. Tässä synkronoidussa kuviossa integrointiavaimien käsittelyssä on erityisiä huomioitavia asioita.

Pääjärjestelmä	Kuvaus
Salesforce	Ulkoinen järjestelmä tallentaa joko Salesforce-tietueen tunnuksen tai jonkin muun yksilöllisen korvaava avaimen tietueesta.
Ulkoinen järjestelmä	Etäprosessin kutsu palauttaa yksilöllisen avaimen sovelluksesta, ja Salesforce tallentaa avaimen arvon yksilölliseen tietuekenttään.

Monimutkaiset integraatiot

Joissakin tapauksissa tämän kuviossa määritetty ratkaisu voi vaatia monimutkaisen integraatioskenaariota. Nämä skenaariot ratkaistaan usein käyttämällä middleware-ohjelmistoa.

Puheluiden ja niiden tulosten aggregointi useisiin järjestelmiin
Saapuvien ja lähtevien viestien transformaatio
Transaktioiden eheyden ylläpito useisiin järjestelmiin lähetetyissä puheluissa
Muut prosessien orkestrointitoiminnot Salesforcen ja ulkoisen järjestelmän välillä

Rajoitukset

Eri sovittimille on eri rajoitukset. Lisätietoja on kohdassa Salesforce Connectin yleiset rajoitukset.

Middleware-ominaisuudet

Seuraava taulukko korostaa tämän kuvion sisältävän middleware-järjestelmän halutut ominaisuudet.

Ominaisuus	Pakollinen	Haluttu	Ei pakollinen
Tapahtumien käsittely		X
Protokollan muuntaminen	X
Käännös ja transformaatio	X
Jonot ja puskurointi	X
Synkronoidut kuljetusprotokollat	X
Ei-synkronoidut kuljetusprotokollat		X
Välitysreititys		X
Prosessien koreografia ja palvelun orkestrointi		X
Transaktiivisuus (salaus, allekirjoitus, luotettava toimitus, transaktioiden hallinta)	X
Reititys			X
Nouda, muunna ja lataa			X
Pitkä kysely			X

Ulkoisten objektien suhteet

Ulkoiset objektit tukevat vakiomuotoisia hakusuhteita, jotka käyttävät siihen liittyvien tietueiden liittämiseen 18-merkkistä Salesforce-tietueen tunnusta. Salesforce-organisaatiosi ulkopuoliset tiedot eivät kuitenkaan usein sisällä kyseisiä tietuetunnuksia. Tästä syystä ulkoisille objekteille on käytettävissä kaksi erityyppistä hakusuhdetta: ulkoiset haut ja epäsuorat haut.

Tämä taulukko kuvaa ulkoisille objekteille käytettävissä olevien suhteiden tyypit.

Suhde	Sallitut aliobjektit	Sallitut ylätason objektit	Ylätason kenttä tietueiden täsmäämiseksi
Haku	Vakiomuotoinen, Mukautettu, Ulkoinen	Vakiomuotoinen, Mukautettu	18-merkkinen Salesforce-tietueen tunnus
Ulkoinen haku	Vakiomuotoinen, Mukautettu, Ulkoinen	Ulkoinen	Ulkoinen tunnus -vakiokenttä
Epäsuora haku	Ulkoinen	Vakiomuotoinen, Mukautettu	Valitse mukautettu kenttä, joka sisältää Ulkoinen tunnus- ja Yksilöllinen-attribuutit

Koko datamäärässä huomioitavia asioita Salesforce Connectille — OData 2.0- ja 4.0 -sovittimet

Jos organisaatiosi saavuttaa nopeusrajoituksia ulkoisten objektien käyttämisessä, harkitse Suuri datamäärä -vaihtoehdon valitsemista niihin liittyvistä ulkoisista tietolähteistä. Tämä ohittaa useimmat tiedonsiirtorajoitukset, mutta sinulla on joitakin erityisiä toimintatapoja ja rajoituksia. Lisätietoja on kohdassa Suuren datamäärän käytössä huomioitavia asioita Salesforce Connectille.

Asiakkaisiin ja palvelimiin perustuva sivutus Salesforce Connectille — OData 2.0- ja 4.0 -sovittimet

Ulkoisen datan Salesforce Connect -kyselyillä on tavallisesti suuri tulosjoukko, joka on pilkottu pienemmiksi eriksi tai sivuiksi. Sinä päätät, hallitaanko sivutusta ulkoisella järjestelmällä (palvelinpohjainen) vai Salesforce Connectin OData 2.0- tai 4.0 -sovittimella (asiakaspohjainen). Ulkoisen tietolähteen Palvelimen määrittämä sivutus -kenttä määrittää, haluatko käyttää asiakassovelluksen määrittämää tai palvelimen määrittämää sivutusta. Jos otat palvelimen määrittämän sivutuksen käyttöön ulkoiselle tietolähteelle, Salesforce ei huomioi pyydettyjä sivukoita, mukaan lukien oletusarvoinen queryMore()-erän koko, joka on 500 riviä. Ulkoisen järjestelmän palauttamat sivut määrittävät erät, mutta jokaisella sivulla voi olla enintään 2 000 riviä. Salesforce Connect Odata rajoitukset ovat kuitenkin edelleen voimassa.

Esimerkki

Valmistusyritys käyttää Salesforcea asiakastapausten hallintaan. Asiakaspalveluagentit haluavat käyttää reaaliaikaisia tilaustietoja toimiston ERP-järjestelmästä saadakseen 360-näkymän asiakkaasta ilman, että heidän täytyisi oppia ja suorittaa raportteja manuaalisesti ERP:ssä.

Kun toteutat tämän kuvion määrittämän ratkaisun, sinun tulisi:

Määritä ulkoinen tietolähde Odata. Etäsovelluksesi saattaa sisältää natiivituen tuen ODatalle. Muissa sovelluksissa suuret integraatiotoimittajat, kuten Dell Boomi, Informatica, Jitterbit, MuleSoft ja Progress Software, ovat tehneet yhteistyötä Salesforce on Salesforce Connectin kanssa sovittimien laatimiseksi.
Osoita Salesforce Connect Odata joko suoraan tai middleware-ratkaisun kautta.
Synkronoi ulkoiset tietokantataulukkosi ulkoisten objektien kanssa Salesforcessa. Kun käyttäjä avaa sivun, joka sisältää tietoja näistä ulkoisista objekteista, Salesforce Connect tekee reaaliaikaisia callout-kutsuja taustasovelluksillesi.

Kehittäjien dokumentaatio

Trailhead

Kaikkien sovellusten täytyy olla luotuja ja integroituja asiaankuuluvien suojausmekanismien kanssa, jotta he voivat olla tehokkaita jäseniä yritysportfoliossa. Modernit IT-strategiat käyttävät paikallisten ja pilvipohjaisten palveluiden yhdistelmää.

Vaikka pilvipalveluiden integrointi keskittyy tavallisesti verkkopalveluihin ja niihin liittyviin valtuutuksiin, paikallisten ja pilvipalveluiden yhdistäminen aiheuttaa usein monimutkaisempaa. Tässä osiossa kuvataan tietoturvatyökaluja, -tekniikoita ja Salesforce-kohtaisia huomioitavia asioita.

Käänteinen välityspalvelin

Käänteinen välityspalvelin on palvelin, joka sijaitsee verkkopalvelimien edessä ja välittää asiakaspyyntöjä (esimerkiksi verkkoselaimella) kyseisille verkkopalvelimille. Tavallisesti käänteisiä välityspalvelimia käytetään tietoturvan, suorituskyvyn ja luotettavuuden parantamiseksi.

Se on välityspalvelimen tyyppi, joka noutaa resursseja asiakassovelluksen puolesta yhdestä tai useammasta palvelimesta. Nämä resurssit palautetaan sitten asiakassovellukseen kuin ne olisivat peräisin itse välityspalvelimelta. Toisin kuin välityspalvelin, joka on välityspalvelu, jonka asiakkaat voivat ottaa yhteyttä mihin tahansa palvelimeen, käänteinen välityspalvelu on välityspalvelu, johon kaikki asiakkaat voivat ottaa yhteyttä.

Salesforce-toteutuksissa tällainen palvelu tarjotaan tavallisesti ulkoisen yhdyskäytävän tuotteen kautta. Voit käyttää esimerkiksi avoimen lähdekoodin vaihtoehtoja, kuten Apache HTTP, lighttpd ja nginix. Kaupallisiin tuotteisiin sisältyvät IBM WebSeal ja Computer Associates SiteMinder. Nämä tuotteet voidaan määrittää helposti välityspalvelimelle ja hallitsemaan kaikkia lähteviä Salesforce-pyyntöjä sisäisen pyynnön lähettäjän puolesta.

Salaus

Jotkin yritykset vaativat, että valitut transaktiot tai datakentät salataan paikallisissa ja pilvipohjaisissa sovelluksissa. Jos organisaatiosi täytyy noudattaa ylimääräisiä vaatimuksia, voit ottaa käyttöön vaihtoehtoja, mukaan lukien:

Paikalliset kaupalliset salausyhdyskäytäväpalvelut, mukaan lukien Salesforcen omat, CipherCloud, IBM DataPower ja Computer Associates. Jokaisessa ratkaisussa salausjärjestelmää tai yhdyskäytävää kutsutaan transaktion rajassa lähettämällä ja vastaanottamalla salattu hyötykuorma tai salaamalla tai purkamalla tiettyjä datakenttiä ennen kuin HTTP(S) -pyyntö suoritetaan.
Pilvipohjaiset vaihtoehdot, kuten Salesforce Shield Platform Encryption. Shield Platform Encryption tarjoaa datallesi uuden tietoturvakerroksen säilyttäen samalla tärkeät sovellusalustan toiminnot. Valitsemasi tiedot salataan paikallisesti käyttämällä edistyneitä avainten muodostusjärjestelmiä. Voit suojata tietojasi turvallisemmin kuin koskaan ennen. Lisätietoja on Salesforcen online-ohjeessa.

Erikoistunut WS-* -protokollatuki

Suosittelemme seuraavia vaihtoehtoja, jotta voit vastata suojausprotokollien (kuten WS-*) vaatimuksiin.

Security/XML gateway — Syötä WS-Security-tunnuksia (IBM WebSeal tai Datapower, Layer7, TIBCO jne.) itse transaktiovirtaan. Tämä lähestymistapa ei vaadi muutoksia sovellustason verkkopalveluihin tai verkkopalvelun kutsut Salesforcesta. Voit myös käyttää tätä lähestymistapaa uudelleen kaikkialla Salesforce-asennuksessa. Se vaatii kuitenkin suunnittelua, kokoonpanoa, testausta ja ylläpitoa hallitakseen asiaankuuluvaa WS-Security-injektiota olemassa olevaan suojausyhdyskäytävän lähestymistapaan.
Kuljetustason salaus — Salaa viestintäkanava käyttämällä kaksisuuntaisia SSL- ja IP-rajoituksia. Tämä lähestymistapa ei toteuta WS-* -protokollaa suoraan, mutta se suojaa paikallisten sovellusten ja Salesforcen välisen viestintäkanavan välittämättä käyttäjänimeä ja salasanaa. Se ei myöskään vaadi Salesforcen luomien luokkien muutoksia. Joitakin paikallisten verkkopalveluiden muutoksia saattaa kuitenkin vaatia (joko itse sovelluksessa tai middleware-/ESB-kerroksessa).
Salesforcen mukautettu kehitys — Lisää lähtevään SOAP-pyyntöön WS-Security-otsakkeita WSDL2Apex-apukohteen kautta. Tämä luo Java-muotoisen Apex WSDL-tiedostosta, jota käytetään sisäisen palvelun kutsumiseen. Tämä lähestymistapa ei vaadi muutoksia taustalla toimiviin verkkopalveluihin tai DMZ:n lisäkomponentteihin, mutta se vaatii:
- kasvava rakentaminen ja testaaminen
- suhteellisen monimutkainen ja manuaalinen prosessi, jolla WS-Security-attribuutit koodataan manuaalisesti (mukaan lukien XML-sarjanumerointi Apex)
- korkeampi pitkäaikainen huoltotyö

Huomautus: Viimeistä vaihtoehtoa ei suositella sen monimutkaisuuden ja riskin vuoksi, että tällaiset integraatiot tarvitsevat säännöllisiä tarkastuksia Salesforcen säännöllisten päivitysten perusteella.

Muita tietoturvaan liittyviä huomautuksia

Nimetyt tunnukset: Nimetyn tunnuksen tarkoitus on suojata ja yksinkertaistaa todennettuja API-kutsuja ulkoisiin järjestelmiin, ja se määrittää callout-päätepisteen URL-osoitteen ja sen vaaditut todennusparametrit yhdessä määritelmässä. Määritä nimetty tunnus callout-päätepisteeksi virtaviivaistaaksesi Apex ja yksinkertaistaaksesi todennettujen callout-kutsujen määrittämistä. Lisätietoja on tässä.
OAUTH 2.0: OAuth 2.0 on toimialan standardin valtuutuskehys, joka sallii käyttäjien myöntää rajoitetun käyttöoikeuden suojattuihin resursseihinsa kolmannen osapuolen sovellukseen jakamatta tunnuksiaan (kuten salasanojaan). Käyttäjä hyväksyy suoran salasananvaihdon sijaan käyttöoikeusvaltuuden pyynnön, jota sovellus käyttää sitten käyttäjän tietojen käyttämiseen resurssipalvelimelta. Tämä prosessi erottaa asiakassovelluksen käyttäjän henkilöllisyydestä ja salasanasta ja parantaa tietoturvaa tarjoamalla väliaikaisen, vaikutusalueen mukaisen avaimen resurssien käyttämiseen. Lisätietoja on tässä.
Yksityinen yhteys: Kun integroit Salesforce-organisaatiosi kolmannen osapuolen pilvipalveluissa isännöityihin sovelluksiin, on tärkeää, että voit lähettää ja vastaanottaa HTTP-liikennettä/liikennettä turvallisesti. Private Connectin avulla voit parantaa Amazon Web Services (AWS) -integraatioidesi tietoturvaa määrittämällä täysin hallitun verkkoyhteyden Salesforce-organisaatiosi ja AWS Virtual Private Cloud (VPC) -palvelusi välille. Reititä sitten pilvipalvelusi liikenne yhteyden kautta julkisen internetin sijaan välttyäksesi ulkopuolisten tietoturvahyökkäyksiltä. Private Connect on saatavilla yhteistyössä AWS:n kanssa AWS PrivateLink -ominaisuuden kautta. Private Connect on kaksisuuntainen: voit käynnistää saapuvaa ja lähtevää liikennettä. Saapuvien yhteyksien avulla voit lähettää liikennettä Salesforceen käyttämällä vakiomuotoisia API-rajapintoja. Lähtevien yhteyksien avulla voit myös lähettää liikennettä Salesforcesta käyttämällä ominaisuuksia, kuten Apex, ulkoisia palveluita ja ulkoisia objekteja. Lisätietoja VPC:stä on tässä.

Salesforce-tapahtumaväylä, jossa on sovellusalustan tapahtumat, muutostietojen datan taltiointi (CDC) ja Pub/Sub API, sallii yritysten luoda tapahtumiin perustuvia tyyliarkkitehtuuria (EDA).

EDA irrottaa tapahtumaviestien kuluttajat (tilaajat) tapahtumaviestien tuottajista (julkaisijat), mikä mahdollistaa suuremman skaalan ja joustavuuden. Tässä asiakirjassa käsitellään tiettyjä kuvioita osana olemassa olevaa kuvion rakennetta, joka vertaa ja vertaa asiaan liittyviä vaihtoehtoja tai vaihtoehtoja. Kuitenkin kokonaisvaltainen ymmärrys tapahtumiin perustuvasta arkkitehtuurista ja siitä, miten kuviot vuorovaikuttavat, voi auttaa sinua valitsemaan tarpeisiisi sopivan kuvion.

Khalid Mohammed on arvostettu arkkitehtijohtaja Salesforcen Professional Services -palvelussa. Vuodesta 2015 lähtien, jolloin hän liittyi Salesforceen, hän on hyödyntänyt laaja-alaista asiantuntemustaan Enterprise-sovelluksissa ja arkkitehtuurissa, jota hän on tarkentanut lukuisilla asiakastransformaatioilla ennen Salesforcessa työskentelyään. Khalid johtaa Toimituksen arkkitehtuuri -neuvostoa ja hänet tunnustetaan myös sertifioiduksi tekniseksi arkkitehtiksi.

Gulal Kumar on Salesforcen ohjelmisto-arkkitehti, joka keskittyy dataan ja integraatioarkkitehtuuriin. Hänellä on yli 20 vuoden kokemus integroinnista ja API-rajapinnoista, modernisointiohjelmista, tietoturvasta ja AIML-aloitteista, joten hänellä on runsaasti ammattitaitoa. Gulal on sitoutunut edistämään liiketoiminnan transformaatio-aloitteita, parantamaan tietoturvaa ja kestävyyttä, edistämään arkkitehtuurin huippuosaamista ja johtamaan AIML-aloitteita eri toimialueissa.

Sushant on tekninen arkkitehti Salesforcessa, joka on erikoistunut ratkaisun arkkitehtuuriin ja Salesforce-alustojen loppuun -toimitukseen. Hänellä on syvällistä asiantuntemusta sovellusalustan hallinnasta, sovelluskehityksestä, integraatiosta ja DevOpsista. Hän on johtanut lukuisia asiakastransformaatio-ohjelmia eri toimialoilla. Sushant on sitoutunut edistämään toimitusten huippuosaamista ja skaalattavia arkkitehtonisia lopputuloksia.