Connect Microsoft Azure to EDI instantly
Join thousands of businesses moving EDI orders, invoices and fulfilment updates between Microsoft Azure and their trading partners on XEDI, no manual re-keying.
No credit card needed ✦ Free EDI mailbox included
Getting started with Microsoft Azure EDI
XEDI connects into an Azure estate wherever it makes sense, which begins with establishing which Azure service is actually carrying your data, because Azure names a platform rather than a route.
One managed platform, no custom code
XEDI maps Microsoft Azure to your trading partners and validates every document, so data flows straight into the systems your teams already use.
"We're on Azure" does not describe an integration
Azure covers storage, messaging, data platforms, integration services and hosting, and a business saying it runs on Azure could mean blobs in a container, a Data Lake, a Service Bus queue, a Logic App already moving files, or a database behind a private network.
Each of those is a different piece of work with different constraints. So the first conversation is not about EDI at all, it is about which part of the estate is actually going to hold the trading data, and who owns it internally.
Existing pipelines are usually the shortest route
Azure estates of any maturity already move data. There is typically something extracting from a line of business system, landing it somewhere, and handing it on, built by a team who still maintain it.
Adding a trading connection to that is almost always better than building a parallel path beside it. It means one operational pattern rather than two, alerting your team already watches, and no argument about which copy of the data is authoritative. Where the existing pipeline is the right place, we integrate there rather than insisting on our own.
What your team sees day to day
You get an EDI mailbox and a portal that behaves like an inbox, so trading state is visible without anyone querying a resource.
A retailer's order comes in, what you actually ship becomes the despatch advice with SSCC labels where the partner needs them, and the invoice goes out on delivery with its arrival confirmed in the dashboard.
Whatever your estate does internally is untouched. The EDI capability is bolted onto the Azure services you already run, and the partner side stays ours to maintain.
Documents you can exchange
- Trading files exchanged through whichever Azure service holds them
- Order data delivered to the service your systems consume
- Despatch and quantity data collected from your estate
- Invoice data written out for downstream use
- Exceptions surfaced wherever your teams will see them
Built for Microsoft Azure teams
Whoever owns Microsoft Azure in your business, XEDI keeps EDI accurate and hands-off.
- Azure architects and platform teams
- Enterprises standardised on Microsoft
- Integration teams maintaining existing pipelines
- Operations consuming trading data downstream
- Businesses migrating workloads into Azure
Microsoft Azure EDI document types
Where each of these lives depends on your estate, which is established before anything is built.
| Document | What it carries | Direction |
|---|---|---|
| Order data | Retailer demand delivered into whichever Azure service your systems consume from. | XEDI to your estate |
| Despatch data | What is actually shipping, collected from your estate and validated before it becomes a document. | Your estate to XEDI |
| Invoice data | Invoice detail written where finance or reporting will pick it up. | XEDI to your estate |
| Catalogue and stock data | Product and availability figures exchanged with partners on an agreed cycle. | Either direction |
| Exceptions | Validation failures surfaced wherever your teams already watch for problems. | XEDI to your estate |
| Acknowledgements | Confirmation of what reached a partner and what came back, for downstream reconciliation. | XEDI to your estate |
How to connect Microsoft Azure with EDI using XEDI
The first task is establishing what your estate actually consists of. The sequence below is what onboarding looks like from your side.
-
01
We establish which Azure services are genuinely in play, since the answer varies widely.
-
02
We agree where trading data should be written and collected within that estate.
-
03
We set up access according to your platform team's policy.
-
04
We prove the flows against how your estate actually behaves rather than a reference architecture.
-
05
You get EDI added to the Azure footprint you already operate.
Ready to connect Microsoft Azure?
Talk through documents, mapping, testing and go-live with XEDI.
Everything about Microsoft Azure EDI
Common requirements
- Which Azure services hold the data
- Subscription and resource scope
- Access policy for integrations
- How your teams expect to see exceptions
- The trading partners involved
What we need from you to build it
Only what we cannot decide for you. Partner requirements remain ours; the estate map has to come from you.
- Which services are in play
- Storage, messaging, data platform or integration services, since each implies a different design.
- Subscription and resource scope
- Where exchange traffic belongs, so access is scoped to those resources.
- Integration access policy
- What your platform team permits, which usually decides the approach more than any technical consideration.
- Existing pipelines
- What already moves data internally, because adding to it beats building a parallel path beside it.
- The trading partners involved
- Which relationships this covers. What each requires is already ours.
Why suppliers choose XEDI for Microsoft Azure
- Trading partners are generally connected already, so mapping your estate is the longer half of the job.
- The design follows the Azure services you actually run rather than a reference architecture.
- Where you already have a pipeline, we add to it rather than building a second path beside it.
- Access follows your platform team's policy instead of requiring an exception.
- Trading partner requirements stay ours no matter how your estate is arranged.
- If a partner raises a problem, it comes to us rather than becoming a ticket for your integration team.
Which Azure services do you work with?
The question is which ones you use. Storage, messaging, data platforms and integration services all appear in Azure estates, and each implies a different design, so that is established before anything is built.
We already have data pipelines. Can you use them?
Usually yes, and it is generally the better answer. One operational pattern with alerting your team already watches beats a parallel path that only the trading connection uses.
How is this different from the Blob Storage page?
That one covers a specific route with its own characteristics, particularly access tiers and credential expiry. This one is for estates where the answer is not simply a container.
Plan your Microsoft Azure EDI setup
Everything you need to scope, map and go live with Microsoft Azure, in one place.