Wanneer u Salesforce implementeert, moet u het doorgaans integreren met andere toepassingen. Hoewel elk integratiescenario uniek is, zijn er veelvoorkomende vereisten en problemen die ontwikkelaars en architecten moeten oplossen.

Dit document beschrijft strategieën (in de vorm van patronen) voor deze veel voorkomende integratiescenario's. Elk patroon beschrijft het ontwerp en de aanpak voor een bepaald scenario in plaats van een specifieke implementatie te beschrijven. In dit document vindt u:

• Een aantal patronen die betrekking hebben op belangrijke integratiescenario's voor "archetypen"
• Een selectiematrix om te bepalen welk patroon het beste bij uw scenario past
• Integratietips en best practices

Doel en bereik

Dit document is bedoeld voor ontwerpers en architecten die het Salesforce Platform moeten integreren met andere toepassingen in hun onderneming. Deze inhoud is een distillatie van vele succesvolle implementaties door Salesforce-architecten en -partners.

Lees Patroonsamenvatting en patroonselectiehandleiding om vertrouwd te raken met integratiemogelijkheden en opties die beschikbaar zijn voor grootschalige acceptatie van op Salesforce gebaseerde toepassingen. Architecten en ontwikkelaars moeten rekening houden met deze patroondetails en best practices tijdens de ontwerp- en implementatiefase van een Salesforce-integratieproject.

Als deze patronen op de juiste manier worden geïmplementeerd, kunt u zo snel mogelijk naar productie gaan en beschikt u over de meest stabiele, schaalbare en onderhoudsvrije set toepassingen. De eigen consultingarchitecten van Salesforce gebruiken deze patronen als referentiepunten tijdens architectuurbeoordelingen en onderhouden en verbeteren ze actief.

Zoals bij alle patronen omvat deze inhoud de meeste integratiescenario's, maar niet alle. Hoewel Salesforce integratie van de gebruikersinterface (UI) toestaat, bijvoorbeeld mashups, valt een dergelijke integratie buiten het bereik van dit document.

Patroonsjabloon

Elk integratiepatroon volgt een consistente structuur. Dit biedt consistentie in de informatie die in elk patroon wordt gegeven en maakt het ook gemakkelijker om patronen te vergelijken.

Naam

De patroonidentifier die ook het type integratie aangeeft dat in het patroon is opgenomen.

Context

Het algemene integratiescenario waarop het patroon betrekking heeft. Context geeft informatie over wat gebruikers proberen te bereiken en hoe de toepassing zich gedraagt om aan de vereisten te voldoen.

Probleem

Het scenario of probleem (uitgedrukt als een vraag) waarvoor het patroon is ontworpen. Lees bij het beoordelen van de patronen deze sectie om snel te begrijpen of het patroon geschikt is voor uw integratiescenario.

Krachten

De beperkingen en omstandigheden die het opgegeven scenario moeilijk op te lossen maken.

Oplossing

De aanbevolen manier om het integratiescenario op te lossen.

Sketch

Een UML-volgordediagram dat toont hoe de oplossing het scenario aanpakt.

Resultaten

Legt de details uit van de manier waarop u de oplossing toepast op uw integratiescenario en hoe deze de krachten oplost die aan dat scenario zijn gekoppeld. Deze sectie bevat ook nieuwe uitdagingen die kunnen ontstaan als gevolg van het toepassen van het patroon.

Sidebars

Aanvullende secties gerelateerd aan het patroon die belangrijke technische problemen, variaties van het patroon, patroonspecifieke problemen, enzovoort bevatten.

Voorbeeld

Een end-to-end scenario dat beschrijft hoe het ontwerppatroon wordt gebruikt in een Salesforce-scenario uit de praktijk. In het voorbeeld worden de integratiedoelen uitgelegd en wordt uitgelegd hoe u het patroon implementeert om die doelen te bereiken.

Patroonsamenvatting

De volgende tabel vermeldt de integratiepatronen in dit document.

Lijst van patronen remote-process-aanroep--verzoek-en-antwoord

Pattern Approach

De integratiepatronen in dit document zijn ingedeeld in drie categorieën:

• Gegevensintegratie: deze patronen hebben betrekking op de vereiste om gegevens te synchroniseren die zich in twee of meer systemen bevinden, zodat beide systemen altijd tijdige en betekenisvolle gegevens bevatten. Gegevensintegratie is vaak het eenvoudigste type integratie om te implementeren, maar vereist de juiste informatiebeheertechnieken om de oplossing duurzaam en kosteneffectief te maken. Dergelijke technieken omvatten vaak aspecten van masterdata management (MDM), data governance, mastering, de-duplicatie, gegevensstroomontwerp en andere.

• Procesintegratie—De patronen in deze categorie geven aan dat een bedrijfsproces twee of meer toepassingen moet gebruiken om de taak te voltooien. Wanneer u een oplossing voor dit type integratie implementeert, moet de activerende toepassing over procesgrenzen heen andere toepassingen aanroepen. Meestal omvatten deze patronen ook zowel doeltreffende combinaties (waarbij één toepassing de centrale “controller” is) als choreografie (waarbij toepassingen meerdere deelnemers zijn en er geen centrale “controller” is). Deze integraties vereisen vaak complexe vereisten voor ontwerp, testen en het afhandelen van uitzonderingen. Dergelijke samengestelde toepassingen stellen doorgaans hogere eisen aan de onderliggende systemen, omdat ze vaak langdurige transacties ondersteunen en de mogelijkheid bieden om te rapporteren over de processtatus of deze te beheren.

• Virtuele integratie—De patronen in deze categorie hebben betrekking op de noodzaak voor een gebruiker om gegevens weer te geven, te zoeken en te wijzigen die zijn opgeslagen in een extern systeem. Wanneer u een oplossing voor dit type integratie implementeert, moet de activerende toepassing andere toepassingen aanroepen en in real-time met hun gegevens werken. Dit type integratie verwijdert de noodzaak van gegevensreplicatie tussen systemen en betekent dat gebruikers altijd interactie hebben met de meest actuele gegevens.

Het kiezen van de beste integratiestrategie voor uw systeem is niet triviaal. Er zijn vele aspecten om rekening mee te houden en vele tools die kunnen worden gebruikt, waarbij sommige tools geschikter zijn dan andere voor bepaalde taken. Elk patroon behandelt specifieke kritieke gebieden, waaronder de mogelijkheden van elk van de systemen, het volume van gegevens, de afhandeling van storingen en transactionaliteit.

Patroonselectiehandleiding

De selectiematrixtabellen vermelden de patronen en hun belangrijkste aspecten om u te helpen bepalen welk patroon het beste aansluit op uw integratievereisten. De patronen worden gecategoriseerd met behulp van deze dimensies.

Salesforce integreren met een ander systeem

Deze tabel vermeldt de patronen en hun belangrijkste aspecten om u te helpen bepalen welk patroon het beste aansluit op uw vereisten wanneer uw integratie plaatsvindt van Salesforce naar een ander systeem.

Een ander systeem integreren met Salesforce

Deze tabel vermeldt de patronen en hun belangrijkste aspecten om u te helpen het patroon te bepalen dat het beste aansluit op uw vereisten wanneer uw integratie plaatsvindt vanuit een ander systeem naar Salesforce.

Termen en definities van middleware

Deze tabel vermeldt enkele belangrijke termen die zijn gerelateerd aan middleware en hun definities met betrekking tot deze patronen.

Context

U gebruikt Salesforce om leads bij te houden, uw pijplijn te beheren, opportunities te maken en orderdetails vast te leggen die leads converteren naar klanten. Het Salesforce-systeem bevat of verwerkt echter geen orders. Nadat de orderdetails zijn vastgelegd in Salesforce, wordt de order gemaakt in het externe systeem, dat de order tot aan de conclusie beheert.

Wanneer u dit patroon implementeert, roept Salesforce het externe systeem aan om de order te maken en wacht vervolgens op succesvolle voltooiing. Indien geslaagd, antwoordt het externe systeem synchroon met de orderstatus en het ordernummer. Als onderdeel van dezelfde transactie werkt Salesforce het ordernummer en de status intern bij. Het ordernummer wordt gebruikt als externe sleutel voor daaropvolgende updates van het externe systeem.

Probleem

Wanneer een event zich voordoet in Salesforce, hoe initieert u dan een proces in een extern systeem, geeft u de vereiste informatie door aan dat proces, ontvangt u een reactie van het externe systeem en gebruikt u die reactiegegevens vervolgens om updates aan te brengen binnen Salesforce?

Krachten

Denk aan de volgende krachten bij het toepassen van oplossingen op basis van dit patroon.

• Vereist de aanroep naar het externe systeem dat Salesforce wacht op een reactie voordat de verwerking wordt voortgezet? Is de aanroep naar het externe systeem een synchroon verzoek-antwoord of een asynchroon verzoek?
• Als de aanroep naar het externe systeem synchroon is, moet Salesforce de respons dan verwerken als onderdeel van dezelfde transactie als de initiële aanroep?
• Is de berichtgrootte klein of groot?
• Is de integratie gebaseerd op het optreden van een specifieke event, zoals een knopklik in de Salesforce-gebruikersinterface of op DML gebaseerde events?
• Kan het externe eindpunt met een lage latentie op het verzoek reageren? Hoeveel gebruikers voeren deze transactie waarschijnlijk uit tijdens een piekperiode?

Oplossing

Deze tabel bevat oplossingen voor dit integratieprobleem.

Sketch

Dit diagram illustreert een synchrone externe procesaanroep met behulp van Apex aanroepen.

Salesforce aanroepen naar een extern systeem

Diagram downloaden

In dit scenario:

• Een actie wordt geïnitieerd op de Lightning pagina (bijvoorbeeld een knopklik).
• De browser (via een client-side controller in het geval van een Lightning component) voert een HTTP POST uit die op zijn beurt een actie uitvoert op de corresponderende Apex controller.
• De controller roept de feitelijke aanroep naar de externe webservice aan.
• De respons van het externe systeem wordt geretourneerd naar de Apex controller. De controller verwerkt de respons, werkt indien nodig gegevens in Salesforce bij en geeft de pagina opnieuw weer.

In gevallen waarin de daaropvolgende status moet worden bijgehouden, retourneert het externe systeem een unieke identifier die is opgeslagen in de Salesforce-record.

Resultaten

De toepassing van de oplossingen die zijn gerelateerd aan dit patroon, maakt event-geïnitieerde externe procesaanroepen mogelijk, waarbij Salesforce de verwerking afhandelt.

Aanroepmechanismen

Het aanroepmechanisme is afhankelijk van de oplossing die is gekozen om dit patroon te implementeren.

Foutafhandeling en herstel

Het is belangrijk om een strategie voor foutafhandeling en herstel op te nemen als onderdeel van de algemene oplossing.

• Foutafhandeling: wanneer er een fout optreedt (uitzonderingen of foutcodes worden geretourneerd aan de beller), beheert de beller de foutafhandeling. Bijvoorbeeld een foutbericht dat wordt weergegeven op de pagina van de eindgebruiker of dat wordt vastgelegd bij een tabel die verdere actie vereist.

• Herstel: wijzigingen worden pas doorgevoerd naar Salesforce als de beller een succesvolle reactie ontvangt. Zo wordt de orderstatus pas bijgewerkt in de database nadat er een respons is ontvangen die aangeeft dat de order is geslaagd. Indien nodig kan de beller de bewerking opnieuw proberen.

Overwegingen bij impotent ontwerp

Idempotente mogelijkheden garanderen dat herhaalde aanroepen veilig zijn. Als idempotentie niet is geïmplementeerd, kunnen herhaalde aanroepen van hetzelfde bericht verschillende resultaten hebben, wat mogelijk leidt tot problemen met de gegevensintegriteit. Mogelijke problemen zijn het maken van duplicaatrecords of duplicaatverwerking van transacties.

Het is belangrijk ervoor te zorgen dat de externe procedure die wordt aangeroepen, idempotent is. Als de aanroep wordt gedaan via de gebruikersinterface, moeten we zorgen voor idempotentie op de integratielaag, vooral als er geen garantie is dat Salesforce slechts één keer aanroept.

De meest typische methode voor het samenstellen van een idempotente ontvanger is het bijhouden van duplicaten op basis van unieke bericht-ID's die door de consument zijn verzonden. Apex webservice- of REST-aanroepen moeten worden aangepast om een unieke bericht-ID te verzenden.

Daarnaast moeten bewerkingen die records maken op het externe systeem, controleren op duplicaten voordat ze worden ingevoegd. Controleer dit door een unieke record-ID van Salesforce door te geven. Als de record voorkomt op het externe systeem, werkt u de record bij. In de meeste systemen wordt deze bewerking een upsert-bewerking genoemd.

Beveiligingsoverwegingen

Elke aanroep naar een extern systeem moet de vertrouwelijkheid, integriteit en beschikbaarheid van het verzoek waarborgen. De volgende beveiligingsoverwegingen zijn specifiek voor het gebruik van Apex SOAP- en HTTP-aanroepen in dit patroon.

• Eenrichtings-SSL is standaard ingeschakeld, maar tweeweg-SSL wordt ondersteund met zowel zelfondertekende als door een certificeringsinstantie ondertekende certificaten om de authenticiteit van zowel de client als de server te behouden.

• Als u uw Apex code wilt stroomlijnen en de set-up van geauthenticeerde aanroepen wilt vereenvoudigen, geeft u een benoemd gegeven op in het eindpunt van de aanroep.

• Overweeg het gebruik van OAUTH 2.0 als authenticatiemechanisme voor integratie met externe systemen.

• Overweeg waar nodig het gebruik van hashes in één richting of digitale handtekeningen met behulp van de Apex Crypto-klassemethoden om de integriteit van verzoeken te waarborgen.

• Het externe systeem moet worden beschermd door de juiste firewallmechanismen te implementeren. Zie Beveiligingsoverwegingen.

• Salesforce biedt momenteel geen ondersteuning voor WS-Security. Hoewel deze complexe WS-Security-headers niet automatisch worden gegenereerd of afgedwongen vanuit een inkomende WSDL, kunt u ze handmatig samenstellen en implementeren door aangepaste Apex klassen te maken voor het afhandelen van de SOAP-headers en beveiligingstokens voor inkomende verzoeken.

Sidebars

Geen.

Timeliness

Tijdigheid is in dit patroon van groot belang. Doorgaans:

• Het verzoek wordt doorgaans aangeroepen vanuit de gebruikersinterface, dus het proces mag de gebruiker niet in de wachtstand houden.
• Salesforce heeft een configureerbare time-out van maximaal 120 seconden voor aanroepen vanuit Apex.
• Voltooiing van het externe proces wordt tijdig uitgevoerd om te worden voltooid binnen de Salesforce-time-outlimiet en binnen de verwachtingen van de gebruiker.
• Externe aanroepen zijn onderworpen aan Apex beheerlimieten voor synchrone transacties. Zorg er dus voor dat u het risico verkleint dat u meer dan 50 transacties instantieert die elk meer dan vijf seconden worden uitgevoerd. Naast het garanderen dat het externe eindpunt presteert, omvatten opties om het risico van een time-out te beperken:
  • De time-out van de externe aanroep instellen op vijf seconden.
  • Een voortzetting in Lightning Components gebruiken om langlopende transacties af te handelen

Gegevensvolumes

Dit patroon wordt voornamelijk gebruikt voor real-time activiteiten met een klein volume, vanwege de kleine time-outwaarden en de maximale grootte van het verzoek of de reactie voor de Apex call-oplossing. Gebruik dit patroon niet in batchverwerkingsactiviteiten waarbij de gegevenspayload is opgenomen in het bericht.

Ondersteuning van eindpuntmogelijkheden en standaarden

De mogelijkheden en standaardondersteuning voor het eindpunt zijn afhankelijk van de oplossing die u kiest.

Staatsbeheer

Bij het integreren van systemen zijn sleutels belangrijk voor het continu bijhouden van de status. Er zijn twee opties.

• Salesforce slaat de primaire of unieke vervangende sleutel van het externe systeem voor de externe record op.
• Het externe systeem slaat de unieke Salesforce-record-ID of een andere unieke vervangende sleutel op.

Er zijn specifieke overwegingen bij het afhandelen van integratiesleutels, afhankelijk van welk systeem de hoofdrecord bevat, zoals getoond in de volgende tabel.

Complexe integratiescenario's

In bepaalde gevallen kan de oplossing die door dit patroon wordt voorgeschreven, de implementatie van verschillende complexe integratiescenario's vereisen. Dit komt het best tot zijn recht door middleware te gebruiken of Salesforce een samengestelde service te laten aanroepen. Deze scenario's omvatten:

• Afstemming van bedrijfsprocessen en regels met complexe stroomlogica
• Aggregatie van gesprekken en de resultaten ervan over gesprekken naar meerdere systemen
• Transformatie van zowel inkomende als uitgaande berichten
• Transactionele integriteit behouden voor alle aanroepen naar meerdere systemen

Gouverneurlimieten

Zie Uitvoeringsbeheer en limieten in de Apex Developer Guide voor informatie over Apex limieten.

Middlewaremogelijkheden

De volgende tabel markeert de gewenste eigenschappen van een middlewaresysteem dat aan dit patroon deelneemt.

Voorbeeld

Een nutsbedrijf gebruikt Salesforce en heeft een afzonderlijk systeem dat factureringsgegevens van klanten bevat. Als onderdeel van het bestelproces moeten nieuwe factureringsaccounts worden gemaakt in het factureringssysteem en moet Salesforce het factuuraccountnummer weerspiegelen binnen het orderactiveringsproces. Ze hebben een bestaande webservice waarmee een factuuraccount kan worden gemaakt en het factuuraccountnummer als reactie kan worden geretourneerd.

Aan deze eis kan worden voldaan met de volgende benadering.

1. Salesforce verbruikt de WSDL van de factureringsaccountservice vanuit een Apex proxyklasse.
2. Voer de Apex proxyklasse uit met de klantgegevens die zijn doorgegeven aan de externe webservice vanuit een aangepaste Apex controller of externe service.
3. De aangepaste controller parseert vervolgens de retourwaarden uit de Apex aanroep en slaat die informatie op in het salesforce-object.

Dit voorbeeld toont aan dat:

• De status van de klant wordt bijgehouden met een accountnummer dat is opgeslagen in het Salesforce-accountobject.
• Verwerking van het antwoordbericht door de beller

Context

U gebruikt Salesforce om leads bij te houden, uw pijplijn te beheren, opportunities te maken en orderdetails vast te leggen die leads converteren naar klanten. Als onderdeel van de processen voor Orderbeheer moet er echter een factureringsaccount worden gemaakt in het factureringssysteem voor de order.

Wanneer u dit patroon implementeert, roept Salesforce het externe systeem aan om de factuuraccount te maken, maar wacht niet op de succesvolle voltooiing van het gesprek. Het externe systeem kan Salesforce optioneel bijwerken met de nieuwe factuuraccount die in een afzonderlijke transactie is gemaakt.

Probleem

Wanneer een event zich voordoet in Salesforce, hoe initieert u dan een proces in een extern systeem en geeft u de vereiste informatie door aan dat proces zonder te wachten op een reactie van het externe systeem?

Krachten

Denk aan de volgende krachten bij het toepassen van oplossingen op basis van dit patroon.

• Vereist de aanroep naar het externe systeem dat Salesforce wacht op een reactie voordat de verwerking wordt voortgezet? Is de aanroep naar het externe systeem synchroon of asynchroon?
• Als de aanroep naar het externe systeem synchroon is, moet de respons dan door Salesforce worden verwerkt als onderdeel van dezelfde transactie als de aanroep?
• Is de berichtgrootte klein?
• Is de integratie gebaseerd op het optreden van een specifieke event, zoals een knopklik in de Salesforce-gebruikersinterface of op DML gebaseerde events?
• Is gegarandeerde berichtlevering vanuit Salesforce naar het externe systeem een vereiste?
• Kan het externe systeem deelnemen aan een contract-first integratie waarin Salesforce het contract opgeeft? In sommige oplossingsvarianten (bijvoorbeeld uitgaand berichtenverkeer) geeft Salesforce een contract op dat het externe systeemeindpunt implementeert.
• Ondersteunt het eindpunt of de Enterprise Service Bus (ESB) lange polling?
• Hebben declaratieve configuratiemethoden de voorkeur boven aangepaste Apex ontwikkeling? In dit geval hebben oplossingen zoals platformevents de voorkeur boven Apex aanroepen.

Oplossing

De volgende tabel bevat oplossingen voor dit integratieprobleem.

Sketch

Het volgende diagram illustreert een aanroep van Salesforce naar een extern systeem waarin het maken of bijwerken van bewerkingen voor een record het gesprek activeert.

Diagram downloaden

In dit scenario:

1. Een extern systeem abonneert zich op de platformevent.
2. Een update of invoeging vindt plaats voor een bepaalde set records in Salesforce.
3. Een Salesforce-stroom wordt geactiveerd wanneer aan een set voorwaarden wordt voldaan.
4. Deze stroom maakt een platformevent.
5. De externe luisteraar ontvangt het eventbericht en plaatst het bericht in een lokale wachtrij.
6. De toepassing in de wachtrij stuurt het bericht door naar de externe toepassing voor verwerking.

In het geval dat het externe systeem bewerkingen tegen Salesforce moet uitvoeren, kunt u een optionele callbackbewerking implementeren.

Resultaten

De toepassing van de oplossingen die gerelateerd zijn aan dit patroon maakt het volgende mogelijk:

• Door gebruikersinterface geïnitieerde externe procesaanroepen waarin het resultaat van de transactie kan worden weergegeven aan de eindgebruiker
• Door DML-events geïnitieerde externe procesaanroepen waarin het resultaat van de transactie kan worden verwerkt door het aanroepproces

Aanroepmechanismen

Het aanroepmechanisme is afhankelijk van de oplossing die is gekozen om dit patroon te implementeren.

Foutafhandeling en herstel

Een strategie voor foutafhandeling en herstel moet worden beschouwd als onderdeel van de algemene oplossing. De beste methode is afhankelijk van de oplossing die u kiest.

Overwegingen bij impotent ontwerp

Platformevents worden slechts eenmaal naar de bus gepubliceerd. Er wordt niet opnieuw geprobeerd aan de Salesforce-zijde. Het is aan de ESB om te verzoeken dat de events opnieuw worden afgespeeld. In een herhaling blijft de herhalings-ID van het platformevent hetzelfde en kan de ESB dubbele berichten proberen op basis van de herhalings-ID.

Idempotentie is belangrijk voor uitgaand berichtenverkeer omdat het asynchroon is en nieuwe pogingen worden geïnitieerd wanneer er geen positieve bevestiging wordt ontvangen. Daarom moet de externe service berichten van Salesforce op een idempotente manier kunnen afhandelen.

Uitgaand berichtenverkeer verzendt een unieke ID per bericht en deze ID blijft hetzelfde voor alle pogingen. Het externe systeem kan dubbele berichten bijhouden op basis van deze unieke ID. De unieke record-ID voor elke record die wordt bijgewerkt, wordt ook verzonden en kan worden gebruikt om het maken van dubbele records te voorkomen.

De idempotente ontwerpoverwegingen in het patroon Aanroeping van extern proces: verzoek en antwoord zijn ook van toepassing op dit patroon.

Beveiligingsoverwegingen

Elke aanroep naar een extern systeem moet de vertrouwelijkheid, integriteit en beschikbaarheid van het verzoek waarborgen. Afhankelijk van de oplossing die u kiest, gelden verschillende beveiligingsoverwegingen.

Zie Beveiligingsoverwegingen.

Sidebars

Geen.

Timeliness

Tijdigheid is minder een factor bij het vuur-en-vergeet patroon. De controle wordt onmiddellijk aan de klant overgedragen of na een positieve bevestiging van een geslaagde overdracht aan het externe systeem. Bij uitgaand berichtenverkeer van Salesforce moet de bevestiging binnen 24 uur plaatsvinden (dit kan worden verlengd tot zeven dagen); anders vervalt het bericht. Voor platformevents stuurt Salesforce de events naar de eventbus en wacht niet op een bevestiging of bevestiging van de abonnee. Als de abonnee het bericht niet ontvangt, kan de abonnee verzoeken om de event opnieuw af te spelen met behulp van de ID van het eventantwoord. Eventberichten met groot volume worden 72 uur (drie dagen) bewaard. Als u eventberichten uit het verleden wilt ophalen, gebruikt u CometD-clients om u te abonneren op een kanaal.

Gegevensvolumes

Overwegingen bij gegevensvolumes zijn afhankelijk van welke oplossing u kiest. Zie voor de limieten van elke oplossing de Salesforce Limits Quick Reference.

Ondersteuning van eindpuntmogelijkheden en standaarden

De mogelijkheden en standaardondersteuning voor het eindpunt zijn afhankelijk van de oplossing die u kiest.

Staatsbeheer

Bij het integreren van systemen zijn unieke record-ID's belangrijk voor het continu bijhouden van de status. Als er bijvoorbeeld een record wordt gemaakt op het externe systeem, hebt u twee opties.

• Salesforce slaat de primaire of unieke vervangende sleutel van het externe systeem voor de externe record op.
• Het externe systeem slaat de unieke Salesforce-record-ID of een andere unieke vervangende sleutel op.

De volgende tabel vermeldt overwegingen voor statusbeheer in dit patroon.

Complexe integratiescenario's

Elke oplossing in dit patroon heeft verschillende overwegingen voor complexe integratiescenario's zoals transformatie en procescombinatie.

Gouverneurlimieten

Vanwege het multitenant karakter van het Salesforce-platform zijn er limieten aan uitgaande aanroepen. Limieten zijn afhankelijk van het type uitgaand gesprek en de timing van het gesprek.

Zie de Platforms Events Developer Guide voor limieten en toewijzingen die van toepassing zijn op platformevents.

Betrouwbaar berichtenverkeer

Betrouwbaar berichtenverkeer probeert het probleem op te lossen van het garanderen van de levering van een bericht aan een extern systeem waarin de afzonderlijke componenten onbetrouwbaar zijn. De methode om de ontvangst van een bericht door het externe systeem te waarborgen, is afhankelijk van de oplossing die u kiest.

In het geval van Salesforce Change Gegevensvastlegging worden typen wijzigingsevents geleverd om speciale situaties af te handelen, zoals het vastleggen van wijzigingen die niet zijn vastgelegd in de Salesforce-toepassingsservers, of het afhandelen van grote hoeveelheden wijzigingen.

In sommige gevallen verzendt Salesforce Gap-events in plaats van wijzigingsevents om abonnees te informeren over fouten of als het niet mogelijk is om wijzigingsevents te genereren. Een gap-event bevat informatie over de wijziging in de koptekst, zoals het wijzigingstype en de record-ID. Het bevat geen details over de wijziging, zoals recordvelden. Om wijzigingen efficiënter vast te leggen, worden overloopevents gegenereerd voor afzonderlijke transacties die een drempelwaarde overschrijden. Voor meer informatie zie hier.

Middlewaremogelijkheden

De volgende tabel markeert de gewenste eigenschappen van een middlewaresysteem dat aan dit patroon deelneemt.

Oplossingsvariant—Platformevents: Publicatiewerking en transacties

Wanneer Platform-eventberichten onmiddellijk worden gepubliceerd, houdt het publiceren van events zich niet aan transactiegrenzen van het publicatieproces. Eventberichten kunnen worden gepubliceerd voordat de transactie is voltooid of zelfs als een transactie mislukt. Deze werking kan leiden tot problemen wanneer een abonnee verwacht gegevens te vinden die de publicerende transactie doorvoert. De gegevens zijn mogelijk niet aanwezig wanneer de abonnee het eventbericht ontvangt. Als u dit probleem wilt oplossen, stelt u de publicatiewerking van het platformevent in op Publiceren na verbintenis in de eventdefinitie. De publicatiewerkingen die u kunt instellen in een platformeventdefinitie zijn:

• Publiceren na verbintenis om het eventbericht pas te laten publiceren nadat een transactie met succes is gecommit. Selecteer deze optie als abonnees vertrouwen op gegevens die de publicerende transactie vastlegt. Een proces publiceert bijvoorbeeld een eventbericht en maakt een taakrecord. Een tweede proces dat is geabonneerd op de event, wordt geactiveerd en verwacht de taakrecord te vinden. Een andere reden om voor deze werking te kiezen is wanneer u niet wilt dat het eventbericht wordt gepubliceerd als de transactie mislukt.
• Onmiddellijk publiceren om het eventbericht te laten publiceren wanneer de aanroep voor publiceren wordt uitgevoerd. Selecteer deze optie als u wilt dat het eventbericht wordt gepubliceerd, ongeacht of de transactie slaagt. Kies deze optie ook als de uitgever en abonnees onafhankelijk zijn en abonnees niet afhankelijk zijn van gegevens die door de uitgever zijn vastgelegd. Zo is de werking voor onmiddellijk publiceren geschikt voor een event dat wordt gebruikt voor het vastleggen van doeleinden. Met deze optie kan een abonnee het eventbericht ontvangen voordat gegevens worden vastgelegd door de uitgeverstransactie.

Voorbeeld

Een telecommunicatiebedrijf wil Salesforce gebruiken als front-end voor het maken van accounts met behulp van het lead-naar-opportunityproces. Er wordt een order gemaakt in Salesforce wanneer de opportunity is gesloten en gewonnen, maar het back-end ERP-systeem is de gegevensbeheerder. De order moet worden opgeslagen in de Salesforce-opportunityrecord en de opportunitystatus moet worden gewijzigd om aan te geven dat de order is gemaakt.

De volgende beperkingen zijn van toepassing.

• Alleen declaratieve ontwikkeling kan worden geïmplementeerd.
• U hoeft het ordernummer niet onmiddellijk te melden nadat de opportunity naar een order is geconverteerd.
• De organisatie heeft een ESB die het CometD-protocol ondersteunt en zich kan abonneren op platformevents.

Dit voorbeeld kan het best worden geïmplementeerd met behulp van Salesforce Platform-events, maar vereist wel dat de ESB zich abonneert op de Platform-event.

Aan de Salesforce-zijde:

• Maak een stroom om de platformevent te initiëren (bijvoorbeeld wanneer de opportunitystatus verandert in Close-Won).
• Maak een nieuw platformevent dat de opportunitydetails publiceert.

Aan de externe systeemzijde:

• De ESB abonneert zich op het Salesforce Platform-event met behulp van het CometD-protocol.
• De ESB ontvangt een of meer kennisgevingen die aangeven dat de opportunity moet worden geconverteerd naar een order.
• De ESB stuurt het bericht door naar het back-end ERP-systeem zodat de order kan worden gemaakt.
• Nadat de order is gemaakt in het ERP-systeem, roept een afzonderlijke thread Salesforce aan met behulp van de SessionId als authenticatietoken. De callback werkt de opportunity bij met het ordernummer en de status. U kunt deze callback uitvoeren met behulp van gedocumenteerde patroonoplossingen, zoals Salesforce Platform-events, Salesforce SOAP API, REST API of een Apex webservice.

Dit voorbeeld toont het volgende aan.

• Implementatie van een extern proces dat asynchroon wordt aangeroepen
• End-to-end gegarandeerde levering
• Daaropvolgende callback naar Salesforce om de status van de record bij te werken

Context

U verplaatst uw CRM-implementatie naar Salesforce en wilt:

• Extraheer en transformeer accounts, contactpersonen en opportunities uit het huidige CRM-systeem en laad de gegevens in Salesforce (initiële gegevensimport).
• Extraheer, transformeer en laad factureringsgegevens van klanten wekelijks in Salesforce vanuit een extern systeem (doorlopend).
• Extraheer informatie over klantactiviteit uit Salesforce en importeer deze wekelijks in een on-premises gegevensmagazijn (doorlopend).

Probleem

Hoe importeert u gegevens in Salesforce en exporteert u gegevens uit Salesforce, rekening houdend met het feit dat deze import en export de activiteiten van eindgebruikers tijdens kantooruren kunnen verstoren en grote hoeveelheden gegevens kunnen omvatten?

Krachten

Er zijn verschillende krachten om rekening mee te houden bij het toepassen van oplossingen op basis van dit patroon:

• Moeten de gegevens worden opgeslagen in Salesforce? Zo niet, dan zijn er andere integratiemogelijkheden die een architect kan en moet overwegen (mashups bijvoorbeeld).
• Als de gegevens moeten worden opgeslagen in Salesforce, moeten de gegevens dan worden vernieuwd als reactie op een event in het externe systeem?
• Moeten de gegevens op geplande basis worden vernieuwd?
• Ondersteunt de data primaire bedrijfsprocessen?
• Zijn er vereisten voor analyses (rapportage) die worden beïnvloed door de beschikbaarheid van deze gegevens in Salesforce?

Oplossing

De volgende tabel bevat diverse oplossingen voor dit integratieprobleem.

Sketch

Het volgende diagram illustreert de volgorde van events in dit patroon, waarbij Salesforce het gegevenshoofdobject is.

Diagram downloaden

Het volgende diagram illustreert de daaropvolgende synchronisatie van events in vrijwel realtime, waarbij Salesforce de gegevensbeheerder is.

Resultaten

In de volgende scenario's kunt u gegevens die extern afkomstig zijn, integreren met Salesforce:

• Extern systeem is de gegevensbeheerder: Salesforce verbruikt gegevens die worden aangeleverd door één bronsysteem of meerdere systemen. In dit scenario is het gebruikelijk om een datawarehouse of datamart te hebben die de gegevens aggregeert voordat de gegevens in Salesforce worden geïmporteerd.
• Salesforce is de gegevensbeheerder—Salesforce is het registratiesysteem voor bepaalde entiteiten en clienttoepassingen van Salesforce Change Gegevensvastlegging kunnen worden geïnformeerd over wijzigingen in Salesforce-gegevens.

In een typisch Salesforce-integratiescenario voert het implementatieteam een van de volgende handelingen uit:

• Implementeer gegevensvastlegging voor de brongegevensset.
• Implementeer een set ondersteunende databasestructuren, ook wel controletabellen genoemd, in een tussentijdse, on-premises database.

De ETL-tool wordt vervolgens gebruikt om programma's te maken die:

1. Lees een controletabel om de laatste uitvoeringstijd van de taak te bepalen en eventuele andere benodigde controlewaarden te extraheren.
2. Gebruik de bovenstaande controlewaarden als filters en voer een query uit op de brongegevensset.
3. Pas vooraf gedefinieerde verwerkingsregels toe, inclusief validatie, verrijking, enzovoort.
4. Gebruik beschikbare connectoren/transformatiemogelijkheden van de ETL-tool om de bestemmingsgegevensset te maken.
5. Schrijf de gegevensset naar Salesforce-objecten.
6. Als de verwerking is geslaagd, werkt u de controlewaarden in de controletabel bij.
7. Als de verwerking mislukt, werkt u de controletabellen bij met waarden die een herstart en beëindiging mogelijk maken.

Opmerking: U wordt aangeraden om de besturingstabellen en gekoppelde gegevensstructuren te maken in een omgeving waartoe de ETL-tool toegang heeft, zelfs als er geen toegang tot Salesforce beschikbaar is. Dit biedt voldoende veerkracht. Salesforce moet in dit proces als spreekbuis worden beschouwd en de ETL-infrastructuur is de hub.

Als u een ETL-tool maximaal wilt laten profiteren van gegevenssynchronisatiemogelijkheden, moet u rekening houden met het volgende:

• Koppel en sequence de ETL-taken om een samenhangend proces te bieden.
• Gebruik primaire sleutels van beide systemen om inkomende gegevens te vergelijken.
• Gebruik specifieke API-methoden om alleen bijgewerkte gegevens te extraheren.
• Als u onderliggende records importeert in een hoofd-/detail- of opzoekrelatie, groepeert u de geïmporteerde gegevens met behulp van de bovenliggende sleutel ervan bij de bron om vergrendeling te voorkomen. Als u bijvoorbeeld contactpersoonsgegevens importeert, moet u de contactpersoonsgegevens groeperen op de bovenliggende accountsleutel, zodat het maximale aantal contactpersonen voor één account in één API-aanroep kan worden geladen. Als u de geïmporteerde gegevens niet groepeert, wordt doorgaans de eerste contactpersoonsrecord geladen en mislukken daaropvolgende contactpersoonsrecords voor die account in de context van de API-aanroep.
• Elke verwerking na de import, zoals triggers, mag gegevens alleen selectief verwerken.
• Als uw scenario grote gegevensvolumes omvat, volgt u de best practices uit deze Trailhead module Best Practices for Implementations with Large Data Volumes (Best practices voor implementaties met grote gegevensvolumes)
.

Foutafhandeling en herstel

Een strategie voor foutafhandeling en herstel moet worden beschouwd als onderdeel van de algemene oplossing. De beste methode is afhankelijk van de oplossing die u kiest.

Beveiligingsoverwegingen

Elke aanroep naar een extern systeem moet de vertrouwelijkheid, integriteit en beschikbaarheid van het verzoek waarborgen. Afhankelijk van de oplossing die u kiest, gelden verschillende beveiligingsoverwegingen.

• Een Lightning Platform-licentie met minstens "API Only"-gebruikersmachtigingen is vereist om geauthenticeerde API-toegang tot de Salesforce-API toe te staan.
• Het wordt aanbevolen standaardencryptie te gebruiken om wachtwoordtoegang veilig te houden.
• Gebruik het HTTPS-protocol bij het aanroepen van de Salesforce-API's. U kunt ook proxyverkeer naar de Salesforce-API's sturen via een on-premises beveiligingsoplossing, indien nodig.

Zie Beveiligingsoverwegingen.

Sidebars

Geen.

Timeliness

Tijdigheid is in dit patroon niet van betekenis. Er moet echter voor worden gezorgd dat de interfaces zo zijn ontworpen dat alle batchprocessen worden voltooid in een bepaald batchvenster.

Zoals bij alle batchgeoriënteerde bewerkingen wordt sterk aangeraden om de bron- en doelsystemen te isoleren tijdens batchverwerkingsvensters. Het laden van batches tijdens kantooruren kan leiden tot een meningsverschil, wat kan resulteren in het mislukken van de update van een gebruiker of, belangrijker nog, het mislukken van het laden van een batch (of het gedeeltelijk laden van een batch).

Voor organisaties die globale activiteiten hebben, is het mogelijk niet mogelijk om alle batchprocessen tegelijkertijd uit te voeren, omdat het systeem mogelijk continu in gebruik is. Gegevenssegmenteringstechnieken met behulp van recordtypen en andere filtercriteria kunnen in deze gevallen worden gebruikt om gegevenscontroverse te voorkomen.

Staatsbeheer

U kunt statusbeheer implementeren door middel van vervangende sleutels tussen de twee systemen. Als u elk type transactiebeheer binnen Salesforce-entiteiten nodig hebt, raden we u aan om het patroon Externe oproep te gebruiken met behulp van Apex.

Standaard optimistische recordvergrendeling vindt plaats op het platform en updates die worden aangebracht met behulp van de API, vereisen dat de gebruiker, die de record bewerkt, de record vernieuwt en de transactie start. In de context van de Salesforce-API verwijst optimistisch vergrendelen naar een proces waarbij:

• Salesforce houdt niet de status bij van een record die door een specifieke gebruiker wordt bewerkt.
• Bij het lezen wordt het tijdstip vastgelegd waarop de gegevens zijn geëxtraheerd.
• Als de gebruiker de record bijwerkt en opslaat, controleert Salesforce of een andere gebruiker de record tussentijds heeft bijgewerkt.
• Als de record is bijgewerkt, informeert het systeem de gebruiker dat er een update is uitgevoerd en moet de gebruiker de nieuwste versie van de record ophalen voordat hij of zij doorgaat met de updates.

Middlewaremogelijkheden

De meest effectieve externe technologieën die worden gebruikt om dit patroon te implementeren, zijn traditionele ETL-tools. Het is belangrijk dat de gekozen middlewaretools de Salesforce Bulk-API ondersteunen.

Het is nuttig, maar niet essentieel, dat de middlewaretools de functie getUpdated() ondersteunen. Deze functie komt het dichtst in de buurt van de standaard mogelijkheid voor gegevensvastlegging voor wijzigingen op het Salesforce-platform.

De volgende tabel markeert de gewenste eigenschappen van een middlewaresysteem dat aan dit patroon deelneemt.

Voorbeeld

Een nutsbedrijf gebruikt een op een mainframe gebaseerd batchproces dat prospects toewijst aan afzonderlijke verkoopvertegenwoordigers en teams. Deze informatie moet elke nacht in Salesforce worden geïmporteerd.

De klant heeft besloten gegevensvastlegging voor de brontabellen te implementeren met behulp van een commercieel beschikbare ETL-tool. De oplossing werkt als volgt:

• Een cronachtige planner voert een batchtaak uit die prospects toewijst aan gebruikers en teams.
• Nadat de batchtaak is uitgevoerd en de gegevens zijn bijgewerkt, herkent de ETL-tool deze wijzigingen met behulp van gegevensvastlegging. De ETL-tool verzamelt de wijzigingen uit de gegevensopslag.
• De ETL-connector gebruikt de Salesforce REST-API om de wijzigingen in Salesforce te laden.

Context

U gebruikt Salesforce om leads bij te houden, uw pijplijn te beheren, opportunities te maken en orderdetails vast te leggen die leads converteren naar klanten. Het Salesforce-systeem maakt de orders intern en pusht die gegevens vervolgens naar het externe factureringssysteem voor levering en activering. Factuurorders worden beheerd door een extern (extern) systeem. Dat externe systeem moet de orderstatus in Salesforce bijwerken wanneer de order of factureringsentiteit in de status van het factureringssysteem verandert.

Probleem

Hoe kan een extern systeem verbinding maken met en authenticeren met Salesforce om Salesforce te informeren over externe events, records te maken en bestaande records bij te werken?

Krachten

Er zijn verschillende krachten om rekening mee te houden bij het toepassen van oplossingen op basis van dit patroon:

• Is het doel van het externe gesprek met Salesforce om Salesforce te informeren over een event dat extern heeft plaatsgevonden met behulp van een eventgestuurde architectuur? Of is het doel het uitvoeren van CRUD-bewerkingen op specifieke records? Als u een eventgestuurde architectuur gebruikt, wordt de eventproducer (het externe proces) losgekoppeld van de Salesforce-eventconsument.
• Vereist de aanroep naar Salesforce dat het externe proces wacht op een reactie voordat de verwerking wordt voortgezet? Externe aanroepen naar Salesforce zijn altijd synchroon verzoek-antwoord, hoewel het externe proces de respons kan negeren als het niet nodig is om een asynchroon gesprek te simuleren.
• Werkt elke transactie met één Salesforce-object of meerdere gerelateerde objecten?
• Wat is de indeling van het bericht (bijvoorbeeld SOAP of REST, of beide via HTTP)?
• Is de berichtgrootte relatief klein of groot?
• Als het externe systeem SOAP-geschikt is, kan het externe systeem dan deelnemen aan een contract-first benadering, waarbij Salesforce het contract dicteert? Dit is verplicht wanneer onze SOAP API wordt gebruikt, waarvoor een vooraf gedefinieerde WSDL wordt geleverd.
• Is transactieverwerking vereist?
• Wat is de mate waarin u tolerant bent voor aanpassing in Salesforce?

Oplossing

Deze tabel bevat diverse oplossingen voor dit integratieprobleem.

Sketch

De volgende diagrammen illustreren de volgorde van events wanneer u dit patroon implementeert met behulp van de REST-API voor kennisgevingen van externe events of de SOAP-API voor het uitvoeren van een query op een Salesforce-object. De volgorde van events is dezelfde bij gebruik van de REST-API.

Extern systeem voert query's uit op Salesforce via de SOAP-API

Extern systeem Salesforce informeren met events via REST-API

Resultaten

In een eventgestuurde architectuur roept het externe systeem Salesforce aan met behulp van de SOAP-API, REST-API of Bulk-API 2.0 om een event te publiceren naar de Salesforce-eventbus. Het publiceren van een event informeert alle abonnees. Eventabonnees kunnen zich op het Salesforce Platform bevinden, zoals Stromen, of Lightning Components, Apex triggers. Eventabonnees kunnen ook extern zijn voor het Salesforce Platform, zoals CometD-abonnees.

Wanneer u rechtstreeks met Salesforce-objecten werkt, bieden de oplossingen die aan dit patroon zijn gerelateerd, de volgende mogelijkheden:

• Het externe systeem roept de Salesforce-API's aan om een query uit te voeren op de database en bewerkingen met één object uit te voeren (maken, bijwerken, verwijderen, enzovoort).
• Het externe systeem om de samengestelde Salesforce REST API-resources aan te roepen om een reeks objectbewerkingen uit te voeren.
• Extern systeem voor het aanroepen van op maat gemaakte Salesforce-API's (services) die transactiebewerkingen voor meerdere objecten en aangepaste pre-/postverwerkingslogica kunnen ondersteunen.

Aanroepmechanismen

Het aanroepmechanisme is afhankelijk van de oplossing die is gekozen om dit patroon te implementeren.

Foutafhandeling en herstel

Een strategie voor foutafhandeling en herstel moet worden beschouwd als onderdeel van de algemene oplossing.

• Afhandeling van fouten: alle externe aanroepmethoden, standaard- of aangepaste API's, vereisen dat het externe systeem eventuele daaropvolgende fouten, zoals time-outs en het beheer van nieuwe pogingen, afhandelt. Middleware kan worden gebruikt om de logica voor foutafhandeling en herstel te bieden.
• Herstel — Er moet een aangepast mechanisme voor opnieuw proberen worden gemaakt als dit vereist is vanwege de kwaliteit van de service. In dit geval is het belangrijk om te zorgen voor idempotente ontwerpkenmerken. Platform-event laat abonnees de replay-ID gebruiken om berichten op te halen binnen een bepaald tijdsbestek nadat die berichten zijn gepubliceerd.

Overwegingen bij impotent ontwerp

Idempotente mogelijkheden garanderen dat herhaalde aanroepen veilig zijn en geen negatief effect hebben. Als idempotentie niet is geïmplementeerd, kunnen herhaalde aanroepen van hetzelfde bericht verschillende resultaten hebben, wat mogelijk kan leiden tot problemen met de gegevensintegriteit, bijvoorbeeld het maken van duplicaatrecords, duplicaatverwerking van transacties, enzovoort.

Het externe systeem moet meerdere (duplicaat)aanroepen beheren, in het geval van fouten of time-outs, om dubbele invoegingen en redundante updates te voorkomen (met name als triggers verderop in de stroom en werkstroomregels worden geactiveerd). Hoewel het mogelijk is om bepaalde van deze situaties binnen Salesforce te beheren (met name in het geval van aangepaste SOAP- en REST-services), raden we aan dat het externe systeem (of middleware) foutafhandeling en idempotent ontwerp beheert.

Beveiligingsoverwegingen

Er gelden verschillende beveiligingsoverwegingen, afhankelijk van de gekozen patroonoplossing. In alle gevallen gebruikt het platform de toegangsrechten van de ingelogde gebruiker (bijvoorbeeld profielinstellingen, regels voor delen, machtigingensets, enzovoort). Daarnaast kunnen IP-beperkingen voor profielen worden gebruikt om toegang tot de API voor een specifiek IP-adresbereik te beperken.

Zie Beveiligingsoverwegingen.

Sidebars

Geen.

Timeliness

SOAP API en Apex webservice API zijn synchroon. De volgende time-outs zijn van toepassing:

• Sessietime-out: de sessie treedt op als er geen activiteit is op basis van de sessietime-outinstelling van de Salesforce-organisatie.
• Querytime-out: elke SOQL-query heeft een individuele time-outlimiet van 120 seconden.

Gegevensvolumes

Overwegingen bij gegevensvolumes zijn afhankelijk van welke oplossing en welk communicatietype u kiest.

Ondersteuning van eindpuntmogelijkheden en standaarden

De mogelijkheden en standaardondersteuning voor het eindpunt zijn afhankelijk van de oplossing die u kiest.

Staatsbeheer

Bij het integreren van systemen zijn sleutels belangrijk voor het continu bijhouden van de status, bijvoorbeeld als een record wordt gemaakt in het externe systeem, om doorlopende updates van die record te ondersteunen. Er zijn twee opties:

• Salesforce slaat de primaire of unieke vervangende sleutel van het externe systeem voor de externe record op.
• Het externe systeem slaat de unieke Salesforce-record-ID of een andere unieke vervangende sleutel op. Er zijn specifieke overwegingen bij het afhandelen van integratiesleutels in dit synchrone patroon.

Complexe integratiescenario's

Elke oplossing in dit patroon heeft verschillende overwegingen bij het afhandelen van complexe integratiescenario's zoals transformatie en procescombinatie.

Gouverneurlimieten

Vanwege het multitenant karakter van het Salesforce-platform zijn er limieten bij het gebruik van de API's.

Betrouwbaar berichtenverkeer

Betrouwbaar berichtenverkeer probeert het probleem op te lossen van het garanderen van de levering van een bericht aan een extern systeem, waarbij de afzonderlijke componenten zelf mogelijk onbetrouwbaar zijn. De Salesforce SOAP-API en REST-API zijn synchroon en bieden niet per se expliciete ondersteuning voor betrouwbare berichtenverkeersprotocollen (bijvoorbeeld WS-ReliableMessaging).

We raden aan dat het externe systeem een betrouwbaar berichtenverkeerssysteem implementeert om ervoor te zorgen dat fout- en time-outscenario's met succes worden beheerd. Het publiceren van platformevents vanuit externe systemen is afhankelijk van Salesforce-API's, waardoor dezelfde overwegingen voor de SOAP-API en de REST-API van toepassing zijn.

Middlewaremogelijkheden

Deze tabel markeert de gewenste eigenschappen van een middlewaresysteem dat deelneemt aan dit patroon:

Voorbeeld

Een bedrijf dat afdrukbenodigdheden en -services levert, gebruikt Salesforce als front-end om printerbenodigdheden en -orders te maken en te beheren. Salesforce-activumrecords die printers vertegenwoordigen, worden periodiek bijgewerkt met afdrukgebruiksstatistieken (inktstatus, papierniveau) vanuit het on-premises Printer Management System (PMS), dat printers op clientsites regelmatig controleert. Bij het bereiken van een ingestelde drempelwaarde (bijvoorbeeld een lage inktstatus of een laag/leeg papierniveau van minder dan 30%) worden meerdere apps/processen (variabelen) die geïnteresseerd zijn in de event geïnformeerd, worden e-mail- of Chatter waarschuwingen verzonden en wordt er een orderrecord gemaakt. In het PMS wordt de Salesforce-ID opgeslagen (Salesforce is de hoofdrecord van het activum).

De volgende beperkingen zijn van toepassing:

• Het PMS kan deelnemen aan een contract-first integratie, waarbij Salesforce het contract levert en het PMS optreedt als een klant (consument) van de Salesforce-service (gedefinieerd via de Enterprise of Partner WSDL).
• Salesforce mag geen aangepaste ontwikkeling bevatten.

Dit voorbeeld kan het best worden geïmplementeerd met behulp van de Salesforce SOAP-API of REST-API voor het publiceren van events en declaratieve automatisering (stroom) in Salesforce. De primaire reden voor het gebruik van platformevents is het variabele en niet-eindige aantal abonnees. Voor eenvoudige updates van een eindige lijst van records zoals orders gebruikt u echter SOAP of de REST-API om de records bij te werken.

In Salesforce:

• Definieer een platformevent in Salesforce om de kennisgevingsgegevens te bevatten die afkomstig zijn uit het PMS.
• Maak een stroom die wordt geactiveerd door de kennisgeving van de printerevent. Het proces werkt het printeractivum bij en maakt een order (met behulp van een automatisch gestarte stroom).
• Download de Enterprise of Partner WSDL en lever deze aan het externe systeem aan.

In het externe systeem:

• Maak een client-stub vanuit de Enterprise of Partner WSDL.
• Authenticeer bij Salesforce (via OAuth-webserver of bearertokenstroom) met behulp van de inloggegevens van de integratiegebruiker.
• Bij de event voor de printerstatus roept het PMS de API aan om de event voor het printerstatusplatform (met statistieken over printergebruik) te maken. De Salesforce-eventbus informeert de stroomabonnee en alle andere abonnees.

Wanneer u platformevents gebruikt, kunt u met de eventbus events gedurende 72 uur opnieuw afspelen voor platformevents met groot volume. Het publiceren van die events met behulp van een middleware-oplossing kan helpen bij het opnemen van foutafhandeling aan de publicatiezijde. U kunt foutafhandeling echter implementeren aan de abonnementszijde als u meer betrouwbaarheid nodig hebt.

Dit voorbeeld toont het volgende:

• Implementatie van een Salesforce-synchrone API-client (consument).
• Een callback naar Salesforce om een platformevent te publiceren (uitgelijnd met eerder behandelde platformeventpatronen voor verzoeken/antwoorden).

Context

U gebruikt Salesforce voor het beheer van klantcases. Een medewerker van de klantenservice is aan de telefoon met een klant die aan een case werkt. De klant doet een betaling en de klantenservicemedewerker moet een real-time update binnen de Salesforce-toepassing zien vanuit de toepassing voor betalingsverwerking, die aangeeft dat de klant het openstaande bedrag van de order met succes heeft betaald.

Probleem

Wanneer een event zich voordoet in Salesforce, hoe kan de gebruiker dan worden geïnformeerd in de Salesforce-gebruikersinterface zonder zijn of haar scherm te hoeven vernieuwen en potentieel werk te verliezen?

Krachten

Er zijn verschillende krachten om rekening mee te houden bij het toepassen van oplossingen op basis van dit patroon:

• Moeten de gegevens waarop wordt gehandeld, worden opgeslagen in Salesforce?
• Kan er een aangepaste gebruikersinterfacelaag worden samengesteld voor het weergeven van deze gegevens?
• Krijgt de gebruiker toegang voor het aanroepen van de aangepaste gebruikersinterface?

Oplossing

De aanbevolen oplossing voor dit integratieprobleem is het gebruik van platformevents die vrijwel realtime eventing in Salesforce garanderen. Platform-events bieden een gestructureerde, flexibele payload onafhankelijk van Salesforce-objecten. Het garandeert ook duurzame onderwerpen met een herhalingsvenster van 72 uur. Dit zorgt ervoor dat events beschikbaar zijn, zelfs als een offline consument later beschikbaar komt. Deze oplossing bestaat uit de volgende componenten :

• Apex Trigger of Stromen met een logica om een platformevent over een onderwerp te publiceren
• Een onderwerp waarmee u een event kunt publiceren vanuit Apex Trigger of Flow
• Een op JavaScript gebaseerde implementatie van het protocol van Bayeux (momenteel CometD ) die kan worden gebruikt door de gebruikersinterface
• Een Lightning component
• Een JavaScript-bibliotheek die is opgenomen als een statische resource

Sketch

Het volgende diagram illustreert hoe de Streaming-API kan worden geïmplementeerd om kennisgevingen naar de Salesforce-gebruikersinterface te streamen. Deze kennisgevingen worden geactiveerd door recordwijzigingen in Salesforce.

UI-update in Salesforce geactiveerd door een gegevenswijziging

Resultaten

Voordelen

De toepassing van de oplossing gerelateerd aan dit patroon heeft de volgende voordelen:

• Elimineert de noodzaak voor het schrijven van aangepaste pollingmechanismen
• Elimineert de noodzaak van een door de gebruiker geïnitieerde feedbacklus

Niet-ondersteunde vereisten

De oplossing heeft de volgende beperkingen:

• Levering van kennisgevingen is niet gegarandeerd.
• De volgorde van kennisgevingen is niet gegarandeerd.
• Kennisgevingen worden niet gegenereerd vanuit recordwijzigingen die zijn aangebracht door de Bulk-API.

Beveiligingsoverwegingen

Standaardbeveiliging op Salesforce-organisatieniveau wordt nageleefd. U wordt aangeraden om het HTTPS-protocol te gebruiken om verbinding te maken met de Streaming-API. Zie Beveiligingsoverwegingen

Sidebars

De optimale oplossing bestaat uit het maken van een aangepaste gebruikersinterface in Salesforce. Het is noodzakelijk dat u rekening houdt met een geschikte gebruikersinterfacecontainer die kan worden gebruikt voor het weergeven van de aangepaste gebruikersinterface. Ondersteunde browsers worden vermeld in de Streaming API Developer Guide

Voorbeeld

Een telecommunicatiebedrijf gebruikt Salesforce voor het beheer van klantcases. De klantenservicemanagers willen een kennisgeving ontvangen wanneer een case met succes wordt gesloten door een van hun medewerkers.

De klant moet de in dit patroon voorgeschreven oplossing implementeren door:

• Maak een Apex Trigger PushTopic die een platformevent verzendt wanneer een case wordt opgeslagen met de status "Gesloten" en de oplossing "Geslaagd".
• Maak een aangepaste gebruikersinterface die beschikbaar is voor klantenservicemanagers. Deze gebruikersinterface abonneert zich op de eventbus om platformevents te verbruiken.
• Implementeer logica in de aangepaste gebruikersinterface die waarschuwingen toont die zijn gegenereerd door de medewerkers van de klantenservice van die manager.

Context

U gebruikt Salesforce om leads bij te houden, uw pijplijn te beheren, opportunities te maken en orderdetails vast te leggen die leads converteren naar klanten. Salesforce is echter niet het systeem dat orders bevat of verwerkt. Orders worden beheerd door een extern (remote) systeem. Verkoopvertegenwoordigers willen echter real-time ordergegevens in Salesforce weergeven en bijwerken zonder het externe systeem te hoeven leren of gebruiken.

Probleem

Hoe kunt u in Salesforce gegevens weergeven, zoeken en wijzigen die zijn opgeslagen buiten Salesforce, zonder de gegevens van het externe systeem naar Salesforce te verplaatsen?

Krachten

Er zijn verschillende krachten om rekening mee te houden bij het toepassen van oplossingen op basis van dit patroon:

• Wilt u een declaratieve/point-and-click uitgaande integratie of UI-mashup samenstellen in Salesforce?
• Hebt u een grote hoeveelheid gegevens die u niet naar uw Salesforce-organisatie wilt kopiëren?
• Moet u tegelijkertijd toegang hebben tot kleine hoeveelheden externe systeemgegevens?
• Hebt u realtime toegang nodig tot de nieuwste gegevens?
• Slaat u uw gegevens op in de cloud of in een back-officesysteem, maar wilt u die gegevens weergeven of verwerken in uw Salesforce-organisatie?
• Hebt u problemen met de gegevensverblijfplaats bij het opslaan van bepaalde typen gegevens in Salesforce?

Oplossing

De volgende tabel bevat diverse oplossingen voor dit integratieprobleem.

Sketch

Het volgende diagram illustreert hoe u Salesforce Connect kunt gebruiken om gegevens op te halen uit een extern systeem met behulp van een OData adapter.

In dit scenario:

1. De browser voert een AJAX-aanroep uit die op zijn beurt een actie uitvoert op de overeenkomende adapter voor het externe object.
2. De adapter vertaalt de actie naar een OData aanvraag en doet een HTTP GET aanvraag naar het externe systeem via de lagen Integration en Services.
3. Het externe systeem retourneert een JSON-respons naar Salesforce via de lagen Integratie en Services.
4. De respons wordt vanuit Odata vertaald naar een extern object en vervolgens terug gepresenteerd aan de browser.

Resultaten

De toepassing van de oplossingen die zijn gerelateerd aan dit patroon, maakt door de gebruikersinterface geïnitieerde aanroepen mogelijk waarin het resultaat van de transactie kan worden weergegeven aan de eindgebruiker.

Aanroepmechanismen

Het aanroepmechanisme is afhankelijk van de oplossing die is gekozen om dit patroon te implementeren.

Foutafhandeling

Het is belangrijk om foutafhandeling op te nemen als onderdeel van de totaaloplossing. Wanneer een fout optreedt (uitzonderingen of foutcodes worden geretourneerd aan de beller), beheert de beller de foutafhandeling. De Salesforce Connect Validator is een gratis tool om enkele veel voorkomende query's uit te voeren en fouttypen en oorzaken van fouten op te merken.

Voordelen

Enkele voordelen van het gebruik van een Salesforce Connect oplossing zijn:

• Deze oplossing verbruikt geen gegevensopslag in Salesforce.
• Gebruikers hoeven zich geen zorgen te maken over het regelmatig synchroniseren van gegevens tussen het externe systeem en Salesforce.
• Een declaratieve set-up die snel kan worden bereikt met OData, of een inter-organisatorische adapter, of met behulp van minimale code met een aangepaste Apex adapter.
• Gebruikers hebben toegang tot externe gegevens met vrijwel dezelfde functionaliteit als aangepaste objecten in de vorm van externe objecten.
• Mogelijkheid om een gebundelde zoekopdracht uit te voeren in het verbonden externe systeem met behulp van globaal zoeken.
• Mogelijkheid om rapporten uit te voeren die toegang hebben tot externe gegevens vanuit cloud- en on-premises bronnen. Raadpleeg onderstaande overwegingen bij rapportage.

Salesforce Connect overwegingen

De Salesforce Connect oplossing heeft de volgende overwegingen:

• Externe objecten werken als aangepaste objecten, maar sommige voorzieningen zijn niet beschikbaar voor externe objecten. Zie Overwegingen bij Salesforce-compatibiliteit voor Salesforce Connect voor meer informatie.
• Externe objecten kunnen van invloed zijn op rapportprestaties. Zie Rapportoverwegingen voor Salesforce Connect voor meer informatie.
• Zie Overwegingen bij Salesforce Connect—Alle adapters voor aanvullende overwegingen bij het gebruik van Salesforce Connect adapters.
• Als u overweegt om een inter-organisatorische adapter te gebruiken, raadpleegt u Overwegingen bij Salesforce Connect: inter-organisatorische adapter.
• Zie Overwegingen bij Salesforce Connect: OData 2.0- en 4.0-adapters als u overweegt om een OData adapter te gebruiken.
• Als u overweegt om een aangepaste Apex adapter te gebruiken, raadpleegt u Overwegingen bij Salesforce Connect: aangepaste adapter.

Beveiligingsoverwegingen

Oplossingen voor dit patroon moeten voldoen aan standaardbeveiliging op Salesforce-organisatieniveau. U wordt aangeraden om het HTTPS-protocol te gebruiken om verbinding te maken met elk extern systeem. Zie Beveiligingsoverwegingen voor meer informatie.

Als u een OData connector gebruikt, zorg er dan voor dat u de speciale werkingen, beperkingen en aanbevelingen voor Cross-Site Request Forgery (CSRF) voor externe Odata gegevensbronnen begrijpt. Zie CSRF-overwegingen voor Salesforce Connect — OData 2.0- en 4.0-adapters voor meer informatie.

Sidebars

Geen.

Timeliness

Tijdigheid is in dit patroon van groot belang. Houd rekening met het volgende:

• Het verzoek wordt doorgaans aangeroepen vanuit de gebruikersinterface, dus het proces mag de gebruiker niet in de wachtstand houden.
• Afhankelijk van de beschikbaarheid van en de verbinding met het externe systeem kan het ophalen van externe gegevens veel tijd in beslag nemen. Salesforce heeft een configureerbare maximale time-outwaarde van 120 seconden om te wachten op een reactie van het externe systeem.
• Voltooiing van het externe proces moet tijdig en binnen de Salesforce-time-outlimiet en binnen de verwachtingen van de gebruiker worden uitgevoerd.

Gegevensvolumes

Dit patroon wordt voornamelijk gebruikt voor real-time activiteiten met een klein volume, vanwege de kleine time-outwaarden en de maximale grootte van het verzoek of de reactie voor de Apex call-oplossing. Gebruik dit patroon niet in batchverwerkingsactiviteiten waarbij de gegevenspayload is opgenomen in het bericht.

Ondersteuning van eindpuntmogelijkheden en standaarden

De mogelijkheden en standaardondersteuning voor het eindpunt zijn afhankelijk van de oplossing die u kiest.

Staatsbeheer

Bij het integreren van systemen zijn sleutels belangrijk voor continue status bijhouden. Als een record bijvoorbeeld wordt gemaakt op het externe systeem, heeft de record doorgaans een soort identificerende sleutel nodig om doorlopende updates te ondersteunen. Er zijn twee opties voor het opslaan van sleutels.

• Salesforce slaat de primaire of unieke vervangende sleutel voor de externe record op.
• Het externe systeem slaat de unieke Salesforce-record-ID of een andere unieke vervangende sleutel op. Er zijn specifieke overwegingen bij het afhandelen van integratiesleutels in dit synchrone patroon.

Complexe integraties

In bepaalde gevallen kan de oplossing die door dit patroon wordt voorgeschreven, de implementatie van een complex integratiescenario vereisen. Deze scenario's worden vaak opgelost met behulp van middleware.

• Aggregatie van gesprekken en de resultaten ervan over gesprekken naar meerdere systemen
• Transformatie van zowel inkomende als uitgaande berichten
• Transactionele integriteit behouden voor alle aanroepen naar meerdere systemen
• Andere procescombinatieactiviteiten tussen Salesforce en het externe systeem

Beheerslimieten

Er gelden verschillende limieten voor verschillende adapters. Zie Algemene limieten voor Salesforce Connect voor meer informatie.

Middlewaremogelijkheden

De volgende tabel markeert de gewenste eigenschappen van een middlewaresysteem dat aan dit patroon deelneemt.

Externe objectrelaties

Externe objecten ondersteunen standaard opzoekrelaties, die de Salesforce-record-ID van 18 tekens gebruiken om gerelateerde records te koppelen. Gegevens die buiten uw Salesforce-organisatie zijn opgeslagen, bevatten echter vaak niet die record-ID's. Daarom zijn er twee speciale typen opzoekrelaties beschikbaar voor externe objecten: externe opzoekopdrachten en indirecte opzoekopdrachten.

Deze tabel geeft een overzicht van de typen relaties die beschikbaar zijn voor externe objecten.

Overwegingen bij groot gegevensvolume voor Salesforce Connect: OData 2.0- en 4.0-adapters

Als uw organisatie scorelimieten bereikt bij toegang tot externe objecten, kunt u overwegen om de optie Groot gegevensvolume te selecteren voor de gekoppelde externe gegevensbronnen. Hiermee worden de meeste scorelimieten omzeild, maar gelden enkele speciale werkingen en beperkingen. Zie Overwegingen bij groot gegevensvolume voor Salesforce Connect voor meer informatie.

Clientgestuurde en servergestuurde paginering voor Salesforce Connect: OData 2.0- en 4.0-adapters

Het komt vaak voor dat Salesforce Connect's op externe gegevens een grote resultatenset hebben die is opgesplitst in kleinere batches of pagina's. U bepaalt of de werking van de paginering wordt bepaald door het externe systeem (servergestuurd) of door de OData 2.0- of 4.0-adapter voor Salesforce Connect (clientgestuurd). Het veld Servergestuurde paginering voor de externe gegevensbron geeft aan of clientgestuurde of servergestuurde paginering moet worden gebruikt. Als u servergestuurde paginering inschakelt voor een externe gegevensbron, negeert Salesforce de aangevraagde paginagrootten, inclusief de standaard batchgrootte van queryMore() van 500 rijen. De pagina's die door het externe systeem worden geretourneerd, bepalen de batches, maar elke pagina mag niet groter zijn dan 2000 rijen. De limieten voor de OData adapters voor Salesforce Connect zijn echter nog steeds van toepassing.

Voorbeeld

Een productiebedrijf gebruikt Salesforce voor het beheer van klantcases. De klantenserviceagenten willen toegang tot de real-time orderinformatie vanuit het back-office ERP-systeem om een 360-weergave van de klant te krijgen zonder dat ze rapporten handmatig in ERP hoeven uit te voeren.

Als u de oplossing implementeert die door dit patroon wordt voorgeschreven, moet u:

• Configureer uw externe gegevensbron met een OData eindpunt. Uw externe toepassing kan native ondersteuning voor Odata bevatten. Voor andere toepassingen werken grote integratieleveranciers zoals Dell Boomi, Informatica, Jitterbit, MuleSoft en Progress Software samen met Salesforce voor het samenstellen van adapters.
• Richt Salesforce Connect naar het OData eindpunt, rechtstreeks of via een middleware-oplossing.
• Synchroniseer uw externe databasetabellen met externe objecten in Salesforce. Wanneer een gebruiker een pagina opent met gegevens uit deze externe objecten, voert Salesforce Connect realtime aanroepen uit naar uw back-endtoepassingen.

Ontwikkelaarsdocumentatie

• Salesforce Help: Integratiegebruikers alleen API-toegang geven

• SOAP API Developer Guide

• REST API Developer Guide

• Streaming API Developer Guide

• Bulk API 2.0 en Bulk API Developer Guide

• Apex Developer Guide

• SOQL en SOSL Reference

• Snelle naslag voor Salesforce Developer Limits and Allocations (Limieten en toewijzingen voor Salesforce-ontwikkelaars)

• Ontwikkelaarshandleiding voor Platform Events

• Apex Developer Guide: Salesforce Connect

Trailhead

• Grote gegevensvolumes

• Basisprincipes van Platform-events

• Basisprincipes van gegevensvastlegging wijzigen

• Snelstart: Salesforce Connect

Om effectieve leden van het ondernemingsportfolio te zijn, moeten alle toepassingen worden gemaakt en geïntegreerd met relevante beveiligingsmechanismen. Moderne IT-strategieën maken gebruik van een combinatie van on-premises en cloudgebaseerde services.

Hoewel het integreren van cloud-naar-cloud-services zich doorgaans richt op webservices en gekoppelde autorisatie, leidt het verbinden van on-premises en cloudservices vaak tot meer complexiteit. Deze sectie beschrijft beveiligingstools, -technieken en Salesforce-specifieke overwegingen.

Omgekeerde proxyserver

Een reverse proxy is een server die zich voor webservers bevindt en clientverzoeken (bijvoorbeeld webbrowser) doorstuurt naar die webservers. Reverse proxy's worden doorgaans geïmplementeerd om de beveiliging, prestaties en betrouwbaarheid te verbeteren.

Het is een type proxyserver dat namens een client resources ophaalt van een of meer servers. Deze resources worden vervolgens geretourneerd naar de client alsof ze afkomstig zijn van de proxyserver zelf. In tegenstelling tot een voorwaartse proxy, die een tussenpersoon is voor de gekoppelde clients om contact te maken met een server, is een reverse proxy een tussenpersoon voor de gekoppelde servers om contact te maken met een willekeurige client.

In Salesforce-implementaties wordt een dergelijke service doorgaans geleverd via een extern gatewayproduct. Open source-opties zoals Apache HTTP, lighttpd en nginix kunnen bijvoorbeeld worden gebruikt. Commerciële producten omvatten IBM WebSeal en Computer Associates SiteMinder. Deze producten kunnen gemakkelijk worden geconfigureerd om namens de interne verzoeker proxy te gebruiken en alle uitgaande Salesforce-verzoeken te beheren.

Encryptie

Sommige ondernemingen vereisen dat geselecteerde transacties of gegevensvelden worden versleuteld tussen een combinatie van on-premises en cloudgebaseerde toepassingen. Als uw organisatie moet voldoen aan aanvullende nalevingsvereisten, kunt u alternatieven implementeren, waaronder:

• On-premises commerciële gatewayservices voor encryptie, inclusief Salesforce's eigen, CipherCloud, IBM DataPower, Computer Associates. Voor elke oplossing wordt de encryptie-engine of gateway aangeroepen op de transactiegrens door het verzenden en ontvangen van een versleutelde payload of bij het versleutelen of ontsleutelen van specifieke gegevensvelden voordat het HTTP(S)-verzoek wordt uitgevoerd.

• Op de cloud gebaseerde opties, zoals Salesforce Shield Platform-encryptie. Shield Platform Encryption biedt uw gegevens een geheel nieuwe beveiligingslaag met behoud van kritieke platformfunctionaliteit. De gegevens die u selecteert, worden "at rest" versleuteld met behulp van een geavanceerd sleutelafleidingssysteem. U kunt uw gegevens veiliger dan ooit tevoren beschermen. Raadpleeg de online Help van Salesforce voor meer informatie.

Gespecialiseerde WS-* Protocolondersteuning

Om te voldoen aan de vereisten van beveiligingsprotocollen (zoals WS-*), raden we deze alternatieven aan.

• Beveiliging/XML-gateway: injecteer WS-Security-inloggegevens (IBM WebSeal of Datapower, Layer7, TIBCO, enzovoort) in de transactiestroom zelf. Deze benadering vereist geen wijzigingen in webservices op toepassingsniveau of webserviceaanroepen van Salesforce. U kunt deze benadering ook opnieuw gebruiken binnen de Salesforce-installatie. Het vereist echter extra ontwerp, configuratie, testen en onderhoud om de juiste WS-Security-injectie in de bestaande beveiligingsgatewaybenadering te beheren.

• Encryptie op transportniveau: versleutel het communicatiekanaal met behulp van SSL- en IP-beperkingen in twee richtingen. Hoewel deze benadering het WS-*-protocol op zichzelf niet rechtstreeks implementeert, beveiligt het het communicatiekanaal tussen de on-premises toepassingen en Salesforce zonder een gebruikersnaam en wachtwoord door te geven. Er zijn ook geen wijzigingen in door Salesforce gegenereerde klassen vereist. Er zijn echter mogelijk enkele on-premises webservicesaanpassingen vereist (in de toepassing zelf of in de middleware-/ESB-laag).

• Aangepaste Salesforce-ontwikkeling: voeg WS-Security-headers toe aan het uitgaande SOAP-verzoek via het hulpprogramma WSDL2Apex. Dit genereert een Java-achtige Apex klasse op basis van het WSDL-bestand dat wordt gebruikt om de interne service aan te roepen. Hoewel deze benadering geen wijzigingen in back-end webservices of aanvullende componenten in de DMZ vereist, vereist deze wel:

  • Meer inspanningen voor samenstellen en testen
  • Een relatief complex en handmatig proces voor het handmatig coderen van de WS-Security kenmerken (inclusief XML serialisering binnen de Apex code)
  • Een hogere onderhoudsinspanning op lange termijn

Opmerking: De laatste optie wordt niet aanbevolen vanwege de complexiteit ervan en het risico dat dergelijke integraties periodieke beoordelingen vereisen op basis van regelmatige updates van Salesforce.

Andere beveiligingsoverwegingen

• Benoemde gegevens: Bedoeld om geauthenticeerde API-aanroepen naar externe systemen te beveiligen en te vereenvoudigen, geeft een benoemd gegeven de URL van een eindpunt van een aanroep en de vereiste authenticatieparameters ervan in één definitie op. Als u uw Apex code wilt stroomlijnen en de set-up van geauthenticeerde aanroepen wilt vereenvoudigen, geeft u een benoemd gegeven op als het eindpunt van de aanroep. Voor meer details zie hier.

• OAUTH 2.0: OAuth 2.0 is een industriestandaard autorisatieframework waarmee een gebruiker beperkte toegang tot zijn beschermde resources kan verlenen aan een externe toepassing zonder zijn of haar inloggegevens (zoals wachtwoorden) te delen. In plaats van een directe wachtwoorduitwisseling keurt de gebruiker een aanvraag voor een toegangstoken goed, die de toepassing vervolgens gebruikt om toegang te krijgen tot de gegevens van de gebruiker vanaf een resourceserver. Dit proces scheidt de clienttoepassing van de identiteit en het wachtwoord van de gebruiker, waardoor de beveiliging wordt verbeterd door een tijdelijke, bereikspecifieke "sleutel" te bieden voor toegang tot resources. Voor meer informatie zie hier.

• Privé verbinden: Wanneer u uw Salesforce-organisatie integreert met toepassingen die worden gehost op cloudservices van derden, is het essentieel om HTTP/s-verkeer veilig te kunnen verzenden en ontvangen. Met Privé verbinden vergroot u de beveiliging van uw AWS-integraties (Amazon Web Services) door een volledig beheerde netwerkverbinding in te stellen tussen uw Salesforce-organisatie en uw AWS Virtual Private Cloud (VPC). Routeer vervolgens uw cross-cloud verkeer via de verbinding in plaats van via het openbare internet om blootstelling aan externe beveiligingsrisico's te verminderen. Private Connect is beschikbaar in samenwerking met AWS via een voorziening met de naam AWS PrivateLink. Privé verbinden is tweerichtingsverkeer: u kunt zowel inkomend als uitgaand verkeer initiëren. Met inkomende verbindingen kunt u verkeer naar Salesforce verzenden met behulp van de standaard-API's. En met uitgaande verbindingen kunt u verkeer uit Salesforce sturen via voorzieningen zoals Apex aanroepen, Externe services en Externe objecten. Voor meer informatie over VPC kunt u hier terecht.

Met de Salesforce Event Bus met Platform Events, Change Gegevensvastlegging (CDC) en Pub /Sub-API kunnen ondernemingen Event Drived Style Architectures (EDA's) maken.

Een EDA ontkoppelt consumenten van eventberichten (abonnees) van producenten van eventberichten (uitgevers), waardoor schaalbaarheid en flexibiliteit mogelijk zijn. Specifieke patronen worden in dit document behandeld als onderdeel van de bestaande patroonstructuur die gerelateerde alternatieven of opties vergelijkt en contrasteert. Het verkrijgen van een holistisch inzicht in de eventgestuurde architectuur en de manier waarop patronen samenwerken, kan u echter helpen het juiste patroon voor uw behoeften te selecteren.

Khalid Mohammed is een vooraanstaand architect binnen de Professional Services van Salesforce. Sinds hij in 2015 bij Salesforce kwam werken, heeft hij zijn uitgebreide expertise in Enterprise Application and Architecture benut, die hij vóór zijn aanstelling bij Salesforce door talrijke klanttransformaties heeft gescherpt. Khalid leidt de Delivery Architecture Board en wordt ook erkend als gecertificeerd technisch architect.

Gulal Kumar is Software Engineering Architect bij Salesforce, met een focus op data- en integratiearchitectuur. Met meer dan 20 jaar ervaring in integratie en API's, moderniseringsprogramma's, beveiliging en AIML-initiatieven brengt hij een schat aan expertise met zich mee. Gulal zet zich in voor het bevorderen van bedrijfstransformatie-initiatieven, het verbeteren van beveiliging en veerkracht, het bevorderen van architectuurexcellentie en het leiden van AIML-initiatieven binnen verschillende domeinen.

Sushant is technisch architect bij Salesforce, gespecialiseerd in oplossingsarchitectuur en end-to-end levering van Salesforce-platforms. Met diepgaande expertise in platform-governance, toepassingsontwikkeling, integratie en DevOps heeft hij tal van transformatieprogramma's voor klanten in verschillende sectoren geleid. Sushant zet zich in voor het stimuleren van uitstekende levering en schaalbare architectonische resultaten.