Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
Order and stock records move between SAP and the IBM AS/400 in both directions, so two systems that have each been right for years stop disagreeing quietly about the same figures at month end.
The IBM AS/400 is a platform rather than an application, which is why no two of them are alike. What it holds, and what it exposes, is whatever the programs written for that particular business were built to do, and those programs have usually been right for two decades. It was sold as hard to connect to and it generally was not. The SAP to IBM AS/400 integration treats it as what it is, a reachable system with interfaces that have been there for years, holding figures SAP needs and needing figures SAP holds, with one side agreed as authoritative for each.
DATA THAT FLOWS BETWEEN THEM
Order records
Stock balances
Item numbers
Customer accounts
Shipment confirmations
Pricing data
Alumio works with the interfaces the AS/400 already presents, so the starting point is what the machine exposes now rather than a modernization programme scheduled ahead of it.
Stock, pricing and order status each get a nominated system of record, so SAP and the AS/400 stop holding two versions of a number that only one of them should be deciding.
Each new requirement reuses the AS/400 configuration already built rather than adding another scheduled extract, so the machine serves one integration instead of nine jobs.
How data leaves the AS/400 is configured and visible in Alumio, so it stops being something only the colleague who has worked there longest can explain to anybody else.
An order created in SAP is written into the AS/400. Alumio connects to it through the interfaces it already exposes, as it would any reachable system, and maps each order to the fields those programs expect to receive.
Stock balances the AS/400 maintains are published to SAP as often as planning needs them, so planning works from what the warehouse actually holds rather than from a figure that was accurate at the time of last week's extract.
An extract that has run nightly for years becomes a configured route, so the same data reaches SAP with a log of what moved and when, and nobody needs to remember which server the old job used to be running on.
Alumio sits between sales channels and fulfillment systems as a governed integration backbone. Orders are routed, transformed, and validated, while status updates return to every channel.
Authenticate your systems using Alumio's pre-built connectors. Choose from 200+ connector packages in the marketplace, plus unlimited custom integrations.
Define how data fields map between systems in a visual interface. Adjust formats, enrich records, and apply business logic, no custom code required.
Configure flows to run in real time on events, on a schedule, or both. Reduce manual data entry and let Alumio handle movement and transformation between systems.
.svg){kind=icon}
Once your first integration is live, adding your ERP, PIM, WMS, or CRM connects to the same hub. Existing flows keep running. No rebuilding from scratch.
An EDI trading partner channel is the usual addition, because a business running an AS/400 has almost always been exchanging files with its customers for years, and those exchanges are the least visible integrations it owns. Alumio holds them alongside and reuses the AS/400 configuration already built, so a partner feed becomes a route with a log rather than a script somebody inherited.
Yes, and deciding which side is authoritative for each figure matters more here than the schedule does. Both systems can hold stock, pricing and order status, so Alumio is configured with one system of record per figure and publishes in that direction. Where something genuinely has to move both ways, the sequence is explicit rather than left to whichever job ran last.
No, this is configured rather than coded. Stock balances, order numbers and the account references the two systems use for the same customer are mapped once in Alumio and maintained there, which replaces the extract script this usually runs on. For a conversion that decades of local convention have made genuinely peculiar, the Code Transformer takes custom logic at that step.
Less than a modernization pitch suggests, usually. The AS/400 is a platform, so what it does is whatever was written for that business, and some of that works well and is understood by the people who depend on it. The useful split is to leave the processing where it runs and move only the figures other systems need, which is a smaller decision and a much more reversible one.
The two systems drift apart after a record was accepted, which is the failure nobody sees, because a later change in SAP leaves the AS/400 holding a version that was correct when it arrived. Alumio monitors each transfer live and records exactly what it handed over, so a refused record alerts immediately with the reason, and retries run automatically where configured. Updates republish on change, so neither side is silently left holding last month's figure.
Talk to an Alumio integration specialist. We'll map the right architecture for your systems, at the right scale, so your operations stay reliable through every change.
.svg)
