View the documentation
Preserved business logic
NTi lets .NET applications execute existing RPG programs, business rules, and data access directly on IBM i.
- Existing IBM i logic remains intact
- Business rules stay centralized on IBM i
- Functional changes are not duplicated
From the field to IBM i with NTi
Edge computing & IoT
By providing native support for all architectures (x86, ARM, Power...), NTi opens up new possibilities between IBM i and embedded/real-time systems.
Scanning...
Distributed execution
Centralized data
On-site operations require immediate access to business data. Depending on the context, actions may trigger processing or business rules executed by IBM i programs, from mobile or embedded terminals.
Barcode scanning
Real-time inventory updates
Inventory tracking
Mobile warehouse operations
Field maintenance
On-site equipment access
Quality control
Inspection data collection
Direct access to IBM i with NTi
With NTi, the .NET application runs locally on the device and natively accesses IBM i resources. You reduce the exposure surface (no additional application service to publish) while maintaining full control through IBM i mechanisms (profiles, authorities, auditing).
Device
.NET application
Provider
TCP/IP
IBM i
System resources
Real-time user input
Data captured on the device
Access to DB2 for i, RPG/CLP/36 programs, CL commands
Barcode scanning
in real time with NTi
A concrete embedded use case
1
Scanning…
Scan a barcode or QR code
2
.NET
using var conn = new NTiConnection(connString);
conn.Open();
conn.Execute("INSERT INTO
SAMPLE.BARCODES (SCANDATE, SCANTYPE, VALUE)
VALUES (@Time, @Type, @Value)",
new
{
Time = DateTime.Now,
Type = scan.Format.ToString(),
Value = scan.Value,
}
);
SQL insert with NTi on the .NET side
3
Scan completed
Code - 26061160
Instant user confirmation
4
IBM i
DATA FILE MANAGEMENT
Format . . . . : SCAN
*RECNBR: 9
SCANDATE: 2024-04-04-16.55.26.903886
SCANTYPE: EAN8
--------------------------------------------
VALUE: 26061160
Data stored on IBM i (DB2 for i)
Extend IBM i
to peripheral workloads
Eliminate gaps between action and processing with .NET and NTi, and maintain precise control over the data sent to IBM i.
IBM i
Field data acquisition
Automated events
Business data
Multiple use cases
A single IBM i access layer with NTi, adapted to network constraints, security requirements, and device scale.
Usage
Actions that must be executed immediately: scanning, validation, business queries, or business updates.
Examples
- Warehouse with reliable connectivity: 20 to 50 scanners.
Each scan validates an item, updates inventory data, and triggers existing business rules (RPG programs). - Fixed workstation on the shop floor: production reporting or quality control, with instant confirmation expected by the operator.
Where NTi fits in
NTi runs within the .NET application, directly on the device.
The application directly consumes IBM i resources (data or existing business programs), without any intermediary layer.
Usage
Large numbers of devices on a single site, or strict network access requirements.
All exchanges are routed through a local .NET gateway instead of connecting each device directly to IBM i.
Examples
- Logistics platform or factory environment: 200+ devices.
Devices communicate with a local .NET gateway that consolidates requests, handles traffic spikes, and provides centralized tracing. - Security and segmentation: devices operate on a dedicated field network (VLAN). Only the .NET gateway is allowed to access IBM i through NTi, with no direct device connectivity.
Where NTi fits in
NTi runs inside a locally deployed .NET gateway. This gateway is the only component with direct access to IBM i resources.
Usage
Unstable or unavailable network conditions (mobility, coverage gaps, challenging buildings). Operators must be able to keep working without interruption.
Examples
- Field technician: enters a service report while offline, with automatic transmission when connectivity is restored.
- Warehouse or shop floor: unreliable Wi-Fi (hangars, metal structures). Scans continue locally and are sent in batches once the network becomes stable again.
Where NTi fits in
The application stores actions locally. During synchronization, NTi is used to transmit these actions to IBM i, update data, and trigger existing business logic when required.
NTi, a strategic asset
for edge and IoT around IBM i
A single, unified .NET stack
Embedded applications, intermediate services, and operational tooling all run on .NET.
- One technical ecosystem to operate
- One shared skill set
- One maintenance lifecycle
Security and access control
NTi relies on native IBM i security mechanisms: profiles, authorities, and auditing. You retain full control over when and how IBM i is accessed.
- IBM i profiles and authorities remain unchanged
- SSL/TLS encryption supported
- TOTP-based MFA supported (depending on IBM i version)
Operations and scalability
Designed to handle activity spikes: reduced latency, reused connections, and clear correlation between .NET connections and IBM i jobs.
- Built-in .NET pooling (fewer QZDASOINIT jobs)
- Connection and job lifecycles fully controlled
- Tracing available through STRTRCTCP on IBM i
Any questions ?
Here, IoT and edge computing refer to use cases performed as close as possible to the point of action: barcode scanning, field data entry, quality control, equipment monitoring, or technical measurements...
These use cases must be able to interact with IBM i immediately, without relying on a cloud service, a remote API, or an intermediate data collection platform before business processing is executed.
Today, one approach is to rely on .NET and NTi to bypass traditional technical constraints.
Applications directly access IBM i data and trigger the required existing business processing.
When actions must be handled immediately, network latency and the availability of remote services become structural constraints.
Running the application locally allows the action to be processed at the moment it occurs, regardless of network conditions, while ensuring consistent response times.
Access to IBM i occurs only when required to trigger business execution or persist meaningful data, without depending on remote infrastructure for every interaction.
No. .NET applications running at the edge act as filtering and orchestration layers. They determine when a business execution must be triggered on IBM i.
This avoids calling the system for every action (scan, input, measurement...) while keeping IBM i as the central system for data and business logic.
This behavior is a matter of application design: the .NET application defines when and how IBM i is accessed, based on business rules and design choices made by the development teams.
.NET provides a unified platform for building the full set of business applications across the information system.
Edge and IoT workloads can be built in .NET using the same tools, patterns, and engineering practices, without introducing a separate technology stack.
With NTi, these applications interact directly with IBM i resources, DB2 for i data, RPG, CLP, 36 programs, and CL commands, without replicating business logic.
It removes the need for an extra layer between applications and IBM i.
.NET applications handle the user-facing layer, orchestration, and distributed workloads.
IBM i remains the system of record for data and existing business rules.
NTi defines a clear separation by allowing .NET applications to call IBM i resources directly, without exposing the system as APIs and without relocating business logic outside its intended domain.
