ObjMgrLog  Info  ::  ARTICLES

Converting Siebel EAI XML to JSON (for REST APIs and Open UI)

August 26, 2026

Siebel is an XML system. EAI Siebel Adapter queries return XML hierarchies, integration objects are XML, and the whole EAI layer is built around it. That was fine when the systems Siebel talked to also spoke XML. But the modern world runs on JSON: REST APIs expect JSON payloads, and Open UI / browser JavaScript is far happier with a JSON object than an XML document.

So sooner or later you need to convert between the two, inside Siebel. And it turns out that’s trickier than a one-line “XML to JSON” makes it sound.

Two places this bites

Calling a REST API with Siebel data. You run an EAI Siebel Adapter query to get the records you need. The Adapter hands you XML. The REST API you want to call expects JSON. Somewhere in between, that XML has to become a JSON payload - correctly shaped, correctly typed - before you can POST it.

Using query results in Open UI. You’ve got Siebel data you want to work with in a browser-side customization. As XML, navigating it in JavaScript means walking a DOM. As JSON, it’s just an object - data.contacts[0].lastName - and everything downstream gets simpler. But first something has to turn the Adapter’s XML into that object.

Why it’s not just “XML to JSON”

A naive conversion gets you most of the way and then leaves you with two classic problems.

The single-element array problem. In XML, a repeating element that happens to appear once looks identical to an element that only ever appears once. Convert blindly and a list with one item becomes a single object, not a one-element array. Your downstream code, written to loop over a list, breaks the moment real data returns exactly one row. You need to be able to force specific paths to always be arrays, so “one row” and “many rows” produce the same shape.

The typing problem. Should <count>1</count> become {"count":1} (a number) or {"count":"1"} (a string)? It depends entirely on who’s consuming it. JavaScript wants a real number so it can do arithmetic; a strict data-exchange target might want everything as quoted strings. A good conversion lets you choose, rather than guessing.

On top of that, real integrations usually need to reshape the result - strip an outer envelope the Adapter added, or add one the target API expects - before the JSON is actually usable.

What clean conversion looks like

The goal is to convert and reshape in one step, so the JSON that comes out is ready to use rather than “converted but still wrong shape.” Concretely, a good converter for Siebel should let you:

• Convert XML to JSON and JSON back to XML, both directions.
• Choose whether values come out typed ({"count":1}) or as strings ({"count":"1"}), depending on whether JavaScript or a data target is consuming them.
• Force chosen paths to arrays, so a single repeating element doesn’t collapse to an object and break your loop.
• Strip or add an envelope so the outer structure matches what the API or component expects.
• Extract specific values by path when you only need a few fields, not the whole document.
• Control the XML declaration’s encoding when converting back to XML, for consumers that are strict about it.

That’s the gap the SRS XML/JSON Converter fills - a Siebel Business Service that does the conversion and the reshaping together, so the Adapter’s XML becomes a REST-ready JSON payload, or a query result becomes a clean object for Open UI, in one call. Paired with the SRS HTTP Client, it’s the full path from “query Siebel data” to “POST it to a REST API.”

The takeaway

Converting between XML and JSON in Siebel is easy to start and easy to get subtly wrong - the single-element array and the typing question catch almost everyone, and reshaping the envelope is usually needed on top. If you’re bridging Siebel’s XML world to REST APIs or Open UI more than once, it’s worth doing the conversion with something that handles those cases deliberately, instead of discovering them one production bug at a time.