For an inherited GoXML Transform integration, the most useful starting point is a documented mapping: what enters, which rules and lookups apply, what leaves, and what happens when a record fails. Preserve that behavior as evidence before replacing the runtime.
Identify the historical product and installation
GoXML Transform belongs to the XML Global/Xenos integration product history. A 2003 company filing explicitly names GoXML Transform, Registry, and Messaging in a proposed transaction. That historical record identifies the product family; it establishes no current availability or support status.
Record the exact installed product, version, deployment mode, license information, runtime dependencies, and locally held manuals. Distinguish the transformation engine from surrounding scheduling, communications, or database components. A familiar product name alone is insufficient to reproduce a working integration.
Keep a protected copy of the configuration and mapping assets through your normal backup process. Confirm that a restoration can actually load them. This guide uses a generic example because vendor-specific commands and compatibility need documentation for the installation being maintained.
Inventory the complete mapping
| Record | Example question | Why it matters |
|---|---|---|
| Input contract | Which fields, encodings, and record boundaries are accepted? | Defines the population a replacement must handle. |
| Lookups and joins | Which database or table supplies customer regions? | External data can change the output without a mapping edit. |
| Conversions | How are blank values, dates, and quantities interpreted? | Implicit defaults often cause migration differences. |
| Output and failures | Which destination receives ready and rejected records? | Reconciliation must account for both paths. |
| Execution context | What schedules, retries, credentials, and transaction boundaries apply? | A correct transformation can still be delivered twice or incompletely. |
Choose several representative mappings, including one with nested data and one with lookup failures. Record the input and lookup snapshot together. Keep original business data within its authorized environment; create synthetic examples for external discussion.
See how a lookup changes the record count
In the fictional exercise, order O1 belongs to customer C1 and contains two units. O2 belongs to C9 and contains one unit. The customer lookup contains only C1, whose region is North.
| Order | Customer | Quantity | Region | Disposition |
|---|---|---|---|---|
| O1 | C1 | 2 | North | Ready |
| O2 | C9 | 1 | Missing | Review |
An inner join against that lookup would retain O1 and lose O2. A left join preserves both orders while exposing the unmatched customer. PostgreSQL's table-expression documentation explains the underlying join semantics. Which behavior is correct depends on the business contract.
Extract the XML labs pack, install lxml, and run python mapping.py. Expect two orders and three total units; O2 retains its original customer ID, has a null region, and is marked for review. This is ordinary Python demonstrating a mapping decision, not GoXML syntax or a replacement GoXML engine.
Compare behavior before switching delivery
Run the old and proposed implementations on the same controlled inputs and lookup snapshots. Compare business keys, record counts, totals, nested relationships, rejected records, and error classifications. Decide which lexical differences are acceptable; an XML tree comparison may ignore details that signed or byte-sensitive downstream consumers require.
Add cases for missing lookups, duplicate keys, empty and absent values, invalid numbers, unexpected namespaces, large records, interrupted runs, and retries. A duplicate lookup row can multiply output just as a missing row can remove it. Reconcile accepted plus rejected records to the defined input population.
Resolve mismatches with the business owner. Document intentional corrections separately from compatibility requirements. For a rollout, define a reversible cutover and observe duplicate delivery, backlog, and downstream acknowledgments. Keep a recoverable checkpoint until the agreed acceptance period has passed.