Syncing e-shop orders to your ERP with Boomi

Getting e-shop orders into the ERP is usually the first integration a company builds, and the one that hurts most when it goes wrong. A missing order means an unhappy customer. A duplicate order means double invoicing, wrong stock and an afternoon of credit notes. This article explains the two patterns that prevent both problems, then builds the flow step by step in Boomi.

Why the naive approach fails

The first version usually looks like this: every 10 minutes, fetch the orders from the last 10 minutes and create them in the ERP. It works in testing, and then:

Orders go missing. The flow ran late, or failed once, or the server clock was a little off. Any order that falls in a gap between two windows is never picked up.
Orders are duplicated. The ERP call timed out, but the ERP actually created the order. The flow retries and creates it again. Or two executions overlap and both pick up the same order.
Edits are lost. An order paid at 10:02 and changed to “cancelled” at 10:15 is fetched once and never again.

The pattern: watermark plus idempotency

Two simple ideas fix this.

1. Incremental polling with a watermark

Instead of “the last 10 minutes”, remember where you stopped. After each successful run, store the highest updated_at timestamp you processed (the watermark). The next run asks the e-shop for orders updated after the watermark. If a run fails, the watermark doesn’t move, so the next run picks up from the same point. Nothing falls in a gap.

Two details matter:

Take the watermark from the data (the latest updated_at you actually processed), not from the clock of the integration server.
Use “greater than or equal” and a small overlap (for example one minute back) if the e-shop’s timestamps have low precision. The overlap will fetch a few orders twice, which is fine, because of the second idea.

2. Idempotent creates

An operation is idempotent if doing it twice has the same effect as doing it once. For orders, that means the ERP must be able to recognise an order it already has. The usual way is to store the e-shop order number in the ERP order, for example in an “external reference” field, and check it before creating:

for each order since watermark:
    if ERP has order with externalRef = "ESHOP-58213":
        update it if the status changed, otherwise skip
    else:
        create it with externalRef = "ESHOP-58213"
move watermark to the latest updated_at processed

With both in place, you can retry anything at any time without fear. That is what makes the flow safe to operate.

Building it in Boomi

The example uses a WooCommerce-style REST API on the e-shop side and an ERP that exposes a REST or SOAP API. The same structure works for other e-shops and ERPs, only the connectors change.

Step 1: Store the watermark

Boomi lets a process keep values between executions with persisted process properties. Create a dynamic process property, for example LAST_ORDER_UPDATED_AT, and mark it as persisted when you set it in a Set Properties shape. Its value survives from one execution to the next on the same runtime.

For the first run, give it a sensible starting value (for example the go-live date) so the process doesn’t try to fetch the e-shop’s entire history.

Step 2: Fetch changed orders

Start the process with a No Data start shape and schedule it later in the deployment (for example every five minutes).
Add an HTTP Client connector shape (or the e-shop’s dedicated connector if one exists) with a GET operation on the orders endpoint.
Pass the watermark as a query parameter, such as modified_after. In the HTTP Client operation you can define replacement variables in the resource path and fill them from the process property.
Handle paging. Most e-shop APIs return 50 or 100 orders per page. Loop until a page comes back empty, or use the connector’s paging support where it has one.
Split the response into one document per order (a Data Process shape with a split by profile is a common way to do this), so each order succeeds or fails on its own.

Step 3: Map to the ERP order

Use a Map shape from the e-shop order profile to the ERP order profile. Typical work here:

Map the e-shop order number to the ERP’s external reference field, for example ESHOP-58213.
Translate codes: payment methods, shipping methods and VAT categories. A cross reference table keeps these lists in one place (see Cross reference tables in Boomi).
Resolve the customer: find the ERP customer by email or VAT number, or route the order to a sub-process that creates the customer first, for example C-1042.

Step 4: Check before you create

Before the create call, query the ERP for an order with the same external reference. Then use a Decision shape:

Not found: create the order.
Found: compare status. If the e-shop status changed (for example to cancelled), update it. Otherwise stop quietly, it is a harmless repeat.

If your ERP supports an upsert or a unique constraint on the external reference, use it as well. A check-then-create step can still race if two executions run at the same time, so also make sure executions don’t overlap. Boomi processes have an option that controls whether simultaneous executions are allowed. Keep it off for this process (exact option labels can change between releases).

Step 5: Move the watermark only after success

At the end of the successful path, set LAST_ORDER_UPDATED_AT to the highest updated_at among the orders processed. A simple way is to track the maximum in a dynamic process property while documents flow through, and persist it in the last Set Properties shape.

If an individual order fails, decide your policy. The safest default is to send the failed order to error handling (see the next article in this series) and still move the watermark, so one bad order doesn’t block all the others. The failed order then needs a reliable path back in, either a manual re-run or a retry queue.

Before you go live

Run it twice on purpose. Reset the watermark to an hour ago and run the process again. Nothing new should appear in the ERP. This is the best single test of idempotency.
Test the gaps. Stop the schedule for an hour, place a few test orders, then start it again. All of them should arrive.
Watch the first peak. Check execution times during the first sale or campaign, and adjust the schedule and page size if a run takes longer than the interval.
Log the external reference. Add the e-shop order number to the process logs or tracked fields, so you can answer “did order 58213 reach the ERP?” in seconds.
Document the watermark. Write down where it lives and how to reset it, for the day someone needs to re-sync a period.

Summary

A watermark guarantees nothing is missed, and idempotent creates guarantee nothing is duplicated. Together they turn order sync from a fragile timer into a flow you can retry and re-run at will. In Boomi, persisted process properties hold the watermark and a lookup plus a Decision shape keeps creates idempotent. For the wider context, see our guide Application integration: connecting ERP, CRM and e-shop without the spaghetti, and continue with Error handling and retries in Boomi integrations.