In this technology-driven, fast-paced business world, many different applications and services often work together. This explains why today's organizations need APIs to connect to these applications and services and power their business applications.
By Joydip Kajilal
This article will examine what IBM i modernization is, why it is needed, and how to expose the business logic of legacy RPG applications as APIs.
The Need for IBM i Modernization
Organizations that depend on the IBM i platform for their mission-critical RPG applications are looking for ways to update their IBM i systems to achieve their digital transformation goals. This can help them leverage modern technologies to add more value to their RPG applications.
In general, this will allow an organization to develop new applications that leverage the stability and reliability of their current IBM i systems without spending money to change legacy application code.
To be successful with this modernization effort, all organizations must focus carefully on planning, adhere to architectural standards, and maintain an operationally excellent environment for their businesses. Organizations that execute this strategy effectively will relish improvements in customer satisfaction, increased agility, and increased returns from their IBM i systems.
Why expose existing RPG apps as REST APIs?
The RPG programming language was introduced by IBM in the RPG originated in the 1960s (RPG II), with RPG III and RPG IV (ILE RPG) following later, as most enterprises began adopting client/server architectures. Support for high availability, reliable transactions, and built-in business rules is not going anywhere anytime soon.
Today's businesses have been looking for ways to expose their legacy RPG applications. One popular way to achieve this is to expose these applications as REST APIs. This would enable external applications to communicate with RPG applications without altering the legacy source code.
Figure 1 below shows a high-level architecture diagram that demonstrates how client applications can communicate with IBM i RPG applications.
Figure 1: High-level architecture diagram
Why should I use .NET for this integration?
The .NET ecosystem can act as a bridge between modern application architecture and IBM i systems, connecting your data sources so your .NET applications can communicate directly with an RPG application.
One way among several integration options this can be achieved is by using a data provider, such as the NTi Data Provider, which enables a .NET application to call RPG applications using strongly typed parameters, just like any other reusable service. Most importantly, you don’t have to rewrite your business logic in C#.
Comparing Integrated Web Services (IWS) vs Db2 for i REST services vs .NET wrapper approach
Db2 provides your web, mobile, and cloud applications with a way to access Db2 data via a set of scalable RESTful APIs, which are in turn integrated into the Db2 distributed data facility.
IWS is built for IBM i applications and is tightly integrated with the platform, making deployment and management easy. IWS enables RPG programs to interact directly with IBM i services without using any middleware (i.e., JDBC drivers).
The .NET wrapper approach to modernizing IBM i (AS/400) involves creating a modern C#/.NET wrapper for your legacy RPG application. Organizations can wrap RPG logic in a C#/.NET layer and expose it using APIs and modern web interfaces.
Modernizing RPG applications: When to use .NET and when not to
In this section, we'll examine when .NET is a good choice and when it is not for modernizing legacy RPG applications.
When to utilize .NET
Here’s when you should use .NET to modernize your legacy RPG Applications as REST APIs using .NET:
- When building RESTful APIs to support Web or Mobile integrations
- When you require OAuth2 / OpenID Connect capabilities.
- When you’re developing a centralized authentication strategy
- When you’d like to enforce policies centrally.
- When designing for observability via structured logging, metrics, and tracing.
- When you want to version your APIs and manage their lifecycle.
When not to utilize the .NET
Here’s when you should not use .NET to modernize your legacy RPG Applications using .NET:
- When you're simply going to rewrite existing stable RPG logic
- When all of your workloads are internal to your organization, and you have already optimized those workloads.
- When your organization lacks the required operational readiness to deploy distributed services.
Exposing RPG applications using RESTful Endpoints
The following are the series of steps you should follow to expose an RPG program via a RESTful endpoint.
1. Build a RESTful Web API using ASP.NET Core
2. Use an integration library, such as third-party data providers, such as NTi
3. Call RPG Programs using the library
4. Receive and then process the data
5. Return an HTTP response to the client
The following code snippet shows how you can expose an RPG program named Sample-RPG-01 using a REST endpoint.
app.MapPost("/product/{id}/name", async (
string id,
Product product,
IConfiguration configuration) =>
{
if (string.IsNullOrWhiteSpace(id))
{
return Results.BadRequest("Product id is required.");
}
if (product is null || string.IsNullOrWhiteSpace(product.Name))
{
return Results.BadRequest("Product name is required.");
}
if (product.Name.Length > 50)
{
return Results.BadRequest("Product name must be less than or equal to 50 characters.");
}
var connectionString = configuration.GetConnectionString("IBMi-Connection")
?? throw new InvalidOperationException("IBM i connection string is not configured.");
try
{
using var connection = new NTiConnection(connectionString);
await connection.OpenAsync();
await connection.ExecuteClCommandAsync("Specify your command here…");
var parameters = new List<NTiProgramParameter>
{
new NTiProgramParameter(id, 5),
new NTiProgramParameter(product.Name, 50)
};
await connection.CallProgramAsync("Sample-Library", "Sample-RPG-01", parameters);
return Results.Ok();
}
catch (Exception ex)
{
return Results.Problem("Error occurred while calling the RPG program.", statusCode: 500);
}
})
.WithName("InvokeSampleRPGProgram")
.WithOpenApi();
Here is a typical request/response flow:
- A user enters data into an order form
- A JSON payload is created and sent as an HTTP POST request to your .NET API, as shown below:
POST /api/orders
Content-Type: application/json
{
"id": "P0001",
"name": "Lenovo Laptop",
"status": "Ordered",
"orderDate": "2026-03-05"
}
- The API endpoint receives the JSON payload and binds it to an OrderRequest DTO.
- The controller action method validates the data and translates the DTO to a set of RPG parameters
- Next, it opens an IBM i connection and ensures that the job context is correct.
- Finally, it calls the order entry RPG program with a parameter list corresponding to the RPG signature.
It is imperative to modernize your IBM i incrementally and evolutionarily by integrating evidence-based, proven solutions with new, cutting-edge options. Organizations can maximize the benefits of their IBM i systems by leveraging the .NET REST API pattern today and well into the future.
By 2026 and beyond, the reliability of RPG business logic, combined with .NET's ability to integrate, will enable organizations to take full advantage of the digital economy while enjoying the performance their business relies on. Maximize the value of your IBM i systems and their proven value as an asset by unlocking their applications through modern APIs.
Different Layers of System Management in the IBM i (AS/400) ecosystem
In this section, we’ll examine the various layers of system management in the IBM i 7.4/7.5 ecosystem.
Authority Model and Profile Mapping
This determines who can access what resources and the permissions to those resources. It should be noted that IBM i uses an object-based security model. Profile Mapping is used to manage credentials by mapping external identities, such as LDAP or the Active Directory, to the IBM i User Profiles.
Commitment Control
This relates to data integrity and transaction handling and concerns managing database changes as a single, atomic unit of work, committing or rolling back the changes, ensuring data integrity even in the face of system failures.
Job Handling
This relates to workload or resource management, handling how work, including CPU priority and resource allocation, is submitted, prioritized, executed, and monitored.
High Availability
Typically implemented using Logical Replication or Hardware Replication, this promotes business continuity and almost zero downtime, ensuring data resilience by reducing both planned and unplanned downtime and preventing data loss.
Takeaways
The integration process does not require rewriting the core application. All you have to do is build an interface or an integration surface that wraps your legacy application by following the strategies mentioned below
- Build an extensible and secure API layer
- Encapsulate your business rules instead of duplicating them
- Improve your observability
- Minimize your operational risks
- Provide support for both hybrid and cloud deployments.
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online