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. Dette indhold er en destillation af mange vellykkede implementeringer af Salesforce-arkitekter og -partnere.

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ønstersammendrag og Vejledning til mønstervalg. Arkitekter og udviklere bør overveje 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. Dette giver ensartethed i de oplysninger, der leveres i hvert mønster, og gør det også nemmere at sammenligne mønstre.

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

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 Lightning Platform, oprettes eller opdateres, så de afspejler opdateringer fra et eksternt system, og når ændringer fra Lightning 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 udnytte 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 Virtualitet.
  • 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.
  • Virtual: 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 integrationens typografi: Proces, Data eller Virtualitet.
  • Synkron: Blokering og anmodninger i realtid er anmodnings-/svarhandlinger. Resultatet returneres straks til opkalderen via denne handling.
  • Asynkron – Ikke-blokerende, kø- 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 funktionalitet opnås med Salesforce-virksomhedsmeddelelsesplatformen ved at bruge 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 gør det muligt for disse slutpunkter at blive vist som servicemæssige.

Med Salesforce-integrationer antages det, at alle sådanne krav opfyldes af middleware-laget eller slutpunktet. Transformation af data kan kodes i Apex, men det anbefales ikke af hensyn til vedligeholdelse og ydeevne.
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 kun eksplicit køfunktionalitet i form af arbejdsflowbaserede udgående meddelelser. 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. computer [Mediator] kan sikre, at den rigtige meddelelse kommer til 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 Salesforce-arbejdsflows eller ved brug af Apex. Vi anbefaler, at alle komplekse orkestreringer implementeres i middleware-laget på grund af Salesforce-timeoutværdier 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.

Med Salesforce-integrationer antages det, at alle sådanne krav opfyldes af middleware-laget eller slutpunktet. Meddelelsesdistribution kan kodes i Apex, men det anbefales ikke af hensyn til vedligeholdelse og ydeevne.
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 nu 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.

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.
  • 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, der derefter eksekverer denne proxy Apex for at udføre fjernkaldet. Lightning kræver tilpasning af Salesforce-applikationen.
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

Download diagram

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 kaldemekanisme, kan du se mønsteret Fjernproceskald – Brand og glem.
Apex Bruges til kald af fjernprocesser i batch. Hvis du ønsker flere oplysninger om denne kaldemekanisme, 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.

  • Gendannelse – Ændringer bekræftes ikke i 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ænseflade, skal vi tage os af idempotency på integrationslaget, især hvis der ikke er nogen garanti for, at Salesforce kun ringer 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 har Salesforce nu også startet med at understøtte Salesforce Private connect via Hyperforce Platform sikkert. 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.
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 har Salesforce nu også startet med at understøtte Salesforce Private connect via Hyperforce Platform sikkert. 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. 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

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 System Beskrivelse
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

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, og Salesforce skal afspejle faktureringskontonummeret i bestillingsaktiveringsprocessen. De har en eksisterende webtjeneste, der tillader oprettelse af en faktureringskonto og returnerer faktureringskontonummeret som et svar.

Dette krav kan opfyldes med følgende tilgang.

  1. Salesforce bruger faktureringskontotjenesten WSDL fra en Apex.
  2. Kør Apex med de kundeoplysninger, der er overført til den eksterne webservice fra en tilpasset Apex eller en ekstern tjeneste.
  3. Den tilpassede controller parser derefter returværdierne fra Apex og lagrer disse oplysninger på salesforce-objektet.

Dette eksempel viser, at:

  • Kundens tilstand spores med et kontonummer, der er lagret på Salesforce-kontoobjektet.
  • Efterfølgende behandling af svarmeddelelsen af opkalderen

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 abonnere på en kanal gennem CometD. Platformsapps, f.eks. Lightning, kan også abonnere på begivenhedsmeddelelser med CometD. Salesforce PubSub Api, der er baseret på gRPC og HTTP/2 kan også bruges her.

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)

Når en platformsbegivenhed er defineret i Salesforce, bliver den tilgængelig for både interne og eksterne forbrugere.
Æ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
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 Integrationsprocedurer heri.
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 Tilpas Den anbefalede løsning for denne type integration er, når fjernprocessen kaldes fra en indsættelses- eller opdateringsbegivenhed. Salesforce leverer en forløbstyrede udgående meddelelsesfunktion, der tillader afsendelse af 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.
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.

Ligesom løsningen for fjernproceskald – anmodnings- og svarmønsterløsning, der angiver brug af en Lightning-komponent sammen med et Apex-udkald. 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 ringer ud til et fjernsystem

Download diagram

I dette scenarie:

  1. Et fjernsystem abonnerer på platformsbegivenheden.
  2. En opdatering eller indsættelse forekommer på et givent sæt registreringer i Salesforce.
  3. Et Salesforce-forløb udløses, når et sæt betingelser opfyldes.
  4. Dette forløb opretter en platformsbegivenhed.
  5. Fjernlytteren modtager begivenhedsmeddelelsen og placerer meddelelsen på en lokal kø.
  6. 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/under-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.
Forløbstyrede udgående meddelelser Bruges kun til den udgående meddelelsesløsning. Oprettelse og opdatering af DML-begivenheder udløser Salesforce-arbejdsflowreglerne, som derefter kan sende en meddelelse til et fjernsystem.
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
  • 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 fjernsystemet 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 meddelelser om tidligere begivenheder, når du bruger CometD-klienter 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.

Idempotence er vigtigt for udgående meddelelser, da det er asynkront, og genforsøg startes, når der ikke modtages nogen positiv bekræftelse. Fjerntjenesten skal derfor kunne håndtere meddelelser fra Salesforce på en idempotent måde.

Udgående meddelelser sender et entydigt id pr. meddelelse, og dette id forbliver det samme for alle forsøg. Fjernsystemet kan spore dubletmeddelelser baseret på dette entydige id. Det entydige registrerings-id for hver registrering, der opdateres, sendes også og kan bruges til at forhindre dubletregistreringsoprettelse.

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 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. Med Salesforce-udgående meddelelser skal bekræftelsen ske inden for 24 timer (dette kan udvides til syv dage). Ellers udløber meddelelsen. 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 meddelelser om tidligere begivenheder, skal du bruge CometD-klienter til at abonnere på en kanal.

Datamængder

Datamængdeovervejelser afhænger af, hvilken løsning du vælger. For begrænsningerne 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, processer og forløb kan abonnere på begivenheder. Du kan modtage begivenhedsadviseringer, uanset hvordan de blev udgivet.
  • Brug CometD til at abonnere på platformsbegivenheder fra en ekstern klient. Implementer din egen CometD-klient, eller brug EMP-forbindelsen, et open-source, fællesskabsunderstøttet værktøj, der implementerer alle detaljerne ved at oprette forbindelse til CometD og lytte på en kanal. Salesforce sender platformsbegivenheder til CometD-klienter i rækkefølge i den rækkefølge, de modtages. Rækkefølgen af begivenhedsadviseringer er baseret på genafspilnings-id'et for begivenheder.

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 System Beskrivelse
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 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. Det inkluderer 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 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 platformsbegivenheder)

Løsningsvariant – platformsbegivenheder: Udgivelsesadfæ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 en ESB, der understøtter CometD-protokollen og kan 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:

  • ESB abonnerer på Salesforce Platform-begivenheden ved brug af CometD-protokollen.
  • 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 SessionId som godkendelsestokenet. 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 ).
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.

For mere information om Data Loader se venligst her.
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.

Download diagram

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

Resultater

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

  • Eksternt system er den overordnede – 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 den overordnede – 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 bruges derefter til at oprette programmer, der skal:

  1. Læs en kontroltabel for at bestemme det sidste kørselstidspunkt for jobbet, og udtræk eventuelle andre kontrolværdier, der er nødvendige.
  2. Brug ovennævnte kontrolværdier som filtre, og forespørg på kildedatasættet.
  3. Anvend foruddefinerede behandlingsregler, herunder validering, berigelse osv.
  4. Brug tilgængelige forbindelses-/transformationsfunktioner i ETL-værktøjet til at oprette destinationsdatasættet.
  5. Skriv datasættet til Salesforce-objekter.
  6. Hvis behandlingen lykkes, skal du opdatere kontrolværdierne i kontroltabellen.
  7. 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 meddelelser om tidligere begivenheder, når du bruger CometD-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 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.
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.

  • Der kræves en Lightning Platform-licens med brugertilladelserne "Kun API" for at tillade godkendt API-adgang til Salesforce API.
  • 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 fjernopkald 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. Det er vigtigt, at de valgte middlewareværktøjer understøtter Salesforce Bulk API.

Det er nyttigt, men ikke vigtigt, at middleware-værktøjerne understøtter funktionen getUpdated(). Denne funktion giver den tætteste implementering af standardændringsdataregistrering på Salesforce-platformen.

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 afstemning X (påkrævet for dataregistrering)

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 grundlæggende 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.
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
  • 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.

I modsætning til Bulk API 1.0 behandler Bulk API 2.0 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.
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)

Når en platformsbegivenhed er defineret i Salesforce, bliver den tilgængelig for både interne og eksterne forbrugere.
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 Tilpas 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.
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 logik for førindsættelse af transaktioner hos 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.
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 logik for førindsættelse af transaktioner hos 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 SOAP 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. CometD-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 kan bruge OAuth 2.0 eller brugernavn og adgangskodegodkendelse. I begge tilfælde skal klienten angive autorisationens HTTP-sidehoved med den relevante værdi (et OAuth-adgangstoken eller et sessions-id kan hentes via et loginopkald til SOAP API).

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 – Der skal oprettes en tilpasset prøvemekanisme, hvis krav til servicekvalitet dikterer 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 alesforce understøtter SSL-protokollen (Secure Sockets Layer v3) og TLS-protokollen (Transport Layer Security). Koder skal have en nøglelængde på mindst 128 bit.

Fjernsystemet skal logge ind ved brug af gyldige legitimationsoplysninger for at få et sessions-id. Hvis fjernsystemet allerede har et gyldigt sessions-id, kan det kalde API uden et eksplicit login. Dette bruges i tilbagekaldsmønstre, der er beskrevet tidligere i dette dokument, hvor en tidligere Salesforce-udgående meddelelse indeholdt et sessions-id og registrerings-id til efterfølgende brug.

Vi anbefaler, at klienter, der kalder SOAP API-cache og genbruger sessions-id'et for at maksimere ydeevnen, i stedet for at få et nyt sessions-id for hvert kald.
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. Det er også muligt at foretage REST-kald med et gyldigt sessions-id, der kan være blevet hentet på andre måder (f.eks. hentet ved kald af SOAP API eller leveret via en udgående meddelelse).

Vi anbefaler, at klienter, der kalder REST API-cachen og genbruger sessions-id'et for at maksimere ydeevnen, i stedet for at få et nyt sessions-id 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
  • SOAP Login – Størrelsen på SOAP-loginanmodningen er begrænset til 10 KB eller mindre. Du kan maksimalt foretage 3.600 kald til login()-funktionen pr. bruger pr. time. Hvis du overskrider denne grænse, returnerer API en fejl.
  • 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 system Beskrivelse
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)

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. Det sikrer også holdbare emner med et genafspilningsvindue på 72 timer. Dette sikrer, 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
  • En JavaScript-baseret implementering af Bayeux-protokollen (i øjeblikket CometD ), der kan bruges af brugergrænsefladen
  • En Lightning
  • Et JavaScript-bibliotek, der er inkluderet som en statisk ressource

Sketch

Følgende diagram illustrerer, hvordan Streaming 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

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. Understøttede browsere er angivet i Streaming 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 Trigger PushTopic, 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å begivenhedsbussen 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 (begrænset) på eksterne data.
  • 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 2.0 adapter eller Odata 4.0 adapter – tilslutter til data, der vises af enhver Odata 2.0 eller 4.0 producent.
  • Krydsorganisationsadapter – opretter forbindelse til data, der er lagret i en anden Salesforce-organisation. Krydsorganisationsadapteren bruger Lightning REST API-standard. I modsætning til Odata opretter krydsorganisationsadapteren direkte forbindelse til en anden organisation uden at skulle bruge en webtjeneste.
  • Tilpasset adapter, der er oprettet via Apex – hvis Odata og krydsorganisationsadaptere ikke er egnede til dine behov, kan du udvikle din egen adapter med Apex Connector Framework.
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

I dette scenarie:

  1. Browseren foretager et AJAX-kald, der igen foretager en handling på den tilsvarende eksterne objektadapter.
  2. Adapteren oversætter handlingen til en Odata og opretter en HTTP GET-anmodning til fjernsystemet via integrations- og servicelager.
  3. Fjernsystemet returnerer et JSON-svar til Salesforce via integrations- og servicelager.
  4. 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 Lightning 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.
Belysningskomponenter 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:

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

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 standardsupporten for 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 Lightning REST API til at få adgang til data, der er lagret i andre Salesforce-organisationer.

Opret forbindelse via Middleware

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

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

Højvolumen overvejelser 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

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 nginix 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 (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: Et navngivet legitimationsoplysning, der er beregnet til at sikre og forenkle godkendte API-udkald til eksterne systemer, angiver URL'en for et udkaldsslutpunkt og dens krævede godkendelsesparametre i en definition. Hvis du vil strømline din Apex og forenkle opsætningen af godkendte udkald, skal du angive en navngivet legitimationsoplysning som udkaldsslutpunktet. Se her for flere oplysninger.

  • OAUTH 2.0: OAuth 2.0 er en branchestandardautorisationsstruktur, der tillader en bruger 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. For mere information se her.

  • 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. For mere information om VPC bedes du heri.

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 20 års erfaring inden for integration og API'er, moderniseringsprogrammer, sikkerhed og AIML-initiativer giver han et væld af 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 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.