Oversigt over integrationsmønstre

Når du implementerer Salesforce, skal du typisk integrere det med andre applikationer. Selvom hvert integrationsscenarie er entydigt, er der fælles krav og problemer, som udviklere og arkitekter skal løse.

Dette dokument beskriver strategier (i form af mønstre) for disse almindelige integrationsscenarier. Hvert mønster beskriver designet og tilgangen for et bestemt scenarie i stedet for at beskrive en specifik implementering. I dette dokument finder du:

Et antal mønstre, der håndterer nøgle- "arketype"-integrationsscenarier
En valgmatrix til at hjælpe med at bestemme, hvilket mønster der bedst passer til dit scenarie
Integrationstips og bedste fremgangsmåder

Formål og omfang

Dette dokument er til designere og arkitekter, der har brug for at integrere Salesforce Platform med andre applikationer i deres virksomhed. Vi har distilleret dette indhold fra mange vellykkede implementeringer.

Hvis du vil gøre dig bekendt med integrationsfunktioner og indstillinger, der er tilgængelige for ibrugtagning i stor skala af Salesforce-baserede applikationer, kan du læse mønstersammendraget og vejledningen til mønstervalg. Architekter og udviklere bør anvende disse mønsterdetaljer og bedste fremgangsmåder under design- og implementeringsfasen af et Salesforce-integrationsprojekt.

Hvis de implementeres korrekt, giver disse mønstre dig mulighed for at komme i produktion så hurtigt som muligt og have det mest stabile, skalerbare og vedligeholdelsesfrie sæt af applikationer. Salesforces egne konsulentarkitekter bruger disse mønstre som referencepunkter under arkitektoniske gennemgange og vedligeholder og forbedrer dem aktivt.

Som med alle mønstre dækker dette indhold de fleste integrationsscenarier, men ikke alle. Mens Salesforce tillader brugergrænsefladeintegration (UI), er en sådan integration f.eks. uden for dette dokuments omfang.

Mønsterskabelon

Hvert integrationsmønster følger en ensartet struktur. Denne struktur gør det nemmere at sammenligne mønstre og finde relevante oplysninger.

Navn

Den mønsteridentifikator, der også angiver den type integration, der er indeholdt i mønsteret.

Kontekst

Det generelle integrationsscenarie, som mønsteret håndterer. Kontekst giver oplysninger om, hvad brugere forsøger at opnå, og hvordan applikationen optræder for at understøtte kravene.

Problem

Det scenarie eller det problem (udtrykt som et spørgsmål), som mønsteret er designet til at løse. Når du gennemser mønstrene, kan du læse dette afsnit for hurtigt at forstå, om mønsteret er relevant for dit integrationsscenarie.

Kræfter

De begrænsninger og omstændigheder, der gør det angivne scenarie vanskeligt at løse.

Løsning

Den anbefalede måde at løse integrationsscenariet på.

Sketch

Et UML-sekvensdiagram, der viser dig, hvordan løsningen håndterer scenariet.

Resultater

Forklarer detaljerne for, hvordan du anvender løsningen på dit integrationsscenarie, og hvordan det løser de kræfter, der er knyttet til dette scenarie. Dette afsnit indeholder også nye udfordringer, der kan opstå som et resultat af anvendelse af mønsteret.

Sidebars

Yderligere afsnit, der er relateret til mønsteret, der indeholder vigtige tekniske problemer, variationer af mønsteret, mønsterspecifikke problemer osv.

Eksempel

Et end-to-end-scenarie, der beskriver, hvordan designmønsteret bruges i et Salesforce-scenarie i den virkelige verden. Eksemplet forklarer integrationsmålene, og hvordan du implementerer mønsteret for at nå disse mål.

Mønstersammendrag

Følgende tabel viser de integrationsmønstre, der er indeholdt i dette dokument.

Liste over mønstre

Mønstre	Scenario
Fjernproceskald – anmodning og svar	Salesforce kalder en proces på et fjernsystem, venter på fuldførelse af denne proces og sporer derefter tilstanden baseret på svaret fra fjernsystemet.
Fjernproceskald – brand og glem	Salesforce kalder en proces i et fjernsystem, men venter ikke på fuldførelse af processen. I stedet modtager og bekræfter fjernprocessen anmodningen og overfører derefter kontrollen tilbage til Salesforce.
Batchdatasynkronisering	Data, der er lagret i Salesforce Platform, oprettes eller opdateres til at afspejle opdateringer fra et eksternt system, og når ændringer fra Salesforce Platform sendes til et eksternt system. Opdateringer i begge retninger udføres på en batchmetode.
Fjernopkald	Data, der er lagret i Salesforce Platform, oprettes, hentes, opdateres eller slettes af et fjernsystem.
UI-opdatering baseret på dataændringer	Salesforce-brugergrænsefladen skal opdateres automatisk som et resultat af ændringer af Salesforce-data.
Datavirtualisering	Salesforce får adgang til eksterne data i realtid. Dette fjerner behovet for at bevare data i Salesforce og derefter afstemme dataene mellem Salesforce og det eksterne system.

Mønstertilgang

Integrationsmønstrene i dette dokument er klassificeret i tre kategorier:

Dataintegration: Disse mønstre håndterer kravet om at synkronisere data, der findes i to eller flere systemer, så begge systemer altid indeholder rettidige og meningsfulde data. Dataintegration er ofte den enkleste type integration, der kan implementeres, men kræver korrekte oplysningsstyringsteknikker for at gøre løsningen bæredygtig og omkostningseffektiv. Sådanne teknikker omfatter ofte aspekter af overordnet datastyring (MDM), dataadministration, mastering, fjernelse af dubletter, dataforløbsdesign og andre.
Procesintegration: Mønstrene i denne kategori håndterer behovet for, at en forretningsproces kan bruge to eller flere applikationer til at fuldføre dens opgave. Når du implementerer en løsning til denne type integration, skal den udløsende applikation kalde på tværs af procesgrænser til andre applikationer. Disse mønstre inkluderer sædvanligvis både orkestrering (hvor en applikation er den centrale "controller") og koreografi (hvor applikationer er flerdeltagere, og der ikke er nogen central "controller"). Disse integrationer kræver ofte komplekse krav til design, test og undtagelseshåndtering. Og sådanne sammensatte applikationer er typisk mere krævende på de underliggende systemer, fordi de ofte understøtter længe kørende transaktioner og muligheden for at rapportere om eller administrere procestilstand.
Virtuel integration: Mønstrene i denne kategori håndterer behovet for, at en bruger kan se, søge og redigere data, der er lagret i et eksternt system. Når du implementerer en løsning til denne type integration, skal den udløsende applikation ringe til andre applikationer og interagere med deres data i realtid. Denne type integration fjerner behovet for datareplikering på tværs af systemer og betyder, at brugere altid interagerer med de mest aktuelle data.

Valg af den bedste integrationsstrategi for dit system er ikke trivielt. Der er mange aspekter, der skal overvejes, og mange værktøjer, der kan bruges, med nogle værktøjer, der er mere relevante end andre for bestemte opgaver. Hvert mønster håndterer specifikke kritiske områder, herunder funktionerne i hvert af systemerne, mængden af data, fejlhåndtering og transaktionalitet.

Mønsterudvælgelsesvejledning

Valgmatrikstabellerne viser mønstrene og deres nøgleaspekter for at hjælpe dig med at bestemme, hvilket mønster der bedst passer til dine integrationskrav. Mønstrene kategoriseres ved brug af disse dimensioner.

Aspekt	Beskrivelse
Type	Angiver integrationens typografi: Proces, data eller virtuel. Proces: Procesbaserede integrationer er måder til at integrere behandling af funktionelt forløb på tværs af to eller flere applikationer. Disse integrationer involverer typisk et højere niveau af abstraktion og kompleksitet, især for transaktionalitet og tilbagerulning. Data: Dataintegrationer er integrationen af de oplysninger, der bruges af applikationer. Disse integrationer kan variere fra en enkelt tabelindsættelse eller upsert til komplekse dataopdateringer, der kræver referenceintegritet og komplekse oversættelser. Virtuelt: Virtuale integrationer er de steder, hvor Salesforce interagerer med data, der findes i et eksternt system, uden behov for at replikere de data, der findes i Salesforce. Denne type integration udløses altid via en begivenhed fra Salesforce-platformen, f.eks. en brugerhandling, en søgning eller en registreringsopdatering, hvilket resulterer i dataintegration med en ekstern kilde i realtid.
Tid	Angiver integrationstypografien baseret på timing: Synkron eller Asynkron. Synkron: Blokering og anmodninger i realtid er anmodnings-/svarhandlinger. Resultatet returneres straks til opkalderen via denne handling. Asynkron: Ikke-blokerende, købaserede eller meddelelsesbaserede anmodninger kaldes af en envejshandling, der er næsten realtid. Resultaterne og eventuelle fejl returneres ved at kalde andre envejshandlinger. Opkalderen foretager derfor anmodningen og fortsætter uden at vente på et svar.

Aspekt

Beskrivelse

Type

Angiver integrationens typografi: Proces, data eller virtuel.

Proces: Procesbaserede integrationer er måder til at integrere behandling af funktionelt forløb på tværs af to eller flere applikationer. Disse integrationer involverer typisk et højere niveau af abstraktion og kompleksitet, især for transaktionalitet og tilbagerulning.

Data: Dataintegrationer er integrationen af de oplysninger, der bruges af applikationer. Disse integrationer kan variere fra en enkelt tabelindsættelse eller upsert til komplekse dataopdateringer, der kræver referenceintegritet og komplekse oversættelser.

Virtuelt: Virtuale integrationer er de steder, hvor Salesforce interagerer med data, der findes i et eksternt system, uden behov for at replikere de data, der findes i Salesforce. Denne type integration udløses altid via en begivenhed fra Salesforce-platformen, f.eks. en brugerhandling, en søgning eller en registreringsopdatering, hvilket resulterer i dataintegration med en ekstern kilde i realtid.

Tid

Angiver integrationstypografien baseret på timing: Synkron eller Asynkron.

Synkron: Blokering og anmodninger i realtid er anmodnings-/svarhandlinger. Resultatet returneres straks til opkalderen via denne handling.

Asynkron: Ikke-blokerende, købaserede eller meddelelsesbaserede anmodninger kaldes af en envejshandling, der er næsten realtid. Resultaterne og eventuelle fejl returneres ved at kalde andre envejshandlinger. Opkalderen foretager derfor anmodningen og fortsætter uden at vente på et svar.

Integrering af Salesforce med et andet system

Denne tabel viser mønstrene og deres nøgleaspekter for at hjælpe dig med at bestemme, hvilket mønster der bedst passer til dine krav, når din integration er fra Salesforce til et andet system.

Type	Tid	Nøglemønster, du bør overveje
Procesintegration	Synkron	Fjernproceskald – anmodning og svar
Procesintegration	Asynkron	Fjernproceskald – brand og glem
Dataintegration	Synkron	Fjernproceskald – anmodning og svar
Dataintegration	Asynkron	UI-opdatering baseret på dataændringer
Virtuel integration	Synkron	Datavirtualisering

Integrering af et andet system med Salesforce

Denne tabel viser mønstrene og deres nøgleaspekter for at hjælpe dig med at bestemme det mønster, der bedst passer til dine krav, når din integration er fra et andet system til Salesforce.

Type	Tid	Nøglemønster, du bør overveje
Procesintegration	Synkron	Fjernopkald
Procesintegration	Asynkron	Fjernopkald
Dataintegration	Synkron	Fjernopkald
Dataintegration	Asynkron	Batchdatasynkronisering

Middleware Termer og definitioner

Denne tabel viser nogle nøgleudtryk, der er relateret til middleware og deres definitioner med hensyn til disse mønstre.

Vilkår	Definition
Begivenhedshåndtering	Begivenhedshåndtering er modtagelse af en identificerbar forekomst hos en udpeget modtager ("handler"). De nøgleprocesser, der er involveret i begivenhedshåndtering, inkluderer: Identificering af, hvor en begivenhed skal videresendes Udførelse af denne videresendelseshandling Modtagelse af en videresendt begivenhed Udførelse af en relevant handling som svar, f.eks. skrivning til en logfil, afsendelse af en fejl- eller gendannelsesproces eller afsendelse af en ekstra meddelelse Husk på, at begivenhedshandleren i sidste ende kan videresende begivenheden til en begivenhedsforbruger. Almindelige anvendelser af denne funktion med middleware kan udvides til at inkludere den populære "udgiv/abonner" eller "pub/sub"-funktionalitet. I et udgiv/abonnementscenarie distribuerer middleware anmodninger eller meddelelser til aktive data-begivenhedsabonnenter fra aktive data-begivenhedsudgivere. Disse forbrugere med aktive lytterbrugere kan derefter hente begivenhederne, efterhånden som de udgives. I Salesforce-integrationer, der bruger middleware, overtager middleware-laget kontrol over begivenhedshåndtering. Den indsamler alle relevante begivenheder, synkrone eller asynkrone, og administrerer distribution til alle slutpunkter, herunder Salesforce. Alternativt kan denne funktion opnås ved brug af Salesforce-begivenhedsbussen med platformsbegivenheder.
Protokolkonvertering	Protokolkonvertering er typisk en softwareapplikation, der konverterer standardprotokollen eller den beskyttede protokol for en enhed til den protokol, der er egnet til en anden enhed for at opnå interoperabilitet. I konteksten af middleware kan forbindelsen til et bestemt målsystem være begrænset af protokol. I sådanne situationer skal meddelelsesformatet konverteres til eller indkapsles i formatet på målsystemet, hvor dataene kan udtrækkes. Dette kaldes også tunneling. Salesforce understøtter ikke den oprindelige protokolkonvertering, så det antages, at sådanne krav opfyldes af middleware-laget eller slutpunktet.
Oversættelse og transformation	Transformation er muligheden for at tilknytte et dataformat til et andet for at sikre interoperabilitet mellem de forskellige systemer, der integreres. Typisk involverer processen omformatering af meddelelser undervejs, så de matcher kravene for afsenderen eller modtageren. I mere komplekse situationer kan en applikation sende en meddelelse i sit eget oprindelige format, og to eller flere andre applikationer kan hver modtage en kopi af meddelelsen i deres eget oprindelige format. Mellemvareoversættelses- og transformationsværktøjer inkluderer ofte muligheden for at oprette servicefacader for ældre eller andre ikke-standardslutpunkter. Disse servicefacader tillader, at disse slutpunkter vises som servicemæssige. Med Salesforce-integrationer antages det, at alle sådanne krav opfyldes af middleware-laget eller slutpunktet. Mens middleware stadig foretrækkes for komplekse transformationer, er Salesforce-platformen moden. OmniStudio-integrationsprocedurer, forløbsdatatilknytning og Apex med moderne mønstre er alle tilgængelige for moderate transformationer.
Kø og buffering	Kø og buffering er generelt baseret på asynkron meddelelsesoverførsel i modsætning til en anmodnings-svar-arkitektur. I asynkrone systemer giver meddelelseskøer midlertidig lagring, når destinationsprogrammet er optaget, eller forbindelsen er kompromitteret. Endvidere leverer de fleste asynkrone middleware-systemer vedvarende lager til sikkerhedskopiering af meddelelseskøen. Nøglefordelen ved en asynkron meddelelsesproces er, at hvis modtagerapplikationen mislykkes af en eller anden grund, kan afsendere fortsætte upåvirket. De sendte meddelelser akkumuleres ganske enkelt i meddelelseskøen til senere behandling, når modtageren genstarter. Salesforce leverer asynkrone funktioner i form af ændringsdataregistrering / platformsbegivenheder med Pub/Sub API. Hvis du vil levere sande meddelelser i kø for andre integrationsscenarier, herunder orkestrering, proces koreografi og servicekvalitet, kræves der en middleware-løsning.
Synkrone transportprotokoller	Synkrone transportprotokoller refererer til protokoller, der understøtter aktiviteter, hvor en "enkelttråd i opkalderen sender anmodningsmeddelelsen, blokerer for at vente på svarmeddelelsen og derefter behandler svaret....Anmodningstråden, der venter på svaret, angiver, at der kun er en udestående anmodning, eller at svarkanalen for denne anmodning er privat for denne tråd."
Asynkrone transportprotokoller	Asynkrone transportprotokoller refererer til protokoller, der understøtter aktiviteter, hvor "en tråd i opkalderen sender anmodningsmeddelelsen og opsætter et tilbagekald for svaret. En separat tråd lytter efter svarmeddelelser. Når der ankommer en svarmeddelelse, kalder svartråden det relevante tilbagekald, som genopretter opkalderens kontekst og behandler svaret. Denne tilgang aktiverer flere udestående anmodninger til at dele en enkelt svartråd".
Mediationsdistribution	Mediationdistribution er specifikationen af et komplekst "forløb" af meddelelser fra komponent til komponent. F.eks. afhænger mange middleware-baserede løsninger af et meddelelseskøsystem. Mens nogle implementeringer tillader, at distributionslogik leveres af selve meddelelsesslaget, afhænger andre af klientapplikationer til at levere distributionsoplysninger eller tillade en blanding af begge paradigmer. I sådanne komplekse situationer forenkler mediation fra middleware udvikling, integration og validering. En mediator sikrer, at den rigtige meddelelse når den rigtige forbruger.
Proces koreografi og serviceorkestrering	Proces koreografi og serviceorkestrering er hver form for "servicesammensætning", hvor et hvilket som helst antal slutpunkter og funktioner koordineres. Forskellen mellem koreografi og serviceorkestrering er: Koreografi kan defineres som en asynkron tilgang, der gør det muligt for processer at arbejde autonomt og fjerne eventuelle problemer forårsaget af afhængigheder, som er adfærd, der er et resultat af en gruppe af interagerende individuelle enheder uden nogen central autoritet. Orkestrering kan defineres som en synkron tilgang, der aktiverer kørsel af en forespørgsel eller proces ved at tillade, at hver mikroservice implementerer opgaver, der er tildelt af orkestrator, hvilket er adfærd, der er resultatet af en central conductor, der koordinerer adfærden af individuelle enheder, der udfører opgaver uafhængigt af hinanden. Desuden viser en orkestrering den komplette adfærd for hver tjeneste, mens koreografien kombinerer beskrivelser af grænsefladens adfærd for hver tjeneste. Dele af forretningsproceschoreografier kan opbygges i forløbsorkestrering, Salesforce-arbejdsflows eller ved brug af Apex. Salesforce-indbygget forløbsorkestrering leverer lange kørende processer med flere trin med baggrunds-, interaktive og MuleSoft-trin. Dens oprindelige funktioner kan orkestrere uden mellemudstyr ved hjælp af indbygget faseadministration og tildelingsdistribution. Vi anbefaler implementering af alle komplekse krydssystemorkestrering i middleware-laget for at undgå Salesforce-timeout og styringsbegrænsninger, især i løsninger, der kræver sand transaktionshåndtering.
Transaktionalitet (kryptering, signering, pålidelig levering, transaktionsstyring)	Transaktionalitet kan defineres som muligheden for at understøtte globale transaktioner, der omfatter alle nødvendige handlinger op mod hver krævet ressource. Transaktionalitet angiver understøttelse af alle fire ACID-egenskaber, atomicitet, ensartethed, isolation, holdbarhed, hvor atomicitet garanterer alle-eller-ingen-resultater for arbejdsenheden (transaktion). Selvom Salesforce er transaktionel i sig selv, kan det ikke deltage i distribuerede transaktioner eller transaktioner, der er startet uden for Salesforce. Derfor antages det, at for løsninger, der kræver komplekse, multi-system-transaktioner, implementeres transaktionalitet og tilknyttede tilbagerulnings-/kompensationsmekanismer på middleware-laget.
Distribution	Distribution kan defineres som angivelse af det komplekse forløb af meddelelser fra komponent til komponent. I moderne servicebaserede løsninger kan sådanne meddelelsesforløb være baseret på en række kriterier, herunder sidehoved, indholdstype, regel og prioritet. For Salesforce-integrationer antages det, at disse kriterier opfyldes af middleware-laget eller slutpunktet, men meddelelsesdistribution kan også kodes i Apex.
Udtræk, transformer og indlæs	Udtræk, transformer og indlæs (ETL) henviser til en proces, der involverer: Udtrækning af data fra kildesystemerne. Denne proces involverer typisk data fra flere kildesystemer og både relationelle og ikke-relationelle strukturer. Transformering af dataene, så de passer til driftsmæssige behov, som kan inkludere datakvalitetsniveauer. Transformeringsfasen anvender sædvanligvis en række regler eller funktioner på de udtrukne data fra kilden for at aflede dataene til indlæsning i slutmålet(e). Indlæsning af data i målsystemet. Målsystemet kan variere meget fra database, driftsmæssigt datalager, datamarkt, datalager eller andre operativsystemer. Selvom det ikke er strengt nødvendigt, giver de fleste modne ETL-værktøjer en dataregistrering for ændringsdata. Denne funktion er det sted, hvor værktøjet identificerer registreringer i kildesystemet, der er ændret siden den sidste udtrækning, hvilket reducerer mængden af registreringsbehandling. Salesforce understøtter også Change Dataregistrering, som er udgivelsen af ændringsbegivenheder, der repræsenterer ændringer af Salesforce-registreringer. Med Change Dataregistrering modtager klienten eller det eksterne system ændringer i næsten realtid af Salesforce-registreringer. Med disse oplysninger kan klienten eller det eksterne system synkronisere tilsvarende registreringer i et eksternt datalager.
Lang polling	Lang polling, også kaldet Comet-programmering, emulerer en push-oplysning fra en server til en klient. I lighed med en normal afstemning opretter klienten forbindelse og anmoder om oplysninger fra serveren. Men i stedet for at sende et tomt svar, hvis oplysninger ikke er tilgængelige, bevarer serveren anmodningen og venter, indtil oplysningerne er tilgængelige (en begivenhed forekommer). Serveren sender derefter et komplet svar til klienten. Klienten anmoder straks om oplysninger igen. Klienten vedligeholder kontinuerligt en forbindelse til serveren, så den altid venter på at modtage et svar. Hvis serveren udløber, opretter klienten forbindelse igen og starter forfra. Salesforce Streaming API bruger Bayeux-protokollen og CometD til lang polling. Bayeux er en protokol til transport af asynkrone meddelelser, primært over HTTP. CometD er en skalerbar HTTP-baseret begivenhedsdistributionsbus, der bruger et AJAX-push-teknologimønster, der kaldes Comet. Den implementerer Bayeux-protokollen. Denne mekanisme er en forældet integrationsmåde. Alle nye løsninger skal bruge Pub/Sub API.

Udover disse integrationsværktøjer leverer MuleSoft og Informatica grundlæggende søjler til en moderne, højtydende integrationsstrategi. Selvom begge findes i det samme økosystem, løser de forskellige arkitektoniske udfordringer. Ledende virksomheder implementerer disse platforme sammen for at skabe en omfattende "bedre sammen"-struktur, der opfylder hele spektret af data- og applikationsbehov.

MuleSoft er Salesforces førende integrationsplatform. Den gør det muligt for organisationer at tilslutte applikationer, data og enheder på tværs af lokale miljøer og cloudmiljøer. MuleSoft giver it værktøjerne til at låse data op på tværs af systemer, udvikle skalerbare integrations- og automatiseringsstrukturer og oprette differentierede, tilsluttede oplevelser med fart. Det kan også tilslutte en kerneorganisation til en Anypoint-forekomst i et API-katalog for at gøre MuleSoft-API'er tilgængelige til kald i Apex, Forløb og Agentforce som handlinger. Anypoint Exchange har et antal Salesforce-forbindelser, der er bygget på forhånd.

Informatica er en førende virksomhedsdatastyrings- og integrationsplatform. Det hjælper organisationer med at indsamle, administrere, integrere og analysere data fra forskellige kilder. Den bruger ETL-processer (Extract, Transform, Load) til at levere de tilsluttede, pålidelige data, der er nødvendige for at fremme moderne analyser og autonome AI-agenter.

Kontekst

Du bruger Salesforce til at spore emner, administrere din pipeline, oprette salgsmuligheder og registrere bestillingsdetaljer, der konverterer emner til kunder. Men Salesforce-systemet indeholder eller behandler ikke bestillinger. Når bestillingsdetaljerne er registreret i Salesforce, oprettes bestillingen i fjernsystemet, som administrerer bestillingen til afslutning.

Når du implementerer dette mønster, kalder Salesforce fjernsystemet for at oprette bestillingen og venter derefter på en vellykket fuldførelse. Hvis det lykkes, svarer fjernsystemet synkront med bestillingsstatussen og bestillingsnummeret. Som en del af den samme transaktion opdaterer Salesforce bestillingsnummeret og statussen internt. Bestillingsnummeret bruges som en fremmed nøgle til efterfølgende opdateringer af fjernsystemet.

Problem

Når der forekommer en begivenhed i Salesforce, hvordan starter du en proces i et fjernsystem, overfører de krævede oplysninger til den pågældende proces, modtager et svar fra fjernsystemet og bruger derefter disse svardata til at foretage opdateringer i Salesforce?

Kræfter

Overvej følgende kræfter, når du anvender løsninger baseret på dette mønster.

Kræver opkaldet til fjernsystemet, at Salesforce venter på et svar, før det fortsætter behandlingen? Er opkaldet til fjernsystemet et synkront anmodningssvar eller en asynkron anmodning?
Hvis opkaldet til fjernsystemet er synkront, skal Salesforce behandle svaret som en del af den samme transaktion som det indledende opkald?
Er meddelelsesstørrelsen lille eller stor?
Er integrationen baseret på forekomsten af en specifik begivenhed, f.eks. et knapklik i Salesforce-brugergrænsefladen eller DML-baserede begivenheder?
Kan fjernslutpunktet besvare anmodningen med lav forsinkelse? Hvor mange brugere, der sandsynligvis udfører denne transaktion i en spidsperiode?

Løsning

Denne tabel indeholder løsninger på dette integrationsproblem.

Løsning	Tilpas	Kommentarer
Eksterne tjenester kalder et REST API-kald	Best	Eksterne tjenester giver dig mulighed for at kalde en eksternt hostet tjeneste på en deklarativ måde (ingen kode påkrævet). Denne funktion bruges bedst, når følgende betingelser er opfyldt: Den eksternt hostede tjeneste er en RESTful-tjeneste, og definitionerne er tilgængelige i et OpenAPI 2.0- eller OpenAPI 3.0- eller YAML-skemaformat. Anmodnings- og svardefinitionerne indeholder primitive datatyper, f.eks. boolesk, datotid, dobbelt, heltal, streng eller en opstilling af primitive datatyper. Indlejrede objekttyper og afsendelsesparametre, f.eks. sidehoveder i HTTP-anmodninger understøttes. Bemærk: Hvis den eksternt hostede tjeneste er RESTful, men OpenAPI-specifikationen ikke er tilgængelig eller mulig, skal du bruge Navngivne legitimationsoplysninger i Apex til at foretage HTTP-udkald direkte. Der skal bruges Apex til at parse resultaterne. Transaktionen kan kaldes fra et forløb.
Salesforce Lightning – Lightning eller -side starter et synkront Apex REST- eller SOAP-udkald. Hvis fjernslutpunktet udgør en risiko for et højt forsinkelsessvar (se dokumentationen for seneste grænser for de gældende grænser her), anbefales der et asynkront udkald, også kaldet et fortsættelse, for at undgå at ramme grænser for synkron Apex	Best	Salesforce gør det muligt for dig at bruge en WSDL og generere en resulterende Apex. Denne klasse leverer den nødvendige logik til at kalde fjerntjenesten. Salesforce giver dig også mulighed for at kalde HTTP-tjenester (REST) ved brug af standardmetoderne GET, POST, PUT og DELETE. En brugerinitieret handling på en Lightning kalder derefter en Apex for at udføre denne proxy Apex for at udføre fjernkaldet ved brug af navngivne legitimationsoplysninger. Lightning kræver tilpasning af Salesforce-applikationen.
HTTP-udkaldshandling i forløb	God	Denne løsning tillader synkrone udgående REST-kald deklarativt fra forløb uden Apex og uden den fulde registreringsproces for Eksterne tjenester. Det passer godt til deklarativ implementering, når der ikke er en fuld OpenAPI-specifikation tilgængelig.
En synkron udløser, der kaldes fra Salesforce-dataændringer, udfører et asynkront Apex SOAP eller HTTP-udkald.	Suboptimal	Du kan bruge Apex til at udføre automatisering baseret på registreringsdataændringer. En Apex kan afvikles som et resultat af en DML-handling ved brug af en Apex. Men alle opkald, der foretages fra udløserkonteksten, skal udføres asynkront fra initieringsbegivenheden. Derfor anbefales denne løsning ikke for dette integrationsproblem. Denne løsning er bedre egnet til mønsteret Fjernproceskald – Fire og Glem.
Et Apex udfører et synkront Apex SOAP- eller HTTP-udkald.	Suboptimal	Du kan foretage opkald til et fjernsystem fra et batchjob. Denne løsning tillader batchfjernproceskørsel og -behandling af svaret fra fjernsystemet i Salesforce. Men et givent batch har begrænsninger for antallet af opkald. Yderligere oplysninger findes i Governor Limits. En given batchkørsel kan eksekvere flere transaktionskontekster (normalt i intervaller på 200 registreringer). Styringsbegrænsningerne nulstilles pr. transaktionskontekst.

Sketch

Dette diagram illustrerer et synkront fjernproceskald ved brug af Apex.

Salesforce ringer ud til et fjernsystem

Salesforce ringer ud til et fjernsystem med anmodning og svar

I dette scenarie:

En handling startes på Lightning (f.eks. et knapklik).
Browseren (via en klient-side-controller i tilfælde af en Lightning) udfører en HTTP POST, der igen udfører en handling på den tilsvarende Apex.
Controlleren kalder det faktiske opkald til fjernwebtjenesten.
Svaret fra fjernsystemet returneres til Apex. Controlleren behandler svaret, opdaterer data i Salesforce efter behov og gengiver siden igen.

I situationer, hvor den efterfølgende tilstand skal spores, returnerer fjernsystemet en entydig identifikator, der er lagret i Salesforce-registreringen.

Resultater

Anvendelsen af de løsninger, der er relateret til dette mønster, tillader begivenhedsinitierede fjernproceskald, hvor Salesforce håndterer behandlingen.

Opkaldsmekanismer

Kaldsmekanismen afhænger af den løsning, der er valgt for at implementere dette mønster.

Opkaldsmekanisme	Beskrivelse
Forbedret ekstern tjeneste integreret i et forløb eller Lightning eller Apex	Bruges, når fjernprocessen udløses som en del af en end-to-end-proces, der involverer brugergrænsefladen, og resultatet skal vises eller opdateres i en Salesforce-registrering. Indsendelsen af en kreditkortbetaling til en ekstern betalingsgateway og betalingsresultaterne returneres straks og vises for brugeren.
Apex	Bruges primært til kald af fjernprocesser ved brug af Apex fra DML-initierede begivenheder. Hvis du ønsker flere oplysninger om denne opkaldsmekanisme, kan du se mønsteret Fjernproceskald – Brand og glem.
Apex	Bruges til kald af fjernprocesser i batch. Hvis du ønsker flere oplysninger om denne opkaldsmekanisme, kan du se mønsteret Fjernproceskald – Brand og glem.

Fejlhåndtering og gendannelse

Det er vigtigt at inkludere en fejlhåndterings- og gendannelsesstrategi som en del af den generelle løsning.

Fejlhåndtering: Når der opstår en fejl (undtagelser eller fejlkoder returneres til opkalderen), administrerer opkalderen fejlhåndtering. F.eks. en fejlmeddelelse, der vises på slutbrugerens side eller logges på en tabel, der kræver yderligere handling.
Recovery: Ændringer bekræftes ikke til Salesforce, før opkalderen modtager et vellykket svar. F.eks. opdateres bestillingsstatussen ikke i databasen, før der er modtaget et svar, der angiver, at det lykkedes. Om nødvendigt kan opkalderen prøve handlingen igen.

Idempotent Design Overvejelser

Idempotent-funktioner garanterer, at gentagne kald er sikre. Hvis idempotence ikke implementeres, kan gentagne kald af den samme meddelelse have forskellige resultater, hvilket potentielt resulterer i problemer med dataintegritet. Potentielle problemer omfatter oprettelse af dubletregistreringer eller dubletbehandling af transaktioner.

Det er vigtigt at sikre, at den fjernprocedure, der kaldes, er idempotent. Hvis opkaldet foretages af brugergrænsefladen, skal du håndtere idempotency på integrationslaget, især hvis der ikke er nogen garanti for, at Salesforce kun kalder opkaldet en gang.

Den mest typiske metode til at opbygge en idempotent-modtager er for den at spore dubletter baseret på entydige meddelelsesidentifikatorer, der sendes af forbrugeren. Apex webtjeneste eller REST-kald skal tilpasses til at sende et entydigt meddelelses-id.

Endvidere skal handlinger, der opretter registreringer i fjernsystemet, kontrollere for dubletter, før de indsættes. Kontroller ved at overføre et entydigt registrerings-id fra Salesforce. Hvis registreringen findes i fjernsystemet, skal du opdatere registreringen. I de fleste systemer kaldes denne handling en upsert-handling.

Sikkerhedsovervejelser

Ethvert opkald til et fjernsystem skal bevare anmodningens fortrolighed, integritet og tilgængelighed. Følgende sikkerhedsovervejelser er specifikke for brug af Apex SOAP- og HTTP-kald i dette mønster.

Envejs-SSL er som standard aktiveret, men tovejs-SSL understøttes med både selvsignerede og CA-signerede certifikater for at bevare ægtheden af både klienten og serveren.
Hvis du vil strømline din Apex og forenkle opsætningen af godkendte udkald, skal du angive en navngivet legitimationsoplysning i udkaldsslutpunktet.
Overvej brug af OAuth 2.0 som godkendelsesmekanisme til integration i eksterne systemer.
Hvis det er nødvendigt, kan du overveje at bruge envejs-hashes eller digitale signaturer ved brug af Apex Crypto-klassemetoder for at sikre anmodningens integritet.
Fjernsystemet skal beskyttes ved at implementere de relevante firewall-mekanismer. Se Sikkerhedsovervejelser.
Salesforce understøtter aktuelt ikke WS-Security. Selvom det ikke genererer disse komplekse WS-Security-sidehoveder som standard eller automatisk håndhæver dem fra en indgående WSDL, kan du manuelt konstruere og implementere dem ved at oprette tilpassede Apex til at håndtere SOAP-sidehoveder og sikkerhedstokener for indgående anmodninger.

Sidebars

Ingen.

Tidlighed

Tidlighed er af væsentlig betydning i dette mønster. Normalt:

Anmodningen kaldes typisk fra brugergrænsefladen, så processen må ikke lade brugeren vente.
Salesforce har en konfigurerbar timeout på op til 120 sekunder for opkald fra Apex.
Færdiggørelse af fjernprocessen udføres rettidigt for at afslutte inden for Salesforce-timeoutgrænsen og inden for brugerens forventninger.
Eksterne opkald er underlagt Apex synkrone transaktionsstyringsbegrænsninger, så sørg for at reducere risikoen for at oprette flere end 50 transaktioner, der kører i mere end fem sekunder hver. Udover at sikre, at det eksterne slutpunkt fungerer, omfatter indstillinger til at reducere risikoen for en timeout:
- Indstilling af timeout for det eksterne udkald til fem sekunder.
- Brug af en fortsættelse i Lightning til at håndtere længe kørende transaktioner

Datamængder

Dette mønster bruges primært til små mængder af aktiviteter i realtid på grund af de små timeoutværdier og den maksimale størrelse på anmodningen eller svaret for Apex. Brug ikke dette mønster i batchbehandlingsaktiviteter, hvor dataene er indeholdt i meddelelsen.

Support af slutpunktsfunktioner og standarder

Funktionaliteten og standardunderstøttelsen af slutpunktet afhænger af den løsning, du vælger.

Løsning	Overvejelser i forbindelse med slutpunkter
Apex HTTP-udkald	Slutpunktet skal kunne modtage HTTP-kald. Salesforce skal kunne få adgang til slutpunktet over det offentlige internet. For privat og sikker kommunikation understøtter Salesforce også Salesforce Private Connect gennem Hyperforce. Se Salesforce Private Connect for at få flere oplysninger. Du kan bruge Apex HTTP-udkald til at kalde REST-tjenester ved brug af standardmetoderne GET, POST, PUT, DELETE og PATCH. Brug navngivne legitimationsoplysninger til at definere slutpunktet og den krævede godkendelse, og implementer ikke din egen godkendelsesmekanisme.
Apex SOAP-udkald	Slutpunktet skal kunne modtage HTTP-kald. Salesforce skal kunne få adgang til slutpunktet over det offentlige internet. For privat og sikker kommunikation understøtter Salesforce også Salesforce Private Connect gennem Hyperforce. Se Salesforce Private Connect for at få flere oplysninger. Denne løsning kræver, at fjernsystemet er kompatibelt med de standarder, der understøttes af Salesforce. De webtjenestestandarder, der aktuelt understøttes af Salesforce for Apex SOAP-udkald, er: WSDL 1.1 SOAP 1.1 WSI-basisprofil 1.1

Løsning

Overvejelser i forbindelse med slutpunkter

Apex HTTP-udkald

Slutpunktet skal kunne modtage HTTP-kald. Salesforce skal kunne få adgang til slutpunktet over det offentlige internet. For privat og sikker kommunikation understøtter Salesforce også Salesforce Private Connect gennem Hyperforce. Se Salesforce Private Connect for at få flere oplysninger.

Du kan bruge Apex HTTP-udkald til at kalde REST-tjenester ved brug af standardmetoderne GET, POST, PUT, DELETE og PATCH. Brug navngivne legitimationsoplysninger til at definere slutpunktet og den krævede godkendelse, og implementer ikke din egen godkendelsesmekanisme.

Apex SOAP-udkald

Slutpunktet skal kunne modtage HTTP-kald. Salesforce skal kunne få adgang til slutpunktet over det offentlige internet. For privat og sikker kommunikation understøtter Salesforce også Salesforce Private Connect gennem Hyperforce. Se Salesforce Private Connect for at få flere oplysninger.

Denne løsning kræver, at fjernsystemet er kompatibelt med de standarder, der understøttes af Salesforce. De webtjenestestandarder, der aktuelt understøttes af Salesforce for Apex SOAP-udkald, er:

WSDL 1.1
SOAP 1.1
WSI-basisprofil 1.1

Statsforvaltning

Når du integrerer systemer, er nøgler vigtige for igangværende tilstandssporing. Der er to muligheder.

Salesforce lagrer fjernsystemets primære eller entydige alternativnøgle for fjernregistreringen.
Fjernsystemet lagrer det entydige Salesforce-registrerings-id eller en anden entydig alternativnøgle.

Der er specifikke overvejelser for håndtering af integrationsnøgler, afhængigt af hvilket system der indeholder den overordnede registrering, som vist i følgende tabel.

Master	Systembeskrivelse
Salesforce	Fjernsystemet lagrer enten Salesforce RecordId eller en anden entydig alternativnøgle fra registreringen.
Fjernsystem	Kaldet til fjernprocessen returnerer den entydige nøgle fra applikationen, og Salesforce lagrer denne nøgleværdi i et entydigt registreringsfelt.

Komplekse integrationsscenarier

I visse situationer kan den løsning, der er foreskrevet af dette mønster, kræve implementering af flere komplekse integrationsscenarier. Dette vises bedst ved at bruge middleware eller få Salesforce til at kalde en sammensat tjeneste. Disse scenarier omfatter:

Orkestrering af forretningsprocesser og regler, der involverer kompleks forløbslogik
Aggregering af opkald og deres resultater på tværs af opkald til flere systemer
Transformation af både indgående og udgående meddelelser
Vedligeholdelse af transaktionsintegritet på tværs af opkald til flere systemer

Governor Limits

Hvis du ønsker oplysninger om Apex-begrænsninger, kan du se Udførelsesstyringer og begrænsninger i Apex Developer Guide.

Middleware-funktioner

Følgende tabel fremhæver de ønskede egenskaber for et middleware-system, der deltager i dette mønster.

Egenskab	Obligatorisk	Ønsket	Ikke påkrævet
Begivenhedshåndtering		X
Protokolkonvertering		X
Oversættelse og transformation		X
Kø og buffering		X
Synkrone transportprotokoller	X
Asynkrone transportprotokoller			X
Mediationsdistribution		X
Proces koreografi og serviceorkestrering		X
Transaktionalitet (kryptering, signering, pålidelig levering, transaktionsstyring)		X
Distribution			X
Udtræk, transformer og indlæs			X
Lang polling			X
gRPC-understøttelse (for Pub/Sub API)			X

Eksempel

Et hjælpeprogramfirma bruger Salesforce og har et separat system, der indeholder kundefaktureringsoplysninger. Som en del af bestillingsprocessen skal der oprettes nye faktureringskonti i faktureringssystemet. Salesforce skal afspejle faktureringskontonummeret i bestillingsaktiveringsprocessen. Firmaet har en eksisterende REST API, der tillader oprettelse af en faktureringskonto og returnerer faktureringskontonummeret som et svar.

Dette krav kan opfyldes med følgende tilgang.

Salesforce bruger faktureringskontoen HTTP API som en ekstern tjeneste eller forløbs-HTTP-udkald. Vi bør kun bruge en Apex proxy-klasse til SOAP-tjenesteforbrug, hvis faktureringssystemet kun leverer SOAP-baserede tjenester og ingen HTTP-API'er.
Kundeoplysninger overføres til det eksterne HTTP API-objekt.
Ekstern tjeneste eller HTTP-forløbskald returnerer svaret fra HTTP API, som kan lagres i Salesforce-objekter.
Dette eksempel viser, at:
Kundetilstanden spores med et kontonummer, der er lagret på Salesforce-kontoobjektet.
Opkalderen behandler derefter svarmeddelelsen.

Kontekst

Du bruger Salesforce til at spore emner, administrere din pipeline, oprette salgsmuligheder og registrere bestillingsdetaljer, der konverterer emner til kunder. Men som en del af bestillingsstyringsprocesserne skal der oprettes en faktureringskonto i faktureringssystemet for bestillingen.

Når du implementerer dette mønster, kalder Salesforce fjernsystemet for at oprette faktureringskontoen, men venter ikke på opkaldets vellykkede fuldførelse. Fjernsystemet kan eventuelt opdatere Salesforce med den nye faktureringskonto, der er oprettet i en separat transaktion.

Problem

Når der forekommer en begivenhed i Salesforce, hvordan starter du en proces i et fjernsystem og overfører de krævede oplysninger til denne proces uden at vente på et svar fra fjernsystemet?

Kræfter

Overvej følgende kræfter, når du anvender løsninger baseret på dette mønster.

Kræver opkaldet til fjernsystemet, at Salesforce venter på et svar, før det fortsætter behandlingen? Er opkaldet til fjernsystemet synkront eller asynkront?
Hvis opkaldet til fjernsystemet er synkront, skal svaret behandles af Salesforce som en del af den samme transaktion som opkaldet?
Er meddelelsesstørrelsen lille?
Er integrationen baseret på forekomsten af en specifik begivenhed, f.eks. et knapklik i Salesforce-brugergrænsefladen eller DML-baserede begivenheder?
Er garanteret levering af meddelelser fra Salesforce til fjernsystemet et krav?
Kan fjernsystemet deltage i en kontraktfør integration, hvor Salesforce angiver kontrakten? I nogle løsningsvarianter (f.eks. udgående meddelelser) angiver Salesforce en kontrakt, som fjernsystemets slutpunkt implementerer.
Understøtter slutpunktet eller ESB (Enterprise Service Bus) lang polling?
Foretrækkes deklarative konfigurationsmetoder frem for tilpasset Apex? I denne situation foretrækkes løsninger som platformsbegivenheder frem for Apex.

Løsning

Følgende tabel indeholder løsninger på dette integrationsproblem.

Løsning	Tilpas	Kommentarer
Forløbsstyrede platformsbegivenheder	Best	Opret forløb deklarativt for at implementere platformsbegivenheder. Den anbefalede løsning er, når fjernprocessen kaldes fra en indsættelses- eller opdateringsbegivenhed. Platformsbegivenheder er begivenhedsmeddelelser (eller adviseringer), som dine apps sender og modtager for at udføre yderligere handlinger. Platformsbegivenheder forenkler processen med at kommunikere ændringer og reagere på dem uden at skrive kompleks logik. En eller flere abonnenter kan lytte til den samme begivenhed og udføre handlinger. Et softwaresystem kan f.eks. sende begivenheder, der indeholder oplysninger om printerblækpatroner. Abonnenter kan abonnere på begivenhederne for at overvåge printerblækkeniveauer og afgive bestillinger for at erstatte patroner med lave blækkeniveauer. Eksterne apps kan lytte til begivenhedsmeddelelser ved at bruge Salesforce Pub/Sub API, som er baseret på gRPC og HTTP/2. Salesforce understøtter også platformsbegivenhedsudløste forløb, hvilket effektivt tillader oprettelse af en lytter ved brug af Flow Builder-grænsefladen. Denne type forløb starter automatisk, når en specifik meddelelse om en platformsbegivenhed udgives til Salesforce-begivenhedsbussen.
Pub/Sub API	Best	Pub/Sub API er den anbefalede måde for eksterne forbrugere at bruge begivenhederne på begivenhedsbussen. Den gRPC-baserede Pub/Sub API: Understøtter både udgivelse og abonnement på platformsbegivenheder fra eksterne applikationer Er tilgængelig med korrekt godkendelse (OAuth-, JWT- eller sessionstokener)
Ændring af dataregistrering	Best	Change Dataregistrering (CDC) udgiver begivenheder for ændringer i Salesforce-registreringer, der svarer til oprettelse, opdatering, sletning og fortryd sletningshandlinger. Aktivering af CDC (Change dataregistrering) i Salesforce er en rent deklarativ proces, der ikke kræver nogen Apex. Adviseringsmeddelelser sendes til begivenhedsbussen, som klienter kan abonnere på ved brug af Pub/Sub API eller Apex. Begivenhedsstyrede systemer strømliner kommunikationen mellem distribuerede virksomhedssystemer, øger skalerbarheden og leverer realtidsdata. Hvis f.eks. bestillingsoplysninger findes i både dit ERP-system og Salesforce, kan du streame bestillingsændringsbegivenheder fra Salesforce til en integrationsapp. Appen synkroniserer derefter ændringerne i ERP-systemet.
Begivenhedsvideresendelse	Bedst (med AWS-integrationer)	Salesforce-begivenhedsrelæ giver en serverløs, lav kode-integration i realtid til at streame Salesforce Platform-begivenheder og CDC-begivenheder direkte til Amazon EventBridge. Salesforce-begivenhedsvideresendelser sender disse begivenheder fra Salesforce til Amazon Web Services (AWS) og rapporterer end-to-end-begivenhedsforløb ved at sende begivenheder tilbage til Salesforce. Med Begivenhedsvideresendelse kan vi streame begivenheder til AWS som standard uden at skrive en integrationsapp.
Omnistudio-integrationsprocedurer	God	Brug Omnistudio-integrationsprocedurer til deklarativt at automatisere datainteraktioner mellem Salesforce og eksterne tredjepartsapplikationer. Integrationsprocedurer håndterer komplekse datatransformationer, API-kald og begivenhedsstyret automatisering, og de kan udføre flere handlinger i et enkelt serverkald. Brug integrationsprocedurer, når der ikke kræves nogen brugerinteraktion under kørslen, og du ønsker at: Hent, transformer og send data mellem Salesforce og eksterne systemer Offload-behandling til serveren for at forbedre ydeevnen og skalerbarheden Pak flere handlinger i en enkelt servertransaktion Aktiver datacachelagring for ofte åbnede oplysninger Læs mere om Integration Procedures here.
Tilpasningsstyrede platformsbegivenheder	God	Svarer til forløbsstyrede platformsbegivenheder, men begivenhederne oprettes af Apex eller -klasser. Du kan udgive og forbruge platformsbegivenheder ved brug af Apex eller en API. Platformsbegivenheder integreres med Salesforce-platformen gennem Apex. Udløsere er begivenhedsforbrugere på Salesforce-platformen, der lytter til begivenhedsmeddelelser. Når en ekstern app bruger API'en, eller en indbygget Salesforce-app bruger Apex til at udgive begivenhedsmeddelelsen, udløses en udløser på denne begivenhed. Udløsere kører handlingerne som svar på begivenhedsadviseringerne.
Forløbstyrede udgående meddelelser	Suboptimal	Dette er en forældet integrationsmetode og kan bruges, når fjernprocessen kaldes fra en indsættelses- eller opdateringsbegivenhed. Salesforce leverer denne forløbsstyrede udgående meddelelsesfunktionalitet til at sende SOAP-meddelelser til fjernsystemer, der udløses af en indsættelses- eller opdateringshandling i Salesforce. Disse meddelelser sendes asynkront og er uafhængige af Salesforce-brugergrænsefladen. Den udgående meddelelse sendes til et specifikt fjernslutpunkt. Fjerntjenesten skal kunne deltage i en kontraktfør integration, hvor Salesforce leverer kontrakten. Hvis fjerntjenesten ikke svarer med en positiv bekræftelse ved modtagelse af meddelelsen, forsøger Salesforce at sende meddelelsen igen og leverer en form for garanteret levering. Dette er en forældet integrationsmåde. Alle nye løsninger skal bruge Forløb med Pub/Sub API.
Tilpasset Lightning, der starter et asynkront Apex SOAP- eller HTTP-udkald	Suboptimal	Denne løsning bruges typisk i brugergrænsefladebaserede scenarier, men kræver tilpasning. Endvidere skal løsningen håndtere garanteret levering af meddelelsen i koden. Svarer til løsningen for fjernproceskald – anmodnings- og svarmønsterløsning, der angiver brug af en Lightning-komponent sammen med et Apex-udkald ved brug af navngivne legitimationsoplysninger. Forskellen er, at Salesforce i dette mønster ikke venter på, at anmodningen fuldføres, før den overdrager kontrollen til brugeren. Når meddelelsen er modtaget, svarer fjernsystemet og angiver modtagelse af meddelelsen og behandler derefter meddelelsen asynkront. Fjernsystemet overfører kontrollen tilbage til Salesforce, før det begynder at behandle meddelelsen. Derfor behøver Salesforce ikke at vente på, at behandlingen er fuldført.
Apex til at gøre Apex SOAP eller HTTP asynkront udkald	Suboptimal	Du kan bruge Apex til at udføre automatisering baseret på registreringsdataændringer. En Apex kan afvikles som et resultat af en DML-handling ved brug af en Apex. Men alle opkald, der foretages fra udløserkonteksten, skal udføres asynkront.
Apex til at gøre Apex SOAP eller HTTP asynkront udkald	Suboptimal	Opkald til et fjernsystem kan udføres fra et batchjob. Denne løsning tillader batchfjernproceskørsel og til behandling af svaret fra fjernsystemet i Salesforce. Men der er begrænsninger for antallet af opkald for en given batchkontekst. Hvis du ønsker yderligere oplysninger, kan du se Hurtig reference til Salesforce Developer-grænser og tildelinger.

Sketch

Følgende diagram illustrerer et opkald fra Salesforce til et fjernsystem, hvor oprettelse eller opdatering af handlinger på en registrering udløser opkaldet.

Salesforce kalder ud til et fjernsystem ved hjælp af brand og glemme

Download diagram

I dette scenarie:

Et fjernsystem abonnerer på platformsbegivenheden.
En opdatering eller indsættelse forekommer på et givent sæt registreringer i Salesforce.
Et Salesforce-forløb udløses, når et sæt betingelser opfyldes.
Dette forløb opretter en platformsbegivenhed.
Fjernlytteren modtager begivenhedsmeddelelsen og placerer meddelelsen på en lokal kø.
Køapplikationen videresender meddelelsen til fjernapplikationen til behandling.

I tilfælde hvor fjernsystemet skal udføre handlinger mod Salesforce, kan du implementere en valgfri tilbagekaldshandling.

Resultater

Anvendelsen af de løsninger, der er relateret til dette mønster, tillader:

Brugergrænsefladeinitierede fjernproceskald, hvor resultatet af transaktionen kan vises for slutbrugeren
DML-begivenhedsinitierede fjernproceskald, hvor resultatet af transaktionen kan behandles af opkaldsprocessen

Opkaldsmekanismer

Kaldsmekanismen afhænger af den løsning, der er valgt for at implementere dette mønster.

Opkaldsmekanisme	Beskrivelse
Flow	Bruges af både processtyrede og tilpasningsstyrede løsninger. Begivenheder udløser Salesforce-processen, som derefter kan udgive en platformsbegivenhed til abonnement af et fjernsystem.
Pub/Sub API	Pub/Sub API giver en enkelt grænseflade til udgivelse og abonnement på platformsbegivenheder, herunder begivenhedsovervågning i realtid og ændringsdataregistrering. Baseret på gRPC og HTTP/2, udgiver og leverer Pub/Sub API effektivt binære begivenhedsmeddelelser i formatet Apache Avro.
Ændring af dataregistrering	Salesforce Change Dataregistrering udgiver ændringsbegivenheder, som repræsenterer ændringer af Salesforce-registreringer. Ændringer inkluderer oprettelse af en ny registrering, opdateringer til en eksisterende registrering, sletning af en registrering og fortrydelse af sletning af en registrering.
Lightning og Apex	Bruges til at kalde en fjernproces asynkront ved brug af et Apex.
Apex	Bruges til udløserstyrede platformsbegivenheder og kald af fjernprocesser ved brug af Apex fra DML-initierede begivenheder.
Apex	Bruges til kald af fjernprocesser i batchtilstand.

Fejlhåndtering og gendannelse

En fejlhåndterings- og gendannelsesstrategi skal tages med i betragtning som en del af den overordnede løsning. Den bedste metode afhænger af den løsning, du vælger.

Løsning	Fejlhåndtering og gendannelsesstrategi
Flow	Fejlhåndtering – Under visse forhold kan forløb mislykkes at behandle fuldstændigt. Når et proces- eller forløbsinterview mislykkes, sendes der en detaljeret mail til den administrator, der sidst redigerede processen eller forløbet. Rediger standardadfærden ved at føje fejlstier til alle elementer, der kan mislykkes. Denne adfærd bør forbedres til at indsætte tilpasset adfærd, f.eks. oprettelse af en sag eller skrivefejl til et tilpasset objekt, der kan overvåges og spores. Gendannelse – Gendannelse er mere kompleks i dette scenarie. Der skal oprettes en tilpasset prøvemekanisme, hvis krav til servicekvalitet dikterer det.
Apex ved brug af navngivne legitimationsoplysninger	Fejlhåndtering – Fjernsystemet annullerer kald af afslutningsprocessen, så udkaldet håndterer kun undtagelser i den indledende kald af fjerntjenesten. F.eks. udløses der en timeoutbegivenhed, hvis der ikke modtages nogen positiv bekræftelse fra fjernudkaldet. Fjernsystemet skal håndtere efterfølgende fejl, når det indledende kald videregives til asynkron behandling. Gendannelse – Gendannelse er mere kompleks i dette scenarie. Der skal oprettes en tilpasset prøvemekanisme, hvis krav til servicekvalitet dikterer det.
CDC (Change Dataregistrering) / Platformsbegivenheder	Fejlhåndtering – Fejlhåndtering skal udføres af fjerntjenesten, da begivenheden effektivt videregives til fjernsystemerne til yderligere behandling. Da dette mønster er asynkront, håndterer fjernsystemet meddelelseskø, behandling og fejlhåndtering. Endvidere behandles platformsbegivenheder ikke i databasetransaktioner. Som resultat kan udgivne platformsbegivenheder ikke rulles tilbage i en transaktion. Gendannelse – Da dette mønster er asynkront, skal fjernsystemet starte forsøg baseret på servicekvalitetskravene. Genafspilnings-id'et, der er knyttet til hver begivenhed, er atomisk og øges med hver udgivet begivenhed. Dette id kan bruges til at afspille streamen fra en bestemt begivenhed (f.eks. baseret på den sidst registrerede begivenhed). Meddelelser om højvolumen platformsbegivenhed lagres i 72 timer (tre dage). Du kan hente tidligere begivenhedsmeddelelser, når du bruger Pub/Sub-API'er til at abonnere på en kanal.

Idempotent Design Overvejelser

Platformsbegivenheder udgives kun til bussen en gang. Der er ingen forsøg på Salesforce-siden. Det er op til ESB at anmode om, at begivenhederne afspilles igen. I en genvisning forbliver platformsbegivenhedens afspilnings-id det samme, og ESB kan prøve dubletmeddelelser baseret på afspilnings-id'et.

De idempotente designovervejelser i mønsteret Fjernprocesanmodning – Anmodning og Svar gælder også for dette mønster.

Sikkerhedsovervejelser

Ethvert opkald til et fjernsystem skal bevare anmodningens fortrolighed, integritet og tilgængelighed. Der gælder forskellige sikkerhedsovervejelser, afhængigt af den løsning, du vælger.

Løsning	Sikkerhedsovervejelser
Apex ved brug af navngivne legitimationsoplysninger	Et opkald til et fjernsystem skal bevare anmodningens fortrolighed, integritet og tilgængelighed. Følgende er sikkerhedsovervejelser, der er specifikke for brug af Apex SOAP- og HTTP-kald i dette mønster. Envejs-SSL er som standard aktiveret, men tovejs-SSL understøttes med både selvsignerede og CA-signerede certifikater for at bevare ægtheden af både klienten og serveren. Salesforce understøtter ikke WS-Security, når der genereres Apex. Hvis det er nødvendigt, kan du overveje at bruge envejs-hashes eller digitale signaturer ved brug af Apex Crypto-klassemetoder for at sikre anmodningens integritet. Fjernsystemet skal beskyttes ved at implementere de relevante firewall-mekanismer.
CDC (Change Dataregistrering) / Platformsbegivenheder	For platformsbegivenheder skal det abonnerende eksterne system kunne godkende til Salesforce Streaming API. Platformsbegivenheder overholder den eksisterende sikkerhedsmodel, der er konfigureret i Salesforce-organisationen. For at abonnere på en begivenhed skal brugeren have læseadgang til begivenhedsenheden. For at udgive en begivenhed skal brugeren have tilladelsen "opret" på begivenhedsenheden.

Løsning

Sikkerhedsovervejelser

Apex ved brug af navngivne legitimationsoplysninger

Et opkald til et fjernsystem skal bevare anmodningens fortrolighed, integritet og tilgængelighed. Følgende er sikkerhedsovervejelser, der er specifikke for brug af Apex SOAP- og HTTP-kald i dette mønster.

Envejs-SSL er som standard aktiveret, men tovejs-SSL understøttes med både selvsignerede og CA-signerede certifikater for at bevare ægtheden af både klienten og serveren.
Salesforce understøtter ikke WS-Security, når der genereres Apex.
Hvis det er nødvendigt, kan du overveje at bruge envejs-hashes eller digitale signaturer ved brug af Apex Crypto-klassemetoder for at sikre anmodningens integritet.
Fjernsystemet skal beskyttes ved at implementere de relevante firewall-mekanismer.

CDC (Change Dataregistrering) / Platformsbegivenheder

For platformsbegivenheder skal det abonnerende eksterne system kunne godkende til Salesforce Streaming API.

Platformsbegivenheder overholder den eksisterende sikkerhedsmodel, der er konfigureret i Salesforce-organisationen. For at abonnere på en begivenhed skal brugeren have læseadgang til begivenhedsenheden. For at udgive en begivenhed skal brugeren have tilladelsen "opret" på begivenhedsenheden.

Se Sikkerhedsovervejelser.

Sidebars

Ingen.

Tidlighed

Tidlighed er mindre en faktor med fire-og-glem-mønsteret. Kontrol overføres tilbage til klienten enten med det samme eller efter positiv bekræftelse af en vellykket overdragelse til fjernsystemet. For platformsbegivenheder sender Salesforce begivenhederne til begivenhedsbussen og venter ikke på en bekræftelse eller bekræftelse fra abonnenten. Hvis abonnenten ikke henter meddelelsen, kan abonnenten anmode om at afspille begivenheden ved brug af begivenhedssvar-id'et. Højvolumen begivenhedsmeddelelser lagres i 72 timer (tre dage). Hvis du vil hente tidligere begivenhedsmeddelelser, skal du bruge Pub/Sub-API'er til at abonnere på en kanal.

Datamængder

Datamængdeovervejelser afhænger af, hvilken løsning du vælger. Hvis du vil se grænserne for hver løsning, kan du se den hurtige reference til Salesforce-begrænsninger.

Support af slutpunktsfunktioner og standarder

Funktionaliteten og standardunderstøttelsen af slutpunktet afhænger af den løsning, du vælger.

Løsning	Overvejelser i forbindelse med slutpunkter
Apex SOAP-udkald	Slutpunktet skal kunne behandle et webserviceopkald via HTTP. Salesforce skal kunne få adgang til slutpunktet over det offentlige internet. Denne løsning kræver, at fjernsystemet er kompatibelt med de standarder, der understøttes af Salesforce. På dette tidspunkt er de webtjenestestestandarder, der understøttes af Salesforce for Apex SOAP-udkald: WSDL 1.1 SOAP 1.1 WSI-basisprofil 1.1 HTTP
Apex HTTP-udkald	Slutpunktet skal kunne modtage HTTP-opkald og være tilgængeligt over det offentlige internet af Salesforce. Apex HTTP-udkald kan bruges til at kalde RESTful-tjenester ved brug af standardmetoderne GET, POST, PUT og DELETE.
CDC (Change Dataregistrering) / Platformsbegivenheder	Udløsere og forløb kan abonnere på begivenheder. Du kan modtage begivenhedsadviseringer, uanset hvordan de blev udgivet.

Statsforvaltning

Når du integrerer systemer, er entydige registreringsidentifikatorer vigtige for igangværende tilstandssporing. Hvis f.eks. en registrering oprettes i fjernsystemet, har du to muligheder.

Salesforce lagrer fjernsystemets primære eller entydige alternativnøgle for fjernregistreringen.
Fjernsystemet lagrer det entydige Salesforce-registrerings-id eller en anden entydig alternativnøgle.

Følgende tabel viser overvejelser i forbindelse med statsadministration i dette mønster.

Master	Systembeskrivelse
Salesforce	Fjernsystemet skal lagre enten Salesforce RecordId eller en anden entydig alternativnøgle i Salesforce-registreringen.
Fjernsystem	Salesforce skal lagre en reference til den entydige identifikator i fjernsystemet. Da processen er asynkron, kan lagring af denne entydige identifikator ikke være del af den oprindelige transaktion. Salesforce skal angive et entydigt id i opkaldet til fjernprocessen. Fjernsystemet skal derefter kalde tilbage til Salesforce for at opdatere registreringen i Salesforce med fjernsystemets entydige id ved brug af det entydige Salesforce-id. Tilbagekaldet angiver specifik tilstandshåndtering i fjernapplikationen til at lagre den entydige Salesforce-id for den pågældende transaktion, der skal bruges til tilbagekaldet, når behandlingen er fuldført, eller den entydige Salesforce-id lagres på fjernsystemets registrering.

Master

Systembeskrivelse

Salesforce

Fjernsystemet skal lagre enten Salesforce RecordId eller en anden entydig alternativnøgle i Salesforce-registreringen.

Fjernsystem

Salesforce skal lagre en reference til den entydige identifikator i fjernsystemet. Da processen er asynkron, kan lagring af denne entydige identifikator ikke være del af den oprindelige transaktion.

Salesforce skal angive et entydigt id i opkaldet til fjernprocessen. Fjernsystemet skal derefter kalde tilbage til Salesforce for at opdatere registreringen i Salesforce med fjernsystemets entydige id ved brug af det entydige Salesforce-id.

Tilbagekaldet angiver specifik tilstandshåndtering i fjernapplikationen til at lagre den entydige Salesforce-id for den pågældende transaktion, der skal bruges til tilbagekaldet, når behandlingen er fuldført, eller den entydige Salesforce-id lagres på fjernsystemets registrering.

Komplekse integrationsscenarier

Hver løsning i dette mønster har forskellige overvejelser i forbindelse med komplekse integrationsscenarier, f.eks. transformation og procesorkestrering.

Løsning	Overvejelser
Apex ved brug af navngivne legitimationsoplysninger	I visse situationer kræver løsninger, der er foreskrevet af dette mønster, implementering af flere komplekse integrationsscenarier, der bedst vises ved brug af middleware, eller at Salesforce kalder en sammensat tjeneste. Disse scenarier omfatter: Orkestrering af forretningsprocesser og regler, der involverer kompleks forløbslogik Aggregering af opkald og deres resultater på tværs af opkald til flere systemer Transformation af både indgående og udgående meddelelser Vedligeholdelse af transaktionsintegritet på tværs af opkald til flere systemer
CDC (Change Dataregistrering) / Platformsbegivenheder	Da begivenheder er af statisk, deklarativ karakter, kan der ikke udføres komplekse integrationsscenarier, f.eks. aggregering, orkestrering eller transformation i Salesforce. Fjernsystemet eller middleware skal håndtere disse typer handlinger.
OmniStudio Integration Procedures	Integrationsprocedurer (OmniStudio) leverer server-side, statløs orkestrering til at koordinere flere back-end-tjenester, mens du udfører komplekse, deklarative datatransformationer. Integrationsprocedurer knytter trin som HTTP-handlinger, DataRaptor Extract/Transform/Load, Angiv værdier, Løkke/hvis og Matrixopslag til at normalisere, berige, aggregere og tilknytte data mellem brugergrænsefladekontrakter og uensartede API'er. De understøtter robuste kørselskontrolelementer som betinget forgrening, sideinddeling, timeouts, gentagne forsøg, delvis fejlhåndtering og continue-on-error samt ydeevneoptimeringer som serverside-cachelagring og svarformatering. IP'er kan kaldes synkront fra OmniScripts eller headless via REST, hvilket aktiverer genanvendelige, versionerede "integrationsfacader", der skjuler back-end-kompleksitet fra kanaler.

Governor Limits

På grund af multilejerens karakter af Salesforce-platformen er der begrænsninger for udgående udkald. Begrænsninger afhænger af typen af udgående opkald og opkaldets tid.

For begrænsninger og tildelinger, der gælder for platformsbegivenheder, kan du se Platformsbegivenheder Udviklervejledning.

Pålidelige meddelelser

Pålidelige meddelelser forsøger at løse problemet med at garantere leveringen af en meddelelse til et fjernsystem, hvor de individuelle komponenter er upålidelige. Metoden til at sikre modtagelse af en meddelelse af fjernsystemet afhænger af den løsning, du vælger.

I tilfælde af Salesforce Change dataregistrering findes der ændringsbegivenhedstyper til at håndtere særlige situationer, f.eks. registrering af ændringer, der ikke er registreret i Salesforce-applikationsservere, eller håndtering af store ændringer.

I nogle situationer sender Salesforce mangelbegivenheder i stedet for ændringsbegivenheder for at oplyse abonnenter om fejl, eller hvis det ikke er muligt at generere ændringsbegivenheder. En hulbegivenhed indeholder oplysninger om ændringen i sidehovedet, f.eks. ændringstypen og registrerings-id'et. Den indeholder ikke detaljer om ændringen, f.eks. registreringsfelter. For at registrere ændringer mere effektivt genereres overløbsbegivenheder for enkelte transaktioner, der overskrider en tærskel. For mere information se venligst her.

Løsning	Overvejelser i forbindelse med pålidelige meddelelser
Apex ved brug af navngivne legitimationsoplysninger	Salesforce understøtter ikke eksplicit pålidelige meddelelsesprotokoller (f.eks. WS-ReliableMessaging). Vi anbefaler, at fjernslutpunktet, der modtager Salesforce-meddelelsen, implementerer et pålideligt meddelelsessystem, f.eks. JMS eller MQ. Dette system sikrer fuld end-to-end-garanteret levering til det fjernsystem, der til sidst behandler meddelelsen. Men dette system sikrer ikke garanteret levering fra Salesforce til det fjernslutpunkt, det kalder. Garanteret levering skal håndteres gennem tilpasninger til Salesforce. Specifikke teknikker, f.eks. behandling af en positiv bekræftelse fra fjernslutpunktet i tillæg til tilpasset forsøgslogik, skal implementeres.
CDC (Change Dataregistrering) / Platformsbegivenheder	Platformsbegivenheder forsøger at levere pålidelige meddelelser ved midlertidigt at bevare begivenhedsmeddelelser i begivenhedsbussen. Abonnenter kan komme i gang med manglende begivenhedsmeddelelser ved at afspille meddelelser fra begivenhedsbussen ved brug af Genafspilnings-id'et for begivenhedsmeddelelser. Begivenhedsbussen er et distribueret system og har ikke de samme garantier som en transaktionel database. Som resultat kan Salesforce ikke levere et synkront svar for en begivenhedsudgivelsesanmodning. Begivenheder sættes i kø og sættes i en buffer, og Salesforce forsøger at udgive begivenhederne asynkront. I sjældne tilfælde vil begivenhedsmeddelelsen muligvis ikke blive bevaret i det distribuerede system under de indledende eller efterfølgende forsøg. Dette betyder, at begivenhederne ikke leveres til abonnenter, og de kan ikke gendannes.

Middleware-funktioner

Følgende tabel fremhæver de ønskede egenskaber for et middleware-system, der deltager i dette mønster.

Egenskab	Obligatorisk	Ønsket	Ikke påkrævet
Begivenhedshåndtering		X
Protokolkonvertering		X
Oversættelse og transformation		X
Kø og buffering	X
Synkrone transportprotokoller			X
Asynkrone transportprotokoller	X
Mediationsdistribution		X
Proces koreografi og serviceorkestrering		X
Transaktionalitet (kryptering, signering, pålidelig levering, transaktionsstyring)	X
Distribution			X
Udtræk, transformer og indlæs			X
Lang polling	X (påkrævet for streaming-API)
gRPC-understøttelse (for Pub/Sub API)	X

Løsningsvariant: Platformsbegivenheder - Publiceringsadfærd og transaktioner

Når meddelelser om platformsbegivenheder udgives med det samme, respekterer begivenhedsudgivelse ikke transaktionsgrænserne for udgivelsesprocessen. Begivenhedsmeddelelser kan udgives, før transaktionen er fuldført, eller selv hvis en transaktion mislykkes. Denne adfærd kan føre til problemer, når en abonnent forventer at finde data, som udgivelsestransaktionen bekræfter. Dataene er muligvis ikke til stede, når abonnenten modtager begivenhedsmeddelelsen. Hvis du vil løse dette problem, skal du indstille platformsbegivenhedsudgivelsesadfærd til Udgiv efter bekræftelse i begivenhedsdefinitionen. De udgivelsesadfærd, du kan angive i en platformsbegivenhedsdefinition, er:

Udgiv Efter bekræftelse for kun at få begivenhedsmeddelelsen udgivet, når en transaktion bekræftes. Vælg denne indstilling, hvis abonnenter er afhængige af data, som udgivelsestransaktionen bekræfter. En proces udgiver f.eks. en begivenhedsmeddelelse og opretter en opgaveregistrering. En anden proces, der abonnerer på begivenheden, udløses og forventer at finde opgaveregistreringen. En anden årsag til at vælge denne adfærd er, når du ikke ønsker, at begivenhedsmeddelelsen skal udgives, hvis transaktionen mislykkes.
Udgiv straks for at få begivenhedsmeddelelsen udgivet, når udgivelseskaldet udføres. Vælg denne indstilling, hvis du ønsker, at begivenhedsmeddelelsen skal udgives, uanset om transaktionen lykkes. Vælg også denne indstilling, hvis udgiveren og abonnenterne er uafhængige, og abonnenterne ikke er afhængige af data, der er bekræftet af udgiveren. F.eks. er den øjeblikkelige udgivelsesadfærd egnet til en begivenhed, der bruges til logføringsformål. Med denne indstilling kan en abonnent modtage begivenhedsmeddelelsen, før data bekræftes af handlingsområdetransaktionen.

Eksempel

Et telekommunikationsfirma ønsker at bruge Salesforce som en front-end til oprettelse af konti ved brug af emne-til-salgsmulighedsprocessen. Der oprettes en bestilling i Salesforce, når salgsmuligheden er lukket og vundet, men back-end ERP-systemet er den overordnede. Bestillingen skal gemmes i Salesforce-salgsmulighedsregistreringen, og salgsmulighedsstatussen skal ændres til at angive, at bestillingen blev oprettet.

Følgende begrænsninger gælder.

Kun deklarativ udvikling kan implementeres.
Du kræver ikke øjeblikkelig advisering om bestillingsnummeret, når salgsmuligheden konverteres til en bestilling.
Organisationen har mulighed for at understøtte gRPC og HTTP2, så Salesforce Pub/Sub-API'er kan bruges til at abonnere på platformsbegivenheder.

Dette eksempel implementeres bedst ved brug af Salesforce Platform-begivenheder, men kræver, at ESB abonnerer på platformsbegivenheden.

På Salesforce-siden:

Opret et forløb for at starte platformsbegivenheden (f.eks. når salgsmulighedsstatussen ændres til Lukket Vundet).
Opret en ny platformsbegivenhed, der udgiver salgsmulighedsdetaljerne.

På systemfjernsiden:

Integrationsværktøjerne (f.eks. ESB) abonnerer på Salesforce Platform-begivenheden ved brug af Pub/Sub API.
ESB modtager en eller flere adviseringer, der angiver, at salgsmuligheden skal konverteres til en bestilling.
ESB videresender meddelelsen til back-end ERP-systemet, så bestillingen kan oprettes.
Når bestillingen er oprettet i ERP-systemet, kalder en separat tråd tilbage til Salesforce ved brug af OAuth 2.0 med en tilsluttet app. Tilbagekaldet opdaterer salgsmuligheden med bestillingsnummeret og statussen. Du kan foretage dette tilbagekald ved brug af dokumenterede mønsterløsninger, f.eks. Salesforce Platform-begivenheder, Salesforce SOAP API, REST API eller en Apex.

Dette eksempel viser følgende.

Implementering af en fjernproces, der kaldes asynkront
Slut-til-slut-garanteret levering
Efterfølgende tilbagekald til Salesforce for at opdatere statussen på registreringen

Kontekst

Du flytter din CRM-implementering til Salesforce og ønsker at:

Udtræk og transformer konti, kontakter og salgsmuligheder fra det aktuelle CRM-system, og indlæs dataene i Salesforce (første dataimport).
Udtræk, transformer og indlæs kund faktureringsdata i Salesforce fra et fjernsystem på ugentlig basis (løbende).
Udtræk oplysninger om kundeaktivitet fra Salesforce, og importer dem i et lokalt datalager på ugentlig basis (løbende).

Problem

Hvordan importerer du data i Salesforce og eksporterer data ud af Salesforce, idet du tager højde for, at disse importer og eksporter kan forstyrre slutbrugerhandlinger i arbejdstiden og involvere store mængder data?

Kræfter

Der er forskellige kræfter, du skal overveje, når du anvender løsninger baseret på dette mønster:

Skal dataene lagres i Salesforce? Hvis ikke, er der andre integrationsindstillinger, som en arkitekt kan og bør overveje (f.eks. opdelinger).
Hvis dataene skal lagres i Salesforce, skal dataene opdateres som reaktion på en begivenhed i fjernsystemet?
Skal dataene opdateres på en planlagt basis?
Understøtter dataene primære forretningsprocesser?
Er der analysekrav (rapportering), der påvirkes af tilgængeligheden af disse data i Salesforce?

Løsning

Følgende tabel indeholder forskellige løsninger på dette integrationsproblem.

Løsning	Tilpas	Dataoverordnet	Kommentarer
Replikering via ETL-værktøj fra tredjepart	Best	Fjernsystem	Hvor et eksternt system har brug for at sende en stor mængde data i Salesforce, skal du bruge et tredjeparts ETL-værktøj, der giver dig mulighed for at køre dataregistrering op mod kildedata. Værktøjet reagerer på ændringer i kildedatasættet, transformerer dataene og kalder derefter Salesforce Bulk API for at udstede DML-erklæringer. Dette kan også implementeres ved brug af Salesforce REST-API'er, hvis antallet af registreringer er mindre.
Replikering via ETL-værktøj fra tredjepart	God	Salesforce	Anvend et ETL-tredjepartsværktøj, der giver dig mulighed for at køre dataregistrering af ændringsdata mod ERP- og Salesforce-datasæt. I denne løsning er Salesforce datakilden, og du kan bruge tids-/statusoplysninger på individuelle rækker til at forespørge på dataene og filtrere målresultatsættet. Dette kan implementeres ved brug af masse-API 2.0- eller REST-standard-API'er (hvis antallet af registreringer er mindre).
Data 360- og datahandlinger og -aktiveringer	Best	Data 360	Flyt data mellem organisationer ved brug af Data 360-handlinger og -aktiveringer. Når data er overført fra forskellige organisationer til Data 360, kan datahandlinger og aktiveringer synkronisere dataene til en anden organisation. Denne tilgang kan være meget nyttig for integrationer med Marketing Cloud-organisationer.
Data 360, Datadiagrammer og Connect-API'er	Best	Data 360	Udtræk og flyt data ved brug af MuleSoft Anypoint. MuleSoft Et nypoint kan bruges til at udtrække data fra Data 360 ved brug af Connect API og Data Graph API og flytte dem til en anden Salesforce-organisation. Uden Data 360 kan MuleSoft Anypoint også bruges, når der skal flyttes data mellem organisationer uden at blive replikeret i Data 360.
Sammensat diagram-API	Best	Salesforce	Den sammensatte diagramressource giver dig mulighed for at indsende sammensatte diagramhandlinger. Denne ressource er tilgængelig i REST API version 50.0 og nyere. Sammensat diagram-API kan understøtte op til 75 grafer i en dataindlæsning og maksimalt 500 noder i et diagram.
Guiden Dataimport og Data Loader	Tilpas	Salesforce/eksternt system	Guiden Dataimport og Data Loader kan bruges til at importere, eksportere og migrere data. Mens Data Loader-kommandoer også kan scriptes til at automatisere import og eksport af data, er kommandolinjegrænsefladen kun til Windows. Ingen af disse værktøjer er en anbefalet basis for en dataintegrationsstrategi. De bør i stedet supplere din dataforvaltnings- og vedligeholdelsesstrategi. Se Data Loader-dokumentationen for at få flere oplysninger.
Fjernopkald	Suboptimal	Fjernsystem	Det er muligt for et fjernsystem at kalde Salesforce ved at bruge en af API'erne og foretage opdateringer af data, efterhånden som de forekommer. Dette medfører dog en betydelig vedvarende trafik mellem de to systemer. Der bør lægges større vægt på fejlhåndtering og låsning. Dette mønster har potentiale til at forårsage kontinuerlige opdateringer, hvilket har potentiale til at påvirke ydeevnen for slutbrugere.
Fjernproceskald	Suboptimal	Salesforce	Det er muligt for Salesforce at kalde et fjernsystem og foretage opdateringer af data, efterhånden som de forekommer. Dette medfører dog en betydelig vedvarende trafik mellem de to systemer. Der bør lægges større vægt på fejlhåndtering og låsning. Dette mønster har potentiale til at forårsage kontinuerlige opdateringer, hvilket har potentiale til at påvirke ydeevnen for slutbrugere.

Sketch

Følgende diagram illustrerer rækkefølgen af begivenheder i dette mønster, hvor Salesforce er den overordnede.

Batchdatasynkronisering med Salesforce som datamaster

Følgende diagram illustrerer den efterfølgende synkronisering af begivenheder i næsten realtid, hvor Salesforce er den overordnede.

Næsten datasynkronisering i realtid

Resultater

Du kan integrere data, der er købt eksternt, med Salesforce under følgende scenarier:

Det eksterne system er datamaster: Salesforce er en forbruger af data, der leveres af et enkelt kildesystem eller flere systemer. I dette scenarie er det almindeligt at have et datalager eller en datamart, der aggregerer dataene, før dataene importeres til Salesforce.
Salesforce er datamesteren: Salesforce er registreringssystemet for visse enheder, og Salesforce Change dataregistrering kan blive informeret om ændringer af Salesforce-data.

I et typisk Salesforce-integrationsscenarie gør implementeringsteamet et af følgende:

Implementer dataregistrering af ændringsdata på kildedatasættet.
Implementer et sæt understøttende databasestrukturer, kaldet kontroltabeller, i en mellemliggende database på stedet.

ETL-værktøjet opretter programmer, der vil:

Læs en kontroltabel for at bestemme det sidste kørselstidspunkt for jobbet, og udtræk eventuelle andre kontrolværdier, der er nødvendige.
Brug ovennævnte kontrolværdier som filtre, og forespørg på kildedatasættet.
Anvend foruddefinerede behandlingsregler, herunder validering, berigelse osv.
Brug tilgængelige forbindelses-/transformationsfunktioner i ETL-værktøjet til at oprette destinationsdatasættet.
Skriv datasættet til Salesforce-objekter.
Hvis behandlingen lykkes, skal du opdatere kontrolværdierne i kontroltabellen.
Hvis behandlingen mislykkes, skal du opdatere kontroltabellerne med værdier, der aktiverer en genstart og afslutning.

Notat: Vi anbefaler, at du opretter kontroltabellerne og tilknyttede datastrukturer i et miljø, som ETL-værktøjet har adgang til, selvom der ikke er adgang til Salesforce. Dette giver tilstrækkelige niveauer af fleksibilitet. Salesforce skal behandles som et tal i denne proces, og ETL-infrastrukturen er hubben.

Hvis et ETL-værktøj skal have maksimal fordel af datasynkroniseringsfunktioner, skal du overveje følgende:

Kæd og arranger ETL-job for at levere en sammenhængende proces.
Brug primære nøgler fra begge systemer til at matche indgående data.
Brug specifikke API-metoder til kun at udtrække opdaterede data.
Hvis du importerer underordnede registreringer i en overordnet-detalje- eller opslagsrelation, skal du gruppere de importerede data ved brug af deres overordnede nøgle ved kilden for at undgå at låse. Hvis du f.eks. importerer kontaktdata, skal du sørge for at gruppere kontaktdata efter den overordnede kontonøgle, så det maksimale antal kontakter for en enkelt konto kan indlæses i et API-kald. Hvis du ikke kan gruppere de importerede data, resulterer det sædvanligvis i, at den første kontaktregistrering indlæses, og efterfølgende kontaktregistreringer for denne konto mislykkes i konteksten af API-kaldet.
Enhver efterimportbehandling, f.eks. udløsere, skal kun behandle data selektivt.
Hvis dit scenarie involverer store datamængder, skal du følge de bedste fremgangsmåder fra dette Trailhead-modul Bedste fremgangsmåder for implementeringer med store datamængder

Fejlhåndtering og gendannelse

En fejlhåndterings- og gendannelsesstrategi skal tages med i betragtning som en del af den overordnede løsning. Den bedste metode afhænger af den løsning, du vælger.

Fejlplacering	Fejlhåndtering og gendannelsesstrategi
Læs fra Salesforce ved brug af ændringsdataregistrering	Fejlhåndtering – Fejlhåndtering skal udføres i fjerntjenesten, da begivenheden effektivt videregives til fjernsystemet til yderligere behandling. Da dette mønster er asynkront, håndterer fjernsystemet meddelelseskø, behandling og fejlhåndtering. Endvidere behandles dataregistrering ikke i databasetransaktioner. Som resultat kan udgivne begivenheder ikke rulles tilbage i en transaktion. Gendannelse – Da dette mønster er asynkront, skal fjernsystemet starte forsøg baseret på tjenestens kvalitet af servicekrav. Genafspilnings-id'et, der er knyttet til hver ændringsdataregistreringsbegivenhed, er atomisk og øges med hver udgivet begivenhed. Dette id kan bruges til at afspille streamen fra en bestemt begivenhed (f.eks. baseret på den sidst registrerede begivenhed). Meddelelser om højvolumen platformsbegivenhed lagres i 72 timer (3 dage). Du kan hente tidligere begivenhedsmeddelelser, når du bruger Pub/Sub API-klienter til at abonnere på en kanal.
Læs fra Salesforce ved brug af et ETL-system fra tredjepart	Fejlhåndtering – Hvis der opstår en fejl under en læsehandling, skal du implementere et forsøg på fejl, der ikke er infrastrukturrelateret. I tilfælde af gentaget fejl skal standardbehandling ved brug af kontroltabeller/fejltabeller implementeres i konteksten af en ETL-handling for at: Logfør fejlen Prøv read-handlingen igen Afslut, hvis det mislykkedes Send en advisering Gendannelse – Genstart ETL-processen for at gendanne fra en mislykket skrivningshandling. Hvis handlingen lykkes, men der er mislykkede registreringer, skal en øjeblikkelig genstart eller efterfølgende kørsel af jobbet håndtere problemet. I denne situation kan en forsinket genstart være en bedre løsning, da det giver tid til at sortere og rette data, der kan forårsage fejlene.
Skriv til Salesforce	Fejlhåndtering – Fejl, der forekommer under en skrivehandling, kan være et resultat af en kombination af faktorer i applikationen. API-kald returnerer et resultatsæt, der består af de oplysninger, der er angivet nedenfor. Disse oplysninger skal bruges til at prøve skrivehandlingen igen (hvis det er nødvendigt). Registrering, der identificerer oplysninger Advisering om gennemførelse/fejl En samling af fejl for hver registrering Gendannelse – Genstart ETL-processen for at gendanne fra en mislykket læsehandling. Hvis handlingen lykkes, men der er mislykkede registreringer, skal en øjeblikkelig genstart eller efterfølgende kørsel af jobbet håndtere problemet. I denne situation kan en forsinket genstart være en bedre løsning, da det giver tid til at sortere og rette data, der kan forårsage fejlene.
Eksternt overordnet system	Fejl skal håndteres i overensstemmelse med de bedste fremgangsmåder for det overordnede system.

Sikkerhedsovervejelser

Ethvert opkald til et fjernsystem skal bevare anmodningens fortrolighed, integritet og tilgængelighed. Der gælder forskellige sikkerhedsovervejelser, afhængigt af den løsning, du vælger.

Godkendt API-adgang til Salesforce API kræver en Lightning Platform-licens med mindst API-Only-brugertilladelser.
Vi anbefaler, at standardkryptering bruges til at bevare adgangskode sikker.
Brug HTTPS-protokollen, når der foretages kald til Salesforce-API'er. Du kan også proxyføre trafik til Salesforce-API'er gennem en sikkerhedsløsning på stedet, hvis det er nødvendigt.

Se Sikkerhedsovervejelser.

Sidebars

Ingen.

Tidlighed

Tidlighed er ikke af væsentlig betydning i dette mønster. Men det skal være omhyggeligt at designe grænsefladerne, så alle batchprocesser fuldføres i et udpeget batchvindue.

Som med alle batchorienterede handlinger anbefaler vi, at du sørger for at isolere kilde- og målsystemerne under batchbehandlingsvinduer. Indlæsning af batches i arbejdstiden kan resultere i noget uenighed, hvilket resulterer i, at enten en brugers opdatering mislykkes, eller endnu mere, at en batchindlæsning (eller delvis batchindlæsning) mislykkes.

For organisationer, der har globale handlinger, er det muligvis ikke muligt at køre alle batchprocesser samtidigt, da systemet muligvis fortsat er i brug. Datasegmenteringsteknikker ved brug af registreringstyper og andre filtreringskriterier kan bruges til at undgå datakonflikter i disse situationer.

Statsforvaltning

Du kan implementere statsstyring ved at bruge alternativnøgler mellem de to systemer. Hvis du har brug for transaktionsstyring på tværs af Salesforce-enheder, anbefaler vi, at du bruger mønsteret fjernindkald ved brug af Apex.

Standardoptimeret registreringslåsning forekommer på platformen, og alle opdateringer, der foretages ved brug af API, kræver, at brugeren, der redigerer registreringen, opdaterer registreringen og starter sin transaktion. I konteksten af Salesforce API henviser optimistisk låsning til en proces, hvor:

Salesforce vedligeholder ikke tilstanden for en registrering, der redigeres af en bestemt bruger.
Efter læsning registrerer den det tidspunkt, hvor dataene blev udtrukket.
Hvis brugeren opdaterer registreringen og gemmer den, kontrollerer Salesforce, om en anden bruger har opdateret registreringen i mellemtiden.
Hvis registreringen er blevet opdateret, adviserer systemet brugeren om, at der er foretaget en opdatering, og brugeren skal hente den seneste version af registreringen, før vedkommende fortsætter med sine opdateringer.

Middleware-funktioner

De mest effektive eksterne teknologier, der bruges til at implementere dette mønster, er traditionelle ETL-værktøjer som Informatica eller MuleSoft. Det er vigtigt, at de valgte middlewareværktøjer understøtter Salesforce Bulk API.

Mellemvarer skal kunne lagre det sidste vellykkede tidsstempel enten internt eller eksternt til vandmærkning. Dette sidste vellykkede tidsstempel skal bruges til at forbruge ændringerne siden den sidste vellykkede kørsel.

Følgende tabel fremhæver de ønskede egenskaber for et middleware-system, der deltager i dette mønster.

Egenskab	Obligatorisk	Ønsket	Ikke påkrævet
Begivenhedshåndtering		X
Protokolkonvertering		X
Oversættelse og transformation	X
Kø og buffering	X
Synkrone transportprotokoller	X
Asynkrone transportprotokoller			X
Mediationsdistribution		X
Proces koreografi og serviceorkestrering	X
Transaktionalitet (kryptering, signering, pålidelig levering, transaktionsstyring)		X
Distribution		X
Udtræk, transformer og indlæs	X
Lang polling	X (påkrævet for dataregistrering)
gRPC-understøttelse (for Pub/Sub API)	X

Eksempel

Et hjælpeprogramfirma bruger en mainframe-baseret batchproces, der tildeler kundeemner til individuelle sælgere og teams. Disse oplysninger skal importeres til Salesforce på natbasis.

Kunden har besluttet at implementere dataregistrering af ændringsdata på kildetabellerne ved brug af et kommercielt tilgængeligt ETL-værktøj. Løsningen fungerer på følgende måde:

En Cron-lignende planlægning afvikler et batchjob, der tildeler kundeemner til brugere og teams.
Når batchjobbet er kørt og opdateret, genkender ETL-værktøjet disse ændringer ved hjælp af ændringsdataregistrering. ETL-værktøjet samler ændringerne fra datalageret.
ETL-forbindelsen bruger Salesforce REST API til at indlæse ændringerne i Salesforce.

Kontekst

Du bruger Salesforce til at spore emner, administrere din pipeline, oprette salgsmuligheder og registrere bestillingsdetaljer, der konverterer emner til kunder. Salesforce-systemet opretter bestillingerne internt og overfører derefter disse data til det eksterne faktureringssystem til provisionering og aktivering. Faktureringsbestillinger administreres af et eksternt (fjernanmodningssystem). Dette fjernsystem skal opdatere bestillingsstatussen i Salesforce, når bestillingen eller faktureringsenheden på faktureringssystemets status ændres.

Problem

Hvordan opretter et fjernsystem forbindelse og godkendelse med Salesforce for at advisere Salesforce om eksterne begivenheder, oprette registreringer og opdatere eksisterende registreringer?

Kræfter

Der er forskellige kræfter, du skal overveje, når du anvender løsninger baseret på dette mønster:

Er formålet med fjernopkaldet til Salesforce at advisere Salesforce om en begivenhed, der forekom eksternt ved brug af en begivenhedsstyret arkitektur? Eller er formålet med at udføre CRUD-handlinger på specifikke registreringer? Hvis du bruger en begivenhedsstyret arkitektur, afkobles begivenhedsproduceren (fjernprocessen) fra Salesforce-begivenhedsforbrugeren.
Kræver opkaldet til Salesforce, at fjernprocessen venter på et svar, før den fortsætter behandlingen? Fjernopkald til Salesforce er altid synkront anmodnings-svar, selvom fjernprocessen kan kassere svaret, hvis det ikke er nødvendigt for at simulere et asynkront opkald.
Fungerer hver transaktion mod et enkelt Salesforce-objekt eller flere relaterede objekter?
Hvad er formatet på meddelelsen (f.eks. SOAP eller REST eller begge over HTTP)?
Er meddelelsesstørrelsen relativt lille eller stor?
Hvis fjernsystemet er SOAP-kompatibelt, kan fjernsystemet deltage i en kontraktførende tilgang, hvor Salesforce dikterer kontrakten? Dette er påkrævet, hvor vores SOAP API bruges, som der leveres en foruddefineret WSDL for.
Er transaktionsbehandling krævet?
Hvor tolerant er du over for tilpasning i Salesforce?

Løsning

Denne tabel indeholder forskellige løsninger på dette integrationsproblem.

Løsning	Tilpas	Kommentarer
Sammensat API	Best	Salesforce leverer en sammensat API, som er en REST API og understøtter sammensatte anmodninger. Dette kan bruges af fjernsystemer til at: Send op til 25 anmodninger i et enkelt opkald. Til forespørgsel, oprettelse og redigering af data i Salesforce-organisationen ved brug af JSON-anmodninger. Synkron API – Når API-kaldet er foretaget, venter fjernklientapplikationen, indtil den modtager et svar fra tjenesten. Transaktion/Forpligtelsesadfærd – Som standard tillader sammensat API ikke delvis succes, hvis nogle registreringer er markeret med fejl. Dette kan ændres ved at markere "alle eller ingenting"-flaget som falsk, hvilket vil tillade delvis succes. Fejlhåndtering: Korrekt fejlhåndtering bør undersøge svarbrødteksten, ikke kun HTTP-statuskoder. Et sammensat slutpunkt svarer med 200 HTTP-statuskode, selvom det i svarbrødteksten viser, at en af underanmodningerne mislykkedes, og transaktionen skulle rulles tilbage.
Sammensat diagram-API	Best	Den sammensatte diagramressource giver dig mulighed for at indsende sammensatte diagramhandlinger. Denne ressource er tilgængelig i REST API version 50.0 og nyere. Sammensat diagram-API kan understøtte op til 75 grafer i en dataindlæsning og maksimalt 500 noder i et diagram.
REST API	Best	Tilgængelighed – Salesforce leverer en REST API, som fjernsystemer kan bruge til at: Udgiv begivenheder for at advisere din Salesforce-organisation Forespørg på data i din organisation - ved brug af enten forespørgselsressourcen eller Navngiven forespørgsels-API Opret, opdater og slet data Få metadata om din organisation Synkron API – Når API-kaldet er foretaget, venter fjernklientapplikationen, indtil den modtager et svar fra tjenesten. REST API respekterer sikkerhed på objektniveau og feltniveau, der er konfigureret i Salesforce baseret på den påloggede brugers profil. REST viser ressourcer (enheder/objekter) som URI'er og bruger HTTP-verber til at definere CRUD-handlinger på disse ressourcer. I modsætning til SOAP kræver REST API ingen foruddefineret kontrakt, bruger XML og JSON til svar og har løs skrivning. REST API er let og giver en enkel metode til at interagere med Salesforce. Dets fordele omfatter nem integration og udvikling, og det er et fremragende valg til brug med mobilapps og webapps. Transaktion/Forpligtelsesadfærd – Som standard behandles hver registrering som en separat transaktion og bekræftes separat. Fejl i en registreringsændring medfører ikke tilbagerulning af andre registreringsændringer. Denne adfærd kan ændres til en "alle eller ingenting"-adfærd. Brug de sammensatte REST API-ressourcer til at foretage en række opdateringer i et API-kald. Massedata – Enhver datahandling, der inkluderer mere end 2.000 registreringer, er en god kandidat for Bulk API 2.0 til at forberede, eksekvere og administrere et asynkront arbejdsflow, der bruger massestrukturen.
Bulk API 2.0	Bedst til massehandlinger	Bulk API 2.0 er Salesforces moderne, strømlinede API til håndtering af datahandlinger i stor skala. Den REST-baserede Bulk API 2.0 giver en programmeringsmæssig mulighed for asynkront at indsætte, upsertere, forespørge på eller slette store datasæt i din Salesforce-organisation. Den er designet til effektivitet, når du har brug for at indlæse store mængder af data i Salesforce eller udføre masseforespørgsler på din organisations data. Bulk API 2.0 behandler altid batches parallelt og understøtter ikke seriel tilstand. Dette betyder, at: Registreringer behandles samtidigt på tværs af flere tråde Der er ingen garanti for behandlingsbestilling mellem batches Der er højere ydeevne, men også et potentiale for låseafstemning Hvert batch i Bulk API 2.0 behandles som sin egen transaktion. Dette betyder: Succesfulde batches bekræfter uafhængigt Mislykkede batches påvirker ikke vellykkede batches Som standard er der ingen "alle-eller-ingen"-adfærd på tværs af alle job Selvom SOAP API også kan bruges til behandling af et stort antal registreringer, bliver det mindre optimalt, når datasæt indeholder hundredtusinder til millioner af registreringer. Dette skyldes dets relativt høje overhead- og lavere ydeevnekarakteristika. Begivenhedsstyret arkitektur – Platformsbegivenheder defineres på samme måde, som du definerer Salesforce-objekter. Udgivelse af en begivenhed via Bulk API 2.0 er det samme som at oprette en Salesforce-registrering. Kun handlingerne Opret og Indsæt understøttes. Begivenheder i en batch udgives til Salesforce-begivenhedsbussen asynkront, når batchjobbet behandles.
GraphQL API	Best	For fjernopkaldsscenarier, der involverer komplekse, flerobjektlæsninger med selektive felter, er GraphQL en overlegen valgmulighed i forhold til REST API.
Pub/Sub API	Best	Pub/Sub API er den anbefalede måde for eksterne handlingsområder at udgive begivenheder på begivenhedsbussen. Pub/Sub API er en gRPC-baseret API, der tillader eksterne systemer at udgive platformsbegivenheder. Pub/Sub API: Understøtter både udgivelse og abonnement på platformsbegivenheder fra eksterne applikationer Er tilgængelig med korrekt godkendelse (OAuth-, JWT- eller sessionstokener)
Platformsbegivenheder	Best	Platformsbegivenheder defineres på samme måde, som du definerer Salesforce-objekter. Platformsbegivenheder kan udgives ved brug af forskellige mekanismer som REST-API'er, Bulk API og SOAP-API'er. Udgivelse af en begivenhed via REST API er det samme som oprettelse af en Salesforce-registrering. Slutpunktsformat: POST /services/data/vXX.X/sobjects/EventName__e/ Indholdstype: application/json Godkendelse: Bearertoken (OAuth) Med Bulk API understøttes kun handlingerne Opret og Indsæt. Begivenheder i en batch udgives til Salesforce-begivenhedsbussen asynkront, når batchjobbet behandles. Da platformsbegivenheder er SObjects, understøttes SOAP API-standardhandlinger.
SOAP API	Suboptimal	Tilgængelighed – Salesforce leverer en SOAP API, som fjernsystemer kan bruge til at: Udgiv begivenheder for at advisere din Salesforce-organisation Forespørg på data i din organisation Opret, opdater og slet data Få metadata om din organisation Kør hjælpeprogrammer til at udføre administrative opgaver Synkron API – Når API-kaldet er foretaget, venter fjernklientapplikationen, indtil den modtager et svar fra tjenesten. Asynkrone opkald til Salesforce understøttes ikke. Genereret WSDL – Salesforce leverer to WSDL'er til fjernsystemer: Enterprise WSDL – Leverer en stærkt typet WSDL, der er specifik for en Salesforce-organisation. Partner WSDL – Indeholder en løst indtastet WSDL, der ikke er specifik for en Salesforce-organisation. Sikkerhed – Klienten, der kører SOAP API, skal have et gyldigt login og få en session for at udføre eventuelle API-kald. API respekterer sikkerhed på objektniveau og feltniveau, der er konfigureret i Salesforce baseret på den påloggede brugers profil. Transaktion/Forpligtelsesadfærd – Som standard tillader hvert API-kald delvis succes, hvis nogle registreringer er markeret med fejl. Dette kan ændres til en "alle eller ingenting"-adfærd, hvor alle resultaterne rulles tilbage, hvis der opstår en fejl. Det er ikke muligt at strække en transaktion over flere API-kald. For at overvinde denne begrænsning er det muligt for et enkelt API-kald at påvirke flere objekter. SOAP kræver betydelig Knowledge af Salesforce-objektmodellen, API-mekanismer og SOAP-meddelelseshåndtering. Disse yderligere faktorer gør REST foretrukket frem for SOAP.
Apex webtjenester	Suboptimal	Apex kan vises som webtjenestemetoder til eksterne applikationer. Denne metode er et alternativ til SOAP API og bruges typisk kun, hvor følgende yderligere krav skal opfyldes. Fuld transaktionel support kræves (f.eks. opret en konto, kontakt og salgsmulighed i en transaktion). Tilpasset logik skal anvendes på Salesforce-siden, før bekræftelse. Fordelen ved at bruge en Apex webtjeneste skal vejes op i forhold til den yderligere kode, der skal vedligeholdes i Salesforce. Ikke gældende for platformsbegivenheder, da transaktionsforudindsættelseslogik for forbrugeren ikke gælder i en begivenhedsstyret arkitektur. Hvis du vil advisere en Salesforce-organisation om, at der er forekommet en begivenhed, skal du bruge SOAP API, REST API eller Bulk API 2.0. SOAP kræver betydelig Knowledge af Salesforce-objektmodellen, API-mekanismer og SOAP-meddelelseshåndtering. Disse yderligere faktorer gør REST foretrukket frem for SOAP.
Apex REST-tjenester	Suboptimal	En Apex kan vises som REST-ressourcer, der er tilknyttet specifikke URI'er med et defineret HTTP-verb (f.eks. POST eller GET). Du kan bruge sammensatte REST API-ressourcer til at udføre flere opdateringer i en enkelt transaktion. I modsætning til SOAP er der ingen grund til, at klienten skal bruge en servicedefinition/kontrakt (WSDL) og generere klientstubs. Fjernsystemet kræver kun muligheden for at oprette en HTTP-anmodning og behandle de returnerede resultater (XML eller JSON). Ikke gældende for platformsbegivenheder, da transaktionsforudindsættelseslogik for forbrugeren ikke gælder i en begivenhedsstyret arkitektur. Hvis du vil advisere en Salesforce-organisation om, at der er forekommet en begivenhed, skal du bruge SOAP API, REST API eller Bulk API 2.0.

Sketch

Følgende diagrammer illustrerer sekvensen af begivenheder, når du implementerer dette mønster ved brug af enten REST API for adviseringer fra eksterne begivenheder eller SOAP API til at forespørge på et Salesforce-objekt. Sekvensen af begivenheder er den samme, når der bruges REST API.

Fjernsystemforespørgsel til Salesforce via REST API

Fjernsystem forespørger på Salesforce via REST API

Fjernsystem, der adviserer Salesforce om begivenheder via REST API

Fjernsystem, der adviserer Salesforce om begivenheder via REST API

Resultater

I en begivenhedsstyret arkitektur kalder fjernsystemet Salesforce ved brug af SOAP API, REST API eller Bulk API 2.0 for at udgive en begivenhed til Salesforce-begivenhedsbussen. Udgivelse af en begivenhed adviserer alle abonnenter. Begivenhedsabonnenter kan være på Salesforce Platform, f.eks. Forløb eller Lightning, Apex. Begivenhedsabonnenter kan også være eksterne for Salesforce Platform, f.eks. Pub/Sub API-abonnenter.

Når du arbejder direkte med Salesforce-objekter, gør de løsninger, der er relateret til dette mønster, det muligt at:

Fjernsystemet kalder Salesforce-API'er for at forespørge på databasen og udføre enkeltobjekthandlinger (opret, opdater, slet osv.).
Fjernsystemet til at kalde sammensatte Salesforce REST API-ressourcer for at udføre en række objekthandlinger.
Fjernsystem til at kalde tilpassede Salesforce-API'er (tjenester), der kan understøtte transaktionshandlinger med flere objekter og tilpasset før/efter-behandlingslogik.

Opkaldsmekanismer

Kaldsmekanismen afhænger af den løsning, der er valgt for at implementere dette mønster.

Opkaldsmekanisme	Beskrivelse
SOAP API	Fjernsystemet bruger Salesforce Enterprise eller Partner WSDL til at generere klientstubs, der igen bruges til at kalde SOAP API-standarden.
REST API	Fjernsystemet skal godkendes, før der åbnes en Apex REST-tjeneste. Fjernsystemet skal bruge OAuth 2.0 til godkendelse og autorisation. Klienten skal angive autorisationens HTTP-sidehoved med den relevante værdi som et OAuth-adgangstoken. Fjernsystemet genererer derefter REST-kald (HTTP-anmodninger) med de relevante verber og behandler de returnerede resultater (JSON- og XML-dataformater understøttes).
Apex webtjeneste	Fjernsystemet bruger den tilpassede Apex webtjeneste WSDL til at generere klientstubs, der igen bruges til at kalde den tilpassede Apex webtjeneste.
Apex REST-tjeneste	I henhold til REST API defineres ressource-URI'en og gældende verber ved brug af @RestResource, @HttpGet og @HttpPost-anmærkninger.
Bulk API 2.0	Bulk API 2.0 er en REST-baseret API, så de samme kaldemekanismer som REST API gælder.
REST API til at kalde forløb	Brug REST API til at kalde et tilpasset handlingsslutpunkt, der kan kaldes, for at kalde et automatisk startet forløb.

Fejlhåndtering og gendannelse

En fejlhåndterings- og gendannelsesstrategi skal tages med i betragtning som en del af den overordnede løsning.

Fejlhåndtering – Alle fjernopkaldsmetoder, standard- eller tilpassede API'er, kræver, at fjernsystemet håndterer eventuelle efterfølgende fejl, f.eks. timeouts og administration af forsøg. Mellemware kan bruges til at levere logik til fejlhåndtering og gendannelse.
Gendannelse – Opbyg en tilpasset prøvemekanisme, hvis krav til servicekvalitet kræver det. I denne situation er det vigtigt at sikre idempotente designegenskaber. Platformsbegivenhed gør det muligt for abonnenter at bruge afspilnings-id'et til at hente meddelelser inden for en bestemt tidsperiode, efter disse meddelelser er udgivet.

Idempotent Design Overvejelser

Idempotent-funktioner garanterer, at gentagne kald er sikre og ikke vil have en negativ virkning. Hvis idempotence ikke implementeres, kan gentagne kald af den samme meddelelse have forskellige resultater, hvilket potentielt resulterer i problemer med dataintegritet, f.eks. oprettelse af dubletregistreringer, dubletbehandling af transaktioner osv.

Fjernsystemet skal administrere flere (dobbelt) opkald i tilfælde af fejl eller timeouts for at undgå dubletindsættelser og overflødige opdateringer (især hvis downstream-udløsere og arbejdsflowregler udløses). Selvom det er muligt at administrere nogle af disse situationer i Salesforce (især i tilfælde af tilpassede SOAP- og REST-tjenester), anbefaler vi, at fjernsystemet (eller middleware) administrerer fejlhåndtering og idempotent-design.

Sikkerhedsovervejelser

Der gælder forskellige sikkerhedsovervejelser, afhængigt af den valgte mønsterløsning. I alle situationer bruger platformen den påloggede brugers adgangsrettigheder (f.eks. profilindstillinger, delingsregler, tilladelsessæt osv.). Endvidere kan profil-IP-begrænsninger bruges til at begrænse adgang til API for et specifikt IP-adresseområde.

Løsning	Sikkerhedsovervejelser
SOAP API	Salesforce understøtter transportlagsikkerhedsprotokoller (TLS 1.2 eller nyere). Koder skal have en nøglelængde på mindst 128 bit.
REST API	Vi anbefaler, at fjernsystemet etablerer en OAuth Trust til godkendelse. REST-kald kan derefter foretages på specifikke ressourcer ved brug af HTTP-verb. Vi anbefaler, at klienter, der kalder REST API, derefter cachelagrer og genbruger OAuth-tokenet for at maksimere ydeevnen i stedet for at få et nyt OAuth-token for hvert kald.
Apex webtjeneste	Vi anbefaler, at fjernsystemet etablerer en OAuth Trust til godkendelse.
Apex REST-tjeneste	Vi anbefaler, at fjernsystemet etablerer en OAuth Trust til godkendelse.
Bulk API 2.0	Vi anbefaler, at fjernsystemet etablerer en OAuth Trust til godkendelse.

Se Sikkerhedsovervejelser.

Sidebars

Ingen.

Tidlighed

SOAP API og Apex Web Service API er synkrone. Følgende timeouts gælder:

Sessionstimeout – Sessionen udløber, hvis der ikke er nogen aktivitet baseret på Salesforce-organisationens sessionstimeoutindstilling.
Forespørgselstimeout – Hver SOQL-forespørgsel har en individuel timeoutgrænse på 120 sekunder.

Datamængder

Datamængdeovervejelser afhænger af, hvilken løsning og kommunikationstype du vælger.

Løsning	Kommunikationstype	Begrænsninger
SOAP API eller REST API	Synkron	Opret, Opdater, Slet – Fjernsystemet kan oprette, opdatere eller slette op til 200 registreringer ad gangen. Der kan foretages flere opkald for at behandle mere end 200 registreringer i alt, men hver anmodning er begrænset til 200 registreringer i størrelse. BLOB-data – Du kan bruge SObject-basisoplysninger, SObject Rows eller SObject Collections REST-ressourcer til at indsætte eller opdatere BLOB-data i Salesforce-standardobjekter. For ressourcerne SObject-basisoplysninger eller SObject-rækker er den maksimale filstørrelse for uploads 2 GB for ContentVersion-objekter og 500 MB for alle andre kvalificerede standardobjekter. Ved at bruge SObject-samlingsressourcer er den maksimale samlede størrelse på alle filer i en enkelt anmodning 500 MB. Størrelse på forespørgselsresultater – Som standard er antallet af rækker, der returneres i forespørgselsresultatobjektet (batchstørrelse), returneret i et query() eller queryMore()-kald indstillet til 500. Det maksimale antal rækker, der returneres, er 2.000. Du kan eksplicit angive batchstørrelsen, men der er ingen garanti for, at den ønskede batchstørrelse vil være den faktiske batchstørrelse. Dette gøres for at maksimere ydeevnen. Hvor antallet af rækker, der skal returneres, overskrider batchstørrelsen, skal du bruge queryMore() API-kaldet til at gentage gennem flere batches. Yderligere regler kan gælde, hvis du ønsker yderligere oplysninger. Begivenhedsmeddelelse – Den maksimale størrelse på begivenhedsmeddelelsen er 1 MB. Udgivelse af en begivenhed ved brug af Salesforce-API'er tæller med i dine API-standardgrænser.
Bulk API 2.0	Asynkron	Bulk API 2.0 er optimeret til import og eksport af store datasæt asynkront. Enhver datahandling, der inkluderer mere end 2.000 registreringer, er en god kandidat for Bulk API 2.0 til at forberede, eksekvere og administrere et asynkront arbejdsflow, der bruger massestrukturen. Job med færre end 2.000 registreringer skal involvere "masseinddelte" synkrone opkald i REST (f.eks. Sammensat) eller SOAP. Bulk API 2.0 er synkront, når batchanmodningen og tilknyttede data sendes. Den faktiske behandling af dataene forekommer asynkront. Hvis du ønsker flere oplysninger om API- og batchbehandlingsgrænser, kan du se grænser.

Support af slutpunktsfunktioner og standarder

Funktionaliteten og standardunderstøttelsen af slutpunktet afhænger af den løsning, du vælger.

Løsning	Overvejelser i forbindelse med slutpunkter
SOAP API	Fjernsystemet skal kunne implementere en klient, der kan kalde Salesforce SOAP API, baseret på et meddelelsesformat, der er defineret på forhånd af Salesforce. Fjernsystemet (klienten) skal deltage i en kontraktfør-implementering, hvor kontrakten leveres af Salesforce (f.eks. Enterprise eller Partner WSDL).
REST API	Fjernsystemet skal kunne implementere en REST-klient, der kalder Salesforce – definerede REST-tjenester og behandler XML- eller JSON-resultaterne.
Apex webtjeneste	Fjernsystemet skal kunne implementere en klient, der kan kalde SOAP-meddelelser i et foruddefineret format som defineret af Salesforce. Fjernsystemet skal deltage i en code-first-implementering, hvor kontrakten leveres af Salesforce, når Apex webtjenesten er implementeret. Hver Apex webtjeneste har sin egen WSDL.
Apex REST-tjeneste	De samme slutpunktsovervejelser, som REST API gælder.

Statsforvaltning

Når du integrerer systemer, er nøgler vigtige for løbende tilstandssporing, f.eks. hvis der oprettes en registrering i fjernsystemet, for at understøtte igangværende opdateringer af den pågældende registrering. Der er to muligheder:

Salesforce lagrer fjernsystemets primære eller entydige alternativnøgle for fjernregistreringen.
Fjernsystemet lagrer det entydige Salesforce-registrerings-id eller en anden entydig alternativnøgle. Der er specifikke overvejelser i forbindelse med håndtering af integrationsnøgler i dette synkrone mønster.

Master	Systembeskrivelse
Salesforce	I dette scenarie lagrer fjernsystemet enten Salesforce RecordId eller en anden entydig alternativnøgle fra registreringen.
Fjernsystem	I dette scenarie lagrer Salesforce en reference til den entydige identifikator i fjernsystemet. Da processen er synkron, kan nøglen angives som en del af den samme transaktion ved brug af eksterne id-felter.

Komplekse integrationsscenarier

Hver løsning i dette mønster har forskellige overvejelser, når der håndteres komplekse integrationsscenarier, f.eks. transformation og procesorkestrering.

Løsning	Overvejelser
SOAP API eller REST API	SOAP API og REST API giver mulighed for enkle transaktioner på objekter. Komplekse integrationsscenarier, f.eks. aggregering, orkestrering og transformation, kan ikke udføres i Salesforce. Disse scenarier skal håndteres af fjernsystemet eller middleware med middleware som den foretrukne metode.
Apex webtjeneste eller Apex REST-tjeneste	Tilpassede webtjenester kan levere krydsobjektfunktionalitet, tilpasset logik og mere kompleks transaktionsunderstøttelse. Denne løsning skal bruges med omhu, og du bør altid overveje egnetheden af middleware til enhver transformation, orkestrering og fejlhåndteringslogik.

Governor Limits

På grund af multilejerens karakter af Salesforce-platformen er der begrænsninger, når der bruges API'er.

Løsning	Begrænsninger
SOAP API, REST API og tilpassede Apex'er	API-anmodningsgrænser – Salesforce anvender en grænse på antallet af API-kald pr. 24-timers periode. Grænsen er baseret på Salesforce-versionstypen og antallet af licenser. For eksempel leverer Unlimited Edition 5.000 API-anmodninger pr. Salesforce Platform-licens pr. 24 timer. Hvis du ønsker yderligere oplysninger, kan du se Hurtig reference til Salesforce Developer-grænser og tildelinger. API-forespørgselsmarkørbegrænsninger – En bruger kan have op til 10 forespørgselsmarkører åbne ad gangen. Ellers frigives den ældste af de 10 markører. Hvis fjernapplikationen forsøger at åbne den frigivne forespørgselsmarkør, resulterer der en fejl. Hvis du f.eks. deler integrationsbrugerlegitimationsoplysninger, skal de maksimale forespørgselsmarkører tages med i betragtning. Når det er muligt, skal middleware fuldføre den fulde forespørgsel, før der afvikles en anden forespørgsel (på en seriel måde), eller hver applikation skal bruge en udpeget integrationsbruger. Alternativt kan middleware have brug for at køre anmodninger på tværs af flere brugere på en "round robin"-mode. Opkaldsgrænser – Se sidepanelet Datamængder for oprettelses-, opdaterings- og forespørgselsgrænser.
Bulk API 2.0	Se sidepanelet Datamængder for at få flere oplysninger.
Platformsbegivenheder	Begrænsninger for begivenhedsadviseringer – Et maksimum på 100.000 begivenheder kan udgives pr. time for standardvolumen platformsbegivenheder. Der kan maksimalt udgives 250.000 begivenheder pr. time for højvolumen anvendelsesbaserede platformsbegivenheder. Hvis du vil overvåge højvolumen begivenhedsanvendelse, skal du bruge REST API-begrænsningsressource. Begrænsninger for størrelse på begivenhedsmeddelelser – Den maksimale størrelse på begivenhedsmeddelelser er 1 MB. Udgivelse af en begivenhed ved brug af Salesforce-API'er tæller med i dine API-standardgrænser.

Pålidelige meddelelser

Pålidelige meddelelser forsøger at løse problemet med at garantere leveringen af en meddelelse til et fjernsystem, hvor de individuelle komponenter i sig selv kan være upålidelige. Salesforce SOAP API og REST API er synkrone og giver ikke eksplicit understøttelse af nogen pålidelige meddelelsesprotokoller i sig selv (f.eks. WS-ReliableMessaging).

Vi anbefaler, at fjernsystemet implementerer et pålideligt meddelelsessystem for at sikre, at fejl- og timeoutscenarier administreres korrekt. Udgivelse af platformsbegivenheder fra eksterne systemer er baseret på Salesforce-API'er, så de samme overvejelser gælder for SOAP API og REST API.

Middleware-funktioner

Denne tabel fremhæver de ønskede egenskaber for et middleware-system, der deltager i dette mønster:

Egenskab	Obligatorisk	Ønsket	Ikke påkrævet
Begivenhedshåndtering		X
Protokolkonvertering		X
Oversættelse og transformation		X
Kø og buffering	X
Synkrone transportprotokoller	X
Asynkrone transportprotokoller			X
Mediationsdistribution		X
Proces koreografi og serviceorkestrering		X
Transaktionalitet (kryptering, signering, pålidelig levering, transaktionsstyring)	X
Distribution			X
Udtræk, transformer og indlæs		X (for masser/batches)
gRPC-understøttelse (for Pub/Sub API)		X

Eksempel

Et firma med udskriftsmaterialer og tjenester bruger Salesforce som en front-end til at oprette og administrere printerleveringer og bestillinger. Salesforce-aktivregistreringer, der repræsenterer printere, opdateres regelmæssigt med udskrivningsanvendelsesstatistikker (blækstatus, papirniveau) fra det lokale printerstyringssystem (PMS), som regelmæssigt overvåger printere på klientlokaliteter. Når en angivet tærskelværdi er nået (f.eks. lavt blækstatus eller lavt/tomt papirniveau på mindre end 30 %), adviseres flere apps/processer (variabel), der er interesseret i begivenheden, sendes der mail- eller Chatter, og der oprettes en bestillingsregistrering. PMS lagrer Salesforce-id'et (Salesforce er den overordnede aktivregistrering).

Følgende begrænsninger gælder:

PMS kan deltage i en kontrakt-første-integration, hvor Salesforce leverer kontrakten, og PMS fungerer som en klient (forbruger) af Salesforce-tjenesten (defineret via Enterprise eller Partner WSDL).
Der skal ikke være nogen tilpasset udvikling i Salesforce.

Dette eksempel implementeres bedst ved brug af Salesforce SOAP API eller REST API til at udgive begivenheder og deklarativ automatisering (forløb) i Salesforce. Den primære årsag til at bruge platformsbegivenheder er variablen og ikke-begrænset antal abonnenter. Men for enkle opdateringer til en begrænset liste over registreringer, f.eks. bestillinger, skal du derefter bruge SOAP eller REST API til at opdatere registreringerne.

I Salesforce:

Definer en platformsbegivenhed i Salesforce til at indeholde adviseringsdata, der kommer fra PMS.
Opret et forløb, der udløses af printerbegivenhedsadviseringen. Processen opdaterer printeraktivet og opretter en bestilling (ved brug af et automatisk startet forløb).
Download Enterprise- eller Partner WSDL, og giv det til fjernsystemet.

I fjernsystemet:

Opret en klientstump fra Enterprise- eller Partner WSDL.
Godkend til Salesforce (via OAuth-webserver eller bearertokenforløb) ved brug af integrationsbrugerens legitimationsoplysninger.
Ved en printerstatusbegivenhed kalder PMS API'en for at oprette platformsbegivenheden for printerstatus (med statistikker for printeranvendelse). Salesforce-begivenhedsbussen adviserer forløbsabonnenten og alle andre abonnenter.

Når du bruger platformsbegivenheder, giver begivenhedsbussen dig mulighed for at afspille begivenheder i 72 timer for højvolumen platformsbegivenheder. Udgivelse af disse begivenheder ved brug af en middleware-løsning kan hjælpe med at indarbejde fejlhåndtering på udgivelsessiden. Du kan dog implementere fejlhåndtering på abonnementsiden, hvis du har brug for højere pålidelighed.

Dette eksempel viser følgende:

Implementering af en Salesforce synkron API-klient (forbruger).
Et tilbagekald til Salesforce for at udgive en platformsbegivenhed (justeret med tidligere dækkede anmodnings-/svarplatformsbegivenhedsmønstre).

Kontekst

Du bruger Salesforce til at administrere kundesager. En kundeservicerepræsentant er i telefonen med en kunde, der arbejder på en sag. Kunden foretager en betaling, og kundeservicerepræsentanten skal se en opdatering i realtid i Salesforce-applikationen fra betalingsbehandlingsapplikationen, der angiver, at kunden har betalt bestillingens udestående beløb.

Problem

Når der forekommer en begivenhed i Salesforce, hvordan kan brugeren adviseres i Salesforce-brugergrænsefladen uden at skulle opdatere sin skærm og potentielt miste arbejde?

Kræfter

Der er forskellige kræfter, du skal overveje, når du anvender løsninger baseret på dette mønster:

Skal de data, der handles på, gemmes i Salesforce?
Kan der opbygges et tilpasset brugergrænsefladelag til visning af disse data?
Vil brugeren have adgang til at kalde den tilpassede brugergrænseflade?

Løsning

Den anbefalede løsning på dette integrationsproblem er at bruge platformsbegivenheder, der sikrer næsten realtidsbegivenheder i Salesforce. Platformsbegivenheder giver en struktureret, fleksibel data, der er uafhængig af ethvert Salesforce-objekt. De sikrer også holdbare emner med et genafspilningsvindue på 72 timer. Dette vindue garanterer, at begivenheder er tilgængelige, selvom en offline forbruger bliver tilgængelig senere. Denne løsning består af følgende komponenter:

Apex eller forløb med en logik til at udgive en platformsbegivenhed på et emne
Et emne, der giver dig mulighed for at udgive en begivenhed fra Apex eller forløb
Pub/Sub API (baseret på gRPC og HTTP/2) til effektiv forbrug af platformsbegivenheder
En Lightning
Et JavaScript-bibliotek, der er inkluderet som en statisk ressource

Sketch

Følgende diagram illustrerer, hvordan Pub/Sub API kan implementeres til at streame adviseringer til Salesforce-brugergrænsefladen. Disse adviseringer udløses af registreringsændringer i Salesforce.

UI-opdatering i Salesforce udløst af en dataændring

UI-opdatering i Salesforce udløst af en dataændring

Resultater

Fordel

Anvendelsen af den løsning, der er relateret til dette mønster, har følgende fordele:

Eliminerer behovet for at skrive tilpassede afstemningsmekanismer
Eliminerer behovet for en brugerinitieret feedbackløbe

Ikke-understøttede krav

Løsningen har følgende begrænsninger:

Levering af adviseringer er ikke garanteret.
Rækkefølgen af adviseringer er ikke garanteret.
Adviseringer genereres ikke fra registreringsændringer, der er foretaget af Bulk API.

Sikkerhedsovervejelser

Salesforce-standardsikkerhed på organisationsniveau overholdes. Det anbefales, at du bruger HTTPS-protokollen til at oprette forbindelse til streaming-API'en. Se Sikkerhedshensyn

Sidebars

Den optimale løsning involverer oprettelse af en tilpasset brugergrænseflade i Salesforce. Det er vigtigt, at du tager højde for en relevant brugergrænsefladebeholder, der kan bruges til gengivelse af den tilpassede brugergrænseflade. Yderligere oplysninger findes i Pub/Sub API Developer Guide.

Eksempel

Et telekommunikationsfirma bruger Salesforce til at administrere kundesager. Kundeservicemanagers ønsker at blive adviseret, når en sag lukkes af en af deres kundeservicemedarbejdere.

Implementering af den løsning, der er foreskrevet af dette mønster, skal kunden:

Opret en Apex, der sender en platformsbegivenhed, når en sag gemmes med statussen "Lukket" og Løsning "Løses".
Opret en tilpasset brugergrænseflade, der er tilgængelig for kundeservicemanagers. Denne brugergrænseflade abonnerer på Pub/Sub API for at forbruge platformsbegivenheder.
Implementer logik i den tilpassede brugergrænseflade, der viser advarsler genereret af den pågældende managers kundeservicerepræsentanter.

Kontekst

Du bruger Salesforce til at spore emner, administrere din pipeline, oprette salgsmuligheder og registrere bestillingsdetaljer, der konverterer emner til kunder. Men Salesforce er ikke det system, der indeholder eller behandler bestillinger. Bestillinger administreres af et eksternt (fjernanmodningssystem). Men sælgere ønsker at se og opdatere bestillingsoplysninger i realtid i Salesforce uden at skulle lære eller bruge det eksterne system.

Problem

Hvordan ser, søger og redigerer du i Salesforce data, der er lagret uden for Salesforce, uden at flytte dataene fra det eksterne system til Salesforce?

Kræfter

Der er forskellige kræfter, du skal overveje, når du anvender løsninger baseret på dette mønster:

Ønsker du at opbygge en deklarativ/punk-og-klik-udgående integration eller brugergrænsefladens mashup i Salesforce?
Har du en stor mængde data, som du ikke ønsker at kopiere til din Salesforce-organisation?
Har du brug for at få adgang til små mængder af fjernsystemdata ad gangen?
Har du brug for adgang i realtid til de seneste data?
Gemmer du dine data i clouden eller i et back-office-system, men ønsker du at vise eller behandle disse data i din Salesforce-organisation?
Har du problemer med dataplacering for lagring af bestemte typer af data i Salesforce?

Løsning

Følgende tabel indeholder forskellige løsninger på dette integrationsproblem.

Løsning	Tilpas	Kommentarer
Salesforce Connect	Best	Brug Salesforce Connect til at få adgang til data fra eksterne kilder sammen med dine Salesforce-data. Hent data fra systemer som SAP, Microsoft, Oracle og andre cloudbaserede systemer som Snowflake i realtid uden at oprette en kopi af dataene i Salesforce. Salesforce Connect tilknytter datatabeller i eksterne systemer til eksterne objekter i din organisation. Eksterne objekter minder om tilpassede objekter, bortset fra at de er tilknyttet data, der er placeret uden for din Salesforce-organisation. Salesforce Connect bruger en liveforbindelse til eksterne data til altid at holde eksterne objekter opdateret. Adgang til et eksternt objekt henter dataene fra det eksterne system i realtid. Salesforce Connect giver dig mulighed for at: Forespørg på data i et eksternt system. Opret, opdater og slet data i et eksternt system. Få adgang til eksterne objekter via listevisninger, detaljesider, registreringsfeeds, tilpassede faner og sidelayouts. Definer relationer mellem eksterne objekter og standardobjekter eller tilpassede objekter for at integrere data fra forskellige kilder. Kør rapporter om eksterne data. (Bemærk: begrænsningerne for Rapporter og dashboards i Salesforce gælder stadig). Få vist dataene på Salesforce Mobile-appen. Hvis du vil have adgang til data, der er lagret på et eksternt system ved brug af Salesforce Connect, kan du bruge en af følgende adaptere: Odata adapter – opretter forbindelse til data, der vises af enhver Odata producent. Salesforce Connect understøtter version 4.01, 4.0 og 2.0. AWS og Snowflake – opretter forbindelse til data, der er lagret i Aten, DynamoDB eller Snowflake. Adapterne bruger disse platformers API'er til at vise kildedata. GraphQL - opretter forbindelse til data, der er lagret i AWS RDS ved brug af AWS AppSync for at levere en GraphQL-oversættelse. Krydsorganisationsadapter – opretter forbindelse til data, der er lagret i en anden Salesforce-organisation. Krydsorganisationsadapteren bruger Salesforce Platform REST API-standarden. I modsætning til Odata opretter krydsorganisationsadapteren direkte forbindelse til en anden organisation uden at skulle bruge en webtjeneste. Tilpasset adapter oprettet via Apex – hvis de andre adaptere ikke passer til dine behov, kan du udvikle din egen adapter med Apex Connector Framework. Dette er en mulig indstilling for ethvert system, der viser en HTTP/REST API.
Data 360 og Zero Copy	Best	Når en registrering opdateres i eksterne systemer som ERP, kan registreringsopdateringerne synkroniseres til Data 360 enten ved brug af tilgængelige indbyggede forbindelser eller ved brug af API'er og pro-code-værktøjer som MuleSoft. Der kan også refereres til registreringer i Data 360 ved brug af nulkopieringsmekanisme (tilgængelig med nogle platforme). Når data er tilgængelige i Data 360, kan forskellige indbyggede integrationsmekanismer bruges til at synkronisere dataene med andre Salesforce-organisationer. Data kan fås adgang til ved reference ved brug af Data Cloud One. Data kan også replikeres ved brug af aktiveringer og andre API'er ved brug af indbyggede forbindelser eller ved hjælp af pro-code-værktøjer som MuleSoft Anypoint-platformen. Bemærk: data i Data 360 kan ikke redigeres. Hvis dette er et krav, skal du bruge Salesforce Connect.
Data 360, Data Cloud One og Salesforce	Best	Harmoniser data fra forskellige kilder med Data 360 og Data Cloud One. Gennem Customer 360, identitetsløsning, datafederation og andre funktioner konsoliderer Data 360 data fra Salesforce og andre eksterne systemer i en forenet visning af din kunde. Med Data Cloud One kan brugere i andre Salesforce-organisationer sikkert få adgang til data, der deles virtuelt fra Data 360. Bemærk: data i Data 360 kan ikke redigeres. Hvis dette er et krav, skal du bruge Salesforce Connect.
Anmodning og svar	Suboptimal	Brug Salesforce Web Service-API'er til at foretage ad hoc-dataanmodninger for at få adgang til og opdatere eksterne systemdata. Denne løsning inkluderer følgende tilgange: Brug Salesforce SOAP API. En tilpasset side eller knap starter et Apex REST/SOAP-udkald på en synkron måde. I Salesforce kan du bruge en WSDL og generere en resulterende Apex. Denne klasse leverer den nødvendige logik til at kalde fjerntjenesten. En brugerinitieret handling på en side kalder derefter en Apex, der eksekverer denne Apex for at udføre fjernkaldet. Siderne kræver tilpasning af Salesforce-appen. Brug Salesforce REST API. En tilpasset side eller knap starter et Apex HTTP-udkald (REST-tjeneste) på en synkron måde. I Salesforce kan du kalde HTTP-tjenester ved brug af standardmetoderne GET, POST, PUT og DELETE. Hvis du ønsker flere oplysninger om denne løsning, kan du se Fjernproceskald – anmodning og svar.

Sketch

Følgende diagram illustrerer, hvordan du kan bruge Salesforce Connect til at hente data fra et eksternt system ved brug af en Odata

Salesforce Connect OData-adapterarkitektur

I dette scenarie:

Browseren foretager et AJAX-kald, der igen foretager en handling på den tilsvarende eksterne objektadapter.
Adapteren oversætter handlingen til en Odata og opretter en HTTP GET-anmodning til fjernsystemet via integrations- og servicelager.
Fjernsystemet returnerer et JSON-svar til Salesforce via integrations- og servicelager.
Svaret oversættes fra OData til et eksternt objekt og præsenteres tilbage i browseren.

Resultater

Anvendelsen af de løsninger, der er relateret til dette mønster, tillader brugergrænsefladeinitierede kald, hvor resultatet af transaktionen kan vises for slutbrugeren.

Opkaldsmekanismer

Kaldsmekanismen afhænger af den løsning, der er valgt for at implementere dette mønster.

Opkaldsmekanisme	Beskrivelse
Eksterne objekter	Salesforce Connect tilknytter eksterne Salesforce-objekter til datatabeller i eksterne systemer. I stedet for at kopiere dataene i din organisation, får Salesforce Connect adgang til dataene efter behov og i realtid. Selvom dataene er lagret uden for din organisation, giver Salesforce Connect problemfri integration med Salesforce Platform. Eksterne objekter er tilgængelige for Salesforce-værktøjer, f.eks. global søgning, opslagsrelationer, registreringsfeeds og Salesforce Mobile-appen. Eksterne objekter er også tilgængelige for Apex, SOSL, SOQL-forespørgsler, Salesforce-API'er og implementering via Metadata API, ændringssæt og pakker.
Lightning	Bruges, når fjernprocessen udløses som en del af en end-to-end-proces, der involverer brugergrænsefladen, og resultatet skal vises eller opdateres i en Salesforce-registrering. F.eks. en proces, der indsender kreditkortbetalinger til en ekstern betalingsgateway og straks returnerer betalingsresultater, der vises for brugeren. Integration, der udløses fra brugergrænsefladebegivenheder, kræver normalt oprettelse af tilpassede Lightning.

Opkaldsmekanisme

Beskrivelse

Eksterne objekter

Salesforce Connect tilknytter eksterne Salesforce-objekter til datatabeller i eksterne systemer. I stedet for at kopiere dataene i din organisation, får Salesforce Connect adgang til dataene efter behov og i realtid. Selvom dataene er lagret uden for din organisation, giver Salesforce Connect problemfri integration med Salesforce Platform. Eksterne objekter er tilgængelige for Salesforce-værktøjer, f.eks. global søgning, opslagsrelationer, registreringsfeeds og Salesforce Mobile-appen. Eksterne objekter er også tilgængelige for Apex, SOSL, SOQL-forespørgsler, Salesforce-API'er og implementering via Metadata API, ændringssæt og pakker.

Lightning

Bruges, når fjernprocessen udløses som en del af en end-to-end-proces, der involverer brugergrænsefladen, og resultatet skal vises eller opdateres i en Salesforce-registrering. F.eks. en proces, der indsender kreditkortbetalinger til en ekstern betalingsgateway og straks returnerer betalingsresultater, der vises for brugeren. Integration, der udløses fra brugergrænsefladebegivenheder, kræver normalt oprettelse af tilpassede Lightning.

Fejlhåndtering

Det er vigtigt at inkludere fejlhåndtering som en del af den overordnede løsning. Når der opstår en fejl (undtagelser eller fejlkoder returneres til opkalderen), administrerer opkalderen fejlhåndteringen. Salesforce Connect Validator er et gratis værktøj til at køre nogle almindelige forespørgsler og advarselsfejltyper og fejlårsager.

Fordel

Nogle af fordelene ved at bruge en Salesforce Connect er:

Denne løsning forbruger ikke datalagring i Salesforce.
Brugere behøver ikke at bekymre sig om regelmæssig synkronisering af data mellem det eksterne system og Salesforce.
En deklarativ opsætning, der hurtigt kan opnås med Odata eller en krydsorganisationsadapter eller ved brug af minimal kode med en tilpasset Apex
Brugere kan få adgang til eksterne data med meget af den samme funktionalitet som tilpassede objekter i form af eksterne objekter.
Mulighed for at foretage en forenet søgning i det tilsluttede eksterne system ved brug af global søgning.
Mulighed for at køre rapporter, der får adgang til eksterne data fra cloud og lokale kilder. Se rapporteringsovervejelser nedenfor.

Salesforce Connect-overvejelser

Salesforce Connect har følgende overvejelser:

Eksterne objekter fungerer som tilpassede objekter, men nogle funktioner er ikke tilgængelige for eksterne objekter. Hvis du ønsker yderligere oplysninger, kan du se Overvejelser i forbindelse med Salesforce-kompatibilitet for Salesforce Connect.
Eksterne objekter kan påvirke rapportydeevnen. Hvis du ønsker yderligere oplysninger, kan du se Rapportovervejelser i forbindelse med Salesforce Connect.
Hvis du ønsker yderligere oplysninger om brug af Salesforce Connect-adaptere, kan du se Overvejelser i forbindelse med Salesforce Connect – Alle adaptere.
Hvis du overvejer at bruge en krydsorganisationsadapter, kan du se Overvejelser i forbindelse med Salesforce Connect – krydsorganisationsadapter.
Hvis du overvejer at bruge en OData-adapter, kan du se Overvejelser i forbindelse med Salesforce Connect – OData 2.0- og 4.0-adaptere.
Hvis du overvejer at bruge en tilpasset Apex-adapter, kan du se Overvejelser i forbindelse med Salesforce Connect – tilpasset adapter.

Sikkerhedsovervejelser

Løsninger for dette mønster skal overholde Salesforce-standardsikkerhed på organisationsniveau. Det anbefales, at du bruger HTTPS-protokollen til at oprette forbindelse til ethvert fjernsystem. Se Sikkerhedsovervejelser for at få flere oplysninger

Hvis du bruger en Odata, skal du sørge for, at du forstår den specielle adfærd, begrænsninger og anbefalinger for CSRF (Cross-Site Request Forgery) på eksterne Odata. Hvis du ønsker yderligere oplysninger, kan du se CSRF Overvejelser i forbindelse med Salesforce Connect – OData 2.0- og 4.0-adaptere.

Sidebars

Ingen.

Tidlighed

Tidlighed er af væsentlig betydning i dette mønster. Husk på følgende punkter:

Anmodningen kaldes typisk fra brugergrænsefladen, så processen må ikke lade brugeren vente.
Afhængig af tilgængeligheden af og forbindelsen til det eksterne system kan det tage lang tid at hente eksterne data. Salesforce har en konfigurerbar maksimal timeoutværdi på 120 sekunder til at vente på et svar fra det eksterne system.
Færdiggørelse af fjernprocessen skal udføres rettidigt og fuldføres inden for Salesforce-timeoutgrænsen og inden for brugerens forventninger.

Datamængder

Support af slutpunktsfunktioner og standarder

Funktionaliteten og standardunderstøttelsen af slutpunktet afhænger af den løsning, du vælger.

Løsning	Overvejelser i forbindelse med slutpunkter
Salesforce Connect	Odata'er – Brug Open Data Protocol til at få adgang til data, der er lagret uden for Salesforce. De eksterne data skal vises via OData producenter. Andre API'er – Brug Apex Connector Framework til at udvikle din egen tilpassede adapter, når de andre tilgængelige adaptere ikke passer til dine behov. En tilpasset adapter kan hente data fra enhver kilde. Nogle data kan f.eks. hentes fra internettet via udkald, mens andre data kan manipuleres eller endda genereres programmeringsmæssigt. Opret forbindelse til Salesforce – Bruger Salesforce Platform REST API til at få adgang til data, der er lagret i andre Salesforce-organisationer. Opret forbindelse via Middleware – Salesforce Connect har samarbejdet tæt med Salesforce om at sikre, at deres middleware-gateways viser Odata fra deres tjeneste, så Salesforce kan oprette forbindelse til dem uden at skrive yderligere kode.
Anmod om og svar	Apex SOAP-udkald - Slutpunktet skal kunne modtage et webserviceopkald via HTTP. Apex HTTP-udkald - Slutpunktet skal kunne modtage HTTP-kald. Du kan bruge Apex HTTP-udkald til at kalde RESTful-tjenester ved brug af standardmetoderne GET, POST, PUT og DELETE

Løsning

Overvejelser i forbindelse med slutpunkter

Salesforce Connect

Odata'er – Brug Open Data Protocol til at få adgang til data, der er lagret uden for Salesforce. De eksterne data skal vises via OData producenter.

Andre API'er – Brug Apex Connector Framework til at udvikle din egen tilpassede adapter, når de andre tilgængelige adaptere ikke passer til dine behov. En tilpasset adapter kan hente data fra enhver kilde. Nogle data kan f.eks. hentes fra internettet via udkald, mens andre data kan manipuleres eller endda genereres programmeringsmæssigt.

Opret forbindelse til Salesforce – Bruger Salesforce Platform REST API til at få adgang til data, der er lagret i andre Salesforce-organisationer.

Opret forbindelse via Middleware – Salesforce Connect har samarbejdet tæt med Salesforce om at sikre, at deres middleware-gateways viser Odata fra deres tjeneste, så Salesforce kan oprette forbindelse til dem uden at skrive yderligere kode.

Anmod om og svar

Apex SOAP-udkald -

Slutpunktet skal kunne modtage et webserviceopkald via HTTP.

Apex HTTP-udkald -

Slutpunktet skal kunne modtage HTTP-kald.

Du kan bruge Apex HTTP-udkald til at kalde RESTful-tjenester ved brug af standardmetoderne GET, POST, PUT og DELETE

Statsforvaltning

Når du integrerer systemer, er nøgler vigtige for igangværende tilstandssporing. Hvis f.eks. en registrering oprettes i fjernsystemet, skal registreringen typisk have en slags identifikationsnøgle til at understøtte igangværende opdateringer. Der er to muligheder for lagring af nøgler.

Salesforce lagrer den primære eller entydige alternativnøgle for fjernregistreringen.
Fjernsystemet lagrer det entydige Salesforce-registrerings-id eller en anden entydig alternativnøgle. Der er specifikke overvejelser i forbindelse med håndtering af integrationsnøgler i dette synkrone mønster.

Overordnet system	Beskrivelse
Salesforce	Fjernsystemet lagrer enten Salesforce-registrerings-id'et eller en anden entydig alternativnøgle fra registreringen.
Fjernsystem	Kaldet til fjernprocessen returnerer den entydige nøgle fra applikationen, og Salesforce lagrer denne nøgleværdi i et entydigt registreringsfelt.

Komplekse integrationer

I visse situationer kan den løsning, der er foreskrevet af dette mønster, kræve implementering af et komplekst integrationsscenarie. Disse scenarier løses ofte ved brug af middleware.

Aggregering af opkald og deres resultater på tværs af opkald til flere systemer
Transformation af både indgående og udgående meddelelser
Vedligeholdelse af transaktionsintegritet på tværs af opkald til flere systemer
Andre procesorkestreringsaktiviteter mellem Salesforce og det eksterne system

Regulerende grænser

Forskellige begrænsninger gælder for forskellige adaptere. Hvis du ønsker yderligere oplysninger, kan du se Generelle begrænsninger for Salesforce Connect.

Middleware-funktioner

Følgende tabel fremhæver de ønskede egenskaber for et middleware-system, der deltager i dette mønster.

Egenskab	Obligatorisk	Ønsket	Ikke påkrævet
Begivenhedshåndtering		X
Protokolkonvertering	X
Oversættelse og transformation	X
Kø og buffering	X
Synkrone transportprotokoller	X
Asynkrone transportprotokoller		X
Mediationsdistribution		X
Proces koreografi og serviceorkestrering		X
Transaktionalitet (kryptering, signering, pålidelig levering, transaktionsstyring)	X
Distribution			X
Udtræk, transformer og indlæs			X
Lang polling			X
gRPC-understøttelse (for Pub/Sub API)			X

Eksterne objektrelationer

Eksterne objekter understøtter standardopslagsrelationer, som bruger det 18-tegns Salesforce-registrerings-id til at tilknytte relaterede registreringer. Men data, der er lagret uden for din Salesforce-organisation, indeholder ofte ikke disse registrerings-id'er. Derfor er der to specielle typer af opslagsrelationer tilgængelige for eksterne objekter: eksterne opslag og indirekte opslag.

Denne tabel opsummerer de typer af relationer, der er tilgængelige for eksterne objekter.

Relation	Tilladte underordnede objekter	Tilladte overordnede objekter	Overordnet felt for matchende registreringer
Opslag	Standard, Tilpasset, Ekstern	Standard, tilpasset	Det 18-tegns Salesforce-registrerings-id
Eksternt opslag	Standard, Tilpasset, Ekstern	Ekstern	Eksternt id-standardfelt
Indirekte opslag	Ekstern	Standard, tilpasset	Vælg et tilpasset felt med attributterne Eksternt id og Entydig

Overvejelser i forbindelse med høj datamængde for Salesforce Connect: Odata 2.0- og 4.0-adaptere

Hvis din organisation når frekvensgrænserne, når du får adgang til eksterne objekter, kan du overveje at vælge indstillingen Høj datamængde på de tilknyttede eksterne datakilder. Hvis du gør det, tilsidesættes de fleste vurderingsgrænser, men der gælder nogle specielle adfærdsmønstre og begrænsninger. Hvis du ønsker yderligere oplysninger, kan du se Overvejelser i forbindelse med høj datamængde for Salesforce Connect.

Klientstyret og serverstyret sideinddeling til Salesforce Connect: Odata 2.0- og 4.0-adaptere

Det er almindeligt for Salesforce Connect på eksterne data at have et stort resultatsæt, der er opdelt i mindre batches eller sider. Du bestemmer, om sideoprettelsen skal styres af det eksterne system (serverstyret) eller af Odata 2.0- eller 4.0-adapteren til Salesforce Connect (klientstyret). Feltet Serverstyret sideinddeling på den eksterne datakilde angiver, om der skal bruges klientstyret eller serverstyret sideinddeling. Hvis du aktiverer serverstyret sideinddeling på en ekstern datakilde, ignorerer Salesforce de ønskede sidestørrelser, herunder standardbatchstørrelsen queryMore() på 500 rækker. De sider, der returneres af det eksterne system, bestemmer batches, men hver side må ikke overstige 2.000 rækker. Begrænsningerne for Odata til Salesforce Connect gælder dog stadig.

Eksempel

Et manufacturing-firma bruger Salesforce til at administrere kundesager. Kundeserviceagenterne ønsker at få adgang til bestillingsoplysningerne i realtid fra back-office ERP-systemet for at få en 360-visning af kunden uden at skulle lære og køre rapporter manuelt i ERP.

Implementering af den løsning, der er foreskrevet af dette mønster, skal du:

Konfigurer din eksterne datakilde med et Odata. Din fjernapplikation kan indeholde indbygget understøttelse af OData. For andre applikationer har større integrationsleverandører som Dell Boomi, Informatica, Jitterbit, MuleSoft og Progress Software samarbejdet med Salesforce på Salesforce Connect om at opbygge adaptere.
Peg på Salesforce Connect ved Odata enten direkte eller gennem en middleware-løsning.
Synkroniser dine eksterne databasetabeller med eksterne objekter i Salesforce. Når en bruger får adgang til en side med data fra disse eksterne objekter, foretager Salesforce Connect udkald i realtid til dine back-end-applikationer.

Udviklerdokumentation

Trailhead

Salesforce bevæger sig mod hurtigere og begivenhedsstyrede arkitekturer. Migrering væk fra forældede integrationsværktøjer er nu påkrævet for at forblive sikker og skalerbar. Mange ældre værktøjer bruger forældede protokoller som SOAP eller lang afstemning (CometD), som ikke kan holde trit med Pub/Sub API's effektive gRPC-baserede levering eller automatiseringsstyrken i Flow Builder. Hvis du vil forberede dig, skal du starte med at overvåge dine eksisterende integrationer for at finde hardcodede afhængigheder. Dette er især vigtigt, da Salesforce begynder at trække funktioner som Salesforce-til-Salesforce tilbage (fuldt trukket tilbage til Spring '27) og udfaser ældre godkendelsesmetoder. Når du planlægger din migrering, skal du bruge en "Flow-first"-tilgang til intern forretningslogik og en "Pub/Sub-first"-tilgang til eksterne datastreams. Dette giver dig en fleksibel, afkoblet arkitektur, der er klar til datakravene i dagens AI-drevne platform.

login() i Salesforce SOAP API trækkes tilbage. Det er allerede ikke tilgængeligt i API v65.0 og nyere. Nye Salesforce-organisationer vil som standard have login() inaktiveret, og eksisterende organisationer skal have den nye tilladelse "Brug enhver API-godkendelse" for at fortsætte med at bruge den. Den hårde deadline er Summer '27, hvor Salesforce fuldt ud vil trække login() tilbage på tværs af alle API-versioner (31.0 til 64.0).

Produkt	Status	Foreslået alternativ	Migreringsstrategi
Udgående meddelelser	Forældet (understøttet)	Forløb + platformsbegivenheder	Erstat med forløbsudløste platformsbegivenheder for at få bedre prøvelogik og moderne godkendelse.
Proceskonstruktør	Slutning af support	Flow Builder	Brug værktøjet "Migrer til forløb" til at konvertere eksisterende processer; kompleks refactor-logik for ydeevne.
Salesforce-til-Salesforce	Tilbagetrækning forår ’27	Salesforce Connect eller Pub/Sub API	Skift dataregistrering, Salesforce Connect eller Pub/Sub API med MuleSoft
Streaming-API	Forældet (understøttet)	Pub/Sub API	Flyt til Pub/Sub API for at udnytte gRPC, som tilbyder højere gennemsnit og forenklet abonnementsstyring.
SOAP API `login()`	Legacy (understøttet indtil juni 2027)	OAuth 2.0-forløb	Flyt til OAuth2.0 ved brug af eksterne klientapps.

For at være effektive medlemmer af virksomhedsporteføljen skal alle applikationer oprettes og integreres med relevante sikkerhedsmekanismer. Moderne it-strategier anvender en kombination af lokale og cloudbaserede tjenester.

Mens integration af cloud-til-cloud-tjenester typisk fokuserer på webtjenester og tilknyttet autorisation, introducerer tilslutning af lokale og cloud-tjenester ofte øget kompleksitet. Dette afsnit beskriver sikkerhedsværktøjer, teknikker og Salesforce-specifikke overvejelser.

Reverse Proxy-server

En omvendt proxy er en server, der sidder foran webservere og videresender klientanmodninger (f.eks. webbrowser) til disse webservere. Omvendte proxyer implementeres typisk for at hjælpe med at øge sikkerhed, ydeevne og pålidelighed.

Det er en type proxyserver, der henter ressourcer på vegne af en klient fra en eller flere servere. Disse ressourcer returneres derefter til klienten, som om de stammer fra selve proxyserveren. I modsætning til en videresendelsesproxy, som er en formidler for dens tilknyttede klienter til at kontakte enhver server, er en omvendt proxy en formidler for dens tilknyttede servere til at blive kontaktet af enhver klient.

I Salesforce-implementeringer leveres en sådan tjeneste typisk via et eksternt gatewayprodukt. F.eks. kan åbne kildeindstillinger som Apache HTTP, lighttpd og nginx bruges. Kommercielle produkter omfatter IBM WebSeal og Computer Associates SiteMinder. Disse produkter kan nemt konfigureres til at proxy og administrere alle udgående Salesforce-anmodninger på vegne af den interne anmoder.

Kryptering

Nogle virksomheder kræver, at valgte transaktioner eller datafelter krypteres mellem en kombination af lokale og cloudbaserede applikationer. Hvis din organisation skal overholde yderligere overensstemmelseskrav, kan du implementere alternativer, herunder:

Kommerciel krypteringsgatewaytjenester på stedet, herunder Salesforces egne, CipherCloud, IBM DataPower, Computer Associates. For hver løsning kaldes krypteringssystemet eller gatewayen ved transaktionsgrænsen ved at sende og modtage en krypteret data, eller når der krypteres eller dekrypteres specifikke datafelter, før HTTP(S)-anmodningen udføres.
Cloudbaserede indstillinger, f.eks. Salesforce Shield Platform Encryption. Shield Platform Encryption giver dine data et helt nyt lag af sikkerhed, mens du bevarer vigtig platformsfunktionalitet. De data, du vælger, krypteres som inaktive ved brug af et avanceret nøgleafledningssystem. Du kan beskytte dine data mere sikkert end nogensinde før. Se Salesforce Online-hjælp for at få flere oplysninger.

Specialized WS-* Protocol Support

For at håndtere kravene til sikkerhedsprotokoller (f.eks. WS-*) anbefaler vi disse alternativer.

Sikkerheds-/XML-gateway – indsæt WS-Security-legitimationsoplysninger (MuleSoft, IBM WebSeal eller Datapower, Layer7, TIBCO osv.) i selve transaktionsstreamen. Denne tilgang kræver ingen ændringer af webservices på applikationsniveau eller webservicekald fra Salesforce. Du kan også genbruge denne tilgang på tværs af Salesforce-installationen. Men det kræver yderligere design, konfiguration, test og vedligeholdelse for at administrere den relevante WS-Security-injektion i den eksisterende sikkerhedsgatewaytilgang.
Kryptering på transportniveau – Krypter kommunikationskanalen ved brug af tovejs-SSL- og IP-begrænsninger. Selvom denne tilgang ikke implementerer WS-*-protokollen direkte, sikrer den kommunikationskanalen mellem de lokale applikationer og Salesforce uden at overføre et brugernavn og en adgangskode. Det kræver heller ikke ændringer af Salesforce-genererede klasser. Men nogle ændringer af webtjenester på stedet kan være påkrævede (på enten selve applikationen eller på middleware-/ESB-laget).
Salesforce-tilpasset udvikling – Føj WS-Security-sidehoveder til den udgående SOAP-anmodning via WSDL2Apex-hjælpeprogrammet. Dette genererer en Java-lignende Apex fra den WSDL-fil, der bruges til at kalde den interne tjeneste. Selvom denne tilgang ikke kræver nogen ændringer af back-end-webtjenester eller yderligere komponenter i DMZ, kræver den:
- en øget opbygnings- og testindsats
- en relativt kompleks og manuel proces til manuelt at kode WS-Security-attributterne (herunder XML-seriering i Apex)
- en højere langsigtet vedligeholdelsesindsats

Notat: Den sidste indstilling anbefales ikke på grund af dens kompleksitet og risikoen for, at sådanne integrationer skal gennemgå regelmæssigt baseret på regelmæssige opdateringer til Salesforce.

Andre sikkerhedsovervejelser

Navngivne legitimationsoplysninger: Salesforce har forbedret sin godkendelsesarkitektur ved at introducere en model med navngivne legitimationsoplysninger på to niveauer, der tydeligt adskiller problemer mellem forbindelser og identitet. Brug dette, når du foretager udkald gennem Apex, og undgå at oprette din egen godkendelsesprotokol. Dette sikrer også udvidelighed og større sikkerhed. Eksterne legitimationsoplysninger er grundlaget for denne model. De lagrer de faktiske godkendelsesdetaljer og understøtter et avanceret sæt af protokoller, herunder OAuth 2.0-klientlegitimationsoplysninger, JWT Bearer og AWS Signature V4, mens de også definerer, hvordan kontoer tilknyttes: enten som et enkelt navngivet konto (delt på tværs af alle brugere) eller som Pr. bruger-kontoer (hvor hver bruger godkender med sin egen identitet). Navngivne legitimationsoplysninger fungerer til gengæld som slutpunktslaget – de definerer udkalds-URL'en og refererer til en ekstern legitimationsoplysning for at håndtere godkendelseshåndtrykket, og bevarer slutpunktskonfigurationen rent frakoblet fra legitimationsoplysningsstyring. Hvis du vil aktivere pr. bruger-godkendelsesforløb, tilknytter administratorer tilladelsessæt til den relevante eksterne legitimationsoplysningskonstant, hvilket sikrer, at kun brugere med den rigtige tilladelsessættildeling kan kalde udkald under deres egen identitet. Dette design på to niveauer forenkler ikke kun sikker udkaldskonfiguration, men giver også arkitekter meget større fleksibilitet og styringskontrol over, hvordan integrationer godkendes på tværs af Salesforce-tilsluttede systemer. Hvis du ønsker flere oplysninger, kan du se dokumentationen til navngivne legitimationsoplysninger.
OAuth 2.0: OAuth 2.0 er en branchestandard autorisationsstruktur, der giver en bruger mulighed for at tildele begrænset adgang til deres beskyttede ressourcer til en tredjepartsapplikation uden at dele deres legitimationsoplysninger (f.eks. adgangskoder). I stedet for en direkte adgangskodeudveksling godkender brugeren en adgangstokenanmodning, som applikationen derefter bruger til at få adgang til brugerens data fra en ressourceserver. Denne proces adskiller klientapplikationen fra brugerens identitet og adgangskode og forbedrer sikkerheden ved at angive en midlertidig, omfangsspecifik "nøgle" til at få adgang til ressourcer. Se OAuth 2.0-dokumentationen for at få flere oplysninger. For slutpunkter med streng OAuth 2.1-overensstemmelse er der et tredje niveau af arkitekturen tilgængeligt (Ekstern godkendelsesidentitetsudbyder) til at administrere interaktionen med IDP på en 2.1-kompatibel måde.
Private Connect: Når du integrerer din Salesforce-organisation med applikationer, der hostes på tredjeparts cloudtjenester, er det vigtigt at kunne sende og modtage HTTP-trafik sikkert. Med Private Connect kan du øge sikkerheden på dine Amazon Web Services-integrationer (AWS) ved at opsætte en fuldt administreret netværksforbindelse mellem din Salesforce-organisation og din AWS Virtual Private Cloud (VPC). Distribuer derefter din kryds-cloud-trafik gennem forbindelsen i stedet for over det offentlige internet for at reducere eksponering for udvendige sikkerhedstrusler. Private Connect er tilgængelig i partnerskab med AWS via en funktion ved navn AWS PrivateLink. Private Connect er tosidig: du kan starte både indgående og udgående trafik. Med indgående forbindelser kan du sende trafik til Salesforce ved brug af standard-API'er. Og med udgående forbindelser kan du sende trafik ud af Salesforce via funktioner som Apex, eksterne tjenester og eksterne objekter. Se dokumentationen til Private Connect for at få flere oplysninger.

Salesforce-begivenhedsbussen med platformsbegivenheder, CDC (Change Dataregistrering) og Pub/Sub API gør det muligt for virksomheder at oprette begivenhedsstyrede typografiarkitekturer (EDA'er).

En EDA adskiller begivenhedsmeddelelsesforbrugere (abonnenter) fra begivenhedsmeddelelsesproducenter (udgivere), hvilket giver større skalering og fleksibilitet. Specifikke mønstre er beskrevet i dette dokument som en del af den eksisterende mønsterstruktur, der sammenligner og kontrasterer relaterede alternativer eller indstillinger. Men at få en holistisk forståelse af den begivenhedsstyrede arkitektur, og hvordan mønstre interagerer, kan hjælpe dig med at vælge det rigtige mønster til dine behov.

Khalid Mohammed er en fremhævede arkitektleder i Salesforces professionelle tjenester. Siden han tiltrådte Salesforce i 2015 har han udnyttet sin omfattende ekspertise inden for virksomhedsapplikationer og arkitektur, som han har gennemgået adskillige kundetransformationer, før han blev ansat i Salesforce. Khalid leder bestyrelsen for leveringsarkitektur og er også anerkendt som en leder for Certified Technical Architect.

Gulal Kumar er Software Engineering Architect hos Salesforce med fokus på data- og integrationsarkitektur. Med over 21 års erfaring inden for integration og API'er, moderniseringsprogrammer, sikkerhed og AIML-initiativer giver han en lang række ekspertise. Gulal har været engageret i at fremme forretningstransformationsinitiativer, forbedre sikkerhed og modstandsdygtighed, fremme arkitektonisk ekspertise og føre AIML-initiativer på tværs af forskellige domæner.

Sushant Verma er teknisk arkitekt hos Salesforce, der er specialiseret i løsningens arkitektur og end-to-end-levering af Salesforce-platforme. Med dyb ekspertise inden for platformsstyring, applikationsudvikling, integration og DevOps har han ført adskillige kundetransformationsprogrammer på tværs af brancher. Sushant er forpligtet til at fremme fremragende levering og skalerbare arkitektoniske resultater.