Integration Patterns

Chapter 7 of Integration Architect, Part 1: Understanding Integration (See), and the end of Part 1. Previous: Understanding Integration Requirements · Next: Part 2 begins with Salesforce as an API Provider (coming soon).

Chapter 6 gave every arrow its shape: who starts it, from where to where, how soon, how much. This chapter gives those shapes names.

A pattern is a proven answer to a problem that keeps coming back, with a name. The name is the point. I can say a few words to a development team, and they understand what I want them to do. Patterns are the language shared by the business, the architects and the implementation teams, and they’re the words on the exam.

Steve Trucking runs through every module, and the chapter ends with Checkpoint 1: every arrow on its landscape, sized and named.

The ideas in this chapter

• Does anyone wait for the answer? That’s the question every pattern name answers. Request and reply waits. Fire and forget gets a receipt, not the outcome: all you know is it went onto the event bus. Unless you’re actually waiting for the response, you can’t be synchronous.
• Call-outs and call-ins are Salesforce-centric words. Salesforce calling out is outbound; anything calling in is inbound, and that includes your own middleware. The word decides how it’s built, how it signs in, and which limits it meets.
• Salesforce’s six patterns, in plain words. Request and Reply, Fire and Forget, Batch Data Synchronization, Remote Call-In, UI Update Based on Data Changes and Data Virtualization. Each one in Salesforce’s words, then mine, with what builds it today, dated, because the mechanisms change and the patterns don’t.
• Publish and subscribe. One event goes out, and it could be delivered to 50 different clients, each in its own time. The publisher never has to know who’s listening, and a new subscriber never changes the publisher.
• Choose with three questions. Which way, what kind (process, data or virtual), and does anyone wait. Salesforce’s selection tables do the rest, and the numbers decide how it’s built. And for any kind of movement, batch is your backup plan.
• Real solutions combine patterns. A batch to set the baseline, events to keep it in sync, virtualization to see it, and a batch underneath to catch what was missed.

The path through this chapter

Seven modules, each standing on its own.

1. Patterns Are a Language. Proven answers with names; the six names; one word, three people; a receipt, not the outcome; a pattern isn’t a product.
2. Call-Outs and Call-Ins. Out and in; who’s calling in, read on Steve Trucking’s landscape; why the word matters.
3. Salesforce’s Six Patterns, in My Words. Each pattern, its history where it matters (outbound messages, the Streaming API), and copy it, or see it.
4. Publish and Subscribe. One call each, or one event for all; each in its own time; they never have to coordinate; everything in the event, or a notice with the ID.
5. Choosing a Pattern. Three questions; Salesforce’s selection tables and where they stop; three arrows, three patterns; batch is your backup plan.
6. Several Patterns, One Solution. Five orgs that wanted to see each other; the problem, counted; five orgs, one database, built in order; the sixth org.
7. Checkpoint 1: Steve Trucking, What I Would Architect. The landscape, the numbers, and every arrow’s pattern, after you’ve tried the challenge yourself.

Part 2 picks the mechanism behind each pattern, with its own limits: Salesforce as a provider in chapter 8, as a client in chapter 9, bulk in chapter 10 and events in chapter 11.

When you’ve finished, check yourself with the chapter study guide: a checklist for the exam, the habits beyond it, the words to know, and a few questions.

What an architect decides here

• The pattern for every arrow, by name, from which way it goes, what kind it is, and whether anyone waits.
• Whether it’s a call-out or a call-in, and so its credential, its mechanism and the limits it spends.
• For every fire and forget: what the receipt tells you, and who finds out when the outcome fails.
• For every change several systems care about: one call each, or one event for all, and what goes in the event.
• For every flow built on events: the batch underneath.
• For every design: what happens when it grows by one.

Beyond the exam: AI speaks patterns 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 guesses. An agent that looks something up while a person waits is a request and reply, whatever it’s called. Each module ends with what AI changes.

Explore

• Salesforce Architects, Integration Patterns (opens in a new tab): the six patterns, their solutions and the selection tables.
• Enterprise Integration Patterns (opens in a new tab), Gregor Hohpe and Bobby Woolf: the industry’s pattern language.

Next: Part 2 begins with Salesforce as an API Provider (coming soon)