Der er mange måder, hvorpå du kan få adgang til, synkronisere og dele data mellem Salesforce og eksterne systemer. Men ikke alle værktøjer er rigtige for dit særlige projekt. Denne vejledning gennemgår landskabet af dataintegrationsværktøjer, der er tilgængelige fra Salesforce. Den tilbyder også anbefalinger til de værktøjer (eller kombinationer af værktøjer), der er mest relevante for en bestemt anvendelsessituation, samt vejledning i værktøjer, der skal undgås i specifikke scenarier.

Denne beslutningsvejledning fokuserer på integrationer på dataniveau, der involverer Salesforce. Specifikt dækker den følgende anvendelsessituationer for dataintegration:

• Salesforce til eksterne systemer
• Eksterne systemer til Salesforce
• Salesforce-organisation til Salesforce-organisation

Dette er kun et undersæt af de integrationsudfordringer, som Salesforce-arkitekter står over for, så vi planlægger at tilføje flere beslutningsvejledninger med fokus på begivenhedsstyret integration, opbygning af effektive kunde- eller medarbejderorienterede arbejdsflows ved brug af procesintegration osv. Endelig er det vigtigt at bemærke, at mange af de værktøjer og tilgange, der er beskrevet her, kan bruges til at løse integrationsudfordringer på tværs af den bredere virksomhed, men sådanne anvendelser er uden for omfanget af denne vejledning.

• Undgå unødvendig datareplikering. Medmindre dataene absolut skal være i Salesforce, kan du overveje datavirtualisering med Salesforce Connect i stedet for. Flere data i din organisation fører til sidst til større datamængder, hvilket kan påvirke ydeevnen negativt og øge den tekniske gæld. Hvis dine data allerede findes i Salesforce, og du har brug for dem i et eksternt system, skal du undgå at kopiere dem til et eksternt system, medmindre det er absolut nødvendigt. I stedet kan du få det eksterne system adgang til dataene via Salesforce-API'er.
• Brug MuleSoft eller andre Enterprise Service Bus (ESB) eller Extract-Transform-Load (ETL) løsninger, hvis de er tilgængelige, og del af dit eksisterende landskab. Da disse værktøjer er bygget til at hjælpe med at understøtte datamigrering og -transformation, har de ofte effektive funktioner, der gør det muligt for dig at genbruge integrationer på tværs af virksomheden, vedligeholde stærkere styring og centralisere administration af integrationer. I denne vejledning, uanset hvor MuleSoft Anypoint anbefales, skal du overveje, om din eksisterende ESB/ETL-løsning vil være tilstrækkelig.
• Harmoniser data fra forskellige kilder med Data 360 og Data Cloud One. Gennem Customer 360, identitetsløsning, datafederation og andre funktioner konsoliderer Data 360 data fra Salesforce og andre eksterne systemer i en forenet visning af din kunde. Og med Data Cloud One kan brugere i andre Salesforce-organisationer sikkert få adgang til data, der deles virtuelt fra Data 360, gennem dataområder.
• Flyt data mellem organisationer ved brug af Data 360-handlinger og -aktiveringer. Når data er overført fra forskellige organisationer til Data 360, kan datahandlinger og aktiveringer synkronisere dataene til en anden organisation. Denne tilgang kan være meget nyttig for integrationer med Marketing Cloud-organisationer.
• Udtræk og flyt data ved brug af MuleSoft Anypoint. MuleSoft Anypoint kan bruges til at udtrække data fra Data 360 ved brug af Connect API og Data Graph API og flytte dem til en anden Salesforce-organisation. Uden Data 360 kan MuleSoft Anypoint også bruges, når der skal flyttes data mellem organisationer uden at blive replikeret i Data 360.
• Vær forsigtig, hvis du vælger at opbygge med udgående meddelelser. Salesforce vil fortsætte med at understøtte Udgående meddelelser inden for de aktuelle funktionelle kapaciteter, men har ikke planer om at foretage yderligere investeringer i denne teknologi.
• Integrationsbrugerlicens med profilen "Kun API" anbefales altid til alle integrationer. Salesforce anbefaler også brug af eksterne klientapplikationer (til fordel for tilsluttede apps eller SOAP-login) som de korrekt tilladte AuthN- og AuthZ-mønstre for alle integrationer.

Før du går i detaljer med de tilgængelige dataintegrationsværktøjer, er det vigtigt at huske på nogle få almindelige overvejelser, når du vælger et værktøj. Som det er typisk med arkitektur, er der ingen retningsgivende svar på alle forretningsudfordringer. Hvis du har erklæret ordene "det afhænger", når du foretager integrationsvalg, så er du på det rigtige sted.

Her er en oversigt på højt niveau over de værktøjer, der er tilgængelige for dataintegration, og nogle overvejelser for at starte med at evaluere hver indstilling. Følgende afsnit indeholder detaljerede anvendelsessituationer og detaljer om funktionerne i disse værktøjer.

*Tilføjelse kræves for anvendelsessituationer med højvolumen ændringsdataregistrering

**Tilføjelse kræves for anvendelsessituationer med højvolumen platformsbegivenheder

***Gælder i situationer, hvor det er ok at køre forretningslogik i webbrowseren.

Kolonnefortælling:

• Tilgængelig: Fungerer godt i de fleste anvendelsessituationer
• Ikke ideel: muligt, men overvej et alternativt værktøj
• Ikke tilgængelig: ingen planer om at understøtte i de næste tolv måneder

Der er andre værktøjer, der understøtter nogle aspekter af en datalagintegration, men som ikke må betragtes som en primær metode til at løse integrationsproblemer. Lad os se nærmere på disse værktøjer nu.

Lightning Web-komponenter bruges typisk til procesintegrationer, men de kan foretage udkald ved brug af JavaScript-funktionalitet, så data kan være involveret i disse transaktioner.

Salesforce-forløb kan bruges til at orkestrere eksterne udkald med eksterne tjenester eller Apex-handlinger. Salesforce-forløb i sig selv betragtes ikke som et enkeltstående dataintegrationsværktøj.

Guiden Dataimport og Data Loader kan bruges til at synkronisere, importere og migrere data. Mens Data Loader-kommandoer også kan scriptes til at automatisere import og eksport af data, er kommandolinjegrænsefladen kun til Windows, og ingen af disse værktøjer er et anbefalet grundlag for en dataintegrationsstrategi. Brug dem i stedet til at supplere din dataforvaltnings- og vedligeholdelsesstrategi.

Datakommandoerne Salesforce CLI kan bruges til at manipulere registreringer i din organisation. Kommandoer er tilgængelige for at hjælpe dig med at importere og eksportere data med Bulk API og SObject Tree Save API og udføre enkle CRUD-handlinger på individuelle registreringer med REST API. Salesforce CLI i sig selv betragtes ikke som et enkeltstående dataintegrationsværktøj.

OmniStudio Data Mapper kan bruges som et deklarativt ETL-værktøj til at flytte data mellem Salesforce-objekter og JSON-datastrukturer. Mens der automatisk oprettes en REST-grænseflade for hver Data Mapper-grænseflade, hvilket giver en deklarativ måde at flytte data fra eksterne systemer til Salesforce-objekter, er Standalone Data Mapper ikke en anbefalet basis for en dataintegrationsstrategi. Data Mapper-handlinger er tilgængelige i OmniStudio-integrationsprocedurer.

Dataloader.io er en anden data loader værktøj til Salesforce drevet af MuleSoft Anypoint Platform giver dig mulighed for hurtigt og sikkert at importere, eksportere og slette ubegrænsede mængder af data for din virksomhed. Dataloader.io er ikke en anbefalet basis for en dataintegrationsstrategi.

For udgående integrationer fra Salesforce kan du overveje forskellige typer værktøjer: lav kode, pro-code eller en hybrid. Følgende afsnit giver vejledning for hver af disse værktøjstyper og tilbyder eksempelløsninger.

• Værktøjer med lav kode til udgående integrationer
• Hybridværktøjer til udgående integrationer
• Pro-Code-værktøjer til udgående integrationer

Når salgsmuligheder er vundet, skal der oprettes en bestilling for de tilknyttede produkter i firmaets ERP-system eller bestillingsstyringssystem.

Skift dataregistrering Når salgsmulighedsregistreringer opdateres, udgiver Skift dataregistrering ændringsbegivenheder, der indeholder opdateringerne til objekterne. Ændringsbegivenhederne forbruges på kundens side over en CometD-forbindelse (eller via en MuleSoft-forbindelse) og bruges til at opdatere kundens ERP- eller bestillingsstyringssystem. Ændringsbegivenheder kan beriges til altid at inkludere eksterne registrerings-id'er eller andre data fra objektet (f.eks. område), der er nødvendige for integrationen. Ændringsbegivenhedsstreams for flere objekter kan kombineres til kanaler til forenklet abonnement og streambehandling (så du kan abonnere på og behandle en stream i stedet for mange).

Eksterne tjenester Hvis du har en webtjeneste, der understøtter OpenAPI 2.0- eller 3.0-specifikationen, kan du vise handlingerne og tjenesterne som en ekstern tjeneste i Salesforce. API-handlingerne (f.eks. oprette bestilling) kan kaldes som en handling, der kan kaldes, i et forløb, der er opbygget med Flow Builder, når fasen af salgsmuligheden ændres til "Vundet".

Heroku Connect Heroku Connect bruges typisk til at holde en Heroku Postgres Database og Salesforce synkroniseret. Hvis kunden bruger Heroku Postgres som deres kilde-til-sandhed-transaktionsbutik, kan du synkronisere registreringerne og ændringerne fra Salesforce til Heroku Postgres ved brug af Heroku Connect. Derfra kan du bruge Heroku Streaming-forbindelser til at udgive disse ændringer til Apache Kafka og sende dem som begivenheder til downstreamapplikationer, herunder ERP eller bestillingsstyringssystemet.

OmniStudio Integration Procedure Når en ordre indsendes, kan Omniscript, der orkestrerer processen, sende bestillingsdetaljerne til en ERP- eller MuleSoft-forbindelse. Indlægget kan afvikles enten direkte af Omniscript (på klientsiden) eller indirekte via en integrationsprocedure (på serversiden). Hvis ERP-systemet medfører en valideringsfejl, skal Omniscript-brugergrænsefladen advisere brugeren og om nødvendigt oversætte og kontekstualisere fejlen for brugeren.

Salesforce Connect/External Objects Du kan oprette et registreringsudløst forløb i Salesforce, der indsætter en registrering i de relaterede eksterne objekter, når fasen i salgsmuligheden ændres til "Vundet". Da dette er en blandet transaktion, skal du for at undgå fejl tilføje et pauseelement i nul sekunder mellem salgsmulighedsopdateringen og de relaterede eksterne objektindsætninger, så du lukker en transaktionskontekst, før du starter en ny.

*Tilføjelse påkrævet i højvolumen anvendelsessituationer.

**Test og implementering refererer til muligheden for at bygge i et lavere miljø og implementere via Metadata API, pakker eller ændringssæt til produktion.

Når salgsmuligheder er vundet, skal der oprettes en bestilling for de tilknyttede produkter i firmaets ERP- eller bestillingsstyringssystem.

Apex-handlinger Et registreringsudløst forløb baseret på salgsmulighedstilstanden kan udløses automatisk, når en salgsmulighed vinder. Forløbet udfører en handling, der kan kaldes, der bruger et eksternt udkald til at indsende bestillingen til bestillingsstyringssystemet eller ERP-løsningen. Højvolumen indsendelser og bestillinger på flere lokaliteter håndteres af Apex og kømekanismer.

Udgående meddelelser Efter opsætning af udgående meddelelser kan du definere en arbejdsflowregel, der udløses af salgsmulighedsopdateringen for at sende en SOAP-meddelelse over HTTP(S) til en angivet slutpunkts-URL, der er vært for lytter. Meddelelsen vil indeholde de felter, der er angivet, da den udgående meddelelse blev oprettet. Hvis oplysningerne i objektet ændres, efter adviseringen er sat i kø, men før den sendes, er det kun de opdaterede oplysninger, der leveres, og meddelelser forbliver i køen, indtil de er sendt korrekt, eller indtil de er 24 timer gamle. Efter 24 timer droppes meddelelser fra køen. Hvis ERP-systemet kræver yderligere data, kan du overføre sessionId i udgående meddelelser, så det eksterne system kan foretage en tilbagekaldsanmodning.

Platformsbegivenheder Du kan definere en platformsbegivenhed, der inkluderer den tilpassede data, der er nødvendige for at oprette registreringerne i det eksterne system. Da platformsbegivenheder ikke udgives automatisk ved registreringsændring, skal du udgive begivenheden via Apex, Salesforce-forløb eller Proceskonstruktør, når fasen af salgsmuligheden ændres til "Vundet". En ekstern tjeneste lytter til platformsbegivenhedskanalen ved brug af CometD (eller en MuleSoft-forbindelse) og opretter de relevante registreringer i det eksterne system.

Salesforce Connect/External Objects (med tilpassede Apex-adaptere) En løsning baseret på Salesforce Connect/External-objekter er ikke perfekt egnet til en anvendelsessituation, der kun kræver datasynkronisering. Men denne løsning kan anvendes i situationer, hvor brugere i Salesforce har brug for at se og potentielt interagere med data fra det eksterne system, og dataene kan ikke replikeres i Salesforce. Hvis ERP eller ordreadministrationssystemet ikke understøtter OData- eller GraphQL-protokoller, kan udviklerteamet bruge Apex Connector Framework til at skrive Apex-klasser, der håndterer kommunikation med det eksterne system via en understøttet protokol.

Data 360 En løsning baseret på Data 360 passer perfekt til anvendelsessituationer, hvor vi har brug for harmoniserede data fra forskellige kilder i ét datalager. Det kan også bruges, når vi har brug for at replikere data fra en Salesforce-organisation til flere Salesforce-organisationer eller til andre eksterne systemer ved brug af Data 360 som en datahub. Når en salgsmulighed vundes og opdateres i kildeorganisationen, synkroniseres salgsmulighedsdata til Data 360, hvor de kan replikeres i andre systemer, herunder Salesforce-organisationer, ved brug af forskellige mekanismer som handlinger, aktiveringer og API'er. På samme måde kan en salgsmulighed refereres til uden at replikere dataene i andre Salesforce-organisationer ved brug af Data Cloud One. Men Data Cloud One understøtter ikke ikke-Salesforce-platforme.

*Aktivering af Shield Platform Encryption ændrer visse adfærd, se Generelle Shield Platform Encryption Overvejelser for yderligere oplysninger.

**Test og implementering refererer til muligheden for at bygge i et lavere miljø og implementere via Metadata API, pakker eller ændringssæt til produktion.

Når salgsmuligheder er vundet, skal der oprettes en bestilling for de tilknyttede produkter i firmaets ERP- eller bestillingsstyringssystem.

Tilpasset Apex Du kan oprette en Apex-udløser og udløserhåndtere på salgsmuligheden, der foretager et udkald til ERP- eller bestillingsstyringssystemet, når fasen af salgsmuligheden ændres til "Vundet". Bemærk, at hvis du foretager udkald fra en udløser eller efter udførelse af en DML-handling, skal du bruge en metode, der er anmærket som fremtidig eller kan sættes i kø. Et udkald i en udløser bevarer databaseforbindelsen åben i udkaldets levetid. Alle Apex-koder er bundet af Apex-styring og API-grænser, som løbende revideres.

Eksterne tjenester Hvis virksomhedens eksterne ERP eller ordreadministrationssystem er defineret via en OpenAPI-specifikation, kan udkald til disse tjenester, der udføres i den fremtidige metode eller job, der kan køes, forenkles. De registrerede eksterne tjenester kan kaldes direkte fra Apex uden at skulle skrive kedelkode. I eksemplet kan udkaldet til at oprette bestillingen håndteres af den eksterne tjeneste.

MuleSoft Anypoint MuleSoft Anypoint leverer API-styring på virksomhedsniveau. MuleSoft Anypoint kan oprette API'er for at aktivere læseadgang (og/eller skriveadgang) til data for Salesforce og mange andre virksomhedssystemer. Der er mange forudbyggede forbindelser til rådighed for at forenkle implementeringen, og virksomheder kan også oprette og udgive deres egne forbindelser. Disse API'er kan implementeres i Anypoint med fleksible sikkerhedspolitikker, der understøtter centraliseret administration og styring. Der er ingen begrænsninger på mængden af transaktioner, når blot API er blevet tilpasset til den maksimale anvendelse (som målt i vCores).

For indgående integrationer i Salesforce kan du overveje forskellige typer værktøjer: lav kode, pro-code eller en hybrid. Følgende afsnit giver vejledning for hver af disse værktøjstyper og tilbyder eksempelløsninger.

• Værktøjer med lav kode til indgående integrationer
• Hybridværktøjer til indgående integrationer
• Pro-Code-værktøjer til indgående integrationer

*Test og implementering refererer til muligheden for at bygge i et lavere miljø og implementere via Metadata API, pakker eller ændringssæt til produktion.

En kontakt opdateres i organisationens ERP-system. Disse kontaktoplysninger skal opdateres i Salesforce.

Heroku Connect Heroku Connect bruges typisk til at holde en Heroku Postgres Database og Salesforce synkroniseret. Medmindre ERP-systemet bruger Heroku Postgres som dets transaktionslager, er denne anvendelsessituation ikke mulig. Hvis den bruger Heroku Postgres, kan ændringer, der er foretaget i Postgres-tabeller, synkroniseres til objekter i Salesforce ved brug af Heroku Connect.

OmniStudio Integration Procedure Når ERP-systemet opdaterer kontaktregistreringen, kan en OmniStudio Integration Procedure med en Data Mapper-indlæsningshandling og en svarhandling kaldes via den REST API, der genereres af Data Mapper. Først sender en Data Mapper Load-handling en JSON- eller XML-data, som bruges til at upsertere kontaktregistreringerne baseret på et Eksternt id-felt eller via en Upsert-nøgle. Hvis et enkelt svar i JSON er alt, hvad der forventes, kan en svarhandling sende alle relevante oplysninger tilbage fra de tidligere handlinger for at angive, at det lykkedes eller mislykkedes. Hvis ERP-systemet forventer et specifikt svar, kan der bruges en Data Mapper-transformations- eller udtrækningshandling til at generere et JSON- eller XML-svar med yderligere funktioner til deklarativt at inkludere data, der blev genereret i udløsere af kontaktregistreringsopdateringen. Hovedudfordringen med dette scenarie er samtidig: Flere opkald til at opdatere den samme kontaktregistrering samtidigt vil forårsage problemer, da API findes direkte i Salesforce.

Salesforce Connect / eksterne objekter Salesforce Connect og eksterne objekter anbefales ikke til denne anvendelsessituation, da scenariet specifikt kræver datareplikering i Salesforce. Hvis du har en allerede eksisterende Salesforce Connect, der er bygget til ERP, kan du konfigurere Odata 4.0-forbindelsen til at understøtte dataregistrering, hvis ERP kan understøtte dataregistrering af ændringsdata. Endvidere skal du konfigurere i Salesforce for at abonnere på ændringsstream fra ERP ved brug af Pub/Sub API.

*Tilføjelse kræves for højvolumen anvendelsessituationer.

**Test og implementering refererer til muligheden for at bygge i et lavere miljø og implementere via Metadata API, pakker eller ændringssæt til produktion.

En kontakt opdateres i organisationens ERP-system. Disse kontaktoplysninger skal opdateres i Salesforce.

Tilpasset kode i et eksternt system udgiver en platformsbegivenhed, når kontaktregistreringen opdateres i ERP.**** En udløser, proces eller et forløb i Salesforce kan abonnere på platformsbegivenheden og opdatere de tilsvarende Salesforce-objekter, når en begivenhed behandles. Platformsbegivenheden kan fungere ganske enkelt som et signal om, at der er sket en ændring i kundens ERP-system uden at indeholde nogen data, eller den kan indeholde de faktiske data, der er nødvendige for at opdatere Salesforce-objektet.

Salesforce Connect/External Objects (med tilpassede Apex-adaptere) Denne løsning er ikke anvendelig i en anvendelsessituation, der kræver datareplikering. Denne løsning er anvendelig, hvis brugere i Salesforce skal kunne se oplysninger fra et eksternt system, der ikke må eller ikke kan replikeres i Salesforce, og det eksterne system ikke kan understøtte standardprotokoller som Odata eller GraphQL. Se Anvendelsessituation: Udgående integration ved brug af hybride værktøjer til en eksempelanvendelsessituation for en tilpasset Apex-adapter.

Data 360 Når en kontakt opdateres i eksterne systemer som ERP, kan kontaktopdateringerne synkroniseres til Data 360 enten ved hjælp af indbyggede forbindelser eller ved hjælp af API'er og pro-code-værktøjer som MuleSoft. Kontakt kan også refereres til i Data 360 ved brug af nul-kopieringsmekanisme (tilgængelig med nogle platforme). Når data er tilgængelige i Data 360, kan forskellige indbyggede integrationsmekanismer bruges til at synkronisere dataene med andre Salesforce-organisationer. Data kan fås adgang til ved reference ved brug af Data Cloud One. Data kan også replikeres ved brug af aktiveringer og andre API'er ved brug af indbyggede forbindelser eller ved hjælp af pro-code-værktøjer som MuleSoft Anypoint-platformen.

*API-anmodningsgrænser og tildelinger gælder.

**Bulk-API'er har aspekter af genprøveadfærd, og en række API'er tilbyder tilbagerulningsbeskyttelse via allOrNone-indstillingen (se f.eks. allOrNone-parametre i sammensatte og samlingsanmodninger)

***Aktivering af Shield Platform Encryption ændrer visse adfærd, se Generelle overvejelser i Shield Platform Encryption for yderligere oplysninger.

****Test og implementering refererer til muligheden for at bygge i et lavere miljø og implementere via Metadata API, pakker eller ændringssæt til produktion.

***** Sammensatte API'er understøtter flere objekter.

En kontakt opdateres i organisationens ERP-system. Disse kontaktoplysninger skal opdateres i Salesforce.

Tilpassede Apex REST- og SOAP-webtjenester Du kan oprette en webtjeneste ved brug af Apex-kode, der kan udføre CRUD-handlinger (oprette, læse, opdatere, slette) på objektet Kontakt. Denne tjeneste kaldes via SOAP eller REST fra det eksterne system (ERP).

MuleSoft Anypoint Hensigten med MuleSoft Anypoint er at levere API-styring i virksomhedsklasse. MuleSoft Anypoint tilbyder et stort sæt forudbyggede forbindelser, som du kan bruge til at integrere med mange ERP-systemer, herunder SAP, Oracle EBS, Oracle ERP og NetSuite. Du kan oprette et forløb for at lytte efter begivenheder i disse ERP-systemer (i dette tilfælde, når der oprettes en ny kontakt). Når forløbet startes, bruger det Salesforce-forbindelsen til at oprette en ny kontaktregistrering (eller opdatere en, hvis kontakten allerede findes). Endvidere er det muligt at integrere med andre systemer, hvis replikeringstransaktionen involverer offentliggørelse af kontakten i andre systemer. Hvis der er behov for det, kan du bruge tilknytnings- og transformationssproget (DataWeave) til at udføre kompleks logik og beregninger, når oplysningerne flyder på tværs af flere uensartede systemer. Godkendelse mod disse systemer kan udføres gennem mange forskellige godkendelsesmekanismer, f.eks. Basisgodkendelse og OAuth, blandt andre. Der er ingen begrænsninger på mængden af transaktioner, når blot forløbet er blevet tilpasset til den maksimale anvendelse (målt i vCores).

Indbyggede Salesforce-API'er Når (eller umiddelbart efter) opdateringstransaktionen i ERP-systemet er færdig, kan du udføre en upsert-handling på kontaktobjektet via SOAP API eller udføre en PATCH mod Contact sObjects REST API i Salesforce-organisationen.

Salesforce til Salesforce-produktet har nået slutningen af dets levetid. Salesforce til Salesforce gjorde det nemt for partnere, der samarbejder om at sælge til og understøtte fælles kunder, men Salesforce vil investere i at bringe mere innovation til andre værktøjer. Følgende tilgange anbefales til deling af data mellem Salesforce-organisationer.

*Test og implementering refererer til muligheden for at bygge i et lavere miljø og implementere via Metadata API, pakker eller ændringssæt til produktion

**Aktivering af Shield Platform Encryption ændrer visse adfærd, se Generelle overvejelser i Shield Platform Encryption for yderligere oplysninger.

Platformsbegivenheder er ikke optimale til at integrere data fra en Salesforce-organisation til en anden, da de ikke kan "lytte" mellem organisationer for den samme begivenhed. Tilpasset Apex er heller ikke en anbefalet tilgang til denne type integration.

En stor virksomhed opererer på tværs af flere forretningsenheder (BU'er). Hver BU har sin egen Salesforce-organisation. En enkelt kunde håndterer flere forretningsenheder i virksomheden og har dermed konto- og salgsmulighedsdata i flere organisationer. Virksomheden skal have adgang til en aggregeret visning af alle konto- og salgsmulighedsdata på tværs af alle BU'er i en enkelt organisation.

Bemærk: Alle nedenstående løsninger er designet til den mindste mængde af datareplikering i overensstemmelse med Takeaway #1.

Data 360-konto- og salgsmulighedsdata fra forskellige Salesforce-organisationer kan overføres til Data 360 ved brug af indbyggede Salesforce-forbindelser. De kan også aggregeres og harmoniseres (hvis det er nødvendigt). Når data er aggregeret i Data 360, kan der opnås adgang til dem i andre Salesforce-organisationer ved brug af Data Cloud One uden datareplikering.

Heroku Connect For hver BUs individuelle organisation kan du bruge Heroku Connect til at synkronisere ændringer fra Salesforce til en enkelt Heroku Postgres-database. I dette scenarie er tovejssynkronisering ikke aktiveret, kun synkronisering fra Salesforce til Postgres. Derefter kan du i Heroku Connect aktivere Odata og vælge de tabeller, du ønsker at vise som eksterne objekter i Salesforce-organisationen, hvor du ønsker en aggregeret visning. Fra Salesforce definerer du en ekstern datakilde, der peger på Odata i Heroku.

MuleSoft Anypoint MuleSoft Anypoint leverer API-styring på virksomhedsniveau. En MuleSoft Anypoint API kan konfigureres, så den læser oplysninger fra flere relaterede Salesforce-organisationer ved brug af Salesforce-forbindelsen med flere forbindelser til organisationerne. MuleSoft-forløbet kan forespørge på de forskellige Salesforce-organisationer og returnere en specifik struktur, der er forbedret eller beriget med andre tredjepartsoplysninger, hvis det er nødvendigt. Når API'en kaldes, foretager den alle de rette Salesforce-organisationsudkald (i dette eksempel forespørgsler på konto- og salgsmulighedsoplysninger), så dataene kan behandles af forbrugeren (sandsynligvis en brugergrænseflade). Godkendelse mod disse systemer kan udføres gennem en række godkendelsesmekanismer, herunder basisgodkendelse og OAuth. Der er ingen begrænsninger på mængden af transaktioner, når blot forløbet er blevet tilpasset til den maksimale anvendelse (målt i vCores eller Kerner).

Native Salesforce-API'er Forespørgselshandlinger kan udstedes til hver af de interesserede organisationer, især via Salesforce Bulk API 2.0, som er velegnet til effektiv udtrækning af tusindvis af registreringer. Du kan hente forespørgselsresultaterne fra hver organisation individuelt og aggregere dem med en tilpasset applikation eller en mellemliggende software pr. kundekrav.

Salesforce Connect med Cross-Org-adapter Salesforce Connect Cross-Org-adapteren passer ikke godt i dette scenarie, da konti eller salgsmuligheder fra fjernorganisationer alle vises i den centrale organisation som forskellige objekter. Der er f.eks. ingen måde at opsummere en hovedtotal for beløbene for alle salgsmuligheder på tværs af alle organisationer.

Selektiv opdatering af krydsorganisations-scenarie: En sælger, der bruger Salesforce-organisation A, skal se og opdatere sagsdata fra Salesforce-organisation B og føje sagskommentarer til den overordnede sag på Salesforce-organisation B, mens han/hun arbejder i organisation A. Data må ikke replikeres til organisation A.

Heroku Connect Du kan bruge den samme tilgang som beskrevet i dataggregeringsscenariet ovenfor. Du skal dog aktivere CRUD på det eksterne objekt via Odata og skrive ændringerne tilbage til Heroku Postgres.

MuleSoft Anypoint MuleSoft Anypoint leverer API-styring på virksomhedsniveau. Du kan bruge den samme tilgang, der er beskrevet i dataggregeringsscenariet ovenfor.

Indbyggede Salesforce-API'er bruger navngivne legitimationsoplysninger og kalder de oprindelige Salesforce-API'er til at læse og opdatere data i den relaterede Salesforce-organisation. En komponent skal være designet til at vise dataene.

Salesforce Connect med krydsorganisationsadapter Muligheden for at se data i et eksternt objekt (samt redigere dataene, hvis du har CRUD aktiveret på det eksterne objekt) understøttes via Salesforce tværorganisationsadapteren. Relationer understøttes også mellem eksterne objekter, så du kan linke til den overordnede sag i det eksterne objekt. Men oprettelse af relationer er en manuel proces i dag, hvor du konverterer en eksisterende datatype til en relationsdatatype. Endvidere overføres optimeringer, der er foretaget i Service Cloud for at arbejde med sager mere effektivt, ikke til fjernorganisationen. Salesforce anbefaler på det kraftigste, at du tester krydsorganisationsadapteren og evaluerer afvejningerne i at arbejde med eksterne objekter i forhold til standardobjekter for din anvendelsessituation.

Datasynkronisering på tværs af organisationer: Når en konto for en kunde opdateres i en af organisationens Salesforce-forretningsenhedsorganisationer, skal de andre Salesforce-organisationskontoobjekter opdateres for at bevare ensartede kontooplysninger.

Data 360 Data 360 kan bruges til datareplikering fra en organisation til en anden Salesforce-organisation. Kontodata fra en Salesforce-organisation kan overføres til Data 360 ved brug af indbyggede Salesforce-forbindelser. Vi kan bruge dataktiveringsmekanismer som batchaktivering, datahandlinger i næsten realtid eller API-baserede aktiveringer samt til at flytte dataene fra Data 360 til Salesforce-organisationen.

Heroku Connect Du kan bruge den samme tilgang som beskrevet i dataggregeringsscenariet ovenfor. Du skal dog aktivere tovejssynkronisering, og du behøver ikke længere at aktivere Salesforce Connect, da tovejssynkronisering vil holde alle organisationer opdateret, når der foretages ændringer af Postgres-tabellen.

MuleSoft Anypoint MuleSoft Anypoint leverer API-styring på virksomhedsniveau. Du kan konfigurere en Mule-applikation med Flow Designer i MuleSoft Anypoint til at lytte til standardobjektbegivenheder og tilpassede objektbegivenheder for at starte et automatisk startet forløb i Salesforce. Når Mule-applikationen udløses, kan den kalde Anypoint-forbindelsen for Salesforce for at kommunikere med ethvert antal Salesforce-organisationer. I denne anvendelsessituation, når en kontoregistrering opdateres i en Salesforce-organisation, kan Mule-appen opdatere kontoregistreringer i de relaterede Salesforce-organisationer. Hver relateret Salesforce-organisation vil have et entydigt opdateringstrin indbygget i det generelle applikationsforløb i MuleSoft. Godkendelse mod disse systemer kan udføres gennem forskellige godkendelsesmekanismer, herunder basisgodkendelse og OAuth. Der er ingen begrænsninger på mængden af transaktioner, når blot forløbet er blevet tilpasset til den maksimale anvendelse (målt i vCores eller Kerner).

Indbyggede Salesforce-API'er Replication API (getUpdated, getDeleted-handlinger) kan bruges til at synkronisere data på tværs af organisationer, men denne tilgang anbefales ikke.

Salesforce Connect med krydsorganisationsadapter Du kan bruge registreringsudløste forløb og eksterne objekter til at holde nogle data synkroniseret mellem Salesforce-organisationer. Opdatering af en kontoregistrering i organisation A udløser f.eks. et forløb, der derefter opdaterer den matchende registrering på det eksterne kontoobjekt, som skriver disse opdateringer til kontoregistreringen i organisation B. Dette kræver korrekt brug af forløbssemantik for at undgå blandede DML-transaktioner. Husk også på, at valideringsregler og forløb i organisation B udløses på samme måde, som når ændringer foretages af vores REST/SOAP-API'er.

Husk på denne vejledning, og se på den, når du planlægger en ny dataintegration, der involverer Salesforce. Det er altid en god ide at forstå det fulde omfang af indstillinger, der er tilgængelige for dig, og hvordan de kan passe til din specifikke anvendelsessituation.

Hjælp os med at sikre, at vi udgiver det, der er mest relevant for dig. Tag vores undersøgelse for at give feedback om dette indhold og fortæl os, hvad du gerne vil se som det næste.