MGCLattice Intake Accelerators

Vertical intake accelerator bundles for Lattice. An intake accelerator is a packaged, end-to-end intake scenario built entirely on surfaces the Lattice model already has:

• File Ingestion (MGCLatticeFileIngestConnection + the ingestion pipeline) as the source,
• an input format + sample payload (CSV / JSON / XML / fixed-width),
• a field mapping to the target, and
• a target: a Lattice service operation (AxServiceGroup / AxService) or a Lattice* OData entity.

A bundle is a folder of design-time artifacts - nothing here is deployed X++; bundles describe how to configure existing capabilities.

What ships in a bundle

bundles/<bundle-id>/
  manifest.json      # the versioned bundle manifest  (schema/bundle.schema.json)
  sample.<ext>       # a representative sample payload
  mapping.json       # source-field -> target-field mapping (schema/mapping.schema.json)
  transform.liquid   # illustrative Liquid transform (optional but recommended)
  README.md          # what it does, verified target, known gaps

The two target styles

Grounded in how the model actually works:

Style	When	How it reaches the target
customService	A typed service operation exists (e.g. AP invoice register, SO confirm)	The ingestion custom-service dispatcher (MGCLatticeFileIngestCustomServiceDispatcher) invokes a class implementing MGCLatticeIFileIngestServiceTarget.handleIngestedContent(str). The generic adapter MGCLatticeFileIngestServiceInvokeTarget bridges typed contracts via a routing envelope - see below.
odataEntity	A writable Lattice* OData entity is the natural landing spot	Transformed records are inserted into the entity's collection over OData.

Platform fact (the integration loop is closed)

MGCLatticeFileIngestCustomServiceDispatcher resolves the connection's TargetServiceClass at runtime and, for safety, only invokes classes implementing MGCLatticeIFileIngestServiceTarget, passing the Liquid-transformed content as a single str. The generic ingest-target adapter MGCLatticeFileIngestServiceInvokeTarget implements that interface: set TargetServiceClass = MGCLatticeFileIngestServiceInvokeTarget + TargetServiceOperation = handleIngestedContent, and have the transform emit a routing envelope { "service": .., "operation": .., "requestKey": .., "request": { .. } }. The adapter completes request with the run context, deserializes it into the operation's contract and invokes it via MGCLatticeServiceTestRunner::run. So the customService style is executable end-to-end - see Authoring, section 4b. The connection must list the operation the envelope names (Service.operation) in Allowed service operations, because the adapter refuses any other operation and an empty list allows none. The common members every Lattice posting service validates are filled by the adapter when the template leaves them empty: RequestId is a name-based GUID of the connection, the legal entity, the operation and the envelope's requestKey (a stable external id such as an order number), so a record sent again replays instead of posting twice; LegalEntityId and UserContext are the company and user the processing batch job runs as; CorrelationId is shared by the records of one file. Remaining released-blocking questions are per-bundle policy items in each productDecisions.

Authoring a new bundle

1. Pick the vertical and the real target. Verify it in the AOT:
   • Lattice services: Lattice/AxServiceGroup/* + Lattice/AxService/* (operation names) and the request/line …Contract classes for DataMember field names.
   • OData entities: Lattice/AxDataEntityView/MGCLattice*Entity.xml -> PublicEntityName / PublicCollectionName and the mapped field names. Do not invent names.
2. Create bundles/<bundle-id>/ and write manifest.json against schema/bundle.schema.json.
3. Add a sample.<ext> payload matching source.fileFormat.
4. Write mapping.json against schema/mapping.schema.json; every target must be a real contract DataMember or entity field, every source must be a field present in the sample.
5. Record open product questions in productDecisions.
6. Validate (see tools/validator).

Schemas

• schema/bundle.schema.json - the manifest format (formatVersion 1.0).
• schema/mapping.schema.json - the mapping document format.

Bundles

Bundle	Vertical	Source	Target
vendor-invoice-intake	P2P	Sftp / Csv	customService → MGCLatticeVendorInvoiceJournalService.postInvoiceRegisterJournal
sales-order-intake	O2C	Blob / Json	customService → MGCLatticeSalesOrderCaptureService.createSalesOrder
asn-product-receipt-intake	Logistics	Sftp / Xml	customService → MGCLatticePurchaseOrderPostingService.postPurchasePackingSlip
customer-payment-intake	O2C	Sftp / FixedWidth	customService → MGCLatticePaymentJournalService.postCustomerPaymentJournal
opportunity-intake	O2C	Blob / Csv	odataEntity → LatticeOpportunity

Between them the catalog covers both target styles and all four source formats, each on the scheduled file ingestion pull: a JSON record and a CSV row reach the Liquid transform as a JSON object, an XML record is converted to JSON with FileIngestionService.ConvertXmlToJson (local names, attributes as plain properties; see Authoring, section 4), and a fixed-width file yields one JSON object per non-blank line through the connection's FixedWidthColumnSpec. opportunity-intake is the only odataEntity exemplar.

Activation

A bundle carries structure; it cannot carry tenant values (endpoints, credentials, journal names, offset accounts). Each manifest declares those blanks in an activation.parameters[] block - the typed, first-class generalization of the older batching.provisioningRequired list - and bundlecatalog plan <id> turns them into an ordered provisioning plan, a fill-in parameter file, and a completeness check.

Full design, the four parameter scopes, the __parameterKey__ transform convention, and the current limitations: Activation.

Publishing model: content catalog / registry

Accelerators are published as a content catalog / registry: bundles live under bundles/ and a generator emits a machine-readable index plus a browse page.

• tools/catalog - dotnet run -- catalog scans bundles/*/manifest.json, validates each (reusing the validator), and writes catalog/registry.json (index) + catalog/catalog.html (self-contained searchable browse page). dotnet run -- resolve <bundleId> validates a bundle and returns its loader path for a consumer to provision. dotnet run -- plan <bundleId> prints the activation plan and can emit/check a tenant parameter file.
• Full walkthrough - folder layout, schemas, routing envelope, add-a-bundle, and consumer provisioning - is in Authoring.

Validator

tools/validator - a small .NET console app that parses a bundle, checks it against the schemas, and verifies mapping/target cross-references resolve. See the bundle validator. Its checks live in tools/validator/BundleValidator.cs, which the catalog tool links in so validation means the same thing in both places.

Scope note: this folder (Tools/MGCLatticeIntakeAccelerators) is standalone tooling/design content. It does not modify the X++ model.