Det finnes mange måter å få tilgang til, synkronisere og dele data på mellom Salesforce og eksterne systemer på. Men ikke alle verktøy er riktige for ditt bestemte prosjekt. Denne veiledningen går gjennom landskapet med dataintegreringsverktøy som er tilgjengelig fra Salesforce. Den tilbyr også anbefalinger for verktøyene (eller kombinasjoner av verktøy) som er best egnet i et bestemt bruksområde, i tillegg til veiledning om verktøy som kan unngås i bestemte scenarier.

Denne beslutningsveiledningen fokuserer på datanivåintegrasjoner som involverer Salesforce. Spesifikt dekker den følgende brukstilfeller med dataintegrering:

• Salesforce til eksterne systemer
• Eksterne systemer til Salesforce
• Salesforce-organisasjon til Salesforce-organisasjon

Dette er bare et delsett av integrasjonsutfordringene som Salesforce-arkitekter står overfor, så vi planlegger å legge til flere beslutningsveiledninger fokusert på hendelsesdrevet integrasjon, bygge effektive kunde- eller ansattrettede arbeidsflyter ved bruk av prosessintegrering og så videre. Til slutt er det viktig å merke seg at mange av verktøyene og tilnærmingene som er beskrevet her, kan brukes til å løse integrasjonsutfordringer i hele virksomheten, men slike bruksområder er utenfor omfanget av denne veiledningen.

• Unngå unødvendig dataregistrering. Med mindre dataene absolutt trenger å befinner seg i Salesforce, kan du vurdere datavirtualisering med Salesforce Connect i stedet. Flere data i organisasjonen fører til slutt til større datavolumer, noe som kan påvirke ytelsen negativt og øke teknisk gjeld. Hvis dataene allerede befinner seg i Salesforce og du trenger dem i et eksternt system, unngår du å kopiere dem til et eksternt system med mindre det er helt nødvendig. La i stedet det eksterne systemet få tilgang til dataene via Salesforce API-ene.
• Bruk MuleSoft eller andre Enterprise Service Bus (ESB) eller Extract-Transform-Load (ETL) løsninger, hvis tilgjengelig og en del av ditt eksisterende landskap. Fordi disse verktøyene er bygd for å bidra til å støtte dataoverføring og transformasjon, har de ofte kraftige funksjoner som gir deg mulighet til å gjenbruke integrasjoner på tvers av virksomheten, opprettholde sterkere styring og sentralisere administrasjonen av integrasjoner. I denne veiledningen vurderer du om den eksisterende ESB/ETL-løsningen vil være tilstrekkelig der MuleSoft Anypoint anbefales.
• Harmoniser data fra forskjellige kilder med Data 360 og Data Cloud One. Gjennom Customer 360, identitetsløsning, dataforbund og andre funksjoner konsoliderer Data 360 data fra Salesforce og andre eksterne systemer til en forent visning av kunden. Og med Data Cloud One kan brukere i andre Salesforce-organisasjoner trygt få tilgang til data som deles virtuelt fra Data 360, via dataområder.
• Flytt data mellom organisasjoner med Data 360-handlinger og -aktiveringer. Når data hentes inn fra forskjellige organisasjoner til Data 360, kan datahandlinger og aktiveringer synkronisere dataene til en annen organisasjon. Denne tilnærmingen kan være svært nyttig for integrasjoner med Marketing Cloud-organisasjoner.
• Trekk ut og flytt data med MuleSoft Anypoint. MuleSoft Anypoint kan brukes til å trekke ut data fra Data 360 med Connect API og Data Graph API og flytte dem til en annen Salesforce-organisasjon. Uten Data 360 kan MuleSoft Anypoint også brukes når data må flyttes mellom organisasjoner uten å bli replikert i Data 360.
• Vær forsiktig hvis du velger å bygge med Utgående meldinger. Salesforce vil fortsette å støtte utgående meldinger innenfor gjeldende funksjonell kapasitet, men har ikke planer om å gjøre ytterligere investeringer i denne teknologien.
• Integrasjonsbrukerlisens med API Only-profil anbefales alltid for alle integrasjoner. Salesforce anbefaler også å bruke eksterne klientprogrammer (i favør av tilkoblede apper eller SOAP-pålogging) som de riktig tillatte AuthN- og AuthZ-mønstrene for alle integrasjoner.

Før du går inn i de tilgjengelige dataintegreringsverktøyene, er det viktig å ta hensyn til noen vanlige punkter når du velger et verktøy. Som med arkitektur er det ikke noe preskriptivt svar på alle forretningsutfordringer. Hvis du har uttalt ordene "det avhenger" når du gjør integrasjonsvalg, er du på riktig sted.

Her er en generell oversikt over verktøyene som er tilgjengelig for dataintegrering, og noen viktige punkter om hvordan du kan begynne å evaluere hvert alternativ. Følgende deler inneholder detaljerte bruksområder og detaljer om funksjonaliteten til disse verktøyene.

*Tillegg kreves for brukstilfeller med datafangst av endringer med stor trafikk

**Tillegg kreves for brukstilfeller med plattformhendelser med stor trafikk

***Passer i situasjoner der det er greit at forretningslogikk kjøres i nettleseren.

Kolonneforklaring:

• Tilgjengelig: fungerer bra for de fleste brukstilfeller
• Ikke ideell: mulig, men vurder et alternativt verktøy
• Ikke tilgjengelig: Ingen planer om støtte i de neste tolv månedene

Det finnes andre verktøy som kan støtte enkelte aspekter ved en dataoverleggsintegrering, men de må ikke betraktes som en primær måte å løse integreringsproblemer på. La oss ta en rask titt på disse verktøyene nå.

Lightning-nettkomponenter brukes vanligvis til prosessintegrasjoner, men de kan utføre oppkall ved bruk av JavaScript-funksjonalitet, så data kan være involvert i disse transaksjonene.

Salesforce-flyter kan brukes til å orkestrere eksterne oppkall med eksterne tjenester eller Apex-handlinger. Salesforce-flyt alene betraktes ikke som et frittstående dataintegreringsverktøy.

Dataimportveiviser og Data Loader kan brukes til å synkronisere, importere og overføre data. Selv om Data Loader-kommandoer også kan skripteres for å automatisere import og eksport av data, er kommandolinjegrensesnittet bare for Windows, og ingen av disse verktøyene er en anbefalt grunnlag for en dataintegreringsstrategi. Bruk dem i stedet til å utfylle datastyrings- og vedlikeholdsstrategien.

Datakommandoer Salesforce CLI kan brukes til å manipulere poster i organisasjonen. Kommandoer er tilgjengelig for å hjelpe deg med å importere og eksportere data med Bulk API og SObject Tree Save API, og utføre enkle CRUD-operasjoner på individuelle poster med REST API. Salesforce CLI i seg selv anses ikke som et frittstående dataintegreringsverktøy.

OmniStudio Data Mapper kan brukes som et deklarativt ETL-verktøy for å flytte data mellom Salesforce-objekter og JSON-datastrukturer. Et REST-grensesnitt opprettes automatisk for hvert Datakartler-grensesnitt, som gir en deklarativ måte å flytte data fra eksterne systemer til Salesforce-objekter på, men Datakartter frittstående er ikke et anbefalt grunnlag for en dataintegreringsstrategi. Datatilordningshandlinger er tilgjengelig i OmniStudio-integreringsprosedyrer.

Dataloader.io er et annet datalasterverktøy for Salesforce drevet av MuleSofts Anypoint Platform som lar deg raskt og sikkert importere, eksportere og slette ubegrensede mengder data for virksomheten din. Dataloader.io er ikke et anbefalt grunnlag for en dataintegreringsstrategi.

For utgående integrasjoner fra Salesforce kan du vurdere forskjellige typer verktøy: lavkode, pro-kode eller en hybrid. Følgende deler gir veiledning for hver av disse verktøytypene og tilbyr eksempler på løsninger.

• Lavkode-verktøy for utgående integrasjoner
• Hybridverktøy for utgående integrasjoner
• Pro-Code-verktøy for utgående integrasjoner

Når salgsmuligheter er vunnet, må det opprettes en bestilling for de tilknyttede produktene i firmaets ERP-system eller bestillingsbehandlingssystem.

Endre datafangst Etter hvert som salgsmulighetsposter oppdateres, publiserer Endre datafangst endringshendelser som inneholder oppdateringene til objektene. Endringshendelsene forbrukes på kundesiden via en CometD-tilkobling (eller via en MuleSoft-kobling) og brukes til å oppdatere kundens ERP- eller bestillingsbehandlingssystem. Endringshendelser kan forbedres til alltid å inkludere eksterne post-ID-er eller andre data fra objektet (som område) som er nødvendige for integrasjonen. Endringshendelsesstrømmer for flere objekter kan kombineres i kanaler for å forenkle abonnement- og strømbehandlingen (slik at du kan abonnere på og behandle én strøm i stedet for mange).

Hvis du har en nettjeneste som støtter OpenAPI 2.0- eller 3.0-spesifikasjonen, kan du vise operasjonene og tjenestene som en ekstern tjeneste i Salesforce.**** API-operasjonene (for eksempel opprettelsesrekkefølge) kan kalles opp som en kallbar handling i en flyt som er bygd med Flow Builder, når fasen i salgsmuligheten endres til "vunnet".

Heroku Connect Heroku Connect brukes vanligvis til å holde en Heroku Postgres Database og Salesforce synkronisert. Hvis kunden bruker Heroku Postgres som sin sanne transaksjonsbutikk, kan du synkronisere postene og endringene fra Salesforce til Heroku Postgres med Heroku Connect. Derfra kan du bruke Heroku Streaming-koblinger til å publisere disse endringene til Apache Kafka og sende dem som hendelser til nedstrøms programmer, inkludert ERP- eller bestillingsbehandlingssystemet.

OmniStudio Integrasjonsprosedyre Når en bestilling sendes inn, kan Omniscript som orkestrerer prosessen, legge inn bestillingsdetaljene i en ERP- eller MuleSoft-kobling. Innlegget kan utføres enten direkte av Omniscript (klientside) eller indirekte via en integrasjonsprosedyre (serverside). Hvis ERP-systemet utløser en valideringsfeil, må OmniScript-grensesnittet varsle brukeren, og om nødvendig oversette og kontekstualisere feilen for brukeren.

Salesforce Connect/External Objects Du kan opprette en postutløst flyt i Salesforce som setter inn en post i de relaterte eksterne objektene når fasen i salgsmuligheten endres til "vunnet". Fordi dette er en blandet transaksjon, legger du til et pauseelement i null sekunder mellom Opportunity-oppdateringen og de relaterte eksterne objektinnsettingene, slik at du lukker én transaksjonskontekst før du starter en ny.

*Tillegg kreves for brukstilfeller med stor trafikk.

**Testing og distribusjon henviser til muligheten til å bygge i et lavere miljø og distribuere via Metadata API, pakker eller endringssett til produksjon.

Når salgsmuligheter er vunnet, må det opprettes en bestilling for de tilknyttede produktene i firmaets ERP- eller bestillingsbehandlingssystem.

Apex-handlinger En postutløst flyt basert på salgsmulighetsstatusen kan utløses automatisk når en salgsmulighet vunnes. Flyten utfører en kallbar handling som bruker et eksternt kall til å sende bestillingen til bestillingsbehandlingssystemet eller ERP-løsningen. Sendinger med stor trafikk og bestillinger på flere nettsteder håndteres av Apex og kømekanismer.

Utgående meldinger Etter at du har konfigurert utgående meldinger, kan du definere en arbeidsflytregel utløst av salgsmulighetsoppdateringen for å sende en SOAP-melding via HTTP(S) til en angitt endepunkt-URL-adresse som er vert for lytter. Meldingen vil inneholde feltene som ble angitt da den utgående meldingen ble opprettet. Hvis informasjonen i objektet endres etter at varselet er lagt i kø, men før det sendes, vil bare den oppdaterte informasjonen bli levert, og meldinger vil bli værende i køen til de er sendt riktig, eller til de er 24 timer gamle. Etter 24 timer utelates meldinger fra køen. Hvis ERP-systemet krever flere data, kan du overføre sessionId i utgående meldinger slik at det eksterne systemet kan sende en forespørsel om tilbakekall.

Plattformhendelser Du kan definere en plattformhendelse som inkluderer den tilpassede belastningen med dataene som kreves for å opprette postene i det eksterne systemet. Fordi plattformhendelser ikke publiseres automatisk ved postendringer, må du publisere hendelsen via Apex, Salesforce-flyt eller Prosessbygger når fasen i salgsmuligheten endres til Vunnet. En ekstern tjeneste lytter på plattformhendelseskanalen med CometD (eller en MuleSoft-kobling) og oppretter de riktige postene i det eksterne systemet.

Salesforce Connect/External Objects (med tilpassede Apex-adaptere) En løsning basert på Salesforce Connect/External Objects er ikke perfekt egnet for et bruksområde som bare krever datasynkronisering. Denne løsningen kan imidlertid brukes i tilfeller der brukere i Salesforce trenger å se og potensielt samhandle med data fra det eksterne systemet, og dataene ikke kan replikeres i Salesforce. Hvis ERP- eller bestillingsbehandlingssystemet ikke støtter OData- eller GraphQL-protokoller, kan utviklerteamet bruke Apex Connector Framework til å skrive Apex-klasser som håndterer kommunikasjon med det eksterne systemet via en støttet protokoll.

Data 360 En løsning basert på Data 360 passer perfekt for brukstilfeller der vi trenger harmoniserte data fra forskjellige kilder i ett datalager. Den kan også brukes når vi trenger å replikere data fra én Salesforce-organisasjon til flere Salesforce-organisasjoner eller til andre eksterne systemer som bruker Data 360 som dataknutepunkt. Når en salgsmulighet vunnes og oppdateres i kildeorganisasjonen, synkroniseres salgsmulighetsdata til Data 360, der de kan replikeres i andre systemer, inkludert Salesforce-organisasjoner som bruker forskjellige mekanismer som handlinger, aktiveringer og API-er. På samme måte kan en salgsmulighet refereres uten å replikere dataene i andre Salesforce-organisasjoner ved bruk av Data Cloud One. Data Cloud One støtter imidlertid ikke ikke-Salesforce-plattformer.

*Aktivering av Shield Platform Encryption endrer visse virkemåter, se Generelle punkter om Shield Platform Encryption for å få mer informasjon.

**Testing og distribusjon henviser til muligheten til å bygge i et lavere miljø og distribuere via Metadata API, pakker eller endringssett til produksjon.

Når salgsmuligheter er vunnet, må det opprettes en bestilling for de tilknyttede produktene i firmaets ERP- eller bestillingsbehandlingssystem.

Tilpasset Apex Du kan opprette en Apex-utløser og utløserbehandler(e) i salgsmuligheten som sender et kall til ERP- eller bestillingsbehandlingssystemet når fasen i salgsmuligheten endres til "vunnet". Vær oppmerksom på at hvis du gjør oppkall fra en utløser eller etter å ha utført en DML-operasjon, må du bruke en metode som er merket som fremtidig eller som kan legges i kø. Et oppkall i en utløser holder databasetilkoblingen åpen i løpet av oppkallets levetid. All Apex-kode er bundet av Apex Governor og API Limits, som revideres kontinuerlig.

Eksterne tjenester Hvis firmaets eksterne ERP- eller bestillingsbehandlingssystem er definert via en OpenAPI-spesifikasjon, kan oppkall til disse tjenestene som utføres i den fremtidige metoden eller jobben som kan legges i kø, forenkles. De registrerte eksterne tjenestene kan ringes direkte fra Apex uten å måtte skrive koder. I eksemplet kan oppkallet for å opprette bestillingen håndteres av den eksterne tjenesten.

MuleSoft Anypoint MuleSoft Anypoint tilbyr API-behandling i bedriftsnivå. MuleSoft Anypoint kan opprette API-er for å aktivere lese (og/eller skrive) tilgang til data for Salesforce og mange andre bedriftssystemer. Det finnes mange forhåndsbygde koblinger tilgjengelig for å forenkle implementeringen, og firmaer kan også lage og publisere sine egne koblinger. Disse API-ene kan distribueres i Anypoint med fleksible sikkerhetspolicyer som støtter sentralisert administrasjon og styring. Det er ingen begrensninger for volumet av transaksjoner så lenge API-et har fått riktig størrelse for sin maksimale utnyttelse (som målt i vCores).

For innkommende integrasjoner i Salesforce kan du vurdere forskjellige typer verktøy: lavkode, pro-kode eller en hybrid. Følgende deler gir veiledning for hver av disse verktøytypene og tilbyr eksempler på løsninger.

• Lavkode-verktøy for innkommende integrasjoner
• Hybridverktøy for innkommende integrasjoner
• Pro-Code-verktøy for innkommende integrasjoner

*Testing og distribusjon henviser til muligheten til å bygge i et lavere miljø og distribuere via Metadata API, pakker eller endringssett til produksjon.

En kontakt oppdateres i organisasjonens ERP-system. Denne kontaktinformasjonen må oppdateres i Salesforce.

Heroku Connect Heroku Connect brukes vanligvis til å holde en Heroku Postgres Database og Salesforce synkronisert. Med mindre ERP-systemet bruker Heroku Postgres som transaksjonsbutikk, er ikke dette bruksområdet mulig. Hvis den bruker Heroku Postgres, kan endringer som gjøres i Postgres-tabellene, synkroniseres til objekter i Salesforce med Heroku Connect.

OmniStudio Integrasjonsprosedyre Etter at ERP-systemet har oppdatert kontaktposten, kan en OmniStudio Integrasjonsprosedyre med en Data Mapper-innlastingshandling og en responshandling kalles opp via REST API-et som genereres av Data Mapper. Først sender en Data Mapper Load-handling en JSON- eller XML-belastning, som brukes til å oppdatere kontaktpostene basert på et Ekstern ID-felt eller via en Upsert Key. Hvis et enkelt svar i JSON er alt som forventes, kan en svarhandling sende tilbake eventuell relevant informasjon fra de tidligere handlingene for å indikere suksess eller feil. Hvis ERP-systemet forventer et bestemt svar, kan en Data Mapper-transformasjon eller -uttrekkshandling brukes til å generere et JSON- eller XML-svar med tilleggsfunksjoner for å deklarativt inkludere data som ble generert i utløsere av kontaktpostoppdateringen. Hovedutfordringen med dette scenariet er samtidighet: Flere samtaler for å oppdatere samme kontaktpost samtidig vil føre til problemer fordi APIen finnes direkte i Salesforce.

Salesforce Connect / eksterne objekter Salesforce Connect og eksterne objekter anbefales ikke for dette brukstilfellet fordi scenariet spesifikt krever datareplikasjon i Salesforce. Hvis du har en eksisterende Salesforce Connect integrasjon bygd på ERP, kan du konfigurere OData 4.0-koblingen til å støtte ekstern datafangst hvis ERP kan støtte datafangst av endringer. Videre må du konfigurere i Salesforce for å abonnere på endringsstrømmen fra ERP med Pub/Sub API.

*Tilleggs kreves for brukstilfeller med stor trafikk.

**Testing og distribusjon henviser til muligheten til å bygge i et lavere miljø og distribuere via Metadata API, pakker eller endringssett til produksjon.

En kontakt oppdateres i organisasjonens ERP-system. Denne kontaktinformasjonen må oppdateres i Salesforce.

Tilpasset kode i et eksternt system publiserer en plattformhendelse når kontaktposten oppdateres i ERP.**** En utløser, Prosess eller Flyt i Salesforce kan abonnere på plattformhendelsen og oppdatere tilhørende Salesforce-objekter når en hendelse behandles. Plattformhendelsen kan fungere bare som et signal om at en endring skjedde i kundens ERP-system uten å inneholde data, eller den kan inneholde de faktiske dataene som er nødvendige for å oppdatere Salesforce-objektet.

Salesforce Connect/External Objects (med tilpassede Apex-adaptere) Denne løsningen gjelder ikke i et brukstilfelle som krever datareplikasjon. Denne løsningen gjelder hvis du trenger at brukere i Salesforce skal se informasjon fra et eksternt system som ikke kan eller ikke kan replikeres i Salesforce, og det eksterne systemet ikke støtter standardprotokoller som OData eller GraphQL. Se Brukstilfellet: Utgående integrasjon ved bruk av hybridverktøy som et eksempel på et brukstilfelle for en tilpasset Apex-adapter.

Data 360 Når en kontakt oppdateres i eksterne systemer som ERP, kan kontaktoppdateringene synkroniseres til Data 360 enten ved hjelp av tilgjengelige forhåndskoblinger eller ved hjelp av API-er og kodeverktøy som MuleSoft. Kontakt kan også refereres til i Data 360 ved bruk av nullkopieringsmekanisme (tilgjengelig på enkelte plattformer). Når data er tilgjengelig i Data 360, kan andre integrasjonsmekanismer brukes til å synkronisere dataene til andre Salesforce-organisasjoner. Data kan åpnes ved referanse med Data Cloud One. Data kan også replikeres ved bruk av aktiveringer og andre API-er ved bruk av ferdige koblinger eller ved hjelp av pro-kodingsverktøy som MuleSoft Anypoint-plattform.

*API-forespørselsgrenser og -tildelinger gjelder.

**Bulk-API-er har aspekter ved virkemåte for å prøve på nytt, og en rekke API-er tilbyr tilbakemeldingsbeskyttelse via allOrNone-innstillingen (se for eksempel allOrNone-parametere i sammensatte og samlingsforespørsler)

*** Aktivering av Shield Platform Encryption endrer visse virkemåter, se Generelle vurderinger om Shield Platform Encryption for å få mer informasjon.

****Testing og distribusjon henviser til muligheten til å bygge i et lavere miljø og distribuere via Metadata API, pakker eller endringssett til produksjon.

*****Sammensatte API-er støtter flere objekter.

En kontakt oppdateres i organisasjonens ERP-system. Denne kontaktinformasjonen må oppdateres i Salesforce.

Tilpassede Apex REST- og SOAP-nettjenester Du kan opprette en nettjeneste med Apex-kode som kan utføre CRUD-operasjoner (opprette, lese, oppdatere, slette) på Kontakt-objektet. Denne tjenesten kalles opp via SOAP eller REST fra det eksterne systemet (ERP).

MuleSoft Anypoint Hensikten med MuleSoft Anypoint er å gi API-behandling i bedriftsklasse. MuleSoft Anypoint tilbyr et stort sett forhåndsbygde koblinger som du kan bruke til å integrere med mange ERP-systemer, inkludert SAP, Oracle EBS, Oracle ERP og NetSuite. Du kan opprette en flyt for å lytte etter hendelser i disse ERP-systemene (i dette tilfellet når en ny kontakt opprettes). Når flyten startes, bruker den Salesforce-koblingen til å opprette en ny Kontakt-post (eller oppdatere en hvis kontakten allerede finnes). I tillegg er det mulig å integrere med andre systemer hvis replikeringstransaksjonen involverer syndikering av kontakten til andre systemer. Om nødvendig kan du bruke tilordnings- og transformasjonsspråket (DataWeave) til å utføre kompleks logikk og beregninger når informasjon flyter på tvers av flere forskjellige systemer. Godkjenning mot disse systemene kan gjøres via mange forskjellige godkjenningsmekanismer, som grunnleggende godkjenning og OAuth, blant annet. Det er ingen begrensninger for volumet av transaksjoner så lenge flyten har fått riktig størrelse for sin maksimale utnyttelse (målt i vCores).

Innebygde Salesforce-APIer Når (eller umiddelbart etter) oppdateringstransaksjonen i ERP-systemet fullføres, kan du utføre en oppdateringsoperasjon på Kontakt-objektet via SOAP API eller utføre en PATCH mot Contact sObjects REST API i Salesforce-organisasjonen.

Salesforce-til-Salesforce-produktet har nådd slutten på levetiden. Salesforce-til-Salesforce gjorde det enkelt for partnere som samarbeider om å selge til og støtte felles kunder, men Salesforce vil investere i å bringe mer innovasjon til andre verktøy. For å gå videre anbefales følgende tilnærminger for deling av data mellom Salesforce-organisasjoner.

*Testing og distribusjon henviser til muligheten til å bygge i et lavere miljø og distribuere via Metadata API, pakker eller endringssett til produksjon

**Aktivering av Shield Platform Encryption endrer visse virkemåter, se Generelle vurderinger om Shield Platform Encryption for å få mer informasjon.

Plattformhendelser er ikke optimale for integrering av data fra én Salesforce-organisasjon til en annen fordi de ikke kan "lytte" mellom organisasjoner for samme hendelse. Tilpasset Apex er heller ikke en anbefalt tilnærming for denne typen integrasjon.

Et stort firma opererer på tvers av flere forretningsenheter (BU-er). Hver forretningsorganisasjon har sin egen Salesforce-organisasjon. En enkelt kunde håndterer flere forretningsenheter i virksomheten og har dermed konto- og salgsmulighetsdata i flere organisasjoner. Virksomheten må ha tilgang til en samlet visning av alle Konto- og Salgsmulighetsdata på tvers av alle forretningsorganisasjoner i én organisasjon.

Note: Alle løsninger nedenfor er utformet for den minste mengden dataregistrering, i henhold til Takeaway #1.

Data 360 Konto- og salgsmulighetsdata fra forskjellige Salesforce-organisasjoner kan hentes inn i Data 360 med ferdige Salesforce-koblinger. De kan også aggregeres og harmoniseres (hvis det er nødvendig). Når data er samlet i Data 360, får du tilgang til dem i andre Salesforce-organisasjoner ved bruk av Data Cloud One uten datareplikering.

Heroku Connect For hver organisasjons organisasjon kan du bruke Heroku Connect til å synkronisere endringer fra Salesforce til en enkelt Heroku Postgres-database. I dette scenariet er ikke toveis synkronisering aktivert, bare synkronisering fra Salesforce til Postgres. Deretter kan du i Heroku Connect aktivere Odata og velge tabellene du vil vise som eksterne objekter i Salesforce-organisasjonen der du vil ha en samlet visning. Fra Salesforce definerer du en ekstern datakilde som peker til Odata i Heroku.

MuleSoft Anypoint MuleSoft Anypoint tilbyr API-behandling i bedriftsnivå. En MuleSoft Anypoint API kan konfigureres slik at den leser informasjon fra flere relaterte Salesforce-organisasjoner ved å bruke Salesforce-koblingen med flere tilkoblinger til organisasjonene. MuleSoft-flyten kan spørre de forskjellige Salesforce-organisasjonene og returnere en bestemt struktur som er forbedret eller beriket med annen tredjepartsinformasjon hvis det er nødvendig. Når APIen kalles opp, utfører den alle de riktige oppkallene til Salesforce-organisasjonen (i dette eksemplet spørring om konto- og salgsmulighetsinformasjon) slik at dataene kan behandles av forbrukeren (sannsynligvis et grensesnitt). Godkjenning mot disse systemene kan gjøres via en rekke godkjenningsmekanismer, inkludert grunnleggende godkjenning og OAuth. Det er ingen begrensninger for volumet av transaksjoner, så lenge flyten har fått riktig størrelse for sin maksimale utnyttelse (målt i vCores eller Cores).

Native Salesforce APIer Spørringsoperasjoner kan utstedes til hver av de interesserte organisasjonene, spesielt via Salesforce Bulk API 2.0, som er godt egnet for å effektivt trekke ut tusenvis av poster. Du kan hente spørringsresultatene fra hver organisasjon individuelt og aggregere dem med et tilpasset program eller mellomprogramvare etter kundekrav.

Salesforce Connect med adapter for flere organisasjoner Salesforce Connect-adapteren for flere organisasjoner passer ikke godt i dette scenariet, da kontoer eller salgsmuligheter fra eksterne organisasjoner alle vil vises i den sentrale organisasjonen som forskjellige objekter. Det er for eksempel ingen måte å legge sammen en totalsum for beløpene for alle salgsmulighetene på tvers av alle organisasjonene.

Selektive oppdateringer for flere organisasjoner: En selger som bruker Salesforce-organisasjon A, må vise og oppdatere saksdata fra Salesforce-organisasjonen B og legge til sakskommentarer i den overordnede saken i Salesforce-organisasjonen B mens de arbeider i organisasjonen A. Data må ikke replikeres til organisasjonen A.

Heroku Connect Du kan bruke den samme tilnærmingen som er beskrevet i Data Aggregation Scenario ovenfor. Du må imidlertid aktivere CRUD på det eksterne objektet via Odata og skrive endringene tilbake til Heroku Postgres.

MuleSoft Anypoint MuleSoft Anypoint tilbyr API-behandling i bedriftsnivå. Du kan bruke den samme tilnærmingen som beskrevet i Datasammendragsscenariet ovenfor.

Native Salesforce-API-er bruker navngitt legitimasjon og kaller opp de innebygde Salesforce-API-ene til å lese og oppdatere data i den relaterte Salesforce-organisasjonen. En komponent må være utformet for å vise dataene.

Salesforce Connect med adapter for flere organisasjoner Muligheten til å vise data i et eksternt objekt (samt redigere dataene hvis du har CRUD aktivert på det eksterne objektet) støttes via Salesforce-adapteren for flere organisasjoner. Relasjoner støttes også mellom eksterne objekter slik at du kan koble til den overordnede saken i det eksterne objektet. Opprettelse av relasjoner er imidlertid en manuell prosess i dag der du konverterer en eksisterende datatype til en relasjonsdatatype. Optimaliseringer som gjøres i Service Cloud for å arbeide mer effektivt med saker, overføres heller ikke til den eksterne organisasjonen. Salesforce anbefaler sterkt å teste adapteren for flere organisasjoner og evaluere avveiningen ved arbeid med eksterne objekter kontra standardobjekter for bruksområdet.

Datasynkronisering på tvers av organisasjoner: Når en konto for en kunde oppdateres i en Salesforce-organisasjon i organisasjonens forretningsenhet, må de andre Salesforce-organisasjonens Konto-objekter oppdateres for å holde konsistent kontoinformasjon.

Data 360 Data 360 kan brukes til dataregistrering fra én organisasjon til en annen Salesforce-organisasjon. Kontodata fra én Salesforce-organisasjon kan hentes inn i Data 360 ved bruk av ferdige Salesforce-koblinger. Vi kan også bruke dataktiveringsmekanismer som gruppektivering, nær sanntids datahandlinger eller API-baserte aktiveringer til å flytte dataene fra Data 360 til Salesforce-organisasjonen.

Heroku Connect Du kan bruke den samme tilnærmingen som er beskrevet i Data Aggregation Scenario ovenfor. Du må imidlertid aktivere toveis synkronisering, og du trenger ikke lenger å aktivere Salesforce Connect fordi toveis synkronisering vil holde alle organisasjoner oppdatert når endringer gjøres i Postgres-tabellen.

MuleSoft Anypoint MuleSoft Anypoint tilbyr API-behandling i bedriftsnivå. Du kan konfigurere et Mule-program med Flow Designer i MuleSoft Anypoint for å lytte etter standard og tilpassede objekthendelser for å starte en automatisk startet flyt i Salesforce. Når Mule-programmet utløses, kan det kalle opp Anypoint-koblingen for Salesforce for å kommunisere med et hvilket som helst antall Salesforce-organisasjoner. I dette brukstilfellet kan Mule-appen oppdatere Konto-poster i de relaterte Salesforce-organisasjonene når en Konto-post oppdateres i én Salesforce-organisasjon. Hver relaterte Salesforce-organisasjon vil ha et unikt oppdateringstrinn innebygd i den generelle programflyten i MuleSoft. Godkjenning mot disse systemene kan gjøres via ulike godkjenningsmekanismer, inkludert grunnleggende godkjenning og OAuth. Det er ingen begrensninger for volumet av transaksjoner så lenge flyten har blitt riktig dimensjonert for sin maksimale utnyttelse (målt i vCores eller Cores).

Native Salesforce APIer Replication API (getUpdated, getDeleted-operasjoner) kan brukes til å synkronisere data på tvers av organisasjoner, men denne tilnærmingen anbefales ikke.

Salesforce Connect med adapter for flere organisasjoner Du kan bruke postutløste flyter og eksterne objekter til å holde enkelte data synkronisert mellom Salesforce-organisasjoner. Oppdatering av en kontopost i Organisasjon A utløser for eksempel en flyt som deretter oppdaterer den samsvarende posten i det eksterne objektet Konto, som skriver disse oppdateringene til kontoposten i Organisasjon B. Dette krever riktig bruk av flytsemantikk for å unngå blandede DML-transaksjoner. Husk også at valideringsregler og flyter i organisasjon B utløses på samme måte som når endringer utføres av våre REST/SOAP API-er.

Vær oppmerksom på denne veiledningen og referer til den når du planlegger en ny dataintegrering som involverer Salesforce. Det er alltid en god idé å forstå hele omfanget av alternativer som er tilgjengelig for deg, og hvordan de kan passe til ditt spesifikke bruksområde.

Hjelp oss med å sikre at vi publiserer det som er mest relevant for deg. Ta undersøkelsen for å gi tilbakemelding om dette innholdet og fortell oss hva du vil se videre.