Jira + ERP + MES:
integration step by step

Imagine a machine on the shop floor has just stopped an important order. The MES has known about it for a few minutes. The ERP still sees the order as "in progress". The IT help desk has not received any ticket yet. When the technician finally opens Jira, they lose more minutes gathering context from three different systems. The lack of integration between IT, ERP and production systems means that important operational events get lost in silos or reach the help desk with a delay. This article describes how to build the integration that prevents that: from architecture, through REST APIs, to production monitoring.

Why integrating three systems is hard

Integrations Jira-ERP sound like a weekend project until you start. Reality turns out to be far more complex, and for concrete architectural reasons, not random difficulties.

Three different data models

Jira thinks in terms of issue, project, workflow, SLA. ERP (Comarch, SAP, Sage) sees the world through orders, invoices, counterparties, fixed assets. MES operates on work orders, operations, machines, batches, quality. These three ontologies do not map 1:1; every transformation requires business decisions, not just technical ones.

Three different change frequencies

The ERP changes data on a scale of minutes to hours (new order, invoice status change). Jira operates on minutes to days (ticket opening, status change, comment). MES generates events every second: machine alarms, production parameter changes, sensor readings. A synchronous integration that works for the ERP can completely fall over under the load from the MES.

Three different API contracts

Jira offers a modern REST API with pagination, webhooks and good documentation. Comarch ERP XL uses a native API based on a DLL library (CDN_API.DLL); integration with Jira requires middleware or a proxy service. Older installations also use a SOAP or COM+ interface. MES systems often have no REST API at all - they communicate over OPC-UA, MQTT, CSV files or proprietary binary protocols. That requires separate adapters for each layer.

Integration architecture: reference model

The most durable pattern for Jira+ERP+MES integration is event-driven hub-and-spoke with a central middleware layer. Avoid point-to-point integration: with N systems it generates N x (N-1)/2 connections - for 3 systems that is 3 connections, for 5 systems it is already 10.

Responsibility split (MDM)

It is critical to establish a Master Data Management split - which system owns which data:

• ERP: master for counterparty data, products, price lists, service contracts, fixed assets (serial numbers, locations).
• MES: master for production orders, machine operations, process parameters, batching, quality data.
• Jira: master for IT incidents, service requests, SLAs, history of communication with the client, escalations.

Every system can read data from the other systems (through middleware). Writes should happen only through the master system: middleware never overwrites data while bypassing the owner. If you want to understand general system integration patterns via API (REST, webhooks and middleware), read our comprehensive guide to system integration.

Jira ↔ ERP step by step (Comarch ERP XL + REST API)

Below we cover a concrete, most common scenario: a service ticket in Jira SM is to be automatically enriched with counterparty and fixed asset data from Comarch ERP XL, without manual copying.

// POST /api/token
{
  "grant_type": "client_credentials",
  "client_id":     "your_client_id",
  "client_secret": "your_client_secret",
  "scope":         "api"
}

// GET /api/Kontrahenci?nip={nip}
Authorization: Bearer {token}

// ERP response:
{
  "Id":         "KNT-001234",
  "Nazwa":      "Acme Manufacturing Sp. z o.o.",
  "OpisTrwaly": "Premium service contract until 2027-06-30",
  "OpiekunId":  "USR-042"
}

// PUT /rest/api/3/issue/{issueKey}
{
  "fields": {
    "customfield_10201": "KNT-001234",          // ERP counterparty ID
    "customfield_10202": "Acme Manufacturing",   // Company name
    "customfield_10203": "Premium until 2027-06-30", // Contract status
    "priority": { "name": "High" }               // from ERP SLA conditions
  }
}

Jira ↔ MES: specifics of the production environment

Integration with the MES plays by different rules than integration with the ERP. Three key differences you need to address at the design stage:

1. Real-time events, not polling

The MES generates machine alerts on a second-level frequency. Do not use HTTP polling to read MES events. Instead, configure push via MQTT or WebSocket. The middleware subscribes to a MES topic (mes/line1/alarm/critical) and on each event decides whether to open a new Jira ticket, update an existing one, or ignore it (duplicate).

2. Filtering and deduplication at the middleware level

A machine can generate 200 alarms of the same type within a minute (flapping). The middleware must implement window deduplication: if an alarm of the same type from the same machine appeared in the last 5 minutes, do not create a new ticket. Add a note to the existing one.

3. Production context in the ticket

A Jira ticket created from a MES alarm should contain the full context: work order number, machine/line designation, the value of the parameter that crossed the threshold, the last 10 operations on that machine. Without that, the IT technician cannot assess the severity of the incident without calling the shop floor, which negates the benefits of the integration.

Middleware tools: comparison

The choice of middleware platform has the greatest impact on the cost of maintaining the integration over 3-5 years. Below is a comparison of the five most popular options for an SME manufacturing company:

For most SME manufacturing companies, n8n self-hosted offers the best flexibility/cost ratio. It supports REST, MQTT (via a custom node), webhooks, queueing, retry logic and has a built-in flow monitoring panel. A VPS deployment from 200 PLN/month will cover 90% of integration scenarios.

5 typical pitfalls and how to anticipate them

Maintaining and monitoring the integration

An integration deployed without monitoring is an integration that will break silently. You will find out about it from the production manager, not from a dashboard. Three monitoring layers I consider mandatory:

Layer 1: Connection health-check

Periodic ping (HEAD or GET /health) to each system every 60 seconds. If any one does not respond within 5 seconds for 3 consecutive attempts, send an alert to Teams/Jira/email. Implementation cost: 30 minutes in n8n or a simple Lambda function.

Layer 2: Throughput metrics

Monitor how many messages pass through each flow per hour. A sudden drop to zero usually means something has broken. Configure an alert when throughput falls below 20% of the average from the last 7 days for more than 30 minutes.

Layer 3: Dead Letter Queue

Every message that could not be processed after N attempts goes to the DLQ. The alert should fire immediately once the DLQ is not empty and require manual analysis, not automatic retry. The DLQ is your "canary in the coal mine" for data transformation errors.

FAQ: most common questions