Når du implementerer Salesforce, må du vanligvis integrere den med andre programmer. Selv om hvert integrasjonsscenarium er unikt, er det vanlige krav og problemer som utviklere og arkitekter må løse.

Dette dokumentet beskriver strategier (i form av mønstre) for disse vanlige integrasjonsscenariene. Hvert mønster beskriver utformingen og tilnærmingen for et bestemt scenario i stedet for å detaljere en bestemt implementering. I dette dokumentet finner du følgende:

• En rekke mønstre som håndterer viktige "arketype"-integreringsscenarier
• En valgmatrise for å finne ut hvilket mønster som passer best til scenariet ditt
• Integreringstips og gode fremgangsmåter

Formål og omfang

Dette dokumentet er for designere og arkitekter som trenger å integrere Salesforce Platform med andre programmer i virksomheten. Dette innholdet er en destillasjon av mange vellykkede implementeringer av Salesforce-arkitekter og -partnere.

Hvis du vil gjøre deg kjent med integrasjonsfunksjoner og alternativer som er tilgjengelig for omfattende bruk av Salesforce-baserte programmer, kan du lese Mønstersammendrag og Veiledning for mønstervalg. Arkitekter og utviklere bør vurdere disse mønsterdetaljene og gode fremgangsmåter under utformings- og implementeringsfasen av et Salesforce-integrasjonsprosjekt.

Hvis de implementeres riktig, gir disse mønstrene deg mulighet til å komme i produksjon så raskt som mulig og ha det mest stabile, skalerbare og vedlikeholdsfrie settet av programmer som er mulig. Salesforces egne rådgivningsarkitekter bruker disse mønstrene som referansepunkter under arkitektoniske gjennomganger, og vedlikeholder og forbedrer dem aktivt.

Som med alle mønstre dekker dette innholdet de fleste integrasjonsscenarier, men ikke alle. Salesforce tillater for eksempel brukergrensesnittintegrering, men slike integrasjoner er utenfor omfanget av dette dokumentet.

Mønstermal

Hvert integrasjonsmønster følger en konsistent struktur. Dette gir konsistens i informasjonen som gis i hvert mønster, og gjør det også enklere å sammenligne mønstre.

Navn

Mønsteridentifikatoren som også angir typen integrasjon som finnes i mønsteret.

Context

Det generelle integreringsscenarie, som mønsteret håndterer. Kontekst gir informasjon om hva brukere prøver å oppnå og hvordan programmet vil oppføre seg for å oppfylle kravene.

Problem

Scenariet eller problemet (uttrykt som et spørsmål) som mønsteret er utformet for å løse. Når du går gjennom mønstrene, leser du denne delen for å raskt forstå om mønsteret er riktig for integreringsscenariet.

Forces

Begrensningene og omstendighetene som gjør det angitte scenariet vanskelig å løse.

Løsning

Den anbefalte måten å løse integrasjonsscenariet på.

Skiss

Et UML-sekvensdiagram som viser deg hvordan løsningen håndterer scenariet.

Resultater

Forklarer detaljene om hvordan du bruker løsningen på integrasjonsscenariet og hvordan den løser kreftene knyttet til dette scenariet. Denne delen inneholder også nye utfordringer som kan oppstå som et resultat av å bruke mønsteret.

Sidefelt

Andre deler relatert til mønsteret som inneholder viktige tekniske problemer, variasjoner av mønsteret, mønsterspesifikke bekymringer og så videre.

Eksempel

Et ende-til-ende-scenarium som beskriver hvordan utformingsmønsteret brukes i et virkelig Salesforce-scenarium. Eksempelet forklarer integrasjonsmålene og hvordan du implementerer mønsteret for å oppnå disse målene.

Mønsteroppsummering

Følgende tabell viser integrasjonsmønstrene i dette dokumentet.

Liste over mønstre remote-process-invocation--forespørsel-og-svar

Mønstertilnærming

Integrasjonsmønstrene i dette dokumentet er klassifisert i tre kategorier:

• Dataintegrering: Disse mønstrene tar hånd om kravet om å synkronisere data som befinner seg i to eller flere systemer, slik at begge systemene alltid inneholder tidsriktige og meningsfylte data. Dataintegrering er ofte den enkleste typen integrasjon som kan implementeres, men krever riktige informasjonsbehandlingsteknikker for å gjøre løsningen bærekraftig og kostnadseffektiv. Slike teknikker inkluderer ofte aspekter ved overordnet databehandling (MDM), datastyring, overføring, fjerning av duplikater, dataflytutforming og andre.

• Prosessintegrering: Mønstrene i denne kategorien tar for seg behovet for at en forretningsprosess kan bruke to eller flere programmer til å utføre oppgaven sin. Når du implementerer en løsning for denne typen integrasjon, må det utløsende programmet kalle opp på tvers av prosessgrenser til andre programmer. Vanligvis inkluderer disse mønstrene også både orkestrering (der ett program er den sentrale "kontrolleren") og koreografi (der programmer er flerdeltakere og det ikke er noen sentral "kontroller"). Disse integrasjonene krever ofte komplekse krav til utforming, testing og håndtering av unntak. Slike sammensatte programmer er vanligvis mer krevende for de underliggende systemene fordi de ofte støtter transaksjoner som kjører lenge, og muligheten til å rapportere om eller behandle prosessstatus.

• Virtuell integrering: Mønstrene i denne kategorien tar hensyn til at en bruker trenger å vise, søke etter og endre data som er lagret i et eksternt system. Når du implementerer en løsning for denne typen integrasjon, må det utløsende programmet kalle opp andre programmer og samhandle med deres data i sanntid. Denne typen integrasjon fjerner behovet for datareplikering på tvers av systemer, og betyr at brukere alltid samhandler med de nyeste dataene.

Å velge den beste integreringsstrategien for systemet er ikke noe trivielt. Det er mange aspekter å vurdere og mange verktøy som kan brukes, med noen verktøy som er mer passende enn andre for bestemte oppgaver. Hvert mønster tar seg av bestemte kritiske områder, inkludert funksjonaliteten til hvert av systemene, datavolumet, feilhåndtering og transaksjonalitet.

Mønsterutvalg guide

Valgmatrisetabellene viser mønstrene og deres viktige aspekter for å hjelpe deg med å finne ut hvilket mønster som passer best til integrasjonskravene dine. Mønstrene kategoriseres med disse dimensjonene.

Integrere Salesforce med et annet system

Denne tabellen viser mønstrene og deres viktige aspekter for å hjelpe deg med å finne ut hvilket mønster som passer best til behovene dine når integrasjonen er fra Salesforce til et annet system.

Integrere et annet system med Salesforce

Denne tabellen viser mønstrene og deres viktige aspekter for å hjelpe deg med å finne det mønsteret som passer best til behovene dine når integrasjonen er fra et annet system til Salesforce.

Termer og definisjoner for mellomprodukter

Denne tabellen viser noen viktige termer relatert til mellomprodukter og deres definisjoner med hensyn til disse mønstrene.

Context

Du bruker Salesforce til å spore salgsemner, behandle pågående arbeid, opprette salgsmuligheter og fange opp bestillingsdetaljer som konverterer salgsemner til kunder. Men Salesforce-systemet inneholder eller behandler ikke bestillinger. Når bestillingsdetaljene er registrert i Salesforce, opprettes bestillingen i det eksterne systemet, som administrerer bestillingen til fullføring.

Når du implementerer dette mønsteret, kaller Salesforce opp det eksterne systemet for å opprette bestillingen og venter på vellykket fullføring. Hvis det lykkes, svarer det eksterne systemet synkront med bestillingsstatusen og bestillingsnummeret. Som en del av den samme transaksjonen oppdaterer Salesforce bestillingsnummeret og statusen internt. Bestillingsnummeret brukes som fremmednøkkel til etterfølgende oppdateringer av det eksterne systemet.

Problem

Når en hendelse skjer i Salesforce, hvordan starter du en prosess i et eksternt system, overfører den nødvendige informasjonen til den prosessen, mottar et svar fra det eksterne systemet, og deretter bruker du svardataene til å gjøre oppdateringer i Salesforce?

Forces

Ta hensyn til følgende krefter når du bruker løsninger basert på dette mønsteret.

• Krever samtalen til det eksterne systemet at Salesforce venter på et svar før prosessen fortsetter? Er samtalen til det eksterne systemet en synkron forespørselssvar eller en asynkron forespørsel?
• Hvis samtalen til det eksterne systemet er synkron, må Salesforce behandle svaret som en del av den samme transaksjonen som den første samtalen?
• Er meldingsstørrelsen liten eller stor?
• Er integrasjonen basert på forekomsten av en bestemt hendelse, som et knappeklikk i Salesforce-brukergrensesnittet eller DML-baserte hendelser?
• Er det eksterne endepunktet i stand til å svare på forespørselen med lav latens? Hvor mange brukere er sannsynlig å utføre denne transaksjonen i en periodeperiode?

Løsning

Denne tabellen inneholder løsninger på dette integrasjonsproblemet.

Skiss

Dette diagrammet illustrerer en synkron ekstern prosessoppkall ved bruk av Apex.

Salesforce ringer ut til et eksternt system

Last ned diagram

I dette scenariet:

• En handling startes på Lightning (for eksempel et knappeklikk).
• Nettleseren (via en kontroller på klientsiden i tilfelle av en Lightning) utfører en HTTP POST som i sin tur utfører en handling på den tilhørende Apex.
• Kontrolleren kaller opp det faktiske kallet til den eksterne nettjenesten.
• Svaret fra det eksterne systemet returneres til Apex. Kontrolleren behandler svaret, oppdaterer data i Salesforce etter behov og gjengir siden på nytt.

I tilfeller der den etterfølgende tilstanden må spores, returnerer det eksterne systemet en unik identifikator som er lagret i Salesforce-posten.

Resultater

Bruk av løsningene som er relatert til dette mønsteret, tillater hendelsesinitierte eksterne prosessoppkall der Salesforce håndterer behandlingen.

Kallmekanismer

Oppkallmekanismen avhenger av løsningen som er valgt for å implementere dette mønsteret.

Feilhåndtering og gjenoppretting

Det er viktig å inkludere en feilhåndterings- og gjenopprettingsstrategi som en del av den generelle løsningen.

• Feilhåndtering: Når det oppstår en feil (unntak eller feilkoder returneres til anroperen), håndterer anroperen feilhåndtering. For eksempel en feilmelding som vises på sluttbrukerens side eller logges på en tabell som krever ytterligere handling.

• Gjenoppretting: Endringer bekreftes ikke til Salesforce før anroperen mottar et vellykket svar. Bestillingsstatusen oppdateres for eksempel ikke i databasen før et svar som indikerer vellykket utførelse, mottas. Om nødvendig kan anroperen prøve operasjonen på nytt.

Idempotent Design vurderinger

Idempotent-egenskaper sikrer at gjentatte kall er trygge. Hvis idempotency ikke implementeres, kan gjentatte kall av samme melding få forskjellige resultater, som potensielt fører til problemer med dataintegritet. Potensielle problemer inkluderer opprettelse av duplikatposter eller duplikatbehandling av transaksjoner.

Det er viktig å sikre at den eksterne prosedyren som kalles opp, er idempotent. Hvis samtalen utføres av brukergrensesnittet, må vi ta hånd om idempotency på integrasjonslaget spesielt hvis det ikke er noen garanti for at Salesforce ringer bare én gang.

Den mest typiske metoden for å bygge en idempotent-mottaker er å spore duplikater basert på unike meldingsidentifikatorer sendt av forbrukeren. Apex eller REST-kall må tilpasses for å sende en unik meldings-ID.

I tillegg må operasjoner som oppretter poster i det eksterne systemet, sjekke duplikater før de settes inn. Merk av ved å overføre en unik post-ID fra Salesforce. Hvis posten finnes i det eksterne systemet, oppdaterer du posten. I de fleste systemer kalles denne operasjonen en oppdateringsoperasjon.

Sikkerhetshensyn

Alle kall til et eksternt system må opprettholde konfidensialiteten, integriteten og tilgjengeligheten til forespørselen. Følgende sikkerhetshensyn er spesifikke for bruk av Apex SOAP- og HTTP-kall i dette mønsteret.

• Enveis SSL er aktivert som standard, men toveis SSL støttes med både egensignerte og CA-signerte sertifikater for å opprettholde autentisiteten til både klienten og serveren.

• For å effektivisere Apex og forenkle oppsettet av godkjente oppkall angir du en navngitt legitimasjon i oppkallssluttpunktet.

• Vurder å bruke OAUTH 2.0 som godkjenningsmekanisme for integrering med eksterne systemer.

• Vurder om nødvendig å bruke enveis hash-koder eller digitale signaturer ved bruk av Apex Crypto-klassemetoder for å sikre forespørselsintegritet.

• Det eksterne systemet må beskyttes ved å implementere de riktige brannmurmekanismene. Se Sikkerhetsvurderinger.

• Salesforce støtter for øyeblikket ikke WS-Security. Selv om den ikke genererer disse komplekse WS-Security-hodene som standard eller automatisk håndhever dem fra et innkommende WSDL, kan du konstruere og implementere dem manuelt ved å opprette tilpassede Apex for å håndtere SOAP-hodene og sikkerhetstokenene for innkommende forespørsler.

Sidefelt

Ingen.

Tidlighet

Tidlighet er av betydelig betydning i dette mønsteret. Vanligvis:

• Forespørselen kalles vanligvis opp fra brukergrensesnittet, så prosessen må ikke la brukeren vente.
• Salesforce har en konfigurerbar tidsavbrudd på opptil 120 sekunder for samtaler fra Apex.
• Fullføring av den eksterne prosessen utføres i rett tid for å avsluttes innenfor Salesforce-tidsavbruddsgrensen og innenfor brukerforventningene.
• Eksterne samtaler er underlagt Apex synkrone transaksjonsstyringsgrenser, så sørg for å redusere risikoen for instansiering av mer enn 50 transaksjoner som kjører i mer enn fem sekunder hver. I tillegg til å sikre at det eksterne endepunktet fungerer, inkluderer alternativer for å redusere risikoen for tidsavbrudd følgende:
  • Angi tidsavbruddet for det eksterne oppkallet til fem sekunder.
  • Bruke en fortsettelse i Lightning til å håndtere transaksjoner som kjører lenge

Datavolumer

Dette mønsteret brukes primært til små volumer, sanntidsaktiviteter på grunn av de små tidsavbruddsverdiene og den maksimale størrelsen på forespørselen eller svaret for Apex. Ikke bruk dette mønsteret i gruppebehandlingsaktiviteter der datalastingen finnes i meldingen.

Støtte for endepunktsfunksjonalitet og standarder

Funksjonaliteten og standardstøtten for endepunktet avhenger av løsningen du velger.

Statsforvaltning

Når du integrerer systemer, er nøkler viktige for pågående statussporing. Det finnes to alternativer.

• Salesforce lagrer det eksterne systemets primære eller unike erstatningsnøkkel for den eksterne posten.
• Det eksterne systemet lagrer den unike Salesforce-post-IDen eller en annen unik erstatningsnøkkel.

Det er spesifikke vurderinger for håndtering av integrasjonsnøkler avhengig av hvilket system som inneholder den overordnede posten, som vist i tabellen nedenfor.

Komplekse integrasjonsscenarier

I enkelte tilfeller kan løsningen som foreskrives av dette mønsteret, kreve implementering av flere komplekse integrasjonsscenarier. Dette betjenes best ved å bruke mellomprogramvare eller få Salesforce til å kalle opp en sammensatt tjeneste. Disse scenariene inkluderer følgende:

• orkestrering av forretningsprosesser og regler som involverer kompleks flytlogikk
• Aggregering av samtaler og deres resultater på tvers av samtaler til flere systemer
• Transformasjon av både innkommende og utgående meldinger
• Opprettholde transaksjonsintegritet på tvers av samtaler til flere systemer

Governorgrenser

Hvis du vil ha informasjon om Apex-grenser, kan du se Utførelsesstyringer og grenser i Apex Developer Guide.

Middleware-egenskaper

Følgende tabell fremhever de ønskede egenskapene for et mellomproduktsystem som deltar i dette mønsteret.

Eksempel

Et verktøyfirma bruker Salesforce og har et eget system som inneholder faktureringsinformasjon for kunder. Som en del av bestillingsprosessen må nye faktureringskontoer opprettes i faktureringssystemet, og Salesforce må gjenspeile faktureringskontonummeret i bestillingsaktiveringsprosessen. De har en eksisterende nettjeneste som tillater oppretting av en faktureringskonto og returnerer faktureringskontonummeret som et svar.

Dette kravet kan oppfylles med følgende løsning.

1. Salesforce bruker faktureringskontotjenesten WSDL fra en Apex.
2. Utfør Apex med kundeinformasjonen overført til den eksterne nettjenesten fra en tilpasset Apex eller ekstern tjeneste.
3. Den tilpassede kontrolleren analyserer deretter returverdiene fra Apex og lagrer denne informasjonen i Salesforce-objektet.

Dette eksemplet viser at

• Statusen til kunden spores med et kontonummer lagret i Salesforce-kontoobjektet.
• Etterfølgende behandling av svarmeldingen av anroperen

Context

Du bruker Salesforce til å spore salgsemner, behandle pågående arbeid, opprette salgsmuligheter og fange opp bestillingsdetaljer som konverterer salgsemner til kunder. Som en del av bestillingsbehandlingsprosessene må det imidlertid opprettes en faktureringskonto i faktureringssystemet for bestillingen.

Når du implementerer dette mønsteret, kaller Salesforce opp det eksterne systemet for å opprette faktureringskontoen, men venter ikke på at samtalen skal fullføres. Det eksterne systemet kan eventuelt oppdatere Salesforce med den nye faktureringskontoen opprettet i en separat transaksjon.

Problem

Når en hendelse skjer i Salesforce, hvordan starter du en prosess i et eksternt system og overfører den nødvendige informasjonen til den prosessen uten å vente på svar fra det eksterne systemet?

Forces

Ta hensyn til følgende krefter når du bruker løsninger basert på dette mønsteret.

• Krever samtalen til det eksterne systemet at Salesforce venter på et svar før prosessen fortsetter? Er samtalen til det eksterne systemet synkron eller asynkron?
• Hvis samtalen til det eksterne systemet er synkron, må svaret behandles av Salesforce som en del av samme transaksjon som samtalen?
• Er meldingsstørrelsen liten?
• Er integrasjonen basert på forekomsten av en bestemt hendelse, som et knappeklikk i Salesforce-brukergrensesnittet eller DML-baserte hendelser?
• Er garantert levering av meldinger fra Salesforce til det eksterne systemet et krav?
• Er det eksterne systemet i stand til å delta i en kontraktsfør integrasjon der Salesforce spesifiserer kontrakten? I enkelte løsningsvarianter (for eksempel utgående meldinger) angir Salesforce en kontrakt som det eksterne systemendepunktet implementerer.
• Støtter endepunktet eller ESB (Enterprise Service Bus) langspørring?
• Foretrukkes deklarative konfigurasjonsmetoder fremfor tilpasset Apex? I dette tilfellet foretrekkes løsninger som plattformhendelser foran Apex.

Løsning

Følgende tabell inneholder løsninger på dette integrasjonsproblemet.

Skiss

Følgende diagram illustrerer et kall fra Salesforce til et eksternt system der opprettelse eller oppdatering av operasjoner på en post utløser samtalen.

Last ned diagram

I dette scenariet:

1. Et eksternt system abonnerer på plattformhendelsen.
2. En oppdatering eller innsetting skjer i et gitt sett med poster i Salesforce.
3. En Salesforce-flyt utløses når et sett betingelser er oppfylt.
4. Denne flyten oppretter en plattformhendelse.
5. Den eksterne lytter mottar hendelsesmeldingen og plasserer meldingen i en lokal kø.
6. Køprogrammet videresender meldingen til det eksterne programmet for behandling.

Hvis det eksterne systemet må utføre operasjoner mot Salesforce, kan du implementere en valgfri tilbakekalloperasjon.

Resultater

Bruk av løsningene som er relatert til dette mønsteret, gjør følgende mulig:

• Brukergrensesnittinitierte eksterne prosessoppkall der resultatet av transaksjonen kan vises til sluttbrukeren
• DML-hendelsesinitierte eksterne prosessoppkall der resultatet av transaksjonen kan behandles av samtaleprosessen

Kallmekanismer

Oppkallmekanismen avhenger av løsningen som er valgt for å implementere dette mønsteret.

Feilhåndtering og gjenoppretting

En feilhåndterings- og gjenopprettingsstrategi må vurderes som en del av den generelle løsningen. Den beste metoden avhenger av løsningen du velger.

Idempotent Design vurderinger

Plattformhendelser publiseres bare til bussen én gang. Det er ingen nye forsøk på Salesforce-siden. Det er opp til ESB å be om at hendelsene spilles av igjen. I en repetisjon forblir plattformhendelsens repetisjons-ID den samme, og ESB kan prøve duplikatmeldinger basert på repetisjons-IDen.

Idempotency er viktig for utgående meldinger fordi den er asynkron, og nye forsøk startes når ingen positiv bekreftelse mottas. Den eksterne tjenesten må derfor kunne håndtere meldinger fra Salesforce på en idempotent måte.

Utgående meldinger sender en unik ID per melding, og denne IDen forblir den samme for eventuelle nye forsøk. Det eksterne systemet kan spore duplikatmeldinger basert på denne unike IDen. Den unike post-IDen for hver post som oppdateres, sendes også, og kan brukes til å hindre opprettelse av duplikatposter.

De idempotente konstruksjonsvurderingene i mønsteret Fjernprosessoppkall – Forespørsel og Svar gjelder også for dette mønsteret.

Sikkerhetshensyn

Alle kall til et eksternt system må opprettholde konfidensialiteten, integriteten og tilgjengeligheten til forespørselen. Forskjellige sikkerhetsvurderinger gjelder avhengig av hvilken løsning du velger.

Se Sikkerhetsvurderinger.

Sidefelt

Ingen.

Tidlighet

Tidlighet er mindre av en faktor med mønsteret for brann og glemsel. Kontroll overføres tilbake til klienten umiddelbart eller etter positiv bekreftelse av en vellykket overføring til det eksterne systemet. Med Salesforce-utgående meldinger må bekreftelsen skje innen 24 timer (dette kan utvides til sju dager); ellers utløper meldingen. For plattformhendelser sender Salesforce hendelsene til hendelsesbussen og venter ikke på en bekreftelse eller bekreftelse fra abonnenten. Hvis abonnenten ikke henter meldingen, kan abonnenten be om å spille hendelsen på nytt med hendelsessvar-IDen. Meldinger om hendelser med stor trafikk lagres i 72 timer (tre dager). Til å hente tidligere hendelsesmeldinger bruker du CometD-klienter til å abonnere på en kanal.

Datavolumer

Viktige punkter om datavolum er avhengig av hvilken løsning du velger. Du finner grensene for hver løsning i Salesforce-hurtigreferansen for grenser.

Støtte for endepunktsfunksjonalitet og standarder

Funksjonaliteten og standardstøtten for endepunktet avhenger av løsningen du velger.

Statsforvaltning

Når du integrerer systemer, er unike postidentifikatorer viktige for pågående statussporing. Hvis en post for eksempel opprettes i det eksterne systemet, har du to alternativer.

• Salesforce lagrer det eksterne systemets primære eller unike erstatningsnøkkel for den eksterne posten.
• Det eksterne systemet lagrer den unike Salesforce-post-IDen eller en annen unik erstatningsnøkkel.

Følgende tabell viser viktige punkter om delstatsbehandling i dette mønsteret.

Komplekse integrasjonsscenarier

Hver løsning i dette mønsteret har forskjellige vurderinger for komplekse integrasjonsscenarier som transformasjon og prosessorkestrering.

Governorgrenser

På grunn av multitalent-karakteren til Salesforce-plattformen er det grenser for utgående oppkall. Grenser er avhengig av typen utgående samtale og tidspunktet for samtalen.

Hvis du vil vite mer om grenser og tildelinger som gjelder for plattformhendelser, kan du se Platforms Events Developer Guide.

Pålitelige meldinger

Pålitelige meldinger forsøker å løse problemet med å garantere levering av en melding til et eksternt system der de individuelle komponentene ikke er pålitelige. Metoden for å sikre mottak av en melding av det eksterne systemet avhenger av hvilken løsning du velger.

I tilfelle av Salesforce Change Datafangst er endringshendelsestyper tilgjengelig for å håndtere spesielle situasjoner, som å fange opp endringer som ikke fanges opp i Salesforce-programserverne, eller håndtere store endringer.

I noen tilfeller sender Salesforce Gap-hendelser i stedet for endringshendelser for å informere abonnenter om feil, eller hvis det ikke er mulig å generere endringshendelser. En gaphendelse inneholder informasjon om endringen i toppteksten, som endringstype og post-ID. Det inkluderer ikke detaljer om endringen, som postfelt. For å fange opp endringer mer effektivt genereres Overflyt-hendelser for enkelttransaksjoner som overskrider en terskel. Se heri for mer informasjon.

Middleware-egenskaper

Følgende tabell fremhever de ønskede egenskapene for et mellomproduktsystem som deltar i dette mønsteret.

Løsningsvariant – Plattformhendelser: Publiseringsvirkemåte og transaksjoner

Når meldinger om plattformhendelser publiseres umiddelbart, respekterer ikke hendelsespublisering transaksjonsgrensene til publiseringsprosessen. Hendelsesmeldinger kan publiseres før transaksjonen fullføres, eller også hvis en transaksjon mislykkes. Denne virkemåten kan føre til problemer når en abonnent forventer å finne data som publiseringstransaksjonen bekrefter. Dataene er kanskje ikke til stede når abonnenten mottar hendelsesmeldingen. For å løse dette problemet angir du virkemåten for publisering av plattformhendelse til Publiser etter bekreftelse i hendelsesdefinisjonen. Virkemåtene for publisering du kan angi i en plattformhendelsesdefinisjon, er:

• Publiser etter bekreftelse for å få hendelsesmeldingen publisert først etter at en transaksjon har blitt riktig bekreftet. Velg dette alternativet hvis abonnenter baserer seg på data som publiseringstransaksjonen bekrefter. En prosess publiserer for eksempel en hendelsesmelding og oppretter en oppgavepost. En andre prosess som abonnerer på hendelsen, utløses og forventer å finne oppgaveposten. En annen årsak til å velge denne virkemåten er når du ikke vil at hendelsesmeldingen skal publiseres hvis transaksjonen mislykkes.
• Publiser umiddelbart for å få hendelsesmeldingen publisert når publiseringskallet utføres. Velg dette alternativet hvis du vil at hendelsesmeldingen skal publiseres uavhengig av om transaksjonen lykkes. Velg også dette alternativet hvis utgiveren og abonnentene er uavhengige og abonnenter ikke er avhengige av data som publiseringen har forpliktet seg til. Virkemåten for umiddelbar publisering er for eksempel egnet for en hendelse som brukes til loggingsformål. Med dette alternativet kan en abonnent motta hendelsesmeldingen før data bekreftes av publiseringstransaksjonen.

Eksempel

Et telekommunikasjonsselskap ønsker å bruke Salesforce som frontlinje for å opprette kontoer ved bruk av salgsemne-til-salgsmulighet-prosessen. En bestilling opprettes i Salesforce når salgsmuligheten er avsluttet og vunnet, men serverdel-ERP-systemet er dataoverordnet. Bestillingen må lagres i Salesforce-salgsmulighetsposten, og salgsmulighetsstatusen må endres for å angi at bestillingen ble opprettet.

Følgende begrensninger gjelder.

• Bare deklarativ utvikling kan implementeres.
• Du trenger ikke umiddelbart varsel om bestillingsnummeret etter at salgsmuligheten er konvertert til en bestilling.
• Organisasjonen har et ESB som støtter CometD-protokollen og kan abonnere på plattformhendelser.

Dette eksemplet implementeres best med Salesforce-plattformhendelser, men krever at ESB abonnerer på plattformhendelsen.

På Salesforce-siden:

• Opprett en flyt for å starte plattformhendelsen (for eksempel når salgsmulighetsstatusen endres til Avsluttet vunnet).
• Opprett en ny plattformhendelse som publiserer salgsmulighetsdetaljene.

På den eksterne systemsiden:

• ESB abonnerer på Salesforce Platform-hendelsen ved bruk av CometD-protokollen.
• ESB mottar ett eller flere varsler som angir at salgsmuligheten skal konverteres til en bestilling.
• ESB videresender meldingen til serverdel-ERP-systemet slik at bestillingen kan opprettes.
• Når bestillingen er opprettet i ERP-systemet, kaller en separat tråd tilbake til Salesforce med SessionId som godkjenningstoken. Tilbakekallet oppdaterer salgsmuligheten med bestillingsnummeret og statusen. Du kan gjøre dette tilbakekallet ved å bruke dokumenterte mønsterløsninger, som Salesforce Platform-hendelser, Salesforce SOAP API, REST API eller en Apex.

Dette eksemplet viser følgende.

• Implementering av en ekstern prosess kalt opp asynkront
• Garantert slutt-til-slutt-levering
• Etterfølgende tilbakekall til Salesforce for å oppdatere statusen til posten

Context

Du flytter CRM-implementeringen til Salesforce og vil

• Trekk ut og transformer kontoer, kontakter og salgsmuligheter fra det gjeldende CRM-systemet, og last inn dataene i Salesforce (første dataimport).
• Trekk ut, transformer og last inn faktureringsdata for kunder i Salesforce fra et eksternt system ukentlig (pågår).
• Trekk ut informasjon om kundeaktivitet fra Salesforce og importer den til et datalager på stedet på ukentlig basis (fortløpende).

Problem

Hvordan importerer du data til Salesforce og eksporterer data ut av Salesforce, med tanke på at disse importene og eksportene kan påvirke sluttbrukeroperasjoner i åpningstider og involvere store mengder data?

Forces

Det er forskjellige krefter å vurdere når du bruker løsninger basert på dette mønsteret:

• Skal dataene lagres i Salesforce? Hvis ikke, er det andre integreringsalternativer en arkitekt kan og bør vurdere (for eksempel tilpassinger).
• Hvis dataene skal lagres i Salesforce, skal dataene oppdateres som svar på en hendelse i det eksterne systemet?
• Skal dataene oppdateres planlagt?
• Støtter dataene primære forretningsprosesser?
• Er det analysekrav (rapporteringskrav) som påvirkes av tilgjengeligheten av disse dataene i Salesforce?

Løsning

Følgende tabell inneholder ulike løsninger på dette integrasjonsproblemet.

Skiss

Følgende diagram illustrerer sekvensen av hendelser i dette mønsteret der Salesforce er dataoverordnet.

Last ned diagram

Følgende diagram illustrerer den etterfølgende synkroniseringen av hendelser i nær sanntid, der Salesforce er dataoverordnet.

Resultater

Du kan integrere data som er eksternt kildet, med Salesforce i følgende scenarier:

• Eksternt system er dataoverordnet – Salesforce er en forbruker av data fra et enkelt kildesystem eller flere systemer. I dette scenariet er det vanlig å ha et datalager eller en datamart som samler dataene før data importeres til Salesforce.
• Salesforce er dataoverordnet – Salesforce er postsystemet for bestemte enheter, og Salesforce-klientprogrammer for datafangst kan informeres om endringer i Salesforce-data.

I et typisk Salesforce-integreringsscenario gjør implementeringsteamet ett av følgende:

• Implementer datafangst av endringer i kildedatasettet.
• Implementer et sett støttende databasestrukturer, kalt kontrolltabeller, i en mellomliggende database på stedet.

ETL-verktøyet brukes deretter til å opprette programmer som

1. Les en kontrolltabell for å bestemme siste kjøretid for jobben og trekke ut eventuelle andre nødvendige kontrollverdier.
2. Bruk kontrollverdiene ovenfor som filtre, og spør kildedatasettet.
3. Bruk forhåndsdefinerte behandlingsregler, inkludert validering, berikelse og så videre.
4. Bruk tilgjengelige koblinger/transformasjonsfunksjoner i ETL-verktøyet til å opprette måldatasettet.
5. Skriv datasettet til Salesforce-objekter.
6. Hvis behandlingen er vellykket, oppdaterer du kontrollverdiene i kontrolltabellen.
7. Hvis behandlingen mislykkes, oppdaterer du kontrolltabellen med verdier som aktiverer en ny start og avslutning.

Notat: Vi anbefaler at du oppretter kontrolltabellene og tilknyttede datastrukturer i et miljø som ETL-verktøyet har tilgang til, selv om tilgang til Salesforce ikke er tilgjengelig. Dette gir tilstrekkelige nivåer av fleksibilitet. Salesforce bør behandles som en bane i denne prosessen, og ETL-infrastrukturen er knutepunktet.

Vurder følgende for å få et ETL-verktøy til å få størst mulig nytte av datasynkroniseringsfunksjonalitet:

• Kjed og sekvenser ETL-jobbene for å gi en sammenhengende prosess.
• Bruk primærnøkler fra begge systemene til å samsvare med innkommende data.
• Bruk spesifikke API-metoder til å trekke ut bare oppdaterte data.
• Hvis du importerer underordnede poster i en overordnet-detalj- eller oppslagsrelasjon, grupperer du de importerte dataene med sin overordnede nøkkel ved kilden for å unngå låsing. Hvis du for eksempel importerer kontaktdata, må du passe på å gruppere kontaktdataene etter den overordnede kontonøkkelen slik at maksimalt antall kontakter for en enkelt konto kan lastes inn i ett API-kall. Mislykket gruppering av de importerte dataene fører vanligvis til at den første kontaktposten lastes inn og påfølgende kontaktposter for denne kontoen mislykkes i konteksten av API-kallet.
• Eventuell postimportbehandling, som utløsere, skal bare behandle data selektivt.
• Hvis scenariet involverer store datavolumer, følger du anbefalte fremgangsmåter fra Trailhead-modulen Beste fremgangsmåter for distribusjoner med store datavolumer
.

Feilhåndtering og gjenoppretting

En feilhåndterings- og gjenopprettingsstrategi må vurderes som en del av den generelle løsningen. Den beste metoden avhenger av løsningen du velger.

Sikkerhetshensyn

Alle kall til et eksternt system må opprettholde konfidensialiteten, integriteten og tilgjengeligheten til forespørselen. Forskjellige sikkerhetsvurderinger gjelder avhengig av hvilken løsning du velger.

• En Lightning Platform-lisens med minst Bare API-brukertillatelser kreves for å tillate godkjent API-tilgang til Salesforce API.
• Vi anbefaler at standardkryptering brukes til å holde passordtilgang sikker.
• Bruk HTTPS-protokollen når du starter kall til Salesforce API-ene. Du kan også sende proxy-trafikk til Salesforce-API-ene via en sikkerhetsløsning på stedet, om nødvendig.

Se Sikkerhetsvurderinger.

Sidefelt

Ingen.

Tidlighet

Tidlighet er ikke av stor betydning i dette mønsteret. Det må imidlertid være forsiktig med å utforme grensesnittene slik at alle gruppeprosessene fullføres i et utpekt gruppevindu.

Som med alle batchorienterte operasjoner anbefaler vi sterkt at du tar hensyn til å isolere kildesystemer og målsystemer under batchbehandlingsvinduer. Innlasting av batcher i åpningstider kan føre til en del tvist, noe som fører til at en brukers oppdatering mislykkes, eller mer viktig, at en batchinnlasting (eller delvis batchinnlasting) mislykkes.

For organisasjoner som har globale operasjoner, er det kanskje ikke mulig å kjøre alle gruppeprosesser samtidig fordi systemet kan være i bruk kontinuerlig. Datasegmenteringsteknikker som bruker posttyper og andre filtreringskriterier, kan brukes til å unngå datakonflikter i disse tilfellene.

Statsforvaltning

Du kan implementere delstatsbehandling ved å bruke erstatningsnøkler mellom de to systemene. Hvis du trenger en hvilken som helst type transaksjonsbehandling på tvers av Salesforce-enheter, anbefaler vi at du bruker mønsteret Fjerninnkall med Apex.

Standard optimistisk postlåsing skjer på plattformen, og eventuelle oppdateringer som gjøres med API-et, krever at brukeren som redigerer posten, oppdaterer posten og starter transaksjonen. I Salesforce API refererer optimistisk låsing til en prosess der

• Salesforce vedlikeholder ikke statusen til en post som redigeres av en bestemt bruker.
• Ved avlesing registreres tidspunktet da dataene ble trukket ut.
• Hvis brukeren oppdaterer posten og lagrer den, sjekker Salesforce om en annen bruker har oppdatert posten i mellomtiden.
• Hvis posten har blitt oppdatert, varsler systemet brukeren om at en oppdatering har blitt gjort, og brukeren må hente den nyeste versjonen av posten før brukeren fortsetter med oppdateringene.

Middleware-egenskaper

De mest effektive eksterne teknologiene som brukes til å implementere dette mønsteret, er tradisjonelle ETL-verktøy. Det er viktig at de valgte mellomprogramverktøyene støtter Salesforce Bulk API.

Det er nyttig, men ikke viktig, at middleware-verktøyene støtter getUpdated()-funksjonen. Denne funksjonen er den nærmeste implementeringen av standard datafangst av endringer på Salesforce-plattformen.

Følgende tabell fremhever de ønskede egenskapene for et mellomproduktsystem som deltar i dette mønsteret.

Eksempel

Et verktøyfirma bruker en hoveddatamaskinbasert gruppeprosess som tildeler prospekter til individuelle selgere og team. Denne informasjonen må importeres til Salesforce hver natt.

Kunden har besluttet å implementere datafangst i kildetabellene ved bruk av et kommersielt tilgjengelig ETL-verktøy. Løsningen fungerer som følger:

• En cron-lignende planlegger utfører en gruppejobb som tildeler prospekter til brukere og team.
• Når gruppejobben har kjørt og oppdatert dataene, gjenkjenner ETL-verktøyet disse endringene ved bruk av datafangst. ETL-verktøyet samler endringene fra datalageret.
• ETL-koblingen bruker Salesforce REST API til å laste endringene inn i Salesforce.

Context

Du bruker Salesforce til å spore salgsemner, behandle pågående arbeid, opprette salgsmuligheter og fange opp bestillingsdetaljer som konverterer salgsemner til kunder. Salesforce-systemet oppretter bestillingene internt og sender deretter disse dataene til det eksterne faktureringssystemet for klargjøring og aktivering. Faktureringsbestillinger behandles av et eksternt (fjerndistribuert) system. Dette eksterne systemet må oppdatere bestillingsstatusen i Salesforce når bestillingen eller faktureringsenheten i faktureringssystemstatusen endres.

Problem

Hvordan kobler et eksternt system til og godkjenner Salesforce for å varsle Salesforce om eksterne hendelser, opprette poster og oppdatere eksisterende poster?

Forces

Det er forskjellige krefter å vurdere når du bruker løsninger basert på dette mønsteret:

• Er formålet med det eksterne kallet til Salesforce å varsle Salesforce om en hendelse som skjedde eksternt ved bruk av en hendelsesdrevet arkitektur? Eller er formålet å utføre CRUD-operasjoner på bestemte poster? Hvis du bruker en hendelsesdrevet arkitektur, kobles hendelsesprodusenten (den eksterne prosessen) fra Salesforce-hendelsesforbrukeren.
• Krever samtalen til Salesforce at den eksterne prosessen venter på et svar før prosessen fortsetter? Eksterne samtaler til Salesforce er alltid synkrone forespørselssvar, selv om den eksterne prosessen kan forkaste svaret hvis det ikke er nødvendig for å simulere en asynkron samtale.
• Opererer hver transaksjon mot ett enkelt Salesforce-objekt eller flere relaterte objekter?
• Hva er formatet på meldingen (for eksempel SOAP eller REST eller begge deler over HTTP)?
• Er meldingsstørrelsen relativt liten eller stor?
• Hvis det eksterne systemet er SOAP-kompatibelt, kan det eksterne systemet delta i en kontraktsfør tilnærming der Salesforce dikterer kontrakten? Dette kreves der SOAP API brukes, som det leveres et forhåndsdefinert WSDL for.
• Er transaksjonsbehandling nødvendig?
• Hvor tolerant er du for tilpassing i Salesforce?

Løsning

Denne tabellen inneholder ulike løsninger på dette integrasjonsproblemet.

Skiss

Følgende diagrammer illustrerer sekvensen av hendelser når du implementerer dette mønsteret ved å bruke enten REST API for varsler fra eksterne hendelser eller SOAP API til å spørre et Salesforce-objekt. Sekvensen av hendelser er den samme når REST API brukes.

Fjernsystemspørring for Salesforce via SOAP API

Fjernsystem varsler Salesforce med hendelser via REST API

Resultater

I en hendelsesdrevet arkitektur kaller det eksterne systemet opp til Salesforce med SOAP API, REST API eller Bulk API 2.0 for å publisere en hendelse til Salesforce-hendelsesbussen. Publisering av en hendelse varsler alle abonnenter. Hendelsesabonnenter kan være i Salesforce Platforms Apex som Flyter eller Lightning. Hendelsesabonnenter kan også være eksterne for Salesforce Platform, som CometD-abonnenter.

Når du arbeider direkte med Salesforce-objekter, kan løsningene som er relatert til dette mønsteret, gjøre følgende:

• Det eksterne systemet kaller opp Salesforce-API-ene for å spørre databasen og utføre operasjoner med ett objekt (opprette, oppdatere, slette og så videre).
• Det eksterne systemet for å kalle opp Salesforce REST API-sammensatte ressurser for å utføre en serie av objektoperasjoner.
• Eksternt system for å kalle opp tilpassede Salesforce-API-er (tjenester) som kan støtte transaksjonsoperasjoner med flere objekter og tilpasset logikk for pre/post-behandling.

Kallmekanismer

Oppkallmekanismen avhenger av løsningen som er valgt for å implementere dette mønsteret.

Feilhåndtering og gjenoppretting

En feilhåndterings- og gjenopprettingsstrategi må vurderes som en del av den generelle løsningen.

• Feilhåndtering – Alle eksterne oppkallmetoder, standard eller tilpassede API-er, krever at det eksterne systemet håndterer eventuelle etterfølgende feil, som tidsavbrudd og behandling av nye forsøk. Mellomprogramvare kan brukes til å gi logikk for feilhåndtering og gjenoppretting.
• Gjenoppretting: Det må opprettes en tilpasset mekanisme for å prøve på nytt hvis krav til tjenestenes kvalitet krever det. I dette tilfellet er det viktig å sikre idempotente designegenskaper. Plattformhendelse gir abonnenter mulighet til å bruke avspillings-IDen til å hente meldinger innen en bestemt tidsperiode etter at disse meldingene har blitt publisert.

Idempotent Design vurderinger

Idempotent-egenskaper garanterer at gjentatte kall er trygge og ikke vil ha noen negativ effekt. Hvis idempotens ikke implementeres, kan gjentatte kall av samme melding få forskjellige resultater, som potensielt fører til problemer med dataintegritet, for eksempel opprettelse av duplikatposter, duplikatbehandling av transaksjoner og så videre.

Det eksterne systemet må håndtere flere (duplikat) samtaler i tilfelle feil eller tidsavbrudd for å unngå duplikatinnsetting og overflødige oppdateringer (spesielt hvis nedstrømsutløsere og arbeidsflytregler utløses). Selv om det er mulig å håndtere noen av disse situasjonene i Salesforce (spesielt i tilfelle tilpassede SOAP- og REST-tjenester), anbefaler vi at det eksterne systemet (eller mellomprogramvaren) håndterer feilhåndtering og idempotent-utforming.

Sikkerhetshensyn

Forskjellige sikkerhetsvurderinger gjelder avhengig av hvilken mønsterløsning som velges. I alle tilfeller bruker plattformen den påloggede brukerens tilgangsrettigheter (for eksempel profilinnstillinger, delingsregler, tillatelsessett og så videre). I tillegg kan profil-IP-restriksjoner brukes til å begrense tilgang til APIen for et bestemt IP-adresseområde.

Se Sikkerhetsvurderinger.

Sidefelt

Ingen.

Tidlighet

SOAP API og Apex web service API er synkrone. Følgende tidsavbrudd gjelder:

• Økttidsavbrudd – Økten tidsavbrytes hvis det ikke er noen aktivitet basert på Salesforce-organisasjonens innstilling for tidsavbrudd av økt.
• Spørringstidsavbrudd – Hver SOQL-spørring har en individuell tidsavbruddsgrense på 120 sekunder.

Datavolumer

Viktige punkter om datavolum er avhengig av hvilken løsning og hvilken kommunikasjonstype du velger.

Støtte for endepunktsfunksjonalitet og standarder

Funksjonaliteten og standardstøtten for endepunktet avhenger av løsningen du velger.

Statsforvaltning

Når du integrerer systemer, er nøkler viktige for pågående statussporing, for eksempel hvis en post opprettes i det eksterne systemet, for å støtte pågående oppdateringer av denne posten. Det finnes to alternativer:

• Salesforce lagrer det eksterne systemets primære eller unike erstatningsnøkkel for den eksterne posten.
• Det eksterne systemet lagrer den unike Salesforce-post-IDen eller en annen unik erstatningsnøkkel. Det er spesifikke vurderinger for håndtering av integrasjonsnøkler i dette synkrone mønsteret.

Komplekse integrasjonsscenarier

Hver løsning i dette mønsteret har forskjellige vurderinger når det gjelder å håndtere komplekse integrasjonsscenarier som transformasjon og prosessorkestrering.

Governorgrenser

På grunn av multitenant-karakteren til Salesforce-plattformen er det grenser når API-ene brukes.

Pålitelige meldinger

Pålitelige meldingsforsøk for å løse problemet med å garantere levering av en melding til et eksternt system der de individuelle komponentene i seg selv kan være upålitelige. Salesforce SOAP API og REST API er synkrone og gir ikke eksplisitt støtte for noen pålitelige meldingsprotokoller, per se (for eksempel WS-ReliableMessaging).

Vi anbefaler at det eksterne systemet implementerer et pålitelig meldingssystem for å sikre at feil- og tidsavbruddsscenarier håndteres riktig. Publisering av plattformhendelser fra eksterne systemer er avhengig av Salesforce-API-er, så de samme punktene gjelder for SOAP API og REST API.

Middleware-egenskaper

Denne tabellen fremhever de ønskede egenskapene for et mellomproduktsystem som deltar i dette mønsteret:

Eksempel

Et firma for utskriftsutstyr og -tjenester bruker Salesforce som frontlinje til å opprette og behandle skriverutstyr og -bestillinger. Salesforce-aktivumposter som representerer skrivere, oppdateres regelmessig med utskriftsbruksstatistikk (blekkstatus, papirnivå) fra det lokale skriverbehandlingssystemet (PMS), som regelmessig overvåker skrivere på klientnettsteder. Når du når en angitt terskelverdi (for eksempel lav blekkstatus eller lav/tom papirnivå på mindre enn 30 %), varsles flere apper/prosesser (variabel) som er interessert i hendelsen, sendes e-post- eller Chatter, og en Bestilling-post opprettes. PMS lagrer Salesforce-IDen (Salesforce er den overordnede aktivumposten).

Følgende begrensninger gjelder:

• PMS kan delta i en kontraktsfør integrasjon der Salesforce leverer kontrakten og PMS fungerer som en klient (forbruker) av Salesforce-tjenesten (definert via Enterprise- eller Partner WSDL).
• Det bør ikke være noen tilpasset utvikling i Salesforce.

Dette eksemplet implementeres best ved å bruke Salesforce SOAP API eller REST API til å publisere hendelser og deklarativ automatisering (Flyt) i Salesforce. Den primære årsaken til å bruke plattformhendelser er det variable og ikke-endelige antall abonnenter. Men for enkle oppdateringer til en endelig liste med poster som bestillinger, bruker du SOAP eller REST API til å oppdatere postene.

I Salesforce:

• Definer en plattformhendelse i Salesforce til å inneholde varslingsdataene som kommer fra PMS.
• Opprett en flyt som utløses av varselet om skriverhendelsen. Prosessen oppdaterer skriveraktivumet og oppretter en bestilling (ved å bruke en automatisk startet flyt).
• Last ned Enterprise- eller Partner WSDL-et og gi det til det eksterne systemet.

I det eksterne systemet:

• Opprett en klientstub fra Enterprise- eller Partner WSDL.
• Godkend dig til Salesforce (via OAuth-webserver eller bærertokenforløb) ved brug af integrationsbrugerens legitimationsoplysninger.
• Ved skriverstatushendelse kaller PMS opp API-et for å opprette plattformhendelsen for skriverstatus (med statistikk over skriverbruk). Salesforce-hendelsesbussen varsler flytabonnenten og alle andre abonnenter.

Når du bruker plattformhendelser, lar hendelsesbussen deg spille av hendelser på nytt i 72 timer for plattformhendelser med stor trafikk. Publisering av disse hendelsene med en mellomprogramvareløsning kan bidra til å innlemme feilhåndtering på publiseringssiden. Du kan imidlertid implementere feilhåndtering på abonnentsiden hvis du trenger høyere pålitelighet.

Dette eksemplet viser følgende:

• Implementering av en Salesforce synkron API-klient (forbruker).
• Et tilbakekall til Salesforce for å publisere en plattformhendelse (justert med mønstre for tidligere dekkede forespørsels-/svarplattformhendelser).

Context

Du bruker Salesforce til å behandle kundesaker. En kundeservicerepresentant er på telefonen med en kunde som arbeider med en sak. Kunden foretar en betaling, og kundeservicerepresentanten må se en sanntidsoppdatering i Salesforce-appen fra betalingsbehandlingsappen, som angir at kunden har betalt bestillingens utestående beløp.

Problem

Hvordan kan brukeren varsles i Salesforce-brukergrensesnittet uten å måtte oppdatere skjermen og potensielt miste arbeid når en hendelse skjer i Salesforce?

Forces

Det er forskjellige krefter å vurdere når du bruker løsninger basert på dette mønsteret:

• Trenger dataene som handles på, å lagres i Salesforce?
• Kan et tilpasset brukergrensesnittlag bygges for å vise disse dataene?
• Vil brukeren ha tilgang til å kalle opp det tilpassede brukergrensesnittet?

Løsning

Den anbefalte løsningen på dette integrasjonsproblemet er å bruke plattformhendelser som sikrer nær sanntidshendelser i Salesforce. Plattformhendelser gir en strukturert, fleksibel belastning uavhengig av hvilket som helst Salesforce-objekt. Den sikrer også holdbare emner med et gjentagelsesvindu på 72 timer. Dette sikrer at hendelser er tilgjengelig selv om en offline forbruker blir tilgjengelig senere. Denne løsningen består av følgende komponenter:

• Apex eller flyter med en logikk for å publisere en plattformhendelse for et emne
• Et emne som du kan bruke til å publisere en hendelse fra Apex eller flyt
• En JavaScript-basert implementering av Bayeux protokollen (for tiden CometD) som kan brukes av brukergrensesnittet
• En Lightning
• Et JavaScript-bibliotek inkludert som en statisk ressurs

Skiss

Følgende diagram illustrerer hvordan Streaming API kan implementeres for å strømme varsler til Salesforce-brukergrensesnittet. Disse varslene utløses av postendringer i Salesforce.

Grensesnittoppdatering i Salesforce utløst av en dataendring

Resultater

Fordeler

Bruk av løsningen relatert til dette mønsteret har følgende fordeler:

• Eliminerer behovet for å skrive tilpassede avspørringsmekanismer
• Eliminerer behovet for en brukerinitiert tilbakemeldingsløyfe

Krav som ikke støttes

Løsningen har følgende begrensninger:

• Levering av varsler er ikke garantert.
• Rekkefølge av varsler garanteres ikke.
• Varsler genereres ikke fra postendringer gjort av Bulk API.

Sikkerhetshensyn

Standard Salesforce-sikkerhet på organisasjonsnivå overholdes. Det anbefales at du bruker HTTPS-protokollen til å koble til Streaming API. Se Sikkerhetsvurderinger

Sidefelt

Den optimale løsningen innebærer å opprette et tilpasset brukergrensesnitt i Salesforce. Det er viktig at du tar hensyn til en egnet brukergrensesnittbeholder som kan brukes til gjengivelse av det tilpassede brukergrensesnittet. Støttede nettlesere er oppført i Streaming API Developer Guide

Eksempel

Et telekommunikasjonsselskap bruker Salesforce til å behandle kundesaker. Kundeserviceledere ønsker å bli varslet når en sak er vellykket avsluttet av en av kundeservicerepresentantene.

Ved implementering av løsningen som er foreskrevet av dette mønsteret, skal kunden

• Opprett et Apex som sender en plattformhendelse når en sak lagres med statusen Avsluttet og Løsning vellykket.
• Opprett et tilpasset brukergrensesnitt som er tilgjengelig for kundeserviceledere. Dette brukergrensesnittet abonnerer på hendelsesbussen for å forbruke plattformhendelser.
• Implementer logikk i det tilpassede brukergrensesnittet som viser varsler generert av den lederens kundeservicerepresentanter.

Context

Du bruker Salesforce til å spore salgsemner, behandle pågående arbeid, opprette salgsmuligheter og fange opp bestillingsdetaljer som konverterer salgsemner til kunder. Salesforce er imidlertid ikke systemet som inneholder eller behandler bestillinger. Bestillinger behandles av et eksternt (fjerndistribuert) system. Men selgere ønsker å vise og oppdatere sanntids bestillingsinformasjon i Salesforce uten å måtte lære eller bruke det eksterne systemet.

Problem

Hvordan kan du i Salesforce vise, søke etter og endre data som er lagret utenfor Salesforce, uten å flytte dataene fra det eksterne systemet til Salesforce?

Forces

Det er forskjellige krefter å vurdere når du bruker løsninger basert på dette mønsteret:

• Vil du bygge en deklarativ/poeng-og-klikk-utgående integrasjon eller grensesnittmatchup i Salesforce?
• Har du en stor mengde data som du ikke vil kopiere til Salesforce-organisasjonen?
• Trenger du tilgang til små mengder eksterne systemdata samtidig?
• Trenger du sanntidstilgang til de nyeste dataene?
• Lagrer du dataene i skyen eller i et back-office-system, men vil vise eller behandle disse dataene i Salesforce-organisasjonen?
• Har du problemer med dataoppbevaring når det gjelder lagring av bestemte typer data i Salesforce?

Løsning

Følgende tabell inneholder ulike løsninger på dette integrasjonsproblemet.

Skiss

Følgende diagram illustrerer hvordan du kan bruke Salesforce Connect til å trekke ut data fra et eksternt system ved bruk av en Odata.

I dette scenariet:

1. Nettleseren utfører et AJAX-kall som i sin tur utfører en handling på den tilhørende adapteren for det eksterne objektet.
2. Adapteren oversetter handlingen til en Odata og sender en HTTP GET-forespørsel til det eksterne systemet via Integrasjon- og Tjenester-lagene.
3. Det eksterne systemet returnerer et JSON-svar til Salesforce via Integrasjon- og Tjenester-lagene.
4. Svaret oversettes fra OData til et eksternt objekt og presenteres tilbake til nettleseren.

Resultater

Bruk av løsningene som er relatert til dette mønsteret, tillater brukergrensesnittinitierte kall der resultatet av transaksjonen kan vises til sluttbrukeren.

Kallmekanismer

Oppkallmekanismen avhenger av løsningen som er valgt for å implementere dette mønsteret.

Feilhåndtering

Det er viktig å inkludere feilhåndtering som en del av den generelle løsningen. Når det oppstår en feil (unntak eller feilkoder returneres til anroperen), administrerer anroperen feilhåndteringen. Salesforce Connect Validator er et gratis verktøy for å kjøre noen vanlige spørringer og varseltyper og feilårsaker.

Fordeler

Noen av fordelene med å bruke en Salesforce Connect er:

• Denne løsningen bruker ikke lagringsplass i Salesforce.
• Brukere trenger ikke å bekymre seg om regelmessig synkronisering av data mellom det eksterne systemet og Salesforce.
• En deklarativ oppsett som kan oppnås raskt med OData, eller en adapter for flere organisasjoner, eller ved å bruke minimal kode med en tilpasset Apex adapter.
• Brukere kan få tilgang til eksterne data med mye av samme funksjonalitet som tilpassede objekter i form av eksterne objekter.
• Mulighet til å utføre et samlet søk i det tilkoblede eksterne systemet ved bruk av globalt søk.
• Mulighet til å kjøre rapporter som har tilgang til eksterne data fra skyen og kilder på stedet. Se viktige punkter om rapportering nedenfor.

Viktige punkter om Salesforce Connect

Salesforce Connect har følgende vurderinger:

• Eksterne objekter fungerer som tilpassede objekter, men noen funksjoner er ikke tilgjengelig for eksterne objekter. Hvis du vil ha mer informasjon, kan du se Viktige punkter om Salesforce-kompatibilitet for Salesforce Connect.
• Eksterne objekter kan påvirke rapportytelsen. Hvis du vil ha mer informasjon, kan du se Rapportvurderinger for Salesforce Connect.
• Se Vurderinger for Salesforce Connect – Alle adaptere for å få mer informasjon om bruk av Salesforce Connect-adaptere.
• Hvis du vurderer å bruke en adapter for flere organisasjoner, kan du se Viktige punkter om Salesforce Connect – adapter for flere organisasjoner.
• Hvis du vurderer å bruke en OData-adapter, kan du se Vurderinger for Salesforce Connect – OData 2.0- og 4.0-adaptere.
• Hvis du vurderer å bruke en tilpasset Apex-adapter, kan du se Viktige punkter om Salesforce Connect – tilpasset adapter.

Sikkerhetshensyn

Løsninger for dette mønsteret må overholde standard Salesforce-sikkerhet på organisasjonsnivå. Det anbefales at du bruker HTTPS-protokollen til å koble til et eksternt system. Se Sikkerhetsvurderinger for å få mer informasjon

Hvis du bruker en Odata, må du forsikre deg om at du forstår de spesielle virkemåtene, begrensningene og anbefalingene for CSRF (CSRF) på Odata eksterne datakilder. Hvis du vil ha mer informasjon, kan du se CSRF-vurderinger for Salesforce Connect – OData 2.0- og 4.0-adaptere.

Sidefelt

Ingen.

Tidlighet

Tidlighet er av betydelig betydning i dette mønsteret. Vær oppmerksom på følgende punkter:

• Forespørselen kalles vanligvis opp fra brukergrensesnittet, så prosessen må ikke la brukeren vente.
• Avhengig av tilgjengeligheten av og tilkoblingen til det eksterne systemet kan det ta lang tid å hente eksterne data. Salesforce har en konfigurerbar maksimal tidsavbruddsverdi på 120 sekunder for å vente på svar fra det eksterne systemet.
• Fullføring av den eksterne prosessen skal utføres i rett tid og fullføres innenfor Salesforce-tidsavbruddsgrensen og innenfor brukerforventningene.

Datavolumer

Dette mønsteret brukes primært til små volumer, sanntidsaktiviteter på grunn av de små tidsavbruddsverdiene og den maksimale størrelsen på forespørselen eller svaret for Apex. Ikke bruk dette mønsteret i gruppebehandlingsaktiviteter der datalastingen finnes i meldingen.

Støtte for endepunktsfunksjonalitet og standarder

Støtten for funksjonalitet og standarder for endepunktet avhenger av løsningen du velger.

Statsforvaltning

Når du integrerer systemer, er nøkler viktige for pågående statussporing. Hvis en post for eksempel opprettes i det eksterne systemet, trenger posten vanligvis en slags identifiseringsnøkkel for å støtte pågående oppdateringer. Det finnes to alternativer for lagring av nøkler.

• Salesforce lagrer den primære eller unike erstatningsnøkkelen for den eksterne posten.
• Det eksterne systemet lagrer den unike Salesforce-post-IDen eller en annen unik erstatningsnøkkel. Det er spesifikke vurderinger for håndtering av integrasjonsnøkler i dette synkrone mønsteret.

Komplekse integrasjoner

I enkelte tilfeller kan løsningen som foreskrives av dette mønsteret, kreve implementering av et komplekst integrasjonsscenarium. Disse scenariene løses ofte med mellomprogramvare.

• Aggregering av samtaler og deres resultater på tvers av samtaler til flere systemer
• Transformasjon av både innkommende og utgående meldinger
• Opprettholde transaksjonsintegritet på tvers av samtaler til flere systemer
• Andre prosessorkestreringsaktiviteter mellom Salesforce og det eksterne systemet

Regulerende grenser

Forskjellige grenser gjelder for forskjellige adaptere. Du finner flere detaljer i Generelle grenser for Salesforce Connect.

Middleware-egenskaper

Følgende tabell fremhever de ønskede egenskapene for et mellomproduktsystem som deltar i dette mønsteret.

Eksternt objekt-relasjoner

Eksterne objekter støtter standard oppslagsrelasjoner, som bruker den 18-tegns Salesforce-post-IDen til å knytte til relaterte poster. Data som er lagret utenfor Salesforce-organisasjonen, inneholder imidlertid ofte ikke disse post-ID-ene. Derfor er to spesielle typer oppslagsrelasjoner tilgjengelig for eksterne objekter: eksterne oppslag og indirekte oppslag.

Denne tabellen oppsummerer relasjonstypene som er tilgjengelig for eksterne objekter.

Viktige punkter om høyt datavolum for Salesforce Connect – OData 2.0- og 4.0-adaptere

Hvis organisasjonen når grenser for tilgang til eksterne objekter, kan du vurdere å velge alternativet Høy datatrafikk i de tilknyttede eksterne datakildene. Det omgår de fleste grenser, men noen spesielle virkemåter og begrensninger gjelder. Hvis du vil ha mer informasjon, kan du se Viktige punkter om høy datatrafikk for Salesforce Connect

Kundedrevet og serverdrevet paginering for Salesforce Connect – OData 2.0- og 4.0-adaptere

Det er vanlig at Salesforce Connect med eksterne data har et stort resultatsett som er delt inn i mindre batcher eller sider. Du bestemmer om virkemåten til pagineringen skal kontrolleres av det eksterne systemet (serverdrevet) eller av OData 2.0- eller 4.0-adapteren for Salesforce Connect (klientdrevet). Feltet Serverdrevet paginering i den eksterne datakilden angir om det skal brukes klientdrevet eller serverdrevet paginering. Hvis du aktiverer serverdrevet paginering på en ekstern datakilde, ignorerer Salesforce de forespurte sidestørrelsene, inkludert standard batchstørrelse queryMore() på 500 rader. Sidene som returneres av det eksterne systemet, bestemmer gruppene, men hver side kan ikke overskride 2000 rader. Grensene for Odata for Salesforce Connect gjelder imidlertid fremdeles.

Eksempel

Et manufacturing-firma bruker Salesforce til å behandle kundesaker. Kundeservicerepresentantene ønsker å få tilgang til sanntidsbestillingsinformasjonen fra ERP-systemet i serverbygningen for å få en 360-visning av kunden uten å måtte lære og kjøre rapporter manuelt i ERP.

Når du implementerer løsningen som er foreskrevet av dette mønsteret, bør du

• Konfigurer den eksterne datakilden med et Odata. Det eksterne programmet kan inkludere innebygd støtte for OData. For andre applikasjoner har store integrasjonsleverandører som Dell Boomi, Informatica, Jitterbit, MuleSoft og Progress Software samarbeidet med Salesforce på Salesforce Connect for å bygge adaptere.
• Point Salesforce Connect at Odata, enten direkte eller via en mellomprogramvareløsning.
• Synkroniser de eksterne databasetabellene med eksterne objekter i Salesforce. Når en bruker åpner en side med data fra disse eksterne objektene, sender Salesforce Connect oppkall i sanntid til serverdelprogrammene dine.

Utviklerdokumentasjon

• Salesforce Hjelp: Gi integrasjonsbrukere bare API-tilgang

• SOAP API Developer Guide

• REST API Developer Guide

• Streaming API Developer Guide

• Bulk API 2.0 og Bulk API Developer Guide

• Apex Developer Guide

• SOQL og SOSL Reference

• Salesforce Developer Grenser og tildelinger Hurtigreferanse

• Platform Events Utviklerhåndbok

• Apex Developer Guide: Salesforce Connect

Trailhead

• Større datavolumer

• Grunnleggende om plattformhendelser

• Grunnleggende om datafangst

• Hurtigstart: Salesforce Connect

For å være effektive medlemmer av bedriftsporteføljen må alle programmer opprettes og integreres med relevante sikkerhetsmekanismer. Moderne IT-strategier bruker en kombinasjon av lokale og skybaserte tjenester.

Integrering av sky-til-sky-tjenester fokuserer vanligvis på nettjenester og tilknyttet godkjenning, men tilkobling av stedsbaserte tjenester og skytjenester innebærer ofte økt kompleksitet. Denne delen beskriver sikkerhetsverktøy, teknikker og Salesforce-spesifikke vurderinger.

Omvendt proxyserver

En omvendt proxyserver er en server som sitter foran nettservere og videresender klientforespørsler (for eksempel nettleser) til disse nettserverne. Omvendte proxyer implementeres vanligvis for å bidra til å øke sikkerhet, ytelse og pålitelighet.

Det er en type proxyserver som henter ressurser på vegne av en klient fra én eller flere servere. Disse ressursene returneres deretter til klienten som om de kom fra selve proxy-serveren. Til forskjell fra en videresendingsproxy, som er en mellomledd for sine tilknyttede klienter for å kontakte en hvilken som helst server, er en omvendt proxy en mellomledd for sine tilknyttede servere for å bli kontaktet av en hvilken som helst klient.

I Salesforce-implementasjoner leveres en slik tjeneste vanligvis via et eksternt gatewayprodukt. Alternativer med åpen kildekode som Apache HTTP, lighttpd og nginix kan for eksempel brukes. Markedsprodukter inkluderer IBM WebSeal og Computer Associates SiteMinder. Disse produktene kan enkelt konfigureres til å proxy og behandle alle utgående Salesforce-forespørsler på vegne av den interne forespørselen.

Kryptering

Enkelte virksomheter krever at valgte transaksjoner eller datafelt krypteres mellom en kombinasjon av nettstedsbaserte og skybaserte programmer. Hvis organisasjonen må overholde tilleggskrav til samsvar, kan du implementere alternativer, inkludert følgende:

• Gatewaytjenester for kommersiell kryptering på stedet, inkludert Salesforces egne, CipherCloud, IBM DataPower og Computer Associates. For hver løsning kalles krypteringsmotoren eller gatewayen opp ved transaksjonsgrensen ved å sende og motta en kryptert last eller ved kryptering eller dekryptering av bestemte datafelt før HTTP(S)-forespørselen utføres.

• Skybaserte alternativer, som Salesforce Shield Plattformkryptering. Shield Platform Encryption gir dataene dine et helt nytt sikkerhetslag samtidig som de beholder viktig plattformfunksjonalitet. Dataene du velger, krypteres under lagring ved bruk av et avansert nøkkelutledningssystem. Du kan beskytte dataene dine mer sikkert enn noen gang før. Du finner mer informasjon i Salesforce Online-hjelpen.

Spesialisert WS-* protokollstøtte

For å løse kravene til sikkerhetsprotokoller (som WS-*), anbefaler vi disse alternativene.

• Sikkerhet/XML-gateway: Injiser WS-Security-legitimasjon (IBM WebSeal eller Datapower, Layer7, TIBCO og så videre) i selve transaksjonsstrømmen. Denne løsningen krever ingen endringer i nettjenester på programnivå eller oppkall av nettjenester fra Salesforce. Du kan også gjenbruke denne løsningen på tvers av Salesforce-installeringen. Det krever imidlertid tilleggsutforming, konfigurasjon, testing og vedlikehold for å behandle riktig WS-Security-innsetting i den eksisterende sikkerhetsgatewaytilnærmingen.

• Kryptering på transportnivå: Krypter kommunikasjonskanalen med toveis SSL- og IP-restriksjoner. Selv om denne tilnærmingen ikke implementerer WS-*-protokollen direkte alene, sikrer den kommunikasjonskanalen mellom programmene på stedet og Salesforce uten å overføre brukernavn og passord. Det kreves heller ikke endringer i Salesforce-genererte klasser. Det kan imidlertid være nødvendig med enkelte endringer av nettjenester på stedet (i selve programmet eller på mellomprogramvaren/ESB-laget).

• Tilpasset Salesforce-utvikling: Legg til WS-Security-hoder i den utgående SOAP-forespørselen via WSDL2Apex-verktøyet. Dette genererer en Java-lignende Apex fra WSDL-filen som brukes til å kalle opp den interne tjenesten. Denne tilnærmingen krever ingen endringer i serverdelnettjenester eller andre komponenter i DMZ, men den krever:

  • en økt bygg- og testinnsats
  • en relativt kompleks og manuell prosess for å manuelt kode WS-Security-attributtene (inkludert XML-serieralisering i Apex)
  • en høyere langsiktig vedlikeholdsinnsats

Notat: Det siste alternativet anbefales ikke på grunn av kompleksiteten og risikoen for at slike integrasjoner må gjennomgås regelmessig basert på regelmessige oppdateringer av Salesforce.

Andre sikkerhetshensyn

• Navngivne legitimationsoplysninger: En navngitt legitimasjon som er ment å sikre og forenkle godkjente API-oppkall til eksterne systemer, angir URL-adressen til et oppkallssluttpunkt og dens nødvendige godkjenningsparametere i én definisjon. For å effektivisere Apex og forenkle oppsettet av godkjente oppkall angir du en navngitt legitimasjon som oppkallssluttpunkt. Se heri for flere detaljer.

• OAUTH 2.0: OAuth 2.0 er et bransjestandard autorisasjonsrammeverk som lar en bruker gi begrenset tilgang til sine beskyttede ressurser til et tredjepartsprogram uten å dele legitimasjonen sin (som passord). I stedet for en direkte passordutveksling godkjenner brukeren en tilgangstokenforespørsel, som programmet deretter bruker til å få tilgang til brukerens data fra en ressursserver. Denne prosessen skiller klientprogrammet fra brukerens identitet og passord, og forbedrer sikkerheten ved å oppgi en midlertidig, omfangspesifikk "nøkkel" for tilgang til ressurser. Se heri for mer informasjon.

• Privat tilkobling: Når du integrerer Salesforce-organisasjonen med programmer som driftes på tredjeparts skytjenester, er det viktig å kunne sende og motta HTTP-trafikk sikkert. Med Privat tilkobling kan du øke sikkerheten i Amazon Web Services (AWS)-integrasjonene ved å konfigurere en fullt administrert nettverkstilkobling mellom Salesforce-organisasjonen og AWS Virtual Private Cloud (VPC). Rut deretter trafikken på tvers av skyer gjennom tilkoblingen i stedet for over det offentlige Internett for å redusere eksponeringen for utenforstående sikkerhetstrusler. Privat tilkobling er tilgjengelig i partnerskap med AWS via en funksjon kalt AWS PrivateLink. Privat tilkobling er toveis: Du kan starte både innkommende og utgående trafikk. Med innkommende tilkoblinger kan du sende trafikk til Salesforce med standard-API-ene. Og med utgående tilkoblinger kan du sende trafikk ut av Salesforce via funksjoner som Apex, Eksterne tjenester og Eksterne objekter. For mer informasjon om VPC vennligst heri.

Med Salesforce Event Bus med plattformhendelser, CDC (Change Datafangst) og Pub/Sub API kan virksomheter opprette hendelsesdrevne stilarkitekturer (EDA).

En EDA kobler forbrukere av hendelsesmeldinger (abonnenter) fra produsenter av hendelsesmeldinger (publiserere) for å gi større skala og fleksibilitet. Spesifikke mønstre dekkes i dette dokumentet som en del av den eksisterende mønsterstrukturen som sammenligner og kontrasterer relaterte alternativer eller alternativer. Men å få en helhetlig forståelse av den hendelsesdrevne arkitekturen og hvordan mønstre samhandler, kan hjelpe deg å velge riktig mønster for behovene dine.

Khalid Mohammed er en fremhevet arkitektleder innenfor Salesforces profesjonelle tjenester. Siden han sluttet seg til Salesforce i 2015 har han benyttet seg av sin omfattende ekspertise innen Enterprise-programmer og -arkitektur, gjennom mange kundetransformasjoner før han ble ansatt i Salesforce. Khalid leder Delivery Architecture Board og er også anerkjent som leder for sertifisert teknisk arkitekt.

Gulal Kumar er Software Engineering Architect hos Salesforce med fokus på data og integrasjonsarkitektur. Med over 20 års erfaring innen integrasjon og API-er, moderniseringsprogrammer, sikkerhet og AIML-initiativer, har han en rik ekspertise. Gulal har vært forpliktet til å fremme forretningstransformasjonsinitiativer, forbedre sikkerhet og motstandskraft, fremme arkitektonisk dyktighet og lede AIML-initiativer på tvers av ulike domener.

Sushant er teknisk arkitekt hos Salesforce og spesialiserer seg på løsningsarkitektur og levering av Salesforce-plattformer fra ende til ende. Med dyp ekspertise innen plattformstyring, programutvikling, integrering og DevOps har han ledet en rekke kundetransformasjonsprogrammer på tvers av bransjer. Sushant er forpliktet til å oppnå enestående levering og skalerbare arkitektoniske utfall.