Перейти к содержимому
SteveTechArcSteveTechArc Courses

Study guide

Это содержимое пока не доступно на вашем языке.

Study guide for chapter 7 of the Integration Architect course. Read the seven modules first, and try the Checkpoint 1 challenge; this page helps you check what stuck.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

This chapter carries the first objective of the biggest section on the exam, Design Integration Solutions (28%): choosing the integration pattern that meets the requirements. It also starts on the trade-offs of a proposed solution. If you study one chapter of Part 1 twice, make it this one: the six names are the words the exam is written in.

For the Exam

Section titled “For the Exam”

Tick them off as you go. Each one links to where it’s taught.

Patterns are a language (DES-1)

  • I know a pattern is a proven solution to a problem that keeps coming back, with a name, and that the names come from Enterprise Integration Patterns and Salesforce’s own Integration Patterns. (Proven Answers, With Names)
  • I can name the six and which way each goes: Request and Reply, Fire and Forget, UI Update Based on Data Changes and Data Virtualization from Salesforce; Remote Call-In and Batch Data Synchronization from another system. (The Six Names)
  • I know request and reply waits for the answer, and fire and forget doesn’t. (One Word, Three People)
  • I know fire and forget gets a receipt, not the outcome, so unless you’re waiting for the response, you can’t be synchronous. (A Receipt, Not the Outcome)
  • I keep the pattern apart from the mechanism: a platform event is one way to build fire and forget. (A Pattern Isn’t a Product)

Call-outs and call-ins (DES-1, supports REQ-1)

  • I know a call-out is Salesforce making the call (outbound), and a call-in is another system calling Salesforce (inbound). (Out and In)
  • I know a call-in is any external client, including your own middleware. (Who’s Calling In?)
  • I know the word decides the build: a call-out uses a named credential and counts against per-transaction limits; a call-in signs in through an External Client App as an integration user and spends the org’s shared daily allocation. (Why the Word Matters)

Salesforce’s six patterns (DES-1)

  • Request and Reply: Salesforce calls, waits and tracks state from the response; best fit today External Services, then the Flow HTTP callout, then Apex. (Request and Reply)
  • Fire and Forget: the remote process acknowledges and hands control back; best fit a platform event, with Pub/Sub API and Change Data Capture; outbound messages are legacy. (Fire and Forget)
  • Batch Data Synchronization: replication in bulk, in either direction; best fit an ETL tool with the Bulk API. (Batch Data Synchronization)
  • Remote Call-In: another system creates, reads, updates or deletes Salesforce data, through REST, Composite, GraphQL or Bulk API 2.0, or by publishing an event through Pub/Sub API. (Remote Call-In)
  • UI Update Based on Data Changes: the screen updates itself without polling; delivery and order of notifications aren’t guaranteed, and Bulk API changes don’t generate them. (UI Update Based on Data Changes)
  • Data Virtualization: external data read in real time and never stored, with Salesforce Connect’s external objects, or a component that calls out and throws the data away. (Data Virtualization)
  • I can weigh copy it (fast, reportable, as old as the last run) against see it (always current, a call every look, down when the other system is down). (Copy It, or See It)

Publish and subscribe (DES-1, DES-3)

  • I know publish and subscribe sends one event to every subscriber, each with its own copy, and that Salesforce does it with the event bus and platform events. (Publish and Subscribe)
  • I can compare one call each with one event for all, and know a new subscriber never changes the publisher. (One Call Each, or One Event for All)
  • I know each subscriber reads in its own time, within the 72 hours high-volume platform events are kept, and one away longer misses it. (Each in Its Own Time)
  • I know loose coupling, and that a queue, where each message goes to only one worker, isn’t the same thing. (They Never Have to Coordinate)
  • I can choose what goes in the event: everything, or a notice with the ID, where every call back is a call-in. (What Goes in the Event?)

Choosing a pattern (DES-1, DES-3)

  • I ask three questions: which way, what kind (process, data or virtual), and does anyone wait (synchronous or asynchronous). (Three Questions)
  • I can use Salesforce’s selection tables, and know Remote Call-In covers every inbound row except data and asynchronous, which is Batch Data Synchronization. (Salesforce’s Selection Tables)
  • I know the tables show batch only coming in, though it works in either direction. (Salesforce’s Selection Tables)
  • I know the pattern doesn’t finish the job; the numbers do. (Three Arrows, Three Patterns)
  • I can settle the close calls with one question each: does anyone wait; how many and how soon; do you need to keep the data; how many systems care. (When It’s Not Obvious)
  • I layer a batch under event-driven flows: batch is your backup plan. (Batch Is Your Backup Plan)

Several patterns, one solution (DES-1, DES-3)

  • I can count why connecting five orgs to each other with Salesforce Connect costs 20 connections and four related lists per object. (The Problem, Counted)
  • I build in order: set the baseline with a bulk load, keep it in sync with Change Data Capture, then turn on Salesforce Connect. (Five Orgs, One Database)
  • I can name four patterns in one design: a batch to seed it, events to keep it current, virtualization to see it, and a batch to catch what was missed. (Four Patterns, One Design)
  • I test a design by adding one more: the sixth org. (The Sixth Org)
  • I know Salesforce-to-Salesforce retires in Spring ‘27, and Salesforce names Salesforce Connect, Change Data Capture or Pub/Sub API as the replacements. (The Same Parts, Today)

Checkpoint 1 (DES-1, supports REQ-1)

  • I can name a pattern for every arrow on a landscape, and find an arrow that’s really two flows. (Every Arrow, Its Pattern)
  • I know where I’d layer a batch, and that in three years the patterns stay while the mechanisms change. (Where I’d Layer a Batch)

Beyond the Exam

Section titled “Beyond the Exam”

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

  • Say the pattern’s name, so the business, the architects and the team mean the same thing.
  • Ask: does anyone wait for the answer? It’s the question every pattern name answers.
  • Shape first, then pattern, then the mechanism. When someone starts with a tool, bring it back.
  • Copy it, or see it. Decide it out loud.
  • Write down who subscribes to what. The publisher can’t tell you.
  • Batch is your backup plan. On a good day it finds nothing to fix.
  • Ask what happens when it grows by one.
  • Know the legacy mechanisms by sight (outbound messages, the Streaming API) and which way the design is going.

Words to Know

Section titled “Words to Know”
TermIn one line
PatternA proven solution to a problem that keeps coming back, with a name
Call-out, call-inSalesforce makes the call (outbound); another system calls Salesforce (inbound)
Request and ReplySalesforce calls and waits for the answer
Fire and ForgetSalesforce sends, gets an acknowledgment, and moves on
Batch Data SynchronizationData kept in step in bulk, either direction
Remote Call-InAnother system creates, reads, updates or deletes Salesforce data
UI Update Based on Data ChangesThe screen updates itself when the data changes
Data VirtualizationExternal data read live, never stored in Salesforce
Process, data, virtualSalesforce’s three kinds of integration
Synchronous, asynchronousThe caller waits; the caller doesn’t
Publish and subscribeOne event, a copy to every subscriber
Loose couplingSystems joined by the event, not by each other
Claim checkA notice with an ID; the subscriber comes back for the rest
PollingAsking on a timer whether anything changed
Outbound messageThe legacy fire and forget: a SOAP message to one endpoint, retried until acknowledged

Check Yourself

Section titled “Check Yourself”

Short scenarios in the style of the course. Decide your answer before you open it.

1. A sales rep can't submit an order until the customer's balance comes back from the accounting system. The team proposes a platform event, "because events are fast." Which pattern is it?

Request and Reply. Someone waits for the answer, so it has to be synchronous. A platform event gives you a receipt that the event went on the bus, not the balance. Reread A Receipt, Not the Outcome.

2. Your middleware upserts partner manifests into Salesforce. Is that a call-out or a call-in?

A call-in. The middleware opens the connection, so it’s an external client: it signs in through an External Client App as its own integration user, and spends the org’s daily allocation. Reread Who’s Calling In?

3. A care agent needs to see deliveries from three years ago, kept in a data warehouse, on the case in front of them. Nobody wants to copy them back. Which pattern, and what's one mechanism?

Data Virtualization: read live, never stored. Salesforce Connect with an external object is one mechanism; a component that calls out and throws the data away is another. If the warehouse is down, so is that part of the page. Reread Data Virtualization.

4. A coordinator's screen must show a delivery as late without a refresh. Can you rely on it for the alert that must never be missed?

UI Update Based on Data Changes keeps the screen current, but Salesforce says delivery and order of notifications aren’t guaranteed, and Bulk API changes don’t generate them. Use it for the screen, and something you can prove for the alert. Reread UI Update Based on Data Changes.

5. Three systems need to know when a delivery is late, and next year a fourth will. Which design?

Publish and subscribe: one event, a copy for each subscriber, and the fourth subscribes without the publisher changing. Decide what goes in the event, and what each subscriber does if it’s away longer than the event is kept. Reread One Call Each, or One Event for All.

6. Finance sends new rates into Salesforce every night, in bulk. Nobody waits. Which pattern does the selection table give?

In, data, asynchronous: Batch Data Synchronization, the one inbound row that isn’t Remote Call-In. Reread Salesforce’s Selection Tables.

7. Status changes reach the warehouse through events. One night, the listener was down for four days. What should have been in the design?

A batch underneath: every night, read the day’s changes by date and fill any gap. Events give you the near real time; a batch gets a whole date range and puts you back in alignment. Reread Batch Is Your Backup Plan.

8. Six business lines, six orgs, and each wants to see the others' cases without copying them. What do you count, and what would you design?

Every org connected to every other is 30 connections and five related lists of cases on every account. A shared database in the middle needs six: bulk load to set the baseline, Change Data Capture to keep it in sync, then one Salesforce Connect connection per org, with each org’s own records filtered out. Reread Several Patterns, One Solution.

Explore

Section titled “Explore”