Files
james.maesandClaude Opus 5.5 5afeefb1c2 Merge develop into feature/phase-g-edifact
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>
2026-10-14 08:50:06 -05:00

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.