Mapping a JSON order to XML with Boomi maps and profiles

The e-shop sends new orders as JSON. The ERP accepts orders as XML. Between the two sits a mapping, and its quality decides whether orders land in the ERP correctly or whether someone retypes them every morning. This article explains how to approach a mapping like this in any tool, then builds it in Boomi.

Why “just copy the fields” fails

On paper the two documents look similar: both have a customer, a date, some lines and a total. In practice they differ in ways that only appear with real data:

Structure. The e-shop nests customer.billing.city, the ERP wants a flat <BillCity>.
Formats. The e-shop sends 2026-10-23T14:05:00Z, the ERP wants 23/10/2026.
Codes. The e-shop says "payment": "card", the ERP expects payment method 07.
Composed fields. The ERP has one <CustomerName> field, the e-shop has firstName and lastName.
Repeating data. Each order has a variable number of lines that must become repeating XML elements.

A field-by-field copy handles none of this. The approach that works is to describe both formats precisely first (with schemas or sample-based profiles), write down a rule for every target field, and then implement and test the rules against real samples.

The example

The source order from the e-shop:

{
  "id": "WEB-58211",
  "createdAt": "2026-10-23T14:05:00Z",
  "payment": "card",
  "customer": {
    "id": "C-1042",
    "firstName": "Ελένη",
    "lastName": "Παπαδοπούλου",
    "billing": { "street": "Ερμού 12", "city": "Αθήνα", "zip": "10563" }
  },
  "lines": [
    { "sku": "TSH-001-M", "qty": 2, "price": 19.90 },
    { "sku": "MUG-014", "qty": 1, "price": 8.50 }
  ]
}

The order the ERP expects:

<SalesOrder>
  <ExternalRef>WEB-58211</ExternalRef>
  <OrderDate>23/10/2026</OrderDate>
  <CustomerCode>C-1042</CustomerCode>
  <CustomerName>Ελένη Παπαδοπούλου</CustomerName>
  <BillCity>Αθήνα</BillCity>
  <PaymentMethod>07</PaymentMethod>
  <Lines>
    <Line><ItemCode>TSH-001-M</ItemCode><Qty>2</Qty><UnitPrice>19.90</UnitPrice></Line>
    <Line><ItemCode>MUG-014</ItemCode><Qty>1</Qty><UnitPrice>8.50</UnitPrice></Line>
  </Lines>
</SalesOrder>

Before building anything, write the rules in a short table: target field, source field, rule. For example OrderDate ← createdAt, convert to local date in dd/MM/yyyy; PaymentMethod ← payment, lookup. This table is your mapping specification and the reference for testing.

Building it in Boomi

In Boomi, the shape of each document is described by a profile, and the transformation between two profiles is a Map component, used in a process through the Map shape.

Step 1: Create the profiles from samples

Create a new Profile component of type JSON. Use the import option and select a file containing the sample order above. Boomi builds the element tree from it, including lines as a repeating array.
Review the generated elements. Set the data type where it matters: qty and price as numbers, createdAt as a date/time with the mask that matches the e-shop’s format. Keep id and sku as character data, so codes with leading zeros survive.
Create a Profile component of type XML and import the ERP’s XSD if you have one, or a sample XML order if you don’t. An XSD is better: it brings in required fields, lengths and types.
Check that <Line> is marked as repeating (max occurs greater than one). If you imported from a sample with a single line, you may need to adjust this by hand.

Use a sample with real Greek characters. It is the cheapest way to discover encoding problems early.

Step 2: Create the Map

Create a new Map component and choose the JSON profile as the source and the XML profile as the destination. Then connect the fields:

Direct links. Drag id to ExternalRef, customer/id to CustomerCode, customer/billing/city to BillCity.
Lines. Link lines/sku to Line/ItemCode, qty to Qty, price to UnitPrice. Because both sides are repeating, Boomi creates one <Line> per array entry.

Step 3: Add map functions

Map functions sit between source and destination fields and transform values on the way. Add them from the functions area of the map.

Date format. Add a Date Format function (in the date category). Set the input mask to match createdAt and the output mask to dd/MM/yyyy. Alternatively, if both profile elements are typed as date/time with their own masks, Boomi converts between the masks automatically when you link them directly. Pick one approach and use it consistently.

There is a catch here: createdAt is in UTC. An order placed at 01:30 Athens time is still the previous day in UTC. If the ERP’s order date must be the local date, convert the time zone before formatting. Depending on your release, this can be done with date masks that include the offset or with a small scripting function; test it with an order placed just after midnight.

Concatenate. Add a String Concat function (in the string category), link firstName and lastName as inputs, set a space as the delimiter, and link the output to CustomerName.

Lookup. For payment methods, the quickest option is a Simple Lookup function: a small two-column table inside the map, for example card → 07, cod → 03, bank → 06. Link payment to its input and its output to PaymentMethod.

A Simple Lookup is fine for a prototype. For codes that change or differ between environments, use a Cross Reference Table instead; we show how in Translating codes between systems with Boomi Cross Reference Tables.

Defaults. For target fields with a fixed value, such as a company code, use a default value on the destination element instead of a function.

Step 4: Put the map in a process

Create a test process: a Start shape set to no data, a Message shape containing the sample JSON, then the Map shape with your map, then a Stop shape. In production, the Message shape will be replaced by the e-shop connector or listener, but for developing the map you want a fixed, repeatable input.

A practical note about the Message shape: it treats curly braces as placeholders for variables, so JSON pasted into it has to be wrapped in single quotes to be taken literally. Any apostrophe inside the JSON then needs to be doubled.

Step 5: Test

Click Test, select a test runtime (an Atom or a test cloud attached to your account) and run.
When the run finishes, select the Map shape and open the document that came out of it. Check the XML against the expected order above.
Check the details that usually go wrong: Greek characters intact, two <Line> elements, prices with a decimal point, OrderDate in the right format and day.
Change the sample and run again: an unknown payment method, a missing lastName, an order at 23:50 UTC. Note what the map does in each case, and decide whether that is what you want.

The exact panel names in Test mode can change between releases, but the idea stays the same: every shape keeps the documents that passed through it, so you can see where a value went wrong. More on this in Testing Boomi processes during development.

Before you go live

Decide what happens with unknown codes. A lookup with no match returns an empty value by default. Usually you want the order to fail loudly instead, for example with a Decision or Business Rules shape after the map.
Check lengths against the ERP. If CustomerName is limited to 50 characters, decide whether to truncate or reject, and do it on purpose.
Keep the samples. Store the sample documents with the process documentation. They are your regression tests when the e-shop or the ERP changes.
Keep the mapping specification in sync. When you change the map, update the table, and the other way round.

Summary

A good mapping starts with precise descriptions of both formats and a rule for every field. In Boomi, profiles hold the descriptions, the Map holds the rules, map functions handle formats, concatenation and lookups, and Test mode lets you check each change against real samples. For the wider view of formats and pitfalls, see our data mapping and formats guide.