Enterprise integration for systems that were never meant to talk

The hardest integrations are not the modern SaaS-to-SaaS ones. They are the ERP that has been running for fifteen years, the trading partner that only speaks EDI, the database that cannot leave your network for compliance reasons, the vendor system whose only interface is a DLL.

Many integration platforms treat EDI and legacy protocol support as a separate, bolted-on B2B product with its own pricing and its own learning curve.

Enterprise integration in Neblex Integration Fabric connects legacy and modern systems through one platform: it ships with 239 built-in connectors and growing, including on-prem systems, so those integrations run through the same flows, the same audit trail, and the same governance.

Applications integrate four classic ways: file transfer, a shared database, a synchronous API (a remote procedure call), and asynchronous messaging. A shared database couples every system to one schema, so Neblex works the other three, and a single flow can start with a file drop, call an API to enrich it, and publish the result to a message broker without changing tools.

EDI document exchange over AS2, in the standards your trading partners already use (X12, EDIFACT), is built into the core connector library, not a bolt-on.

SFTP, FTP, SSH, SOAP, and OData sit alongside modern REST and webhook connections, and more than a dozen messaging and event-streaming protocols (AMQP, MQTT, the Kafka protocol, NATS, and the managed cloud queues and streams) are first-class too. A single flow can consume from a queue, transform the payload between XML, JSON, flat file, and EDI, and push the result to an ERP, a REST API, or a trading partner without leaving the platform.

When a system has no API, no supported protocol, and no connector at all, there are still two ways in. The Native Library step calls an exported C-ABI function in a vendor DLL or shared library (.dll, .so, .dylib) directly, in a short-lived crash-contained process on an On-Prem Worker, against a library the operator has approved. That process is a crash boundary, not a security sandbox: native code keeps the worker account's file and network access and must be trusted explicitly. The SSH adapter runs a command, or a bash, Python, PowerShell, or cmd script, on any host that accepts SSH, Windows with OpenSSH Server included.

Flows are built three ways, and you can move between them on the same flow:

• Natural language. Describe the flow to Matt, the Neblex AI Assistant built into the builder. Matt drafts the canvas, maps fields, and explains steps. It runs on the platform's builder model by default, or on a model you connect for the building experience only. That setting never supplies a model or credential to deployed agents, their tools, knowledge search, apps, or flows.
• Native builder. Assemble steps, branches, and connectors on the visual canvas.
• MCP. Create, change, publish, and run flows programmatically, so an external client or agent can build on Neblex directly, with consent scopes for operating, authoring, and publishing.

Agents, forms, apps, data tables, and connections have their own builders and the same MCP surface.

Messaging is the backbone of most enterprise integration, so brokers and event streams are first-class connectors, not an afterthought. Neblex speaks more than a dozen messaging and event-streaming protocols:

• Broker protocols. AMQP 0-9-1 and AMQP 1.0, MQTT, the Apache Kafka protocol, and NATS, JetStream included.
• Managed cloud queues and streams. AWS SQS, SNS, and Kinesis, Google Cloud Pub/Sub, Redis Streams, Salesforce Pub/Sub for change events, WebSocket and Server-Sent Events, and Azure Event Hubs through its Kafka endpoint.
• Both directions on one connection. Every connection can publish (send one message to one topic or queue) and subscribe (a live-stream step that receives everything matching a topic filter). The direction is set on the step, not the connection.
• Delivery controls. Deduplicated intake keyed per flow and trigger, at-least-once queueing with a stated window, and exactly-once effects wherever the destination honors an idempotency key. A durable consumer identity stays stable per flow, with a choice of an isolated consumer per flow or shared, competing consumers across workers.
• Failure handling. A run that exhausts its retries is dead-lettered with the reason and finalized, never silently dropped; consumed messages then flow into the same chunked, checkpointed processing and replayable run history as any other source.
• Inbound endpoints. A flow can also be exposed as an inbound HTTP or webhook endpoint, so a system that pushes rather than polls has somewhere to send to.

Enterprise integration has a standard pattern vocabulary, the same set that Apache Camel, Spring Integration, and every iPaaS implement as components. On Neblex these patterns are step types and connector behaviors, not things you re-implement by hand each project.

• Routing. Filter, Split, Aggregate, Group and summarize, Group into batches, and Sort are step types. Content-based routing is conditional edges (if, switch, merge), and scatter-gather is Repeat for each record followed by a join that waits for the chosen share of repeats to finish, so a batch can fan out and recombine without custom code.
• Transformation. Map fields, Transform items, Edit fields, and Lookup cover the message translator, content enricher, and content filter patterns. Governed Data Models are the canonical data model: JSON Schema contracts with a compatibility check that flags breaking changes before release, so each system is mapped once to a shared format, not once for every pair of systems.
• Channels and endpoints. Point-to-point and publish-subscribe channels, guaranteed at-least-once delivery on a durable queue, dead-lettering after retries are exhausted, an idempotent receiver keyed on a deduplication key per flow, competing consumers, and both polling and event-driven consumers.
• Reliability. Retry with exponential backoff per step, bulkhead isolation through per-step concurrency caps and workspace queue limits, and durable result delivery from On-Prem Workers that survives a link failure and is re-sent until the cloud acknowledges it.

A stateful, multi-step flow is the process manager pattern: it correlates related messages, waits for the ones it needs, and drives the sequence to completion. Neblex is an iPaaS: one platform where the integration bus, the API gateway, the human workflow, and the AI agent all live, instead of four products and the glue between them.

Enterprise integration does not live on an island. Neblex plugs into the version control and observability your team already runs.

• Git sync, in a few clicks. Connect a GitHub, GitLab, or Bitbucket repository with a scoped access token. Every saved flow is then committed to your repo, so the team gets version history and pull-request diffs on top of Neblex's built-in flow history. Pick the delivery policy: commit directly, or require every flow change to go through a pull request against the base branch. Drift review shows which copy changed and resolves conflicts without guessing. Neblex calls the provider's API directly over HTTPS and never clones the repository; SSH remotes, deploy keys, and app installations are not used.
• Telemetry export. Turn on export and new flow runs are delivered to your own OpenTelemetry collector as OTLP traces, metrics, and logs. Point it at your collector's OTLP/HTTP endpoint, authenticate with a header token or an mTLS client certificate, and suppress the environments (Dev, Test) you do not want exported. Runs then land in the same dashboards and alerts as the rest of your stack: Grafana, Datadog, Honeycomb, or any OTLP collector.

• 239 built-in connectors and growing, on-prem systems included
• EDI (X12, EDIFACT) over AS2 built into the core platform, not a separate B2B product
• SFTP, FTP, SSH, SOAP, and OData protocol support alongside REST and webhooks
• More than a dozen messaging and streaming protocols: AMQP 0-9-1 and 1.0, MQTT, Kafka, NATS, SQS, SNS, Kinesis, Pub/Sub, Redis Streams, Salesforce Pub/Sub, WebSocket, and Server-Sent Events
• Every broker connection both publishes and subscribes; durable consumer identity and dead-lettering after retries are built in
• Payload transformation between XML, JSON, CSV, fixed-width flat file, and EDI in the same flow
• Standard integration patterns as step types: filters, splitters, aggregators, translators, enrichers, lookups, and governed data models
• Reliability patterns built in: idempotent receivers, retry with backoff, bounded concurrency, and durable delivery from On-Prem Workers
• Deploy as SaaS or on On-Prem Workers inside your network, with self-managed installation available on request
• Git sync to GitHub, GitLab, or Bitbucket: every flow save commits, with optional pull-request review before the base branch
• Telemetry export: flow runs delivered to your own OpenTelemetry collector over OTLP (traces, metrics, logs), with header-token or mTLS auth
• Native Library step: call an exported C-ABI function in a vendor DLL or shared library on an On-Prem Worker, crash-contained, against an operator-approved library
• SSH adapter: run a command, or a bash, Python, PowerShell, or cmd script, on any host that accepts SSH
• One flow can span legacy and modern systems, with no hand-off between a B2B tool and an iPaaS tool

Two real flows, one EDI and one event-driven, with the actual step-level detail.

Inbound EDI 850 from a retail partner to a NetSuite sales order

A big-box customer sends purchase orders as EDI 850 over AS2. The flow validates, translates, and creates the sales order in NetSuite, then returns a 997 acknowledgment, all on one audit trail.

1. 1Receive: an EDI 850 lands over AS2, decrypted and MDN-acknowledged at the transport layer.
2. 2Validate: the document is checked against the partner's X12 4010 guideline, with envelope and segment errors rejected back to the partner.
3. 3Translate: the 850 is mapped to an internal order structure, resolving partner SKUs to NetSuite item IDs via a data table.
4. 4Create: a sales order is created in NetSuite with the partner as customer, keyed on the PO number for idempotency.
5. 5Acknowledge: a 997 functional acknowledgment is generated and sent back over AS2.
6. 6Handle exceptions: any SKU that does not resolve routes to a human task instead of failing the whole order.

Kafka order events into NetSuite, status published back to a topic

A commerce platform publishes order events to a Kafka topic. The flow consumes them, creates orders in NetSuite, and publishes a status event back, with a dead-letter queue for anything that fails.

1. 1Subscribe: a live-stream step consumes the orders.created topic with a durable consumer group and one copy per flow.
2. 2Deserialize: each message is parsed from Avro to an internal order structure; a schema mismatch routes the message to the dead-letter topic with the reason.
3. 3Resolve: customer and SKU lookups run against NetSuite; missing references are held for a human task, not dropped.
4. 4Create: the sales order is created in NetSuite, keyed on the event ID so a redelivered message does not double-book.
5. 5Publish status: an orders.status event of accepted, held, or rejected is published back to Kafka for the commerce platform.
6. 6Replay: if a downstream step fails, the run replays from that step once the issue is fixed, without re-consuming the topic.