Skip to main content

Implementation Patterns

Before you implement connector logic, understand how your ERP integration is expected to behave based on how your company uses the ERP and through ERP capability analysis. You may choose to plan integration direction with your MachineMetrics contact before deep implementation work.

  • ERP-driven
  • ShopPulse-driven

What the patterns mean​

The two patterns describe which system is the source of truth and which direction data flows on each sync cycle. A single connector usually runs cycles in both directions; the pattern names describe the intent of a cycle, not mutually exclusive modes.

ERP-driven means that the ERP state the connector projects into MachineMetrics includes labor ticketing. These are your from-ERP cycles: the connector reads work orders/jobs, operations, schedules, and reference data from the ERP and creates or updates the corresponding MachineMetrics entities so the shop floor sees the right job, operation, and operator activity at each machine. This can then be compared real-time against actual activity as measured by MachineMetrics: machine signals, run/cycle counts, and operator actions. Note that any changes made directly in MachineMetrics to the imported data would be overwritten on the next sync cycle.

ShopPulse-driven means the shop-floor reality captured by MachineMetrics (job/operation selection, part counts, labor) is written back to the ERP, typically from input on the operator's tablet. In this case, the from-ERP cycles still provide the full context (orders/jobs, operations, schedules, and reference data), and it is yet possible to import labor ticket information from the ERP for a historically complete picture of labor within MachineMetrics. During the to-ERP cycles the connector will export produced quantities and operator activity to the ERP.

Decisions within a pattern​

Choosing a pattern does not fully specify a connector. Within it you make per-entity decisions, including:

  • Which entities each direction owns. Jobs and operations are commonly ERP-driven (read-only mirror), while produced quantities and labor are often ShopPulse-driven (written back). Decide this entity by entity rather than for the connector as a whole.
  • Whether labor tickets are included in from-ERP cycles. If labor is authored in the ERP, you may pull existing tickets to give operators context. If MachineMetrics is the source of truth for labor, you may not read labor on from-ERP cycles at all and instead only write tickets back on to-ERP cycles — avoiding round-trips and conflicting edits.
  • Whether parts, operations, or routings are synthesized from work-order data. Some ERPs do not expose clean, discrete part or operation entities through their API. In those cases you may synthesize MachineMetrics operations (and the part references they carry) from work-order/operation rows — deriving them from the order header and its operation lines — rather than from a dedicated parts or operations endpoint. How to do so is documented in the SDK reference — see Documentation.
  • Write-back scope. Whether to write back labor tickets that are not yet closed, and how to handle records the ERP considers closed or posted.

Capture these decisions as connector requirements on the ERP discovery checklist so they stay next to your implementation and can be handed to an AI assistant.

Efficiency and API-cost considerations​

ERP and MachineMetrics APIs are shared, rate-limited, and are for some ERPs sometimes slow. Design sync cycles to do the least work that keeps data correct.

How to accomplish these goals is provided in the SDK documentation.

  • Do not ask for all data every cycle. Prefer incremental/delta queries: filter by a modified-since (or equivalent) timestamp, by status, or to the set of currently open/active work orders, instead of full re-pulls on every run.
  • Bound the working set. Scope reads to a relevant window (open jobs, recent activity) rather than the entire ERP history; full backfills should be deliberate, one-time, or low-frequency operations.
  • Be conservative with both MM and ERP APIs. Respect rate limits, batch and paginate requests, reuse connections/auth tokens, and back off on errors instead of retrying tightly. A misbehaving connector can degrade the ERP for its normal users.
  • Cache slow-changing reference data. Look-up tables (resources, work centers, status codes, part masters) rarely change between cycles — fetch them infrequently and reuse them, rather than re-reading on every job.
  • Use separate cadences per direction and entity. Context that changes slowly (schedules, routings) can sync on a longer interval than fast-moving signals (counts, labor). Match cycle frequency to how quickly each entity actually changes.
  • Write only what changed. On to-ERP cycles, make writes idempotent so a retried cycle does not duplicate tickets or quantities.

Develop against a sandbox​

Build and iterate against a non-production ERP sandbox, never the live system. Sync cycles read broadly and during to-ERP cycles write back labor tickets, quantities, and operation status; an immature connector pointed at production can create bad records, double-post, or hammer shared APIs. A sandbox lets you confirm mappings, exercise both from-ERP and to-ERP directions, and replay edge cases safely before cutover. Treat acquiring sandbox base URLs, credentials, and representative data as part of ERP discovery, and keep sandbox and production settings in separate environment configurations so promotion is a config change, not a code change. Validate write-back against the sandbox first; only point at production once mappings and cadences are confirmed and agreed with your MachineMetrics contact.