A previous post on this blog, The Integration Bottleneck, covered a familiar problem, a mobile app, a partner, or a cloud service needs to reach data and business logic that live on IBM i, and building that connection the traditional way takes months instead of days.
That post covered one direction. Modern systems reading from IBM i. There is a second direction that shows up just as often and gets solved with a much worse default: modern systems writing into IBM i.
A storefront taking new orders. A sensor on a warehouse floor logging a completed pick. A partner’s system confirming a shipment. All of that needs to land inside the applications and data that run the business, and for most organizations, it still lands there once a night.
The Default Is a Batch Job, and Batch Jobs Have a Cost
When a new integration comes up that involves writing data into IBM i rather than reading it, the path of least resistance is usually a scheduled job. A flat file gets dropped, an overnight process picks it up, and by morning the order, the inventory adjustment, or the shipment confirmation has made its way into the system that runs the business.
This works, in the sense that the data eventually arrives. What it does not do is arrive when the business actually needed it.
A warehouse that only sees this morning’s order volume is a warehouse that oversold something at 9 PM last night. A finance team reconciling payments against a batch that runs at 2 AM is a finance team that is always half a day behind what actually happened. None of this shows up as a system outage or a support ticket. It shows up as a standing tax on how current the business’s own data is, paid quietly every day the batch window exists.
Why Writing into IBM i is its Own Problem, Not the Same One in Reverse
It would be convenient if closing this gap were just the outbound integration story run backward, but writing into a system carries a constraint that reading from one does not: the data has to be validated on the way in, not just retrieved on the way out.
RPG programs have spent decades encoding exactly what a valid order looks like, which fields are required, what a legal status transition is, what has to be checked before an inventory count moves. A raw write straight into a Db2 for i table skips all of that. It is fast, and it is also how a warehouse system ends up with a negative inventory count or an order with no customer record attached, because nothing enforced the rules that RPG was already enforcing everywhere else.
The integration has to go through the same business logic a green-screen transaction would have gone through, just triggered by a REST call instead of a 5250 session.
Where Profound API Closes This Side of the Gap
This is the same platform that solved the outbound half of the problem, applied to the other direction. Profound API connects to Db2 for i, RPG programs, and ILE procedures directly, which means an inbound endpoint can be built to call the RPG program that already validates and applies the write, not just to insert a row and hope. The validation logic that already exists does not get rebuilt in a middleware layer. It gets reused.
Every API Profound API generates is documented against the OpenAPI specification automatically, so a partner’s system or an internal application knows exactly what a valid inbound payload looks like before the first request is ever sent. And because the platform supports MySQL, MariaDB, SQL Server, and Oracle in addition to Db2 for i, the same pattern covers the rest of a company’s data estate, not just the IBM i piece of it.
What This Looks Like in Practice
Kamik is a clear example of the inbound side of this working at scale. The company’s IT team built Node.js applications using Profound API that take orders from multiple sources, Amazon, EDI, and its Magento storefront, and write them straight into its ERP and warehouse management systems automatically. As Trevor McCullough, Director of IT at Kamik, put it, “Thanks to Profound API, our applications are now incredibly seamless, flexible, and dynamic.” Three separate order sources, one path into the system that runs the business, with no overnight file drop in the middle.
The Witra Logistics and LERROS Moden case makes the same point from the warehouse floor. An automated sorting system needed to exchange data continuously with IBM i on Power, not just report status back out. Built on REST interfaces through Profound API, the connection let the sorting system’s activity write directly into the IBM i environment in real time. Daily processing capacity doubled, from 6,000 to 12,000 SKUs, and delivery volume rose 30% once the sorting system and IBM i were actually working from the same current data instead of a batch reconciled hours later.
The banking institution featured in the outbound piece tells a version of this story too. The platform handling more than 2,000 transactions per second is not just serving up read requests. A meaningful share of that volume is inbound: transactions being written, validated, and applied in real time rather than queued for a batch cycle.
What Changes for the People Building This
For RPG developers, the shift is the same one described on the outbound side. The validation logic already written does not get reimplemented anywhere. It gets exposed as an endpoint that any modern system can call, including systems that are writing data in, not just reading it out.
For developers building the systems on the other end, in Node.js, Python, or whatever a given integration calls for, a documented REST endpoint means building against a known contract rather than negotiating a file format and a delivery schedule with the IBM i team.
For the IT managers and business leaders sponsoring these projects, the number that matters is how much of the day’s activity is actually current inside the systems that run the business. A partner feed, a storefront, or a sensor network that writes in real time instead of overnight closes a gap that used to be accepted as the cost of doing business with a legacy application, and it does so without touching the business logic that already governs what a valid transaction looks like.
Where This Fits Into a Broader Strategy
Reading from IBM i in real time and writing into it in real time are the same underlying idea applied in both directions: Futurization treats the business logic and data already running on IBM i as something to extend, not something to replace or route around. Profound API is how that extension works in practice, whichever direction the data needs to move.
If your organization is still reconciling a batch window every morning to find out what actually happened the night before, that is worth a direct conversation. Reach our team at Futurization@ProfoundLogic.com or explore Profound API at profoundlogic.com/profound-api.