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. Detta innehåll är en destillation av många framgångsrika implementeringar av Salesforces arkitekter och partners.

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 Mönstersammanfattning och Guide för att välja mönster. Arkitekter och utvecklare bör överväga 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. Detta ger enhetlighet i informationen i varje mönster och gör det även enklare att jämföra mönster.

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 remote-process-invocation--request-and-reply

Mönstermetod

Integreringsmönstren i detta dokument klassificeras i tre kategorier:

• Dataintegrering—Dessa mönster uppfyller kravet 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.

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.

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.

Termer och definitioner för programvara

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

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.

Skiss

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

Salesforce anropar ett fjärrsystem

Nedladdningsdiagram

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.

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—När ett fel inträffar (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.

• Återställning—Ändringar görs inte i 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 via användargränssnittet måste vi ta hand om bristande kapacitet på integreringslagret, särskilt om det inte finns någon garanti för att Salesforce endast ringer 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 till 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.

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.

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.

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 och Salesforce ska återspegla faktureringskontonumret i orderaktiveringsprocessen. De har en befintlig webbtjänst 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.

1. Salesforce använder WSDL för faktureringskontotjänsten från en Apex proxyklass.
2. Kör Apex proxyklass med kundinformationen som skickas till den externa webbtjänsten från en egen Apex kontroll eller extern tjänst.
3. Den egna kontrollen tolkar sedan returvärdena från Apex och lagrar denna information i Salesforce-objektet.

Detta exempel visar att:

• Kundens status följs med ett kontonummer som lagras i Salesforce-kontoobjektet.
• Uppringarens efterföljande bearbetning av 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.

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.

Nedladdningsdiagram

I detta scenario:

1. Ett fjärrsystem prenumererar på plattformshändelsen.
2. En uppdatering eller infogning inträffar för en given uppsättning poster i Salesforce.
3. Ett Salesforce-flöde utlöses när en uppsättning villkor uppfylls.
4. Detta flöde skapar en plattformshändelse.
5. Fjärrlyssnaren tar emot händelsemeddelandet och placerar meddelandet i en lokal kö.
6. 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.

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.

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.

Idempotens är viktigt för utgående meddelanden eftersom det är asynkront och försök inleds om inget positivt godkännande mottas. Därför måste fjärrtjänsten kunna hantera meddelanden från Salesforce på ett idempotent sätt.

Utgående meddelanden skickar ett unikt ID per meddelande och detta ID förblir samma för alla försök. Fjärrsystemet kan spåra dubbletter av meddelanden baserat på detta unika ID. Det unika post-ID:t för varje post som uppdateras skickas också och kan användas för att förhindra att dubbletter av poster skapas.

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.

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. Med Salesforces utgående meddelanden måste bekräftelsen ske inom 24 timmar (detta kan utökas till sju dagar), annars går meddelandet ut. 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 CometD-klienter 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.

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.

Komplexa integreringsscenarion

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

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 luckhändelse innehåller information om ändringen i sidhuvudet, till exempel ändringstyp och post-ID. Den innehåller inte detaljer om ändringen, som 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.

Middleware-kapacitet

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

Lösningsvariant—Plattformshändelser: Publiceringsbeteende och transaktioner

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 en ESB som har stöd för CometD-protokollet och kan 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:

• ESB prenumererar på Salesforce Platform-händelsen med CometD-protokollet.
• 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 SessionId som autentiseringstoken. 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.

Skiss

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

Nedladdningsdiagram

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

Resultat

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

• Externt system är datahuvudet—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 klientprogram för Salesforce 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 används sedan för att skapa program som:

1. Läs en kontrolltabell för att avgöra den senaste körtiden för jobbet och extrahera andra kontrollvärden som behövs.
2. Använd ovanstående kontrollvärden som filter och fråga källdatauppsättningen.
3. Tillämpa fördefinierade bearbetningsregler, inklusive validering, berikning och så vidare.
4. Använd tillgängliga anslutare/transformationsmöjligheter för ETL-verktyget för att skapa destinationsdatauppsättningen.
5. Skriv datauppsättningen till Salesforce-objekt.
6. Om bearbetningen lyckas, uppdatera kontrollvärdena i kontrolltabellen.
7. 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.

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.

• En Lightning Platform-licens med minst användarbehörigheterna “Endast API” krävs för att tillåta autentiserad API-åtkomst till Salesforce 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 tekniker som används för att implementera detta mönster är traditionella ETL-verktyg. Det är viktigt att de middleware-verktyg som väljs har stöd för Salesforce Bulk API.

Det är bra, men inte viktigt, att middleware-verktygen har stöd för funktionen getUpdated(). Denna funktion ger den implementering som är närmast standardkapaciteten för datainsamling på Salesforce Platform.

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

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.

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 SOAP API

Fjärrsystem som 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 CometD-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.

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 — En egen försöksmekanism måste skapas 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.

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.

Stöd för slutpunktskapacitet och standarder

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

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.

Komplexa integreringsscenarion

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

Governorgränser

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

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:

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. Det säkerställer även hållbara ämnen med ett reprisfönster på 72 timmar. Detta säkerställer 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
• En JavaScript-baserad implementering av Bayeuxprotokollet (för närvarande CometD) som kan användas av användargränssnittet
• En Lightning
• Ett JavaScript-bibliotek inkluderat som en statisk resurs

Skiss

Följande diagram illustrerar hur Streaming 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

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. Webbläsare som stöds listas i Streaming API Developer Guide

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 ett Apex Trigger PushTopic 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å händelsebussen 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.

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.

I detta scenario:

1. Webbläsaren utför ett AJAX-anrop som i sin tur utför en åtgärd på motsvarande externa objektadapter.
2. 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.
3. Fjärrsystemet returnerar ett JSON-svar till Salesforce via lagren Integrering och Tjänster.
4. 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.

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

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

Stödet för kapacitet och standarder för slutpunkten beror på vilken lösning du väljer.

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.

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.

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.

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 för 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

• Salesforce-hjälpen: Ge endast åtkomst till Integreringsanvändares API

• SOAP API Developer Guide

• REST API Developer Guide

• Utvecklarguide för Streaming API

• Bulk API 2.0 och Bulk API Developer Guide

• Apex Developer Guide

• SOQL- och SOSL-referens

• Snabbreferens för gränser och allokeringar för Salesforce Developer

• Utvecklarguide för plattformshändelser

• Apex Developer Guide: Salesforce Connect

Trailhead

• Stora datavolymer

• Grunder för plattformshändelser

• Grunderna för datainsamling

• Snabbstart: Salesforce Connect

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 nginix 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 (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

• Autentiseringsuppgifter: Avsedd att säkra och förenkla autentiserade API-anrop till externa system specificerar en autentiseringsuppgift URL:en för ett anrops slutpunkt och dess obligatoriska autentiseringsparametrar i en definition. För att effektivisera din Apex kod och förenkla konfigurationen av autentiserade anrop, specificera en autentiseringsuppgift som anropets slutpunkt. Mer information finns här.

• 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 här.

• 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 om VPC finns här.

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 20 å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 ä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.