Docs / Worked Example

One change, from map to evidence

A retailer sends purchase order PO0001. Your 850 map turns it into JSON for your application. Later your application sends an 810 invoice. Here is how mapping tests, an optional scenario, and optional external Git help you answer different questions about the same integration.

The map: did we extract the right value?

Use this small incoming map for an X12 004010/850. The final expression returns the JSON text:

purchaseOrderNumber = ST->BEG(03)
"{\"purchaseOrderNumber\": \"" + purchaseOrderNumber + "\"}"

Download the map source and its synthetic saved case. The case file is a regressionCases array, not a complete configuration bundle. In the browser, run its input, inspect the result, and use Save latest Run as test. In an exported mapping resource, the array belongs under spec.regressionCases.

The expectation is exactly {"purchaseOrderNumber": "PO0001"}, without a trailing newline. Change BEG(03) to BEG(02): the map still produces JSON, but the value becomes SA. The saved case fails. Restore BEG(03) and it passes again. The optional Mapper tutorial lets you practice the same mistake and repair without changing live configuration.

This test proves one sample's exact output. It does not prove the partner sent an order, received an invoice, or accepted either document.

The optional scenario: is the invoice part of the right conversation?

The order/invoice definition asks for one 850 followed by one 810 within 30 days, with matching purchase-order numbers. It also requires successful order mapping, an invoice total, a transport receipt within four hours, and a functional or implementation acknowledgment for the invoice.

The binding example connects those roles and steps to your partner and mappings. Replace its example IDs and definition hash using your workspace's validated values. The order fact reads ST->BEG(03); the invoice fact reads ST->BIG(04). These are the same X12 Mapper expressions you already use in mappings, not a second selector language. If your application handles the outgoing invoice without an outgoing runtime map, select an observation-only invoice target instead.

Validate and apply the binding, then exchange fresh documents and attach eligible transactions to a run. An invoice for PO9999 must not satisfy the conversation for PO0001, even if each document is individually valid. An invoice with the right number but missing acknowledgment is not a completed pass either. The conversation guide explains transaction eligibility and evidence.

The minimal synthetic invoice contains the matching PO number and total used by our local example test. It is not a partner-ready implementation guide. The downloadable files are learning inputs, not runtime evidence. A real pass requires the persisted transaction and acknowledgment evidence requested by the definition; it does not certify business payment or general compliance.

The configuration change: which version did we actually test?

In the browser, Save draft keeps editing work. Review & deploy prepares the change to live configuration. Optionally choose Verify saved cases on server to retain a result for that exact reviewed plan, then deploy and wait for runtime activation.

If a live mapping or partner dependency changes, aggregate apply refreshes affected scenario bindings in the same change. The new binding has its own revision and frozen configuration hash. An older passing run remains valid historical evidence of its old binding, but does not verify the new one. Changing only the saved test cases does not refresh bindings or republish the runtime mapping.

Open Change history. The saved mapping result describes the reviewed sample checks. Conversations in this change lists the exact binding revisions created or retired by that operation and each revision's latest retained run. Open the run to inspect evidence, or follow View configuration change from a tenant-applied run back to the operation that created its binding. A newer in-progress or failed run is not hidden by an older pass. No retained run means no evidence is available here, not success.

Optional external Git: keep the same source available to your team

When connected, external Git receives applied mapping source, cases, partner configuration, and scenario definition/binding source. Unsaved editor keystrokes and run results are not mirrored into Git. An accepted external edit goes through the same aggregate plan/apply path; conflicting edits pause synchronization for an explicit choice.

Keep using the browser unless you want local tools or CI. If you edit this map in Git, keep the same saved case, review the change, and check the resulting configuration history. A source commit alone is not a passing test. The Git guide covers permissions, branch ownership, and the optional provider-neutral runner.

If a later change causes a problem, Change history → Review recovery compares an earlier whole configuration with today's workspace. Recovery is a new reviewed change, not a deletion of history or a replay of documents. Run fresh saved tests if desired, and verify any recovered scenario bindings again. See reviewed configuration recovery before replacing later edits.

In short: the map produces the document your application needs; the scenario checks the related runtime conversation; configuration history tells you which exact source and binding each result belongs to.