Bỏ qua để đến nội dung

Study guide

Nội dung này hiện chưa có sẵn bằng ngôn ngữ của bạn.

Study guide for chapter 2 of the Integration Architect course. Read the five modules first; 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 is the smallest brick in integration: one call, between a client and a server. No exam objective belongs to it alone, but nearly every scenario on the exam depends on it, because the side that dials and the side that answers carry different jobs. Each group below says which objectives it supports.

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

Who dials (supports LAND-1 and DES-2)

  • I know the client is whichever side starts the conversation, and the server is the side that’s already listening, whatever their size or importance. (Somebody Dials)
  • I keep two questions apart: who dials, and whether the call pushes data, asks for data, or asks the other side to do something. (Push or Ask)
  • I know every turn on a call is the client’s, and the server answers each one without starting one of its own. (One Call, Many Turns)
  • I know that if the line drops, the client reconnects; the server doesn’t call back. (If the Line Drops, the Caller Calls Back)
  • I know an event subscriber still dials: it calls, subscribes and waits on the line, and asks for everything after the last event it saw when it reconnects. (Almost Always)

Finding the server (supports LAND-1)

  • I know a client needs three things: where the server is, how to prove who it is, and how to talk to it. (Finding the Server)
  • I can choose the kind of address: localhost within a machine, an IP address only inside a network you run, and a name for anything outside it or behind a load balancer. (An Address)
  • I know DNS turns a name into an address, and that if the client can’t look up the name, the call never starts. (An Address)
  • I know a port is the phone number inside the building: 443 for HTTPS, 80 for plain HTTP, and that every firewall in between has to allow the port the server listens on. (Your Port Is Like the Phone Number)
  • I know 443 means the traffic is encrypted with TLS and the server is proven to the client, not that the caller is authenticated. (Your Port Is Like the Phone Number)
  • I know someone has to keep the server listening, and that when nothing is, the client finds out and decides what to do. (Someone Has to Be Listening)

Proving who you are (supports BLD-5)

  • I know an open server is public on purpose or not at all: it can’t turn anyone away, so it’s exposed to denial of service. (An Open Door)
  • I know today’s integrations prove who they are with a client ID and secret or a certificate, and get back a token, and that an integration never quietly borrows a person’s login. (Proving Who You Are)
  • I know the OAuth username-password flow can’t be enabled in orgs created from Summer ‘26 and is retired for connected apps on 2027-02-20. (Proving Who You Are)
  • I know the client often gets its token from a second address, an authorization server, then sends the token with every call. (A Second Address)
  • I know the server checks who’s calling and then decides what they may do, so a narrow integration user gets a narrow answer. (The Server’s Side of the Door)

Each side’s moves (supports DES-2 and BLD-4)

  • I can list the client’s moves (endpoint, token, protocol and contract, payload, the round trip) and the server’s (available, listening, tokens, defining the contract, validating, logging). (Each Side’s Dance Moves)
  • I know the client owns the round trip, because only the client sees all of it. (The Client Owns the Round Trip)
  • I can name the four kinds of error the client traces: connection, sign-in, server errors passed back, and response errors. (The Client Owns the Round Trip)
  • I know the server receives, examines, validates and processes, logs its own internal errors, and returns one of the errors its contract defines. (The Server Owns What Happens Inside)
  • I know client and server are parts in a call, not kinds of system: two systems that call each other are both clients and both servers. (Both Clients and Both Servers)

Making a call yourself (supports BLD-4)

  • I can make a call with an API client and read the method, address, headers, body, status and time. (Your First Call)
  • I know the time my tool shows is the whole round trip, which only the client can see. (Read What Came Back)
  • I can tell three outcomes apart: a slow answer, an error the server sent back (such as 404 Not Found), and no status at all, which is a connection error on the client’s side. (Now Break It, on Purpose)

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.

  • Ask one question first: who dials?
  • Write it per arrow, not per system. For this call, who’s the client?
  • Write every name, address, port and listener down for each arrow, not in someone’s head.
  • Decide the port, and tell the people who run the firewall.
  • Public access is the exception, chosen on purpose.
  • The contract isn’t only for success. The server promises its errors too.
  • Decide how long each client waits before it gives up.
  • Never send real data to a public test server, and never paste a secret or a token into AI.
TermIn one line
ClientThe side that dials: starts the conversation and owns the round trip
ServerThe side that answers: already listening before anyone calls
localhostThe address that always loops back to the machine you’re on
IP addressA number that identifies one machine on a network
Domain, subdomainA name for a service, such as api.steve-trucking.example
DNSThe internet’s address book: turns a name into an address
Load balancerStands in front of several servers and spreads the calls across them
PortThe number a service listens on inside a machine; 443 for HTTPS
Authorization serverThe second address, where a client trades its credentials for a token
Access tokenProof the client was checked, sent with every call, good for a limited time
Round tripThe whole call: out to the server, its work, and back
API clientA tool, such as Postman, that makes calls for you

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

1. A partner's system sends manifests to Salesforce, and later Salesforce sends each delivery's status back to the partner. Which one is the client?

Both, in different calls. For the manifests, the partner dials and Salesforce answers. For the status, Salesforce dials and the partner answers, so Salesforce needs the partner’s address and credentials and owns that round trip. Two calls, two arrows. Reread Both Clients and Both Servers.

2. A connection to an event stream drops overnight. Who's responsible for reconnecting, and what does it ask for?

The subscriber. It dialed in the first place, so it calls back, and asks for everything after the last event it saw. The server doesn’t keep a list of who to call back. Reread If the Line Drops, the Caller Calls Back.

3. The developers point a client at port 7443, and the call never connects, though the name and address are right. What would you check?

The firewall. If the network team only opened 443, the call is blocked before it reaches anyone listening. Someone has to decide the port and tell the people who run the firewall. Reread Your Port Is Like the Phone Number.

4. A service runs on one machine, and partners call it by its IP address. What's the risk, and the fix?

An IP address usually takes you to a single machine; if it goes down, the partners are lost. Give the service a name in front of a load balancer, so machines can be added and replaced behind it while the partners keep calling the same name. Reread An Address.

5. The server says it answered in one second. The client says the call took thirty. Whose problem is it?

The client’s. The server did its job in a second; everything on the way there and back is on the client’s side, because only the client sees the whole round trip. Reread The Client Owns the Round Trip.

6. In your API client, one call returns 404 Not Found and another shows no status at all. What's the difference?

A 404 means the server got the call and answered with an error its contract defines. No status means the call never got there: a connection error, for the client to trace. Reread Now Break It, on Purpose.

7. A new integration plans to sign in to Salesforce with a username and password through OAuth. What do you recommend?

Not that flow: it can’t be enabled in orgs created from Summer ‘26 and is retired for connected apps on 2027-02-20. Use the integration’s own credentials, such as a client ID and secret or a certificate, to get a token, as its own integration user. Chapter 12 picks the flow. Reread Proving Who You Are.