تخطَّ إلى المحتوى
SteveTechArcSteveTechArc Courses

The Star Trek Transporter

هذا المحتوى غير متوفر بلغتك بعد.

Module 3 of 6 in the chapter APIs, Contracts and Data Across the Wire, chapter 3 of the Integration Architect course. Each module stands on its own. Previous: The Contract · Next: Formats, Old to New

The question this module answers: How does data leave one system and arrive in another, and what can go wrong on the way?

When I teach this, I ask the room a question. Anybody know why they invented the transporter?

Usually, nobody does. Some classes, nobody’s even seen it: they’re all Star Wars people. So here’s the short version. Star Trek was a television series from the 1960s about the crew of a starship. In it, a machine called the transporter turns a person on the ship into energy, sends them down to the planet below, and rebuilds them there, exactly as they were.

Why the Transporter Was Invented

Section titled “Why the Transporter Was Invented”

Every episode, the crew had to visit a new planet. But a starship landing and taking off every week would have needed expensive model shots and special effects, and the show didn’t have the budget. So the writers had a better idea: show the ship circling a planet, and have the people simply disappear on board and appear on the ground. The show’s creator, Gene Roddenberry, said that not having the money to land the ship made the stories better, because they could start right away. In his words, not having the budget “forced us into conceiving the transporter” (Stephen E. Whitfield and Gene Roddenberry, The Making of Star Trek, 1968, as quoted by Word Origins (opens in a new tab), checked 2026-11-01). A shuttlecraft was the next idea, but its full-size model wasn’t ready when filming began, so beaming people down, with a simple fade out and fade in, was the cheaper answer (Transporter (Star Trek) (opens in a new tab), Wikipedia, checked 2026-11-01).

So the transporter came from a limit: they couldn’t move the ship. And that’s exactly the problem in integration.

Across the Process Boundary

Section titled “Across the Process Boundary”

In a system, data rests in a database: in Salesforce, as records in its tables. When the system works with it, it loads it into objects in memory: a delivery, with its fields, its recipient, its list of items, all connected inside that one process. That object can’t leave. Another system can’t reach into your memory and pick it up. Between the two is what I call the process boundary, and only a stream of data can cross it.

So you do what the transporter does. You take the object apart into a stream of text, send the stream, and the other side rebuilds it. That’s serialization:

Serialization is the process of converting complex data and objects into a format that can be stored, transmitted and reconstructed later, ensuring the data integrity and compatibility.

Turning the object into the stream is serializing it. Rebuilding the object on the other side is deserializing it. Bring the human back on the other side.

The transporter Three panels, left to right. 1, a structure, in Salesforce, an Apex object: a Delivery with id D-1042 and status Delivered; a recipient, named Corner Hardware; and items, PAL-200 with quantity 3 and BOX-12 with quantity 40. 2, serialized, a stream, in amber: on the wire, one line of JSON text, shown wrapped to fit, holding the same id, status, recipient and items. 3, deserialized, a new structure, in Redrock, say a Java object: a Shipment with shipmentId D-1042 and state DELIVERED; a consignee, named Corner Hardware; and lines, PAL-200, 3, and BOX-12, 40. Underneath: the object can't cross; its data can, as text both sides know how to read, and each side builds its own shape. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.52.0", "built": "2026-10-28", "id": "DGM-INT-AC-07", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison/side-by-side 0.5.0", "theme": "stevetecharc 1.4.0"} 1. A structure in Salesforce: an Apex object DELIVERY id: D-1042 status: Delivered RECIPIENT name: Corner Hardware ITEMS PAL-200, quantity 3 BOX-12, quantity 40 2. Serialized: a stream on the wire: one line of JSON THE TEXT, WRAPPED TO FIT {"id":"D-1042","status":"Delivered", "recipient":{"name":"Corner Hardware"}, "items":[{"sku":"PAL-200","quantity":3}, {"sku":"BOX-12","quantity":40}]} 3. Deserialized: a new structure in Redrock: say, a Java object SHIPMENT shipmentId: D-1042 state: DELIVERED CONSIGNEE name: Corner Hardware LINES PAL-200, 3 BOX-12, 40 The object can't cross. Its data can, as text both sides know how to read, and each side builds its own shape. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

The transporter: a structure on one side, a stream of text on the wire, and a new structure on the other.

Look at what crosses. On the left, Steve Trucking’s delivery is a structure in Salesforce: a delivery with its fields, a recipient inside it, and a list of items. In the middle, it’s nothing but one line of text. On the right, Redrock has rebuilt it as a structure again.

Any Language, Any Shape

Section titled “Any Language, Any Shape”

Now look at the right side again. It isn’t the same structure. Redrock calls it a Shipment, not a Delivery. The recipient is a consignee. The status is in capitals. That’s the other power of serialization: the stream doesn’t care what’s on either side.

Steve Trucking runs on Salesforce, so its side is Apex. Redrock’s system could be written in Java, or .NET, or Python, or anything else. Data can leave one platform, one tech stack, one language, cross as a stream, and be rebuilt on the other side in a completely different structure. Neither side has to know how the other one is built. They only have to agree on two things: the format of the stream, and how to rebuild their own structure from it. The transporter doesn’t need two ships built the same way. It only needs both of them to read the same signal.

For it to work, both sides must know the format. You have to decide what the stream is: JSON, XML, a fixed structure, or binary. The system on the other end needs to know that format to rebuild the object. A transporter that sends in one format and receives in another doesn’t bring anybody back.

And it happens in both directions. On one call, the client serializes its request, the server deserializes it, the server serializes its answer, and the client deserializes that. That’s four trips through the transporter on a single round trip.

Four trips through the transporter The client on the left, Steve Trucking on Salesforce, whose processing keeps records in the database and objects in memory; the server on the right, Redrock's system, with database tables and objects in memory; the process boundary in the middle. On top, the request: the client's object is serialized into text, crosses the boundary as the request body, in JSON, XML, a fixed structure or binary, and is deserialized into an object on the server. Underneath, the response: the server's object is serialized into text, crosses back as the response body, in the same format, and is deserialized into an object on the client. Underneath: one round trip, four trips through the transporter; the way in should equal the way out. THE CLIENT: STEVE TRUCKING, ON SALESFORCE THE PROCESS BOUNDARY THE SERVER: REDROCK'S SYSTEM Processing the call goes out: records in the database, objects in memory Serialize Request body JSON, XML, a fixed structure or binary Deserialize Processing the call comes in: database tables, objects in memory object text text object One round trip, four trips through the transporter. The way in should equal the way out. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

The request: serialize, cross, deserialize.

Four trips through the transporter The client on the left, Steve Trucking on Salesforce, whose processing keeps records in the database and objects in memory; the server on the right, Redrock's system, with database tables and objects in memory; the process boundary in the middle. On top, the request: the client's object is serialized into text, crosses the boundary as the request body, in JSON, XML, a fixed structure or binary, and is deserialized into an object on the server. Underneath, the response: the server's object is serialized into text, crosses back as the response body, in the same format, and is deserialized into an object on the client. Underneath: one round trip, four trips through the transporter; the way in should equal the way out. THE CLIENT: STEVE TRUCKING, ON SALESFORCE THE PROCESS BOUNDARY THE SERVER: REDROCK'S SYSTEM Processing the call goes out: records in the database, objects in memory Serialize Request body JSON, XML, a fixed structure or binary Deserialize Processing the call comes in: database tables, objects in memory Processing the answer goes out Serialize Response body the same format, back the other way Deserialize Processing the answer comes in object text text object object text text object One round trip, four trips through the transporter. The way in should equal the way out. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Then the answer, the same way back. One round trip, four trips through the transporter.

It’s why the way in should equal the way out: if you send JSON, you should expect JSON back.

Every Place Has Its Own Encoding

Section titled “Every Place Has Its Own Encoding”

Any communication between two systems has some form of serialization. You just need to know what it is. And remember the three places to put things from the first module: each one has its own rules.

  • In the address, special characters are percent-encoded: a space becomes %20 (RFC 3986 (opens in a new tab), section 2.1).
  • In the body, the data is serialized in the format the contract says: most often JSON.
  • For binary content, like a photo of a signed delivery note, inside a text format such as JSON, the bytes are usually carried as Base64 text (RFC 4648 (opens in a new tab)). You’ll see Base64 again in tokens, in chapter 12.

Notice something about all three: they make the data bigger. Encoding a space turns one character into three. Base64 turns three bytes into four characters. Serialization almost always makes the payload larger than the object it came from. That matters when the volumes grow, and chapter 10 comes back to it.

Your Tools Do It for You, Until They Don’t

Section titled “Your Tools Do It for You, Until They Don’t”

Most of the time, you won’t write the transporter yourself. Your tools will. In Apex, one line serializes an object to JSON, and one line deserializes it back. In Flow, Salesforce does it behind the scenes. And in an API client, you just see the text.

That one line works great until it doesn’t. Two things bring it down. The payload might use a field name you can’t use in your own code, a reserved word. Or the payload is so big that rebuilding it runs out of memory. Then you have to take the stream apart piece by piece, with a parser, and that’s a lot more work.

Here’s what experience teaches. Making the call is the straightforward part: a handful of lines of code. Dealing with the answer, rebuilding it and checking it, is the biggest lift in an integration. Chapter 9 shows the code; chapter 4 shows what Salesforce does for you without code.

What the Transporter Can Drop

Section titled “What the Transporter Can Drop”

Now the part that makes this a data quality problem. Imagine a transporter that brings the person back, but drops a few atoms on the way. They look fine. They walk off. And something is quietly wrong.

Serialization can do that to data. Nothing fails. The call returns a 200. But four things can arrive changed:

  • The time. A delivery was made at 14:05. Whose 14:05? A time with no time zone is a guess, and a time zone can shift a delivery into the next day. Send the zone, in the international standard format: 2026-11-01T14:05:00Z, where the Z means UTC (ISO 8601 (opens in a new tab), checked 2026-11-01).
  • The number. A charge of 412.50 arrives as 412.5. For a weight, that’s fine. For money with a fixed number of decimal places, it may not be. And many systems read every JSON number the same way, with a fixed amount of precision, so a number with more digits than that can be rounded without warning (RFC 8259 (opens in a new tab), section 6). Agree the precision in the contract. And never leave money to chance.
  • The currency. An amount of 100.00, of what? An amount with no currency is a guess. Send the three-letter code with it: USD, EUR, JPY (ISO 4217 (opens in a new tab), checked 2026-11-01).
  • The characters. A recipient named Zoë arrives as Zoë. Both sides have to read the text in the same character encoding, and for JSON between systems that’s UTF-8: the standard says JSON “MUST be encoded using UTF-8” (RFC 8259 (opens in a new tab), section 8.1; RFC 3629 (opens in a new tab)). With customers in twenty languages, this one isn’t rare.
What the transporter can drop Four panels, in amber. The time, whose 14:05?: a time with no zone is a guess; send the zone, as in 2026-11-01T14:05:00Z; the standard is ISO 8601. The number, 412.50 became 412.5: decimals can be rounded on the way; agree the precision; money is never left to chance. The currency, 100.00 of what?: an amount with no currency is a guess; send the code, such as USD, EUR or JPY; the standard is ISO 4217. The characters, Zoë became Zoë: both sides must read the same encoding; send UTF-8, and say so; JSON between systems is UTF-8. Underneath: a 200 doesn't check any of these; the contract has to. {"author": "Steve Simpson", "blueprint": "1.0.1", "builder": "standard 1.57.1", "built": "2026-11-01", "id": "DGM-INT-AC-08", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison/side-by-side 0.5.0", "theme": "stevetecharc 1.4.0"} The time whose 14:05? A time with no zone is a guess Send the zone: 2026-11-01T14:05:00Z The standard: ISO 8601 The number 412.50 became 412.5 Decimals can be rounded on the way Agree the precision Money is never left to chance The currency 100.00 of what? An amount with no currency is a guess Send the code: USD, EUR, JPY The standard: ISO 4217 The characters Zoë became Zoë Both sides must read the same encoding Send UTF-8, and say so JSON between systems: UTF-8 A 200 doesn't check any of these. The contract has to. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

What the transporter can drop. Nothing fails, and the data is quietly wrong.

That’s why “the API returned 200” isn’t data quality, from the first module. A 200 doesn’t check the time zone, the precision, the currency or the characters. The contract has to say how each one is sent, and both sides have to follow it.

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • For every call, the format going out and coming back, written in the contract.
  • How times are sent: always with a zone, in ISO 8601.
  • The precision of every number that matters, and how money is sent: an amount and its currency code, together.
  • The character encoding: UTF-8, stated, not assumed.
  • Where serialization happens: in a tool, in Flow, in code, or in middleware, and who checks the result.
  • The names on each side: which field in your structure maps to which field in the stream, when the other side calls things by different names. Module 5 is mapping.

Beyond the exam: what AI changes. AI is good at turning one format into another, and at spotting a time with no zone or an amount with no currency. It’s also good at quietly guessing: give it a time with no zone, and it may add one. When AI writes or checks your serialization, ask it to list every assumption it made. Module 6 puts this to work.

Explore

Section titled “Explore”