Mobile appJD Edwards World (IBM i) Agent view

How to build a mobile app for JD Edwards World

Short answer

World has no mobile API, so you add a thin REST layer in front of DB2 for i and the World batch input path, then build a scanner-friendly app on top. Reads go straight to SQL, writes are validated and staged, and the app handles spotty Wi-Fi with a local queue.

Get this built on your JD Edwards World (IBM i)

Warehouses and shop floors on World often run on 5250 emulation on rugged handhelds, or on paper that someone keys later. Emulation screens are slow to navigate with a trigger scanner, and every extra screen costs seconds that add up over a shift. Paper creates a delay between the physical event and the system record, which is where inventory accuracy goes wrong.

A purpose-built mobile app solves the interaction problem, but the real design work is on the back end: World was not built for modern clients, so the layer you build has to protect data integrity while giving the app something simple to call.

This page describes that layer, the screens that pay back first, and the traps specific to IBM i and to offline use.

What teams use it for

Receiving against purchase orders

Scan the PO or item, enter or scan quantity, capture lot and location, and stage the receipt so the system matches reality at the dock.

Inventory transfers and put-away

Scan from-location, item and to-location to move stock between bins, with immediate on-hand feedback.

Cycle counting

Present the count list by location, capture scanned counts and send variances above tolerance to a supervisor.

Work order labor and completion reporting

Let operators clock on and off operations and report quantities complete and scrap without visiting a terminal.

Pick confirmation and shipping

Show pick lists, confirm picks by scanning, and capture carrier and tracking at ship confirm.

JD Edwards World (IBM i) integration surface

DB2 for i via JDBC (jt400) or ODBC for reads of items, locations, open orders and work orders; table names and column layouts depend on your release and customizations.
World batch input and interactive-batch programs, or locally written RPG interface programs, for transactions such as receipts, transfers, adjustments and labor; direct updates to inventory files are strongly discouraged.
Commitment control and journaling on IBM i, which let a custom interface program apply multi-file changes atomically or roll them back.
Data queues for pushing real-time notifications from the IBM i to a middle tier that forwards them to devices.
IBM i Integrated Web Services Server or an external API gateway as the front door, with HTTPS, authentication and rate limits.
Device layer: Android handhelds with Zebra DataWedge or camera scanning, or iOS devices with camera barcodes.

How it works

1
Pick the first workflow
Start where keying delay hurts most, usually receiving or transfers. A narrow first release is easier to validate against World.
2
Design the API contract
Define small endpoints such as GET item, GET location stock, POST receipt, POST transfer, each with explicit validation rules and idempotency keys.
3
Build the interface programs
Use a World-supported entry path or a carefully written RPG program under commitment control. Never write the raw inventory ledger from the outside.
4
Authenticate users
Map each mobile user to a World user profile or to a service account plus user ID in the audit field. Handle shared device logins deliberately.
5
Build the app with scanning first
Use large targets, scan-driven fields, audible and haptic feedback and minimal typing. Test with gloves and under warehouse lighting.
6
Add offline and sync
Queue transactions locally with timestamps and idempotency keys, sync when connected, and show clear conflict messages.
7
Pilot, then expand
Run in parallel with the existing process for a few weeks, reconcile differences and then retire paper or emulation for that workflow.

Example flows

Receiving a PO with a lot-tracked item

Trigger: A truck arrives and the receiver opens the PO on a handheld.

The app calls the API for open lines of the PO.
The receiver scans the item label, enters the quantity and scans a lot barcode.
The app checks over-receipt tolerance and shows a warning if exceeded.
The transaction is posted through the interface program under commitment control.
The app shows the new on-hand and prints a put-away label.

Result: Receipts appear in World within seconds, not at the end of the shift.

Offline cycle count in a freezer

Trigger: A counter works in an area without Wi-Fi.

The count list is downloaded before entering.
Counts are scanned and stored locally with a timestamp.
On return to coverage, the app syncs and the server compares each count with the current on-hand.
Variances above tolerance go to a supervisor; others post automatically.

Result: Counts complete without hunting for a signal or re-keying from paper.

Keeping data on-prem

A World mobile app fits an on-prem model naturally: the IBM i, the API service and the device management can all live on your network, with the handhelds reaching the API over private Wi-Fi or a VPN. Avoid placing the IBM i directly on the internet; put an API gateway in a DMZ with TLS and certificate pinning on the device. If you add AI features such as voice commands or a photo-based part lookup, run the models on a local server so nothing leaves your site, which matters for facilities with export or customer restrictions.

Security checklist

Use HTTPS with certificate pinning and enforce device management (MDM) with remote wipe.
Give the API a least-privilege IBM i profile and authorize each user action by role and branch/plant.
Use idempotency keys so a retried transaction cannot post twice.
Do not cache sensitive data such as pricing on the device unless it is needed and encrypted.
Log every transaction with user, device ID and timestamp for audit.

Ways to get it done

Third-party warehouse or shop-floor mobile product with an IBM i connector

Effort: Weeks to a few months including interface setup and license costs.

Fits standard receiving, picking and counting where a vendor already integrates with World.

Custom app with an in-house team

Effort: Several months for the API layer, app and testing, plus ongoing maintenance.

Fits shops with mobile and RPG skills and workflows that do not match packaged products.

Partner build with Netray

Effort: A pilot with one workflow, then extension; the IBM i interface work is often split with a World-experienced partner.

Fits those who want a governed API layer, and optionally AI features like voice or photo lookup running on-prem.

Pitfalls

!Writing directly to inventory files creates ledger and balance mismatches; always use a validated posting path.
!Shared handheld logins destroy audit trails; use individual sign-in even if it is a quick badge scan.
!Wi-Fi dead spots are common in warehouses; survey before go-live and design offline from the start.
!Lot, serial and location-controlled items need extra validation rules; test with real edge cases.
!Ignoring batch jobs that run at night can create locks or stale reads; check what else touches the same files.

Frequently asked questions

Does JD Edwards World have a mobile app?

Not a modern one. World is a character-based IBM i application, so mobile access is built with an API layer over DB2 for i and a controlled posting path. Some third-party vendors offer scanner apps for World, which can be quicker for standard warehouse flows.

Can the app write directly to the database?

It should not. Direct writes bypass World's edits and can corrupt inventory balances and ledgers. Use an interface program or batch input that applies the same logic as the screens, with commitment control for multi-file changes.

How do barcode scanners work with an IBM i?

Handhelds scan through a keyboard-wedge or camera SDK in the app, which then calls the API. Old 5250 emulation can also accept scans but is slower to navigate. A native or web app gives you scan-driven screens and offline capability.

What about offline use?

Queue transactions locally with timestamps and unique keys, then sync when connected. The server must revalidate each one, because stock may have changed. Plan clear messages for conflicts, and do not allow offline for high-risk actions like adjustments above tolerance.

Can we add AI features to the app?

Yes, for example voice commands, photo-based part identification or natural-language stock questions. Run the models on a local server to keep data on site, and keep any write action behind the same validation and approval rules as a manual entry.

More for JD Edwards World (IBM i)

AI agents ChatGPT Claude MCP server AI chatbot Power BI WhatsApp Microsoft Teams Slack Email automation Document OCR

AI for ERP

AI for JD Edwards World on IBM i, without a EnterpriseOne migration

AI for ERP

AI for JD Edwards Inventory Management and Shop Floor Manufacturing

Want Mobile app working on your JD Edwards World (IBM i)?

A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.

Get a free assessment

All integrations

Try it here, free

JD Edwards World Private AI Layer Blueprint Generator

Open full tool

Fill in your JD Edwards World version, database, hosting and users to get a shareable architecture plan for a private, on-prem AI assistant.

Fill in

Company name

System version

Database or engine

Hosting for the AI layer

Named users

Sites, plants or entities

Main use cases

Data that must never leave the site

GPU available

Target go-live

Live preview

Free, optional. Reopen it on any device.

Download:

JD Edwards World Private AI Layer Blueprint Generator

Context

Company: Prairie Gear and Machine System: JD Edwards World A8.1 on IBM Db2 for i (V7R3 or later) Scale: 160 named users; 2 plants, 1 distribution centre AI layer hosting: On-prem server; GPU position: None yet Target go-live: Q2 2027

Goal: add a private AI assistant on the existing system without moving data off-site. The assistant answers questions from live system data and documents, shows the data behind each answer, respects existing user permissions, and proposes changes for human approval.

Use cases in scope

Item availability, open order and PO status, vendor and customer lookup, ledger inquiry, search of spooled reports and PDFs

Data that must stay on site

Costing, margin and vendor pricing data, customer contracts

All model serving, indexing and logging for these data sets run inside the On-prem server boundary. No data is sent to an external model service.

Components

Component	Design for JD Edwards World	Notes
Data access path	JDBC or ODBC to Db2 for i with a read-only profile; journal-fed off-box copy for heavy reads; batch input (Z) files for approved write-back	Reads are read-only; no direct writes to production tables
Retrieval index	Spooled reports, IFS and shared-drive PDFs, with company or business unit as the label	Embedding model runs locally; ACL stored with every chunk
Model serving	Open-weight model served with vLLM or Ollama on None yet	Size the model to the GPU; add a second node for availability
Tool server	Named read tools with Julian date, implied decimal and UDC decoding; draft documents only until approved for batch input	Named, parameterised tools; the model never writes free SQL
Identity and permissions	One narrow IBM i profile for the connection; end-user scope enforced in the tool server from a reviewed mapping table	Acceptance test with a restricted user and a super user
Audit	Log of user, tool, SQL text and answer on the Linux tool server; reviewed against IBM i audit journal entries	Append-only; reviewed by IT and the system owner

Security controls mapped to your inputs

Control	Implementation	Driven by
Data residency	Model, index and logs inside the On-prem server boundary; no external API calls	Data that must not leave the site
Least privilege	Dedicated read-only account limited to listed objects	Use cases in scope
Permission mirroring	One narrow IBM i profile for the connection; end-user scope enforced in the tool server from a reviewed mapping table	160 named users and roles
Network isolation	Model host has no internet route for air-gapped; inbound only from the tool server	Hosting choice
Write-back control	Drafts only, then supported APIs after named human approval	Use cases in scope
Auditability	Log of user, tool, SQL text and answer on the Linux tool server; reviewed against IBM i audit journal entries	Internal audit and system owner

Rollout plan

Phase	Scope	Exit criteria	Typical duration
1. Read-only questions	5 to 10 named tools and document search for a pilot group	Answers match the system for a restricted and an unrestricted test user	6 to 10 weeks
2. Drafts	Assistant prepares documents or change requests as text for review	Reviewers accept drafts with low edit rate; audit log complete	4 to 8 weeks
3. Approved actions	Supported write path, each action approved by a named person	No action executes without approval; rollback procedure tested	6 to 10 weeks

Open questions for IT

1. Which libraries hold production data and which files are journaled? 2. How is World security configured today (menu, action code, file, program)? 3. Which custom RPG programs and batch interfaces already exist? 4. Is an off-box reporting copy acceptable, and which database will host it? 5. What CCSID and character conversion issues exist in the data?

Sign-off

System owner / Date

IT architect / Date

Security officer / Date

Business sponsor / Date

Planning document, not a design guarantee. Confirm object names, API availability and licensing for your exact version and patch level with your vendor documentation and DBA. Compliance with any regulation remains the responsibility of your organisation.