Come connettersi a un IBM i (AS/400) da .NET?

Come connettersi a un sistema IBM i (AS/400) da un’applicazione .NET? È una domanda che molti team si pongono ancora, siano essi sviluppatori o responsabili tecnici. La risposta sta in una soluzione: NTi Data Provider.

immagine illustrativa dell'articolo “Come connettersi a un IBM i (AS/400) da .NET?”

Il riflesso abituale consiste nell’utilizzare driver esterni come ODBC o OleDB. Queste soluzioni, spesso gratuite e ancora utilizzate, hanno reso servizio per molto tempo. Si trova anche DB2 Connect, la soluzione IBM più completa ma costosa e complessa da implementare. Tuttavia, tutte si basano su codice nativo compilato per ogni architettura e funzionano al di fuori della CLR (.NET Common Language Runtime, il motore di esecuzione standard di .NET). Risultato: un’integrazione incompleta nell’ecosistema .NET, limitata unicamente al database, con dipendenze proprie di ogni ambiente e una portabilità ridotta delle applicazioni.

Confronto tra ODBC/OleDB/DB2 Connect e NTi Data Provider per collegare IBM i a .NET

NTi porta un approccio diverso, decisamente moderno. Interamente basato sulla CLR .NET, è multipiattaforma (Windows, Linux, macOS) e non richiede alcuna dipendenza esterna. Nessuna installazione è necessaria lato IBM i, tutto viene eseguito nell’ambiente .NET, come qualsiasi altro provider.

In pratica, la connessione a IBM i avviene come con qualsiasi altro DBMS supportato da .NET. La differenza essenziale è che si tratta di un provider ADO.NET dedicato a IBM i, AS/400, iSeries, progettato e ottimizzato per DB2 for i. In altre parole, il principio è esattamente lo stesso che per gli altri database:

NTi Data Provider multipiattaforma: compatibilità con ARM64, AMD64 e ppc64le con .NET

Connessione.

In pratica, la connessione a IBM i avviene come con qualsiasi altro DBMS supportato da .NET. La differenza essenziale è che si tratta di un provider ADO.NET dedicato a IBM i, AS/400, iSeries, progettato e ottimizzato per DB2 for i. In altre parole, il principio è esattamente lo stesso che per gli altri database:

  • Per SQL Server, si utilizza SqlConnection.
  • Per PostgreSQL, si utilizza NpgsqlConnection.
  • Per IBM i, si utilizza NTiConnection.

Il codice è identico nella sua struttura, sia che si tratti di aprire una connessione sia di eseguire un comando SQL. L’unica differenza si trova nella classe utilizzata e nella stringa di connessione, tutto il resto si basa sul modello standardizzato ADO.NET.

Installare i pacchetti NuGet

In Visual Studio, aprire la console e installare:

Install-Package Aumerial.Data.NTi

Connessione di base.

using Aumerial.Data.Nti;
using var conn = new NTiConnection("server=myIBMi;user=myUser;password=myPassword;");
conn.Open();

 try
 {
     conn.ExecuteClCommand("CRTLIB LIB(MYLIB) TEXT('new library')");
 }
 catch(NTiException ex)
 {
     Console.WriteLine(ex.Message);
 }
 conn.Close();

Se conosci SqlConnection, conosci già NTi. Hai così la garanzia di una presa in mano immediata per qualsiasi team che abbia già competenze .NET, senza bisogno di conoscenze specifiche di IBM i.

Novità e proprietà di connessione.

NTi si è evoluto nelle sue ultime versioni per rispondere alle esigenze di prestazioni e sicurezza delle applicazioni moderne, ma anche alle aspettative espresse dai nostri clienti. Queste funzionalità si attivano direttamente nella stringa di connessione, allo stesso modo dei parametri classici server, user e password.

Dalla versione 3.2.3 è disponibile un connection pool, attivato per impostazione predefinita. In pratica, le sessioni IBM i vengono riutilizzate invece di ricreare un job (QZDASOINIT) a ogni richiesta, riducendo drasticamente i tempi di risposta e migliorando la scalabilità delle applicazioni, in particolare con Entity Framework Core.

La sicurezza è stata inoltre rafforzata con il supporto dell’autenticazione multi-fattore (MFA) a partire dalla versione 4.4.0. NTi si basa sul meccanismo TOTP introdotto da IBM nella versione V7R6 del suo sistema operativo. Un codice monouso può essere trasmesso direttamente nella stringa di connessione o recuperato tramite un callback, permettendo di integrare facilmente l’MFA nelle applicazioni .NET già esistenti.

Un argomento, tra l’altro, al centro dell’attualità: è stato ampiamente discusso durante l’evento Securit.i Securit.i edizione 2025, appuntamento di riferimento sulla sicurezza IBM i, dove le novità della V7R6 e l’MFA occupavano un posto centrale. Con NTi, questa evoluzione è già disponibile e operativa nei vostri progetti .NET.

Va inoltre notato che NTi stabilisce la connessione a IBM i tramite canali standard TCP/IP, basandosi sui servizi abituali del sistema:

  • QZDASOINIT per il database
  • QZRCSRVS per i programmi e i comandi
  • QZSOSIGN per il sign-on

È possibile attivare una connessione crittografata SSL/TLS con un semplice parametro nella stringa di connessione, garantendo che gli scambi tra l’applicazione .NET e IBM i rimangano protetti. La configurazione SSL deve ovviamente essere realizzata in anticipo per poter stabilire questo tipo di connessione.

Entity Framework Core con NTi

Entity Framework Core (EF Core) è il framework ufficiale di Microsoft per l’accesso ai dati in .NET. Fornisce un livello di astrazione che consente di manipolare i dati direttamente tramite codice C# (LINQ), senza scrivere SQL esplicito.

Con l’estensione EF Core disponibile con NTi, beneficiate di questo approccio standard ma dedicato a DB2 for i. La vostra logica di business rimane interamente in C#, e le query SQL vengono generate automaticamente verso IBM i.

  • Database First (DB First): a partire dalle tabelle e dagli schemi esistenti su DB2 for i, generate direttamente le vostre entità C#. È la soluzione ideale per modernizzare un database già in produzione senza disturbare i team di business.
  • Code First: definite le vostre entità direttamente in C#, ed EF Core crea la struttura corrispondente in DB2 for i, con il mapping automatico dei tipi corretti. Ideale per i nuovi progetti.

Tutte le operazioni classiche sono coperte: creazione, lettura, scrittura e cancellazione (CRUD) ma anche join, aggregazioni, paginazione o query parametrizzate. Lo sviluppatore .NET rimane in un contesto omogeneo, senza doversi preoccupare delle specificità di DB2 for i.

Esempio:


var ctx = new ProductDbContext();
string filter = "PROD";

var data = ctx.Products
              .Where(p => p.Label.Contains(filter))
              .Select(p => p.Label.Trim())
              .ToList();

Generato automaticamente lato IBM i:

SELECT TRIM(p.Label)
FROM Products AS p
WHERE POSITION(@__filter_0, p.Label) <> 0

L’ultima versione dell’estensione va oltre aggiungendo un mapping preciso delle funzioni scalari native di DB2 for i. In concreto, quando uno sviluppatore utilizza metodi comuni in C# (stringhe, numeri, ecc.), essi vengono tradotti in istruzioni SQL tipizzate “DB2 for i”. I calcoli e le trasformazioni non sono quindi più simulati lato .NET, ma eseguiti direttamente da DB2 stesso su IBM i. E poiché è progettato per gestire e processare carichi elevati in totale affidabilità, è il luogo migliore per delegare queste operazioni al fine di garantire risultati precisi e prestazioni ottimali.

Conclusione.

Non si costruisce il futuro con gli strumenti del passato. I driver storici vi hanno sicuramente accompagnato a lungo, ma oggi mostrano chiaramente i loro limiti non appena si parla di evoluzione, cloud, container o portabilità. Continuare a farvi affidamento significa scegliere un debito tecnico crescente e rimandare i problemi a domani.

Con NTi, cambiate prospettiva: optate per un connettore .NET nativo, stabile e sicuro, progettato e pensato per integrarsi naturalmente nei vostri progetti .NET/IBM i a lungo termine.

Quindi, se la domanda rimane — Come collegare il vostro IBM i (AS/400) a .NET? — la risposta è ormai evidente: non con soluzioni rattoppate, ma con il meglio che oggi offre il mercato. E il modo migliore per convincersi rimane ancora provarlo.

Richiedete oggi stesso la vostra licenza di prova NTi e misurate voi stessi la differenza.

Quentin Destrade

Indietro