Generate source for outbound mappings

When you set up an outbound integration in Tediware, you send your own data in whatever shape is natural for your system, and a mapping transforms it into the X12 document your partner expects. You never touch the EDI yourself.

The JSON your system emits is what we call a source.

Defining the source is the first thing you do on a new outbound mapping, and until now it meant staring at an empty editor. You already know what your system holds: a row of column names, a database table, a flat file you export for someone else. You just have to turn that into a JSON sample that lines up with, say, an 850 purchase order, and then write down what each field means.

That’s the kind of thing a model is good at, so now it’s in Tediware.

Generating a source

On the source pane of the mapping editor there’s now a Generate button next to Select and New. Open it and you get a box where you can paste or drag reference material from your own system: a CSV export, a SQL schema, an XML or JSON sample, or just a bare list of column names, one per line. You don’t have to tell it which format it is; it reads the content and works that out.

It then proposes a complete source: a representative JSON sample, a name, and a short semantics document describing the fields. You review it, refine it by chatting (“add a ship-from address”, “flatten the line items”), and when it looks right you click Accept. That drops the JSON and semantics into the editor as an unsaved source, where you edit it like anything else and save when you’re happy.

You don’t even need reference material. Point it at a transaction set with nothing else and it proposes a clean, workable source from the target alone.

Getting the shape right

The hard part wasn’t getting a model to emit JSON. It was getting it to emit the right kind of JSON.

Left alone, a model mirrors the EDI. It hands you a deeply nested structure with an object for every loop and a field for every element, named after segment positions like REF02 and N101. That’s a faithful picture of the X12 and a terrible source. Real systems don’t emit that. They emit flat, practical payloads with fields named in plain business language.

So Generate source stays flat by default. It emits scalar fields at the root and one or two arrays for the things that genuinely repeat, names like poNumber and shipToCity instead of segment coordinates.

The exception is hierarchical documents. An 856 advance ship notice really is nested: shipment, then order, then pack, then item. Collapsing that to keep it tidy would break the transformation, because the mapping needs every level to be there. So for those, generation follows the real hierarchy all the way down. The platform already knows which transaction sets are hierarchical and steers generation accordingly.

One more thing it gets right is codes. If your system already holds a value as a standard code (a status reason, a unit of measure, a country code), it keeps the code under a plain name like reasonCode or unitOfMeasure, rather than inventing a friendly synonym the mapping would only have to translate back.

Try it

Generate source is live in the mapping editor now. Open a mapping, select your target implementation, and hit Generate on the source pane. If you’ve got a flat file or a schema sitting around from another integration, paste it in and see what comes back.

If you try it and it gets something wrong, let me know. Email me at adrian@tediware.com.