Integration patterns
Every connection you build between the Revenue Cloud and another system is one of three shapes. Choosing the wrong shape is the most expensive decision in an integration project, and it is usually made in the first meeting, by accident.
The three shapes
Batch. Data moves on a schedule. A file or an API run at 02:00 brings the night's product changes across, another at 06:00 brings prices. Batch is throughput-oriented: it handles large volumes cheaply because nobody is waiting for it. If it fails, you re-run it.
Real-time. The Revenue Cloud asks the other system a question at the moment somebody needs the answer, and waits. A buyer opens a product page and the shop calls the ERP for that customer's price and the current stock. Nothing is stored; the answer is as fresh as the source and as slow as the source.
Hybrid. Most of the data comes in by batch, and a small, deliberately chosen set of fields is asked for live. This is what almost every real project ends up as, and it is worth aiming at directly rather than arriving at it after two rewrites.
Which one for which data
The useful question about a field is: how wrong is this allowed to be, and for how long? Asking how important it is leads nowhere, because everything is important.
| Data | Volatility | Cost of being stale | Pattern |
|---|---|---|---|
| Product master data, descriptions, attributes | Low | Low; a description from yesterday is fine | Batch, nightly |
| Categories, families, media | Low | Low | Batch, nightly or on demand |
| List prices, price lists | Low to medium | Medium; a wrong list price is embarrassing | Batch, nightly |
| Customer-specific and contract prices | Medium | High; a wrong contract price is a credit note | Real-time, or batch with a live check at cart |
| Stock and availability | High | High; an in-stock promise on an out-of-stock article costs a phone call | Real-time, with a cached fallback |
| Customer master, organisations, contacts | Low | Medium | Batch, plus real-time on first login |
| Credit limit, blocked status | Medium | Very high; you must not deliver to a blocked customer | Real-time at checkout |
| Orders going out to the ERP | Event-driven | Very high | Event, immediately, with retries |
| Order status, delivery notes, invoices | Medium | Medium | Batch, several times a day |
Read the table as a starting position rather than a rule. A spare-parts business where one article in stock is the difference between a machine running and a machine stopped needs live stock. A wholesaler shipping from a full warehouse can serve a stock figure that is two hours old with a note, and save themselves an integration.
Why "real-time everything" is usually wrong
It sounds like the safe choice. It is the expensive one, for four reasons.
Your shop inherits the ERP's availability. A synchronous call means the page cannot render until the ERP answers. If the ERP is in maintenance on Sunday night, your shop is down on Sunday night. If it takes 900 ms on a bad day, your category page takes 900 ms per product on a bad day.
Load multiplies where you cannot control it. A category page with 48 products is 48 price calls and 48 stock calls, and a crawler hitting your catalog turns that into a load test of your ERP that nobody scheduled. Most ERP systems were sized for the number of people in the Innendienst, not for the internet.
You cannot search or filter on data you do not hold. "Show me all articles under 50 € that are in stock" is impossible if price and stock live in another system and are only fetched per product. Faceted search needs the data locally.
Debugging gets harder. With batch you have a file and a log: you can see exactly what arrived and re-run it. With real-time you have a moment that has passed and a buyer who says the price was different five minutes ago.
The other direction has a matching failure, and it is worth naming: a purely nightly integration means your shop tells buyers about yesterday's world. In technischer Großhandel that is enough to lose the channel, because the reason people phone the Innendienst instead of ordering online is that they do not believe the availability shown on the screen.
Idempotency: the property that makes retries safe
An operation is idempotent if running it twice has the same effect as running it once. That property decides whether a failed integration is a five-minute re-run or an evening of manual repair.
Things fail halfway. A file transfer breaks at row 40,000 of 60,000. An order call times out, and a timeout tells you nothing about whether the other side processed it. If your operations are idempotent, the answer in both cases is "run it again". If they are not, the answer is "find out what got through first".
Three rules make it work:
- Match on a stable business key, never on a technical one. Products match
on SKU
4711-A, customers on their ERP customer number, orders on your order number. An internal database ID that the other system has never seen is not a key you can match on. - Upsert instead of insert. Every import should mean "make the record look like this", not "create a record". Re-running then converges instead of duplicating. This is why the product import matches on SKU and updates; see Import products in bulk.
- Give every outbound message an ID and expect the receiver to deduplicate. The same order transmitted twice with the same order number is one order. The same order transmitted twice with two generated IDs is two deliveries and an awkward call.
The classic failure is a nightly stock file that is applied as a delta rather than a state. Run it twice and stock is wrong by exactly one night's movements, silently, with no error anywhere. Full-state files are boring and safe; deltas are efficient and unforgiving.
Full load or delta
Related decision, same trade-off:
| Full load | Delta | |
|---|---|---|
| Volume | Everything, every run | Only what changed |
| Runtime | Long, hours for a large catalog | Short |
| Recovery from a missed run | Automatic, the next run repairs it | Manual; the gap stays a gap |
| Deletions | Visible: what is absent is gone | Only if the source sends a delete signal |
| Good for | Catalogs up to a few hundred thousand articles, nightly | Very large catalogs, or frequent runs |
A common and workable compromise: deltas through the week, one full load at the weekend to repair whatever the deltas missed. If you run deltas only, plan how you find out that an article was deleted upstream; otherwise your catalog grows articles that no longer exist and nobody notices until a buyer orders one.
How this works in the Revenue Cloud
- Batch runs are workflows in Integration Studio with a schedule; see Build a workflow. A run keeps its log, so you can see what arrived and re-run it.
- Real-time calls are made when a page or a cart needs them, against a connected system; see Connect a system.
- Event-driven flows react to something happening here, such as an order being placed, and push outward; see Events and webhooks.
- Files are still most of German B2B integration, and they are a first-class option. Import and export profiles under Data Exchange describe a file's structure and its mapping, and the built-in SFTP server gives an ERP somewhere to drop a CSV without anyone building an API. A folder, a naming convention and a schedule is a working integration.
Whichever you choose, decide first which system owns which field. That decision outranks the pattern, and it is the subject of the next article.
Next
- Deciding your system of record: who owns which field.
- Monitor your syncs: knowing a feed broke before your buyers do.