Ga naar inhoud
SteveTechArcSteveTechArc Courses

Patterns Are a Language

Deze inhoud is nog niet vertaald.

Module 1 of 7 in the chapter Integration Patterns, chapter 7 of the Integration Architect course. Each module stands on its own. Next: Call-Outs and Call-Ins

The question this module answers: Why do integration patterns have names, and what does a name give the people who use it?

Chapter 6 ended with the shape of every arrow: who starts it, where the data goes, how soon, how much, how sensitive. Now we give those shapes names.

A pattern is a way of grabbing a high-level concept and creating a language around it. Then that language can be given to the developer teams. I can say a few words to a development team, and they understand what I want them to do. That’s the point. Patterns are the concepts that create one language among the business, the architects and the implementation teams.

Proven Answers, With Names

Section titled “Proven Answers, With Names”

Integration problems come back again and again. Send this, and wait for the answer. Send this, and don’t wait. Keep these two systems in step every night. Show that data here without copying it. People have solved each of these many times, and the good solutions have a lot in common. A pattern is one of those proven solutions, written down, with a name.

Patterns are standard, proven solutions to design problems that keep coming back. We want them because we want integrations that are scalable, robust and maintainable. What we don’t want is every team solving the same problem from the beginning, in its own words, with nobody sure what anyone else means.

The names come from two places you’ll meet throughout this course:

  • Enterprise Integration Patterns, the book by Gregor Hohpe and Bobby Woolf (2003), and its website. It calls itself “a pattern language” of 65 integration patterns, “a technology-independent vocabulary” (Enterprise Integration Patterns (opens in a new tab), checked 2026-11-01). It’s where names like publish and subscribe, and request and reply, were written down for the whole industry.
  • Salesforce’s own Integration Patterns, six patterns for integrating with Salesforce, sorted into three kinds: data integration, process integration and virtual integration (Integration Patterns (opens in a new tab), Salesforce Architects, checked 2026-11-01). These are the names on the exam, and module 3 takes each one in turn.

The Six Names

Section titled “The Six Names”

Here’s the whole list, so you know the words before we take them apart. Salesforce sorts them by which way the integration goes:

From Salesforce to another system

  • Request and Reply: Salesforce asks, and waits for the answer.
  • Fire and Forget: Salesforce sends it, and doesn’t wait for the outcome.
  • UI Update Based on Data Changes: the screen updates itself when the data changes.
  • Data Virtualization: Salesforce shows data that lives somewhere else, without copying it.

From another system to Salesforce

  • Remote Call-In: another system creates, reads, updates or deletes data in Salesforce.
  • Batch Data Synchronization: data is kept in step in batches, in either direction.

Two of them go by a longer name in Salesforce’s guide: Remote Process Invocation—Request and Reply, and Remote Process Invocation—Fire and Forget. Module 2 is about the direction itself, module 3 takes each pattern in turn, and module 4 adds one more name from the industry that isn’t on Salesforce’s list: publish and subscribe.

One Word, Three People

Section titled “One Word, Three People”

Here’s what a name does. Take two of them, the two that get mixed up most: request and reply, and fire and forget.

One word, three people A table with two rows and four columns: the pattern, what the business says, what the architect means, and what the team builds (tinted amber). Request and reply: the business says "check the customer's balance before the order goes in"; the architect means Salesforce asks, and waits for the answer, in the same call; the team builds a callout that waits, and a screen that handles no answer. Fire and forget: the business says "when a delivery runs late, tell Redrock"; the architect means Salesforce sends it, gets a receipt, and moves on; the team builds a platform event, a subscriber, and a record of every failure. Underneath: say the pattern's name, and the business, the architect and the team all know what happens, and what doesn't. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.53.0", "built": "2026-10-30", "id": "DGM-INT-PT-01", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "system-landscape/inventory 0.13.0", "theme": "stevetecharc 1.4.0"} THE PATTERN THE BUSINESS SAYS THE ARCHITECT MEANS THE TEAM BUILDS Request and reply "Check the customer's balance before the order goes in." Salesforce asks, and waits for the answer, in the same call A callout that waits, and a screen that handles no answer Fire and forget "When a delivery runs late, tell Redrock." Salesforce sends it, gets a receipt, and moves on A platform event, a subscriber, and a record of every failure Say the pattern's name, and the business, the architect and the team all know what happens, and what doesn't. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

One word, three people.

Request and reply means you are going to wait for the answer. It’s a request, and it’s a wait. The caller sends the request, and its processing holds until the response comes back. The business sentence from chapter 6 is the classic: check the customer’s balance before the order goes in.

Fire and forget means triggering something and not waiting for the response. The thread taking the action launches it off, sends the courier, sends the message, and moves on. Now, that doesn’t mean that if it fails you won’t record an error and take action. It means the action itself doesn’t wait. A delivery running late, and Redrock needs to know: the platform event from chapter 4 is a fire and forget.

Say “fire and forget” to the business, an architect and a developer, and all three know what happens, and what doesn’t.

A Receipt, Not the Outcome

Section titled “A Receipt, Not the Outcome”

The name also forces the most important question in integration: does anyone wait for the answer?

Here’s the confusion I see most. A team wants something to happen in real time, and they reach for fire and forget, because events are fast. But you get a receipt, not the outcome. Salesforce’s own definition says it: in fire and forget, Salesforce “doesn’t wait for completion of the process. Instead, the remote process receives and acknowledges the request and then hands off control back to Salesforce.” The receipt only tells you it made it to the next step. With a platform event, all you know is that it went onto the event bus. That’s all you know.

An answer, or a receipt Two frames on the same cells. Frame 1, request and reply: a person at the order screen, waiting to place the order; Salesforce, which needs the balance before the order goes in, asks accounting for the balance and waits for the answer. Frame 2, fire and forget: Salesforce publishes it to the event bus, between Salesforce and accounting, and gets a receipt: it's on the bus (an amber arrow; that's all Salesforce knows). The bus delivers it to accounting later. The person at the order screen has no balance to look at. Underneath: unless you're waiting for the answer, in request and reply, you can't be synchronous; fire and forget gives you a receipt, not the outcome. THE USER SALESFORCE ACCOUNTING A person at the order screen waiting to place the order Salesforce needs the balance before the order goes in Accounting knows the customer's balance places the order asks for the balance, and waits for the answer Unless you're waiting for the answer, in request and reply, you can't be synchronous. Fire and forget gives you a receipt, not the outcome. HOW TO READ IT all Salesforce knows: it went onto the bus © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Frame 1 of 2: request and reply. The answer comes back in the same call.

An answer, or a receipt Two frames on the same cells. Frame 1, request and reply: a person at the order screen, waiting to place the order; Salesforce, which needs the balance before the order goes in, asks accounting for the balance and waits for the answer. Frame 2, fire and forget: Salesforce publishes it to the event bus, between Salesforce and accounting, and gets a receipt: it's on the bus (an amber arrow; that's all Salesforce knows). The bus delivers it to accounting later. The person at the order screen has no balance to look at. Underneath: unless you're waiting for the answer, in request and reply, you can't be synchronous; fire and forget gives you a receipt, not the outcome. THE USER SALESFORCE ACCOUNTING A person at the order screen no balance to look at Salesforce needs the balance before the order goes in The event bus holds the event until it's delivered Accounting knows the customer's balance places the order the receipt: it's on the bus delivered later Unless you're waiting for the answer, in request and reply, you can't be synchronous. Fire and forget gives you a receipt, not the outcome. HOW TO READ IT all Salesforce knows: it went onto the bus © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Frame 2 of 2: fire and forget. A receipt, not the outcome.

So unless you’re actually waiting for the response, in request and reply, you can’t be synchronous. If the person at the order screen needs the balance before the order goes in, fire and forget can’t give it to them, however fast the event is. That one sentence has saved a lot of designs. And it only works because everyone in the room knows what the two names mean.

A Pattern Isn’t a Product

Section titled “A Pattern Isn’t a Product”

One more thing the language gives you: it keeps the pattern apart from the tool. Fire and forget is the pattern. A platform event is one mechanism that builds it, and there are others. Request and reply is the pattern; an Apex callout, a Flow HTTP callout and External Services are mechanisms that can build it.

That’s the order from chapter 6: shape first, then pattern, then mechanism. If someone starts with a tool (“we’ll use platform events”), bring it back to the pattern, and then to the shape: does anyone wait?

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • The pattern for every arrow, by name, so the business, the architects and the team mean the same thing.
  • For every “real time” requirement: whether someone waits for the answer, and so whether it’s request and reply.
  • For every fire and forget: what the receipt tells you, and how a failure after the receipt is recorded and acted on.
  • That the pattern is chosen before the mechanism.

Beyond the exam: what AI changes. Patterns are a language for AI too. Tell a coding assistant “fire and forget, with a platform event, and record every failure”, and it knows what to build. Tell it “make it real time”, and it has to guess. And agents follow the same patterns: a person asking an agent is waiting, so the agent’s call to another system is a request and reply, with all its error handling, whatever it’s called.

Explore

Section titled “Explore”

Volg mij

© 2023–2026 Twinshark LLC. All rights reserved. · Gebruik van content

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.

Juridische mededelingen zijn in het Engels, en de Engelse versie is leidend.