Resolve guide loader, validator, demo and docs conflicts with phases c and e; HealthcareValidation now takes the standard-neutral EdiDocument. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
6.3 KiB
EDI local demo
From this worktree with Java 21:
./mvnw.cmd -B test-compile exec:java '-Dexec.classpathScope=test' '-Dexec.mainClass=com.kingsrook.qbits.edi.demo.EdiDemoServer' '-Dexec.args=8099'
Open http://localhost:8099/app/edi. Stop with Ctrl+C. On Unix use ./mvnw.
Next UI table routes are /app/<tableName> and record routes are /app/<tableName>/<id>.
Each launch creates a fresh in-memory H2 database, an in-memory synthetic payload key and a
fully anonymous demo session. No external credentials or services are required. Demo auth is
in test sources only and must not be installed in a real host.
The seed includes Northwind Retail (gateway), Harbor Logistics (SFTP) and Summit Market (HTTPS),
with codes NORTHWIND, HARBOR and SUMMIT and synthetic contacts at example.invalid.
It includes identities/agreements, guides/maps, orders with lines, shipments with cartons/items,
invoices and inventory. Forty synthetic inbound documents go through intake and the real inbox worker:
850s, 860s, validation errors, an unknown sender and a byte duplicate. Northwind's 855/856/810/846
pass the outbound worker and an in-memory gateway; incoming 997s reconcile some sent groups.
An overdue group, an exhausted send and several open exceptions provide operational examples.
Public self-signed certificates are generated in memory (two for expiry alerts, three for AS2); private keys are never persisted.
Pacific Wholesale (code PACIFIC) is the AS2 partner. An in-process BouncyCastle peer listens on a
random loopback port and the seed generates synthetic RSA certificates in memory (our ACTIVE and NEXT
certificates and the partner's; the private keys live only in the demo secrets map and are never
written to disk). The seed sends three 850s to the application's own AS2 hook (signed, encrypted;
two with base64 transfer encoding), which answers with signed MDNs (edi_as2_mdn rows, shown as
"AS2 MDNs" on the inbound message); the 997s go back over AS2 as well. An 855 built from a source record is sent
over AS2 to the peer, which verifies the signature and MIC and returns a signed synchronous MDN
(the outbound message becomes DELIVERED with its transport_mic). One more message goes to the
asynchronous transport pacific-as2-async: it stays SENT until the peer posts the MDN to
/qqq/hooks/edi/as2/pacific-as2-async/mdn. The running demo serves
POST /qqq/hooks/edi/as2/pacific-as2 (and .../mdn) on the same port; Test Connection,
Export Public Certificate and Promote Certificate (on demo-as2-next) work on the AS2 records.
Phase d adds warehouse and logistics traffic, seeded last so the retail scenarios above are
unchanged. Harbor Logistics (the 3PL) gets a gateway OUTBOX transport (the partner pulls over SFTP)
and sends three valid 940 shipping orders and one with a bad unit; the orders and lines land in
sample_wms_order, and two shipments (one short) go out as 945s. A fourth partner, Ridgeline Freight
(code RIDGELINE, gateway transport), receives two 204 load tenders (the second a change) and sends
four 214 status events (one rejected with a bad status code) that build sample_shipment_status.
The in-memory gateway accepts every send, and the rejected documents produce rejecting 997s.
Phase g adds a fifth partner, Lindqvist Retail AB (LINDQVIST), after the existing scenarios.
Its D96A test agreement receives three synthetic ORDERS documents through the durable inbox;
orders and lines appear in sample_order, and CONTRLs enter the gateway queue. ORDRSP, DESADV
and INVOIC are mapped from the retail sample records, delivered through the in-memory gateway,
and reconciled by incoming accepted CONTRLs. Look for ORDERS with status APPLIED and the three
outbound message types with status ACKNOWLEDGED. Released delimiters in buyer/item identifiers
exercise the same parser used for partner input. All contacts remain synthetic example.invalid.
The SFTP/HTTPS partner settings are illustrative .invalid destinations. Their agreements have
no outbound transport, so they cannot contact a real partner; resulting acknowledgement send
retries are visible. Northwind, Harbor, Ridgeline and Lindqvist have configured outbound documents; the healthcare scenario adds its own. The in-memory gateway
is restored after the intentional dead-letter scenario. Standard Send As EDI, Test Connection,
Resend, Resend As New and Cancel actions are available. The gateway stores bytes in memory;
it does not expose a separate partner download UI.
Acceptance boots a random-port QApplicationJavalinServer, loads Next UI, renders and serializes every registered widget through core RenderWidgetAction/JsonUtils, and POSTs every home and child-list widget over HTTP using seeded parent records. It also checks configuration JSON, metadata, table queries, labels, field order, foreign-key value sources and PHI-safe record labels. Next UI defaults table queries to descending ID (newest records first); activity child lists use descending creation date and ID. The home exception queue puts OPEN before IN_PROGRESS, newest first within each status. RC.5 has no table-level default-sort metadata to override Next's sort. Inbound message labels use external IDs because filenames are classified as PHI. Light/dark visual layout and production scheduler/gateway deployment remain host acceptance.
Phase e adds a fifth partner, Cedar Health Clearinghouse (CEDAR, PHI enabled), after the existing
retail and logistics scenarios. It sends seeded synthetic professional and institutional claims,
a remittance, a professional claim with a one-dollar balancing error (SNIP 3), and a professional
claim missing its dependent patient loop (SNIP 4). Both business-rule errors are accepted with
errors (E) and open exceptions. Value-free 999s go to the in-memory clearinghouse outbox.
A synthetic eligibility request goes out as a 270 and a matching-trace 271 arrives. Clinical keys
appear only in the classified PHI key column, not the ordinary document key or record labels.
The healthcare sample maps and tables are test-only. Patients are seeded Testpatient Alpha
fixtures, member IDs begin with SYN, and 1234567893 is a documented NPI checksum test value.
The host database must be encrypted for real PHI; this disposable demo uses synthetic data only.
The System widget shows format-only external code validation until a provider is registered.
Inbox and interchange records offer the audited Download Raw Document action.