Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
A logged-in buyer's own price is asked of the AS/400 while the Shopware page loads, so a trade customer sees the exact figure their account has always had rather than a copy made last night.
On an AS/400 a customer's price is usually the output of a program rather than a value sitting in a table, because decades of agreements, breaks and exceptions were built into the logic instead of the data. That makes it something you can ask for and not something you can sensibly copy, and a Shopware storefront that copies it will be wrong for the customers who matter most. So B2B buyers phone in orders they could have placed online. Connecting Shopware and IBM AS/400 asks the question at the moment the page needs an answer, with Alumio acting as an API gateway between the two.
DATA THAT FLOWS BETWEEN THEM
Customer accounts
Account-specific prices
Stock positions
Sales orders
Order confirmations
Product records
The price a logged-in Shopware customer sees is requested from the AS/400 as the page loads, so an agreement that exists only inside a program is still what the buyer is charged.
Nothing has to be extracted and flattened into a price list, which matters because the exceptions that make a trade price correct are the first thing an extract loses.
A buyer who has always called to check their price can place the order themselves, because the storefront is answering with the same number the sales office would have read out.
The AS/400 stays where the pricing lives, and Alumio reaches it through the interface it makes available, so the storefront gains a capability without the older system changing.
When a logged-in Shopware customer views a product, Alumio requests that account's price from the AS/400 and returns it to the storefront in the same request, so the page shows a live answer rather than a cached one.
A trade buyer completes checkout in Shopware and the order is written into the AS/400 records the sales office already works from, so an online order and a phoned one arrive in the same place and are handled the same way.
Availability is checked against the AS/400 records before the order is accepted at checkout, so a customer who has been told a price is not then told two days later that the stock behind it went to somebody else.
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.
What a trade customer has to do before they can buy at all is the question that opens the next connection. Approved accounts are the precondition here, and once orders are arriving through Shopware the thing customers ask for next is being told when the goods went, so an order-status notification service is the common addition. Alumio holds that connection alongside this one, so a despatch recorded in the AS/400 reaches the buyer without the sales office sending an email.
This one is a live request rather than a sync, which is the whole point. Alumio acts as an API gateway between Shopware and the AS/400, so a price request made while a page loads is answered in that request and nothing is stored in between. Stock and product data can still run on a schedule where a live answer is not needed, and choosing which flows are live and which are scheduled is a configuration decision.
No, and asking is a smaller build than copying. Holding IBM AS/400 account pricing inside Shopware would mean turning program logic into a table, keeping that table current, and being wrong every time an agreement moves. Database connections sit on the list of what Alumio publishes as supported, so a platform with no API of its own is still reachable, and the work is shaping a request and a response in the interface.
It can, and asking is the right approach rather than a compromise. The IBM AS/400 is a platform rather than an application, so what it holds and what it exposes is whatever the programs written for that business were built to do, and account pricing is usually one of those programs. Alumio reaches it through the interface it makes available and passes the answer to Shopware while the page is still loading, so the agreement never has to be duplicated.
A request that never comes back is a different failure from a message that never sent, because a customer is waiting on this one. The Shopware storefront is configured to fall back to a state you choose, showing no price and a request-a-quote route rather than a wrong figure. Alumio monitors each IBM AS/400 request in real time and logs the response, so a timeout alerts immediately with the account and the reason, retries run where configured, and nothing is priced quietly from a stale copy.
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)
