Det finns flera olika sätt att komma åt, synkronisera och dela data mellan Salesforce och externa system. Men inte alla verktyg är rätt för ditt specifika projekt. Denna guide går igenom landskapet av dataintegreringsverktyg som är tillgängliga från Salesforce. Den erbjuder även rekommendationer för de verktyg (eller kombinationer av verktyg) som är mest lämpliga för ett visst användningsfall, samt råd om verktyg att undvika för specifika scenarion.

Denna beslutsguide fokuserar på datanivåintegreringar som involverar Salesforce. Specifikt omfattar den följande användningsfall för dataintegrering:

• Salesforce till externa system
• Externa system till Salesforce
• Salesforce-organisation till Salesforce-organisation

Dessa är endast en underuppsättning av de integreringsutmaningar som Salesforce Architects står inför, så vi planerar att lägga till fler beslutsguider som fokuserar på händelsedriven integrering, bygga effektiva arbetsflöden för kunder eller anställda med hjälp av processintegrering, och så vidare. Slutligen är det viktigt att notera att många av de verktyg och metoder som beskrivs här kan användas för att lösa integrationsutmaningar i hela företaget, men sådana användningsområden ligger utanför denna guides räckvidd.

• Undvik onödig datareplikering. Om inte data absolut måste finnas i Salesforce, överväg datavirtualisering med Salesforce Connect istället. Mer data i din organisation leder i slutändan till större datavolymer, vilket kan påverka prestandan negativt och lägga till tekniska skulder. Om dina data redan finns i Salesforce och du behöver dem i ett externt system, undvik att kopiera dem till ett externt system om det inte är absolut nödvändigt. Låt istället det externa systemet komma åt data via Salesforce API.
• Använd MuleSoft eller andra Enterprise Service Bus-lösningar (ESB) eller Extract-Transform-Load-lösningar (ETL), om de är tillgängliga och en del av ditt befintliga landskap. Eftersom dessa verktyg är byggda för att hjälpa till att stödja datamigrering och -transformation har de ofta kraftfulla funktioner som låter dig återanvända integreringar i hela företaget, upprätthålla starkare styrning och centralisera hanteringen av integreringar. I denna guide, där MuleSoft Anypoint rekommenderas, överväg om din befintliga ESB/ETL-lösning kommer att räcka.
• Harmonisera data från olika källor med Data 360 och Data Cloud One. Genom datamodellen Customer 360, identitetslösning, datafederation och andra funktioner slår Data 360 samman data från Salesforce och andra externa system till en enhetlig vy av din kund. Och med Data Cloud One kan användare i andra Salesforce-organisationer säkert komma åt data som delas virtuellt från Data 360 genom datautrymmen.
• Flytta data mellan organisationer med hjälp av Data 360-åtgärder och aktiveringar. När data har intagits från olika organisationer i Data 360 kan dataåtgärder och aktiveringar synkronisera data till en annan organisation. Detta tillvägagångssätt kan vara mycket användbart för integreringar med Marketing Cloud-organisationer.
• Extrahera och flytta data med MuleSoft Anypoint. MuleSoft Anypoint kan användas för att extrahera data från Data 360 med Connect API och Data Graph API och flytta dem till en annan Salesforce-organisation. Utan Data 360 kan MuleSoft Anypoint även användas när data behöver flyttas mellan organisationer utan att replikeras i Data 360.
• Var försiktig om du väljer att bygga med utgående meddelanden. Salesforce kommer att fortsätta stödja utgående meddelanden inom nuvarande funktionskapacitet, men planerar inte att göra ytterligare investeringar i denna teknik.
• Integreringsanvändarlicens med profilen "API Only" rekommenderas alltid för alla integreringar. Salesforce rekommenderar även att använda Externa klientprogram (till förmån för anslutna appar eller SOAP-inloggning) som rätt behörighetsmönster för AuthN och AuthZ för alla integreringar.

Innan du fördjupar dig i de tillgängliga dataintegreringsverktygen är det viktigt att tänka på några vanliga saker när du väljer ett verktyg. Som vanligt med arkitektur finns det inget preskriptivt svar på varje verksamhetsutmaning. Om du har yttrat ordet "det beror på" när du gör integreringsval har du kommit rätt.

Här är en översikt av de verktyg som är tillgängliga för dataintegrering och några saker att tänka på för att börja utvärdera varje alternativ. Följande avsnitt innehåller djupgående användningsfall och detaljer om kapaciteten hos dessa verktyg.

*Tillägg som krävs för användningsfall för datainsamling av ändringar med hög volym

**Tillägg krävs för användningsfall för plattformshändelser med hög volym

***Lämpligt i situationer där det är ok för affärslogik att köras i webbläsaren.

Kolumnförklaring:

• Tillgänglig: fungerar bra för de flesta användningsfall
• Inte idealiskt: möjligt men överväg ett alternativt verktyg
• Inte tillgängligt: inga planer på support under de kommande tolv månaderna

Det finns andra verktyg som kan stödja vissa aspekter av en datalagerintegrering, men som inte får betraktas som ett primärt sätt att lösa integreringsproblem. Låt oss ta en snabb titt på dessa verktyg nu.

Lightning-webbkomponenter används vanligtvis för processintegreringar, men de kan göra anrop med JavaScript-funktionalitet, så data kan vara involverade i dessa transaktioner.

Salesforce-flöde kan användas för att orkestrera externa anrop med externa tjänster eller Apex åtgärder. Salesforce-flödet i sig anses inte vara ett fristående dataintegreringsverktyg.

Dataimportguiden och Data Loader kan användas för att synkronisera, importera och migrera data. Data Loader-kommandon kan även skriptas för att automatisera import och export av data, men kommandoradsgränssnittet är endast för Windows och inget av dessa verktyg är en rekommenderad bas för en dataintegreringsstrategi. Använd dem istället för att komplettera din strategi för dataförvaltning och underhåll.

Datakommandon för Salesforce CLI kan användas för att manipulera poster i din organisation. Kommandon är tillgängliga för att hjälpa dig importera och exportera data med Bulk API och SObject Tree Save API, och utföra enkla CRUD-operationer för individuella poster med REST API. Salesforce CLI anses inte vara ett fristående dataintegreringsverktyg.

OmniStudio Data Mapper kan användas som ett deklarativt ETL-verktyg för att flytta data mellan Salesforce-objekt och JSON-datastrukturer. Även om ett REST-gränssnitt skapas automatiskt för varje Data Mapper-gränssnitt, vilket ger ett deklarativt sätt att flytta data från externa system till Salesforce-objekt, är Data Mapper fristående inte en rekommenderad bas för en dataintegreringsstrategi. Datamappningsåtgärder är tillgängliga i OmniStudio-integreringsprocesser.

Dataloader.io är ett annat dataloader-verktyg för Salesforce som drivs av MuleSofts Anypoint Platform som gör att du snabbt och säkert kan importera, exportera och ta bort obegränsade mängder data för ditt företag. Dataloader.io är inte en rekommenderad bas för en dataintegreringsstrategi.

För utgående integreringar från Salesforce kan du överväga olika typer av verktyg: lågkod, prokod eller en hybrid. Följande avsnitt ger vägledning för var och en av dessa verktygstyper och erbjuder exempellösningar.

• Verktyg med låg kod för utgående integreringar
• Hybridverktyg för utgående integreringar
• Prokodverktyg för utgående integreringar

När säljprojekt vinns måste en order för de associerade produkterna skapas i företagets affärssystem eller orderhanteringssystem.

Ändra datainsamling När säljprojektposter uppdateras publicerar datainsamling ändringshändelser som innehåller uppdateringarna av objekten. Ändringshändelserna konsumeras på kundens sida över en CometD-anslutning (eller via en MuleSoft-anslutare) och används för att uppdatera kundens ERP- eller orderhanteringssystem. Ändringshändelser kan berikas så att de alltid inkluderar externa post-ID:n eller andra data från objektet (till exempel region) som behövs för integreringen. Strömmar för ändringshändelser för flera objekt kan kombineras till kanaler för förenklad prenumeration och strömbearbetning (så att du kan prenumerera på och bearbeta en ström istället för många).

Externa tjänster Om du har en webbtjänst som har stöd för OpenAPI 2.0- eller 3.0-specifikationen kan du visa åtgärderna och tjänsterna som en extern tjänst i Salesforce. API-åtgärderna (till exempel skapa order) kan anropas som en åberopbar åtgärd i ett flöde byggt med Flow Builder när säljprojektets fas ändras till "Vunnet".

Heroku Connect Heroku Connect används vanligtvis för att hålla en Heroku Postgres-databas och Salesforce synkroniserade. Om kunden använder Heroku Postgres som sin transaktionsbutik för sanningens källa kan du synkronisera posterna och ändringarna från Salesforce till Heroku Postgres med Heroku Connect. Därifrån kan du använda Heroku Streaming-anslutare för att publicera dessa ändringar till Apache Kafka och skicka dem som händelser till program längre ner, inklusive ERP eller orderhanteringssystemet.

OmniStudio-integreringsprocess När en order skickas kan Omniscript-orkestrera processen skicka orderdetaljerna till en ERP- eller MuleSoft-anslutare. Inlägget kan utföras antingen direkt av Omniscript (klientsidan) eller indirekt via en integreringsprocess (serversidan). Om ERP-systemet kastar ett valideringsfel måste Omniscript-gränssnittet meddela användaren och vid behov översätta och sammanhangsanpassa felet åt användaren.

Salesforce Connect/Externa objekt Du kan skapa ett postutlöst flöde i Salesforce som infogar en post i de relaterade externa objekten när säljprojektets fas ändras till "Vunnet". Eftersom detta är en blandad transaktion, lägg till ett pauselement i noll sekunder mellan säljprojektuppdateringen och de relaterade externa objektinfogningarna för att undvika fel så att du stänger ett transaktionssammanhang innan du startar ett nytt.

*Tillägg som krävs för användningsfall med hög volym.

**Test och distribuering refererar till möjligheten att bygga i en lägre miljö och distribuera via Metadata API, paket eller ändringsanvisningar till produktion.

När säljprojekt vinns måste en order för de associerade produkterna skapas i företagets ERP- eller orderhanteringssystem.

Apex-åtgärder Ett postutlöst flöde baserat på säljprojektstatus kan utlösas automatiskt när ett säljprojekt vinns. Flödet utför en åberopbar åtgärd som använder ett externt anrop för att skicka ordern till orderhanteringssystemet eller ERP-lösningen. Inskickningar med hög volym och ordrar med flera webbplatser hanteras av Apex batch- och kömekanismer.

Utgående meddelanden När du har konfigurerat utgående meddelanden kan du definiera en arbetsflödesregel som utlöses av säljprojektuppdateringen för att skicka ett SOAP-meddelande över HTTP(S) till en specificerad slutpunkts-URL som är värd för lyssnaren. Meddelandet kommer att innehålla de fält som specificerades när det utgående meddelandet skapades. Om informationen i objektet ändras efter att notisen har placerats i kö, men innan den skickas, kommer endast den uppdaterade informationen att levereras och meddelanden kommer att stanna i kön tills de har skickats, eller tills de är 24 timmar gamla. Efter 24 timmar tas meddelanden bort från kön. Om ERP-systemet kräver ytterligare data kan du skicka sessionId i utgående meddelanden så att det externa systemet kan göra en callback-begäran.

Plattformshändelser Du kan definiera en plattformshändelse som inkluderar den egna belastningen med de data som behövs för att skapa posterna i det externa systemet. Eftersom plattformshändelser inte publiceras automatiskt vid poständring måste du publicera händelsen via Apex, Salesforce-flöde eller Processbyggare när säljprojektets fas ändras till "Vunnet". En extern tjänst lyssnar på plattformshändelsekanalen med CometD (eller en MuleSoft-anslutare) och skapar lämpliga poster i det externa systemet.

Salesforce Connect/Externa objekt (med egna Apex adapters) En lösning baserad på Salesforce Connect/Externa objekt passar inte perfekt för ett användningsfall som endast kräver datasynkronisering. Denna lösning kan dock tillämpas i fall där användare inom Salesforce behöver se och potentiellt interagera med data från det externa systemet och dessa data inte kan replikeras i Salesforce. Om ERP- eller orderhanteringssystemet inte har stöd för OData- eller GraphQL-protokoll kan utvecklingsteamet använda Apex-anslutarramverket för att skriva Apex klasser som hanterar kommunikation med det externa systemet via ett protokoll som stöds.

Data 360 En lösning baserad på Data 360 är perfekt för användningsfall där vi behöver harmoniserade data från olika källor i ett datalager. Den kan även användas när vi behöver replikera data från en Salesforce-organisation till flera Salesforce-organisationer eller till andra externa system med Data 360 som ett datanav. När ett säljprojekt vinns och uppdateras i källorganisationen synkroniseras säljprojektdata till Data 360, där de kan replikeras i andra system, inklusive Salesforce-organisationer, med hjälp av olika mekanismer som åtgärder, aktiveringar och API. På samma sätt kan ett säljprojekt refereras utan att replikera data i andra Salesforce-organisationer med hjälp av Data Cloud One. Data Cloud One har dock inte stöd för icke-Salesforce-plattformar.

*Att aktivera Shield Platform Encryption ändrar vissa beteenden, se Allmänna överväganden för Shield Platform Encryption för mer information.

**Test och distribuering refererar till möjligheten att bygga i en lägre miljö och distribuera via Metadata API, paket eller ändringsanvisningar till produktion.

När säljprojekt vinns måste en order för de associerade produkterna skapas i företagets ERP- eller orderhanteringssystem.

Egen Apex Du kan skapa en Apex-utlösare och utlösarhanterare för säljprojektet som anropar ERP eller orderhanteringssystemet när säljprojektets fas ändras till "Vunnet". Observera att om du gör anrop från en utlösare eller efter att du har utfört en DML-operation måste du använda en metod som är annoterad som framtida eller köbar. Ett anrop i en utlösare håller databasanslutningen öppen under anropets livstid. All Apex kod är bunden av Apex Governor och API-gränser, som revideras kontinuerligt.

Externa tjänster Om företagets externa ERP eller orderhanteringssystem definieras via en OpenAPI-specifikation kan anropen till de tjänster som utförs i den framtida metoden eller det köade jobbet förenklas. De registrerade externa tjänsterna kan anropas direkt från Apex utan att behöva skriva boilerplate-kod. I exemplet kan anropet för att skapa ordern hanteras av den externa tjänsten.

MuleSoft Anypoint MuleSoft Anypoint tillhandahåller API-hantering i företagsklass. MuleSoft Anypoint kan skapa API:n för att aktivera läs- (och/eller skrivåtkomst) till data för Salesforce och många andra företagssystem. Det finns många färdigbyggda anslutare för att förenkla implementeringen, och företag kan även skapa och publicera sina egna anslutare. Dessa API:n kan distribueras i Anypoint med flexibla säkerhetspolicyer, med stöd för centraliserad hantering och styrning. Det finns inga begränsningar för transaktionsvolym, så länge som API har rätt storlek för sin toppanvändning (mätt i vCores).

För inkommande integreringar till Salesforce kan du överväga olika typer av verktyg: lågkod, prokod eller en hybrid. Följande avsnitt ger vägledning för var och en av dessa verktygstyper och erbjuder exempellösningar.

• Verktyg med låg kod för inkommande integreringar
• Hybridverktyg för inkommande integreringar
• Prokodverktyg för inkommande integreringar

*Test och distribuering refererar till möjligheten att bygga i en lägre miljö och distribuera via Metadata API, paket eller ändringsanvisningar till produktion.

En kontakt uppdateras i organisationens ERP-system. Dessa kontaktuppgifter måste uppdateras i Salesforce.

Heroku Connect Heroku Connect används vanligtvis för att hålla en Heroku Postgres-databas och Salesforce synkroniserade. Om inte ERP-systemet använder Heroku Postgres som transaktionslager är detta användningsfall inte möjligt. Om det använder Heroku Postgres kan ändringar som görs i Postgres-tabellerna synkroniseras till objekt i Salesforce med Heroku Connect.

OmniStudio-integreringsprocess När ERP-systemet har uppdaterat kontaktposten kan en OmniStudio-integreringsprocess med en åtgärd för inläsning av datamappning och en svarsåtgärd anropas via REST API som skapas av Data Mapper. Först skickar en Data Mapper Load-åtgärd en JSON- eller XML-belastning, som används för att infoga kontaktposterna baserat på ett Externt ID-fält eller genom en Uppdateringsnyckel. Om ett enkelt svar i JSON är allt som förväntas kan en svarsåtgärd skicka tillbaka all relevant information från de tidigare åtgärderna för att indikera framgång eller misslyckande. Om ERP-systemet förväntar sig ett specifikt svar kan en åtgärd för att transformera eller extrahera datamappning användas för att skapa ett JSON- eller XML-svar med ytterligare funktioner för att deklarativt inkludera data som skapats i utlösare av kontaktpostuppdateringen. Den största utmaningen med detta scenario är samtidighet: Flera anrop för att uppdatera samma kontaktpost samtidigt kommer att orsaka problem eftersom API finns direkt i Salesforce.

Salesforce Connect / Externa objekt Salesforce Connect och externa objekt rekommenderas inte för detta användningsfall, eftersom scenariot specifikt kräver datareplikering i Salesforce. Om du har en befintlig Salesforce Connect byggd till ERP kan du konfigurera Odata 4.0-anslutaren så att den stöder datainsamling av externa ändringsdata om ERP har stöd för datainsamling av ändringsdata. Dessutom måste du konfigurera i Salesforce att prenumerera på ändringsströmmen från ERP, med Pub/Sub API.

*Tillägg krävs för användningsfall med hög volym.

**Test och distribuering refererar till möjligheten att bygga i en lägre miljö och distribuera via Metadata API, paket eller ändringsanvisningar till produktion.

En kontakt uppdateras i organisationens ERP-system. Dessa kontaktuppgifter måste uppdateras i Salesforce.

Plattformshändelser Egen kod i ett externt system publicerar en plattformshändelse när kontaktposten uppdateras i ERP. En utlösare, process eller flöde i Salesforce kan prenumerera på plattformshändelsen och uppdatera motsvarande Salesforce-objekt när en händelse bearbetas. Plattformshändelsen kan endast fungera som en signal om att en ändring har inträffat i kundens ERP-system utan att innehålla några data, eller så kan den innehålla de faktiska data som behövs för att uppdatera Salesforce-objektet.

Salesforce Connect/Externa objekt (med egna Apex adapters) Denna lösning är inte tillämplig i ett användningsfall som kräver datareplikering. Denna lösning är tillämplig om du vill att användare i Salesforce ska se information från ett externt system som inte får eller inte kan replikeras i Salesforce och det externa systemet inte har stöd för standardprotokoll som Odata eller GraphQL. Se Användningsfall: Utgående integrering med hybridverktyg för ett exempel på användning av en egen Apex-adapter.

Data 360 När en kontakt uppdateras i externa system som ERP kan kontaktuppdateringarna synkroniseras till Data 360 antingen med hjälp av tillgängliga färdiga anslutare eller med hjälp av API:n och prokodverktyg som MuleSoft. Kontakt kan även refereras i Data 360 med nollkopieringsmekanism (tillgängligt med vissa plattformar). När data är tillgängliga i Data 360 kan olika färdiga integreringsmekanismer användas för att synkronisera data till andra Salesforce-organisationer. Data kan kommas åt genom hänvisning med Data Cloud One. Data kan också replikeras med hjälp av aktiveringar och andra API:n med hjälp av färdiga anslutare eller med hjälp av prokodverktyg som MuleSoft Anypoint Platform.

*API-begärangränser och allokeringar gäller.

**API:n i bunt har aspekter av återförsöksbeteende och ett antal API:n erbjuder återställningsskydd via inställningen allOrNone (till exempel, se allOrNone-parametrar i sammansatta begäranden och samlingsbegäranden)

***Att aktivera Shield Platform Encryption ändrar vissa beteenden, se Allmänna överväganden för Shield Platform Encryption för mer information.

****Test och distribuering refererar till möjligheten att bygga i en lägre miljö och distribuera via Metadata API, paket eller ändringsanvisningar till produktion.

*****Samlade API:n har stöd för flera objekt.

En kontakt uppdateras i organisationens ERP-system. Dessa kontaktuppgifter måste uppdateras i Salesforce.

Egna Apex REST- och SOAP-webbtjänster Du kan skapa en webbtjänst med Apex kod som kan utföra CRUD-operationer (skapa, läsa, uppdatera, ta bort) för objektet Kontakt. Denna tjänst kommer att åberopas via SOAP eller REST från det externa systemet (ERP).

MuleSoft Anypoint Syftet med MuleSoft Anypoint är att tillhandahålla API-hantering av företagsklass. MuleSoft Anypoint erbjuder en stor uppsättning färdigbyggda anslutare som du kan använda för att integrera med många ERP-system, inklusive SAP, Oracle EBS, Oracle ERP och NetSuite. Du kan skapa ett flöde för att lyssna efter händelser i dessa ERP-system (i detta fall när en ny kontakt skapas). När flödet sparkas igång använder det Salesforce-anslutaren för att skapa en ny kontaktpost (eller uppdatera en om kontakten redan finns). Det är även möjligt att integrera med andra system om replikeringstransaktionen innefattar att syndikera kontakten till andra system. Om det behövs kan du använda mappnings- och transformationsspråket (DataWeave) för att utföra komplex logik och beräkningar medan information flödar över flera olika system. Autentisering mot dessa system kan göras genom många olika autentiseringsmekanismer som till exempel Grundläggande autentisering och OAuth. Det finns inga begränsningar för transaktionsvolym så länge som flödet har rätt storlek för sin toppanvändning (mätt i vCores).

Inbyggda Salesforce API:n När (eller direkt efter) uppdateringstransaktionen i ERP-systemet är klar kan du utföra en infoga-åtgärd för objektet Kontakt via SOAP API eller utföra en PATCH mot Contact sObjects REST API i Salesforce-organisationen.

Salesforce till Salesforce-produkten har nått sitt slut. Salesforce till Salesforce har gjort det enkelt för partners som arbetar tillsammans att sälja till och stödja gemensamma kunder, men Salesforce kommer att investera i att skapa mer innovation i andra verktyg. Framöver rekommenderas följande metoder för att dela data mellan Salesforce-organisationer.

*Test och distribuering refererar till möjligheten att bygga i en lägre miljö och distribuera via Metadata API, paket eller ändringsanvisningar till produktion

**Att aktivera Shield Platform Encryption ändrar vissa beteenden, se Allmänna överväganden för Shield Platform Encryption för mer information.

Plattformshändelser är inte optimala för att integrera data från en Salesforce-organisation till en annan eftersom de inte kan "lyssna" mellan organisationer för samma händelse. Egna Apex rekommenderas inte heller för denna typ av integrering.

Ett stort företag arbetar över flera affärsenheter (BUs). Varje BU har sin egen Salesforce-organisation. En enskild kund hanterar flera affärsenheter i företaget och har därmed konto- och säljprojektdata i flera organisationer. Företaget måste få åtkomst till en aggregerad vy över alla konto- och säljprojektdata i alla BUs i en enda organisation.

Obs! Alla lösningar nedan är utformade för minsta möjliga datareplikering, i enlighet med Takeaway #1.

Data 360 Konto- och säljprojektdata från olika Salesforce-organisationer kan tas in i Data 360 med hjälp av färdiga Salesforce-anslutare. De kan även aggregeras och harmoniseras (om det behövs). När data har aggregerats i Data 360 kan de kommas åt i andra Salesforce-organisationer med hjälp av Data Cloud One utan datareplikering.

Heroku Connect För varje enskild BU-organisation kan du använda Heroku Connect för att synkronisera ändringar från Salesforce till en enda Heroku Postgres-databas. I detta scenario är dubbelriktad synkronisering inte aktiverad, endast synkronisering från Salesforce till Postgres. I Heroku Connect kan du sedan aktivera Odata och välja de tabeller du vill visa som externa objekt i den Salesforce-organisation där du vill ha en aggregerad vy. Från Salesforce definierar du en extern datakälla som pekar till OData leverantör i Heroku.

MuleSoft Anypoint MuleSoft Anypoint tillhandahåller API-hantering i företagsklass. En MuleSoft Anypoint API kan konfigureras så att den läser information från flera relaterade Salesforce-organisationer med hjälp av Salesforce-anslutaren med flera anslutningar till organisationerna. MuleSoft-flödet kan fråga de olika Salesforce-organisationerna och returnera en specifik struktur som utökas eller berikas med annan information från tredje part om det behövs. När API åberopas kommer det att göra alla korrekta Salesforce-organisationsanrop (i detta exempel fråga Konto- och Säljprojektinformation) så att data kan bearbetas av konsumenten (troligen ett användargränssnitt). Autentisering mot dessa system kan göras genom en mängd olika autentiseringsmekanismer, inklusive grundläggande autentisering och OAuth. Det finns inga begränsningar för transaktionsvolymen, så länge som flödet har rätt storlek för sin toppanvändning (mätt i vCores eller Cores).

Inbyggda Salesforce API:n Frågeoperationer kan utfärdas till var och en av de organisationer som är av intresse, särskilt via Salesforce Bulk API 2.0, som är väl lämpad för att effektivt extrahera tusentals poster. Du kan hämta sökfrågeresultaten från varje organisation individuellt och aggregera dem med ett eget program eller mellanprogramvara per kundkrav.

Salesforce Connect med korsorganisationsadapter Korsorganisationsadaptern Salesforce Connect passar inte så bra i detta scenario, eftersom Konton eller Säljprojekt från fjärrorganisationer alla visas i den centrala organisationen som olika objekt. Det finns till exempel inget sätt att summera en totalsumma för Belopp för alla säljprojekt i alla organisationer.

Scenario för korsorganisation med selektiva uppdateringar: En säljare som använder Salesforce-organisation A behöver visa och uppdatera kundcasedata från Salesforce-organisation B och lägga till kundcasekommentarer i det överordnade kundcaset i Salesforce-organisation B medan de arbetar i organisation A. Data får inte replikeras till organisation A.

Heroku Connect Du kan använda samma metod som beskrivs i Dataaggregeringsscenariot ovan. Du måste dock aktivera CRUD för det externa objektet via Odata och skriva tillbaka ändringarna till Heroku Postgres.

MuleSoft Anypoint MuleSoft Anypoint tillhandahåller API-hantering i företagsklass. Du kan använda samma metod som beskrivs i Dataaggregeringsscenariot ovan.

Inbyggda Salesforce API:n använder autentiseringsuppgifter och åberopar inbyggda Salesforce API:n för att läsa och uppdatera data i den relaterade Salesforce-organisationen. En komponent måste vara utformad för att visa data.

Salesforce Connect med korsorganisationsadapter Möjligheten att visa data i ett externt objekt (samt redigera data om du har aktiverat CRUD för det externa objektet) stöds genom korsorganisationsadaptern Salesforce. Relationer stöds även mellan externa objekt så att du kan länka till det överordnade kundcaset i det externa objektet. Att skapa relationer är dock en manuell process idag där du konverterar en befintlig datatyp till en relationsdatatyp. Optimeringar som görs inom Service Cloud för att arbeta med kundcase mer effektivt kaskadkopplas inte till fjärrorganisationen. Salesforce rekommenderar starkt att testa korsorganisationsadaptern och utvärdera kompromisserna i att arbeta med externa objekt vs standardobjekt för ditt användningsfall.

Korsorganisation för datasynkronisering: När ett konto för en kund uppdateras i en av organisationens affärsenhets Salesforce-organisationer måste de andra Salesforce-organisationens kontoobjekt uppdateras för att hålla enhetlig kontoinformation.

Data 360 Data 360 kan användas för datareplikering från en organisation till en annan Salesforce-organisation. Kontodata från en Salesforce-organisation kan tas in i Data 360 med hjälp av färdiga Salesforce-anslutare. Vi kan även använda dataaktiveringsmekanismer som batchaktivering, dataåtgärder nästan i realtid eller API-baserade aktiveringar för att flytta data från Data 360 till Salesforce-org.

Heroku Connect Du kan använda samma metod som beskrivs i Dataaggregeringsscenariot ovan. Du måste dock aktivera dubbelriktad synkronisering och du behöver inte längre aktivera Salesforce Connect eftersom dubbelriktad synkronisering håller alla organisationer uppdaterade när ändringar görs i Postgres-tabellen.

MuleSoft Anypoint MuleSoft Anypoint tillhandahåller API-hantering i företagsklass. Du kan konfigurera ett Mule-program med Flow Designer i MuleSoft Anypoint för att lyssna efter standardobjekthändelser och egna objekthändelser för att starta ett autostartat flöde i Salesforce. När Mule-programmet utlöses kan det åberopa Anypoint-anslutaren för Salesforce för att kommunicera med valfritt antal Salesforce-organisationer. I detta användningsfall, när en kontopost uppdateras i en Salesforce-organisation, kan Mule-appen uppdatera kontoposter i de relaterade Salesforce-organisationerna. Varje relaterad Salesforce-organisation skulle ha ett unikt uppdateringssteg inbyggt i det övergripande programflödet i MuleSoft. Autentisering mot dessa system kan göras genom olika autentiseringsmekanismer, inklusive grundläggande autentisering och OAuth. Det finns inga begränsningar för transaktionsvolymen så länge som flödet har rätt storlek för sin toppanvändning (mätt i vCores eller Cores).

Inbyggda Salesforce API:n Replication API (getUpdated, getDeleted operations) kan användas för att synkronisera data mellan organisationer, men detta tillvägagångssätt rekommenderas inte.

Salesforce Connect med korsorganisationsadapter Du kan använda postutlösta flöden och externa objekt för att synkronisera vissa data mellan Salesforce-organisationer. Till exempel utlöser uppdatering av en kontopost i organisation A ett flöde som sedan uppdaterar den matchande posten i det externa objektet Konto, som skriver dessa uppdateringar av kontoposten i organisation B. Detta kräver korrekt användning av flödessemantik för att undvika blandade DML-transaktioner. Kom även ihåg att valideringsregler och flöden i organisation B kommer att utlösas på samma sätt som när ändringar görs av våra REST/SOAP API.

Tänk på denna guide och referera till den när du planerar en ny dataintegrering som involverar Salesforce. Det är alltid en bra idé att förstå hela omfattningen av alternativ som är tillgängliga för dig, och hur de kan passa med ditt specifika användningsfall.

Hjälp oss se till att vi publicerar det som är mest relevant för dig. Ta vår undersökning för att ge feedback om detta innehåll och berätta för oss vad du vill se härnäst.