# How to build a mobile app for JD Edwards World

> Source: https://netray.co/integrations/jde-world-mobile-app
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Integrations

## 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.

## System

JD Edwards World (IBM i)

## Capability

mobile-app

## Intro

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.

## Use Cases

### Receiving against purchase orders

**Description:** 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

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

### Cycle counting

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

### Work order labor and completion reporting

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

### Pick confirmation and shipping

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

## System 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

### Pick the first workflow

**Detail:** Start where keying delay hurts most, usually receiving or transfers. A narrow first release is easier to validate against World.

### Design the API contract

**Detail:** Define small endpoints such as GET item, GET location stock, POST receipt, POST transfer, each with explicit validation rules and idempotency keys.

### Build the interface programs

**Detail:** Use a World-supported entry path or a carefully written RPG program under commitment control. Never write the raw inventory ledger from the outside.

### Authenticate users

**Detail:** 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.

### Build the app with scanning first

**Detail:** Use large targets, scan-driven fields, audible and haptic feedback and minimal typing. Test with gloves and under warehouse lighting.

### Add offline and sync

**Detail:** Queue transactions locally with timestamps and idempotency keys, sync when connected, and show clear conflict messages.

### Pilot, then expand

**Detail:** 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.

**Steps:**

- 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.

**Steps:**

- 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.

## 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

- 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.

## Options

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

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

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

### Custom app with an in-house team

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

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

### Partner build with Netray

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

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

## 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.

## Faq

### Does JD Edwards World have a mobile app?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

jd edwards world mobile app, ibm i warehouse barcode app, jd edwards world barcode scanning, as400 mobile inventory app, jd edwards world rf scanner, mobile app for jd edwards world, ibm i rest api mobile, jde world shop floor mobile, jd edwards world cycle count mobile, replace 5250 handheld screens

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json