Översikt av integreringsmönster

När du implementerar Salesforce behöver du vanligtvis integrera det med andra program. Även om varje integreringsscenario är unikt finns det vanliga krav och problem som utvecklare och arkitekter måste lösa.

Detta dokument beskriver strategier (i form av mönster) för dessa vanliga integreringsscenarion. Varje mönster beskriver designen och tillvägagångssättet för ett visst scenario istället för att beskriva en specifik implementering. I detta dokument hittar du:

Ett antal mönster som hanterar viktiga integreringsscenarion för "arketyper"
En urvalsmatris för att hjälpa till att avgöra vilket mönster som passar ditt scenario bäst
Integreringstips och rekommenderade metoder

Syfte och omfattning

Detta dokument är till för designers och arkitekter som behöver integrera Salesforce Platform med andra program i sin verksamhet. Vi har använt detta innehåll från många framgångsrika implementeringar.

För att bekanta dig med integreringsmöjligheter och alternativ som är tillgängliga för storskalig användning av Salesforce-baserade program, läs Guide för mönstersammanfattning och mönsterval. Arkitekter och utvecklare bör tillämpa dessa mönsterdetaljer och rekommenderade metoder under design- och implementeringsfasen av ett Salesforce-integreringsprojekt.

Om de implementeras korrekt låter dessa mönster dig komma till produktion så snabbt som möjligt och ha den mest stabila, skalbara och underhållsfria uppsättningen applikationer som möjligt. Salesforces egna konsultarkitekter använder dessa mönster som referenspunkter under arkitektgranskningar och underhåller och förbättrar dem aktivt.

Som med alla mönster täcker detta innehåll de flesta integreringsscenarion, men inte alla. Salesforce tillåter integrering av användargränssnitt (UI), till exempel mashups, men sådan integrering ligger utanför detta dokuments omfattning.

Mönstermall

Varje integreringsmönster följer en enhetlig struktur. Denna struktur gör det enklare att jämföra mönster och hitta relevant information.

Namn

Mönsteridentifieraren som även indikerar vilken typ av integrering som finns i mönstret.

Sammanhang

Det övergripande integreringsscenario som mönstret hanterar. Sammanhang ger information om vad användare försöker åstadkomma och hur programmet kommer att bete sig för att stödja kraven.

Problem

Det scenario eller problem (uttryckt som en fråga) som mönstret är utformat för att lösa. När du granskar mönstren, läs denna sektion för att snabbt förstå om mönstret är lämpligt för ditt integreringsscenario.

Krafter

De begränsningar och omständigheter som gör det angivna scenariot svårt att lösa.

Lösning

Det rekommenderade sättet att lösa integreringsscenariot.

Skiss

Ett UML-sekvensdiagram som visar dig hur lösningen hanterar scenariot.

Resultat

Förklarar detaljerna om hur du tillämpar lösningen på ditt integreringsscenario och hur den löser de krafter som är associerade med det scenariot. Denna sektion innehåller även nya utmaningar som kan uppstå som ett resultat av att tillämpa mönstret.

Sidofält

Ytterligare sektioner relaterade till mönstret som innehåller viktiga tekniska problem, variationer av mönstret, mönsterspecifika problem och så vidare.

Exempel

Ett heltäckande scenario som beskriver hur designmönstret används i ett verkligt Salesforce-scenario. Exemplet förklarar integreringsmålen och hur man implementerar mönstret för att uppnå dessa mål.

Mönstersammanfattning

Följande tabell listar de integreringsmönster som finns i detta dokument.

Lista över mönster

Mönster	Scenario
Åberopning av fjärrprocess—Begäran och svar	Salesforce åberopar en process i ett fjärrsystem, väntar på att processen slutförs och följer sedan status baserat på svaret från fjärrsystemet.
Åberopning av fjärrprocess—Brinn och glöm	Salesforce åberopar en process i ett fjärrsystem men väntar inte på att processen slutförs. Istället tar fjärrprocessen emot och bekräftar begäran och lämnar sedan tillbaka kontrollen till Salesforce.
Batchdatasynkronisering	Data som lagras i Salesforce Platform skapas eller uppdateras för att återspegla uppdateringar från ett externt system, och när ändringar från Salesforce Platform skickas till ett externt system. Uppdateringar i någon riktning görs i en batch.
Fjärranrop	Data som lagras i Salesforce Platform skapas, hämtas, uppdateras eller tas bort av ett fjärrsystem.
Uppdatering av användargränssnitt baserat på dataändringar	Salesforces användargränssnitt måste uppdateras automatiskt till följd av ändringar av Salesforce-data.
Datavirtualisering	Salesforce får åtkomst till externa data i realtid. Detta tar bort behovet av att behålla data i Salesforce och sedan stämma av data mellan Salesforce och det externa systemet.

Mönstermetod

Integreringsmönstren i detta dokument klassificeras i tre kategorier:

Dataintegrering: Dessa mönster uppfyller kravet på att synkronisera data som finns i två eller flera system så att båda systemen alltid innehåller relevanta och meningsfulla data. Dataintegrering är ofta den enklaste typen av integrering att implementera, men kräver rätt informationshanteringstekniker för att göra lösningen hållbar och kostnadseffektiv. Sådana tekniker inkluderar ofta aspekter av huvuddatahantering (MDM), datastyrning, mastering, avduplicering, dataflödesdesign och andra.
Processintegrering: Mönstren i denna kategori uppfyller behovet av en verksamhetsprocess för att använda två eller flera program för att utföra sin uppgift. När du implementerar en lösning för denna typ av integrering måste det utlösande programmet anropa över processgränser till andra program. Vanligtvis inkluderar dessa mönster även både orkestrering (där en applikation är den centrala "controllern") och koreografi (där applikationer är flera deltagare och det inte finns någon central "controller"). Dessa integreringar kräver ofta komplex design, tester och undantagshantering. Sådana sammansatta program är vanligtvis mer krävande på de underliggande systemen eftersom de ofta har stöd för transaktioner som körs länge och möjligheten att rapportera om eller hantera processstatus.
Virtuell integrering: Mönstren i denna kategori hanterar behovet för en användare att visa, söka och ändra data som lagras i ett externt system. När du implementerar en lösning för denna typ av integrering måste det utlösande programmet anropa andra program och interagera med deras data i realtid. Denna typ av integrering tar bort behovet av datareplikering mellan system och innebär att användare alltid interagerar med de senaste data.

Att välja den bästa integreringsstrategin för ditt system är inte trivialt. Det finns många aspekter att tänka på och många verktyg som kan användas, där vissa verktyg är mer lämpliga än andra för vissa uppgifter. Varje mönster hanterar specifika kritiska områden, inklusive kapaciteten för vart och ett av systemen, datavolym, felhantering och transaktionalitet.

Guide för mönsterval

Urvalsmatristabellerna listar mönstren och deras nyckelaspekter för att hjälpa dig avgöra vilket mönster som passar dina integreringskrav bäst. Mönstren kategoriseras med hjälp av dessa dimensioner.

Aspekt	Beskrivning
Typ	Anger integreringsstilen: Process, Data eller Virtuell. Process: Processbaserade integreringar är sätt att integrera bearbetningen av funktionella flöden mellan två eller flera program. Dessa integreringar involverar vanligtvis en högre nivå av abstraktion och komplexitet, särskilt för transaktionalitet och rollback. Data: Dataintegreringar är integreringen av den information som används av program. Dessa integreringar kan vara allt från en enkel tabellinfogning eller -uppsättning till komplexa datauppdateringar som kräver referensintegritet och komplexa översättningar. Virtuell: Virtuella integreringar är där Salesforce interagerar med data som finns i ett externt system utan att behöva replikera de data som finns i Salesforce. Denna typ av integrering utlöses alltid via en händelse från Salesforce Platform, till exempel en användaråtgärd, sökning eller postuppdatering, vilket resulterar i dataintegrering med en extern källa i realtid.
Timing	Anger integreringsstilen baserat på timing: Synkron eller asynkron. Synkron: Blockerings- och realtidsbegäranden är begäran-/svarsåtgärder. Resultatet returneras till uppringaren omedelbart via denna operation. Asynkron: Icke-blockerande, kö- eller meddelandebaserade begäranden åberopas av en enkelriktad operation som sker nästan i realtid. Resultaten och eventuella fel returneras genom att åberopa andra envägsoperationer. Samtalet gör därför begäran och fortsätter utan att vänta på ett svar.

Aspekt

Beskrivning

Typ

Anger integreringsstilen: Process, Data eller Virtuell.

Process: Processbaserade integreringar är sätt att integrera bearbetningen av funktionella flöden mellan två eller flera program. Dessa integreringar involverar vanligtvis en högre nivå av abstraktion och komplexitet, särskilt för transaktionalitet och rollback.

Data: Dataintegreringar är integreringen av den information som används av program. Dessa integreringar kan vara allt från en enkel tabellinfogning eller -uppsättning till komplexa datauppdateringar som kräver referensintegritet och komplexa översättningar.

Virtuell: Virtuella integreringar är där Salesforce interagerar med data som finns i ett externt system utan att behöva replikera de data som finns i Salesforce. Denna typ av integrering utlöses alltid via en händelse från Salesforce Platform, till exempel en användaråtgärd, sökning eller postuppdatering, vilket resulterar i dataintegrering med en extern källa i realtid.

Timing

Anger integreringsstilen baserat på timing: Synkron eller asynkron.

Synkron: Blockerings- och realtidsbegäranden är begäran-/svarsåtgärder. Resultatet returneras till uppringaren omedelbart via denna operation.

Asynkron: Icke-blockerande, kö- eller meddelandebaserade begäranden åberopas av en enkelriktad operation som sker nästan i realtid. Resultaten och eventuella fel returneras genom att åberopa andra envägsoperationer. Samtalet gör därför begäran och fortsätter utan att vänta på ett svar.

Integrera Salesforce med ett annat system

Denna tabell listar mönstren och deras nyckelaspekter för att hjälpa dig avgöra vilket mönster som passar dina krav bäst när din integrering är från Salesforce till ett annat system.

Typ	Timing	Nyckelmönster att tänka på
Processintegrering	Synkron	Åberopning av fjärrprocess—Begäran och svar
Processintegrering	Asynchronous	Åberopning av fjärrprocess—Brinn och glöm
Dataintegrering	Synkron	Åberopning av fjärrprocess—Begäran och svar
Dataintegrering	Asynchronous	Uppdatering av användargränssnitt baserat på dataändringar
Virtuell integrering	Synkron	Datavirtualisering

Integrera ett annat system med Salesforce

Denna tabell listar mönstren och deras nyckelaspekter för att hjälpa dig avgöra vilket mönster som passar dina krav bäst när din integrering är från ett annat system till Salesforce.

Typ	Timing	Nyckelmönster att tänka på
Processintegrering	Synkron	Fjärranrop
Processintegrering	Asynchronous	Fjärranrop
Dataintegrering	Synkron	Fjärranrop
Dataintegrering	Asynchronous	Batchdatasynkronisering

Termer och definitioner för programvara

Denna tabell listar några nyckeltermer relaterade till middleware och deras definitioner med avseende på dessa mönster.

Term	Definition
Händelsehantering	Händelsehantering är mottagandet av en identifierbar förekomst hos en utsedd mottagare (”hanterare”). De viktigaste processerna i händelsehantering inkluderar: Identifiera var en händelse ska vidarebefordras Utföra denna vidarebefordringsåtgärd Ta emot en vidarebefordrad händelse Utföra någon form av lämplig åtgärd som svar, till exempel skriva till en logg, skicka ett fel eller en återställningsprocess, eller skicka ett extra meddelande Kom ihåg att händelsehanteraren i slutändan kan vidarebefordra händelsen till en händelsekonsument. Vanliga användningar av denna funktion med middleware kan utökas till att inkludera den populära funktionen “publicera/prenumerera” eller “pub/sub”. I ett scenario för publicering/prenumeration dirigerar middleware begäranden eller meddelanden till aktiva prenumeranter på datahändelser från aktiva utgivare av datahändelser. Dessa konsumenter med aktiva lyssnare kan sedan hämta händelserna medan de publiceras. I Salesforce-integreringar som använder mellanprogramvara tar mellanvarulagret kontroll över händelsehanteringen. Den samlar in alla relevanta händelser, synkrona eller asynkrona, och hanterar distribution till alla slutpunkter, inklusive Salesforce. Alternativt kan denna kapacitet uppnås med Salesforce-händelsebussen med plattformshändelser.
Protokollkonvertering	Protokollkonvertering är vanligtvis ett program som konverterar standardprotokollet eller proprietärt protokoll för en enhet till protokollet som är lämpligt för en annan enhet för att uppnå interoperabilitet. I mellanprogramsammanhang kan anslutningen till ett visst målsystem begränsas av protokoll. I sådana fall måste meddelandeformatet konverteras till eller kapslas in i målsystemets format, där nyttolasten kan extraheras. Detta kallas även tunneldrivning. Salesforce har inte stöd för konvertering av inbyggda protokoll, så det antas att sådana krav uppfylls av middleware-lagret eller slutpunkten.
Översättning och transformation	Transformation är möjligheten att mappa ett dataformat till ett annat för att säkerställa interoperabilitet mellan de olika system som integreras. Vanligtvis innefattar processen att formatera om meddelanden på väg för att uppfylla kraven för avsändaren eller mottagaren. I mer komplexa fall kan ett program skicka ett meddelande i sitt eget ursprungliga format och två eller flera andra program kan ta emot en kopia av meddelandet i sitt eget ursprungliga format. Verktyg för översättning och transformation av mellanprogramvara inkluderar ofta möjligheten att skapa servicefasader för äldre eller andra icke-standardslutpunkter. Dessa servicefasader låter dessa slutpunkter verka vara serviceadresserbara. Med Salesforce-integreringar antas att sådana krav uppfylls av mellanlager eller slutpunkt. Mellanprogramvara föredras fortfarande för komplexa transformationer, men Salesforce Platform har mognat. OmniStudio-integreringsprocesser, flödesdatamappning och Apex med moderna mönster fungerar alla för moderata transformationer.
Köer och buffring	Köer och buffring förlitar sig i allmänhet på asynkrona meddelanden som skickas, till skillnad från en begäran-svar-arkitektur. I asynkrona system ger meddelandeköer tillfällig lagring när destinationsprogrammet är upptaget eller anslutningen är nedsatt. Dessutom tillhandahåller de flesta asynkrona mellanprogramsystem beständig lagring för att säkerhetskopiera meddelandekön. Den största fördelen med en asynkron meddelandeprocess är att om mottagarprogrammet av någon anledning misslyckas kan avsändarna fortsätta vara opåverkade. De skickade meddelandena samlas bara i meddelandekön för senare bearbetning när mottagaren startar om. Salesforce tillhandahåller asynkron kapacitet i form av datainsamling/plattformshändelser med Pub/Sub API. För att tillhandahålla äkta meddelandeköer för andra integreringsscenarion, inklusive orkestrering, processkoreografi och tjänstekvalitet, krävs en mellanprogramlösning.
Synkrona transportprotokoll	Synkrona transportprotokoll refererar till protokoll som stöder aktiviteter där en "enskild tråd i uppringaren skickar begärandemeddelandet, blockerar för att vänta på svarsmeddelandet och sedan bearbetar svaret....Begärantråden som väntar på svaret antyder att det endast finns en utestående begäran eller att svarskanalen för denna begäran är privat för denna tråd".
Asynkrona transportprotokoll	Asynkrona transportprotokoll refererar till protokoll som stöder aktiviteter där "en tråd i anroparen skickar begärandemeddelandet och konfigurerar en callback för svaret. En separat tråd lyssnar efter svarsmeddelanden. När ett svarsmeddelande anländer åberopar svarstråden lämplig callback, vilket återställer uppringarens sammanhang och bearbetar svaret. Detta tillvägagångssätt möjliggör flera utestående begäranden att dela en enda svarstråd.”
Medlingsdirigering	Medlingsdirigering är specifikationen av ett komplext "flöde" av meddelanden från komponent till komponent. Till exempel är många middleware-baserade lösningar beroende av ett meddelandekösystem. Medan vissa implementeringar tillåter dirigeringslogik att tillhandahållas av själva meddelandelagret, är andra beroende av klientprogram för att tillhandahålla dirigeringsinformation eller tillåta en blandning av båda paradigmen. I sådana komplexa fall förenklar medling från mellanprogramvarans sida utveckling, integrering och validering. En medlare säkerställer att rätt budskap når rätt konsument.
Processkoreografi och serviceorkestrering	Processkoreografi och serviceorkestrering är varje form av "servicesammansättning" där valfritt antal slutpunkter och kapaciteter koordineras. Skillnaden mellan koreografi och serviceorkestrering är: Koreografi kan definieras som en asynkron metod som låter processer arbeta autonomt, vilket tar bort problem som orsakas av beroenden som är beteenden som härrör från en grupp av interagerande individuella enheter utan central auktoritet. Orkestrering kan definieras som ett synkront tillvägagångssätt som möjliggör utförandet av en sökfråga eller process genom att låta varje mikrotjänst implementera uppgifter tilldelade av orkestreraren, vilket är ett beteende som är ett resultat av att en central dirigent koordinerar beteendena hos individuella enheter som utför uppgifter oberoende av varandra. Dessutom visar en orkestrering det fullständiga beteendet för varje tjänst medan koreografin kombinerar beskrivningarna av gränssnittbeteendet för varje tjänst. Delar av koreografier för verksamhetsprocesser kan byggas i flödesorkestrering, Salesforce-flöden eller med Apex. Salesforce inbyggda flödesorkestrering tillhandahåller långa körprocesser i flera steg med bakgrundssteg, interaktiva steg och MuleSoft-steg. Dess inbyggda kapacitet kan orkestreras utan mellanprogramvara, med inbyggd fashantering och tilldelningsdirigering. Vi rekommenderar att implementera alla komplexa korssystemorkestreringar i middleware-lagret för att undvika Salesforces gränser för timeout och styrande, särskilt i lösningar som kräver sann transaktionshantering.
Transaktionalitet (kryptering, signering, pålitlig leverans, transaktionshantering)	Transaktionalitet kan definieras som möjligheten att stödja globala transaktioner som omfattar alla nödvändiga operationer mot varje resurs som behövs. Transaktionalitet innebär stöd för alla fyra syraegenskaper, atomicitet, enhetlighet, isolering, hållbarhet, där atomicitet garanterar allt eller inget resultat för arbetsenheten (transaktion). Salesforce är transaktionellt inom sig självt, men kan inte delta i distribuerade transaktioner eller transaktioner som inleds utanför Salesforce. Därför antas det att för lösningar som kräver komplexa transaktioner med flera system implementeras transaktionsfunktioner och associerade mekanismer för tillbakadragande/kompensation på mellanlager.
Dirigering	Dirigering kan definieras som att specificera det komplexa flödet av meddelanden från komponent till komponent. I moderna tjänstebaserade lösningar kan sådana meddelandeflöden baseras på ett antal kriterier, inklusive sidhuvud, innehållstyp, regel och prioritet. För Salesforce-integreringar antas dessa kriterier uppfyllas av mellanlager eller slutpunkt, men meddelandedirigering kan också kodas i Apex.
Extrahera, transformera och läs in	Extrahera, transformera och läs in (ETL) refererar till en process som involverar: Extrahera data från källsystemen. Denna process involverar vanligtvis data från flera källsystem, och både relationella och icke-relationella strukturer. Transformera data så att de passar operativa behov, vilket kan inkludera datakvalitetsnivåer. Transformationssteget tillämpar vanligtvis en serie regler eller funktioner för extraherade data från källan för att derivera data för inläsning i slutmålet. Läsa in data i målsystemet. Målsystemet kan variera mycket från databas, operativt datalager, datamarknad, datalager eller andra operativa system. Även om det inte är absolut nödvändigt ger de flesta mogna ETL-verktyg möjlighet till datainsamling. Denna kapacitet är där verktyget identifierar poster i källsystemet som har ändrats sedan den senaste extraheringen, vilket minskar mängden postbearbetning. Salesforce har även stöd för datainsamling, vilket är publicering av ändringshändelser som representerar ändringar av Salesforce-poster. Med datainsamling för ändringar får klienten eller det externa systemet ändringar nästan i realtid av Salesforce-poster. Med denna information kan klienten eller det externa systemet synkronisera motsvarande poster i ett externt datalager.
Lång pollning	Lång pollning, även kallad Cometprogrammering, emulerar en informationspush från en server till en klient. På liknande sätt som en vanlig omröstning ansluter klienten och begär information från servern. Istället för att skicka ett tomt svar om information inte är tillgänglig håller servern begäran och väntar tills information är tillgänglig (en händelse inträffar). Servern skickar sedan ett fullständigt svar till klienten. Klienten begär sedan omedelbart information. Klienten upprätthåller kontinuerligt en anslutning till servern, så den väntar alltid på att få ett svar. Om servern går ut ansluter klienten igen och börjar om. Salesforce Streaming API använder Bayeux-protokollet och CometD för långa pollningar. Bayeux är ett protokoll för att transportera asynkrona meddelanden, främst över HTTP. CometD är en skalbar HTTP-baserad händelsedirigeringsbuss som använder ett AJAX-pushteknikmönster som kallas Comet. Det implementerar Bayeux-protokollet. Denna mekanism är ett äldre sätt att integrera. Alla nya lösningar ska använda Pub/Sub API.

Utöver dessa integreringsverktyg tillhandahåller MuleSoft och Informatica grundpelarna för en modern, högpresterande integreringsstrategi. Båda finns i samma ekosystem, men de löser olika arkitektoniska utmaningar. Ledande företag distribuerar dessa plattformar tillsammans för att skapa ett omfattande ramverk för "Bättre tillsammans" som uppfyller alla data- och programbehov.

MuleSoft är Salesforces ledande integreringsplattform. Den låter organisationer ansluta program, data och enheter mellan miljöer på plats och i molnet. MuleSoft ger IT verktygen för att låsa upp data mellan system, utveckla skalbara ramverk för integrering och automatisering och skapa differentierade, anslutna upplevelser snabbt. Den kan även ansluta en kärnorganisation till en Anypoint-instans i en API-katalog för att göra MuleSoft API tillgängliga för åberopning i Apex, flöde och Agentforce som åtgärder. Anypoint Exchange har ett antal färdigbyggda Salesforce-anslutare.

Informatica är en ledande plattform för hantering och integrering av företagsdata. Den hjälper organisationer samla in, hantera, integrera och analysera data från olika källor. Den använder ETL-processer (extrahera, transformera, läs in) för att tillhandahålla de anslutna, pålitliga data som behövs för att driva moderna analyser och autonoma AI-agenter.

Sammanhang

Du använder Salesforce för att följa leads, hantera din pipeline, skapa säljprojekt och samla in orderdetaljer som konverterar leads till kunder. Salesforce-systemet innehåller eller bearbetar dock inte ordrar. När orderdetaljerna har samlats in i Salesforce skapas ordern i fjärrsystemet, som hanterar ordern till avslut.

När du implementerar detta mönster anropar Salesforce fjärrsystemet för att skapa ordern och väntar sedan på att slutföras. Om det lyckas svarar fjärrsystemet synkront med orderstatus och ordernummer. Som en del av samma transaktion uppdaterar Salesforce ordernumret och statusen internt. Ordernumret används som en främmande nyckel för efterföljande uppdateringar av fjärrsystemet.

Problem

När en händelse inträffar i Salesforce, hur inleder du en process i ett fjärrsystem, skickar den information som behövs till processen, får ett svar från fjärrsystemet och använder sedan dessa svarsdata för att göra uppdateringar i Salesforce?

Krafter

Tänk på följande krafter när du tillämpar lösningar baserade på detta mönster.

Kräver samtalet till fjärrsystemet att Salesforce väntar på ett svar innan det fortsätter bearbetas? Är anropet till fjärrsystemet ett synkront begäran-svar eller en asynkron begäran?
Om anropet till fjärrsystemet är synkront, måste Salesforce bearbeta svaret som en del av samma transaktion som det inledande anropet?
Är meddelandestorleken liten eller stor?
Är integreringen baserad på förekomsten av en specifik händelse, till exempel ett knapptryck i Salesforces användargränssnitt, eller DML-baserade händelser?
Kan fjärrslutpunkten svara på begäran med låg latens? Hur många användare är troliga att utföra denna transaktion under en period med hög belastning?

Lösning

Denna tabell innehåller lösningar på detta integreringsproblem.

Lösning	Anpassa	Kommentarer
Externa tjänster åberopar ett REST API-anrop	Bästa	Externa tjänster låter dig åberopa en extern värdtjänst på ett deklarativt sätt (ingen kod krävs). Denna funktion används bäst när följande villkor uppfylls: Den externa värdtjänsten är en RESTful-tjänst och definitionerna är tillgängliga i schemaformatet OpenAPI 2.0 eller OpenAPI 3.0 eller YAML. Begäran- och svarsdefinitionerna innehåller primitiva datatyper som boolesk, datetime, dubbel, heltal, sträng eller en matris av primitiva datatyper. Kapslade objekttyper och skicka parametrar som sidhuvuden inom HTTP-begäranden stöds. Obs! om den externt värda tjänsten är RESTful men OpenAPI-specifikationen inte är tillgänglig eller livskraftig, använd Autentiseringsuppgifter i Apex för att göra HTTP-anropet direkt. Apex kod kommer att behövas för att tolka resultaten. Transaktionen kan åberopas från ett flöde.
Salesforce Lightning—Lightning eller -sida inleder ett synkront Apex REST- eller SOAP-anrop. Om fjärrslutpunkten utgör en risk för svar med hög latens (se dokumentationen för de senaste gränserna här) rekommenderas ett asynkront anrop, även kallat fortsättning, för att undvika att uppnå synkrona Apex transaktionsreglerande gränser.	Bästa	Salesforce låter dig konsumera en WSDL och skapa en resulterande proxy Apex klass. Denna klass tillhandahåller den logik som behövs för att anropa fjärrtjänsten. Salesforce låter dig även åberopa HTTP-tjänster (REST) med standardmetoderna GET, POST, PUT och DELETE. En användarinitierad åtgärd på en Lightning anropar sedan en Apex för att utföra denna proxy-Apex för att utföra fjärranropet med autentiseringsuppgifter. Lightning kräver anpassning av Salesforce-programmet.
HTTP-anropsåtgärd i flöde	Bra	Denna lösning tillåter synkrona utgående REST-anrop deklarativt från Flöde utan Apex och utan den fullständiga registreringsprocessen för Externa tjänster. Det passar bra för deklarativ implementering om en fullständig OpenAPI-specifikation inte är tillgänglig.
En synkron utlösare som åberopas från Salesforce-dataändringar utför ett asynkront Apex SOAP- eller HTTP-anrop.	Suboptimal	Du kan använda Apex för att utföra automatisering baserat på postdataändringar. En Apex proxyklass kan köras som ett resultat av en DML-operation genom att använda en Apex utlösare. Alla samtal som görs inom utlösarsammanhanget måste dock utföras asynkront från den inledande händelsen. Därför rekommenderas inte denna lösning för detta integreringsproblem. Denna lösning är bättre lämpad för mönstret Fjärrprocessåberopning—Eld och Glömma.
Ett Apex batchjobb utför ett synkront Apex SOAP- eller HTTP-anrop.	Suboptimal	Du kan ringa samtal till ett fjärrsystem från ett batchjobb. Denna lösning tillåter batchfjärrprocesskörning och bearbetning av svaret från fjärrsystemet i Salesforce. En given sats har dock gränser för antalet samtal. Mer information finns i Governorgränser. En given batchkörning kan köra flera transaktionssammanhang (vanligtvis i intervaller om 200 poster). Styrande begränsningar återställs per transaktionssammanhang.

Skiss

Detta diagram illustrerar en synkron fjärrprocessåberopning med Apex anrop.

Salesforce anropar ett fjärrsystem

Salesforce anropar ett fjärrsystem med begäran och svar

I detta scenario:

En åtgärd inleds på Lightning (till exempel ett knappklick).
Webbläsaren (via en kontroll på klientsidan när det gäller en Lightning) utför en HTTP POST som i sin tur utför en åtgärd på motsvarande Apex.
Kontrollen åberopar det faktiska anropet till fjärrwebbtjänsten.
Svaret från fjärrsystemet returneras till Apex kontroller. Kontrollen bearbetar svaret, uppdaterar data i Salesforce efter behov och återger sidan.

Om det efterföljande läget måste spåras returnerar fjärrsystemet en unik identifierare som lagras i Salesforce-posten.

Resultat

Tillämpningen av lösningarna relaterade till detta mönster tillåter händelseinledda fjärrprocessåberopningar där Salesforce hanterar bearbetningen.

Anropsmekanismer

Anropsmekanismen beror på vilken lösning som valts för att implementera detta mönster.

Anropsmekanism	Beskrivning
Utökad extern tjänst inbäddad i ett flöde eller Lightning eller Apex kontroller	Används när fjärrprocessen utlöses som en del av en end-to-end-process som involverar användargränssnittet och resultatet måste visas eller uppdateras i en Salesforce-post. Till exempel skickas en kreditkortsbetalning till en extern betalningsgateway och betalningsresultaten returneras omedelbart och visas för användaren.
Apex utlösare	Används främst för åberopning av fjärrprocesser med Apex från DML-inledda händelser. Mer information om denna anropsmekanism finns i mönstret Fjärrprocessåberopning—Eld och Glömma.
Apex batchklasser	Används för åberopning av fjärrprocesser i batch. Mer information om denna anropsmekanism finns i mönstret Fjärrprocessåberopning—Eld och Glömma.

Felhantering och återställning

Det är viktigt att inkludera en strategi för felhantering och återställning som en del av den övergripande lösningen.

Felhantering: Om ett fel uppstår (undantag eller felkoder returneras till uppringaren) hanterar uppringaren felhantering. Till exempel ett felmeddelande som visas på slutanvändarens sida eller loggas till en tabell som kräver ytterligare åtgärder.
Återhämtning: Ändringar förpliktas inte till Salesforce förrän uppringaren får ett framgångsrikt svar. Till exempel uppdateras inte orderstatusen i databasen förrän ett svar som indikerar framgång tas emot. Om det behövs kan uppringaren försöka igen.

Att tänka på vad gäller Idempotent design

Idempotent kapacitet garanterar att upprepade åberopningar är säkra. Om idempotens inte implementeras kan upprepade åberopningar av samma meddelande ha olika resultat, vilket potentiellt kan resultera i problem med dataintegritet. Möjliga problem inkluderar skapandet av dubbletter av poster eller dubblettbearbetning av transaktioner.

Det är viktigt att säkerställa att fjärrproceduren som anropas är idempotent. Om samtalet görs av användargränssnittet, hantera oförmåga på integreringslagret, särskilt om det inte finns någon garanti för att Salesforce endast åberopar samtalet en gång.

Den mest typiska metoden för att bygga en idempotent mottagare är att spåra dubbletter baserat på unika meddelandeidentifierare som skickas av konsumenten. Apex webbtjänst eller REST-anrop måste anpassas för att skicka ett unikt meddelande-ID.

Utöver detta måste operationer som skapar poster i fjärrsystemet kontrollera om det finns dubbletter innan de infogas. Kontrollera genom att skicka ett unikt post-ID från Salesforce. Om posten finns i fjärrsystemet, uppdatera posten. I de flesta system kallas denna operation en infoga-operation.

Säkerhetsöverväganden

Alla anrop till ett fjärrsystem måste upprätthålla begärans konfidentialitet, integritet och tillgänglighet. Följande säkerhetsöverväganden är specifika för att använda Apex SOAP- och HTTP-anrop i detta mönster.

Envägs SSL är aktiverat som standard, men tvåvägs SSL stöds med både självsignerade och CA-signerade certifikat för att upprätthålla autentiseringen för både klienten och servern.
För att effektivisera din Apex kod och förenkla konfigurationen av autentiserade anrop, specificera en autentiseringsuppgift i anropets slutpunkt.
Överväg att använda OAuth 2.0 som autentiseringsmekanism för integrering med externa system.
Vid behov, överväg att använda enkelriktade hashvärden eller digitala signaturer med hjälp av Apex kryptoklassmetoder för att säkerställa begärans integritet.
Fjärrsystemet måste skyddas genom att implementera lämpliga brandväggsmekanismer. Se Att tänka på vad gäller säkerhet.
Salesforce har för närvarande inte stöd för WS-Security. Även om det inte skapar dessa komplexa WS-Security-sidhuvuden inbyggt eller automatiskt tillämpar dem från en inkommande WSDL kan du manuellt skapa och implementera dem genom att skapa egna Apex klasser för att hantera SOAP-sidhuvuden och säkerhetstokens för inkommande begäranden.

Sidofält

Inga.

Rättidighet

I detta mönster är aktualitet av stor betydelse. Vanligtvis:

Begäran åberopas vanligtvis från användargränssnittet, så processen får inte låta användaren vänta.
Salesforce har en konfigurerbar timeout på upp till 120 sekunder för samtal från Apex.
Fjärrprocessen utförs i tid för att slutföras inom Salesforces tidsgräns och inom användarens förväntningar.
Externa samtal är föremål för Apex synkrona styrande begränsningar för transaktioner, så se till att minska risken för instansiering av fler än 50 transaktioner som körs i mer än fem sekunder vardera. Utöver att säkerställa att den externa slutpunkten fungerar inkluderar alternativ för att minska risken för en timeout:
- Ställa in timeout för det externa anropet till fem sekunder.
- Använda en fortsättning i Lightning Components för att hantera långa transaktioner

Datavolymer

Detta mönster används främst för aktiviteter i realtid med liten volym på grund av de små värdena för timeout och den maximala storleken på begäran eller svaret för Apex anropslösning. Använd inte detta mönster i batchbearbetningsaktiviteter där databelastningen finns i meddelandet.

Stöd för slutpunktskapacitet och standarder

Kapaciteten och standardsupporten för slutpunkten beror på vilken lösning du väljer.

Lösning	Att tänka på vad gäller slutpunkter
Apex HTTP-anrop	Slutpunkten måste kunna ta emot HTTP-anrop. Salesforce måste ha åtkomst till slutpunkten över det offentliga Internet. För privat och säker kommunikation har Salesforce även stöd för Salesforce Private Connect via Hyperforce Platform. Se Salesforce Private Connect för mer information. Du kan använda Apex HTTP-anrop för att anropa REST-tjänster med standardmetoderna GET, POST, PUT, DELETE och PATCH. Använd Autentiseringsuppgifter för att definiera slutpunkten och den autentisering som behövs, och implementera inte din egen autentiseringsmekanism.
Apex SOAP-anrop	Slutpunkten måste kunna ta emot HTTP-anrop. Salesforce måste ha åtkomst till slutpunkten över det offentliga Internet. För privat och säker kommunikation har Salesforce även stöd för Salesforce Private Connect via Hyperforce Platform. Se Salesforce Private Connect för mer information. Denna lösning kräver att fjärrsystemet är kompatibelt med de standarder som stöds av Salesforce. De webbtjänststandarder som för närvarande stöds av Salesforce för Apex SOAP-anrop är: WSDL 1.1 SOAP 1.1 WSI-grundprofil 1.1

Lösning

Att tänka på vad gäller slutpunkter

Apex HTTP-anrop

Slutpunkten måste kunna ta emot HTTP-anrop. Salesforce måste ha åtkomst till slutpunkten över det offentliga Internet. För privat och säker kommunikation har Salesforce även stöd för Salesforce Private Connect via Hyperforce Platform. Se Salesforce Private Connect för mer information.

Du kan använda Apex HTTP-anrop för att anropa REST-tjänster med standardmetoderna GET, POST, PUT, DELETE och PATCH. Använd Autentiseringsuppgifter för att definiera slutpunkten och den autentisering som behövs, och implementera inte din egen autentiseringsmekanism.

Apex SOAP-anrop

Slutpunkten måste kunna ta emot HTTP-anrop. Salesforce måste ha åtkomst till slutpunkten över det offentliga Internet. För privat och säker kommunikation har Salesforce även stöd för Salesforce Private Connect via Hyperforce Platform. Se Salesforce Private Connect för mer information.

Denna lösning kräver att fjärrsystemet är kompatibelt med de standarder som stöds av Salesforce. De webbtjänststandarder som för närvarande stöds av Salesforce för Apex SOAP-anrop är:

WSDL 1.1
SOAP 1.1
WSI-grundprofil 1.1

Statsförvaltning

Vid integrering av system är nycklar viktiga för pågående lägesspårning. Det finns två alternativ.

Salesforce lagrar fjärrsystemets primära eller unika surrogatnyckel för fjärrposten.
Fjärrsystemet lagrar Salesforces unika post-ID eller någon annan unik ersättningsnyckel.

Det finns specifika överväganden för hantering av integreringsnycklar, beroende på vilket system som innehåller huvudposten, enligt följande tabell.

Huvud	Systembeskrivning
Salesforce	Fjärrsystemet lagrar antingen Salesforce RecordId eller någon annan unik surrogatnyckel från posten.
Fjärrsystem	Anropet till fjärrprocessen returnerar den unika nyckeln från programmet och Salesforce lagrar detta nyckelvärde i ett unikt postfält.

Komplexa integreringsscenarion

I vissa fall kan lösningen som föreskrivs i detta mönster kräva implementering av flera komplexa integreringsscenarion. Detta uppnås bäst genom att använda middleware eller låta Salesforce anropa en sammansatt tjänst. Dessa scenarion inkluderar:

Orkestrering av verksamhetsprocesser och regler som involverar komplex flödeslogik
Aggregering av samtal och deras resultat över samtal till flera system
Transformation av både inkommande och utgående meddelanden
Upprätthålla transaktionsintegritet över anrop till flera system

Governorgränser

Mer information om Apex gränser finns i Verkställighetsregler och gränser i Apex Developer Guide.

Middleware-kapacitet

Följande tabell lyfter fram de önskvärda egenskaperna för ett middleware-system som deltar i detta mönster.

Egenskap	Obligatorisk	Önskvärt	Ej obligatoriskt
Händelsehantering		X
Protokollkonvertering		X
Översättning och transformation		X
Köer och buffring		X
Synkrona transportprotokoll	X
Asynkrona transportprotokoll			X
Medlingsdirigering		X
Processkoreografi och serviceorkestrering		X
Transaktionalitet (kryptering, signering, pålitlig leverans, transaktionshantering)		X
Dirigering			X
Extrahera, transformera och läs in			X
Lång pollning			X
gRPC-stöd (för Pub/Sub API)			X

Exempel

Ett allmännyttigt företag använder Salesforce och har ett separat system som innehåller kunders faktureringsinformation. Som en del av orderprocessen måste nya faktureringskonton skapas i faktureringssystemet. Salesforce ska återspegla faktureringskontonumret i orderaktiveringsprocessen. Företaget har ett befintligt REST API som tillåter skapandet av ett faktureringskonto och returnerar faktureringskontonumret som ett svar.

Detta krav kan uppnås med följande tillvägagångssätt.

Salesforce använder HTTP API för faktureringskontot som en extern tjänst eller flödes-HTTP-anrop. Vi bör endast använda en Apex proxyklass för användning av SOAP-tjänster om faktureringssystemet endast tillhandahåller SOAP-baserade tjänster och inga HTTP API.
Kundinformation skickas till det externa HTTP API-objektet.
Den externa tjänsten eller HTTP-flödesanropet returnerar svaret från HTTP API som kan lagras i Salesforce-objekt.
Detta exempel visar att:
Kundstatusen följs med ett kontonummer som lagras i Salesforce-kontoobjektet.
Uppringaren bearbetar sedan svarsmeddelandet.

Sammanhang

Du använder Salesforce för att följa leads, hantera din pipeline, skapa säljprojekt och samla in orderdetaljer som konverterar leads till kunder. Som en del av orderhanteringsprocesserna måste dock ett faktureringskonto skapas i faktureringssystemet för ordern.

När du implementerar detta mönster anropar Salesforce fjärrsystemet för att skapa faktureringskontot, men väntar inte på att samtalet ska slutföras. Fjärrsystemet kan om du vill uppdatera Salesforce med det nya faktureringskontot som skapats i en separat transaktion.

Problem

När en händelse inträffar i Salesforce, hur inleder du en process i ett fjärrsystem och skickar den information som behövs till processen utan att behöva vänta på ett svar från fjärrsystemet?

Krafter

Tänk på följande krafter när du tillämpar lösningar baserade på detta mönster.

Kräver samtalet till fjärrsystemet att Salesforce väntar på ett svar innan det fortsätter bearbetas? Är anropet till fjärrsystemet synkront eller asynkront?
Om samtalet till fjärrsystemet är synkront, måste svaret bearbetas av Salesforce som en del av samma transaktion som samtalet?
Är meddelandestorleken liten?
Är integreringen baserad på förekomsten av en specifik händelse, till exempel ett knapptryck i Salesforces användargränssnitt, eller DML-baserade händelser?
Är garanterad meddelandeleverans från Salesforce till fjärrsystemet ett krav?
Kan fjärrsystemet delta i en integrering där Salesforce specificerar kontraktet? I vissa lösningsvarianter (till exempel utgående meddelanden) specificerar Salesforce ett kontrakt som fjärrsystemets slutpunkt implementerar.
Har slutpunkten eller Enterprise Service Bus (ESB) stöd för lång pollning?
Föredrar man deklarativa konfigurationsmetoder framför egen Apex utveckling? I detta fall föredras lösningar som plattformshändelser framför Apex anrop.

Lösning

Följande tabell innehåller lösningar på detta integreringsproblem.

Lösning	Anpassa	Kommentarer
Flödesdrivna plattformshändelser	Bästa	Skapa flöden deklarativt för att implementera plattformshändelser. Den rekommenderade lösningen är när fjärrprocessen åberopas från en infognings- eller uppdateringshändelse. Plattformshändelser är de händelsemeddelanden (eller notiser) som dina appar skickar och tar emot för att utföra ytterligare åtgärder. Plattformshändelser förenklar processen att kommunicera ändringar och svara på dem utan att skriva komplex logik. En eller flera prenumeranter kan lyssna på samma händelse och utföra åtgärder. Till exempel kan ett programvarusystem skicka händelser som innehåller information om bläckpatroner för skrivare. Prenumeranter kan prenumerera på händelserna för att bevaka bläcknivåer för skrivare och placera ordrar för att ersätta bläckpatroner med låga bläcknivåer. Externa appar kan lyssna på händelsemeddelanden med hjälp av Salesforce Pub/Sub API, som baseras på gRPC och HTTP/2. Salesforce har även stöd för plattformshändelseutlösta flöden, vilket effektivt tillåter att skapa en lyssnare med Flow Builder-gränssnittet. Denna typ av flöde startar automatiskt när ett specifikt meddelande för plattformshändelse publiceras i Salesforce Event Bus.
Pub/Sub API	Bästa	Pub/Sub API är det rekommenderade sättet för externa konsumenter att konsumera händelserna i händelsebussen. Den gRPC-baserade Pub/Sub API: Stöder både publicering och prenumeration på plattformshändelser från externa program Är tillgänglig med korrekt autentisering (OAuth-, JWT- eller sessionstokens)
Ändra datainsamling	Bästa	Ändra datainsamling (CDC) publicerar händelser för ändringar i Salesforce-poster som motsvarar åtgärder för att skapa, uppdatera, ta bort och ångra. Att aktivera datainsamling (CDC) i Salesforce är en rent deklarativ process som inte kräver någon Apex kod. Notiser skickas till händelsebussen som klienter kan prenumerera på med Pub/Sub API eller Apex utlösare. Händelsedrivna system effektiviserar kommunikationen mellan distribuerade företagssystem, ökar skalbarheten och levererar data i realtid. Till exempel, om orderinformation finns i både ditt ERP-system och Salesforce kan du strömma händelser för orderändringar från Salesforce till en integreringsapp. Appen synkroniserar sedan ändringarna i ERP-systemet.
Händelsestafett	Bästa (med AWS-integreringar)	Salesforce Event Relay tillhandahåller en serverlös integrering med låg kod och realtid för att strömma händelser i Salesforce Platform-händelser och datainsamling (CDC) direkt till Amazon EventBridge. Salesforce-händelsereläer skickar dessa händelser från Salesforce till Amazon Web Services (AWS), och uppnår ett händelseflöde från början till slut genom att skicka tillbaka händelser till Salesforce. Med Händelserelä kan vi strömma händelser till AWS inbyggt utan att skriva en integreringsapp.
Omnistudio-integreringsprocesser	Bra	Använd Omnistudio-integreringsprocesser för att deklarativt automatisera datainteraktioner mellan Salesforce och externa tredjepartsprogram. Integreringsprocedurer hanterar komplexa datatransformationer, API-anrop och händelsedriven automatisering, och de kan utföra flera åtgärder i ett enskilt serveranrop. Använd integreringsprocesser när ingen användarinteraktion krävs under körningen och du vill: Hämta, transformera och skicka data mellan Salesforce och externa system Avlastbearbetning till servern för att förbättra prestanda och skalbarhet Paketera flera operationer i en enskild servertransaktion Aktivera datacachning för ofta besökt information Se mer information om integreringsprocesser här.
Anpassningsdrivna plattformshändelser	Bra	Liknar flödesdrivna plattformshändelser, men händelserna skapas av Apex utlösare eller klasser. Du kan publicera och konsumera plattformshändelser med hjälp av Apex eller en API. Plattformshändelser integreras med Salesforce Platform via Apex utlösare. Utlösare är de händelsekonsumenter på Salesforce Platform som lyssnar på händelsemeddelanden. När en extern app använder API eller en inbyggd Salesforce-app använder Apex för att publicera händelsemeddelandet aktiveras en utlösare för händelsen. Utlösare kör åtgärderna som svar på händelsenotiserna.
Flödesdrivna utgående meddelanden	Suboptimal	Detta är ett äldre sätt att integrera och kan användas när fjärrprocessen åberopas från en infognings- eller uppdateringshändelse. Salesforce tillhandahåller denna flödesdrivna utgående meddelandekapacitet för att skicka SOAP-meddelanden till fjärrsystem som utlöses av en infognings- eller uppdateringsåtgärd i Salesforce. Dessa meddelanden skickas asynkront och är oberoende av Salesforces användargränssnitt. Det utgående meddelandet skickas till en specifik fjärrslutpunkt. Fjärrtjänsten måste kunna delta i en integrering där Salesforce tillhandahåller kontraktet. Om fjärrtjänsten inte svarar med en positiv bekräftelse försöker Salesforce skicka meddelandet och ger en form av garanterad leverans. Detta är ett äldre sätt att integrera. Alla nya lösningar ska använda Flöde med Pub/Sub API.
Egen Lightning som inleder ett asynkront Apex SOAP- eller HTTP-anrop	Suboptimal	Denna lösning används vanligtvis i scenarion baserade på användargränssnitt, men kräver anpassning. Dessutom måste lösningen hantera garanterad leverans av meddelandet i koden. Liknande lösning för fjärrprocessanrop – begäran och svar som specificerar att använda en Lightning-komponent, tillsammans med ett Apex-anrop med autentiseringsuppgifter. Skillnaden är att i detta mönster väntar inte Salesforce på att begäran ska slutföras innan de lämnar över kontrollen till användaren. Efter att meddelandet har tagits emot svarar fjärrsystemet och indikerar att meddelandet har tagits emot och bearbetar sedan meddelandet asynkront. Fjärrsystemet lämnar tillbaka kontrollen till Salesforce innan det börjar bearbeta meddelandet. Salesforce behöver därför inte vänta på att bearbetningen slutförs.
Apex utlöser asynkrona Apex SOAP- eller HTTP-anrop	Suboptimal	Du kan använda Apex för att utföra automatisering baserat på postdataändringar. En Apex proxyklass kan köras som ett resultat av en DML-operation genom att använda en Apex utlösare. Alla samtal som görs inom utlösarsammanhanget måste dock utföras asynkront.
Apex utlöser asynkrona Apex SOAP- eller HTTP-anrop	Suboptimal	Samtal till ett fjärrsystem kan utföras från ett batchjobb. Denna lösning tillåter körning av batchfjärrprocess och bearbetning av svaret från fjärrsystemet i Salesforce. Det finns dock gränser för antalet samtal för ett givet batchsammanhang. Mer information finns i Snabbreferens för Salesforce Developer-gränser och -allokeringar.

Skiss

Följande diagram illustrerar ett samtal från Salesforce till ett fjärrsystem där skapande eller uppdatering av åtgärder för en post utlöser samtalet.

Salesforce anropar ett fjärrsystem med eld och glömmer

Nedladdningsdiagram

I detta scenario:

Ett fjärrsystem prenumererar på plattformshändelsen.
En uppdatering eller infogning inträffar för en given uppsättning poster i Salesforce.
Ett Salesforce-flöde utlöses när en uppsättning villkor uppfylls.
Detta flöde skapar en plattformshändelse.
Fjärrlyssnaren tar emot händelsemeddelandet och placerar meddelandet i en lokal kö.
Köprogrammet vidarebefordrar meddelandet till fjärrprogrammet för bearbetning.

Om fjärrsystemet måste utföra åtgärder mot Salesforce kan du implementera en valfri callback-åtgärd.

Resultat

Tillämpningen av lösningarna relaterade till detta mönster tillåter:

Användargränssnittinledda fjärrprocessanrop där resultatet av transaktionen kan visas för slutanvändaren
DML-händelseinledda fjärrprocessanrop där resultatet av transaktionen kan bearbetas av anropsprocessen

Anropsmekanismer

Anropsmekanismen beror på vilken lösning som valts för att implementera detta mönster.

Anropsmekanism	Beskrivning
Flöde	Används av både processdrivna och anpassningsdrivna lösningar. Händelser utlöser Salesforce-processen, som sedan kan publicera en plattformshändelse för prenumeration via ett fjärrsystem.
Pub/Sub API	Pub/Sub API tillhandahåller ett enda gränssnitt för att publicera och prenumerera på plattformshändelser, inklusive händelser för händelseövervakning i realtid och händelser för datainsamling av ändringar. Baserat på gRPC och HTTP/2 publicerar och levererar Pub/Sub API effektivt binära händelsemeddelanden i Apache Avro-formatet.
Ändra datainsamling	Salesforce datainsamling publicerar ändringshändelser som representerar ändringar av Salesforce-poster. Ändringar inkluderar skapande av en ny post, uppdateringar av en befintlig post, borttagning av en post och återborttagning av en post.
Lightning komponent och Apex kontroller	Används för att åberopa en fjärrprocess asynkront med ett Apex.
Apex utlösare	Används för utlösardrivna plattformshändelser och åberopning av fjärrprocesser, med Apex från DML-inledda händelser.
Apex batchklasser	Används för åberopning av fjärrprocesser i batch-läge.

Felhantering och återställning

En strategi för felhantering och återställning måste betraktas som en del av den övergripande lösningen. Den bästa metoden beror på vilken lösning du väljer.

Lösning	Strategi för felhantering och återställning
Flöde	Felhantering — Under vissa förhållanden kan flöden misslyckas med att bearbetas fullständigt. Om en process eller flödesintervju misslyckas skickas ett detaljerat e-postmeddelande till den administratör som senast ändrade processen eller flödet. Ändra standardbeteendet genom att lägga till felvägar till alla element som kan misslyckas. Detta beteende bör utökas för att lägga in eget beteende som att skapa ett kundcase eller skriva fel till ett eget objekt som kan övervakas och spåras. Återställning — Återställning är mer komplext i detta scenario. En egen mekanism för återförsök måste skapas om kraven på servicekvalitet kräver det.
Apex anrop med autentiseringsuppgifter	Felhantering — Fjärrsystemet lämnar över åberopning av slutprocessen, så anropet hanterar endast undantag i den inledande åberopningen av fjärrtjänsten. Till exempel utlöses en timeouthändelse om ingen positiv bekräftelse tas emot från fjärranropet. Fjärrsystemet måste hantera efterföljande fel när den inledande åberopningen överlämnas för asynkron bearbetning. Återställning — Återställning är mer komplext i detta scenario. En egen mekanism för återförsök måste skapas om kraven på servicekvalitet kräver det.
Ändra datainsamling (CDC) / Plattformshändelser	Felhantering — Felhantering måste utföras av fjärrtjänsten eftersom händelsen effektivt skickas till fjärrsystemen för ytterligare bearbetning. Eftersom detta mönster är asynkront hanterar fjärrsystemet meddelandeköer, bearbetning och felhantering. Plattformshändelser behandlas inte heller inom databastransaktioner. Som ett resultat av detta kan inte publicerade plattformshändelser dras tillbaka inom en transaktion. Återställning — Eftersom detta mönster är asynkront måste fjärrsystemet inleda försök baserat på tjänstens krav på servicekvalitet. Repris-ID som är associerat med varje händelse är atomiskt och ökar med varje publicerad händelse. Detta ID kan användas för att spela upp strömmen från en specifik händelse (till exempel baserat på den senast insamlade händelsen). Plattformshändelsemeddelanden med hög volym lagras i 72 timmar (tre dagar). Du kan hämta tidigare händelsemeddelanden när du använder Pub/Sub APIs för att prenumerera på en kanal.

Att tänka på vad gäller Idempotent design

Plattformshändelser publiceras endast till bussen en gång. Det finns inget nytt försök på Salesforce-sidan. Det är upp till ESB att begära att händelserna spelas upp igen. I en repris förblir plattformshändelsens repris-ID samma och ESB kan försöka duplicera meddelanden baserat på repris-ID.

De impotenta designövervägandena i mönstret Åberopning av fjärrprocess—Begäran och Svar gäller även för detta mönster.

Säkerhetsöverväganden

Alla anrop till ett fjärrsystem måste upprätthålla begärans konfidentialitet, integritet och tillgänglighet. Olika säkerhetsöverväganden gäller beroende på vilken lösning du väljer.

Lösning	Att tänka på vad gäller säkerhet
Apex anrop med autentiseringsuppgifter	Ett anrop till ett fjärrsystem måste upprätthålla begärans konfidentialitet, integritet och tillgänglighet. Följande är säkerhetsöverväganden som är specifika för att använda Apex SOAP- och HTTP-anrop i detta mönster. Envägs SSL är aktiverat som standard, men tvåvägs SSL stöds med både självsignerade och CA-signerade certifikat för att upprätthålla autentiseringen för både klienten och servern. Salesforce har inte stöd för WS-Security när Apex proxyklass skapas. Vid behov, överväg att använda enkelriktade hashningar eller digitala signaturer med hjälp av Apex kryptoklassmetoder för att säkerställa begärans integritet. Fjärrsystemet måste skyddas genom att implementera lämpliga brandväggsmekanismer.
Ändra datainsamling (CDC) / Plattformshändelser	För plattformshändelser måste det prenumererande externa systemet kunna autentisera till Salesforce Streaming API. Plattformshändelser följer den befintliga säkerhetsmodell som konfigurerats i Salesforce-organisationen. För att prenumerera på en händelse behöver användaren läsåtkomst till händelseenheten. För att publicera en händelse behöver användaren behörigheten "Skapa" för händelseenheten.

Lösning

Att tänka på vad gäller säkerhet

Apex anrop med autentiseringsuppgifter

Ett anrop till ett fjärrsystem måste upprätthålla begärans konfidentialitet, integritet och tillgänglighet. Följande är säkerhetsöverväganden som är specifika för att använda Apex SOAP- och HTTP-anrop i detta mönster.

Envägs SSL är aktiverat som standard, men tvåvägs SSL stöds med både självsignerade och CA-signerade certifikat för att upprätthålla autentiseringen för både klienten och servern.
Salesforce har inte stöd för WS-Security när Apex proxyklass skapas.
Vid behov, överväg att använda enkelriktade hashningar eller digitala signaturer med hjälp av Apex kryptoklassmetoder för att säkerställa begärans integritet.
Fjärrsystemet måste skyddas genom att implementera lämpliga brandväggsmekanismer.

Ändra datainsamling (CDC) / Plattformshändelser

För plattformshändelser måste det prenumererande externa systemet kunna autentisera till Salesforce Streaming API.

Plattformshändelser följer den befintliga säkerhetsmodell som konfigurerats i Salesforce-organisationen. För att prenumerera på en händelse behöver användaren läsåtkomst till händelseenheten. För att publicera en händelse behöver användaren behörigheten "Skapa" för händelseenheten.

Se Att tänka på vad gäller säkerhet.

Sidofält

Inga.

Rättidighet

Tidsaspekten är mindre av en faktor med eld-och-glöm-mönstret. Styrningen överlämnas till klienten antingen direkt eller efter positivt godkännande av en framgångsrik överlämning till fjärrsystemet. För plattformshändelser skickar Salesforce händelserna till händelsebussen och väntar inte på en bekräftelse eller ett godkännande från prenumeranten. Om prenumeranten inte hämtar meddelandet kan prenumeranten begära att händelsen spelas upp igen med hjälp av händelsesvarets ID. Händelsemeddelanden med hög volym lagras i 72 timmar (tre dagar). För att hämta tidigare händelsemeddelanden, använd Pub/Sub APIs för att prenumerera på en kanal.

Datavolymer

Att tänka på vad gäller datavolym beror på vilken lösning du väljer. Gränserna för varje lösning finns i Salesforce-gränssnabbreferens.

Stöd för slutpunktskapacitet och standarder

Kapaciteten och standardsupporten för slutpunkten beror på vilken lösning du väljer.

Lösning	Att tänka på vad gäller slutpunkter
Apex SOAP-anrop	Slutpunkten måste kunna bearbeta ett webbtjänstanrop via HTTP. Salesforce måste ha åtkomst till slutpunkten över det offentliga Internet. Denna lösning kräver att fjärrsystemet är kompatibelt med de standarder som stöds av Salesforce. När detta skrivs är webbtjänststandarderna som stöds av Salesforce för Apex SOAP-anrop: WSDL 1.1 SOAP 1.1 WSI-grundprofil 1.1 HTTP
Apex HTTP-anrop	Slutpunkten måste kunna ta emot HTTP-anrop och kunna kommas åt via det offentliga internet av Salesforce. Apex HTTP-anrop kan användas för att anropa RESTful-tjänster med standardmetoderna GET, POST, PUT och DELETE.
Ändra datainsamling (CDC) / Plattformshändelser	Utlösare och flöden kan prenumerera på händelser. Du kan få händelsenotiser oavsett hur de publicerades.

Statsförvaltning

Vid integrering av system är unika postidentifierare viktiga för pågående lägesspårning. Till exempel, om en post skapas i fjärrsystemet har du två alternativ.

Salesforce lagrar fjärrsystemets primära eller unika surrogatnyckel för fjärrposten.
Fjärrsystemet lagrar Salesforces unika post-ID eller någon annan unik ersättningsnyckel.

Följande tabell listar överväganden för delstatshantering i detta mönster.

Huvud	Systembeskrivning
Salesforce	Fjärrsystemet måste lagra antingen Salesforce RecordId eller någon annan unik surrogatnyckel i Salesforce-posten.
Fjärrsystem	Salesforce måste lagra en referens till den unika identifieraren i fjärrsystemet. Eftersom processen är asynkron kan lagring av denna unika identifierare inte vara en del av den ursprungliga transaktionen. Salesforce måste ange ett unikt ID i anropet till fjärrprocessen. Fjärrsystemet måste sedan anropa Salesforce för att uppdatera posten i Salesforce med fjärrsystemets unika identifierare, med hjälp av Salesforces unika ID. Callbacken innebär specifik lägeshantering i fjärrprogrammet för att lagra Salesforces unika identifierare för den transaktionen att använda för callbacken när bearbetningen är klar, eller så lagras Salesforces unika identifierare i fjärrsystemets post.

Huvud

Systembeskrivning

Salesforce

Fjärrsystemet måste lagra antingen Salesforce RecordId eller någon annan unik surrogatnyckel i Salesforce-posten.

Fjärrsystem

Salesforce måste lagra en referens till den unika identifieraren i fjärrsystemet. Eftersom processen är asynkron kan lagring av denna unika identifierare inte vara en del av den ursprungliga transaktionen.

Salesforce måste ange ett unikt ID i anropet till fjärrprocessen. Fjärrsystemet måste sedan anropa Salesforce för att uppdatera posten i Salesforce med fjärrsystemets unika identifierare, med hjälp av Salesforces unika ID.

Callbacken innebär specifik lägeshantering i fjärrprogrammet för att lagra Salesforces unika identifierare för den transaktionen att använda för callbacken när bearbetningen är klar, eller så lagras Salesforces unika identifierare i fjärrsystemets post.

Komplexa integreringsscenarion

Varje lösning i detta mönster har olika överväganden för komplexa integreringsscenarion som transformation och processorkestrering.

Lösning	Att tänka på
Apex anrop med autentiseringsuppgifter	I vissa fall kräver lösningar som föreskrivs i detta mönster att flera komplexa integreringsscenarion implementeras bäst med hjälp av mellanprogramvara eller att Salesforce anropar en sammansatt tjänst. Dessa scenarion inkluderar: Orkestrering av verksamhetsprocesser och regler som involverar komplex flödeslogik Aggregering av samtal och deras resultat över samtal till flera system Transformation av både inkommande och utgående meddelanden Upprätthålla transaktionsintegritet över anrop till flera system
Ändra datainsamling (CDC) / Plattformshändelser	Med tanke på att händelser är statiska, deklarativa kan inga komplexa integreringsscenarion, som aggregering, orkestrering eller transformation, utföras i Salesforce. Fjärrsystemet eller mellanprogramvaran måste hantera dessa typer av åtgärder.
OmniStudio-integreringsprocesser	Integreringsprocedurer (OmniStudio) tillhandahåller lägeslös orkestrering på serversidan för att koordinera flera backendtjänster medan du utför komplexa, deklarativa datatransformationer. Kedjesteg för integreringsprocesser som HTTP-åtgärder, DataRaptor-extrahering/transformering/inläsning, Ställ in värden, Loop/om och Matrissökningar för att normalisera, berika, aggregera och mappa belastningar mellan användargränssnittkontrakt och olika API. De har stöd för robusta körtidskontroller som villkorlig förgrening, paginering, timeout, försök, delvis misslyckad hantering och fortsatt fel, samt prestandaoptimeringar som cachning på serversidan och svarsutformning. IP-adresser kan åberopas synkront från OmniScripts, eller sidhuvudlöst via REST, vilket möjliggör återanvändbara, versionerade "integreringsfasader" som döljer backend-komplexitet från kanaler.

Governorgränser

På grund av Salesforce Platforms multitenantkaraktär finns det gränser för utgående anrop. Gränser beror på typen av utgående samtal och tidpunkten för samtalet.

För gränser och allokeringar som gäller för plattformshändelser, se Utvecklarguiden för plattformshändelser.

Pålitliga meddelanden

Pålitliga meddelanden försöker lösa problemet med att garantera leverans av ett meddelande till ett fjärrsystem där de enskilda komponenterna inte är tillförlitliga. Metoden för att säkerställa att ett meddelande tas emot av fjärrsystemet beror på vilken lösning du väljer.

Vid Salesforce ändringsdatainsamling tillhandahålls typer av ändringshändelser för att hantera speciella situationer, till exempel att samla in ändringar som inte fångas upp i Salesforces programservrar eller hantera stora mängder ändringar.

I vissa fall skickar Salesforce händelser med luckor istället för ändringshändelser för att informera prenumeranter om fel, eller om det inte går att skapa ändringshändelser. En mellanrumshändelse innehåller information om ändringen i sidhuvudet, till exempel ändringstyp och post-ID. Den innehåller inte detaljer om ändringen, till exempel postfält. För att samla in ändringar mer effektivt skapas spillhändelser för enskilda transaktioner som överskrider en tröskel. Mer information finns här.

Lösning	Att tänka på vad gäller pålitliga meddelanden
Apex anrop med autentiseringsuppgifter	Salesforce ger inte uttryckligt stöd för pålitliga meddelandeprotokoll (till exempel WS-ReliableMessaging). Vi rekommenderar att fjärrslutpunkten som tar emot Salesforce-meddelandet implementerar ett pålitligt meddelandesystem, som JMS eller MQ. Detta system säkerställer fullständig garanterad leverans från början till slut till det fjärrsystem som slutligen bearbetar meddelandet. Detta system säkerställer dock inte garanterad leverans från Salesforce till den fjärrslutpunkt som det anropar. Garanterad leverans måste hanteras genom anpassningar av Salesforce. Specifika tekniker, som att bearbeta ett positivt godkännande från fjärrslutpunkten utöver egen försökslogik, måste implementeras.
Ändra datainsamling (CDC) / Plattformshändelser	Plattformshändelser försöker tillhandahålla pålitliga meddelanden genom att tillfälligt behålla händelsemeddelanden i händelsebussen. Prenumeranter kan komma ikapp med missade händelsemeddelanden genom att spela upp meddelanden från händelsebussen igen med hjälp av Repris-ID för händelsemeddelanden. Händelsebussen är ett distribuerat system och har inte samma garantier som en transaktionsdatabas. Som ett resultat av detta kan Salesforce inte tillhandahålla ett synkront svar för en begäran om händelsepublicering. Händelser placeras i kö och buffras och Salesforce försöker publicera händelserna asynkront. I sällsynta fall kanske inte händelsemeddelandet kvarstår i det distribuerade systemet under de inledande eller efterföljande försöken. Detta innebär att händelserna inte levereras till prenumeranter och att de inte går att återställa.

Middleware-kapacitet

Följande tabell lyfter fram de önskvärda egenskaperna för ett middleware-system som deltar i detta mönster.

Egenskap	Obligatorisk	Önskvärt	Ej obligatoriskt
Händelsehantering		X
Protokollkonvertering		X
Översättning och transformation		X
Köer och buffring	X
Synkrona transportprotokoll			X
Asynkrona transportprotokoll	X
Medlingsdirigering		X
Processkoreografi och serviceorkestrering		X
Transaktionalitet (kryptering, signering, pålitlig leverans, transaktionshantering)	X
Dirigering			X
Extrahera, transformera och läs in			X
Lång pollning	X (krävs för Streaming API)
gRPC-stöd (för Pub/Sub API)	X

Lösningsvariant: Publiceringsbeteende och transaktioner för plattformshändelser

När meddelanden för plattformshändelser publiceras omedelbart respekterar inte händelsepublicering transaktionsgränserna för publiceringsprocessen. Händelsemeddelanden kan publiceras innan transaktionen slutförs eller även om en transaktion misslyckas. Detta beteende kan leda till problem när en prenumerant förväntar sig att hitta data som publiceringstransaktionen förbinder. Data kanske inte finns när prenumeranten får händelsemeddelandet. För att lösa detta problem, sätt publiceringsbeteendet för plattformshändelsen till Publicera efter åtagande i händelsedefinitionen. De publiceringsbeteenden du kan ange i en plattformshändelsedefinition är:

Publicera efter åtagande för att låta händelsemeddelandet publiceras endast efter att en transaktion har gjorts. Välj detta alternativ om prenumeranter förlitar sig på data som publiceringstransaktionen förbinder. Till exempel publicerar en process ett händelsemeddelande och skapar en uppgiftspost. En andra process som prenumererar på händelsen aktiveras och förväntar sig att hitta uppgiftsposten. En annan anledning till att välja detta beteende är om du inte vill att händelsemeddelandet ska publiceras om transaktionen misslyckas.
Publicera direkt för att låta händelsemeddelandet publiceras när publiceringsanropet körs. Välj detta alternativ om du vill att händelsemeddelandet ska publiceras oavsett om transaktionen lyckas eller inte. Välj även detta alternativ om utgivaren och prenumeranterna är oberoende och prenumeranter inte förlitar sig på data som utgivaren har åtagit sig. Till exempel är det omedelbara publiceringsbeteendet lämpligt för en händelse som används för loggning. Med detta alternativ kan en prenumerant få händelsemeddelandet innan data överlämnas av utgivartransaktionen.

Exempel

Ett telekommunikationsföretag vill använda Salesforce som frontend för att skapa konton med lead-till-säljprojekt-processen. En order skapas i Salesforce när säljprojektet avslutas och vinns, men backend-ERP-systemet är datahuvudet. Ordern måste sparas i Salesforces säljprojektpost och säljprojektstatusen måste ändras för att indikera att ordern skapades.

Följande begränsningar gäller.

Endast deklarativ utveckling kan implementeras.
Du behöver inte meddelas omedelbart om ordernumret efter att säljprojektet konverteras till en order.
Organisationen har kapacitet att stödja gRPC och HTTP2 så att Salesforce Pub/Sub API kan användas för att prenumerera på plattformshändelser.

Detta exempel implementeras bäst med Salesforce Platform-händelser, men kräver att ESB prenumererar på plattformshändelsen.

På Salesforce-sidan:

Skapa ett flöde för att inleda plattformshändelsen (till exempel om säljprojektstatusen ändras till Avslutat vunnet).
Skapa en ny plattformshändelse som publicerar säljprojektdetaljerna.

På fjärrsystemsidan:

Integreringsverktygen (till exempel ESB) prenumererar på Salesforce Platform-händelsen med Pub/Sub API.
ESB får en eller flera notiser som indikerar att säljprojektet ska konverteras till en order.
ESB vidarebefordrar meddelandet till backend-ERP-systemet så att ordern kan skapas.
När ordern har skapats i ERP-systemet anropar en separat tråd Salesforce med OAuth 2.0 med en ansluten app. Callbacken uppdaterar säljprojektet med ordernummer och status. Du kan göra denna callback med dokumenterade mönsterlösningar, som Salesforce Platform-händelser, Salesforce SOAP API, REST API eller en Apex webbtjänst.

Detta exempel visar följande.

Implementering av en fjärrprocess åberopad asynkront
Garantileverans från början till slut
Efterföljande callback till Salesforce för att uppdatera postens status

Sammanhang

Du flyttar din CRM-implementering till Salesforce och vill:

Extrahera och transformera konton, kontakter och säljprojekt från det aktuella CRM-systemet och läs in data i Salesforce (inledande dataimport).
Extrahera, transformera och läs in kundfaktureringsdata till Salesforce från ett fjärrsystem veckovis (pågående).
Extrahera information om kundaktivitet från Salesforce och importera den till ett datalager på plats veckovis (pågående).

Problem

Hur importerar du data till Salesforce och exporterar data från Salesforce, med tanke på att dessa importer och exporter kan påverka slutanvändarens verksamhet under arbetstid och involvera stora mängder data?

Krafter

Det finns olika krafter att tänka på vid tillämpning av lösningar baserade på detta mönster:

Ska data lagras i Salesforce? Annars finns det andra integreringsalternativ som en arkitekt kan och bör överväga (till exempel sammanslagningar).
Om data ska lagras i Salesforce, ska data uppdateras som svar på en händelse i fjärrsystemet?
Ska data uppdateras schemalagt?
Har data stöd för primära verksamhetsprocesser?
Finns det krav på analys (rapportering) som påverkas av tillgängligheten för dessa data i Salesforce?

Lösning

Följande tabell innehåller olika lösningar på detta integreringsproblem.

Lösning	Anpassa	Datahuvud	Kommentarer
Replikering via ETL-verktyg från tredje part	Bästa	Fjärrsystem	Om ett externt system behöver skicka stora mängder data till Salesforce använder du ett ETL-verktyg från tredje part som låter dig köra datainsamling av ändringar mot källdata. Verktyget reagerar på ändringar i källdatauppsättningen, transformerar datan och anropar sedan Salesforce Bulk API för att utfärda DML-uttryck. Detta kan även implementeras med Salesforce REST API:n om antalet poster är mindre.
Replikering via ETL-verktyg från tredje part	Bra	Salesforce	Använd ett ETL-verktyg från tredje part som låter dig köra datainsamling av ändringar mot ERP- och Salesforce-datauppsättningar. I denna lösning är Salesforce datakällan och du kan använda information om tid/status för enskilda rader för att fråga data och filtrera målresultatuppsättningen. Detta kan implementeras genom att använda mass-API 2.0 eller standard-REST API (om antalet poster är mindre).
Data 360 och Dataåtgärder och aktiveringar	Bästa	Data 360	Flytta data mellan organisationer med hjälp av Data 360-åtgärder och aktiveringar. När data har tagits in från olika organisationer i Data 360 kan å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.
Data 360, Datagrafer och Connect API	Bästa	Data 360	Extrahera och flytta data med MuleSoft Anypoint. MuleSoft En nypunkt 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.
Sammansatt graf-API	Bästa	Salesforce	Resursen för sammansatta diagram låter dig skicka in operationer för sammansatta diagram. Denna resurs är tillgänglig i REST API version 50.0 och senare. Sammansatt graf-API kan stödja upp till 75 grafer i en nyttolast och högst 500 noder i en graf.
Dataimportguiden och Data Loader	Anpassa	Salesforce / Externt system	Dataimportguiden och Data Loader kan användas för att importera, exportera 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. Inget av dessa verktyg är en rekommenderad bas för en dataintegreringsstrategi. De bör istället komplettera din strategi för dataförvaltning och underhåll. Mer information finns i Data Loader-dokumentationen.
Fjärranrop	Suboptimal	Fjärrsystem	Det är möjligt för ett fjärrsystem att anropa Salesforce genom att använda ett av API:na och utföra uppdateringar av data medan de inträffar. Detta orsakar dock betydande pågående trafik mellan de två systemen. Större vikt bör läggas vid felhantering och låsning. Detta mönster har potential att orsaka kontinuerliga uppdateringar, vilket har potential att påverka prestandan för slutanvändare.
Fjärranrop av process	Suboptimal	Salesforce	Det är möjligt för Salesforce att anropa ett fjärrsystem och utföra uppdateringar av data medan de inträffar. Detta orsakar dock betydande pågående trafik mellan de två systemen. Större vikt bör läggas vid felhantering och låsning. Detta mönster har potential att orsaka kontinuerliga uppdateringar, vilket har potential att påverka prestandan för slutanvändare.

Skiss

Följande diagram illustrerar händelseförloppet i detta mönster, där Salesforce är huvuddata.

Batcha datasynkronisering med Salesforce som huvuddata

Följande diagram illustrerar den efterföljande synkroniseringen av händelser nästan i realtid, där Salesforce är datahuvudet.

Datasynkronisering nära realtid

Resultat

Du kan integrera data som hämtas externt med Salesforce enligt följande scenarion:

Det externa systemet är huvuddata: Salesforce är en konsument av data som tillhandahålls av ett enskilt källsystem eller flera system. I detta scenario är det vanligt att ha ett datalager eller en datamarknad som aggregerar datan innan data importeras till Salesforce.
Salesforce är huvuddata: Salesforce är postsystemet för vissa enheter och Salesforces klientprogram för datainsamling kan informeras om ändringar av Salesforce-data.

I ett typiskt Salesforce-integreringsscenario gör implementeringsteamet något av följande:

Implementera datainsamling för ändringar i källdatauppsättningen.
Implementera en uppsättning stödjande databasstrukturer, så kallade kontrolltabeller, i en mellanliggande databas på plats.

ETL-verktyget skapar program som kommer att:

Läs en kontrolltabell för att avgöra den senaste körtiden för jobbet och extrahera andra kontrollvärden som behövs.
Använd ovanstående kontrollvärden som filter och fråga källdatauppsättningen.
Tillämpa fördefinierade bearbetningsregler, inklusive validering, berikning och så vidare.
Använd tillgängliga anslutare/transformationsmöjligheter för ETL-verktyget för att skapa destinationsdatauppsättningen.
Skriv datauppsättningen till Salesforce-objekt.
Om bearbetningen lyckas, uppdatera kontrollvärdena i kontrolltabellen.
Om bearbetning misslyckas, uppdatera kontrolltabellerna med värden som aktiverar en omstart och avslut.

Anteckning: Vi rekommenderar att du skapar kontrolltabeller och associerade datastrukturer i en miljö som ETL-verktyget har åtkomst till även om åtkomst till Salesforce inte är tillgänglig. Detta ger tillräcklig motståndskraft. Salesforce ska behandlas som en eker i denna process och ETL-infrastrukturen är navet.

För att ett ETL-verktyg ska få maximal nytta av datasynkroniseringsfunktioner, tänk på följande:

Kedja och sekvensera ETL-jobben för att ge en sammanhängande process.
Använd primära nycklar från båda systemen för att matcha inkommande data.
Använd specifika API-metoder för att extrahera endast uppdaterade data.
Om du importerar underordnade poster i en huvud-detalj-relation eller sökrelation, gruppera importerade data med dess överordnade nyckel vid källan för att undvika låsning. Om du till exempel importerar kontaktuppgifter, se till att gruppera kontaktuppgifterna efter den överordnade kontonyckeln så att det högsta antalet kontakter för ett enskilt konto kan läsas in i ett API-anrop. Att inte gruppera importerade data resulterar vanligtvis i att den första kontaktposten läses in och efterföljande kontaktposter för det kontot misslyckas i sammanhanget för API-anropet.
All bearbetning efter import, som utlösare, ska endast bearbeta data selektivt.
Om ditt scenario innefattar stora datavolymer, följ de rekommenderade metoderna från denna Trailhead modul Rekommenderade metoder för distribueringar med stora datavolymer

Felhantering och återställning

En strategi för felhantering och återställning måste betraktas som en del av den övergripande lösningen. Den bästa metoden beror på vilken lösning du väljer.

Felplats	Strategi för felhantering och återställning
Läs från Salesforce med hjälp av datainsamling för ändring	Felhantering—Felhantering måste utföras i fjärrtjänsten eftersom händelsen effektivt skickas till fjärrsystemet för ytterligare bearbetning. Eftersom detta mönster är asynkront hanterar fjärrsystemet meddelandeköer, bearbetning och felhantering. Dessutom bearbetas inte händelser för datainsamling i databastransaktioner. På grund av detta kan inte publicerade händelser dras tillbaka inom en transaktion. Återställning—Eftersom detta mönster är asynkront måste fjärrsystemet inleda försök baserat på tjänstens krav på servicekvalitet. Det repris-ID som är associerat med varje händelse för datainsamling är atomärt och ökar med varje händelse som publiceras. Detta ID kan användas för att spela upp strömmen från en specifik händelse (till exempel baserat på den senast insamlade händelsen). Plattformshändelsemeddelanden med hög volym lagras i 72 timmar (3 dagar). Du kan hämta tidigare händelsemeddelanden när du använder Pub/Sub API-klienter för att prenumerera på en kanal.
Läs från Salesforce med ett ETL-system från tredje part	Felhantering—Om ett fel uppstår under en läsoperation, genomför ett nytt försök för fel som inte är infrastrukturrelaterade. I händelse av upprepade fel bör standardbearbetning med hjälp av kontrolltabeller/feltabeller genomföras i samband med en ETL-operation för att Logga felet Försök med läsoperationen igen Avsluta om det inte går Skicka en notis Återställning— Starta om ETL-processen för att återställa från en misslyckad skrivoperation. Om operationen lyckas men det finns poster som misslyckats bör en omedelbar omstart eller efterföljande utförande av jobbet åtgärda problemet. I detta fall kan en försenad omstart vara en bättre lösning eftersom det ger tid att prioritera och korrigera data som kan orsaka felen.
Skriv till Salesforce	Felhantering—Fel som uppstår under en skrivoperation kan bero på en kombination av faktorer i programmet. API-anropen returnerar en resultatuppsättning som består av informationen som anges nedan. Denna information ska användas för att försöka skriva igen (om det behövs). Postidentifierande information Notis om lyckat/misslyckat resultat En samling fel för varje post Återställning—Starta om ETL-processen för att återställa från en misslyckad läsoperation. Om operationen lyckas men det finns poster som misslyckats bör en omedelbar omstart eller efterföljande utförande av jobbet åtgärda problemet. I detta fall kan en försenad omstart vara en bättre lösning eftersom det ger tid att prioritera och korrigera data som kan orsaka felen.
Externt huvudsystem	Fel ska hanteras i enlighet med huvudsystemets rekommenderade metoder.

Säkerhetsöverväganden

Alla anrop till ett fjärrsystem måste upprätthålla begärans konfidentialitet, integritet och tillgänglighet. Olika säkerhetsöverväganden gäller beroende på vilken lösning du väljer.

Godkänd API-åtkomst till Salesforce API kräver en Lightning Platform-licens med minst användarbehörigheter endast för API.
Vi rekommenderar att standardkryptering används för att hålla lösenordsåtkomst säker.
Använd HTTPS-protokollet när du gör anrop till Salesforce API. Du kan även proxytrafik till Salesforce API genom en säkerhetslösning på plats om det behövs.

Se Att tänka på vad gäller säkerhet.

Sidofält

Inga.

Rättidighet

Aktualitet är inte av någon större betydelse i detta mönster. Man måste dock se till att utforma gränssnitten så att alla batchprocesser slutförs i ett utsett batchfönster.

Precis som med alla batchorienterade operationer rekommenderar vi starkt att du isolerar käll- och målsystemen under batchbearbetningsfönster. Att läsa in satser under arbetstid kan resultera i vissa tvister, vilket antingen resulterar i att en användares uppdatering misslyckas, eller ännu viktigare, att en satsinläsning (eller delvis satsinläsning) misslyckas.

För organisationer som har global verksamhet kanske det inte är möjligt att köra alla batchprocesser samtidigt eftersom systemet kan fortsätta att användas. Datasegmenteringstekniker som använder posttyper och andra filtreringskriterier kan användas för att undvika datakonflikter i dessa fall.

Statsförvaltning

Du kan implementera delstatshantering genom att använda surrogatnycklar mellan de två systemen. Om du behöver någon typ av transaktionshantering i Salesforce-enheter rekommenderar vi att du använder mönstret Fjärranrop med Apex.

Standardoptimistisk låsning av poster inträffar på plattformen och alla uppdateringar som görs med API kräver att användaren, som redigerar posten, uppdaterar posten och inleder sin transaktion. I Salesforce API-sammanhang refererar optimistisk låsning till en process där:

Salesforce upprätthåller inte statusen för en post som redigeras av en specifik användare.
Vid läsning registreras den tidpunkt då data extraherades.
Om användaren uppdaterar posten och sparar den kontrollerar Salesforce om en annan användare har uppdaterat posten under tiden.
Om posten har uppdaterats meddelar systemet användaren att en uppdatering har gjorts och användaren bör hämta den senaste versionen av posten innan de fortsätter med sina uppdateringar.

Middleware-kapacitet

De mest effektiva externa teknikerna som används för att implementera detta mönster är traditionella ETL-verktyg som Informatica eller MuleSoft. Det är viktigt att de middleware-verktyg som väljs har stöd för Salesforce Bulk API.

Middleware ska kunna lagra den senaste framgångsrikt bearbetade tidsstämpeln antingen internt eller externt för vattenmärkning. Denna senast framgångsrikt bearbetade tidsstämpel ska användas för att konsumera ändringarna sedan den senaste framgångsrika körningen.

Följande tabell lyfter fram de önskvärda egenskaperna för ett middleware-system som deltar i detta mönster.

Egenskap	Obligatorisk	Önskvärt	Ej obligatoriskt
Händelsehantering		X
Protokollkonvertering		X
Översättning och transformation	X
Köer och buffring	X
Synkrona transportprotokoll	X
Asynkrona transportprotokoll			X
Medlingsdirigering		X
Processkoreografi och serviceorkestrering	X
Transaktionalitet (kryptering, signering, pålitlig leverans, transaktionshantering)		X
Dirigering		X
Extrahera, transformera och läs in	X
Lång pollning	X (krävs för datainsamling av Salesforce ändringsdata)
gRPC-stöd (för Pub/Sub API)	X

Exempel

Ett allmännyttigt företag använder en stordatorbaserad batchprocess som tilldelar prospekt till individuella säljare och team. Denna information måste importeras till Salesforce varje natt.

Kunden har beslutat att implementera datainsamling för ändringar i källtabellerna med ett kommersiellt tillgängligt ETL-verktyg. Lösningen fungerar enligt följande:

En cron-liknande schemaläggare utför ett batchjobb som tilldelar prospekt till användare och team.
Efter att batchjobbet körts och uppdaterat datan känner ETL-verktyget igen dessa ändringar med hjälp av datainsamling för ändringar. ETL-verktyget samlar ändringarna från datalagringen.
ETL-anslutaren använder Salesforce REST API för att läsa in ändringarna i Salesforce.

Sammanhang

Du använder Salesforce för att följa leads, hantera din pipeline, skapa säljprojekt och samla in orderdetaljer som konverterar leads till kunder. Salesforce-systemet skapar ordrarna internt och pushar sedan dessa data till det externa faktureringssystemet för provisionering och aktivering. Faktureringsordrar hanteras av ett externt (fjärr)system. Detta fjärrsystem måste uppdatera orderstatusen i Salesforce när ordern eller faktureringsenheten i faktureringssystemets status ändras.

Problem

Hur ansluter och autentiserar ett fjärrsystem med Salesforce för att meddela Salesforce om externa händelser, skapa poster och uppdatera befintliga poster?

Krafter

Det finns olika krafter att tänka på vid tillämpning av lösningar baserade på detta mönster:

Är syftet med fjärranropet till Salesforce att meddela Salesforce om en händelse som inträffat externt med en händelsedriven arkitektur? Eller är syftet att utföra CRUD-operationer för specifika poster? Om du använder en händelsedriven arkitektur frikopplas händelseproducenten (fjärrprocessen) från Salesforce-händelsekonsumenten.
Kräver samtalet till Salesforce att fjärrprocessen väntar på ett svar innan den fortsätter bearbetas? Fjärrsamtal till Salesforce är alltid synkrona begäran-svar, även om fjärrprocessen kan ignorera svaret om det inte behövs för att simulera ett asynkront samtal.
Fungerar varje transaktion mot ett enskilt Salesforce-objekt eller flera relaterade objekt?
Vad är formatet på meddelandet (till exempel SOAP eller REST, eller båda över HTTP)?
Är meddelandestorleken relativt liten eller stor?
Om fjärrsystemet är SOAP-kompatibelt, kan fjärrsystemet delta i en metod där Salesforce bestämmer kontraktet? Detta krävs där vår SOAP API används, för vilken en fördefinierad WSDL tillhandahålls.
Krävs transaktionsbearbetning?
I vilken utsträckning är du tolerant mot anpassningar i Salesforce?

Lösning

Denna tabell innehåller olika lösningar på detta integreringsproblem.

Lösning	Anpassa	Kommentarer
Sammansatt API	Bästa	Salesforce tillhandahåller en sammansatt API som är en REST API och har stöd för sammansatta begäranden. Detta kan användas av fjärrsystem för att: Skicka upp till 25 begäranden i ett enda samtal. För att fråga, skapa och ändra data i Salesforce-organisationen med JSON-begäranden. Synkron API—Efter att API-anropet har gjorts väntar fjärrklientprogrammet tills det får ett svar från tjänsten. Transaktions-/förpliktelsebeteende—Som standard tillåter inte sammansatt API delvis framgång om vissa poster är markerade med fel. Detta kan ändras genom att markera flaggan “allt eller inget” som falskt vilket kommer att tillåta delvis framgång. Felhantering: Korrekt felhantering bör undersöka svarsbrödtexten, inte bara HTTP-statuskoder. En sammansatt slutpunkt svarar med 200 HTTP-statuskod även om den inuti svarsbrödtexten visar att en av underbegärandena misslyckades och transaktionen måste dras tillbaka.
Sammansatt graf-API	Bästa	Resursen för sammansatta diagram låter dig skicka in operationer för sammansatta diagram. Denna resurs är tillgänglig i REST API version 50.0 och senare. Sammansatt graf-API kan stödja upp till 75 grafer i en payload och högst 500 noder i en graf.
REST API	Bästa	Tillgänglighet—Salesforce tillhandahåller en REST API som fjärrsystem kan använda för att: Publicera händelser för att meddela din Salesforce-organisation Sökfrågedata i din organisation - med antingen sökfrågeresursen eller Named Query API Skapa, uppdatera och ta bort data Hämta metadata om din organisation Synkron API—Efter att API-anropet har gjorts väntar fjärrklientprogrammet tills det får ett svar från tjänsten. REST API respekterar objektnivå- och fältnivåsäkerhet som konfigurerats i Salesforce baserat på den inloggade användarens profil. REST exponerar resurser (enheter/objekt) som URI:er och använder HTTP-verb för att definiera CRUD-operationer för dessa resurser. Till skillnad från SOAP kräver REST API inget fördefinierat kontrakt, använder XML och JSON för svar och har lös skrivning. REST API är lätt och ger en enkel metod för att interagera med Salesforce. Dess fördelar inkluderar enkel integrering och utveckling och är ett utmärkt val för användning med mobilappar och webbappar. Transaktions-/förpliktelsebeteende—Som standard behandlas varje post som en separat transaktion och förpliktas separat. Misslyckande med en poständring orsakar inte tillbakadragande av andra poständringar. Detta beteende kan ändras till ett "allt eller inget"-beteende. Använd REST API-kompositresurser för att göra en serie uppdateringar i ett API-anrop. Bulkdata—Alla dataoperationer som innehåller mer än 2 000 poster är en bra kandidat för Bulk API 2.0 för att framgångsrikt förbereda, köra och hantera ett asynkront arbetsflöde som använder Bulk Framework.
Bulk API 2.0	Bäst för massoperationer	Bulk API 2.0 är Salesforces moderna, effektiva API för hantering av storskaliga dataoperationer. REST-baserade Bulk API 2.0 har ett programmatiskt alternativ för att asynkront infoga, infoga, fråga eller ta bort stora datauppsättningar i din Salesforce-organisation. Den är utformad för effektivitet när du behöver läsa in stora mängder data i Salesforce eller utföra massfrågor på din organisations data. Bulk API 2.0 bearbetar alltid satser parallellt och har inte stöd för serieläge. Detta innebär att: Poster bearbetas samtidigt över flera trådar Det finns ingen garanti för bearbetning av order mellan satser Det finns högre prestanda men också en potential för låskonflikter Varje batch i Bulk API 2.0 bearbetas som sin egen transaktion. Detta innebär: Framgångsrika satser förbinder sig oberoende Misslyckade satser påverkar inte framgångsrika Som standard finns inget "allt-eller-inget"-beteende för alla jobb Även om SOAP API även kan användas för att bearbeta ett stort antal poster blir det mindre optimalt när datauppsättningar innehåller hundratusentals till miljoner poster. Detta på grund av dess relativt höga overhead och lägre prestandaegenskaper. Händelsedriven arkitektur—Plattformshändelser definieras på samma sätt som du definierar Salesforce-objekt. Att publicera en händelse via Bulk API 2.0 är samma sak som att skapa en Salesforce-post. Endast operationerna Skapa och Infoga stöds. Händelser inom en sats publiceras till Salesforce-händelsebussen asynkront medan batchjobbet bearbetas.
GraphQL API .	Bästa	För scenarion med fjärrinkallning som involverar komplexa läsningar med flera objekt och selektiva fält är GraphQL ett överlägset alternativ till REST API.
Pub/Sub API	Bästa	Pub/Sub API är det rekommenderade sättet för externa utgivare att publicera händelser i händelsebussen. Pub/Sub API är en gRPC-baserad API som låter externa system publicera plattformshändelser. Pub/Sub API: Stöder både publicering och prenumeration på plattformshändelser från externa program Är tillgänglig med korrekt autentisering (OAuth-, JWT- eller sessionstokens)
Plattformshändelser	Bästa	Plattformshändelser definieras på samma sätt som du definierar Salesforce-objekt. Plattformshändelser kan publiceras med olika mekanismer som REST API, Bulk API och SOAP API. Att publicera en händelse via REST API är samma sak som att skapa en Salesforce-post. Slutpunktsformat: POST /services/data/vXX.X/sobjects/EventName__e/ Innehållstyp: application/json Autentisering: Bärartoken (OAuth) Med Bulk API stöds endast operationerna Skapa och Infoga. Händelser inom en sats publiceras till Salesforce-händelsebussen asynkront medan batchjobbet bearbetas. Eftersom plattformshändelser är SObjects stöds standardåtgärder för SOAP API.
SOAP API	Suboptimal	Tillgänglighet—Salesforce tillhandahåller en SOAP API som fjärrsystem kan använda för att: Publicera händelser för att meddela din Salesforce-organisation Fråga data i din organisation Skapa, uppdatera och ta bort data Hämta metadata om din organisation Kör verktyg för att utföra administrativa uppgifter Synkron API—Efter att API-anropet har gjorts väntar fjärrklientprogrammet tills det får ett svar från tjänsten. Asynkrona samtal till Salesforce stöds inte. Skapad WSDL—Salesforce tillhandahåller två WSDL för fjärrsystem: Enterprise WSDL - Ger en starkt skriven WSDL som är specifik för en Salesforce-organisation. Partner WSDL - Innehåller en löst skriven WSDL som inte är specifik för en Salesforce-organisation. Säkerhet—Klienten som kör SOAP API måste ha en giltig inloggning och erhålla en session för att utföra API-anrop. API respekterar objektnivå- och fältnivåsäkerhet som konfigurerats i Salesforce baserat på den inloggade användarens profil. Transaktions-/förpliktelsebeteende—Som standard tillåter varje API-anrop delvis framgång om vissa poster är markerade med fel. Detta kan ändras till ett "allt eller inget"-beteende där alla resultat dras tillbaka om något fel uppstår. Det går inte att sträcka sig över flera API-anrop. För att övervinna denna begränsning är det möjligt att ett enskilt API-anrop påverkar flera objekt. SOAP kräver betydande Knowledge om Salesforce-objektmodellen, API-mekanismer och SOAP-meddelandehantering. Dessa ytterligare faktorer gör att REST är att föredra framför SOAP.
Apex webbtjänster	Suboptimal	Apex klassmetoder kan exponeras som webbtjänstmetoder för externa program. Denna metod är ett alternativ till SOAP API och används vanligtvis endast där följande ytterligare krav måste uppfyllas. Fullständig transaktionssupport krävs (till exempel skapa ett konto, en kontakt och ett säljprojekt i en och samma transaktion). Egen logik måste tillämpas på Salesforce-sidan innan du utför något. Fördelen med att använda en Apex webbtjänst måste vägas mot den ytterligare kod som behöver underhållas i Salesforce. Inte tillämpligt för plattformshändelser eftersom logik för förinfoga transaktioner hos konsumenten inte gäller i en händelsedriven arkitektur. För att meddela en Salesforce-organisation att en händelse har inträffat, använd SOAP API, REST API eller Bulk API 2.0. SOAP kräver betydande Knowledge om Salesforce-objektmodellen, API-mekanismer och SOAP-meddelandehantering. Dessa ytterligare faktorer gör att REST är att föredra framför SOAP.
Apex REST-tjänster	Suboptimal	En Apex klass kan visas som REST-resurser mappade till specifika URI:er med ett definierat HTTP-verb (till exempel POST eller GET). Du kan använda sammansatta REST API-resurser för att utföra flera uppdateringar i en enskild transaktion. Till skillnad från SOAP behöver klienten inte konsumera en servicedefinition/ett kontrakt (WSDL) och skapa klientstubbar. Fjärrsystemet kräver endast möjligheten att skapa en HTTP-begäran och bearbeta de returnerade resultaten (XML eller JSON). Inte tillämpligt för plattformshändelser eftersom logik för förinfoga transaktioner hos konsumenten inte gäller i en händelsedriven arkitektur. För att meddela en Salesforce-organisation att en händelse har inträffat, använd SOAP API, REST API eller Bulk API 2.0.

Skiss

Följande diagram illustrerar händelseförloppet när du implementerar detta mönster med antingen REST API för notiser från externa händelser eller SOAP API för att fråga ett Salesforce-objekt. Händelsesekvensen är densamma vid användning av REST API.

Fjärrsystemfråga Salesforce via REST API

Fjärrsystem frågar Salesforce via REST API

Fjärrsystem som meddelar Salesforce med händelser via REST API

Fjärrsystem meddelar Salesforce med händelser via REST API

Resultat

I en händelsedriven arkitektur anropar fjärrsystemet Salesforce med SOAP API, REST API eller Bulk API 2.0 för att publicera en händelse till Salesforce-händelsebussen. Publicering av en händelse meddelar alla prenumeranter. Händelseprenumeranter kan vara på Salesforce Platform, till exempel Flöden eller Apex för Lightning. Händelseprenumeranter kan även vara externa till Salesforce Platform, till exempel Pub/Sub API-prenumeranter.

När du arbetar direkt med Salesforce-objekt tillåter lösningarna relaterade till detta mönster:

Fjärrsystemet anropar Salesforce API för att fråga databasen och utföra operationer med ett objekt (skapa, uppdatera, ta bort och så vidare).
Det fjärrsystem som anropar Salesforce REST API:s sammansatta resurser för att utföra en serie objektoperationer.
Fjärrsystem för att anropa egna Salesforce API:n (tjänster) som kan stödja transaktioner med flera objekt och egen logik för för-/efterbearbetning.

Anropsmekanismer

Anropsmekanismen beror på vilken lösning som valts för att implementera detta mönster.

Anropsmekanism	Beskrivning
SOAP API	Fjärrsystemet använder Salesforce Enterprise eller Partner WSDL för att skapa klientstubbar som i sin tur används för att åberopa standard-SOAP API.
REST API	Fjärrsystemet måste autentiseras innan åtkomst till någon Apex REST-tjänst. Fjärrsystemet ska använda OAuth 2.0 för autentisering och auktorisering. Klienten måste ange HTTP-sidhuvudet för auktorisering med lämpligt värde, till exempel en OAuth-åtkomsttoken. Fjärrsystemet skapar sedan REST-åberopningar (HTTP-begäranden) med lämpliga verb och bearbetar de returnerade resultaten (JSON- och XML-dataformat stöds).
Apex webbtjänst	Fjärrsystemet använder den egna Apex webbtjänsten WSDL för att skapa klientstubbar som i sin tur används för att åberopa den egna Apex webbtjänsten.
Apex REST-tjänst	Enligt REST API definieras resurs-URI och tillämpliga verb med annotationerna @RestResource, @HttpGet och @HttpPost.
Bulk API 2.0	Bulk API 2.0 är en REST-baserad API, så samma anropsmekanismer som REST API gäller.
REST API för att åberopa flöde	Använd REST API för att anropa en slutpunkt för egna åberopbara åtgärder för att åberopa ett autostartat flöde.

Felhantering och återställning

En strategi för felhantering och återställning måste betraktas som en del av den övergripande lösningen.

Felhantering — Alla fjärranropsmetoder, standard eller egna API:n, kräver att fjärrsystemet hanterar eventuella efterföljande fel, som timeout och hantering av försök. Middleware kan användas för att tillhandahålla logiken för felhantering och återställning.
Återställning — Bygg en egen försöksmekanism om kraven på servicekvalitet kräver det. I detta fall är det viktigt att säkerställa idempotenta designegenskaper. Plattformshändelse låter prenumeranter använda repris-ID för att hämta meddelanden inom en viss tidsperiod efter att dessa meddelanden publicerades.

Att tänka på vad gäller Idempotent design

Idempotent kapacitet garanterar att upprepade åberopningar är säkra och inte har en negativ effekt. Om idempotens inte implementeras kan upprepade åberopningar av samma meddelande ha olika resultat, vilket potentiellt kan resultera i problem med dataintegritet, till exempel att dubblettposter skapas, att transaktioner bearbetas flera gånger och så vidare.

Fjärrsystemet måste hantera flera (dubbla) samtal i händelse av fel eller timeout för att undvika dubbletter av inmatningar och överflödiga uppdateringar (särskilt om utlösare längre ner och arbetsflödesregler aktiveras). Även om det är möjligt att hantera vissa av dessa situationer i Salesforce (särskilt när det gäller egna SOAP- och REST-tjänster), rekommenderar vi att fjärrsystemet (eller mellanprogramvaran) hanterar felhantering och idempotent design.

Säkerhetsöverväganden

Olika säkerhetsöverväganden gäller, beroende på vilken mönsterlösning som valts. I samtliga fall använder plattformen den inloggade användarens åtkomsträttigheter (till exempel profilinställningar, delningsregler, behörighetsuppsättningar och så vidare). Utöver detta kan profil-IP-begränsningar användas för att begränsa åtkomst till API för ett specifikt IP-adressintervall.

Lösning	Säkerhetsöverväganden
SOAP API	Salesforce har stöd för protokoll för Transport Layer Security (TLS 1.2 eller senare). Chiffer måste ha en nyckellängd på minst 128 bitar.
REST API	Vi rekommenderar att fjärrsystemet etablerar en OAuth Trust för auktorisering. REST-anrop kan sedan göras för specifika resurser med HTTP-verb. Vi rekommenderar att klienter som anropar REST API sedan cachar och återanvänder OAuth-token för att maximera prestandan, istället för att få en ny OAuth-token för varje anrop.
Apex webbtjänst	Vi rekommenderar att fjärrsystemet etablerar en OAuth Trust för auktorisering.
Apex REST-tjänst	Vi rekommenderar att fjärrsystemet etablerar en OAuth Trust för auktorisering.
Bulk API 2.0	Vi rekommenderar att fjärrsystemet etablerar en OAuth Trust för auktorisering.

Se Att tänka på vad gäller säkerhet.

Sidofält

Inga.

Rättidighet

SOAP API och Apex webbtjänst API är synkrona. Följande timeouter gäller:

Sessionstimeout — Sessionen löper ut om det inte finns någon aktivitet baserat på Salesforce-organisationens inställning för sessionstimeout.
Sökfrågetimeout — Varje SOQL-fråga har en individuell gräns för timeout på 120 sekunder.

Datavolymer

Att tänka på vad gäller datavolym beror på vilken lösning och kommunikationstyp du väljer.

Lösning	Kommunikationstyp	Gränser
SOAP API eller REST API	Synkron	Skapa, Uppdatera, Ta bort—Fjärrsystemet kan skapa, uppdatera eller ta bort upp till 200 poster åt gången. Flera samtal kan göras för att bearbeta mer än totalt 200 poster, men varje begäran är begränsad till 200 poster. BLOB-data—Du kan använda REST-resurserna Grundläggande information för SObject, SObject-rader eller SObject-samlingar för att infoga eller uppdatera BLOB-data i Salesforces standardobjekt. För resurserna Grundläggande information för SObject eller Rader för SObject är den maximala filstorleken för uppladdningar 2 GB för ContentVersion-objekt och 500 MB för alla andra kvalificerade standardobjekt. Med SObject-samlingsresurser är den maximala totala storleken på alla filer i en enskild begäran 500 MB. Storlek på sökfrågeresultat — Som standard är antalet rader som returneras i sökfrågeresultatobjektet (satsstorlek), som returneras i ett query()- eller queryMore()-anrop 500. Det högsta antalet rader som returneras är 2 000. Du kan uttryckligen ange satsstorleken, men det finns ingen garanti för att den begärda satsstorleken kommer att vara den faktiska satsstorleken. Detta görs för att maximera prestandan. Om antalet rader som ska returneras överskrider batchstorleken, använd API-anropet queryMore() för att upprepa genom flera batcher. Ytterligare regler kan gälla, så för mer information. Händelsemeddelande — Den maximala storleken på händelsemeddelanden är 1 MB. Att publicera en händelse med Salesforce API räknas mot dina standard API-gränser.
Bulk API 2.0	Asynchronous	Bulk API 2.0 är optimerat för att importera och exportera stora datauppsättningar asynkront. Alla dataoperationer som innehåller mer än 2 000 poster är en bra kandidat för Bulk API 2.0 för att framgångsrikt förbereda, köra och hantera ett asynkront arbetsflöde som använder Bulk Framework. Jobb med färre än 2 000 poster ska involvera ”buntade” synkrona anrop i REST (till exempel Sammansatt) eller SOAP. Bulk API 2.0 är synkront när batchbegäran och associerade data skickas. Den faktiska bearbetningen av data sker asynkront. Mer information om gränser för API och batchbearbetning finns i Gränser.

Stöd för slutpunktskapacitet och standarder

Kapaciteten och standardsupporten för slutpunkten beror på vilken lösning du väljer.

Lösning	Att tänka på vad gäller slutpunkt
SOAP API	Fjärrsystemet måste kunna implementera en klient som kan anropa Salesforce SOAP API, baserat på ett meddelandeformat som fördefinierats av Salesforce. Fjärrsystemet (klienten) måste delta i en implementering där kontraktet levereras av Salesforce (till exempel Enterprise eller Partner WSDL).
REST API	Fjärrsystemet måste kunna implementera en REST-klient som åberopar Salesforce-definierade REST-tjänster och bearbetar XML- eller JSON-resultaten.
Apex webbtjänst	Fjärrsystemet måste kunna implementera en klient som kan åberopa SOAP-meddelanden i ett fördefinierat format, enligt Salesforce. Fjärrsystemet måste delta i en kodförst implementering, där kontraktet levereras av Salesforce efter att Apex webbtjänst har implementerats. Varje Apex webbtjänst har sin egen WSDL.
Apex REST-tjänst	Samma överväganden för slutpunkter som REST API gäller.

Statsförvaltning

Vid integrering av system är nycklar viktiga för pågående lägesspårning, till exempel om en post skapas i fjärrsystemet, för att stödja pågående uppdateringar av den posten. Det finns två alternativ:

Salesforce lagrar fjärrsystemets primära eller unika surrogatnyckel för fjärrposten.
Fjärrsystemet lagrar Salesforces unika post-ID eller någon annan unik ersättningsnyckel. Det finns specifika överväganden för att hantera integreringsnycklar i detta synkrona mönster.

Huvud	Systembeskrivning
Salesforce	I detta scenario lagrar fjärrsystemet antingen Salesforce RecordId eller någon annan unik surrogatnyckel från posten.
Fjärrsystem	I detta scenario lagrar Salesforce en referens till den unika identifieraren i fjärrsystemet. Eftersom processen är synkron kan nyckeln tillhandahållas som en del av samma transaktion med externa ID-fält.

Komplexa integreringsscenarion

Varje lösning i detta mönster har olika överväganden vid hantering av komplexa integreringsscenarion som transformation och processorkestrering.

Lösning	Att tänka på
SOAP API eller REST API	SOAP API och REST API ger enkla transaktioner på objekt. Komplexa integreringsscenarion, som aggregering, orkestrering och transformation, kan inte utföras i Salesforce. Dessa scenarion måste hanteras av fjärrsystemet eller mellanprogramvaran, med mellanprogramvara som den föredragna metoden.
Apex webbtjänst eller Apex REST-tjänst	Egna webbtjänster kan tillhandahålla korsobjektfunktionalitet, egen logik och mer komplex transaktionssupport. Denna lösning bör användas med försiktighet och du bör alltid överväga om middleware passar för transformation, orkestrering och felhanteringslogik.

Governorgränser

På grund av Salesforce-plattformens multitenantkaraktär finns det gränser vid användning av API.

Lösning	Gränser
SOAP API, REST API och egna Apex API	API-begärangränser — Salesforce tillämpar en gräns för antalet API-anrop per 24-timmarsperiod. Gränsen baseras på Salesforce Edition-typen och antalet licenser. Till exempel tillhandahåller Unlimited Edition 5 000 API-begäranden per Salesforce Platform-licens under 24 timmar. Mer information finns i Snabbreferens för Salesforce Developer-gränser och -allokeringar. Gränser för API-frågemarkörer—En användare kan ha upp till 10 frågemarkörer öppna åt gången. Annars släpps den äldsta av de 10 markörerna. Om fjärrprogrammet försöker öppna den utgivna sökfrågemarkören visas ett fel. Till exempel, om du delar inloggningsuppgifter för integreringsanvändare måste de maximala sökfrågemarkörerna övervägas. När så är möjligt ska mellanprogramvaran slutföra den fullständiga sökfrågan innan en annan sökfråga körs (i serie) eller så ska varje program använda en utsedd integreringsanvändare. Alternativt kan middleware behöva utföra begäranden över flera användare på ett "round robin"-sätt. Samtalsgränser—Se Datavolymers sidofält för att skapa, uppdatera och fråga gränser.
Bulk API 2.0	Se sidofältet Datavolymer för mer information.
Plattformshändelser	Gränser för händelsenotiser—Högst 100 000 händelser kan publiceras per timme för plattformshändelser med standardvolym. Högst 250 000 händelser kan publiceras per timme för användningsbaserade plattformshändelser med hög volym. För att bevaka händelseanvändning med hög volym, använd REST API-gränsresurs. Storleksgränser för händelsemeddelanden—Den maximala storleken på händelsemeddelanden är 1 MB. Att publicera en händelse med Salesforce API räknas mot dina standard API-gränser.

Pålitliga meddelanden

Pålitliga meddelanden försöker lösa problemet med att garantera leverans av ett meddelande till ett fjärrsystem där de enskilda komponenterna själva kan vara opålitliga. Salesforce SOAP API och REST API är synkrona och ger inte uttryckligt stöd för några pålitliga meddelandeprotokoll i sig (till exempel WS-ReliableMessaging).

Vi rekommenderar att fjärrsystemet implementerar ett pålitligt meddelandesystem för att säkerställa att fel- och timeoutscenarion hanteras framgångsrikt. Publicering av plattformshändelser från externa system förlitar sig på Salesforce API, så samma överväganden för SOAP API och REST API gäller.

Middleware-kapacitet

Denna tabell lyfter fram de önskvärda egenskaperna för ett middleware-system som deltar i detta mönster:

Egenskap	Obligatorisk	Önskvärt	Ej obligatoriskt
Händelsehantering		X
Protokollkonvertering		X
Översättning och transformation		X
Köer och buffring	X
Synkrona transportprotokoll	X
Asynkrona transportprotokoll			X
Medlingsdirigering		X
Processkoreografi och serviceorkestrering		X
Transaktionalitet (kryptering, signering, pålitlig leverans, transaktionshantering)	X
Dirigering			X
Extrahera, transformera och läs in		X (för bunt/satser)
gRPC-stöd (för Pub/Sub API)		X

Exempel

Ett tryckeriföretag använder Salesforce som frontend för att skapa och hantera skrivarmaterial och ordrar. Salesforce-tillgångsposter som representerar skrivare uppdateras regelbundet med användningsstatistik (bläckstatus, pappersnivå) från det lokala skrivarhanteringssystemet (PMS), som regelbundet övervakar skrivare på klientwebbplatser. När ett fast tröskelvärde uppnås (till exempel låg bläckstatus eller låg/tom pappersnivå på mindre än 30 %) meddelas flera appar/processer (variabler) som är intresserade av händelsen, e-postmeddelanden eller Chatter skickas och en orderpost skapas. PMS lagrar Salesforce-ID (Salesforce är huvudposten för tillgångar).

Följande begränsningar gäller:

PMS kan delta i en integrering där Salesforce tillhandahåller kontraktet och PMS agerar som en klient (konsument) för Salesforce-tjänsten (definierad via Enterprise eller Partner WSDL).
Det ska inte finnas någon egen utveckling i Salesforce.

Detta exempel implementeras bäst med Salesforce SOAP API eller REST API för att publicera händelser och deklarativ automatisering (flöde) i Salesforce. Den primära anledningen till att använda plattformshändelser är variabeln och det icke-ändliga antalet prenumeranter. För enkla uppdateringar av en ändlig lista över poster som ordrar, använd SOAP eller REST API för att uppdatera posterna.

I Salesforce:

Definiera en plattformshändelse i Salesforce som ska innehålla notisdata från PMS.
Skapa ett flöde som utlöses av notisen om skrivarhändelsen. Processen uppdaterar skrivartillgången och skapar en order (med ett autostartat flöde).
Ladda ner Enterprise eller Partner WSDL och tillhandahåll den till fjärrsystemet.

I fjärrsystemet:

Skapa en klientstub från Enterprise eller Partner WSDL.
Autentisera till Salesforce (via OAuth-webbserver eller bärartokenflöde) med integreringsanvändarens inloggningsuppgifter.
Vid händelsen skrivarstatus anropar PMS API för att skapa händelsen skrivarstatusplattform (med statistik om skrivaranvändning). Salesforce-händelsebussen meddelar Flödesprenumeranter och alla andra prenumeranter.

När du använder plattformshändelser låter händelsebussen dig spela upp händelser i 72 timmar för plattformshändelser med hög volym. Att publicera dessa händelser med hjälp av en mellanprogramlösning kan hjälpa till att införliva felhantering på publiceringssidan. Du kan dock implementera felhantering på prenumerationssidan om du behöver högre pålitlighet.

Detta exempel visar följande:

Implementering av en Salesforce synkron API-klient (konsument).
En callback till Salesforce för att publicera en plattformshändelse (i linje med tidigare täckta mönster för plattformshändelser för begäran/svar).

Sammanhang

Du använder Salesforce för att hantera kundcase. En kundtjänstrepresentant pratar i telefon med en kund som arbetar med ett kundcase. Kunden gör en betalning och kundtjänstrepresentanten behöver se en uppdatering i realtid i Salesforce-programmet från betalningsbearbetningsprogrammet, som indikerar att kunden har betalat orderns utestående belopp.

Problem

När en händelse inträffar i Salesforce, hur kan användaren meddelas i Salesforces användargränssnitt utan att behöva uppdatera sin skärm och eventuellt förlora arbete?

Krafter

Det finns olika krafter att tänka på vid tillämpning av lösningar baserade på detta mönster:

Behöver de data som hanteras lagras i Salesforce?
Kan ett eget användargränssnittlager byggas för att visa dessa data?
Har användaren åtkomst för att åberopa det egna användargränssnittet?

Lösning

Den rekommenderade lösningen på detta integreringsproblem är att använda plattformshändelser som säkerställer händelser nästan i realtid i Salesforce. Plattformshändelser ger en strukturerad, flexibel belastning oberoende av något Salesforce-objekt. De säkerställer även hållbara ämnen med ett reprisfönster på 72 timmar. Detta fönster garanterar att händelser är tillgängliga även om en offlinekonsument blir tillgänglig senare. Denna lösning består av följande komponenter:

Apex eller flöden med en logik för att publicera en plattformshändelse för ett ämne
Ett ämne som låter dig publicera en händelse från Apex utlösare eller flöde
Pub/Sub API (baserat på gRPC och HTTP/2) för effektiv användning av plattformshändelser
En Lightning
Ett JavaScript-bibliotek inkluderat som en statisk resurs

Skiss

Följande diagram illustrerar hur Pub/Sub API kan implementeras för att strömma notiser till Salesforces användargränssnitt. Dessa notiser utlöses av poständringar i Salesforce.

Uppdatering av användargränssnitt i Salesforce utlöst av en dataändring

Uppdatering av användargränssnitt i Salesforce utlöst av en dataändring

Resultat

Fördelar

Tillämpningen av lösningen relaterad till detta mönster har följande fördelar:

Utesluter behovet av att skriva egna omröstningsmekanismer
Utesluter behovet av en användarinitierad feedbackloop

Krav som inte stöds

Lösningen har följande begränsningar:

Leverans av notiser garanteras inte.
Ordning på notiser garanteras inte.
Notiser skapas inte från poständringar som görs av Bulk API.

Säkerhetsöverväganden

Standardsäkerhet på Salesforce-organisationsnivå följs. Vi rekommenderar att du använder HTTPS-protokollet för att ansluta till Streaming API. Se Säkerhetsöverväganden

Sidofält

Den optimala lösningen innefattar att skapa ett eget användargränssnitt i Salesforce. Det är viktigt att du tar hänsyn till en lämplig behållare för användargränssnittet som kan användas för att återge det egna användargränssnittet. Mer information finns i Utvecklarguide för Pub/Sub API.

Exempel

Ett telekommunikationsföretag använder Salesforce för att hantera kundcase. Kundtjänstcheferna vill meddelas när ett kundcase avslutas av en av deras kundtjänstrepresentanter.

Genom att implementera lösningen som föreskrivs i detta mönster ska kunden:

Skapa en Apex som skickar en plattformshändelse när ett kundcase sparas med Status “Avslutat” och Lösning “Framgångsrikt”.
Skapa ett eget användargränssnitt som är tillgängligt för kundtjänstansvariga. Detta användargränssnitt prenumererar på Pub/Sub API för att konsumera plattformshändelser.
Implementera logik i det egna användargränssnittet som visar varningar som skapas av den ansvariges kundtjänstrepresentanter.

Sammanhang

Du använder Salesforce för att följa leads, hantera din pipeline, skapa säljprojekt och samla in orderdetaljer som konverterar leads till kunder. Salesforce är dock inte det system som innehåller eller bearbetar ordrar. Ordrar hanteras av ett externt (fjärr)system. Men säljare vill se och uppdatera orderinformation i realtid i Salesforce utan att behöva lära sig eller använda det externa systemet.

Problem

I Salesforce, hur visar, söker och ändrar du data som lagras utanför Salesforce, utan att flytta data från det externa systemet till Salesforce?

Krafter

Det finns olika krafter att tänka på vid tillämpning av lösningar baserade på detta mönster:

Vill du bygga en deklarativ/peka-och-klicka-utgående integrering eller användargränssnittsmashup i Salesforce?
Har du en stor mängd data som du inte vill kopiera till din Salesforce-organisation?
Behöver du åtkomst till små mängder fjärrsystemdata samtidigt?
Behöver du åtkomst till de senaste data i realtid?
Lagrar du dina data i molnet eller i ett backoffice-system, men vill visa eller bearbeta dessa data i din Salesforce-organisation?
Har du problem med datalagring för att lagra vissa typer av data i Salesforce?

Lösning

Följande tabell innehåller olika lösningar på detta integreringsproblem.

Lösning	Anpassa	Kommentarer
Salesforce Connect	Bästa	Använd Salesforce Connect för att komma åt data från externa källor, tillsammans med dina Salesforce-data. Hämta data från system som SAP, Microsoft, Oracle och andra molnbaserade system som Snowflake i realtid utan att göra en kopia av data i Salesforce. Salesforce Connect mappar datatabeller i externa system till externa objekt i din organisation. Externa objekt liknar egna objekt, förutom att de mappar till data utanför din Salesforce-organisation. Salesforce Connect använder en liveanslutning till externa data för att alltid hålla externa objekt uppdaterade. Att öppna ett externt objekt hämtar data från det externa systemet i realtid. Salesforce Connect låter dig: Fråga data i ett externt system. Skapa, uppdatera och ta bort data i ett externt system. Åtkomst till externa objekt via listvyer, detaljsidor, postkanaler, egna flikar och sidlayouter. Definiera relationer mellan externa objekt och standardobjekt eller egna objekt för att integrera data från olika källor. Kör rapporter om externa data. (Notera: begränsningarna för Rapporter och instrumentpaneler i Salesforce fortfarande gäller). Visa data i Salesforce-mobilappen. För att komma åt data som lagras i ett externt system med Salesforce Connect kan du använda en av följande adapters: OData adapter — ansluter till data exponerade av en Odata producent. Salesforce Connect har stöd för versionerna 4.01, 4.0 och 2.0. AWS och Snowflake - ansluter till data som lagras i Athena, DynamoDB eller Snowflake. Adaptrarna använder dessa plattformars API för att exponera källdata. GraphQL - ansluter till data som lagras i AWS RDS med AWS AppSync för att tillhandahålla en GraphQL-översättning. Korsorganisationsadapter — ansluter till data som lagras i en annan Salesforce-organisation. Korsorganisationsadaptern använder standard Salesforce Platform REST API. Till skillnad från Odata ansluter korsorganisationsadaptern direkt till en annan organisation utan att behöva en mellanliggande webbtjänst. Egen adapter skapad via Apex — om de andra adapters inte passar dina behov, utveckla din egen adapter med Apex Connector Framework. Detta är ett användbart alternativ för alla system som exponerar en HTTP/REST API.
Data 360 och Zero Copy	Bästa	När en post uppdateras i externa system som ERP kan postuppdateringarna synkroniseras till Data 360 antingen med hjälp av tillgängliga färdiga anslutare eller med hjälp av API och prokodverktyg som MuleSoft. Poster 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. Obs! data i Data 360 kan inte redigeras. Om detta är ett krav, använd Salesforce Connect.
Data 360, Data Cloud One och Salesforce	Bästa	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. Med Data Cloud One kan användare i andra Salesforce-organisationer säkert komma åt data som delas virtuellt från Data 360. Obs! data i Data 360 kan inte redigeras. Om detta är ett krav, använd Salesforce Connect.
Begäran och svar	Suboptimal	Använd Salesforce webbtjänst-API:n för att göra ad hoc-databegäranden för att komma åt och uppdatera externa systemdata. Denna lösning innehåller följande metoder: Använd Salesforce SOAP API. En egen sida eller knapp inleder ett Apex REST/SOAP-anrop på ett synkront sätt. I Salesforce kan du konsumera en WSDL och skapa en resulterande proxy Apex klass. Denna klass tillhandahåller den logik som behövs för att anropa fjärrtjänsten. En användarinitierad åtgärd på en sida anropar sedan en Apex kontrollåtgärd som kör denna proxy Apex klass för att utföra fjärranropet. Sidorna kräver anpassning av Salesforce-appen. Använd Salesforce REST API. En egen sida eller knapp inleder ett Apex HTTP-anrop (REST-tjänst) på ett synkront sätt. I Salesforce kan du åberopa HTTP-tjänster med standardmetoderna GET, POST, PUT och DELETE. Mer information om denna lösning finns i Åberopning av fjärrprocess—Begäran och svar.

Skiss

Följande diagram illustrerar hur du kan använda Salesforce Connect för att hämta data från ett externt system med en OData adapter.

Arkitektur för Salesforce Connect OData-adapter

I detta scenario:

Webbläsaren utför ett AJAX-anrop som i sin tur utför en åtgärd på motsvarande externa objektadapter.
Adaptern översätter åtgärden till en Odata begäran och gör en HTTP GET-begäran till fjärrsystemet via lagren Integration och Tjänster.
Fjärrsystemet returnerar ett JSON-svar till Salesforce via lagren Integrering och Tjänster.
Svaret översätts från Odata till ett externt objekt och visas tillbaka i webbläsaren.

Resultat

Tillämpningen av lösningarna relaterade till detta mönster tillåter användargränssnittinledda åberopningar där resultatet av transaktionen kan visas för slutanvändaren.

Anropsmekanismer

Anropsmekanismen beror på vilken lösning som valts för att implementera detta mönster.

Anropsmekanism	Beskrivning
Externa objekt	Salesforce Connect mappar Salesforces externa objekt till datatabeller i externa system. Istället för att kopiera data till din organisation kommer Salesforce Connect åt data på begäran och i realtid. Även om data lagras utanför din organisation ger Salesforce Connect sömlös integrering med Salesforce Platform. Externa objekt är tillgängliga för Salesforce-verktyg, som global sökning, sökrelationer, postkanaler och Salesforce-mobilappen. Externa objekt är även tillgängliga för Apex, SOSL, SOQL-frågor, Salesforce API och distribuering via Metadata API, ändringsanvisningar och paket.
Lightning	Används när fjärrprocessen utlöses som en del av en end-to-end-process som involverar användargränssnittet och resultatet måste visas eller uppdateras i en Salesforce-post. Till exempel en process som skickar kreditkortsbetalningar till en extern betalningsgateway och omedelbart returnerar betalningsresultat som visas för användaren. Integrering som utlöses från händelser i användargränssnittet kräver vanligtvis att egna Lightning skapas.

Anropsmekanism

Beskrivning

Externa objekt

Salesforce Connect mappar Salesforces externa objekt till datatabeller i externa system. Istället för att kopiera data till din organisation kommer Salesforce Connect åt data på begäran och i realtid. Även om data lagras utanför din organisation ger Salesforce Connect sömlös integrering med Salesforce Platform. Externa objekt är tillgängliga för Salesforce-verktyg, som global sökning, sökrelationer, postkanaler och Salesforce-mobilappen. Externa objekt är även tillgängliga för Apex, SOSL, SOQL-frågor, Salesforce API och distribuering via Metadata API, ändringsanvisningar och paket.

Lightning

Används när fjärrprocessen utlöses som en del av en end-to-end-process som involverar användargränssnittet och resultatet måste visas eller uppdateras i en Salesforce-post. Till exempel en process som skickar kreditkortsbetalningar till en extern betalningsgateway och omedelbart returnerar betalningsresultat som visas för användaren. Integrering som utlöses från händelser i användargränssnittet kräver vanligtvis att egna Lightning skapas.

Felhantering

Det är viktigt att inkludera felhantering som en del av den övergripande lösningen. Om ett fel uppstår (undantag eller felkoder returneras till uppringaren) hanterar uppringaren felhanteringen. Salesforce Connect Validator är ett gratisverktyg för att köra några vanliga sökfrågor och lägga märke till feltyper och felorsaker.

Fördelar

Några av fördelarna med att använda en Salesforce Connect lösning är:

Denna lösning konsumerar inte datalagring i Salesforce.
Användare behöver inte oroa sig för att regelbundet synkronisera data mellan det externa systemet och Salesforce.
En deklarativ konfiguration som kan uppnås snabbt med Odata, eller en korsorganisationsadapter, eller med minimal kod med en egen Apex.
Användare kan komma åt externa data med mycket av samma funktionalitet som egna objekt i form av externa objekt.
Möjlighet att göra en sammanslagen sökning i det anslutna externa systemet med global sökning.
Möjlighet att köra rapporter som får åtkomst till externa data från molnkällor och lokala källor. Se rapporteringsöverväganden nedan.

Att tänka på vad gäller Salesforce Connect

Salesforce Connect har följande överväganden:

Externa objekt beter sig som egna objekt, men vissa funktioner är inte tillgängliga för externa objekt. Mer information finns i Att tänka på vad gäller Salesforce-kompatibilitet för Salesforce Connect.
Externa objekt kan påverka rapportprestanda. Mer information finns i Rapportöverväganden för Salesforce Connect.
Mer information om att använda Salesforce Connect-adapters finns i Att tänka på vad gäller Salesforce Connect – Alla adapters.
Om du överväger att använda en korsorganisationsadapter, se Att tänka på vad gäller Salesforce Connect—korsorganisationsadapter.
Om du överväger att använda en OData adapter, se Att tänka på vad gäller Salesforce Connect—OData 2.0- och 4.0-adapters.
Om du överväger att använda en egen Apex-adapter, se Att tänka på vad gäller Salesforce Connect—Egen adapter.

Säkerhetsöverväganden

Lösningar för detta mönster ska följa standardsäkerhet på Salesforce-organisationsnivå. Vi rekommenderar att du använder HTTPS-protokollet för att ansluta till alla fjärrsystem. Mer information finns i Att tänka på vad gäller säkerhet

Om du använder en Odata, se till att du förstår de speciella beteendena, begränsningarna och rekommendationerna för Cross-Site Request Forgery (CSRF) i externa Odata. Mer information finns i CSRF-överväganden för Salesforce Connect — OData 2.0- och 4.0-adapters.

Sidofält

Inga.

Rättidighet

I detta mönster är aktualitet av stor betydelse. Tänk på följande:

Begäran åberopas vanligtvis från användargränssnittet, så processen får inte låta användaren vänta.
Beroende på tillgängligheten och anslutningen till det externa systemet kan det ta lång tid att hämta externa data. Salesforce har ett konfigurerbart maximalt timeoutvärde på 120 sekunder för att vänta på ett svar från det externa systemet.
Fjärrprocessen ska utföras i tid och slutföras inom Salesforces tidsgräns och inom användarens förväntningar.

Datavolymer

Stöd för slutpunktskapacitet och standarder

Kapaciteten och standardsupporten för slutpunkten beror på vilken lösning du väljer.

Lösning	Att tänka på vad gäller slutpunkter
Salesforce Connect	OData APIs — Använd Open Data Protocol för åtkomst till data som lagras utanför Salesforce. Externa data måste exponeras via Odata producenter. Andra API:n — Använd Apex för att utveckla din egen adapter om de andra tillgängliga adapters inte passar dina behov. En egen adapter kan hämta data från vilken källa som helst. Till exempel kan vissa data hämtas från internet via anrop, medan andra data kan manipuleras eller till och med skapas programmatiskt. Anslut till Salesforce — Använder Salesforce Platform REST API för åtkomst till data som lagras i andra Salesforce-organisationer. Anslut via mellanprogramvara — Salesforce Connects partnerekosystem har haft ett nära samarbete med Salesforce för att säkerställa att deras mellanprogramvaras gateways exponerar Odata slutpunkter från deras tjänst så att Salesforce kan ansluta till dem utan att skriva ytterligare kod.
Begäran och svar	Apex SOAP-anrop - Slutpunkten måste kunna ta emot ett webbtjänstanrop via HTTP. Apex HTTP-anrop - Slutpunkten måste kunna ta emot HTTP-anrop. Du kan använda Apex HTTP-anrop för att anropa RESTful-tjänster med standardmetoderna GET, POST, PUT och DELETE

Lösning

Att tänka på vad gäller slutpunkter

Salesforce Connect

OData APIs — Använd Open Data Protocol för åtkomst till data som lagras utanför Salesforce. Externa data måste exponeras via Odata producenter.

Andra API:n — Använd Apex för att utveckla din egen adapter om de andra tillgängliga adapters inte passar dina behov. En egen adapter kan hämta data från vilken källa som helst. Till exempel kan vissa data hämtas från internet via anrop, medan andra data kan manipuleras eller till och med skapas programmatiskt.

Anslut till Salesforce — Använder Salesforce Platform REST API för åtkomst till data som lagras i andra Salesforce-organisationer.

Anslut via mellanprogramvara — Salesforce Connects partnerekosystem har haft ett nära samarbete med Salesforce för att säkerställa att deras mellanprogramvaras gateways exponerar Odata slutpunkter från deras tjänst så att Salesforce kan ansluta till dem utan att skriva ytterligare kod.

Begäran och svar

Apex SOAP-anrop -

Slutpunkten måste kunna ta emot ett webbtjänstanrop via HTTP.

Apex HTTP-anrop -

Slutpunkten måste kunna ta emot HTTP-anrop.

Du kan använda Apex HTTP-anrop för att anropa RESTful-tjänster med standardmetoderna GET, POST, PUT och DELETE

Statsförvaltning

Vid integrering av system är nycklar viktiga för pågående lägesspårning. Till exempel, om en post skapas i fjärrsystemet behöver posten vanligtvis någon form av identifierande nyckel för att stödja pågående uppdateringar. Det finns två alternativ för att lagra nycklar.

Salesforce lagrar den primära eller unika surrogatnyckeln för fjärrposten.
Fjärrsystemet lagrar Salesforces unika post-ID eller någon annan unik ersättningsnyckel. Det finns specifika överväganden för att hantera integreringsnycklar i detta synkrona mönster.

Huvudsystem	Beskrivning
Salesforce	Fjärrsystemet lagrar antingen Salesforces post-ID eller någon annan unik surrogatnyckel från posten.
Fjärrsystem	Anropet till fjärrprocessen returnerar den unika nyckeln från programmet och Salesforce lagrar detta nyckelvärde i ett unikt postfält.

Komplexa integreringar

I vissa fall kan lösningen som föreskrivs i detta mönster kräva implementering av ett komplext integreringsscenario. Dessa scenarion löses ofta med hjälp av middleware.

Aggregering av samtal och deras resultat över samtal till flera system
Transformation av både inkommande och utgående meddelanden
Upprätthålla transaktionsintegritet över anrop till flera system
Andra processorkestreringsaktiviteter mellan Salesforce och det externa systemet

Gällande gränser

Olika gränser gäller för olika adapters. Mer information finns i Allmänna gränser för Salesforce Connect.

Middleware-kapacitet

Följande tabell lyfter fram de önskvärda egenskaperna för ett middleware-system som deltar i detta mönster.

Egenskap	Obligatorisk	Önskvärt	Ej obligatoriskt
Händelsehantering		X
Protokollkonvertering	X
Översättning och transformation	X
Köer och buffring	X
Synkrona transportprotokoll	X
Asynkrona transportprotokoll		X
Medlingsdirigering		X
Processkoreografi och serviceorkestrering		X
Transaktionalitet (kryptering, signering, pålitlig leverans, transaktionshantering)	X
Dirigering			X
Extrahera, transformera och läs in			X
Lång pollning			X
gRPC-stöd (för Pub/Sub API)			X

Externa objektrelationer

Externa objekt har stöd för standardsökrelationer, som använder Salesforces post-ID på 18 tecken för att associera relaterade poster. Data som lagras utanför din Salesforce-organisation innehåller dock ofta inte dessa post-ID:n. Därför finns två speciella typer av sökrelationer för externa objekt: externa sökningar och indirekta sökningar.

Denna tabell sammanfattar de typer av relationer som är tillgängliga för externa objekt.

Relation	Tillåtna underordnade objekt	Tillåtna överordnade objekt	Överordnat fält för matchande poster
Sökning	Standard, Egen, Extern	Standard, Egen	Salesforces post-ID på 18 tecken
Extern sökning	Standard, Egen, Extern	Extern	Standardfältet Externt ID
Indirekt sökning	Extern	Standard, Egen	Välj ett eget fält med attributen Externt ID och Unik

Att tänka på vad gäller hög datavolym för Salesforce Connect: OData 2.0- och 4.0-adapters

Om din organisation uppnår hastighetsgränser vid åtkomst till externa objekt, överväg att välja alternativet Hög datavolym i de associerade externa datakällorna. Att göra detta kringgår de flesta begränsningsgränser, men vissa speciella beteenden och begränsningar gäller. Mer information finns i Att tänka på vad gäller hög datavolym i Salesforce Connect.

Klientdriven och serverdriven personsökning för Salesforce Connect: OData 2.0- och 4.0-adapters

Det är vanligt att Salesforce Connect med externa data har en stor resultatuppsättning som delas upp i mindre satser eller sidor. Du bestämmer om du vill att pagingbeteendet ska styras av det externa systemet (serverdriven) eller av OData 2.0- eller 4.0-adaptern för Salesforce Connect (klientdriven). Fältet Serverdriven paginering i den externa datakällan specificerar om klientdriven eller serverdriven paging ska användas. Om du aktiverar serverdriven paging på en extern datakälla ignorerar Salesforce de begärda sidstorlekarna, inklusive standardsatsstorleken queryMore() på 500 rader. Sidorna som returneras av det externa systemet avgör partierna, men ingen sida kan överskrida 2 000 rader. Gränserna för OData adapters för Salesforce Connect gäller dock fortfarande.

Exempel

Ett tillverkningsföretag använder Salesforce för att hantera kundcase. Kundtjänstagenterna vill få åtkomst till orderinformationen i realtid från backoffice ERP-systemet för att få en 360-vy av kunden utan att behöva lära sig och köra rapporter manuellt i ERP.

Implementering av lösningen som föreskrivs i detta mönster ska du:

Konfigurera din externa datakälla med en OData slutpunkt. Ditt fjärrprogram kan innehålla inbyggt stöd för Odata. För andra program har stora integreringsleverantörer som Dell Boomi, Informatica, Jitterbit, MuleSoft och Progress Software samarbetat med Salesforce på Salesforce Connect för att bygga adapters.
Rikta Salesforce Connect mot OData:s slutpunkt, antingen direkt eller genom en mellanprogramlösning.
Synkronisera dina externa databastabeller med externa objekt i Salesforce. När en användare öppnar en sida med data från dessa externa objekt gör Salesforce Connect anrop i realtid till dina backend-program.

Utvecklardokumentation

Trailhead

Salesforce går mot snabbare och händelsedrivna arkitekturer. Att migrera bort från äldre integreringsverktyg krävs nu för att förbli säker och skalbar. Många äldre verktyg använder föråldrade protokoll som SOAP eller long-polling (CometD), vilket inte kan hålla jämna steg med Pub/Sub API:s effektiva gRPC-baserade leverans eller automatiseringskraften hos Flow Builder. För att förbereda, börja med att granska dina befintliga integreringar för att hitta hårdkodade beroenden. Detta är särskilt viktigt eftersom Salesforce börjar dra tillbaka funktioner som Salesforce-till-Salesforce (helt tillbaka i utgåvan Spring '27) och fasar ut äldre autentiseringsmetoder. När du planerar din migrering, använd en "Flow-first"-metod för intern verksamhetslogik och en "Pub/Sub-first"-metod för externa dataströmmar. Detta ger dig en flexibel, frikopplad arkitektur som är redo för dagens AI-drivna plattforms datakrav.

login() i Salesforce SOAP API dras tillbaka. Den är redan inte tillgänglig i API v65.0 och senare. Nya Salesforce-organisationer kommer att ha login() inaktiverade som standard och befintliga organisationer behöver den nya behörigheten "Använd valfri API-autentisering" för att fortsätta använda den. Den hårda deadlinen är Summer '27, då Salesforce helt drar tillbaka login() i alla API-versioner (31,0 till 64,0).

Produkt	Status :	Föreslaget alternativ	Migreringsstrategi
Utgående meddelanden	Äldre (stöds)	Flöde + plattformshändelser	Ersätt med flödesutlösta plattformshändelser för bättre logik och modern autentisering.
Processbyggare	Slut på support	Flow Builder	Använd verktyget "Migrera till flöde" för att konvertera befintliga processer; refaktorisera komplex logik för prestanda.
Salesforce-till-Salesforce	Pension Spring ‘27	Salesforce Connect eller Pub/Sub API	Övergång till Salesforces datainsamling Ändra, Salesforce Connect eller Pub/Sub API med MuleSoft
Streaming API	Äldre (stöds)	Pub/Sub API	Flytta till Pub/Sub API för att utnyttja gRPC, som erbjuder högre genomströmning och förenklad prenumerationshantering.
SOAP API `login()`	Äldre (stöds till juni 2027)	OAuth 2.0-flöden	Flytta till OAuth2.0 med hjälp av externa klientappar.

För att vara effektiva medlemmar i företagsportföljen måste alla program skapas och integreras med relevanta säkerhetsmekanismer. Moderna IT-strategier använder en kombination av lokala och molnbaserade tjänster.

Att integrera moln-till-moln-tjänster fokuserar vanligtvis på webbtjänster och associerad auktorisering, men att ansluta på plats och molntjänster medför ofta ökad komplexitet. Detta avsnitt beskriver säkerhetsverktyg, tekniker och Salesforce-specifika överväganden.

Omvänd proxyserver

En omvänd proxy är en server som sitter framför webbservrar och vidarebefordrar klientförfrågningar (t.ex. webbläsare) till dessa webbservrar. Omvända proxyvärden implementeras vanligtvis för att hjälpa till att öka säkerhet, prestanda och pålitlighet.

Det är en typ av proxyserver som hämtar resurser åt en klient från en eller flera servrar. Dessa resurser returneras sedan till klienten som om de kommer från själva proxyservern. Till skillnad från en framåtproxy, som är en mellanhand för dess associerade klienter att kontakta vilken server som helst, är en omvänd proxy en mellanhand för dess associerade servrar att kontaktas av vilken klient som helst.

I Salesforce-implementeringar tillhandahålls en sådan tjänst vanligtvis via en extern gateway-produkt. Till exempel kan alternativ med öppen källkod som Apache HTTP, lighttpd och nginx användas. Kommersiella produkter inkluderar IBM WebSeal och Computer Associates SiteMinder. Dessa produkter kan enkelt konfigureras för att proxyhantera och hantera alla utgående Salesforce-begäranden åt den interna begäran.

Kryptering

Vissa företag kräver att valda transaktioner eller datafält krypteras mellan en kombination av program på plats och molnbaserade program. Om din organisation måste följa ytterligare efterlevnadskrav kan du implementera alternativ, inklusive:

gatewaytjänster för kommersiell kryptering på plats, inklusive Salesforces egna, CipherCloud, IBM DataPower, Computer Associates. För varje lösning åberopas krypteringsmotorn eller gateway vid transaktionsgränsen genom att skicka och ta emot en krypterad belastning eller vid kryptering eller avkryptering av specifika datafält innan HTTP(S)-begäran körs.
Molnbaserade alternativ, som Salesforce Shield Platform Encryption. Shield Platform Encryption ger dina data ett helt nytt lager säkerhet samtidigt som viktig plattformsfunktionalitet bevaras. De data du väljer krypteras vid vila med ett avancerat nyckelderiveringssystem. Du kan skydda dina data säkrare än någonsin tidigare. Mer information finns i Salesforces onlinehjälp.

Speciellt stöd för WS-*-protokoll

För att hantera kraven i säkerhetsprotokoll (som WS-*) rekommenderar vi dessa alternativ.

Security/XML gateway—Injicera WS-Security-inloggningsuppgifter (MuleSoft, IBM WebSeal eller Datapower, Layer7, TIBCO, och så vidare) i själva transaktionsströmmen. Detta tillvägagångssätt kräver inga ändringar av webbtjänster på programnivå eller webbtjänståberopningar från Salesforce. Du kan även återanvända denna metod i Salesforce-installationen. Det kräver dock ytterligare design, konfiguration, tester och underhåll för att hantera rätt WS-Security-injektion i den befintliga säkerhetsgatewaymetoden.
Transportnivåkryptering—Kryptera kommunikationskanalen med tvåvägs SSL och IP-begränsningar. Även om detta tillvägagångssätt inte implementerar WS-*-protokollet direkt av sig självt säkrar det kommunikationskanalen mellan de lokala programmen och Salesforce utan att skicka ett användarnamn och lösenord. Det kräver inte heller ändringar av Salesforce-skapade klasser. Vissa ändringar av webbtjänster på plats kan dock krävas (antingen i själva programmet eller i mellanprogrammet/ESB-lagret).
Egen utveckling i Salesforce—Lägg till WS-Security-sidhuvuden i den utgående SOAP-begäran via verktyget WSDL2Apex. Detta skapar en Java-liknande Apex klass från WSDL-filen som används för att åberopa den interna tjänsten. Detta tillvägagångssätt kräver inga ändringar av backend-webbtjänster eller ytterligare komponenter i DMZ, men det kräver:
- en ökad bygg- och testinsats
- en relativt komplex och manuell process för att handkoda attributen WS-Security (inklusive XML serialisering i Apex koden)
- en högre långsiktig underhållsinsats

Anteckning: Det sista alternativet rekommenderas inte på grund av dess komplexitet och risken att sådana integreringar behöver periodiska genomgångar baserat på regelbundna uppdateringar av Salesforce.

Övriga säkerhetsöverväganden

Inloggningsuppgifter: Salesforce har uppdaterat sin autentiseringsarkitektur genom att introducera en modell med två nivåer av autentiseringsuppgifter som tydligt separerar problem mellan anslutning och identitet. Använd detta när du gör anrop via Apex och undvik att skapa ditt eget autentiseringsprotokoll. Detta säkerställer även utökning och mer säkerhet. Externa inloggningsuppgifter finns i grunden för denna modell. De lagrar de faktiska autentiseringsdetaljerna och har stöd för en omfattande uppsättning protokoll, inklusive OAuth 2.0 Client Credentials, JWT Bearer och AWS Signature V4, samtidigt som de definierar hur principer mappas: antingen som en enskild namngiven princip (delad över alla användare) eller som principer per användare (där varje användare autentiserar med sin egen identitet). Autentiseringsuppgifter fungerar i sin tur som slutpunktslagret — de definierar anrops-URL:en och refererar till en extern autentiseringsuppgift för att hantera autentiseringshandskakningen, vilket håller slutpunktskonfigurationen rent frånkopplad från inloggningshantering. För att aktivera autentiseringsflöden per användare mappar administratörer behörighetsuppsättningar till lämplig princip för Externa inloggningsuppgifter, vilket säkerställer att endast användare med rätt tilldelning av behörighetsuppsättningar kan åberopa anrop under sin egen identitet. Denna design i två nivåer förenklar inte bara säker anropskonfiguration utan ger även arkitekter mycket större flexibilitet och styrningskontroll över hur integreringar autentiseras över Salesforce-anslutna system. Mer information finns i dokumentationen Autentiseringsuppgifter.
OAuth 2.0: OAuth 2.0 är ett auktoriseringsramverk av branschstandard som låter en användare bevilja begränsad åtkomst till sina skyddade resurser till ett tredjepartsprogram utan att dela sina inloggningsuppgifter (som lösenord). Istället för ett direkt lösenordsutbyte godkänner användaren en åtkomsttokenbegäran, som programmet sedan använder för att komma åt användarens data från en resursserver. Denna process separerar klientprogrammet från användarens identitet och lösenord, vilket förbättrar säkerheten genom att tillhandahålla en tillfällig, omfattningsspecifik "nyckel" för åtkomst till resurser. Mer information finns i OAuth 2.0-dokumentationen. För slutpunkter med strikt OAuth 2.1-efterlevnad är en tredje nivå av arkitekturen tillgänglig (Extern autentiseringsidentitetsleverantör) för att hantera interaktionen med IDP på ett 2.1-kompatibelt sätt.
Privat anslutning: När du integrerar din Salesforce-organisation med program som värdas i molntjänster från tredje part är det viktigt att kunna skicka och ta emot HTTP/s-trafik säkert. Med Privat anslutning, öka säkerheten för dina Amazon Web Services-integreringar (AWS) genom att konfigurera en fullständigt hanterad nätverksanslutning mellan din Salesforce-organisation och ditt AWS Virtual Private Cloud (VPC). Dirigera sedan din molntrafik genom anslutningen istället för över det offentliga internet för att minska exponeringen för externa säkerhetshot. Privat anslutning är tillgänglig i samarbete med AWS via en funktion som heter AWS PrivateLink. Privat anslutning är dubbelriktad: du kan inleda både inkommande och utgående trafik. Med inkommande anslutningar kan du skicka trafik till Salesforce med hjälp av standard-API:n. Och med utgående anslutningar kan du skicka trafik från Salesforce via funktioner som Apex anrop, externa tjänster och externa objekt. Mer information finns i dokumentationen för Privat anslutning.

Salesforce-händelsebussen med plattformshändelser, datainsamling (CDC) och Pub/Sub API låter företag skapa händelsedrivna formatarkitekturer (EDA).

En EDA kopplar bort konsumenter av händelsemeddelanden (prenumeranter) från tillverkare av händelsemeddelanden (utgivare), vilket ger större skala och flexibilitet. Specifika mönster behandlas i detta dokument som en del av den befintliga mönsterstrukturen som jämför och kontrasterar relaterade alternativ eller alternativ. Att få en helhetsbild av den händelsedrivna arkitekturen och hur mönster interagerar kan dock hjälpa dig välja rätt mönster för dina behov.

Khalid Mohammed är en framstående arkitektledare inom Salesforces Professional Services. Sedan han började på Salesforce 2015 har han utnyttjat sin omfattande expertis inom Enterprise Application och arkitektur, och finslipat flera kundtransformationer innan han började på Salesforce. Khalid leder styrelsen för leveransarkitektur och är även erkänd som en certifierad teknisk arkitektledare.

Gulal Kumar är arkitekt inom programvaruteknik på Salesforce, med fokus på data- och integrationsarkitektur. Med över 21 års erfarenhet av integrering och API, moderniseringsprogram, säkerhet och AIML-initiativ bidrar han med en mängd expertis. Gulal har engagerat sig i att främja initiativ för verksamhetstransformation, förbättra säkerhet och motståndskraft, främja arkitekturexcellens och leda AIML-initiativ över olika domäner.

Sushant Verma är teknisk arkitekt på Salesforce och specialiserar sig på lösningsarkitektur och helhetsleverans av Salesforce-plattformar. Med djup expertis inom plattformsstyrning, applikationsutveckling, integration och DevOps har han lett många kundtransformationsprogram i olika branscher. Sushant strävar efter att driva leveranskvalitet och skalbara arkitektoniska resultat.