# How to build a mobile app for Infor XA > Source: https://netray.co/integrations/infor-xa-mobile-app > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Integrations ## Short answer A mobile app for XA talks to an API layer you host, which reads from Db2 for i views and posts transactions through stored procedures or supported XA programs. The phone or scanner never connects to the IBM i, and offline capture is handled by queuing transactions on the device. ## System Infor XA (on IBM i) ## Capability mobile-app ## Intro On many XA plants, the shop floor still depends on 5250 sessions on fixed terminals, rugged RF guns running an emulator, or paper that someone keys in later. That works until you have a large warehouse, a second shift with high turnover, or a technician who needs to log time from a customer site. A modern mobile layer improves the experience without replacing XA. You get a camera for barcode and photo capture, simple screens for one task, and an interface that new staff can learn in a few minutes. The IBM i remains the system of record. The design question is where logic lives. If you keep business rules inside XA programs and the app only calls them, the mobile experience stays consistent with the green screen and you inherit existing edits. ## Use Cases ### Cycle counts and inventory moves **Description:** Scan a bin and item, enter a count, and post the adjustment or transfer through the standard inventory transaction path. ### Receiving against POs **Description:** Scan the PO or packing slip, receive lines with lot capture and photo of damage, and print labels. ### Shop floor labor and quantity reporting **Description:** Operators clock on to a work order operation, report good and scrap quantity and see the next job. ### Pick and ship confirmation **Description:** Scan to confirm picks against a pick list and capture the carrier and tracking number at the dock. ### Field service and approvals **Description:** Technicians log time and parts on a work order and managers approve requisitions or timesheets from their phone. ## System Surface - Db2 for i is reachable over JDBC (JTOpen) or ODBC from a mobile back end. Use views for lookups: item, bin, open orders, work order operations. - For transactions, SQL stored procedures that call the same RPG programs behind the green screen options. This keeps edits, costing and audit behaviour in one place. Which programs are callable differs by release and mods. - Existing RF or mobile modules, where licensed, may already cover receiving and picking through the 5250 data stream. Evaluate them before building new screens. - 5250 screen scraping or emulator-based wrappers can modernise screens quickly, but are fragile when screens change. Treat as a stopgap. - The IBM i can print labels to network printers and write IFS files, which the back end can trigger for barcode and travel labels. ## How It Works ### Choose a few high-value tasks **Detail:** Pick the transactions with the most keystrokes or rework, such as receiving and cycle counts. Walk the floor and time them. ### Define the API surface **Detail:** A small REST service hosted on an internal server with endpoints per task. It authenticates the user and calls only approved views and procedures. ### Pick the client approach **Detail:** A progressive web app is cheapest for phones. Native or cross-platform apps suit scanners with hardware triggers and stronger offline needs. ### Handle identity **Detail:** Use single sign-on where you can, with badge or PIN login for shared devices. Map each user to an XA user so transactions carry the right ID. ### Design for connectivity **Detail:** Warehouses have dead zones. Queue transactions on the device with a client-generated ID, replay them in order and make the server idempotent. ### Pilot on one area **Detail:** Run beside the existing screens for a few weeks in one warehouse or cell, compare counts and timing, then roll out. ## Example Flows ### Receiving with lot capture **Trigger:** A receiver scans a PO barcode at the dock. **Steps:** - The app pulls open lines for the PO from a view. - The receiver scans each item, enters quantity and lot, and photographs damage if any. - The app queues the receipt and sends it when connected. - The server calls the receiving procedure and returns the receipt number or an error. **Result:** Receipts post at the dock in real time, with lot numbers captured at the source. ### Cycle count with variance review **Trigger:** A counter opens a count task for a zone. **Steps:** - The app lists bins to count and hides the system quantity if blind counting is required. - The counter scans and enters quantities. - Variances above a threshold are sent to a supervisor for approval. - Approved adjustments post through the standard adjustment procedure. **Result:** Counts finish faster and large adjustments are reviewed before they hit the books. ### Technician logs time and parts **Trigger:** A field technician finishes a service call. **Steps:** - They open the work order and enter hours and parts used. - They capture a customer signature and photos. - The service posts labor and issues and attaches the files to the order. **Result:** Billing can proceed the same day without paper. ## On Prem Host the API and any file storage on internal servers and expose it to devices through your Wi-Fi or a VPN, or a reverse proxy with certificates and device management for remote users. The IBM i does not need an inbound internet path. If your app includes AI features such as voice entry, photo recognition of labels, or a question box, run the models on your own GPU servers so images of parts, labels and paperwork stay in your control. Mobile device management should enforce encryption, screen lock and remote wipe on all devices that carry cached data. ## Security - Authenticate each user and map them to an XA user. Avoid shared accounts on shared devices. - Use TLS everywhere, certificate pinning for native apps, and device management for scanners and phones. - Limit the cached data on the device, encrypt it and wipe it on logout or loss. - Make transaction endpoints idempotent and validate every request server-side. Never trust the client. - Audit each transaction with user, device, and timestamp. ## Options ### Vendor RF or mobile module for XA **Fit:** Standard warehouse flows and you want vendor support. **Effort:** Licensing plus configuration, usually weeks. ### Progressive web app on views and stored procedures **Fit:** A handful of custom tasks, mixed device types, and a developer with web and Db2 for i skills. **Effort:** Often six to twelve weeks for the first tasks. ### Netray and an XA partner **Fit:** You want custom tasks plus optional on-prem AI such as photo-based receiving or voice questions. **Effort:** A scoped pilot over several weeks per task group. ## Pitfalls - Re-creating every green screen option on a phone. Pick tasks, not screens. - Posting transactions directly to files, skipping XA edits and costing. - No offline plan, so a Wi-Fi dead zone causes duplicate receipts or lost scans. - Underestimating scanner hardware differences and keyboard wedge behaviour. - Skipping user testing on the floor, which finds the real problems in an hour. ## Faq ### Can I use iPhones or Android phones with XA? **Answer:** Yes, via an app or progressive web app that calls your API layer. The phone never connects to the IBM i. For heavy scanning, rugged Android scanners with hardware triggers are usually a better fit than consumer phones. ### Do I have to scrape the green screen? **Answer:** No. Screen scraping can modernise quickly but breaks when screens change. A stored procedure that calls the same business logic is more stable, though it takes more design effort and RPG knowledge. ### How does offline mode work? **Answer:** The device stores transactions locally with unique IDs and sends them when it reconnects. The server rejects duplicates and returns errors for transactions that no longer apply, which the user must resolve. ### Which transactions should I start with? **Answer:** Start where manual keying or paper is worst, usually receiving and cycle counts. They are well-defined, easy to measure, and have clear controls you can compare against the existing process. ### Can AI be added to the mobile app? **Answer:** Yes. Examples are photographing a label to fill in a receipt, voice notes turned into a nonconformance draft, or asking a question about an item. Keep the model on-prem if images or data are sensitive. ## Search terms infor xa mobile app, mobile app for infor xa, infor xa barcode scanning, ibm i mobile app development, as400 handheld scanner app, infor xa warehouse mobile, infor xa shop floor app, modernize 5250 green screen mobile, infor xa rf scanning alternative --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json